6 câu chuyện sự cố đáng sợ

1. Charity Majors, CTO của Honeycomb

• Push notification không được gửi tới người dùng ở một khu vực cụ thể (Đông Âu)

• Bắt đầu xảy ra ngay sau khi thay đổi kích thước ASG

• Nguyên nhân là do bản ghi DNS Round Robin vượt quá kích thước gói UDP

2. Matthew Fornaciari, CTO của Gremlin

• Sự cố xảy ra vì đĩa đầy nên không thể ghi log

• Phát triển tính năng log rotation

• Thiết lập cảnh báo mức sử dụng đĩa

• Bổ sung để có thể kiểm thử qua Gremlin (chaos engineering)

3. Lirran Haimovitch, CTO của Rookout

"Truyền thuyết đô thị rằng server cứ đến một giờ nhất định mỗi ngày là lại sập,

sau vài tuần điều tra cuối cùng đã tìm ra nguyên nhân từ camera an ninh,

nhân viên vệ sinh đã ngắt kết nối server để cắm máy hút bụi"

4. Daniel "Spoons" Spoonhower, CTO của Lightstep

• Ứng dụng không tải được

• Hôm đó không có triển khai hay thay đổi hạ tầng nào

• Xác nhận chỉ người dùng nội bộ là gặp vấn đề

• Trong lúc kiểm tra API dùng để tải ứng dụng, phát hiện phần trả về dữ liệu bổ sung đối với người dùng nội bộ

• Payload đã tăng dần trong vài tuần trước đó, và đến chiều hôm ấy vượt quá kích thước payload tối đa khiến ứng dụng không thể tải

5. Lee liu, CTO của LogDNA

6. Ting Huang, CTO của Transpoit

• Không thể đọc trên Twitter mobile

• Phát hiện vấn đề ở thư viện mới không parse được session cookie

[kunggom]

Trường hợp số 5, phần không được tóm tắt nội dung, có vẻ là liên quan đến việc chứng chỉ hết hạn.

Người ta nghĩ rằng chứng chỉ hết hạn đúng như dự kiến thì sẽ không có vấn đề gì, nhưng điều đó chỉ đúng với các hệ thống mới phát triển; còn ở các hệ thống legacy vẫn đang được sử dụng thì sự cố đã xảy ra. Trớ trêu là cùng vấn đề đó cũng bùng lên ở giải pháp CI/CD đang dùng, khiến mọi chuyện càng phức tạp hơn.

[kbumsik]

"Nhân viên vệ sinh đã ngắt kết nối máy chủ để cắm máy hút bụi"

Ôi trời...

[kunggom]

Đọc nguyên văn thì hóa ra phần đó chỉ là để mở đầu câu chuyện, còn sự cố thực tế là mỗi khi quản trị viên phía khách hàng chạy một truy vấn chỉ thỉnh thoảng mới dùng, thường là lúc họp, nó đã khóa toàn bộ bảng nên mỗi lần như vậy độ trễ của dịch vụ backend lại tăng lên không có giới hạn. Họ đã tối ưu truy vấn bị nghi ngờ nhưng đó là chẩn đoán sai, nên cứ mỗi lần phía khách hàng thấy trang quá chậm rồi liên tục nhấn làm mới thì hiện tượng tương tự lại tiếp tục xảy ra.

[kunggom]

Một trải nghiệm cá nhân có phần tương tự.

Đó là khi tôi nhận gấp một công việc liên quan đến một trung tâm mua sắm trực tuyến với tư cách freelancer.

Rạng sáng, bên phía trung tâm mua sắm đã thực hiện một thay đổi lớn (nâng cấp phiên bản quy mô lớn của giải pháp), rồi sau khi xác nhận các chức năng chính như thanh toán sản phẩm không có vấn đề gì thì mở lại hoạt động. Nhưng đến chiều thì đột nhiên website của trung tâm mua sắm chậm hẳn đi, rồi cuối cùng gần như tê liệt. Hóa ra nguyên nhân là do trang dành cho người bán được gắn riêng vào trung tâm mua sắm. Họ đang vận hành bằng cách gắn thêm một trang quản trị dành cho người bán được phát triển tùy chỉnh vào giải pháp trung tâm mua sắm, và mỗi khi vào đó thì một truy vấn cực nặng lại được thực thi. Sau khi trung tâm mua sắm mở lại, cứ mỗi lần các người bán riêng lẻ truy cập để xem tình hình bán hàng thì tải lên MySQL lại tăng mạnh, kết quả là bản thân trung tâm mua sắm cũng bị chậm theo. Kiểm tra ra thì vì lý do nào đó, index trên các bảng liên quan không được thiết lập đúng cách. Cuối cùng, bằng cách thiết lập lại index cho chuẩn và tinh chỉnh một vài tham số, chúng tôi đã giải quyết được tình trạng bản thân trung tâm mua sắm bị chậm.

[kbumsik]

Ồ, cảm ơn bạn đã chia sẻ trải nghiệm.

Quả thật, vì tài liệu phục vụ cho việc quản trị hoặc ra quyết định kinh doanh thường dùng aggregation nên chắc tải sẽ khá lớn nhỉ. Tôi không phải là web developer nên cũng không rõ lắm, nhưng dạo này có vẻ người ta gọi đó là data engineering và tách riêng dữ liệu ra để gom lại thì phải.

[kunggom]

Đúng như bạn nói, cách làm bài bản là tách riêng những dữ liệu như vậy để xử lý, nhưng trung tâm thương mại điện tử mà tôi từng làm lại là một hệ thống legacy có khá nhiều chỗ bất hợp lý, nên hoàn toàn không hề có những cân nhắc về mặt kiến trúc như thế. Một phiên bản MySQL rất cũ (từ thời MyISAM chứ không phải InnoDB còn là engine mặc định) chạy cùng với một phiên bản Apache web server cũng đã cũ trong cùng một VM instance. Giải pháp dùng để vận hành trang thương mại điện tử đó cũng đã bị xếp vào loại legacy và chỉ còn được phát hành các bản vá. Những vấn đề mang tính cấu trúc của giải pháp mà tôi cảm nhận được trong lúc làm việc dường như đã được giải quyết ngay từ đầu ở phiên bản mới được phát triển lại từ đầu, nhưng với tôi, người phải đụng vào phiên bản legacy, điều đó hoàn toàn không mang lại ảnh hưởng gì. Mới đó mà chuyện ấy đã là từ năm ngoái rồi.