Resilience không chỉ là Uptime

Có những hệ thống chạy rất ổn trong nhiều tháng. Nhưng đến ngày cần Restore, người ta mới phát hiện mình chưa từng thật sự kiểm tra khả năng phục hồi.

Trong nhiều năm làm Infrastructure, mình từng có xu hướng nhìn độ ổn định của hệ thống qua những thứ rất quen thuộc: server Up, service phản hồi, backup job Success, Dashboard xanh.

Những tín hiệu đó tất nhiên quan trọng. Nhưng càng làm nhiều với Backup, DR, Monitoring và các đợt migration, mình càng thấy một hệ thống “đang chạy tốt” và một hệ thống “có khả năng phục hồi tốt” là hai khái niệm khác nhau.

Câu hỏi khiến mình thay đổi cách nhìn khá đơn giản:

Nếu ngày mai một workload quan trọng biến mất, mình có thực sự biết cách đưa nó trở lại không?

Không phải trên tài liệu. Không phải “theo lý thuyết là được”. Mà là đã từng làm, từng đo thời gian, từng gặp lỗi và biết những dependency nào sẽ xuất hiện trong lúc Restore.

Backup Success là một tín hiệu tốt — nhưng chưa phải bằng chứng Recovery

Một backup job báo Success chứng minh dữ liệu đã được ghi đến nơi lưu trữ. Nó chưa chứng minh workload có thể quay lại production trong khoảng thời gian business chấp nhận được.

Khi Restore thật sự, nhiều thứ mới xuất hiện: network, permission, application state, dependency, thứ tự khởi động, storage performance, thậm chí cả việc người chịu trách nhiệm có nhớ đúng runbook hay không.

Đó là lý do mình ngày càng xem Restore validation là một phần của Backup design. Backup mà chưa từng Restore giống như một chiếc dù được đóng gói rất đẹp nhưng chưa ai kiểm tra dây.

Khi có test định kỳ, niềm tin bắt đầu được thay bằng evidence.

Observability cũng là một phần của khả năng phục hồi

Lúc đầu nghe có vẻ Monitoring và DR là hai câu chuyện khác nhau. Nhưng khi có incident, chúng gặp nhau rất nhanh.

Muốn recovery tốt, trước tiên team phải hiểu cái gì đang hỏng, phạm vi ảnh hưởng ở đâu và hệ thống đang thay đổi như thế nào. Nếu telemetry rời rạc hoặc Alert quá nhiều noise, thời gian đầu tiên của incident thường bị tiêu tốn chỉ để tìm xem nên nhìn vào đâu.

Vì vậy mình không còn xem Observability chỉ là chuyện Dashboard. Nó giảm uncertainty trong lúc team đang phải đưa ra quyết định.

Rollback plan nên được viết khi mọi người còn bình tĩnh

Một bài học khác đến từ những lần thay đổi Firewall, WAN, Identity hay shared infrastructure.

Trước maintenance window, mọi người thường tập trung vào câu hỏi: “Làm thế nào để cutover thành công?” Nhưng mình thấy một câu khác quan trọng không kém: đến lúc nào thì chúng ta quyết định dừng và quay lại?

Nếu success criteria, validation steps và rollback trigger chỉ được thảo luận sau khi sự cố đã xảy ra, quyết định rất dễ bị ảnh hưởng bởi áp lực thời gian và tâm lý “đã đi đến đây rồi thì cố thêm chút nữa”.

Rollback không phải dấu hiệu của thất bại. Nó là một capability được chuẩn bị trước để giới hạn rủi ro.

Tại sao Governance lại xuất hiện trong một câu chuyện kỹ thuật?

Đây là điều mình hiểu rõ hơn khi làm việc với DR/BCP và ISO/IEC 27001.

Một engineer giỏi có thể nhớ chính xác cách Restore một hệ thống. Nhưng nếu chỉ người đó biết, tổ chức chưa thật sự có capability — tổ chức đang phụ thuộc vào một cá nhân.

Runbook, ownership, test record, evidence và periodic validation đôi khi không hấp dẫn bằng triển khai một công nghệ mới. Nhưng chúng biến kiến thức cá nhân thành một quy trình có thể lặp lại.

Và mình nghĩ đó là điểm Governance gặp Engineering: không phải thêm giấy tờ cho đủ audit, mà làm cho một năng lực kỹ thuật tồn tại ngay cả khi “đúng người” không có mặt.

Mình nhìn Resilience khác đi như thế nào?

Ngày trước, nếu một hệ thống có Uptime cao, Backup đều đặn và ít incident, mình có thể gọi nó là ổn định.

Bây giờ mình muốn hỏi thêm:

Nếu nó hỏng, team có nhìn thấy đủ nhanh không? Có hiểu dependency không? Có Restore được không? Có biết khi nào cần rollback không? Và khả năng đó nằm trong hệ thống vận hành của tổ chức, hay chỉ nằm trong trí nhớ của vài engineer?

Từ những câu hỏi đó, mình dần nhìn Resilience như sự kết hợp của Architecture + Observability + Recovery + Governance.

Uptime vẫn quan trọng. Nhưng Uptime chỉ kể cho chúng ta câu chuyện về những ngày hệ thống chưa gặp điều xấu nhất.

Resilience mới là câu chuyện về việc chúng ta sẽ làm gì khi ngày đó thật sự đến.