למה מנכ"לים שונאים DevOps?

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

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

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

פיתוח תוכנה זמיש האיץ את הפיתוח והזיז את צוואר הבקבוק של הדילוור לגופי התפעול. כתוצאה מכך, אנחנו עדים למנעד של חברות: בקצה האחד – ארגון טיפוסי שמשחרר גרסה חדשה אחת למספר שנים (לחברות ותיקות), או במקרה הטוב 2-3 פעמים בשנה. בקצה השני – חברות כמו פייסבוק (Facebook), שמדלוורת יותר מגרסה בכל יום, ו-Github, שמדלוורת יותר מ-100 גרסאות בכל יום.

מודל הבשלות

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

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

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

להלן מודל הבשלות שלנו:

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

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

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

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

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

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