Production đang cháy trong phát triển — định nghĩa, nguyên nhân và quy trình hành động

“Production đang cháy” nghĩa là gì và các loại sự cố

Cụm từ “production đang cháy” (mọi thứ sụp đổ) mô tả tình huống môi trường production hoạt động không chính xác và người dùng bị ảnh hưởng. Sự cố có thể biểu hiện dưới dạng không thể truy cập hoàn toàn (màn hình trắng, lỗi 502), không thể truy cập một phần (mô-đun thanh toán không hoạt động nhưng các chức năng khác khả dụng), hoặc suy giảm hiệu suất (tải cực kỳ chậm). Mức độ nghiêm trọng của sự cố được xác định bởi tỷ lệ người dùng bị ảnh hưởng và thời gian gián đoạn.

Theo Atlassian Statuspage (2025), thời gian chết trung bình cho các ứng dụng di động năm 2024 là 27 phút mỗi sự cố. Nguyên nhân phổ biến nhất: hồi quy mã sau khi triển khai (34%), sự cố nhà cung cấp đám mây (22%), vấn đề cơ sở dữ liệu (18%), lỗi cấu hình (15%) và tấn công DDoS (11%). Kết luận chính: hầu hết các sự cố do các thay đổi mà nhóm tự thực hiện gây ra, không phải do yếu tố bên ngoài.

Điều quan trọng là phân biệt giữa crash (ứng dụng sụp đổ phía máy khách) và sự cố backend (máy chủ không khả dụng). Crash thường được sửa bằng hotfix mã máy khách, trong khi sự cố backend cần thay đổi hạ tầng hoặc triển khai lại dịch vụ. Chỉ số giám sát: cho máy khách — tỷ lệ không có crash, cho máy chủ — tỷ lệ lỗi 5xx và độ trễ p95. APM (Giám sát Hiệu suất Ứng dụng) — Sentry, New Relic, Datadog — giúp xác định nhanh loại sự cố.

Mức độ nghiêm trọng: P0, P1, P2 và tiêu chí phân loại

Phân loại mức độ nghiêm trọng thống nhất là nền tảng của phản ứng nhanh. Nếu không có nó, nhóm sẽ lãng phí thời gian thảo luận “điều này khẩn cấp đến mức nào” thay vì hành động. Thang đo cổ điển: P0 (nghiêm trọng) — ứng dụng hoàn toàn không khả dụng hoặc dữ liệu người dùng bị rò rỉ, thời gian phản ứng — ngay lập tức; P1 (cao) — chức năng quan trọng không hoạt động cho 50%+ người dùng, thời gian phản ứng — 15 phút; P2 (trung bình) — chức năng không quan trọng không khả dụng cho một số người dùng, thời gian phản ứng — 1 giờ.

P0 yêu cầu leo thang ngay lập tức: kỹ sư trực ngắt bỏ mọi công việc hiện tại và tập trung vào sự cố. Nếu vấn đề không được giải quyết trong vòng 10 phút — trưởng nhóm kỹ thuật tham gia. Nếu sau 30 phút — leo thang đến quản lý kỹ thuật. Đối với sự cố P0, cho phép phá vỡ mọi quy trình: thực hiện hotfix mà không có đánh giá mã đầy đủ, triển khai trực tiếp lên production, bỏ qua các quy tắc bảo vệ nhánh. Ghi đè khẩn cấp phải được thỏa thuận trước ở cấp độ nhóm.

Bảng mức độ nghiêm trọng

Điều cực kỳ quan trọng là không được đánh giá thấp mức độ nghiêm trọng. Các sự cố P0 và P1 được phân loại là P2 dẫn đến phản ứng chậm trễ và tăng thời gian chết. Quy tắc: nếu nghi ngờ — đặt P0. Phân loại thừa tốt hơn phân loại thiếu: tổ chức thêm một cuộc họp còn hơn mất một giờ khôi phục.

10 phút đầu tiên: quy trình hành động khi có sự cố

Đồng hồ bắt đầu: từ thời điểm có cảnh báo hoặc tin nhắn từ người dùng. 10 phút đầu tiên là quan trọng nhất. Quy trình: 1) xác nhận vấn đề — đảm bảo vấn đề là thật (không phải báo động giả); 2) dừng chảy máu — giảm tác động ngay lập tức (rollback, feature toggle, chặn endpoint); 3) giao tiếp — viết trên kênh chung #incident trạng thái: điều gì đã xảy ra, mức độ nghiêm trọng, đang làm gì. 10 phút đầu tiên không được dùng để phân tích nguyên nhân gốc rễ.

Song song với việc dừng chảy máu, một kỹ sư bắt đầu chẩn đoán trong khi người kia phụ trách giao tiếp. Kênh giao tiếp: kênh Slack #incident (cho nhóm), trang trạng thái (cho người dùng), email/SMS leo thang (cho quản lý). Cứ 15 phút — cập nhật trạng thái với thông tin: biết được gì, đang làm gì, thời gian khôi phục dự kiến. Trang trạng thái (StatusPage, Statuspal) hiển thị thời gian hoạt động và lịch sử sự cố cho người dùng bên ngoài.

Cách dừng chảy máu: rollback, feature toggle và hotfix

Quy tắc đầu tiên và quan trọng nhất: đừng cố gắng sửa vấn đề trên production. Nếu bản phát hành mới gây ra sự cố — rollback về phiên bản ổn định trước đó. Nếu sự cố do một tính năng cụ thể nằm sau feature toggle gây ra — chỉ cần tắt toggle. Nếu cả rollback lẫn toggle đều không khả dụng — áp dụng hotfix với sự khác biệt tối thiểu. Rollback là lựa chọn an toàn nhất vì nó quay lại trạng thái đã hoạt động.

Feature toggle (còn gọi là feature flag) là công cụ mạnh mẽ để dừng chảy máu mà không cần triển khai. Nếu mô-đun thanh toán bị lỗi nhưng đã tắt qua toggle — người dùng chỉ đơn giản không thấy nút thanh toán thay vì nhận màn hình lỗi. Toggle không yêu cầu build, không yêu cầu đánh giá cửa hàng và có hiệu lực trong vài giây. Mỗi tính năng quan trọng nên được đặt sau một feature toggle với khả năng tắt ở cấp máy chủ (cấu hình từ xa). Feature flag — tuyến phòng thủ đầu tiên.

Nếu rollback không thể thực hiện (ví dụ, do di chuyển cơ sở dữ liệu không thể đảo ngược) và không có toggle — biện pháp cuối cùng: hotfix với thay đổi tối thiểu. Hotfix được tạo từ thẻ phát hành mới nhất, chỉ chứa các dòng cần thiết để khắc phục sự cố và trải qua triển khai nhanh (xem bài viết “Hotfix — Sửa lỗi khẩn cấp”). Quy tắc vàng: sau khi ổn định, luôn thực hiện phân tích nguyên nhân gốc rễ, ngay cả khi nguyên nhân có vẻ hiển nhiên.

Chẩn đoán nguyên nhân: log, chỉ số và cảnh báo

Sau khi dừng chảy máu (hoặc song song, nếu số lượng kỹ sư cho phép), bắt đầu chẩn đoán. Nguồn đầu tiên là log. Ghi log tập trung (ELK, Grafana Loki, Datadog Logs) cho phép tìm lỗi theo dấu thời gian, ID người dùng hoặc ID yêu cầu. Quan trọng: log phải được cấu trúc (JSON) để grep hoạt động nhanh. Ghi log cấu trúc là yêu cầu bắt buộc đối với tất cả các dịch vụ.

Nguồn thứ hai là các chỉ số. Grafana, Datadog, New Relic cho thấy đỉnh lỗi xảy ra khi nào, trên endpoint nào và với mã trạng thái nào. So sánh các chỉ số trước và sau khi triển khai giúp xác định vấn đề ở một dịch vụ hoặc endpoint cụ thể. Chỉ số RED (Rate, Errors, Duration) — tiêu chuẩn giám sát microservice.

Nguồn thứ ba là theo dõi phân tán (distributed tracing). Jaeger, Zipkin, Datadog APM hiển thị đường đi của yêu cầu qua các microservice và xác định chính xác nơi xảy ra độ trễ hoặc lỗi. Theo dõi đặc biệt hữu ích trong các sự cố tầng, khi một lỗi ở một dịch vụ gây ra lỗi ở tất cả các dịch vụ phụ thuộc. ID theo dõi phải được truyền từ máy khách đến tất cả các dịch vụ backend.

# Ví dụ chẩn đoán nhanh bằng kubectl và log
# Liệt kê pod có lỗi
kubectl get pods --field-selector=status.phase!=Running

# Kiểm tra log của pod bị crash
kubectl logs --previous pod/auth-service-7f4b9c5d6-abc12

# Tìm lỗi trong dịch vụ 30 phút qua
kubectl logs deployment/api-gateway --since=30m
  | grep "5[0-9][0-9]" | head -50

Quan trọng: không cố gắng chẩn đoán nguyên nhân trước khi dừng chảy máu. Nếu 50% người dùng thấy crash — đầu tiên rollback, sau đó điều tra. Ngoại lệ: nếu rollback mất nhiều thời gian hơn hotfix trực tiếp (ví dụ, do không tương thích dữ liệu). Trong trường hợp này, áp dụng hotfix ngay lập tức và thực hiện post-mortem sau khi ổn định. Chẩn đoán trước khi sửa là mẫu nguy hiểm làm tăng thời gian chết.

Post-mortem: cách phân tích sự cố mà không đổ lỗi

Post-mortem (cũng được gọi là đánh giá sự cố) là phân tích có cấu trúc của sự cố được thực hiện sau 24–72 giờ kể từ khi giải quyết. Mục đích: hiểu tại sao sự cố xảy ra, tại sao giám sát và kiểm thử không phát hiện trước khi lên production, và cần thay đổi gì trong quy trình để ngăn ngừa tái diễn. Văn hóa không đổ lỗi là nguyên tắc cơ bản: post-mortem thảo luận về quy trình, công cụ và giao tiếp, không phải lỗi của cá nhân cụ thể.

Cấu trúc tài liệu post-mortem: dòng thời gian (trình tự sự kiện với dấu thời gian), tác động (người dùng bị ảnh hưởng, thời gian, tổn thất tài chính), nguyên nhân gốc rễ (nguyên nhân kỹ thuật chính), phát hiện (cách phát hiện, tại sao không phát hiện sớm hơn), phản ứng (đã làm gì, có thể làm nhanh hơn không), hành động (nhiệm vụ cụ thể với người chịu trách nhiệm và thời hạn). Các hành động phải S.M.A.R.T.: cụ thể, đo lường được, có thể giao, thực tế, có thời hạn.

Các hành động điển hình sau sự cố production: thêm giám sát và cảnh báo cho chỉ số đang im lặng; mở rộng phạm vi kiểm thử cho trường hợp bỏ sót; thêm trang vào runbook với quy trình từng bước cho tình huống tương tự; tổ chức đào tạo nhóm về công cụ đã sử dụng không đúng. Mỗi hành động là một thay đổi cụ thể giảm khả năng tái diễn sự cố.