כשמדדים משקרים
כשמדדים משקרים
אחרי שהבנו ש-Latency היא תוצאה של החלטות ולא רק של קוד, מגיע השלב שבו אנחנו מנסים “להבין מה קורה”.
ואז אנחנו פותחים Dashboard.
והכול נראה… בסדר.
האשליה: “אם הגרפים ירוקים - המערכת בריאה”
Metrics נועדו להרגיע. הם נותנים תחושת שליטה:
- מספרים
- קווים
- ממוצעים
והבעיה היא לא שהם שגויים - אלא שהם מסננים את המציאות.
ברוב המערכות, Metrics לא משקרים במודע. הם פשוט מספרים סיפור חלקי.
mean מול tail: המקום שבו האמת מתחבאת
הממוצע כמעט תמיד נראה טוב.
95% מהבקשות עוברות מהר. 99% אולי עדיין עומדות בדרישות שהתחייבנו עליהן.
אבל המערכת לא חווה ממוצעים. היא חווה קצוות.
אותו 1%:
- נתקע
- מייצר retries
- מפעיל עומס משני
- ומדליק שרשרת תגובות
ה-tail הוא המקום שבו מערכות נשברות - אבל הממוצע ממשיך להרגיע.
למה Dashboards נותנים ביטחון שקרי
Dashboards בנויים כדי:
- לפשט
- לאחד
- ולהציג תמונה נקייה
אבל פשטות באה במחיר.
גרף שממצע הכול:
- מעלים שונות
- מסתיר התנהגות קיצון
- ומטשטש דפוסים מסוכנים
הכול נראה “בשליטה” - עד שהוא לא.
כשמדדים מונעים פעולה
יש רגע מסוכן במיוחד: כשמישהו אומר:
“אבל לפי הגרפים - הכול בסדר”.
זה הרגע שבו:
- תחושת בטן נדחקת הצידה
- חריגות קטנות מועלמות
- ותקלות מתחילות להיבנות בשקט
Metrics לא רק מתארים מציאות - הם משפיעים על החלטות.
וכשמדדים מרגיעים, אנשים מפסיקים להילחץ - גם כשצריך.
מתי להסתכל על גרף, ומתי להקשיב
מערכת יציבות יודעת להבחין בין שני מצבים:
- גרף שמאשר הבנה קיימת
- וגרף שמחליף שיקול דעת
Metrics טובים:
- מאששים חשד
- מסייעים לחקירה
- מחדדים שאלות
Metrics מסוכנים:
- סוגרים דיון
- מבטלים אינטואיציה
- נותנים תשובה כשעוד אין הבנה
המשל
אפשר לחשוב על לוח מחוונים ברכב.
מד מהירות, דלק וטמפרטורה - כולם חשובים.
אבל נהג שלא מקשיב:
- לרעש
- לרטט
- או לשינוי בהתנהגות
עלול להמשיך לנסוע - עד שהרכב עוצר בפתאומיות.
המחוונים לא שיקרו. הם פשוט לא סיפרו את כל הסיפור.
השורה התחתונה
Metrics הם כלי. לא תחליף לשיפוט.
מערכות מסוכנות לא נראות תמיד אדומות - לעיתים הן נראות ירוקות מדי.
מי שסומך רק על מדדים - מאבד רגישות.
מי שמשלב מדדים עם הבנה, שאלות, וחשד בריא - מזהה בעיות מוקדם.
מבט קדימה
וכשבעיה כבר מזוהה, מגיע הרגע המסוכן הבא:
לשנות משהו בפרודקשן.
בפוסט הבא נצלול לשאלה למה Deploy הוא אחד האירועים המסוכנים ביותר במערכת - ולמה שינוי קטן אינו דבר קטן בכלל.
📚 פוסטים נוספים בסדרה: כשהמערכת כבר רצה
- חלק 1 Production הוא נקודת האמת של המערכת
- חלק 2 Latency כבעיה ארגונית, לא טכנית
- חלק 4 Deploy הוא אירוע מסוכן
- חלק 5 Gradual rollout: למה "בהדרגה" לא תמיד בטוח
- חלק 6 Backward compatibility כהתחייבות ארוכת טווח
- חלק 7 כשמערכת משקפת מבנה ארגוני
- חלק 8 Incident response הוא תרבות, לא פרוצדורה
- חלק 9 Good Enough Engineering
- חלק 10 Over-engineering ו-Under-engineering: שני צדדים של אותה טעות
- חלק 11 מהנדסים בוגרים לא מחפשים שליטה