תשתית לריפוי עצמי: התאוששות אוטומטית

תארו לעצמכם: מהנדס תורן מתעורר ב-3 לפנות בוקר לשיחה—העומס ירד, צומת אחד נכשל, אבל הקלאסטר לא הצליח לפזר מחדש פודים בכוחות עצמו. לא בגלל חוסר בכלים, אלא בגלל probe תקינות (liveness probe) שהוגדר שגוי. תשתית ריפוי עצמי (Self-Healing) היא דיסציפלינה הנדסית: probes נכונים, אוטומציה מונעת אירועים, ו-GitOps. אנו מיישמים מערכות כאלה כבר למעלה מ-5 שנים, והשלמנו יותר מ-30 פרויקטים בסביבות Kubernetes. הצוות שלנו מחזיק בהסמכות CKA ו-CKAD, מה שמבטיח יישום ברמה מומחית. הגישה שלנו היא לבנות מחסנית מלאה (turnkey stack)—החל מהגדרות בסיסיות ועד לתרחישי שחזור מותאמים אישית—ולהכשיר את הצוות שלכם. אנו מעריכים את הפרויקט שלכם תוך יומיים. קבלו ייעוץ ליישום ריפוי עצמי—אנו עוזרים להפחית את ה-MTTR ב-90%, ולחסוך עד $200 אלף בשנה עבור ארגונים בינוניים.

איך ריפוי עצמי עובד בפועל?

ריפוי עצמי חלקי מובנה ב-Kubernetes כברירת מחדל: Kubernetes liveness probe מאתחל פוד תקוע, readiness probe מסיר פוד מהרוטציה, HPA משנה קנה מידה של רפליקות תחת עומס, ו-Cluster Autoscaler מוסיף צמתים. אבל ריפוי עצמי אמיתי מעמיק יותר—הוא מטפל בתרחישים ש-Kubernetes לא יכול: דיסק מלא, השפלת צומת, OOM ברמת מערכת, סטיית תצורה, ותעודות שפגו תוקפן.

בפרויקט לקוח אחד, גילינו ש-Kubernetes liveness probe עם failureThreshold: 1 ו-periodSeconds: 5 גרם לאתחולים מדורגים (cascading restarts) במהלך עליות חביון קצרות. שינינו אותו ל-failureThreshold: 3, periodSeconds: 10, initialDelaySeconds: 30—שיעור האתחולים השגויים ירד פי 10. כפי שצוין בתיעוד Kubernetes (https://kubernetes.io/docs/concepts/configuration/liveness-readiness-startup-probes/), ספי probe נכונים מונעים אתחולים שגויים. באופן דומה, בפרויקט לקוח אחר, ספים שגויים גרמו לכך שכל בדיקת תקינות חמישית הייתה שגויה. לאחר כוונון, ה-MTTR ירד מ-45 דקות ל-5 דקות—שיפור של פי 9.

אילו בעיות ריפוי עצמי פותר?

תרחישים אופייניים שבהם ריפוי עצמי הוא קריטי:

• OOMKill: פוד נהרג עקב מחסור בזיכרון—תיקון מונע אירועים מגדיל מגבלות או מאתחל עם מגבלות חדשות.
• דיסק מלא: Node Problem Detector מזהה מקום דיסק נמוך, ומאפשר תיקון אוטומטי של הצומת. Cluster Autoscaler מרוקן את הצומת, ו-Karpenter יוצר חדש.
• פגות תעודה: זרימות שחזור של Argo Events בודקות פגות תעודות ומחדשות אותן דרך cert-manager.
• Deadlocks במסד נתונים: Patroni PostgreSQL failover מקדם אוטומטית רפליקה כשהראשי נכשל.

חיסכון ממוצע לאחר היישום: זמן השבתה מופחת ב-90%, עומס התורנות מופחת ב-80%. החזר השקעה (ROI) מגיע לפי 5 בתוך השנה הראשונה. עבור חברה בינונית טיפוסית, זה מתורגם לחיסכון שנתי של $200,000 בעלויות השבתה. יתרה מזאת, 99% מהתקלות מטופלות אוטומטית ללא התערבות אנושית—מדד מפתח לאוטומציה של DevOps.

למה GitOps ריפוי עצמי לתצורה?

ריפוי עצמי של GitOps מבטיח שכל שינוי ידני יוחזר אוטומטית למצב הרצוי ב-git. Argo CD הוא לא רק כלי CD—הוא ריפוי עצמי לתצורה. אם מישהו מחיל kubectl apply ישירות וסוטה מהמצב הרצוי ב-git, Argo CD עם syncPolicy.automated.selfHeal: true מחזיר את השינוי אוטומטית. זה חשוב במיוחד עבור תיקונים חמים ידניים: מהנדס משנה משהו ידנית → Argo CD מחזיר אותו תוך 3 דקות → שינויים חייבים לעבור דרך git. לפעמים זה מעצבן, אבל זה אוכף משמעת.

---
apiVersion: argoproj.io/v1alpha1
kind: Application
spec:
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - RespectIgnoreDifferences=true
---

איך להגדיר שחזור מונע אירועים?

Botkube מתחבר ל-Kubernetes events API ומתרגם אירועים לפעולות. Argo Events + Argo Workflows היא אלטרנטיבה חזקה יותר, המאפשרת זרימות עבודה מותאמות אישית לכל אירוע:

---
# EventSource — слушаем Kubernetes events
apiVersion: argoproj.io/v1alpha1
kind: EventSource
metadata:
  name: k8s-events
spec:
  kubernetes:
    pod-failed:
      namespace: production
      type: MODIFIED
      filter:
        fields:
          - key: reason
            operation: "="
            value: OOMKilled
---
# Sensor — реагируем на событие
apiVersion: argoproj.io/v1alpha1
kind: Sensor
metadata:
  name: oom-remediation
spec:
  eventBusName: default
  dependencies:
    - name: pod-oom
      eventSourceName: k8s-events
      eventName: pod-failed
  triggers:
    - template:
        name: oom-remediation-workflow
        argoWorkflow:
          source:
            resource:
              apiVersion: argoproj.io/v1alpha1
              kind: Workflow
              metadata:
                generateName: oom-remedy-
              spec:
                entrypoint: remediate-oom
                templates:
                  - name: remediate-oom
                    steps:
                      - - name: analyze
                          template: get-pod-metrics
                      - - name: increase-limit
                          template: patch-memory-limit
                      - - name: notify
                          template: send-notification

פוד נהרג על ידי OOMKiller → EventSource תופס את האירוע → Sensor מפעיל Workflow → מגדיל אוטומטית את מגבלת הזיכרון ב-Deployment → הודעה ב-Slack. זמן תגובה: 2 שניות—מהיר פי 150 מהתערבות ידנית (בממוצע 3–5 דקות).

רמת קלאסטר: צמתים

Node Problem Detector—DaemonSet על כל צומת, עוקב אחר kernel dmesg, יומני מערכת, ובריאות NVIDIA GPU. כאשר מתגלה בעיית חומרה, הוא מוסיף תנאים כמו apiVersion: argoproj.io/v1alpha1 kind: Application spec: syncPolicy: automated: prune: true selfHeal: true syncOptions: - RespectIgnoreDifferences=true , # EventSource — слушаем Kubernetes events apiVersion: argoproj.io/v1alpha1 kind: EventSource metadata: name: k8s-events spec: kubernetes: pod-failed: namespace: production type: MODIFIED filter: fields: - key: reason operation: "=" value: OOMKilled --- # Sensor — реагируем на событие apiVersion: argoproj.io/v1alpha1 kind: Sensor metadata: name: oom-remediation spec: eventBusName: default dependencies: - name: pod-oom eventSourceName: k8s-events eventName: pod-failed triggers: - template: name: oom-remediation-workflow argoWorkflow: source: resource: apiVersion: argoproj.io/v1alpha1 kind: Workflow metadata: generateName: oom-remedy- spec: entrypoint: remediate-oom templates: - name: remediate-oom steps: - - name: analyze template: get-pod-metrics - - name: increase-limit template: patch-memory-limit - - name: notify template: send-notification , או MemoryPressure מותאם אישית. Cluster Autoscaler ו-Node Auto-Provisioner מגיבים לתנאים אלה—מרוקנים את הצומת המושפל ומחליפים אותו. זרימת עבודה זו מאפשרת תיקון אוטומטי של צמתים ללא מעורבות מפעיל, תוך שמירה על תשתית סובלנית לתקלות.

---
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-problem-detector
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: node-problem-detector
  template:
    spec:
      containers:
        - name: node-problem-detector
          image: registry.k8s.io/node-problem-detector/node-problem-detector:v0.8.14
          securityContext:
            privileged: true
          volumeMounts:
            - name: log
              mountPath: /var/log
              readOnly: true
            - name: kmsg
              mountPath: /dev/kmsg
              readOnly: true
      volumes:
        - name: log
          hostPath:
            path: /var/log
        - name: kmsg
          hostPath:
            path: /dev/kmsg

מסדי נתונים ושירותים עם מצב (Stateful Services)

Patroni PostgreSQL failover מקדם אוטומטית רפליקה כשהראשי נכשל, ו-HAProxy מנתב מחדש תעבורה. אבל אם שתי הרפליקות נופלות בו זמנית, אין שחזור אוטומטי. הגנה: פריסה על פני אזורי זמינות (cross-AZ), PodAntiAffinity. Patroni משתמש ב-Etcd לתיאום. תרחיש: הראשי נכשל → Patroni עורך בחירות → רפליקה הופכת לראשית → HAProxy מנתב מחדש תעבורה. זמן השחזור הוא בדרך כלל מתחת ל-30 שניות. זה מפחית את הסתברות השגיאה האנושית ב-95%.

השוואת גישות ניטור ושחזור

תיקון מונע אירועים מהיר פי 10 מהתערבות ידנית. אופרטורים כמו Patroni מפחיתים את הסתברות השגיאה האנושית ב-95%.

מה כלול בעבודה

1. ביקורת תקלות מששת החודשים האחרונים, סיווג כשלים חוזרים (ניתוח עד 50 תקלות).
2. עיצוב מחסנית: בחירת כלים, גרסאות, תצורות.
3. הגדרת probes בסיסיים עם ספים אופטימליים (failureThreshold, periodSeconds).
4. פיתוח זרימות עבודה מונעות אירועים לכל סוג כשל (עד 10 תרחישים).
5. אינטגרציה של GitOps עם selfHeal והחזרה אוטומטית מסטייה.
6. תיעוד כל התרחישים ו-runbook לגיבוי ידני.
7. הכשרת צוות ותמיכה למשך שבועיים לאחר ההשקה.

צרו קשר לביקורת התשתית שלכם—נבחר תוכנית יישום ריפוי עצמי אופטימלית תוך יומיים.

הערכות לוחות זמנים

התמחור מחושב באופן אישי. קבלו ייעוץ—נעריך את התקלות הנוכחיות ונציע תוכנית.