כוונון הביצועים של Office 365 באמצעות ביצועי הבסיס והיסטוריית הביצועים

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

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

חשוב: נתקלת ממש עכשיו בבעיה של ביצועים בין הלקוח שלך ו- Office 365? בצע את השלבים המתוארים תוכנית לפתרון בעיות ביצועים עבור Office 365.

משהו שעליך לדעת אודות הביצועים של Office 365

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

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

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

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

אוקיי, איך נראית בעיה בביצועים?

תחילה, עליך לוודא שהבעיה שאתה חווה היא אכן בעיה בביצועים ולא מקרה שירות. בעיה בביצועים שונה ממקרה שירות ב- Office 365. כך תוכל להבחין בין השניים.

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

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

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

תמונה של לוח המחוונים של תקינות השירות של Office 365 המסבירה כי שירות Exchange Online שוחזר, ומדוע.

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

  • בעיית ביצועים מתרחשת ללא קשר לדיווח תחת תקינות נוכחית במרכז הניהול של Office 365 עבור השירות.

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

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

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

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

כיצד להגדיר ולבדוק את בעיית הביצועים

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

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

  • העלאת הקבצים שלי ל- SharePoint Online נמשכת זמן רב מדי. מדוע הוא איטי אחה"צ, אך מהיר בשעות אחרות במהלך היום? האם הוא לא יכול להיות פשוט מהיר?

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

  • לא ברור כיצד המעבר מתיבת הדואר הנכנס ללוח השנה התבצע במחשב הנייד.

  • כאשר המשתמש כותב, "האם הוא לא יכול להיות פשוט מהיר?", למה הכוונה ב"מהיר"?

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

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

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

  • באיזה תאריך הופיעה הבעיה, ובאיזו שעה של היום או של הלילה?

  • באיזה סוג של מחשב לקוח השתמשת, ואיך הוא מתחבר לרשת העסקית (VPN, קווי, אלחוטי)?

  • האם עבדת מרחוק או האם היית במשרד?

  • האם ניסית את אותן פעולות במחשב אחר ונתקלת באותו אופן פעולה?

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

  • כמה איטיים הביצועים בשניות או בדקות?

  • היכן אתה ממוקם בעולם?

חלק מהשאלות צפויות יותר מאחרות. רוב האנשים יבינו שפותר בעיות צריך לדעת את השלבים המדויקים כדי לשחזר את הבעיה. אחרי הכל, אם לא כך - כיצד תוכל לתעד את מה שהשתבש, וכיצד תוכל לבדוק אם הבעיה נפתרה? השאלות הצפויות פחות הן "באיזה תאריך ובאיזו שעה התעוררה הבעיה?" ו"היכן אתה ממוקם בעולם?", מידע שניתן להשתמש בו בשילוב. בהתאם למקום שבו עובד המשתמש, ייתכן שהפרש של כמה שעות עבודה פירושו שהתחזוקה כבר החלה בחלקים אחרים של הרשת במקום העבודה שלך. אם, לדוגמה, לחברה שלך יש יישום היברידי, כגון חיפוש היברידי של SharePoint, המבצע שאילתות באינדקסי חיפוש הן ב- SharePoint Online והן במופע מקומי של SharePoint Server 2013, ייתכן שהעדכונים החלו בחווה המקומית. אם החברה שלך נמצאת כולה בענן, תחזוקת המערכת עשויה לכלול הוספה או הסרה של חומרת רשת, עדכונים קרובים החלים על כל החברה או ביצוע שינויים ב- DNS, או בתשתית ליבה אחרת.

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

האם אתה יודע כיצד הביצועים נראו כשהיו טובים?

אם אין לך מזל, אף אחד לא יודע. לאף אחד לא היו נתונים. משמעות הדבר היא שאף אחד אינו יכול להשיב לשאלה הפשוטה "כמה שניות נמשכה פתיחה של תיבת הדואר הנכנס ב- Office 365?" או "כמה זמן נמשכה פגישת Lync Online של המנהלים?", שהוא התרחיש הנפוץ בחברות רבות.

מה שחסר כאן הוא ביצועי בסיס.

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

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

  • זהה את ההתקנים שבין מחשב הלקוח שלך לנקודת היציאה שלך, לדוגמה, שרת ה- Proxy שלך.

    • עליך להכיר את ההתקנים שלך כדי לקבל הקשר (כתובות IP, סוג המכשיר וכו') לבעיות ביצועים שעלולות להתעורר.

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

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

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

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

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

  • זמן ממחשב הלקוח שלך אל נקודת היציאה שלך באלפיות שניה

  • זמן מנקודת היציאה שלך אל Office 365 באלפיות שניה

  • מיקום בעולם של השרת אשר פותר את כתובות ה- URL עבור Office 365 במהלך גלישה

  • מהירות זיהוי ה- DNS על-ידי ספק שירותי האינטרנט (ISP) שלך באלפיות שניה, מקרים של חוסר עקביות בהגעת המנות (ריצוד רשת), זמני העלאה והורדה באלפיות שניה

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

מהם ביצועי בסיס?

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

גרפיקת רשת בסיסית המציגה לקוח, שרת Proxy וענן של Office 365.

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

רשת בסיסית עם לקוח, שרת Proxy וענן, והצעות לכלים PSPing,‏ TraceTCP ומעקבי רשת.

האפשרויות המפורטות הן פשוט ומתקדם בשל מידת ההתמחות הנחוצה כדי לאתר את נתוני ביצועים. מעקב רשת יימשך זמן רב, בהשוואה להפעלת כלי שורת פקודה, כגון PsPing ו- TraceTCP. שני כלי שורת הפקודה הללו נבחרו משום שהם לא משתמשים במנות ICMP, אשר ייחסמו על-ידי Office 365, ומשום שהם מודדים את הזמן שנדרש לצאת ממחשב הלקוח, או משרת ה- Proxy (אם יש לך גישה אליו) ולהגיע ל- Office 365 באלפיות שניה. כל דילוג ממחשב אחד למחשב אחר יסתיים בערך זמן, וזה נהדר לביצועי בסיס! יתרה מזאת, כלי שורת הפקודה הללו מאפשרים לך להוסיף לפקודה מספר יציאה, וזה חשוב מכיוון ש- Office 365 מתקשר דרך יציאה 443, שהיא היציאה המשמשת את Secure Sockets Layer ואת Transport Layer Security‏ (SSL ו- TLS). עם זאת, כלים של ספקים חיצוניים אחרים עשויים להיות פתרונות טובים יותר - הדבר תלוי בנסיבות שלך. Microsoft אינה תומכת בכל הכלים הללו, כך שאם, מסיבה כלשהי, אינך יכול להפעיל את PsPing ואת TraceTCP, עבור למעקב רשת בעזרת כלי כגון Netmon.

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

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

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

  • Feb_09_2015_9amPST_PerfBaseline_Netmon_ClientToEgress_Normal

  • Jan_10_2015_3pmCST_PerfBaseline_PsPing_ClientToO365_bypassProxy_SLOW

  • Feb_08_2015_2pmEST_PerfBaseline_BADPerf

  • Feb_08_2015_8-30amEST_PerfBaseline_GoodPerf

יש המון דרכים שונות לעשות זאת, אך השימוש בתבנית <dateTime><what's happening in the test> מהווה נקודת התחלה טובה. אם תקפיד להשתמש בה, הדבר יעזור לך מאוד כאשר תנסה לפתור בעיות בהמשך. בהמשך, תוכל לומר "רשמתי לעצמי שני מעקבים ב- 8 בפברואר, אחד הציג ביצועים טובים ואחד הציג ביצועים ירודים, כך שנוכל להשוות ביניהם". אפשרות זו שימושית במיוחד לצורך פתרון בעיות.

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

מדוע כדי לאסוף נתוני ביצועים בפריסת ניסיון

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

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

כיצד לאסוף ביצועי בסיס

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

  • מחשב הלקוח שבו אתה משתמש (סוג המחשב או ההתקן, כתובת IP והפעולות שגרמו לבעיה)

  • היכן בעולם נמצא מחשב הלקוח (לדוגמה, האם משתמש זה מתחבר באמצעות VPN לרשת, עובד מרחוק או מחובר לאינטרא-נט של החברה)

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

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

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

שיטות פשוטות

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

רשת בסיסית עם לקוח, שרת Proxy וענן, והצעות לכלים PSPing,‏ TraceTCP ומעקבי רשת.

הערות: 

  • TraceTCP כלול בצילום מסך זה משום שזהו כלי שימושי להצגת משך הזמן לעיבוד בקשה, באלפיות שניה, ולהצגת מספר דילוגי הרשת, או מספר החיבורים ממחשב אחד לשני שבהם משתמשת הבקשה כדי להגיע ליעד. כמו כן, ל- TraceTCP יש אפשרות לספק את שמות השרתים שבהם נעשה שימוש במהלך דילוגים - נתון שימושי עבור פותר בעיות של Microsoft Office 365 בצוות התמיכה.

  • פקודות TraceTCP יכולות להיות פשוטות מאוד, כגון:

  • tracetcp.exe outlook.office365.com:443

  • זכור לכלול את מספר היציאה בפקודה!

  • TraceTCP ניתן להורדה ללא תשלום, אבל הוא מבוסס על Wincap‏. Wincap הוא כלי שגם משמש ומותקן על-ידי Netmon. אנו משתמשים ב- Netmon גם בסעיף השיטות המתקדמות.

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

ישנן מספר דרכים להתמודד עם נקודת היציאה, במקרה זה, שרת ה- Proxy. באפשרותך לבצע מעקב מ- 1 עד 2 ולאחר מכן מ- 2 עד 3 ולחבר את המספרים באלפיות השניה כדי לקבל פרק זמן כולל להגעה עד לקצה הרשת שלך. לחלופין, באפשרותך להגדיר את החיבור כך שיעקוף את שרת ה- Proxy עבור כתובות של Office 365. ברשת גדולה יותר עם חומת אש, שרת Proxy הפוך, או שילוב כלשהו של השניים, ייתכן שתצטרך לכלול חריגים בשרת ה- Proxy אשר יאפשרו לתעבורה להעביר כמות גדולה של כתובות URL. לקבלת הרשימה של נקודות קצה המשמשות את Office 365, ראה טווחי כתובות ה- IP וכתובות ה- URL של Office 365. אם יש לך שרת Proxy לאימות, התחל בבדיקת חריגים עבור הפעולות הבאות:

  • יציאות 80 ו- 443

  • TCP ו- HTTPs

  • חיבורים יוצאים לכל אחת מכתובות URL אלה:

  • ‎*.microsoftonline.com

  • ‎*.microsoftonline-p.com

  • ‎*.sharepoint.com

  • ‎*.outlook.com

  • ‎*.lync.com

  • osub.microsoft.com

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

כדי להוסיף אותן לרשימת העקיפה של ה- Proxy ב- Internet Explorer, עבור אל כלים > אפשרויות אינטרנט > חיבורים > הגדרות LAN > מתקדם. הכרטיסיה 'מתקדם' היא גם המקום שבו תוכל למצוא את שרת ה- Proxy שלך ואת היציאה שלו. ייתכן שיהיה עליך ללחוץ על תיבת הסימון השתמש בשרת Proxy עבור רשת LAN, כדי לגשת ללחצן מתקדם. רצוי לוודא שהאפשרות עקוף שרת Proxy עבור כתובות מקומיות מסומנת. לאחר שתלחץ על מתקדם, תראה תיבת טקסט שבה ניתן להזין חריגים. הפרד בין כתובות ה- URL הכלליות באמצעות נקודה-פסיק, לדוגמה:

‎*.microsoftonline.com; *.sharepoint.com

לאחר עקיפת ה- Proxy, אתה אמור להיות מסוגל לבצע בדיקה באמצעות איתות (Ping) או בדיקת PsPing ישירות בכתובת URL של Office 365. השלב הבא יהיה לבצע בדיקה באמצעות איתות (Ping) של outlook.office365.com. לחלופין, אם אתה משתמש ב- PsPing או בכלי אחר שיאפשר לך לספק מספר יציאה לפקודה, PsPing מול portal.microsoftonline.com:443 כדי לראות את זמן ההלוך ושוב הממוצע באלפיות השניה.

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

עליך להשתמש ב- PSPing או בכלי אחר שאינו משתמש במנות ICMP הנחסמות על-ידי Office 365 כדי לבצע בדיקה זו.

כיצד להשתמש ב- PsPing כדי לקבל זמן הלוך ושוב כולל באלפיות שניה ישירות מכתובת URL של Office 365

  1. הפעל בקשה לשורת פקודה על-ידי השלמת השלבים הבאים:

    1. לחץ על התחל.

    2. בתיבה התחל חיפוש, הקלד cmd ולאחר מכן הקש Ctrl+Shift+Enter.

    3. אם מופיעה תיבת הדו-שיח בקרת חשבון משתמש, אשר כי הפעולה המוצגת היא הפעולה הרצויה, ולאחר מכן לחץ על המשך.

  2. נווט אל התיקיה שבה הכלי (במקרה זה PsPing) מותקן ובדוק את כתובות ה- URL הבאות של Office 365:

    • psping portal.office.com:443

    • psping microsoft-my.sharepoint.com:443

    • psping outlook.office365.com:443

    • psping www.yammer.com:443

      הפקודה PSPing עוברת אל יציאה 443 של microsoft-my.sharepoint.com.

הקפד לכלול את מספר היציאה 443. זכור כי Office 365 פועל בערוץ מוצפן. אם אתה מבצע בדיקת PsPing ללא מספר יציאה, הבקשה שלך תיכשל. לאחר שביצעת בדיקה באמצעות איתות (Ping) ברשימה הקצרה שלך, חפש את הזמן הממוצע באלפיות השניה (ms). זה מה שאתה רוצה לתעד!

גרפיקה המציגה איור של לקוח ל- PSPing של שרת Proxy עם זמן הלוך ושוב של 2.8 אלפיות שניה.

אם אינך מכיר עקיפות של Proxy, ומעדיף לבצע את הפעולות שלב אחר שלב, תחילה עליך לברר את שם שרת ה- Proxy שלך. ב- Internet Explorer, עבור אל כלים > אפשרויות אינטרנט > חיבורים > הגדרות LAN > מתקדם. הכרטיסיה מתקדם היא המקום שבו יופיע שרת ה- Proxy שלך. בצע בדיקה באמצעות איתות (Ping) בשרת ה- Proxy בשורת פקודה על-ידי השלמת המשימה הבאה:

כדי לבצע בדיקה באמצעות איתות (Ping) לשרת ה- Proxy ולקבל ערך זמן הלוך ושוב באלפיות שניה עבור שלב 1 עד 2

  1. הפעל בקשה לשורת פקודה על-ידי השלמת השלבים הבאים:

    1. לחץ על התחל.

    2. בתיבה התחל חיפוש, הקלד cmd ולאחר מכן הקש Ctrl+Shift+Enter.

    3. אם מופיעה תיבת הדו-שיח בקרת חשבון משתמש, אשר כי הפעולה המוצגת היא הפעולה הרצויה, ולאחר מכן לחץ על המשך.

  2. הקלד ping <שם שרת ה- Proxy שבו משתמש הדפדפן שלך, או כתובת ה- של שרת ה- Proxy> ולאחר מכן הקש ENTER. אם במחשב שלך מותקן PsPing, או כלי אחר, באפשרותך לבחור להשתמש בכלי זה במקום זאת.

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

    • ping ourproxy.ourdomain.industry.business.com

    • ping 155.55.121.55

    • ping ourproxy

    • psping ourproxy.ourdomain.industry.business.com:80

    • psping 155.55.121.55:80

    • psping ourproxy:80

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

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

גרפיקה המציגה את זמן ההעברה החוזרת מלקוח ל- Proxy של 2.8 אלפיות שניה.

אם מחשב הלקוח שלך הוא אחד המחשבים המעטים שיש להם גישה לשרת ה- Proxy (או היציאה), ניתן להפעיל את השלב הבא של הבדיקה על-ידי התחברות מרחוק לאותו מחשב, והפעלת שורת הפקודה ל- PsPing לכתובת URL של Office 365 משם. אם אין לך גישה לאותו מחשב, באפשרותך לפנות למשאבי הרשת שלך לקבלת עזרה בשלב הבא וכך לקבל נתונים מדויקים. אם זה בלתי אפשרי, בצע בדיקת Psping מול כתובת ה- URL של Office 365 הנתונה והשווה אותו לזמן ביצוע בדיקת ה- PsPing או ה- Ping מול שרת ה- Proxy שלך.

לדוגמה, אם יש לך 51.84 אלפיות שניה מהלקוח לכתובת ה- URL של Office 365, ויש לך 2.8 אלפיות שניה מהלקוח לשרת ה- Proxy (או לנקודת היציאה), יש לך 49.04 אלפיות שניה מנקודת היציאה ל- Office 365. בדומה, אם יש לך בדיקת PsPing האורכת 12.25 אלפיות שניה מהלקוח לשרת ה- Proxy בעיצומו של היום, ו- 62.01 אלפיות שניה מהלקוח לכתובת ה- URL של Office 365, הערך הממוצע עבור נקודת היציאה של ה- Proxy לכתובת ה- URL של Office 365 הוא 49.76 אלפיות שניה.

גרפיקה נוספת המציגה את האיתות (Ping) באלפיות שניה מהלקוח לשרת ה- Proxy לצד הלקוח ל- Office 365 לשם גריעת הערכים.

במונחים של פתרון בעיות, אתה עשוי לגלות פרטים מעניינים רק מכך שתקפיד לשמור על ביצועי בסיס אלה. לדוגמה, אם אתה מגלה שבדרך כלל יש לך 40 עד 59 אלפיות שניה של השהיה משרת ה- Proxy או מנקודת יציאה לכתובת ה- URL של Office 365, ויש לך השהיית לקוח לשרת Proxy או לנקודת יציאה של כ- 3 עד 7 אלפיות שניה (בהתאם לכמות תעבורת הרשת שאתה רואה במהלך אותה שעה של היום), תדע בוודאות שמשהו לא תקין אם שלושת ביצועי הבסיס האחרונים שלך מסוג לקוח לשרת Proxy או לנקודת יציאה מציגים השהיה של 45 אלפיות שניה.

שיטות מתקדמות

אם אתה באמת רוצה לדעת מה קורה עם הבקשות שלך באינטרנט ל- Office 365, עליך להכיר מעקבים ברשת. אין זה משנה אילו כלים אתה מעדיף עבור מעקבים אלה - הכלים HTTPWatch,‏ Netmon,‏ Message Analyzer,‏ Wireshark,‏ Fiddler,‏ Developer Dashboard או כל כלי אחר מקובלים, כל עוד הכלי יכול ללכוד ולסנן את תעבורת הרשת. בסעיף זה תגלה שכדאי להפעיל יותר מכלי אחד כדי לקבל תמונה מלאה יותר של הבעיה. כאשר אתה מבצע בדיקה, חלק מהכלים הללו פועלים כשרתי Proxy בעצמם. כלים המשמשים במאמר הנלווה, תוכנית לפתרון בעיות ביצועים עבור Office 365, כוללים את Netmon 3.4‏, HTTPWatch, או WireShark.

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

  • רשימת ביצועי בסיס עבור SPO - שלב 1: עיין בדף הבית של אתר האינטרנט של SPO ובצע מעקב רשת. שמור את המעקב.

  • רשימת ביצועי בסיס עבור SPO - שלב 2: חפש מונח (למשל, שם החברה שלך) דרך 'חיפוש ארגוני' ובצע מעקב רשת. שמור את המעקב.

  • רשימת ביצועי בסיס עבור SPO - שלב 3: העלה קובץ גדול לספריית מסמכים של SharePoint Online ובצע מעקב רשת. שמור את המעקב.

  • רשימת ביצועי בסיס עבור SPO - שלב 4: עיין בדף הבית של אתר האינטרנט של OneDrive ובצע מעקב רשת. שמור את המעקב.

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

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

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

למידע נוסף

ניהול נקודות קצה של Office 365

הרחב את הכישורים שלך
סייר בהדרכה
קבל תכונות חדשות לפני כולם
הצטרף למשתתפי Office Insider

האם מידע זה היה שימושי?

תודה על המשוב!

תודה על המשוב! נראה שכדאי לקשר אותך לאחד מנציגי התמיכה של Office.

×