Khi kiểm thử CI/CD xóa thư mục phương tiện của bạn: Bài học từ một sai lầm DevOps trong thực tế

 

“Nó chạy tốt trên máy của tôi”… cho đến khi nó xóa sạch thư mục media sản xuất của chúng tôi.

 

Gần đây, chúng tôi đã nhận thêm một thực tập sinh DevOps mới tại Glinteco. Một trong những nhiệm vụ đầu tiên của anh ấy là thiết lập CI/CD sử dụng GitHub Actions để triển khai ứng dụng Django của chúng tôi lên máy chủ phát triển.

 

Đó là một nhiệm vụ tương đối an toàn, hoặc ít nhất là chúng tôi nghĩ vậy.

 

Sai lầm đã khiến chúng tôi mất 30% tệp Media

 

Trong nỗ lực chạy các bài kiểm tra triển khai, thực tập sinh đã cấu hình đường dẫn CI/CD để triển khai ứng dụng vào một trang web thử nghiệm trên máy chủ phát triển.

 

Tuy nhiên, máy chủ phát triển có các thư mục được chia sẻ với dữ liệu sản xuất thực tế, bao gồm cả các thư mục được gắn kết được sử dụng bởi các trang web khách hàng đang hoạt động.

 

Một đường dẫn được cấu hình sai trong đường dẫn CI/CD đã khiến việc triển khai ghi đè lên thư mục MEDIA được chia sẻ, nơi lưu trữ các hình ảnh và tệp được tải lên cho một dự án Django trực tiếp.

 

Không sao lưu. Không cảnh báo. Chỉ còn lại sự mất mát.

 

Đột nhiên, các trang web trực tiếp đầy các liên kết hình ảnh bị hỏng. Khách hàng bị ảnh hưởng. Và chúng tôi phải hành động nhanh chóng.

 

Cách chúng tôi phục hồi từ thảm họa

 

Nhóm DevOps của chúng tôi đã nhanh chóng hành động:

 

• Kiểm tra các commit GitHub và nhật ký CI để xác định khi nào việc xóa xảy ra
   

• Tìm kiếm tên tệp và đường dẫn từ các tham chiếu cơ sở dữ liệu cũ và nhật ký ứng dụng
   

• Tìm kiếm trong tất cả các máy phát triển cục bộ và thiết bị đầu cuối triển khai được nhóm của chúng tôi sử dụng để phục hồi các hình ảnh được lưu trong bộ nhớ cache hoặc đã được tải lên trước đó
   

• Đánh giá và thiết kế thủ công các hình ảnh mới cho bài đăng trên blog để thay thế những hình ảnh bị thiếu

 

Cuối cùng, chúng tôi đã quản lý để phục hồi khoảng 70% các tệp media. 30% còn lại bị mất không thể khôi phục, chủ yếu là hình ảnh liên quan đến blog, may mắn là không ảnh hưởng đến chức năng quan trọng của người dùng.

 

Nhưng điều này có thể còn tồi tệ hơn nhiều.

 

Bài học kinh nghiệm quan trọng (và bạn cũng nên học)

 

Câu chuyện này không phải là duy nhất nhưng nỗi đau thì rất thật. Dưới đây là những gì chúng tôi đã rút ra:

 

1. KHÔNG BAO GIỜ sử dụng dữ liệu hoặc khóa Sản xuất trên máy chủ Phát triển/Kiểm thử

 

Môi trường phát triển của bạn nên được cách ly hoàn toàn với sản xuất:

 

• Các cơ sở dữ liệu khác nhau
   

• Các đường dẫn tệp khác nhau
   

• Các biến môi trường khác nhau (không có khóa bucket S3 sản xuất, vui lòng!)

 

2. Luôn sao lưu trước khi bạn chạm vào triển khai

 

Ngay cả đối với các máy chủ phát triển, nếu chúng chứa bất kỳ dữ liệu quan trọng hoặc được chia sẻ nào, hãy tự động sao lưu trước bất kỳ lần triển khai nào. Nếu máy chủ nhỏ, bạn thậm chí có thể tạo một script sao lưu tarball nhanh.

 

“Không ai hối hận vì có quá nhiều bản sao lưu.”

 

3. Không sử dụng lại cơ sở hạ tầng chia sẻ để kiểm thử

 

Tránh sử dụng cùng một máy chủ (hoặc các thư mục được chia sẻ) cho cả kiểm thử và sản xuất. Nếu tài nguyên bị hạn chế, ít nhất hãy sử dụng các container, VM hoặc điểm gắn kết riêng biệt.

 

4. Thực thi quy trình xem xét và phê duyệt

 

Thực tập sinh (và cả các kỹ sư toàn thời gian) luôn nên:

 

• Gửi các thay đổi cấu hình triển khai thông qua PR.
   

• Gắn thẻ các thành viên cấp cao trong nhóm để xem xét.
   

• Xác nhận môi trường mục tiêu và đường dẫn tệp trước khi triển khai.

 

5. Xây dựng một mạng lưới an toàn vào đường dẫn CI/CD

 

Thêm các biện pháp bảo vệ này:

 

• Chế độ chạy thử hoặc chế độ tạm thời trước khi triển khai thực tế.
   

• Logic triển khai có điều kiện (nếu kiểm tra nhánh, môi trường hoặc thư mục).
   

• Nhật ký và cảnh báo cho các hoạt động tệp.

 

6. Tài liệu hóa và phiên bản cấu hình triển khai của bạn

 

Nếu có sự cố xảy ra, việc có cơ sở hạ tầng được kiểm soát phiên bản cho phép bạn:

 

• Theo dõi các thay đổi nhanh chóng
   

• Hoàn nguyên nếu cần
   

• Học hỏi từ những sai lầm

 

Suy nghĩ cuối cùng

 

DevOps không chỉ là tự động hóa - đó là về tự động hóa an toàn.

 

Sự cố này đã nhắc nhở chúng tôi về việc một cấu hình sai nhỏ có thể lan rộng thành mất dữ liệu khổng lồ, ngay cả với những ý định tốt nhất.

 

Chúng tôi rất biết ơn vì chỉ là hình ảnh blog. Nhưng lần sau, nó có thể là thứ tồi tệ hơn.

 

Hãy để câu chuyện này là một câu chuyện răn đe và là một danh sách kiểm tra cho nhóm của bạn.