המדריך המלא ל-שומר-התוצר, 'רץ' זה לא 'ייצר'
שכבת-השמירה שבודקת שכל עבודה מתוזמנת באמת ייצרה תוצר, לא רק 'רצה בהצלחה'
שומר-התוצר זה דפוס-בקרה (watchdog, 'כלב-שמירה' תוכנתי שמשגיח על תהליכים אחרים) שנולד מתובנה לא נעימה: הכשל הכי מסוכן במערכת אוטומטית הוא לא זה שצועק, אלא זה ששותק. עבודה מתוזמנת יכולה לרוץ כל יום, להסתיים בלי שום שגיאה, ולהיראות 'ירוקה' בכל לוג, ובפועל לא לייצר שום דבר: הגיבוי לא באמת מגבה, הדוח לא באמת נשלח, הקובץ לא באמת נכתב. שומר-התוצר סוגר בדיוק את החור הזה: הוא עובר בקצב קבוע על כל העבודות המתוזמנות ברשת ושואל שאלה אחת פשוטה, לא 'האם התהליך רץ?' אלא 'האם נוצר תוצר אמיתי?', קובץ שהתעדכן, רשומה שנכתבה, הודעה שנשלחה. אם עבודה 'רצה בהצלחה' אבל התוצר חסר, נשלחת התראה ישירה לטלפון. אצלי (אלעד) השומר משגיח על כל העבודות המתוזמנות של רשת-הסוכנים, והוא כבר הוכיח את עצמו בכך שתפס עבודות שנראו בריאות לגמרי בלי לייצר כלום. אצלכם, זה אותו עיקרון לכל אוטומציה שיש לכם: גיבויים, דוחות, סנכרונים. אם יש לכם תהליך מתוזמן אחד שחשוב לכם, מגיע לו שומר-תוצר.
מה המדריך מכסה
מה זה שומר-תוצר?
ה-watchdog שבודק את המדפים, לא את התנור
שומר-התוצר (output guardian) הוא תהליך-בקרה קטן שרץ בקצב קבוע ועובר על כל העבודות המתוזמנות במערכת. לכל עבודה מוגדר מראש מה התוצר שהיא אמורה לייצר ובאיזה חלון-זמן, קובץ-גיבוי מעודכן, דוח יומי שנשלח, רשומה שנכתבה למסד. השומר בודק את התוצר עצמו, לא את התהליך. אם עבודה רצה 'בהצלחה' אבל התוצר חסר או מיושן, זה בדיוק הכשל השקט שהוא נבנה לתפוס, והתראה יוצאת. הוא משלים את אימות-על-תוצאה של שכבת-האוטונומיה: האימות בודק משימה בודדת ברגע שהיא רצה, והשומר בודק את התמונה הכוללת לאורך זמן.
שלוש רמות-אמת, רץ, הצליח, ייצר
כל רמה תופסת כשלים שהקודמת מפספסת
כדי להבין למה שומר-תוצר הכרחי, צריך להבחין בין שלוש רמות-אמת שונות. רמה 1, 'רץ': התהליך הופעל והסתיים בלי לקרוס (exit code 0). רמה 2, 'הצליח': שלב-אימות בדק שהמשימה השיגה את היעד המיידי שלה (זה ה-verify-on-result של שכבת-האוטונומיה). רמה 3, 'ייצר': קיים תוצר מוחשי, עדכני ולא-ריק בעולם. רוב המערכות עוצרות ברמה 1. מערכות טובות מגיעות לרמה 2. אבל רק רמה 3 נותנת ביטחון אמיתי, כי היא בודקת את מה שבסוף באמת חשוב: התוצר.
סוגי-בדיקה, איך בודקים 'יש תוצר'
קובץ, רשומה, לוג, הודעה, לכל עבודה סוג-הבדיקה שלה
'תוצר' נראה אחרת בכל עבודה, ולכן שומר-תוצר טוב תומך בכמה סוגי-בדיקה פשוטים. המשותף לכולם: הם בודקים משהו מוחשי ואובייקטיבי, עם חלון-זמן (freshness, עד כמה התוצר 'טרי'). ההגדרה לכל עבודה היא שורה-שתיים בקובץ-תצורה: סוג-הבדיקה, איפה לבדוק, ומה חלון-הזמן המותר. זה כל מה שצריך כדי להפוך עבודה 'עיוורת' לעבודה מושגחת.
התראות, ישירות לטלפון, בלי להציף
התראה אמיתית כשיש פער, שקט מוחלט כשאין
שומר-תוצר שמציף אתכם בהתראות ייכנס להתעלמות תוך שבוע, ואז הוא חסר-ערך. לכן צד-ההתראות חשוב לא פחות מצד-הבדיקות: התראה יוצאת רק כשיש פער אמיתי ('רץ אבל לא ייצר'), היא מגיעה ישירות לטלפון של הבעלים דרך קאמי, והיא מכבדת שבתות וחגים ותקופת-צינון (cooldown), אותה תקלה לא תציק לכם שוב ושוב כל שעה. הפערים גם נרשמים לתיבת-קשב מרכזית, כך שהתדריך של לולאת-המנכ״ל יכול לרכז אותם בבוקר.
דוגמאות מהחיים, איפה זה תופס
גיבוי, דוח יומי, סריקה מתוזמנת, צינור-תוכן
הדרך הכי טובה להרגיש את הערך של שומר-תוצר היא דרך המקרים הקלאסיים שבהם הוא תופס כשל שאף שכבה אחרת לא הייתה תופסת. המשותף לכולם: תהליך שרץ 'בהצלחה' לאורך זמן, בלי אף שגיאה, ובלי לייצר את מה שהוא קיים בשבילו. אלה לא תרחישים תיאורטיים; אלה הדפוסים הכי נפוצים של כשל שקט בכל מערכת אוטומטית.
אינטגרציה, איך מאמצים שומר-תוצר אצלכם
מתחילים מעבודה אחת קריטית, מרחיבים בהדרגה
כמו בכל המדריכים, לא עוטפים את כל המערכת ביום הראשון. הסדר: בוחרים את העבודה שהכי כואב לגלות באיחור שנכשלה (כמעט תמיד: הגיבוי), מגדירים לה בדיקת-תוצר אחת, ומחברים התראה לטלפון. חיים עם זה שבוע, מכיילים את חלון-הזמן, ורק אז מוסיפים את שאר העבודות. שומר-התוצר משתלב ברשת הרחבה: הוא קורא מ-יומן-התוצאות, מדווח דרך קאמי, מזין את התדריך של לולאת-המנכ״ל, ומספק ל-אורורה חומר-גלם לזיהוי דפוסי-כשל.
