Điều chỉnh hiệu suất Office 365 bằng đường cơ sở và lịch sử hiệu suất

Có một số cách đơn giản để kiểm tra hiệu năng kết nối giữa Office 365 và doanh nghiệp của bạn, điều này cho phép bạn thiết lập một đường cơ sở sơ bộ cho kết nối của mình. Biết được lịch sử hiệu năng của kết nối máy tính khách có thể giúp bạn phát hiện những vấn đề xuất hiện trước đây, xác định được và dự đoán được các vấn đề.

Nếu bạn không quen làm việc với những sự cố hiệu năng, bài viết này được thiết kế nhằm giúp bạn xem xét một số câu hỏi thường gặp, như Làm thế nào bạn biết được vấn đề mình đang thấy là một sự cố hiệu năng chứ không phải sự cố của dịch vụ Office 365? Làm thế nào để bạn có thể lập kế hoạch nhằm đạt hiệu năng cao, trong dài hạn? Làm thế nào bạn có thể để mắt tới hiệu năng? Nếu nhóm hoặc máy khách của bạn đang gặp vấn đề hiệu năng chậm trong khi dùng Office 365 và bạn thắc mắc về bất kỳ câu hỏi nào trong số này, thì hãy đọc tiếp.

Quan trọng: Bạn đang gặp vấn đề về hiệu năng giữa máy khách của bạn và Office 365 ngay bây giờ? Thực hiện theo các bước được thảo ra trong phần Kế hoạch khắc phục sự cố về hiệu năng cho Office 365.

Vài điều bạn nên biết về hiệu năng của Office 365

Office 365 nằm bên trong một mạng năng suất cao, chuyên dụng của Microsoft, vốn được giám sát ổn định không chỉ theo cách tự động, mà còn bởi người thực. Một phần trong vai trò duy trì nền tảng điện toán đám mây Office 365 là điều chỉnh và hợp lý hóa hiệu năng dựng sẵn nếu có thể. Vì máy khách của nền tảng điện toán đám mây Office 365 phải kết nối qua Internet, nên cũng có nỗ lực liên tục để tinh chỉnh hiệu năng trên toàn bộ các dịch vụ Office 365. Việc cải tiến hiệu năng không bao giờ ngừng hẳn trên nền tảng điện toán đám mây, và có nhiều trải nghiệm được tích lũy trong quá trình giữ cho nền tảng điện toán đám mây hoạt động tốt và nhanh chóng. Nếu bạn gặp phải vấn đề về hiệu năng khi kết nối từ vị trí của mình với Office 365, thì tốt nhất là không nên khởi tạo và chờ trả lời từ trường hợp Hỗ trợ. Thay vào đó, bạn nên bắt đầu điều tra vấn đề 'từ trong ra ngoài'. Nghĩa là, hãy bắt đầu bên trong mạng của bạn rồi điều tra ra ngoài đến Office 365. Trước khi mở một trường hợp với Hỗ trợ Office 365, bạn có thể thu thập dữ liệu và thực hiện các hành động giúp khám phá và có thể giải quyết vấn đề của bạn.

Quan trọng: Hãy lưu ý việc hoạch định dung lượng và các giới hạn trong Office 365. Thông tin đó sẽ giúp bạn nắm rõ tình hình khi tìm cách giải quyết sự cố về hiệu suất. Đây là liên kết tới Mô tả Dịch vụ Nền tảng của Office 365. Đây là một hub trung tâm và tất cả các dịch vụ được Office 365 cung cấp đều có liên kết đến Mô tả Dịch vụ của riêng mình từ đây. Có nghĩa là, giả sử bạn cần xem giới hạn tiêu chuẩn cho SharePoint Online, bạn sẽ bấm vào Mô tả Dịch vụ SharePoint Online, rồi tìm mục Giới hạn của SharePoint Online ở trong đó.

Đảm bảo rằng bạn tiến hành khắc phục sự cố với nhận thức rằng hiệu năng là một thang đo biến thiên, chứ nó không phải về việc đạt được và duy trì vĩnh viễn một giá trị lý tưởng (nếu bạn hiểu như thế, thì sẽ rất căng thẳng khi thực hiện các tác vụ băng thông cao thỉnh thoảng diễn ra như lúc triển khai một lượng lớn người dùng hoặc thực hiện di chuyển dữ liệu lớn -- vì vậy hãy lập kế hoạch cho các ảnh hưởng đến hiệu năng). Bạn có thể, và nên, ước tính gần đúng mục tiêu hiệu năng của mình, nhưng nhiều biến số sẽ ảnh hưởng đến hiệu năng, do đó hiệu năng sẽ thay đổi. Đó là bản chất của hiệu năng.

Khắc phục vấn đề về hiệu năng không phải là đạt được mục tiêu cụ thể và duy trì vĩnh viễn các con số đó, mà là cải thiện các hoạt động hiện có, khi tính đến tất cả các biến số.

Được rồi, vậy vấn đề về hiệu năng trông như thế nào?

Trước tiên, bạn cần phải đảm bảo rằng điều mà mình đang gặp phải thật sự là vấn đề về hiệu năng chứ không phải sự cố dịch vụ. Vấn đề về hiệu năng khác với sự cố dịch vụ trong Office 365. Đây là cách phân biệt.

Nếu dịch vụ Office 365 đang gặp vấn đề, thì đó là sự cố dịch vụ. Bạn sẽ nhìn thấy biểu tượng màu đỏ hoặc màu vàng bên dưới Trạng thái hiện tại trong trung tâm quản trị Office 365, bạn cũng có thể nhận thấy hiệu năng chậm trên máy tính khách kết nối với Office 365. Chẳng hạn, nếu Trạng thái hiện tại báo cáo biểu tượng màu đỏ và bạn nhìn thấy Đang điều tra bên cạnh Exchange, thì sau đó bạn có thể cũng sẽ nhận được hàng loạt cuộc gọi từ những người trong tổ chức của bạn phàn nàn rằng hộp thư khách sử dụng Exchange Online đang hoạt động không tốt. Trong trường hợp đó, theo suy luận hợp lý là nên giả định rằng hiệu năng Exchange Online của bạn vừa trở thành nạn nhân của vấn đề trong Dịch vụ.

Bảng điều khiển Trạng thái Office 365 với tất cả khối lượng công việc hiển thị màu lục, ngoại trừ Exchange hiển thị Dịch vụ được Khôi phục.

Lúc này, bạn, tức là người quản trị Office 365, nên kiểm tra Trạng thái hiện tại rồi Xem chi tiết và lịch sử thường xuyên, để luôn cập nhật các phần bảo trì mà chúng tôi thực hiện trên hệ thống. Bảng điều khiển Trạng thái hiện tại được tạo để cập nhật cho bạn về các thay đổi và vấn đề trong dịch vụ. Các ghi chú và giải thích về lịch sử trạng thái, từ người quản trị này đến người quản trị khác, đều ở đó để giúp bạn đánh giá ảnh hưởng của mình và giúp bạn cập nhật về công việc đang diễn ra.

Ảnh của bảng điều khiển trạng thái Office 365 giải thích rằng dịch vụ Exchange Online đã được khôi phục và nguyên nhân khôi phục.

Vấn đề về hiệu năng không phải là sự cố dịch vụ, ngay cả khi sự cố dịch vụ có thể dẫn đến hiệu năng chậm. Vấn đề về hiệu năng trông như thế này:

  • Vấn đề về hiệu năng xảy ra bất kể Trạng thái hiện tại trong trung tâm quản trị Office 365 đang báo cáo cho dịch vụ những gì.

  • Một hành vi trước đây vốn tương đối trơn tru bỗng mất nhiều thời gian để hoàn thành hoặc không bao giờ hoàn thành.

  • Bạn cũng có thể tái tạo vấn đề, hoặc ít nhất, bạn biết rằng nó sẽ xảy ra nếu bạn thực hiện chuỗi các bước phù hợp.

  • Nếu vấn đề xảy ra theo kiểu ngắt quãng, thì vẫn có một mẫu hình, ví dụ như bạn biết rằng trước 10:00 SA bạn sẽ nhận cuộc gọi từ những người dùng không thể truy nhập ổn định vào Office 365, và rằng các cuộc gọi này sẽ giảm xuống vào khoảng giữa trưa.

Điều này nghe có vẻ quen thuộc; có thể là quá quen thuộc. Sau khi bạn biết đây là vấn đề về hiệu năng, thì câu hỏi trở thành "Tiếp theo bạn phải làm gì?" Phần còn lại của bài viết này sẽ giúp bạn xác định đúng điều đó.

Cách xác định và kiểm tra vấn đề hiệu năng

Vấn đề về hiệu năng thường phát sinh qua thời gian, do đó có thể khó xác định được vấn đề thực sự. Bạn cần tạo một báo cáo rõ ràng về vấn đề, nắm được ngữ cảnh của vấn đề, rồi sau đó bạn cần đề ra các bước kiểm tra hiệu quả để giải quyết. Nếu không, cho dù bạn không có lỗi gì, nhưng vẫn có thể không giải quyết được. Tại sao? Dưới đây là một số ví dụ về báo cáo vấn đề không cung cấp đủ thông tin:

  • Việc chuyển từ Hộp thư đến của tôi sang Lịch của tôi trước đây vốn là điều tôi không nhận thấy, còn bây giờ thì cứ ngắc ngứ. Bạn có thể làm cho nó hoạt động giống như trước đây không?

  • Việc tải tệp của tôi lên SharePoint Online đang mất quá nhiều thời gian. Tại sao việc này lại chậm vào buổi chiều, nhưng vào những lúc khác thì lại nhanh? Việc này có thể luôn luôn nhanh không?

Có một vài thử thách lớn mà những báo cáo vấn đề phía trên gây ra. Cụ thể là có nhiều thông tin mơ hồ cần phải xử lý. ví dụ:

  • Không biết rõ việc chuyển đổi giữa Hộp thư đến và Lịch trước đây hoạt động ra sao trên máy tính xách tay.

  • Khi người dùng nói, "Việc này không thể nhanh được sao", thì "nhanh" nghĩa là gì?

  • "Mất quá nhiều thời gian" là bao lâu? Vài giây, vài phút, hay người dùng có thể đi ăn trưa rồi thao tác sẽ kết thúc mười phút sau khi người dùng quay lại?

Tất cả điều này còn chưa kể đến việc người quản trị và người khắc phục sự cố không thể biết được nhiều chi tiết từ những báo cáo vấn đề như thế này. Chẳng hạn, khi vấn đề bắt đầu xảy ra; người dùng làm việc ở nhà và chỉ nhận thấy thao tác chuyển đổi chậm khi ở trong mạng gia đình; người dùng có lẽ đang chạy một vài ứng dụng tốn nhiều RAM khác trên máy khách cục bộ, hoặc người dùng đang chạy hệ điều hành cũ hay chưa chạy các bản cập nhật gần đây.

Khi người dùng báo cáo một vấn đề về hiệu năng, thì có rất nhiều thông tin cần thu thập. Việc thu thập các thông tin này là một phần của quy trình gọi là khoanh phạm vi vấn đề, hay điều tra vấn đề. Sau đây là danh sách khoanh phạm vi cơ bản mà bạn có thể dùng để thu thập thông tin về vấn đề hiệu năng của mình. Danh sách này không đầy đủ, nhưng là bước khởi đầu để tạo danh sách của riêng bạn:

  • Vấn đề xảy ra vào ngày nào, và vào mấy giờ sáng hay tối?

  • Bạn đang sử dụng loại máy tính khách nào, và máy kết nối với mạng doanh nghiệp bằng cách nào (VPN, Có dây, Không dây)?

  • Bạn làm việc từ xa hay ở trong văn phòng?

  • Bạn có thử các hành động giống như vậy trên máy tính khác và nhận thấy hành vi tương tự không?

  • Hãy làm theo các bước khiến bạn gặp vấn đề để bạn có thể ghi lại các hành động mà mình thực hiện.

  • Hiệu năng chậm đến mức nào nếu tính theo giây hoặc phút?

  • Bạn đang ở đâu trên thế giới?

Một số câu hỏi trong số này dễ nhận thấy hơn các câu khác. Hầu hết mọi người sẽ hiểu rằng người khắc phục sự cố cần biết các bước chính xác để tái tạo vấn đề. Nói cho cùng thì bạn còn có thể ghi lại vấn đề và kiểm tra xem vấn đề đã được giải quyết chưa bằng cách nào khác nữa? Những điều khác khó nhận thấy hơn là những câu như "Bạn nhận thấy vấn đề vào ngày nào và mấy giờ?" và "Bạn đang ở đâu trên thế giới?", nghĩa là những thông tin có thể sử dụng cùng nhau. Tùy thuộc vào thời điểm người dùng làm việc, một vài giờ chênh lệch có thể nghĩa là phần bảo trì hiện đã chạy trên các phần trong mạng công ty của bạn. Nếu chẳng hạn như công ty của bạn có môi trường thực thi hỗn hợp, chẳng hạn như Tìm kiếm SharePoint hỗn hợp mà vốn có thể truy vấn chỉ mục tìm kiếm trong cả SharePoint Online lẫn phiên bản SharePoint Server 2013 tại cơ sở, thì các bản cập nhật có thể đang chạy trong cụm máy chủ tại cơ sở. Nếu công ty của bạn hoàn toàn nằm trên nền tảng điện toán đám mây, thì quá trình bảo trì hệ thống có thể bao gồm việc thêm hoặc loại bỏ phần cứng mạng, triển khai các bản cập nhật trên toàn công ty, hoặc thực hiện thay đổi cho DNS hoặc cơ sở hạ tầng cốt lõi khác.

Khi bạn đang khắc phục vấn đề về hiệu năng, thì tương tự như hiện trường vụ án, bạn cần phải chính xác và nhạy bén để rút ra bất kỳ kết luận nào từ bằng chứng. Để làm điều này, bạn phải có được báo cáo vấn đề tốt bằng cách thu thập bằng chứng. Báo cáo này nên bao gồm ngữ cảnh của máy tính, ngữ cảnh của người dùng, thời điểm vấn đề bắt đầu và các bước chính xác dẫn đến vấn đề về hiệu năng. Báo cáo về vấn đề này nên và luôn nằm ở trang đầu tiên trong các ghi chú của bạn. Bằng cách xem lại báo cáo vấn đề sau khi tìm ra giải pháp, bạn đang thực hiện các bước để kiểm tra và chứng minh việc các hành động mà bạn thực hiện đã giải quyết được vấn đề hay chưa. Điều này rất quan trọng để biết được khi nào thì công việc của bạn trong việc này đã kết thúc.

Bạn biết hiệu năng từng trông ra sao khi đạt hiệu quả tốt?

Nếu bạn không may thì không ai biết được. Không ai có số liệu cả. Điều này nghĩa là không ai có thể trả lời câu hỏi đơn giản như "Trước đây mất bao nhiêu giây để mở Hộp thư đến trong Office 365?", hoặc "Trước đây mất bao lâu khi Người điều hành tiến hành cuộc họp trong Lync Online?", đây là kịch bản thường gặp đối với nhiều công ty.

Điều còn thiếu ở đây là một đường cơ sở hiệu năng.

Đường cơ sở cung cấp cho bạn ngữ cảnh về hiệu năng của bạn. Bạn nên thu thập đường cơ sở thỉnh thoảng hoặc thường xuyên, tùy thuộc vào nhu cầu của công ty bạn. Nếu bạn là công ty lớn hơn, thì nhóm Vận hành có thể đã thu thập đường cơ sở cho môi trường tại cơ sở của bạn. Chẳng hạn, nếu bạn vá lỗi cho tất cả máy chủ Exchange vào thứ hai đầu tiên của tháng và cho tất cả máy chủ SharePoint vào thứ hai của tuần thứ ba, thì nhóm Vận hành có thể có danh sách các tác vụ và kịch bản mà họ chạy sau khi sửa lỗi, để chứng tỏ rằng các chức năng quan trọng đang hoạt động. Chẳng hạn, mở Hộp thư đến, bấm Gửi/Nhận và đảm bảo rằng các thư mục cập nhật, hoặc trong SharePoint, duyệt trang chính của site, đi đến trang Tìm kiếm trong doanh nghiệp và thực hiện một thao tác tìm kiếm có trả về kết quả.

Nếu các ứng dụng của bạn nằm trong Office 365, thì một số đường cơ sở căn bản nhất mà bạn có thể thu thập sẽ đo thời gian (tính theo mili giây) từ máy tính khách bên trong mạng của bạn, đến một điểm đầu ra, hoặc điểm mà bạn rời khỏi mạng của mình và đi đến Office 365. Dưới đây là một số đường cơ sở hữu ích mà bạn có thể điều tra và ghi lại:

  • Xác định các thiết bị giữa máy tính khách và điểm đầu ra của bạn, ví dụ như máy chủ proxy của bạn.

    • Bạn cần biết về các thiết bị của mình để nắm rõ ngữ cảnh (địa chỉ IP, loại thiết bị, v.v.) cho bất kỳ vấn đề về hiệu năng nào phát sinh.

    • Máy chủ proxy là điểm đầu ra chung, vì vậy bạn có thể kiểm tra trình duyệt web của mình để xem máy chủ proxy nào đang được đặt để sử dụng, nếu có.

    • Có các công cụ của bên thứ ba vốn có thể khám phá và ánh xạ mạng của bạn, nhưng cách an toàn nhất để biết về các thiết bị của bạn là hỏi thành viên trong nhóm mạng của bạn.

  • Xác định nhà cung cấp dịch vụ Internet (ISP) của bạn, ghi lại thông tin liên hệ của họ, và hỏi xem bạn có bao nhiêu mạch và bao nhiêu băng thông.

  • Trong công ty của bạn, hãy xác định tài nguyên cho các thiết bị giữa máy khách của bạn và điểm đầu ra, hoặc xác định liên hệ khẩn cấp để trao đổi về vấn đề nối mạng.

Dưới đây là một số đường cơ sở mà thao tác kiểm tra đơn giản bằng công cụ có thể tính toán cho bạn:

  • Thời gian đi từ máy tính khách đến điểm đầu ra của bạn tính theo mili giây

  • Thời gian đi từ điểm đầu ra của bạn đến Office 365 tính theo mili giây

  • Vị trí trên thế giới của máy chủ phân giải URLS cho Office 365 khi bạn duyệt

  • Tốc độ phân giải DNS của ISP của bạn tính theo mili giây, sự không nhất quán trong thời gian gói đến (mạng chập chờn), tải lên và tải xuống tính theo mili giây

Nếu bạn chưa quen với cách thực hiện các bước này, chúng tôi sẽ giải thích chi tiết hơn trong bài viết này.

Đường cơ sở là gì?

Bạn sẽ biết ảnh hưởng khi mọi thứ trở nên kém đi, nhưng nếu bạn không biết dữ liệu hiệu năng lịch sử của mình, thì không thể có được ngữ cảnh về mức độ kém đi và thời điểm mà mọi thứ trở nên kém đi. Vì vậy nếu không có đường cơ sở, thì bạn đang thiếu mất mấu chốt để giải quyết trò chơi ghép hình: bức hình trên nắp hộp trò chơi. Trong việc khắc phục vấn đề về hiệu năng, bạn cần có một điểm để so sánh. Đường cơ sở hiệu năng đơn giản không khó thu thập. Nhóm Vận hành của bạn có thể được giao nhiệm vụ thực hiện điều này theo lịch biểu. Chẳng hạn, giả sử kết nối của bạn trông như thế này:

Đồ họa mạng cơ bản thể hiện máy khách, proxy và nền tảng điện toán đám mây Office 365.

Điều đó nghĩa là bạn đã kiểm tra với nhóm mạng của mình và biết rằng bạn rời khỏi công ty của mình để đi đến Internet thông qua một máy chủ proxy và proxy đó xử lý tất cả các yêu cầu mà máy tính khách của bạn gửi lên nền tảng điện toán đám mây. Trong trường hợp này, bạn nên vẽ một phiên bản đơn giản về kết nối của mình, trong đó liệt kê tất cả các thiết bị trung gian. Bây giờ, hãy chèn các công cụ mà bạn có thể sử dụng để kiểm tra hiệu năng giữa máy khách, điểm đầu ra (nơi bạn rời khỏi mạng của mình để đi đến Internet), và nền tảng điện toán đám mây Office 365.

Mạng cơ bản với máy khách, proxy, đám mây, các công cụ được đề xuất như PSPing, TraceTCP, và quy trình dõi vết mạng.

Các tùy chọn được liệt kê dưới dạng Đơn giảnNâng cao theo mức độ kiến thức chuyên môn mà bạn cần để tìm dữ liệu hiệu năng. Việc theo dõi mạng sẽ mất nhiều thời gian, so với việc chạy các công cụ dòng lệnh như PsPing và TraceTCP. Hai công cụ dòng lệnh này được chọn vì chúng không sử dụng gói ICMP vốn bị Office 365 chặn, và vì chúng cung cấp thời gian tính bằng mili giây cần thiết để rời khỏi máy tính khách hoặc máy chủ proxy (nếu bạn có quyền truy nhập) và đến Office 365. Mỗi bước nhảy riêng lẻ từ máy tính này sang máy tính khác sẽ kết thúc với một giá trị thời gian, và điều này rất phù hợp với đường cơ sở! Cũng quan trọng không kém, những công cụ dòng lệnh này cho phép bạn thêm số cổng lên lệnh, điều này rất hữu ích vì Office 365 giao tiếp qua cổng 443, vốn là cổng được sử dụng bởi Tầng Khe Bảo mật và Transport Layer Security (SSL và TLS). Tuy nhiên, các công cụ bên thứ ba khác có thể là giải pháp tốt hơn cho tình huống của bạn. Microsoft không hỗ trợ tất cả các công cụ này, vì vậy nếu vì một số lý do mà bạn không thể dùng PsPing và TraceTCP, hãy chuyển sang theo dõi mạng bằng một công cụ như Netmon.

Bạn có thể thu thập đường cơ sở trước giờ làm việc, thu thập lần nữa trong thời gian sử dụng nhiều, rồi lần nữa khi hết giờ. Điều này nghĩa là cuối cùng có thể bạn sẽ có cấu trúc thư mục tương tự như thế này:

Đồ hoạ đề xuất một cách sắp xếp dữ liệu thực hiện công việc của bạn thành các thư mục.

Bạn cũng nên chọn quy ước đặt tên cho tệp của mình. Sau đây là một số ví dụ:

  • 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

Có nhiều cách khác nhau để làm điều này, nhưng việc dùng định dạng <dateTime><what's happening in the test> là điểm thích hợp để bắt đầu. Cẩn trọng trong việc này sẽ giúp ích rất nhiều khi bạn tìm cách khắc phục sự cố sau này. Sau này, bạn sẽ có thể nói rằng "Tôi thực hiện hai lần dõi vết vào ngày 8 tháng 2, một lần cho thấy hiệu năng tốt và một lần cho thấy hiệu năng kém, vì vậy chúng ta có thể so sánh chúng". Điều này vô cùng hữu ích khi khắc phục sự cố.

Bạn cần phải có phương pháp gọn gàng để lưu giữ các đường cơ sở lịch sử của mình. Trong ví dụ này, các phương pháp đơn giản cung cấp ba đầu ra dòng lệnh và các kết quả được thu thập dưới dạng ảnh chụp màn hình, nhưng thay vào đó bạn có thể yêu cầu mạng thu thập tệp. Hãy sử dụng phương pháp phù hợp nhất với bạn. Lưu trữ đường cơ sở lịch sử của bạn và tham khảo chúng tại các điểm mà bạn nhận thấy thay đổi trong hành vi của dịch vụ trực tuyến.

Tại sao nên thu thập dữ liệu hiệu năng trong quá trình thí điểm?

Không còn thời điểm nào phù hợp để bắt đầu thu thập đường cơ sở hơn là trong quá trình thí điểm dịch vụ Office 365. Văn phòng của bạn có thể có hàng ngàn, hàng trăm ngàn hoặc năm người dùng, nhưng thậm chí với một số ít người dùng, bạn có thể thực hiện kiểm tra để đo mức dao động trong hiệu năng. Trong trường hợp công ty lớn, mẫu đại diện gồm vài trăm người dùng thí điểm Office 365 có thể được tăng lên đến vài ngàn để bạn biết vị trí mà vấn đề có thể phát sinh trước khi chúng xảy ra.

Trong trường hợp công ty nhỏ, trong đó việc triển trai nghĩa là tất cả người dùng đều dùng dịch vụ cùng một lúc và không có thí điểm, thì hãy lưu giữ các số đo hiệu năng để bạn có dữ liệu nhằm cung cấp cho bất kỳ người nào có thể phải khắc phục một thao tác có hiệu năng kém. Chẳng hạn, nếu bạn nhận thấy rằng bỗng nhiên bạn có thể đi vòng quanh toà nhà của mình trong thời gian cần thiết để tải lên một đồ họa cỡ vừa trong khi thao tác này vốn xảy ra rất nhanh.

Cách thu thập các đường cơ sở

Đối với tất cả các kế hoạch khắc phục sự cố, ít nhất bạn cần phải xác định những điều này:

  • Máy tính khách mà bạn đang sử dụng (loại máy tính hay thiết bị, địa chỉ IP và những hành động gây ra sự cố)

  • Vị trí đặt các máy tính khách trên thế giới (ví dụ, người dùng này có ở trên một VPN đối với mạng này không, có làm việc từ xa không, hoặc có ở trên mạng nội bộ công ty không)

  • Điểm đầu ra mà máy tính khách sử dụng từ mạng của bạn (điểm mà tại đó lưu lượng rời khỏi doanh nghiệp để đến một ISP hay để vào mạng Internet)

Bạn có thể tìm hiểu bố trí mạng của mình từ người quản trị mạng. Nếu bạn dùng mạng nhỏ, hãy xem các thiết bị kết nối bạn với Internet, và gọi cho ISP của bạn nếu có bất kỳ câu hỏi nào về bố trí. Tạo đồ họa về bố trí cuối cùng để tham khảo.

Phần này được chia thành các công cụ và phương pháp dòng lệnh đơn giản cũng như các tùy chọn công cụ nâng cao hơn. Chúng tôi sẽ đề cập đến các phương pháp đơn giản trước tiên. Nhưng nếu bạn gặp vấn đề về hiệu năng ngay bây giờ, thì bạn nên đi thẳng đến các phương pháp nâng cao và thử dùng kế hoạch hành động mẫu nhằm khắc phục sự cố về hiệu năng.

Phương pháp đơn giản

Mục tiêu của các phương pháp đơn giản này là tìm hiểu cách thu thập, hiểu và lưu trữ đúng cách các đường cơ sở hiệu năng đơn giản theo thời gian để bạn nắm rõ về hiệu năng của Office 365. Dưới đây là sơ đồ rất đơn giản cho phương pháp đơn giản, như bạn đã thấy trước đây:

Mạng cơ bản với máy khách, proxy, đám mây, các công cụ được đề xuất như PSPing, TraceTCP, và quy trình dõi vết mạng.

Lưu ý: 

  • TraceTCP được bao gồm trong ảnh chụp màn hình này vì đây là một công cụ hữu ích để hiển thị, theo milligiây, thời gian mà một yêu cầu cần để xử lý và số lượng bước nhảy trong mạng, hay kết nối từ máy tính này sang máy tính khác, mà yêu cầu đó cần để đến đích. TraceTCP cũng có thể cung cấp tên của máy chủ được dùng trong quá trình nhảy, điều này có thể hữu ích cho người khắc phục sự cố của Microsoft Office 365 trong bộ phận Hỗ trợ.

  • Lệnh TraceTCP có thể rất đơn giản, chẳng hạn như:

  • tracetcp.exe outlook.office365.com:443

  • Hãy nhớ bao gồm số cổng trong lệnh!

  • TraceTCP là bản tải xuống miễn phí, nhưng dựa trên Wincap. Wincap là công cụ mà Netmon cũng sử dụng và cài đặt. Chúng tôi cũng sử dụng Netmon trong phần phương pháp nâng cao.

Nếu bạn có nhiều văn phòng, bạn cũng sẽ cần lưu giữ một bộ dữ liệu từ một máy khách trong từng vị trí đó. Kiểm tra này đo độ trễ, mà trong trường hợp này là một giá trị số mô tả khoảng thời gian từ khi một máy khách gửi yêu cầu đến Office 365, đến khi Office 365 trả lời yêu cầu. Quá trình kiểm tra bắt nguồn từ bên trong tên miền của bạn trên máy tính khách, và tìm cách đo thời gian truyền đi về từ bên trong mạng của bạn, đi ra ngoài qua một điểm đầu ra, qua Internet đến Office 365, rồi quay lại.

Có một số cách để xử lý điểm đầu ra, trong trường hợp này là máy chủ proxy. Bạn có thể theo dõi từ 1 đến 2 rồi 2 đến 3, sau đó tính tổng các số này theo mili giây để có được tổng cuối cùng tính đến đường biên của mạng của bạn. Hoặc bạn có thể cấu hình kết nối để bỏ qua proxy cho địa chỉ Office 365. Trong mạng lớn hơn có tường lửa, proxy đảo ngược hoặc kết hợp cả hai, bạn có thể cần đặt ngoại lệ trên máy chủ proxy mà sẽ cho phép lưu lượng đi qua nhiều URL. Để biết danh sách các điểm cuối được Office 365 sử dụng, hãy xem URL và dải địa chỉ IP của Office 365. Nếu bạn có proxy xác thực, hãy bắt đầu bằng cách kiểm tra ngoại lệ cho các mục sau:

  • Cổng 80 và 443

  • TCP và HTTP

  • Kết nối đi tới bất kỳ URL nào sau đây:

  • *.microsoftonline.com

  • *.microsoftonline-p.com

  • *.sharepoint.com

  • *.outlook.com

  • *.lync.com

  • osub.microsoft.com

Tất cả người dùng cần được cho phép đi đến những địa chỉ này mà không có bất kỳ sự can thiệp hay xác thực proxy nào. Trên mạng nhỏ hơn, bạn nên thêm các mục này vào danh sách bỏ qua proxy trong trình duyệt web của bạn.

Để thêm những mục này vào danh sách bỏ qua proxy của bạn trong Internet Explorer, hãy đi đến Công cụ > Tùy chọn Internet > Kết nối > Thiết đặt LAN > Nâng cao. Tab nâng cao cũng là nơi bạn sẽ tìm thấy máy chủ proxy và cổng máy chủ proxy của mình. Bạn có thể cần bấm vào hộp kiểm Dùng máy chủ proxy cho mạng LAN của bạn, để truy nhập vào nút Nâng cao. Bạn sẽ muốn đảm bảo rằng Máy chủ proxy bỏ qua cho địa chỉ cục bộ được chọn. Sau khi bấm Nâng cao, bạn sẽ thấy một hộp văn bản mà bạn có thể nhập ngoại lệ. Phân tách các URL đại diện được liệt kê ở trên bằng dấu chấm phẩy, ví dụ:

*.microsoftonline.com; *.sharepoint.com

Sau khi bỏ qua proxy của mình, bạn sẽ có thể sử dụng ping hoặc PsPing trực tiếp trên URL Office 365. Bước tiếp theo sẽ là kiểm tra ping outlook.office365.com. Hoặc nếu bạn đang sử dụng PsPing hay công cụ khác mà sẽ cho phép bạn cung cấp số cổng cho lệnh, thì hãy PsPing dựa trên portal.microsoftonline.com:443 để xem thời gian thời gian truyền đi về trung bình tính theo mili giây.

Thời gian truyền đi về, hay RTT, là một giá trị số, vốn đo khoảng thời gian cần để gửi yêu cầu HTTP đến một máy chủ như outlook.office365.com và nhận được phản hồi xác nhận rằng máy chủ biết rằng bạn đã thực hiện điều đó. Thỉnh thoảng bạn sẽ nhìn thấy giá trị này được viết tắt thành RTT. Giá trị này sẽ là một khoảng thời gian khá ngắn.

Bạn phải sử dụng PSPing hoặc công cụ khác vốn không sử dụng gói ICMP, mà Office 365 đã chặn, để thực hiện kiểm tra này.

Cách dùng PsPing để có được thời gian truyền đi về tính bằng mili giây trực tiếp từ URL Office 365

  1. Chạy lời nhắc chỉ lệnh mức cao bằng cách hoàn tất các bước sau đây:

    1. Bấm Bắt đầu.

    2. Trong hộp Bắt đầu Tìm kiếm, nhập cmd, rồi nhấn CTRL+SHIFT+ENTER.

    3. Nếu hộp thoại Kiểm soát Tài khoản Người dùng xuất hiện, hãy xác nhận rằng hành động mà nó hiển thị là điều bạn muốn, sau đó bấm Tiếp.

  2. Dẫn hướng tới thư mục mà công cụ (trong trường hợp này là PsPing) được cài đặt và kiểm tra các URL Office 365 sau đây:

    • psping portal.office.com:443

    • psping microsoft-my.sharepoint.com:443

    • psping outlook.office365.com:443

    • psping www.yammer.com:443

      Lệnh PSPing đang đi đến microsoft-my.sharepoint.com cổng 443.

Đảm bảo bao gồm số cổng 443. Hãy nhớ rằng Office 365 hoạt động trên kênh được mã hóa. Nếu bạn PsPing mà không có số cổng, yêu cầu của bạn sẽ không thành công. Sau khi bạn đã ping danh sách ngắn của mình, hãy tìm thời gian Trung bình tính theo mili giây (ms). Đây chính là điều bạn muốn ghi lại!

Đồ họa hiển thị hình minh họa PSPing từ máy khách đến proxy với thời gian truyền đi về là 2,8 mili giây.

Nếu bạn không quen với việc bỏ qua máy chủ proxy và muốn thực hiện mọi việc theo từng bước, trước tiên bạn cần tìm tên máy chủ proxy của bạn. Trong Internet Explorer, đi đến Công cụ > Tuỳ chọn Internet > Kết nối > Thiết đặt LAN > Nâng cao. Tab Nâng cao là nơi bạn sẽ thấy máy chủ proxy của mình được liệt kê. Ping máy chủ proxy đó tại một dấu nhắc lệnh bằng cách hoàn tất tác vụ này:

Để ping máy chủ proxy và lấy giá trị thời gian truyền đi về tính bằng mili giây cho giai đoạn từ 1 đến 2

  1. Chạy lời nhắc chỉ lệnh mức cao bằng cách hoàn tất các bước sau đây:

    1. Bấm Bắt đầu.

    2. Trong hộp Bắt đầu Tìm kiếm, nhập cmd, rồi nhấn CTRL+SHIFT+ENTER.

    3. Nếu hộp thoại Kiểm soát Tài khoản Người dùng xuất hiện, hãy xác nhận rằng hành động mà nó hiển thị là điều bạn muốn, sau đó bấm Tiếp.

  2. Nhập ping <tên của máy chủ proxy mà trình duyệt của bạn dùng, hoặc địa chỉ IP của máy chủ proxy> rồi nhấn ENTER. Nếu bạn cài đặt PsPing hoặc công cụ khác, thì thay vào đó bạn có thể chọn sử dụng công cụ đó.

    Lệnh của bạn có thể trông giống như bất cứ ví dụ nào sau đây:

    • 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. Khi quá trình theo dõi ngừng gửi các gói kiểm tra, bạn sẽ nhận được một bản tóm tắt nhỏ liệt kê một giá trị trung bình tính theo mili giây, và đó là giá trị bạn muốn có. Chụp ảnh màn hình của lời nhắc và lưu nó bằng cách dùng quy ước đặt tên của bạn. Lúc này, có thể cũng sẽ hữu ích nếu điền giá trị vào sơ đồ.

Có thể bạn đã thực hiện theo dõi vào buổi sáng sớm và máy khách của bạn có thể nhanh chóng truy nhập proxy (hoặc bất kỳ máy chủ đầu ra nào đi đến Internet). Trong trường hợp này, số liệu của bạn có thể trông giống như thế này:

Đồ họa cho thấy thời gian truyền đi về từ một máy khách đến một proxy là 2,8 mili giây.

Nếu máy tính khách của bạn là một trong số ít các máy chọn lọc có quyền truy nhập vào máy chủ proxy (hoặc đầu ra), thì bạn có thể chạy nhánh tiếp theo của kiểm tra bằng cách kết nối từ xa với máy tính đó, chạy dấu nhắc lệnh để PsPing đến một URL Office 365 từ đó. Nếu không có quyền truy nhập đến máy tính đó, thì bạn có thể liên lạc với tài nguyên mạng của mình để được trợ giúp về nhánh tiếp theo và lấy số liệu chính xác theo cách này. Nếu việc này không khả thi, hãy thực hiện PsPing dựa trên URL Office 365 cần quan tâm và so sánh nó với thời gian PsPing hoặc Ping dựa trên máy chủ proxy của bạn.

Chẳng hạn, nếu bạn có 51,84 mili giây từ máy khách đến URL Office 365, và có 2,8 mili giây từ máy khách đến proxy (hoặc điểm đầu ra), thì bạn có 49,04 mili giây từ đầu ra tới Office 365. Tương tự, nếu bạn có PsPing 12,25 mili giây từ máy khách tới proxy vào giờ cao điểm trong ngày, và 62,01 mili giây từ máy khách tới URL Office 365, thì giá trị trung bình của bạn cho đầu ra proxy tới URL Office 365 là 49,76 mili giây.

Đồ họa bổ sung hiển thị ping theo mili giây từ máy khách đến proxy bên cạnh máy khách đến Office 365 để có thể trừ các giá trị.

Về mặt khắc phục sự cố, bạn có thể nhận thấy thông tin thú vị chỉ từ việc lưu giữ các đường cơ sở này. Chẳng hạn, nếu bạn nhận thấy rằng nói chung bạn có độ trễ khoảng 40 đến 59 mili giây từ proxy hoặc điểm đầu ra tới URL Office 365 và có độ trễ khoảng 3 đến 7 mili giây từ máy khách đến proxy hoặc điểm đầu ra (tùy thuộc vào mức lưu lượng mạng mà bạn nhìn thấy vào thời điểm đó trong ngày) thì bạn chắc chắn sẽ biết rằng có vấn đề phát sinh nếu ba đường cơ sở của thời gian máy khách đến proxy hoặc đầu ra mới nhất hiển thị độ trễ 45 mili giây.

Phương pháp nâng cao

Nếu bạn thực sự muốn biết điều gì đang xảy ra với các yêu cầu Internet tới Office 365, thì bạn cần làm quen với việc theo dõi mạng. Bất kể bạn muốn dùng công cụ nào cho các theo dõi này, HTTPWatch, Netmon, Message Analyzer, Wireshark, Fiddler, công cụ Bảng điều khiển Nhà phát triển hoặc bất kỳ công cụ nào khác đều được miễn là công cụ đó có thể thu thập và lọc được lưu lượng mạng. Trong phần này, bạn sẽ nhận thấy rằng sẽ hữu ích nếu chạy nhiều công cụ trong số đó để hiểu vấn đề toàn diện hơn. Khi bạn đang kiểm tra, một số công cụ trong số đó cũng thể tự động đóng vai trò như proxy. Các công cụ được dùng trong bài viết dẫn dắt này, Kế hoạch khắc phục sự cố hiệu năng cho Office 365, bao gồm Netmon 3.4, HTTPWatch, or WireShark.

Việc thu thập đường cơ sở hiệu năng là phần đơn giản của phương pháp này và nhiều bước giống như khi bạn khắc phục vấn đề về hiệu năng. Các phương pháp nâng cao hơn trong việc tạo đường cơ sở cho hiệu năng yêu cầu bạn phải thực hiện và lưu trữ theo dõi mạng. Hầu hết các ví dụ trong bài viết này dùng SharePoint Online, nhưng bạn nên phát triển một danh sách hành động phổ biến trên toàn bộ các dịch vụ Office 365 mà bạn đăng ký để kiểm tra và ghi lại. Sau đây là ví dụ về đường cơ sở:

  • Danh sách đường cơ sở cho SPO - Bước 1: Duyệt trang chủ của website SPO và thực hiện theo dõi mạng. Lưu theo dõi.

  • Danh sách đường cơ sở cho SPO - Bước 2: Tìm kiếm một thuật ngữ (chẳng hạn như tên công ty của bạn) thông qua Tìm kiếm trong Doanh nghiệp và thực hiện theo dõi mạng. Lưu theo dõi.

  • Danh sách đường cơ sở cho SPO - Bước 3: Tải một tệp lớn lên thư viện tài liệu SharePoint Online và thực hiện theo dõi mạng. Lưu theo dõi.

  • Danh sách đường cơ sở cho SPO - Bước 4: Duyệt trang chủ của website OneDrive và thực hiện theo dõi mạng. Lưu theo dõi.

Danh sách này nên bao gồm các hành động phổ biến quan trọng nhất mà người dùng thực hiện đối với SharePoint Online. Hãy lưu ý rằng bước cuối cùng: theo dõi đến OneDrive for Business, sẽ dựng sẵn so sánh giữa tải của trang chủ SharePoint Online (thường được công ty tuỳ chỉnh) và trang chủ OneDrive for Business vốn hiếm khi được tùy chỉnh. Đây là một kiểm tra rất cơ bản dành cho site SharePoint Online tải chậm. Bạn có thể dựng một bản ghi về mức chênh lệch này vào kiểm tra của mình.

Nếu bạn đang gặp vấn đề về hiệu năng, thì nhiều bước trong số này giống hệt như khi thu thập đường cơ sở. Theo dõi mạng trở nên rất cần thiết, vì vậy tiếp theo chúng tôi sẽ đề cập đến cách thực hiện các theo dõi quan trọng.

Để xử lý vấn đề về hiệu năng, ngay bây giờ, bạn cần phải theo dõi vào thời điểm bạn đang gặp vấn đề về hiệu năng. Bạn cần có sẵn các công cụ thích hợp để thu thập nhật ký, và cần có một kế hoạch hành động, nghĩa là danh sách các hành động cần thực hiện để thu thập thông tin tốt nhất có thể. Điều đầu tiên cần làm là ghi lại ngày và thời gian của kiểm tra để có thể lưu tệp vào thư mục phản ánh thời điểm đó. Tiếp theo, hãy thu hẹp xuống đến các bước của vấn đề. Đây là các bước chính xác mà bạn sẽ dùng để kiểm tra. Đừng quên điều cơ bản: nếu sự cố này chỉ xảy ra với Outlook, hãy đảm bảo ghi lại rằng hành vi của vấn đề chỉ xảy ra ở một dịch vụ Office 365. Việc thu hẹp phạm vi của vấn đề này sẽ giúp bạn tập trung vào phần mà bạn có thể giải quyết.

Xem Thêm

Quản lý điểm cuối Office 365

Phát triển các kỹ năng của bạn
Khám phá nội dung đào tạo
Sở hữu tính năng mới đầu tiên
Tham gia Người dùng nội bộ Office

Thông tin này có hữu ích không?

Cảm ơn phản hồi của bạn!

Cảm ơn bạn đã phản hồi! Để trợ giúp tốt hơn, có lẽ chúng tôi sẽ kết nối bạn với một trong những nhân viên hỗ trợ Office của chúng tôi.

×