Nguyen Le PhongNguyen Le Phong

Thiết kế escape hatch, không phải back door

Một reflection thực tế về cách xây safe operational escape hatch rõ ràng, có audit và có boundary thay vì back door bị giấu.

Incident không lớn, nhưng nó lộ ra một design smell. Team có một cách bypass normal flow, nhưng chỉ hai người biết nó nằm đâu. Không có owner rõ, không có audit trail, và không có rule viết xuống cho lúc nào được dùng. Nó từng được tạo để giúp một lần, rồi ở lại như một back door yên lặng.

Một engineering team review service diagram với một escape path an toàn được đánh dấu rõ và control có guard.
Escape hatch tốt phải visible, bounded và reviewable trước khi ai đó cần dùng.

System cần escape hatch. Production work thật có provider failure, data repair, workflow bị kẹt, emergency rollback và operational exception. Giả vờ mọi case đều đi qua happy path không phải trưởng thành. Trưởng thành là thiết kế exceptional path mà không biến nó thành quyền lực vô hình.

Khác biệt giữa escape hatch và back door không chỉ nằm ở kỹ thuật. Nó là social và operational. Escape hatch được gọi tên, document, authorize, log và narrow. Back door mơ hồ, riêng tư, khó audit và dễ trở thành bình thường. Một cái bảo vệ system khi stress. Cái kia tạo một system thứ hai không ai thật sự own.

Escape hatch an toàn bắt đầu từ failure mode cụ thể. Nó giải quyết vấn đề gì? Ai được dùng? Nó đổi data nào? Evidence nào cần có trước khi dùng? Sau đó cần chuyện gì? Nếu những câu hỏi này thấy nặng, đó là signal tốt. Action này có lẽ mang quyền lực thật.

Hatch tốt cũng nên reversible khi có thể. Nếu operator có thể grant access, phải có path revoke bù lại. Nếu workflow có thể advance thủ công, event nên nói ai advance và vì sao. Nếu data được repair, repair phải để lại trace mà support, engineering và audit sau này hiểu được.

Security không có nghĩa phủ nhận operational reality. Nó là đối xử với reality một cách trung thực. Script giấu trên máy một người không an toàn hơn chỉ vì ít người biết nó tồn tại. Admin action có boundary, approval, logging và alert thường an toàn hơn vì tổ chức có thể reason về nó.

User experience cũng quan trọng. Một số escape hatch phục vụ operator nội bộ, nhưng customer vẫn có thể cảm nhận effect. Manual payment reconciliation, entitlement correction, hoặc order unblock không nên để customer nhìn thấy state mâu thuẫn. Exceptional path vẫn cần product thinking.

Tôi thích hỏi một câu trong design review: nếu path này được dùng lúc 2 giờ sáng, sáng hôm sau mình biết được gì? Nếu câu trả lời chủ yếu là trí nhớ và chat history, hatch chưa sẵn sàng. Nếu câu trả lời có event, owner, reason, scope và follow-up, system có cơ hội học.

Escape hatch không phải shortcut vòng qua discipline. Nó là discipline áp dụng cho lúc normal flow không đủ. Mục tiêu không phải xóa mọi emergency path. Mục tiêu là làm emergency path đủ visible để chúng không trở thành shadow vĩnh viễn.

Bạn thấy bài viết thế nào?