Sự Cố
Vào ngày 02.08.25, trong sự kiện PBCTF 4.0 - cuộc thi CTF chủ lực của CLB Point Blank - chúng tôi đã gặp phải điều mà mọi người tổ chức CTF đều sợ hãi: sự cố ngừng hoạt động hoàn toàn của nền tảng. Trong 35 phút căng thẳng từ 10:00 sáng đến 10:35 sáng theo giờ IST, tôi và Govind đã cố gắng khôi phục dịch vụ trong khi 45-50 thành viên khác làm meme và giúp bình tĩnh các tham gia viên đang nổi loạn.
Sự cố không phải là một sự ngừng hoạt động hoàn toàn vì chúng tôi đã có một triển khai CTFd dự phòng chạy trên máy chủ PB của mình, trỏ đến một DNS khác, nơi chúng tôi đã chuyển hướng lưu lượng truy cập. Thật không may, máy chủ PB không đủ mạnh để xử lý tất cả 400 người tham gia nhưng nó đã phục vụ khoảng một nửa trong số đó trong khi phần còn lại của các thành viên PB đã phân tán sự chú ý của nửa còn lại.
Cảm ơn anh Ashutosh Pandey, người đã gợi ý giữ một triển khai dự phòng sẵn sàng.
Giới Thiệu
Tôi là Akash Singh, sinh viên năm cuối ngành kỹ thuật và là người đóng góp mã nguồn mở đến từ Bangalore.
Đây là LinkedIn, GitHub và Twitter của tôi.
Tôi thường được biết đến với tên SkySingh04 trên mạng.
Thời Gian Sự Kiện
T-0: Sự Bình Yên Trước Bão Tố
Lễ khai mạc diễn ra tốt đẹp và chúng tôi đã sẵn sàng để bắt đầu CTF. Cả hai triển khai đều khỏe mạnh và các tham gia viên đang đăng nhập và chuẩn bị cho CTF.
Cụm Kubernetes GCP của chúng tôi là một thỏa thuận tuyệt vời, chúng tôi đã chi 1000 INR để nhận 25000 INR tín dụng GCP và cảm thấy như mình vô địch với tất cả sức mạnh đám mây trong tay.
T+5 phút: "Hãy Mở Rộng!"
Lưu lượng truy cập đang gia tăng. Trong một khoảnh khắc mà tôi tưởng tượng là thời điểm xuất sắc của DevOps (thực sự không phải), tôi đã quyết định mở rộng các pod của chúng tôi. Ai mà không thích tự động mở rộng chứ? 25000 INR cần phải được sử dụng sau cùng.
yaml
# Có chuyện gì có thể xảy ra?
spec:
replicas: 2 # YOLOTôi đang thư giãn sau khi "Tự Động Mở Rộng"
T+10 phút: Dấu Hiệu Đầu Tiên Của Vấn Đề
Các pod mới bắt đầu khởi động. Chúng đã cố gắng thực hiện các bản di chuyển cơ sở dữ liệu - quy trình tiêu chuẩn, đúng không? Sai. Các pod ngay lập tức bị sập với lỗi di chuyển.
T+15 phút: Chế Độ Hoảng Loạn Được Kích Hoạt
Giả thuyết ban đầu của chúng tôi: "Chắc phải có vấn đề với di chuyển!"
Tối hôm trước, Govind đã nói rằng anh ấy đã chạy một số bản di chuyển tùy chỉnh. Có thể có điều gì đó không tương thích? Trong suy nghĩ lớn lao của tôi, tôi đã quyết định xóa tất cả các pod và bắt đầu lại từ đầu.
bash
kubectl delete pods --all -n ctfd
# Những lời cuối cùng nổi tiếng: "Điều này sẽ sửa nó"T+16 phút: Ngừng Hoạt Động Hoàn Toàn
Chúc mừng, chúng tôi đã tự chơi mình. Tất cả các pod đều biến mất. CTFd hoàn toàn ngừng hoạt động trên triển khai k8s và sau đó tất cả các thành viên PB bắt đầu gọi cùng một lúc :
Dịch Vụ Dự Phòng Đã Cứu Chúng Tôi
Đây là nơi chúng tôi nợ một lời cảm ơn lớn đến anh Ashutosh vì lời khuyên sáng suốt của anh ấy: "Luôn giữ một triển khai dự phòng sẵn sàng."
Chúng tôi đã có một phiên bản CTFd thứ hai chạy trên máy chủ PB của mình - hoàn toàn tách biệt khỏi cụm Kubernetes nhưng kết nối với cùng một cơ sở dữ liệu. Trong khi Govind và tôi chiến đấu với triển khai K8s, phiên bản dự phòng này đã tiếp tục phục vụ lưu lượng cho một số người tham gia.
Thủ Phạm Thực Sự
Sau 30 phút gỡ lỗi, kiểm tra các tập lệnh di chuyển và gần như khóc để tìm một giải pháp, tôi đã thấy một pod khẩn cấp được tạo ra sau một số lệnh ngẫu nhiên và cuối cùng khỏe mạnh.
Sau khi mọi thứ ổn định lại và chúng tôi ngồi lại để phân tích RCA, chúng tôi đã tìm ra vấn đề thực sự.
"Chúng tôi đang sử dụng hai phiên bản CTFd khác nhau từ hai máy chủ khác nhau"
- Triển khai của Lavi : Trên máy chủ PB: Phiên bản CTFd mới nhất
- Triển khai của Govind : Trên GCP K8S: CTFd 3.7.2
Cả hai đều kết nối với cùng một cơ sở dữ liệu. Cả hai đều cố gắng chạy các sơ đồ di chuyển khác nhau. Cả hai đều tin rằng họ là đúng.
Và để tôn vinh khoảnh khắc này, meme này đã ra đời :
Những Gì Chúng Tôi Nên Đã Thực Hiện
1. Kiến Trúc Cân Bằng Tải Đúng Cách
Thay vì phương pháp "một số người dùng đi đây, một số đi đó", chúng tôi nên thực hiện:
yaml
# Cài đặt lý tưởng với bộ cân bằng tải bên ngoài
DNS bên ngoài (Cloudflare/Route53)
|
Bộ Cân Bằng Tải
/ \
Cụm K8s Máy Chủ PB
\ /
Cơ Sở Dữ Liệu Chia SẻĐiều này sẽ:
- Tự động phân phối lưu lượng giữa cả hai triển khai
- Cung cấp khả năng chuyển đổi liền mạch khi K8s ngừng hoạt động
- Ngăn chặn kịch bản ngừng hoạt động hoàn toàn
2. Kiểm Tra Tự Động Mở Rộng (Hoặc Đừng Sử Dụng Nó)
Hãy thành thật - chúng tôi đã kích hoạt tự động mở rộng vì nó nghe có vẻ hấp dẫn. Chúng tôi có cần nó không? Có thể không. Chúng tôi có thử nghiệm nó không? Chắc chắn là không.
Bài học rút ra:
- Tự động mở rộng không phải là một giải pháp thần thánh
- Kiểm tra hành vi mở rộng trong môi trường staging trước
- Đôi khi, mở rộng dọc > mở rộng ngang cho các ứng dụng có trạng thái
Các Hạng Mục Hành Động Sau Sự Cố
- [ ] Xin lỗi đội Cyber
- [ ] Đổ lỗi cho người tham gia rằng đó không phải là sự cố máy chủ, mà là internet của họ không ổn định
- [ ] Nhắc nhở bản thân luôn sử dụng phiên bản mới nhất ở mọi nơi
- [ ] Trừng phạt Govind vì không nói cho tôi biết về tập lệnh di chuyển tùy chỉnh mà anh ấy đã chạy tối hôm trước cho đến khi các pod tự động mở rộng sập xuống.
Hơn Cả Những Meme
PBCTF 4.0 đã dạy chúng tôi rằng việc tổ chức một cuộc thi CTF không chỉ là về sự bền bỉ của cơ sở hạ tầng mà còn là chất lượng của thử thách. Mặc dù các tham gia viên của chúng tôi đã trải qua 35 phút ngừng hoạt động, tôi nghĩ rằng lỗi nằm ở internet của họ mà thôi.
Đến tất cả các nhà tổ chức CTF tương lai: Hãy học từ những sai lầm của chúng tôi. Hãy khóa phiên bản của bạn. Kiểm tra khả năng mở rộng của bạn. Và có thể, chỉ có thể, đừng tự động mở rộng trừ khi bạn thực sự cần thiết.
