Tài nguyên hệ thống
Baseline 3σ trượt trên CPU và bộ nhớ, tính riêng cho workload trong cluster và cho máy chủ từ xa — nên “bình thường” được học theo từng máy chứ không phải mặc định.
Vận hành hạ tầng tự chủ
Hạ tầng tự chẩn đoán — và chứng minh được nó đã làm gì.
Omni là nền tảng SRE đa tác tử cho Kubernetes và các đội máy chủ Linux. Hệ thống thu thập bằng chứng qua bốn lane chẩn đoán độc lập, suy luận bằng LLM chạy ngay tại chỗ, và chỉ thực thi khắc phục qua một đường đi có kiểm soát cùng sổ audit ký mã hoá.
4lane bằng chứng độc lập phía sau mỗi chẩn đoán
5mốc dự báo cho mỗi khuyến nghị, từ vài phút tới vài ngày
3mức tự chủ, từ chỉ quan sát tới thực thi có giám sát
6.700+kiểm thử tự động canh cửa control plane
Vấn đề
Cảnh báo thì rẻ. Hành động đúng và chịu trách nhiệm được thì không.
Phần lớn đội ngũ không thiếu giám sát. Thứ họ thiếu là một đường đi đáng tin từ một bức tường tín hiệu tới một quyết định mà ai đó dám ký tên vào.
- 01Tín hiệu không có nghĩa. CPU vọt, 5xx dồn dập và một unit chết là ba cảnh báo, không phải một sự cố. Việc nối chúng lại bị đẩy cho người trực, lúc 3 giờ sáng.
- 02Hiểu biết nằm trong đầu người. Runbook cũ đi. Kỹ sư nắm rõ topology thì nghỉ việc. Nhận một hệ thống mới đồng nghĩa xây lại toàn bộ hiểu biết đó bằng tay.
- 03Không ai tin tự động hoá. Nhiều đội đủ sức tự động hoá khắc phục nhưng vẫn từ chối, vì một thao tác sai còn tệ hơn một con người chậm — và vì sau đó không có gì chứng minh được tự động hoá đã thực sự làm gì.
- 04Môi trường tuân thủ không được đẩy dữ liệu ra ngoài. Tài chính và khu vực công không thể gửi telemetry production sang API mô hình của bên thứ ba.
Cách hoạt động
Bốn lane bằng chứng, một khuyến nghị có lập luận.
Mọi tín hiệu đi vào qua một lane có kiểu rõ ràng, với logic phát hiện riêng. Các lane độc lập với nhau, nên một chẩn đoán không bao giờ dựng trên một chỉ số nhiễu duy nhất.
Hỏng cứng
Một máy trạng thái ở tầng OS theo dõi unit, mount và trạng thái kernel. Các bất biến tất định quyết định thế nào là hỏng thật, trước khi hỏi tới bất kỳ mô hình nào.
HTTP ứng dụng
Probe phát hiện bùng log phân loại lưu lượng theo họ mã trạng thái — 5xx, 429, 401 — tách bài toán quá tải khỏi bài toán lạm dụng, và khỏi lỗi xác thực.
An ninh
Sự cố an ninh được nối thành chuỗi tấn công xuyên thực thể và thời gian, rồi dự báo tiếp — thay vì báo cáo như những sự kiện rời rạc.
agent từ xa
bộ thu thập chỉ-đọc trên đội máy Linux
nguồn cảnh báo
cluster · ứng dụng · an ninh
lane tri thức · lane chẩn đoán
quan sát thường nhật không bao giờ vào đường cảnh báo, và không gọi mô hình
truy hồi sự cố đã gặp
lần trước nhìn giống thế này thì đã xảy ra chuyện gì
suy luận bằng LLM tại chỗ
cái gì · ai · tại sao · khắc phục ra sao + dự báo năm mốc
CỔNG KIỂM SOÁT
fail-closed — không ghi được audit thì không hành động
khuyến nghị
người phê duyệt
thực thi
phản hồi kết quả
đánh giá lại, rồi học từ đó
Kiểm soát
Tự chủ có thể tắt được, và audit lại được sau khi việc đã xảy ra.
Omni được thiết kế cho người vận hành phải chịu trách nhiệm về hệ thống mà nó chạm vào. Mọi thuộc tính an toàn đều fail-closed: nếu đường ghi audit không khả dụng, hành động không xảy ra.
Tách đọc khỏi ghi
Đường suy luận là chỉ-đọc tuyệt đối. Mọi thay đổi đi qua một executor duy nhất, với danh sách công cụ được cho phép tường minh và cách ly theo namespace. Tầng suy luận không thể thay đổi cluster kể cả khi mô hình yêu cầu.
Sổ audit ký mã hoá
Quyết định, lệnh gửi đi, phê duyệt của người, thao tác bị chặn và các lần rollback đều được ghi vào chuỗi băm SHA-256 kèm chữ ký Ed25519 — thiết kế theo yêu cầu bằng chứng của SOX §404 và PCI-DSS v4.0.
Công tắc dừng tổng
Thực thi tự động mặc định tắt. Bật nó lên là một thay đổi cấu hình có chủ đích, theo từng khách hàng, và giá trị đang có hiệu lực quan sát được lúc chạy chứ không suy ra từ tài liệu.
| Mức | Hành vi | Dành cho |
|---|---|---|
| shadow | Chẩn đoán và dự báo, không hành động. Khuyến nghị được gửi tới người vận hành để chấm điểm. | Khách hàng mới; giai đoạn xây niềm tin và tạo dữ liệu đối chứng. |
| minimal | Thực thi một tập khắc phục hẹp và đảo ngược được; mọi thứ khác chuyển cho người. | Khách hàng đã có số liệu đo được về độ chính xác của khuyến nghị. |
| autonomous | Thực thi trong phạm vi chính sách, có snapshot trước khi thay đổi và có rollback, vẫn ghi audit đầy đủ. | Hệ thống đã ổn định và được hiểu rõ. |
Kỹ thuật
Async-first, hướng sự kiện, và chạy trọn vẹn được tại chỗ.
Suy luận chạy ngay tại chỗ, nên telemetry production không bao giờ rời khỏi ranh giới của khách hàng — đúng cái yêu cầu đã loại bỏ hầu hết phương án dùng mô hình đặt ở bên ngoài trong các ngành chịu quản lý.
- Control plane
- Python, asyncio xuyên suốt, FastAPI làm cổng vào
- Trục sự kiện
- Kafka — tách riêng topic bằng chứng, hành động và phản hồi
- Suy luận
- LLM chạy tại chỗ, không gọi mô hình bên ngoài
- Truy hồi
- Tìm kiếm vector trên sự cố cũ và playbook
- Lưu trữ
- PostgreSQL cho cấu hình và sổ cái; Redis cho đường nóng
- Đối tượng
- Workload Kubernetes cùng các máy Linux có gắn agent
- Agent biên
- Bộ thu thập chỉ-đọc, làm cứng chống chèn lệnh và rò rỉ dữ liệu
- Giao diện
- Portal cho nhà cung cấp và cho khách hàng, HTTP API, thông báo qua chat
Hiện trạng
Một hệ thống chạy thật trong môi trường lab, đang tiến tới pilot production.
Chúng tôi chọn nói thẳng thay vì nói quá. Dưới đây là những gì đã được kiểm chứng bằng cách chạy hệ thống, không phải những gì đang dự định.
ĐANG CHẠYToàn bộ pipeline chẩn đoán vận hành liên tục trên một cluster Kubernetes sống và một đội máy chủ Linux có gắn agent.
ĐANG CHẠYControl plane đa khách hàng với cấu hình riêng, cách ly và agent từ xa đã đăng ký.
ĐANG CHẠYSổ audit ký mã hoá, luồng phê duyệt bởi người, và portal cho nhà cung cấp lẫn khách hàng.
ĐANG CHẠYTự động khám phá topology hệ thống, tạo ra mô hình cập nhật liên tục cho từng môi trường khách hàng.
TIẾP THEOTriển khai trên cloud có quản lý — GKE cho control plane, Pub/Sub hoặc Kafka có quản lý cho trục sự kiện, Cloud SQL cho sổ cái, và suy luận tăng tốc cho khách hàng chấp nhận mô hình đặt ngoài.
TIẾP THEOPilot cùng đối tác thiết kế, với những đơn vị vận hành workload Kubernetes chịu quản lý.