IIMS – Quy trình Vận hành & Vòng đời (Operational Workflows & Lifecycle)

Information Infrastructure Management System (IIMS)

Cách alert trở thành incident, incident trở thành hành động và vận hành luôn được kiểm soát

Mục đích

Tài liệu này mô tả các quy trình vận hành và vòng đời chính trong IIMS, phù hợp với việc triển khai iims-api và Flutter UI hiện tại.

Tài liệu giải thích:

Cách alert được thu thập và suppress bởi maintenance
Cách incident được tạo và quản lý
Cách ticket được tạo và liên kết
Cách topology và geo view cung cấp nhận thức tình huống
Cách cache và dashboard được làm mới

Tổng quan Luồng Vận hành

Ở mức cao, IIMS quản lý năm vòng đời vận hành chính:

Thu thập và chuẩn hóa alert
Suppress và kiểm soát maintenance
Tạo và quản lý vòng đời incident
Tạo ticket và đồng bộ hạn chế
Hiển thị topology và bản đồ địa lý cho nhận thức tình huống

Các vòng đời này chuyển đổi tín hiệu giám sát thô thành các quy trình vận hành có cấu trúc cho con người.

1. Quy trình Thu thập Alert

1.1 Nguồn Alert

Alert chủ yếu xuất phát từ:

Zabbix (nhà cung cấp giám sát chính trong hiện tại)

Ghi chú:

Prometheus và các nhà cung cấp khác được lên kế hoạch cho tương lai

Alert đại diện cho tín hiệu kỹ thuật thô. Chúng có thể:

Xuất hiện thường xuyên
Tồn tại ngắn hạn
Lặp lại và nhiều nhiễu

1.2 Luồng Thu thập Alert

Luồng hiện tại:

Hệ thống giám sát sinh alert
Adapter nhà cung cấp nhận và chuẩn hóa alert
Alert được lưu vào:
Lịch sử alert
Alert cache (cho dashboard và bản đồ)
Quy tắc suppress theo maintenance được áp dụng ngay lập tức

Ở giai đoạn này:

Alert vẫn chỉ là sự kiện kỹ thuật
Không đảm bảo tạo incident tự động

Kế hoạch:

Thu thập alert từ nhiều nhà cung cấp
Pipeline thu thập dạng streaming

2. Quy trình Suppress Maintenance

Maintenance là cơ chế kiểm soát hạng nhất trong hiện tại.

2.1 So khớp Maintenance

Với mỗi alert mới hoặc được cập nhật:

Các cửa sổ maintenance đang hoạt động được đánh giá
So khớp theo:
Site
Asset
Tag và phạm vi

2.2 Hành vi Suppress

Nếu maintenance áp dụng:

Alert được đánh dấu là suppressed
Alert không thể tạo hoặc cập nhật incident
Chặn tạo ticket
Lịch sử alert vẫn được lưu cho audit

Điều này giúp tránh:

Incident giả
Mệt mỏi cho người vận hành
Leo thang sai trong thời gian bảo trì

Kế hoạch:

Đồng bộ maintenance phía provider
Mô phỏng ảnh hưởng trong thời gian maintenance

3. Quy trình Tương quan Alert

3.1 Mục đích của Tương quan

Alert thô không phù hợp trực tiếp cho quy trình con người.

Tương quan gom nhóm alert thành các vấn đề vận hành có ý nghĩa và giảm nhiễu.

3.2 Luật Tương quan (Phạm vi Hiện tại)

Trong hiện tại, tương quan còn hạn chế và đơn giản:

Alert có thể được nhóm theo:
Asset
Site
Gần nhau về thời gian

Ghi chú:

Chưa có engine tương quan nâng cao
Tương quan dựa trên topology chưa tự động

3.3 Luồng Tương quan

Hành vi hiện tại:

Alert mới đến
IIMS tìm incident đang mở cho cùng asset hoặc site
Nếu tìm thấy, alert được gắn vào incident đó
Nếu không, người vận hành hoặc luật đơn giản có thể tạo incident mới

Quy tắc:

Nhiều alert có thể thuộc một incident
Một alert chỉ thuộc tối đa một incident đang hoạt động

Kế hoạch:

Luật tương quan nâng cao
Tạo và gộp incident tự động
Tương quan nhận biết topology

4. Tạo Incident và Vòng đời

4.1 Tạo Incident

Incident được tạo khi:

Một hoặc nhiều alert chỉ ra vấn đề vận hành thực sự
Người vận hành hoặc luật đơn giản quyết định mở incident

Incident là đối tượng vận hành trung tâm của IIMS.

4.2 Trạng thái Vòng đời Incident

Vòng đời hiện tại:

New
Investigating / Open
Resolved
Closed

Tùy chọn / hạn chế:

Suppressed (maintenance)

Ghi chú:

Assigned / In-Progress / SLA chưa được triển khai đầy đủ

Kế hoạch:

Trạng thái Assigned và In-Progress
Gộp incident và xử lý trùng lặp
Bộ đếm SLA và chính sách leo thang

4.3 Cập nhật Incident

Trong vòng đời:

Alert có thể được thêm hoặc gỡ
Mức độ nghiêm trọng có thể thay đổi
Ticket có thể được tạo hoặc liên kết
Bình luận và hành động được ghi lại

Mọi thay đổi quan trọng đều sinh ra activity event.

4.4 Sở hữu và Trách nhiệm Incident

Theo dõi hiện tại:

Trạng thái incident
Alert liên quan
Ticket liên kết (tùy chọn)

Giới hạn:

Phân công và sở hữu còn cơ bản
Chưa có cưỡng chế SLA tự động

Kế hoạch:

Mô hình phân công đầy đủ
Bộ đếm SLA và phát hiện vi phạm
Quy trình leo thang

5. Quy trình Đồng bộ Ticket

5.1 Chính sách Tạo Ticket

Ticket là tùy chọn.

Ticket có thể được tạo khi:

Người vận hành yêu cầu thủ công
Incident đạt mức nghiêm trọng cao

Không phải mọi incident đều cần ticket.

5.2 Luồng Tạo Ticket

Luồng hiện tại:

Người vận hành yêu cầu tạo ticket từ incident
IIMS gửi yêu cầu tới adapter Zammad
Zammad tạo ticket
Tham chiếu ticket được lưu trong incident

Cơ chế an toàn:

Chặn tạo ticket nếu maintenance đang hoạt động

5.3 Đồng bộ Ticket

Hành vi hiện tại:

Tham chiếu và trạng thái ticket được lưu trong IIMS
Đồng bộ trạng thái định kỳ ở mức hạn chế

Giới hạn:

Chưa có đồng bộ hai chiều thời gian thực
Bình luận và trạng thái workflow chưa được phản chiếu đầy đủ

Kế hoạch:

Đồng bộ hai chiều realtime
Nhiều ticket cho một incident
Hỗ trợ nhiều hệ thống ticket

6. Quy trình Ảnh hưởng Topology và Địa lý

6.1 Mục đích của Topology

Topology và geo view chủ yếu dùng cho:

Hiển thị kết nối
Nhận thức tình huống
Đánh giá ảnh hưởng thủ công

6.2 Hành vi Ảnh hưởng

Hành vi hiện tại:

Trạng thái asset và link được tính riêng lẻ
Trạng thái link đánh giá bằng gán thủ công và luật chính sách
GeoMap hiển thị cluster, asset và link

Giới hạn:

Không có lan truyền ảnh hưởng tự động
Không có engine suy luận nguyên nhân gốc

Kế hoạch:

Duyệt phụ thuộc tự động
Tính toán blast-radius
Xác định ứng viên nguyên nhân gốc
Mô hình hóa ảnh hưởng ở mức dịch vụ

7. Quy trình Activity và Audit

7.1 Sinh Activity Event

Activity event được sinh cho:

Tạo và cập nhật incident
Tạo ticket và thay đổi trạng thái
Tạo và cập nhật maintenance
Bình luận và hành động người dùng

7.2 Audit và Dòng thời gian

Hiện tại cung cấp:

Timeline activity theo từng incident
Audit trail cho hành động vận hành

Kế hoạch:

Timeline liên đối tượng (site, asset, service)
Công cụ post-mortem và báo cáo
Báo cáo SLA và tuân thủ

8. Quy trình Cập nhật Dashboard và Cache

8.1 Cache Vận hành

IIMS duy trì cache đọc cho:

Tổng hợp alert
Bộ đếm incident
Sức khỏe asset và site
GeoMap và topology

8.2 Luồng Làm mới

Khi trạng thái vận hành thay đổi:

Domain service cập nhật trạng thái bền vững
Worker nền làm mới cache tổng hợp
UI chỉ truy vấn API và cache của IIMS

Điều này đảm bảo hiệu năng UI nhanh và khả năng mở rộng.

Kế hoạch:

Cập nhật streaming và push
Dashboard realtime với WebSocket

9. Xử lý Lỗi và Phục hồi

9.1 Lỗi Provider

Hành vi:

Lỗi provider được ghi nhận và log
Worker nền retry để phục hồi
IIMS lõi vẫn hoạt động bình thường

Giới hạn:

Chưa có failover provider tự động

Kế hoạch:

Chấm điểm sức khỏe provider
Failover tự động và định tuyến chế độ suy giảm

9.2 Idempotency và Khử trùng lặp

Cơ chế bảo vệ hiện tại:

Thu thập alert là idempotent
Tạo incident ngăn trùng lặp
Tạo ticket được bảo vệ chống gửi lặp

Kế hoạch:

Luật khử trùng lặp toàn cục
Idempotency xuyên nhà cung cấp

10. Ví dụ Quy trình Đầu–Cuối

Kịch bản lỗi điển hình:

Interface router bị down trong Zabbix
Alert được thu thập vào IIMS
Kiểm tra maintenance (không có)
Người vận hành xem alert và tạo hoặc gắn vào incident
Trạng thái link và asset hiển thị trên GeoMap
Người vận hành tạo ticket trong Zammad
Kỹ sư điều tra và khắc phục
Alert clear và incident chuyển sang Resolved
Ticket đóng và incident chuyển sang Closed

Các Nâng cao Kế hoạch

Các trọng tâm kế hoạch:

Tương quan alert và tạo incident tự động
Lan truyền ảnh hưởng và RCA dựa trên topology
Bộ đếm SLA, leo thang và phân công
Đồng bộ ticket realtime
Dashboard streaming và push notification
Mô hình hóa ảnh hưởng dịch vụ và nghiệp vụ

12. Tổng kết

Trong hiện tại, quy trình vận hành của IIMS cung cấp:

Thu thập và suppress alert tin cậy
Xử lý incident thủ công và ít luật
Tạo ticket an toàn với chặn maintenance
Nhận thức tình huống bằng topology và bản đồ
Theo dõi activity và audit đầy đủ

Điều này thiết lập một nền tảng vận hành ổn định.

Các giai đoạn tương lai mở rộng nền tảng này với:

Tự động hóa và trí tuệ
Engine nguyên nhân gốc và ảnh hưởng
Quy trình dựa trên SLA
Cộng tác realtime và dashboard

Các nâng cao này được xây dựng tự nhiên trên kiến trúc hiện tại mà không phá vỡ vận hành.