Một hệ thống chạy trên cloud hiếm khi ngừng hoạt động vì một nguyên nhân duy nhất. Thông thường nó suy giảm dần: một node cạn dung lượng đĩa, một connection pool bị chiếm hết, một job nền chạy lâu hơn bình thường, và đến một lúc nào đó người dùng bắt đầu gọi điện. Giám sát 24/7 tồn tại để rút ngắn khoảng cách giữa thời điểm hệ thống bắt đầu lệch chuẩn và thời điểm có người thực sự biết về điều đó.

Vấn đề là cụm từ giám sát 24/7 đang được dùng quá rộng. Nó có thể chỉ là một dashboard luôn bật mà không ai nhìn. Nó có thể là một bot đẩy cảnh báo vào một kênh chat không ai trực ngoài giờ. Hoặc nó có thể là một quy trình có người chịu trách nhiệm cụ thể, có thời gian phản hồi cam kết và có đường leo thang rõ ràng. Ba thứ đó chênh nhau nhiều về chi phí và chênh nhau hoàn toàn về giá trị thực tế.

Giám sát, cảnh báo và trực sự cố là ba việc khác nhau

Giám sát là việc thu thập và lưu trữ tín hiệu: metric, log, trace, kết quả health check. Nó trả lời câu hỏi hệ thống đang ở trạng thái nào, và ba tuần trước ở trạng thái nào. Không có dữ liệu lịch sử thì mọi cuộc điều tra sự cố đều thành phỏng đoán.

Cảnh báo là lớp logic đặt lên trên tín hiệu đó: khi một điều kiện được thoả mãn, một thông điệp được gửi tới nơi cụ thể. Cảnh báo chỉ có giá trị khi dẫn tới hành động. Một cảnh báo mà người nhận không biết phải làm gì là cảnh báo bị thiết kế sai, và nếu lặp lại đủ nhiều thì cả hệ thống sẽ bị bỏ qua.

Trực sự cố là phần con người: ai đang cầm máy lúc hai giờ sáng, người đó có quyền truy cập gì để xử lý, và nếu người đó không phản hồi thì ai là người tiếp theo. Ba lớp này thường được bán chung trong một gói dịch vụ, nhưng khi đánh giá nhà cung cấp bạn nên tách chúng ra và hỏi riêng từng lớp. Rất nhiều hợp đồng có lớp thứ nhất rất mạnh, lớp thứ hai tạm được và lớp thứ ba gần như không tồn tại.

Bốn lớp tín hiệu cần thu thập

Lớp hạ tầng

CPU, RAM, dung lượng đĩa và IOPS, băng thông và packet loss, trạng thái instance và node, tình trạng của từng availability zone. Đây là lớp dễ giám sát nhất và nói ít nhất về trải nghiệm người dùng: một máy chủ có CPU 20 phần trăm vẫn có thể đang trả lỗi 500 cho toàn bộ khách hàng. Lớp này cần cho việc tìm nguyên nhân, nhưng không nên là nơi phát sinh phần lớn cảnh báo.

Lớp nền tảng và dịch vụ được quản lý

Độ trễ và tỷ lệ lỗi của database, độ trễ replication, số kết nối đang mở so với giới hạn, độ sâu hàng đợi message, tỷ lệ hit của cache, trạng thái job định kỳ, hạn dùng chứng chỉ TLS và tên miền, hạn mức quota. Nhiều sự cố kéo dài bắt nguồn từ lớp này chứ không phải lớp hạ tầng bên dưới, vì các giới hạn ở đây vô hình cho đến khi bị chạm.

Lớp ứng dụng và trải nghiệm người dùng

Tỷ lệ lỗi theo endpoint, thời gian phản hồi ở phân vị 95 và 99 chứ không phải giá trị trung bình, throughput, và tỷ lệ thành công của các luồng nghiệp vụ quan trọng như đăng nhập, thanh toán, đặt hàng. Kiểm tra tổng hợp chạy từ bên ngoài mạng nội bộ là cách rẻ nhất để biết hệ thống có thực sự phục vụ được người dùng hay không, kể cả khi mọi biểu đồ bên trong đều xanh.

Lớp bảo mật và kỷ luật vận hành

Thay đổi trong quyền IAM, đăng nhập quản trị bất thường, thay đổi security group và firewall, cấu hình bị sửa ngoài quy trình change management, dấu hiệu quét cổng, tài nguyên tạo ngoài vùng cho phép. Phần lớn tín hiệu ở lớp này không cần đánh thức ai lúc nửa đêm, nhưng cần được ghi nhận đầy đủ và xem lại theo lịch cố định.

Từ tín hiệu đến cảnh báo: nguyên tắc thiết kế ngưỡng

Số lượng cảnh báo không phải thước đo chất lượng giám sát; thước đo thực sự là tỷ lệ cảnh báo dẫn tới một hành động có ích. Vài nguyên tắc giúp giữ tỷ lệ đó:

Cảnh báo dựa trên triệu chứng mà người dùng cảm nhận được, không dựa trên nguyên nhân kỹ thuật. Tỷ lệ lỗi của luồng thanh toán tăng là một cảnh báo tốt; CPU của một node tăng thường không phải.
Mỗi cảnh báo phải gắn với một runbook mô tả cách kiểm chứng, cách khắc phục tạm thời và điều kiện đóng. Không viết được runbook nghĩa là cảnh báo chưa đủ chín để đưa vào ca trực.
Ngưỡng nên gắn với mục tiêu mức dịch vụ đã thống nhất chứ không phải với một con số tròn dễ nhớ. Nếu mục tiêu là 99,9 phần trăm request thành công trong tháng thì ngưỡng nên phản ánh tốc độ tiêu hao ngân sách lỗi.
Dùng cửa sổ thời gian thay vì điểm dữ liệu đơn lẻ, để một đỉnh nhọn trong 30 giây không tạo ra một cuộc gọi lúc 3 giờ sáng.
Gộp cảnh báo theo sự cố. Khi một database gặp vấn đề, mọi dịch vụ phụ thuộc đều lỗi; người trực cần một sự cố chứ không phải bốn mươi tin nhắn.
Cảnh báo phải tự đóng khi điều kiện hết. Một hàng dài cảnh báo cũ chưa đóng làm mất khả năng nhận ra cái mới.

Phân mức nghiêm trọng và ý nghĩa của từng mức

Phân mức là nơi kỳ vọng của hai bên gặp nhau. Nếu không định nghĩa trước bằng văn bản, mọi sự cố sẽ được khách hàng coi là mức cao nhất và nhà cung cấp coi là mức thấp nhất. Bảng dưới là cấu trúc tham chiếu phổ biến, cần điều chỉnh theo nghiệp vụ từng hệ thống.

レベル	定義	Ví dụ	Kênh thông báo
P1	Dịch vụ ngừng hoạt động hoặc mất dữ liệu, không có giải pháp thay thế	Toàn bộ website không truy cập được; database chính không phản hồi	Gọi điện đánh thức người trực, mở cầu truyền hình xử lý sự cố
P2	Suy giảm nghiêm trọng ảnh hưởng một phần lớn người dùng hoặc một luồng nghiệp vụ chính	Thanh toán lỗi 20 phần trăm; độ trễ tăng gấp năm lần	Gọi điện trong giờ cam kết, thông báo tới kênh chung
P3	Ảnh hưởng hạn chế, có giải pháp thay thế, rủi ro leo thang nếu bỏ qua	Đĩa còn 15 phần trăm; một replica bị tụt hậu	Ticket ưu tiên, xử lý trong giờ làm việc
P4	Không ảnh hưởng dịch vụ, cần ghi nhận và xử lý theo kế hoạch	Chứng chỉ hết hạn sau 30 ngày; cấu hình lệch chuẩn	Ticket thường, đưa vào chu kỳ bảo trì

Những con số nên có trong thoả thuận mức dịch vụ

Các con số nêu dưới đây chỉ mang tính minh hoạ về mặt cấu trúc. Chúng không phải cam kết của bất kỳ nhà cung cấp nào và mục đích duy nhất là giúp bạn biết cần đòi hỏi những chỉ tiêu gì khi so sánh các đề xuất:

Thời gian xác nhận cảnh báo, tính từ lúc cảnh báo được kích hoạt đến lúc có người thừa nhận đang xử lý, tách riêng theo từng mức nghiêm trọng và theo trong hay ngoài giờ hành chính.
Mục tiêu thời gian khắc phục, phân biệt rõ đâu là mục tiêu nỗ lực và đâu là cam kết có chế tài.
Thời hạn gửi báo cáo sau sự cố cho từng mức.
Mức sẵn sàng của chính hệ thống giám sát và thời gian lưu trữ log, metric, trace.
Phạm vi phủ sóng theo múi giờ và theo ngày lễ, cùng ngôn ngữ làm việc của ca trực.

60 phút đầu tiên: ai làm gì

Phần lớn thiệt hại của một sự cố phát sinh trong giờ đầu, và phần lớn sự lộn xộn cũng vậy. Một quy trình đơn giản nhưng được tập dượt sẽ hiệu quả hơn một quy trình chi tiết mà chưa ai đọc.

Cảnh báo được kích hoạt và tới đúng người trực theo lịch, không phải tới một danh sách gửi thư chung.
Người trực xác nhận trong thời gian cam kết. Nếu không xác nhận, hệ thống tự động chuyển sang người dự phòng.
Xác định phạm vi ảnh hưởng trước khi tìm nguyên nhân: bao nhiêu người dùng, chức năng nào, từ thời điểm nào.
Ưu tiên khôi phục dịch vụ hơn tìm nguyên nhân gốc. Rollback, chuyển lưu lượng, tăng tài nguyên, tắt tính năng có cờ điều khiển nên được cho phép trước bằng văn bản.
Chỉ định một người điều phối sự cố tách khỏi người thao tác kỹ thuật, ngay khi có từ ba người tham gia.
Thông báo cho phía khách hàng theo mẫu đã thống nhất: điều gì đang xảy ra, ảnh hưởng gì, đang làm gì, khi nào cập nhật lần sau. Không hứa thời điểm khắc phục khi chưa biết nguyên nhân.
Ghi lại dòng thời gian ngay trong lúc xử lý; dựng lại sau đó luôn tốn kém và thiếu chính xác.

Leo thang: khi nào và tới ai

Leo thang không phải dấu hiệu thất bại mà là cơ chế được thiết kế sẵn, và cần hai chiều. Chiều kỹ thuật đưa sự cố tới người có kiến thức sâu hơn, ví dụ từ kỹ sư trực sang kỹ sư chuyên trách database, rồi sang nhà cung cấp nền tảng. Chiều quản lý đưa thông tin tới người có thẩm quyền quyết định đánh đổi, chẳng hạn chấp nhận mất dữ liệu của một khoảng ngắn để khôi phục nhanh.

Ba yếu tố cần thống nhất trước: mốc thời gian tự động leo thang cho từng mức, danh sách người liên hệ theo cấp kèm số dự phòng, và quyền quyết định của từng cấp. Danh sách này cần rà lại mỗi khi có thay đổi nhân sự, vì một số điện thoại sai trong bảng leo thang chỉ bị phát hiện đúng vào lúc tệ nhất.

Sau sự cố: báo cáo và vòng lặp cải tiến

Một báo cáo sau sự cố có ích cần nêu dòng thời gian, ảnh hưởng đo được, nguyên nhân trực tiếp và các yếu tố góp phần, điều gì giúp phát hiện sớm hoặc làm chậm việc phát hiện, và danh sách hành động có người chịu trách nhiệm kèm thời hạn. Phần khó nhất là theo dõi các hành động đó đến khi đóng.

Nên xem lại cấu hình cảnh báo theo chu kỳ cố định: cảnh báo nào kích hoạt mà không dẫn tới hành động thì sửa ngưỡng hoặc bỏ; sự cố nào xảy ra mà không cảnh báo nào bắn thì cần bổ sung tín hiệu. Nếu không, hệ thống cảnh báo sẽ phình lên và mất tác dụng một cách âm thầm.

HiTechCloud có thể hỗ trợ gì

HiTechCloud là đối tác của AWS và Google Premier Partner, đồng thời vận hành hạ tầng đặt tại Việt Nam. Trong lĩnh vực giám sát và ứng phó sự cố, đội ngũ có thể tham gia ở các phần việc sau: rà soát độ phủ giám sát hiện tại theo bốn lớp tín hiệu nêu trên; thiết lập thu thập metric, log và trace cùng chính sách lưu trữ; xây dựng bộ cảnh báo gắn với mục tiêu mức dịch vụ và viết runbook tương ứng; thiết kế lịch trực, ma trận leo thang và mẫu thông báo sự cố; và tham gia rà soát sau sự cố để chuyển các phát hiện thành thay đổi cụ thể trong cấu hình.

Phạm vi công việc, chỉ tiêu mức dịch vụ và mô hình chi phí được thống nhất theo từng hệ thống. Nếu bạn đang so sánh nhiều phương án, hãy dùng danh sách chỉ tiêu ở phần trên làm khung câu hỏi chung cho tất cả các bên tham gia chào thầu.