למה מערכת שעובדת ב-99% מהזמן היא מערכת גרועה

במבט ראשון, 99% נשמע מצוין. כמעט תמיד עובד. כמעט תמיד זמין. כמעט תמיד מהיר.

אבל מערכות לא נמדדות לפי “כמעט”. והמשתמשים - בטח שלא.

ההנחה השגויה

הבעיה מתחילה בהנחה שגויה: שמה שקורה רוב הזמן הוא מה שיקבע את החוויה.

בפועל, משתמשים לא זוכרים ממוצעים. הם זוכרים חריגים.

הבקשה שנתקעה. הפעולה שנכשלה בדיוק ברגע הלא נכון. המערכת שעבדה נהדר - עד שלא.

ה-1% הוא לא שולי. הוא החלק שבו המערכת פוגשת את המציאות.

למה זה מחריף בסקייל

וככל שהמערכת גדולה יותר - ה-1% הזה מופיע כל הזמן.

אם יש:

• אלפי משתמשים
• מיליוני בקשות
• או תהליכים רציפים

אז “כשל נדיר” הופך לחוויה יומיומית עבור מישהו. כל יום מישהו נופל על הקצה.

הפער בין סטטיסטיקה לחוויה

כאן נוצר הפער בין סטטיסטיקה לחוויה.

מבחינת המדדים: המערכת מצוינת.

מבחינת המשתמש: המערכת לא אמינה.

והמוניטין נבנה בדיוק שם - לא במקום שבו הכול עובד, אלא במקום שבו זה לא עובד.

למה כשל לא צפוי מרגיש חמור יותר

מערכות גרועות לא נופלות כל הזמן. הן נופלות בצורה לא צפויה.

כשהכשל:

• נדיר
• קשה לשחזור
• ולא מוסבר

הוא מרגיש הרבה יותר חמור מכשל קבוע וברור.

לא בגלל התדירות - אלא בגלל חוסר הוודאות.

תכנון למקרי קצה, לא רק למקרה הנפוץ

זו הסיבה שתכנון למקרי קצה חשוב יותר מתכנון למקרה הנפוץ.

המקרה הנפוץ בדרך כלל מסתדר גם לבד. מקרי הקצה הם אלה שדורשים מחשבה:

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

שם נבחנת המערכת.

המשל

מעלית שעובדת 99% מהזמן. אבל פעם בכמה ימים נתקעת לכמה דקות.

סטטיסטית - מצוין. חווייתית - אף אחד לא רוצה להיכנס.

השורה התחתונה

מערכת טובה לא שואפת לעבוד “כמעט תמיד”. היא שואפת להתנהג בצורה צפויה - גם כשהיא נכשלת.

כי ה-1% לא קובע רק את הקצה. הוא קובע את האמון. והאמון - הוא המוניטין.