Dấu hiệu không nên Deploy và cách từ chối bằng Data

Ở bài trước tôi có chia sẻ DevOps không phải là người deploy code, mà là người biết khi nào không nên deploy may mắn là có bạn khen hữu ích và mong chờ phần tiếp. Và cũng chính xác thì với những người làm hạ tầng lâu năm một chút, việc ngửi được mùi toang trước khi nó xảy ra là cực kỳ cần thiết.

Những lúc không được deploy

Nhiều release phải rollback không phải do code dở, mà do deploy đúng code vào sai thời điểm. Bài này sẽ là những tình huống tôi đã hứa làm ở phần trước mà chỉ cần bạn bấm deploy một cái là… bước luôn vào họp postmortem 😀

Hệ thống đang hồi phục sau sự cố

Ví dụ (sample cho mọi người dễ hiểu nhé):

HPA vừa scale từ 10 -> 40 pod
Cache hit rate tăng chậm
DB mới hết nghẽn connection pool
Error rate từ 20% vừa hạ xuống 3%

Nhìn vào thì ổn rồi, nhưng thật ra hệ thống chưa đứng vững. Deploy vào lúc này giống như ép người mới hết sốt đi chạy đua ấy.

Kết quả dễ thấy là:

Pod restart -> cache cold
DB reconnect hàng loạt
Latency bật tăng
Autoscaler hoảng loạn scale sai

Ai từng on-call nhiều sẽ thấy đây là vùng cực kỳ nguy hiểm.

Downstream đang bottleneck

Nhắc đến lại nhớ em trong team nói: “nhìn vào dashboard chính thấy xanh lè, em tưởng ok”. Nhưng:

Redis đang full evict
API thanh toán trả về chậm
Queue backlog tăng nhẹ
External service rate-limit đang chạm ngưỡng

Deploy vào lúc này = tăng connection burst + restart + mất session + tăng load đột biến -> Downstream sập theo cấp số nhân luôn.

Database đang chạy vacuum/reindex

Vacuum nặng hoặc reindex là chuyện rất bình thường, nhưng deploy đúng lúc này thì:

Pod restart -> spike query
Reindex chiếm I/O -> DB nghẽn
Migration fail -> rollback -> choke nặng hơn

Rất nhiều lần tôi thấy người ta nghĩ DB ổn, deploy xong mới thấy lỗi “why latency x4??”.

Vì vacuum + deploy = x2 nỗi đau :))

Autocaler vừa scale mạnh nhưng chưa ổn định

HPA scale từ 5 -> 25 pod nhưng:

Cache chưa warm
Node CPU còn căng
Pod mới đang pull image
Request retry đang còn dư âm

Nếu deploy đúng lúc này: restart toàn bộ pod -> warm lại từ đầu -> autoscaler mất baseline -> crash loop.

Autoscale xong không nghĩa là an toàn để deploy ngay. Hãy đợi hệ thống bình ổn trở lại.

Traffic đang chuẩn bị bước vào peak

Giờ ăn trưa, giờ tan làm, flash sale, livestream, add-to-cart giờ vàng…v.v. Peak là peak. Không cần giải thích.

Deploy vào peak = toang. Không có lý do nào thuyết phục.

Cho nên policy đúng thường là:

Không deploy từ 9h-11h
Không deploy từ 19h-22h
Freeze toàn bộ trước big event, big sale, Tết, lương về

Startup cũng cần freeze window, không chỉ enterprise.

Làm sao từ chối deploy mà không bị nghĩ là DevOps cản trở tiến độ?

Nhiều DevOps biết rõ hệ thống đang yếu. Cái này nhiều lúc cũng phải nói với mấy em trong team là đừng ngại từ chối nếu có lý do chính đáng thì cứ mạnh dạn. Nhưng nhiều lúc ngại nói không

Sợ bị dev nghĩ mình làm khó.
Sợ PM nghĩ mình chậm tiến độ.
Sợ sếp nghĩ mình “không chủ động”.

Điểm mấu chốt là: Không bao giờ từ chối bằng cảm tính chỉ từ chối bằng dữ liệu.

Dưới đây là cách tôi hay làm, và rất hiệu quả (với tôi và team):

Luôn đưa ra lý do bằng metric, nói chung chung là tự sát

Đừng nói: Em thấy chưa ổn, deploy hơi nguy hiểm

Hãy nói:

Cache hit rate đang 45%, deploy bây giờ sẽ làm cold cache lại từ đầu.
DB đang vacuum table orders, deploy vào có thể làm spike connection.
HPA vừa scale 200% trong 3 phút, em chờ nó ổn định lại.

Có metric -> không ai kêu bạn được.

Đừng từ chối, hãy đề xuất thời điểm an toàn hơn

Không nói: Không deploy được

Hãy nói: Deploy được, nhưng an toàn nhất là sau X phút khi latency về mức bình thường

Từ chối kiểu này = không gây xung đột, vẫn giữ được chuyên môn.

Đừng làm mình thành người cản trở hãy làm mình thành người bảo vệ team

PM rất sợ câu: Không deploy.

Nhưng họ lại rất tin câu:

Nếu deploy bây giờ, rủi ro downtime tăng gấp 4 lần.
Để hệ thống ổn định rồi deploy là tốt nhất cho user.

Đặt lợi ích user lên trước -> ai cũng nghe.

Tránh nói dựa trên cảm giác chỉ nói dựa trên hành vi hệ thống

Ví dụ:

Error rate đang dao động -> chưa deploy
CPU đang tránh peak nhưng chưa ổn định -> chưa deploy
Downstream đang chậm -> chưa deploy
Cluster vừa scale -> chưa deploy

Chỉ cần nói điều hệ thống đang làm -> không ai nghĩ bạn cản trở.

Cuối cùng: tôi luôn giữ một nguyên tắc sống còn

DevOps không được trả lương để deploy nhanh.
DevOps được trả lương để không deploy sai thời điểm.

Và sai thời điểm = cả team trả giá.

Cũng nhiều phết rồi

Tổng kết lại kinh nghiệm là:

Không deploy theo cảm tính
Không deploy vì áp lực
Không deploy vì “dev nói ổn”
Chỉ deploy khi hệ thống cho phép

Ranh giới giữa một DevOps khó tính, cản trở và một DevOps có tâm, có tầm nằm ở cách bạn giao tiếp (chắc thế). Khi bạn từ chối deploy kèm theo một dashboard đầy đủ metric và một giải pháp thay thế an toàn hơn, bạn đang dạy cho cả team cách tôn trọng hệ thống 😀