Nếu team bạn đã từng triển khai một bản cập nhật rồi ngay lập tức tự hỏi liệu mình có đang thực sự nhanh hơn hay chỉ đang bận rộn hơn — DORA Metrics chính là câu trả lời. Theo dõi bốn chỉ số này giúp bất kỳ team DevOps nào có một cách cụ thể, có thể lặp lại để đo lường cải tiến liên tục. Phần khó không phải là thu thập con số. Mà là tìm ra cách thu thập và hành động dựa trên chúng mà không làm nặng thêm backlog vốn đã đầy ắp.
DORA (DevOps Research and Assessment) đã xác định bốn chỉ số có khả năng dự đoán nhất quán hiệu suất phân phối phần mềm trên hàng nghìn tổ chức:
- Deployment Frequency — Tần suất code được đưa lên production
- Lead Time for Changes — Thời gian từ commit đầu tiên đến khi deploy lên production
- Mean Time to Recovery (MTTR) — Tốc độ phục hồi sau sự cố production
- Change Failure Rate (CFR) — Tỷ lệ phần trăm các lần deploy gây ra sự cố
Các team hàng đầu deploy nhiều lần mỗi ngày, với lead time dưới một giờ và thời gian phục hồi dưới một giờ, giữ tỷ lệ thất bại dưới 15%. Hầu hết các team nằm ở đâu đó giữa mức “trung bình” (deploy hàng tuần, lead time tính theo ngày) và mức “cao”. Phương pháp nào để đo lường những chỉ số này thực sự phù hợp với team của bạn hiện tại? Điều đó phụ thuộc vào quy mô, công cụ và khả năng chấp nhận chi phí thiết lập của bạn.
Ba Cách Tiếp Cận để Đo Lường DORA Metrics
Cách 1: Theo Dõi Thủ Công bằng Bảng Tính
Ít cản trở nhất, không tốn chi phí công cụ. Team của bạn ghi lại từng lần deploy lên production, ghi nhận thời gian bắt đầu và kết thúc sự cố, và liên kết các lần deploy với phạm vi commit trong một bảng tính dùng chung. Bạn tính toán bốn chỉ số theo cách thủ công mỗi sprint hoặc mỗi quý trong buổi retrospective. Không cần tự động hóa — chỉ cần kỷ luật nhất quán từ mọi người liên quan.
Cách 2: Script trong CI/CD Pipeline
Tích hợp vào các pipeline hiện có của bạn (GitHub Actions, GitLab CI, Jenkins) để phát ra các sự kiện có cấu trúc tại mỗi lần deploy. Một lần deploy thành công kích hoạt một script ghi lại timestamp và commit SHA. Một log sự cố riêng — được cập nhật bởi PagerDuty webhooks hoặc nhập thủ công — theo dõi MTTR. Bạn tổng hợp bằng các script nhẹ và tùy chọn đẩy metrics lên Grafana hoặc Datadog.
Cách 3: Nền Tảng DORA Chuyên Dụng
Các công cụ như Sleuth, LinearB hoặc Faros AI kết nối trực tiếp với GitHub hoặc GitLab, các công cụ deploy của bạn (Argo CD, Heroku, ECS), và các hệ thống theo dõi sự cố (PagerDuty, OpsGenie). Cả bốn chỉ số DORA được tính tự động với dashboard xu hướng mà không cần viết script. Sleuth cung cấp gói miễn phí cho team nhỏ; LinearB và Faros AI tính giá theo số lượng developer.
Ưu và Nhược Điểm của Từng Cách
Theo Dõi Thủ Công
- ✅ Không tốn chi phí thiết lập, hoạt động ngay từ ngày đầu
- ✅ Không phụ thuộc công cụ hay mối quan hệ với nhà cung cấp
- ❌ Không mở rộng được khi team vượt quá năm hoặc sáu người
- ❌ Chất lượng dữ liệu phụ thuộc hoàn toàn vào kỷ luật của team
- ❌ Không có khả năng theo dõi thời gian thực — bạn chỉ thấy con số khi ai đó cập nhật bảng tính
Script trong CI/CD Pipeline
- ✅ Thu thập dữ liệu tự động, nhất quán
- ✅ Toàn quyền kiểm soát định nghĩa “deploy lên production”
- ✅ Tích hợp với các dashboard mà team đã dùng
- ❌ Cần đầu tư vài giờ thiết lập ban đầu
- ❌ MTTR vẫn cần một hook quản lý sự cố riêng
Nền Tảng Chuyên Dụng
- ✅ Thiết lập tối thiểu, dashboard phong phú sẵn dùng ngay
- ✅ Tự động liên kết các lần deploy với sự cố tương ứng
- ❌ Phụ thuộc nhà cung cấp và chi phí theo đầu người khi mở rộng
- ❌ Kém linh hoạt hơn với các workflow deploy phi tiêu chuẩn
Cách Thiết Lập Khuyến Nghị
Với team từ 2–10 kỹ sư mới bắt đầu: chọn cách tiếp cận CI/CD pipeline. Cách này đủ nhẹ để thiết lập trong một buổi chiều, tránh phải đăng ký dịch vụ SaaS mới, và cho bạn dữ liệu tự động chính xác mà bạn thực sự sở hữu. Bắt đầu với Deployment Frequency và Lead Time — đây là hai chỉ số dễ tự động hóa nhất và ngay lập tức cho thấy liệu quy trình của bạn đang đi đúng hướng hay không.
Khi có từ 15 kỹ sư trở lên, hoặc nếu bạn đã dùng PagerDuty hay OpsGenie để quản lý sự cố, hãy xem xét Sleuth (có gói miễn phí) hoặc LinearB. Thời gian tiết kiệm được từ việc không phải liên kết thủ công các lần deploy và sự cố thường đủ để hoàn vốn cho subscription trong tháng đầu tiên.
Hướng Dẫn Triển Khai
1. Deployment Frequency — Tag Mỗi Lần Deploy Lên Production
Tạo một git tag có timestamp tại mỗi lần deploy lên production trong pipeline của bạn. Đếm các tag đó trong một khoảng thời gian trượt sẽ cho bạn deployment frequency mà không cần thêm công cụ hay sự mơ hồ nào.
# Thêm đoạn này vào deploy job trong CI/CD (GitHub Actions, GitLab CI, v.v.)
git tag "deploy-prod-$(date +%Y%m%d-%H%M%S)"
git push origin --tags
# Đếm số lần deploy lên production trong 30 ngày qua (chạy local hoặc trong cron job)
CUTOFF=$(date -d '30 days ago' +%Y%m%d 2>/dev/null || date -v-30d +%Y%m%d)
git tag --list 'deploy-prod-*' | while read tag; do
tag_date=$(echo "$tag" | grep -oP '\d{8}')
[[ "$tag_date" -ge "$CUTOFF" ]] && echo "$tag"
done | wc -l2. Lead Time for Changes — Từ Commit Đến Production
Lead time đo khoảng cách giữa thời điểm developer push một commit và khi nó đến được production. Script Python này tính lead time trung bình giữa hai deploy tag liên tiếp. Truyền prev_deploy_tag để xác định phạm vi commit chính xác; bỏ qua nó thì script sẽ dùng 30 commit cuối của tag đó.
import subprocess
import datetime
def calculate_lead_time(deploy_tag: str, prev_deploy_tag: str = None) -> float:
"""Trả về lead time trung bình tính bằng giờ cho các commit trong một lần deploy."""
deploy_ts = subprocess.run(
["git", "log", "-1", "--format=%aI", deploy_tag],
capture_output=True, text=True
).stdout.strip()
deploy_time = datetime.datetime.fromisoformat(deploy_ts)
if prev_deploy_tag:
commit_range = f"{prev_deploy_tag}..{deploy_tag}"
else:
commit_range = f"{deploy_tag}~30..{deploy_tag}"
commits = subprocess.run(
["git", "log", commit_range,
"--first-parent", "--format=%aI"],
capture_output=True, text=True
).stdout.strip().split('\n')
durations = []
for ts in commits:
if not ts:
continue
commit_time = datetime.datetime.fromisoformat(ts)
hours = (deploy_time - commit_time).total_seconds() / 3600
durations.append(hours)
return sum(durations) / len(durations) if durations else 0.0
tag = "deploy-prod-20260601-143000"
prev_tag = "deploy-prod-20260531-110000"
print(f"Lead time cho {tag}: {calculate_lead_time(tag, prev_tag):.1f} giờ")3. MTTR — Ghi Log và Tính Thời Gian Phục Hồi
Duy trì một log JSON đơn giản về các sự cố. Mỗi mục ghi lại thời điểm sự cố bắt đầu và thời điểm được giải quyết. Kỹ sư trực ca sẽ điền timestamp resolved_at sau khi sự cố được xử lý xong.
[
{
"id": "INC-042",
"started_at": "2026-05-20T09:15:00",
"resolved_at": "2026-05-20T10:02:00",
"triggered_by_deploy": "deploy-prod-20260520-091000"
}
]import json
from datetime import datetime
def calculate_mttr(incidents_file: str) -> float:
"""Trả về mean time to recovery tính bằng phút."""
with open(incidents_file) as f:
incidents = json.load(f)
times = [
(datetime.fromisoformat(inc["resolved_at"]) -
datetime.fromisoformat(inc["started_at"])).total_seconds() / 60
for inc in incidents
]
return sum(times) / len(times) if times else 0.0
print(f"MTTR: {calculate_mttr('incidents.json'):.0f} phút")4. Change Failure Rate — Tích Hợp với GitHub Actions
Theo dõi tự động các lần deploy thất bại qua workflow events. Định nghĩa rõ “thất bại” ngay từ đầu: một lần deploy cần rollback, gây ra sự cố, hoặc buộc phải có hotfix trong vòng một giờ thì được tính. Sự mơ hồ ở đây sẽ làm lệch số liệu của bạn.
# .github/workflows/record-deploy.yml
name: Ghi Lại Deployment Metrics
on:
workflow_run:
workflows: ["Deploy to Production"]
types: [completed]
jobs:
record:
runs-on: ubuntu-latest
steps:
- name: Ghi lại kết quả deploy
run: |
STATUS="${{ github.event.workflow_run.conclusion }}"
SHA="${{ github.event.workflow_run.head_sha }}"
TIMESTAMP=$(date -u +%Y-%m-%dT%H:%M:%SZ)
echo "${TIMESTAMP},${STATUS},${SHA}" >> deployments.csv
- name: Tính Change Failure Rate
run: |
TOTAL=$(wc -l < deployments.csv)
FAILED=$(grep -c ",failure," deployments.csv || true)
echo "Tổng số lần deploy: $TOTAL"
echo "Thất bại: $FAILED"
awk "BEGIN {printf \"Change Failure Rate: %.1f%%\\n\", $FAILED * 100 / $TOTAL}"Lưu ý: deployments.csv được ghi vào filesystem tạm thời của runner và sẽ không tồn tại giữa các lần chạy workflow. Để theo dõi lịch sử đáng tin cậy, hãy upload nó như một workflow artifact sau mỗi lần chạy, hoặc ghi dữ liệu vào một store bên ngoài như S3 bucket, bảng Postgres, hoặc file trong GitHub repository được commit lại sau mỗi lần chạy.
Biến Các Con Số Thành Hành Động
Thu thập metrics mới chỉ là một nửa công việc — hành động dựa trên chúng mới là chỗ hầu hết các team bị mắc kẹt. Chọn một chỉ số mỗi quý để tích cực cải thiện. Nếu lead time của bạn đang là ba ngày, đó chính là đòn bẩy của bạn. Xem xét thời gian review PR, thời lượng chạy test suite và các điểm nghẽn trong pipeline từng cái một thay vì cố gắng sửa tất cả cùng lúc.
DORA Metrics không cho bạn biết phải sửa gì — chúng cho bạn biết cần nhìn vào đâu. Change Failure Rate tăng lên sau khi team mở rộng chỉ ra các lỗ hổng trong quy trình onboarding và review code. Deployment Frequency đứng im trong một sprint mà cả team tuyên bố “đang tiến nhanh” là dấu hiệu có ma sát ẩn trong release pipeline của bạn.
Bắt đầu đơn giản: tag các lần deploy lên production của bạn ngay hôm nay, chạy script lead time trên năm release gần nhất, và bạn sẽ có hai trong bốn chỉ số hoạt động trước cuối tuần. Thêm việc ghi log sự cố vào sprint tiếp theo. Dù dữ liệu bạn thu thập trong 30 ngày đầu là gì, gần như chắc chắn sẽ lộ ra một hoặc hai cải tiến rõ ràng mà bạn chưa từng theo dõi trước đây — và đó chính xác là mục đích.
