Akhir bulan pertama dan awal bulan kedua musim panas tahun 2019 ternyata merupakan masa yang sulit dan ditandai dengan beberapa penurunan besar dalam layanan TI global. Di antara yang penting: dua insiden serius dalam infrastruktur CloudFlare (yang pertama - dengan tangan yang tidak benar dan sikap lalai terhadap BGP di pihak beberapa ISP dari AS; yang kedua - dengan penerapan CF itu sendiri yang tidak benar, yang memengaruhi semua orang yang menggunakan CF , dan ini adalah banyak layanan penting) dan pengoperasian infrastruktur CDN Facebook yang tidak stabil (memengaruhi semua produk FB, termasuk Instagram dan WhatsApp). Kami juga harus ikut terdampak dalam distribusi, meskipun pemadaman kami tidak terlalu terlihat jika dibandingkan dengan latar belakang global. Seseorang sudah mulai menyeret helikopter hitam dan konspirasi “berdaulat”, jadi kami merilis post mortem publik atas insiden kami.
03.07.2019, 16: 05
Masalah sumber daya mulai tercatat, mirip dengan gangguan konektivitas jaringan internal. Karena belum sepenuhnya memeriksa semuanya, mereka mulai melakukan kesalahan pada kinerja saluran eksternal menuju DataLine, karena ternyata masalahnya ada pada akses jaringan internal ke Internet (NAT), hingga mereka menghentikan sementara sesi BGP. menuju DataLine.
03.07.2019, 16: 35
Jelas terlihat bahwa peralatan yang menyediakan terjemahan alamat jaringan dan akses dari jaringan lokal situs ke Internet (NAT) telah gagal. Upaya untuk me-reboot peralatan tidak menghasilkan apa-apa, pencarian opsi alternatif untuk mengatur konektivitas dimulai sebelum mendapat tanggapan dari dukungan teknis, karena dari pengalaman, hal ini kemungkinan besar tidak akan membantu.
Masalahnya diperburuk oleh kenyataan bahwa peralatan ini juga memutus koneksi masuk dari karyawan klien VPN, dan pekerjaan pemulihan jarak jauh menjadi lebih sulit untuk dilakukan.
03.07.2019, 16: 40
Kami mencoba menghidupkan kembali skema NAT cadangan yang sudah ada sebelumnya dan telah bekerja dengan baik sebelumnya. Namun menjadi jelas bahwa sejumlah perbaikan jaringan membuat skema ini hampir tidak berfungsi sama sekali, karena pemulihannya bisa saja tidak berhasil, atau, paling buruk, merusak apa yang sudah berjalan.
Kami mulai mengerjakan beberapa ide untuk mentransfer lalu lintas ke sekumpulan router baru yang melayani tulang punggung, tetapi ide tersebut tampaknya tidak dapat dilaksanakan karena kekhasan distribusi rute di jaringan inti.
03.07.2019, 17: 05
Pada saat yang sama, masalah teridentifikasi dalam mekanisme resolusi nama pada server nama, yang menyebabkan kesalahan dalam penyelesaian titik akhir dalam aplikasi, dan mereka mulai dengan cepat mengisi file host dengan catatan layanan penting.
03.07.2019, 17: 27
Fungsionalitas terbatas Habr telah dipulihkan.
03.07.2019, 17: 43
Namun pada akhirnya, solusi yang relatif aman ditemukan untuk mengatur lalu lintas melalui salah satu router perbatasan, yang dengan cepat dipasang. Konektivitas internet telah dipulihkan.
Selama beberapa menit berikutnya, banyak pemberitahuan datang dari sistem pemantauan tentang pemulihan fungsi agen pemantauan, namun beberapa layanan ternyata tidak dapat dioperasikan karena mekanisme resolusi nama pada server nama (dns) rusak.
03.07.2019, 17: 52
NS telah dimulai ulang dan cache telah dibersihkan. Penyelesaian telah dipulihkan.
03.07.2019, 17: 55
Semua layanan mulai berfungsi kecuali MK, Freelansim dan Toaster.
03.07.2019, 18: 02
MK dan Freelansim mulai bekerja.
03.07.2019, 18: 07
Kembalikan sesi BGP yang tidak berbahaya dengan DataLine.
03.07.2019, 18: 25
Mereka mulai mencatat masalah dengan sumber daya, yang disebabkan oleh perubahan alamat eksternal kumpulan NAT dan ketidakhadirannya di acl sejumlah layanan, yang segera diperbaiki. Pemanggang roti segera mulai bekerja.
03.07.2019, 20: 30
Kami melihat kesalahan terkait bot Telegram. Ternyata mereka lupa mendaftarkan alamat eksternal di beberapa acl (server proxy), yang segera diperbaiki.
Temuan
- Peralatan yang sebelumnya menimbulkan keraguan akan kesesuaiannya, ternyata gagal. Ada rencana untuk menghilangkannya dari pekerjaan, karena mengganggu pengembangan jaringan dan memiliki masalah kompatibilitas, tetapi pada saat yang sama menjalankan fungsi penting, itulah sebabnya penggantian apa pun secara teknis sulit dilakukan tanpa mengganggu layanan. Sekarang Anda dapat melanjutkan.
- Masalah DNS dapat dihindari dengan memindahkannya lebih dekat ke jaringan backbone baru di luar jaringan NAT dan masih memiliki konektivitas penuh ke jaringan abu-abu tanpa terjemahan (yang merupakan rencana sebelum kejadian).
- Anda tidak boleh menggunakan nama domain saat merakit cluster RDBMS, karena kenyamanan mengubah alamat IP secara transparan tidak terlalu diperlukan, karena manipulasi seperti itu masih memerlukan pembangunan kembali cluster. Keputusan ini ditentukan oleh alasan historis dan, pertama-tama, oleh kejelasan nama titik akhir dalam konfigurasi RDBMS. Secara umum, jebakan klasik.
- Pada prinsipnya, latihan yang sebanding dengan “kedaulatan Runet” telah dilakukan, ada sesuatu yang perlu dipikirkan dalam hal memperkuat kemampuan kelangsungan hidup otonom.
Sumber: www.habr.com