פתרון פרויקט תחקיר מערכת נוספת

הפתרון מתחיל בקיבוע גרסה ובהפרדה בין שתי חבילות הראיות. לתקלה של client איטי בודקים איזה אוסף מחזיק bytes לאחר שהשליחה נעצרה. לתקלה בשדרוג בודקים איזה reader קיבל איזה schema ומה כבר אושר לפני המעבר. אין סיבה להניח שאותו שינוי יפתור את שתיהן.

בתרחיש הראשון ניסוי מבחין משאיר את קצב הproducer קבוע ומאט רק את הconsumer. אם retained memory גדל לפי ההפרש בקצבים, בודקים תורים וbuffers ולא רק את הallocator. התיקון מגדיר capacity ומדיניות דחייה או המתנה, עם מדד שמראה כמה עבודה לא התקבלה.

בתרחיש השני מייצרים snapshot קטן עם נתונים קיימים ומפסיקים את הmigration בכל שלב. משווים את manifest הפעיל ואת הschema של הbytes. אם binary ישן קורא format חדש, התיקון צריך להגדיר תאימות או למנוע rollback שאינו חוקי, ולא רק לתפוס exception מאוחר.

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

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

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