Bài viết của John O'Shea

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.

Khai thác bảng thông tin tại Amazon

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.

Các loại bảng thông tin

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:

Các loại bảng thông tin

Bảng thông tin cấp cao

Bảng thông tin về trải nghiệm của khách hà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?"

Bảng thông tin cấp hệ thống

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.

Bảng thông tin phiên bản dịch vụ

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.

Bảng thông tin kiểm tra dịch vụ

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 đó.

Bảng thông tin dự báo và lập kế hoạch năng lự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ụ.

Bảng thông tin cấp thấp

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 riêng cho vi dịch vụ

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.

Bảng thông tin về cơ sở hạ tầng

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.

Bảng thông tin về thành phần phụ thuộc

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.

Thiết kế bảng thông tin

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:

Thiết kế bảng thông tin

Chúng tôi dùng biểu đồ lớn hơn cho các số liệu quan trọng nhất

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.

Chúng tôi bố trí biểu đồ đáp ứng độ phân giải màn hình tối thiểu dự kiến

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.

Chúng tôi hiển thị múi giờ

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 sử dụng khoảng thời gian và khoảng thời gian điểm dữ liệu ngắn nhất

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.

Chúng tôi cho phép điều chỉnh khoảng thời gian và giai đoạn số liệu

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
Bảng thông tin có các khoảng thời gian

Chúng tôi chú thích biểu đồ bằng các ngưỡng cảnh báo

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.

Chúng tôi tránh thêm đường ngang vào các biểu đồ đã dùng trục y ở cả bên trái và bên phải

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.

Bảng thông tin có các đường ngang

Chúng tôi tránh gây quá tải cho trục y bằng cách không đưa vào các số liệu có khoảng giá trị quá khác nhau

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.

Bảng thông tin với trục y có nhiều số liệu

Chúng tôi thận trọng trong việc thu hẹp giới hạn trục y xuống đúng khoảng giá trị của điểm dữ liệu hiện tại

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 tránh gây quá tải cho các biểu đồ đơn

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)

Chúng tôi không cho rằng người dùng biết chính xác ý nghĩa của mọi số liệu hay tiện ích

Đ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.
Không cho rằng người dùng biết mọi số liệu trong bảng thông tin

Chúng tôi sử dụng trạng thái cảnh báo, con số đơn giản và/hoặc tiện ích biểu đồ chuỗi thời gian nếu thích hợp

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ử dụng con số đơn giản nếu thích hợp

Chúng tôi tránh sử dụng các biểu đồ hiển thị số liệu hiếm

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 thêm các biểu đồ khác để hiển thị số liệu cho mỗi chế độ

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.

Bảo trì bảng thông tin

Việc xây dựng bảng thông tin thể hiện nhiều chế độ xem hệ thống là bước đầu tiên. Tuy nhiên, hệ thống của chúng tôi sẽ liên tục phát triển và mở rộng quy mô, khi các tính năng mới được thêm vào và các kiến trúc được cải tiến, các bảng thông tin cũng cần phải phát triển tương xứng. Việc bảo trì và cập nhật bảng thông tin là hoạt động cốt lõi trong quá trình phát triển của chúng tôi. Trước khi hoàn thành các thay đổi và trong quá trình đánh giá mã, các nhà phát triển của chúng tôi luôn tự hỏi: "Tôi có cần cập nhật bất kỳ bảng thông tin nào không?" Họ được phép thay đổi bảng thông tin trước khi triển khai các thay đổi cơ bản. Việc này giúp tránh được tình huống người vận hành phải cập nhật bảng thông tin trong hoặc sau khi triển khai hệ thống để xác thực thay đổi đang được triển khai.

Nếu bảng thông tin chứa nhiều thông tin chi tiết hơn bình thường thì điều đó có thể cho thấy rằng người vận hành đang dùng bảng thông tin đó để tự mình phát hiện bất thường thay cho hoạt động cảnh báo và khắc phục tự động. Chúng tôi liên tục kiểm tra các bảng thông tin của mình để xem liệu có cách nào có thể giảm bớt nỗ lực thủ công này thông qua việc cải thiện việc đo lường trong các dịch vụ của chúng tôi và nâng cao tính năng báo động tự động hay không. Chúng tôi cũng tích cực lược bỏ hoặc cập nhật các biểu đồ không còn tạo thêm giá trị cho bảng thông tin.

Bằng cách cho phép các nhà phát triển của mình cập nhật bảng thông tin, chúng tôi đảm bảo rằng chúng tôi có một bộ bảng thông tin hoàn chỉnh, giống hệt nhau cho môi trường tiền sản xuất (alpha, beta hoặc gamma). Các quy trình triển khai tự động của chúng tôi sẽ triển khai các thay đổi vào môi trường tiền sản xuất trước tiên. Như vậy, các nhóm phải có thể xác nhận thay đổi dễ dàng trong các môi trường kiểm thử này bằng bảng thông tin được liên kết (và báo động tự động) theo cách hoàn toàn nhất quán với cách xác thực khi thay đổi được đưa vào môi trường sản xuất của chúng tôi.

Hầu hết các hệ thống sẽ không ngừng phát triển khi các yêu cầu được cập nhật, các tính năng mới được bổ sung và kiến trúc phần mềm sẽ thay đổi để phù hợp với việc mở rộng quy mô theo thời gian. Bảng thông tin là một thành phần thiết yếu trong hệ thống của chúng tôi, vì vậy chúng tôi tuân theo quy trình Cơ sở hạ tầng dưới dạng mã (IaC) để bảo trì chúng. Quy trình này sẽ đảm bảo bảng thông tin được duy trì trong hệ thống kiểm soát phiên bản và các thay đổi sẽ được triển khai cho bảng thông tin bằng chính các công cụ mà nhà phát triển và người vận hành sử dụng cho dịch vụ của chúng tôi.

Khi chúng tôi phân tích để rút kinh nghiệm về một sự kiện vận hành không mong muốn, các nhóm sẽ xem xét liệu các cải tiến đối với bảng thông tin (và báo động tự động) có thể ngăn ngừa sự kiện, xác định nguyên nhân gốc nhanh hơn hay giảm thời gian phục hồi trung bình hay không. Chúng tôi thường tự hỏi rằng: “Nghĩ lại xem bảng thông tin có hiển thị rõ ràng tác động đến khách hàng, giúp người vận hành phân loại để xác định nguyên nhân gốc cuối cùng và hỗ trợ tính toán thời gian phục hồi không?” Nếu câu trả lời cho bất kỳ câu hỏi nào ở trên là không thì quá trình phân tích rút kinh nghiệm của chúng tôi sẽ bao gồm hoạt động tinh chỉnh các bảng thông tin đó. 

Kết luận

Tại Amazon, chúng tôi vận hành các dịch vụ quy mô lớn trên toàn thế giới. Hệ thống tự động của chúng tôi liên tục theo dõi, phát hiện, cảnh báo và khắc phục mọi sự cố có thể xảy ra. Chúng tôi cần có khả năng giám sát, tìm hiểu sâu, kiểm tra và đánh giá các dịch vụ và hệ thống tự động này. Để đạt được điều này, chúng tôi xây dựng và duy trì các bảng thông tin mang đến nhiều chế độ xem khác nhau về hệ thống của mình. Chúng tôi thiết kế các bảng thông tin này cho cả phạm vi đối tượng rộng lớn và cụ thể bằng cách bắt đầu từ vạch đích - người dùng bảng thông tin. Để giúp bảng thông tin trở nên dễ hiểu hơn với người vận hành và chủ sở hữu dịch vụ, chúng tôi sử dụng một bộ đặc ngữ và quy ước thiết kế thống nhất để đảm bảo khả năng sử dụng và tiện ích của bảng thông tin.

Bảng thông tin của chúng tôi mang đến nhiều góc nhìn và chế độ xem khác nhau về cách thức hoạt động của các dịch vụ AWS. Chúng đóng vai trò quan trọng trong việc đem đến trải nghiệm tuyệt vời cho khách hàng bằng cách giúp các nhóm Amazon hiểu, vận hành và mở rộng quy mô dịch vụ. Chúng tôi hy vọng bài viết này sẽ hữu ích khi bạn chuẩn bị thiết kế, xây dựng và duy trì bảng thông tin của riêng mình.  Nếu bạn muốn biết ví dụ về cách tạo bảng thông tin bằng các dịch vụ AWS, vui lòng tham khảo video ngắnhướng dẫn tự thực hành này.


Về tác giả

John O'Shea là Kỹ sư chính tại Amazon Web Services. Ông hiện tập trung vào Amazon CloudWatch cũng như các dịch vụ giám sát và quan sát nội bộ khác của Amazon.