Ngày 16/1 xảy ra sự cố, đến ngày 10/3 mới công bố bản tổng kết sau sự cố (Post-Mortem). Trong suốt 53 ngày đó, phía chính thức rốt cuộc đã làm gì? Đây là câu hỏi lớn nhất của tôi trước khi đọc Post-Mortem.
Tôi đã chép các mốc thời gian trong bản tổng kết ra sổ ghi chú: sự cố xảy ra vào ngày 16/1, vào cuối ngày hôm đó thì chuỗi chính tạm dừng dịch vụ cầu nối (bridge) ; đến cuối tháng 1 hoàn tất việc thu gom vốn (funds aggregation) và xác minh các địa chỉ bị ảnh hưởng; ngày 10/3 phát hành bản tổng kết đầy đủ. Trước khi chép lại con số $DUSK , tôi đã lật trang đăng bài để kiểm tra dấu thời gian cập nhật, xác nhận rằng không có phiên bản trung gian nào bị rút gỡ. Chép đến mục thứ ba thì tôi dừng lại: trong 53 ngày đó, phía chính thức chỉ cập nhật trạng thái 2 lần—một lần là trong ngày xảy ra sự cố, và một lần là vào ngày công bố bản tổng kết.
Tôi trải lịch ra và tính một lượt: từ 16/1 đến 10/3 là 53 ngày, chỉ có 2 lần cập nhật. Trung bình 26,5 ngày mới có một lần thay đổi. Trong giai đoạn cuối tháng 1, lượt thu gom vốn và xác minh địa chỉ—tất cả đều chỉ được bổ sung trong bản tổng kết, chứ lúc đó ra bên ngoài thì không có một chữ nào. Tôi chia 53 ngày đó thành bốn ô: “đóng băng” theo cấp độ giờ, “xác minh” theo cấp độ ngày, “nguyên nhân gốc” theo cấp độ tuần, còn “bản tổng kết + kiểm duyệt nội bộ” thì chiếm hơn một tháng. Ba ô đầu đều trống không; chỉ đến ô cuối mới bắt đầu nói. Đây chính là phép tính về thời gian của tôi, và cũng là điểm khiến tôi cảm thấy ban đầu là không ổn.
Nhưng nếu trải bốn ô đó ra và nhìn kỹ, thì im lặng không đồng nghĩa với thiếu trách nhiệm. Việc “đóng băng” ở cấp độ giờ—con số @Dusk —ngụ ý rằng trong ngày xảy ra sự cố đã cắt đứt sự lan tỏa rủi ro; “xác minh” theo cấp độ ngày nghĩa là việc đối soát từng giao dịch không bị trì hoãn; “nguyên nhân gốc” theo cấp độ tuần nghĩa là kết luận có căn cứ, có thể kiểm tra, chứ không phải suy đoán theo cảm tính. Mỗi giai đoạn đều có hành động rõ ràng, chỉ là không cập nhật ra bên ngoài. Tôi lại đem cách xử lý một vài sự kiện liên quan đến cầu nối gần đây để so sánh: có dự án xảy ra sự cố thì ngày hôm sau đã xóa Twitter; có dự án kéo dài nửa năm mới ra một thông báo nhưng không có chi tiết; và cũng có dự án chẳng thèm phản hồi. So sánh xong, tôi càng chắc chắn hơn: quá trình xử lý mới chính là “nguyên liệu” tạo nên niềm tin, còn bản tổng kết này là một trong số ít tài liệu công khai toàn bộ timeline, nguyên nhân gốc và biện pháp—đem ra trải hết.
Vì vậy, bây giờ tôi sẽ để ý một việc: lần tới khi nó xảy ra sự cố, từ thời điểm sự kiện xảy ra đến khi công bố bản tổng kết, liệu có cập nhật theo quá trình (process-based updates) hay không. Tần suất cập nhật chính là thước đo minh bạch—nói hay đến mấy cũng không bằng dấu thời gian trung thực. #dusk
Tôi đã chép các mốc thời gian trong bản tổng kết ra sổ ghi chú: sự cố xảy ra vào ngày 16/1, vào cuối ngày hôm đó thì chuỗi chính tạm dừng dịch vụ cầu nối (bridge) ; đến cuối tháng 1 hoàn tất việc thu gom vốn (funds aggregation) và xác minh các địa chỉ bị ảnh hưởng; ngày 10/3 phát hành bản tổng kết đầy đủ. Trước khi chép lại con số $DUSK , tôi đã lật trang đăng bài để kiểm tra dấu thời gian cập nhật, xác nhận rằng không có phiên bản trung gian nào bị rút gỡ. Chép đến mục thứ ba thì tôi dừng lại: trong 53 ngày đó, phía chính thức chỉ cập nhật trạng thái 2 lần—một lần là trong ngày xảy ra sự cố, và một lần là vào ngày công bố bản tổng kết.
Tôi trải lịch ra và tính một lượt: từ 16/1 đến 10/3 là 53 ngày, chỉ có 2 lần cập nhật. Trung bình 26,5 ngày mới có một lần thay đổi. Trong giai đoạn cuối tháng 1, lượt thu gom vốn và xác minh địa chỉ—tất cả đều chỉ được bổ sung trong bản tổng kết, chứ lúc đó ra bên ngoài thì không có một chữ nào. Tôi chia 53 ngày đó thành bốn ô: “đóng băng” theo cấp độ giờ, “xác minh” theo cấp độ ngày, “nguyên nhân gốc” theo cấp độ tuần, còn “bản tổng kết + kiểm duyệt nội bộ” thì chiếm hơn một tháng. Ba ô đầu đều trống không; chỉ đến ô cuối mới bắt đầu nói. Đây chính là phép tính về thời gian của tôi, và cũng là điểm khiến tôi cảm thấy ban đầu là không ổn.
Nhưng nếu trải bốn ô đó ra và nhìn kỹ, thì im lặng không đồng nghĩa với thiếu trách nhiệm. Việc “đóng băng” ở cấp độ giờ—con số @Dusk —ngụ ý rằng trong ngày xảy ra sự cố đã cắt đứt sự lan tỏa rủi ro; “xác minh” theo cấp độ ngày nghĩa là việc đối soát từng giao dịch không bị trì hoãn; “nguyên nhân gốc” theo cấp độ tuần nghĩa là kết luận có căn cứ, có thể kiểm tra, chứ không phải suy đoán theo cảm tính. Mỗi giai đoạn đều có hành động rõ ràng, chỉ là không cập nhật ra bên ngoài. Tôi lại đem cách xử lý một vài sự kiện liên quan đến cầu nối gần đây để so sánh: có dự án xảy ra sự cố thì ngày hôm sau đã xóa Twitter; có dự án kéo dài nửa năm mới ra một thông báo nhưng không có chi tiết; và cũng có dự án chẳng thèm phản hồi. So sánh xong, tôi càng chắc chắn hơn: quá trình xử lý mới chính là “nguyên liệu” tạo nên niềm tin, còn bản tổng kết này là một trong số ít tài liệu công khai toàn bộ timeline, nguyên nhân gốc và biện pháp—đem ra trải hết.
Vì vậy, bây giờ tôi sẽ để ý một việc: lần tới khi nó xảy ra sự cố, từ thời điểm sự kiện xảy ra đến khi công bố bản tổng kết, liệu có cập nhật theo quá trình (process-based updates) hay không. Tần suất cập nhật chính là thước đo minh bạch—nói hay đến mấy cũng không bằng dấu thời gian trung thực. #dusk