Lỗi lúc có lúc không thường bắt nguồn từ một trong bốn chỗ: thời điểm các việc chạy chen nhau, một loại dữ liệu đặc biệt hiếm gặp, môi trường khác nhau giữa các máy, hoặc một tài nguyên cạn dần theo thời gian. Cách săn là ghi nhật ký đủ chi tiết để lần sau lỗi xảy ra bạn có manh mối, tìm điểm chung giữa các lần lỗi, và chủ động ép lỗi lộ diện.
Chào bạn, đây là Nhà Lập Trình. Nếu lỗi thường là con chuột chạy qua bếp, thì lỗi lúc có lúc không là con chuột chỉ xuất hiện khi bạn quay lưng. Người dùng báo lỗi, bạn thử mười lần không thấy gì, rồi tuần sau lại có người báo. Tập này mình kể cách những người trong nghề săn loại lỗi khó chịu nhất này.
Bốn nơi lỗi thích ẩn nấp
Nơi thứ nhất là thời điểm. Hai việc chạy song song, thường thì việc A xong trước việc B, nhưng thỉnh thoảng mạng chậm hơn một chút và B xong trước. Chương trình được viết với giả định A luôn xong trước, nên khi ngược lại thì hỏng.
Nơi thứ hai là dữ liệu đặc biệt. Chương trình chạy tốt với chín mươi chín phần trăm dữ liệu, chỉ hỏng khi gặp một tên có ký tự lạ, một ngày hai mươi chín tháng hai, một đơn hàng có số lượng không, một khách hàng không có địa chỉ.
Nơi thứ ba là môi trường. Lỗi chỉ xảy ra trên một máy chủ trong số ba máy chủ, vì máy đó cài phiên bản thư viện khác. Hoặc chỉ xảy ra trên một dòng điện thoại, với một cài đặt ngôn ngữ nhất định.
Nơi thứ tư là tài nguyên cạn dần. Chương trình chạy tốt lúc mới khởi động, nhưng mỗi yêu cầu lại giữ lại một chút bộ nhớ hay một kết nối mà không trả. Sau vài ngày, tài nguyên cạn và lỗi bắt đầu xuất hiện, rồi khởi động lại thì hết. Người ta gọi đó là rò rỉ.
Nhật ký là chiếc bẫy chuột
Vì không thể ngồi canh lỗi, bạn cần một thứ canh thay mình. Đó là nhật ký. Khi lỗi xảy ra lần sau, nhật ký phải ghi lại đủ thông tin để bạn hiểu chuyện gì đã xảy ra, mà không cần tái hiện.
Nhật ký tốt ghi lại ai, khi nào, làm gì, với dữ liệu nào, và kết quả ra sao. Không cần ghi mọi thứ, nhưng ở những chỗ nghi ngờ, hãy ghi dày hơn. Mỗi yêu cầu nên có một mã riêng xuyên suốt, để bạn lần theo được một yêu cầu qua nhiều bước, nhiều máy.
Khi lỗi xảy ra, ghi lại càng nhiều bối cảnh càng tốt: toàn bộ thông báo lỗi, dữ liệu đầu vào lúc đó, trạng thái của những thứ liên quan. Một dòng nhật ký chỉ ghi có lỗi xảy ra gần như vô dụng.
Cẩn thận đừng ghi mật khẩu, số thẻ, thông tin cá nhân nhạy cảm vào nhật ký. Nhật ký thường được nhiều người xem hơn cơ sở dữ liệu và ít được bảo vệ hơn.
Tìm điểm chung giữa các lần lỗi
Khi đã có vài lần lỗi được ghi lại, hãy đặt chúng cạnh nhau và tìm điểm chung. Có phải đều vào giờ cao điểm? Đều từ cùng một máy chủ? Đều với khách hàng ở một tỉnh? Đều sau khi hệ thống chạy liên tục vài ngày?
Điểm chung thường chỉ thẳng vào một trong bốn nơi ẩn nấp. Đều vào giờ cao điểm, nghi thời điểm và tải. Đều từ cùng một máy, nghi môi trường. Đều với một loại khách, nghi dữ liệu. Đều sau vài ngày, nghi rò rỉ.
Một anh kỹ sư ở Hà Nội kể anh từng săn một lỗi gửi thư thất bại ngẫu nhiên suốt hai tuần. Cuối cùng anh xếp các lần lỗi theo giờ và thấy tất cả đều rơi vào đúng phút đầu tiên của mỗi giờ, đúng lúc một tiến trình sao lưu chạy và chiếm hết kết nối. Lỗi không ngẫu nhiên chút nào, chỉ là chưa ai nhìn theo đúng chiều.
Hãy thử nhìn dữ liệu lỗi theo nhiều chiều khác nhau: thời gian, người dùng, máy, phiên bản. Chiều nào cho thấy một khuôn mẫu, chiều đó là manh mối.
Ép lỗi lộ diện
Khi đã có giả thuyết, đừng chờ lỗi tự đến. Hãy ép nó. Nếu nghi thời điểm, hãy cố tình làm chậm một bước bằng cách chèn một khoảng chờ trong môi trường thử nghiệm. Nếu lỗi xuất hiện đều đặn, giả thuyết đúng.
Nếu nghi tải, hãy giả lập nhiều người dùng cùng lúc. Lỗi hiếm khi có một người thường trở nên thường xuyên khi có một trăm người.
Nếu nghi dữ liệu, hãy lấy chính dữ liệu đã gây lỗi, đã được làm sạch thông tin cá nhân, và chạy lại. Nếu nghi rò rỉ, theo dõi bộ nhớ và số kết nối theo thời gian, xem nó có tăng dần mà không giảm không.
Biến một lỗi lúc có lúc không thành một lỗi lúc nào cũng có là đã giải quyết được phần khó nhất. Từ đó, bạn quay về quy trình gỡ lỗi bình thường.
Đừng vội tuyên bố đã sửa
Với lỗi thường, sửa xong thử lại thấy hết là yên tâm. Với lỗi lúc có lúc không, thử lại mười lần không thấy lỗi chẳng chứng minh gì, vì trước khi sửa, mười lần thử cũng có thể không thấy.
Hãy đo trước và sau. Trước khi sửa, lỗi xảy ra khoảng bao nhiêu lần mỗi ngày. Sau khi sửa, theo dõi một khoảng thời gian đủ dài. Nếu số lần giảm về không và giữ nguyên, bạn mới có bằng chứng.
Cũng cẩn thận với những cách sửa làm lỗi hiếm hơn chứ không hết. Thêm một khoảng chờ để việc A chắc chắn xong trước việc B là một ví dụ. Lỗi ít đi, nhưng khi mạng chậm hơn nữa, nó quay lại. Cách sửa thật là không phụ thuộc vào thứ tự nữa.
Lỗi lúc có lúc không dạy cho người lập trình sự khiêm tốn và kiên nhẫn. Nhưng nó cũng dạy một điều quý: hệ thống thật chạy trong một thế giới hỗn loạn, và mã tốt là mã được viết cho thế giới đó, không phải cho máy thử nghiệm yên tĩnh của bạn.
Câu hỏi thường gặp
Vì sao lỗi chỉ xảy ra trên máy chủ mà không xảy ra trên máy mình?
Thường do khác biệt môi trường như phiên bản phần mềm, cấu hình, dữ liệu, múi giờ hoặc tải. Liệt kê và so sánh từng khác biệt là cách thu hẹp nguyên nhân.
Rò rỉ bộ nhớ là gì?
Là khi chương trình giữ lại bộ nhớ không còn dùng mà không trả lại. Bộ nhớ bị chiếm tăng dần theo thời gian cho tới khi chương trình chậm hoặc ngừng chạy.
Nên ghi những gì vào nhật ký để gỡ lỗi?
Thời gian, mã yêu cầu, người dùng, hành động, dữ liệu đầu vào chính và kết quả hoặc lỗi đầy đủ. Không ghi mật khẩu, số thẻ hay thông tin cá nhân nhạy cảm.
Khởi động lại máy chủ để hết lỗi có được không?
Có thể dùng tạm để khôi phục dịch vụ, nhưng không phải cách sửa. Nếu khởi động lại giúp hết lỗi, rất có thể có rò rỉ tài nguyên cần tìm và sửa tận gốc.
Làm sao biết một lỗi ngẫu nhiên đã thật sự được sửa?
Đo tần suất lỗi trước khi sửa và theo dõi đủ lâu sau khi sửa. Chỉ khi tần suất giảm về không và giữ ổn định mới có thể tin là đã sửa xong.
