לפני 23 שנים התחלתי לעבוד בסטרטאפ הראשון שלי, שכלל צוות של 20 איש. המוצרים שלנו היו כמה אפליקציות גדולות ומונוליטים אימתניים (אפליקציות גדולות שצורכות שירותים רבים). קו התקשורת היה נוראי, הבילד היה איטי להחריד והכל היה צריך להיות מסונכרן. בכל פעם שהעלנו גרסה לשרתים בארה"ב זה לקח שלוש (!) שעות. גם ההוראות מהממונים היו קשות: "אל תתקין את A לפני ש-B מתחיל, שים לב ש-C קופץ לפני D", בקיצור, אללה יוסתור - איזו תקופה נוראית.
אחרי כמה חודשים ראש הצוות שלי העלה רעיון לאוטומציה. הוא תפס אותי בזמן שישנתי על המשמר: "שומע? אתה אולי מפתח ג'וניור, אבל יש לי בשבילך משימה מיוחדת". כמה מיוחדת אתם שואלים? שלחו אותי מעבר לקווי האויב, לבד. השיחה, או יותר נכון, המונולוג שקיבלתי מראש הצוות, הלך בערך ככה: "יש כלי חדש שנקרא ANT (לא ניכנס לזה עכשיו) - קח לעצמך כמה ימים, תכתוב לנו משהו שישפר את התהליך". ופשוט נשלחתי לדרכי, לגמרי לבדי.
אז כתבתי וכתבתי, ואחרי עבודה מאומצת, לבסוף עמד מולי תהליך שלם שמריץ בדיקות, עושה אריזות, מבצע סנכרון, מוודא תקינות ומגדיר דשבורדים עוד לפני שקראו לזה פייפליין. הפלא ופלא, ירדנו משלוש שעות לרבע שעה.
כש-Dev פגש את Ops
קפיצה בזמן יותר מעשור קדימה. פתחתי איזה סטארטאפ קטן. גם שם עשינו הכל לבד: הייתי גם מפתח Backend, גם מפתח Frontend וגם מפתח אוטומציה - מה שנקרא היום בשפת העם DevOps. למה? פשוט כי לא היה מישהו אחר.
התקנתי, קינפגתי ובניתי סקריפטים שלמים שמתפעלים את המערכת. אמנם לא מיקרו שירותים, אבל שלוש אפליקציות שונות, עם בדיקות שונות ושרתים שונים בלוקיישנים שונים. בילדים עפו לכל עבר, והפקודה המשומשת ביותר הייתה "העתק" (SCP). ככה הדרך התחילה, למדתי את הערך שבחיבור בין פיתוח לתפעול.
טרנספורמציה
כשהגעתי לעבודה בבנק, חשבתי שכולם צריכים להכיר את הדברים כפי שאני מכיר אותם. סברתי שעבור כל מפתח, היכרות מלאה עם האקוסיסטם שבה הוא מייצר, היא הכרח. חשבתי שכמו ברכב, כדי להיות נהג מיומן באמת, אתה צריך לדעת מה קורה גם מתחת למכסה המנוע. קראתי לזה Developer Empowerment. מאז התפכחתי והתבגרתי, ולונג סטורי שורט - טעיתי בגדול.
אשתי, למשל, מעולם לא פתחה את מכסה המנוע של הרכב, אבל היא נהגת מעולה. הבנתי שאת הכלל הזה צריך ליישם גם בגישה שלי לעבודת הפיתוח בבנק. לא כל מפתח צריך לדעת גם אופרציה. אולי האחריות מקצה לקצה על הקוד היא רלוונטית יותר לסטארט-אפ, שם התהליכים פשוטים יותר, הכלים הדוקים, הדרישות צנועות והכמות קטנה - אבל בארגון גדול זה פשוט לא ישים.
נכון שמפתחים תמיד צריכים להרחיב את היריעה על המוצרים שהם עובדים עליהם, אבל לבקש מהם להתמחות בעולמות התוכן של DevOps - זה אולי קצת יותר מדי. אנחנו מבקשים מהם היום להבין עשרות תהליכים וכלים - למעשה עולם תוכן כל כך גדול שהוא כמו עוד תפקיד. בדרך ל-Production, מה שהיה פעם "תעתיק לספרייה ההיא ותעשה ריסטרט", הפך ל"שומע? אנחנו הולכים להעביר אותך 'ויה דה-לרוזה', בהצלחה".
זו דרישה כמעט לא הוגנת להכיר את הכול בצורה כל כך מקיפה, כי נדרשת לשם כך היכרות אינטימית, זוגיות של ממש. מהכלים דרך הבילד, סריקה של התוצרים, אריזה מחדש (דוקרים), הרצה על סביבות מתקדמות - ולא לשכוח לשמור את הסיקרטים, לבנות דשבורד, להגדיר התראות, לשלוח לוגים, לייצר תעודות, בדיקות כאוס, לפתוח תקשורת, לוודא שהכול למעלה ואז לפנות זמן גם לתהליכים ארגוניים. אללה יסטור, כבר אמרנו?
תנו לפלטפורמה לשרת אתכם
אז מה עושים? טרנספורמציה - גם לכלים ולתהליכים, אבל בעיקר לאנשים. האחריות שלנו היא לפשט עבורם את התהליך, לשבת איתם על MVP בודד, לפצח איתם את האטום - ולרוץ משם. במקום המודל של זוגיות ארוכה - בואו נצא ל-3-2 דייטים במקום. רק להכיר, לא להתעמק.
המסר שלי למפתחים הצעירים הוא כזה :תתרכזו בלייצר את הקוד שמביא את הערך העסקי לארגון, ואנחנו (המנהלים? הסיניורים?) נעזור לכם ונארגן מסביב. תנו לפלטפורמה לשרת אתכם, כי זה עולם תוכן שלם. בכל יום שעובר הטכנולוגיה מתקדמת, והכל נהיה מורכב יותר: צריך גם לפתח ולעמוד ב-KPI עסקי, גם לעמוד ב-SLA, גם לבנות ארכיטקטורה חדשה וגם להבין את התהליך. Too Much, כבר אמרנו?
מה שאנחנו באמת צריכים לעשות זה להגדיר מדדים על ידי בחינה ואיטרציות מהירות, כדי לדייק את השירות של המפתחים, לשבת איתם על התהליך שלהם, לחקור איתם את הארכיטקטורה ואפילו לתקן אותה אם נדרש, להגדיר לכל שירות את המדדים הנכונים ולהנגיש להם כלים. למעשה - ללכת איתם יד ביד לעבר השקיעה (או במקרה שלנו, ה-production).
יוני מוזס הוא מנהל תחום ענן בחטיבה הטכנולוגית בבנק הפועלים
מתוך CodeReview - מגזין החטיבה הטכנולוגית של בנק הפועלים