Bỏ qua

IIMS – Kiến trúc & Thiết kế (Mô hình Mục tiêu)

Information Infrastructure Management System (IIMS)

Nền tảng Điều phối Vận hành Hợp nhất

Mục đích

Tài liệu này đại diện cho tài liệu tham chiếu kiến trúc và thiết kế tổng hợp cuối cùng của IIMS.

Tài liệu mô tả thiết kế mục tiêu của hệ thống (kiến trúc và quy trình vận hành ở trạng thái hoàn chỉnh), mà không phân tách theo các giai đoạn triển khai trong phần nội dung chính.

Mục tiêu của tài liệu là:

  • Trình bày một thiết kế hệ thống mạch lạc và chuyên nghiệp cho ban quản lý và các bên liên quan
  • Phản ánh một kiến trúc dài hạn được thiết kế cẩn thận
  • Cho phép việc triển khai hiện tại được định vị như một bước triển khai gia tăng của thiết kế này

Một phần riêng ở cuối tài liệu mô tả trạng thái triển khai hiện tại và lộ trình phát triển, giúp các nhóm hiểu rõ những gì đã được triển khai và những gì sẽ được thực hiện tiếp theo.

1. Tầm nhìn Hệ thống

IIMS (Information Infrastructure Management System) là một nền tảng điều phối vận hành hợp nhất, kết nối giám sát, topology, sự cố, bảo trì và ticketing vào một mô hình vận hành thống nhất.

Thay vì thay thế các nền tảng hiện có như Zabbix, Zammad hay Keycloak, IIMS tích hợp chúng và đóng vai trò như một lớp điều phối và trí tuệ vận hành trung tâm.

Mục đích của IIMS rất đơn giản:

Cung cấp cho đội vận hành một nơi duy nhất để hiểu điều gì đang xảy ra, xảy ra ở đâu, ảnh hưởng như thế nào và những hành động nào đang được thực hiện.

IIMS trở thành trung tâm điều khiển vận hành hàng ngày cho hệ thống hạ tầng.

2. Kiến trúc Tổng thể Hệ thống

Sơ đồ dưới đây mô tả kiến trúc tổng thể của IIMS, bao gồm lớp định danh, lớp ứng dụng, quản lý bí mật, lưu trữ dữ liệu và tích hợp với các hệ thống bên ngoài.

Kiến trúc Tổng thể IIMS

Kiến trúc được chia thành:

  • Lớp Định danh (Keycloak, JWT, MFA)
  • Lớp Ứng dụng (Flutter UI, NestJS API)
  • Lớp Dữ liệu & Bí mật (MongoDB, Vault)
  • Lớp Nhà cung cấp (Monitoring và Ticketing)

3. Nguyên tắc Cốt lõi

Tích hợp, Không Thay thế

IIMS tích hợp các hệ thống giám sát, ticketing và định danh hiện có thay vì thay thế chúng.

Một Góc nhìn Vận hành Duy nhất

Tất cả thông tin vận hành được hiển thị trong một nơi duy nhất:

  • Site và Asset
  • Alert và Incident
  • Cửa sổ bảo trì
  • Ticket và quy trình làm việc
  • Topology và bản đồ địa lý

Độc lập Nhà cung cấp

Tất cả hệ thống bên ngoài được trừu tượng hóa thông qua adapter. Domain model không phụ thuộc vào API của nhà cung cấp.

Tương quan Thay vì Dữ liệu Thô

IIMS tập trung vào việc tương quan các tín hiệu thành các vấn đề vận hành thay vì chỉ hiển thị các sự kiện thô.

Ưu tiên Vận hành

Thiết kế được dẫn dắt bởi các câu hỏi của người vận hành:

  • Site nào đang bị ảnh hưởng?
  • Mức độ ảnh hưởng ra sao?
  • Đây có phải là bảo trì đã được lên kế hoạch không?
  • Ai chịu trách nhiệm?

4. Core Domain Model

Mô hình Hạ tầng

  • Site – Một vị trí vật lý hoặc logic (vùng, trung tâm dữ liệu, chi nhánh)
  • Asset – Một đối tượng được giám sát (thiết bị, VM, dịch vụ)
  • Link – Một kết nối topology giữa các site và/hoặc asset

Site cung cấp phân cấp và ngữ cảnh địa lý. Asset là đối tượng giám sát chính. Link mô tả kết nối và phụ thuộc.

Mô hình Cấu hình Giám sát

  • Monitoring Target – Một backend giám sát đã được cấu hình
  • Collector – Một proxy hoặc nhóm agent thu thập dữ liệu
  • Pack – Một gói template giám sát có thể tái sử dụng
  • Profile – Một kế hoạch giám sát cụ thể được áp dụng cho asset

Mô hình này cho phép cấp phát và định tuyến độc lập nhà cung cấp.

Mô hình Vận hành

  • Alert – Một tín hiệu kỹ thuật từ hệ thống giám sát
  • Incident – Một vấn đề vận hành ở mức con người
  • Ticket – Một bản ghi ITSM bên ngoài liên kết với incident
  • Maintenance – Một khoảng thời gian suppress đã được lên kế hoạch
  • Activity Event – Một bản ghi audit và dòng thời gian vận hành

Alert là triệu chứng kỹ thuật. Incident là quy trình con người. Ticket đại diện cho quy trình và giao tiếp.

5. Kiến trúc Nhà cung cấp & Tích hợp

Mẫu Adapter

Tất cả hệ thống bên ngoài được tích hợp thông qua adapter:

  • Adapter giám sát (Zabbix, tương lai Prometheus)
  • Adapter ticketing (Zammad, ITSM tương lai)
  • Adapter định danh (Keycloak)

Adapter chuyển đổi các thao tác miền sang API cụ thể của nhà cung cấp và chuẩn hóa phản hồi.

Mô hình Định tuyến

Định tuyến xác định:

  • Asset sử dụng monitoring target nào
  • Collector nào thực hiện thu thập

Định tuyến là:

  • Dựa trên chính sách
  • Nhận biết theo site
  • Độc lập nhà cung cấp

Target và collector được chọn trước khi bất kỳ lời gọi provider nào được thực thi.

6. Quy trình Vận hành

Thu thập Alert

Alert được thu thập từ các hệ thống giám sát, chuẩn hóa, lưu cache và đánh giá theo quy tắc bảo trì.

Suppress Bảo trì

Các cửa sổ bảo trì đang hoạt động sẽ suppress alert, chặn tạo incident và ticket, đồng thời giữ lịch sử audit.

Tương quan Alert

Alert được gom nhóm thành incident bằng luật, thao tác người vận hành và các engine tương quan trong tương lai.

Vòng đời Incident

Incident theo dõi:

  • Trạng thái và mức độ nghiêm trọng
  • Alert liên quan
  • Ticket liên kết
  • Lịch sử hoạt động

Incident là đơn vị trung tâm của vận hành con người.

Tích hợp Ticket

Ticket được tạo từ incident và đồng bộ với các hệ thống ITSM bên ngoài.

Ảnh hưởng Topology & Geo

Topology và bản đồ địa lý cung cấp nhận thức tình huống và hỗ trợ phân tích ảnh hưởng và quy trình tìm nguyên nhân gốc.

7. Hiệu năng & Khả năng Mở rộng

IIMS sử dụng các mô hình đọc cache cho:

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

Các worker nền làm mới cache để đảm bảo hiệu năng UI nhanh ở quy mô lớn.

8. Khả năng Mở rộng

Kiến trúc hỗ trợ:

  • Nhiều nhà cung cấp giám sát
  • Nhiều hệ thống ticket
  • Triển khai đa tenant
  • Tự động hóa và engine trí tuệ nâng cao

Nhà cung cấp và khả năng mới có thể được thêm vào mà không phá vỡ quy trình hiện tại.

9. Trạng thái Triển khai (Thông tin)

Phần này mô tả trạng thái triển khai hiện tại và lộ trình phát triển. Nó không thay đổi thiết kế mục tiêu phía trên.

9.1 Triển khai Hiện tại (Bản giao đầu tiên)

Triển khai hiện tại cung cấp:

  • Phân cấp site và asset đầy đủ
  • Hiển thị vị trí địa lý và topology
  • Tích hợp giám sát Zabbix
  • Tích hợp ticket Zammad
  • Thu thập alert và suppress bảo trì
  • Quản lý incident thủ công và ít luật
  • Dashboard cache và tổng hợp vận hành

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

9.2 Lộ trình & Năng lực Tiếp theo

Các khả năng tương lai bao gồm:

  • Tương quan alert tự động và tạo incident
  • Lan truyền ảnh hưởng dựa trên topology và suy luận nguyên nhân gốc
  • Bộ đếm SLA, phân công và quy trình leo thang
  • Giám sát đa nhà cung cấp (Zabbix + Prometheus)
  • Failover định tuyến tự động và cân bằng theo dung lượng
  • Dashboard thời gian thực và không gian làm việc cộng tác cho incident

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

10. Tổng kết

Tài liệu này mô tả kiến trúc mục tiêu và thiết kế vận hành của IIMS như một nền tảng dài hạn.

Triển khai hiện tại đại diện cho một bước giao gia tăng của thiết kế này, tập trung vào tính ổn định và khả năng quan sát hợp nhất.

Các cải tiến trong tương lai sẽ dần phát triển IIMS thành một nền tảng vận hành thông minh, tự động trong khi vẫn giữ liên tục kiến trúc và an toàn vận hành.