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