Architecture Defect — Enterprise Software Vendor
Did an architectural defect in the SaaS platform cause the data loss at the centre of the claim?
This case study was authored in Hebrew (the canonical language). The English version presents the same technical content.
השאלה הטכנית
לקוח של ספק פלטפורמת SaaS ארגונית טען כי תקרית אובדן נתונים נגרמה על ידי פגם בתכנון הארכיטקטורה של הפלטפורמה. הספק טען כי הכשל נבע מתצורה שגויה של המשתמש. בית המשפט מינה מומחה כדי להכריע בין שני הפרשנויות.
הגישה
בחינת קוד המקור, תיעוד הארכיטקטורה, יומני המערכת, ואירועי הנתונים של יומן ה-WAL בחלון של 72 שעות סביב האירוע. ניתוח רצפי האתחול מחדש, מנגנוני הגיבוי, וחישוב תקופת ה-RPO. הרצת סביבת שחזור על גבי חומרה זהה.
ממצאים מרכזיים:
- גרסת הפלטפורמה שנפרסה כללה שגיאה ידועה במנגנון ה-commit בבסיס הנתונים.
- תיעוד ה-release notes נכשל בחשיפה על הידועה.
- תצורת המשתמש לא חרגה ממסמכי ה-API הרשמיים.
התוצאה
חוות הדעת קבעה, בסבירות של למעלה מ-50%, כי הכשל נבע מהשגיאה הארכיטקטונית ולא מטעות הגדרה של המשתמש. 18 שעות אובדן נתונים ניתנות לייחוס לסיבה הזו. הסכסוך הסתיים בפשרה מחוץ לכותלי בית המשפט תוך שישה שבועות מהגשת חוות הדעת.
מה זה היה נראה בבית המשפט
בעניין טכני כזה, בית המשפט זקוק למומחה שיכול להסביר מדוע התנהגות גרסה X ≠ גרסה X+1 בשפה שיאפשר לשופט להסיק מסקנות עובדתיות. חוות הדעת סיפקה השוואת שורה-לשורה, תרשים סדרת זמן של האירוע, ותיאור פשוט של אופן הפעולה של ה-commit-log שכל שופט בעל ידע טכני בסיסי יכול היה לעקוב אחריו.
פרטים מזהים שונו; התוכן הטכני משקף עבודה בפועל.