מפתח תורן – או, איך להפוך מטלה מבאסת לאתגר קבוצתי

 

ליאור:            היי ערן.

ערן:               היי ליאור.

ליאור:            היי כולם. הגעתם ל-Startup for Startup, הפודקאסט שבו אנחנו חולקים מהניסיון, מהידע והתובנות שלנו כאן במאנדיי.קום וגם מחברות אחרות, והוא מיועד לכל מי שסטארט-אפ מדבר אליו, לא משנה באיזה כסא הוא יושב ברגעים אלו. [מוזיקה]. תפקיד של Dev on call מוכר לכל חברה עם צוותי פיתוח. זוהי בעצם פונקציה שמוגדרת כחלק ממאמצי החברה לנטר ולתחזק את סביבת ה-production, ולמעשה את המוצר שבו משתמשים הלקוחות. בגדול יש מוצר שהיוזרים שלנו משתמשים בו 24/7 במשך רוב ימות השנה, ואנחנו צריכים לעשות כל מה שאפשר כדי לוודא שהם באמת יוכלו להמשיך ולהשתמש בו ככה. כולל מינוי מפתח תורן שיטפל בתקלות גם באמצע הלילה. אז זוהי מטרה שהיא בעצם צריכה לעשות. עכשיו בוא נבין מה האתגר בלעשות אותה. אז כמו שכל מי שמאזין לנו כבר יודע, מאנדיי צומחת מאוד מהר. ובהקשר הספציפי של dev on call, זה בעצם בא לידי ביטוי בשני מישורים. המישור הראשון הוא כמות המשתמשים שמשתמשים במוצר בכל רגע נתון. והמישור השני כמובן כוח אדם. בכל חודש חמישה מפתחים בעצם מצטרפים ל-R&D אצלנו בחברה. אז מכאן עולה בעצם השאלה איך אפשר לנהל את ה-dev on call בצורה הכי אפקטיבית, גם מבחינת המוצר וגם מבחינת הצוות. ואיך אפשר לקחת מטרה שחייבת לקרות ולשפר דרכה את סביבת הפיתוח. לטובת העניין, כדי להסביר לנו את האתגר טוב יותר וגם את הדרך שבה אנחנו מתמודדים איתו, הצטרף אלינו היום אביתר מוצפי, שהוא ראש צוות פיתוח ב-R&D במאנדיי.קום. היי אביתר, איזה כיף שהצטרפת אלינו.

אביתר:           היי ליאור, היי ערן.

ערן:               מה קורה אביתר?

אביתר:           בסדר.

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

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

ליאור:            וכמה אנשים בעצם מתמודדים עם האתגר הזה שזינמן תיאר קודם?

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

ליאור:            משתנה בין חברה לחברה גם.

אביתר:           כן.

ליאור:            אז איך אנחנו עושים את זה? או איך אנחנו שואפים לעשות את זה, קודם-כל, בוא נתחיל רגע קונספטואלית.

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

ליאור:            אז זה פן אחד של האתגר.

אביתר:           כן. כשמדברים על איך עושים את זה, כאן בעצם נכנס הפן השני. כי יש שתי גישות עיקריות ללנהל on call, אוקיי? גישה אחת זה שיש צוות יחסית מצומצם, לרוב הוא מרוכז בצוות של ה-infra, עם עוד כמה מפתחים, שהם בעצם מטפלים בכל ה-on call. מה זה בעצם אומר dev on call, אולי נדבר על זה שנייה.

ליאור:            כן, כדאי.

אביתר:           כן.

ליאור:            זה נשמע כמו מילואים [צוחקת].

ערן:               כמו שמירות.

ליאור:            כן.

אביתר:           כיתת כוננות, כן.

ליאור:            זה נשמע כמו duty כזה, כן. [צוחקת]

[5:00]

אביתר:           בגדול זה הבן אדם… יש לנו הרבה התרעות על הסביבת production. יש התרעות שאומרות שהמערכת עכשיו במצב פחות טוב, למרות שהיוזרים אולי עוד לא מרגישים את זה. יש לנו המון סוגים של התרעות, ועכשיו השאלה היא מה עושים עם ההתרעות האלה. אז ה-dev on call או הבן אדם הראשון שמקבל את ההתרעה. אנחנו משתמשים במערכת שנקראת pager duty, שבעצם יודעת, מתקינים את זה על הטלפון, זה יודע להתקשר, לצפצף באפליקציה. וממש להקפיץ בכל שעה ביום, בלילה, ולהגיד יש פה התרעה, וההתרעות האלה זה התרעות שאנחנו מקנפגים בעצם. ה-dev on call הוא הבן אדם הראשון שמקבל את ההתרעה. עכשיו, השאלה היא מי יכול להיות dev on call. מי האנשים שזה מתאים להם להיות. אז יש גישה של בעצם לקחת כמות מאוד מצומצמת של אנשים, כי הרבה פעמים זה דברים שדורשים ידע. כאילו, צריך להבין קצת ב-database, צריך ממש להבין בברזלים של הסביבה. לא כל אחד יכול לעשות הכול. אז מביאים את זה לכמות מצומצמת של אנשים שהם סוג של מומחים בזה. בכללי זה הרבה פעמים הצוות dev ops בחברה. והם היחידים שמתעסקים עם הדברים האלה. לשיטה הזאת יש יתרון, שמי שמתעורר בלילה לרוב גם ידע לפתור את הבעיה. הוא יותר מומחה. אבל יש שם גם סכנות.

ליאור:            מה למשל?

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

ליאור:            אדם יכול למצוא את עצמו מתעורר-

אביתר:           כל לילה.

ליאור:            פעמיים-שלוש בלילה.

אביתר:           נכון. שזה גם כאילו סימן לא טוב בלי קשר, כן? אבל-

ליאור:            תיכף נדבר על זה, כן.

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

ליאור:            אז הפער רק הולך וגדל.

אביתר:           בדיוק. ואז, ואת זה מאוד קשה לשבור אחרי שזה התחיל.

ערן:               אני כן רוצה להתייחס למשהו שאביתר אמר, שאני מאוד מאוד מאמין בו ברמה הקונספטואלית, אם נרוץ טיפה קדימה לאיפה שאנחנו נמצאים היום. אני הייתי בהרבה חברות לפני-כן, שכמו שאביתר אמר, יש את הצוות של ה-dev ops. צוות של אנשים שמתעסקים בשרתים. שזה בסדר, כן? זה טוב שיש לאנשים מומחיות מסוימת. אבל הרבה פעמים הנטייה הטבעית היא להגיד המפתח מעלה איזשהו פיצ'ר ב-production, עושה איזשהו שיפור במוצר, לא משנה מה, ואז הוא אומר סבבה, החבר'ה של ה-dev ops, אם תהיה בעיה-

ליאור:            עליכם.

ערן:               נתראה מחר בבוקר, כן. אני ממש לא מאמין בדבר הזה, זה כאילו הכי זריקת אחריות. 90 אחוז מהבעיות בדרך-כלל נובעות מקוד שמכניסים, כי זה הפרמטר שהכי הרבה משתנה. והעובדה הזאת, שמה שזה מייצר לאורך זה שבעצם המפתחים לא חושבים על האספקט הזה, של עומס, של איך היוזרים יגיבו לזה, של איך השרתים מתמודדים עם הדבר הזה. ואז ה-dev ops, אותו בן אדם שכאילו אחראי על השרתים, מעירים אותו באמצע הלילה, אין לו מה להתמודד עם הדבר הזה. וזה מייצר לדעתי אנטגוניזם, זה מייצר פיתוח פחות טוב, קוד פחות טוב. [מוזיקה].

ליאור:            משהו אומר לי שאנחנו לא עובדים ככה.

אביתר:           אנחנו עושים גישה קצת שונה, שהסבב של ה-dev on call בעצם מכיל את רוב המפתחים בחברה. אנחנו עושים סבב כמה שיותר גדול. מכמה סיבות. היתרונות של גישה כזאת זה קודם-כל סביבת ידע הרבה יותר רחבה. זה בעצם משפר את ה-R&D. כלומר, כל אחד נחשף להרה יותר דברים, יודע להתמודד עם יותר דברים. אנחנו, המפתחים פה עם full step, במובן המלא של המילה. כאילו, מה-infra ועד ה-product. לא רק client backend. וזה בעצם משפר את הרמה של ה-R&D, דבר ראשון. דבר שני זה גם בונה איזשהו ownership שאנחנו מאוד רוצים לקדם. כלומר, בן אדם אחראי לפיצ'ר שלו. עכשיו, מה זה אומר שהוא אחראי? זה לא רק לעשות אותו עובד ב-production, זה גם לנטר אותו, זה לנטר את השימוש בו, זה לראות שהוא לא מתריע, ואם הוא כן מתריע זה לתקן אותו. זה בעצם חיבור מלא, זה הפיצ'ר שלך, ואתה אחראי עליו מההתחלה ועד הסוף. זה משהו שאנחנו מאוד מאמינים בו.

ליאור:            כן, אבל ה-dev on call לא מתחלק לפי פיצ'רים, נכון?

אביתר:           נכון.

ליאור:            אז איך זה עובד בפועל?

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

ליאור:            כמה אנשים כלולים בסבב הזה? מספר אבסולוטי. כדי להבין שנייה, להיות מסוגלים לדמיין את זה.

[10:00]

אביתר:           כרגע אנחנו בסבב של בערך 20 אנשים. יוצא לבן אדם פעם בשלושה שבועות.

ליאור:            כלומר 20 איש צריכים תמיד לדעת להיות מסוגלים לטפל במערכת באותה מידה?

אביתר:           לא [צוחק].

ליאור:            אוקיי.

אביתר:           יש איזשהו ידע בסיסי שאנחנו מצפים שיהיה לכל האנשים ב-R&D. כי-

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

אביתר:           לא, אנחנו בכללי, זה אולי פודקאסט אחר, אבל אנחנו בכללי תמיד נעדיף להביא בן אדם מוכשר לעומת בן אדם עם ניסיון. אנחנו מחפשים את הכישרון. אז גם אם אתה לא בא עם הידע הזה אתה יכול, אפשר להגיע לפה, אנחנו רוצים את האנשים האלה. ואנחנו דואגים להכשרה הזאת. אז מה זה בעצם ההכשרה הזאת? קודם-כל, יש לנו knowledge base מסודר, כלומר, כמה דברים שצריך לקרוא, שצריך להכיר, שצריך לעבור עליהם, שזה דברים שאנחנו מצפים שכל אחד ידע לעשות. זה בעצם בטכנולוגיות הבסיסיות שלנו, זה כאילו ה-pro technologies שלנו, שכולם משתמשים בזה, יש לנו כל-מיני אפליקציות, כל-מיני micro services, שירותים קטנים שעושים דברים ספציפיים, אבל הם כתובים בטכנולוגיות דומות. אז יש בעיות שהן מאוד דומות על כל המערכת, למרות שהיא גדולה. וזה אנחנו מצפים שכל אחד ידע להתמודד. מצד שני יש דברים שהם מאוד מאוד ספציפיים ודורשים התמחות. שזה בעיות ממש ב-database, או בעיות שהן מאוד business logic ספציפי של איזושהי אפליקציה, שאז מה שה-dev on call אמור לעשות זה להעיר או לקרוא לבן אדם שמכיר את הדברים האלה. עוד משהו שחשוב להגיד דרך אגב זה שאם מישהו מתעורר באמצע הלילה והמערכת למטה, הדבר הראשון שהוא צריך לעשות זה להעיר את כולם. כאילו, אין דבר כזה שהמערכת למטה ואנחנו כאילו ישנים, רגועים וזה. המערכת למטה לא תמיד מתבטא בהתרעה. יש התרעות שהן יש פה איזושהי בעיה, צריך לבדוק, אפשר לפתור. אבל יש כל-מיני דברים-

ליאור:            מה זאת אומרת, המערכת יכולה להיות למטה מבלי שתהיה התרעה?

אביתר:           לא. המערכת למטה תהיה התרעה, הבן אדם האחראי מקבל אותה. ה-dev on call.

ליאור:            אבל לא בהכרח כל התרעה היא מערכת למטה.

אביתר:           יש לנו איזשהו מנגנון של אסקלציה. יש לנו dev on call שזה הסבב הראשון שדיברנו עליו, ואם עושים לזה אסקלציה אז זה בערך לעשרה אנשים, שזה כבר הרבה מהחברה בוא נקרא לזה ככה, ואז כבר מעירים את כולם. או אם זה קורה גם במהלך היום מוציאים את כולם מישיבות או ממה שהם לא עושים ומטפלים בבעיה. אחרי העשרה אנשים האלה זה מגיע לזינמן. [צוחק]. בתור level 3.

ליאור:            רגע, אז ה-level הראשון זה dev on call, ה-level השני זה עשרה אנשים שהוא מעיר, וה-level השלישי זה שאר האנשים? מה זאת אומרת level שלישי?

אביתר:           לא, level שלישי זה רק זינמן.

ליאור:            [צוחקת] הבנתי.

אביתר:           לא, באמת. זה מקונפג, level בשביל עצמו. לא, עשרה אנשים זה כבר כל החברה, זה כבר כאילו התקשרו לכולם, נפעיל כבר את כל הכוח של ה-R&D בשביל לפתור את הבעיה. [מוזיקה].

ליאור:            זינמן, איך זה היה פעם?

ערן:               כמה פעם את רוצה ללכת?

ליאור:            כמה שבא לך. [צוחקת]. יש לנו את כל הזמן שאתה צריך.

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

ליאור:            וואו, זה רק לפני ארבע שנים כל הסיפור הזה.

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

ליאור:            הנה בדיחה: מה יותר גרוע מלהיות הורה טרי? להיות הורה טרי ו-dev on call. [צוחקת].

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

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

[15:00]

ערן:               כן, זה לא טובים, זה מנוסים. כאילו, התנסו בבעיות ב-production. ואני זוכר שממש עשינו איזשהו transition. היה פה את דניאל והיה פה, דניאל בדיוק הגיע, וטל. והאמת שיש לי עוד איזו אנקדוטה לספר, שהיא הייתה כזאת טרנספורמטיבית מבחינתי. שאני קם יום אחד בבוקר, שש וחצי-שבע בבוקר, אני פותח את הטלפון, אני רואה 150 הודעות וואטסאפ ו-8 שיחות שלא נענו. מחשבה ראשונה – מי מת? כאילו, זה ה-

ליאור:            זה לפני עידן ה-pager duty.

ערן:               לא, עם ה-pager duty. היה לנו כבר מערכת התרעה, אני לא זוכר אם זה היה pager duty או משהו אחר. פשוט שמתי את הטלפון על שקט, לא עשיתי את ההחרגה שאם זה טלפון מ-pager duty או משהו כזה שיעבור את השקט. בטעות, אני בדרך-כלל לא שם בלילה את הטלפון על שקט. אני אוהב לשמור איזשהו מפלס של חרדה בשינה, אז… אבל שמתי את זה על שקט. ואז אני רואה התכתבות של טל עם דניאל, והמערכת למטה, וזינן לא עונה, ואני כאילו תופס את הראש, שיואו, כאילו… ואז כאילו אני מסתכל, אני עובר בהודעות, ואני רואה שהם פתרו את הבעיה, והכול בסדר, והם הסתדרו, והם חיפשו אותי בלילה אבל הכול היה בסדר, והם הרימו את המערכת והכול סבבה [צוחקת].

ליאור:            היית צריך אירוע אחד כזה כדי לשחרר אתה אומר.

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

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

אביתר:           אז כן, זה בעצם התפקיד הכי חשוב של ה-dev on call, הדברים שהוא יכול לטפל בהם בעצמו. זה החלק הכי מעניין. ואנחנו תמיד מצפים את זה מכל בן אדם. בשביל לעשות את זה, אז כמו שאמרתי, יש לנו איזשהו Knowledge base, עם כל-מיני הרצאות שהכנו ומסמכים שהכנו והסברים שהכנו-

ליאור:            אז מה הציפיה, שאני אקום, תהיה התרעה, אני dev on call, יש התרעה, אני קמה באמצע הלילה ופותחת את ה-knowledge base?

אביתר:           מדי פעם לטפל בבעיות סופר-ספציפיות, אבל הרעיון זה שלפני שאת נעשית dev on call פעם ראשונה את עוברת על ה-knowledge base הזה. כל השאלות שיש לך את שואלת את הצוות לפני. יש לנו גם-

ליאור:            זה באחריות של כל מפתח לעשות את זה?

אביתר:           כן, זה חלק מה-onboarding. ברמת החודש-חודשיים הראשונים. יש לנו גם נוהל לעשות dev on call shadow, שזה בעצם אומר שאתה לא ה-dev on call, אבל כל מה שקורה במהלך היום אתה עובד עם ה-dev on call. אז אם יש התרעות אתה שם איתו. אתה מסתכל, אתה לומד ככה.

ליאור:            זה לטובת מפתחים חדשים.

אביתר:           כן. שזה חלק מההכשרה של מפתחים חדשים לפני שהם נעשים dev on call. וכשיש בעיות במהלך היום אז אתה מטפל בהן, בעיות בלילה, בעיות בלילה דבר ראשון לבדוק מה שלום המערכת. אם המערכת למטה אז זה להעיר את כולם, כי… זה בדיוק זה, אנחנו לא נשלם ב, אנחנו לא נגרום ליוזרים שלנו לשלם על זה שאנחנו רוצים להכשיר אנשים. אם המערכת למטה, דבר ראשון שעושים מתקנים אותה. זה ברור. אבל אם לא, אם רואים שיש איזושהי התרעה, מסתכלים, הכול נראה בסדר, שם אפשר קצת להתעמק יותר, לא חייבים לעשות אסקלציה מיידית. אפשר לבדוק את הדברים, אפשר לנסות לתקן לבד. אם יש חששות ואם יש חשדות תמיד מעדיפים את האסקלציה מאשר לעשות בעיות ב-production – כל הדברים האלה הם מאוד רגישים.

ליאור:            בוא נדבר על זה שנייה, סבבה? אני מדמיינת את עצמי עוד פעם, קמה בלילה, וזה לא בגלל נעמי, זה בגלל ההתרעה שקיבלתי, ויש לי שתי אפשרויות… ואני מבינה שהמערכת למעלה וזה בסדר וזה לא עכשיו פוגע בלקוחות וביוזרים שלנו. ויש לי שתי אפשרויות, או להעמיק כמו שתיארת ולפתוח knowledge bases וקצת לחקור, או לעשות איזשהו עכשיו משהו קטן, או לסמן איזה note ומחר בבוקר שיתמודד עם זה ה-dev on call, אני מבינה שמחר אני כבר לא dev on call, נכון?

אביתר:           כן, dev on call זה יום אחד אצלנו.

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

אביתר:           קודם-כל, מה שאמרת הוא לא משהו רע. כלומר, אני לא מצפה שבן אדם… אנחנו לא מצפים שבן אדם יהיה ער בלילה סתם. אם המערכת למעלה, אם הכול בסדר ויש לנו התרעות, זה כבר בעיה אצלנו ברמת ה-R&D, זה בעיה שקורית.

ערן:               אגב, אני חייב להגיד כ-sign out, כי אני חושב שאנחנו מדברים על הנושא הזה. אז זה משתמע שכאילו כולם קמים פה בלילות. זה קורה לעתים מאוד רחוקות, בסדר? זה…

[20:00]

ליאור:            כן, זו נקודה טובה. כמה פעמים בשבוע קמים בלילה?

אביתר:           אנחנו מנתחים את הדברים האלה, זה משתנה לנו פר רבעון. זה בדיוק מה שדיברנו על סביבה משתנה והתרעות משתנות. רוב ההתרעות קורות ביום. כלומר, בערך 67 אחוז מההתרעות קורות ביום, משהו כזה. ו-20 אחוז מהלילות מתעוררים פה. בגדול זה קורה לילה מתוך חמישה, למרות שיש לילות שכאילו יש הרבה התרעות.

ליאור:            אז לילה לחמישה מישהו קם, ובגלל שיש סבב בסוף של 20 איש אז יוצא ש-

ערן:               כן, אחד למאה לילות. וזה גם משתנה, ככל שאנחנו מגדילים את ה-R&D, אז זה אומר שיצא לבן אדם אולי פעמיים בשנה-

ליאור:            להתעורר בלילה.

ערן:               בסיטואציה כזאת, כן.

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

ערן:               איטרציה.

ליאור:            אני כרגע באיטרציה [צוחקים]. ואיך אני מדמה את ה-

ערן:               את צוחקת עלינו ליאור?

ליאור:            ואני dev on call. ויש לי שתי אפשרויות. עוד פעם, להעמיק בבעיה או לשים עליה פלסטר – מה שלא תהיה המשמעות של פלסטר ב-R&D.

אביתר:           זה גם יותר מזה דרך אגב, כי לפני שנה היו לנו הרבה יותר התרעות. וזה גם אפשר לדבר אחרי זה על התהליך שעשינו, אבל-

ליאור:            אז בוא, בוא נדבר על זה עכשיו.

אביתר:           אוקיי. היו לנו הרבה יותר התרעות לפני שנה. היו לנו הרבה התרעות בלילה. בערך לפני שנה, כן? זה הסדר גודל. היו לנו הרבה יותר התרעות בלילה. לרוב מישהו היה מתעורר. מצד שני, המערכת production הייתה למעלה. כלומר, הכול עבד, היוזרים בסדר, ויש התרעות. מתעוררים בליה, עושים איזה משהו, שמים איזשהו פלסטר, חוזרים לישון. וזה כאילו מין הופך לנוהלך. עכשיו, הסיבה שזה היה בסדר לאנשים אני חושב היא דווקא באה ממקום קצת מפתיע. לאנשים פה יש המון מוטיבציה. הם רוצים להיות טובים, הם רוצים לעזור, הם רוצים לתרום. אז מה שקורה, הם מתעוררים בלילה, אומרים טוב, זה התפקיד שלי, זה מה שאני אמור לעשות, אני אתקן את זה. עכשיו, אז הם מתקנים וחוזרים לישון, וזה בעצם הופך לנוהל. הנוהל זה כשאתה dev on call ואז הסבב שלנו היה בערך שמונה ימים. אז פעם בשמונה ימים היית מתעורר בלילה. יכול להיות גם כמה פעמים, זה לא רק, פעם אחת בלילה זה עוד סביר אולי. זה יכול לקרות שלוש-ארבע פעמים בלילה פתאום. מצד שני המערכת למעלה, הכול בסדר, אבל אנחנו מתרוצצים סביב עצמנו. אז זה בא ממקום ממש טוב. כי לדעתי לאנשים פה יש מוטיבציה אדירה והם מנסים לעזור ולפתור את זה כמה שיותר. אבל מדי פעם מה שחשוב לעשות זה להרים את הראש וקצת לעבוד יותר חכם, לא יותר קשה. התרעות שלא מעידות על זה שהמערכת למטה אפשר  להעיף או לפתור אוטומטית. כלומר אנחנו מתכנתים, כן? אנחנו תמיד מעדיפים אוטומציה על עבודה ידנית. הרבה מההתרעות האלה שהיו לנו פשוט היה אפשר לפתור אותן מהשורש. עכשיו, אז אני לא מצפה שמישהו יעשה את זה באמצע הלילה. התעוררת באמצע הלילה, תתקן כמה שיותר מהר, תעשה אסקלציה אם צריך, ותחזור לישון. עכשיו אתה בא למחרת לחברה, מה אתה עושה? עכשיו אני, מה שאנחנו רוצים ברמת ה-R&D, איך שאנחנו נשתפר בתור חברה, זה אם נפתור את הדברים האלה מהיסוד. כי אם יש התרעה שמעירה אנשים בלילה, או שצריך לפתור אותה – כי היא גם משפיעה על לקוחות – או שהיא התרעת שווא, false positive כמו שאנחנו קוראים להן, וצריך להעיף אותה. זה לא תמיד פשוט, זה לא כאילו אתה בא ובעשר דקות פותר את הבעיה. השאלה היא כמה משקיעים בזה.

ליאור:            יש לך דוגמה?

אביתר:           כן. הייתה לנו… זו דווקא דוגמה לא טובה לנו. הייתה לנו התרעה, היינו ב, הסביבה הקודמת שלנו הייתה ב … [00:23:30], זו איזושהי חברה מעל אמזון, ששם היו השרתים. והיו שם קשיים טכניים בזה שמדי פעם כמות הזיכרון במכונה התמלאה. כלומר, הזיכרון התחיל להיגמר. וקיבלנו על זה התרעה. עכשיו, זאת התרעה, מצד אחד היא עוד לא משפיעה על לקוחות, כי השרת עובד. מצד שני אם נתעלם ממנה ייגמר הזיכרון בשרת, השרת ייפול, ואנשים יקבלו errors. אז חייבים לפתור אותה. אז אנשים היו קמים בלילה, מריצים איזשהו script, מה שדיברנו שהכנו ב-knowledge base, פותרים את זה, חוזרים לישון. וזה היה מתריע עוד פעם, פותרים, חוזרים לישון. והסביבה גדולה, וכמות המכונות גדלה, ובגלל… זו באמת הייתה בעיה שכאילו מכל-מיני סיבות טכניות היה קצת קשה לפתור. זה דברים שכן אפשר לעשות אוטומטית, שימחקו את הקבצים. אבל צריך לחשוב איזה קבצים אפשר למחוק, איזה קבצים אי אפשר למחוק, באמת היה פה קושי טכני.

ליאור:            כדי לפנות מקום אתה מתכוון. בזיכרון.

אביתר:           כן. היה פה קושי טכני אמיתי לפתור את הבעיה. והייתה לנו איזושהי אדישות כלפיה. כלומר, אמרנו "טוב, אני לא מצליח לפתור את זה ביום", זה גם אני אישית אמרתי. אני לא מצליח לפתור את זה ביום, אז בסדר, זה יתריע ונתקן ומתישהו, כאילו, כשנעבור מ … [00:24:38] – שעשינו דרך אגב – זה יפתור את הבעיה. ואז היא נעלמה. אבל זה משדר כמה דברים שאנחנו ממש לא מאמינים בהם לדעתי. כאילו-

ליאור:            מה הם?

[25:00]

אביתר:           קודם-כל שהזמן של האנשים שלנו חשוב. כשאנחנו מתכננים איטרציה, כשאנחנו מחליטים מה לעשות, אנחנו נלחמים על כל שעה של בן אדם. כלומר, יש לנו כל-כך הרבה דברים לעשות והם כל-כך חשובים, שכל דבר אנחנו מתכננים וחושבים עליו. ועכשיו פתאום אנחנו מבזבזים שעות, אנחנו שוחקים אנשים, על סתם. אנחנו יכולים לפתור את זה, זה ייקח יום, זה ייקח שבוע. אבל זה פוגע בנו בתור R&D וזה גם איזשהו זלזול בזמן של אנשים. זה כאילו, זה אצלנו ב-R&D ואנחנו צריכים לתקן את הדברים האלה, זה לא אצל אף אחד אחר. [מוזיקה].

ערן:               אני רוצה להוסיף משהו על התרעות, כי זה נושא מאוד מעניין. אז אביתר הסביר על כמה סוגי התרעות. אז בואו שנייה נסתכל על זה בהסתכלות יותר רחבה. יש כאילו את ההתרעות הברורות מאליהן, שהמערכת למטה. אם אתה מקבל דבר כזה באמצע הלילה ברור שכולם צריכים להתגייס ולהרים את המערכת, זה אומר שיש משהו שפוגע בחברה. ויש את ההתרעות שהן אמיתיות, שאומרות "משהו לא טוב קורה", זה הולך לקראת מקום של המערכת הולכת להיות למטה – וזה גם אני חושב צריך להתמודד עם זה, וזה חשוב, וצריך לנסות להגיע למקומות שיתקנו את זה בעתיד. יש את ההתרעות שהן באמת false positive. שאנחנו צריכים לצמצם אותן כמה שיותר, לראות שהן לא אמיתיות ולהבין מה הם המקרים. אבל אני רוצה לאתגר אותנו עם עוד סוג של התרעות שיש לנו היום בחברה. בעצם יש בעיות שקורות במערכת שאין לנו התרעות. אוקיי? דברים לא טובים שקורים שאין עליהם התרעות. אפילו נגיד יותר מזה, יש דברים שהשרתים לא מספרים לנו. כי יכול להיות שהעלינו איזשהו פיצ'ר ממש לפני שאחד המפתחים הלך הביתה, והוא בניו יורק, נהיה אמצע הלילה, ופתאום לקוחות מקבלים כל-מיני בעיות. זאת אומרת נעלם להם נגיד מידע מהבורד. משהו שהוא אקוטי. והצוות של ה-Customer Success מתחיל לקבל פניות. בסדר? הלקוחות מתקשרים, זועמים, המידע שלהם לא נשמר. עכשיו שלוש לפנות בוקר בישראל. אחד הדברים שהוספנו בעצם ל-big brain, במסגרת העבודה, זה כפתור ל-Customer Success להפעיל נוהל מפתח כונן. זאת אומרת יש להם כפתור ב-big brain לייצר התרעה ב-pager duty למפתח כונן. ומה שזה אומר, שעכשיו כאילו אחד אנשי ה-Customer Success זיהה בעיה, הוא חושב שיש פה pattern, כן? שהוא רואה את זה עם הרבה לקוחות, והוא מעיר את המפתח. עכשיו, תחשבי איזו סיטואציה קשה זאת להיות, כאילו איש Customer Success-

ליאור:            לגמרי, אני מדמיינת את זה.

ערן:               שעכשיו אתה רועד על הכפתור הזה, שעכשיו שלוש לפנות בוקר בישראל, אתה הולך להעיר מישהו. ויכול להיות שהוא יגיד לך-

ליאור:            זה שטויות, למה הערת אותי, כן.

ערן:               למה אתה מעיר אותי? למה אתה מעיר אותי? כאילו, או, מצד שני-

ליאור:            או ההיפך אגב

ערן:               להציל את היום, כן. וזה, אני חושב שזה-

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

ערן:               נכון, נכון. אבל כאילו מה אתה עושה?

ליאור:            והוא מבחינתו בעצם ב-ownership מלא, כי הוא קיבל עכשיו איזושהי הודעה והוא לא יודע אם היא קריטית או לא. איך אתה מוודא שה-Customer Success יש לו מספיק מידע ומספיק ידע כדי להבין מתי זה עלול להיות אקוטי ומתי אפשר לחכות עם זה למחר בבוקר?

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

אביתר:           אני חושב שהדבר שהכי חשוב שאנחנו עושים בתור חברה זה ללמוד ממקרים. כלומר, מגיעים בבוקר, היה צריך להעיר את הבן אדם או לא? מדי פעם זה גם הפוך. היו לנו כמה תקלות שאמרנו היו צריכים להעיר, ודיברנו עם ה-Customer Success למה לא הערתם אותנו, היה לנו באג חמור, והוא נמשך כאילו כל הלילה סתם. וממש פגע בלקוחות שלנו. זה גם, זה להעיר ברמת אסקלציה, גם על באגים שהם מוצהרים יש אסקלציה אם זה באג חמור. אז בקטע הזה זה, יש לנו איזשהו נוהל שה-head of operation, זה אוריאל, עשה. על מה עושים אסקלציה ומתי. זה לדעתי נוהל ממש טוב, שמתאר כל-מיני סוגים. שיש גם דברים שיכולים להיות לגאליים או security, ומה האסקלציה שם. ותמיד תמיד עדיין נשארים אזורים אפורים. והדרך הכי טובה זה פשוט ללמוד מהמקרים שקורים. אם היה צריך, אם לא היה צריך, ולפעם הבאה נשתפר. שזה לדעתי הדבר הכי ברור וטוב שאנחנו יכולים לעשות על הדברים האלה.

ערן:               אבל אני אוסיף על זה עוד משהו שלדעתי הוא אקוטי בתוך הדבר הזה. אני חושב שה-Customer Success כאילו מאוד איכפת להם לא להעיר סתם, אבל אף פעם ה-R&D לא באים אליהם בטענות. זאת אומרת, לא מייצרים כזאתי אווירה של האשמות, למה הערתם אותנו, ואתם over מייצרים את זה. זה משהו ב-culture שמאוד חשוב לשמר, כי מאוד קל לייצר סיטואציה שבה מפחידים את הצד השני לא לייצר את הדברים האלה.

אביתר:           נכון.

ערן:               זה משהו שאני ממש-

ליאור:            ה"שלך-שלי" הזה שתיארת קודם.

ערן:               לגמרי.

ליאור:            אז פתאום הוא לא ב-QA כי אין כאן את הפונקציה הזאת, אבל זה כן בין ה-Customer Success לבין ה-R&D.

ערן:               נכון.

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

[30:00]

ערן:               כן. אגב, אני אוסיף עוד משהו פה. שצריך להבין שלפעמים אסקלציות הן חוצות פיתוח. לדוגמה, חס וחלילה, מותר לדפוק על העץ פה ב…? [צוחק]

ליאור:            לא לדפוק על העץ, לא לדפוק על העץ.

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

ליאור:            או ל-dev on call.

ערן:               כן.

ליאור:            ובכל זאת אני שנייה חוזרת ל-dev on call. תיארת שבשלב של ה-onboarding בעצם אנשים כן יש להם איזושהי אחריות ללמוד ולהביא את עצמם למסוגלות מסוימת. אבל איך משמרים את זה לאורך זמן? יכול להיות שבן אדם עובד בחברה כבר שנתיים, לא פגש את ה-knowledge base הזה כל השנתיים האלה.

אביתר:           אחד הדברים שעשינו זה בעצם training day לכל מי שהוא dev on call. כל מי שהוא ה-dev on call בהגדרה הזאת עשינו לו איזשהו training day, שמה שזה אומר, מיפינו בעצם את ה… שם בעצם קצת פירמלנו מה התפקיד ומה אנחנו מצפים שכל אחד ידע לעשות. כל-מיני אנשים ב-R&D קיבלו כל-מיני נושאים והעבירו הרצאות לכל ה-R&D. אז היה לנו בערך שש שעות של הרצאות. החלק היותר מעניין של היום, בעצם לקראת אחר הצהריים, עשינו תחרות. יש לנו סביבת בדיקות, קוראים לה staging. ולשם העלינו כל-מיני באגים מתוכננים בכל-מיני רמות של אסקלציה. איזשהו באג אפליקטיבי. עשינו את הבאג הכי… אחד הבאג הכי חמורים, שהפלנו את ה-databases, כל המערכת למטה. ובעצם עשינו תחרות מי מתקן הכי מהר. היה לנו איזה חמישה-שישה תרגילים. וזה ממש מחבר אנשים. כי עכשיו הם בעצם שמעו על כל הכלים שהם יכולים להשתמש בהם, ועכשיו הם יכולים ממש לדמות את זה. על מערכת הבדיקות שלנו, בלי שום פגיעה בלקוחות כמובן. ועשינו מזה תחרות. דרך אגב גיא ואביגיל זכו בתחרות, זכו ב-chrome cast כל אחד. וזה מאוד חיבר אנשים ויישר איזשהו קו, וזה גם יצר לנו, הקלטנו את כל ההרצאות האלה, זה עיבה לנו את ה-knowledge base. אנחנו עושים עוד יום כזה דרך אגב עוד שלושה שבועות.

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

ערן:               בשביל זה הזמנו אותך, לקדם את האירוע.

ליאור:            כן, זה פתוח לקהל הרחב? [צוחקים]. כל החברה תבוא פתאום ל-training day ולא תבין למה הם הגיעו [צוחקת].

אביתר:           צריך להוציא את הפודקאסט בזמן.

ליאור:            צריך להוציא את הפודקאסט בזמן, כן. [מוזיקה].

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

אביתר:           זה גם אני כבר לא יכול להגיד בדיוק איך זה מרגיש, אבל זה כן מרגיש שחבר'ה חדשים שהולכים ל-dev on call פעם ראשונה לחוצים מזה. אני לא חושב שזה משהנו שבאמת אפשר לנטרל. כאילו, הלילה הראשון מלחיץ. בייחוד אם זה מישהו עם פחות ניסיון, לא תחזק מערכות production, לא היה dev on call במקום אחר. אבל אנחנו, בקטע הזה אנחנו מביאים הרבה גב. כלומר, זה כבר לא המצב שהחברה הייתה לפני ארבע שנים שזה היה רק אתה ואתה צריך להרים את הכול ואין לך למי לעשות אסקלציה. כלומר תמיד ברור לך, כאילו, אנחנו תמיד מבהירים שאם יש בעיות אז ישר לעשות אסקלציה, לא להתבייש להתקשר, גם בטלפון, אם לא רוצים לעשות אסקלציה, ישר אליי או לראש הצוות. אם יש איזושהי בעיה. יש איזו חניכה. כלומר, אני חושב שמצד אחד זה מלחיץ, אבל מצד שני אתה לא מרגיש לבד. אתה לא מרגיש שאתה מבודד ושזו רק בעיה שלך. שזה גם, הדבר האחרון שאנחנו רוצים שיקרה שהמערכת למטה ומישהו מתבייש להתקשר. זה הכי גרוע מבחינתנו, הוא בעצם מסתיר את הבעיה. אז כן, זה-

ליאור:            כן, אבל שוב, זה יכול לקרות דווקא ממקום טוב. אני יכולה לדמיין שבן אדם לא מתקשר כי הוא רוצה להראות שהוא שולט בסיטואציה. אז איך אתה מנטרל את זה?

אביתר:           זה שיקול דעת בסוף. בסוף אם אתה מחובר למוצר, אם אתה מחובר ליוזרים, אתה מבין שאתה עובד על מערכת production.

ליאור:            It's not about me כאילו, אתה אומר.

[35:00]

אביתר:           בדיוק. זה יהיה לך ברור. זה, מרגישים את זה. ואנחנו, זה גם התרבות פה ב-R&D. כאילו, כולם מרגישים את זה, אנחנו, יש לנו נוהל ב-onboarding, מדברים על זה עם כל בן אדם. ועדיין, בסוף שיקול דעת של אנשים זה הדבר הכי חשוב שיש לנו. כי כל נוהל יש בו פינות אפורות שיתפספסו.

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

ליאור:            תיארת קודם שיש איזשהן מדידות שעושים על ה-dev on call, נכון? שדור ממש לקח נתונים אחורה ועשה איזשהם ניתוחים. באמת זה מעלה איזושהי שאלה על איך אפשר לבדוק ולוודא שאנחנו משתפרים בדבר הזה. נכון? אמרת שלפני שנה היו יותר התרעות, היום יש פחות התרעות. יש מדדים, יש KPIs כמו בכל דבר אצלנו במאנדיי?

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

ערן:               גם מודדים את זה באחוזים. זאת אומרת אומרים נגיד בתוך חודש היינו uptime 99.99 אחוז. זה נגיד ratio שאנחנו מוכנים לעמוד בו.

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

ליאור:            כן, הציפייה שלא יהיו התרעות היא לא בהכרח מעידה על השתפרות.

אביתר:           נכון. מצד שני אנחנו כן מזהים שהתרעות שחוזרות על עצמן כל הזמן זה התרעות שאנחנו צריכים לעקור מהשורש. או שהן פוגעות בלקוחות, הן בוודאות פוגעות בנו בתור R&D. אז זה משהו שצריך ללכת לאפס. כל ההתרעות החוזרות צריכות להיעלם. ככל שעובר הזמן. והדבר האחרון, שהוא קצת יותר קשה למדוד, זה בעצם… אבל זה בעצם בתרבות שלנו ב-R&D, שכמה שיותר אנשים בעצם חושבים על ה-infra, חושבים על השרתים, מעורבים בדברים האלה. מה שדיברנו בהתחלה, שהידע לא מרוכז אצל כמה אנשים ספציפית, הוא אצל כל ה-R&D. שזה קצת יותר קשה להגיד איך מודדים-

ליאור:            יכול להיות שאפשר, אה?

אביתר:           בטוח אפשר, רק צריך לחשוב על זה.

ליאור:            אתה מתחייב פה ב-on the record, אז…

אביתר:           בטוח אפשר, צריך לחשוב על איך.

ליאור:            אביתר, אם מישהו מאזין לפרק הזה והוא בעצמו עכשיו צריך לנהל סבב on call בחברה שלו, מה היית מייעץ לו בתור התחלה?

אביתר:           בתור התחלה הייתי אומר שזה תלוי. זה תלוי בגודל של החברה, בכמות האנשים שיש. בכמה המוצר יציב או לא. זה תלוי באלף דברים, ושיתאים את זה למה שהוא צריך. אני כן הייתי מייעץ להיזהר מלרכז את הידע רק אצל כמה אנשים, ולהשתמש בזה בתור הזדמנות, בשביל לשפר את ה-R&D ובשביל לחבר את כולם לחלק מהותי מהמוצר.

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

ליאור:            אביתר, תודה שהצטרפת אלינו היום.

אביתר:           תודה שאירחתם אותי.

ליאור:            תודה ערן.

ערן:               תודה ליאור.

ליאור:            תודה שהאזנתם. [מוזיקה].