מה זה DevOps ולמה יש ביקוש כל כך גבוה למקצוענים בתחום?

מה זה DevOps בדיוק?

לפי גוגל, מדובר באוסף של פרקטיקות, קווים מנחים ותרבות. בגדול, מטרת ה-DevOps היא להקל על הפיתוח, אופרציות ה-IT, השיתופיות וגם על האבטחה.

אך מכיוון שההגדרה הזאת כללית מדי (ולא בטוח שהיא אומרת לכם הרבה), במאמר הזה נחלק אותה לשניים: 

1. DevOps כתרבות (או תפיסת עולם)
2. DevOps כתפקיד

תפיסת עולם של DevOps (דבאופס כתרבות)

אם תשאלו בחברות הייטק שונות "מה זה DevOps?" אתם כנראה תקבלו תשובה אחרת לגמרי מכל אחת. הסיבה לכך היא ש- DevOps זה קודם כל סוג של תרבות. 

התרבות הזאת כוללת שיתוף פעולה בין המפתחים ושאר החלקים האופרטיביים בחברה. 

כדי שארגון בצמיחה יתקדם לעבר התרבות הארגונית שהוא מעוניין בה, ההנהלה שלו יכולה לאמץ:

• חלוקת משימות יעילה בין הצוותים
• שימוש בכלים אוטומטיים (לא להיתלות רק באנשים, אלא בתהליכים ברורים)
• שמירה על קונבנציות (תפישה משותפות בין המפתחים) 
• תקשורת בין המפתחים
• ביורוקרטיה – ברור מאד מה כל עובד עושה (תלוי כמובן כמה)
• בקרת איכות מתמדת על המוצר
• בקרת איכות מתמדת על תוצרי העובדים

בתרבות דבופס, תהליך פיתוח המוצר בארגון יכול להראות כך: 

תכנון (פידבק מתמשך בשלב התכנוןעבור פיצ׳רים משמעותיים) >> תכנות >> בדיקה לוקאלית >> ״בנייה״ >> הרצת טסטים >> הוצאת גרסה >> דפלוט (הכנסה לתוך הפרודשן) >> תפעול >> ניטור (בדיקה שהכל בסדר ומה אפשר לשפר) 

DevOps כתפקיד

כשמתייחסים ל- DevOps כתפקיד, הכוונה היא לסט פעולות שמטרתן לשפר את יעילות הארגון.

בארגונים שונים יהיו הטמעות שונות לשימושים שהזכרנו. אצל חלק, כלי הניטור על המוצר מוגדרים על ידי המפתחים של המערכת עצמם. אצל אחרים, יהיה סטנדרט אחיד על הניטור, והוא יהיה מבוסס על כלים שצוות ייעודי פיתח.

הצוות שאחראי על ניהול הכלים השונים של ״תרבות ה-DevOps״ שציינתי, נקרא בשם המפתיע: צוות DevOps.

איש DevOps, או DevOps, או DevOps Engineer הוא עובד שמקבל תחת אחריותו ניהול של חלק מהתחומים שהזכרתי.

בשנים האחרונות המושג הפך לבאזזוורד בעקבות ההתאמה שלו לארגונים בכל הגדלים, והמשכורות הגבוהות בתחום. אך מעבר לבאזז שנוצר סביב התחום, דבופס טוב הוא חלק משמעותי בצמיחה של ארגון והפיכת המוצר לסקלבילי.

מה מפתח DevOps עושה?

בקצרה, דבאופס משלב של Dev (פיתוח – Development), ו- Ops (אופרציות – Operations). הרעיון הוא שאם יש תהליכי IT בארגון (אופרציות) – אז שיהיו כמה שיותר אוטומטיים. 

מפתח DevOps מפתח, מטמיע, מלמד, או מאפשר בצורות אחרות – כלים שיאפשרו להטמיע תפיסה DevOps-ית. למשל, בארגון מסוים הוא יכול להיות זה שנותן הרשאה לדחוף שינויים באחד מה-repos.

בארגונים אחרים הוא יפתח תשתית להעברת הלוגים של המוצר שבה המפתחים האחרים ישתמשו, או אולי תשתית שמרימה ומורידה מכונות בהתאם לביקושים למוצר. במקרים אחרים, אנשי דבאופס יכולים לפתוח תשתית לבדיקת המוצר (למשל מכונת בדיקות), ולתת הרשאות לשימוש ב-database ב-production.

בכל אופן, ישנן המון פרוצדורות שונות שנכללות תחת התפקיד הזה מעצם הההגדרה הרחבה שלו: לגרום לארגון להיות אפקטיבי יותר.

תחומי האחראיות של ה- DevOps

התפקידים השונים של הדבופס כוללים פיתוח של פרצדורות, ושימוש בכלים הבאים (שמשתנים בין ארגונים):

1. ניהול משאבי הארגון

שירותים שהארגון משתמש בהם עולים כסף, עולים תחזוקה (שמתרגמת בעצמה לכסף), ויש גם חשיבות לבחירה של המשאב מהיבטים אחרים: מהירות שימוש, אמינות, זמן החזקה של המידע, כמה משאבים הוא דורש וכו׳.

פעמים רבות ה-DevOps ילמד את הצורך של המפתח שפונה אליו. בהתאם למידת הצורך, הוא ייתן הרשאות נכונות לשימוש במשאב (למשל – הרשאות קריאה בלבד), או ייעץ למפתח על שיטה אחרת שרלוונטית עבור הפיתוח שלו יותר.

2. בניית תהליך CI-CD

תהליך ה-CI-CD מתחלק לשניים: CI – Continuous Integration כלומר – אינטגרציה רציפה, ו-CD – Continuous Delivery כלומר – ״שילוח״ רציף.

בקצרה, זהו תהליך שמאפשר לגרום לקוד של המפתח להיכנס למוצר בצורה כמה שיותר בטוחה, יעילה ומהירה.

מפתח ה-DevOps יהיה אחראי בדרך כלל על חלק מהפעולות הבאות:

1. בניית פייפליין עבור שירות ספציפי
2. בניית כלים המאפשרים לייצר תהליך כזה לכל מוצר בקלות, עם קונבנציה זהה לכל תת שירות בארגון
3. מתן ייעוץ לגבי התהליך עצמו
4. בנייה של חלקים מתוך התהליך

3. ניטור

המוצר עובד? צריך לדעת איך, כמה משתמשים בו, כמה תקלות יש בו. המטרה היא להגיע למצב שהלקוח יתלונן פחות, והמפתחים יוכלו לזהות את הבעיה לפני שמישהו מתלונן.

כפי שבטח שמתם לב, ישנם הרבה תתי-תפקידים שיכולים להכלל תחת ההגדרה של תפקיד ה-DevOps.

בחלק מהחברות הוא משמש כיועץ או נותן הרשאות. בארגונים אחרים יש הרבה מאד פונקציות שמבצעות את חלקי התפקיד שלו, ול- DevOps עצמו יש משימות מוגדרות יותר. לפעמים תחתיו ירוכזו הרבה תפקידים אחרים.

האימפקט (מידת ההשפעה) של ה- DevOps על הארגון

לאנשי DevOps יש השפעה עצומה על הארגונים שלכם שכוללת חיסכון בכסף, ייעול שימוש במשאבים, הפחתת סיכונים חיצוניים, ושיפור במהירות.

באופן כללי, יהיה קשה לארגון לבצע אדפטציות מהירות בלי ישות כלשהי שתעזור בניהול של הפרצדורות סביב זה. 

הארגון יודע לעבוד נכון יותר, ולהתאים את עצמו לשינויים רבים יותר בזכות הטמעה של תפקיד כזה. לכן, בעקבות הערך הרב של שימוש בפונקציה הזו, יותר ויותר ארגונים מטמיעים אותה.

חשוב להבין שתנאי הכרחי ל-agility (״זמישות״ – זמינות וגמישות) של ארגון הוא הטמעת גישת DevOps. זאת משום שלתרבות יש אפקט משמעותי על ביצועי החברה. במחקרים נמצא כי לתרבות הארגונית יש השפעה עמוקה על מגוון הארגונים, העובדים וביצועיהם.

לפי 2020 DevOps Trends Survey של Atlassian & CITE Research כ-90% החברות דיווחו על impact גבוה בהחדרת תרבות DevOps לארגון. היות ש-85% מהארגונים נתקלו במכשולים בהטמעה התרבות, נראה ששימוש בכח אדם ייעודי יכול לקדם ארגונים.

תפקידים דומים ל-DevOps

כפי שציינתי, ל-DevOps יש המון תפקידים אפשריים, אבל בארגונים שונים בוחרים לחלק את האחריות לכמה תפקידים שונים:

1. SRE – אחראי על היציבות של המוצר: ניטור, עלויות ועוד.
2. DBA – מנהל מסדי נתונים
3. Automation Engineer – מפתח אוטומציות. זה יכול להיות שונה לחלוטין, ויכול להיות מאד דומה (תלוי אילו אוטומציות הוא מפתח)
4. IT – בארגונים מסוימים יש לו תפקידים שיכולים להשיק ל-DevOps – כמו התקנות והרשאות.

איך מגיעים לתפקיד DevOps

התשובה הרווחת היא שזה לא תפקיד התחלתי. בהרבה מקרים מגיעים אליו או מקידום פנימי בארגון, או אחרי רצף תעסוקתי בתפקידים דומים שכוללים פיתוח או IT.

הסיבה היא שמי שמתעסק בפרודקשן של המוצר צריך להכיר את הסביבה של המוצר. מעבר לכך, לדעת מה מפתחים צריכים, או לפחות לדעת צד אחר במשוואת הדבופס: מה זה IT, או מה האופרציות סביב המוצר. מה זאת הטמעה של שינוי, מה התהליכים אומרים בכלל.

היות שהביקוש לאנשי DevOps גובר כל הזמן, בפועל אפשר להגיע לתפקיד גם כג׳וניור ללא ניסיון. בדרך-כלל הגדרת התפקיד תהיה דלה יותר או תדרוש ביצוע של משימות עם הגדרה שונה מ-DevOps באמת (למשל משימות IT כאלו ואחרות). בכל אופן, זה תהליך שדורש תכנון נכון וזמן.

אם התחום מעניין אתכם, אני מציע לנסות להשתמש בחלק מהכלים שהזכרתי לאורך המאמר.

>> לקריאה נוספת: 7 קורסי DevOps מומלצים שיכניסו אתכם לתחום >>

ספרים, פודקאסטים ומקורות מומלצים בנושא

1. SRE Book – ספר מאד תיאורטי שעוסק בחלוקה שגוגל יצרו בתוך תפקיד ה-DevOps

2. תפקיד ה-SRE – כולל בתוכו חישובים רלוונטיים, איך בוחנים יציבות של מערכת. סוגים של מנגנוני ניטור ועוד המון אספקטים של תחום יציבות המוצר ותפקיד ה-SRE.

3. פודקאסט ״מדברים עננים״ על תפיסת הדבופס

4. ספר ci-cd של אמאזון

5. סקירה מלאה של כל קורסי ה- DevOps בארץ

אייל סגל

SRE ומפתח תוכנה. בוגר תואר מדעי המחשב וניהול בפתוחה, עם 6 שנים בתעשייה, שהובילו אותי לפתוח את פודקאסט "המסלול להייטק".