Xây dựng bảng thông tin về hoạt động vận hành

Tất cả chúng ta đều chạy các ứng dụng trên máy tính xách tay, máy tính bảng và điện thoại thông minh của mình. Chúng ta dễ dàng biết được liệu thiết bị đã được cấp nguồn chưa và kết nối mạng Wi-Fi có trực tuyến hay không. Chúng ta biết rằng màn hình sẽ hiển thị mọi thông báo quan trọng, chẳng hạn như cảnh báo sắp hết dung lượng đĩa trống. Trên thực tế, tốc độ chung và khả năng phản hồi của giao diện người dùng (UI) có thể là một chỉ báo tốt về việc liệu thiết bị có đủ tài nguyên, như bộ nhớ hoặc CPU, để chạy các ứng dụng hay không.

Bất kỳ ai từng hỗ trợ kỹ thuật từ xa cho thiết bị của gia đình họ đều có thể công nhận rằng việc phát hiện và chẩn đoán sự cố sẽ khó hơn một chút khi bạn không thể nhìn thấy và tương tác trực tiếp với thiết bị. Vì vậy, khi nói đến việc chạy các dịch vụ dựa trên đám mây, chúng tôi phải đối mặt với một thách thức tương tự: Làm thế nào để chúng tôi có thể giám sát các dịch vụ từ xa này và làm thế nào để chúng tôi biết khách hàng của mình hài lòng?

Để quan sát dịch vụ trên một máy chủ, chúng tôi có thể đăng nhập vào máy chủ đó, chạy nhiều công cụ giám sát thời gian hoạt động và kiểm tra nhật ký để xác định nguyên nhân gốc của những gì đang xảy ra trên máy chủ. Tuy nhiên, các giải pháp trên một máy chủ chỉ khả thi đối với các dịch vụ không quan trọng và đơn giản nhất. Đối lập là các vi dịch vụ phân tán, nhiều tầng, chạy trên hàng trăm hoặc hàng nghìn máy chủ, bộ chứa hoặc môi trường phi máy chủ.

Làm thế nào để Amazon biết được tất cả các dịch vụ dựa trên đám mây, chạy trong nhiều Vùng sẵn sàng ở nhiều Khu vực trên toàn thế giới, đang thực sự hoạt động như thế nào? Giám sát tự động, quy trình khắc phục tự động (ví dụ như chuyển đổi lưu lượng) và hệ thống triển khai tự động đóng vai trò quan trọng trong việc phát hiện và giải quyết phần lớn các sự cố ở quy mô này. Tuy nhiên, vì nhiều lý do, chúng tôi vẫn cần có khả năng biết được các dịch vụ, quy trình và hoạt động triển khai này đang làm gì tại bất kỳ thời điểm nào một cách kịp thời.

Chúng tôi sử dụng bảng thông tin như một cơ chế để giải quyết thách thức trong việc luôn cập nhật hoạt động trong các dịch vụ đám mây của mình. Bảng thông tin là dạng xem dành cho người dùng giúp chúng tôi quan sát hệ thống, cung cấp các bản tóm tắt ngắn gọn về cách hệ thống đang hoạt động qua việc hiển thị số liệu chuỗi thời gian, nhật ký, dấu vết và dữ liệu cảnh báo.

Tại Amazon, chúng tôi coi việc tạo, sử dụng và bảo trì liên tục các bảng thông tin này là việc khai thác bảng thông tin. Khai thác bảng thông tin đã phát triển thành hoạt động hàng đầu vì việc này đóng vai trò quan trọng đối với sự thành công của dịch vụ không khác gì các hoạt động vận hành và phân phối phần mềm hàng ngày khác, chẳng hạn như thiết kế, lập trình, xây dựng, kiểm thử, triển khai và mở rộng dịch vụ.

Tất nhiên, chúng tôi không mong đợi người vận hành của mình lúc nào cũng giám sát bảng thông tin. Thông thường, không ai xem các bảng thông tin này. Trên thực tế, chúng tôi nhận thấy rằng bất kỳ quy trình hoạt động nào yêu cầu đánh giá thủ công bảng thông tin sẽ không thành công do lỗi của con người, bất kể tần suất đánh giá bảng thông tin. Để giải quyết rủi ro này, chúng tôi đã tạo các cảnh báo tự động liên tục đánh giá các dữ liệu giám sát quan trọng nhất do hệ thống của chúng tôi phát ra. Thông thường, đây là những số liệu cho biết hệ thống đang đạt đến một giới hạn nào đó (phát hiện chủ động, trước khi tác động) hoặc hệ thống đã bị suy yếu theo một cách không mong muốn nào đó (phát hiện bị động, sau khi tác động).

Những cảnh báo này có thể thực hiện quy trình khắc phục tự động và có thể thông báo cho người vận hành của chúng tôi rằng đã xảy ra sự cố. Thông báo này hướng người vận hành đến các bảng thông tin và tài liệu vận hành chính xác mà họ cần sử dụng. Khi tôi đang trực và nhận được thông báo cảnh báo về sự cố, tôi có thể nhanh chóng sử dụng các bảng thông tin liên quan để xác định định lượng về tác động đến khách hàng, xác thực hoặc phân loại nguyên nhân gốc, giảm thiểu và giảm thời gian phục hồi. Ngay cả khi cảnh báo đã bắt đầu quy trình khắc phục tự động, tôi vẫn cần xem quy trình tự động đang làm gì, ảnh hưởng đến hệ thống như thế nào và trong những trường hợp ngoại lệ, thúc đẩy quy trình bằng cách cung cấp xác nhận của con người đối với các bước quan trọng đối với sự an toàn.

Khi một sự kiện đang diễn ra, Amazon thường yêu cầu nhiều người vận hành đang trực tham gia. Người vận hành có thể sử dụng các bảng thông tin khác nhau khi thực hiện chuỗi nhiệm vụ. Những nhiệm vụ này thường bao gồm việc xác định định lượng về tác động đối với khách hàng, phân loại, theo dõi trên nhiều dịch vụ để tìm ra nguyên nhân gốc của sự kiện, quan sát quy trình khắc phục tự động và thực thi cũng như xác thực các bước giảm thiểu dựa trên tài liệu vận hành. Trong khi đó, các nhóm ngang hàng và các bên liên quan trong kinh doanh cũng đang sử dụng bảng thông tin để theo dõi tác động đang diễn ra trong suốt sự kiện. Những người tham gia khác nhau này giao tiếp bằng cách sử dụng các công cụ quản lý sự cố, phòng trò chuyện (với các bot như AWS Chatbot) và các cuộc gọi hội nghị. Mỗi bên liên quan có một quan điểm khác nhau về dữ liệu mà họ thấy trong bảng thông tin.

Hàng tuần, các nhóm của Amazon và các tổ chức lớn hơn cũng tổ chức các cuộc họp đánh giá hoạt động có sự tham gia của các nhà lãnh đạo cấp cao, quản lý và nhiều kỹ sư. Trong các cuộc họp đó, chúng tôi sử dụng vòng quay may mắn để chọn các bảng thông tin kiểm tra cấp cao. Các bên liên quan đánh giá trải nghiệm của khách hàng và các mục tiêu cấp độ dịch vụ chính, chẳng hạn như độ sẵn sàng và độ trễ. Bảng thông tin kiểm tra mà các bên liên quan này sử dụng thường hiển thị dữ liệu hoạt động từ tất cả các Vùng sẵn sàng và Khu vực.

Ngoài ra, khi lập kế hoạch và dự báo năng lực dài hạn, Amazon sử dụng bảng thông tin trực quan hóa số liệu kinh doanh, mức sử dụng và năng lực cấp cao nhất mà hệ thống của chúng tôi tạo ra trong các khoảng thời gian dài hơn.

Mọi người sử dụng bảng thông tin để giám sát các dịch vụ theo cách thủ công, nhưng không có một loại bảng nào phù hợp với tất cả các trường hợp sử dụng. Đối với hầu hết các hệ thống, chúng tôi sử dụng nhiều bảng thông tin, mỗi bảng cung cấp một chế độ xem khác nhau về hệ thống. Các chế độ xem khác nhau này giúp những người dùng khác nhau hiểu cách hệ thống của chúng tôi đang hoạt động từ các khía cạnh khác nhau và trong các khoảng thời gian khác nhau.

Dữ liệu mà mỗi đối tượng muốn xem có thể khác nhau đáng kể giữa các bảng thông tin. Chúng tôi đã học cách tập trung vào đối tượng dự kiến khi thiết kế bảng thông tin. Chúng tôi quyết định dữ liệu nào được đưa vào từng bảng thông tin dựa trên việc ai sẽ sử dụng bảng thông tin và lý do họ sẽ sử dụng bảng thông tin. Có thể bạn đã nghe nói rằng tại Amazon, chúng tôi bắt đầu từ vạch đích - khách hàng. Tạo bảng thông tin là một ví dụ điển hình về điều này. Chúng tôi xây dựng bảng thông tin dựa trên nhu cầu của người dùng dự kiến và yêu cầu cụ thể của họ.

Sơ đồ sau minh họa cách các bảng thông tin khác nhau cung cấp các chế độ xem khác nhau về toàn bộ hệ thống:

Tại Amazon, bảng thông tin quan trọng nhất và được sử dụng rộng rãi nhất là bảng thông tin về trải nghiệm của khách hàng. Các bảng thông tin này được thiết kế để nhiều nhóm người dùng sử dụng, trong đó có người vận hành dịch vụ và nhiều bên liên quan khác. Các bảng thông tin này trình bày một cách hiệu quả số liệu về tình trạng dịch vụ chung và việc tuân thủ các mục tiêu. Chúng hiển thị dữ liệu giám sát được lấy từ chính dịch vụ và cả từ công cụ đo lường máy khách, công cụ kiểm thử liên tục (chẳng hạn như công cụ theo dõi Amazon CloudWatch Synthetics) và hệ thống khắc phục tự động. Các bảng thông tin này cũng chứa dữ liệu giúp người dùng trả lời các câu hỏi về mức độ sâu và rộng của tác động. Một số câu hỏi trong số này có thể là "Có bao nhiêu khách hàng bị ảnh hưởng?" và "Những khách hàng nào bị ảnh hưởng nhiều nhất?"

Các điểm nhập vào các dịch vụ dựa trên web của chúng tôi thường là điểm cuối UI và API, vì vậy, các bảng thông tin cấp hệ thống chuyên dụng phải chứa đủ dữ liệu để người vận hành có thể xem hệ thống và các điểm cuối hướng tới khách hàng đang hoạt động như thế nào. Các bảng thông tin này chủ yếu hiển thị dữ liệu giám sát cấp giao diện. Các bảng thông tin này hiển thị ba danh mục dữ liệu giám sát cho mỗi API:

• Dữ liệu giám sát liên quan đến đầu vào. Dữ liệu này có thể bao gồm số lượng yêu cầu nhận được hoặc công việc được thăm dò từ hàng đợi/luồng, phân vị kích thước byte yêu cầu và số lỗi xác thực/ủy quyền.
• Dữ liệu giám sát liên quan đến việc xử lý. Dữ liệu này có thể bao gồm số lượng đường dẫn logic doanh nghiệp đa phương thức/thực thi nhánh, số lượng yêu cầu vi dịch vụ phụ trợ/phân vị lỗi/độ trễ, đầu ra nhật ký lỗi và sai hỏng cũng như dữ liệu theo dõi yêu cầu.
• Dữ liệu giám sát liên quan đến đầu ra. Dữ liệu này có thể bao gồm số lượng loại phản hồi (với các bảng phân tích phản hồi về lỗi/sai hỏng của khách hàng), kích thước phản hồi và tỷ lệ phần trăm cho thời gian ghi byte phản hồi đầu tiên và thời gian ghi phản hồi hoàn thành.

Thông thường, chúng tôi đặt mục tiêu duy trì trải nghiệm của khách hàng và bảng thông tin cấp hệ thống ở mức cao nhất có thể. Chúng tôi chủ động tránh việc muốn thêm quá nhiều số liệu vào các bảng thông tin này vì quá nhiều thông tin có thể làm phân tán thông điệp cốt lõi mà các bảng thông tin này cần truyền tải.

Chúng tôi xây dựng một số bảng thông tin để tạo điều kiện đánh giá nhanh chóng và toàn diện về trải nghiệm của khách hàng trong một phiên bản dịch vụ duy nhất (phân vùng hoặc ô). Chế độ xem thu hẹp này đảm bảo rằng người vận hành làm việc trên một phiên bản dịch vụ duy nhất không bị quá tải với dữ liệu không liên quan từ các phiên bản dịch vụ khác.

Chúng tôi cũng xây dựng các bảng thông tin về trải nghiệm của khách hàng nhằm mục đích hiển thị dữ liệu cho tất cả các phiên bản dịch vụ, trên tất cả các Vùng sẵn sàng và Khu vực. Các bảng thông tin kiểm tra dịch vụ này được người vận hành sử dụng để kiểm tra báo động tự động trên tất cả các phiên bản dịch vụ. Các báo động này cũng có thể được đánh giá trong các cuộc họp hoạt động hàng tuần đã đề cập trước đó.

Đối với các trường hợp sử dụng lâu dài hơn, chúng tôi cũng xây dựng bảng thông tin để lập kế hoạch và dự báo năng lực nhằm hình dung sự phát triển của các dịch vụ.

Các API của Amazon thường được triển khai bằng cách sắp xếp các yêu cầu trên các vi dịch vụ phụ trợ. Các vi dịch vụ này có thể thuộc sở hữu của các nhóm khác nhau, mỗi nhóm chịu trách nhiệm về một số khía cạnh cụ thể của việc xử lý yêu cầu. Ví dụ: Một số vi dịch vụ dành riêng để yêu cầu xác thực và ủy quyền, thực thi điều chỉnh/giới hạn, đo lường mức sử dụng, tạo/cập nhật/xóa tài nguyên, truy xuất tài nguyên từ kho dữ liệu và bắt đầu quy trình không đồng bộ. Các nhóm thường xây dựng ít nhất một bảng thông tin dành riêng cho từng vi dịch vụ, hiển thị số liệu cho từng API hoặc đơn vị công việc nếu dịch vụ đang xử lý dữ liệu một cách không đồng bộ.

Bảng thông tin dành cho vi dịch vụ thường hiển thị dữ liệu giám sát cụ thể về việc triển khai và yêu cầu kiến thức sâu về dịch vụ. Các bảng thông tin này chủ yếu được sử dụng bởi các nhóm sở hữu dịch vụ. Tuy nhiên, vì các dịch vụ của chúng tôi có nhiều công cụ đo lường, nên chúng tôi cần trình bày dữ liệu từ hoạt động đo lường này sao cho không khiến người vận hành cảm thấy quá tải. Vì vậy, các bảng thông tin này thường hiển thị một số dữ liệu ở dạng tổng hợp. Khi người vận hành xác định các điểm bất thường trong dữ liệu tổng hợp, họ thường sử dụng nhiều công cụ khác để tìm hiểu sâu hơn, thực thi các truy vấn đặc ứng trên dữ liệu giám sát cơ bản để phân tách dữ liệu, theo dõi các yêu cầu và tìm ra dữ liệu có liên quan hoặc tương quan.

Các dịch vụ của chúng tôi chạy trên cơ sở hạ tầng AWS, mà cơ sở hạ tầng này thường tạo ra các số liệu, vì vậy chúng tôi cũng có các bảng thông tin chuyên dụng về cơ sở hạ tầng. Các bảng thông tin này chủ yếu tập trung vào các số liệu được tạo ra bởi các tài nguyên tính toán là cơ sở hạ tầng cho hệ thống của chúng tôi, chẳng hạn như các phiên bản Amazon Elastic Compute Cloud (EC2), Amazon Elastic Container Service (ECS)/Amazon Elastic Kubernetes Service (EKS) và các hàm AWS Lambda. Các số liệu như mức sử dụng CPU, lưu lượng mạng, IO đĩa và mức sử dụng dung lượng thường được dùng trong các bảng thông tin này, cùng với mọi số liệu cụm liên quan, Auto Scaling và các số liệu hạn mức liên quan đến các tài nguyên tính toán này.

Ngoài tài nguyên tính toán, trong nhiều trường hợp, vi dịch vụ còn phụ thuộc vào các vi dịch vụ khác. Ngay cả khi các nhóm sở hữu những thành phần phụ thuộc đó đã có bảng thông tin của riêng họ thì mỗi chủ sở hữu vi dịch vụ vẫn thường tạo bảng thông tin thành phần phụ thuộc chuyên dụng để cung cấp chế độ xem về cách thức cả thành phần phụ thuộc ngược dòng (ví dụ: proxy và cân bằng tải) và thành phần phụ thuộc xuôi dòng (ví dụ: kho dữ liệu, hàng đợi và luồng) đang hoạt động, được đo lường bởi dịch vụ của họ. Các bảng thông tin này cũng có thể được sử dụng để theo dõi các số liệu quan trọng khác, chẳng hạn như ngày hết hạn chứng chỉ bảo mật và mức sử dụng hạn mức của thành phần phụ thuộc khác.

Tại Amazon, chúng tôi coi sự nhất quán trong việc trình bày dữ liệu là yếu tố quan trọng để tạo thành công một bảng thông tin. Để đạt hiệu quả, phải đảm bảo sự nhất quán trong từng bảng thông tin và trên tất cả các bảng thông tin. Trong những năm qua, chúng tôi đã xác định, điều chỉnh và tinh chỉnh một tuyển tập đặc ngữ và quy ước thiết kế chung mà chúng tôi tin rằng có thể giúp bảng thông tin tiếp cận được với nhiều đối tượng nhất, hướng đến tăng giá trị của chúng với tổ chức của chúng tôi. Chúng tôi thậm chí đã tìm được những cách hay để đo lường và cải thiện các quy ước thiết kế này theo thời gian. Ví dụ: Nếu nhân viên vận hành mới có thể nhanh chóng hiểu và sử dụng dữ liệu được trình bày trong bảng thông tin để tìm hiểu về cách thức hoạt động của một dịch vụ thì đó là dấu hiệu cho thấy các bảng thông tin đó đang hiển thị đúng thông tin, theo đúng cách.

Một xu hướng rất phổ biến khi thiết kế bảng thông tin là đánh giá quá cao hoặc quá thấp kiến thức về miền của người dùng mục tiêu. Việc xây dựng bảng thông tin hoàn toàn dễ hiểu với người tạo ra bảng thì rất đơn giản. Tuy nhiên, bảng thông tin này có thể không mang đến giá trị cho người dùng. Chúng tôi dùng kỹ thuật bắt đầu từ vạch đích - khách hàng (trong trường hợp này là người dùng bảng thông tin) để loại bỏ rủi ro này.

Chúng tôi đã áp dụng quy ước thiết kế chuẩn hóa bố cục dữ liệu trong bảng thông tin. Bảng thông tin hiển thị từ trên xuống dưới và người dùng có xu hướng coi các biểu đồ hiển thị lúc đầu (hiển thị khi bảng thông tin tải) là thông tin quan trọng nhất. Do đó, quy ước thiết kế của chúng tôi khuyên bạn nên đặt dữ liệu quan trọng nhất ở đầu bảng thông tin. Chúng tôi nhận thấy biểu đồ độ sẵn sàng tổng hợp/tóm tắt và biểu đồ phân vị độ trễ toàn diện thường là những bảng thông tin quan trọng nhất về các dịch vụ web.

Dưới đây là ảnh chụp màn hình phần đầu bảng thông tin cho Dịch vụ Foo giả định:

Nếu có nhiều số liệu trong biểu đồ, chúng tôi đảm bảo sẽ không chèn chú giải biểu đồ theo chiều dọc hay chiều ngang vào phần hiển thị dữ liệu biểu đồ. Nếu đang sử dụng các truy vấn tìm kiếm trong biểu đồ, chúng tôi đảm bảo cho phép trả về tập kết quả số liệu lớn hơn bình thường.

Việc này giúp người dùng không phải cuộn theo chiều ngang. Một nhân viên vận hành đang trực trên máy tính xách tay lúc 3 giờ sáng có thể không chú ý đến thanh cuộn ngang nếu không có dấu hiệu trực quan rõ ràng cho thấy còn có các đồ thị khác ở bên phải.

Với các bảng thông tin hiển thị dữ liệu ngày giờ, chúng tôi đảm bảo múi giờ tương ứng sẽ hiển thị trong bảng thông tin. Với các bảng thông tin được nhiều người vận hành ở nhiều múi giờ cùng sử dụng, chúng tôi đặt mặc định về một múi giờ (UTC) mà mọi người dùng đều có thể xác định. Bằng cách này, người dùng có thể liên lạc với nhau theo cùng một múi giờ, giúp tiết kiệm thời gian và công sức nhờ không phải nhẩm tính múi giờ quá nhiều.

Chúng tôi đặt khoảng thời gian và giai đoạn điểm dữ liệu mặc định tương ứng với các trường hợp sử dụng phổ biến nhất. Chúng tôi đảm bảo rằng lúc đầu, tất cả biểu đồ trên bảng thông tin đều hiển thị dữ liệu cho cùng một khoảng thời gian và độ phân giải. Chúng tôi nhận thấy nếu kích thước chiều ngang của tất cả biểu đồ trong một phần của bảng thông tin đều giống nhau thì rất có lợi. Việc này giúp bạn dễ dàng đối chiều thời gian giữa các biểu đồ.

Chúng tôi cũng tránh vẽ quá nhiều điểm dữ liệu trong biểu đồ vì việc này sẽ kéo dài thời gian tải bảng thông tin. Ngoài ra, theo quan sát của chúng tôi, việc hiển thị quá nhiều điểm dữ liệu cho người dùng thực sự có thể làm giảm khả năng thấy rõ các điểm bất thường. Ví dụ: Biểu đồ thể hiện khoảng thời gian 3 giờ của các điểm dữ liệu độ phân giải 1 phút chứa đúng 180 giá trị cho mỗi số liệu sẽ hiển thị rõ ràng trong cả những tiện ích bảng thông tin nhỏ. Số lượng điểm dữ liệu này cũng cung cấp đủ ngữ cảnh cho những người vận hành đang phân loại các sự kiện hoạt động đang diễn ra.

Bảng thông tin của chúng tôi có các điều khiển để điều chỉnh nhanh cả khoảng thời gian và giai đoạn số liệu cho mọi biểu đồ. Chúng tôi còn dùng các tỷ lệ khoảng thời gian x độ phân giải phổ biến khác trong bảng thông tin như:

• 1 giờ x 1 phút (60 điểm dữ liệu) – thích hợp để phóng to nhằm quan sát các sự kiện đang diễn ra
• 12 giờ x 1 phút (720 điểm dữ liệu)
• 1 ngày x 5 phút (288 điểm dữ liệu) – thích hợp để xem xu hướng hàng ngày
• 3 ngày x 5 phút (864 điểm dữ liệu)
• 1 tuần x 1 giờ (168 điểm dữ liệu) – thích hợp để xem xu hướng hàng tuần
• 1 tháng x 1 giờ (744 điểm dữ liệu)
• 3 tháng x 1 ngày (90 điểm dữ liệu) – thích hợp để xem xu hướng hàng quý
• 9 tháng x 1 ngày (270 điểm dữ liệu)
• 15 tháng x 1 ngày (450 điểm dữ liệu) – thích hợp để xem đánh giá năng lực dài hạn
  

Khi chúng tôi lập biểu đồ số liệu liên quan đến các cảnh báo tự động, nếu ngưỡng cảnh báo là tĩnh, chúng tôi sẽ chú thích biểu đồ bằng các đường ngang. Nếu ngưỡng cảnh báo là động, tức là dựa trên các dự báo hoặc dự đoán mà trí tuệ nhân tạo (AI) hoặc máy học (ML) đưa ra, chúng tôi sẽ hiển thị cả số liệu thực tế và số liệu ngưỡng trong cùng biểu đồ. Nếu biểu đồ hiển thị số liệu đo lường một khía cạnh dịch vụ có giới hạn xác định (chẳng hạn như giới hạn “được kiểm thử tối đa” hoặc giới hạn tài nguyên cố định), chúng tôi sẽ chú thích biểu đồ bằng một đường ngang cho biết mức độ giới hạn đã biết hoặc được kiểm thử. Với các số liệu có mục tiêu, chúng tôi sẽ thêm các đường ngang để hiển thị ngay những mục tiêu này cho người dùng.

Nếu bạn thêm đường ngang vào những biểu đồ này, có thể người dùng sẽ khó biết được đường ngang tương ứng với trục y nào. Để tránh nhầm lẫn, chúng tôi chia các biểu đồ dạng này thành hai biểu đồ sử dụng chung một trục ngang và chỉ thêm đường ngang vào biểu đồ thích hợp.

Chúng tôi tránh tình huống này vì nó có thể làm giảm khả năng quan sát sự biến động của một hoặc nhiều số liệu. Ví dụ: Khi chúng tôi biểu thị độ trễ p0 (tối thiểu) và p100 (tối đa) trên cùng một biểu đồ, trong đó các giá trị của điểm dữ liệu p100 có thể có độ lớn lớn hơn điểm dữ liệu p0.

Việc nhìn lướt qua biểu đồ có phạm vi trục y giới hạn ở các giá trị điểm dữ liệu có thể làm cho số liệu có vẻ biến động hơn nhiều so với thực tế.

Chúng tôi muốn đảm bảo rằng sẽ không có quá nhiều số liệu thống kê hoặc số liệu không liên quan trong một biểu đồ đơn. Ví dụ: Khi thêm biểu đồ để xử lý yêu cầu, chúng tôi thường tạo các biểu đồ riêng lẻ, liền kề trong bảng thông tin để thể hiện các số liệu sau:

• Độ sẵn sàng % (Lỗi/Yêu cầu * 100)
• Độ trễ p10, Trung bình, p90
• Độ trễ p99.9 và Tối đa (p100)
  

Điều này đặc biệt đúng với số liệu của mỗi lần triển khai. Chúng tôi muốn cung cấp đầy đủ ngữ cảnh trong văn bản bảng thông tin, chẳng hạn bằng văn bản mô tả bên cạnh hoặc bên dưới mỗi biểu đồ. Người vận hành có thể đọc văn bản này để hiểu ý nghĩa của số liệu. Sau đó, người vận hành có thể hiểu được trạng thái "bình thường" là như thế nào và nếu biểu đồ không "bình thường" thì có nghĩa gì. Trong văn bản này, chúng tôi sẽ cung cấp liên kết đến các tài nguyên liên quan mà người vận hành có thể sử dụng để xác định nguyên nhân gốc. Chúng tôi cung cấp một số loại liên kết như:

• Đến tài liệu vận hành. Với các chuyên gia theo lĩnh vực, bảng thông tin có thể là tài liệu vận hành.
• Đến bảng thông tin “chuyên sâu” liên quan.
• Đến các bảng thông tin tương đương cho các cụm hoặc phân vùng khác.
• Đến các quy trình triển khai.
• Đến thông tin liên hệ của thành phần phụ thuộc.
  

Tùy thuộc vào trường hợp sử dụng bảng thông tin, chúng tôi thấy rằng việc hiển thị tiện ích chứa một số duy nhất (ví dụ: giá trị mới nhất của số liệu) hoặc trạng thái cảnh báo đôi khi thích hợp hơn việc hiển thị biểu đồ chuỗi thời gian phức tạp cho mọi điểm dữ liệu gần đây.

Số liệu hiếm là số liệu chỉ được tạo ra khi có một số điều kiện lỗi nhất định. Mặc dù đây có thể là cách hiệu quả để chỉ tạo ra những số liệu này khi cần thiết đối với các dịch vụ đo lường, nhưng các biểu đồ trống hoặc gần như trống có thể khiến người dùng bảng thông tin cảm thấy khó hiểu. Khi gặp dạng số liệu này trong lúc thiết kế bảng thông tin, chúng tôi thường chỉnh sửa dịch vụ để không ngừng tạo ra giá trị an toàn (nghĩa là bằng 0) cho các số liệu này trong trường hợp không có điều kiện lỗi. Nhờ đó, người vận hành có thể dễ dàng hiểu được việc không có dữ liệu nghĩa là dịch vụ không tạo ra phép đo từ xa chính xác.

Chúng tôi làm vậy khi hiển thị biểu đồ cho số liệu tổng hợp từ hành vi đa mô hình trong hệ thống. Những trường hợp có thể thêm biểu đồ khác gồm:

• Nếu dịch vụ hỗ trợ yêu cầu ở nhiều kích thước, chúng tôi có thể tạo một biểu đồ cho độ trễ tổng thể của các yêu cầu. Ngoài ra, chúng tôi cũng có thể tạo biểu đồ hiển thị số liệu cho các yêu cầu nhỏ, trung bình và lớn.
• Nếu một dịch vụ thực thi yêu cầu theo những cách khác nhau tùy thuộc vào giá trị (hoặc tổ hợp) của các tham số đầu vào thì chúng tôi có thể thêm biểu đồ cho các số liệu ghi lại từng chế độ thực thi.