Release It! của Michael Nygard: sách gối đầu cho FDE phải sống trong production của khách

Theo trang giới thiệu của nhà xuất bản, 80% chi phí vòng đời một dự án phần mềm nằm ở production, vậy mà rất ít sách chịu viết về giai đoạn này. Release It! của Michael Nygard được viết để lấp đúng khoảng trống đó.

Với một FDE, câu trên gần như là mô tả công việc. Bạn không deploy vào một cluster sạch sẽ do team mình kiểm soát, mà vào môi trường của khách, nơi có API cũ, database không ai dám đụng và mạng nội bộ chập chờn. Hiếm có cuốn sách nào dạy kỹ như cuốn này về cách giữ hệ thống đứng vững khi những thứ xung quanh nó hỏng.

Một cuốn sách viết cho người sợ bị gọi dậy lúc nửa đêm

Bản đầu tiên ra năm 2007. Bản hiện hành là Release It! Second Edition: Design and Deploy Production-Ready Software, do Pragmatic Bookshelf phát hành tháng 1/2018, dày 376 trang (ISBN 9781680502398). Nhà xuất bản giới thiệu Nygard là người đã làm lập trình viên và kiến trúc sư chuyên nghiệp hơn 15 năm.

Lời chào hàng của nhà xuất bản rất thẳng: nếu bạn là developer và không muốn suốt đời bị alert réo mỗi đêm thì cuốn sách này dành cho bạn. Sách dạy qua các case study và những lời khuyên dùng được ngay. Bản thứ hai mở rộng danh mục stability antipattern sang các vấn đề mang tính hệ thống ở quy mô lớn.

Trong danh mục antipattern có Integration Points, Cascading Failures, Blocked Threads, Slow Responses và Unbounded Result Sets. Phía pattern có Timeouts, Circuit Breaker, Bulkheads, Fail Fast và Shed Load. Martin Fowler ghi nhận chính Nygard là người phổ biến Circuit Breaker, pattern ngăn sự cố lan dây chuyền giữa các service.

Từ danh mục đó, có ba ý mà một FDE nên mang theo tới mọi dự án ở khách.

Ý thứ nhất: mỗi điểm tích hợp là một chỗ có thể vỡ

Với FDE, Integration Points là antipattern đáng đọc kỹ nhất. Mỗi kết nối tới hệ thống của khách, từ CRM, data warehouse cho tới API xác thực, đều là chỗ bạn không kiểm soát được bên kia.

Thử hình dung bạn deploy một agent đọc dữ liệu đơn hàng của khách. Ở staging, bảng đơn hàng có 100 dòng. Trên production, cùng câu query đó trả về toàn bộ lịch sử nhiều năm, và service của bạn cạn bộ nhớ. Đó là Unbounded Result Sets: một lỗi không có trong code, chỉ lộ ra khi gặp dữ liệu thật.

Cách chặn đơn giản nhất ở đây là đặt giới hạn số dòng và phân trang cho mọi query sang hệ thống của khách. Rộng hơn, việc nên làm đầu tiên ở khách là vẽ sơ đồ mọi điểm tích hợp, rồi hỏi từng điểm ba câu: nếu bên kia chết thì sao, nếu chậm thì sao, nếu trả về quá nhiều dữ liệu thì sao.

Ý thứ hai: chậm còn nguy hiểm hơn chết hẳn

Một service chết hẳn sẽ báo lỗi ngay, còn một service chậm thì giữ chân bạn. Thử làm một phép tính: service của bạn có pool 50 thread, nhận 10 request mỗi giây, mỗi request gọi sang API của khách vốn trả lời trong 200ms.

Một sáng API đó chậm lại, mỗi lời gọi treo 30 giây. Mỗi giây có thêm 10 thread bị kẹt, nên chỉ sau 5 giây cả 50 thread đều đang chờ. Health check của chính service bạn cũng không còn thread để chạy, load balancer đánh dấu nó là chết, và mọi hệ thống phụ thuộc vào bạn bắt đầu chậm theo.

Chuỗi đó đi qua Slow Responses, Blocked Threads rồi Cascading Failures. Cách chặn đầu tiên, và rẻ nhất, là Timeouts. Đặt timeout 2 giây thì thread được trả về pool thay vì treo 30 giây, kết hợp với Fail Fast để báo lỗi ngay thay vì để người dùng chờ.

Ý thứ ba: cô lập để một chỗ hỏng không kéo sập cả hệ thống

Timeout mới cắt được từng lời gọi riêng lẻ. Circuit Breaker đi xa hơn, và Fowler tóm gọn cách nó vận hành: bọc lời gọi cần bảo vệ trong một đối tượng circuit breaker chuyên theo dõi lỗi. Khi lỗi vượt ngưỡng, breaker mở ra và các request sau bị từ chối ngay, không còn ai đi gõ cửa một API đang hấp hối.

Bulkheads xử lý phần còn lại. Quay lại ví dụ trên, nếu lời gọi sang API của khách chỉ được dùng một pool riêng 10 thread thì khi API đó treo, 40 thread còn lại vẫn phục vụ các chức năng khác. Shed Load là bước cuối: khi quá tải, chủ động từ chối bớt request còn hơn để tất cả cùng chậm.

Ai nên đọc, và đọc theo thứ tự nào?

Cuốn sách hợp nhất với developer đã có 2 năm kinh nghiệm trở lên và từng ít nhất một lần thức trắng vì sự cố. Bản thứ hai ra từ 2018, nên lộ trình hợp lý gồm cả sách lẫn hai cuộc trò chuyện với tác giả.

Bước một, nghe tập GOTO Book Club năm 2023 với Nygard và Trisha Gee, vốn bàn về những pattern và antipattern mới xuất hiện kể từ bản 2007. Nghe trước giúp bạn biết phần nào của sách vẫn đứng vững và phần nào cần đọc kèm bối cảnh mới.

Bước hai, đọc danh mục antipattern, và với mỗi mục hãy tìm cho được một ví dụ trong hệ thống bạn đang vận hành. Phải nhận ra bệnh trên chính code của mình thì mới chọn đúng cách chữa.

Bước ba, đọc phần pattern, và với mỗi pattern hãy ghi lại nó chặn antipattern nào trong danh sách bạn vừa lập. Bước bốn, nghe tập 141 của Cognicast năm 2018, đi sâu vào circuit breaker và hiện tượng dogpile (hàng loạt request cùng dồn vào một chỗ một lúc).

Với developer Việt Nam muốn chuyển sang FDE, đừng chỉ ghi “đã đọc Release It!” vào CV. Hãy viết một dòng có số liệu thật của chính bạn, kiểu “thêm timeout 2 giây và circuit breaker cho lời gọi API đối tác, giảm thời gian sự cố từ X giờ xuống Y phút”.

Khi đọc JD có cụm “production-ready” hay “reliability”, hãy chuẩn bị sẵn một câu chuyện theo đúng chuỗi chậm, kẹt thread rồi đổ dây chuyền như ở trên.

Khách hàng sẽ không nhớ demo của bạn chạy mượt thế nào. Họ sẽ nhớ cái sáng API của họ chậm đi mà hệ thống của bạn vẫn chạy.