קוד שנוצר ב-AI ונוגע בחיובים דורש בקרות של נכונות פיננסית: הפרדת סביבות, בדיקות למסלול הכסף, אידמפוטנטיות, התאמה יומית ואישור אנושי לפני עלייה.
עיקרי הדברים
- אבטחה שואלת מי נכנס. נכונות פיננסית שואלת האם הסכום, המטבע והפעם היו נכונים. שתי שאלות שונות, שתי מערכות בקרה.
- הכשל הנפוץ בקוד תשלומים אינו פרצה אלא חיוב כפול, וכמעט תמיד הוא נולד מניסיון חוזר בלי מפתח אידמפוטנטיות.
- סביבת בדיקה שמדברת עם מפתח ייצור אינה סביבת בדיקה. ההפרדה נאכפת בקונפיגורציה, לא במשמעת.
- התאמה יומית היא הבקרה היחידה שתופסת שקט. עסקה שנכשלה בשקט לא מייצרת שגיאה, רק פער.
- מסלול ביקורת בלי מזהה שמחבר בקשה, עסקה ורשומה חשבונאית לא יאפשר לענות על שאלה של רואה חשבון.
קוד שנכתב בעזרת AI ונוגע בחיובים, בזיכויים או בהעברות כסף צריך חמש בקרות שאינן קשורות כלל לאבטחה: הפרדת סביבות אמיתית, סט בדיקות שמכסה את מסלול הכסף, אידמפוטנטיות בכל פעולה כספית, התאמה יומית מול הספק, ואישור אנושי מתועד לפני העלייה לאוויר.
למה נכונות פיננסית היא לא אותה בעיה כמו אבטחה?
מפני שהיא נשברת גם כשאף אחד לא תוקף. חיוב כפול, מטבע שהתחלף, עיגול שנופל לכיוון אחד וזיכוי שנרשם פעמיים הם באגים של לוגיקה עסקית שמתרחשים בתנועה תקינה לחלוטין. סקירת אבטחה טובה לא תתפוס אף אחד מהם, ולכן שתי הסקירות משלימות ולא מחליפות זו את זו. הצד השני, זה שכן שואל מי נכנס, מכוסה בסיכוני אבטחה בקוד שנוצר על ידי AI.
יש כאן גם הבדל בהתנהגות המודל. קוד שנוצר במהירות נוטה למסלול המוצלח: תשלום שעובר, לקוח יחיד, רשת יציבה. מסלול הכסף האמיתי מורכב בעיקר מהמקרים האחרים, וזה בדיוק מה שלא נכתב בלי שביקשו במפורש.
הפרדת סביבות: מה "מצב בדיקה" חייב להיות בפועל
- מפתחות ייצור לא קיימים במחשב הפיתוח ולא בקובץ שנמצא בגיט.
- הסביבה נבחרת ממשתנה סביבה יחיד, ולא מדגל בקוד שאפשר לשכוח.
- מסד הנתונים של הבדיקות נפרד לחלוטין, כולל גיבויים ותורים.
- שליחת דוא"ל וחיובים אמיתיים חסומים בסביבת בדיקה, לא רק "לא בשימוש".
- העתקת נתוני ייצור לסביבת בדיקה עוברת שלב הסתרה של פרטי לקוח.
- לוג ההפעלה מציין בבירור באיזו סביבה הוא רץ, בשורה הראשונה.
הכלל הפשוט: אם קיים תרחיש שבו הרצה מקומית יכולה לחייב כרטיס אמיתי, ההפרדה לא קיימת. רקע כללי על ההפרדה הזאת יש בסביבת בדיקה מול סביבת ייצור.
הבדיקה המעשית לוקחת חמש דקות: חפשו במאגר הקוד את התחילית של מפתח הייצור, ואז הריצו את המערכת מקומית ובדקו לאיזו כתובת היא פונה בפועל. שני הממצאים האלה תופסים את רוב מקרי הדליפה בין הסביבות, והם נמצאים לפני שנכתבה שורת בדיקה אחת.
מה סט הבדיקות למסלול הכסף חייב לכסות?
הבדיקה החשובה כאן היא לא "התשלום עבר" אלא "מה קרה כשלא". טבלת המקרים הבאה היא המינימום, וכל שורה בה מייצגת באג שכבר קרה למישהו.
| מקרה | מה נבדק | מה חייב לקרות |
|---|---|---|
| חיוב מוצלח | סכום, מטבע ורשומה | רשומה אחת בדיוק, סכום זהה |
| כשל אצל הספק | טיפול בשגיאה | אין רשומת הצלחה, יש רשומת ניסיון |
| תשובה שאבדה ברשת | ניסיון חוזר | אותו מפתח, לא חיוב שני |
| שתי לחיצות מהירות | מניעת כפילות | חיוב אחד, שתי בקשות |
| החזר חלקי | חישוב יתרה | היתרה תואמת את סכום ההחזר |
| מטבע שונה | המרה ועיגול | אין המרה מרומזת, אין עיגול כפול |
| עדכון סטטוס שהגיע פעמיים | טיפול בהודעות ספק | עדכון אחד, לא שניים |
| עסקה שנשארה תלויה | תהליך ניקוי | סגירה מפורשת או התראה |
שלוש השורות האמצעיות הן אלה שקוד שנכתב מהר כמעט תמיד מפספס, מפני שכולן דורשות לחשוב על מה שקורה בין הבקשה לתשובה.
אידמפוטנטיות וחיוב כפול
אידמפוטנטיות פירושה שבקשה שנשלחה פעמיים מייצרת תוצאה אחת. במונחי תשלומים: הלקוח מחויב פעם אחת גם אם הרשת אכלה את התשובה והמערכת ניסתה שוב.
- צרו מפתח ייחודי לפעולה הכספית לפני הקריאה הראשונה, לא בזמן הניסיון החוזר.
- שמרו את המפתח ברשומת ההזמנה, כך שהוא ישרוד ריסטארט של השרת.
- שלחו את אותו מפתח בכל ניסיון חוזר של אותה פעולה בדיוק.
- אל תשתמשו במפתח מחדש לפעולה אחרת, גם אם היא נראית זהה.
- טפלו בתשובת "כבר טופל" כהצלחה ולא כשגיאה.
- בדקו את המסלול הזה בבדיקה אוטומטית שמדמה תשובה שאבדה.
ספקי תשלומים מתעדים את המנגנון הזה במפורש, ובכל זאת הוא נעדר בקוד שנוצר במהירות, כי בזרימה המוצלחת הוא לא נדרש. זו בדיוק ההגדרה של בקרה: משהו שמיותר עד הרגע שבו הוא היחיד שמונע נזק.
המלכודת הנפוצה השנייה היא מפתח שנוצר מנתוני ההזמנה, למשל מזהה לקוח וסכום. שתי הזמנות זהות באמת של אותו לקוח יקבלו אז מפתח זהה, והשנייה תיבלע בשקט. מפתח אידמפוטנטיות צריך להיות ייחודי לניסיון העסקי ולא נגזר מתוכן שיכול לחזור על עצמו.
התאמה יומית: הבקרה שתופסת את מה ששתק
התאמה היא השוואה יומית בין שלושה מקורות: מה שהמערכת שלכם רשמה, מה שהספק מדווח, ומה שנרשם בהנהלת החשבונות. פער נחשב ממצא גם כשאין שגיאה בשום לוג.
- ספרו עסקאות ולא רק סכומים. שתי טעויות יכולות להתקזז לסכום נכון.
- השוו לפי מזהה עסקה, ולא לפי סכום ותאריך.
- הפרידו בין פער זמני, כמו הפרש יום עסקים, לבין פער אמיתי.
- הריצו את ההשוואה כל יום, גם ביום שבו לא היה כלום.
- שלחו התראה על פער, ולא דוח שמישהו אמור לפתוח.
- שמרו את תוצאת ההתאמה, כדי שאפשר יהיה לחזור אליה בעוד חצי שנה.
עסקה שנכשלה בשקט לא מייצרת שגיאה ולא התראה. היא מייצרת רק פער, ולכן ההתאמה היא הבקרה היחידה שתמצא אותה. שיטות ההשוואה עצמן זהות לאלה שמתוארות בהתאמת עסקאות אשראי.
אישור אנושי ומסלול ביקורת
- שינוי שנוגע בסכומים, במטבע או בעיגול עובר קריאה של אדם, גם אם הבדיקות עברו.
- העלייה לאוויר נעשית בשלב, למשל אחוז קטן מהתנועה, לפני פתיחה מלאה.
- לכל פעולה כספית נשמרים מזהה בקשה, מזהה אצל הספק ומזהה הרשומה החשבונאית.
- הלוג מציין מי אישר, מה הגרסה, ומתי עלתה.
- קיים נוהל חזרה לאחור כתוב, כולל מה עושים עם חיובים שכבר בוצעו.
הפריט השלישי הוא זה שמכריע כשמגיעה שאלה מרואה חשבון. שלושת המזהים הם מה שהופך את השאלה "מה קרה בעסקה הזאת" לשאילתה אחת במקום לחקירה, וזה תקף בין אם את הקוד כתב אדם או מודל.
לגבי חזרה לאחור יש הבדל שלא תמיד מובן: בקוד רגיל אפשר להחזיר גרסה ולסיים. בקוד שמנהל כסף, החזרת הגרסה לא מבטלת חיובים שכבר בוצעו, ולכן הנוהל חייב לכלול גם את הצד הכספי: מי מזהה את העסקאות המושפעות, מי מבצע החזר, ומה נרשם בהנהלת החשבונות.
מקורות
שאלות נפוצות
האם בדיקות אוטומטיות מספיקות לקוד שמנהל כסף?
הן הכרחיות ולא מספיקות. בדיקות מכסות מקרים שחשבו עליהם, וההתאמה היומית תופסת את מה שלא חשבו עליו. שתי הבקרות פועלות בזמנים שונים: הבדיקות לפני העלייה, ההתאמה כל יום אחריה, וכל אחת מוצאת סוג אחר של פער.
מה עושים כשמתגלה חיוב כפול בייצור?
עוצרים את המסלול שיצר אותו, מזהים את כל העסקאות המושפעות לפי המפתח, ומבצעים החזר דרך הספק ולא בעריכה ידנית של רשומות. אחרי הטיפול מוסיפים מקרה בדיקה עם התרחיש המדויק, כדי שאותו כשל לא יחזור בשקט.
האם ספק תשלומים לא מונע חיוב כפול לבד?
הספק מספק את המנגנון, אבל מפעיל אותו רק אם הקוד שולח מפתח ייחודי. בלי מפתח, שתי בקשות זהות הן שתי עסקאות לגיטימיות מבחינת הספק. האחריות על יצירת המפתח ושמירתו נמצאת אצל המערכת שקוראת, לא אצלו.
מה בודקים ראשון בקוד תשלומים שנוצר ב-AI?
בודקים אם קיים מפתח אידמפוטנטיות, אם המטבע מוגדר במפורש ולא מונח, ואם יש טיפול בתשובה שלא חזרה. שלושת הפריטים האלה מכסים את רוב הכשלים הפיננסיים בקוד שנכתב מהר, והם נראים בקריאה של דקות ספורות.
להמשך קריאה
שירות רלוונטי
אוטומציה לעסקים
אני בונה אוטומציות מותאמות שמורידות עבודה חוזרת מקצה לקצה.
על הכותב
יהונתן סעדיה
מפתח פרילנסר לאוטומציה, אתרים ו-MVP
אני יהונתן סעדיה, מפתח בכיר שבונה אוטומציה עסקית, אתרים מותאמים ומוצרי MVP לעסקים קטנים ובינוניים בארה"ב, אירופה וישראל. המדריכים האלה נכתבים מתוך עבודה אמיתית עם לקוחות, לא מתיאוריה.
בוא נעבוד יחדיש לך פרויקט דומה?
ספר לי מה אתה רוצה לבנות או איזה תהליך להפוך לאוטומטי. אני חוזר תוך 24 שעות עסקים עם כמה שאלות ממוקדות, ואז עוברים על זה יחד בשיחת היכרות חינמית של 30 דקות, בלי התחייבות. בסוף יש לך היקף עבודה, לוח זמנים ומחיר קבוע - או תשובה כנה שלא שווה לבנות את זה.