Runbooks – SLO Incidents

תמצית. קצר, תכל’ס, בעברית פשוטה.

HighErrorRate

  • בדוק Grafana: פאנל Error Rate.

  • בדוק פריסות אחרונות. אם נפרס – שקול rollback מהיר.

  • בדוק תלויות חיצוניות (DB/Redis/חיבורים) ושגרות רקע.

  • אם חריג זמני – עקוב 10 דק« והפעל rate‑limit עדין אם צריך.

PromQL לדוגמה:

sum(rate(http_requests_total{status=~"5.."}[5m]))
  /
sum(rate(http_requests_total[5m]))

SLOAvailabilityBreach (זמינות < 99.9%)

  • בדוק ב‑Grafana זמינות מול תקלות 5xx.

  • סקור לוגים לפי trace_id; חפש דפוס אחיד (endpoint ספציפי?).

  • עקוף רכיב חולה (feature flag או ניתוק זמני) והורד עומס.

  • פתח Incident אם נמשך > 30 דק«.

מדד זמינות משוער (על בסיס מונים סטנדרטיים):

(1 - (sum(rate(http_requests_total{status=~"5.."}[5m]))
      / sum(rate(http_requests_total[5m])))) * 100

SLOLatencyP95Breach (P95 > 0.5s)

  • בדוק פאנל Latency P95 והיסטוגרמות endpoint.

  • זהה צוואר בקבוק (DB/IO/חיצוני) דרך traces.

  • פרוס cache/עלות חישובית מופחתת/הגדל משאבים זמנית.

  • כתוב ממצא קצר ברנבוק בסיום.

PromQL לדוגמה (Histogram):

histogram_quantile(0.95,
  sum(rate(http_request_duration_seconds_bucket[5m])) by (le, endpoint))

תקלת התחברות ל‑DB (MongoDB) – קריטי

מכסה שגיאות נפוצות: ReplicaSetNoPrimary, No replica set members, SSL handshake failed, OperationCancelled

חומרה: 🔴 קריטית (הבוט מושבת חלקית/מלא בפעולות שדורשות DB)

סימפטומים

  • התראות/Issues ב‑Sentry סביב MongoDB/pymongo.

  • פקודות שדורשות שמירה/שליפה לא עובדות (למשל /stats, רישום משתמש).

  • זמן תגובה קופץ, או הרבה 5xx סביב פעולות DB.

סדר פעולות (בקצרה)

  1. בדיקת ספק (Atlas Status): אם יש תקלה אצל הספק – לרוב אין מה “לתקן” אצלנו, רק לעקוב ולעדכן סטטוס.

  2. בדיקת קונפיג בסיסי: ודא ש‑MONGODB_URL מוגדר ונראה תקין (במיוחד אם זה mongodb+srv://...).

    • הערה: את YOUR_MONGODB_HOST קח מתוך ה‑URL (לרוב הדומיין אחרי @, למשל cluster0.mongodb.net).

  3. בדיקת DNS/TCP מהשרת (מהיר, בלי תלות בכלים “אקזוטיים”):

    • DNS:

      • getent hosts YOUR_MONGODB_HOST

    • TCP (פורט 27017):

      • timeout 5 bash -lc 'cat < /dev/null > /dev/tcp/YOUR_MONGODB_HOST/27017'

      • אם זה נכשל: בעיית רשת/Firewall/NAT/ספק.

  4. בדיקת TLS (אם השגיאה על SSL Handshake):

    • timeout 8 openssl s_client -connect YOUR_MONGODB_HOST:27017 -servername YOUR_MONGODB_HOST -brief < /dev/null

    • אם זה נכשל, בדוק: זמן מערכת (NTP), CA bundle במכונה, ותצורת TLS בארגון.

  5. Network Access / IP allowlist (Atlas):

    • ודא שה‑egress IP של השרת מורשה.

    • המלצה: להוסיף רק x.x.x.x/32 של השרת.

    • לא מומלץ לפתוח 0.0.0.0/0. אם חייבים לשלול חסימה באירוע קריטי:

      • לעשות זאת רק לזמן קצר, עם תיעוד, ורק אם זה עומד במדיניות האבטחה – ואז להחזיר מיד.

  6. Restart לשירות:

    • לפעמים הדרייבר “נתקע” (pool/handshake). אתחל רק את שירות הבוט/ה‑worker הרלוונטי (Docker/Systemd), ואז עקוב ב‑Logs אם החיבור חוזר.

טיפ: אם יש request_id מאירוע משתמש – הרץ /triage <request_id> כדי לקפוץ ישר ללוגים/קישורי Sentry הרלוונטיים.

איטיות/נפילה של שירות חיצוני – בינוני

מכסה: External Service Degraded, latency גבוה, timeouts, 429

חומרה: 🟡 בינונית (חווית משתמש נפגעת; לפעמים נראה כמו “הבוט חושב”)

סימפטומים

  • זמן תגובה עולה מעל כמה שניות (בעיקר ב‑P95/P99).

  • Error Rate עולה (timeouts/429/5xx מהתלות).

  • משתמשים מתלוננים על “הודעות נתקעות”.

סדר פעולות

  1. זהה מי האיטי: Grafana/Logs/Traces – האם זה OpenAI? Telegram? DB? או השרת עצמו.

  2. בדוק Status רשמי של הספק:

  3. אם הספק למטה/איטי:

    • עדכן תקשורת למשתמשים (“יתכנו עיכובים עקב עומס אצל הספק”).

    • שקול להפעיל/להדק rate limit עדין, ולהגדיל timeouts בצורה שמרנית (רק אם זה לא מגדיל עומס).

  4. אם האיטיות פנימית:

    • בדוק CPU/RAM/דיסק/תורים, ושגרות רקע.

    • נסה הקלה מהירה: הגדלת משאבים זמנית או restart לשחרור משאבים (אחרי שיש לך תמונת מצב בלוגים).

באג אחרי Deploy / Release – משתנה

מכסה: exceptions חדשות מיד אחרי פריסה (למשל TypeError ב‑observability), internal_alert, 500 בפיצ’ר מסוים

חומרה: 🟠 משתנה (תלוי אם זה משבית זרימה מרכזית)

סדר פעולות

  1. צמצום נזק מיידי:

    • אם זה שובר פרודקשן: בצע rollback דרך ה‑CI/CD או החזרה לגרסת image/tag האחרונה שעבדה (לא “לעשות קסמים” ידנית ב‑git בפרודקשן).

  2. איסוף נתונים:

    • פתח Sentry, קח traceback מלא וה‑fingerprint.

    • אסוף request_id ורוץ /triage <request_id> כדי לאמת את אותו דפוס בלוגים.

  3. Root Cause:

    • בדוק שינויי קונפיג/ENV, שינויים ב‑schema/DB, ושינויי גרסאות של תלויות.

  4. Hotfix:

    • תקן, הוסף בדיקה/כיסוי מינימלי כדי למנוע חזרה, והעלה גרסת תיקון.

דשבורד

  • דשבורד codebot-slo-dashboard.json מסופק תחת docker/grafana/provisioning/dashboards/.

  • מומלץ לקשר אליו מתוך Grafana ולכוונן ספים לפי סביבת Staging/Prod.