Apa yang ditunjukkan oleh 'Musim Panas Pemadaman', dan apa yang bisa kita lakukan

Musim panas 2019 adalah masa yang sulit untuk internet, dengan pemadaman sistemik sering terjadi dan berturut-turut cepat.

Beberapa dari pemadaman ini disebabkan oleh kesalahan internal, yang lain eksternal, tetapi dua penyebab utama muncul: kompleksitas jaringan yang lebih besar dan frekuensi dan laju perubahan kode. Secara keseluruhan, pemadaman ini berfungsi sebagai pengingat menyakitkan betapa rapuhnya internet, terutama ketika jaringan dan layanan tumbuh semakin saling berhubungan dan saling bergantung.

Pemadaman utama adalah:

• Pada 2 Juni, Google mengalami pemadaman yang disalahkan oleh perusahaan atas "tingkat kepadatan jaringan yang tinggi di AS bagian timur". Beberapa layanan paling populer, termasuk Search, Nest, YouTube dan Gmail terhenti. Tidak lama kemudian, Kalender Google turun, dengan bercanda memberi banyak pengguna akhir alasan untuk menyatakan hari libur.
• Cloudflare turun pada 24 Juni karena kebocoran jaringan kecil, yang memengaruhi domain yang mengandalkan jaringan pengiriman konten terkemuka ini (CDN). Pengguna akhir dikunci dari layanan populer termasuk Discord, Google, Amazon dan lainnya.
• Pada 3 Juli, Google dan Cloudflare sama-sama dilanda pemadaman tambahan.
• Juga pada 3 Juli, Facebook memiliki masalah memuat gambar, video, dan data lainnya di seluruh aplikasi dan layanan utama, termasuk Instagram, WhatsApp, dan Messenger. Facebook menyalahkan ini pada "kesalahan yang dipicu selama operasi pemeliharaan rutin."
• Apple bergabung dengan klub sehari kemudian, dengan pemadaman awan tiga jam yang melanda App Store, Apple Musik dan Apple TELEVISI.
• Akhirnya, pada 11 Juli, Twitter mengalami pemadaman aplikasi web dan seluler selama satu jam, yang dihasilkan dari apa yang oleh perusahaan disebut "perubahan sistem internal".

Anda tidak dapat mencegah pemadaman seperti itu terjadi, tetapi Anda dapat dengan lebih baik melindungi organisasi Anda dari ketidakpastian yang tak terduga dengan berfokus pada lima kategori ini:

Tetap waspada terhadap pemadaman di sebanyak mungkin wilayah geografis, dan dari perspektif jaringan sebanyak mungkin: Apakah berbagai segmen pengguna akhir Anda dapat mengakses situs web atau layanan tergantung pada rantai panjang elemen yang mempengaruhi kinerja yang berdiri di antara mereka dan pusat data Anda. Ini termasuk CDN, cloud, ISP regional dan lokal, jaringan seluler dan banyak lagi.

Karena langkah pertama dipersiapkan untuk / menanggapi pemadaman listrik adalah dengan mendeteksinya secara proaktif, ini hampir mustahil jika Anda hanya menguji ketersediaan secara nasional atau di geografi terbatas. Hal yang sama berlaku jika Anda hanya melacak dari sejumlah kecil tempat-tempat jaringan, seperti cloud atau segelintir ISP atau operator seluler. Pendekatan sempit seperti itu akan meninggalkan Anda dengan bintik-bintik buta yang signifikan. Jangkauan yang lebih luas memberi Anda pemberitahuan sebelumnya tentang lebih banyak pemadaman dan memberikan kesempatan yang lebih baik untuk menempatkan rencana cadangan, jika tersedia, atau untuk berkomunikasi secara proaktif dengan pengguna akhir yang terkena dampak, memberi tahu mereka bahwa Anda sedang mengatasi masalah tersebut.

Mengurangi waktu rata-rata untuk mendeteksi dan berarti waktu untuk memperbaiki: Sementara deteksi dini dan pemberitahuan pemadaman berguna, niat baik pengguna akhir hanya akan bertahan begitu lama. Tidak cukup hanya mengetahui suatu insiden sedang terjadi; Anda juga perlu mencari tahu apa yang menyebabkannya, dan cepat. Dalam beberapa kasus, masalahnya adalah sesuatu di dalam firewall Anda sendiri yang dapat Anda perbaiki. Dalam kasus lain, kesalahan akan menjadi sesuatu di luar kendali langsung Anda, seperti layanan cloud, CDN atau jaringan operator.

Sekalipun masalahnya adalah sesuatu yang tidak bisa Anda atasi secara langsung, pengetahuan ini adalah kekuatan – karena itu berarti Anda tidak mengirim tim IT Ops Anda dan insinyur keandalan situs (SRE) ke dalam jam-jam terbuang untuk perang, yang menyebabkan kelelahan yang waspada. , kelelahan dan kehilangan waktu di mana mereka dapat secara proaktif berfokus pada peningkatan ketersediaan dalam jangka panjang.

Aktifkan pelacakan rute BGP – Internet pada dasarnya adalah sirkuit yang mengirimkan sinyal dan paket data melalui jalur jaringan yang berbeda. Beberapa protokol mengelola aliran data ini, salah satunya adalah Border Gateway Protocol, atau BGP. BGP mengatur bagaimana data ditransmisikan antara berbagai entitas jaringan otonom. Internet mengandalkannya untuk bekerja, tetapi kesalahan tumbuh dapat muncul karena pembajakan, kesalahan konfigurasi kebijakan, flap rute, dan masalah peering. Hal ini dapat menyebabkan paket dikirim secara tidak sengaja ke tujuan yang salah, atau berakhir sama sekali.

Salah satu contoh nyata dari kebocoran BGP melibatkan Google November lalu. Dalam kasus “grand theft internet,” lalu lintas layanan Google dari berbagai negara dan situs web diarahkan ke alamat IP milik ISP luar negeri termasuk TransTelekom Russia dan China Telecom, alih-alih ke server Google. Ini mengakibatkan paket dikirim ke berbagai tujuan yang tidak diinginkan sebelum diakhiri, atau disembunyikan.

Laporan awal dari insiden tersebut menunjukkan bahwa ini mungkin peretasan BGP yang berbahaya, mengingat bahwa negara-negara yang terlibat memiliki sejarah penyensoran internet. Namun, kemudian ditemukan bahwa arahan ulang yang salah sebenarnya adalah hasil dari kesalahan manusia; dalam hal ini, lihat kesalahan konfigurasi antara Google dan MainOne, ISP Nigeria, yang telah didirikan Google untuk lebih mendukung kehadiran Nigeria yang terus berkembang.

Karena pembangunan jaringan berlanjut dengan cepat, kecelakaan BGP seperti itu mungkin menjadi lebih umum. Meskipun Anda mungkin tidak dapat berbuat banyak tentang suatu insiden ketika itu mempengaruhi penyedia eksternal, Anda dapat lebih dekat melacak kebocoran BGP dalam rantai pengiriman aplikasi Anda sendiri, untuk memungkinkan identifikasi lebih cepat, mengesampingkan penyebab tertentu dan melanjutkan ke perbaikan.

Tes otomatis lebih awal dan sering: Tidak pernah merupakan ide bagus untuk menjalankan kode baru secara langsung pada sistem produksi. Tetapi terburu-buru untuk melepaskan kode, ini sering terjadi, yang mengarah ke masalah. Google melakukan puluhan ribu penyebaran kode baru setiap hari ke ribuan layanan, tujuh di antaranya memiliki lebih dari satu miliar pengguna di seluruh dunia.

Tidak mengherankan – SREs, yang memiliki keahlian di bidang TI dan pengkodean dan siapa yang memikul tanggung jawab untuk menjaga ketersediaan sistem dalam menghadapi perubahan perangkat lunak yang hampir konstan – baru-baru ini melaporkan bahwa manajemen insiden adalah bagian besar dari pekerjaan mereka. Pada saat survei, hampir setengah dari responden mencatat bahwa mereka telah mengerjakan insiden layanan selama seminggu terakhir.

Dengan laju peluncuran perangkat lunak yang diperkirakan tidak akan melambat dalam waktu dekat, organisasi harus menjadi lebih mahir dalam menyeimbangkan kecepatan dan kualitas. Peningkatan otomatisasi pengujian perangkat lunak fungsional, yang dilakukan pada fase paling awal dari siklus pengembangan, sangat penting untuk ini, seperti halnya pengujian regresi komprehensif dan kemampuan rollback.

Ukur pihak ketiga dan minta mereka bertanggung jawab: Pihak ketiga, mulai dari komponen perangkat lunak yang diintegrasikan ke situs Anda ke infrastruktur eksternal seperti cloud dan CDN, dapat memiliki dampak besar pada ketersediaan situs Anda. Organisasi apa pun yang mengandalkan pihak ketiga eksternal harus selalu mengawasi mereka untuk memastikan ketersediaannya sendiri.

Ketika datang ke cloud secara khusus, bisnis harus menghindari meletakkan semua telur mereka (data dan aplikasi) dalam satu keranjang (penyedia layanan cloud tunggal). Menerapkan strategi multicloud sebagai bentuk cadangan dan perlindungan dapat melibatkan cukup banyak waktu dan upaya, termasuk menguji strategi failover di muka dan memastikan interaksi cloud-to-cloud (mendukung replikasi) cepat dan dapat diandalkan. Ini sebenarnya adalah satu kasus penggunaan yang baik di mana pemantauan dari titik pandang tunggal dari berbagai awan tepat; namun, seperti yang dirujuk di atas, pemantauan hanya awan tidak boleh digunakan untuk mengukur pengalaman pengguna akhir nyata secara komprehensif.

Kesimpulan: Akhir-akhir ini pemadaman telah memperkuat fakta bahwa internet sangat mirip rumah kartu, dan hampir tidak mungkin untuk menghindari pemadaman besar dan dampaknya. Ketika web tumbuh lebih saling terhubung, kemungkinan downtime yang tidak direncanakan berdampak pada bisnis Anda hanya akan tumbuh. Untungnya, ada langkah-langkah yang dapat diambil bisnis untuk mengantisipasi dan merespons peristiwa ini dengan lebih baik. Mungkin sulit didengar, tetapi merencanakan kegagalan adalah suatu keharusan. Jika itu bisa terjadi pada suka Google, Facebook dan Apple, itu bisa – dan pasti akan – terjadi pada Anda.

Kredit gambar: pathdoc / Shutterstock

Mehdi Daoudi adalah pendiri dan CEO Catchpoint, perusahaan intelijen pengalaman digital terkemuka. Timnya memiliki keahlian dalam merancang, membangun, mengoperasikan, menskalakan, dan memantau layanan Internet yang sangat transaksional yang digunakan oleh ribuan perusahaan yang berdampak pada pengalaman jutaan pengguna. Sebelum Catchpoint, Mehdi menghabiskan 10+ tahun di DoubleClick dan Google, di mana ia bertanggung jawab atas Kualitas Layanan, membeli, membangun, menyebarkan, dan menggunakan solusi pemantauan untuk mengawasi infrastruktur yang mengirimkan milyaran transaksi setiap hari.