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

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

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 - קביעת גייטים כגון קוד ריוויו, וולדיציות, יצירת רליס, פריסה וכו'.

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

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

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

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