בדיקת תקינות לאחר פריסה: ערובה לתפעוליות

בדיקת תקינות לאחר פריסה: ערובה לתפקוד תקין

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

כיצד בדיקת תקינות לאחר פריסה מונעת כשלים לאחר פריסה

בדיקת תקינות לאחר פריסה היא אימות שרץ לאחר ש-Kubernetes (או כל מתזמן אחר) מחשיב את הפריסה כמושלמת ומוודא שהשירות באמת עובד: הוא מקבל תעבורה, מגיב כראוי, וכל התלויות זמינות. לשם כך נדרש endpoint ייעודי לבדיקת תקינות — /health/ready או /health/deep — שבודק פנימית את כל התלויות הקריטיות. לא רק return 200, אלא בדיקות אמיתיות:

func deepHealthCheck(w http.ResponseWriter, r *http.Request) {
	checks := map[string]error{
		"database":      db.PingContext(r.Context()),
		"redis":         rdb.Ping(r.Context()).Err(),
		"s3_bucket":     checkS3Bucket(r.Context(), cfg.BucketName),
		"feature_flags": featureFlags.CheckConnection(),
	}
	// агрегируем и возвращаем 200/503
}

מדוע בדיקת מוכנות (Readiness Probe) אינה מספיקה?

ב-Kubernetes קיים func deepHealthCheck(w http.ResponseWriter, r *http.Request) { checks := map[string]error{ "database": db.PingContext(r.Context()), "redis": rdb.Ping(r.Context()).Err(), "s3_bucket": checkS3Bucket(r.Context(), cfg.BucketName), "feature_flags": featureFlags.CheckConnection(), } // агрегируем и возвращаем 200/503 } , ורבים חושבים שזה מספיק. אבל בדיקת מוכנות בודקת רק את הפוד עצמו. היא אינה יודעת ש:

• מפסק מעגל לשירות במורד הזרם נפתח מיד לאחר ההתחלה
• מיגרציות מסד נתונים יושמו עם שגיאה; השירות עלה על סכמה ישנה
• דגל תכונה מ-AppConfig או LaunchDarkly לא נטען, ומחצית מהפונקציונליות מושבתת

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

אילו בדיקות מבוצעות עבור סוגי שירותים שונים?

עבור HTTP APIs — readinessProbe עם בדיקות תלויות בתוספת עסקה סינתטית: בקשה עסקית אמיתית אחת עם תוצאה ידועה. עבור עובדים (Celery, צרכני SQS/Kafka) — אנו מוודאים שהצרכן מחובר לברוקר ומטפל בהודעת בדיקה. עבור שירותים בעלי מצב (מטמון, סשנים) — אנו בודקים קריאה/כתיבה ב-Redis או Memcached, לא רק פינג. גישה זו מכסה 95% מתרחישי הכשל.

כיצד להגדיר בדיקת תקינות לאחר פריסה ב-CI/CD?

תבנית סטנדרטית עבור GitLab CI או GitHub Actions — עבודת /health/ready נפרדת בשלב post-deploy שרצה לאחר verify:

---
post_deploy_check:
  stage: verify
  needs: [deploy]
  script:
    - |
      for i in $(seq 1 12); do
        STATUS=$(curl -s -o /dev/null -w "%{http_code}" \
          "https://${APP_URL}/health/ready")
        if [ "$STATUS" = "200" ]; then
          echo "Health check passed"
          exit 0
        fi
        echo "Attempt $i: got $STATUS, waiting 10s..."
        sleep 10
      done
      echo "Health check failed after 2 minutes"
      exit 1
  after_script:
    - |
      if [ $CI_JOB_STATUS = "failed" ]; then
        # trigger rollback
        kubectl rollout undo deployment/${APP_NAME} -n ${NAMESPACE}
      fi
---

שתי דקות הוא זמן קצוב טיפוסי לשירותים עם התחלה קרה איטית. עבור יישומי JVM לעיתים יש צורך ב-3–4 דקות. יישום אימות CI כזה מפחית את ה-MTTR ב-70% וחותך את מספר התקריות בחצי, וחוסך תקציב לתיקון כשלים.

אם הפריסה מתבצעת דרך ArgoCD, בדיקת תקינות לאחר פריסה מוטמעת באמצעות הוקים של deploy או דרך post_deploy_check: stage: verify needs: [deploy] script: - | for i in $(seq 1 12); do STATUS=$(curl -s -o /dev/null -w "%{http_code}" \ "https://${APP_URL}/health/ready") if [ "$STATUS" = "200" ]; then echo "Health check passed" exit 0 fi echo "Attempt $i: got $STATUS, waiting 10s..." sleep 10 done echo "Health check failed after 2 minutes" exit 1 after_script: - | if [ $CI_JOB_STATUS = "failed" ]; then # trigger rollback kubectl rollout undo deployment/${APP_NAME} -n ${NAMESPACE} fi עם PostSync:

analysis: templates: - templateName: success-rate startingStep: 2 args: - name: service-name value: my-service