מערכת המידע איטית או תקולה: האם ה־AI יודע מה באמת קרה?
מאת: יהודה לסרי | מנכ"ל Ryltech
18.09.2026
תקציר
כמעט כל ארגון יכול להעביר לוגים ונתוני ניטור לכלי AI ולקבל בתוך שניות תשובה שנשמעת מקצועית.
אבל השאלה החשובה באמת היא לא כמה מהר התקבלה התשובה, אלא האם המודל קיבל את העובדות הנכונות.
על מנת להבין מה קרה בפועל בסביבת הייצור, המודל זקוק לנתונים תפעוליים, להיסטוריה ולהקשר. תקלה שנחשפת במסד הנתונים עשויה להתחיל בשרת, ביישום או בשינוי שבוצע קודם.
כאשר מחברים מידע ממסד הנתונים, מהשרת, ממערכת ההפעלה ומהיישום עם יכולות AI, ניתן לקצר את זמן התחקור, לזהות קשרים בין אירועים ולקבל החלטות על בסיס תמונה רחבה יותר.
כמעט כל מנהל מערכות מידע כבר נשאל כיצד הארגון שלו משתמש ב־AI.
זו גם אחת הציפיות המרכזיות של ארגונים מהשימוש ב-AI לזהות בעיות מהר יותר, לחסוך זמן ולהפיק יותר ערך מהמידע שכבר קיים בארגון.
הכלים נגישים מאי פעם. אפשר להעביר לכלי AI ארגוני לוג, נתוני ניטור או פלט של שאילתה, ובתוך שניות לקבל הסבר, כיוון לבדיקה ולעיתים גם המלצה לפתרון.
אבל בסביבת ייצור לא די בתשובה שנשמעת משכנעת.
בזמן אמת, בעת תקלה, תשובה ללא עומק מתארת רק תרחיש אפשרי ולא בהכרח את מה שהתרחש בפועל.
ה־AI אינו מכיר את סביבת השרתים מעצמו
נניח שמשתמש מדווח שהתנתק מהמערכת, שמסך מסוים נתקע או שתהליך עסקי הפך לאיטי.
מודל AI כללי יכול להציע סיבות אפשריות כך לדוגמא: בעיית תקשורת, עומס על השרת, שאילתה איטית, מחסור בזיכרון או תקלה בשירות.
כל אחת מהאפשרויות סבירה, אך ללא נתונים מהסביבה המודל אינו יודע מה קרה בפועל באותו רגע.
האם שירות אפליקטיבי נעצר? האם תוכנת אבטחה סרקה קבצים קריטיים?האם בוצע עדכון תוכנה או שרת? האם תוכנית הביצוע השתנתה? האם היישום החזיר שגיאה?או שהבעיה נגרמה מעומס חריג של בקשות?
ללא גישה למידע התפעולי, כלי ה־AI אינו מתחקר את האירוע עצמו, אלא הוא מנסח השערות על סמך הידע הכללי שלו.
לעומת זאת, AI שמחובר לנתונים התפעוליים ולהיסטוריה של סביבת הייצור יכול לנתח את האירוע בהקשר שלו, לזהות קשרים בין אירועים ולסייע להגיע מהר יותר להבנת מקור הבעיה.
במילים פשוטות: AI יכול לתת תשובה במהירות, אבל כדי להבין מה באמת קרה - הוא צריך את הנתונים הנכונים.
לא כל חריגה היא תקלה
גם נתון מדויק עלול להוביל למסקנה שגויה ללא הקשר מתאים. נניח שתהליך מסוים נמשך דקה או שלוש שניות. האם הוא איטי? מהנתון הזה בלבד אי אפשר לדעת.
אם התהליך נמשך בדרך כלל חצי שנייה, ייתכן שמתחילה הידרדרות. אם הוא תמיד נמשך כשלוש שניות, ייתכן שזו התנהגות תקינה. אם הוא מתבצע פעם ביום, השפעתו מוגבלת; אם הוא מתבצע אלפי פעמים בשעה, גם עיכוב קטן עלול ליצור עומס משמעותי.
כאן בדיוק ה־AI יכול לספק ערך, בתנאי שהוא מחובר לנתונים ומחפש את ההקשר הנכון.
משווים את זמן הריצה להיסטוריה, בודקים אם התדירות השתנתה, האם תוכנית הביצוע התחלפה ומה עוד התרחש בסביבה באותו חלון זמן. כך ה־AI נעזר בעובדות ומסייע לחבר ביניהן, לזהות חריגות ולדייק את הבדיקה.
הבעיה שמופיעה במסד הנתונים יכולה להתחיל במקום אחר
אחד האתגרים המוכרים בתחקור תקלות הוא שכל צוות בוחן את השכבה שבאחריותו: צוות היישום בודק את הקוד, איש התשתיות בוחן מעבד וזיכרון, וצוות ה־DBA בודק שאילתות, נעילות ותוכניות ביצוע. כל אחד רואה חלק אחר של התמונה.
המשתמש אינו חווה את המערכת בשכבות. מבחינתו המערכת איטית או אינה זמינה.
כדי להבין מה קרה צריך לחבר בין פעילות מסד הנתונים, משאבי השרת, תהליכים פעילים, אירועים במערכת ההפעלה ופעילות היישום.
במערכות Web חשוב לדעת אילו בקשות הגיעו ליישום, אילו פעולות הופעלו והאם נרשמו שגיאות קוד. במקביל יש לבדוק אילו שאילתות רצו, מה צרך משאבים ומה השתנה בהגדרות השרת ומסד הנתונים, באובייקטים או בהרשאות. גם התקנות, עדכונים ושדרוגים עשויים להשפיע.
אנחנו מתחילים פעמים רבות במסד הנתונים, משום שהוא מהווה מקור מרכזי לזיהוי בעיות במערכת. עם זאת, אנחנו לא עוצרים שם. המטרה היא לבחון את יתר שכבות המערכת, לחבר את המידע שמגיע ולהבין היכן הבעיה התחילה.
מערכת AimBetter מחברת את התמונה
זו התפיסה שמובילה את פיתוח AimBetter: מתחילים במסד הנתונים, אך לא עוצרים שם.
יכולות ה־AI הן חלק ממערכת הניטור ואינן כלי נפרד שמקבל בכל פעם קובץ או צילום רגעי.
המערכת מרכזת מידע ממסד הנתונים, מהשרת, ממערכת ההפעלה ומהיישום, ושומרת היסטוריה לצורך השוואה. כך אפשר לבדוק אם תהליך נעשה איטי ביחס לעבר, אם תוכנית הביצוע שלו השתנתה, אילו שגיאות הופיעו באותו זמן ומה השתנה לפני תחילת הבעיה.
במקום לעבור ידנית בין מסכים ורשומות, ניתן להתמקד בממצאים ובשאלות ממוקדות:
מה השתנה בשעה האחרונה?אילו אירועים עשויים להיות קשורים לאיטיות?האם ההתנהגות הנוכחית חריגה ביחס לעבר?ומהו כיוון הבדיקה הסביר ביותר?
מהתראה לתחקור – בשליטה של ה־IT
הרעיון הוא לאפשר לצוותי ה־IT להשתמש במידע שכבר קיים בארגון כדי לנטר, לשאול, לתחקר ולהפיק תובנות באופן עצמאי.
מערכתAimBetter נועדה לאפשר לארגון לשמור על הבעלות המקצועית ועל ההחלטה כיצד לפעול, כאשר המערכת מסייעת לרכז את הנתונים, לזהות חריגות ולהציג את הקשר.
לפי הצורך ניתן להיעזר בתמיכה ובהדרכה, או לשלב מומחה DBA בחקירה עמוקה וביישום שינוי בסביבת הייצור.
המערכת מסייעת; האחריות נשארת בידי אנשי המקצוע
גם מערכת מתקדמת פועלת בתוך הקשר ארגוני. אנשי הארגון יודעים אילו תהליכים קריטיים, מה השתנה לאחרונה ומהי רמת הסיכון המותרת.
המערכת מסייעת להם להתמקד בנתונים הרלוונטיים, לקצר את החקירה ולבחון את ההמלצות לפני ביצוע.
כאשר נדרשת חקירה עמוקה יותר, אפשר לשלב את צוות ה־DBA של Ryltech בטיפול ממוקד.
הצוות עובד עם המערכת מדי יום ומתמודד עם אירועים ותקלות אמיתיים בסביבות ייצור. הניסיון המעשי מאפשר לנו להבין לא רק מה נכון מבחינה טכנית, אלא גם אילו פעולות ניתן לבצע בבטחה, תוך התחשבות בהשפעה האפשרית על המערכת ועל הפעילות העסקית.
העבודה לאורך השנים עם כ־800 לקוחות וכ־2,500 שרתי דאטאבייס חשפה אותנו למגוון רחב של תקלות, תרחישים ודפוסי התנהגות. הניסיון המצטבר הזה מאפשר לנו להמשיך לשפר ולדייק את המערכת, את ההמלצות שהיא מספקת ואת אופן השימוש בה.
בסופו של דבר, האחריות נשארת אנושית
כלי AI יכול לעבור במהירות על כמויות מידע גדולות, לזהות קשרים ולחסוך שעות של חקירה, אבל הוא אינו מכיר לבדו את הארגון, לא תמיד מבין את המשמעות העסקית ואינו נושא באחריות לתוצאה.
המודל הנכון לסביבת ייצור אינו בחירה בין אדם לבין AI. הוא שילוב בין מערכת שאוספת את העובדות, כלי AI שמסייע לחבר ולנתח אותן, ואיש מקצוע שמבין את ההקשר ומחליט כיצד לפעול.
הערך של AI בסביבת ייצור אינו נמדד רק במהירות התשובה, אלא ביכולת להגיע לתשובה מבוססת ולפעול בשליטה.
על הכותב
יהודה לסרי | מנכ״ל Ryltech שירותי DBA ו־AimBetterדוא״ל: yehuda@aimbetter.com
תגובות