שיטות מומלצות לעבודה עם שירות הלקוחות

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

ליצור בקשת תמיכה חדשה

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

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

תיאור הבעיה

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

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

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

בחלקים הבאים נרחיב על כך בפירוט.

חותמת זמן

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

למשל:

  • החל מ-2017-09-08T15:13:06+00:00 ובמשך 5 דקות ראינו…
  • החל מ-2017-09-10 ראינו לסירוגין את הבעיה, בין פעמיים ל-5 פעמים…
  • הבעיה נמשכת מאז 2017-09-08T15:13:06+00:00…
  • מ-2017-09-08T15:13:06+00:00 ועד 2017-09-08T15:18:16+00:00 ראינו…

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

  • "הבעיה התחילה מתישהו אתמול…" (אמירה כזו מאלצת אותנו לשער מה התאריך).
  • "שמנו לב לבעיה ב-9/8…" (זה מעורפל, כי אדם אחד עשוי להבין את התאריך הזה כ-8 בספטמבר, ואנשים אחרים יפרשו אותו כ-9 באוגוסט).

המוצר

אמנם בטופס הבסיסי של בקשת התמיכה אתם מתבקשים לבחור שם מוצר, אבל אנחנו צריכים מידע ספציפי בקשר למאפיין באותו מוצר שבו הייתה הבעיה. מומלץ לצרף לבקשות כתובות URL של ממשקי API או מסוף Google Cloud (או צילומי מסך). אם מדובר ב-API, אפשר לקשר לדף המסמך, שמכיל את שם המוצר ב-URL.

ספרו לנו גם באיזה מנגנון השתמשתם כדי להפעיל את הבקשה (לדוגמה, API בארכיטקטורת REST, ה-CLI של Google Cloud, מסוף Google Cloud או כלי כמו Cloud Deployment Manager). אם מדובר בכמה מוצרים, ציינו את השם של כל אחד מהם בנפרד.

למשל:

  • "במהלך השימוש ב-API בארכיטקטורת REST של Compute Engine הופיעו השגיאות הבאות…"
  • "ממשק השאילתות של BigQuery ב-console.cloud.google.com תקוע ולא מגיב…"

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

  • "לא הצלחנו ליצור מופעים…" (אנחנו צריכים לדעת את השיטה שבה ניסיתם ליצור את המופעים).
  • "כשהרצתי את הפקודה gcloud compute create instances הייתה הודעת שגיאה…" (התחביר של הפקודה שגוי, אז אנחנו לא יכולים להריץ אותה בעצמנו כדי לשחזר את השגיאה. אנחנו גם לא יודעים איזו הודעת שגיאה קיבלתם).

מיקום

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

למשל:

  • "באזור us-east1-b ..."
  • "ניסיתי את אזורים ‎us-east1 ו-‎us-central1…"

מזהים

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

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

  • מזהי מופעים
  • שמות של טבלאות או מזהי משימות ב-BigQuery
  • כתובות IP

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

למשל:

  • "בפרויקט ‎robot-name-165473 או ‎my-project-id…"
  • "בכמה פרויקטים שונים (כולל my-project-id)…"
  • "התחברתי לכתובת IP חיצונית 218.239.8.9 של Google Cloud‏ מהשער העסקי 56.56.56.56…"

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

  • "אין לנו גישה לאחד מהמופעים שלנו…"
  • "לא הצלחנו להתחבר באמצעות האינטרנט…"

קבצים נלווים

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

למשל:

  • תוכלו לצרף צילומי מסך כדי להראות לנו בדיוק מה אתם רואים.
  • בממשקים מבוססי-אינטרנט, תוכלו לספק קובץ ‎.HAR (‏‏Http ARchive. ב-HAR analyzer תוכלו למצוא הוראות לשלושת הדפדפנים הנפוצים.
  • אפשר גם לצרף פלט tcpdump, קטעי יומנים ודוחות קריסות לדוגמה.

סוג הבעיה

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

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

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

תיאורים לדוגמה

דוגמה ראשונה

JobName:

A_ATL_BIG1toBQ_big_04)201704202

00045_491

Source:

S3_avl-transfer

Destination:

CloudStorage: avl-transfer

Start time (ISO 8601 format): 2017-04-20 20:14:43 PDT

End time (ISO 8601 format): 2017-04-21 at 10:03:44 PDT

I started a file transfer at 2017-04-20 at 20:14:43 PDT using the transfer API.
This job normally takes 10 minutes to complete, but in this case the job was
still running when I canceled it the next day (2017-04-21 at 10:03:44 PDT). This
is not an isolated event; several other jobs involving the transfer API had
intermittent, significant delays.

Please investigate the cause of the delays and advise of any best practices that
we can implement to prevent these issues in the future.

דוגמה שנייה

Start time (ISO 8601 format): 2017-05-12 at 11:03:43

End time (ISO 8601 format): The issue is still happening as of the time of this
report.

Issue summary:

`/cron/payments-service/sync-v2-batch` cron using the App Engine Task Queue API
has stopped running since 2017-05-12 at 11:03:43. We rely on this job to handle
payments correctly.

We saw datastore and queue errors and then the cron stopped running. We
attempted unsuccessfully to fix the issue by re-uploading cron.xml. Here is the
error trace:

`[error trace]`

Please advise if the issue is with the API or our implementation and let us
know next steps.

בחירת רמת העדיפות והעברה לטיפול ברמה גבוהה יותר

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

רמת העדיפות דוגמה לסיטואציה
P1: השפעה קריטית – לא ניתן להשתמש בשירות בסביבת הייצור אי אפשר להשתמש באפליקציה או בתשתית בסביבת הייצור בגלל שגיאות רבות אצל משתמשי הקצה. ההשפעה על העסק היא קריטית (אובדן הכנסות, בעיות פוטנציאליות של תקינות נתונים וכו').
P2: השפעה גבוהה – פגיעה חמורה בשימוש בשירות יש תקלה בתשתית בסביבת הייצור עם שגיאות משמעותיות אצל משתמשי הקצה או קשיים בהתחלת ההרצה של מערכות ייצור חדשות. ההשפעה על העסק היא מתונה (סכנה של אובדן הכנסות, ירידה בפרודוקטיביות וכו').
P3: השפעה בינונית – פגיעה חלקית בשימוש בשירות חומרת הבעיה וההיקף שלה מוגבלים. המשתמשים עצמם אינם רואים את הבעיה. ההשפעה על העסק היא נמוכה (למשל, אי נוחות או פגיעה שולית בפעילויות העסק).
P4: השפעה נמוכה – אפשר להשתמש בשירות באופן מלא כמעט שאין השפעה על העסק או מבחינה טכנית. רמת העדיפות הזו מומלצת למקרים שבהם עדיף לבצע ניתוח, פתרון בעיות או ייעוץ מעמיק מאשר תקשורת שוטפת.

מתי לבחור ברמת העדיפות הגבוהה ביותר?

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

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

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

מה אפשר לצפות לגבי בקשות תמיכה ברמה P1?

  • בקשת תמיכה חדשה ברמה P1

    • מומחה תמיכה ייצור איתכם קשר דרך Google Meet או באמצעות כל שירות אחר שתציינו. אנחנו מצפים שתצטרפו לשיחה תוך 15-30 דקות. אם אתם לא מצליחים להצטרף לשיחה מסיבה כלשהי, עליכם להודיע על כך למומחה התמיכה.
    • כברירת מחדל, הטיפול בבקשת התמיכה מתבצע מסביב לשעון. כלומר, מומחי התמיכה יעבדו במשך 24 שעות ביממה עד לצמצום הבעיה או עד להורדת רמת העדיפות שלה. אם יש עדיפות שהטיפול בבקשה יתבצע באזור מסוים, אפשר לנעול את הבקשה לאזור זמן ספציפי. תוכלו לעדכן אותנו מה ההעדפה שלכם בנושא הזה.

  • העלאת העדיפות לרמה P1

    • אם הבעיה התחילה להשפיע על סביבת הייצור או עומדת להשפיע עליה, תוכלו להעלות את רמת העדיפות של בקשת תמיכה קיימת ברמות P2 עד P4 לרמה P1.
    • אחרי העלאת העדיפות של בקשת תמיכה קיימת לרמה P1, יכול להיות שהיא תוקצה מחדש למומחה תמיכה זמין לצורך התייחסות מיידית.

  • בעיה שלא משפיעה על הייצור

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

זמני תגובה

לכל רמת עדיפות יש זמן תגובה מוגדר מראש. זמני התגובה מפורטים בהנחיות לשירותי תמיכה טכנית (TSS) של Google Cloud Platform. אם דרוש לכם מענה תוך פרק זמן מסוים, כתבו לנו על כך בתיאור הבעיה. אם יש צורך לטפל בבעיה ברמה P1 מסביב לשעון, תוכלו לבקש שירות מסביב לשעון ("follow the sun"). הבקשות האלה מוקצות מחדש כמה פעמים ביום כדי שנציג Customer Care פעיל יטפל בהן. במהלך הטיפול שלנו בבקשת תמיכה ברמה P1, מומלץ לשמור על תקשורת יעילה ושתהיו זמינים למענה על שאלות – עד שהבעיה תיפתר. אם לא נקבל מכם תגובה במשך יותר מ-3 שעות, יכול להיות שנוריד את רמת העדיפות של בקשת התמיכה ל-P2 – עד שתחזרו אלינו.

העברה לטיפול ברמה גבוהה יותר

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

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

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

במאמר העברת בקשה לטיפול ברמה גבוהה יותר מוסבר איך מעבירים בקשות לטיפול ברמה גבוהה יותר.

העברת הטיפול בבקשה לאזור הזמן הדרוש

בעקבות הגורמים שמשפיעים על הזמינות של שירות הלקוחות, יכול להיות שבקשת התמיכה שלכם תועבר לטיפול של נציג שירות לקוחות שעובד בשעות אחרות מכם. יכול להיות גם שתרצו לדבר עם שירות הלקוחות במהלך ימי העסקים של אזור זמן מסוים. במקרים כאלה, מומלץ לבקש משירות הלקוחות להעביר את בקשת התמיכה שלכם לצוות שנמצא באזור זמן שנוח לכם. תוכלו לפרט זאת בתיאור הבקשה או בתשובה שלכם. לדוגמה: Please route this case to the Pacific time zone (GMT-8). בקשות תמיכה ברמה P1 מועברות לאזור הבא ב-Customer Care, כי הטיפול בהן הוא מסביב לשעון. בקשות ברמת עדיפות אחרת נשארות אצל הבעלים שלהן, להמשך טיפול ביום הבא.

שליחת משוב באמצעות סקר CES

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

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

למידע נוסף, צפו בסרטון איך לשלוח משוב על שירותי Google Cloud באמצעות CES.

בעיות מתמשכות או קשות

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

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

המסמך כולל:

  • סיכום של המצב הנוכחי (בראש המסמך).
  • רשימת השערות שעשויות להיות נכונות.
  • פירוט של הבדיקות והכלים שאתם מתכוונים להשתמש בהם כדי לבדוק כל השערה.

כדאי להשתדל שכל בקשה תתמקד בבעיה אחת, ולא לפתוח מחדש בקשות כדי לדווח על בעיות חדשות.

דיווח על הפסקה זמנית בשירות בסביבת הייצור

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

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

  • בדיקה מיידית אם יש בעיות מוכרות שמשפיעות על התשתית של Google Cloud .
  • אימות של אופי הבעיה.
  • יצירת ערוצי תקשורת.

תוכלו לצפות לקבל מענה עם הודעה קצרה, שתכיל:

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

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

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

דיווח על בעיות ברשת

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

תרשימי זרימה של חבילות הם דרך מצוינת לדווח על בעיות בצורה מובנית. בתרשימים האלה מתוארים הצעדים החשובים של החבילה בדרך מהמקור ליעד, יחד עם שינויים משמעותיים שקורים בדרך.

בתור התחלה, מציינים אילו נקודות קצה ברשת הושפעו (באמצעות כתובת IP או כתובת RFC 1918 פרטית בתוספת מזהה הרשת). לדוגמה, 2.3.4.5 או 10.2.3.4 ברשת ברירת המחדל של הפרויקט ב-Compute Engine.

מציינים כל דבר חשוב בקשר לנקודות הקצה, כמו:

  • מי שולט בהן.
  • אם הן משויכות לשם מארח ב-DNS.
  • כל אנקפסולציה או עיקוף בדרך, או שניהם, כמו מנהור דרך VPN, שרתי proxy ושערי NAT.
  • כל מסנן בדרך, כמו חומות אש, CDN או WAF.

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

  • ניתוח מסלול – רשימה של כל הצעדים של החבילה, נקראת באנגלית גם traceroute. לעיתים קרובות אנחנו משתמשים ב-MTR או ב-tcptraceroute, או בשניהם, כי יכולת האבחון שלהם טובה יותר. מומלץ להכיר את הכלים האלה.
  • לכידת חבילות (נקרא גם pcap, על שם הספרייה libpcap) – תצפית על התנועה ברשת בפועל. חשוב לבצע לכידת חבילות בשתי נקודות הקצה בו-זמנית, פעולה שעלולה להיות מורכבת. כדאי לתרגל אותה באמצעות הכלים הנדרשים (למשל, tcpdump או Wireshark), ולוודא שהם מותקנים למקרה שתזדקקו להם.