פתרון עומס ותפעול

דוגמה בעייתית היא אלף ניסיונות שבהם 900 בקשות הצליחו בעשר מילישניות ו־100 הגיעו ל־timeout של שנייה. ה־p99 של ההצלחות הוא עשר מילישניות, אבל 10% מן הלקוחות לא קיבלו תוצאה בזמן. הדוח חייב להציג את שני הנתונים יחד, ולא לכנות את הראשון p99 של כלל הבקשות.

בבדיקת spike נרשום גם זמן התאוששות: כמה זמן עבר עד שה־queue חזר לרמה רגילה וה־latency ירד אחרי שהעומס הופחת. אם memory נשאר גבוה, נבדוק אם מדובר ב־cache מתוכנן או באובייקטים שנשארו נגישים. אם fd-ים אינם חוזרים ל־baseline, נאתר סוג descriptor לפני שנאשים את ה־allocator.

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

בשחזור נעתיק את ה־backup אל נתיב חדש, נריץ בדיקת פורמט ו־recovery על העותק ורק אז נבצע מעבר פעיל לפי פרוטוקול הדורות. גרסה לא נתמכת תעצור את התהליך בלי לכתוב לתוך ה־backup. הדוח יציין RTO שנמדד ו־RPO שנובע ממועד הגיבוי והעבודות שאושרו מאז, בלי להציג "השחזור הצליח" כאילו לא אבד שום מידע.