SLA Vận hành Server Cloud — Quy trình & Thời gian Xử lý Sự cố giữa 4 bên

⚠️ Lưu ý quan trọng trước khi đọc: các con số thời gian trong tài liệu này là đề xuất nội bộ để thống nhất trong họp. Con số chính thức cam kết với khách hàng chỉ chốt được sau khi nhận văn bản SLA + scope hỗ trợ của CMC (đang chờ, hạn 14/6). Nguyên tắc bất di bất dịch: SLA mình hứa với khách không thể cao hơn nền CMC cam kết + năng lực trực của mình.

1. Mô hình 4 bên — ai là ai, ai chịu trách nhiệm tầng nào

Bên	Vai trò	Chịu trách nhiệm tầng
CMC	Nhà cung cấp cloud (CKE, máy ảo, mạng, lưu trữ)	Hạ tầng lõi: phần cứng, control plane, mạng, cân bằng tải — giữ "hạ tầng sống" 24/7
Mr. Thái	Vận hành hạ tầng & nền tảng (in-house)	Nền tảng: cụm K8s, giám sát, cảnh báo, backup/khôi phục, leo thang sang CMC
Demepro	Chủ sản phẩm — dev + CSKH	Ứng dụng & khách hàng: tiếp nhận sự cố từ khách, phân loại, fix lỗi ứng dụng, thông báo khách
Khách hàng	Ban quản lý tòa nhà / cư dân sử dụng hệ thống	Báo sự cố qua kênh thống nhất, cung cấp thông tin, xác nhận đã khắc phục

Chuỗi trách nhiệm khi có sự cố

KHÁCH HÀNGBQL tòa nhà / cư dân

▼báo sự cố qua kênh thống nhất

DEMEPRO (CSKH)tiếp nhận · phân loại P1/P2/P3 · một đầu mối với khách

▼chẩn đoán: lỗi ứng dụng hay hạ tầng?

DEV DEMEPROlỗi ỨNG DỤNG: bug, nghiệp vụ, dữ liệu app

MR. THÁI (VẬN HÀNH)lỗi HẠ TẦNG / NỀN TẢNG: cụm K8s, máy, mạng, DB, lưu trữ

▼lỗi tầng lõi do CMC quản → leo thang

CMCtheo SLA hợp đồng cloud

Hai tầng cam kết — đừng lẫn:

CMC cam kết với mình (SLA hạ tầng, theo hợp đồng cloud): giữ phần cứng / máy ảo / mạng / control plane sống, thay phần cứng hỏng, phản hồi khi mình báo lỗi. CMC nói rõ: "chỉ dựng, không check sự cố" — họ KHÔNG theo dõi / xử lý sự cố ứng dụng của mình.
Mình cam kết với khách (SLA dịch vụ): dựng TRÊN nền CMC + giám sát + quy trình trực + năng lực fix của dev.

2. Mô hình SLA 3 tier — phân loại sự cố

Mục đích: chốt trước khi có chuyện, để lúc nóng không cãi nặng – nhẹ. Tiêu chí phân loại dựa trên tác động tới khách hàng, không dựa trên độ khó kỹ thuật.

Tier	Định nghĩa (ngôn ngữ kinh doanh)	Tiêu chí xếp loại
P1 Sự cố nghiêm trọng	Khách không dùng được hệ thống, hoặc có nguy cơ mất / lộ dữ liệu	Toàn bộ hoặc đa số người dùng bị ảnh hưởng; không có cách né; hoặc liên quan dữ liệu cá nhân cư dân
P2 Sự cố trung bình	Hệ vẫn chạy nhưng một chức năng quan trọng hỏng hoặc chậm bất thường	Một nhóm người dùng / một nghiệp vụ chính bị ảnh hưởng; có thể có cách né tạm
P3 Yêu cầu hỗ trợ thông thường	Lỗi nhỏ có cách né, câu hỏi sử dụng, yêu cầu thay đổi nhỏ	Không ảnh hưởng vận hành hằng ngày

Ví dụ điển hình cho từng tier

Tier	Ví dụ tầng hạ tầng (Thái / CMC)	Ví dụ tầng ứng dụng (Demepro)
P1	Cả cụm sập, không truy cập được hệ thống · CSDL chính chết · mất kết nối mạng tới cloud · sự cố nghi lộ/mất dữ liệu cư dân	Toàn bộ người dùng không đăng nhập được · không thu được phí đúng kỳ chốt sổ · dữ liệu hiển thị sai hàng loạt
P2	Một dịch vụ chạy yếu, phản hồi chậm bất thường · hết dung lượng sắp tới ngưỡng · backup đêm thất bại	Không gửi được thông báo đẩy tới cư dân · một phân hệ (vd: đặt tiện ích) lỗi · xuất báo cáo sai
P3	Cảnh báo log mức thấp · một tác vụ nền chạy trễ	Lỗi hiển thị giao diện · hỏi cách dùng tính năng · đề nghị chỉnh sửa nhỏ

Quy tắc khi không chắc tier: xếp tier cao hơn rồi hạ sau — hạ tier dễ, nâng tier giữa chừng gây mất thời gian vàng.

3. Thời gian phản hồi, thời gian xử lý, trách nhiệm từng bên

Tách bạch 2 khái niệm — điểm hay bị gộp nhầm:

Thời gian phản hồi (response): từ lúc tiếp nhận tới lúc có người vào việc và xác nhận với người báo — cái này cam kết cứng được.
Thời gian xử lý (resolution): tới lúc khắc phục xong — phụ thuộc bản chất sự cố và nền CMC, nên cam kết dưới dạng mục tiêu (target) + nhịp cập nhật tiến độ, không phải con số cứng tuyệt đối.

Bảng cam kết đề xuất (chốt số chính thức sau khi có văn bản CMC)

Tier	Thời gian phản hồi	Mục tiêu xử lý	Nhịp cập nhật cho khách	Khung trực
P1	≤ 30 phút, 24/7 — vào việc ngay, ưu tiên tuyệt đối, lập "phòng chỉ huy" tới khi xong	Khôi phục dịch vụ trong vòng 4 giờ (mục tiêu); khôi phục dữ liệu từ backup tính bằng phút – giờ (số chính xác đo ở diễn tập 14/6)	Mỗi 30 – 60 phút cho tới khi xong + báo cáo nguyên nhân sau 48h	24/7
P2	≤ 4 giờ làm việc	Có giải pháp tạm trong 1 ngày làm việc; fix triệt để theo kế hoạch (≤ 1 tuần)	Mỗi ngày làm việc	Giờ hành chính (mở rộng nếu cần)
P3	≤ 1 ngày làm việc	Đưa vào kế hoạch sprint / bảo trì, hẹn ngày cụ thể	Khi có thay đổi trạng thái	Giờ hành chính

Ma trận trách nhiệm theo tier

Việc	Khách hàng	Demepro (CSKH/Dev)	Mr. Thái	CMC
Báo sự cố, cung cấp thông tin (ảnh chụp, thời điểm, thao tác)	✅ Thực hiện	Hướng dẫn	—	—
Tiếp nhận, phân loại tier, mở ticket	—	✅ Chủ trì	Tư vấn xếp tier nếu nghi hạ tầng	—
Chẩn đoán: lỗi app hay hạ tầng?	—	✅ Bước đầu	✅ Phối hợp (nhìn giám sát/cảnh báo)	—
Xử lý lỗi ứng dụng (bug, nghiệp vụ)	—	✅ Chủ trì (dev)	Hỗ trợ log, rollback bản deploy	—
Xử lý lỗi nền tảng (K8s, DB, lưu trữ, mạng trong cụm)	—	Phối hợp test lại	✅ Chủ trì	Hỗ trợ khi liên quan tầng lõi
Xử lý lỗi hạ tầng lõi (phần cứng, control plane, mạng cloud)	—	—	✅ Leo thang + bám sát	✅ Chủ trì (theo SLA hợp đồng)
Khôi phục dữ liệu từ backup	—	Xác nhận dữ liệu đúng	✅ Chủ trì	—
Thông báo & cập nhật tiến độ cho khách	—	✅ Chủ trì (một đầu mối duy nhất)	Cung cấp thông tin kỹ thuật	—
Xác nhận đã khắc phục, đóng ticket	✅ Xác nhận	✅ Đóng	—	—
Báo cáo nguyên nhân sau sự cố P1 (post-mortem 48h)	Nhận báo cáo	✅ Phần app	✅ Phần hạ tầng	Cung cấp RCA nếu lỗi tầng lõi

Nguyên tắc vận hành kèm theo:

Một đầu mối với khách — khách chỉ làm việc với Demepro; không để khách phải tự gọi nhiều nơi.
Ba tầng phòng thủ trước khi tới con người: phần lớn sự cố nhỏ hệ tự khởi động lại (không cần người) → giám sát bắn cảnh báo Telegram trước khi khách kêu → con người + quy trình + đường lui < 5 phút.
Sự cố liên quan dữ liệu cá nhân cư dân (nghi lộ/mất) = P1 đặc biệt: kích hoạt đồng thời quy trình kỹ thuật + quy trình thông báo riêng (xem mục 4).

4. Căn cứ của SLA — pháp lý, hợp đồng hay nội bộ?

Trả lời thẳng: cả ba, mỗi lớp một vai trò khác nhau. Hiện tại SLA này là tiêu chuẩn vận hành nội bộ; lộ trình nâng lên cam kết hợp đồng ở dưới.

Lớp căn cứ	Nội dung	Trạng thái
1. Pháp lý (bắt buộc, không thương lượng)	Dữ liệu cư dân = dữ liệu cá nhân — thuộc nhóm dữ liệu phải bảo vệ ở mức cao nhất. Vì vậy mọi sự cố lộ / mất dữ liệu luôn xếp P1 kèm quy trình xử lý & thông báo riêng, bất kể quy mô ảnh hưởng.	✅ Áp dụng thường trực
2. Hợp đồng (ràng buộc thương mại)	(a) Hợp đồng CMC ↔ mình: uptime hạ tầng, thời gian phản hồi của CMC, phạm vi hỗ trợ — đây là "trần" cho mọi cam kết phía dưới. (b) Hợp đồng mình ↔ khách: hiện tại chưa có điều khoản SLA → cần thống nhất có đưa vào phụ lục hợp đồng hay không.	⏳ (a) chờ văn bản CMC (hạn 14/6) · (b) cần rà hợp đồng khách hiện hữu
3. Tiêu chuẩn vận hành nội bộ	Bảng P1/P2/P3, thời gian phản hồi, quy trình trực, runbook — tài liệu này. Tham chiếu thông lệ ngành (mô hình severity-tier chuẩn của ngành vận hành dịch vụ).	✅ Dự thảo — chính là tài liệu này

Lộ trình nâng cấp căn cứ

BÂY GIỜ (T6/2026)

Tiêu chuẩn nội bộ — đề xuất, dự thảo (tài liệu này)

SAU KHI CÓ VĂN BẢN CMC

Chốt số chính thức — đối chiếu "trần" CMC, điều chỉnh bảng cam kết

SAU HYPERCARE (23/8)

Cân nhắc đưa vào phụ lục hợp đồng khách — khi đã có số liệu vận hành thật

Lý do không vội đưa vào hợp đồng khách ngay: chưa có văn bản CMC + chưa có số liệu vận hành thực tế trên môi trường mới → cam kết hợp đồng lúc này là hứa khi chưa đo. Giai đoạn hypercare (27/7 – 23/8) chính là lúc đo năng lực thật để cam kết có cơ sở.