אני רואה שעברת לפה באופן קבוע :)

האמת אני כמוך, נכנסתי בגלל שהמקור לא עבד 🙂

אז כולם פה עכשיו?

מסגרות הלימודים להיום:
בת 11.5 במכללה שמארחת את שכבה ו
בת 9 (ד') בזום בבית
בת 6 בבית ספר אחר בשכונה שמארח את שכבה א

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

fear and loathing in las twitteras

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

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

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

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

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

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

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

²סוג הכישלון ה-1 הוא כישלון בתשתית. בתור משתמש ,כאשר אני מריץ את הקוד או התהליך יש דברים שאני מצפה שיעבדו. אני מצפה שיהיה חשמל, רשת תקינה, חומרה תקינה, שיהיו לי הרשאות מתאימות, ושכל שירותי צד 3 יעבדו כפי שצריך.

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

החלק האחרון מדבר על ניהול תצורה ואיפה נשמרת הקונפיגורציה (בברנצ', בבינארי או בשירות חיצוני).

בהמשך הפרק מדבר על תהליך הבילד והדיפלוי בגוגל. התהליך מורכב מבילד עם blaze ( המוכר כbazel בגרסת ה OS), עבודה מול ברנצ' ראשי ויצירת ברנצ' לכל רליס, טסטים עבור כל שינוי, אריזת התוצרים באמצעות midas, שימוש בrapid לניהול כל התהליך (בדומה לג'נקינס או כלי CI/CD אחרים) ודיפלויימנט עם רפאיד או Sisyphus.

hermetic builds - תוצר הבילד חייב להיות עקבי עבור revision מסוים, enforcement of policies and procedures - קביעת גייטים כגון קוד ריוויו, וולדיציות, יצירת רליס, פריסה וכו'.

פרק 8 - Release Engineering
הפרק מתחיל בהלסביר מה עושים מהנדסי רליס (כלים ופרקטיקות לרליסים יציבים ועקביים) והעקרונות של התחום: self service - לתת למפתחים את הכח לעשות דברים בעצמם, high velocity - שחרור מהיר ככל האפשר של פיצ'רים לפרודקשן, >

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

בהמשך מתוארים בפרק מספר use cases של שימוש באוטומציה בגוגל: אוטומציה למיגרציה של mysql לבורג (k8s), יצירה של קלאסטרים חדשים והפיתוח של בורג.

פרק 7 - The Evolution of automation in google
הפרק מתחיל בתיאור של הערך מאוטומציה באופן כללי - עקביות, בניית פלטפורמה, פעולות ותיקונים מהירים וחסכון בזמן. לאחר מכן מציין סיבות נוספות ספציפיות לגוגל כמו הסקייל וסביבת פרודקשן המסובכת אבל אחידה.

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

פרק 6 - Monitoring Distributed Systems
הפרק מתחיל עם הגדרות, מה זה מוניטורינג ואיזה סוגים יש, מה זה דשבורד, alert, ו root cause. למה בכלל צריך לנטר ומה לצפות ממערכת ניטור. הפרק מציג את "4 סימני הזהב" שכדאי להשתמש בהם כאשר מתחילים לנטר - latency, traffic, errors ו saturation.

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

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

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

בהמשך מוסבר איך לבחור יעדים - להיות ספציפי לגבי איך מודדים ולגבי תנאי המדידה, כמו כן להיות ראלים ולא לשים יעדים לא הגיונים - למשל לא להתעקש על עמידה בSLO 100% מהזמן (כאן גם מוזכר שוב ה error budget מהפרק הקודם).

לאחר מכן מתאר איך לבחור SLIs מתאימים (זמן תגובה, כמות שגיאות, כמות תגובות כמות נתונים שניתן לעבד, זמן עיבוד ועוד) לפי סוג המערכת (user facing, storage, big data) ואיך כדאי להציג את המטריקות האלו (שימוש באחוזונים ולא בממוצע).

פרק 4 - Service Level Objectives הפרק מתחיל בטרמינולוגיה - מה הם SLI - מדידה של מטריקה מסוימת שנבחרה בקפידה; SLO - ערך המטרה של אותה המטריקה (גבול עליון, תחתון או שניהם); ו SLA - הסכם לגבי ההשלכות של חריגה מה SLO.