פרק מספר 464 של רברס עם פלטפורמה, שהוקלט ב-3 באוגוסט 2023 - אורי ורן מארחים באולפן בכרכור (עדיין גל-חום, אבל עם קצת רוח) את גור שץ מחברת Cato Networks כדי לדבר על המשמעות של לתחזק Infrastructure קריטי - וה-Infrastructure ש-Cato מתחזקים הוא לחלוטין קריטי ללקוחות שלהם: מה המשמעות? איך עושים את זה? מה קורה כשיש תקלות? איך מגיבים אליהן? איך מפתחים DNA בחברה כך שתדע לטפל ב-Infrastructure קריטי ונושאים אחרים.
הנושא עצמו קרוב לליבם של רן ושל אורי, אז אזהרת תוכן מראש על התערבויות באמצע : - )
01:24 גור ו-Cato
- טוב, אז אני הסתובבתי בשטח ככה, 20 משהו שנים בערך - אבל לפני 12-13 שנים בערך גיליתי את עולם ה-Service-ים.
- שמעתי את ההרצאה ב-Velocity של “עשרה Deployment-ים ביום” ואמרתי “זה העתיד!”
- ראיתי ש-Service-ים זה העתיד
- ואז התגלגלתי לעולם ה-Service-ה-Mission-Critical - כש-Incapsula הייתה החברה שהקמתי שעסקה בזה
- היא עשתה הגנה על אתרים - בהתחלה הגנה על התקפות רגילות, על אתרים מההתקפות רגילות,
- ואחר כך התקפות DDoS
- זו הייתה חברה שעסקה באמת בהגנה על אתרים ושמירה עליהם
- ואחרי Incapsula בעצם, הדבר הבא היה Cato.
- ו-Cato בעצם לוקחת את הרשת הארגונית - ובונה אותה מחדש, בענן.
- וזה Mission-Critical Infrastructure - בעצם, מה שזה אומר זה שאם יש בעיה ב-Cato, אז הלקוחות - אין להם אינטרנט, אין להם מייל, אין להם SAP . . .
- אין להם שום דבר שהם מסוגלים לעבוד איתו - זו ההגדרה של Mission-Critical וזה בעצם התחום הזה.
- כלומר, בסופו של דבר, זו החוכמה.
- אני לא יודע מאיזו שנה אתם נמצאים בעולם ה-Service-ים - אבל העולם הזה שבו כולם נמצאים אצלך כל הזמן ואתה צריך בעצם לדאוג להם, זו מנטליות מאוד מאוד הפוכה לעולם ה-Enterprise Applications שהתחלתי ממנו, נכון?
(רן) שאלה טובה . . . . מאיזו שנה אני נמצא שם? אני לא יודע . . . . מתישהו משנות ה-2000+ , אני מניח . . .
- (גור) הרבה לפני . . . .
03:18 הקו האדום של הכנרת
(רן) אחד הדברים המעניינים שאני חושב שכדאי להתחיל בהם את השיחה - אני זוכר שקראתי, יש ספר מאוד טוב שנקרא SRE Book של גוגל, שבו הם מדברים על איך מייצרים Infrastructure, איך מתחזקים Infrastructure, ואחד הפרקים שם מדבר על מה זה “Uptime”, אוקיי?
זאת אומרת, Service - זה לא שהוא רק “למעלה” או “למטה”, אלא יש גם אחוזים, זאת אומרת: “כמה אחוזים למעלה?”, “כמה אחוזים למטה?”. זאת אומרת, אתה תיארת מצב שבו אתם ה-Infrastructure, אתם הרשת, ה-Network של הארגון, ואם אתם “למטה”, אז גם הארגון “למטה” - הוא לא יכול לעבוד, אבל האם זה . . .
(אורי) . . . הלקוח למטה . . .
(רן) כן, הלקוח למטה . . . האם זה בינארי? כלומר, האם זה “למעלה” או “למטה” או שיש אחוזים, יש זה . . . . מתי, בעצם, אנחנו מתחילים לדבר על “אוקיי - ירדנו מתחת לקו האדום של הכנרת”, אם מישהו זוכר את זה . . . . ?
- (גור) אז קודם כל, ברגע שאתה מתעסק באמת ב-Critical-Infrastructure, אז אתה מהר מאוד מגיע ל”חמש תשיעיות”, שזה ה-Common Denominator של Critical-Infrastructure
- אתה לא יכול לרדת מתחת לזה
- אבל גם אם לא ירדת . . .
(אורי) . . . . ולמאזיננו שלא חיים את עולם ה-Infrastructure? . . .
- (גור) - 99.999% מהזמן אתה צריך להיות למעלה
(רן) חמש פעמים תשע . . . . מה המשמעות של זה? נגיד - כמה בשנה? . . . כמה? מה? . . .
- (גור) זה דקות בחודש.
(רן) דקות [ספורות] בחודש . . .
- (גור) . . . . מועטות . . . לדעתי אפילו פחות מזה.
- אבל זה גם לא . . . . זה לא כזה נתון נכון כשאתה מסתכל עליו - כי בסופו של דבר, הבעיה שלך זה שכשאתה סופר את ה-Uptime, אז זה שאתה צריך לספור את ה-Uptime מהנקודה הכי גרועה.
- כלומר, תחשוב נגיד, אם יש לך חברה, ובחברה - יש לה עשרה משרדים.
- ועכשיו, אחד המשרדים - יש לו בעיה.
- עדיין, אותם אנשים באותו המשרד - יש להם בעיה חמורה, הם לא מאושרים, הם לא יכולים לעבוד.
- ולכן, הדרך הנכונה אצלנו למדוד את ה-Uptime זה Uptime אפליקטיבי (Application uptime)
- כלומר, האפליקציות עובדות - ועל פני כל האתרים של הלקוח.
- ולא רק באופן כללי - בממוצע ובסך הכל.
(רן) כן, אז זה למשל, הבדל בין הדרך שאתם מודדים לבין הדרך שבא תיארו בגוגל בספר הזה שלהם איך מודדים - למשל, הם באו ואמרו “אוקיי, נגיד אם יש Downtime בגרמניה, יש שם נגיד X לקוחות, נגיד 90 מיליון לקוחות, מכלל אוכלוסיית הלקוחות של גוגל בעולם, זה אולי 10% - אז יש לנו עשרה אחוז Downtime”, נניח, משהו כזה.
זאת אומרת, אצלכם לא? זה “OR”, זאת אומרת, מספיק שב-Branch של הלקוח יש Downtime, אז זה מאה אחוז Downtime . . .
- (גור) נכון - וזה יכול להיות גם Downtime שהוא אפליקטיבי (Applicative), מסיבה שהיא לא קשורה ממש לרשת עצמה . . . .
- יכול להיות, נגיד, שמנוע Security שלנו מפשל ומחליט ש-Google היא לא אתר אמין - זה יכול לפגוע בשירות שיש ללקוחות וזה יכול לעשות בעיות נוראיות . . .
(רן) בעיות לוגיות, יש בעיות לוגיות, כן . . . .
- (גור) אבל אני חושב שכאילו, כשאנחנו מדברים על Critical-Infrastructure, אז כאילו אנחנו הופכים את זה למשהו מאוד מאוד “מיוחד”, משהו שהוא מאוד מאוד כזה "חריג”
- אבל בסופו של דבר, אני חושב שהנקודה החשובה היא שזה פשוט Production - ואנחנו פשוט מתייחסים ל-Production בתור משהו . . .
- כלומר, שהמדרון להידרדרות של המצב הוא הרבה יותר תלול ואולי הרבה יותר קרוב
- אבל Production זה Production - כל ארגון חייב לדעת לשמור על ה-Production שלו.
- כלומר, אולי אנחנו נמצאים במין מצב כזה שבו, באופן חריג, אנחנו ממש חייבים להקפיד על השמירה על ה-Production ואנחנו ממש חייבים לשמור על ה-Uptime שלו בצורה קנאית
- אבל כל ארגון צריך לעשות את זה - ואולי אצלנו יש פה תהליך שבעצם הוביל אותנו ללימוד של מה הדבר הזה.
- אולי גם הוא רואה מזה ש-Outages אצלנו יהפכו להיות הרבה יותר Stressful והרבה יותר קשוחים כאלה.
- (גור) כן . . .
(אורי) . . . אוקיי? כאילו, זה מאוד חשוב ל-Perception שלך אל מול הלקוח - ובטח לביטחון של אנשי המכירות שלך או של האנשים שעומדים בחזית מול הלקוח - בקטע שאתה אומר “אני על זה”.
- (גור) נכון.
(אורי) אוקיי? “לפניכם” . . . . ואחד “ה-Race” שהיה לנו - המקום שבו אתה מבין שאתה במערכת קריטית - זה כשאתה יודע שאתה ירדת ותספור עוד עשר - יגיע טלפון מהלקוח . . .
- (גור) בדיוק.
(אורי) . . . למה? כי צנח לו ה-Revenue פתאום . . . .
- (גור) נכון.
- אגב, בדיוק השבוע היה לנו Retro, שלא היה על אירוע מאוד מאוד חמור - אבל זה היה אירוע שהלקוח דיווח עליו
- וזה הפך את זה להיות אירוע Retro מאוד מאוד חמור - כי איך זה יכול להיות שלקוח הוא זה שמגלה שיש לו בעיה?
- זה משהו שאסור שיקרה במערכת Production או במערכת קריטית.
- וזו באמת אחת המטריקות (Metrics) הראשיות שאנחנו עוקבים אחריהן - כמה מהאירועים, אנחנו לא עלינו עליהם ראשונים?
- וזהו, כאילו . . .
(רן) אז בעצם אני חושב שמה שניסית גם להגיד, גור, זה שמעבר ללהגיד מה זה “Critical-Infrastructure”, אתה בעצם רוצה להגיד למאזינים “כנראה שגם לכם יש Infrastructureש הוא קריטי” . . . .
ברוב המקרים, זאת אומרת, כל מי שעובד על איזשהו SaaS, איזשהו משהו שמשרת לקחות - מבחינתו, מבחינת הלקוח, ה-Infrastructure שאתם מפתחים הוא קריטי - ולכן הפודקאסט הזה רלוונטי למי ש . . . .
- (גור) כן, מי שמפתח אפליקציות Enterprise שהן “Deployed בשטח” - אז השתתפותי, וכנראה זה לא בשבילו.
- אני הפסקתי את זה לפני 12 שנים . . . .
- אבל מי שמתעסק ב-Service, אז יש לו Production.
- יש לו Production - אז יש לו לקוחות שתלויים בזה.
(אורי) כל מי שנותן בעצם SaaS . . .
- (גור) כן.
09:00 היום הזה, שהוא אחרי יום שני . . . .
(רן) אוקיי, מה הם הכלים הנקרא לזה “מדעיים” שאיתם מודדים? אז דבר אחד הזכרת - זה Five-nines, נכון? זמינות של 99.999 . . . .
- (גור) כן - “כמה שערות לבנות יש לך בעקבות ה-Outage-ים?” . . . . אם יש לך שיערות בכלל . . . .
- אבל לא, כלומר, באמת - אני אתחיל בזה שאחד הדברים שאתה יודע, ואתה יודע כשאתה Infrastructure קריטי, זה שכשיש Outage אתה ישר מבין, שבעצם המוני אנשים עכשיו תלויים בשירות שלך - והם עכשיו סובלים.
- הרבה מאוד מהארגון הולך לאופטימיזציה של המצבים האלה - של הטיפול ב-Incident-ים, של לדעת להתאושש מהם מהר ולפתח את הכלים ואת הדרך לעבוד איתם, למשל.
(אורי) להתאושש מהם - ובטח נדבר על איך מגיבים לזה כדי שהם לא יקרו עוד פעם . . .
- (גור) כן, האירועים עצמם הם מאוד מאוד Stressful
- כלומר, אני יכול, בוא נגיד, אני יכול לספר על אירוע כזה שהיה - אני רק אתחיל בלשאול אתכם: מתי אתם חושבים שהזמן הכי נפוץ בעולם ל-Outage-ים?
(רן) בין שתיים לשלוש בשעון ישראל, בלילה . . . .
- (גור) כן, בין 2 ל - . . . .
- אז קודם כל, כשהייתי בעסק של DDoS - אז זה היה תמיד ביום שישי בלילה . . . .
- אבל זה בגלל שאתה לא אחראי למתי דברים קורים
- אבל לא - בחברה שהיא חברה שלא עוסקת באנשים רעים בסין?
(אורי) לדעתי, שבע בבוקר?
- (גור) אז לא, אז התשובה היא . . . התשובה היא, ממחקרים שנעשו, זה אחר-הצהריים ביום רביעי . . . . זה הזמן הכי . . .
(אורי) שעון - ? . . . .
- (גור) עכשיו, לכן אני חושב נגיד על ה-Outage שלנו - זה היה ביום שלישי אחר-הצהריים, וזה בגלל שבארץ מתחילים לעבוד ביום ראשון
- כלומר, היום הזה - שהוא אחרי יום שני . . . .
(אורי) אוקיי . . . .
- (גור) . . . . ואז כבר מתחילים לקרות דברים שהם פחות . . . . שהם כבר “שייכים לשבוע החדש” - זה הזמן ל-Outage [מהמוצדקים]
- ואחרי ארוחת הצהריים גם כן, יש לזה סיבה טובה מאוד . . .
(אורי) אני דווקא הלכתי למקום של . . . . למה אמרתי “שבע בבוקר”? זה כי האמריקאים מסיימים, כאילו, את היום - ואז הם מתחילים כל מיני “תחזוקות”. עכשיו, לפעמים, אם אתה מושפע ממערכות אחרות, שמושפעות, נגיד . . . פשוט אמריקה היא איזור גדול, אז הם מתחילים שם כל מיני תחזוקות, ואתה - תצפה ל. . .
(רן) למפולת שתגיע . . .
(אורי) . . . . במקום שלא תלוי בך - אלא תלוי בספקים שלך או תלוי בשותפים שלך - פתאום שם אתה מתחיל לחטוף.
- (גור) תראה, בוא נאמר ככה - רוב ה-Outage-ים בעולם הם Self-inflicted,
- כלומר, על כל Outage שנובע מספק, בדרך כלל דווקא Outage-ים מספקים זה דבר שקל מאוד להתאושש ממנו - אתה בונה את זה לתוך המערכת.
- אבל ה-Outage-ים שאתה מייצר - הם החלק הקשה.
- במיוחד שבעצם היום זה שנגיד, אם אתה מריץ שירות - אנחנו חברה שמריצה שירות, ואנחנו חייבים לרוץ מאוד מהר קדימה, בו זמנית.
- כלומר, אנחנו צריכים מצד אחד לשמור על Uptime - אבל מצד שני, כל הזמן להשתפר ולשנות ולהוסיף Feature-ים וכן הלאה.
- ולכן, המערכת נמצאת כל הזמן בשינוי - ולכן יש גם יותר סיכוי שאנחנו נעשה לעצמנו Incident מאשר, נגיד, שזה יקרה מבחוץ
- כי אנחנו בנינו את ה-Resilience-ים מול הספקים החיצוניים - אנחנו לא נהיה אלה שנמנע את ה-Outage-ים אצלנו . . .
- ולכן גם התחקור אחר כך הוא מאוד חשוב.
(רן) אז אמרת “שלישי בצהריים” - אז מזה אפשר להשיג שיש גם יותר Deployments בזמן הזה?
- (גור) האמת ששוב פעם - אני חושב על האירוע בשלישי בצהריים: לא היה Deployment, לא היה כלום . . . .
- יש שתי צורות ש-Outage-ים מתחילים
- (1) זה שהם “מתגנבים” אליך . . . . כלומר, שזה בדרך כלל קורה כשהיה מישהו שהיה אחראי בעצם להרים את “פעמוני האזעקה”, והוא לא עשה את זה.
(רן) DNS לא חודש, קבצים מתמלאים, נגמר מקום בדיסק . . . . דברים כאלה שלאט לאט קורים . . . .
- (גור) אבל ה-Outage-ים הגדולים באמת הם ה-Outage-ים “שמתפרצים עליך”
- כלומר, יום שלישי אחר-הצהריים, אתה מתחיל לקבל ב-Slack, בכל מיני ערוצים, הודעות שאומרות שכל הרשת לאט לאט מאבדת תקשורת של רכיב אחד עם רכיב שני . . . .
- מה אתה עושה?
(אורי) אגב, יש לי עוד דוגמא לדוגמאות שנתת . . . .
(רן) רגע, אנחנו במתח . . .
(אורי) . . . . כשאיזה ID עובר את ה-Integer פתאום . . . .
- (גור) כן . . . Bug ש . . . . עוד עשר שנים יהיה לנו כזה, אני חושב - “באג 2037” או משהו . . . [2038].
- אבל זהו, באמת . . . .
- (גור) יום שלישי אחר צהריים - וכל ה-PoP-ים שלנו מתחילים לדווח שהם לא מצליחים ליצור קשר אחד עם השני.
- ואתה לא יודע את זה - אבל אתה רואה המון המון הודעות ש”זה לא מדבר עם זה” ו”זה לא מדבר עם זה” ו”אני לא רואה אף אחד!” . . . . .
- עדר תרנגולות שלם שבעצם . . . . לול תרנגולות שלם . . . .
(אורי) זה נשמע כמו פוליטיקה ארגונית רגילה . . .
- (גור) כמו היום בכנסת, כן . . . .
(רן) קודם כל, אתה מחפש את מי להאשים, זה דבר ראשון . . . .
- (גור) עכשיו, אז אתה מקבל את זה - ואז השאלה הראשונה היא מה אתה עושה? מה קורה?
- מה הדבר הבא? מה עושים?
- אז אני מקבל את זה במשרד - אני, כאילו, לא יודע מה קורה וכן הלאה
- אז המזל שלי זה שאני רואה נגיד מישהי שהולכת לכיוון ה-NOC - מישהי שאני סומך עליה - ואני אומר לה “משהו קורה! תעשי הליכה יותר מהירה לשם . . . . “
- ואני עצמי פוצח בריצה מסביב, רק כדי לעבור במשרד, לראות שאולי אנשים שהם אנשי-מפתח יודעים מזה או אם הם לא שמו לב, אז שאני אגיד להם “קדימה!”
- ואנחנו הולכים להתאסף עכשיו - כי עכשיו יש בעיה קריטית ואנחנו ב-Mode של War-room.
(רן) כן, “אזעקת אמת” . . .
(אורי) ישנו נוהל מסודר ל-War-room?
- (גור) אז יש דיסציפלינה (Discipline) ל-War-room
- זה לא נוהל מסודר, זה משהו שבסופו של דבר נבנה.
- המזל הגדול הוא באמת . . . השאלה הגדולה הראשונה היא קודם כל “מי בא?”
- כלומר, באיזושהי נקודה מישהו יכריז על All Hands - ויתחיל להעיר אנשים כדי שאנשי-המפתח יגיעו.
- נגיד, יום שלישי אחרי-הצהריים, יחסית במזל . . .
(אורי) קל . . .
- (גור) קל, אז ה-Zoom מתמלא - אבל זה בעצמו, זה גם יכול להיות בעיה . . . .
- כי אם יש לך שלושים אנשים שעולים, אז כבר לא בטוח מה גבולות האחריות וכן הלאה . . .
- כלומר, יש הרבה יותר סיכוי שדברים מאוד מאוד קריטיים שצריכים לקרות, לא יקרו - כי יש כל כך הרבה אנשים שכולם סומכים על אנשים אחרים שיעלו.
- ובאמת, כשאני עולה נגיד עכשיו ורואה את החדר Zoom, אז השאלה היא “מה עושים הלאה?”
- מה אנחנו יודעים?
(אורי) יש מנהל לאירוע?
- (גור) אז נגיד שבדרך כלל יש מנהל-אירוע” טבעי” - מישהו שהוא יותר אחראי.
- ובדרך כלל, איך שאנחנו עובדים על זה אז גם בעצם יש . . . בעצם החברה מתפצלת לשניים [מקום ראשון בהרמות להנחתה ever?]
- כלומר, יש צד אחד שהוא הצד שהוא ה-Customer Facing - ה-Support פותחים War-room, ה-Operations פותחים War-room, ויש חיבור ביניהם.
- ובעצם, ה-Operations War-room זה מי שאחראי להבין מה קורה ולפתור את הבעיה
- וזה כבר עניין של סדר - באמת, הניהול של האירוע כאן יהיה נורא נורא חשוב.
- כי מה בעצם המטרה לעשות? המטרה, הדבר הראשון, השלב הראשון של ה-Outage . . . .
- אז עברנו את שלב הגילוי, אנחנו מבינים שהמצב הוא על הפנים
- השלב הבא זה כבר להבין מה קורה - ולהבין מה קורה זה קשה מאוד במצב ש-(א') יש המון המון Signal-ים -והם מעורבבים ו-(ב') המון אנשים נמצאים על ה-Zoom . . .
- אז התפקיד, בעצם, של מי שמנהל את האירוע הזה, זה לעשות בעצם שלושה דברים ולעשות אותם כל הזמן, בלולאה כזאת:
- אתה כל הזמן צריך לדעת מה אנחנו יודעים
- צריך לחזור על זה לכולם
- לצורך העניין, “אנחנו יודעים שאין לנו כרגע תקשורת בין המחשבים האלה למחשבים האלה, ה-PoP-ים האלה לא מצליחים ליצור קשר עם PoP-ים אחר”
- האם זה קשר של CNC, האם זה קשר של Data?
- מה הדברים שאנחנו יודעים להגיד בוודאות?
- (רן) כי יכול להיות שיש כאלה שרק עכשיו הצטרפו או כי אולי לפני זה התעפצו וצריך שוב לפקס אותם . . . .
- (גור) . . . וחשוב מאוד להגיד מה אנחנו יודעים - כלומר, דבר הראשון שצריך להעביר זה מה אנחנו יודעים, לא מה אנחנו חושבים.
- הדבר השני זה מה אנחנו חושבים - כלומר, יש לנו תאוריות, אבל אסור לבלבל אותן עם העובדות שאנחנו יודעים . . .
- אז מה אנחנו יודעים? מה אנחנו חושבים שיכולה להיות הבעיה? לאיזה כיוון אנחנו מתקדמים?
- והדבר השלישי מאוד חשוב - מי צריך לעשות מה?
- כלומר, יש 30 אנשים - כולם יעשו את אותו דבר, אבל לא את הדבר החשוב . . .
- אז יש ממש . . . לא צריך לעשות רישום של זה, אבל צריך להגיד “אוקיי, אתה תעשה את זה, אתה תעשה את זה”
- ואנשים יודעים - הם יקחו את האחריות על עצמם - אבל חשוב שהיא תהיה אחריות על מה צריך לחקור, איזה דברים צריך לברר וכן הלאה
- ואז אנחנו מתחילים להריץ את זה . . .
(רן) זה נעשה בע”פ או שזה נעשה בכתב? זאת אומרת, זה ב-Zoom או ב-Slack? או משולב ? . . . .
- (גור) אנחנו צריכים . . . . אם אתה יכול לעשות את זה Live ב-Zoom, אז זה הרבה יותר . . .
(אורי) השאלה היא אם מתעדים משהו ב-Zoom, משהו ב-Slack - הסיבה היא שכשמישהו עכשיו מצטרף ל-Zoom, אתה לא צריך לעשות לו את כל “הסקירת-מצב” מחדש, אלא הוא פשוט נכנס ל-Slack והוא קורא מה קרה עד עכשיו . . . .
(רן) צריך איזה Logger - מישהו שהתפקיד שלו הוא לעשות Log-ים . . .
- (גור) כן, לא . . . הנקודה היא שיש . . . כל אירוע, באיזושהי צורה, יש לו גם השלכה על ה-Slack
- הבעיה עם Slack זה שב-Slack כמות המלל שנוצרת - זה לא שאתה מגיע לערוץ ה-Slack ואתה ישר יודע מה קורה . . .
- אתה מגיע לערוץ ה-Slack ומקבל 1500 שורות שאתה צריך לקרוא - ואולי הן כוללות . . .
- לכן, החלק דווקא ב-Zoom הוא שאתה ממקד כל הזמן את מה אנחנו יודעים - אתה כל הזמן חוזר על מה אנחנו יודעים, מה התזות שלנו, מה הדברים שאנחנו צריכים לעשות . . . .
(אורי) האמת שגם הדינמיקה בשלב מסוים של אירוע כזה - ב-Outbrain זה נקרא “מסיבת Production”: הבנאדם עולה, הוא כבר . . . . אתה יודע מה אתה רוצה ממנו . . . .
(אורי) לא יודע, זה השתרש עם הזמן . . .
(רן) כן, כמו שאני, אוקיי . . . .
- (גור) כן . . . אז בעצם, אז החזרה הזאת . . .
- אז נגיד אצלנו - אז אנחנו יודעים שה-PoP-ים לא מדברים אחד עם השני, אז האם אנחנו רואים שיש Corrupted Traffic ביניהם? האם אנחנו רואים שיש בעיית של Key Exchange? מה אנחנו יודעים להגיד?
- ואנחנו מייצרים בדיקות כאלה ואנשים באים ואומרים את זה.
- עכשיו, זה מאוד חשוב - כי עובדה, מה שקורה נגיד אצלנו - אנחנו, אז יש לנו Outage, ה-PoP-ים לא מדברים ביניהם, המערכת מתחילה לסגת לכל מיני Fallback-ים
- כלומר, המערכת עצמה בנויה עם Fallbacks על Fallbacks על Fallbacks . . . .
- אז ה-PoP-ים לא מדברים ביניהם - אבל Fallback-ים מתחילים לקרות, ובמקביל לקוחות מתחילים להרגיש שיש בעיות . . .
- עכשיו, החזרה לדברים האלה בסופו של דבר עוזרת
- למה? כי יש אנשים שנמצאים על הערוץ הזה ואז פתאום אחד אומר “כן, אתם אומרים משהו שהוא ככה וככה, אבל זה לא - אני רואה שהבעיה היא אחרת ממה שאתם רואים!”
- “אתם אומרים שאין CNC, אני אומר לכם שיש CNC - כי ראיתי”
- “מצד שני, אני ראיתי משהו אחר שהוא לא עובד טוב”
- ואז בא מישהו ומתקן אותנו - וזה מכוון אותנו לכיוון הנכון.
20:06 מי נתן את ההוראה?
(רן) מי זה אותו בנאדם שמנהל את התקרית הזאת?
- (גור) אז נניח שזה אני - פשוט בגלל שאנשים, נגיד, “נתנו לי את המקום”
- אבל יש הרבה אנשים שהיו יכולים לעשות את זה בצורה ממש טובה.
- כל עוד יש מישהו כזה -אז המצב הוא טוב.
(רן) אוקיי, אז זה מישהו עם היכרות טובה של הארכיטקטורה . . .
- (גור) בדיוק, ואנשים שנמצאים על הערוץ הזה זה אנשים שמבינים - אנשים שמכירים את המערכת לעומק, מכירים אותה ממש ממש טוב.
- זה גם חלק מ-DNA של חברה שמתעסקת ב-Production - שזו חברה שבה אנשים, לא משנה באיזה דרגה אם הם בהנהלה וכן הלאה, הם צריכים להבין טוב טוב איך הדברים קורים
- הם צריכים להבין איך הדברים קורים “ברמת הברזלים”
- והתקשורת היא אז הרבה יותר קלה, כלומר - אם עכשיו בא ראש צוות ואומר לי “תשמע, ה-CNC עובד, ה-XYZ לא עובד”, אז חשוב שכולם יבינו על מה מדובר.
- וזה בעצם נותן לנו, כאילו, כיוון,
- פתאום אנחנו מבינים “אוקיי, משהו קרה - מישהו איפס את ההצפנה בין המחשבים” . . . .
- מישהו יצר Negotiation של . . . . עשה החלפת Keys שלא עובדת טוב - וזה גרם לכל ההתנתקות הזאת.
- ואז זה כבר מתחיל לכוון אותנו, כי אז אנחנו אומרים “אוקיי, מאיפה זה בא?”
- עכשיו אנחנו יודעים ללכת לרכיב הנכון - ולהבין מה קרה שם.
- (אורי) בסוף הכל חוזר להתנתקות . . . .
- (גור) וזהו, ובאמת, אז מהר מאוד אנחנו מוצאים שמישהו הפעיל . . . . מישהו בעצם הפעיל שכתוב של כל ההצפנות ברשת - וזה גרם לבעית ההתנתקות.
- ואז אתה אומר - מי עשה את זה? מאיפה זה קרה?
- כמובן, אחרי . . . .
- (רן) . . . . ואז המטיגציה (Mitigation) כבר יותר ברורה.
- (גור) כן, אז הבנו איפה זה קורה . . . כמובן שזה בסוף היה “הצוות האדום” שלנו, שעושה Penetration Testing על המערכת
- [למיטיבי האזנה - 422 Pentesting with Erez Metula]
- הוא עשה Whitebox Penetration Test - מתוך הרשת, באמצע . . . .
- והוא הצליח למצוא API ישן - והפעיל אותו
- וגרם בעצם ל-Outage . . . .
- לפחות מצאנו את הצוות, אמרנו “תעצרו הכל, תעצרו הכל!” . . . .
22:24 הצד המסוכן של ה-Outage
- (גור) אבל אז אנחנו מגיעים לצד המסוכן של ה-Outage - זה החלק הכי מסוכן עכשיו . . . .
- כי ברגע שאתה יודע מה המצב, דווקא כשאתה יודע מה הבעיה ואתה יודע למה היא קרתה - אז זה החלק הכי הכי מסוכן.
- אגב, ה-Outage הכי ארוך שהיה לי אי פעם - שזה היה שעה - זה היה לפני 12 שנים וזה קרה בגלל . . . . בגלל אותה סיבה . . .
(רן) מזכיר לי את הנתון של תאונות דרכים, שהרבה - או אולי הרוב - אבל הרבה קורות ליד הבית . . . אתה חושב שאתה כבר ב-Safe Zone, אתה מרגיש בטחון . . . .
(אורי) בדיוק . . .
- (גור) והלקח הכי גדול הוא שהזמן הכי קשה ב-Outage או ב-Incident בכלל, זה שהזמן שאתה חושב שאתה יודע מה אתה צריך לעשות - אז אולי תעצור רגע
- כי לא משנה כמה המצב גרוע כרגע - יכול להיות שעוד חמש דקות אתה ממש תתגעגע לאיפה שהיית, ולכן . . . . [שוב ד”ש ליודוקוליס ליפשיט]
- וה-Outage הכי ארוך שהיה לי אי פעם בדיוק היה מצב כזה - כלומר, היה מצב שהקונפיגורציה (Configuration) במערכת לא עבדה, לא התעדכנה
- ניסיון של תיקון של זה ב-Production גרם לזה שהקונפיגורציה התאפסה . . . .
- ואז כל הרשת . . . .
- (רן) “ה-Database נפל? נרים אותו!” - ואז אתה מגלה שברגע שאתה מרים אותו - מהומה גדולה: הוא מתחיל לדווח לכל האחרים, כולם מדווחים אליו, אף אחד לא יודע מי ה-Leader . . . . הלך עליך.
- (גור) אז דווקא הזמן הזה, זה הזמן שצריך לקחת זמן . . . . במקרה הזה אנחנו לוקחים 5-7 דקות, כדי להריץ סימולציה של מה הדרך שאנחנו חושבים שיכולה לתקן
- אפילו שיש לנו מצב חמור - אנחנו אומרים “ניקח את הזמן, אחרת . . . “ - שלא נתחרט.
- ובאמת, בסופו של דבר, אנחנו מצליחים להחזיר את הרשת . . . .
- אנחנו מצליחים להחזיר את הרשת, היא מצליחה, בגלל כל ה-Fail-back שהיו לנו אז הרגישו את זה עשרות לקוחות - ולא מאות ואלפים . . .
- ותוך חצי שעה אנחנו חזרה למעלה.
- ואז השאלה הבאה היא כבר “אוקיי, צריך ללמוד מזה”
24:12 ללמוד מזה
(רן) כן, אז מה קורה עכשיו? קודם כל, נושמים, שותים מים, נרגעים . . . . אז בעצם, מה שאנחנו מתארים פה עכשיו, זה את ה-Life Cycle של Incident, נכון? כאילו, מה קורה בזמן האמת, ברגע האמת - “צוות ה-SWOT” שבא לטפל בזה. אבל אחר כך גם צריך לעשות איזשהו תחקיר ולמידה.
(אורי) האמת שברגע הזה, התחושה היא כמו ש . . . לא יודע מה, הצלת מישהו מטביעה או מזה . . . האנשים - הם עדיין באדרנלין גבוה.
- (גור) כן . . .
(אורי) הם לא רוצים “לעזוב את המסיבה” . . .
- (גור) זה ממש קשה.
(אורי) . . . הם נשארים כדי לראות “שכל המטריקות (Metrics) חזרו לזה שלהם” - ולפעמים אנחנו מוצאים את עצמנו, לא יודע . . . הם צריכים שיבוא מנהל מספיק בכיר ויגיד להם “לכו לישון”, כי זה . . .
- (גור) בתחילת . . . בתקופת, בהתחלה ב-Incapsula, הייתה תקופה מאוד ארוכה שבה היינו . . .
- זה היה עידן-הזהב של ה-DDoS בעולם, והיו התקפות עצומות, שהלכו ונהיו יותר ויותר גדולות, והרשת שלנו הייתה קטנה יותר מההתקפות האלה
- וממש היה איזה מין קרב-הישרדות שנמשך כמה חודשים - עד שבנינו רשת מספיק גדולה.
- ומה שקרה, זה שאנשים היו כל הזמן במין Mode כזה - של אירועי Production, של אילתורים, כל ה . . . Mode של High Adrenaline כאלה - פשוט לא הצליחו לעבוד גם . . .
- כלומר, ברגע שאתה “מתמכר” למקרים האלה, אז אתה יוצא לגמרי מהשגרה - אתה לא יכול לעבוד ואתה לא יכול לעשות שום דבר.
- (אורי) אתה הופך לכבאי במקום לבנאי . . .
- (גור) כן . . . אתה יכול להיות Junkie גם של אדרנלין . . . .
- (אורי) נכון
- (גור) אבל המטרה שלנו היא להוריד את האירועים האלה, כלומר - המטרה שלנו היא לגרום ל-Production להיות יותר ויותר יציבה עם הזמן.
(רן) כן, יש גם אפקט מוכר שנקרא, אם אני לא טועה, The Hero Effect - זאת אומרת, אותו אחד שבא להציל את כולם ולכאורה הוא הגיבור, צריך לזכור שעצם זה שאנחנו זקוקים לכזה גיבור, זה “נון” שלנו . . . .
- (גור) כן . . .
(רן) זאת אומרת, צריך לבוא ולדעת ולתקן את זה בצורה שהיא שיטתית.
26:30 הפן השיטתי והמלך של כל ה-Design Patterns
(רן) אז בואו נדבר עכשיו על הפן השיטתי - זאת אומרת, אחרי שזה נגמר: האדרנלין קצת ירד, הלכתי לישון, התעוררתי בבוקר. מה עכשיו עושים?
- (גור) אז קודם כל, אני חושב שהמפתח אצלנו זה שכל אירוע ב-Production אצלנו - יש עליו Retro.
- וה-Retro הזה - הוא שונה באופי מאשר ה-Retro שמטרתו להגיד למפתח, או למי שגרם ל-Deployment או עשה שינוי ויצר את ה-Incident, מה היית צריך לעשות כדי למנוע אותו?
- כי הפוקוס הוא לא באמת על המניעה של מה שקרה, או המניעה של ה-Deployment.
- נגיד, אם אני עכשיו מפתח ואני לא יודע . . . בואו נניח עכשיו יצרתי, היה לי Incident וה-Incident היה שיש לי מערכת אות’נטיקציה (Authentication),
- ובמערכת האות’נטיקציה הזאת היה Deployment ל-Production
- ועכשיו, המערכת הזאת קיבלה ב-Production קונפיגורציה (Configuration) שלא הייתה קיימת באף סביבה אחרת
- אני לא יודע אם אתם מכירים אירועים כאלה . . . .
- (רן) מעולם לא קרה . . . . לא מכיר אף אחד שזה קרה לו . . .
- (גור) לא קרה מעולם . . . .
- . . . . וכתוצאה מזה, אחד הרכיבים של אותו רכיב אות’נטיקציה (Authentication), לא תפקד ולכן המערכת האות’נטיקציה התחילה להחזיר תשובות ריקות והתחילה להעיף משתמשים החוצה. אוקיי . . . .
- אז ה-Retro יכול להיות להתקדם בכיוון הבא: אתה יכול לבוא ולגיד, “אוקיי, אני המפתח שיצר את ה-Bug, אני לא בדקתי את הקוד שלי מספיק טוב, לא היה לי טיפול במקרה שהקונפיגורציה (Configuration) מזובלת ו-Automation - לא היה לנו Test שבודק את זה” - וסיימנו את העניין.
- (אורי) תשובה לא נכונה . . . .
- (גור) . . . . כי זה לא הפך את ה-Production להיות יותר יציב - זה פתר, נקודתית, את האירוע הזה.
- ולכן, נגיד, Retro אצלנו, מתחיל באמת בתחקור של האירוע עצמו - מה קרה, מה ה-Bug, מה היה ה-Root Cause וכן הלאה
- אבל אז אנחנו עוברים כבר למצב אחר - למצב שבו, קודם כל, כל צוות הארכיטקטורה-רבתי של החברה יושב ומעורב באירוע הזה, בא ומבין מה קרה.
- וביחד מנסים לחשוב, איך היה אפשר - לא לגרום לאירוע הזה לא לקרות, אלא איך היה אפשר למנמם (To Minimize) את ההשפעה שלו על Production
- מה עשינו לא נכון בזה ש-Bug קטן הפך להיות אירוע ב-Production.
- ואנחנו רוצים שכמו Boeing 747 - צריך להיות כמה וכמה טעויות, שיקרו אחת אחרי השנייה ברצף, כדי שה-Boeing יתרסק [ובכן . . . .]
(אורי) זאת אומרת - יש אנליזה, קודם כל של ה-Root Cause, אבל אחר כך אנחנו שואלים את עצמנו, עושים אנליזה נוספת שהיא על ה-Resilience של המערכת.
- (גור) בדיוק . . .
(רן) בהנחה שזה יקרה גם בעתיד, אוקיי? Bug-ים בסגנון הזה יקרו בעתיד - אז איך אנחנו מצמצמים את ה-Blast Radius, איך אנחנו מצמצמים את הנזק . . .
- (גור) בדיוק - וזו כבר שאלה שהיא לא מוגבלת לאנשים שיצרו את ה-Bug או שעשו לו את ה-Deploy - זו כבר שאלה לצוות את הארכיטקטורה של החברה.
(רן) שאלה אחרת שאפשר גם לשאול זה “אוקיי - יכול להיות שיצרנו API שקל לטעות בו” . . . זאת אומרת, יצרנו קבצי קונפיגורציה (Configuration files) מאוד מורכבים, וסביר להניח שגם המפתח הבא יטעה פה. אז לא בהכרח, Blast Radius יותר קטן, אלא זה יותר Usability של המערכת שלנו.
- (גור) אז בוא נעשה סימולציה - אז אוקיי, יש את הרכיב, הרכיב שלח הודעות ריקות, זרק את כל הרכיבים האחרים, אין להם אותנטיקציה (Authentication), אני חושב שהיה Outage כזה ל-Google לפני כמה שנים . . . .
- מה הבעיה בזה? מה הבעיה הארגונית בתוך הדבר הזה?
- (אורי) קודם כל, יש את הבעיה הארגונית שישר יגידו “אה, גם ל-Google הייתה את הבעיה! זה כאילו, זה בעיה של “גדולים” . . . .
- (רן) “אנחנו בחברה טובה” . . . .
- (גור ) כן . . .
- (רן) כן, אוקיי - כל תשובות נכונות, כן? אין תשובות לא נכונות . . . אז אולי . . . אולי המערכת צריכה לפתח יכולת “להבין שהיא טועה”? זאת אומרת, אותו רכיב, אם הוא מבין שמשהו פה לא בסדר, אז שיפסיק “לצעוק שטויות” ופשוט ישתוק?
- (גור) כן, אז את זה נאמר שזה פורמלי - כלומר, יש כמה עקרונות, ואנחנו, יש לנו סט של עקרונות והם ידועים, הם מוכרים, אנחנו מתקשרים אותם
- ואנחנו כאילו, מניחים שאם היו בעיות - הן נבעו מזה שלא הלכנו לפי העקרונות הבסיסיים שלנו.
- לדוגמא, אם יש רכיב . . . נגיד, שיחה שיכולה להתקיים ב-Retro הזה: הרכיב שלח תשובות ריקות, ולכן כולם עפו.
- אז קודם כל, האם הרכיב הזה ידע לדווח שהמצב שלו הוא זה שהוא זורק תשובות ריקות וכן הלאה?
- אז מישהו אומר “לא, אני כתבתי ל-Log” . . .
- תמיד אומרים “כתבתי ל-Log” וזה בסדר - מישהו היה צריך לאסוף את ההודעה הזאת מה-Log . . .
- אז התשובה היא “לא”
- רכיב צריך לדעת להגיד מה ה-State שלו,
- רכיב צריך לדעת ולהיות מסוגל להבין, אם הוא לא מצליח להוציא אף תשובה אחת ו-100% מהבקשות שהוא נותן נגמרות ב-Error - זו בעיה של הרכיב, והוא צריך לצעוק “אני למטה! אני למטה! אני במצב לא בסדר!”, זו אחריות שלו.
- (רן) בחלק מהמקומות קוראים לזה Health Check, אוקיי? - “האם אני בריא? האם אני בריא ומוכן לשרת לקוחות?”
- (גור) אז יש לנו ממש, נגיד, “כלל ברזל” כזה - רכיב חייב שתיהיה לו אחריות על ה-State שלו.
- לא יכול להיות שהוא פשוט “יזרוק ל-Log” איזושהי הודעה ויצפה שמישהו יאסוף את זה . . .
- זה צריך להיות מדווח בצורה מאוד מאוד ברורה - ”אני ב-State לא בסדר”
- ואם עכשיו החלטנו שכש-90% מהבקשות נופלות זה נחשב ”State לא בסדר”, אז הרכיב הזה צריך להיות מסוגל להגיד למערכת בצורה ברורה “הצילו!”.
- מעבר לזה - אבל מה עם אלה שקיבלו את התשובות הריקות האלה? מה איתם?
- יש שאלה של Graceful Degradation - האם הם היו יכולים לפנות לרכיב אחר? האם הייתה להם דרך אחרת? האם להם הייתה אלטרנטיבה?
- כלומר, גם שם יש אולי שאלה של Resiliency ו . . .
- (רן) כן, אז פה יש טכניקה של Short Circuit [“פיוז”], למשל - זאת אומרת שאם אתה מבין שה-Backend שלך תקול, אז תפסיק לפנות אליו, או לפחות נגיד לחמש שניות או איזשהו מנגנון כזה - ותחזיר איזושהי תשובה Default-יבית.
- אז כן, יש פה לא מעט . . .
- או תפנה לרכיב דומה, שנמצא תחת או מאחורי ה-Load Balancer . . .
- (גור) נכון, כלומר - גם הלקוחות של אותו רכיב צריכים להגיד “יש מצב שבו, יש לנו Graceful Degradation, Short Circuit
- משהו כזה שמאפשר לנו להגיד “אוקיי, הבלתי נתפס קרה!” - מה עושים כשהבלתי נתפס קורה?
- כלומר, מה . . . אז זה כמו ה-Switch Cases שיש תמיד ב-Code - שיש את ה-We Shouldn't Get” Here” [או If you can read this, you’re . . . .]
- (אורי) כן . . . .
- (גור) . . . ותמיד אתה מגיע לשם.
- (אורי) יש גם את ה-Concept של רכיב . . . . הרי אנחנו, כשאנחנו עושים Deployment בדרך כלל, אנחנו לא פורשים הכל על כל ה-Instance-ים של אותו Service
- אתה פורש אחד-אחד, ואחד צריך לגמור את ה-Deployment שלו, לעלות, לדווח שהוא בסדר - ואם הוא לא בסדר הוא לא מקבל תנועה . . .
- (גור) המלך של ה-Design Patterns - ה-Graduality
- שום דבר אסור שיקרה בבת אחת - לא Deployment, לא פרישה של קוד, לא שינוי . . . .
- שום דבר אסור שיקרה בבת אחת בכל המערכת - אתה אף פעם לא צריך “לכבות את השאלטר” ולהדליק אותו ולצפות שהכל יעבוד . . .
- (אורי) כן . . .
- (גור) אז זה באמת - אני חושב ש-Graduality זה המלך של כל ה-Design Patterns של Production
- ומתוך חמישה Retro-ים - בשלושה לפחות ה-Violation היה שמשהו קרה בצורה מיידית ואסור שיקרה בצורה מיידית . . .
- (אורי) או מיידית - או שהעלינו, לא שמנו לב שיש בעיה - והמשכנו הלאה . . .
- (גור) וזהו, והסיבה שזה צוות Architecture-י זה כי יכול להיות שהצוות יבוא ויגיד “למה בכלל יש לנו רכיב אחד שהוא Single Point of Failure במערכת, שמסוגל לייצר בעיה כזאת ל-Client-ים ולכל מיני מקומות?”
- אולי אנחנו צריכים בכלל להוריד אותו? אולי אנחנו צריכים לבזר אותו בצורה מטורפת?
- אולי אנחנו צריכים להעביר את האחריות ולבנות את תהליך האות’נטיקציה (Authentication) בצורה יותר אוטונומית?
- זו הסיבה שבעצם, כדי שה-Production יהיה יציב כל הזמן, אז הצוות המורחב צריך כל הזמן להתעסק “ב-Retro-ים הקטנים”
- כי התיקון הקטן של האירוע הוא לא מה שמעניין - מה שמעניין זה מה שינינו בעקבותיו.
(רן) כן, אז אני חושב, הנושא הזה שאתה מדבר עליו בחלק מהמקומות נקרא “מערכת חיסונית” - זאת אומרת, שכבות שנועדו לייצר מערכת שהיא יותר ויותר יציבה.
34:48 לא הגענו לדבר על מערכת חיסונית של חברה . . . .
(רן) הזמן שלנו כבר עוד מעט נגמר, ויש נושא אחר מעניין שלא נספיק להגיע אליו והוא איך מפתחים DNA של חברה, זאת אומרת - איך מפתחים “מערכת חיסונית” כזו בכוח האדם שלך - ככה שיהיה להם אכפת, ככה שהם גם ידעו איך לטפל, ידעו לכתוב קוד שהוא Resilient, ידעו להתייעץ עם הארכיטקט שהם חושבים שהם צריכים, שהארכיטקטים יהיו במקומות הנכונים וכו' . . . .
לצערי לא נספיק להיכנס גם לשם - אבל זה נושא שהוא חשוב.
(אורי) . . . שיודעים לבוא עם ה-State of Mind הנכון ל-Retro, ל-Take-ים . . .
(רן) נכון, נכון . . . כן, איך לא “סתם מוצאים את הש”ג''? איך לא סתם מוצאים את התקלה הקטנה, אלא יודעים להכליל ולבוא ולתקן סט יותר גדול של בעיות.
אז זה נושא שהוא מעניין - אבל לצערי זמננו תם.
35:34 כתוביות ועוד כמה מילים על Cato
(רן) אבל הייתה שיחה מרתקת, אז תודה רבה לך!
- (גור) תודה רבה לכם
(רן) וזהו, אולי בכל זאת עוד כמה מילים על Cato - איפה אתם נמצאים? מגייסים? דברים אחרים שהיית רוצה לספר?
- (גור) אז Cato נמצאת בתהליך של גידול מהיר
- גידול מהיר בכמות האנשים, גידול מהיר בגודל הרשת, גידול מהיר ב . . . .
- צמיחה, צמיחה - צמיחה בכל הפרמטרים.
- אנחנו מחפשים אנשים - אנחנו מחפשים אנשים שאכפת להם מ-Data, אכפת להם מ-Scale ואכפת להם מ-Mission-Critical Infrastructure.
- ואני חושב שבעיקר החברה מייצגת איזשהו מצב שמשתנה בעולם קצת - וזה שעד היום, החברות נתנו כל מיני “פתרונות”.
- והפתרונות היו צריכים לעבוד אחד עם השני וכן הלאה.
- והיום אנחנו חיים בעידן שבו כל הפתרונות מתכנסים יחד ל”סלים גדולים” ופלטפורמות, שבעצם מספקות שירותים מלאים.
- כמו שפעם היו המון שרתים והמון אפליקציות וכן הלאה, והיום יש AWS בתור כל הריכוז של ה-Compute וה-Networking הפנימי של רשת.
- העולם שלנו הוא עולם שהופך להיות עולם אחד - כל ה-Firewall-ים בעולם, כל ה-Router-ים בעולם, כל ה-Switch-ים בעולם, כל ציוד ה-Access בעולם, כל ה-VPN-ים - הכל יהפוך לדבר אחד.
- והאתגר הזה הוא אתגר שהוא בעצם מה ש-Cato עוסקת בו.
- (גור) Network ו-Security ביחד - ובעצם משהו שמכנס את כל הדרישות של IT של ארגון.
(רן) אוקיי, תודה רבה, נשמע כמו משהו גדול . . . בהצלחה! להתראות.
רפרנסים מומלצים נוספים -
האזנה נעימה ותודה רבה לעופר פורר על התמלול!
אין תגובות:
הוסף רשומת תגובה