Launch và Handover: checklist go-live sống sót

Launch là khoảnh khắc dự án gặp người dùng. Nếu làm tốt, launch sẽ có cảm giác tẻ nhạt - vì cả team đã tập luyện trước. Nếu làm tệ, team sẽ học được cùng lúc rằng mọi giả định đều sai. Chương này giới thiệu ba artifact (checklist, rollback, handover) giúp biến những launch tẻ nhạt đó trở thành đáng tin cậy.

Khi nào quy trình launch chính thức mang lại giá trị?

Có ba tín hiệu chính.

Có thay đổi mà người dùng nhìn thấy. Bất cứ thứ gì khách hàng có thể thấy đều cần một cửa sổ launch kèm rollback. Còn thay đổi chỉ nội bộ thì có thể nhẹ tay hơn.

Không thể đảo ngược nếu không tốn công. Migration schema database, backfill data, đổi billing. Một khi đã ship, việc undo có thể tốn nhiều giờ hoặc nhiều ngày. Launch checklist là tấm bảo hiểm.

Cần phối hợp xuyên team. Marketing thông báo, customer support sẵn sàng, on-call standby. Nếu không có một plan launch viết ra, một trong ba bên sẽ quên việc của mình.

Còn với một rollout feature flag chỉ 1% user và không đụng data, launch chỉ đơn giản là "flip flag, xem dashboard" - không cần artifact chính thức.

Cái giá khi bỏ qua các artifact của launch là gì?

Có ba kiểu lỗi thường gặp.

Rollback bất ngờ. Engineering ship, customer support bị page vì khách bối rối, email marketing đi đúng theo plan, và chẳng ai biết là có rollback hay không. Phối hợp sụp đổ ngay tại chỗ.

Page lúc 3 giờ sáng đến nhầm người. Khi không có doc handover, engineer on-call nhận page mà không có ngữ cảnh gì cả. Mean time to recovery tăng gấp đôi.

Stakeholder bị sốc. Một launch mà sponsor mong đợi vào thứ Hai lại ship vào thứ Tư vì có dependency không được viết ra. Niềm tin bào mòn; team phải xin lỗi mà không có lời giải thích đủ thuyết phục.

Go-live checklist tối thiểu trông thế nào?

# Go-Live Checklist — {{ Tính năng / Dự án }}

## Trước launch (T-2 ngày)
- [ ] Feature flag tạo và mặc định off
- [ ] Script migration test ở staging hai lần
- [ ] Plan rollback viết và review (xem dưới)
- [ ] Lịch on-call cho cửa sổ launch xác nhận
- [ ] Runbook customer support cập nhật; team CS được brief
- [ ] Báo stakeholder gửi (email + channel #launches)

## Cửa sổ launch (T-0)
- [ ] Deploy artifact lên production
- [ ] Smoke test pass
- [ ] Flag bật cho user nội bộ (1%)
- [ ] Dashboard metric xanh 30 phút
- [ ] Flag bật cho 10% user
- [ ] Metric xanh 60 phút
- [ ] Flag bật cho 100% user
- [ ] Thông báo gửi

## Sau launch (T+24h)
- [ ] Không sự cố mới gắn launch này
- [ ] Volume ticket support bình thường
- [ ] Metric hiệu năng trong target
- [ ] Doc handover hoàn tất và gán
- [ ] Channel dự án archive; channel ops có owner

## Plan rollback
**Trigger**: error rate > 0.5% kéo dài 5 phút, HOẶC latency p99
> 2x baseline kéo dài 10 phút, HOẶC volume khiếu nại khách
> 10x baseline.

**Bước** (mục tiêu: < 30 phút):
1. Đặt feature flag off (1 phút)
2. Verify metric về baseline (5 phút)
3. Nếu có migration: chạy migration rollback (10 phút)
4. Báo stakeholder + support (5 phút)
5. Mở channel sự cố cho root cause analysis

**Owner trong cửa sổ launch**: {{ tên on-call lead }}

Có hai chi tiết đáng chú ý. Một là phần "Trước launch" được check trước 48 giờ, để các gap còn lộ ra sớm. Hai là trigger rollback có ngưỡng cụ thể chứ không phải "nếu cảm thấy hỏng"

• chính sự cụ thể đó dừng được tranh cãi trong lúc sự cố.

Doc handover ops trông thế nào?

# Handover Ops — {{ Tính năng }}

## Ai sở hữu cái này trong production
Team: {{ Tên team }}
Lịch on-call: {{ link PagerDuty }}

## Tóm tắt kiến trúc
{{ Mô tả một đoạn hệ + link Mermaid }}

## Vấn đề thường gặp và fix
| Dấu hiệu | Nguyên nhân | Fix |
|----------|-------------|-----|
| 500 trên /refund | Stripe sandbox flake | Retry; check Stripe status |
| Tải trang chậm /orders | Đỉnh cache miss | Đợi 5 phút cache warm |

## Dashboard
- Metric service: {{ link Grafana }}
- Metric nghiệp vụ: {{ link }}
- Log lỗi: {{ link }}

## Runbook
- Refund fail: {{ link }}
- Rollback migration: {{ link }}

## Escalation
- P1 (down): page on-call; tag #incident
- P2 (xuống cấp): mở ticket; phản hồi trong 4 giờ
- P3 (mỹ phẩm): backlog

## Out of scope (cái team này KHÔNG sở hữu)
- Tích hợp payment provider (Team Platform)
- Giao email (Team Comms)

Đây là tài liệu mà engineer on-call sẽ mở ra lúc 3 giờ sáng. Hãy giữ nó ngắn gọn, có thể copy-paste vào Slack, và đặt nhiều link để dẫn tới chi tiết.

Launch scale lên đa team như thế nào?

sequenceDiagram
    participant PM as PM
    participant Eng as Engineering
    participant Mkt as Marketing
    participant CS as Customer Support
    participant On as On-call
    PM->>Eng: T-7 ngày: review sẵn sàng launch
    Eng->>PM: Xác nhận checklist xanh
    PM->>CS: T-3 ngày: brief team support
    PM->>Mkt: T-2 ngày: xác nhận comms lên lịch
    PM->>On: T-1 ngày: xác nhận phủ
    Eng->>On: T-0: deploy + ramp
    On->>PM: T+24h: handover hoàn tất

Mỗi team đảm nhận một bước trong chuỗi launch kèm hạn cụ thể. PM đứng ra phối hợp; mỗi team có checklist riêng của mình. Chương stakeholder sẽ nói về nhịp comms xung quanh launch.

Quy trình launch có thể tạo ra những lỗi nào?

• Checklist hoá thành kịch. Các ô tick được check mà không làm việc tương ứng. Cách phòng: mỗi ô bắt buộc đính kèm link hoặc screenshot làm bằng chứng.
• Rollback chưa từng được test. Plan tồn tại trên giấy nhưng team chưa hề tập. Cách phòng: chạy diễn tập rollback trên staging hàng quý.
• Không ai xem metric. Launch xảy ra, team đi ăn trưa, metric nhảy ngay trong giờ đó. Cách phòng: chỉ định người xem on-call rõ tên trong checklist cho cửa sổ launch.
• Doc handover copy mà không cập nhật. Dự án mới copy doc handover của dự án trước rồi không cập nhật phần kiến trúc hay owner. Cách phòng: PM review doc handover như một phần của khâu đóng dự án.

Khi nào nghi lễ launch là quá liều?

Có hai trường hợp.

Tool nội bộ chỉ có 5 người dùng. Một thay đổi cho dashboard admin của chính team không cần cửa sổ comms 48 giờ.

Có thể đảo ngược chỉ bằng env var. Một thay đổi chỉ mức config mà bạn revert được trong 30 giây không phải là một launch; nó chỉ là một cú config push. Hãy ghi lại lệnh revert và ship.

Quy trình launch đáng tốn overhead khi scope ảnh hưởng tới user, khi không thể đảo ngược, hoặc khi có phụ thuộc xuyên team. Dưới mức đó, một quy trình nhẹ là đủ.

Đi tiếp từ đây như thế nào?

Chương tiếp theo: incident và rollback - những gì xảy ra khi checklist launch không đủ và có thứ gì đó vỡ. Sau đó, retrospective và post-mortem sẽ biến bài học thành thay đổi cho dự án kế tiếp.