בדיקות בריאות וגרסאות

"הפורט פתוח" זה לא "האפליקציה עובדת"

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

שני נתיבים שונים, ושני שימושים

app.get("/healthz", (req, res) => res.send("ok"));           // liveness: התהליך חי
app.get("/readyz", async (req, res) => {                      // readiness: אפשר לשרת
  try {
    await db.query("SELECT 1");
    res.json({ ok: true, version: BUILD_VERSION });
  } catch {
    res.status(503).json({ ok: false });
  }
});

• liveness משמש את המנהל (Docker/PM2/K8s) להחליט אם להרוג את התהליך. הוא חייב להיות זול ולא תלוי בשום שירות חיצוני — אחרת כשל של בסיס נתונים יגרום לריסטארטים אינסופיים שלא פותרים כלום.
• readiness משמש את מאזן העומס להחליט אם לשלוח בקשות. הוא יכול וצריך לבדוק תלויות.

גרסה: לדעת מה רץ

export const BUILD_VERSION = process.env.BUILD_VERSION ?? "dev";
app.get("/version", (req, res) => res.json({ version: BUILD_VERSION, env: process.env.NODE_ENV }));

מזגו את ה-commit (או מספר בנייה) לתוך משתנה סביבה בזמן הפריסה. בלי זה, בשאלה "האם התיקון עלה?" אין תשובה — יש רק השערות. שימו לב לא להסתמך על git בזמן ריצה: בתמונת Docker אין .git.

פיקוח מבחוץ

בדיקה שרצה מבחוץ לשרת היא היחידה שתופסת:

• הפרוקסי מחזיר 502.
• ה-DNS הפסיק להצביע.
• התעודה פגה.
• ה-firewall נסגר.

תזמון סביר: כל דקה ל-/readyz, והתראה בערוץ שמישהו באמת קורא. בדיקה שמתריעה למייל שאיש לא קורא היא לא ניטור.

מה כן לתעד

• מהי הבדיקה, מה בדיוק היא בודקת, ומה פירוש כישלון שלה.
• מי מקבל התראה ומתי מפעילים בן אדם בלילה (כמעט אף פעם — עדיף שקט עם תיקון בבוקר מאשר ערנות יתר).