437 Refactoring (and Observability) with Omer van Kloeten

 
שתפו
 

Manage episode 323475444 series 2497397
על ידי רברס עם פלטפורמה התגלה על ידי Player FM והקהילה שלנו - זכויות היוצרים שמורות למפרסם, לא ל-Player FM, והשמע מוזרם ישירות מהשרתים שלכם. הירשמו כדי לעקוב אחר עדכונים ב-Player FM, או הדביקו את כתובת העדכונים באפליקציות פודקאסט אחרות.
בפרק זה אנחנו מארחים למחרת יום הפאי את עומר ון קלוטן לשיחה על Refactoring ו-Observability .


(רן) ולפני - בוא נכיר אותך, עומר - ספר לנו קצת על עצמך
  • (עומר) אז אני עומר, כיום עובד ב-Forter, משהו כמו 21 שנים בתעשייה.
    • בהתחלה בצבא - ואז ערימה של של סטארטאפים בכל מיני שלבים, מגוון של תפקידים, גם בחברות גדולות . . .
    • תפקידי פיתוח, הובלת פיתוח, ניהול בכמה פעמים
    • במקרה גם כמה פעמים Product, לא בכוונה . . . . אבל היה מצויין וכיף.
  • אני מחשיב את עצמי כ”ג’ינרליסט” - מאוד נהנה מהכל, כי הכל מסקרן והכל כיף, אז למה לא?
(רן) הזכרת שהיית פעם Product - אז אני לא יודע אם יצא לך לראות, אבל רץ ברשת סוג של סרטון שבו רואים את איש ה-Product, כשיש לו איזשהו סיוט או מחשבה על “רק שהמפתחים לא יעשו Refactoring” . . . . זה הסיוט של כל איש מוצר, כשהמפתח אומר “רגע-רגע-רגע - אני צריך לעשות Refactoring!” . . . .אז על זה באנו לדבר היום.
  • (עומר) כן, באנו לדבר היום על הפוסט-טראומה של אנשי ה-Product וה-Refactoring . . . .

(רן) אז מפתח מדופלם, בוא נתחיל בזה - קם בבוקר, מסתכל על הקוד ואומר “משהו פה לא נראה לי . . . . משהו פה מסריח - אני חייב לעשות לו Refactoring” . . . .
  • (עומר) כן, כולנו היינו בסיטואציה הזאת, וזה פשוט “נראה נכון” - יש את ההרגשה הזאת בבטן, יש את הקטע של “אני חייב לשנות את זה - כי זה לא *נכון*” . . .
(רן) הכימוס אינו נכון” . . . . (Encapsulation)
  • (עומר) וואו, כמה זמן עבר מאז ששמעתי את זה בעברית . . .
(רן) חיכיתי עד שאוכל לשלוף את המילה הזאת . . . .
  • (עומר) אז אני חושב שאתה צודק - אנשי ה-Product, אנשים שהיו מספיק זמן ב-Product, נמצאים באיזושהי פוסט-טראומה כזאת, של “רק שאנשי הפיתוח לא יבואו ויגידו לי “אני חייב לעשות Refactoring בקוד” . . . .
  • כי בתכל’ס - מה הם מקבלים מזה? הם מקבלים יותר Delays בזמן של המוצר . . . .

(רן) אז בוא נלך רגע ונעשה איזשהו מסע בזמן . . . . צריך להגיד, קודם כל, שאנחנו מדברים כאן בשיחה הזאת בעקבות איזשהו בלוג-פוסט שכתבת, ונשים אליו לינק [הנה], ששם אתה שוטח את התיאוריה - הקצרה, אני חייב להגיד, אבל עניינית.
בוא לרגע ניזכר באיך היה כשהיינו מפתחים צעירים - הסתכלנו על קוד ואמרנו “רגע, זה עובד - אל תיגע בו!” . . . אל תיגע בכלום, זה עובד! ועכשיו מתחילים . . .
  • (עומר) אז אנחנו מתחילים מהנקודה של “גרמתי לדבר לקרות” - שזה נהדר
    • אוקיי - יש את הטקסט שמופיע על המסך וזה עובד.
    • זה ממורכז בצורה הנכונה ובצבע הנכון - לא נוגעים!
    • יש איזשהם תנאים - צריך לשים את זה במקום מאוד מסויים, בחדר מוגן מרוחות וזה - שלא יזוז יותר מדי המחשב, אחרת זה לא יעבוד יותר.
  • אבל אחרי זה, ככל שאנחנו יותר, עם הזמן, עסוקים עם קוד ורואים Code-bases שונים, אנחנו מתחילים לפתח יותר תחושה לגבי מה זה “קוד טוב” או יותר נכון - מה נראה כמו קוד שאנחנו מכירים אותו ומרגישים איתו בנוח
    • יש את ה-Pattern-ים שם, שאנחנו מרגישים איתם בנוח
    • שמענו ממישהו שעבדנו איתו שאם כותבים משהו פעמיים, אז צריך להוציא את זה לפונקציה משותפת וזה נשמע לנו ממש הגיוני לא לכתוב את אותו הדבר פעמיים, כי אז יש לנו פעמיים את אותם באגים . . .
      • אוקיי, אז נעשה את זה . . . .
  • ואז אנחנו יותר ויותר מפתחים את האינסטינקטים האלה של מה שנראה לי “קוד טוב”.
  • ואז[!] הגעתי לנקודה ש”אוקיי, הקוד הזה הוא כבר זוועה . . . .” - הוספנו עוד פיצ’רים ועוד פיצ’רים ועוד פיצ’רים, ואני חייב עכשיו לעצור הכל, לשמוט את הכל מהידיים ולהגיד לאנשי ה-Product “עכשיו חייבים לעשות Refactoring!”.

(רן) אז בוא שנייה נעשה פסיכואנליזה של הסיפור הזה, ברשותך . . . בעצם פיתחנו פה איזשהו Skill טכני, נכון? פיתחנו Skill טכני של להסתכל על הקוד ולהגיד מה אפשר לתקן בו או מה לא טוב בו - ואנחנו יודעים לעשות גם את זה: הזכרת Design Patterns והזכרת . . . . לא הזכרת כימוס אבל אני הזכרתי . . . . הזכרת Usability והזכרת מודולריות וכל זה - יש לנו את היכולת הטכנית לעשות את זה.
עכשיו - כל דבר נראה לנו כמו מסמר . . . יש לנו פטיש ביד, וכל דבר נראית לנו כמו מסמר . . . רק רציתי להציג את הבעיה.
(אורי) אני חושב שחוץ מכלי - יש לנו כלי נוסף ביד, או Skill טכני - יש גם תחושות, זה הרי הכל מתחיל מתחושה. פעם קראתי איזשהו Post על איך מודדים Tech-Debt - סובייקטיבי לגמרי . . . .
(רן) מדד ה-WTF-per-Minute, כמובן . . . .
(אורי) כן, פשוט שאל את המפתח מה הוא חושב על הקוד שלו . . . Over-time, זה כנראה יגיע לרמות שבהן אתה תגיד לו, או שהוא יגיד בעצמו, שהוא צריך לטפל ב-Tech-Debt הזה . . .
  • (עומר) אז אני חושב שמילה שמאוד מגלמת את זה היא בעצם “חוש אסטטי” . . . .
    • מבחינת המפתח, האסטטיקה היא הרבה פעמים מאוד סובייקטיבית, ואתה אומר “לי זה לא נראה נכון”
      • ומישהו אחר היה יכול להסתכל על אותו הקוד והיה אומר “אוקיי, לי זה כן נראה נכון” - ואז הייתם מנסים להתחיל To un-pack it, להבין למה זה לא נכון.
  • אז הרבה מאוד פעמים, יש דברים שהם Idiom-טיים לשפה מסויימת . . .
(אורי) אני חושב שאת זה ה-Product Manager יגיד לי, אם זה נראה נכון
  • (עומר) זו צרה אחרת לחלוטין . . . .
  • אבל יש דברים שהם Idiom-טיים לשפה מסויימת - ואם אתה מגיע משפה אחרת אז פתאום החוש האסטטי שלך לא מסתדר עם השפה החדשה הזאת.
    • אם אני כתבתי עכשיו המון המון Rust ואני הולך לכתוב JavaScript עכשיו, אז אוי . . .
  • לי אישית זה קרה, אגב, במקום שבו קפצתי מ-#C ל-Java, שבו התחלתי להסתכל ואמרתי שחסרים לי הדברים היותר . . . נניח לינק, למשל, או עבודה קצת יותר פונקציונאלית.
    • אז עשיתי דברים שהם סופר לא-Idiom-טיים ל-Java - וזה היה נוראי.
      • כי כל מי שעבד איתי עבד ב-Java והכיר את הדברים ב-Java ואמר לי “למה אתה קורא ל-Interface-ים שלך עם “i-משהו” בהתחלה?” . . . . אוקיי.
(רן) כן . . . דרך אגב, אני רואה את זה הרבה פעמים עם אנשים שמתחילים לכתוב Clojure, והם כותבים Java - רק עם הרבה מאוד סוגריים . . . . ולוקח הרבה מאוד זמן להיכנס לראש הפונקציונאלי של שפה כמו Clojure, כדגומא, אז אני מסכים, זה קורה לפעמים במעבר בין שפות.

אבל אמרת פה משהו - נסתכל על שני המפתחים, ונניח ששניהם מאוד מנוסים, ולאחד זה נראה טוב ולשני זה נראה לא טוב: אני חושב שהרבה פעמים מה שקורה זה לא בדיוק זה - גם כשלשניהם זה נראה לא טוב, המחלוקת היא עד כמה זה רע . . . יש אחד שבעיניו זו קטסטרופה ויש אחד שבעיניו זה דווקא בסדר, זה די נסבל . . . “בוא, יש לנו פה מוצרים להוציא החוצה מהדלת, בוא לא נתעכב על זה” . . . .
(אורי) . . . וגם יש את העומק של ה-Refactoring . . . . בין “יש לי פה איזה Class שצריך לתקן, סבבה” לבין “הכל קטסטרופה, צריך לכתוב עכשיו 15 Service-ים מההתחלה” . . .
(רן) היה פעם סרטון כזה של אישה שיוצאת מהבית ואומרת לבעלה “בבקשה תחליף את המנורה בחדר השינה”, והיא חוזרת הביתה בסוף היום ורואה אותו כשהוא שוכב מתחת למכונית . . . שואלת “מה אתה עושה?” והוא עונה “אני מחליף את המנורה”, ואז זה מתגלגל לזה שכשהוא רצה להחליף את המנורה הוא חיפש איזשהו מברג ולא מצא אז פתח את המגירה וראה שם משהו מקולקל . . . בקיצור, דבר הוביל לדבר, ו-Refactor הוביל ל-Refactor הוביל ל-Refactor ובסופו של דבר הוא מוצא את עצמו מתקן את המכונית כדי להחליף את המנורה . . .
  • (עומר) האמת שאני מאוד אוהב את המונח הזה של Yak Shaving - “למה את מגלח היאק הזה? - כי צריך, כדי שזה יעבוד” . . . .

(רן) אז עצרנו בנקודה שבה כאילו התבגרנו קצת - יש לנו את ה-Skill, אנחנו יודעים איך לכתוב קוד בצורה יותר טובה. עכשיו, יש לנו את האינסטינקט החייתי הזה” של לכתוב קוד בצורה טובה - כל פעם שאנחנו רואים קוד רע אנחנו רוצים לתקן אותו. אבל יש פה בעייה . . .
  • (עומר) יש פה בעייה מאוד גדולה, כי זה אומר שה-Business עוצר . . .
  • אוקיי, אתה בא ל-Product או לראש צוות ואומר “אני חייב לשכתב את הקוד הזה - כי הוא לא טוב”.
    • השאלה הראשונה היא מה זה אומר, “לא טוב”? . . .
    • אז אפשר להסביר מה זה לא טוב - לא כתוב בצורה הנכונה כי כך וכך או לא מודולרי מספיק ודברים כאלה
    • אבל פה, במשוואה של ה-ROI, תיארנו בעצם מה ה -Return שלנו - למה לנו זה חשוב ומה זה עוזר לנו
      • ונתנו איזושהי הערכה ל-Investment, לכמה זמן שזה יקח לנו
      • “ייקח לי חודש לעשות את זה, כדי שהקוד יהיה יותר מודולרי - ואני אוכל לישון יותר טוב בלילה”.
    • אוקיי, סבבה - “זה לא Business Goal של החברה שלנו - למה את רוצה לעשות את זה?”
  • (רן) אלא אם כן זו חברה שעוסקת בחלומות או משהו כזה . . . .
    • (עומר) או בזה שהאנשים שלה ישנו בלילה
      • אגב - הלוואי שכל חברה הייתה עוסקת גם בזה . . .
      • [רגע . . . פודקאסט עם פרסומת למזרונים? זה עוד לא היה לנו . . . ]
  • (רן) אבל זה לא יעזור לנו לעצור יותר Frauds, כמו שעושים ב-Forter, זה לא עוזר לנו לעשות הצעות תוכן יותר טובות כמו שעושים ב-Outbrain - או לפחות לא הצלחנו להוכיח את הקשר, או שלא הצלחנו לשכנע שיש קשר.
    • (עומר) נכון
    • הקטע הוא שבנקודה מסויימת צריך להתחיל להגיד למה זה שווה לנו, להשקיע את הזמן הזה . . . .
      • למה זה שווה לנו לבוא ו-Explicitly להניח דברים אחרים בצד, כדי לעשות את הדבר הזה.
    • אז דרך אחת, למשל, מאוד מאוד חיובית לעשות את זה היא לבוא ולהגיד שאני יודע - דיברתי עם ה-Product Manager - ואני יודע שהפרויקט הגדול הבא שלנו הוא להוסיף את הפיצ’ר של, לא יודע, “לישון יותר טוב”, אם כבר עסקנו בחברות שינה.
      • ואני יודע שהקוד שלנו, אם נצטרך לעשות את זה - זה יקח לנו הרבה יותר זמן
      • מה שאני רוצה לעשות זה להכין אותנו לדבר הזה, כדי שאחר כך יקח לנו פחות זמן.
    • או לחילופין - אני יודע שיש לנו כרגע כמות מאוד מאוד גדולה של Toil, שזו בעצם העבודה הידנית הזאת, הקטנה, שחוזרת על עצמה, ואנחנו משקיעים בזה הרבה יותר זמן על חשבון משימות של לקדם את עצמנו
      • ואם אני אעשה את ה-Refactor הזה אז אני, By Definition, אקטין את העבודה הזאת.
    • ברגע שמציגים את זה ככה, קורים שני דברים -
      • דבר ראשון - האמירה של “אני חייב לעשות את ה-Refactor הזה” נלקחת הרבה יותר ברצינות, כי ההבנה היא שמסתכלים על זה מתוך משהו הרבה יותר רחב.
      • והדבר השני הוא שזה גורם לנו להתחיל לחשוב בצורה טיפה אחרת - על איך שאנחנו תופסים את הבעיה הזאת.
        • אנחנו כבר לא תופסים אותה כבעיה “אסטטית”, אנחנו כבר לא תופסים אותה כבעיה של “אנחנו לא עומדים ב-Patterns או ב-Idioms של מה שאנחנו עובדים עליו”
        • אלא אנחנו תופסים את זה כבעיה של איך שאנחנו נותנים את ה-Value הזה, כי זה מה שאנחנו עושים - אנחנו מייצרים משהו.

(רן) אז פה אני חושב שבאמת יש צדק בהשוואה בין חוב טכני לבין חוב פיננסי - כשאתה רוצה לקנות, נגיד איזשהו נכס, אז אתה יודע שזה בסדר לקחת איזושהי הלוואה, כי אתה יודע שבסוף תוכל למנף את זה, אתה לוקח על עצמך איזשהו חוב כי אתה יודע שאחר כך, בבוא העת, תוכל למכור את הנכס ביותר ולהרוויח יותר כסף. אז אותו הדבר עם חוב טכני - לפעמים אתה יודע שאתה לוקח על עצמך חוב טכני, כי אתה רוצה להוציא את המוצר יותר מהר ואתה יודע שאתה אחר כך תצטרך כנראה לשלם אותו. יכול להיות גם שהמוצר לא יצליח ואז לא תצטרך לשלם - זאת אומרת שהפסדת את הכסף, מה שנקרא . . . זה יכול לקרות.
  • (עומר) המטאפורה שאני יותר מתחבר אליה, שמאז ששמעתי אותה אני לא מסוגל לעזוב, היא של חוב טכני לטטריס . . . .
    • אוקיי סבבה - רצנו נורא נורא מהר והורדנו את כל הלבנים מהר מאוד - אבל בסופו של דבר אנחנו נפסיד במשחק, כי אנחנו לא נוכל לעשות יותר שום דבר
    • אז תנו לנו רגע “לנקות שורות”, כדי שנוכל להמשיך לשחק את המשחק
      • אנחנו לא מנקים את השורות כדי שיהיה לנו כיף, אנחנו לא מנקים את השורות כדי שאיזור המגרש יראה יותר יפה - אנחנו עושים את זה כדי שנוכל להמשיך לשחק [ציטוט של צ’רצ’יל אם היה מנהל פיתוח].

(אורי) אז השאלה שלי היא “למה עכשיו?” . . . . כאילו אוקיי - אתה רוצה שאחר כך יהיה לך יותר קל לרוץ ולכתוב את הקוד - אבל עכשיו? זה הדבר הכי חשוב?
  • (עומר) אז זהו, שזה לא עניין של “הדבר הכי חשוב” - זה עניין של להכנס לתוך סט השיקולים האלה, של מה הם הדברים החשובים ולנסות לשבת ביחד ולהבין ביחד עם Product האם באמת זה תואם מספיק.
  • כי בסופו של דבר, העבודה הכי אפקטיבית שראיתי אי פעם עם Product היא לא עבודה של ספק-לקוח - זו העבודה הכי גרועה שראיתי . . .
    • הכי טוב זו עבודה של Partnership - אתם הולכים יד ביד לכיוון אחד שמאוד מובן לכולם
  • ברגע שיש את ההבנה הזאת, אז גם Product יותר משתפים את הפיתוח בלאן אנחנו הולכים ולמה, וגם הפיתוח בא ואומר “אנחנו מבינים לאן אנחנו הולכים ולכן אנחנו מביאים דברים שאולי אתה, כ-Product, לא היית מבין, אבל אנחנו מבינים שהם יקדמו אותנו לכיוון הזה”.
  • כמובן שיש גם . . . כולנו בני אדם ולכולנו יש את החוש האסטטי שלנו ואנחנו צריכים לחיות עם מה שאנחנו בונים - אנחנו בונים משהו.
    • אז יש דברים שאנחנו נעשה כי הם קטנים והם חשובים והם נקודתיים - כמו כל הדיבור על Boy Scout Rule של “סיימתי את העבודה שלי במקום מסויים אז אני אשאיר אותה יותר יפה ממה שקיבלתי אותה”.
      • אז אני אוסיף עוד טסטים ואני אוסיף עוד דוקומנטציה (Documentation) במקומות הנכונים, אני אבין שהשארית-קוד הזאת הייתה לא במקום ויש לי את המרווח נשימה לעשות את זה
    • אני לא מדבר על דברים כאלה . . . . אני מדבר על דברים ש-Explicitly צריכים זמן, הקצאת זמן בשבילם.
(אורי) אוקיי . . .
(רן) אני אשחק לרגע את פרקליט השטן - אתה מכיר את זה ש . . .שוב, נסתכל לרגע על יחסי הגומלין שבין Product לבין פיתוח - אני שואל אותך כמה זמן יקח ה-Feature, ואם בא לך לעשות אותו אז אתה אומר “יומיים” ואם לא בא לך לעשות אותו אז אתה אומר “שבועיים”, נכון? . . . . זה כלל-אצבע, זה א-ב של פיתוח.
(רן) אל תדאג - אין מנהלי-מוצר שמקשיבים לנו . . . . אז זה אותו הדבר ב-Refactoring - אתה אומר “תקשיב, איש-מוצר יקר: אם אני אעשה את ה-Refactoring הזה אז אחר כך הכל Unicorn-ים ו-Rainbows . . . הכל פה יהיה מדהים, כל Feature - בשנייה אני מטיס לך אותו”. אוקיי - אבל למה שאיש המוצר יאמין לך? זאת אומרת, אתה יודע - לפעמים אתה גם טועה, בוא . . . . לפעמים אנחנו עושים Refactor וזה לא בדיוק מה שחשבנו שהולך לקרות . . .
  • (עומר) כן, חד-משמעית . . . אז פה נכנס האלמנט של היחסים בין פיתוח לבין Product.
  • התחלנו, בתכל’ס, מזה שאמרנו שכל Refactoring הוא בעצם Trigger ל-”PTSD של Product”, כי הם חוו את הדברים האלה, כמו שסיפרת
    • מישהו אמר “אה, זה Refactor של יומיים” - ואז הצוות היה מושבת לחודש.
    • כולנו ראינו את הדברים האלה . . . .
  • הפואנטה פה היא לייצר את האמון ההדדי הזה, את ההליכה יד-ביד הזאת - וברגע שיש את ההליכה יד-ביד הזאת, מה שקורה זה כל מיני אפקטים מאוד נחמדים
    • למשל - יותר קל להודות בכישלון . . . אנחנו ביחד, כי אנחנו תומכים אחד בשני וזה לא עניין של “למה לא הבאתם לי את ה-Feature הזה תוך יומיים כמו שאמרתם שתביאו אותו!”, אלא יש את היד-ביד-יות הזאת.
  • עוד דבר שזה עושה זה שזה מקטין את ה-Feedback Loop -
    • זה אומר שבמקום שאני אגלה “אה, רגע - ה-Refactor הזה היה אמור לקחת יומיים ועכשיו הוא לוקח חמישה ימים” - אני לא אגלה את זה כשיגיעו החמישה ימים, אלא אחרי שלוש שעות של עבודה על ה-Refactor אני אגיד “יש מצב שאני חושב שזה יותר גדול”, ואני אתן נגיעה קלה בכתף של איש ה-Product שלי ואגיד “תקשיב, יש מצב שזה טיפה יותר גדול ממה שחשבתי . . . . בוא נדבר על זה שנייה”.
    • ופה אנחנו נכשלים בקטן - ואנחנו נכשלים כל הזמן
    • והאינקרמנטים (Increment) הקטנים האלה אומרים שהכשלון פחות כואב, ולכן פחות נורא להיכשל בדברים כאלה, כמו הערכות זמנים ל-Refactoring או כל החלטה שיש.
  • אני חושב שמשהו נוסף שנגעת בו ומאוד חשוב לי לשים על השולחן זה שכשמערכת היחסים היא לא מספיק טובה אז יש את אותו “אפקט מצנן”, אותו Chilling effect, של “אמרתי שזה יקח יומיים - אם אני רוצה לעשות את הדבר הזה אז זה ייקח לי יומייים ואם אני לא רוצה לעשות את הדבר שיקח לי יומיים, אז אני אגיד שזה ייקח חודש”.
    • זה האפקט המצנן, זה בגלל שאני יודע שאם אני אגיד “חודש!” אז זה “לא” ואם אני אגיד “יומיים!” אז זה “כן” - ואחרת אני לא אקבל את הזמן לזה.
    • ואם אני לא אקבל את הזמן לזה, אז אני צריך להתחיל להתעסק עם טקטיקות ועם אסטרטגיות של “איך אני עושה את הדברים האלה?”, איך אני כן מתחכם כדי לקבל את מה שאני רוצה . . .

(אורי) אז אני יכול להגיד על העניין הזה שני דברים - קודם כל, גם ל-Product יש Debt . . . לפעמים אתה פותח איזשהו Dashboard או איזשהו מוצר או משהו כזה, ואתה רואה שזה Patch על Patch ואתה רואה שזה לא . . . יש גם דבר כזה שנקרא “Product Debt”, ולפעמים הם מבינים את זה והם מבינים שהם צריכים זמן לזה ואפשר לשים את זה גם כחלק מהשיחה: “זה שאתה עושה לי פה עכשיו re-design של כל ה-UI זה לא כי זה יקדם אותנו לאנשהו אלא כי יש לך Debt, מה לעשות” . . . .
והדבר השני שייך להערכות הזמנים שדיברת עליהן - אני חושב שהרבה פעמים, לנו - בתור הנהלה - היה מאוד קל לתת איזשהו General Rule, אוקיי? ה-General Rule הוא 20% מהזמן, או כמה שאתה חושב, סביר להניח שזה יהיה בין 20% ל-30% - שאתה נותן ל-Tech-Debt, ולפעמים יש גם “Organizational Debt” כזה, שהוא לא של הצוות אלא הוא בכלל של כל הארגון - לא יודע, נגיד שרוצים להחליף איזושהי ספרייה או שרוצים להחליף איזשהו Pattern לרוחב כל הארכיטקטורה. לדברים האלה, ממש ההנהלה צריכה לתת את מסגרת הזמן - ואז יותר קל לאנשים להבין “אוקיי, אני בסדר או לא בסדר”. השיח עם ה-Product מתקיים על מסגרות זמן מוגדרות מראש, ואני חושב שזה גם נותן ל-Engineers תחושה שגם ההנהלה מבינה שאיכות החיים שלכם, בתור מפתחים, חשובה.
  • (עומר) אני מסכים לחלוטין - אני חושב שההסתכלות הזאת . . . נניח, אמרת, 20% אם נצמד למספר הזה - 20% זה טוב משני כיוונים -
    • 1 - כמו שאמרת, זו אמירה של ההנהלה, Explicitly - אנחנו יודעים שיש דבר כזה Technical Debt ודומיו, ויש זמן שמוקצה לזה.
      • זה לא שחייבים למלא את הזמן הזה וזה גם לא שאם תעברו אותו טיפה אז יפלו השמיים
      • אלא יותר אמירה של “זה בערך מה שהיינו מצפים שתשקיעו, מתוך כמות הזמן ה-Overall-ית”, לכמה באמת להשקיע בזה.
    • אני אהבתי את זה שדיברת באמת על Debts אחרים, על חובות אחרים
      • מה שקראת לו Organizational Debt - אני בדרך כלל קורא לו Architectural Debt, כי Organizational Debt זה יותר הסתכלות שלי של - וזה נושא אחר לחלוטין - של כמה אנחנו רחוקים, כמו הארגון רחוק מהארכיטקטורה . . . .
      • כמה אנחנו צריכים לעשות Alignment בארגון כדי לקבל ארכיטקטורה יותר לכיוון שיהיה פחות Friction במקומות בין-ארגוניים יותר, עבודה יותר יעילה . . . .
      • אבל זה נושא . . . .
(אורי) כשהארגון מספיק גדול, אין לך ארכיטקטורה אחת, אז זה כבר . . . . זה הדברים שקשורים לארגון.
  • (עומר) נכון, אבל ברגע שיש לך . . . אנחנו ניכנס לזה? בכיף למה לא . . . .
  • כשיש לך את המספר-ארכיטקטורות האלה, אז אתה צודק לחלוטין - יש לך כמה ארכיטקטורות’ ולא רק שיש לך כמה ארכיטקטורות, יש לך גם כמה Perceptions שונים לאותה ארכיטקטורה . . . .
  • אבל אז אתה אומר “אוקיי, סבבה שיש לי את זה - אבל יש לי עכשיו ארגון, שבגלל שהוא בנוי בצורה אחרת מהארכיטקטורה כפי שהיא, As-perceived, אז זה מייצר Friction” . . . .
    • כי יש לי צוותים שעובדים בדיוק על אותו Code-base - ואחד מהם הוא ה-Owner והשני הוא לא ה-Owner
    • או כששניהם ה-Owner פתאום, שזה מוזר לאללה . . . . אבל בסדר.
    • אבל זה נושא בפני עצמו . . .

(רן) אז בואו נחזור שנייה ל-Refactoring, ונעשה פה איזשהו סיכום ביניים - אתה בעצם פיתחת איזשהו מודל מנטלי
שבו אתה יכול להעריך האם נכון או לא נכון לעשות Refactoring. ספר לנו עליו . . .
  • (עומר) יש פה כמה גורמים שאנחנו רוצים להכניס לתוך ההחלטה של האם באמת לעשות . . . מה ה-Return על ה-Investment שלנו בלעשות את זה.
  • ויש פה כמה דברים שאנחנו רבה מאוד פעמים לא מסתכלים עליהם בכלל, כמו למשל מה הסיכון בזה שאנחנו נעשה את ה-Refactor הזה?
    • כי הרבה מאוד פעמים אנחנו עם ה-Blinders שלנו אומרים “זה חייב להיות ככה - וזהו!”
      • “כי א-ב-ג”- - לא משנה כמה טוב אתה זה . . .
    • אבל אם אנחנו עושים את זה, אז יכול להיות שאנחנו מכניסים פוטנציאל לבאגים, אולי אפילו ב-Business Logic
    • יכול להיות שאנחנו מכניסים טכנולוגיה חדשה, שלא השתמשנו בה עד עכשיו - ואנחנו לא יודעים איך לתפעל אותה ב-Production.
    • זה בעצם ריסק של לעשות את זה
  • לחלופין, יש גם את הריסק של לא לעשות את זה - מה קורה אם אנחנו עכשיו לא עושים את ה-Refactor הזה, או עכשיו או אחר כך או יותר מאוחר וכו’
    • מה אנחנו הולכים להפסיד פה? יכול להיות שיש לנו ריסק גדול יותר על הערכות זמנים? לגיטימי לחלוטין
    • יש ריסק גדול יותר אם נגיד שהייתה לנו התחייבות כלפי לקוח גדול - כי אנחנו משרתים Enterprise Customers? - יש ריסק, כי יכול להיות שאנחנו לא נצליח להוציא את ה-Feature הזה בזמן
    • יש ריסק . . .ננסה לתת אותו במילים או כמותית או משהו שעוזר לנו טיפה . . . .
(אורי) יש גם את הקטע של “בוא נשאיר את ה-Refactoring הזה לאחרי ה-Release . . . .”
  • (עומר) נכון . . .
(אורי) . . . וזה מן זמן כזה שלא קיים, כי סיימת את ה-Release ומיד מתחיל ה-Release הבא . . .
  • (עומר) . . . “גרסא 2 לא קיימת” . . . . זו האמירה הקלאסית הזאת.
(רן) אלא אם כן אין לך לקוחות . . . כשאין לקוחות הכל טוב . . . .
  • (עומר) כן, וזה . . . .
  • כן יש את האמירה של “לשים את הזמן הזה בצד”, אחרי ה-Release -
    • אם אנחנו מחליטים שאנחנו עושים את זה “Quick & Dirty” לפעמים, או דברים כאלה.
    • אבל שם צריך לבוא Buy-in אמיתי, מההנהלה - אמירה של “אנחנו מכירים בזה שבגלל שאנחנו מגיעים ל-Business Goal הזה במהירות גבוהה, יהיה לנו . . . ההגעה תיהיה בנקודה א’, ורק בנקודה ב’ סיימנו את זה באמת כמו שצריך”.
    • אבל לא יודע עד כמה זה עובד בפרקטיקה . . .
(אורי) אני רוצה רק להגיד שיש פה את הלוח הזה . . . לא משנה, זה איזשהו שינוי מאוד גדול - שאגב, הכרזנו עליו ב-Outbrain בשבוע שעבר - שקשור לאיך להביא דברים שעושים Impact גם קדימה, להתרכז על ה-Impact וכו’ - ופה האדום-כחול-ירוק הזה אלו שלושה שלבים של Crawl-Walk-Run - כשב-Crawl ו-Walk אתה בגדול מנסה דברים ורואה שיש להם Impact, וב-Run אתה . . . רן! אהלן . . . - (רן) היו קוראים לי “F5” בגן . . . - (אורי) אבל ב-Run אתה, בעצם, “מהדק” ומכין ל-Production . . . אז יש לך אפשרות לעשות . . . כשאתה מגיע ל-Run, לגיטימי לזרוק את כל הקוד ולבנות אותו מחדש, בגלל שהוא עושה את מה שאנחנו רוצים, אבל כשאתה מביא משהו ל-Production אז תעשה אותו טוב . . .
  • (עומר) כן, גם הרבה מאוד פעמים ה-Technical Debt נצבר מהנחות שלנו, שהיו לא נכונות . . .
    • בין אם זה הנחות Product-יות או הנחות Bussiness-יות או הנחות טכניות
  • וכל פעם אנחנו מוסיפים עוד איזושהי שכבה של Complexity - ומתישהו צריך לקלף אותן ולהגיד “אוקיי, העולם נראה שונה ממה שהוא נראה שחשבנו כשהתחלנו - בואו נשנה את הקוד To Match that”.
  • ואני מאוד מבין מה אתה אומר - אני חושב ש . . . משהו שמאוד תופס לי את העין באותו לוח שהמאזינים לא רואים אותו [!] זה Sustainability at Scale . . . .
    • שאני חושב שזה - לפחות אצלנו, פנימית, דיברנו על “מהו GA למוצר?”
    • ולקח לי הרבה זמן להגיע לזה שאני חושב שהדבר הכי הגיוני זה שזה Sustainable at Scale
    • כי אם אתה “יורק דם” על כל לקוח חדש שמצטרף למוצר, אז זה לא Sustainable, ול-Scale אתה לא תגיע, יהיו הרבה חללים בדרך . . . .
  • אבל כן . . אני אוהב את זה שאנחנו כל הזמן מתבדרים, זה אומר שזו שיחה טובה.
(רן) אנחנו פונקציה מבדרת . . .
  • (עומר) מתאים לפורים . . .
(רן) לגמרי . . . זה הכי מצחיק שלנו עד כאן . . .
  • (עומר) אז נחזור ל-Mental Model - דיברנו על שני דברים . . .
(רן) דיברנו על Risk of Doing it ועל Risk of Not Doing it . . .
  • (עומר) בדיוק - ועכשיו אנחנו מסתכלים על הדבר שהוא “הכי קל לשים על השולחן” - זה Cost, כמה שזה עולה לנו . . .
  • עכשיו, זה לא רק כמה שזה עולה לי - כמפתח - בזמן,
    • אלא כמה זה עולה לי ב-Attention
    • כמה זה עולה לי בצוותים אחרים שצריכים להתיישר - אם הם צריכים להתיישר
    • כמה זה עולה לי בכל עבודה של . . . אולי אני צריך אנשי Operations או DevOps שיהיו עם זה
    • או שאם יש לי QA ידני אז אני צריך אנשים של QA . . .
(אורי) כמה גדול היאק שצריך לגלח . . . .
  • (עומר) זה גם נכון מאוד . . . יכול להיות שהוא מאוד גדול ואנחנו לא יודעים, עד שאנחנו לא באמת נשב ונחשוב על זה ונתכנן אותו טיפה יותר טוב.
(רן) “במהלך הקלטת פרק זה לא נפגעו יאקים” . . .
  • (עומר) אמרת שזה הכי מצחיק שהיה עד עכשיו, אני מצטער . . . .
  • אבל ה-Cost הנוסף זה Opportunity Cost - או “עלות אלטרנטיבית” בעברית, שזה נהדר כי “אלטרנטיבית” זה לא עברית . . . - זה אומר “מה הייתי יכול לעשות עם הזמן הזה, שאני לא עשיתי”.
  • אז אם הייתי עושה את ה-Refactor הזה, מה הייתי יכול לעשות אבל לא עשיתי, במקום ה-Refactor הזה שיכול היה להביא Value על חשבון זה.
(אורי) ואז זה גורם ל-Refactoring אולי גם להצטמצם? להגיע, נגיד, “לגודל הנכון” שלהם? כי, אתה יודע . . .
(רן) החלפת נורה . . .
(אורי) . . . בדיוק - זו אותה החלפת נורה, שקל מאוד להיסחף . . .
  • (עומר) אתה צודק, ממש - ברגע שאתה מתחיל לחשוב בצורה הזאת, מה שזה עושה זה שאתה מכניס את החשיבה הביקורתית לתוך הראש שלך
    • במקום שאתה צריך את הראש-צוות או איש Product שיגיד לך “אבל למה?! מה אנחנו משיגים בזה?”
    • אתה כבר מתחיל לחשוב את הדברים האלה מראש
    • וזה גורם לך להבין שיש דברים שאולי כדאי לך לשים בצד ולרשום לעצמך באיזשהו מסמך בצד של “הנה הדברים שהייתי רוצה לעשות, אבל כרגע זה לא הזמן” - ולתת את ההצעות היותר נכונות
    • זה גם מעלה את רמת האמון בינך לבין אנשי ה-Product ובינך לבין המנהלים, כשאתה אומר להם “אני רואה את הדבר הזה ואני גם מבין, מתוך זווית הראייה שלי, שזה לא הזמן - אבל אחר כך כנראה יהיה הזמן, אז קחו בחשבון שאנחנו נגיע לזה מתישהו”.
    • זה נותן המון-המון נקודות זכות.
(רן) כן, וזה גם נותן לך להתפתח לשלב הבא שהוא לכיוון פרויקטים וניהול - כשאתה מצליח להבין שיקולים מערכתיים ולא “אני חייב-חייב-חייב לעשות את ה-Refactoring הזה, כי הפונקציה הזאת מפריעה לי בעיניים”, ולהבין שגם לזה יש איזושהי עלות ויש גם את התועלת, שאתה יכול למדוד אותה - וזה מפתח אותך.

הדבר האחרון, שאני בטוח שאתה הולך להזכיר, זה מה אפשר להרוויח מזה? אז נניח שאנחנו עושים . . . .
  • (עומר) מה זה נותן לנו לעשות אחר כך? אוקיי, אז עשיתי מודולוריזציה של הדבר הזה . . .
  • אני אתן איזושהי דוגמא מהעבר הלא רחוק - היה לנו מוצר אחד ועכשיו אנחנו רוצים להוסיף עוד מוצר
    • סבבה, אבל אנחנו לא יכולים להמשיך לעשות את אותו הדבר ופשוט להוסיף עוד מוצר לתוך אותה הקלחת, כי הנחות הייסוד שיש לנו על המוצר הראשון הן לא בהכרח אותן הנחות היסוד שיש על המוצר השני.
      • צורת הפיתוח של המוצר הראשון היא לא בהכרח צורת הפיתוח של המוצר השני, מוצר “בוגר” לא בהכרח מפותח כמו מוצר שהוא Moonshot כזה, ראשוני.
    • אז זה מקום שבו אתה אומר “אוקיי, אולי כדאי לעשות איזשהו Refactor גדול? אולי כדאי לעשות את זה”
    • מתוך האמירה של “הנה הדבר שאני יודע שהולך לקרות בעתיד, הנה הצורה שבה הוא כנראה יקרה - והנה שלבי-ההכנה שאני חושב שאנחנו צריכים לעשות”.
      • וזה Refactor, בתכל’ס . . . .
  • (רן) עד כאן - שיחה קטנה וקלילה על Refactoring . . .
    • (עומר) . . . ושאר מרעין בישין . . . .

(רן) יש עוד נושא קצר, שככה רציתי שנתעכב עליו - אמרנו בתחילת הפרק . . . קודם כל, זו הייתה שיחה על Refactoring וחשבנו שזה הולך להיות קצר, אבל הנה: ניהיה לנו מעניין אז המשכנו . . .
(אורי) החלפנו מנורה . . .
(רן) כן, החלפנו מנורה . . . אבל הקלטנו לא מזמן איזשהו פרק על Observability עם ניתאי [433 Breaking Down Observability with Nitay Milner] - וניתאי בעצם בא והציג איזושהי זווית מוצרית: חברה שמייצרת מוצר בתחום של Observability - והוא בא ושטח את המשנה שלו, של איך לתפיסתו ולתפיסת החברה והמוצר שהם בונים צריך לעשות את זה.
ואז עומר פנה אלי ואמר “תראה, זה מאוד נכון - אבל יש גם גישות אחרות, שמסתכלות אחרת” - איזו דרך אחרת יש להסתכל על הדברים?
  • (עומר) מה שהיה מאוד מעניין זו ההסתכלות מתוך העולם של מטריקות - מטריקות (Metrics) ו-Log-ים ו-Trace-ים
  • אבל אני רוצה לקחת צעד אחורה ולהגיד שאוקיי - אנחנו מסתכלים כרגע על מערכת: מה, בתכל’ס, הייתי רוצה להוציא מהכלי Production שלי, הכלי Monitoring?
    • הייתי, בתכל’ס, רוצה לדעת מה קורה ב-Production - לא הייתי רוצה לדעת מה חשבתי שנכון להסתכל עליו ב-Production - אלא באמת מה קורה ב-Production . . .
  • אז אם אני לוקח, נגיד את המטריקות - מטריקות אומרות “איזה דברים הייתי רוצה לספור ב-Production?”
    • מה זה אומר? אני הולך ועושה אגרגציות (Aggregations) של איזושהי נגזרת - כמה Unique Users או כמות User-ים שיש לי במערכת בכל נקודת זמן, כמה היו לי בחודש האחרון וכו’ וכו’
    • ואז אני אומר “רגע! כמה 500-Errors היו לי?” אני צריך לייצר מטריקה חדשה כזאת ולהתחיל לספור אותה . .
      • זה אומר שאני צריך לשנות את הקוד שלי - וזה אומר שרק החל מהרגע שעשיתי Deploy לדבר הזה, יש לי את המטריקה החדשה הזאת.
(רן) מה שאתה מתאר פה בעצם זה Monitoring - שזה למדוד את הדברים שאנחנו יודעים שאנחנו צריכים למדוד, אבל אתה צריך לדעת מראש, אחרת זה לא יהיה שם . . .
  • (עומר) ולא רק זה - רוב כלי ה-Monitoring מאוד מוגבלים ,נניח, בכמות הערכים שיכולים להיות בכל Dimension וכמה Dimension-ים יכולים להיות . . .
(רן) נכון, אי אפשר למדוד הכל . . . זה לא פרקטי, וגם אם תמדוד הכל אתה לא תמצא את עצמך אחר כך.
  • (עומר) זה Fact of Life, אין מה לעשות - צריך לשנות את ה-Mental Model שלנו, כדי להכיל את המגבלה הזאת.
    • אוקיי, אז זה כלי אחד . . .
  • כלי שני זה Logging - אני רוצה לדעת מה קורה בתוך המערכת שלי, סבבה - אני הולך ועושה F- על ה-Log-ים ומסתכל עליהם
    • או מסתכל ב-Elastic Search או Whatever-מה-שאני-משתמש-בו
  • ואני אומר “יופי, יש לי עכשיו את הזה - ואני יכול עכשיו, בנקודות שאשכרה כתבתי את ה-Log-ים האלה, אני יכול להבין מה קרה - בערך” . . .
    • למה? כי ה-Log-ים האלה הם חסרי-הקשר . . .
    • אני מסתכל על Stream של מה שקורה לי במערכת ברגע זה - או באיזשהו טווח-זמן.
      • אני יכול לפלטר (Filter) אותם - למשל אם רשמתי איזה User אז אני יכול לדעת איזה User, וכו’
      • אבל שוב - הם נטולי-הקשר לחלוטין.
(רן) דרך אגב - זה מסוג הדברים שקצת יותר קל לעשות ב-Monolith והרבה הרבה יותר קשה לאסוף באוסף של microServices . . . אבל נכון, זאת אומרת - Log זה סוג של Point-in-Time: אתה מסתכל על זה, אבל קשה לך מאוד לדעת מה קרה לפני זה, מה קרה אחרי זה וכמה דברים אחרים קרו במקביל. לא שזה לחלוטין בלתי אפשרי - תיאורטית, המידע נמצא שם - אבל מאוד מאוד קשה, במבט על ה-Log-ים להבין ולקבל את התמונה המלאה.
(אורי) אלא אם כן אתה אוסף את כל ה-Log-ים של ה-microServices שלך לתוך מערכת אחת ו . . . .
(רן) כן . . . זה לא שהמידע לא קיים - הוא קיים, רק שמאוד מאוד קשה לקבל תמונת מצב. זה כמו שאתה נמצא בקרב - יש לך ערפל, יורים עליך מכל כיוון . . .. אוקיי, תיאורטית יש לך את האינפורמציה, אבל לבוא ולקבל תמונת מצב ברורה זה מאוד קשה מה-Log-ים, כי הם יחסית Low-level.
  • (עומר) נכון, אתה רוצה בעצם לקבל Context ואתה לא בהכרח מקבל את ה-Context הזה סביב אותו Log-line . . .
(רן) Tracing! . . . .
  • (עומר) אז Tracing זו דרך לבוא ולהגיד “אוקיי, יש לנו במקום Monolith עכשיו microServices” ואני רוצה להבין איפה הבקשה שלי עברה - בקשה אחת, אינדיבידואלית
    • אז אני לוקח כלי כמו Jaeger או משהו כזה, ואני מסתכל ואומר “אה, אוקיי - הבקשה הספציפית הזאת, שיש לי את ה-ID שלה, שהבאתי אותה מה-Logging system שלי, בגלל שה-Monitoring שלי אמר לי שיש לי את זה . . .
    • אז אני עושה Copy-Paste בין כל מיני . . . עושה קורלציות בראש ואומר “אה! אוקיי - ניקח את ה-Trace הזה”, כי ה-Trace הזה כן די מייצג את הבעיה הכללית שיש לי.
  • זה נחמד לדבר מאוד מאוד נקודתי, אבל - אבל מה פיספסתי בדרך?
    • אילו 500 Trace-ים אחרים שלא הסתכלתי עליהם?
    • קשה מאוד להסתכל עליהם - אני צריך איזשהו . . . אני צריך לעשות איזושהי אגרגציה (Aggregation) מעל ה-Trace-ים, וזה קשה ממש לעשות דבר כזה . . .

(רן) דרך אגב - אני חושב שמעניין להגיד שבפרק הקודם שהקלטנו עם איתן מ-Optibus [זה - 435 Optibus Playback with Eitan Yanovsky] - הוא סיפר על איזשהו כלי שהם בנו פנימית [Playback] והוא בא ואמר אוקיי - אנחנו יודעים להקליט Traffic, ואם יש שגיאה אז זה נשלח לשירות Monitoring שלנו, ששכחתי מהו [“אנחנו משתמשים ב-New Relic וכל מיני . . . Lumigo ודברים כאלה”], ואז הוא יודע למצוא את כל ה-Instance-ים הנוספים של אותה השגיאה - שזה קצת דומה למה שאתה מתאר פה.
בוא, תביא לי עוד דוגמאות, ספר לי באילו עוד מקרים זה קרה . . .
  • (עומר) אז אני, אם לא אכפת לך - במקום דוגמאות אני אתן איזשהו כלי חלומי, שהייתי מאוד שמח לקבל אותו.
  • אני יכול לקחת את המערכת שלי ולייצר Distributed traces, כמו שיש בדרך כלל - ואני נותן את כל ה-Dimensions של כל העולם: מה שבא לי, באיזו Cardinality, כמה ערכים שאני רוצה בכל Property וכל Dimension ו-Whatever.
    • אני רוצה לזרוק את זה לאיזשהו משהו - ושהוא יעשה לי את ה-Crunching ותיהיה לי “פלטפורמת DBI” כזאת שתעשה לי את כל ה . . .
    • אוקיי - אני רוצה לדעת . . . . “תן לי את כל ה-User-ים שכמות הזמן שהם בילו במערכת יותר גדולה מ-X” ובוא נראה מה מייחד אותם
    • מדהים . . זה חלום, אני לא צריך אחרי זה Log-ים, אני לא צריך Trace-ים, אני לא צריך מטריקות . . . אני פשוט יכול לעשות אגרגציות (Aggregations) על מה שאשכרה קורה בתוך המערכת שלי.
  • אז זה נשמע אחלה וזה נשמע מאוד מאוד חלומי וזה נשמע גם . . .
(רן) למרות ש . . . . נניח שטכנית זה אפשרי, יש חסרון בגישה הזו שאני רוצה להצביע עליו וזה שבזמן הפיתוח אתה לא חושב על הדברים האלה . . . אתה אומר “אחר כך מישהו יאסוף ויאגרג (Aggregate . . .) ויראה לי את כל התמונה, אז לא צריך לחשוב על זה בזמן הפיתוח”, אבל יש פה חיסרון, כי אם אתה לא חושב על המטריקות שלך בזמן הפיתוח, כמו כמה בקשות לשנייה וכמה גישות ל-Database ו-Latency וכל זה, אתה גם - בסופו של דבר - תייצר קוד פחות טוב, כי זה לא במודעות שלך, לבוא ולמדוד את זה . . .
(אורי) נראה לי שגם זו מערכת די דימיונית - שבזמן הפיתוח אתה חושב על כל המטריקות שאתה צריך . . . אבל מהאירועים שקורים, הדבר הזה מתפתח. מערכת מטריקות ו-Log-ים והתראות וכל הדברים האלה מתפתחים עם המקרים שקורים.
  • (עומר) אתם צודקים לחלוטין - ואז אני שואל אתכם שאלה כזאת: אם אותה מערכת דמיונית היא כחלק מתהליך הפיתוח, כמו שאני כותב Unit Testing או כמו ש אני כותב Integration Tests, שאני רוצה לעשות את זה בכל מקרה, לא משנה באיזה שלב התפתחותי של המערכת והם גם ישתנו וזה בסדר
  • אם הייתי זורק את כל המידע שיש לי לתוך המערכת הדימיונית הזאת, הכל - כל דבר שאי פעם אוכל להשתמש בו - ומקסימום המערכת הדימיונית הזאת תיתן לי לעשות אגרגרציות על זה, תיתן לי לייצר מטריקות על בסיס זה. מגניב . . .
  • אני לא צריך לחשוב על זה, לא צריך את החשיבה האופרטיבית הזאת או את החשיבה ה-DevOps-ית הזא בתוך הקוד, כי אני פשוט זורק את זה “לתוך החלל הגדול” ואומר שמתישהו מישהו יעשה עם זה משהו . . . .
(רן) זה מזכיר לי את הספר הקלות הבלתי נסבלת של הקיום” . . . . “הקלות הבלתי נסבלת של Monitoring”, בעולם הדימיוני הזה שלך . . .
  • (עומר) כן . . . אז בוא ניקח את זה ונעמיד את זה מכיוון אחר קצת: המערכת הזאת קיימת.
  • ב-2006, אם אני לא טועה, Facebook הוציאו Whitepaper על מערכת שקוראים לה Scuba, שהם - בגלל שהם Facebook ויש להם אינסוף כסף - הם עושים מלא דברים בזיכרון ועושים אגרגציות . . .
(אורי) ב-2006 Facebook עוד לא היו קיימים . . . . [היו. לא כמו היום, אבל היו מ-2004].
  • (עומר) אז 2016? . . . .יכול להיות, אני מצטער, התאריכים לא כתובים לי בשום מקום, כולל בראש . . . [התאריך על זה הוא 2013]
(אורי) גם לא ב-Scuba, כנראה . . . איך לא חשבת על זה לפני?! היית צריך לעשות את זה בזמן הפיתוח . . . .
  • (עומר) הייתי צריך לעשות מזה מטריקה . . . .
  • בכל מקרה, המערכת הזאת קיימת, אפקטיבית, בתוך Facebook - שזה מאוד נחמד להם, אבל מה איתנו, “פשוטי העם”?!
  • אז מסתבר שיש חברות שכבר מתחילות לתת את הדברים האלה, את ה-Feature-ים האלה.
    • השתיים העיקריות הן LightStep ו-Honeycomb
    • אנחנו ספציפית, בתוך Forter, משתמשים ב-Honeycomb - וזה שינה לנו דרמטית את הצורה שבה אנחנו רואים את Production
    • כי אנחנו כרגע “רואים” את Production . . .

(רן) יש שם Dashbord-ים?
  • (עומר) יש שם Dashboard-ים אם ממש בא לך - אבל Dashboard-ים הם לא תשובה לשאלה . . .
(רן) בדיוק . . . .למה אני שואל? אני חושב שבמקרה הזה לא Facebook אלא Google פרסמו שבאחד מכלי ה-Monitoring הפנימיים שלהם - אם אני לא טועה Borgmon - הם לא רוצים Dashboard-ים, כי Dashboard-ים מסלילים אותך . . . אתה חושב מראש שאתה הולך לדעת איפה הבעיה ולכן אתה בונה לעצמך Dashboard, אבל אנחנו לא רוצים דבר כזה. מה שאנחנו רוצים זו יכולת Exploration מאוד קלה - שברגע שיש בעיה’ אתה תוכל מאוד בקלות לעשות Exploration - קצת ימינה, קצת שמאלה - ובסופו של דבר להגיע ולעשות Pinpoint לבעיה.
לכן, למרות שאולי טכנית אפשר לעשות שם Dashboard-ים, זה נחשב כ-Anti-Pattern.
  • (עומר) אז אני יכול להגיד שבאמת אנחנו, מתוך השימוש היומיומי שלנו בכלי הזה או בכלים מסוג כזה, אנחנו לא משתמשים ב-Dashboard-ים באמת.
  • ה-Dashboard-ים באים כדי לייצג סטטוס - שאלות שאני כבר יודע לשאול, מה התשובות אליהן, At a glance.
  • אלו לא כלי תחקור - כי מה שהם אומרים זה שאני בעצם יוצר המון גרפים שמסתכלים על סיטואציה מזויות שונות, במקום לבוא ולהגיד “בוא נבין מה הסיטואציה הנוכחית”.
    • כי כל הכשלונות במערכת שהיא מספיק מבוזרת - שזה שני Node-ים וזה מספיק מבוזר - כל הכשלונות נראים שונה . . .
    • ואם הכשלונות נראים לי באותה הצורה, אז כנראה שלא תיקנתי את הבאג הספציפי שהייתי צריך לתקן, אז סבבה - צריך לתקן את הבאג.
  • אז דברים כמו Anomaly detection -אנחנו מקבלים את זה Out of the Box - אני רוצה לדעת למה פתאום יש לי מלא Session-ים שעושים Timeout
    • אז אני פשוט לוקח ומסמן אותם ומקבל איזו רשימה של Dimensions - שאפילו לא הייתי חושב לתשאל אותם והם פשוט שם כי הם קיימים, כי זרקתי אותם לתוך המערכת הדמיונית הזאת
      • שהיא לא ממש דימיונית . . . .

(רן) אבל בוא, שנייה, פה אני קצת מבולבל . . . אתה לא צריך לחשוב מראש על המטריקות, אבל בכל אופן - מה הוא אוסף? כאילו . . . עוקב אחרי ה-CPU ואוסף בכל Cycle? מה . . .
  • (עומר) אז אין Agent-ים - מה שיש זה את הסטנדרט של OpenTelemetry - שאם אני לא טועה אז גם דיברתם עם ניתאי על OpenTelemetry - שבבסיסו הוא Distributed Tracing ומטריקות
    • אנחנו לא משתמשים ב-offering של המטריקות של Honeycomb כיום
    • והוא מתייחס לזה כמו אל Distributed Trace, פשוט Wide Events - וכשאני אומר “Wide” אני מתכוון להמון המון Dimensions, המון המון Attributes, באיזו קרדינליות שאני רוצה . . .
(רן) אוקיי, אבל אתה צריך להסביר, אתה צריך להגדיר אותם . . .
  • (עומר) אני מגדיר אותם - פשוט ה-Rule of Thumb הוא “לשלוח הכל” . . . כל מה שמישהו אי-פעם אולי ירצה להשתמש
  • התוכניתן . . . סליחה - המתכנת שיושב לידי . . . “תוכניתן” זה מסגיר את הגיל . . . אז המתכנת שיושב לידי - אולי יהיה בעתיד איזשהו Outage שהוא יצטרך את הדבר הזה מתישהו, אולי . . .
  • וגם אם לא - אה . . . .
(רן) בסדר - צריך לחשוב על זה מראש, אבל זה לא “עולה לך”, זה לא עולה לך להוסיף.
(אורי) אתה צריך לחשוב על זה מראש . . .
  • (עומר) אנחנו, כמי שהם Owner-ים של המערכת שלנו ב-Production, אנחנו רוצים לדעת איזה מידע שאי-פעם נצטרך להשתמש בו.
  • אני גם יכול להגיד שפיספסנו היום - יש המון מקרים שאנחנו אומרים “או, אם רק היה לי את הדבר הנכון הזה, אז הייתי יכול לקבל ולהגיע לבעיה הזאת הרבה יותר מהר”.

(רן) אני גם חושב שאתה הצבעת על בעיה שלא הרבה מכירים - שכשהמערכות גדולות, זה מאוד יקר להוסיף עוד מטריקות, ולכן אתה צריך להתחיל להתחשבן: האם להוסיף את המטריקה הזאת? את המטריקה ההיא? זה לא כל כך עניין של זמן עבודה אלא עניין של Storage ושל Scale וכו’ - ובעצם מה שאמרת ש-Facebook פתרו ב-Scuba ומה שאתם עושים עם Honeycomb זה שאתם אומרים “אוקיי, בעיית ה-Scale-ביליות הזאת נפתרה, אז עכשיו אפשר לשלוח את כל המטריקות - ועכשיו אני . . .
(אורי) רגע - בעיית ה-Scale-ביליות נפתרה? או שאנחנו מחליטים להתעלם ממנה?
  • (עומר) אתה צודק, זה ממש נכון . . .
(אורי) או שיש לנו מספיק כסף כדי להתעלם ממנה . . . .
  • (עומר) אז אני אגיד דבר כזה - שני דברים . . .
  • קודם כל, רן - אני אענה לך על השאלה, על מה שאמרת: זה לא רק להוסיף עוד מטריקה, אלא להוסיף High-Cardinality Dimension למטריקות . . .
    • אם אני עכשיו אגיד שאני מכניס ל-Grafana שלי, אני מכניס עכשיו איזה User ID, ה-Grafana ימות . . .
(רן) נכון - היסטורית, מערכות כאלה לא עמדו בעומסים של קרדינליות, של כמויות של מטריקות, של קצב של מטריקות . . .
  • (עומר) יש להן Constraints מאוד מסויימים - וזה הגיוני לחלוטין.
  • ובנקודה של קצב - אתה צודק, אין דרך לשלוח הכל. אז מה?
    • מה שאתה עושה בנקודה מסויימת זה שאתה מתחיל לעשות Sampling - אתה אומר “אוקיי, יש לי Session-ים שנראים בדיוק אותו הדבר, עד כמה שאני זה . . . אני עושה Sampling דינאמי
    • זאת אומרת שאת כל ה-Error-ים שיש לי במערכת, כל הדברים שהם לא בסדר - אני שולח אותם בלי Sampling
    • אז יש לי 500 פעמים שמישהו קיבל . . .
(אורי) 500 פעמים Error 500 . . . .
  • (עומר) רציתי להגיד את זה וזה נשמע מאוד לא טוב אז אמרתי שאני אעשה את זה 401, אבל בסדר . . .
  • אז אתה יכול לבוא ולהגיד . . . ניתן דוגמא, למשל - אנחנו גילינו הרבה פעמים שבלקוחות עם Throughput יחסית נמוך, אז קיבלנו Alert-ים . . .
    • על מה? אחוז Error-ים גבוה ממש . . .
    • הסתכלנו על זה ואמרנו “אוקיי, זה User שעושה Retry - Retry - Retry . . . . “
      • פשוט Throughput ה-Baseline היה כל כך נמוך, שזה גרם לנו להבין.
    • אבל בשנייה אנחנו אומרים “אוקיי, זה ה-User ID הזה” - אז עכשיו אנחנו יודעים את זה.
  • אבל אתה צודק שבקצבים סופר-סופר-גבוהים, אתה חייב איפשהו להתפשר - כי אין דרך . . .
    • המערכת הזאת אמנם כבר לא דמיונית, אבל אנחנו גם לא יכולים . . . גם לה יש Constraints מסויימים.
    • אז לפעמים יש בה שימוש טוב ולפעמים יש בה שימוש לא טוב . . .
  • ב-Forter, למשל, אנחנו משתמשים בה בקצבים מסויימים - ויש חלק אחר במערכת של Forter שאני לא הייתי ממליץ להם להשתמש בזה
    • כי ה-Throughput הוא כל כך גבוה והבעיות הן כל כך לא מתאימות לסוג כזה של כלי, שלא הייתי ממליץ.
    • אולי הם היו יכולים להשתמש בזה אם ממש היו מתעקשים, אולי זה היה באמת מתאים להם - אני לא יודע.

(רן) עומר, אז אתה היום ב-Forter . . .
  • (עומר) במקרה . . .
(רן) איפה אתם נמצאים? איפשהו בתל-אביב כזה?
  • (עומר) כן, אנחנו בתל אביב - יש את הבניינים החדשים האלה, ליד תחנת רכבת מרכז, דרומית לשם - איפה שהרסיטל [!] . . .
  • למי שלא מכיר את Forter, דרך אגב - אז אנחנו עוסקים באמון . . . .
    • [יש את הפרק המיתולגי של השבוע מ-2014 . . . . ]
    • זה מתקשר מאוד יפה לנושא של השיחה היום, אבל לא בכוונה
    • אנחנו מתעסקים יותר באמון בעולם של כלכלה דיגיטלית
    • מה זה אומר? אם אתם עכשיו מנסים לעשות איזשהו תשלום באתר eCommerce, או שאתם מנסים ליצור אתר או שאתם עושים איזושהי פעולה מסויימת -
      • אז הרבה מאוד פעמים Forter נמצאת שם ואומרת “זה הגיוני, אפשר . . . זה לא Fraudster, זה לא מישהו שמנסה לרמות את האתר”
      • זה לא שעכשיו מישהו מנסה ליצור איזושהי Fraud Ring או עם כרטיס אשראי גנוב ומנסה לעשות רכישה.
  • אני, ספציפית, נמצא ב -Line מוצרים חדש יחסית, שיותר מסתכל על הצד השני -
    • לא רק האם זה Fraudster או לא Fraudster, אלא גם אם זה לא Fraudster לפי Forter - ו-Forter יודעת את זה מאוד מאוד יפה - איך אנחנו יכולים לעזור לשאר השחקנים במגרש להבין שזה לא Fraudster או שהרכישה הזאת לגיטימית
    • זה אתגר מאוד גדול, כשהסטטיסטיקה הרווחת היא שמשהו כמו 1 מ-10 רכישות באינטרנט, שהן לגיטימיות, פשוט לא מצליחות - ואנחנו שם כדי לנסות לעזור.
(רן) הבנתי . . . . אז אתה רוצה למנוע את ה-False-Negatives . . .
  • (עומר) זה תלוי מה ה-”Negative” שלך, אבל בגדול כן . . . .
(רן) “האנשים השליליים האלה” . . . . כן - אז אתה אומר שזה אתר שחוסם User לגיטימי מלקנות מוצר שהוא רוצה
  • (עומר) אתר שחוסם User לגיטימי, חברת אשראי, בנק . . . .
(רן) בסדר . . . אתם בטח מגייסים טונות של מפתחים . . . .
(אורי) מפתחים באים אליכם במשקל? . . .
  • (עומר) מגייסים המון מפתחים להמון . . . בכלל, ב-Forter יש . . .
(רן) איך נראה ה-Stack הטכנולוגי שלכם היום?
  • (עומר) או-ווא . . . .אז בכל איזור הוא יחסית שונה
    • יש לנו איזורים שהם מאוד Data-intensive אז זה כל העולמות הקלאסיים של Data-intensive Compute או Data-intensive Processing ו-Stream Processing וכו’.
    • יש לנו איזורים אחרים שהם יותר מוכווני-Product
    • יש לנו איזורים שהם יותר תשתיתיים . . .
    • אתגרים מאוד מעניינים
  • ואני חייב להגיד - בתור מישהו שעבד בלא מעט סטארטאפים - זו אחת החברות עם ה-Culture הכי כייפי שיש והכי נעים שיש . . . אז אני נהנה.

(רן) ובנימה אופטימית זו - תודה רבה שבאת! היה מעניין. להתראות.

האזנה נעימה ותודה רבה לעופר פורר על התמלול!

234 פרקים