The Phoenix Project: cuốn tiểu thuyết dạy FDE nhìn sự cố từ phía vận hành

Cuốn sách bắt đầu bằng chuyện nhân viên không nhận được lương đúng hạn. Một thay đổi không được duyệt đã làm sập hệ thống lương của Parts Unlimited. Ai từng ở một khách hàng vào ngày production gặp sự cố sẽ thấy cảnh này quen thuộc.

The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win do Gene Kim, Kevin Behr và George Spafford viết, IT Revolution xuất bản lần đầu ngày 10/1/2013. Sách viết như tiểu thuyết, nhưng thứ nó dạy là cách vận hành.

Lý do FDE nên đọc khá đơn giản. Phần lớn thời gian ở khách hàng, bạn làm việc trong hệ thống của người khác, với đội vận hành của người khác, theo quy trình thay đổi của người khác. Cuốn sách giúp bạn hiểu vì sao họ chậm và bạn có thể giúp gì.

Một kỹ sư giỏi có thể làm cả hệ thống tắc

Nhân vật chính là Bill, quản lý IT. CEO giao cho anh 90 ngày để dọn dẹp mớ hỗn độn, nếu không cả phòng ban sẽ bị thuê ngoài.

Nhà xuất bản giới thiệu sách là nơi học Three Ways và Theory of Constraints, hai nguyên tắc nền của DevOps. John Willis gọi nó là phiên bản hiện đại của The Goal, cuốn tiểu thuyết về Theory of Constraints của Goldratt.

Bài này chỉ đi qua First Way và Second Way, hai cách FDE chạm vào nhiều nhất ở khách hàng; Third Way nằm ngoài phạm vi bài. Ba ý đáng giữ dưới đây cũng không phải Three Ways: hai ý dựa trên hai cách đầu, ý còn lại đến từ chuyện kiểm soát thay đổi.

Nhân vật đáng nhớ nhất là Brent. Bản tóm tắt chính thức của IT Revolution mô tả anh là kỹ sư giỏi nhưng quá tải. Vì luôn bị kéo vào chữa cháy, chuyên môn của Brent trở thành nút thắt cổ chai của cả tổ chức.

Nhân vật Erik đưa ra lời khuyên: giảm công việc đang dở (WIP) để tăng hiệu suất và thông lượng. Ghép với Brent, lời khuyên này có nghĩa cụ thể. Nếu mọi việc đều phải đi qua anh, mỗi việc mới thả vào chỉ xếp thêm vào hàng trước mặt anh, không việc nào xong nhanh hơn.

Giảm WIP vì thế là ngừng đẩy việc vào nhanh hơn tốc độ nút thắt xử lý được. Đó cũng là tinh thần First Way mà Gene Kim tóm tắt: nhìn hiệu năng của toàn hệ thống chứ không phải từng silo. Sandor Dargo, một kỹ sư viết về cuốn sách, nhắc lại bài học nhà máy: giữ lượng việc đang dở ở mức nhỏ.

Hãy thử hình dung một tình huống. Đội data của khách hàng có một người duy nhất hiểu pipeline cũ, và mười ticket đang chờ người đó.

Bạn mở thêm ticket thứ mười một cho tích hợp của mình thì cũng chỉ làm hàng đợi dài thêm. Nên làm ngược lại: ghi lại những gì người đó biết thành tài liệu, rồi tự làm phần bạn làm được mà không cần họ.

Việc không có kế hoạch đến từ đâu?

Trang sách của nhà xuất bản nhấn mạnh bốn loại công việc. Theo Dargo, hai loại đầu là dự án kinh doanh và dự án IT nội bộ. Chúng sinh ra thay đổi, và thay đổi thường được theo dõi trong hệ thống ticket.

Loại thứ tư là unplanned work, được định nghĩa là những việc gấp, mang tính phản ứng, chen vào việc đã lên kế hoạch và làm tiến độ chậm lại.

Sự cố hệ thống lương cho thấy unplanned work thường bắt nguồn từ đâu: một thay đổi không được phép. Sau đó Bill lập Change Advisory Board (CAB) để xem xét và duyệt các thay đổi lên hệ thống IT.

Chuỗi nhân quả đáng nhớ là thế này. Thay đổi không được kiểm soát quay lại dưới dạng unplanned work, và lượng việc đó lại dồn lên những người như Brent, đúng nút thắt vốn đã quá tải.

Với FDE, có một điều nên làm sớm. Tuần đầu ở khách hàng, hãy hỏi quy trình duyệt thay đổi của họ trước khi deploy bất cứ thứ gì. Nếu bạn là người gây ra sự cố hệ thống lương tiếp theo, khách hàng sẽ không còn tin bạn.

Phản hồi phải chảy ngược về phía người viết code

Second Way là tạo vòng phản hồi từ phải sang trái, tức từ vận hành ngược về phát triển. FDE ở đúng điểm nối này. Bạn nhìn thấy sản phẩm hỏng thế nào trong môi trường thật, còn đội sản phẩm ở trụ sở thì không thấy.

Khi một sự cố ở khách hàng kết thúc, đừng dừng ở chỗ hệ thống đã chạy lại. Hãy viết cho đội core một ghi chú ngắn gồm ba phần: thay đổi nào gây ra sự cố, mất bao lâu để phát hiện, và nên sửa gì trong sản phẩm để lần sau không phải chữa cháy.

Đọc theo thứ tự nào, và ghi vào CV ra sao?

Tim O’Reilly viết rằng mọi người từng tham gia một dự án IT thất bại đều nên bị buộc đọc cuốn sách này. Lời khuyên hơi quá, nhưng nếu bạn từng trải qua một dự án hỏng, nhiều cảnh trong sách sẽ quen đến mức khó chịu.

Nên đọc The Phoenix Project trước vì dạng tiểu thuyết dễ đọc. Gene Kim nêu The DevOps Handbook là nơi áp dụng tiếp Three Ways, nên đó là cuốn thứ hai. The Goal để sau cùng, nếu bạn muốn biết ý tưởng dòng chảy đến từ sản xuất ra sao.

Trong CV, đừng ghi chung chung “Có kinh nghiệm vận hành và DevOps”. Hãy viết việc cụ thể, chẳng hạn: “Viết runbook cho pipeline cũ mà chỉ một kỹ sư của khách hàng hiểu, để đội họ tự xử lý sự cố thường gặp.”

Câu đó cho người tuyển dụng thấy bạn nhận ra nút thắt và gỡ được nó. Nếu có số liệu thật về số ticket hay thời gian chờ trước và sau, hãy thêm vào.

Bill có 90 ngày để cứu phòng IT. Một FDE thường có ít thời gian hơn để giành được lòng tin của khách hàng, và cách nhanh nhất vẫn là không trở thành một thay đổi không được duyệt.