AI Regression Detection — איתור תקלות שנוצרו בעקבות שינוי קוד

מאת צוות מדיה דיל · 09.08.2026 · AI · 7 דק׳

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

צוות מוציא פיצ'ר חדש - הוספת שדה אופציונלי לטופס הרשמה. שלושה ימים אחר כך מתגלה שתהליך ה-onboarding לעסקים, שלא נגע בקוד הזה כלל, מתחיל לזרוק שגיאות אצל 8% מהמשתמשים. מסתבר שהשדה החדש שינה את המבנה של אובייקט שה-onboarding קורא ממנו נתונים בהנחה על מבנה קודם. זו רגרסיה קלאסית - שינוי בקוד אחד ששובר התנהגות בקוד אחר, לגמרי לא קשור לכאורה. ככל שמערכות גדלות ומורכבות התלויות ביניהן עולה, זיהוי רגרסיות הופך לאתגר הנדסי אמיתי, ו-AI Regression Detection נבנה בדיוק כדי לתפוס את הבעיות האלה - לפני שהן הופכות לתקלת production שלקוחות מרגישים.

עלות הרגרסיה כפונקציה של זמן גילוי

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

למה בדיקות רגרסיה קלאסיות לא תמיד מספיקות

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

שלוש שכבות זיהוי משלימות

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

• ניתוח Impact לפני Merge - שימוש בגרף תלויות (ראו מיפוי ריפו) כדי לזהות מראש אילו מודולים אחרים עלולים להיפגע משינוי, גם אם הם לא מוזכרים ב-diff עצמו.
• Diff סמנטי בין גרסאות - השוואה לא רק של הקוד עצמו, אלא של ההתנהגות בפועל - הרצת אותם קלטים על הגרסה הישנה והחדשה והשוואת פלטים, כדי לתפוס שינויי התנהגות לא-מכוונים.
• ניטור אנומליות בפרודקשן - זיהוי חריגה סטטיסטית במטריקות (שיעור שגיאות, latency, המרות) מיד אחרי deploy, לפני שהבעיה מצטברת לנזק גדול.

שלוש השכבות פועלות בשלבי זמן שונים - impact analysis לפני merge, diff סמנטי בשלב ה-CI, וניטור אנומליות אחרי deploy בפרודקשן - וביחד נותנות רשת ביטחון שמכסה גם את מה שנתפס לפני שהקוד יצא, וגם את מה שרק מתגלה בתנאי עומס אמיתיים.

ניתוח Impact - "מה עוד עלול להישבר"

הרעיון המרכזי הוא לענות על השאלה לפני שהיא הופכת לבעיה: אם משנים את הפונקציה הזו, מי עוד תלוי בה - ישירות או בעקיפין? גרף תלויות סטטי (imports, קריאות פונקציה) עונה על חלק מהשאלה, אבל תלויות עקיפות - סכימת מסד נתונים משותפת, event שמפורסם ונצרך על ידי כמה שירותים, קונפיגורציה גלובלית - דורשות מיפוי נוסף שלא תמיד נראה בניתוח AST פשוט. סוכן AI שמבצע impact analysis טוב משלב את שני סוגי המקורות, וכשהוא מזהה "רדיוס פגיעה" רחב, הוא יכול לסמן PR כדורש בדיקה מוגברת או ביקורת ידנית נוספת, גם אם השינוי עצמו נראה קטן וממוקד.

Diff סמנטי - השוואת התנהגות, לא רק קוד

diff טקסטואלי רגיל מראה אילו שורות השתנו, אבל לא אומר כלום על השלכות ההתנהגות. diff סמנטי הולך צעד נוסף: מריץ קלטים מייצגים (מבחינה אידיאלית, קלטים אמיתיים מתועדים מלוגי production) גם על הגרסה הישנה וגם על החדשה, ומשווה פלטים. כשיש הבדל בפלט שלא היה מכוון - למשל שינוי בפורמט תאריך, או ערך ברירת מחדל שהשתנה בטעות - זה מסומן כרגרסיה חשודה, גם אם אף בדיקה קיימת לא נכשלה. הגישה הזו שימושית במיוחד ל-refactoring ששומר על ממשק חיצוני זהה - היא תופסת בדיוק את המקרים שבהם ה"כוונה" הייתה לשמר התנהגות אבל בפועל היא השתנתה בטעות.

{
  "function": "formatCurrency(amount, locale)",
  "sampled_inputs": 500,
  "differences_found": 3,
  "examples": [
    {"input": [1000, "he-IL"], "before": "1,000.00 ₪", "after": "1000 ₪"}
  ],
  "verdict": "regression_suspected"
}

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

גם עם impact analysis ו-diff סמנטי, חלק מהרגרסיות רק מתגלות בתנאי עומס אמיתיים ובנתוני production אמיתיים - קומבינציות נדירות שאף בדיקה לא כיסתה. שכבת ניטור מבוסס אנומליות משווה מטריקות מיד אחרי deploy לבייסליין היסטורי, ומזהה חריגה - עלייה בשיעור שגיאות, ירידה בהמרות, latency לא רגיל - שמתואמת זמנית עם ה-deploy האחרון. הזיהוי המוקדם הזה מאפשר rollback מהיר, לפני שהבעיה משפיעה על אחוז גדול מהמשתמשים. השילוב עם תשתית self-healing יכול אפילו לבצע rollback אוטומטי כשהאנומליה חוצה סף ברור וודאי, עם דיווח מיידי לצוות.

שילוב עם סוכני קוד אוטונומיים

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

תעדוף - לא כל שינוי דורש אותה רמת בדיקה

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

דוגמה מהשטח: חזרה לתרחיש הפתיחה

נחזור לדוגמת שדה ההרשמה החדש. עם שכבת impact analysis פעילה, כשה-PR שמוסיף את השדה נפתח, המערכת סורקת את גרף התלויות ומזהה שאובייקט המשתמש שהשתנה נצרך גם בקובץ onboarding.ts - קובץ שה-diff עצמו לא נגע בו כלל, אבל הוא תלוי במבנה הנתונים שהשתנה. זה מייצר אזהרה אוטומטית על ה-PR: "שינוי במבנה User Object משפיע גם על 3 קבצים נוספים שלא נבדקו". ה-reviewer האנושי, שבלי האזהרה הזו כנראה לא היה חושב לבדוק onboarding בכלל, יכול כעת לוודא במפורש שהקוד הישן שם מטפל נכון בשדה החדש (או בהיעדרו). זו בדיוק סוג התקלה ש-impact analysis תוכנן לתפוס - לא שגיאה בקוד עצמו, אלא השלכה לא-צפויה על מודול רחוק.

אתגר טכני: הגדרת Baseline לניטור אנומליות

ניטור אנומליות דורש הגדרה ברורה של "מה נורמלי", וזו לא משימה טריוויאלית. מטריקות עסקיות משתנות באופן טבעי לפי שעה ביום, יום בשבוע, ועונתיות - שיעור שגיאות ב-3 בבוקר יכול להיראות "גבוה" רק בגלל שנפח התעבורה נמוך והרעש הסטטיסטי גדול יחסית. baseline נאיבי שמשווה רק למספר קבוע ייצר הרבה false positives. גישה טובה יותר משתמשת בהשוואה למגמה היסטורית מותאמת עונתיות - אותה שעה באותו יום בשבוע לאורך כמה שבועות אחורה - ומחשבת סטיית תקן צפויה, לא רק ממוצע. ככל שיש יותר נתונים היסטוריים איכותיים, כך אפשר להבחין טוב יותר בין רעש טבעי לבין אנומליה אמיתית שקשורה ל-deploy אחרון.

טעויות נפוצות

• הסתמכות רק על בדיקות קיימות - לא תופסת רגרסיות בתחומים שאף בדיקה לא כיסתה מלכתחילה.
• התעלמות מתלויות עקיפות - סכימת נתונים או event schema משותפים שלא נראים בניתוח קוד סטטי.
• אין תעדוף לפי סיכון - הרצת אותה רמת בדיקה מקיפה על כל שינוי מייקרת ומאיטה בלי הצדקה.
• חוסר ניטור אחרי deploy - הסתמכות רק על מה שנתפס לפני שהקוד יצא, בלי רשת ביטחון בפרודקשן עצמה.

שאלות נפוצות

מה ההבדל בין Regression Detection ל-Root Cause Analysis?

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

איך diff סמנטי מתמודד עם side effects כמו כתיבה למסד נתונים?

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

האם AI Regression Detection דורש שינוי בתהליך ה-CI הקיים?

לרוב כן - impact analysis צריך לרוץ כשלב נוסף לפני merge, וCI/CD מבוסס AI מתאר איך משלבים שלבים כאלה בלי להאט את מהירות המשלוח הכללית.

מה קורה כשמזהים רגרסיה אחרי שהקוד כבר בפרודקשן?

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

איך מונעים false positives רבים מדי בניטור אנומליות?

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

האם אפשר להריץ Regression Detection על מונורפו עם עשרות שירותים?

כן, אבל זה דורש מיפוי תלויות שחוצה גבולות שירות - לא רק imports בתוך אותו קוד, אלא גם חוזי API, event schemas, וסכימות מסד נתונים משותפות בין שירותים.

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

תגיות: Regression Detection · Impact Analysis · Semantic Diff · Anomaly Detection · CI/CD · Production Monitoring · AI

← חזרה לבלוג · צור קשר