Thời gian cuối tháng đầu tiên và đầu tháng thứ hai của mùa hè năm 2019 diễn ra đầy khó khăn và được đánh dấu bằng một số đợt sụt giảm lớn về dịch vụ CNTT toàn cầu. Trong số những sự cố đáng chú ý: hai sự cố nghiêm trọng trong cơ sở hạ tầng CloudFlare (sự cố đầu tiên - với bàn tay quanh co và thái độ cẩu thả đối với BGP của một số ISP từ Hoa Kỳ; sự cố thứ hai - với việc triển khai CF không chính xác, ảnh hưởng đến mọi người sử dụng CF và đây là nhiều dịch vụ đáng chú ý) và hoạt động không ổn định của cơ sở hạ tầng CDN của Facebook (ảnh hưởng đến tất cả các sản phẩm của FB, bao gồm Instagram và WhatsApp). Chúng tôi cũng phải tham gia vào quá trình phân phối, mặc dù tình trạng ngừng hoạt động của chúng tôi ít được chú ý hơn nhiều so với bối cảnh toàn cầu. Ai đó đã bắt đầu lôi kéo những chiếc trực thăng đen và những âm mưu "có chủ quyền", vì vậy chúng tôi sẽ công bố kết quả khám nghiệm tử thi công khai về vụ việc của mình.
03.07.2019, 16: 05
Các vấn đề về tài nguyên bắt đầu được ghi nhận, tương tự như sự cố kết nối mạng nội bộ. Chưa kiểm tra đầy đủ mọi thứ, họ bắt đầu mắc lỗi về hiệu suất của kênh bên ngoài đối với DataLine, vì rõ ràng vấn đề là do quyền truy cập Internet (NAT) của mạng nội bộ, đến mức họ đã tạm dừng phiên BGP hướng tới DataLine.
03.07.2019, 16: 35
Rõ ràng là thiết bị cung cấp dịch địa chỉ mạng và truy cập từ mạng cục bộ của trang web tới Internet (NAT) đã bị lỗi. Nỗ lực khởi động lại thiết bị không dẫn đến kết quả gì, việc tìm kiếm các phương án thay thế để tổ chức kết nối đã bắt đầu trước khi nhận được phản hồi từ bộ phận hỗ trợ kỹ thuật, vì theo kinh nghiệm, điều này rất có thể sẽ không giúp ích được gì.
Vấn đề có phần trở nên trầm trọng hơn do thiết bị này cũng chấm dứt các kết nối đến của nhân viên VPN máy khách, khiến công việc khôi phục từ xa trở nên khó thực hiện hơn.
03.07.2019, 16: 40
Chúng tôi đã cố gắng khôi phục sơ đồ NAT dự phòng hiện có trước đây và đã hoạt động tốt trước đó. Nhưng rõ ràng là một số đợt nâng cấp mạng đã khiến kế hoạch này gần như hoàn toàn không hoạt động, vì việc khôi phục nó trong trường hợp tốt nhất có thể không hoạt động hoặc tệ nhất là phá vỡ những gì đã hoạt động.
Chúng tôi bắt đầu thực hiện một số ý tưởng để chuyển lưu lượng truy cập đến một bộ định tuyến mới phục vụ đường trục, nhưng chúng dường như không thể thực hiện được do đặc thù của việc phân bổ các tuyến đường trong mạng lõi.
03.07.2019, 17: 05
Đồng thời, một vấn đề đã được xác định trong cơ chế phân giải tên trên các máy chủ định danh, dẫn đến lỗi trong việc phân giải điểm cuối trong ứng dụng và chúng bắt đầu nhanh chóng lấp đầy các tệp máy chủ bằng bản ghi các dịch vụ quan trọng.
03.07.2019, 17: 27
Chức năng hạn chế của Habr đã được khôi phục.
03.07.2019, 17: 43
Nhưng cuối cùng, một giải pháp tương đối an toàn đã được tìm ra để tổ chức lưu lượng truy cập thông qua một trong các bộ định tuyến biên giới và giải pháp này đã nhanh chóng được cài đặt. Kết nối Internet đã được khôi phục.
Trong vài phút tiếp theo, rất nhiều thông báo đến từ hệ thống giám sát về việc khôi phục chức năng của tác nhân giám sát, nhưng một số dịch vụ hóa ra không thể hoạt động do cơ chế phân giải tên trên máy chủ định danh (dns) đã bị hỏng.
03.07.2019, 17: 52
NS đã được khởi động lại và bộ đệm đã bị xóa. Việc giải quyết đã được khôi phục.
03.07.2019, 17: 55
Tất cả các dịch vụ bắt đầu hoạt động ngoại trừ MK, Freelansim và Toaster.
03.07.2019, 18: 02
MK và Freelansim bắt đầu làm việc.
03.07.2019, 18: 07
Đã hoàn nguyên phiên BGP vô tội với DataLine.
03.07.2019, 18: 25
Họ bắt đầu ghi lại các vấn đề về tài nguyên, nguyên nhân là do sự thay đổi địa chỉ bên ngoài của nhóm NAT và sự vắng mặt của nó trong acl của một số dịch vụ, điều này đã được khắc phục kịp thời. Máy nướng bánh mì bắt đầu hoạt động ngay lập tức.
03.07.2019, 20: 30
Chúng tôi nhận thấy các lỗi liên quan đến bot Telegram. Hóa ra họ đã quên đăng ký địa chỉ bên ngoài trong một vài acl (máy chủ proxy), điều này đã được sửa chữa kịp thời.
Những phát hiện
- Thiết bị trước đây gây nghi ngờ về tính phù hợp của nó đã thất bại. Đã có kế hoạch loại bỏ nó khỏi hoạt động vì nó cản trở sự phát triển của mạng và có vấn đề về khả năng tương thích, nhưng đồng thời nó thực hiện một chức năng quan trọng, đó là lý do tại sao mọi sự thay thế đều khó khăn về mặt kỹ thuật mà không làm gián đoạn dịch vụ. Bây giờ bạn có thể tiếp tục.
- Có thể tránh được sự cố DNS bằng cách di chuyển chúng đến gần mạng đường trục mới bên ngoài mạng NAT và vẫn có đầy đủ kết nối với mạng xám mà không cần dịch thuật (đó là kế hoạch trước khi xảy ra sự cố).
- Bạn không nên sử dụng tên miền khi tập hợp các cụm RDBMS, vì sự tiện lợi của việc thay đổi địa chỉ IP một cách minh bạch là không đặc biệt cần thiết, vì những thao tác như vậy vẫn yêu cầu phải xây dựng lại cụm. Quyết định này được đưa ra bởi các lý do lịch sử và trước hết là bởi sự rõ ràng của các điểm cuối theo tên trong cấu hình RDBMS. Nói chung, một cái bẫy cổ điển.
- Về nguyên tắc, các cuộc tập trận có thể so sánh với “chủ quyền hóa Runet” đã được tiến hành, có điều gì đó cần suy nghĩ về việc tăng cường khả năng sinh tồn tự chủ.
Nguồn: www.habr.com