הנדסת כאוס: עמידות המערכת

הנדסת כאוס: עמידות המערכת

1) למה הנדסת כאוס

• השערות מבחן על התנהגות המערכת ולאמת SLO;
• איתור ספופים חבויים, פסקי זמן לא נכונים/מגשים מחדש, השפעות מפלות;
• קבוצות רכבת: ימי משחק, חשבונות עבודה, תקשורת;
• ליצור תרבות של ”קיימות כברירת מחדל” במקום ”לקוות לטוב”.

מהנדסת כאוס "לשבור הכל. "זוהי שיטה מדעית: steady-state _ hypothesis * escription * excreduction is importion.

2) מחזור ניסוי בסיסי

1. מצב יציב (קו בסיס): (למשל, הצלחה בלמה 500 מ "ר ב-99. 95%).
2. השערה: עם אובדן AZ אחד, p95 יגדל <10%, והזמינות 99. 9%.
3. ניסוי: עבירה מתוכננת עם רדיוס פיצוץ מוגבל ועצירת קריטריונים.
4. תצפיות: metrics/trails/logs, shurn-rate SLO, business SLI (לדוגמה, פיקדונות מוצלחים).
5. שיפורים: אנו מקליטים ממצאים, משנים פסקי זמן/גבולות/ניתוב, מעדכנים את פנקס הריצות.
6. אוטומציה/רגרסיה: חזור על לוח הזמנים, הוסף ל CI/CD ולוחות שנה של ימי משחק.

3) בטיחות קודם

רדיוס פיצוץ: להתחיל עם אחד צר - תרמיל אחד/דוגמה/מסלול/שם.
מעקות בטיחות: התראות לקצב שריפה SLO (מהיר/איטי), מגבלות מגש מחדש, הגבלת QPS, תקציב אירוע.
עצור קריטריון: ”אם שגיאה-קצב> X% או p99> Y ms N דקות - עצור מיד והתגלגל”.
שעות עבודה בכוננות, בעלי עניין מבוקשים, שחרורים קפואים.
תקשורת: IC/Tech Lead/Comms, ערוץ ברור (חדר מלחמה), תבנית הודעה.

4) כיתות כישלון ורעיונות השערה

רשת: עיכוב/מתח/אובדן, ירידה חלקית של נמלים, תקשורת ”נופלת” בין שירותים/PSP.
מחשב/צמתים: תהליכי הרג, חימום יתר של המעבד, תשישות של תיאורי קבצים, בריכות חיבור צרות.
אחסון ומסד נתונים: גידול של דיסקים, העתקים, עצור שבר אחד/מוביל, שבריר מוח.
תלויות: השפלה של API חיצוני, גבולות ספק, 5xx/429 התפרצויות.
שינוי ניהול: שחרור לא מוצלח, דגל תכונה רע, rollout חלקי.
היקפי: CDN משפיל, DNS/Anycast, כשל בהגנה על WAF/BOT.
איזור/AZ: אובדן מוחלט או תקרית ”חלקית” (קצת יותר גרועה ובלתי צפויה).

5) כלים וטכניקות

קוברנטס: Chaos Mesh, Litmus, חותם, קובייה-קוף.
עננים: AWS Afface Simulator (FIS), Fault Domains ליד עננים.
רשת/פרוקסי: Toxiproxy (רעל TCP), tc/netem, iptables, Avenoy fault (עיכוב/ביטול), Istio fault הזריקה.
תהליכים/צמתים: "מתח-נ" ג ", cgroups/CPU-מצערת, מילוי דיסק.
ניתוב תנועה: משקולות GSLB/DNS, מתג כנרי/כחול-ירוק לבדיקות מזויפות.

6) תסריטי דגימה (קוברנטס)

6. 1 עיכוב/ביטול על המסלול (שירות Virtualitual איסטיו)

yaml apiVersion: networking. istio. io/v1alpha3 kind: VirtualService metadata: { name: api-chaos }
spec:
hosts: ["api. internal"]
http:
- route: [{ destination: { host: api-svc } }]
fault:
delay: { percentage: { value: 5 }, fixedDelay: 500ms }
abort: { percentage: { value: 1 }, httpStatus: 503 }

השערה: פסקי זמן לקוח/מגשים מחדש וCBs יחזיקו ב ־ p95 <300 ms ו ־ rate-rate <0. 5%.

6. 2 Pod Kill (כאוס)

yaml apiVersion: chaos-mesh. org/v1alpha1 kind: PodChaos metadata: { name: kill-one-api }
spec:
action: pod-kill mode: one selector:
namespaces: ["prod"]
labelSelectors: { "app": "api" }
duration: "2m"

השערה: המאזן ו ־ HPA מפצים על אובדן מקרה אחד ללא גידול של p99> 20%.

6. 3 כאוס ברשת (עיכוב לבסיס הנתונים)

yaml apiVersion: chaos-mesh. org/v1alpha1 kind: NetworkChaos metadata: { name: db-latency }
spec:
action: delay mode: all selector: { namespaces: ["prod"], labelSelectors: {"app":"payments"} }
delay: { latency: "120ms", jitter: "30ms", correlation: "25" }
direction: to target:
selector: { namespaces: ["prod"], labelSelectors: {"role":"db"} }
mode: all duration: "5m"

השערה: בריכות/פסקי זמן/מטמון יפחיתו את הפגיעה; תשלומי p95 יישארו ללא תשלום.

6. 4 מילוי דיסק

yaml apiVersion: chaos-mesh. org/v1alpha1 kind: IOChaos metadata: { name: disk-fill-logs }
spec:
action: fill mode: one selector: { labelSelectors: {"app":"ingest"} }
volumePath: /var/log size: "2Gi"
duration: "10m"

השערה: סיבוב של לוגים/מכסות/התראות יעבוד לפני הידלדלות המסלולים.

7) ניסויים מחוץ K8s

7. 1 Toxiproxy (אינטגרציה מקומית)

bash toxiproxy-cli create psp --listen 127. 0. 0. 1:9999 --upstream psp. prod:443 toxiproxy-cli toxic add psp -t latency -a latency=200 -a jitter=50 toxiproxy-cli toxic add psp -t timeout -a timeout=1000

7. 2 אשמת שליח HTTP (היקף/רשת)

yaml fault:
delay: { fixed_delay: 0. 3s, percentage: { numerator: 10, denominator: HUNDRED } }
abort: { http_status: 503, percentage: { numerator: 1, denominator: HUNDRED } }

7. 3 AWS FIS (רעיון לדוגמה)

ניסוי ”להרוג” N% EC2 בקבוצת Auto Scaling Group, להעלות באופן מלאכותי EBS-latency, לבטל NAT-GW באחד AZ.
קריטריוני עצירה מובנים עבור מדדי LoudWatch SLO.

8) מדדי תצפית במהלך כאוס

SLO/SLI: שבריר של בקשות טובות, p95/p99, לשרוף קצב.
מודל אדום למסלולים קריטיים (קצב, שגיאות, משך).
בריכות: מחכה לחיבור p95, ניצול.
DB: lag העתקים, מנעולים, דריפט p95 בקשות.
רשת: transmitts, RTT, dscp/ecn.
Business SLI: הצלחה של עסקאות (הפקדות/צ 'קים),% החזרות/שגיאות.
מעקב: שבילים סלקטיביים (מופת), מתאם של הערות שחרור.

9) אינטגרציה עם תקציב SLO/שגיאה

תוכנית ניסויים במסגרת התקציב של טעויות: תוהו ובוהו לא צריך ”לשבש” מטרות רבעוניות.
התראות על שרפה בתור מתג הריגה אוטומטי.
דיווח: ”כמה תקציב נשרף”, ”מה סטיות יציבות מדינה”.

10) ימי משחק (תרגיל)

תרחיש: אגדה קצרה (למשל: ”אזור-מזרח אבוד”), זריקת צעדים, מטרות SLO, תפקידים, זמן.
דירוג: RTO/RPO בפועל, איכות התקשורת, תקינות ריצה.
רטרו: רשימת שיפורים עם בעלים ומועדים, עדכון תיעוד/לוחות מחוונים.

11) אוטומציה ו ־ CI/CD

עשן-כאוס: בדיקות היערכות קצרות על כל שחרור (למשל. 1 pod-kill + 200ms עיכוב לכל מסלול).
לילה/שבועי: תרחישים כבדים יותר (5-15 דקות) עם דיווח.
שערי פרומו: אם p95/שגיאות> סף על קנרית - אוטומטי-rollback.
ריפוזיטוריות עם קטלוג של ניסויים (YAML + runbook + SLO-sefholds).

12) אנטי דפוסים

”שבירת מזון ללא מעקות”: אין קריטריונים לעצור, אין תורן = הסיכון של אירוע אמיתי.
פעולה חד פעמית במקום תהליך.
תוהו ובוהו ללא מצב יציב: לא ברור מה נחשב להצלחה/כישלון.
מגשים מחדש באופן מוגזם * DDOS עצמי בעת הזרקת עיכובים.
מתעלם מההצלחה העסקית: ”טכנאי” כאשר התשלומים/ההזמנות נכשלים.
חוסר בעלים לאחר ניתוח ושיפור.

13) רשימת מימושים (0-45 ימים)

0-10 ימים

הגדר מצב יציב SLI (משתמש + עסק).
בחר כלי (Chaos Mesh/Litmus/Toxiproxy/FIS).
תאר מעקות: רדיוס פיצוץ, קריטריון עצירה, חלונות, תפקידים.

11-25 ימים

הפעל את הניסויים הראשונים: pod-kill, 100-200 ms עיכוב בכל קריטי במעלה הזרם, טיפה 1% של חבילות.
הגדרת התראות קצב שריפה, כרוך מתג להרוג עם קריטריון עצירה.
לבלות את יום המשחק הראשון, לאסוף רטרו ותיקונים.

26-45 ימים

הוספת תסריטי רמת AZ/תלות (PSP חיצוני, DB-lag).
כאוס לילי אוטומטי על היערכות; הכן תרחישים ”עונתיים” (פסגות).
קטלוג של ניסויים ודוחות קבועים לניהול/SRE.

14) מדדי בגרות

ב-80% מהמסלולים הקריטיים יש את הניסויים המתוארים ואת המדדים היציבים.
מתג הריגה אוטומטי מופעל כאשר סף ה ־ p99/שגיאה עולה על סף ה ־ p99.
רבעוני - יום משחק רמת AZ/אזור; 1 פעמים/חודש תרחיש יעד של תלויות.
MTTR יורד לאחר מחזור של שיפורים, מתאם ”שחרור ↔ תקרית” יורד.
הפרופורציה של ”לא צפוי” צונחת בכשלונות אמיתיים.
לוחות מחוונים מראים עמידות כ-KPIs (קצב צריבה, זמן התאוששות, פרופורציה של פעולות DR מוצלחות).

15) דוגמאות של מעקות בטיחות ומעשי עצירה

עצור ב: "http _ req _ נכשל> 1% '3 דקות, p99> 1000 ms' 3 windows, deposition _ success <99. 5%`.
הפחתת רדיוס הפיצוץ: החלפה אוטומטית של המניפסט, החזרת משקולות GSLB, השבתה של זריקות פגמים.
פקודת עצירה: כפתור/תסריט בודד עם רישום סיבות.

16) תרבות ותהליכים

כאוס הוא חלק מקצב ה-SRE, לא ”קיצוני”.
דיווח שקוף, זיהוי פגיעות, פעולה מתקנת.
אימון תורן, הדמיית תקשורת עם לקוחות/שותפים.
קישור עם SLA/SLO ותקציבים: כאוס צריך להגביר, לא לערער, אמינות.

17) מסקנה

הנדסת כאוס הופכת את ”התקווה לתשע” לקיימות. גיבוש מצב יציב, הצבת מעקות, שבירה קטנה ומבוקרת, התבוננות ב-SLO ו-SLI עסקי, שיפורים שיא ואוטומטים. ואז כישלונות אמיתיים יהפכו למאורעות מבוקרים: RTO צפוי, תקציב שגיאות מוגן ומוכנות הצוות לפעול ללא פאניקה.