אמינות היא יותר מ"לא לקרוס"

אמינות אינה רק "לא לקרוס"#

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

להגדיר שירות בר מדידה#

SLI — Service Level Indicator: מדד לתפקוד השירות כפי שהמשתמש חווה אותו; לדוגמה שיעור משימות שהושלמו, שיעור בקשות תקינות או משך תגובה.

SLO — Service Level Objective: היעד הפנימי שנבחר עבור המדד לאורך חלון זמן מוגדר.

SLA — Service Level Agreement: התחייבות שירות חוזית/מסחרית, אם קיימת. לא כל פרויקט צריך SLA; כל מוצר שמתפעלים צריך להבין מהי רמת השירות הרצויה ומה עושים כשחורגים ממנה.

כאשר מדד הצלחה מצריך תשובה איכותית של AI, אפשר למדוד בנפרד זמינות שירות, השלמת תהליך ואיכות תוצאה. קל יותר לזהות צוואר בקבוק כשלא דוחסים את כולם למדד אחד. ספר העבודה של Google SRE מסביר שימוש ביעדים ובתקציב שגיאות: Google SRE Workbook.

Latency, timeout, retries, rate limits#

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

לזה קוראים מדידת Latency לפי אחוזונים (Percentiles) — והיא מסייעת לא להסתפק במהירות הממוצעת.

בדקו זמני תגובה לפי אחוזונים, לא רק ממוצע. אם רוב הבקשות מהירות אבל אחוז קטן נמשך זמן רב מאוד, הממוצע עלול להסתיר חוויית שימוש קשה. בחרו אחוזון וחלון זמן המתאימים למוצר; אין צורך לאמץ יעד p95 שרירותי ללא קשר לתהליך.

מה צריך לקרות כשהספק נופל?#

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

ארבע פעולות קונקרטיות לקריאות חיצוניות#

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

• מפתח Idempotency: בפעולות שיוצרות חיוב, הזמנה או הודעה, שלחו מפתח ייחודי לכל כוונה, כדי שניסיון חוזר לא יבצע את הפעולה פעמיים.
• Exponential backoff עם jitter: המתנה שגדלה בין ניסיונות, עם רכיב אקראי, כדי שלקוחות רבים לא ינסו שוב באותו רגע.
• כיבוד 429 ו-Retry-After: כשהשירות מחזיר 429, האטו וחכו לפי הכותרת אם קיימת, ולא להציף עוד (Rate Limiting).
• מגבלת ניסיונות ותקציב: מספר ניסיונות מקסימלי ו-timeout לכל פעולה, ובלי ניסיונות חוזרים במקביל בכל שכבה, כי העומס מוכפל.

איך מגדירים בדיקת התאוששות שאפשר להפעיל#

בחרו תלות חיצונית אחת והשביתו אותה בסביבת בדיקה מורשית. רשמו מה המשתמש רואה, האם הפעולה נרשמת במצב ברור, האם ה־timeout עוצר אותה, ומה קורה כשהשירות חוזר. לאחר מכן חזרו על ניסיון השליחה כדי לוודא שלא נוצרו תוצאות כפולות. בפעולה רגישה, בדקו גם מה קורה אם התקבלה תשובה מאוחרת אחרי שהמשתמש כבר התייאש או ניסה שנית.

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