DevOps không phải là người deploy code, mà là người biết khi nào không nên deploy

Cuối tuần ngồi chill một tuần hệ thống chạy ổn định. Trong đầu mang nhiều suy nghĩ xin phép chia sẻ một chút kinh nghiệm cá nhân, tám chuyện là chính vì trong phạm vi một bài viết đảm bảo mọi góc nhìn là điều rất khó

Tôi thấy rất nhiều công ty nghĩ DevOps chỉ có nhiệm vụ deploy kiểu bấm nút là xong. Nghĩ là DevOps phải deploy nhanh, không delay release, push code liền tay. Nhưng thực tế khi chạy production một thời gian với kinh nghiệm của tôi thì

Một DevOps giỏi không được đánh giá ở chỗ deploy nhanh, mà ở chỗ biết lúc nào không được deploy.

Nghe thì trái tai nhưng đó là thứ làm nên sự khác biệt giữa DevOps junior và DevOps biết sống sót trong môi trường on-call thật.

Deploy đúng lúc thì chẳng ai khen, deploy sai lúc thì cả team họp

Có lần hệ thống tôi đang phục hồi sau một đợt traffic spike. CPU cluster vừa giảm xuống một chút, cache chưa warm đủ, DB vừa scale xong mà chưa ổn định connection. Dev push một hotfix nhỏ, tưởng đơn giản.

NHƯNG với kinh nghiệm cá nhân tôi thấy nếu deploy lúc đó thì:

Cache cold toàn bộ
Latency tăng
DB query spike trở lại
Service chết vòng lặp restart

Nên tôi dừng lại và nói thẳng ông Dev: Giờ chưa deploy được đâu, hệ thống còn yếu

Tôi nói thêm câu cho ông Dev hiểu ngay: Chẳng có ai yếu mà đem đi mổ cả :))

NHƯNG thực sự không phải anh em nào trong team hiểu được và cũng không ai thích nghe câu đó. Nhất là mấy anh em Dev vì anh em cũng cùng chờ hệ thống xem có vấn đề gì không để fix nhanh chóng.

Và chuẩn nói xong 15 phút thì chính anh em Dev bảo: “May lúc đó anh chưa deploy thật”

Rất nhiều sự cố đến từ việc… deploy đúng code nhưng sai thời điểm

Đừng nghĩ deploy lỗi là do code lỗi. Rất nhiều sự cố production mà tôi từng gặp là:

Deploy khi traffic đang ở mức bất thường
Deploy ngay sau sự cố chưa hoàn toàn phục hồi
Deploy khi downstream service đang nghẽn
Deploy trong lúc autoscaler vừa scale lên chưa kịp ổn định
Deploy khi DB đang chạy vacuum, migration hoặc reindex

Có code sạch đến mấy mà deploy vào thời điểm xấu thì cũng toang như thường.

DevOps phải nhìn hệ thống theo nhịp, không chỉ theo pipeline

Để biết khi nào không nên deploy, bạn phải:

Nhìn được traffic pattern trong ngày
Biết window nào hệ thống hay mất ổn định
Biết service nào là bottleneck, service nào dễ choke
Biết DB có đang có maintenance background không
Biết autoscaling có đang scale sai không
Biết downstream đang bị chậm, chứ bản thân API chưa lỗi

Nói cách khác, DevOps phải “cảm” được hệ thống, pipeline tự động thì ai làm cũng được, nghe thì cũng to tát thật nhưng đúng là cảm được hệ thống thì chỉ những người từng on-call đủ lâu mới có.

Ngay kể cả lúc trao đổi với ông bạn của tôi, tôi vẫn bảo với cái “sở thích” của ông thì cứ thị phạm để mọi người vào xem. Vì tôi biết có những bạn sẽ vào vì thấy chê bai và khi đọc có thể thêm góc nhìn vì những người vừa biết một tý mặt thường ngước ra tận đằng sau lưng, tôi trải qua rồi :))

Nhiều anh em trên này nữa, cũng viết vì tâm huyết muốn mọi người tốt lên có thêm những góc nhìn, kiến thức hữu ích nên có nhiều ông tư tưởng giống tôi là thôi ẩn danh thích thì chia sẻ giúp được ai thì giúp chứ khơi khơi người ta lại nói mình cầu công danh, đánh bóng tên tuổi :))

DevOps giỏi theo tôi là người dám nói: “Không deploy lúc này”

Nhiều nơi DevOps bị xem là người phải deploy theo yêu cầu.

Dev yêu cầu là deploy
PM yêu cầu là deploy
CEO cũng có thể yêu cầu deploy gấp

Nhưng lúc hệ thống đang bấp bênh, nếu bạn vẫn deploy chỉ để làm hài lòng mọi người thì:

Production toang
DevOps bị gọi đầu tiên
Dev phải rollback
PM delay
CEO khó chịu
User phàn nàn

Và tất cả bắt đầu từ một quyết định DevOps không đủ dứt khoát.

Một DevOps trưởng thành phải dám nói: Khoan. Để tôi xem metric đã. Nếu không an toàn thì không deploy

Không deploy đôi khi là cách bảo vệ hệ thống… và bảo vệ chính DevOps Engineer

Làm DevOps mệt nhất không phải deploy nhiều, mà deploy sai thời điểm rồi bị kéo vào cuộc họp nhiều tiếng chỉ để nghe lại lỗi mà ai cũng biết.

Cấm deploy khi:

Metric chưa ổn định
Batch job đang chạy
Migration đang chạy nền
DNS chưa propagate
Cache miss quá nhiều
Traffic peak đang tới
Team đang thiếu người trực on-call backup

Đó không phải chậm tiến độ, đó là điều cần làm để tránh sập hệ thống theo kiểu biết ngỏm mà vẫn đâm đầu.

Chắc vậy thôi nghĩ ra thì viết tiếp

DevOps không phải người chỉ làm nhiệm vụ deploy hay chỉ điều khiển pipeline. DevOps là người giữ nhịp hệ thống, đảm bảo mọi thứ không gãy trong lúc cả team muốn chạy nhanh hơn.

Thế nên: DevOps giỏi không phải người deploy nhanh nhất, mà là người biết lúc nào không nên deploy nhất.

Ai từng on-call rồi sẽ hiểu điều này, tuy nhiên với những hệ thống nhỏ hoặc không yêu cầu SLA cao thì cũng sẽ ít gặp vậy nên mong mọi người thêm góc nhìn.

Để sang tuần ngồi tổng hợp chia sẻ thêm các tình huống thực tế bắt buộc KHÔNG được deploy hoặc cách thiết lập policy freeze window để bảo vệ hệ thống nhé. Have a nice weekend 😀