אבחון רשת (tcpdump, Wireshark, nmap, iperf, mtr, traceroute)

אבחון רשת: מה נשבר ואיך מוצאים את זה

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

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

שרת אחד מתוך מאגר מתחיל להגיב לאט יותר מהאחרים, והמאזן (load balancer) מורח את הבעיה על פני כל השירות.

אבחון רשת נבנה מהמעטפת החיצונית אל האפליקציה.

traceroute ו-mtr מראים באיזה קטע גדלה ההשהיה והיכן אובדות חבילות; iperf מודד רוחב פס נטו בין שתי נקודות ומפריד בין הרשת לקוד; nmap בודק זמינות פורטים וכללי סינון; tcpdump בשני קצוות החיבור מאפשר להשוות מה יצא ומה הגיע, ו-Wireshark מפרק סשן איטי אחד צעד אחר צעד.

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

אפקטים מדידים: השהיות, אובדנים, זמן התאוששות

כל עוד מחפשים את הסיבה לפי תלונות, החשבון נמדד בשעות. לכידה מתמדת של תעבורה בקטעים בעייתיים ותיאור נתיבים מקצרים את זמן איתור האירוע מ-4–6 שעות ל-20–30 דקות: הנתונים כבר נלכדו, נותר להשוות אותם לרגע התלונה, ולא לשחזר את התקלה מחדש עם בקשה «שחזרו את הבעיה».

אובדן חבילות והשהיית תגובה מפסיקים להיות מדידות חד-פעמיות ברגע התקלה. מדידה רציפה בנתיבים קריטיים עם ספים ברורים מספקת התראה לפני המשתמשים — על הקו נשמרים 0.1–0.5% אובדנים במקום 2–5% שתלו שנים ב«אינטרנט גרוע» ובציוד חלש של המנוי.

גם סוג הכשלים משתנה. נעלמת הקטגוריה «חיפשנו, לא מצאנו, אתחלנו»: במקומה — סיבה קונקרטית, מקושרת לקטע ולזמן, ובעלים ברור של השינוי. חלק האירועים שנסגרים בתוך הצוות בלי הסלמה לספק או לספק חיצוני עולה מחצי ל-85–90%, ופניות חוזרות מאותה סיבה כמעט ונעלמות.

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

פורמטים של אבחון רשת: חקירה, ניטור, נהל

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

איך בוחרים פורמט

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

שלבי העבודה: מלכידת סימפטומים ועד מסירת נהל

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

1. איסוף סימפטומים וכרונולוגיה. מחדדים מה בדיוק מידרדר — השהיה, אובדנים, ניתוקים — באילו צמתים ובאילו מרווחים, איך זה משתחזר ומה השתנה לפני ההופעה הראשונה.
2. תרשים הרשת ונתיבי התעבורה. בונים תרשים של מעבר התעבורה: גבולות סגמנטים, מאזנים, תרגום כתובות, מנהרות. כך רואים היכן חבילה יכולה ללכת לאיבוד או לסטות מהנתיב הצפוי.
3. נקודות לכידת נתונים. בוחרים נקודות מפתח — בכניסה וביציאה של הסגמנט הבעייתי, בצומת עצמו ובצומת שכן. את הדאמפים והמדידות לוקחים באופן סינכרוני, עם ייחוס זמן אחיד.
4. תוכנית בדיקות. את ההשערות מדרגים לפי סבירות ועלות בדיקה: תחילה חותכים גרסאות זולות, ואז עוברים למדידות עומס ולתיאור נתיבים.
5. בדיקת ההשערות. משווים נתונים מנקודות שונות, בודקים מול מוני ממשקים, מאמתים או מבטלים גרסה. כל השערה מקבלת מסקנה חד-משמעית — «אומתה» או «נשללה».
6. קיבוע התוצאה ומסירת הנהל. מתארים את הסיבה, את שינוי הקונפיגורציה שבוצע, את מערך בדיקות הבקרה ואת הספים שמעליהם כדאי לחזור לאבחון.

חומרי פלט: תרשימים, מדידות, נהלים

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

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

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

מקרה בוחן: איך איתרנו ניתוקים תקופתיים

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

מה הראו המדידות

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

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

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

איך להבין שצוואר הבקבוק הוא באפליקציה ולא בערוץ?

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

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

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

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

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

שאלות טכניות נפוצות בחקירת אירועים

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

האם יהיה צורך לעצור שירותים בזמן הלכידה?

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

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

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

באיזו תדירות לחזור על המדידות?

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

האם אפשר לבצע עבודות במעגל סגור?

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

נדון במשימה שלכם ונחזור עם תוכנית בדיקות

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

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

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

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

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