Mô tả： Một lần build thất bại có thể kéo theo hàng trăm dòng báo lỗi. Bài viết hướng dẫn cách đọc log, nhận biết lỗi chập chờn và hiểu vì sao AI viết code nhanh chưa chắc giảm tăng ca.
Code đã xong, thay đổi đã được gửi, chỉ còn chờ hệ thống tự động báo xanh. Nhưng màn hình lại đỏ kín đúng lúc sắp tan ca. Máy tính như vừa mở đầu một bộ phim trinh thám dài tập.
Hàng trăm dòng báo lỗi chưa chắc là hàng trăm sự cố khác nhau. Một tệp cấu hình không đọc được có thể khiến tệp đầu ra không được tạo, rồi các bước kiểm tra phụ thuộc vào nó cùng thất bại.
Một chiếc chìa khóa mất, cả nhóm chat náo loạn
Hãy hình dung ví dụ giả định: bước đầu không tìm thấy cấu hình, bước tiếp theo đợi một kết quả không được tạo ra, sau đó nhiều bài kiểm tra đồng loạt báo lỗi. Nguồn gốc có thể chỉ nằm ở một chỗ.
Giống như một người làm mất chìa khóa nhà, cả nhóm chat gia đình gửi đến trăm tin nhắn. Trả lời từng tin vẫn không mở được cửa. Tuy nhiên, dòng báo lỗi đỏ đầu tiên cũng chưa chắc là nguyên nhân chính; cảnh báo sớm hơn hoặc các công việc chạy song song có thể mang manh mối khác.
Đọc log thế nào để không bị ngợp?
Trước tiên, tìm đúng công việc và bước thất bại. Sau đó tìm thông báo giải thích được các lỗi theo sau: thiếu tệp, cấu hình sai, thiếu gói cần dùng hoặc kết quả kiểm tra không đúng dự kiến.
Nếu cùng một phiên bản code lúc chạy qua, lúc chạy trượt, nên kiểm tra mạng, dịch vụ ngoài, thứ tự thực thi và bài kiểm tra thiếu ổn định. Chạy lại thành công một lần chưa có nghĩa đã sửa xong. Chỉnh từng nguyên nhân có cơ sở rồi kiểm tra lại đúng phiên bản đó. Che mật khẩu và khóa bí mật trước khi chia sẻ log với người khác hoặc AI.
CircleCI có lệnh 'circleci run get --failure-report ' để tóm tắt các bước bị lỗi, cùng khả năng chạy lại riêng phần thất bại. Chúng giúp bớt thời gian tìm kiếm, nhưng bấm chạy lại không tự chữa được lỗi code thật.
AI viết code nhanh, vì sao vẫn có thể tăng ca?
Giả sử AI giúp viết thay đổi trong mười phút, còn việc tìm và sửa lỗi build mất thêm bốn mươi lăm phút. Tổng cộng vẫn là năm mươi lăm phút. Đây là con số minh họa, cho thấy viết code nhanh không đồng nghĩa hoàn thành phần mềm nhanh.
Hãy tưởng tượng một nhà hàng nấu nhanh gấp mười lần nhưng chỉ có một quầy thanh toán. Hàng người chờ chỉ dồn về cửa ra. Build, kiểm tra và sửa lỗi cũng có thể trở thành chiếc quầy đó.
Nghiên cứu DORA năm 2025 của Google ghi nhận mối liên hệ thuận giữa sử dụng AI và lượng phần mềm được bàn giao, nhưng liên hệ nghịch với độ ổn định. Đây không phải bằng chứng AI trực tiếp gây tăng ca. Nó nhấn mạnh tầm quan trọng của kiểm tra nhanh và thay đổi nhỏ.
Muốn giảm tăng ca thì đo điều gì?
Nếu mỗi ngày có ba lần build hỏng, mỗi lần mất hai mươi lăm phút để khôi phục, hai mươi ngày làm việc sẽ tốn hai mươi lăm giờ. Đây là phép tính ví dụ, không phải trung bình ngành. Nên theo dõi tần suất lỗi, thời gian đến lần build thành công tiếp theo, nguyên nhân lặp lại và số lần chạy lại qua mà không đổi code.
Hạn chót quá gấp, yêu cầu thay đổi và thiếu nhân lực cũng kéo dài giờ làm. Build lỗi đặc biệt khó chịu vì không biết khi nào xong. Đôi khi việc lâu nhất không phải gõ code, mà là tìm một manh mối đúng giữa cả trăm dòng đang cùng la hét.
Nguồn：
