Dashboard production vẫn trông yên ổn cho tới khi có người hỏi câu thứ hai. Tỷ lệ lỗi chỉ nhích nhẹ, không đủ giải thích vì sao ba khách hàng mắc kẹt ở bước thanh toán. Log có rất nhiều dòng nhưng chẳng dùng chung request ID. Dịch vụ thanh toán báo khỏe, dịch vụ đơn hàng cũng vậy. Mỗi màn hình đang nói một phần sự thật, chỉ là những phần ấy không nối được với nhau.
Đó là lúc observability thôi là chuyện riêng của vận hành và trở thành chuyện kiến trúc. Ta rất dễ xem log, metric, trace, dashboard và alert là phần gắn thêm sau khi tính năng đã chạy. Nhưng production hiếm khi lịch sự chờ tới lúc hệ thống được thiết kế để ghi nhận đủ tín hiệu mới đặt câu hỏi khó. Một hệ thống không giải thích được chính nó không chỉ khó vận hành; nó còn khó được thiết kế một cách có trách nhiệm.
Xem observability là lựa chọn thiết kế nghĩa là hỏi trước khi phát hành: khi luồng chính không còn suôn sẻ, ta cần biết gì? Nếu khách bảo thanh toán chậm, có lần theo được một request qua gateway, cart, payment, inventory và email không? Nếu queue phình lên, có phân biệt được bên phát chậm, bên nhận lỗi, lượt retry dồn hay hệ thống phụ thuộc phía sau gặp vấn đề không? Nếu feature flag đổi hành vi, có tách được người dùng ở luồng mới khỏi luồng cũ không?
Quyết định hữu ích đầu tiên là đặt tên cho những event thật sự quan trọng. Không phải dòng nào cũng cần log, hàm phụ trợ nào cũng cần metric. Nên ghi các bước chuyển bằng ngôn ngữ của sản phẩm: payment_authorized, order_reserved, refund_rejected, invoice_sent. Những cái tên ấy giúp cả người không viết phần code ban đầu vẫn đọc được câu chuyện. Dòng “process failed” có thể đúng về kỹ thuật, nhưng không giúp đồng nghiệp đang mệt nhận ra bước nghiệp vụ nào vừa hỏng.
Quyết định tiếp theo là mang dấu vết đi xuyên hệ thống. Một trace ID được tạo ở rìa nghe nhỏ và chán, nhưng thay đổi hẳn cách điều tra. Không có nó, mỗi dịch vụ dựng một đống bằng chứng riêng. Có nó, một request của khách hàng trở thành sợi chỉ xuyên suốt. Metric báo rằng có điều bất thường. Trace chỉ thời gian đã tiêu ở đâu. Structured log kể chuyện gì xảy ra tại các bước quan trọng. Giá trị không nằm ở việc thu càng nhiều dữ liệu càng tốt, mà ở chỗ các tín hiệu riêng lẻ có thể xếp thành cùng một câu chuyện.
Với mỗi luồng quan trọng, nếu nó hỏng với đúng một khách hàng, định danh nào sẽ giúp ta dựng lại đường đi mà không phải đoán?
Observability tốt cũng cần biết tiết chế. Hệ thống có thể dìm người vận hành trong dữ liệu mà vẫn giấu mất câu trả lời. Label có cardinality cao làm metric đắt đỏ. Log quá ồn che dòng quan trọng. Alert réo lên theo mọi dao động nhỏ sẽ dạy mọi người cách lờ alert. Thiết kế là chọn tín hiệu nào đáng nhận sự chú ý. Cảnh báo hữu ích nên chỉ vào nỗi đau của người dùng hoặc tốc độ đốt error budget quá nhanh, không phải một máy vừa có phút bận rộn bình thường.
Chuyện này còn có mặt văn hóa. Khi observability được tính từ sớm, sự cố bớt bị cá nhân hóa. Mọi người có thể nhìn bằng chứng thay vì đoán code của ai gây lỗi. Trace không buộc tội; dashboard cũng không bảo vệ cái tôi của ai. Chúng cho căn phòng một sự thật chung để kiểm tra. Sự cố vốn đã đủ áp lực, hệ thống nên giúp hạ nhiệt bằng cách làm thực tế dễ nhìn hơn.
Đánh đổi lớn nhất là chi phí. Việc ghi nhận telemetry tốn thời gian. Dashboard cần người sở hữu. Log và trace cần quy định lưu giữ. Phải có người chọn hành trình khách hàng nào cần SLO và alert nào đáng đánh thức người trực. Nhưng thêm observability sau khi production đã đau thường còn đắt hơn. Lúc ấy, đội ngũ phải vừa tìm lỗi vừa tìm cách bù phần bằng chứng chưa từng được ghi.
Có thể bắt đầu rất nhỏ. Chọn một luồng quan trọng như đăng ký, thanh toán, chi trả hoặc tạo báo cáo. Đặt tên cho các event nghiệp vụ chính. Thêm một trace ID đi hết đường. Tạo RED metrics cho các dịch vụ liên quan: rate, errors và duration. Làm một dashboard kể lại trải nghiệm từ góc nhìn người dùng. Thêm đúng một alert mà nếu có trong sự cố gần nhất thì đã giúp được. Chừng đó là đủ để bắt đầu học.
Giá trị thầm lặng của observability không nằm ở dashboard đẹp. Nó nằm ở khả năng đặt một câu hỏi mới giữa lúc áp lực và nhận được câu trả lời hữu ích từ hệ thống đang chạy. Kiến trúc không chỉ là cách các thành phần gọi nhau; nó còn là cách hệ thống nói thật khi có chuyện. Trước lần production tiếp theo đặt câu hỏi khó, mỗi luồng quan trọng cần được thiết kế để lưu lại đủ dấu vết cho câu trả lời.