Bỏ qua

P9.5 — Post-launch Product Operations, reliability, incident và End-of-Life

Module: P9 - Senior Product Practice

Mục tiêu đọc: Sau chương này, người đọc có thể:

  • Phân biệt deploy (triển khai), release (mở thay đổi cho người dùng), launch (ra mắt có phối hợp), operate (vận hành), support (hỗ trợ) và retire (ngừng cung cấp).
  • Đánh giá production readiness (mức sẵn sàng cho môi trường thật) bằng bằng chứng.
  • Dùng telemetry, observability, Service Level Indicator — SLI, Service Level Objective — SLO, Service Level Agreement — SLA và error budget đúng vai trò.
  • Phối hợp xử lý incident từ phân cấp, chỉ huy, truyền thông, giảm tác động, phục hồi đến học sau sự cố.
  • Phân loại phản hồi hỗ trợ thành lỗi, yêu cầu tính năng, vấn đề khả dụng, dữ liệu hoặc vận hành.
  • Quản lý bảo trì, nợ kỹ thuật và năng lực lộ trình dành cho độ tin cậy.
  • Lập kế hoạch deprecation, migration, tương thích ngược, lưu giữ dữ liệu, lưu trữ dài hạn và End-of-Life — EOL.
  • Thiết lập quyền sở hữu, ranh giới trực vận hành, đánh giá vận hành và vòng học quay lại discovery cùng roadmap.

Nguồn tổng hợp: Google Site Reliability Engineering, Google SRE Workbook, các khái niệm ITIL 4, chương trình nghiên cứu DORA.

Đọc chương không thay thế trải nghiệm trực vận hành, xử lý incident, quản lý dữ liệu hoặc quyết định EOL trong môi trường thật. Người đọc cần diễn tập, quan sát hệ thống thật dưới quyền phù hợp và chịu review từ chủ miền trước khi tự quyết.

Mental model

Launch mở trách nhiệm dịch vụ

Sản phẩm ra mắt không có nghĩa công việc kết thúc. Người dùng không trải nghiệm mã nguồn, kế hoạch dự án hoặc số tính năng đã giao. Người dùng trải nghiệm dịch vụ:

  • Có dùng được khi cần không.
  • Phản hồi có đủ nhanh không.
  • Dữ liệu có đúng và còn nguyên không.
  • Khi hỏng, tổ chức có phát hiện và phục hồi không.
  • Khi thay đổi hoặc đóng dịch vụ, người dùng có đủ thời gian và đường chuyển đổi không.

Reliability (độ tin cậy) là thuộc tính sản phẩm nhưng không thuộc riêng Product Manager — PM. Quyền được chia theo miền:

  • PM làm rõ hành trình quan trọng, tác động khách hàng, ưu tiên và đánh đổi lộ trình.
  • Engineer quyết định kiến trúc, triển khai, chẩn đoán, quay lui và sửa kỹ thuật.
  • Service Owner chịu trách nhiệm toàn diện cho dịch vụ.
  • Incident Commander điều phối incident đang diễn ra.
  • Support tiếp nhận, phân loại và quản lý trao đổi theo kênh hỗ trợ.
  • Data Owner quyết định tiêu chuẩn và chất lượng dữ liệu thuộc miền.
  • Security, Legal, Privacy, Finance và chủ hợp đồng quyết định trong thẩm quyền.
  • Sponsor hoặc chủ danh mục quyết định đầu tư lớn, chấp nhận rủi ro lớn và EOL khi vượt quyền đội.

Mô hình vận hành hậu ra mắt có bốn vòng:

  1. Sẵn sàng: xác định điều kiện đưa thay đổi vào dịch vụ thật.
  2. Quan sát: đo trải nghiệm và trạng thái dịch vụ.
  3. Phản ứng: giảm tác động, phục hồi và truyền thông khi có incident.
  4. Học và điều chỉnh: sửa hệ thống, đổi ưu tiên, cải thiện sản phẩm hoặc kết thúc dịch vụ.

P9.5 - Post-launch Product Operations, reliability, incident và End-of-Life — diagram 1

Source mermaid — có thể chỉnh sửa 
flowchart TD
    READY["Vòng 1 Sẵn sàng: Service Owner chịu trách nhiệm; PM làm rõ hành trình và đánh đổi; Engineer quyết định kiến trúc và triển khai"]
    GATE{"Đã có vận hành, quan sát, phục hồi, hỗ trợ và quyền quyết định?"}
    FIX["Engineer chẩn đoán, quay lui hoặc sửa kỹ thuật; PM điều chỉnh ưu tiên"]
    SPONSOR["Sponsor hoặc chủ danh mục quyết định đầu tư lớn và chấp nhận rủi ro lớn"]

    OBSERVE["Vòng 2 Quan sát: vận hành và quan sát liên tục"]
    SIGNAL{"Có tín hiệu cần xử lý?"}
    SOURCE{"Nguồn tín hiệu?"}
    SUPPORT["Support tiếp nhận và phân loại"]
    TECH["Engineer và Service Owner đánh giá telemetry"]
    INCIDENT{"Đủ điều kiện khai báo incident theo policy?"}

    DECLARE["Người có quyền theo policy khai báo incident"]
    COMMAND["Vòng 3 Phản ứng: Incident Commander điều phối"]
    RECOVER["Engineer chẩn đoán, giảm tác động, quay lui, sửa kỹ thuật và phục hồi"]
    COMMS["Duy trì truyền thông qua kênh hỗ trợ"]
    CLOSE{"Đủ điều kiện đóng incident?"}

    LEARN["Vòng 4 Học và điều chỉnh: sửa hệ thống, đổi ưu tiên và cải thiện sản phẩm"]
    NEXT{"Kết quả học tập?"}
    CHANGE["Discovery hoặc thay đổi roadmap"]
    EOL{"Đề xuất deprecation hoặc EOL?"}
    REVIEW["Data Owner, Security, Legal, Privacy, Finance và chủ hợp đồng quyết định theo thẩm quyền"]
    APPROVE{"Sponsor hoặc chủ danh mục phê duyệt EOL?"}
    REWORK["Điều chỉnh đề xuất hoặc tiếp tục vận hành"]
    NOTICE["Cung cấp đủ thời gian thông báo và đường chuyển đổi"]
    MIGRATE["Hỗ trợ chuyển đổi người dùng và xử lý dữ liệu"]
    RETIRE["Kết quả EOL: chuyển đổi người dùng hoặc đóng dịch vụ"]

    READY --> GATE
    GATE -->|"Chưa đủ"| FIX
    FIX --> READY
    GATE -->|"Vượt thẩm quyền đội"| SPONSOR
    SPONSOR --> READY
    GATE -->|"Đủ"| OBSERVE

    OBSERVE --> SIGNAL
    SIGNAL -->|"Không"| OBSERVE
    SIGNAL -->|"Có"| SOURCE
    SOURCE -->|"Kênh hỗ trợ"| SUPPORT
    SOURCE -->|"Monitoring và telemetry"| TECH
    SUPPORT -->|"Yêu cầu thông thường"| OBSERVE
    SUPPORT -->|"Dấu hiệu sự cố"| INCIDENT
    TECH -->|"Không phải incident"| OBSERVE
    TECH -->|"Dấu hiệu sự cố"| INCIDENT

    INCIDENT -->|"Không"| OBSERVE
    INCIDENT -->|"Có"| DECLARE
    DECLARE --> COMMAND
    COMMAND --> RECOVER
    COMMAND --> COMMS
    RECOVER --> CLOSE
    COMMS --> CLOSE
    CLOSE -->|"Chưa"| COMMAND
    CLOSE -->|"Có"| LEARN

    LEARN --> NEXT
    NEXT -->|"Tiếp tục vận hành"| OBSERVE
    NEXT -->|"Thay đổi sản phẩm"| CHANGE
    CHANGE --> READY
    NEXT -->|"Xem xét hết vòng đời"| EOL
    EOL -->|"Không"| OBSERVE
    EOL -->|"Có"| REVIEW
    REVIEW --> APPROVE
    APPROVE -->|"Không"| REWORK
    REWORK --> OBSERVE
    APPROVE -->|"Có"| NOTICE
    NOTICE --> MIGRATE
    MIGRATE --> RETIRE

Cách đọc quyết định vận hành

Mỗi quyết định quan trọng phải trả lời:

  1. Facts: Điều gì đã biết, bằng chứng nào đáng tin?
  2. Current behavior: Hệ thống hoặc người dùng hiện đang làm gì?
  3. Underlying need: Nhu cầu, rủi ro hoặc kết quả cần bảo vệ là gì?
  4. Options: Có phương án nào, gồm cả không làm gì?
  5. Decision criteria: Dùng tiêu chí nào để chọn?
  6. Decision: Chọn gì, trong phạm vi nào?
  7. Authority: Ai có quyền quyết định, ai chỉ cung cấp input?
  8. Artifact: Quyết định được ghi ở đâu?
  9. Consequence if wrong: Nếu sai, tác hại gì và phát hiện bằng cách nào?

Mẫu này ngăn đội nhảy từ triệu chứng sang giải pháp. Nó cũng làm rõ ranh giới giữa ảnh hưởng của PM và quyền quyết định của Engineering, Data, Security, Legal hoặc Sponsor.

Core

1. Deploy, release, launch, operate, support và retire

Trực giác

Một thay đổi có thể đã nằm trong production nhưng người dùng chưa thấy. Một thay đổi người dùng đã thấy có thể chưa được truyền thông như một launch. Dịch vụ vẫn cần operate và support trước khi phát hành rộng. Vì vậy, “đã deploy” không phải tiêu chí hoàn thành sản phẩm.

Định nghĩa chính xác

Khái niệm Cơ chế Quyền chính Tiêu chí hoàn thành
Deploy Đưa mã, cấu hình hoặc tài nguyên sang môi trường đích Engineering theo quy trình kỹ thuật Thay đổi hiện diện trong môi trường, kiểm tra kỹ thuật đạt
Release Cho nhóm người dùng truy cập thay đổi, thường qua cấu hình hoặc feature flag PM quyết phạm vi và điều kiện kinh doanh; Engineering xác nhận an toàn kỹ thuật Nhóm mục tiêu truy cập được, đo lường và hỗ trợ hoạt động
Launch Phối hợp truyền thông, bán hàng, hỗ trợ, đối tác và thị trường PM và Product Marketing điều phối trong governance GTM Hoạt động thị trường chạy, đội đối diện khách hàng sẵn sàng
Operate Duy trì dịch vụ an toàn, ổn định, đủ năng lực và có thể hỗ trợ Service Owner cùng đội kỹ thuật Dịch vụ đáp ứng mục tiêu vận hành
Support Tiếp nhận câu hỏi, vấn đề, hướng dẫn và phản hồi Support hoặc Customer Success Yêu cầu được phân loại, xử lý, chuyển tuyến và đóng có bằng chứng
Retire Kết thúc khả năng, phiên bản hoặc dịch vụ Chủ sản phẩm đề xuất; approver phê duyệt Truy cập dừng, nghĩa vụ xử lý, dữ liệu và hạ tầng quản lý

Vì sao cần phân biệt

Trộn thuật ngữ làm sai quyền và sai tiêu chí hoàn thành. Engineering có thể quyết định deploy. PM có thể quyết định release trong phạm vi kinh doanh. Launch cần phối hợp thị trường. Service Owner chịu operate. Chủ hợp đồng, Legal, Privacy, Data hoặc Sponsor có thể giữ quyền phủ quyết trong miền của họ.

Ví dụ tối thiểu

Mã phiên bản mới được deploy vào production nhưng feature flag vẫn tắt. Đây là deploy, chưa phải release. Flag được bật cho 5% khách hàng với dashboard và support đã sẵn sàng. Đây là release giới hạn, chưa nhất thiết là launch.

Cách dùng trong công việc

  • Mã đã deploy nhưng chưa đủ điều kiện khách hàng: giữ chưa mở.
  • Thay đổi mở cho nhóm nhỏ nhưng chưa cần tác động thị trường: không tổ chức launch.
  • Không có chủ vận hành, cảnh báo, quay lui hoặc hỗ trợ tối thiểu: chưa phát hành rộng.
  • Dịch vụ không còn tạo giá trị vượt chi phí, rủi ro và chi phí cơ hội: đánh giá deprecation hoặc EOL.

Biên giới và lỗi thường gặp

Anti-pattern là dùng “đã deploy” để tuyên bố “đã launch”, rồi phát hiện Support chưa có tài liệu, dữ liệu chưa đo được và không ai trực phản ứng. Release cũng không tự động chứng minh outcome kinh doanh.

2. Production readiness: bằng chứng trước production

Trực giác

Production readiness không phải buổi họp ký tên. Đó là bằng chứng cho thấy đội biết dịch vụ phải làm gì, ai chịu trách nhiệm, thất bại được phát hiện ra sao, tác động giảm thế nào và phục hồi bằng cách nào.

Định nghĩa chính xác

Production readiness là trạng thái dịch vụ có thể được vận hành trong phạm vi rủi ro đã chấp nhận. Production Readiness Review — PRR là đánh giá bằng chứng trước khi phát hành hoặc mở rộng.

PRR phải kiểm tra:

Miền Bằng chứng cần có
Giá trị và phạm vi Nhóm người dùng, hành trình quan trọng, phạm vi phát hành, điều kiện dừng
Quyền sở hữu Service Owner, đội trực kỹ thuật, Product, Support và đường leo thang
Độ tin cậy SLI, SLO, cửa sổ đo, cách xử lý dữ liệu thiếu hoặc sai
Quan sát Telemetry, dashboard, cảnh báo có thể hành động, kiểm tra dữ liệu đo
Năng lực Giả định tải, giới hạn, phụ thuộc và kế hoạch khi vượt năng lực
Thay đổi Triển khai, phát hành dần, quay lui hoặc tắt thay đổi
Incident Mức nghiêm trọng, kênh chỉ huy, mẫu truyền thông, liên hệ
Hỗ trợ Tài liệu, mã phân loại, chuyển tuyến, phản hồi tạm thời
Dữ liệu Chủ dữ liệu, chất lượng, đối soát, sao lưu, phục hồi và lưu giữ
Rủi ro bắt buộc Xác nhận từ Security, Privacy, Legal hoặc Compliance khi thuộc phạm vi
Phụ thuộc Chủ phụ thuộc, mục tiêu dịch vụ, phương án suy giảm hoặc thay thế
Sau phát hành Thời gian giám sát tăng cường, chỉ số bảo vệ, buổi rà kết quả

Vì sao cần PRR

Production làm rủi ro thành tác động thật. PRR buộc đội chứng minh điều kiện vận hành trước khi mở blast radius. Nó cũng buộc người có quyền chấp nhận rủi ro ký đúng phần của mình.

Ví dụ tối thiểu

Một pipeline báo cáo chạy thành công nhưng chưa kiểm tra dữ liệu đầy đủ. “Job thành công” chỉ chứng minh tiến trình kỹ thuật kết thúc, không chứng minh người dùng nhận báo cáo đúng.

Cách dùng trong công việc

Mỗi mục PRR cần bằng chứng hoặc ngoại lệ được chấp nhận. Mỗi rủi ro cần owner, hành động, thời hạn và người chấp nhận. SLO phải phản ánh hành trình người dùng. Cảnh báo phải dẫn tới hành động rõ. Kế hoạch quay lui phải xét dữ liệu và tương thích, không chỉ mã.

Quy tắc go/no-go

  • Rủi ro mất dữ liệu, an toàn, quyền riêng tư hoặc vi phạm nghĩa vụ chưa được chủ miền chấp nhận: no-go.
  • Không thể phát hiện thất bại trên hành trình cốt lõi: thu hẹp phát hành hoặc bổ sung đo lường.
  • Không có cách giảm phạm vi ảnh hưởng hoặc phục hồi hợp lý: giảm quy mô phát hành.
  • Chỉ còn thiếu tối ưu không ảnh hưởng ngưỡng chất lượng: có thể phát hành với owner và ngày rà soát.

PM không tự phê duyệt ngoại lệ bảo mật, pháp lý hoặc toàn vẹn dữ liệu.

3. Telemetry, observability, SLI, SLO và SLA

Telemetry và observability

Telemetry là tín hiệu được tạo và thu thập, thường gồm:

  • Metrics: số đo tổng hợp theo thời gian.
  • Logs: bản ghi sự kiện.
  • Traces: dấu vết yêu cầu qua nhiều thành phần.
  • Sự kiện sản phẩm và tín hiệu chất lượng dữ liệu.

Observability là năng lực dùng tín hiệu để suy ra điều đang xảy ra, kể cả lỗi chưa dự đoán trước. Nhiều telemetry không chắc tạo observability. Hàng triệu log không truy được về hành trình, phiên bản, nhóm khách hàng hoặc phụ thuộc vẫn khó chẩn đoán.

Định nghĩa và mục đích

  • SLI là phép đo định lượng về thuộc tính dịch vụ.
  • SLO là mục tiêu cho SLI trong cửa sổ thời gian.
  • SLA là cam kết với khách hàng hoặc đối tác, thường có phạm vi, cách đo, ngoại lệ và hậu quả.

SLI đo điều người dùng nhận. SLO giúp đội điều hành và đánh đổi nội bộ. SLA tạo nghĩa vụ bên ngoài. Ba khái niệm liên quan nhưng không đồng nghĩa.

SLI

Một SLI cần nêu:

Trường Nội dung
Hành trình Tác vụ hoặc kết quả người dùng
Sự kiện hợp lệ Đơn vị được tính
Thành công Điều kiện được coi là tốt
Tổng Tập cơ hội cung cấp dịch vụ
Cửa sổ Khoảng thời gian đánh giá
Phân đoạn Khu vực, gói, thiết bị hoặc nhóm cần tách
Nguồn dữ liệu Telemetry và hệ thống ghi nhận
Loại trừ Lý do loại trừ có kiểm soát
Owner Người chịu trách nhiệm định nghĩa và chất lượng 
SLI = Số sự kiện tốt / Tổng số sự kiện hợp lệ

Ví dụ:

  • Tỷ lệ thanh toán hoàn tất đúng.
  • Tỷ lệ tìm kiếm trả kết quả trong ngưỡng độ trễ đã chọn.
  • Tỷ lệ báo cáo hoàn tất và vượt kiểm tra chất lượng dữ liệu.
  • Tỷ lệ thông báo được xử lý trong cửa sổ nghiệp vụ.

CPU cao, bộ nhớ dùng nhiều hoặc hàng đợi dài có thể hữu ích cho Engineering, nhưng thường là tín hiệu nội bộ. Không dùng chúng thay SLI nếu chưa chứng minh quan hệ với trải nghiệm.

SLO

SLO phải cân bằng:

  • Tác hại khi suy giảm.
  • Kỳ vọng và quy trình khách hàng.
  • Khả năng thay thế hoặc xử lý thủ công.
  • Chi phí đạt và duy trì độ tin cậy.
  • Độ tin cậy của phụ thuộc.
  • Tốc độ đổi mới.
  • Nghĩa vụ hợp đồng hoặc quy định.

PM cung cấp tác động khách hàng và đánh đổi kinh doanh. Engineering cung cấp khả năng, chi phí và rủi ro kỹ thuật. Service Owner chịu vận hành. Sponsor hoặc chủ ngân sách quyết định đầu tư lớn.

SLA

SLA không tự động là bản sao SLO:

  • SLO dùng quản lý nội bộ.
  • SLA tạo nghĩa vụ bên ngoài.
  • Cách đo, phạm vi và hậu quả cần Legal, Sales, Finance, Operations và Engineering xác nhận.
  • PM cung cấp nhu cầu thị trường; PM không tự cam kết điều khoản pháp lý hoặc khoản bồi hoàn.

Failure mode và boundary

Red flags:

  • SLO không có SLI đo được.
  • SLI đổi công thức nhưng lịch sử không chú thích.
  • Sales hứa SLA trước khi Engineering và Legal đánh giá.
  • Chỉ đo trung bình, che nhóm người dùng chịu trải nghiệm xấu.
  • Loại trừ sự cố sau khi xảy ra để làm số đẹp.
  • Đặt mục tiêu theo số tròn hoặc đối thủ mà không phân tích nhu cầu.

4. Incident: phân cấp, chỉ huy, truyền thông và phục hồi

Trực giác

Incident không phải lúc tìm người có lỗi. Đó là lúc giảm tác động nhanh, giữ thông tin đáng tin, phân vai rõ và phục hồi hành trình người dùng.

Định nghĩa

Incident là gián đoạn hoặc suy giảm ngoài dự kiến cần phản ứng có phối hợp. Defect chưa gây tác động hiện tại có thể vào backlog. Defect đang gây tác động đáng kể có thể kích hoạt incident.

Severity

Severity dựa trên:

  • Phạm vi người dùng hoặc quy trình.
  • Mức mất chức năng hoặc suy giảm.
  • Mất, sai hoặc rò rỉ dữ liệu.
  • Rủi ro an toàn, bảo mật, pháp lý hoặc tài chính.
  • Phương án thay thế.
  • Tốc độ lan rộng.
  • Nhu cầu thông báo khách hàng hoặc đối tác.
  • Khả năng đảo ngược.

Mỗi cấp phải gắn người được gọi, thời gian phản ứng nội bộ, nhu cầu Incident Commander, nhịp cập nhật, kênh truyền thông, điều kiện nâng/hạ cấp và điều kiện kết thúc.

Khi dữ liệu chưa đủ nhưng nguy cơ cao, chọn mức bảo thủ rồi điều chỉnh bằng bằng chứng. Không phân cấp theo độ khó sửa hoặc chức danh khách hàng phàn nàn.

Command

Vai trò Trách nhiệm Không làm
Incident Commander Đặt mục tiêu, phân vai, giữ nhịp, điều phối và leo thang Không cần tự sửa kỹ thuật
Technical Lead Điều tra, đề xuất mitigation, recovery và kiểm tra kỹ thuật Không tự quyết thông điệp pháp lý
Communications Lead Duy trì thông điệp nội bộ và khách hàng Không bịa nguyên nhân hoặc thời gian phục hồi
Scribe Ghi timeline, quyết định, bằng chứng và hành động Không thay Incident Commander
Chủ miền Xử lý dữ liệu, bảo mật, pháp lý, nhà cung cấp hoặc nghiệp vụ Không vượt quyền miền khác

PM có thể làm Communications Lead hoặc cung cấp bối cảnh khách hàng nếu được phân vai. PM không mặc định là Incident Commander, không chỉ đạo cách sửa kỹ thuật và không công bố nghĩa vụ pháp lý khi chưa được phê duyệt.

Mitigation, recovery và resolution

  • Mitigation giảm phạm vi hoặc mức hại: tắt tính năng, giới hạn lưu lượng, chế độ suy giảm hoặc quy trình thủ công.
  • Recovery đưa dịch vụ về trạng thái chấp nhận được và xác nhận hành trình hoạt động.
  • Resolution kết thúc xử lý khẩn cấp khi tác động dừng, trạng thái ổn định và theo dõi còn hiệu lực.
  • Sửa nguyên nhân lâu dài có thể diễn ra sau resolution.

Không trì hoãn mitigation để tìm nguyên nhân hoàn hảo. Không tuyên bố recovery chỉ vì dashboard hạ tầng xanh; cần kiểm tra hành trình và dữ liệu người dùng.

Communication

Thông báo cần nêu:

  • Điều đang bị ảnh hưởng.
  • Nhóm hoặc khu vực chịu tác động.
  • Thời điểm bắt đầu hoặc phát hiện.
  • Trạng thái điều tra, mitigation hoặc recovery.
  • Workaround đã kiểm tra.
  • Thời điểm cập nhật tiếp.
  • Kênh chính thức.

Không nêu nguyên nhân chưa xác nhận, thời gian phục hồi đoán mò, đổ lỗi cá nhân, chi tiết tạo rủi ro bảo mật hoặc cam kết pháp lý chưa phê duyệt.

Artifact: Incident Brief

Trường Nội dung
ID và tiêu đề Mã duy nhất, mô tả tác động
Severity Cấp hiện tại và lý do
Trạng thái Điều tra, mitigation, recovery, theo dõi, kết thúc
Bắt đầu/phát hiện Mốc thời gian và độ chắc chắn
Tác động Hành trình, phân khúc, dữ liệu, doanh nghiệp
Command Incident Commander và vai trò
Hành động hiện tại Việc đang làm, owner
Workaround Cách thay thế đã kiểm tra
Communication Kênh, thông điệp, lần cập nhật tiếp
Rủi ro mở Điều chưa biết hoặc có thể xấu hơn
Liên kết Kênh xử lý, dashboard, ticket, timeline

Incident Brief phải là một nguồn trạng thái ngắn, có timestamp, tách tác động khỏi giả thuyết nguyên nhân.

5. Postmortem và corrective action

Postmortem là phân tích có cấu trúc sau incident để tạo hiểu biết và thay đổi hệ thống. Nó không phải phiên xét lỗi cá nhân.

Nội dung tối thiểu:

  1. Tóm tắt sự cố.
  2. Tác động khách hàng, dữ liệu và doanh nghiệp.
  3. Timeline từ khởi phát đến recovery.
  4. Cách phát hiện.
  5. Yếu tố kỹ thuật và tổ chức góp phần.
  6. Điều làm tốt.
  7. Điều tăng tác động hoặc kéo dài recovery.
  8. Corrective action.
  9. Owner, ưu tiên, hạn và cơ chế kiểm tra hoàn tất.
  10. Bài học quay lại readiness, discovery và roadmap.

Blameless không có nghĩa không có accountability. Cần phân biệt sai sót hợp lý trong hệ thống thiếu hàng rào, quy trình mơ hồ, quyết định đánh đổi đã chấp nhận và hành vi cố ý vi phạm chính sách. Trường hợp cố ý đi qua quy trình quản trị phù hợp, không xử trong postmortem công khai.

Không ép mọi incident vào một root cause duy nhất. Hệ thống phức tạp thường có nhiều điều kiện góp phần. Five Whys có thể hỗ trợ nhưng dễ tạo câu chuyện tuyến tính giả.

Corrective action

Corrective action cần thay đổi xác suất hoặc tác động:

  • Ngăn điều kiện tái diễn.
  • Phát hiện sớm hơn.
  • Giảm blast radius.
  • Phục hồi nhanh hơn.
  • Làm quyết định an toàn hơn.
  • Cải thiện tài liệu, quyền sở hữu hoặc diễn tập.
Trường Yêu cầu
Vấn đề xử lý Yếu tố góp phần cụ thể
Cơ chế Vì sao hành động giảm rủi ro
Owner Một người theo dõi
Priority Dựa trên giảm rủi ro và chi phí
Due/review date Ngày hoàn tất hoặc rà lại
Verification Bằng chứng hiệu lực
Backlog link Liên kết reliability backlog

“Cẩn thận hơn”, “đào tạo lại mọi người” hoặc “thêm monitoring” không đủ cụ thể.

6. Support triage

Support triage chuyển tín hiệu người dùng vào đường xử lý đúng. Mọi ticket không nên đi thẳng vào product backlog.

Loại Dấu hiệu Đường xử lý
Defect Hành vi khác thiết kế hoặc cam kết Xác nhận tái hiện, tác động; Engineering và QA đánh giá
Feature request Nhu cầu chưa được hỗ trợ Làm rõ nhu cầu, workaround và tần suất; đưa vào discovery
Usability issue Có khả năng nhưng khó tìm, khó hiểu hoặc dễ dùng sai Product và Design nghiên cứu hành trình
Data issue Dữ liệu thiếu, trễ, sai hoặc không nhất quán Data Owner và Engineering đánh giá toàn vẹn, phạm vi, nguồn gốc
Operational issue Chậm, gián đoạn, quyền, tích hợp hoặc năng lực Kiểm tra telemetry, SLI, phụ thuộc và runbook

Một phản hồi có thể đổi loại sau điều tra. “Thêm nút xuất” có thể là feature request, hoặc workaround cho báo cáo hiện tại không dùng được.

Hồ sơ triage tối thiểu:

  • Người dùng, tài khoản và phân khúc.
  • Hành trình và mục tiêu.
  • Điều mong đợi và điều thực tế.
  • Thời điểm, tần suất, môi trường.
  • Phạm vi ảnh hưởng.
  • Bằng chứng đã xử lý quyền riêng tư.
  • Workaround.
  • Phân loại và độ tin cậy.
  • Severity nếu có tác động vận hành.
  • Owner và lần cập nhật tiếp.

Nguy cơ an toàn, bảo mật, mất hoặc sai dữ liệu phải chuyển tuyến ngay. Tác động đang lan rộng cần xem xét incident, không chờ backlog grooming. Ticket cùng triệu chứng cần gom thành problem record. Khách hàng doanh thu cao tăng bối cảnh kinh doanh nhưng không tự quyết severity hoặc roadmap.

7. Error budget, reliability investment và roadmap capacity

Với SLO dạng tỷ lệ:

Error budget = 1 - SLO

Công thức chỉ hợp lệ khi dùng cùng định nghĩa SLI, cửa sổ đo và quy tắc loại trừ. Không áp dụng máy móc cho mọi mục tiêu.

Error budget là governance

Chính sách cần ghi:

  • SLO và cửa sổ đo.
  • Cách tính tiêu thụ.
  • Ngưỡng cảnh báo.
  • Thay đổi được tiếp tục.
  • Thay đổi phải thu hẹp hoặc tạm dừng.
  • Ngoại lệ.
  • Người phê duyệt ngoại lệ.
  • Ngày rà chính sách.
Trạng thái Quyết định
Tiêu thụ trong mức dự kiến Tiếp tục thay đổi với kiểm soát chuẩn
Tốc độ tiêu thụ tăng Giảm rủi ro release và điều tra
Gần cạn Hạn chế thay đổi rủi ro, tăng reliability investment
Vi phạm SLO Áp policy; giữ thay đổi thiết yếu hoặc giảm rủi ro
SLI/SLO sai Sửa phép đo qua governance, không sửa hồi tố

Không có luật phổ quát rằng hết budget phải dừng mọi feature. Thay đổi giảm incident, nghĩa vụ bảo mật hoặc pháp lý có thể vẫn phải tiếp tục. Quyết định dựa trên chính sách và rủi ro.

Reliability investment

Bao gồm:

  • Cải thiện phát hiện và cảnh báo.
  • Giảm phạm vi tác động.
  • Tự động hóa recovery.
  • Loại lỗi lặp lại.
  • Kiểm tra sao lưu và phục hồi.
  • Cải thiện năng lực và phụ thuộc.
  • Giảm công việc thủ công.
  • Cải thiện chất lượng dữ liệu.
  • Sửa quyền sở hữu và tài liệu.
  • Trả technical debt làm tăng rủi ro.

Maintenance giữ hệ thống hoạt động: cập nhật phụ thuộc, chứng thư, dữ liệu tham chiếu, dung lượng, tài liệu, tích hợp và quy trình.

Technical debt là chi phí hoặc rủi ro tương lai từ quyết định kỹ thuật hiện tại. Engineering đánh giá bản chất kỹ thuật. PM đánh giá tác động khách hàng, tốc độ sản phẩm và chi phí cơ hội. PM không tự định nghĩa tái kiến trúc.

Roadmap capacity không có tỷ lệ phổ quát. Phân bổ dựa trên error budget, incident lặp lại, bảo trì bắt buộc, nợ kỹ thuật, tăng trưởng tải, phụ thuộc, chi phí cơ hội và nghĩa vụ bảo mật, pháp lý, dữ liệu.

8. Deprecation, migration và EOL

Định nghĩa

  • Deprecation là thông báo khả năng hoặc phiên bản vẫn tồn tại nhưng không nên dùng mới và sẽ bị hạn chế hoặc dừng.
  • EOL là mốc kết thúc cung cấp, hỗ trợ hoặc vận hành theo phạm vi công bố.
  • Retire là hành động thực thi việc loại khỏi dịch vụ.

Ba khái niệm không đồng nghĩa.

Vì sao cần kế hoạch

Dịch vụ cũ có thể vẫn chứa client, dữ liệu, hợp đồng, tích hợp hoặc quy trình không hiển thị. Tắt mà không biết người dùng phụ thuộc sẽ biến quyết định nội bộ thành gián đoạn khách hàng.

Điều kiện xem xét deprecation:

  • Giá trị không còn tương xứng chi phí.
  • Khả năng cũ chặn chiến lược hoặc độ tin cậy.
  • Phiên bản cũ tạo rủi ro bảo mật, dữ liệu hoặc vận hành.
  • Có thay thế tốt hơn.
  • Phụ thuộc bên ngoài kết thúc.
  • Nghĩa vụ hoặc mô hình kinh doanh thay đổi.

PM lập business case và tác động. Engineering đánh giá phụ thuộc, tương thích và cách tắt. Support, Sales và Customer Success đánh giá khách hàng. Data, Security, Privacy, Legal, Finance và chủ hợp đồng quyết định phần thuộc miền. Sponsor hoặc approver danh mục quyết định EOL khi cần.

Backward compatibility

Tương thích ngược giảm gián đoạn và cho thời gian chuyển đổi, nhưng tăng phức tạp, bảo trì, nhánh hành vi và chi phí kiểm thử.

  • Tích hợp rộng hoặc chi phí chuyển đổi cao: ưu tiên cửa sổ tương thích và công cụ migration.
  • Rủi ro an toàn hoặc bảo mật nghiêm trọng: có thể rút ngắn hỗ trợ, nhưng cần governance và truyền thông.
  • Không biết ai còn dùng phiên bản cũ: chưa sẵn sàng EOL; sửa inventory và telemetry.
  • Tương thích vô hạn làm dịch vụ không thể duy trì: đặt giới hạn công khai.

Migration

Migration cần quản như hành trình sản phẩm:

  • Nhóm bị ảnh hưởng.
  • Trạng thái nguồn và đích.
  • Điều kiện đủ.
  • Công cụ, tài liệu và hỗ trợ.
  • Kiểm tra dữ liệu trước và sau.
  • Chạy song song nếu cần.
  • Khả năng và giới hạn rollback.
  • Theo dõi theo cohort.
  • Ngoại lệ.
  • Điều kiện hoàn tất.

Không đo migration bằng số email gửi. Đo đối tượng đủ điều kiện, bắt đầu, hoàn tất, thất bại, cần hỗ trợ và còn bị chặn.

Data retention, archive và deletion

  • Data retention quy định loại dữ liệu, mục đích, thời hạn và quyền truy cập.
  • Archive giữ dữ liệu hoặc hồ sơ cần thiết ngoài luồng vận hành thường ngày.
  • Deletion loại dữ liệu theo chính sách và nghĩa vụ.
  • Backup không tự động là archive.
  • Archive không tự động cho phép truy cập qua sản phẩm.
  • Tắt sản phẩm không tự động cho phép xóa mọi dữ liệu.

Data Owner, Privacy, Legal, Security và Records Management nếu có quyết định chính sách. PM bảo đảm trải nghiệm xuất dữ liệu, thông báo và hỗ trợ được thiết kế. Engineering thực thi kỹ thuật. Không viện dẫn tên luật cụ thể khi chưa xác định phạm vi pháp lý áp dụng.

Applied

Ca mô phỏng: vận hành dịch vụ báo cáo B2B

Đây là ca mô phỏng, không phải số liệu hoặc sự kiện thực tế.

Đội sở hữu dịch vụ tạo báo cáo định kỳ cho khách hàng B2B. Phiên bản xử lý mới đã deploy nhưng chưa release. Phiên bản cũ tốn công bảo trì và sẽ cần deprecation sau khi migration ổn định.

1. Readiness review

Facts: Phiên bản mới đã có trong production. Phiên bản cũ vẫn phục vụ khách hàng. Báo cáo cần đúng dữ liệu và hoàn tất trong cửa sổ nghiệp vụ đã công bố. PRR phát hiện cảnh báo chỉ đo job thất bại, chưa đo dữ liệu sai; phụ thuộc dữ liệu nguồn chưa có owner; mã có thể rollback nhưng schema báo cáo mới không tự động tương thích dữ liệu cũ.

Current behavior: Đội có thể biết pipeline dừng, nhưng chưa biết pipeline chạy xong với dữ liệu thiếu. Đội chưa chứng minh rollback không làm hỏng báo cáo đã tạo bằng schema mới.

Underlying need: Người dùng cần báo cáo đúng và có thể tin cậy trong quy trình kinh doanh. Đội cần giới hạn blast radius trước khi mở rộng.

Options:

  1. Release rộng ngay, chấp nhận thiếu bằng chứng.
  2. Không release cho đến khi mọi tối ưu hoàn tất.
  3. Release giới hạn sau khi thêm kiểm tra dữ liệu, owner phụ thuộc và phương án xử lý schema.
  4. Giữ phiên bản mới chỉ cho nội bộ, bổ sung bằng chứng trước.

Decision criteria: Tác động nếu dữ liệu sai; khả năng phát hiện; khả năng giảm phạm vi; khả năng phục hồi; chi phí trì hoãn; quyền chấp nhận rủi ro.

Decision: Chọn release giới hạn sau khi bổ sung kiểm tra dữ liệu, xác định owner phụ thuộc và viết phương án xử lý báo cáo schema mới. Không release rộng.

Authority: PM quyết phạm vi release và điều kiện kinh doanh. Engineering quyết rollout và rollback kỹ thuật. Data Owner quyết điều kiện chất lượng dữ liệu. Service Owner xác nhận quyền vận hành. Security, Privacy, Legal hoặc chủ hợp đồng phê duyệt phần thuộc miền.

Artifact: PRR, decision log, SLI/SLO definition, rollout plan, rollback plan và support runbook.

Consequence if wrong: Nếu release rộng quá sớm, dữ liệu sai có thể lan rộng và khó phục hồi. Nếu trì hoãn vô hạn, đội chịu chi phí bảo trì phiên bản cũ và mất cơ hội học. Monitoring theo cohort, giới hạn rollout và điều kiện dừng làm hậu quả dễ kiểm soát hơn.

2. Incident

Facts: Sau release giới hạn, Support nhận nhiều ticket về báo cáo thiếu một nhóm giao dịch. Data Owner nghi ngờ nguồn dữ liệu. Tác động đang diễn ra và ảnh hưởng quyết định kinh doanh.

Current behavior: Người dùng nhận báo cáo có vẻ hoàn tất nhưng thiếu dữ liệu. Job không báo lỗi. Support phân loại ban đầu là Data issue.

Underlying need: Khách hàng cần dữ liệu đúng, không chỉ file được tạo thành công. Đội cần ngăn báo cáo sai tiếp tục phát hành và thông báo tác động rõ.

Options:

  1. Tiếp tục tạo báo cáo và điều tra âm thầm.
  2. Tắt toàn bộ dịch vụ.
  3. Dừng pipeline lỗi, dùng workaround đã kiểm tra và kích hoạt incident.
  4. Rollback mã mà không kiểm tra schema và dữ liệu.

Decision criteria: Mức độ lan rộng; nguy cơ dữ liệu sai tiếp; độ an toàn của workaround; khả năng tái tạo; phạm vi rollback; nghĩa vụ thông báo.

Decision: Service Owner kích hoạt incident theo ma trận severity. Đội dừng tạo báo cáo từ pipeline lỗi, xác nhận phạm vi, truyền thông nhóm bị ảnh hưởng và tái tạo báo cáo sau khi nguồn dữ liệu được sửa.

Authority: Incident Commander điều phối. Technical Lead quyết định mitigation kỹ thuật. Data Owner xác nhận phạm vi và chất lượng dữ liệu. PM làm Communications Lead nếu được phân vai. Legal, Privacy hoặc Security quyết định thông điệp thuộc miền của họ.

Artifact: Incident Brief, timeline, dashboard impact, communication log, data reconciliation record.

Consequence if wrong: Nếu tiếp tục phát hành, dữ liệu sai lan rộng. Nếu rollback mù, dữ liệu schema mới có thể không đọc được hoặc tạo lỗi mới. Nếu thông báo quá sớm với nguyên nhân chưa biết, khách hàng nhận thông tin sai.

3. Postmortem

Facts: Pipeline hoàn tất nhưng dữ liệu thiếu. Cấu hình có thể đổi mà thiếu kiểm tra tương thích. Release gate không yêu cầu đối soát theo cohort. Runbook không nêu cách xác định báo cáo cần tái tạo.

Current behavior: Monitoring đo tiến trình kỹ thuật, không đo tính đầy đủ. Đội dựa vào ticket khách hàng để phát hiện vấn đề.

Underlying need: Đội cần phát hiện sai dữ liệu trước khi khách hàng dùng báo cáo, giảm phạm vi và phục hồi có thể kiểm chứng.

Options:

  1. Chỉ sửa cấu hình nguồn.
  2. Đổ lỗi cho người thực hiện thay đổi.
  3. Thêm kiểm tra dữ liệu, chặn cấu hình không hợp đồng, cải thiện dashboard và runbook.
  4. Thêm nhiều log nhưng không đổi release gate.

Decision criteria: Khả năng ngăn tái diễn; khả năng phát hiện sớm; blast radius; chi phí; khả năng kiểm chứng hiệu lực.

Decision: Chọn phương án 3. Reliability backlog nhận các action có owner và verification.

Authority: Incident Commander bảo đảm postmortem hoàn tất. Engineering sở hữu action kỹ thuật. Data Owner sở hữu kiểm tra chất lượng dữ liệu. PM ưu tiên action trong roadmap. Sponsor quyết định nếu cần đầu tư vượt capacity.

Artifact: Blameless postmortem, corrective-action register, reliability backlog, updated PRR.

Consequence if wrong: Nếu chỉ sửa cấu hình, cùng cơ chế có thể gây incident mới. Nếu chỉ thêm log, lượng tín hiệu tăng nhưng khả năng quyết định không tăng. Nếu đổ lỗi cá nhân, tổ chức mất thông tin và không sửa hàng rào hệ thống.

4. Roadmap capacity

Facts: Error budget bị tiêu thụ nhanh. Lỗi dữ liệu tạo nhiều support contact. Tính năng định dạng mới đang chờ. Cập nhật bảo mật bắt buộc tồn tại. Migration khỏi phiên bản cũ có thể giảm gánh bảo trì nhưng cũng tạo rủi ro.

Current behavior: Đội có xu hướng đóng băng mọi feature hoặc tiếp tục giao feature theo kế hoạch cũ.

Underlying need: Cân bằng reliability, nghĩa vụ bắt buộc, giá trị khách hàng và chi phí cơ hội bằng quy tắc minh bạch.

Options:

  1. Dừng mọi feature.
  2. Bỏ qua error budget và giữ roadmap.
  3. Ưu tiên công việc giảm rủi ro, tiếp tục thay đổi bắt buộc, thu hẹp migration và lùi feature tăng biến thể.
  4. Đặt tỷ lệ capacity cố định cho reliability không xét bằng chứng.

Decision criteria: Mức giảm rủi ro; tính bắt buộc; blast radius; chi phí trì hoãn; khả năng rollback; giá trị khách hàng; năng lực đội.

Decision: Ưu tiên kiểm tra dữ liệu và corrective action. Tiếp tục cập nhật bảo mật theo governance. Lùi tính năng định dạng. Chạy migration theo cohort nhỏ.

Authority: PM và Engineering cùng ưu tiên roadmap trong governance. Security hoặc Legal giữ quyền trong phần chuyên môn. Sponsor quyết định thay đổi đầu tư lớn hoặc chấp nhận rủi ro vượt quyền đội.

Artifact: Roadmap decision log, reliability backlog, error-budget policy, capacity allocation record.

Consequence if wrong: Nếu lùi reliability, incident lặp lại và support tăng. Nếu dừng mọi thay đổi, đội có thể bỏ lỡ sửa lỗi hoặc nghĩa vụ bắt buộc. Nếu đặt tỷ lệ cố định, capacity không phản ánh rủi ro thật.

5. Deprecation và EOL

Facts: Phiên bản mới đã ổn định hơn. Inventory phát hiện khách hàng dùng quy trình tải file tự động không hiển thị trong giao diện. Một số hợp đồng có điều kiện hỗ trợ riêng. Chính sách dữ liệu chưa được xác nhận cho EOL.

Current behavior: Đội muốn đặt ngày EOL ngay sau khi phiên bản mới hoạt động. Telemetry chưa đủ để biết mọi client cũ.

Underlying need: Kết thúc phiên bản cũ mà không làm gián đoạn khách hàng, vi phạm nghĩa vụ hoặc xử lý sai dữ liệu.

Options:

  1. Tắt ngay theo ngày nội bộ.
  2. Duy trì vô thời hạn.
  3. Bổ sung inventory và telemetry, migration theo cohort, chạy song song, công bố mốc và chỉ EOL khi exit criteria đạt.
  4. Chỉ gửi email rồi coi cohort đã migrated.

Decision criteria: Độ tin cậy inventory; tỷ lệ migration thành công; compatibility; nghĩa vụ hợp đồng; rủi ro dữ liệu; chi phí duy trì; khả năng rollback hoặc contingency.

Decision: Chưa đặt EOL cuối cùng. Đội bổ sung telemetry, tài liệu migration và chạy song song. Cohort chỉ migrated khi báo cáo mới thành công, kiểm tra dữ liệu đạt, downstream hoạt động và không còn blocker. Sau khi chủ miền xác nhận nghĩa vụ, đội mới thực hiện EOL.

Authority: PM lập Deprecation Plan. Engineering quyết cơ chế tương thích, migration và tắt kỹ thuật. Support quản lý khách hàng và escalation. Data, Privacy, Legal, Security và chủ hợp đồng phê duyệt phần thuộc miền. Sponsor hoặc approver danh mục quyết EOL khi vượt quyền đội.

Artifact: Deprecation Plan, migration dashboard, cohort register, EOL Checklist, decision log.

Consequence if wrong: Nếu tắt sớm, khách hàng có thể mất quy trình tự động hoặc dữ liệu. Nếu duy trì vô hạn, đội tiếp tục trả chi phí bảo trì và tăng rủi ro. Nếu tắt telemetry sớm, client cũ ngoài dự kiến sẽ không được phát hiện.

Senior Lens

Ownership và authority

“Tất cả cùng sở hữu reliability” thường nghĩa không ai chịu trách nhiệm. Bảng sau phân biệt quyền chính và input:

Quyết định Quyền chính Input bắt buộc
Hành trình quan trọng và tác động khách hàng PM Support, Design, Data, Engineering
Thiết kế SLI và khả năng đo Engineering, Data theo miền PM cung cấp hành trình và phân khúc
Mức SLO Service Owner và governance sản phẩm–kỹ thuật PM, Engineering, Support, Finance khi cần
Điều khoản SLA Chủ hợp đồng, Legal và business approver Engineering, PM, Finance, Operations
Kiến trúc reliability Engineering hoặc Architecture SLO, ràng buộc sản phẩm và chi phí
Kích hoạt incident Service Owner hoặc vai trò theo policy Telemetry, Support, Security, Data
Chỉ huy incident Incident Commander Các lead miền
Truyền thông khách hàng Communications Lead Incident Commander, Legal/Security khi cần
Ưu tiên reliability backlog PM và Engineering Incident, SLO, support, risk, maintenance
Retention/archive/deletion Data, Privacy, Legal, Security PM, Engineering, Support
EOL Approver danh mục hoặc Sponsor PM đề xuất; chủ miền xác nhận

PM không phê duyệt toàn bộ. PM giữ liên kết giữa tác động khách hàng, chiến lược, ưu tiên và truyền thông sản phẩm.

On-call boundary

On-call cần chia theo loại quyết định:

  • Technical on-call: chẩn đoán, mitigation và recovery kỹ thuật.
  • Product/business escalation: phạm vi khách hàng, workaround nghiệp vụ hoặc ưu tiên khẩn cấp.
  • Communications on-call: thông điệp và cập nhật.
  • Security, Privacy, Legal hoặc Data escalation: quyết định chuyên môn.

PM không nên nằm trong technical on-call nếu không có năng lực và quyền kỹ thuật. PM có thể thuộc product escalation cho incident nghiêm trọng hoặc tác động khách hàng lớn.

Ranh giới phải ghi điều kiện gọi, kênh gọi, kỳ vọng phản hồi nội bộ, quyền quyết định, người dự phòng, bàn giao và cơ chế bảo vệ sức khỏe người trực.

Operational Review

Operational Review không phải đọc dashboard. Đầu vào gồm SLI, SLO, error budget, incident, corrective action, support volume, chất lượng dữ liệu, maintenance, technical debt, năng lực, phụ thuộc, deprecation, migration và roadmap sắp tới.

Đầu ra phải có:

  • Quyết định ưu tiên.
  • Risk acceptance có approver.
  • Reliability backlog đã sắp lại.
  • Owner và thời hạn.
  • Điều cần đưa vào discovery.
  • Thay đổi release policy, SLO hoặc capacity.
  • Escalation xuyên đội.

Buổi review tốt xem xu hướng và phân khúc, kiểm tra action cũ có hiệu lực, không đổi SLO để hợp thức hóa hiệu suất kém và kết thúc bằng quyết định có owner cùng ngày rà lại.

Learning loop về discovery và roadmap

Dữ liệu vận hành tạo giả thuyết, không tự động tạo feature.

Tín hiệu Câu hỏi discovery Kết quả roadmap có thể có
Defect lặp lại Luồng hoặc kiến trúc nào dễ lỗi? Sửa nền, giảm biến thể, thêm kiểm soát
Usability issue Người dùng hiểu sai ở đâu? Thiết kế lại luồng hoặc nội dung
Feature request Nhu cầu gốc và workaround là gì? Discovery; có thể không xây yêu cầu nguyên dạng
Data issue Định nghĩa, lineage hoặc ownership nào thiếu? Data contract, đối soát, trải nghiệm minh bạch
Operational issue SLO, capacity hoặc dependency nào không phù hợp? Reliability investment hoặc đổi phạm vi
Incident lớn Điều gì làm tác động rộng hoặc recovery chậm? Corrective action, release policy, architecture
Support tăng sau launch Sai message, onboarding, chất lượng hay segment? Sửa GTM, sản phẩm hoặc support model
Migration chậm Giá trị đích yếu hay chi phí chuyển cao? Công cụ migration, compatibility hoặc xem lại EOL

Quy trình:

  1. Gom tín hiệu theo hành trình, phân khúc và cơ chế.
  2. Xác nhận bằng dữ liệu và nghiên cứu định tính.
  3. Phân biệt triệu chứng với nhu cầu.
  4. Chọn thay đổi nhỏ nhất giảm rủi ro hoặc tăng giá trị.
  5. Ghi tiêu chí kiểm chứng.
  6. Đưa quyết định vào roadmap hoặc policy.
  7. Đo lại sau thay đổi.

Trade-off

  • Độ tin cậy cao hơn thường tăng chi phí, độ phức tạp và thời gian thay đổi.
  • Phát hành nhanh hơn tăng tốc học nhưng có thể tăng rủi ro nếu blast radius lớn.
  • Tương thích ngược giảm gián đoạn nhưng kéo dài bảo trì.
  • Cảnh báo nhạy phát hiện sớm nhưng tạo nhiễu.
  • Tự động hóa giảm toil nhưng có thể tăng tác động nếu tự động sai.
  • Migration cưỡng bức kết thúc nhanh nhưng tăng rủi ro khách hàng.
  • Giữ dịch vụ cũ bảo vệ ngắn hạn nhưng hút capacity và tăng nợ dài hạn.

Không có điểm tối ưu phổ quát. Quyết định dựa trên tác hại, khả năng đảo ngược, nghĩa vụ, chi phí và bằng chứng.

Anti-patterns và red flags

Readiness và observability

  • PRR chỉ có checkbox.
  • Dashboard tồn tại nhưng không ai dùng khi incident.
  • Alert không có owner hoặc hành động.
  • SLI đo hạ tầng thay vì hành trình.
  • Không tách lỗi kỹ thuật khỏi lỗi dữ liệu.
  • Release rộng vì rollback “có vẻ dễ”.
  • PM tự chấp nhận ngoại lệ Security hoặc Legal.

Incident

  • Nhiều người cùng chỉ huy.
  • Lãnh đạo chen vào kênh kỹ thuật và giao lệnh trực tiếp.
  • PM hứa thời gian recovery không có bằng chứng.
  • Chờ root cause trước mitigation.
  • Tuyên bố resolved khi người dùng vẫn lỗi.
  • Đổi severity để giảm chú ý.
  • Postmortem tìm người gây lỗi.
  • Corrective action không có owner hoặc verification.

Support và roadmap

  • Mọi ticket thành backlog item.
  • Khách lớn tự động quyết priority.
  • Feature request được hiểu theo giải pháp nói ra.
  • Data issue bị gắn nhãn bug giao diện.
  • Support volume giảm được hiểu là chất lượng tăng dù người dùng có thể bỏ cuộc.
  • Reliability work bị giấu trong estimate.

Error budget và maintenance

  • Dùng error budget làm vũ khí giữa Product và Engineering.
  • Còn budget nên ship thay đổi rủi ro bất kỳ.
  • Hết budget nên dừng cả sửa bảo mật.
  • SLO đổi hồi tố để tránh vi phạm.
  • Maintenance không có owner.
  • Technical debt chỉ có tên, không có cơ chế tác động.

Deprecation và EOL

  • EOL chỉ là tắt hạ tầng.
  • Không có inventory client hoặc tích hợp.
  • Một thông báo cho mọi cohort.
  • Không có replacement hoặc migration.
  • Tương thích ngược vô hạn.
  • Xóa dữ liệu theo suy đoán.
  • Tắt monitoring cùng ngày EOL.
  • Ngoại lệ không có ngày kết thúc.
  • Tuyên bố tiết kiệm nhưng không đo chi phí còn lại.

Quick reference

Production Readiness Review

Mục Cần ghi
Scope Dịch vụ, release, cohort
Critical journeys Hành trình và tác động
Ownership Service Owner, on-call, escalation
SLI/SLO Định nghĩa, cửa sổ, nguồn dữ liệu
Telemetry Metrics, logs, traces, data checks
Alerts Điều kiện, owner, hành động
Capacity Tải, giới hạn, degradation
Dependencies Owner, mục tiêu, fallback
Change safety Rollout, flag, rollback, data compatibility
Incident Severity, command, communications
Support Runbook, taxonomy, training
Governance Security, Privacy, Legal, Data approvals
Decision Go, limited go, no-go, risk acceptance

Incident Brief

Mục Cần ghi
Incident ID Mã duy nhất
Severity/status Cấp và trạng thái
Impact Hành trình, cohort, dữ liệu
Timeline Bắt đầu, phát hiện, cập nhật
Command Incident Commander, lead
Mitigation Hành động giảm tác động
Recovery Trạng thái phục hồi
Communication Thông điệp và cập nhật tiếp
Unknowns Điều chưa rõ
Links Kênh, dashboard, ticket

Postmortem

Mục Cần ghi
Summary Điều xảy ra
Impact Khách hàng, dữ liệu, doanh nghiệp
Detection Cách và thời điểm phát hiện
Timeline Sự kiện và quyết định
Contributing factors Yếu tố kỹ thuật và tổ chức
What worked Hàng rào hiệu quả
What failed Khoảng trống
Corrective actions Cơ chế, owner, hạn
Verification Cách biết rủi ro đã giảm
Learning Thay đổi readiness, discovery, roadmap

Reliability Backlog

Mục Cần ghi
Risk Tình huống và tác động
Evidence SLO, incident, support, audit
Mechanism Cách hạng mục giảm rủi ro
Owner Người theo dõi
Input kỹ thuật Chi phí, phụ thuộc, phương án
Priority Giảm rủi ro so với chi phí cơ hội
Verification Test, SLI, drill, review
Status Planned, active, verified, rejected

Deprecation Plan

Mục Cần ghi
Scope và reason Điều ngừng, vì sao
Approver Người quyết định
Affected population Khách hàng, client, tích hợp
Replacement Giải pháp đích
Compatibility Cửa sổ và giới hạn
Migration Cohort, công cụ, kiểm tra
Communication Kênh, nhịp, owner
Data Export, retention, archive, deletion
Support Runbook, escalation
Milestones Deprecation, support end, EOL
Exit criteria Điều kiện qua từng mốc
Contingency Phương án khi chuyển đổi lỗi

EOL Checklist

  • [ ] Scope EOL rõ: sản phẩm, phiên bản, API, dữ liệu, hỗ trợ, khu vực.
  • [ ] Approver và decision log có bằng chứng.
  • [ ] Inventory người dùng, tích hợp và phụ thuộc đủ tin cậy.
  • [ ] Nghĩa vụ hợp đồng, pháp lý, bảo mật, quyền riêng tư và tài chính được chủ miền xác nhận.
  • [ ] Replacement và migration hoạt động.
  • [ ] Cửa sổ tương thích và hỗ trợ được công bố.
  • [ ] Truyền thông theo cohort, có theo dõi nhận và hành động.
  • [ ] Support có tài liệu, quyền và escalation.
  • [ ] Dữ liệu có kế hoạch xuất, retention, archive và deletion.
  • [ ] Điều kiện tắt và phương án dừng tắt rõ.
  • [ ] Hạ tầng, credential, tích hợp, billing, tài liệu và kênh bán được xử lý.
  • [ ] Monitoring xác nhận không còn lưu lượng ngoài dự kiến.
  • [ ] Trạng thái sau EOL và đầu mối khiếu nại rõ.
  • [ ] Bài học và chi phí tiết kiệm thực tế được rà lại.

Quy tắc ngắn

  • Deploy không đồng nghĩa release.
  • Release không đồng nghĩa launch.
  • Không có owner vận hành: chưa sẵn sàng.
  • Không đo được hành trình cốt lõi: chưa có SLI hữu ích.
  • Không có SLI: SLO chỉ là khẩu hiệu.
  • SLA cần chủ hợp đồng và Legal phê duyệt.
  • Incident ưu tiên mitigation rồi recovery; root cause đến sau.
  • Severity theo tác động, không theo độ khó sửa.
  • Support ticket là tín hiệu, không tự động là roadmap.
  • Error budget cần policy, không cần giáo điều.
  • Maintenance và reliability dùng roadmap capacity thật.
  • Technical debt cần tác động và cơ chế giảm rủi ro.
  • Deprecation cần migration.
  • EOL cần xử lý dữ liệu, nghĩa vụ và hạ tầng.
  • Tắt dịch vụ không đồng nghĩa được xóa dữ liệu.
  • Postmortem không có corrective action với owner và verification: chưa hoàn tất vòng học.

Thuật ngữ sử dụng trong chương

Thuật ngữ Giải nghĩa
Deploy Đưa mã, cấu hình hoặc tài nguyên vào môi trường
Release Mở thay đổi cho một nhóm người dùng
Launch Ra mắt có phối hợp nhiều chức năng
Operate Duy trì dịch vụ trong trạng thái chấp nhận được
Support Tiếp nhận và xử lý nhu cầu hỗ trợ
Retire Ngừng cung cấp khả năng hoặc dịch vụ
Production Readiness Review Đánh giá bằng chứng sẵn sàng vận hành thật
Telemetry Dữ liệu đo do hệ thống tạo và thu thập
Observability Khả năng suy ra trạng thái từ tín hiệu đầu ra
Service Level Indicator Chỉ số định lượng về mức dịch vụ
Service Level Objective Mục tiêu cho chỉ số mức dịch vụ
Service Level Agreement Cam kết mức dịch vụ với hậu quả đã thỏa thuận
Incident Sự cố cần phản ứng phối hợp
Incident Severity Cấp nghiêm trọng dựa trên tác động
Incident Commander Người điều phối và giữ quyền chỉ huy
Mitigation Hành động giảm phạm vi hoặc mức tác động
Recovery Khôi phục dịch vụ về trạng thái chấp nhận được
Postmortem Phân tích có cấu trúc sau sự cố
Corrective Action Hành động giảm xác suất hoặc tác động tái diễn
Support Triage Phân loại yêu cầu hỗ trợ vào đường xử lý đúng
Defect Sai khác giữa hành vi thực tế và dự kiến
Feature Request Yêu cầu khả năng chưa được hỗ trợ
Usability Issue Vấn đề khiến người dùng khó hoàn thành tác vụ
Data Issue Dữ liệu thiếu, sai, trễ hoặc không nhất quán
Operational Issue Vấn đề hiệu năng, khả dụng, tích hợp hoặc vận hành
Error Budget Mức không đạt SLO được chấp nhận
Reliability Investment Đầu tư làm giảm xác suất hoặc tác động thất bại
Maintenance Công việc giữ dịch vụ tiếp tục hoạt động
Technical Debt Chi phí hoặc rủi ro tương lai từ quyết định kỹ thuật
Roadmap Capacity Năng lực được phân bổ giữa các nhóm đầu tư
Deprecation Ngừng khuyến nghị và tiến tới ngừng hỗ trợ
Migration Chuyển người dùng, dữ liệu hoặc tích hợp sang trạng thái đích
Backward Compatibility Hỗ trợ client hoặc dữ liệu cũ sau thay đổi
Data Retention Chính sách giữ dữ liệu theo mục đích và thời hạn
Archive Lưu trữ dài hạn ngoài luồng vận hành chính
End-of-Life Mốc kết thúc cung cấp hoặc hỗ trợ
On-call Trực phản ứng theo ca hoặc ngoài giờ
Operational Review Rà soát định kỳ về sức khỏe và quyết định vận hành
Reliability Backlog Danh sách đầu tư độ tin cậy có bằng chứng và ưu tiên

Nguồn và giới hạn

Nguồn

  • Google Site Reliability Engineering cung cấp nền tảng về SLI, SLO, error budget, incident response, postmortem và cân bằng độ tin cậy với tốc độ thay đổi.
  • Google SRE Workbook cung cấp hướng áp dụng SLO, monitoring, incident và chính sách error budget.
  • Các khái niệm ITIL 4 hỗ trợ phân biệt incident, problem, service management, support, change và continual improvement.
  • Chương trình nghiên cứu DORA hỗ trợ tư duy đo hiệu quả giao phần mềm cùng độ ổn định, thay vì coi tốc độ và độ tin cậy luôn đối nghịch.

Các nguồn trên là nền tảng khái niệm. Chúng không tự tạo policy phù hợp cho từng công ty, sản phẩm, khách hàng hoặc miền rủi ro.

Giới hạn

  • Không có severity scale, SLO, error budget policy, cadence operational review hoặc thời hạn deprecation phổ quát.
  • Công thức và ví dụ chỉ minh họa cơ chế, không phải benchmark.
  • Hệ thống phần cứng, an toàn trọng yếu, tài chính, y tế và ngành chịu quản lý chặt cần assurance, audit và phê duyệt riêng.
  • SLO không thay đánh giá an toàn, bảo mật, quyền riêng tư, toàn vẹn dữ liệu hoặc nghĩa vụ hợp đồng.
  • Postmortem không thay quy trình nhân sự, pháp lý hoặc điều tra an toàn khi có hành vi cố ý hoặc nghĩa vụ báo cáo.
  • PM không tự quyết kiến trúc, trực kỹ thuật, điều khoản SLA, retention, deletion, bảo mật, pháp lý hoặc chấp nhận rủi ro ngoài thẩm quyền.
  • Đọc chương không chứng minh năng lực vận hành. Năng lực thực tế cần được kiểm tra qua diễn tập, shadow on-call, review artifact và quyết định có người có thẩm quyền giám sát.