Error Budget Architecture: איך בונים משטר SLO שמאזן בין יציבות למהירות שחרור

מאת צוות מדיה דיל · 01.08.2026 · DevOps · 7 דק׳

מדריך מעמיק ל-Error Budget Architecture — איך מתרגמים SLO ל-Error Budget מעשי, בונים burn-rate alerts, ומחברים את זה למדיניות שחרורים אוטומטית שעוצרת דיפלוימנטים כשצריך.

הבעיה: ריב בין Product ל-Engineering שאף אחד לא צריך

בכל חברת SaaS שגדלה מעבר לצוות אחד יש את אותו דיון חוזר: צד המוצר רוצה לשחרר פיצ'רים מהר, וצד ה-Infra רוצה לעצור הכול כדי "לייצב את המערכת". בלי מנגנון מדיד, הדיון הזה מוכרע לפי מי צועק חזק יותר באותו שבוע, לא לפי דאטה. Error Budget הוא הפתרון ההנדסי לבעיה הפוליטית הזו: הוא הופך "כמה יציבות מספיק יציבות" למספר אחד מוסכם מראש, ואז נותן לכל הצדדים לקבל החלטות אוטונומיות סביבו.

הרעיון מגיע מ-Google SRE, אבל מימוש שלו כארכיטקטורה בפרודקשן — עם pipelines, alerting ומדיניות אכיפה — הוא משהו שרוב הצוותים עדיין עושים בצורה חלקית או ידנית. במאמר הזה נפרק את זה לרכיבים אמיתיים: איך בוחרים SLI, איך מתרגמים SLO ל-budget, איך בונים burn-rate alerting שלא מציף אתכם ב-false positives, ואיך מחברים הכול ל-CI/CD כך שהמדיניות אוכפת את עצמה.

מהו Error Budget בפועל, לא בסלייד

SLO (Service Level Objective) הוא יעד מדיד, למשל "99.9% מהבקשות ל-API יחזירו תשובה תוך פחות מ-300ms תוך 30 יום". ה-0.1% הנותרים הם ה-Error Budget שלכם — כמות הכשל שהמערכת מותרת לה לצבור בלי להפר את ההבטחה לעסק. אם ב-30 יום יש כ-2.6 מיליון בקשות, ה-budget הוא כ-2,600 בקשות כושלות. זה נשמע מופשט, אבל ברגע שהוא מתורגם למספר קונקרטי — הוא הופך לכלי ניהול אמיתי: אפשר לצרוך אותו מהר (release אגרסיבי) או לאט (release שמרני), אבל ברגע שהוא אפס, יש מדיניות ברורה מה קורה.

ההבדל בין Error Budget לבין "פשוט לנטר uptime" הוא שה-budget הוא consumable. הוא לא רק מספר סטטי בדשבורד — הוא input לתהליך קבלת החלטות. צוות ש"שרף" 80% מה-budget שלו ב-10 הימים הראשונים של החודש נמצא במצב שונה לגמרי מצוות שצרך 5% באותו זמן, גם אם שניהם עדיין "בתוך ה-SLO".

ארכיטקטורה: מ-SLI גולמי ועד להחלטת דיפלוי

מימוש מלא של Error Budget Architecture מורכב מכמה שכבות שצריכות לדבר אחת עם השנייה:

שכבת מדידה (SLI collection) — metrics ברמת ה-request, בדרך כלל דרך Prometheus, Datadog או OpenTelemetry, שמסווגים כל בקשה כ-good/bad event לפי latency ו-status code.
שכבת חישוב (SLO engine) — כלי כמו Sloth, Nobl9 או dashboards מבוססי PromQL שמחשבים burn rate בזמן אמת מול חלון היעד (rolling 28/30 יום, לרוב עם multi-window).
שכבת התרעה (burn-rate alerting) — לא alert בודד, אלא כמה policies במקביל שמזהים שריפה מהירה מול שריפה איטית.
שכבת אכיפה (policy gate) — hook ב-CI/CD (למשל GitHub Actions, ArgoCD) שבודק את מצב ה-budget לפני שהוא מאשר merge לפרודקשן או freeze אוטומטי.

השכבה האחרונה היא זו שרוב הארגונים מדלגים עליה, וזה בדיוק המקום שבו כל הערך האמיתי טמון — כי בלעדיה, Error Budget הוא רק דשבורד יפה שאף אחד לא פועל לפיו.

Multi-Window, Multi-Burn-Rate: הדרך הנכונה להתריע

alert נאיבי כמו "אם success rate נופל מתחת ל-99.9% תריע" יוצר שתי בעיות: התרעות שווא על ספייק קצר של 2 דקות, והתרעה מאוחרת מדי על דליפה איטית שנמשכת ימים. הפתרון הסטנדרטי בתעשייה (מבוסס על Google SRE Workbook) הוא multi-window multi-burn-rate alerting: מגדירים כמה thresholds במקביל, כל אחד עם חלון זמן וקצב שריפה שונה.

// דוגמה עקרונית ל-2 policies במקביל
- alert: FastBurn
  window: 1h + 5m
  burn_rate: 14.4   // ישרוף 2% מה-budget החודשי תוך שעה
  severity: page

- alert: SlowBurn
  window: 6h + 30m
  burn_rate: 6       // ישרוף 5% מה-budget תוך יממה
  severity: ticket

ה"חלון הכפול" (למשל 1h + 5m) הוא טריק חשוב: הוא דורש שגם החלון הארוך וגם חלון קצר-טרי יראו את אותה חריגה, כדי שההתרעה לא תישאר "תקועה" גם אחרי שהבעיה כבר נפתרה. זו נקודה שרוב המימושים הראשונים מפספסים ומגלים רק אחרי שבועיים של alert fatigue.

חיבור ל-CI/CD: מדיניות אכיפה אוטומטית

ברגע שיש engine שמחשב burn rate בזמן אמת, אפשר לחשוף endpoint פשוט (או Prometheus query) שמחזיר "כמה budget נשאר" ולהשתמש בו כ-gate. המדיניות הנפוצה:

budget מעל 20% — deploy pipeline רץ כרגיל, ללא הגבלות.
budget בין 5%-20% — release רק עם approval נוסף (canary חובה, לא deploy ישיר).
budget מתחת ל-5% או שלילי — freeze אוטומטי על כל release שאינו bug fix, עד שה-budget מתחדש או שמתקבלת החלטה מפורשת של Engineering Lead לחרוג ממנה.

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

Trade-offs שחייבים להכריע עליהם מראש

בחירת חלון הזמן (28 יום מול 30 יום קלנדרי) משפיעה על כמה "זיכרון" יש למערכת לתקריות עבר — חלון rolling מוחק תקריות ישנות בהדרגה, חלון קלנדרי מאפס בבת אחת בתחילת החודש ויכול ליצור אפקט "budget מלא פתאום" שמעודד release אגרסיבי בתחילת כל חודש. רוב הצוותים הבשלים בוחרים rolling window כדי למנוע את התופעה הזו.

בחירה שנייה קריטית היא מי בעל ה-SLO. אם ה-SLO נקבע חד-צדדית על ידי Infra, הוא ייתפס כמכשול בירוקרטי. SLO טוב הוא הסכם בין Product ל-Engineering — לרוב עם Error Budget רופף יותר לפיצ'רים ניסיוניים (99% ולא 99.9%) ומחמיר יותר לזרימות תשלום או auth.

Error Budget Policy: מה קורה בפועל כשה-Budget נגמר

הרכיב שהופך את כל המנגנון ממתמטיקה למדיניות ארגונית אמיתית הוא מסמך ה-Error Budget Policy — מסמך קצר ומוסכם מראש (לא באוויר, אלא חתום על ידי Engineering ו-Product יחד) שמגדיר בדיוק מה קורה בכל רמת צריכה. מסמך טוב עונה מראש על שאלות כמו: מי מוסמך לאשר release חריג כשה-budget שלילי? האם יש הבחנה בין release שמתקן bug (מותר גם עם budget שלילי) לבין release שמוסיף פיצ'ר (אסור)? האם freeze חל על כל הצוותים או רק על הצוות שה-SLO שלו הופר?

נקודה חשובה נוספת שכדאי להכניס למדיניות: escalation path אם budget ממשיך להישרף גם אחרי freeze — זה סימן שהבעיה אינה "עוד release אחד גרוע" אלא בעיה מבנית עמוקה יותר (ארכיטקטורה, תשתית, או תהליך QA) שדורשת תשומת לב הנהלה בכירה, לא רק עוד sprint של תיקוני באגים.

טעויות נפוצות בפרודקשן

SLO גלובלי מדי — SLO אחד ל"כל המערכת" מסתיר בעיות ב-endpoint ספציפי קריטי. הפתרון: SLO פר user journey (login, checkout, search) ולא פר שירות טכני.
אין consumer ל-budget — חישוב יפה ב-Grafana שאף אחד לא מחובר אליו מבחינת תהליך. אם freeze לא קורה אוטומטית, הוא לא יקרה.
בלבול בין SLA ל-SLO — SLA הוא ההתחייבות המשפטית/חוזית ללקוח, לרוב עם קנסות. SLO צריך להיות מחמיר יותר מ-SLA (למשל SLA 99.5%, SLO פנימי 99.9%) כדי שיהיה buffer לתגובה לפני שמפרים חוזה.
burn-rate alert יחיד — כפי שהוסבר למעלה, זה מייצר או alert fatigue או תגובה מאוחרת מדי.

Error Budget כשפה משותפת בין הנדסה למוצר

מעבר לכל ההיבטים הטכניים, הערך העמוק ביותר של Error Budget Architecture הוא תרבותי: הוא נותן להנדסה ולמוצר שפה משותפת לדבר על סיכון. במקום שהנדסה תגיד "לא בטוח שזה יציב" (סובייקטיבי, קשה להתווכח איתו אבל גם קשה לפעול לפיו) והמוצר יגיד "אנחנו חייבים לשחרר את זה השבוע" (גם הוא סובייקטיבי), שני הצדדים יכולים להסתכל על אותו מספר — "יש לנו 15% budget נשאר החודש" — ולקבל החלטה משותפת מבוססת עובדות. זה לא מבטל ויכוחים לגמרי, אבל הוא מעביר אותם מוויכוח על תחושות לוויכוח על עדיפויות, שהוא ויכוח הרבה יותר פרודוקטיבי.

ארגונים שמטמיעים את זה בהצלחה משלבים סקירת Error Budget כחלק קבוע מה-sprint planning או מפגש ה-roadmap הרבעוני, לא רק כדשבורד שמסתכלים עליו כשמשהו כבר נשבר. זה הופך את הנושא ממנגנון תגובתי (מה עושים אחרי שקרה כשל) למנגנון פרואקטיבי (איך מתכננים release קדימה בהתחשב בסיכון שנותר).

מתי כן ומתי לא כדאי להשקיע בזה

Error Budget Architecture מחזיר את עצמו במערכות עם קצב שחרור גבוה (כמה deploys ביום) ובסיס משתמשים שרגיש לדאונטיים — כלומר רוב מוצרי ה-SaaS ב-B2B וב-B2C. במערכות פנימיות עם תעבורה נמוכה, או במוצרים בשלב MVP לפני product-market fit, ההשקעה בתשתית הזו מוקדמת מדי — עדיף להתמקד קודם בלמדוד בכלל SLI בסיסיים, ורק אחר כך לבנות אכיפה אוטומטית סביבם.

בפרויקטים שאנחנו מלווים במדיה דיל אנחנו בדרך כלל ממליצים על גישה הדרגתית: חודש ראשון — רק מדידה ודשבורד, בלי אכיפה. חודש שני — burn-rate alerting לצוות בלבד. רק בחודש השלישי, אחרי שיש אמון בנתונים, מחברים gate אמיתי ל-CI/CD.

מדידת SLI נכונה: איפה נמדד ה-Good/Bad Event

שאלה שנשמעת טכנית זניחה אבל בפועל קובעת אם ה-SLO שלכם משקף מציאות: איפה נמדד ה-SLI. מדידה בצד השרת (server-side) תופסת רק בקשות שהגיעו לשרת בכלל — אם ה-load balancer עצמו נופל, או אם יש בעיית DNS, המדידה הזו "עיוורת" לגמרי לכשל שהמשתמש חווה בפועל. מדידה בצד הלקוח (client-side, Real User Monitoring) משקפת את החוויה האמיתית, כולל בעיות רשת, CDN, ו-DNS — אבל מוסיפה מורכבות איסוף (SDK בצד ה-frontend, סינון bot traffic, טיפול ב-outliers של רשתות סלולריות איטיות). ארגונים בוגרים משלבים את שניהם: SLI צד-שרת ל-latency ולוגיקה עסקית, SLI צד-לקוח (RUM) ל-SLO שמייצג את "מה שהמשתמש באמת חווה", ומדווחים אותם בנפרד כי הם עונים על שאלות שונות.

נקודה נוספת שקל לפספס: הגדרת "good event" חייבת לכלול את כל שרשרת התלויות הרלוונטית, לא רק status code. בקשה שמחזירה 200 אבל עם payload ריק או שגוי (למשל בגלל timeout פנימי ב-microservice אחד מתוך שרשרת קריאות) היא כשל אמיתי מבחינת המשתמש, גם אם ה-HTTP status "מצליח" טכנית. SLI טוב בודק תוכן תגובה, לא רק קוד סטטוס.

סיכום

Error Budget Architecture לא נועד להאט אתכם — הוא נועד להחליף ויכוחים סובייקטיביים בהחלטות מבוססות דאטה. ההשקעה האמיתית היא לא בחישוב המתמטי (זה הפשוט), אלא בבניית התהליך שמסביבו: מי מחזיק את ה-SLO, איך burn rate מתורגם להתרעה שלא מציפה, ואיך המדיניות נאכפת אוטומטית בלי צורך בישיבת חירום כל פעם.

תגיות: Error Budget · SLO · SLI · SRE · burn rate · CI/CD · Reliability Engineering

← חזרה לבלוג · צור קשר