IIMS – Core Domain Model

Mục đích

Tài liệu này mô tả các khái niệm nghiệp vụ cốt lõi của IIMS như được triển khai trong nền tảng hiện tại.

Tài liệu giải thích cách mà hạ tầng, cấu hình giám sát, cảnh báo, sự cố, phiếu hỗ trợ, bảo trì và hoạt động được mô hình hóa bên trong hệ thống, đồng thời phân biệt rõ ràng giữa:

Những gì đã được triển khai trong hiện tại
Những gì được lên kế hoạch cho các phiên bản tương lai

Mục tiêu là cung cấp một cách hiểu chung, chính xác cho chủ sản phẩm, kiến trúc sư và kỹ sư trước khi đi vào chi tiết triển khai kỹ thuật.

Tổng quan về domain model

Ở mức cao, IIMS mô hình hóa năm nhóm khái niệm chính:

Cấu trúc hạ tầng (Site, Asset, Topology Link)
Cấu hình giám sát (Target, Collector, Pack, Profile)
Tín hiệu vận hành (Alert)
Quy trình con người (Incident, Ticket, Activity)
Kiểm soát vận hành (Maintenance window)

Các khái niệm này tạo thành nền tảng cho toàn bộ tính năng và luồng làm việc của hệ thống.

Luồng Giám sát Từ Đầu đến Cuối (Mô hình Khái niệm)

Site
  └── Asset
        └── được giám sát bởi → Monitoring Profile
                 └── xây dựng từ → Monitoring Pack
                 └── sử dụng → Monitoring Target
                          └── thông qua → Collector
                                   ↓
                         Hệ thống giám sát
                     (Zabbix / Prometheus / …)
                                   ↓
                                Alert
                                   ↓
                               Incident
                                   ↓
                                Ticket

1. Phân cấp Site và Asset

1.1 Site

Site đại diện cho một vị trí vật lý hoặc logic nơi hạ tầng tồn tại.

Ví dụ:

Trung tâm dữ liệu
Văn phòng chi nhánh
Khu vực cloud

Vai trò trong hiện tại:

Nhóm các asset theo vị trí
Định nghĩa phân cấp giữa các vị trí
Cung cấp ngữ cảnh mặc định cho định tuyến giám sát và chính sách

Đặc điểm quan trọng:

Site có cấu trúc phân cấp (vùng → quốc gia → thành phố → tòa nhà)
Site có thể định nghĩa Target và Collector mặc định
Site có thể định nghĩa hành vi bảo trì và định tuyến mặc định
Site trả lời câu hỏi: Hạ tầng nằm ở đâu?

Ghi chú (phạm vi hiện tại):

Site chủ yếu cung cấp vị trí địa lý cho việc kế thừa asset và hiển thị bản đồ
Site không phải là đối tượng giám sát chính; Asset mới là đối tượng giám sát chính

Kế hoạch:

Chấm điểm sức khỏe ở mức Site và hiển thị marker trực tiếp trên GeoMap
Nhóm dịch vụ / nghiệp vụ ở mức Site

1.2 Asset

Asset là một đối tượng thực được giám sát.

Ví dụ:

Router, switch, firewall
Máy chủ hoặc máy ảo
Ứng dụng hoặc dịch vụ

Vai trò trong hiện tại:

Đối tượng giám sát chính của hệ thống
Luôn thuộc về đúng một Site
Đơn vị chính cho alert, incident, telemetry và topology

Đặc điểm quan trọng:

Mỗi asset có một loại (thiết bị mạng, máy chủ, dịch vụ, …)
Mỗi asset có thể có một hoặc nhiều monitoring profile
Asset kế thừa vị trí và mặc định từ Site nếu không được cấu hình riêng
Asset tham gia vào topology và hiển thị địa lý

Asset trả lời câu hỏi: Chúng ta đang giám sát cái gì?

Kế hoạch:

Quản lý inventory ở mức interface như đối tượng hạng nhất
Trạng thái vòng đời asset (dự kiến, hoạt động, ngừng sử dụng)
Đồng bộ CMDB và mẫu asset

1.3 Phân cấp Site – Asset

Mô hình phân cấp hiện tại cung cấp:

Điều hướng theo vị trí (dạng cây)
Tổng hợp số lượng alert và mức độ nghiêm trọng
Kế thừa chính sách (định tuyến giám sát, mặc định bảo trì)

Cấu trúc điển hình:

Region
└── Data Center
    └── Zone
        └── Assets

Mô hình này cho phép người vận hành:

Điều hướng hạ tầng theo vị trí
Xem tổng hợp alert theo site
Đi sâu từ site → asset → alert / incident

Ghi chú:

Tổng hợp hiện tại tập trung vào số lượng alert và mức độ nghiêm trọng cao nhất
Chấm điểm sức khỏe đầy đủ và tổng hợp SLA sẽ được bổ sung trong tương lai

2. Mô hình Topology

2.1 Link (Topology)

Link đại diện cho một kết nối vật lý hoặc logic giữa hai đầu cuối.

Các loại đầu cuối được hỗ trợ:

Asset ↔ Asset
Site ↔ Site
Asset ↔ Site

Ví dụ:

Kết nối cáp quang giữa các router
Tunnel logic giữa các dịch vụ

Vai trò trong hiện tại:

Mô hình hóa kết nối để hiển thị
Cung cấp gán trạng thái thủ công và đánh giá trạng thái theo chính sách
Cho phép hiển thị GeoMap và sơ đồ topology

Link trả lời câu hỏi: Các asset được kết nối với nhau như thế nào?

2.2 Mô hình Ảnh hưởng Topology

Hành vi hiện tại:

Link và asset hiển thị trạng thái và mức độ riêng lẻ
Người vận hành quan sát topology và bản đồ trực quan
Phân tích ảnh hưởng chủ yếu là thủ công

Đã triển khai:

Gán trạng thái thủ công (alert / availability / interface)
Đánh giá trạng thái link theo chính sách (luật “xấu nhất”)
Hiển thị link và asset bị ảnh hưởng trên bản đồ

Chưa triển khai (kế hoạch):

Tự động lan truyền ảnh hưởng qua đồ thị topology
Suy luận nguyên nhân gốc từ chuỗi phụ thuộc
Mô hình hóa ảnh hưởng ở mức dịch vụ

3. Vòng đời Alert

3.1 Định nghĩa Alert

Alert là một tín hiệu kỹ thuật thô do hệ thống giám sát sinh ra.

Nguồn trong hiện tại:

Zabbix (nhà cung cấp chính)

Vai trò:

Sự kiện ở mức máy móc
Xuất hiện thường xuyên và nhiều nhiễu
Không phải đối tượng trực tiếp cho quy trình con người

Alert đại diện cho triệu chứng kỹ thuật, không phải là vấn đề.

3.2 Trạng thái Alert (hiện tại)

Các trạng thái hỗ trợ:

Open / Active
Acknowledged
Resolved / Closed

Thuộc tính bổ sung:

Bị suppress bởi bảo trì
Gắn với tối đa một incident đang hoạt động

Ghi chú:

Tính năng khử trùng lặp và gom nhóm nâng cao còn hạn chế

Kế hoạch:

Luật tương quan nâng cao
Tự động khử trùng lặp và gộp alert
Phân loại alert và chấm điểm nhiễu

3.3 Luồng xử lý Alert (hiện tại)

Hệ thống giám sát sinh alert
Alert được thu thập và chuẩn hóa vào IIMS
Áp dụng quy tắc suppress theo bảo trì
Người vận hành hoặc luật đơn giản gắn alert vào incident

Ghi chú:

Tương quan hiện tại chủ yếu thủ công hoặc rất nhẹ
Engine tương quan đầy đủ sẽ được bổ sung trong tương lai

4. Máy trạng thái Incident

4.1 Định nghĩa Incident

Incident đại diện cho một sự cố vận hành thực được xử lý bởi con người.

Được tạo từ:

Một hoặc nhiều alert liên quan

Vai trò trong hiện tại:

Đối tượng vận hành trung tâm
Theo dõi vòng đời, người phụ trách, alert và ticket

Incident đại diện cho quy trình con người để xử lý vấn đề.

4.2 Trạng thái Incident (hiện tại)

Các trạng thái đã triển khai:

New
Investigating / Open
Resolved
Closed

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

Suppressed (bảo trì)

Kế hoạch:

Trạng thái Assigned / In Progress
Gộp incident và xử lý trùng lặp
Chuyển trạng thái theo SLA

4.3 Chuyển trạng thái Incident

Các chuyển trạng thái hỗ trợ:

New → Investigating
Investigating → Resolved
Resolved → Closed

Trong vòng đời:

Alert có thể được thêm hoặc gỡ
Ticket có thể được tạo hoặc liên kết
Bình luận và hành động được ghi lại dưới dạng activity

4.4 Quyền sở hữu và trách nhiệm Incident

Hiện tại theo dõi:

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

Hạn chế:

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

Kế hoạch:

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

5. Quan hệ giữa Alert và Incident

Quy tắc chính:

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
Incident đại diện cho vấn đề ở mức con người
Alert vẫn là triệu chứng kỹ thuật thô

Sự tách biệt này cho phép:

Giảm nhiễu
Quy trình con người rõ ràng
Tích hợp ticket hiệu quả

Kế hoạch:

Tạo incident tự động và gộp incident
Chọn ứng viên nguyên nhân gốc

6. Ticket, Maintenance và Activity

Ticket

Hành vi hiện tại:

Incident có thể tạo ticket trong Zammad
Tham chiếu ticket được lưu trong incident
Trạng thái ticket có thể đồng bộ thủ công hoặc định kỳ

Kế hoạch:

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

Maintenance

Hành vi hiện tại:

Cửa sổ bảo trì suppress alert và incident
Suppress theo site, asset hoặc tag
Ticket có thể bị chặn trong thời gian bảo trì

Kế hoạch:

Tự động hóa bảo trì phía provider
Mô phỏng ảnh hưởng khi bảo trì

Activity

Hành vi hiện tại:

Mọi hành động quan trọng sinh activity event
Activity cung cấp audit trail và timeline vận hành

Kế hoạch:

Timeline liên đối tượng
Công cụ hậu kiểm và báo cáo

7. Tổng kết

Trong hiện tại, domain model cốt lõi của IIMS được xây dựng xoay quanh:

Site và Asset cho cấu trúc hạ tầng
Link cho hiển thị kết nối và chính sách thủ công
Alert cho tín hiệu kỹ thuật
Incident cho quy trình con người
Ticket, Maintenance và Activity cho kiểm soát vận hành

Mô hình này cung cấp một nền tảng ổn định cho vận hành hợp nhất.

Trong tương lai, hệ thống sẽ bổ sung:

Tương quan tự động và RCA
Lan truyền ảnh hưởng dựa trên topology
Engine SLA và leo thang
Mô hình dịch vụ và nghiệp vụ

Các mở rộng này sẽ xây dựng trên nền tảng hiện tại mà không phá vỡ quy trình đang có.