Lần chạy êm ở site khách là một bài test không ai chạy lại được

Chương về kiểm thử độ tin cậy trong sách Site Reliability Engineering của Google mở đầu bằng một lời đề từ ngắn: nếu bạn chưa thử nó, hãy coi như nó đã hỏng. Vài đoạn sau, sách nói thêm: test pass chưa chắc chứng minh hệ thống đáng tin cậy, nhưng test fail thì thường chứng minh hệ thống chưa đáng tin.

Hai câu ấy đáng nghĩ lại trước khi bạn nhắn cho khách rằng “xong rồi, đã chạy được ở site”. Một lần chạy êm trên hệ thống thật của khách, xét kỹ, chỉ là một test pass, và là loại test không ai viết ra, không ai chạy lại được.

Bạn cần quan tâm vì công việc FDE luôn có ngày bàn giao. Khoá học về FDE cho hệ thống AI của Educative viết rằng đội của khách không vận hành được thứ họ không hiểu, và không bảo trì được thứ chỉ được thiết kế cho FDE. Từ ngày đó, câu hỏi “chạy được chưa” nhường chỗ cho câu hỏi “sửa vào có an toàn không”.

Một lần chạy êm chứng minh được gì?

Thử hình dung một tình huống điển hình. Bạn viết cho khách một script đọc file export đơn hàng từ hệ thống cũ, chuẩn hoá ngày tháng và đơn vị tiền, rồi đẩy vào kho dữ liệu mới. Script chạy trót lọt trên dữ liệu ba ngày gần nhất, khách xem dashboard và gật đầu.

Lần chạy đó chứng minh ba điều: định dạng file của ba ngày ấy khớp với giả định của bạn, quyền truy cập đã đúng, và đường ống không gãy ở bước nào.

Nó không cho biết chuyện gì xảy ra khi một chi nhánh xuất ngày theo kiểu khác, khi có dòng thiếu mã khách hàng, hay khi kỹ sư của khách đổi tên một cột vào tháng sau. Cả ba trường hợp chưa từng xảy ra, nên lần chạy êm không thể nói gì về chúng.

Công bằng mà nói, chạy trên dữ liệu thật là việc bắt buộc. Bài giải thích vai trò FDE của PostHog mô tả FDE làm việc cùng khách cho đến khi khách thấy kết quả thật trên dữ liệu thật. Nhưng đó là điều kiện để được nghiệm thu, chưa phải bằng chứng rằng hệ thống chịu được thay đổi.

Sách SRE chỉ ra chỗ khác biệt: mỗi test pass cả trước lẫn sau một thay đổi sẽ thu hẹp mức bất định mà người phân tích phải tính đến. Chữ quan trọng là “trước và sau”. Lần chạy êm ở site không có “sau”, vì không ai chạy lại nó khi code được sửa.

Vì sao code của FDE hay thiếu test?

Cấu trúc của công việc giải thích phần lớn chuyện này. Khi bạn viết cho đúng một khách, dưới áp lực phải có kết quả trước buổi demo, test là thứ dễ bị cắt nhất.

Lý do cắt nghe cũng có lý: code này chỉ dùng ở một nơi, và bạn đang ngồi ngay đó để sửa nếu nó hỏng. Nhưng lý do ấy chỉ đứng vững đến ngày bạn rời đi.

Bài viết về mô hình Field-to-Product trên Substack Second File cảnh báo hai thứ: code tuỳ biến chỉ sống trong một tài khoản khách hàng, và những kỹ sư “người hùng” trở thành điểm hỏng duy nhất. Code không có test biến bạn thành đúng kiểu người hùng ấy, vì chỉ bạn biết nó được phép làm gì và không được làm gì.

Người nhận code là người trả giá

Cuốn Software Engineering at Google viết rằng một lý do quan trọng không kém để test phần mềm là giữ được khả năng thay đổi nó. Với dự án sắp bàn giao, hệ quả rất trực tiếp: code không có test vẫn sửa được, nhưng mỗi lần sửa là một canh bạc với đội của khách.

Cái giá còn tăng theo thời gian. Cùng cuốn sách viết rằng bug bị phát hiện càng muộn trong vòng đời phát triển thì càng đắt, nhiều trường hợp đắt theo cấp số nhân. Với code của FDE, thời điểm muộn nhất là khi bug lộ ra trên production của khách, lúc người viết đã sang dự án khác.

Test còn làm được việc mà tài liệu viết tay ít khi làm tốt. Một test ngắn, kiểm đúng một hành vi, cho đội khách biết bạn định để script xử lý dòng thiếu mã khách hàng thế nào, và nói điều đó chắc hơn mọi trang wiki, vì nó chạy được.

Bằng chứng bàn giao trông như thế nào?

Nếu một lần chạy êm chưa đủ, thì cần những gì? Bảng dưới đây đặt lần chạy êm ở hàng đầu làm mốc, rồi thêm năm loại bằng chứng khác. Mỗi loại trả lời một câu hỏi riêng, và không loại nào thay được loại nào.

Bằng chứng	Chứng minh được	Không chứng minh được	Ai cần nó nhất
Một lần chạy êm ở site khách	Code không hỏng với dữ liệu và cấu hình của hôm đó	Code chịu được dữ liệu mới, cấu hình mới, thay đổi mới	Khách, trong buổi demo
Tiêu chí “chạy được” đo bằng số, chốt từ đầu	Hai bên đồng ý thế nào là thành công	Code có dễ bảo trì không	Người tài trợ dự án ở phía khách
Test tự động, mỗi test một hành vi	Hành vi mong muốn vẫn giữ được sau mỗi lần sửa	Code đạt đúng mục tiêu kinh doanh của khách	Kỹ sư của khách khi sửa code
Test hồi quy từ bug gặp ở site	Lỗi đã gặp không quay lại	Những lỗi chưa ai gặp	Người sửa đúng vùng code từng lỗi
Production test chạy định kỳ	Hệ thống thật vẫn khỏe theo thời gian	Một thay đổi cụ thể có làm vỡ hành vi nào không	Đội vận hành
PR upstream kèm case tái hiện	Bản sửa có chỗ đứng trong sản phẩm chính	Phần tuỳ biến còn lại của khách có ổn không	Đội sản phẩm

Một FDE playbook của Truong Phung trên dev.to tóm phần khác biệt bằng một phép so sánh: consultant để lại tài liệu, còn FDE để lại một hệ thống đang chạy cùng năng lực của tổ chức để vận hành nó. Năm loại bằng chứng xếp dưới hàng đầu tiên của bảng chính là năng lực vận hành đó, ở dạng đội khách có thể tự kiểm tra.

Playbook cũng khuyên đưa phần để lại, gồm eval, runbook và việc đào tạo người đầu mối phía khách, vào ngay định nghĩa engagement thay vì để đến cuối. Tác giả cảnh báo rằng thiếu nó, hệ thống sẽ mục ruỗng trong vòng 90 ngày kể từ khi bạn rời đi.

Biến mỗi bug ở site thành một test

Bạn không cần viết lại toàn bộ test suite cho code cũ. Điểm bắt đầu khiêm tốn nhất là ghi mỗi bug gặp ở site thành một test case. Với FDE, việc này gần như không tốn thêm công, vì lúc sửa bug bạn đã có sẵn dữ liệu đầu vào gây lỗi.

Quay lại script đơn hàng. Giả sử tuần thứ hai, một chi nhánh gửi file có ngày ghi theo kiểu ngày-tháng-năm và script đọc nhầm thành tháng-ngày-năm.

Bạn sửa xong, rồi bỏ thêm mười phút viết một test với đúng ba dòng dữ liệu đó, kiểm rằng ngày được hiểu đúng. Từ đó, kỹ sư nào của khách chạm vào hàm parse ngày cũng sẽ được test báo ngay nếu làm hỏng lại chỗ này.

Bước tiếp theo là đưa những gì đáng giữ về sản phẩm. Bài Field-to-Product gói bước tổng quát hoá trong một dòng: đẩy abstraction và test lên upstream, bỏ dần các bản vá cục bộ.

Lỗi đọc ngày ở trên là ứng viên tốt: nếu sản phẩm có tính năng import, test đó nên nằm trong repo sản phẩm chứ không chỉ trong thư mục tuỳ biến của một khách.

Điều quyết định là thời điểm. Phần lớn những việc trên phải bắt đầu từ tuần đầu của engagement, không phải tuần cuối, và lý do nằm ở chính bản chất của test viết muộn.

Test viết vào tuần cuối kiểm cái gì?

Lỗi phổ biến nhất là coi một bước kiểm tra trên production là đủ. Production test cần thiết, nhưng nó chỉ báo hệ thống còn khỏe, không báo được lần sửa vừa rồi đã làm vỡ hành vi nào.

Một lỗi tinh vi hơn là dồn test vào tuần cuối. Một bài hướng dẫn trên freeCodeCamp nói rõ loại test này không cho bạn biết hành vi cũ là đúng; tác giả viết rằng mình chỉ ghi lại hành vi, không giả vờ rằng nó đúng.

Kỹ thuật đó hữu ích khi refactor code kế thừa. Nhưng nếu đó là toàn bộ bộ test bạn bàn giao, bạn đang đóng băng cả những chỗ sai của chính mình và trao cho đội khách như thể đó là hành vi mong muốn. Test viết sớm, khi bạn còn đang hỏi khách “dòng thiếu mã thì xử lý sao”, mới ghi lại ý định thay vì hiện trạng.

Một cái bẫy khác là viết một test khổng lồ kiểm cả đường ống từ file vào đến dashboard. Khi nó đỏ, kỹ sư của khách không biết hành vi nào hỏng. Cuối cùng là sửa bug ở site mà không để lại test, rồi giữ bản sửa mãi trong nhánh tuỳ biến: bug có thể quay lại, và sản phẩm chính không bao giờ biết đến nó.

Nhà tuyển dụng muốn thấy điều gì?

Trong CV, câu “triển khai pipeline cho khách hàng X” chỉ ngang với một lần chạy êm; câu “bàn giao kèm test hồi quy cho từng lỗi gặp ở site, đội khách tự phát hành các bản sửa sau đó” nói được nhiều hơn hẳn.

Trong phỏng vấn, hãy chuẩn bị kể một bug cụ thể: bạn tái hiện nó thế nào, test trông ra sao, giờ test ấy nằm ở repo nào.

Lần chạy êm ở site cho bạn chữ ký nghiệm thu. Còn bàn giao có tử tế hay không thì phải đợi đến lần đầu đội khách tự sửa code mà không cần gọi bạn.