למה Inference לא אוהב מצבי ביניים

במערכות רבות יש שאיפה להיות “אלגנטיים” בכשל: לא ליפול לגמרי, לא להפסיק שירות, להישאר בערך זמינים.

אבל ב-Inference, הגישה הזו מסוכנת במיוחד.

כי מצב חלקי גרוע יותר ממצב גרוע.

רכיבים “חצי זמינים” הם מקור לאי-ודאות

רכיב חצי זמין הוא רכיב ש:

• לפעמים מגיב
• לפעמים מאט
• לפעמים נכשל
• ואף פעם לא ברור מה מצבו כרגע

מבחוץ הוא נראה “חי”. מבפנים - הוא לא צפוי.

Inference לא יודע לעבוד עם אולי:

• אולי הבקשה תעבור
• אולי תיתקע
• אולי תצליח אחרי זמן לא ידוע

התוצאה היא:

• תורים שמתארכים
• retries שמצטברים
• זנב שמתנפח בלי סיבה ברורה

למה מצב degraded מסוכן אם לא הוגדר היטב

מצב degraded יכול להיות כלי חשוב - אבל רק אם הוא חד וברור.

כש-degraded לא מוגדר:

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

במקום ירידה נשלטת - מקבלים התנהגות כאוטית.

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

המשל

דמיינו מעלית ש”לפעמים נוסעת, לפעמים נתקעת”

גרועה בהרבה ממעלית מושבתת.

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

Inference מרגיש בדיוק כך.

מצב גרוע עדיף - אם הוא ברור

מצב גרוע:

• איטי אבל עקבי
• מוגבל אבל צפוי
• מצומצם אבל מובן

מצב חלקי:

• משתנה
• מתנדנד
• ולא ניתן לניהול

Inference לא צריך להיות מושלם. הוא צריך להיות ברור.

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

ב-Inference, אין מקום ל”בערך”.

מערכת יציבה לא מנסה להחזיק בכל מחיר, ולא להיראות זמינה כשאינה כזו.

היא מגדירה מצבים חדים, ומתחייבת אליהם.

כי בסופו של דבר, מצב חלקי מבלבל את המערכת - ומצב גרוע אך ברור, מאפשר לה להמשיך לעבוד.