מה המתכון הסודי של גוגל לתשתיות אמינות?

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

טריינור היה דובר המפתח במפגש מיוחד שערכה ענקית האינטרנט עם חברי פורום C3, פורום המנמ"רים והמנכ"לים של אנשים ומחשבים. המפגש התקיים הבוקר (א') בגלריה דובנוב בתל אביב.

"כל חיי נסבו סביב פיתוח תוכנה וכתיבת שורות קוד", אמר טריינור. "את שורת הקוד הראשונה שלי כתבתי כבר בהיותי בן שש. את העבודה הראשונה שלי כמפתח השגתי בהיותי בן 17, בחברה שהיה לה מוצר מעולה, בשם אורקל (Oracle). מאז ראשית שנות ה-90' אני מהנדס תוכנה".

שירות אמין זמין ויעיל – ובלא השהיות

טריינור הצטרף לגוגל בשנת 2003, ועמד בראש צוות שמנה כמה אנשים מתוך כלל מחלקת התשתיות, שעמדה אז על 100 איש. כיום הוא עומד בראש מערך תמיכה ופיתוח המונה יותר מ-4,000 איש, "האחראים לכך שכאשר משתמשים בשירותים השונים של גוגל, יקבלו תמיד שירות, תמיד אמין זמין ויעיל – ובלא השהיות".

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

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

טריינור הציג תפיסה פרי פיתוחו, אותה מימש בחלוף השנים בענקית ה-IT. לדבריו, זו נועדה לתת מענה לפער האמור. התפיסה, אמר, SRE, ראשי תיבות של  Site Reliability Engineering, לפיה "אנשי התפעול, שאמונים על אמינות המערכות, יעבדו בשיתוף פעולה עם אנשי הפיתוח".

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

מהנדסים עם חיוך

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

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

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

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

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

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

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

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

למצוא את סיבת השורש ולא המהנדס שפישל

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

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