מערכות IT הן התשתית שעליה נשענים כיום כמעט כל התהליכים העסקיים: מערכות מידע, אתרי אינטרנט, אפליקציות, בסיסי נתונים, שרתים, ממשקים, שירותי ענן ומערכות ארגוניות. כאשר אחת המערכות הללו אינה זמינה, איטית או מתפקדת באופן חלקי, ההשפעה יכולה להגיע במהירות למשתמשים, ללקוחות ולתהליכים העסקיים.
כאן נכנס לתמונה ניטור מערכות IT (IT Monitoring).
ניטור אינו מסתכם בבדיקה האם שרת "חי" או "מת". מערכת ניטור טובה צריכה לספק תמונה רציפה של מצב המערכות, לזהות חריגות, להתריע לפני שתקלות הופכות לאירוע משמעותי ולעזור לצוותי IT ו-QA להבין מה השתבש ומה דורש טיפול.
במדריך הזה נסביר מהו ניטור מערכות IT, אילו נתונים חשוב לנטר, מהם סוגי הניטור המרכזיים, איך בונים מערך ניטור נכון, כיצד QA משתלב בתהליך ומהן הטעויות הנפוצות שכדאי להימנע מהן.
מה זה ניטור מערכות IT?
ניטור מערכות IT הוא תהליך של איסוף, מדידה וניתוח רציף של נתונים ממערכות טכנולוגיות במטרה לזהות בעיות, חריגות ושינויים בהתנהגות המערכת.
הניטור יכול להתייחס למגוון רחב של רכיבים:
- שרתים
- מערכות הפעלה
- אפליקציות
- אתרי אינטרנט
- בסיסי נתונים
- רשתות ותקשורת
- שירותי ענן
- מערכות ERP
- ממשקים בין מערכות
- תורים והודעות
- תהליכי Batch
- שירותי API
- מערכות אבטחת מידע
המטרה אינה רק לדעת שמשהו התקלקל. מערך ניטור איכותי צריך לענות גם על שאלות כמו:
- מה בדיוק התקלקל?
- מתי התחילה הבעיה?
- כמה משתמשים מושפעים?
- האם מדובר בתקלה זמנית או במגמה?
- מה השתנה במערכת לפני התקלה?
- האם הביצועים הידרדרו בהדרגה?
- האם מדובר בבעיה במערכת עצמה או בממשק למערכת אחרת?
למה ניטור מערכות IT כל כך חשוב?
ללא ניטור, ארגון עלול לגלות על תקלה רק לאחר שמשתמש או לקוח מדווח עליה.
לדוגמה, נניח שמערכת ארגונית עדיין זמינה, אבל זמן התגובה שלה עלה מ-2 שניות ל-15 שניות. מבחינת בדיקת זמינות בסיסית, המערכת "עובדת". מבחינת המשתמשים, לעומת זאת, מדובר בבעיה משמעותית.
מערכת ניטור טובה יכולה לזהות את הירידה בביצועים לפני שהתקלה הופכת להשבתה מלאה.
ניטור מאפשר לכן לעבור מגישה של:
"המערכת התקלקלה – עכשיו צריך להגיב"
לגישה של:
"אנחנו מזהים סימנים לבעיה – בואו נטפל בה לפני שהיא משפיעה על המשתמשים."
מה צריך לנטר במערכת IT?
אין מדד יחיד שמספיק כדי להבין את מצב המערכת. בדרך כלל יש צורך בשילוב של מספר סוגי מדדים.
1. זמינות המערכת
המדד הבסיסי ביותר הוא האם השירות זמין.
לדוגמה:
- האם האתר עולה?
- האם שרת מגיב?
- האם API מחזיר תשובה?
- האם ניתן להתחבר למערכת?
- האם שירות מסוים פעיל?
חשוב להבין שזמינות אינה שווה לתקינות. מערכת יכולה להיות זמינה אך לא לתפקד כראוי.
2. ביצועים
ניטור ביצועים בוחן כיצד המערכת מתפקדת לאורך זמן.
מדדים נפוצים כוללים:
- זמן תגובה
- זמן טעינת עמוד
- זמן תגובת API
- מספר בקשות בשנייה
- זמן ביצוע שאילתות
- אחוז שגיאות
אחד היתרונות המשמעותיים של ניטור ביצועים הוא האפשרות לזהות הידרדרות הדרגתית ולא רק תקלה מוחלטת.
3. CPU וזיכרון
בשרתים חשוב לעקוב אחר ניצול משאבים.
לדוגמה, שימוש חריג במעבד או בזיכרון יכול להצביע על:
- עומס משתמשים
- תהליך שצורך משאבים חריגים
- דליפת זיכרון
- תהליך תקוע
- שינוי תוכנה
- בעיה בתשתית
גם כאן, לא תמיד הערך המוחלט הוא החשוב ביותר. לעיתים דווקא שינוי משמעותי ביחס להתנהגות הרגילה של המערכת הוא הסימן המעניין.
4. שטח דיסק
מחסור בשטח אחסון יכול לגרום לתקלות שקשה מאוד לאבחן.
לכן מומלץ לנטר:
- שטח פנוי
- קצב גידול הנתונים
- קבצי Log
- קבצים זמניים
- שימוש במחיצות קריטיות
במקום להמתין לכך שדיסק יגיע ל-100% שימוש, אפשר להגדיר התראה מוקדמת כאשר השימוש עובר סף שנקבע מראש.
ניטור לוגים – אחד המקורות החשובים ביותר למידע
מערכות IT מייצרות כמויות גדולות של לוגים. הלוגים יכולים לכלול מידע על פעולות משתמשים, שגיאות, חריגות, תהליכים, התחברויות, ממשקים ופעולות מערכת.
לדוגמה, שגיאה שחוזרת מאות פעמים בשעה יכולה להצביע על בעיה שעדיין לא גרמה להשבתה מלאה, אבל עלולה להתפתח לתקלה משמעותית.
לכן כדאי לחפש:
- עלייה במספר השגיאות
- שגיאות מסוג חדש
- הודעות חריגות
- כשלי התחברות
- כשלי ממשקים
- Timeout
- חריגות בביצוע תהליכים
ניטור ממשקים בין מערכות
אחד התחומים החשובים ביותר בסביבות IT ארגוניות הוא ניטור של ממשקים.
מערכת יכולה לעבוד בצורה תקינה לחלוטין ועדיין התהליך העסקי ייכשל משום שמערכת אחרת אינה מעבירה אליה מידע.
לדוגמה:
מערכת A → ממשק → מערכת B → עיבוד → מערכת C
תקלה בכל אחד מהשלבים עלולה לגרום לכך שהתהליך העסקי כולו לא יושלם.
לכן כדאי לנטר:
- האם הממשק פעיל
- האם הודעות נשלחות
- האם הודעות מתקבלות
- כמה הודעות נכשלו
- האם קיימות הודעות תקועות
- מהו זמן העיבוד הממוצע
- האם קיים פער בין כמות הרשומות שנשלחו לכמות הרשומות שהתקבלו
נושא זה מתחבר ישירות לעולם ה-QA. כאשר בודקים מערכת מורכבת, לא מספיק לבדוק כל מערכת בנפרד. חשוב לבדוק גם את ההתנהגות של הממשק ואת התהליך מקצה לקצה.
קראו גם: בדיקות אינטגרציה ב-SAP – איך לבדוק ממשקים בין מערכות
ניטור בסיסי נתונים
בסיס הנתונים הוא רכיב קריטי במערכות רבות. בעיה בבסיס הנתונים יכולה להשפיע על אפליקציות רבות במקביל.
במסגרת ניטור ניתן לעקוב אחר:
- זמן תגובת שאילתות
- עומס
- חיבורים פעילים
- שגיאות
- נעילות
- נפח נתונים
- שטח אחסון
- תהליכים ארוכים
אם לדוגמה שאילתה שבעבר הסתיימה בתוך שנייה מתחילה להימשך 20 שניות, מדובר באינדיקציה חשובה גם אם המערכת עדיין זמינה.
ניטור אפליקציות
ניטור אפליקציה צריך להיות עמוק יותר מבדיקת HTTP בסיסית.
אפשר לנטר לדוגמה:
- מספר משתמשים פעילים
- מספר בקשות
- שיעור שגיאות
- זמני תגובה
- חריגות
- שגיאות עסקיות
- קריאות לשירותים חיצוניים
- צריכת משאבים
כך ניתן להבין לא רק שהשרת עובד, אלא שהאפליקציה עצמה מתפקדת.
ניטור לעומת בדיקות QA
יש קשר חזק בין ניטור מערכות IT לבין בדיקות תוכנה, אך מדובר בשני תהליכים שונים.
| ניטור | QA |
|---|---|
| מתבצע באופן רציף בסביבת המערכת | מתבצע בהתאם לתוכנית בדיקות |
| מזהה חריגות והתנהגות בפועל | בודק האם המערכת עומדת בדרישות |
| מתמקד במצב המערכת לאורך זמן | מתמקד באיכות השינוי או המוצר |
| יכול להתריע בזמן אמת | מזהה בעיות במסגרת תהליך הבדיקות |
למעשה, שני התחומים משלימים זה את זה.
QA יכול לזהות בעיה לפני Production, בעוד שניטור יכול לזהות בעיה שמתרחשת דווקא לאחר העלייה לייצור.
למידע נוסף על עולם הבדיקות האוטומטיות אפשר לקרוא את המדריך המלא לבדיקות אוטומציה.
ניטור מערכות IT בסביבת SAP
בסביבות ארגוניות שבהן SAP מהווה מערכת מרכזית, לניטור יש חשיבות מיוחדת.
מערכת SAP אינה פועלת בדרך כלל כמערכת מבודדת. היא יכולה להיות מחוברת למערכות פיננסיות, בנקים, מערכות CRM, אתרי אינטרנט, מערכות מסמכים, מערכות שכר ומערכות ארגוניות נוספות.
לכן כדאי לבחון לא רק את זמינות SAP אלא גם:
- תהליכי Batch
- ממשקים
- קבצים נכנסים ויוצאים
- Jobs
- שגיאות
- זמני עיבוד
- תהליכים עסקיים קריטיים
במיוחד לאחר שדרוג או שינוי מערכת, חשוב לשלב בין ניטור Production לבין בדיקות מסודרות.
לדוגמה, ניתן לבצע בדיקות רגרסיה ב-SAP לפני העלייה לייצור, ולאחר מכן לעקוב באמצעות ניטור אחר ההתנהגות בפועל.
ניטור לאחר שדרוג גרסה
אחת התקופות הרגישות ביותר מבחינת מערכות IT היא התקופה שלאחר שינוי משמעותי.
שדרוג גרסה יכול לשנות:
- ביצועים
- ממשקים
- מבני נתונים
- הרשאות
- התנהגות עסקית
- תהליכי רקע
- תאימות בין מערכות
לכן מומלץ להגדיר מראש "קו בסיס" של ביצועי המערכת לפני השדרוג ולהשוות אליו את הנתונים לאחר העלייה.
זה מתחבר ישירות לתהליך של בדיקות S/4HANA לפני ואחרי מעבר.
התראות – לא כל חריגה צריכה להפעיל אזעקה
אחת הטעויות הנפוצות במערכות ניטור היא יצירת כמות גדולה מדי של התראות.
כאשר צוות IT מקבל מאות התראות ביום, חלקן חסרות משמעות, קיימת סכנה שהתרעות חשובות ילכו לאיבוד בתוך "רעש" של התראות.
לכן כדאי להגדיר רמות חומרה.
Critical
אירוע שמשפיע באופן משמעותי על מערכת או תהליך עסקי קריטי ודורש טיפול מיידי.
High
בעיה משמעותית שעלולה להתפתח להשבתה או להשפיע על משתמשים רבים.
Medium
בעיה שדורשת טיפול אך אינה מחייבת תגובה מיידית.
Low
אירוע מידע או חריגה שאינה דורשת פעולה מיידית.
הגדרת רמות נכונה מאפשרת לצוות להבין במהירות מה דורש פעולה ומה יכול להמתין.
Threshold לעומת זיהוי אנומליות
דרך פשוטה ליצור התראה היא להגדיר סף.
לדוגמה:
אם CPU > 90% במשך 10 דקות → שלח התראה.
זה שימושי, אבל לא תמיד מספיק.
מערכת יכולה לעבוד באופן רגיל עם CPU של 80%, אך אם במשך חודשים היא עבדה סביב 30% ופתאום עלתה ל-80%, ייתכן שיש כאן שינוי שדורש בדיקה.
לכן מערכות ניטור מתקדמות יותר מנסות לזהות גם חריגות ביחס להתנהגות ההיסטורית של המערכת.
ניטור Synthetic – בדיקה יזומה של המערכת
סוג נוסף של ניטור הוא Synthetic Monitoring.
במקום רק להמתין למשתמשים אמיתיים, מערכת אוטומטית מבצעת פעולות מוגדרות מראש.
לדוגמה:
- פתיחת אתר
- כניסה למסך Login
- הזנת משתמש וסיסמה
- כניסה למסך מסוים
- ביצוע פעולה
- בדיקת התוצאה
אם התהליך נכשל, מתקבלת התראה.
זה למעשה יוצר חיבור מעניין בין Monitoring לבין QA ואוטומציה.
מי שמכיר בדיקות E2E יכול להבין בקלות את הרעיון: במקום לבצע את הבדיקה רק בזמן תהליך QA, מריצים תרחיש קריטי באופן מחזורי גם לאחר שהמערכת נמצאת בייצור.
אפשר להעמיק בנושא באמצעות המדריך איך כותבים בדיקת E2E עם Playwright.
אילו כלים משמשים לניטור מערכות IT?
קיימים סוגים רבים של כלי ניטור, והבחירה תלויה בסביבה הטכנולוגית ובמטרות הארגון.
קטגוריות נפוצות כוללות:
- Infrastructure Monitoring
- Application Performance Monitoring
- Log Management
- Network Monitoring
- Database Monitoring
- Cloud Monitoring
- Synthetic Monitoring
- Observability Platforms
אין כלי אחד שמתאים לכל ארגון. מערכת גדולה יכולה להשתמש במספר שכבות ניטור שונות, כאשר כל אחת מספקת מידע מסוג אחר.
מה ההבדל בין Monitoring לבין Observability?
המונחים Monitoring ו-Observability קשורים זה לזה אך אינם זהים.
Monitoring מתמקד בדרך כלל במדדים ידועים ובשאלה האם המערכת מתפקדת בהתאם לציפיות.
Observability עוסקת ביכולת להבין את המצב הפנימי של מערכת מורכבת באמצעות הנתונים שהיא מייצרת.
במערכות מודרניות נהוג להתייחס לשלושה מקורות מידע מרכזיים:
- Metrics – מדדים מספריים
- Logs – לוגים ואירועים
- Traces – מעקב אחר בקשה בין רכיבים שונים
השילוב בין השלושה מאפשר לקבל תמונה רחבה הרבה יותר של התנהגות המערכת.
איך בונים מערך ניטור נכון?
אין צורך להתחיל מניטור של כל רכיב אפשרי. עדיף להתחיל מהתהליכים החשובים ביותר לעסק.
שלב 1 – מיפוי המערכות
רשמו את המערכות הקריטיות ואת התלות ביניהן.
שלב 2 – זיהוי התהליכים העסקיים הקריטיים
שאלו אילו תהליכים חייבים לעבוד כדי שהעסק ימשיך לפעול.
שלב 3 – הגדרת מדדים
לכל מערכת הגדירו את המדדים החשובים באמת.
שלב 4 – הגדרת Thresholds
קבעו מתי חריגה הופכת להתראה.
שלב 5 – הגדרת אחריות
התראה ללא גורם אחראי אינה פתרון. לכל סוג אירוע צריך להיות ברור מי מטפל בו.
שלב 6 – בדיקת ההתראות
יש לוודא שההתראה באמת נשלחת כאשר מתרחשת התקלה.
שלב 7 – שיפור מתמשך
לאחר מספר שבועות כדאי לבדוק אילו התראות היו שימושיות, אילו היו מיותרות ואילו בעיות כלל לא זוהו.
מה QA יכול לבדוק במערכת ניטור?
גם מערכת הניטור עצמה היא מערכת תוכנה ולכן היא זקוקה לבדיקות.
QA יכול לבדוק:
- האם המדד נאסף נכון
- האם הערכים נכונים
- האם ההתראה מופעלת בזמן
- האם ההתראה נשלחת לנמען הנכון
- האם רמת החומרה נכונה
- האם אירוע נסגר לאחר חזרת המערכת לשגרה
- האם אין התרעות כפולות
- האם Dashboard מציג נתונים נכונים
- האם תרחישי קצה מטופלים
במילים אחרות, לא מספיק לבדוק את המערכת העסקית. לעיתים צריך לבדוק גם את "מערכת האזעקה" שאמורה לזהות כאשר משהו משתבש.
בדיקות לאחר שינוי במערכת
כל שינוי משמעותי במערכת IT צריך להעלות את השאלה: כיצד נדע שהמערכת ממשיכה לעבוד כראוי לאחר השינוי?
כאן נכנסות בדיקות רגרסיה, אינטגרציה, Smoke Tests ובדיקות E2E.
לדוגמה, לאחר שינוי באפליקציה אפשר:
- להריץ בדיקות אוטומטיות
- להריץ בדיקות פונקציונליות
- לבצע בדיקות אינטגרציה
- להעלות את השינוי לייצור
- לעקוב אחר מדדי ניטור
- לבדוק האם קיימת עלייה בשגיאות
- להשוות ביצועים לפני ואחרי השינוי
כך נוצר תהליך רציף בין QA, Release Management ו-IT Operations.
10 טעויות נפוצות בניטור מערכות IT
- לנטר יותר מדי מדדים – כמות גדולה של נתונים אינה בהכרח איכות.
- לנטר רק זמינות – מערכת יכולה להיות זמינה אך בלתי שמישה.
- להגדיר יותר מדי התראות – הדבר יוצר Alert Fatigue.
- לא להגדיר בעלות על התראה – אף אחד לא יודע מי צריך לטפל.
- לא לבדוק את מערכת הניטור – גם מנגנון ההתראות עלול להיכשל.
- לא לשמור היסטוריה – ללא נתונים היסטוריים קשה לזהות מגמות.
- לא לחבר בין מערכות – תקלה בממשק עלולה להיראות כמו תקלה במערכת אחרת.
- להסתמך רק על Thresholds – חריגה ביחס להתנהגות רגילה יכולה להיות משמעותית גם מתחת לסף.
- לא לשלב ניטור עם תהליכי QA – מפספסים הזדמנות לזהות בעיות לאחר העלייה לייצור.
- לא לבצע Post Incident Analysis – אותה תקלה עלולה לחזור.
Checklist לניטור מערכות IT
לפני שמגדירים מערך ניטור, אפשר להשתמש ברשימת הבדיקה הבאה:
- האם כל המערכות הקריטיות מוגדרות?
- האם כל השרתים הקריטיים מנוטרים?
- האם נבדקת זמינות?
- האם נבדקים ביצועים?
- האם מנוטרים CPU וזיכרון?
- האם מנוטר שטח דיסק?
- האם מנוטרים לוגים?
- האם מנוטרים ממשקים?
- האם מנוטרים תהליכי Batch?
- האם קיימות התראות?
- האם ההתראות מחולקות לפי חומרה?
- האם מוגדר אחראי לכל סוג אירוע?
- האם ההתראות נבדקות באופן יזום?
- האם קיימת היסטוריית נתונים?
- האם קיימת השוואה לביצועי Baseline?
- האם יש ניטור של תהליכים עסקיים קריטיים?
- האם הניטור נבדק לאחר שדרוגים?
- האם QA מעורב בבדיקת מנגנון הניטור?
לסיכום: ניטור טוב לא רק מגלה תקלות – הוא מייצר שליטה
ניטור מערכות IT הוא הרבה יותר מגרף שמראה שימוש ב-CPU או הודעת Email כאשר שרת נופל.
מערך ניטור איכותי מחבר בין תשתיות, אפליקציות, בסיסי נתונים, ממשקים, תהליכים עסקיים ופעילות המשתמשים.
הערך האמיתי של ניטור מגיע כאשר הארגון מסוגל לזהות בעיה מוקדם, להבין את משמעותה, להפנות אותה לגורם הנכון ולפעול לפני שההשפעה העסקית גדלה.
עבור אנשי QA, ניטור הוא גם הרחבה טבעית של עולם הבדיקות: הבדיקות בוחנות האם המערכת אמורה לעבוד בצורה נכונה, בעוד שהניטור מאפשר לראות כיצד היא מתנהגת בפועל לאורך זמן.
השילוב בין QA, אוטומציה, בדיקות אינטגרציה, בדיקות E2E וניטור Production מאפשר ליצור תהליך איכות רחב יותר – מהשינוי הראשון בקוד ועד ההתנהגות של המערכת אצל המשתמשים האמיתיים.
למי שנכנס לעולם ה-QA ורוצה להרחיב את הידע מעבר לבדיקות ידניות, כדאי להכיר גם את עולם האוטומציה, כולל השוואה בין Playwright, Cypress ו-Selenium וגם את כלי בדיקות אוטומציה שכדאי להכיר.
לקרוא מאמרים זה נחמד אבל לא יביא אותך לתוצאה שאתה רוצה, בדיוק בשביל זה הכנו עבורך את הקורס הדיגיטלי המהיר, תוך שעתיים וחצי תלמד את תחום הבדיקות ידניות, תוכל להתחיל לעבוד מהבית דרך FIVERR או ולהתכונן נכון לראיונות עבודה שיעזרו לך לצלוח אותם. כנס כאן הקורס ממוקד בבדיקות תוכנה ידניות הנותן בסיס חזק לתחום.
לעבוד מהבית כבודק תוכנה עם FIVERR >> לחץ כאן
