מוצר

נתונים הם התנהגות המוצר

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

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

נתונים הם התנהגות המוצר, לא רק מקום אחסון#

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

מקור אמת וגבולות אחריות#

Source of Truth — מקור אמת: איפה נמצא הערך המחייב של כל סוג מידע? אם גם הגיליון, גם מסד הנתונים וגם ה-AI יכולים לעדכן מחיר, מי מכריע בסתירה? ריבוי מקורות אמת אינו רק בעיית סנכרון; הוא מייצר החלטות עסקיות סותרות.

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

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

מצבים, כפילויות ופעולות שנקטעו#

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

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

גיבוי אינו שחזור#

"יש גיבוי" אינו מספיק. צריך להגדיר RPO — כמה נתונים מותר, מבחינה עסקית, לאבד בנקודת התאוששות; ו-RTO — כמה זמן מותר להימשך עד שהשירות חוזר לפעול. לשני המדדים קובעים יעדים בהתאם לסיכון וליכולת, לא מספר קסם אוניברסלי. יש להראות ששחזור נבדק לסביבת בדיקה ושהנתונים וההרשאות נותרו תקינים. שמירה של dump שאיש לא ניסה לשחזר ממנו אינה ראיה להתאוששות.

בדיקה מעשית#

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

PR-04