Akhir dari bulan pertama dan awal bulan kedua musim panas tahun 2019 ternyata menjadi sulit dan ditandai oleh beberapa penurunan besar dalam layanan TI dunia. Dari yang terkenal: dua insiden serius dalam infrastruktur CloudFlare (yang pertama - dengan tangan yang bengkok dan sikap ceroboh ke BGP oleh beberapa ISP dari AS; yang kedua - dengan penyebaran CF sendiri yang bengkok, memengaruhi setiap orang yang menggunakan CF, dan ini adalah banyak layanan penting) dan pengoperasian infrastruktur Facebook CDN yang tidak stabil (memengaruhi semua produk FB, termasuk Instagram dan WhatsApp). Kami juga harus mendapatkan di bawah distribusi, meskipun pemadaman kami kurang terlihat pada latar belakang global. Seseorang sudah mulai menyeret helikopter hitam dan konspirasi "berdaulat", oleh karena itu kami merilis pos pemeriksaan mayat publik dari insiden kami.
07/03/2019, 16:05Kami mulai memperbaiki masalah sumber daya, mirip dengan pelanggaran konektivitas jaringan internal. Karena tidak sepenuhnya memeriksa semuanya, mereka mulai berbuat dosa pada operabilitas saluran eksternal ke arah Data Line, karena menjadi jelas bahwa ada masalah dengan akses jaringan internal ke Internet (NAT), hingga mereka menempatkan sesi BGP ke arah DataLine.
07/03/2019, 16:35Menjadi jelas bahwa peralatan yang melakukan terjemahan alamat jaringan dan akses dari jaringan area lokal situs ke Internet (NAT) gagal. Upaya untuk mem-boot ulang peralatan tidak menghasilkan apa-apa, pencarian opsi alternatif untuk mengatur konektivitas dimulai sebelum menerima respons dari dukungan teknis, karena dari pengalaman hal ini kemungkinan besar tidak akan membantu.
Masalahnya agak diperburuk oleh fakta bahwa peralatan ini juga memutuskan koneksi masuk karyawan VPN klien, pekerjaan restorasi jarak jauh menjadi lebih sulit untuk dilakukan.
07/03/2019, 16:40Kami mencoba untuk menghidupkan kembali skema fallback NAT yang sudah ada sebelumnya yang telah bekerja keras sebelumnya. Tetapi menjadi jelas bahwa sejumlah peralatan ulang jaringan membuat skema ini hampir sepenuhnya tidak beroperasi, karena pemulihannya mungkin tidak berfungsi dalam kasus terbaik, dan yang terburuk, hancurkan yang sudah bekerja.
Mereka mulai mengerjakan beberapa ide untuk mentransfer lalu lintas ke kompleks router baru yang melayani tulang punggung, tetapi mereka tampaknya tidak beroperasi karena kekhasan distribusi rute di jaringan inti.
07/03/2019, 17:05Pada saat yang sama, masalah terungkap dalam mekanisme untuk menyelesaikan nama pada server nama, yang menyebabkan kesalahan dalam menyelesaikan titik akhir dalam aplikasi, mereka mulai dengan cepat mengisi file host dengan catatan layanan penting.
07/03/2019, 17:27Mengembalikan fungsi Habr yang terbatas.
07/03/2019, 17:43Tetapi pada akhirnya, solusi yang relatif aman ditemukan untuk mengatur lalu lintas yang melewati hanya satu dari router perbatasan, yang dengan cepat dicabut. Konektivitas internet telah pulih.
Selama beberapa menit berikutnya, sistem pemantauan menerima banyak pemberitahuan tentang pemulihan kapasitas kerja agen pemantauan, tetapi beberapa layanan ternyata tidak beroperasi, karena mekanisme resolusi nama pada server nama (dns) dilanggar.
07/03/2019, 17:52NS telah dimulai ulang, cache telah direset. Penyelesaian pulih.
07/03/2019, 17:55Dapatkan semua layanan kecuali MK, Freelansim, dan Pemanggang Roti.
07/03/2019, 18:02Memperoleh MK dan Freelansim.
07/03/2019, 18:07Membawa kembali sesi BGP yang tidak bersalah dengan DataLine.
07/03/2019, 18:25Mereka mulai memperbaiki flensa pada sumber daya, itu dikaitkan dengan perubahan alamat eksternal dari kolam NAT dan tidak adanya di sejumlah layanan, dengan cepat diperbaiki. Segera diterima dan Pemanggang Roti.
07/03/2019, 20:30Kami melihat kesalahan terkait dengan bot Telegram. Ternyata mereka lupa mendaftarkan alamat eksternal di sepasang acl (proxy-server), mereka dengan cepat memperbaikinya.
Kesimpulan
- Peralatan gagal, yang bahkan sebelum itu telah meragukan kesesuaiannya. Ada rencana untuk mengeluarkannya dari pekerjaan, karena mengganggu pengembangan jaringan dan memiliki masalah kompatibilitas, tetapi pada saat yang sama melakukan fungsi kritis, itulah sebabnya setiap penggantian secara teknis tidak mudah tanpa gangguan layanan. Sekarang Anda bisa melanjutkan.
- Masalah DNS dapat dihindari dengan memindahkan mereka lebih dekat ke jaringan backbone baru di luar jaringan NAT dan pada saat yang sama dengan konektivitas penuh ke jaringan abu-abu tanpa terjemahan (yang direncanakan sebelum kejadian).
- Jangan menggunakan nama domain ketika merakit cluster RDBMS, karena kemudahan mengubah alamat IP secara transparan tidak terlalu diperlukan, karena semua sama, manipulasi seperti itu membutuhkan cluster reassembly. Keputusan ini ditentukan oleh alasan historis dan, pertama-tama, oleh kejelasan titik akhir dengan nama dalam konfigurasi RDBMS. Secara umum, perangkap klasik.
- Pada prinsipnya, latihan telah dilakukan sebanding dengan "kedaulatan Runet", ada sesuatu untuk dipikirkan dari sudut pandang memperkuat kemungkinan kelangsungan hidup otonom.