Quan sát hệ thống trong môi trường thật: log, chỉ số và vết truy dấu
Có một khoảnh khắc mà mọi lập trình viên đều sợ: sản phẩm đang chạy ngoài môi trường thật bỗng trục trặc, khách hàng phàn nàn, còn bạn thì không tài nào tái hiện lại lỗi trên máy mình. Trong những lúc như vậy, thứ duy nhất phân biệt một đội bình tĩnh xử lý với một đội hoảng loạn mò mẫm chính là khả năng quan sát hệ thống. Viết được code chạy được mới chỉ là một nửa công việc; nửa còn lại là làm cho hệ thống kể lại được câu chuyện của chính nó khi bạn không ngồi cạnh nó. Bài viết này bàn về cách xây dựng khả năng quan sát đó một cách thực dụng.
Vì sao chạy được thôi là chưa đủ
Trên máy của lập trình viên, mọi thứ đều nằm trong tầm kiểm soát: bạn thấy được từng dòng, dừng chương trình lại bất cứ lúc nào, chạy lại bao nhiêu lần tùy thích. Môi trường thật thì khác hẳn. Ở đó có hàng nghìn người dùng đồng thời, có những dữ liệu kỳ quặc bạn chưa từng nghĩ tới, có mạng chập chờn và những dịch vụ phụ thuộc thi thoảng lại đổ. Lỗi thường chỉ xuất hiện với một tổ hợp điều kiện hiếm gặp mà bạn gần như không thể dựng lại trên máy mình.
Trong bối cảnh đó, cách gỡ lỗi truyền thống bằng việc chạy từng bước gần như vô dụng. Bạn không thể dừng cả hệ thống đang phục vụ khách hàng lại để soi. Thứ bạn cần là những dấu vết mà hệ thống để lại trong lúc chạy, đủ giàu để sau này ghép lại thành bức tranh về chuyện đã xảy ra. Đầu tư vào khả năng quan sát chính là đầu tư vào sự bình tĩnh của chính bạn trong những đêm sự cố.
Ba trụ cột: log, chỉ số và vết truy dấu
Người ta thường nói về khả năng quan sát qua ba loại tín hiệu bổ sung cho nhau. Hiểu rõ vai trò của từng loại giúp bạn không lạm dụng cái này mà bỏ quên cái kia.
- Log là những bản ghi sự kiện rời rạc kèm thời điểm, trả lời câu hỏi chính xác chuyện gì đã xảy ra ở thời điểm cụ thể này.
- Chỉ số là những con số được tổng hợp theo thời gian như số lượng yêu cầu, độ trễ, tỉ lệ lỗi, trả lời câu hỏi hệ thống đang khỏe hay yếu ở tầm tổng thể.
- Vết truy dấu lần theo hành trình của một yêu cầu đi qua nhiều thành phần, trả lời câu hỏi thời gian và lỗi nằm ở chặng nào trong cả chuỗi xử lý.
Một đội trưởng thành dùng cả ba: chỉ số để phát hiện có gì đó bất thường, vết truy dấu để khoanh vùng thành phần gây ra, và log để soi vào chi tiết cuối cùng. Thiếu một trong ba, bạn sẽ thường xuyên rơi vào cảnh biết có lỗi mà không biết nó ở đâu, hoặc biết nó ở đâu mà không biết vì sao.
Ghi log sao cho hữu ích
Log là thứ dễ làm nhất và cũng dễ làm sai nhất. Nhiều hệ thống ghi log tràn lan đến mức khi cần thì không tìm nổi dòng quan trọng giữa cả biển thông tin vô nghĩa; ngược lại có hệ thống ghi quá ít, đến lúc sự cố thì chẳng có gì để bám vào. Nghệ thuật nằm ở chỗ ghi đúng thứ đáng ghi, tại đúng cấp độ, với đủ ngữ cảnh.
Vài nguyên tắc giúp log thực sự có ích khi hữu sự:
- Ghi log có cấu trúc thay vì những dòng chữ tự do, để máy móc có thể lọc và tìm kiếm được.
- Luôn kèm theo ngữ cảnh định danh, chẳng hạn mã của yêu cầu hay của người dùng, để nối các dòng log rời rạc lại thành một câu chuyện liền mạch.
- Dùng đúng cấp độ log: thông tin thường nhật khác với cảnh báo, và cảnh báo khác với lỗi nghiêm trọng cần người can thiệp ngay.
- Tuyệt đối không ghi vào log những dữ liệu nhạy cảm như mật khẩu, thông tin thẻ hay dữ liệu cá nhân của khách hàng.
Một mẹo nhỏ nhưng đáng giá: mỗi khi bạn viết một dòng log lỗi, hãy tự hỏi nếu ba tháng sau vào lúc nửa đêm mình đọc đúng dòng này, nó có nói cho mình đủ để hành động không. Nếu câu trả lời là không, hãy bổ sung ngữ cảnh ngay tại chỗ.
Cảnh báo không làm kiệt sức con người
Thu thập tín hiệu mới chỉ là bước đầu; giá trị thật đến từ việc biết khi nào cần hành động. Cảnh báo tự động là thứ đánh thức bạn dậy khi có chuyện, nhưng nó là con dao hai lưỡi. Cảnh báo quá nhạy sẽ kêu inh ỏi vì những chuyện chẳng đáng, và sau vài tuần bị dựng dậy vô cớ, cả đội sẽ chai lì đến mức bỏ qua luôn cả những cảnh báo thật. Hiện tượng mệt mỏi vì cảnh báo này nguy hiểm không kém việc không có cảnh báo nào.
Nguyên tắc lành mạnh là chỉ cảnh báo dựa trên những triệu chứng mà người dùng thực sự cảm nhận được, chẳng hạn dịch vụ chậm hẳn hay tỉ lệ lỗi tăng vọt, thay vì cảnh báo mọi biến động kỹ thuật nhỏ nhặt bên trong. Mỗi cảnh báo nên đi kèm một hành động rõ ràng cho người nhận; nếu một cảnh báo kêu lên mà chẳng ai cần làm gì, đó là ứng viên nên được xóa bỏ.
Xây thói quen quan sát từ khi viết code
Khả năng quan sát không phải thứ chắp vá vào phút chót sau khi hệ thống đã xong. Nó là một phẩm chất cần được nghĩ đến ngay khi viết từng tính năng. Khi bạn viết một đoạn xử lý quan trọng, hãy tự hỏi ngay lúc đó: nếu chỗ này hỏng ngoài môi trường thật, mình sẽ biết bằng cách nào, và mình cần để lại dấu vết gì để lần sau khỏi phải đoán mò trong bóng tối.
Thói quen ấy, được lặp lại qua từng dòng code, dần dần biến hệ thống của bạn từ một hộp đen câm lặng thành một cỗ máy biết tự kể chuyện. Và khi sự cố ập đến, như nó chắc chắn sẽ đến vào lúc nào đó, bạn sẽ không còn phải mò mẫm hoảng loạn, mà chỉ cần lắng nghe điều hệ thống đang chủ động nói với mình.
