Ứng dụng AI trong Incident Management: tăng tốc phát hiện sự cố

Trong các tổ chức lớn các ngành tài chính, ngân hàng, bảo hiểm… tại Việt Nam, quy trình Incident Management thường đã được chuẩn hóa ở một mức nhất định. Service desk vận hành 24/7. SLA được định nghĩa theo mức độ ưu tiên. On-call rotation và escalation matrix cũng đã có.

Tuy nhiên, thực tế vận hành lại cho thấy một vấn đề khác: nhiều sự cố không được phát hiện sớm, thậm chí có những trường hợp đội IT còn biết đến sau khi được thống báo từ nhóm kinh doanh khi có người dùng phản ánh.

Ngay cả khi hệ thống monitoring đã có, cảnh báo lại nằm rải rác ở nhiều công cụ khác nhau: APM, infrastructure monitoring, log management, cloud monitoring, network monitoring, database monitoring. Mỗi công cụ gửi một loại alert, theo một format khác nhau, khiến đội IT phải tự lọc, tự đánh giá, tự quyết định alert nào thực sự nghiêm trọng.

Một vấn đề lớn khác là sau khi sự cố được xử lý xong, nhiều tổ chức không log lại đầy đủ quá trình xử lý. Timeline thiếu dữ liệu. Root cause chỉ được trao đổi trong chat. Bài học kinh nghiệm không được chuẩn hóa thành runbook hoặc knowledge base. Vì vậy, khi sự cố tương tự quay lại, đội IT gần như phải xử lý lại từ đầu.

Bài viết này phân tích hai pain point thực tế trong Incident Management: phát hiện sự cố chậm và thiếu tài liệu học hỏi sau sự cố. Từ đó, bài viết đề xuất cách ứng dụng Jira Service Management, các công cụ monitoring, Opsgenie và AI để phát hiện cảnh báo sớm, gom nhóm alert, quyết định cảnh báo nào cần trở thành incident, thông báo nhanh đến đúng người xử lý và tự động hóa quá trình ghi nhận sau sự cố.

1. Vấn đề cốt lõi: Phát hiện sự cố chậm và thiếu vòng học hỏi sau incident

Trong môi các tổ chức ngân hàng, tài chính, hệ thống công nghệ không vận hành như các ứng dụng độc lập. Một giao dịch chuyển tiền, một yêu cầu phê duyệt khoản vay, một lần thanh toán QR hoặc một phiên đăng nhập mobile banking đều đi qua nhiều tầng hệ thống khác nhau.

Một business flow thông thường có thể phụ thuộc vào:

• Application layer: Mobile Banking, Internet Banking, Corporate Banking, Branch Teller, Contact Center
• API layer: các API nội bộ phục vụ xác thực, kiểm tra hạn mức, tạo giao dịch, đối soát
• Database layer: core banking DB, transaction DB, customer DB, reporting DB
• Middleware: API Gateway, message queue, cache layer, integration bus
• Infrastructure layer: server, Kubernetes cluster, cloud service, network, firewall
• External partners: NAPAS, SWIFT, payment partners, eKYC vendor, credit bureau
• Business process: chuyển tiền, thanh toán hóa đơn, phê duyệt khoản vay, đối soát cuối ngày và báo cáo

Vì hệ thống có nhiều lớp phụ thuộc như vậy, một dấu hiệu bất thường nhỏ ở một tầng kỹ thuật có thể nhanh chóng ảnh hưởng đến nhiều dịch vụ nghiệp vụ. Vấn đề là đội IT không phải lúc nào cũng phát hiện được dấu hiệu đó đủ sớm.

Có ba nguyên nhân phổ biến:

Thứ nhất, alert nằm rải rác trên nhiều công cụ monitoring. Một team dùng Datadog hoặc Dynatrace để theo dõi application performance. Team khác dùng Zabbix hoặc Prometheus để theo dõi hạ tầng. Log nằm ở ELK hoặc Splunk. Database có dashboard riêng. Network có hệ thống cảnh báo riêng. Khi sự cố xảy ra, mỗi công cụ có thể phát ra nhiều alert khác nhau, nhưng không có một nơi trung tâm để gom lại, liên kết và đánh giá mức độ nghiêm trọng.

Thứ hai, đội IT bị quá tải bởi alert noise. Không phải alert nào cũng là incident. Một cảnh báo CPU tăng trong 2 phút có thể chỉ là dao động bình thường. Nhưng nếu đi kèm với latency tăng, error rate tăng và transaction fail tăng ở một service quan trọng, đó có thể là dấu hiệu của một incident nghiêm trọng. Nếu không có cơ chế correlation, deduplication và rule phân loại rõ ràng, engineer phải tự đọc từng alert và tự quyết định bằng kinh nghiệm cá nhân.

Thứ ba, tổ chức thiếu tài liệu sau sự cố. Sau khi incident được xử lý xong, nhiều thông tin quan trọng không được ghi lại đầy đủ: alert đầu tiên xuất hiện lúc nào, ai nhận thông báo đầu tiên, mất bao lâu để xác định đúng resolver group, workaround là gì, root cause là gì, runbook nào có ích, điểm nào cần cải tiến. Khi không có post-incident review đúng nghĩa, tổ chức không học được từ incident trước đó.

Hậu quả là Incident Management rơi vào vòng lặp quen thuộc:

• Phát hiện chậm
• Alert bị bỏ sót hoặc không được ưu tiên đúng
• Incident bị tạo muộn
• Sai team xử lý ban đầu
• Escalation chậm
• Business biết sự cố trước đội IT
• Sau khi resolve xong không có tài liệu đầy đủ
• Incident tương tự lặp lại nhưng vẫn mất nhiều thời gian xử lý

Đây không chỉ là vấn đề công cụ. Đây là vấn đề về cách tổ chức dữ liệu vận hành, cách kết nối alert với incident, cách định nghĩa ngưỡng ưu tiên và cách biến mỗi incident thành một nguồn học hỏi cho hệ thống.

2. Use case BFSI: Một API timeout nhưng đội IT phát hiện muộn vì alert bị phân tán

Hãy xem một tình huống thực tế trong ngân hàng.

14h32, thứ Ba: API check-transaction-limit bắt đầu có dấu hiệu bất thường. Latency trung bình tăng từ 80ms lên 4,500ms. Timeout rate tăng từ 0.5% lên 35%.

• Datadog ghi nhận application latency tăng.
• Zabbix ghi nhận CPU của một node tăng bất thường.
• Log management ghi nhận nhiều lỗi timeout từ service transaction-validation.
• Database monitoring ghi nhận connection pool gần chạm ngưỡng tối đa.

Tuy nhiên, các cảnh báo này nằm ở bốn công cụ khác nhau. Mỗi cảnh báo được gửi về một kênh riêng. Một số alert gửi qua email. Một số alert vào Slack. Một số alert nằm trên dashboard nhưng không có người theo dõi liên tục.

14h40: On-call engineer nhận được một email cảnh báo latency tăng, nhưng vì trước đó hệ thống từng có nhiều alert false positive nên engineer chưa lập tức tạo incident. Alert được xem là cảnh báo kỹ thuật cần theo dõi thêm.

14h50: Contact Center bắt đầu nhận cuộc gọi từ khách hàng: không chuyển tiền được trên Mobile Banking.

14h55: Mobile Banking team báo lỗi 500 tăng mạnh ở tính năng chuyển tiền.

15h00: Branch Operation báo giao dịch viên tại chi nhánh không thực hiện được một số lệnh chuyển khoản cho khách doanh nghiệp.

15h10: Incident chính thức được tạo trong hệ thống ITSM. Lúc này, sự cố đã ảnh hưởng đến nhiều kênh nghiệp vụ trong gần 40 phút.

Sau khi điều tra, đội IT phát hiện API check-transaction-limit không chỉ phục vụ một tính năng nhỏ. Đây là dependency bắt buộc cho nhiều luồng giao dịch:

API check-transaction-limit timeout
↓
Chuyển tiền nội bộ trên Mobile Banking bị lỗi
Chuyển tiền liên ngân hàng bị lỗi
Corporate Banking bị ảnh hưởng
Giao dịch tại quầy bị gián đoạn
QR Pay merchant bị lỗi
Auto Transfer scheduled bị fail
↓
Contact Center quá tải vì khách hàng gọi lên
↓
Đối soát cuối ngày có nguy cơ bị lệch nếu không xử lý kịp

Điểm đáng chú ý là monitoring không thiếu dữ liệu. Các công cụ đã phát hiện nhiều tín hiệu bất thường từ sớm. Nhưng vì dữ liệu bị phân tán, alert không được gom nhóm, không có cơ chế đánh giá tương quan và không có rule rõ ràng để quyết định khi nào alert phải trở thành incident, đội IT vẫn phản ứng chậm.

Nếu tổ chức có Jira Service Management kết nối với các công cụ monitoring và Opsgenie, quy trình có thể diễn ra khác:

14h32: Datadog phát hiện latency tăng.

14h33: Zabbix phát hiện CPU và memory bất thường.

14h34: Log tool phát hiện nhiều timeout liên quan đến cùng service.

14h35: JSM/Opsgenie tự động gom các alert có cùng affected service, cùng time window và cùng pattern lỗi.

14h36: Hệ thống xác định đây không còn là một alert đơn lẻ, mà là một cụm alert có khả năng trở thành incident.

14h37: Incident được tạo tự động trong JSM với đầy đủ context: affected service, alert source, log sample, metric bất thường, resolver group đề xuất, severity đề xuất.

14h38: On-call engineer nhận thông báo qua app push, điện thoại, email và Slack.

14h40: Nếu engineer không acknowledge, hệ thống tự động escalate lên người tiếp theo trong on-call schedule.

Như vậy, giá trị không nằm ở việc có thêm nhiều alert hơn. Giá trị nằm ở việc biến alert thành tín hiệu có thể hành động.

Monitoring cho biết “có dấu hiệu bất thường”.

Jira Service Management và Opsgenie giúp trả lời: “Dấu hiệu này có đủ nghiêm trọng để tạo incident không?”, “Ai cần xử lý?”, “Thông báo bằng kênh nào?”, “Nếu không ai phản hồi thì escalate cho ai?”, và “Tất cả thông tin này được ghi lại ở đâu để học lại sau sự cố?”.

3. JSM + Monitoring: Từ alert đến incident trong vài giây

Jira Service Management không phải là monitoring tool – nhưng JSM được thiết kế để trở thành trung tâm tiếp nhận và xử lý tất cả alert từ mọi monitoring tool, biến chúng thành hành động có ý nghĩa. Chuỗi giá trị gồm 4 bước:

Bước 1: Tích hợp monitoring – Thu thập alert từ mọi nguồn về một nơi

JSM (thông qua Opsgenie – đã tích hợp sẵn trong JSM Cloud) hỗ trợ 200+ integration với các monitoring tool phổ biến:

Ví dụ cấu hình tích hợp Datadog → JSM:

Datadog Webhook → Opsgenie Integration
├── Alert payload mapping:
│ ├── title → alert title
│ ├── tags → affected service (auto-map với JSM service)
│ ├── priority → alert priority
│ └── body → alert description + context
└── Auto-enrichment:
├── Link Datadog dashboard URL vào alert
└── Attach monitoring graph snapshot

Bước 2: Gom nhóm cảnh báo – Từ 50 alert thành 1 sự cố rõ ràng

Đây là khả năng quan trọng nhất và cũng là điểm khác biệt lớn nhất so với việc chỉ dùng monitoring tool đơn lẻ. JSM/Opsgenie gom nhóm alert theo nhiều tiêu chí:

TRƯỚC khi gom nhóm:
47 alert riêng lẻ → 47 notification → 3 engineer xử lý 3 hướng khác nhau

SAU khi gom nhóm (JSM/Opsgenie):
Alert Group: "Transaction Flow Degradation"
├── 12 alerts: API check-transaction-limit timeout (Datadog)
├── 8 alerts: DB-TXN-01 high CPU (Zabbix) 
├── 15 alerts: Mobile Banking 5xx errors (Dynatrace)
├── 7 alerts: API Gateway error rate (CloudWatch)
└── 5 alerts: Synthetic transaction failed (Catchpoint)

→ 1 notification → đúng 1 team → xử lý tập trung

Bước 3: Quyết định Alert vs Incident – Khi nào cảnh báo trở thành sự cố

Không phải mọi alert đều là incident. JSM cho phép định nghĩa rõ ràng khi nào alert group tự động trở thành incident cần response team:

Alert (cảnh báo) – chỉ cần lưu ý:

• CPU spike ngắn (<2 phút) rồi tự hồi phục
• Disk usage tăng dần nhưng chưa tới ngưỡng critical
• Latency tăng nhẹ trong giờ peak nhưng trong SLA
• Single service degraded nhưng có workaround

Incident (sự cố) – cần response team ngay:

• Error rate vượt ngưỡng cho phép trong >3 phút
• Nhiều service liên quan cùng bị ảnh hưởng (correlation)
• Business flow critical bị gián đoạn
• Không tự hồi phục sau thời gian cho phép

Cấu hình trên JSM Automation:

RULE: Auto-create Incident from Alert Group

TRIGGER: Alert group created hoặc updated
CONDITIONS (bất kỳ điều kiện nào match):
1. Alert count trong group > 10 trong 5 phút
AND affected service tier = 1 hoặc 2

2. Error rate > 5% kéo dài > 3 phút
AND business flow = critical

3. Multiple services affected (>= 3 services)
AND alert priority >= P2

4. Synthetic monitoring failed
AND service = customer-facing

ACTION:
1. Tạo JSM Incident ticket tự động
2. Link tất cả alert trong group vào incident
3. Auto-classify severity dựa trên business impact
4. Trigger notification workflow (Bước 4)

Ví dụ kịch bản quyết định:

Bước 4: Thông báo nhanh – Đúng người, đúng lúc, đúng kênh

Khi alert trở thành incident, tốc độ thông báo đến đúng người xử lý quyết định toàn bộ. JSM/Opsgenie cung cấp multi-channel notification đảm bảo không ai bỏ lỡ:

Escalation policy – đảm bảo không incident nào bị bỏ lỡ:

ESCALATION POLICY: P1 Critical Incident
Step 1 (0 phút):
  → Push notification + SMS đến on-call engineer chính
  → Slack message đến channel #incident-response
Step 2 (3 phút — nếu chưa acknowledge):
  → Gọi điện thoại cho on-call engineer chính
  → Push notification cho on-call engineer backup
Step 3 (5 phút — nếu vẫn chưa acknowledge):
  → Gọi điện thoại cho on-call engineer backup
  → SMS đến Engineering Manager
  → Email đến IT Director
Step 4 (10 phút — nếu vẫn chưa acknowledge):
  → Gọi điện thoại cho Engineering Manager
  → Email + SMS đến CIO
  → Auto-create war room trên Slack
Step 5 (15 phút — nếu vẫn chưa acknowledge):
  → Gọi điện thoại cho IT Director
  → Notify toàn bộ engineer team qua SMS blast

On-call schedule – biết chính xác gọi ai lúc nào:

JSM/Opsgenie quản lý on-call rotation tự động:

On-call Schedule: API Platform Team
Rotation: Weekly
  Week 1: Nguyễn Văn A (primary), Trần Thị B (backup)
  Week 2: Lê Văn C (primary), Nguyễn Văn A (backup)
  Week 3: Trần Thị B (primary), Lê Văn C (backup)
Override rules:
  - Public holidays: tự động chuyển sang backup
  - Nếu primary đang on leave: tự động chuyển sang backup
Contact preferences (mỗi engineer tự cấu hình):
  - Giờ hành chính (8h-18h): Push notification → chờ 3 phút → SMS
  - Ngoài giờ (18h-8h): SMS → chờ 2 phút → Gọi điện
  - Weekend: Gọi điện ngay lập tức cho P1

Tóm lại, chuỗi giá trị 4 bước:

Monitoring tools (Datadog, Zabbix, Dynatrace...)
  ↓ [Tích hợp — 200+ integrations]
JSM/Opsgenie nhận alert từ mọi nguồn
  ↓ [Gom nhóm — dedup, correlation, time-based]
47 alert → 1 alert group có context rõ ràng
  ↓ [Phân loại — rule-based + AI pattern matching]
Quyết định: Đây là alert (lưu ý) hay incident (cần action)?
  ↓ [Thông báo — multi-channel, escalation]
Đúng người nhận thông báo trong 1-2 phút qua kênh phù hợp nhất

4. Vai trò AI (Rovo) trong chuỗi phát hiện và học hỏi từ sự cố

Trong hệ sinh thái Atlassian, Rovo – AI engine – bổ sung thêm một lớp thông minh không chỉ cho việc phát hiện sự cố, mà còn cho việc ghi chép và học hỏi sau sự cố.

4.1. Smart correlation: Gom nhóm thông minh hơn rule cứng

Rule-based grouping (gom theo thời gian, theo service name) hoạt động tốt cho các pattern đã biết. Nhưng Rovo có thể phát hiện correlation mới mà rule chưa cover:

• Alert trên Service A và Service B chưa bao giờ được gom nhóm, nhưng Rovo nhận ra 3 tháng qua, cứ khi nào Service A timeout thì 5 phút sau Service B cũng timeout → suggest tạo correlation rule mới

• Alert message khác nhau hoàn toàn nhưng Rovo nhận ra cùng root cause từ incident history → gom lại

4.2. Context enrichment: Thêm ngữ cảnh cho alert

Khi incident được tạo tự động từ alert group, Rovo ngay lập tức:

• Tìm incident tương tự trong lịch sử JSM (semantic search, không chỉ keyword match)
• Tìm change request gần đây trên component bị ảnh hưởng
• Đề xuất runbook từ Confluence knowledge base
• Xác định business process bị ảnh hưởng từ Compass service catalog

Engineer mở ticket lên, thấy ngay toàn bộ context thay vì phải tự tra cứu 5–7 tool khác nhau.

4.3. Noise reduction: Giảm alert fatigue

Rovo học từ feedback của engineer: alert nào thường bị dismiss (noise), alert nào thường dẫn đến incident thật. Theo thời gian, Rovo suggest:

• Điều chỉnh threshold monitoring cho alert hay bị false positive
• Suppress alert pattern noise trong giờ peak đã biết
• Highlight alert pattern mới chưa từng thấy (potential unknown issue)

4.4. Auto-generate Post-Incident Review (PIR): Biến kinh nghiệm xử lý thành tài sản tri thức

Đây là phần giải quyết pain point thứ hai: sau khi xử lý xong sự cố, không ai ghi chép lại.

Tại sao pain point này nghiêm trọng?

Thực tế trong hầu hết tổ chức BFSI:

• Sự cố P1 xảy ra, cả team xông vào xử lý trong 2–3 giờ căng thẳng
• Resolve xong, mọi người thở phào, quay lại việc đang dở
• Không ai viết Post-Incident Review vì “bận quá”, “để mai viết” rồi “mai” không bao giờ đến
• 3 tháng sau, cùng loại sự cố xảy ra lần 2 – engineer mới join team không biết lần trước xử lý thế nào, lại mò từ đầu
• Kiến thức nằm trong đầu 1–2 người, khi họ nghỉ phép hoặc nghỉ việc → kiến thức mất theo
• Hậu quả đo được:

Giải pháp: Rovo tự động tạo PIR draft

Thay vì yêu cầu engineer viết PIR từ đầu (điều mà 80% thời gian không xảy ra), Rovo tự động tạo PIR draft ngay khi incident được resolve:

TRIGGER: Incident status chuyển sang "Resolved"
ROVO TỰ ĐỘNG:
1. Thu thập dữ liệu từ incident ticket:
   - Timeline: khi nào alert đầu tiên, khi nào acknowledge, khi nào resolve
   - Ai tham gia xử lý (từ assignee, watchers, comments)
   - Các action đã thực hiện (từ comment history, status changes)
2. Thu thập dữ liệu từ các nguồn liên quan:
   - Slack/Teams war room messages (nếu có)
   - Change requests liên quan trong thời gian sự cố
   - Alert data từ Opsgenie
   - Deployment logs từ Bitbucket/CI-CD
3. Generate PIR draft trên Confluence với cấu trúc:
   ├── Incident Summary (tự động)
   ├── Timeline of Events (tự động từ data)
   ├── Impact Assessment (tự động từ service tier + duration)
   ├── Root Cause Analysis (draft — cần engineer review)
   ├── What Went Well (draft từ response time data)
   ├── What Could Be Improved (draft từ timeline gaps)
   ├── Action Items (cần engineer điền)
   └── Lessons Learned (cần engineer điền)
4. Gửi notification cho incident owner:
   "PIR draft đã được tạo tự động.
    Bạn chỉ cần review và bổ sung Root Cause + Action Items.
    Estimated time: 15 phút thay vì 1-2 giờ viết từ đầu."

Tại sao cách này hiệu quả:

4.5. Knowledge loop: Biến PIR thành vũ khí cho incident tiếp theo

PIR không chỉ để lưu trữ – Rovo tạo ra vòng lặp học hỏi liên tục:

Incident xảy ra
  ↓
Rovo tìm PIR của incident tương tự trong quá khứ
  ↓ (context enrichment — mục 4.2)
Engineer thấy ngay: "Lần trước cùng triệu chứng, root cause là X, fix bằng cách Y"
  ↓
Xử lý nhanh hơn (MTTR giảm)
  ↓
Resolve → Rovo tạo PIR mới
  ↓
PIR mới bổ sung vào knowledge base
  ↓
Incident tiếp theo được hưởng lợi từ PIR này
  ↓ (lặp lại)

Ví dụ thực tế:

• Tháng 1: Incident P1 – Mobile Banking timeout. Team mất 3 giờ tìm root cause (connection pool exhaustion trên database). Rovo tạo PIR, document chi tiết cách fix.
• Tháng 4: Incident tương tự xảy ra. Rovo ngay lập tức surface PIR tháng 1: “Incident tương tự đã xảy ra ngày 15/01. Root cause: connection pool exhaustion. Fix: restart connection pool + tăng max_connections. Runbook: [link]”. Engineer mới (chưa từng gặp sự cố này) resolve trong 30 phút thay vì 3 giờ.

5. Cách triển khai thực tế theo từng phase

Triển khai hệ thống phát hiện sự cố sớm và ghi chép sau sự cố không phải dự án “mua tool về dùng” mà cần lộ trình rõ ràng. Phần dưới đây trình bày kế hoạch triển khai 8 tuần, chia thành 4 phase trên nền tảng Atlassian.

Bộ công cụ sử dụng xuyên suốt:

Phase 1: Foundation – Kết nối monitoring với JSM (Tuần 1–2)

Mục tiêu: Tất cả alert từ mọi monitoring tool đều đổ về JSM/Opsgenie. Setup on-call schedule cơ bản.

Checklist Phase 1

[ ] Liệt kê tất cả monitoring tool đang sử dụng

[ ] Cấu hình integration: mỗi monitoring tool → Opsgenie → JSM

[ ] Test alert flow: tạo test alert từ mỗi tool, verify nhận được trong JSM

[ ] Setup on-call schedule cho mỗi team trong Opsgenie

[ ] Cấu hình contact preferences cho mỗi engineer (kênh thông báo theo giờ)

[ ] Setup escalation policy cơ bản (3 bước)

[ ] Chạy song song 1 tuần: monitoring cũ + JSM – verify không miss alert

Chi tiết triển khai

Tuần 1: Kết nối monitoring

Sai lầm phổ biến nhất: cố gắng setup cả hệ thống phức tạp ngay từ đầu. Bước đầu chỉ cần đảm bảo mọi alert đều đến được JSM – chưa cần gom nhóm, chưa cần auto-create incident.

Với mỗi monitoring tool:

1. Tạo integration trong Opsgenie (hầu hết tool phổ biến có sẵn native integration)
2. Cấu hình alert payload mapping: title, description, priority, tags
3. Test với alert thật: trigger alert trên monitoring → verify JSM nhận được
4. Cấu hình deduplicate cơ bản: alert cùng source + cùng message → gom thành 1

Tuần 2: On-call & Escalation

Setup on-call rotation cho mỗi team:

Team: API Platform
  Rotation: Weekly, starts Monday 9:00 AM
  Members: 4 engineers
  Primary + Backup
Team: Database
  Rotation: Weekly
  Members: 3 engineers
Team: Infrastructure
  Rotation: Bi-weekly
  Members: 5 engineers

Thiết lập escalation policy theo severity:

Phase 2: Alert Grouping & Noise Reduction (Tuần 3–4)

Mục tiêu: Gom nhóm alert thông minh. Giảm noise. Engineer chỉ nhận notification đáng chú ý.

Checklist Phase 2

• [ ] Phân tích 2 tuần alert data: bao nhiêu alert/ngày, bao nhiêu là noise
• [ ] Cấu hình time-based grouping: alert trong cùng 5 phút → 1 group
• [ ] Cấu hình service-based grouping: alert cùng service → 1 group
• [ ] Cấu hình content-based deduplication: alert cùng message → count thay vì duplicate
• [ ] Tạo correlation rules cho các pattern đã biết
• [ ] Cấu hình suppression rules cho known noise patterns
• [ ] Đo kết quả: số notification/ngày giảm bao nhiêu %
• [ ] Verify: không miss alert thật do suppression

Chi tiết triển khai

Tuần 3: Grouping rules

Phân tích alert data 2 tuần đầu:

Trước grouping:
  Total alerts/ngày: ~800
  Notifications/engineer/ngày: ~120
  → Alert fatigue: CAO
Sau grouping:
  Alert groups/ngày: ~50-80
  Notifications/engineer/ngày: ~10-15
  → Manageable, mỗi notification đều có ý nghĩa

Cấu hình 3 lớp grouping trong Opsgenie:

Tuần 4: Noise suppression

Xác định và suppress noise patterns:

Suppression rules:
  1. CPU spike < 2 phút rồi tự recovery → Suppress, log only
  2. Known scheduled job gây spike hàng ngày 2h-3h sáng → Suppress during window
  3. Alert đã resolve tự động trong 1 phút → Suppress notification, keep log
  4. Duplicate alert từ redundant monitoring → Keep 1 source, suppress others

Quan trọng: Mọi suppression rule đều phải được review hàng tuần. Alert bị suppress vẫn được log — nếu pattern thay đổi (ví dụ spike trước đây 30 giây nhưng giờ kéo dài 5 phút), rule cần được update.

Phase 3: Alert → Incident tự động + AI Context + PIR Foundation (Tuần 5–6)

Mục tiêu: Tự động quyết định khi nào alert group trở thành incident. Rovo tự động thêm context cho incident. Thiết lập nền tảng cho Post-Incident Review tự động.

Checklist Phase 3

• [ ] Định nghĩa tiêu chí alert → incident cho từng service tier

• [ ] Cấu hình JSM Automation: auto-create incident từ alert group
• [ ] Cấu hình auto-severity classification
• [ ] Setup Compass service catalog (service → owner → tier)
• [ ] Cấu hình Rovo Action: auto-generate Incident Brief
• [ ] Cấu hình Rovo Action: find similar incidents
• [ ] Cấu hình Rovo Action: suggest runbook
• [ ] Tạo PIR template chuẩn trên Confluence
• [ ] Tạo Confluence space “Incident Knowledge Base” với cấu trúc rõ ràng
• [ ] Cấu hình JSM Automation: khi incident resolve → tự động tạo PIR draft trên Confluence
• [ ] Cấu hình Rovo Action: auto-populate PIR draft với data từ incident
• [ ] Pilot 2 tuần với 1–2 team
• [ ] Thu thập feedback, adjust rules

Chi tiết triển khai

Tuần 5: Auto-create incident + Severity classification

JSM Automation Rules:

Rule 1: Auto-create Incident

TRIGGER: Alert group match incident criteria
CONDITIONS (any):
  - Alert count > 10 AND service tier ≤ 2
  - Error rate > 5% AND duration > 3 min
  - Multiple services (≥ 3) affected simultaneously
  - Customer-facing synthetic monitoring failed
ACTION:
  1. Create JSM Incident
  2. Auto-classify severity (Rule 2)
  3. Link alert group → incident
  4. Trigger Rovo: Generate Incident Brief
  5. Trigger notification workflow

Rule 2: Auto-classify Severity

S1 — Critical:
  Service tier = 1 AND (down OR error rate > 20%)
  → Gọi điện ngay + War room + Notify CIO
S2 — Major:
  Service tier = 1 AND degraded
  OR Service tier = 2 AND down
  → SMS + Slack channel + Notify Manager
S3 — Minor:
  Service tier = 2 AND degraded
  OR Service tier = 3 AND down
  → Push notification + Email
S4 — Low:
  Service tier = 3 AND degraded
  OR has workaround
  → Email only

Tuần 6: Rovo AI integration + PIR Foundation + Pilot

Cấu hình Rovo Actions – giờ đây gồm cả phần phát hiện sớm và ghi chép sau sự cố:

Rovo Actions cho phát hiện sớm (khi incident được tạo):

Rovo Actions cho ghi chép sau sự cố (khi incident được resolve):

Setup Confluence “Incident Knowledge Base”:

Confluence Space: "Incident Knowledge Base"
├── 📁 By Service
│   ├── API Platform
│   │   ├── PIR-2026-001: Transaction timeout (15/01/2026)
│   │   ├── PIR-2026-005: Connection pool exhaustion (12/03/2026)
│   │   └── ...
│   ├── Database
│   ├── Mobile Banking
│   └── ...
├── 📁 By Root Cause Category
│   ├── Capacity / Performance
│   ├── Configuration Change
│   ├── Third-party Dependency
│   ├── Code Bug
│   └── Infrastructure Failure
├── 📁 By Quarter
│   ├── Q1-2026
│   ├── Q2-2026
│   └── ...
└── 📄 Incident Trends Dashboard (Rovo auto-update hàng tháng)
    ├── Top recurring root causes
    ├── MTTR trend by service
    ├── Action items completion rate
    └── Services with most incidents

JSM Automation Rule: Auto-create PIR

TRIGGER: Incident status chuyển sang "Resolved"
ACTION:
  1. Rovo thu thập data:
     - Incident timeline (created → acknowledged → investigating → resolved)
     - Tất cả comments trên ticket (theo thứ tự thời gian)
     - Alert group data (số alert, source, affected services)
     - Participants (assignee, watchers, commenters)
     - Change requests trong ±24h trên affected services
     - Slack/Teams war room transcript (nếu có)
  2. Rovo generate PIR draft trên Confluence:
     ┌─────────────────────────────────────────────┐
     │  POST-INCIDENT REVIEW                       │
     │  Incident: [INC-XXX] — [Title]              │
     │  Date: [Auto]  │  Severity: [Auto]          │
     │  Duration: [Auto-calculated]                 │
     ├─────────────────────────────────────────────┤
     │  📋 SUMMARY (auto-generated)                │
     │  [Rovo tóm tắt incident trong 3-5 câu]      │
     ├─────────────────────────────────────────────┤
     │  ⏱ TIMELINE (auto-generated từ system data) │
     │  14:30 — Alert đầu tiên: API timeout         │
     │  14:31 — Alert group created (47 alerts)     │
     │  14:32 — Incident auto-created, severity S1  │
     │  14:33 — On-call acknowledged                │
     │  14:35 — War room opened                     │
     │  14:50 — Root cause identified               │
     │  15:10 — Fix deployed                        │
     │  15:15 — Service recovered                   │
     │  15:30 — Incident resolved                   │
     ├─────────────────────────────────────────────┤
     │  💥 IMPACT (auto-generated)                  │
     │  - Services affected: [từ Compass]           │
     │  - Duration: [auto-calculated]               │
     │  - Users affected: [từ monitoring data]      │
     │  - Business process impacted: [từ Compass]   │
     ├─────────────────────────────────────────────┤
     │  🔍 ROOT CAUSE (⚠️ CẦN ENGINEER REVIEW)     │
     │  [Rovo draft dựa trên comments + actions]    │
     │  → Engineer xác nhận hoặc chỉnh sửa         │
     ├─────────────────────────────────────────────┤
     │  ✅ WHAT WENT WELL (auto-generated)          │
     │  - MTTI: 2 phút (target: <3 phút)           │
     │  - Acknowledge: 1 phút                      │
     │  - Escalation: không cần (resolved nhanh)    │
     ├─────────────────────────────────────────────┤
     │  ⚠️ WHAT COULD BE IMPROVED (draft)           │
     │  [Rovo suggest dựa trên timeline gaps]       │
     │  → Engineer review và bổ sung                │
     ├─────────────────────────────────────────────┤
     │  📌 ACTION ITEMS (⚠️ CẦN ENGINEER ĐIỀN)     │
     │  [ ] Preventive action 1: ___                │
     │  [ ] Preventive action 2: ___                │
     │  [ ] Monitoring improvement: ___             │
     │  → Mỗi action item sẽ tạo Jira ticket       │
     ├─────────────────────────────────────────────┤
     │  📚 LESSONS LEARNED (⚠️ CẦN ENGINEER ĐIỀN)  │
     │  [Rovo suggest câu hỏi gợi ý:]              │
     │  - Sự cố này có thể phòng tránh không?       │
     │  - Monitoring hiện tại có đủ không?           │
     │  - Runbook có cần update không?               │
     └─────────────────────────────────────────────┘
  3. Link PIR page ↔ JSM Incident ticket (2 chiều)
  4. Auto-categorize PIR:
     - Tag theo service, root cause category, severity
     - Đặt vào đúng folder trong Confluence KB
  5. Notify incident owner:
     "PIR draft đã sẵn sàng — bạn chỉ cần review Root Cause,
      điền Action Items và Lessons Learned (~15 phút).
      Link: [Confluence page URL]
      Deadline: 48h sau resolve."
  6. Auto-reminder nếu PIR chưa được review:
     - 24h sau: Reminder cho incident owner
     - 48h sau: Notify Engineering Manager
     - 72h sau: Escalate lên IT Director

Pilot với 1–2 team trong 2 tuần:

• Chạy song song: hệ thống cũ + JSM auto-detection + auto-PIR
• So sánh: MTTI hệ thống mới vs MTTI hệ thống cũ
• Đo: PIR completion rate (bao nhiêu % incident có PIR?)
• Thu thập feedback hàng ngày qua Confluence “Pilot Feedback”

Phase 4: Optimize, Knowledge Loop & Scale (Tuần 7–8+)

Mục tiêu: Fine-tune dựa trên data thực. Xây dựng vòng lặp học hỏi liên tục. Mở rộng coverage. Dashboard KPI.

Checklist Phase 4

• [ ] Review false positive rate: bao nhiêu auto-created incident thực sự là incident?
• [ ] Review false negative rate: có incident nào bị miss không?
• [ ] Adjust grouping rules và incident criteria dựa trên data
• [ ] Tạo JSM Dashboard “Incident Detection Analytics”
• [ ] Review PIR completion rate: bao nhiêu % incident có PIR?
• [ ] Review PIR quality: PIR có đủ chi tiết không? Action items có được follow up không?
• [ ] Cấu hình Rovo: auto-generate monthly Incident Trends Report từ PIR data
• [ ] Setup quarterly PIR review meeting — rút bài học tổng thể
• [ ] Cấu hình Rovo Action: khi tạo incident mới → auto-search PIR liên quan → attach vào incident
• [ ] Mở rộng coverage: thêm monitoring source, thêm service vào Compass
• [ ] Training cho toàn bộ on-call engineers
• [ ] Setup quarterly review process

JSM Dashboard – “Incident Detection & Learning Analytics”:

Hàng tháng, Rovo tự động tạo report trên Confluence bằng cách phân tích toàn bộ PIR trong tháng:

📊 INCIDENT TRENDS REPORT — Tháng 5/2026
TỔNG QUAN:
- Tổng incidents: 23 (↓15% so với tháng 4)
- P1: 2  |  P2: 5  |  P3: 11  |  P4: 5
- MTTI trung bình: 2.3 phút (target: <3 phút) ✅
- MTTR trung bình: 45 phút (↓20% so với tháng 4) ✅
- PIR completion: 100% P1-P2, 82% P3 (target: 100% P1-P2) ✅
TOP ROOT CAUSE CATEGORIES:
1. Configuration Change (8 incidents) — ⚠️ tăng 60%
   → Suggest: Review change management process
2. Capacity/Performance (6 incidents) — stable
3. Third-party Dependency (4 incidents) — stable
4. Code Bug (3 incidents) — ↓ 40%
5. Infrastructure (2 incidents) — stable
RECURRING INCIDENTS:
- "Connection pool exhaustion" — lần thứ 3 trong 6 tháng
  → Action item từ PIR-2026-005 chưa được implement!
  → ⚠️ ESCALATE: Cần prioritize fix
SERVICES CẦN CHÚ Ý:
- API Gateway: 5 incidents trong tháng — nhiều nhất
- Payment Service: 2 P1 incidents — cần architectural review
ACTION ITEMS STATUS:
- Total from this month's PIRs: 34
- Completed: 21 (62%)
- In progress: 8 (23%)
- Overdue: 5 (15%) — ⚠️ cần follow up

Tổng hợp Timeline 8 tuần

6. Những sai lầm cần tránh

7. KPI cần đo

Hai KPI quan trọng nhất:

#8 Business-first detection rate: Nếu con số này giảm từ >50% xuống <10%, nghĩa là đội IT đã chuyển từ reactive sang proactive.

#13 Recurring incident rate: Nếu con số này giảm 50% sau 6 tháng, nghĩa là vòng lặp học hỏi đang hoạt động – team không chỉ fix sự cố, mà thực sự ngăn nó xảy ra lần nữa.

Cách present cho leadership:

• Trước: “Hệ thống lỗi 40 phút rồi business mới báo IT. Xử lý xong không ai ghi chép. 3 tháng sau cùng lỗi xảy ra lần 2 – engineer lại mò từ đầu.”

• Sau: “Hệ thống bất thường 2 phút, IT đã biết và đang xử lý. Resolve xong, PIR tự động được tạo. 3 tháng sau triệu chứng tương tự xuất hiện – engineer mở ticket thấy ngay PIR cũ, resolve trong 30 phút thay vì 3 giờ. Và loại sự cố này đã giảm 50% nhờ preventive action từ PIR.”

8. Kết luận

Trong nhiều thảo luận về Incident Management, người ta thường tập trung vào xử lý sự cố nhanh hơn – giảm MTTR, tìm root cause nhanh hơn, rollback nhanh hơn. Nhưng có một sự thật đơn giản:

Bạn không thể xử lý nhanh một sự cố mà bạn chưa biết là nó đang xảy ra.

MTTI (Mean Time to Identify) là khoảng thời gian “vô hình” – sự cố đã xảy ra, khách hàng đã bị ảnh hưởng, nhưng đội IT chưa biết. Mọi phút trong khoảng này đều là phút mà SLA bị “ăn” mà không ai đang fix.

JSM tích hợp monitoring không phải thay thế monitoring tool hiện có – mà là thêm lớp thông minh giữa monitoring và con người:

• Thu thập alert từ mọi nguồn về một nơi
• Gom nhóm để giảm noise, tăng signal
• Phân loại để biết cái gì cần action ngay, cái gì chỉ cần lưu ý
• Thông báo đúng người, đúng lúc, qua kênh đủ mạnh để không bị bỏ lỡ

Câu hỏi cốt lõi không phải “monitoring tool có đủ không?” – mà là: “Khi monitoring tool bắn alert, bao lâu sau đúng người biết và bắt đầu xử lý?”

Nếu câu trả lời là “30–45 phút”, đó là 30–45 phút mà khách hàng đang chịu ảnh hưởng trong im lặng.

Bắt đầu bằng cách kết nối monitoring hiện có với JSM. 8 tuần có hệ thống hoạt động. Sau đó liên tục fine-tune dựa trên data thực.

>> Xem thêm Cách AI đánh giá rủi ro cho Change Request – giảm 70% thời gian chuẩn bị CAB