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 chuyện 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à tín hiệu tốt, nhưng chưa đủ

Một backup job báo Success cho mình biết 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 thực hiện 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. Có backup mà chưa từng Restore thì mình vẫn chưa thật sự yên tâm.

Khi có test định kỳ, cảm giác “chắc là được” bắt đầu được thay bằng bằng chứng rõ ràng hơn.

Monitoring và DR gặp nhau rất nhanh khi có incident

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 gần như ngay lập tức.

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 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 Monitoring chỉ là chuyện Dashboard. Khi có sự cố, nó giúp team bớt đoán và có thêm dữ liệu để 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ì 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”.

Với mình, rollback không phải phương án dành cho lúc team mất niềm tin. Nó là một đường quay lại đã được chuẩn bị trước khi change bắt đầu.

Tài liệu chỉ hữu ích khi có người khác dùng được

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

Một engineer có thể nhớ rất rõ cách Restore một hệ thống. Nhưng nếu chỉ người đó biết, đến lúc người đó nghỉ phép hoặc không có mặt thì cả team vẫn gặp rủi ro.

Runbook, ownership, test record và evidence đôi khi không thú vị bằng triển khai một công nghệ mới. Nhưng chúng giúp biến cách làm của một người thành thứ người khác có thể theo lại được.

Vì vậy mình không xem phần này đơn thuần là “làm hồ sơ cho audit”. Nếu tài liệu giúp team Restore đúng, biết ai chịu trách nhiệm và có bằng chứng lần test gần nhất, nó đang phục vụ vận hành thật.

Sau một thời gian, mình bắt đầu hỏi khác đi

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à cách làm đó có nằm trong runbook để người khác thực hiện được không?

Uptime vẫn quan trọng. Nhưng nó chỉ cho mình biết hệ thống đã chạy thế nào trong những ngày bình thường.

Khả năng phục hồi chỉ lộ rõ khi mình thật sự thử đưa một thứ đã hỏng trở lại.