מה זה DevOps? הסבר פשוט לבעלי עסקים

DevOps היא פרקטיקה ותרבות עבודה — לא תפקיד או כלי בודד — שמחברת בין האנשים שבונים תוכנה לבין האנשים שמריצים אותה, כך ששינויים חדשים אפשר לשחרר לעיתים קרובות, במהירות ובבטחה, במקום באצוות גדולות, מסוכנות ונדירות. המילה עצמה היא צירוף של 'Development' (פיתוח) ו-'Operations' (תפעול), והיא מתארת דרך עבודה, לא מוצר שמתקינים.

מה זה DevOps, בדיוק?

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

אילו הרגלים בפועל הופכים את DevOps לעובד?

DevOps היא פילוסופיה, אבל היא הופכת למשהו אמיתי דרך סט מסוים של הרגלים יומיומיים. שלושה מהם הכי חשובים:

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

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

למה DevOps חשוב לעסק, ולא רק למפתחים?

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

האם DevOps הוא תפקיד או כלי שקונים?

אחת הטעויות הנפוצות ביותר היא להתייחס ל-DevOps כמשהו שרוכשים במקום משהו שצוות שלם עושה. גיוס 'מהנדס DevOps' בודד וציפייה שהוא לבדו יביא לשחרורים מהירים ובטוחים יותר מפספסת את הרעיון — DevOps עובד רק כשהוא פרקטיקה משותפת בין מי שכותב את הקוד למי ששומר עליו פועל, לא אחריות שמוטלת על תפקיד אחד. אותה טעות קורית עם כלים: קניית פלטפורמת CI/CD או דשבורד ניטור לא יוצרת DevOps כשלעצמה. הכלים תומכים בפרקטיקות; הם לא מחליפים את השינוי התרבותי שבו כל הצוות לוקח בעלות משותפת על שחרורים ואמינות. תפקיד בשם 'מהנדס DevOps' אכן קיים בתעשייה, ולרוב מתאר מישהו שבונה ומתחזק את האוטומציה והתשתית שמאפשרות את הפרקטיקות האלה — אבל הפרקטיקה עצמה אמורה להיות בבעלות כל הצוות, לא מוסטת החוצה לתפקיד אחד.

את מה DevOps מחליף?

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