Accelerate: bốn chỉ số giúp FDE đo tốc độ và độ ổn định khi triển khai phần mềm
Ra đời từ năm 2018, cuốn sách của Nicole Forsgren, Jez Humble và Gene Kim giúp bạn trả lời bằng số liệu câu khách hỏi nhiều nhất: đội mình đưa thay đổi lên production nhanh và chắc đến đâu.
Tóm tắt nhanh
- Accelerate (IT Revolution, 27/3/2018) dựa trên bốn năm nghiên cứu với dữ liệu từ các báo cáo State of DevOps.
- Bốn chỉ số gồm tần suất deploy, lead time từ commit đến production, tỷ lệ deploy gây lỗi và thời gian khôi phục dịch vụ.
- DORA nay chia chỉ số thành nhóm throughput và nhóm instability, và đã thêm deployment rework rate thành năm chỉ số.
Đặt hai cột cạnh nhau để không ai khoe tốc độ mà giấu cái giá của sự cố.
Đồ hoạ: FDE Times
Rất nhiều cuộc họp với khách hàng mắc kẹt ở cùng một câu: “Đội mình deploy chậm quá.” Chậm so với cái gì? Chậm bao nhiêu? Không ai trong phòng có con số. Accelerate là cuốn sách dạy bạn biến câu than đó thành bốn con số mà ai cũng kiểm chứng được.
Ba tác giả là Nicole Forsgren, Jez Humble và Gene Kim. Phụ đề của sách hứa hẹn một cách tiếp cận khoa học với Lean và DevOps, nhằm xây dựng và mở rộng những tổ chức công nghệ hiệu suất cao. Sách do IT Revolution phát hành ngày 27/3/2018 và từng nhận giải Shingo Publication Award.
Với một FDE, giá trị của sách không nằm ở tuổi đời mà ở kỹ năng nó luyện: đo năng lực triển khai phần mềm của một tổ chức trước khi đề xuất bất cứ điều gì. Bạn ngồi ở site khách, và câu hỏi đầu tiên luôn là đội của họ đang ở đâu.
Cuốn sách đứng trên dữ liệu nào?
Theo trang giới thiệu của IT Revolution, sách là kết quả của bốn năm nghiên cứu, dùng dữ liệu thu thập từ các báo cáo State of DevOps. Nhà xuất bản hứa hẹn người đọc sẽ biết cách đo hiệu suất đội của mình và biết nên đầu tư vào năng lực nào.
Đứng sau những con số ấy là DORA, một chương trình nghiên cứu kéo dài nhiều năm và theo chuẩn mực học thuật. Ngay từ báo cáo năm 2015, DORA đã ghi nhận rằng các tổ chức IT hiệu suất cao bỏ xa đối thủ ở bốn chỉ số then chốt về triển khai phần mềm. Accelerate là nơi những phát hiện ấy được kể lại thành sách.
Bốn con số, tính thử trên một khách hàng
Google Cloud, khi giới thiệu bộ “Four Keys” của DORA, định nghĩa bốn chỉ số như sau. Deployment Frequency là tổ chức release thành công lên production thường xuyên đến đâu. Lead Time for Changes là thời gian để một commit vào được production.
Change Failure Rate là tỷ lệ phần trăm deploy gây lỗi trên production. Time to Restore Service, còn gọi là MTTR, là thời gian để tổ chức phục hồi sau một sự cố trên production.
Thử hình dung bạn vừa đến một công ty logistics. Trong 30 ngày, đội của họ có 20 lần deploy thành công lên production. Deployment Frequency là 20 lần/30 ngày, tức trung bình cứ một ngày rưỡi lại có một lần release.
Trong 20 lần đó, 3 lần gây sự cố, nên Change Failure Rate là 3/20, tức 15%. Lead time thì đừng đo trên một commit đơn lẻ: hãy tính cho từng thay đổi rồi lấy trung vị. Giả sử trung vị ra khoảng bốn ngày, tức một commit điển hình viết sáng thứ Hai, đến chiều thứ Sáu mới tới khách.
Thời gian khôi phục cũng vậy. Ba sự cố mất lần lượt 30 phút, 1 giờ và 6 giờ. Trung vị là 1 giờ, trung bình là 2,5 giờ; lấy riêng ca 6 giờ làm “thời gian khôi phục” là vẽ đội khách tệ hơn thực tế. Ca tệ nhất đáng được kể riêng như một câu chuyện, không phải như chỉ số.
Có bốn con số đó, cuộc họp đổi hẳn tính chất. Thay vì “deploy chậm”, bạn nói “commit điển hình mất bốn ngày mới tới khách, và cứ 20 lần deploy thì 3 lần gây sự cố”. Đó là một vấn đề có thể khoanh vùng, chứ không còn là một cảm giác.
Ba ý sẽ theo bạn tới site khách
Bài học đầu tiên rất đơn giản: đo trước, rồi mới đề xuất. Lời hứa của sách là giúp bạn biết nên đầu tư năng lực nào, và điều đó chỉ đúng khi bạn có số liệu nền. Ở site khách, việc đầu tiên nên làm là lấy log deploy và lịch sử sự cố, chưa vội bàn công cụ.
Ý tiếp theo đến từ cách DORA hiện tổ chức bộ chỉ số: một nhóm cho thấy throughput của thay đổi phần mềm, một nhóm cho thấy instability. Đọc cả hai nhóm cùng lúc giúp bạn tránh cái bẫy quen thuộc: tăng số lần deploy rồi tuyên bố thắng lợi, trong khi tỷ lệ sự cố cũng tăng theo.
Ý cuối là ngôn ngữ chung với quản lý. IT Revolution nói thẳng sách này lý tưởng cho quản lý ở mọi cấp. FDE thường phải thuyết phục cả CTO lẫn trưởng nhóm vận hành, và bốn chỉ số là thứ cả hai phía đều đọc được mà không cần giải thích kiến trúc.
Vì sao nên mở dora.dev trước khi mở sách?
“Bốn chỉ số” là con số của giai đoạn 2018. DORA đã mở rộng lên năm chỉ số, thêm deployment rework rate. Nếu bạn trích sách trong buổi họp với khách mà không biết thay đổi này, người nghe kỹ tính sẽ bắt lỗi ngay.
Vì thế, thứ tự hợp lý là đọc trang “DORA metrics: the four keys” trên dora.dev trước để nắm định nghĩa hiện hành. Sau đó mới đọc Accelerate để hiểu vì sao những con số này đáng tin. Cuối cùng xem bài “Using the Four Keys to measure your DevOps performance” của Google Cloud để thấy cách người ta đo trong thực tế.
Sách hợp nhất với developer 2-8 năm kinh nghiệm đã quen CI/CD nhưng chưa bao giờ phải giải thích cho người ngoài kỹ thuật vì sao pipeline quan trọng. Nếu bạn đang nhắm vai FDE, đây là bước chuyển từ người “biết deploy” sang người “đo được năng lực deploy của cả tổ chức”.
Log thật không bao giờ sạch: thử một bài tập
Log deploy ở site khách hiếm khi gọn như ví dụ trên. Dưới đây là một tuần log giả định, cố tình lộn xộn. Hãy tự tính đủ bốn chỉ số, rồi mới đọc phần đáp án bên dưới.
| Thời điểm deploy | Môi trường | Kết quả | Commit sớm nhất | Ghi chú |
|---|---|---|---|---|
| T2 09:10 | production | thành công | CN 22:00 | — |
| T2 09:12 | production | thành công | CN 22:00 | job chạy lại, trùng bản |
| T3 14:00 | staging | thành công | T3 10:00 | — |
| T4 16:30 | production | hỏng ở pipeline | T4 11:00 | không lên được |
| T4 17:45 | production | thành công | T4 11:00 | gây sự cố, khôi phục 18:30 |
| T6 10:00 | production | thành công | T5 15:00 | — |
Đáp án: làm sạch trước, tính sau
Bước làm sạch quyết định mọi thứ. Bỏ dòng chạy lại trùng bản, bỏ staging, và bỏ lần hỏng ở pipeline vì nó chưa từng tới production. Còn lại 3 lần release thành công, nên tần suất deploy là 3 lần/tuần.
Một trong ba lần gây sự cố, nên tỷ lệ deploy gây lỗi là 1/3, khoảng 33%. Lead time của ba lần lần lượt là 11 giờ 10 phút, 6 giờ 45 phút và 19 giờ, trung vị 11 giờ 10 phút.
Thời gian khôi phục là 45 phút. Nếu bạn đếm nhầm thành 6 lần deploy, tần suất phồng lên gấp đôi, tỷ lệ lỗi tụt còn khoảng 17%, và đội khách trông ổn định gấp đôi thực tế.
Biến nó thành lợi thế khi đi xin việc
Khi đọc JD FDE hay solutions engineer, hãy để ý các cụm như “deployment”, “time to production” hay “đo lường hiệu quả triển khai”. Đó là tín hiệu nhà tuyển dụng cần người nói được bằng số liệu.
Trong CV, một dòng như “rút lead time trung vị từ commit đến production từ bốn ngày xuống dưới một ngày” có sức nặng hơn hẳn “có kinh nghiệm DevOps”. Số liệu phải là của chính bạn, đo trên dự án thật, và bạn phải giải thích được mình đã làm sạch log ra sao khi bị hỏi.
Accelerate không dạy bạn viết pipeline nào. Nó dạy bạn bước vào một tổ chức xa lạ và trong tuần đầu đã biết họ đang đứng ở đâu, đúng thứ khách trả tiền để FDE mang đến.