MTTR là gì? Cách tính MTTR và cách dùng trong production

MTTR thường được hiểu là Mean Time To Recovery hoặc Mean Time To Repair, tuỳ team và tuỳ ngữ cảnh. Điểm quan trọng nhất là bạn phải định nghĩa rõ MTTR của bạn đang đo cái gì, start time là lúc nào và end time là lúc nào, rồi giữ nhất quán trong production.

Ví dụ: Trong 1 tuần có 3 incident làm service bị user impact. Thời gian từ lúc incident bắt đầu đến lúc service recovery lần lượt là 10 phút, 20 phút, 30 phút.
MTTR theo Mean Time To Recovery = (10 + 20 + 30) / 3 = 20 phút.

MTTR phản ánh tốc độ mà team đưa service từ trạng thái user impact về trạng thái hoạt động bình thường.

MTTR cho biết điều gì?

MTTR giúp trả lời nhanh các câu hỏi cơ bản:

Team đang mất trung bình bao lâu để service recovery sau incident?
Sau khi deploy hoặc thay đổi kiến trúc, time to recover có xấu đi không?
Incident response có đang bị bottleneck ở triage, remediation, hay coordination không?

Tuy nhiên, cần lưu ý: MTTR là số trung bình, nên có thể che mất incident lớn nếu bạn không breakdown theo severity hoặc theo service.

MTTR khác MTTD và MTTA ra sao?

MTTR thường được đọc cùng các chỉ số sau:

MTTD: trung bình mất bao lâu để detect incident.
MTTA: trung bình mất bao lâu để acknowledge page.
MTTR: trung bình mất bao lâu để service recovery.

Một hệ thống có MTTR tốt nhưng MTTD cao thì user impact vẫn dài vì detect chậm. Một hệ thống có MTTD tốt nhưng MTTR cao thì detect nhanh nhưng recovery chậm.

MTTR có mấy nghĩa và vì sao dễ gây hiểu sai?

MTTR hay gây hiểu sai vì chữ R thường bị dùng theo nhiều nghĩa. Các cách dùng phổ biến:

Mean Time To Recovery hoặc Mean Time To Restore: tập trung vào service recovery từ góc nhìn user.
Mean Time To Repair hoặc Mean Time To Resolve: tập trung vào repair hoặc resolve root cause.

Gợi ý thực tế: nếu mục tiêu chính là giảm user impact, bạn nên ưu tiên định nghĩa MTTR theo Mean Time To Recovery hoặc Mean Time To Restore và ghi rõ định nghĩa trong dashboard.

Cách hiểu MTTR trong production

Một số nguyên tắc cơ bản khi đọc MTTR:

Nên xem MTTR theo service và theo severity, không chỉ nhìn một con số tổng.
Nên breakdown theo incident type để biết bottleneck nằm ở đâu, ví dụ dependency outage, deploy regression, capacity issue.
Luôn đọc MTTR kèm Latency và Error rate để tránh kết luận sai.

Ví dụ:

MTTR giảm theo thời gian: incident response đang hiệu quả hơn, runbook và automation có tác dụng.
MTTR tăng sau một thay đổi: có thể on-call thiếu context, thiếu runbook, hoặc rollback path không rõ.
MTTR tổng ổn nhưng một service có MTTR rất cao: service đó có bottleneck riêng, cần ưu tiên reliability work.

MTTR thường được đo ở đâu?

Tuỳ mục tiêu, MTTR có thể được tính từ các mốc khác nhau, nhưng phải nhất quán:

Incident start: lúc user impact bắt đầu, hoặc lúc signal đầu tiên vượt ngưỡng paging.
Service recovery: lúc user impact kết thúc và SLI về mức bình thường.

Trong vận hành thực tế, nên chọn 1-2 cách tính MTTR chính, ghi rõ định nghĩa trong dashboard và dùng cùng định nghĩa đó cho postmortem.

Những yếu tố có thể làm MTTR bị lệch

Một số nguyên nhân khiến MTTR nhìn không đúng thực tế:

Start time và end time không nhất quán giữa các incident.
Gộp planned maintenance vào incident recovery.
Chỉ tính incident có ticket, bỏ sót incident nhỏ hoặc silent failure.
Gộp nhiều service khác nhau vào một MTTR tổng, làm bạn khó thấy service nào là nguyên nhân chính.
Retry làm user impact giảm nhưng root cause vẫn còn, khiến recovery time nhìn tốt hơn trong khi risk vẫn tồn tại.

Vì vậy, MTTR nên được breakdown theo service, severity, incident type và có tiêu chuẩn ghi timeline rõ ràng trong postmortem.

MTTR được dùng để làm gì trong DevOps?

Ở mức cơ bản, MTTR thường được dùng cho:

Đánh giá hiệu quả incident response và runbook quality.
Ưu tiên automation, ví dụ auto rollback, traffic shift, circuit breaker, feature flag kill switch.
Kết nối với SLO và error budget để quyết định ưu tiên reliability work so với release velocity.
Theo dõi chất lượng vận hành theo thời gian, đặc biệt sau thay đổi lớn như migration hoặc re-architecture.

Kết luận

MTTR là chỉ số nền tảng để hiểu tốc độ service recovery sau incident.

Để MTTR có ý nghĩa, bạn cần định nghĩa rõ MTTR đang đo theo Mean Time To Recovery hay Mean Time To Repair, và giữ nhất quán start time và end time trong production. Khi đọc MTTR, hãy breakdown theo service và severity, và đọc kèm Latency, Error rate để ra quyết định đúng.