מאיר אדלר, ה-CTO של CA Technologies: "מתודולוגיית DevOps יכולה לצמצם חובות טכניים שמדכאים את החדשנות"
חלקו השני של הראיון
כיצד מתודולוגיית DevOps עוזרת לצמצם חוב טכני?
להימנע מהוצאות בזבזניות – "כשהחבר המתכנת שלי החזיק ביד כרטיס אשראי, הוא חגג כמו ילד בחנות ממתקים. הוא לא הצליח להתגבר על הדחף לבזבז בגדול ולדחות את התשלום למשכורת הבאה. גם במחלקת המחשוב אנו סובלים מהרגלים פסולים ודומים, שלמרבה הצער אימצנו לעצמנו. כך, למשל, אם חלים באופן קבוע עיכובים בתהליכי השחרור והפרישה, הרי שמפתח עמוס עלול 'לדחות' חלק מתהליך האופטימיזציה של הקוד, מתוך ידיעה שיוכל לשוב אליו במועד מאוחר יותר, משום שממילא הקוד לא ישוחרר בתקופה הקרובה שלאחר מכן. מובן מאליו שהתיקונים האלה לעולם לא יבוצעו.
כדי להילחם בהרגלים הפסולים האלה, על הצוותים לאתר ולשלול את התנאים שמעודדים אותם. כך, למשל, על מנת למנוע ליקויים יכולים הצוותים להקדים את שלב הבדיקות במחזור החיים של התוכנה. בשילוב עם תהליכי פרישה אוטומטיים, לא יוכלו עוד הצוותים להסתיר את הקוד הרשלני מאחורי המסך של הדחיות, העיכובים וצווארי הבקבוק של שחרור התוכנה.
לאחד את ה-'חובות' – אנשים שסובלים מבעיות אשראי נוטים, לעתים קרובות, לפזר את החוב בין כרטיסים מרובים. במחלקת המחשוב, מפוזר החוב שלנו לעתים קרובות בין מערכות מרובות, שחלק גדול מהן נסמך על מסדי קוד שתוכננו ופותחו באופן גרוע. בתנאים כאלה, אין זה מפתיע שתיקונים לטווח קצר וקוד גרוע הולכים ומתרבים. אם הקוד גרוע מלכתחילה, מה הטעם ליישם בו פתרונות אלגנטיים?
אי אפשר למצוא מענה קל לבעיה הזו, ועצתי היא להתחיל בפרויקט שנועד לזהות את הבעיות המשמעותיות ביותר – ולטפל בהן בשלב ראשון. זו אינה משימה פשוטה, מפני שצריך למצוא את האיזון ההולם בין פיתוח של אפליקציות חדשות לבין תשלום של חובות העבר. אולם, בטווח הארוך, היתרונות גוברים על ההספקה האיטית יותר בטווח הקצר – אם לא חוזרים, כמובן, על שגיאות העבר בעיצוב ובתכנון.
לפנות לעזרה וייעוץ – מאחר שלא קל להתגבר על ההרגלים הבזבזניים, מי שסובלים מהם בתחום האישי פונה בדרך כלל לעזרה. בתחום של פיתוח התוכנה, כוללת העזרה ביקורת של הקוד על ידי עמיתים, חניכה והדרכה מהמנהלים. אולם, לעתים קרובות מדי מתמקד הייעוץ אך ורק בפיתוח – וכתוצאה מכך לא נחשפת מחלקת המחשוב די הצורך לשיקולים התפעוליים, או, גרוע עוד יותר – מתעלמת מהם כליל, עד שה-'חוב' גולש ומציף את סביבת הייצור.
כדי למנוע מצבים כאלה, חייבים לערב את אנשי התפעול של המחשוב כבר בשלבי הפיתוח המוקדמים, ולהמשיך ולקבל מהם משוב חיוני (דוגמת הנחיות לניהול ביצועים) לכל אורך מחזור החיים של פיתוח התוכנה. בדיוק בכך יכולה לסייע מתודולוגיית DevOps, שכן היבט חשוב שלה הוא שיתוף פעולה ותקשורת הדוקים יותר בין צוותי הפיתוח לצוותי התפעול.
לא להעניק תמריצים שמעודדים הוצאה – אנשים נוטים להיכנס לחובות מפני שהם נכנעים לפיתויים, דוגמת 'הזמן היום וקבל כפליים נקודות נוסע מתמיד' או '0% ריבית בחצי השנה הראשונה' (ואחר כך ריבית נשך). למרבה הצער, גם בפיתוח תוכנה נוטים לעתים קרובות לחלק 'גזרים' כאלה – תמריצים מפתים הקשורים למספר התפקודים, סיפורי המשתמשים או אפילו שורות הקוד שכותב המתכנת.
גישה כזו מבטיחה שייכתב קוד רב, אבל מה באשר לשימושיות? תפקודים רבים יותר עשויים להקנות למפתחים אור ירוק, אולם מאליה עולה השאלה אם הלקוח יאהב את התפקודים האלה. מעבר לכך, אם המפתחים מקבלים תמריצים על הנפקה גרידא של קוד, למה שיהיה אכפת להם אם איכות הקריאות למסד הנתונים של האפליקציה אינה אופטימלית, או אם האפליקציה אינה עומדת בדרישות האבטחה והעמידה בתקנות?
לפעול יחד לצמצום ה-'חוב' – קל להאשים את צוותי הפיתוח בצבירת 'החוב הטכני', אבל סביר להניח שצוותי התפעול אשמים בכך לא פחות. כך, למשל, אם לא מתעדים את שירותי התשתית, משך האבחון של הבעיות יהיה ארוך יותר, בעוד שתמונה דלה ביחס לביצועי האפליקציות והקיבולת בשלבי טרום ייצור עלולה להוביל לרכש מיותר של חומרה.
גם במקרה זה, עבודה משותפת על פי מתודולוגיית DevOps יכולה להועיל. מעורבות של צוותי הפיתוח בתוכניות שוטפות לצמצום ה-'חוב', לפי מתודולוגיית DevOps, יכולה לסייע באיתור יעיל יותר של אזורים שבהם אפשר לשפר את הניצולת של האנשים, התהליכים והטכנולוגיה. כך, למשל, ביקורת וניתוח משותפים של דפוסי השימוש יכולים לסייע לצוותי התפעול להבין כיצד תצורה גרועה של הרשת מגדילה את העכבה, וחשוב אף יותר – פוגעת בחוויית הלקוח.
לסיכום: בעידן שבו הלקוחות חורצים גורלות, התעלמות מ-'החוב הטכני' עלולה להנחית מכת מוות. בסופו של דבר, 'החוב הטכני' עלול לעלות לארגון בדם, יזע ודמעות, ולגזול משאבים שאותם ניתן היה להקדיש לחדשנות דיגיטלית ומפנה בעסקים".
