ניטור תקציב שגיאות: היכן נשבר המשוב
שגיאות בשירות קיימות תמיד — השאלה היא כמה מהן מותר. אם הגבול אינו נמדד, דנים באמינות השירות לפי תחושות: מהנדס אחד מחשיב כתקין כשל בכל אלף בקשות, אחר — נפילות בודדות. ויכוח על איכות מהדורה הופך לוויכוח על טעם.
מגבלת השגיאות של השירות סוגרת בדיוק את החור הזה. היא מגדירה את שיעור הבקשות שמותר לאבד או לקלקל בתקופה, והופכת אותו ליתרה: כל עוד התקציב לא נוצל, מהדורות יוצאות בקצב גבוה; כשההיתרה אפס, עוצרים שינויים ומבררים את סיבות הכשלים. ההחלטה מפסיקה להיות תלויה בכוח המיקוח של המשתתפים.
זה נשבר במטריקות מפוזרות. תדירות השגיאות חיה בלוח מחוונים אחד, השהיות — בשני, אי-זמינות — בשלישי, ואף אחד לא מנהל חשבון כולל. ניטור תקציב שגיאות מחייב איחוד של המקורות האלה לכמות אחת — אחרת התקציב נראה בריא, והמשתמשים עוזבים מדפים איטיים שבהם פורמלית לא היו כשלים.
הכשל השני — התראות סף שהוגדרו לפי אינטואיציה ישנה. סף שמגיב לכל תנודה מבטל את ערך התורנות: המהנדס מתרגל לסגור התראה בלי להסתכל, והתקלה האמיתית הולכת לאיבוד ברעש. התראה צריכה להישען על קצב שריפת התקציב, לא על מספר סטטי.
נפרק כיצד לבנות משוב כזה ב-Prometheus וב-Grafana: מתיאום רמת היעד ועד כללים שעצמם עוצרים מהדורה.
מה נותנת מגבלת שגיאות מנוהלת בשירות
מגבלת השגיאות נגזרת מרמת היעד של זמינות: לשירות מותר לבזבז שיעור מסוים של בקשות כושלות בחלון התצפית, והיתרה הזו הופכת למונה משותף לפיתוח ולתפעול. כל עוד המלאי חיובי, מהדורות יוצאות בקצב רגיל; כשהוא מתמעט, השינויים מתחילים להתחרות על הזכות לעלות לאוויר.
התראות אינן נקשרות לתנודות בודדות, אלא לקצב ניצול היתרה, ולכן כשל קצר אינו מעיר את התורן, ואילו ירידה מתמשכת מאותתת לפני שהשירות יורד מתחת לרמת היעד.
שיעור התראות השווא יורד, וזמן התגובה לכשל מפסיק להיות תחושה והופך לכמות: רואים כמה זמן עובר מהסטייה הראשונה עד ההתערבות ובאיזה שלב מאבדים הכי הרבה.
גם תור המהדורות כפוף לכלל: כשהמגבלה נוצלה, קודם משחזרים אמינות ורק אחר כך מגלגלים פונקציונליות. כך נעלם סוג של כשלים שנבע בעבר מהצטברות של ירידות קטנות שלא הבחינו בהן — כל אחת בנפרד מתחת לסף, וביחד הן מוציאות את השירות מרמת היעד.
התוצאה נמדדת בשיעורים: ירידה בשיעור הבקשות הכושלות, צמצום בבדיקות ידניות, פחות התראות שנסגרות בלי פעולה. חישוב היתרה וקצב שריפתה חי ב-Prometheus ומוצג על לוח משותף — המהנדסים רואים את המלאי בשעות ודנים בהחלטות, לא בשאלה "האם רע עכשיו".
מצבי חישוב: חלון, קצב וקפדנות
מצב החישוב קובע עד כמה מהר המערכת מבחינה בירידה וכיצד מתפרשת יתרת התקציב. ב-Prometheus התקציב מחושב בכלל רישום מעל מוני תשובות מוצלחות ושגויות, והפאנל ב-Grafana רק מציג את הערך שכבר חושב — לכן קפדנות האות נקבעת כאן, ולא בלוח המחוונים.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| חלון נע | זרם בקשות רציף, צריך לזהות ירידה בתוך דקות | תנודה קצרה שורפת את התקציב; התוצאה תלויה בעומק שמירת המטריקות |
| תקופה קלנדרית | דיווח ותכנון: חודש או רבעון עם איפוס | בתחילת התקופה התקציב תמיד מלא, שגיאות של השעות הראשונות נשכחות |
| תקציב לפי בקשות | שירותים שבהם חשוב שיעור התשובות המוצלחות | לא רואה תשובות איטיות אם הן הסתיימו פורמלית בהצלחה |
| תקציב לפי זמן | הפעלות משתמש, זמינות לפי מרווחי דקות | דורש צבירה מדויקת של מרווחים, רגיש לקטיעות קצרות |
| מגבלה מאוחדת למספר שירותים | תקציב פלטפורמה משותף ותעדוף בין צוותים | שירות אחד יכול לאכול את התקציב של שכניו — יש צורך בכללי פיצול ומכסות |
בפועל משלבים בין המצבים: חלון נע נותן אות תפעולי לתורן, תקופה קלנדרית — בסיס לניתוח תוצאות, ומגבלה מאוחדת מרסנת את ההוצאה הכוללת.
פער בין תקציב לפי בקשות ולפי זמן הוא אינדיקטור טוב: שיעור השגיאות תקין, אבל המשתמשים מתלוננים על אי-זמינות, כלומר הבעיה היא בזמני המתנה ובניסיונות חוזרים, ולא בקודי התשובה.
הטמעה: מביקורת מטריקות ועד תקנון ניטור
העבודה מתנהלת בשישה שלבים ומתחילה לא בגרפים, אלא במלאי של מה שכבר נאסף. הסדר עקרוני: תקציב שגיאות מחושב מאותם נתונים שלפיהם פועלות ההתראות, אחרת התורן רואה פער בין הפאנל לאות ומפסיק לתת אמון בשני המספרים.
- ביקורת מטריקות. מפרקים את המקורות: אילו מדדים כבר קיימים, היכן הפערים, אילו משכפלים זה את זה, היכן הקרדינליות גדלה מהר יותר מהתועלת. בפלט — רשימת SLI עובדים לכל שירות ורשימה של מה שצריך להוסיף.
- סכימת חישוב. קובעים חלון (30 ימים נעים), רמת זמינות יעד, הגדרה של אירוע "רע" וכללי צבירה לפי שירותים. הצבירות מחושבות מראש, ולא בכל בקשה של הפאנל, — אחרת לוח מחוונים עם עשרה שירותים מתחיל לגמגם ומשקר בזמן.
- כללים וספים. מגדירים התראות רב-שלביות: אזהרה כשנשרף רבע מהתקציב, התראה — בחצי, עצירת מהדורות — בניצול מלא. סף על קצב השריפה תופס כישלון מהיר לפני שגרף יומי יראה אותו.
- בדיקה על נתונים היסטוריים. מריצים את הסכימה על תקלות קודמות: האם האותות היו נתפסים, כמה היו שווא, האם הספים תאמו לירידה אמיתית. כיול הספים נעשה לפי המציאות, לא לפי אינטואיציה.
- תקנון תורנות. מתארים פעולות בכל רמה: את מי להעיר, מה לבדוק קודם, מתי להקפיא את העלייה לאוויר. את התקנון מתאמים עם אלה שבתורנות, — מסמך שנכתב בלעדיהם לא עובד.
- העברה והדרכה. מנתחים עם הצוות תרחישים חיים, ומסכמים על ניתוח של כל הפעלה. לאחר מכן הסכימה חיה מעצמה: כללים וספים נבחנים מחדש בסוף הרבעון.
מה נשאר במאגר לאחר מסירת העבודה
לאחר מסירת העבודה נשאר לכם מעגל בקרה עובד על אמינות, ולא אוסף של הגדרות מפוזרות. כל הארטיפקטים נמצאים במאגר ובסביבה שלכם: הצוות יכול לפתוח כל אחד מהם, לראות מאיפה מגיע כל מספר, ולשנות את התנהגות המערכת בלעדינו.
- קונפיגורציות של כללים — מקורות רישום מטריקות וביטויים מחושבים לתקציב שגיאות, מסודרים לפי שירותים וסביבות, עם ניהול גרסאות ושמות משמעותיים.
- סכימת חישוב — מסמך שמתעד אילו אירועים נחשבים לכשל, כיצד הם מנורמלים לנפח הבקשות הכולל ובאיזה חלון הם ממוצעים. בזמן ניתוח תקלה אין צורך לנחש את הלוגיקה.
- מדיניות התראות — ספים, קיבוץ ומסלולים: מה עובר לתורן מיד, מה ממתין לאישור, מה נכנס רק לדוח.
- הוראות לתורן — ניתוח צעד-אחר-צעד: כיצד לקרוא את גרף שריפת התקציב, אילו החלטות לקבל בקצבי הוצאה שונים, לאן להסלים ומה לתעד לאחר מכן.
- תקנון לבחינה מחדש של רמות — תדירות וקריטריונים: מתי מחמירים את יעד האמינות, מתי מקלים, מי מחליט וכיצד זה מתועד בהיסטוריה.
- תבניות לוחות מחוונים — פאנלים לשירות בודד וסיכום לכולם, עם אותה לוגיקת חישוב, כדי שצוות חדש לא יצייר גרסה משלו מאפס.
- בדיקות לכללים — מערכת טסטים שתופסת ביטויים שבורים ודגימות ריקות לפני העלייה לאוויר, ולא ברגע התקלה.
מקרה בוחן: שירות תשלומים, התראות וזמן תגובה
שירות תשלומים עם זרם עסקאות רציף: כמה תורנים במשמרת, כל ההתראות נופלות לערוץ משותף אחד, ואף אחד לא חישב תקציב שגיאות. כללי ההתראות הוגדרו לפי ספים "בעין" ולא נבחנו מחדש — האותות התרבו, והאמון בהם פחת.
מה היה
יותר ממחצית ההפעלות נסגרו כשווא: תנודה קצרה של השהיה, שגיאות בודדות במופע אחד, רעש ממשימות רקע. משמרת התורנות הלכה לבדיקות ידניות — 5-6 במשמרת, מהן מועילות בודדות. זמן הגילוי נמדד בעשרות דקות: כשל אמיתי טבע בזרם השווא, וחלק מהכשלים צפו רק לפניית לקוחות.
מה שינו
קשרנו את ההתראות לתקציב שגיאות: עבור API תשלומים קבענו יעדים לזמינות ולזמן תגובה, והאות מחושב כעת לפי קצב ניצול התקציב בחלון, ולא לפי תנודה בודדת. הפרדנו את ההתראות לשני סוגים — אלה שמעירים את התורן ואלה שמטפלים בהן בשעות העבודה. איסוף המטריקות וכללי ההתראות הועברו ל-Prometheus ול-Grafana, כל אות לילי מנותח במשמרת התורנות.
| מדד | לפני | אחרי |
|---|---|---|
| שיעור התראות שווא | ~70% | ~15% |
| זמן גילוי | עשרות דקות | 2-4 דקות |
| כשלים שהוחמצו | נמצאו לפי תלונות | בודדים ברבעון |
| בדיקות ידניות במשמרת | 5-6 | 1-2 |
אפקט נפרד — יכולת הניבוי של המשמרת: התורן יודע שאות לילי משמעו הוצאת תקציב אמיתית, לא רעש. כשלים החלו להימצא לפני פניות לקוחות, וניתוח הפעלה הפך לפרוצדורה קצרה במקום חקירה.
במה SLO שונה מ-SLA ומה להגדיר קודם?
ההבדל פשוט, אבל דווקא אותו מבלבלים יותר מכל השאר. SLA — התחייבות כלפי הלקוח: קבועה בחוזה, בעלת ניסוח מדיד והשלכות מוגדרות להפרה. SLO — רמת יעד פנימית שלפיה הצוות מקבל החלטות על מהדורות ותעדוף.
סדר ההגדרה אחד: קודם יעדים פנימיים, אחר כך חוזיים. SLO נקבעים מחמירים יותר מ-SLA, כדי שביניהם יישאר מרווח — סטיות נבלעות בתוך הצוות ולא הופכות להפרת התחייבויות. סדר הפוך נותן הבטחה בלי נתונים: לא ברור איזה מרווח באמת קיים והאם התשתית תעמוד בו.
תקציב שגיאות — ביטוי כמותי של SLO: כמה אי-זמינות או שיעור בקשות כושלות מותר לבזבז בחלון. כל עוד התקציב שלם, מהדורות יוצאות בקצב רגיל; התקציב התקרב לגבול — סדר העדיפויות עובר לאמינות.
ב-Prometheus אלה כללי חישוב של בקשות מוצלחות ושל יתרת התקציב, ב-Grafana — פאנל הוצאה והתראות על קצב שריפה, לא על כשל בודד.
גם ההשלכות של הפרה שונות, ואסור לערבב ביניהן. הפרת SLO — אירוע פנימי: עצירת מהדורות, החזרת המאמץ לאמינות, בחינה מחדש של יעד לא ריאלי. הפרת SLA — אירוע חיצוני: התחייבויות וכל מה שמעוגן בהן. לכן קודם מודדים את עצמנו, ורק אחר כך מבטיחים.
ספקות טכניים נפוצים לפני הטמעה
ספקות לפני הטמעת תקציב שגיאות נוגעים בדרך כלל לא בכלי, אלא בשאלה עד כמה הנתונים משקפים ביושר את מציאות השירות. להלן מצבים נפוצים במיוחד, וכיצד אנחנו סוגרים אותם בעת הגדרת הבקרה ב-Prometheus וב-Grafana.
חלק מהמטריקות מגיעות בהפסקות — החישוב יהיה נמוך מדי?
את התקציב מחשבים לפי החלונות שבהם יש נתונים, ואת החסרים מסמנים בסימן נפרד ולא מקפלים אותם ל"אפס שגיאות". אם מרווח שלם נפל, הוא מוצא מהמכנה — אחרת הזמינות בדוח נראית טוב יותר ממה שהמשתמשים ראו.
המדד רועש: התנודות לא קשורות לכשלים אמיתיים?
רעש מדכאים לא בסף "בעין", אלא ברמת הגדרת המדד: מסירים בדיקות שירות, תשובות טכניות ובקשות פנימיות בין שירותים, ומצברים על חלון שעובר תנודה בודדת. אז הוצאת התקציב משקפת אובדן למשתמשים, לא פעילות רקע.
בשירות משתמשות כמה צוותים — של מי התקציב?
את התקציב מקשרים לבעלים של השירות, אבל את ההוצאה מסמנים לפי צרכנים: כל צוות רואה את חלקו בשריפה. הוויכוח "מי הוריד את הזמינות" נפתר לפי נתונים, לא בפגישה משותפת.
הספים הוגדרו פורמלית — הבקרה תהפוך לדיווח?
את הרמות לוקחים מהתנהגות בפועל של השירות בתקופה הקודמת, לא מהרצוי. בוחנים אותן מחדש לפי לוח זמנים — אחרי שינויים גדולים בארכיטקטורה או כשהתקציב כלל לא מתכלה באופן יציב.
נדון במשימה שלכם ונחזור עם תוכנית עבודה
כדי שההערכה תהיה עניינית ולא "בעין", אנחנו צריכים ניתוח קצר של התשתית שלכם: כיצד נאספות המטריקות, היכן הן נשמרות, מי וכיצד מגיב להפעלות. תארו את המשימה בצורה חופשית — נחזור עם הערכת היקף ותוכנית עבודה מפוצלת לשלבים.
מה מבהירים בשיחה:
- מקורות המטריקות וסכימת האיסוף הנוכחית — Prometheus, יצואנים, סוכנים על צמתים;
- רשימת שירותים והבעלים שלהם: עבור מי מחשבים תקציב שגיאות ולפי אילו SLI;
- חלונות ומדיניות חישוב: חלון נע, ספי שריפה, מה נחשב לאי-זמינות;
- התראות ותורנויות נוכחיות — אילו הפעלות רועשות, אילו מוחמצות;
- הרשאות ומגבלות: סביבות, רשתות סגורות, זכויות לשינוי כללים ולוחות מחוונים;
- דרישות לדיווח — סיכומים להנהלה, תדירות, עומק היסטוריה;
- פורמט מסירה: מאגר עם קונפיגורציה, runbook, הדרכת משמרת תורנות.
בסיום מתעדים הרכב צוות למשימה — מי אחראי לכללי רישום, מי ללוחות מחוונים והתראות, מי להעברת ידע. את התוכנית מתאמים לפני ההתחלה, כדי שתראו תוצאות ביניים בכל שלב, ולא רק דוח סופי.
ספרו לנו מה כואב עכשיו: התראות רועשות, היעדר תקציב לאמינות או לוחות מחוונים מפוזרים. זה מספיק כדי שנחזור עם תוכנית והערכה.