Cách xây dựng quy trình quản lý sự cố | Hướng dẫn thực hành 7 bước từ phát hiện đến giải quyết

Dành cho đội ngũ DevOps / SRE / Vận hành hạ tầng

Từ phát hiện đến giải quyết — Hướng dẫn thực hành 7 bước

Quy trình quản lý sự cố là gì?

Quy trình quản lý sự cố là hệ thống quy trình có tổ chức, bao gồm các bước từ việc phát hiện nhanh chóng các sự gián đoạn bất ngờ hoặc sự suy giảm chất lượng trong dịch vụ CNTT, cho đến việc ghi chép, phân loại, xử lý và giải quyết các sự cố đó. Nếu có một quy trình được thiết kế phù hợp, sẽ giúp giảm thiểu sự hỗn loạn và giảm đáng kể tác động đến hoạt động kinh doanh.

Khảo sát năm 2024 của PagerDuty , các tổ chức đã hệ thống hóa quy trình quản lý sự cố được báo cáo là có thời gian khắc phục trung bình (MTTR) ngắn hơn khoảng 60% so với các tổ chức chưa thực hiện điều này.

Tại các doanh nghiệp hiện đại, dữ liệu vận hành đang phân tán trên nhiều hệ thống khác nhau, bao gồm các công cụ giám sát như Datadog, CloudWatch, Prometheus; các hệ thống quản lý phiếu yêu cầu như Jira Service Management, ServiceNow; và các nền tảng ghi nhật ký như Elasticsearch, Splunk. Việc không thể tích hợp các hệ thống này chính là nguyên nhân chính dẫn đến sự chậm trễ trong việc xử lý sự cố và tình trạng trùng lặp công việc.

Tổng quan về quy trình quản lý sự cố

Quy trình quản lý sự cố hiệu quả bao gồm 7 bước sau đây. Bài viết này sẽ tổng hợp mục đích của từng bước và các công cụ thường được sử dụng.

Thiết kế quy trình tuân thủ ITIL

Theo ITIL, sự cố được định nghĩa là “sự gián đoạn ngoài kế hoạch của dịch vụ CNTT hoặc sự suy giảm chất lượng dịch vụ CNTT”. Dựa trên định nghĩa này, việc phân biệt rõ ràng giữa sự cố và yêu cầu dịch vụ là rất quan trọng.

Tiêu chí phân biệt: “Nếu không xử lý ngay lập tức sẽ ảnh hưởng đến dịch vụ” → Sự cố; “Yêu cầu thông thường có thể xử lý theo kế hoạch” → Yêu cầu dịch vụ

3 nguyên tắc thiết kế luồng công việc

1. Phân công nhiệm vụ rõ ràng: Lập thành văn bản cụ thể về việc ai sẽ làm gì, vào thời điểm nào, và khi nào cần báo cáo lên cấp trên

2. Quy trình tiêu chuẩn hóa: Áp dụng cùng một Runbook cho các sự cố cùng loại để ngăn chặn sự chênh lệch về chất lượng xử lý

3. Cải tiến liên tục: Áp dụng kết quả phân tích sau sự cố vào quy trình để nâng cao khả năng ứng phó

Bước 1: Phát hiện sự cố

Sự chậm trễ trong việc phát hiện sẽ trực tiếp làm gia tăng tác động đến hoạt động kinh doanh. Mô hình lý tưởng là hệ thống có thể tự động phát hiện vấn đề trước khi người dùng nhận ra.

Các điểm cần lưu ý trong thiết kế hệ thống giám sát tự động

Các đối tượng giám sát được thiết kế chia thành 3 lớp chính: lớp hạ tầng (CPU, bộ nhớ, đĩa cứng, mạng), lớp ứng dụng (thời gian phản hồi, tỷ lệ lỗi, thông lượng) và lớp kinh doanh (số lượng đơn hàng, tỷ lệ thanh toán thành công, số lượt đăng nhập).

Ví dụ thực tế: Trên các trang thương mại điện tử, nếu thiết lập ngưỡng cho các chỉ số kinh doanh theo kiểu “Khi tỷ lệ thanh toán thành công trong 5 phút gần nhất giảm xuống dưới 95%, sẽ kích hoạt cảnh báo P1”, thì có thể phát hiện sớm các sự cố mà các chỉ số kỹ thuật có thể bỏ sót.

Các biện pháp đối phó với tình trạng “mệt mỏi do cảnh báo”

Nếu có quá nhiều cảnh báo, sẽ nảy sinh “vấn đề cậu bé chăn cừu” khiến bạn bỏ lỡ những thông báo quan trọng. Để khắc phục tình trạng này, các biện pháp hiệu quả bao gồm: loại bỏ cảnh báo trùng lặp, nhóm các cảnh báo có liên quan lại với nhau, thông báo theo từng cấp độ (Cảnh báo → Nguy cấp) và rà soát định kỳ các cảnh báo không cần thiết. Việc tận dụng tính năng nhóm thông minh của PagerDuty hay Opsgenie sẽ giúp giảm thiểu đáng kể các cảnh báo không cần thiết.

Hệ thống tiếp nhận báo cáo của người dùng

Có những vấn đề mà hệ thống giám sát tự động không thể phát hiện được. Hãy thiết lập nhiều kênh khác nhau như cổng thông tin tự phục vụ, bot Slack, email, điện thoại… để tạo điều kiện thuận lợi hơn cho việc báo cáo. Khi nhận được báo cáo, hãy cấp ngay mã sự cố (Incident ID) để người dùng có thể theo dõi tiến trình xử lý.

Bước 2: Ghi chép sự cố

Việc ghi chép chính xác là yếu tố không thể thiếu để nâng cao hiệu quả xử lý, phân tích xu hướng và xây dựng các biện pháp phòng ngừa tái diễn. Nếu việc ghi chép không đầy đủ, vấn đề tương tự sẽ lặp lại và tổ chức sẽ mất đi cơ hội học hỏi.

Thông tin cần ghi lại và ví dụ điền thông tin

Ghi lại các mục sau đây theo định dạng chuẩn. Không chỉ sử dụng phần nhập liệu tự do mà còn tận dụng các mục trắc nghiệm để đảm bảo tính nhất quán của dữ liệu.

Tự động hóa hệ thống bán vé

Trong Jira Service Management và ServiceNow, bạn có thể tự động chuyển các cảnh báo từ công cụ giám sát thành phiếu yêu cầu. Nếu xây dựng một quy trình tích hợp như Datadog → PagerDuty → Jira, bạn có thể giảm thời gian từ khi phát hiện đến khi ghi nhận xuống gần như bằng không. Hơn nữa, bạn cũng có thể thiết lập tính năng phân loại tự động dựa trên các từ khóa cụ thể.

Quản lý chất lượng hồ sơ

Hãy áp dụng cơ chế xem xét ngẫu nhiên các phiếu yêu cầu hàng tuần và đưa ra phản hồi về những thông tin bị thiếu hoặc mô tả không rõ ràng. Việc thiết lập để ngăn chặn việc đóng phiếu khi các trường thông tin bắt buộc chưa được điền đầy đủ cũng rất hiệu quả.

Bước 3: Phân loại sự cố

Việc phân loại phù hợp là nền tảng cho việc xử lý hiệu quả. Nhờ phân loại theo danh mục, hệ thống có thể tự động phân công cho nhân viên phụ trách phù hợp, phân tích các mẫu sự cố tương tự và xây dựng cơ sở kiến thức một cách có hệ thống.

Ví dụ về thiết kế phân loại danh mục

Chúng tôi sẽ thiết kế hệ thống phân loại gồm 2 đến 3 cấp phù hợp với cơ sở hạ tầng CNTT của tổ chức. Do việc phân loại sẽ trở nên phức tạp nếu có quá nhiều cấp, nên việc giới hạn trong tối đa 3 cấp là giải pháp thực tế nhất.

Đánh giá phạm vi ảnh hưởng và mức độ khẩn cấp

Phạm vi ảnh hưởng được phân loại thành 3 cấp độ: “Cá nhân”, “Bộ phận” và “Toàn công ty”; mức độ khẩn cấp được đánh giá theo 3 mức: “Cao (ngừng hoạt động)”, “Trung bình (sự cố đối với các chức năng chính)” và “Thấp (sự cố nhỏ)”. Dựa trên sự kết hợp của hai tiêu chí này, chúng ta sẽ xác định thứ tự ưu tiên ở bước tiếp theo.

Ví dụ cụ thể về cách đánh giá: Hệ thống thanh toán ngừng hoạt động hoàn toàn → Phạm vi ảnh hưởng “Toàn công ty” × Mức độ khẩn cấp “Cao” → P1. Giao diện người dùng (UI) của Wiki nội bộ bị lỗi → Phạm vi ảnh hưởng “Cá nhân” × Mức độ khẩn cấp “Thấp” → P5.

Bước 4: Xếp thứ tự ưu tiên

Không thể xử lý đồng thời tất cả các sự cố. Để ưu tiên xử lý những sự cố có tác động lớn đến hoạt động kinh doanh, chúng tôi sẽ thống nhất các tiêu chí đánh giá bằng cách kết hợp ma trận ưu tiên và SLO (Thời gian mục tiêu hoàn thành xử lý: Service Level of Objective).

Ma trận mức độ ưu tiên

Chúng tôi xác định mức độ ưu tiên dựa trên hai tiêu chí: phạm vi ảnh hưởng và mức độ khẩn cấp. Mỗi mức độ ưu tiên sẽ được liên kết với SLO (thời gian phản ứng ban đầu/thời gian mục tiêu để giải quyết).

Các điểm cần lưu ý khi thiết kế SLO

SLO nên được thiết lập ở “mức có thể đạt được nhưng vẫn tạo ra sự căng thẳng vừa phải”. SLO quá khắt khe sẽ khiến đội ngũ kiệt sức và trở nên hình thức. Cách tiếp cận thực tế là trước tiên hãy đo lường MTTR hiện tại, sau đó đặt mục tiêu ở mức khoảng 80% so với con số đó. Ngoài ra, cũng cần xác định rõ khoảng thời gian áp dụng SLO (giờ làm việc hay 24/7).

Xem xét lại thứ tự ưu tiên động

Tình hình sự cố có thể thay đổi. Không hiếm trường hợp sự cố ban đầu được đánh giá là P3, nhưng sau đó lại được phát hiện là đã lan rộng ra phạm vi lớn. Hãy tích hợp quy trình rà soát các sự cố chưa được giải quyết cứ sau 30 phút đến 1 giờ và đánh giá lại mức độ phù hợp của mức độ ưu tiên.

Bước 5: Xử lý sự cố

Mục tiêu của việc xử lý sự cố là khôi phục dịch vụ về trạng thái bình thường càng sớm càng tốt. Phương pháp cơ bản là trước tiên khôi phục dịch vụ bằng các biện pháp tạm thời, thay vì tập trung vào việc xác định nguyên nhân gốc rễ, và sau đó mới xem xét các biện pháp khắc phục lâu dài.

Ví dụ về dòng thời gian ứng phó ban đầu

Các bước xử lý ban đầu đối với sự cố P1 (tham khảo):
0–5 phút: Xác nhận cảnh báo và thiết lập War Room (kênh Slack, v.v.)
5–15 phút: Xác định phạm vi ảnh hưởng và cập nhật trang trạng thái
15–30 phút: Thực hiện biện pháp khắc phục tạm thời và gửi thông báo đầu tiên đến người dùng

Thiết kế quy trình xử lý sự cố

Không phải mọi sự cố đều có thể được giải quyết ở cấp độ L1. Chúng tôi sẽ xác định rõ ràng quy trình chuyển tiếp theo từng cấp độ.

Chiến lược truyền thông

Trong các sự cố kéo dài, việc báo cáo tình hình định kỳ là điều không thể thiếu, ngay cả khi chưa có tiến triển. Đối với mức độ P1, nên báo cáo khoảng 15–30 phút một lần; đối với mức độ P2, nên báo cáo khoảng 1 giờ một lần, nhằm chia sẻ tình hình hiện tại và dự kiến thời gian khắc phục với người dùng, ban lãnh đạo và các đội ngũ liên quan. Việc sử dụng các công cụ trang trạng thái như Statuspage có thể giúp giảm đáng kể số lượng yêu cầu hỗ trợ riêng lẻ.

Ứng dụng Cơ sở kiến thức và Runbook

Hồ sơ xử lý các sự cố tương tự trong quá khứ là tài sản quý giá. Hãy xây dựng Runbook (hướng dẫn xử lý sự cố) trên Confluence hoặc Notion và đảm bảo có thể tìm kiếm theo cấu trúc: Triệu chứng → Nguyên nhân → Giải pháp. Nhờ có Runbook, tỷ lệ giải quyết ngay lần đầu (FCR) ở cấp độ L1 có thể được cải thiện đáng kể.

Bước 6: Giải quyết sự cố

Dù dịch vụ đã được khôi phục, quá trình vẫn chưa hoàn tất. Trước khi xác nhận “đã giải quyết”, bạn cần thực hiện các bước xác minh.

Quy trình xác nhận giải quyết

Đối với các sự cố do người dùng báo cáo, chúng tôi sẽ xác nhận trực tiếp với người báo cáo. Đối với các sự cố được phát hiện qua giám sát tự động, chúng tôi sẽ xác nhận rằng các chỉ số giám sát đã trở về mức bình thường và không tái diễn trong một khoảng thời gian nhất định (ví dụ: 24 giờ). Cài đặt cho phép chức năng giám sát của Datadog tự động đánh giá sự cố cũng đã được kích hoạt.

Phân biệt giữa các biện pháp tạm thời và các biện pháp lâu dài

Trong trường hợp sự cố được giải quyết bằng các biện pháp tạm thời (như khởi động lại máy chủ, xóa bộ nhớ đệm, v.v.), việc xử lý lâu dài sẽ được chuyển giao cho quy trình quản lý sự cố. Cần đặt trạng thái “Đã thực hiện biện pháp tạm thời · Chưa hoàn thành biện pháp lâu dài” cho phiếu yêu cầu để đảm bảo không bỏ sót các biện pháp khắc phục nguyên nhân gốc rễ.

Ghi chép và phân tích thời gian giải quyết

Hệ thống sẽ ghi lại chính xác các mốc thời gian tương ứng với các giai đoạn: phát hiện → ghi nhận → bắt đầu xử lý → giải quyết. Bằng cách tổng hợp dữ liệu này theo từng danh mục và từng nhóm, các điểm nghẽn sẽ được hiển thị rõ ràng. Ví dụ, nếu thời gian MTTR đối với các sự cố liên quan đến cơ sở dữ liệu quá dài, có thể xem xét việc tăng cường nhân sự DBA hoặc hoàn thiện Runbook dành riêng cho cơ sở dữ liệu.

Bước 7: Đóng sự cố

Quá trình tổng kết là một quy trình quan trọng nhằm thúc đẩy việc học hỏi và cải tiến trong tổ chức.

Danh sách kiểm tra trước khi đóng cửa

• Vấn đề đã được giải quyết hoàn toàn và đã có xác nhận từ người dùng chưa?

• Tất cả các mục liên quan đến vé (nguyên nhân, biện pháp xử lý, tiến trình) đã được ghi chép đầy đủ chưa?

• Cơ sở kiến thức / Runbook đã được cập nhật chưa?

• Trong trường hợp xử lý tạm thời, liệu vấn đề có được chuyển giao cho quy trình quản lý vấn đề hay không?

• Trong trường hợp P1/P2, liệu buổi tổng kết sau dự án đã được lên lịch chưa?

Cách tiến hành phân tích sau sự cố

Đối với các sự cố P1 và P2, chúng tôi sẽ tiến hành đánh giá sau sự cố trong vòng 48 giờ kể từ khi sự cố được giải quyết. Mục đích không phải là quy trách nhiệm mà là để tổ chức rút ra bài học. Trên cơ sở văn hóa “Blameless” (không đổ lỗi), chúng tôi sẽ xem xét lại diễn biến sự việc, xác định các vấn đề trong quy trình phát hiện và ứng phó, đồng thời xác định các biện pháp cải thiện cụ thể.

Ví dụ về kết quả của buổi đánh giá sau sự cố: “Rà soát lại ngưỡng cảnh báo (Đơn vị phụ trách: Nhóm SRE, Hạn chót: trong vòng 1 tuần)”, “Bổ sung Runbook (Đơn vị phụ trách: Nhóm L2, Hạn chót: trong vòng 2 tuần)” — Các biện pháp cải tiến phải luôn ghi rõ đơn vị phụ trách và hạn chót.

Phòng ngừa dựa trên phân tích xu hướng

Hàng tháng, chúng tôi tổng hợp các sự cố đã được xử lý xong để thống kê số lượng sự cố theo từng loại, phân bố theo khung giờ và xác định các hệ thống thường xuyên gặp sự cố. Việc xây dựng bảng điều khiển (dashboard) bằng các công cụ BI như Grafana hay Tableau sẽ giúp theo dõi sự thay đổi của các xu hướng theo thời gian thực.

Ứng dụng các công cụ và công nghệ

Việc quản lý sự cố trong cơ sở hạ tầng CNTT ngày càng phức tạp không thể thực hiện được chỉ bằng thủ công. Việc lựa chọn các công cụ phù hợp là rất quan trọng để tự động hóa quy trình, quản lý thông tin tập trung và ra quyết định nhanh chóng.

Các tiêu chí đánh giá trong việc lựa chọn công cụ

Khả năng tích hợp với các công cụ giám sát, quản lý phiếu yêu cầu và nhật ký hiện có là yếu tố quan trọng hàng đầu. Nếu dữ liệu bị phân tán, chúng ta sẽ không thể nắm bắt được bức tranh toàn cảnh về sự cố. Ngoài ra, chúng tôi còn đánh giá tính dễ sử dụng, khả năng tùy chỉnh, tính tương thích với thiết bị di động và hệ thống hỗ trợ của nhà cung cấp.

Số giờ lao động có thể cắt giảm nhờ tự động hóa

Dưới đây là một số ví dụ về các đối tượng và hiệu quả của tự động hóa. Bao gồm: tự động tạo phiếu báo cáo từ cảnh báo (giảm thời gian xử lý từ khâu phát hiện đến ghi chép xuống còn 0), phân loại và phân công tự động dựa trên từ khóa (giảm thời gian phân loại), tự động chuyển cấp thông qua bộ đếm thời gian SLO (ngăn chặn việc bỏ sót các trường hợp cần chuyển cấp), và tự động thực thi Runbook (giảm thời gian xử lý các tình huống tiêu chuẩn). Chúng ta nên triển khai tự động hóa theo từng giai đoạn và tiến hành đồng thời với việc đánh giá hiệu quả của từng bước.

Chìa khóa nằm ở việc tích hợp dữ liệu vận hành

Bằng cách tích hợp dữ liệu từ các hệ thống khác nhau như công cụ giám sát, hệ thống quản lý phiếu yêu cầu, nền tảng nhật ký và công cụ quản lý thay đổi, chúng ta có thể thực hiện một cách liền mạch việc phân tích xu hướng sự cố, xác định nguyên nhân gốc rễ và lập kế hoạch các biện pháp ngăn ngừa tái diễn. Đặc biệt đối với các đội DevOps và SRE, việc tích hợp dữ liệu là yếu tố then chốt nhất để rút ngắn thời gian khắc phục sự cố (MTTR) và nâng cao tính ổn định của hệ thống.

Cơ cấu tổ chức và thành phần đội ngũ

Dù có quy trình hay công cụ xuất sắc đến đâu, nếu không có cơ cấu tổ chức phù hợp thì cũng không thể hoạt động hiệu quả.

Định nghĩa về vai trò và trách nhiệm

Chúng tôi sẽ quy định rõ phạm vi trách nhiệm của từng vai trò, bao gồm: Bộ phận Hỗ trợ Khách hàng (Cấp 1: Tiếp nhận và xử lý ban đầu), Đội ngũ Kỹ thuật Chuyên môn (Cấp 2: Điều tra và xử lý sự cố), Kiến trúc sư/Nhà cung cấp (Cấp 3: Xử lý ở cấp độ thiết kế), Quản lý Sự cố (Điều phối tổng thể và truyền thông), Đội ngũ Quản lý Vấn đề (Phân tích nguyên nhân gốc rễ và đề xuất biện pháp khắc phục lâu dài), đồng thời thể hiện các vai trò này một cách trực quan thông qua Ma trận RACI.

Thiết kế hệ thống trực ca

Trong dịch vụ 24/7, cần xác định rõ lịch trực ca luân phiên, quy trình báo cáo sự cố lên cấp trên và các đầu mối liên lạc khẩn cấp. Hãy tận dụng tính năng lập lịch của PagerDuty và Opsgenie để phân bổ công việc một cách đồng đều cho các nhân viên phụ trách. Thời gian trực liên tục tối đa là 1 tuần; việc đảm bảo thời gian nghỉ ngơi đầy đủ và chế độ đãi ngộ phù hợp là điều kiện tiên quyết để duy trì một hệ thống hoạt động bền vững.

Phát triển kỹ năng và huấn luyện mô phỏng

Hàng quý, chúng tôi tổ chức “Game Day” (buổi diễn tập mô phỏng sự cố) để thực hành quy trình xử lý P1 thực tế. Việc áp dụng phương pháp “Chaos Engineering” có nguồn gốc từ Netflix — tức là cố tình tạo ra sự cố để kiểm tra khả năng chống chịu của hệ thống và tổ chức — cũng là một cách tiếp cận hiệu quả.

Đo lường và cải tiến liên tục

Những gì không thể đo lường được thì không thể cải thiện. Bằng cách thiết lập các chỉ số KPI phù hợp và rà soát định kỳ, chúng ta sẽ không ngừng nâng cao năng lực ứng phó sự cố của tổ chức.

Định nghĩa và chỉ tiêu của các chỉ số KPI chính

So sánh chuẩn

Chúng ta sẽ sử dụng 4 chỉ số của DORA (DevOps Research and Assessment) (tần suất triển khai, thời gian thực hiện thay đổi, tỷ lệ thất bại khi thay đổi và MTTR) để so sánh với tiêu chuẩn của ngành. Tuy nhiên, do quy mô tổ chức và mức độ phức tạp của cơ sở hạ tầng khác nhau, thay vì chỉ so sánh đơn thuần về mặt số liệu, chúng ta nên tập trung vào xu hướng cải thiện của chính tổ chức mình.

Áp dụng chu trình PDCA

Hàng tháng, chúng tôi rà soát các chỉ số KPI và triển khai chu trình: Lập kế hoạch (Plan) → Thực hiện (Do) → Đánh giá hiệu quả (Check) → Áp dụng vào các cải tiến tiếp theo (Act). Các biện pháp cải tiến được thiết lập dưới dạng cụ thể và có thể đo lường được, chẳng hạn như “Thêm 3 mục vào Runbook” hay “Điều chỉnh lại ngưỡng cảnh báo ở 2 trường hợp”, đồng thời theo dõi tiến độ thực hiện.

Tóm tắt: Hướng tới việc thực hiện quy trình quản lý sự cố hiệu quả

Việc xây dựng quy trình quản lý sự cố không phải là việc có thể hoàn thành chỉ trong một lần. Điều quan trọng là phải thực hiện chắc chắn 7 bước: phát hiện → ghi chép → phân loại → xếp hạng mức độ ưu tiên → xử lý → giải quyết → đóng vụ, đồng thời liên tục phản ánh kết quả của việc phân tích sau sự cố và phân tích xu hướng vào quy trình.

Đặc biệt trong bối cảnh cơ sở hạ tầng CNTT phức tạp hiện nay, việc tích hợp các dữ liệu vận hành phân tán là thách thức lớn nhất. Nếu có một nền tảng cho phép phân tích dữ liệu giám sát, phiếu yêu cầu hỗ trợ, nhật ký và quản lý thay đổi một cách toàn diện, chúng ta có thể đồng thời rút ngắn thời gian khắc phục sự cố trung bình (MTTR), giảm tỷ lệ tái phát sự cố và giảm bớt gánh nặng cho đội ngũ.

Quản lý sự cố không chỉ đơn thuần là việc xử lý vấn đề, mà còn là cơ hội để tổ chức học hỏi và phát triển. Bằng cách tích lũy những bài học rút ra từ từng sự cố và triển khai các biện pháp phòng ngừa, chúng ta sẽ có thể cung cấp các dịch vụ CNTT ổn định hơn.

Hãy hợp nhất các dữ liệu vận hành đang phân tán để nâng cao hiệu quả xử lý sự cố một cách đáng kể, được không?

Incident Lake là lớp thông tin tình huống (incident intelligence layer) tích hợp dữ liệu từ các công cụ giám sát, hệ thống phiếu yêu cầu hỗ trợ và nền tảng nhật ký. Giải pháp này hiện thực hóa “tích hợp dữ liệu vận hành” như đã giới thiệu trong bài viết này, từ đó đẩy nhanh quá trình ra quyết định từ khâu phát hiện đến khi giải quyết sự cố. Nếu quý vị đang gặp khó khăn trong việc rút ngắn thời gian trung bình để khắc phục sự cố (MTTR), giảm thiểu cảnh báo giả và tự động hóa phân tích xu hướng, xin hãy cân nhắc sử dụng Incident Lake.

Trang web dịch vụ

https://incidentlake.com/