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

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

מתחילים בתרחיש עבודה אחד

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

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

בדיקההתוצאה שנבדקה במעבדה
עובד מבקש רשומה של עובד אחרהגישה נדחית
מנהלת מבקשת רשומה מארגון אחרהגישה נדחית
עובד מנסה לשנות סטטוס שמיועד למנהלתהפעולה נדחית בשרת
פג תוקף ההתחברותנדרשת התחברות מחדש
מנהלת קוראת פנייה בארגון שלההרשומה מוחזרת

מה קורה כששמירה נכשלת באמצע

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

הוספנו גם מפתח בקשה: שני ניסיונות זהים עם אותו מפתח מחזירים רשומה אחת. שימוש באותו מפתח עם נתונים שונים מחזיר התנגשות. ההבחנה חשובה כאשר המשתמש לוחץ שוב או כשהתגובה מהשרת אינה מגיעה.

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

גיבוי נבדק באמצעות שחזור

תרחיש לדוגמה: שני עובדים מעדכנים אותה פנייה

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

להציג התנגשות כהחלטה של המשתמש

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

להבחין בין מידע עסקי למצב של המסך

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

תוצאה צפויה לפני כתיבת הבדיקה

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

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

הרשאות צריכות ללוות את הנתונים

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

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

שחזור הוא תהליך עבודה

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

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

מה כלול בתרגיל ומה עדיין חסר

ערכת המערכת להורדה כוללת שרת מקומי, מסך בעברית, ארבעה חשבונות תרגול ובדיקות אוטומטיות. לאחר חילוץ אפשר להריץ node server.mjs ולפתוח את הכתובת המקומית שמודפסת. משתמשים רק בפרטים הבדיוניים המצורפים.

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

איך משתמשים ב־AI כדי להשלים את הפערים

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

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

מסירה שמאפשרת להמשיך לעבוד

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

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

לבחור תיקון שאפשר להוכיח

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

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

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

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

שאלות נפוצות

האם מעבר הבדיקות אומר שהמערכת מאובטחת?

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

חייבים לבנות את הפרויקט מחדש?

לא בהכרח. מתחילים בבדיקת הקוד והנתונים ומדרגים פערים. לפעמים אפשר לשמור על הממשק ולהחליף רק את שכבת השמירה או ההרשאות.

איך מתקדמים עם גרסה ראשונה שכבר בניתי?

שלחו תיאור של המערכת ושל מי שאמור להשתמש בה. אפשר לבדוק את הגרסה הקיימת, להגדיר מה חסר ולהשלים פיתוח והפעלה בהתאם להיקף שסוכם.