מה זה DevOps? כל מה שרצית לדעת (ולא העזת לשאול)

מה זה DevOps
שיתוף ב facebook
שיתוף ב linkedin
שיתוף ב whatsapp

מה זה DevOps בדיוק?

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

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

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

תוכן עניינים

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

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

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

עקרונות הליבה של התפיסה (לפי גוגל): 

  1. מעורבות ה- IT ושאר פונקציות האופרציה (Support, Help Desk, אנשי IT) בכל שלב של תכנון ופיתוח המערכת.
  2. הסתמכות רבה על אוטומציה כדי לחסוך מאמץ אנושי.
  3. יישום שיטות וכלים עבור תפעול המוצר, ועבור ביצוע משימות.

המטרה של ארגון שמא​​מץ השקפת עולם DevOps-ית היא להגדיל את השקיפות, התקשורת ושיתוף הפעולה בין הצוותים.


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

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

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

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

תהליך פיתוח מוצר בתרבות DevOps
תהליך פיתוח מוצר טיפוסי בתרבות DevOps

DevOps כתפקיד

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

כדי להיות יותר יעילים, מנהלי הארגון ישקלו להטמיע כמה שיותר:

  • בדיקות אוטומטיות
  • אוטומציה של כל מיני תהליכים – מהגעה או עזיבה של עובד את הארגון, עד הכנסה של פיצ׳ר חדש לתוך המוצר.
  • אימוץ תהליכי CI/CD – ״מסירה רציפה״ (נסביר בהמשך), ו״בנייה רציפה״ של המוצר. כלומר, שאיפה שהתהליכים סביב הפיתוח שיהיו כמה שיותר רציפים. ללא הפסקה.
  • ניהול יעיל של משאבי הארגון – כמו מסדי הנתונים או כל משאב שעשוי לעלות הרבה כסף בשימוש לא נכון.
  • יכולות ניטור על המוצר –  בקרה על הקוד, ניטור על העלויות, בקרה על הביצועים של המפתחים.
  • שמירה על סטנדרטים גבוהים יותר של קוד ובדיקותיו – למשל, באמצעות יצירת פייפליין שלא מאפשר לדחוף שינוי שלא עובר את הטסטים.
  • מניעת פיתוח מיותר –  בין היתר באמצעות:
    – יכולת שימוש בכלים Third party כדי להימנע מפיתוחים מיותרים
    – מניעת מצב של פיתוח זהה בחברה פעמיים
  • מנגנוני התראה בזמן אמת
  • מניעה של פרוצדורות שיפגעו בארגון – כמו פגיעה בצד האבטחתי שלו
  • כלים למציאת באגים


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

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

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

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

DevOps תפקידים
תפקיד ה- DevOps לשפר את יעילות הארגון ע”י שימוש בסט כלים מגוון

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

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

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

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

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

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

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

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

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

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

DevOps אחראי בין היתר על ניהול המשאבים הבאים:

  • מסדי נתונים
  • מערכת ניהול הגרסאות של הקוד
  • השירותים השונים שהחברה משתמשת בהם
  • כלים ללימוד וקריאה של הלוגים
  • מערכות ניטור (log shipping systems למשל)
  • מערכות התראה (victorOps, pagerDuty)
  • משאבי ענן (AWS, Google cloud, azure) – סביבות לבדיקות המוצר (כמו למשל מכונת staging) וכלים אחרים שהארגון יכול לספק.

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

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

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

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

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

3. ניטור

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

סוגים של ניטור

  • התראות – למשל, אימייל למפתח של השירות: ״השירות שלך תקוע מעל לשעה״, או שימוש בהתראות של מערכות ייעודיות לשם זה (ב-SMS, או אפילו טלפון שמצלצל אם התקלה חמורה). 
  • לוגים וטרייסים – מידע שמגיע תוך כדי השימוש במוצר ואפשר להשתמש בו לצרכי חקירה.


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

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


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

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

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

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

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

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

אימפקט של DevOps בארגון

99% מהחברות שיש להם פונקציית DevOps העידו על impact חיובי

אותם ארגונים הדגישו את ההיבטים הבאים:

  1. 48% ציינו ששימוש בפונקציית DevOps עזר להם לגדול
  2. 61% ציינו שאיכות ה-delivery של המוצר עלתה
  3. 49% טענו שהם מגיבים מהר יותר לשוק
  4. 49% אמרו שהם שפרו את תדירות ה-deployment של המוצר שלהם


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

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

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

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

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

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

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

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

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

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

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

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

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

המאמר עזר לך? כאן משתפים >>

שיתוף ב facebook
שיתוף ב linkedin
שיתוף ב whatsapp

מומלצים מהערוץ שלנו:

רוצה להישאר בלופ?

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

*מבטיחים לא לחפור:)