Postmortem atas Gangguan Control Plane dan Sistem Analitik Cloudflare
(blog.cloudflare.com)- Mulai 2 November 2023 pukul 11:43 UTC, control plane dan layanan analitik Cloudflare mengalami gangguan, memengaruhi perubahan melalui dashboard/API serta fungsi log dan analitik
- Titik awal insiden adalah gangguan listrik PDX-04 di Oregon yang dioperasikan Flexential; fasilitas ini menampung klaster analitik terbesar dan lebih dari sepertiga perangkat klaster high-availability
- Saat pemulihan utility feed, generator, UPS, dan circuit breaker terganggu secara berantai, dependensi Kafka dan ClickHouse yang khusus berada di PDX-04 merusak desain high-availability
- Pada 2 November pukul 13:40 UTC diputuskan failover ke situs disaster recovery di Eropa, dan pada 17:57 UTC dampak ke pelanggan sebagian besar berkurang, tetapi pemrosesan log, sebagian API bespoke, konfigurasi manual Magic WAN, dan unggahan Stream terdampak lebih lama
- Cloudflare menjalankan Code Orange untuk mendorong persyaratan high-availability bagi produk GA, rencana disaster recovery yang tervalidasi, chaos testing termasuk penghapusan penuh core data center, serta rencana pencegahan kehilangan log
Cakupan gangguan dan dampak pelanggan
- Mulai 2 November 2023 pukul 11:43 UTC, control plane dan layanan analitik Cloudflare mengalami gangguan
- Control plane berarti antarmuka yang menghadap pelanggan, termasuk situs web dan API
- Layanan analitik mencakup logging dan pelaporan analitik
- Seluruh insiden berlangsung dari 2 November pukul 11:44 UTC hingga 4 November pukul 04:25 UTC
- Pada 2 November pukul 17:57 UTC, sebagian besar control plane dipulihkan di fasilitas disaster recovery
- Setelah fasilitas disaster recovery online, banyak pelanggan mungkin tidak mengalami masalah pada sebagian besar produk
- Beberapa layanan membutuhkan waktu lebih lama untuk pulih, dan pelanggan yang menggunakan layanan tersebut dapat melihat masalah sampai semuanya benar-benar terselesaikan
- Layanan raw log tidak tersedia bagi sebagian besar pelanggan selama sebagian besar durasi insiden
- Layanan jaringan dan keamanan Cloudflare berfungsi sesuai harapan sepanjang insiden
- Ada periode ketika pelanggan tidak dapat mengubah layanan tersebut
- Trafik yang melewati jaringan Cloudflare tidak terdampak
Desain awal: high-availability berbasis 3 data center di Oregon
- Control plane dan sistem analitik Cloudflare terutama berjalan di server pada 3 data center di sekitar Hillsboro, Oregon
- Ketiga data center saling independen, masing-masing memiliki beberapa utility power feed serta beberapa koneksi jaringan redundan dan independen
- Fasilitas-fasilitas tersebut dipilih dengan lokasi yang cukup berjauhan agar bencana alam sulit memengaruhi semuanya sekaligus, tetapi cukup dekat untuk menjalankan klaster data redundan active-active
- Ketiga fasilitas terus menyinkronkan data
- Secara desain, meski satu fasilitas offline, fasilitas lainnya seharusnya tetap dapat beroperasi
- Desain high-availability ini mulai diimplementasikan 4 tahun lalu
- Sebagian besar sistem control plane inti dipindahkan ke klaster high-availability
- Layanan untuk beberapa produk baru belum termasuk dalam klaster high-availability
- Sistem logging sengaja tidak dimasukkan ke klaster high-availability
- Log diperlakukan sebagai masalah terdistribusi: log diantrekan di network edge lalu dikirim ke Oregon core atau fasilitas logging regional
- Jika fasilitas logging offline, log analitik akan menunggu di edge, dan keterlambatan analitik dinilai masih dapat diterima
Awal gangguan listrik PDX-04
- Fasilitas terbesar dari 3 fasilitas Oregon tersebut adalah PDX-04 yang dioperasikan Flexential
- Cloudflare menempatkan klaster analitik terbesarnya di sana
- Lebih dari sepertiga perangkat klaster high-availability juga berada di fasilitas ini
- Ini juga menjadi lokasi default untuk layanan yang belum di-onboard ke klaster high-availability
- Cloudflare adalah pelanggan yang relatif besar, menggunakan sekitar 10% dari total kapasitas fasilitas ini
- Pada 2 November pukul 08:50 UTC, terjadi event pemeliharaan tak terencana pada salah satu power feed independen Portland General Electric (PGE) yang memasok listrik ke PDX-04
- Event ini memutus salah satu feed yang masuk ke PDX-04
- Flexential menyalakan generator untuk mengompensasi feed yang terputus
- Flexential tidak memberi tahu Cloudflare bahwa mereka telah failover ke daya generator
- Alat observasi Cloudflare tidak mendeteksi perubahan sumber listrik
- Jika ada pemberitahuan sebelumnya, Cloudflare dapat memantau fasilitas dengan ketat dan memindahkan layanan control plane yang bergantung pada fasilitas tersebut ke tempat lain
- Tidak lazim juga bahwa Flexential mengoperasikan utility feed yang tersisa dan generator secara bersamaan
- Flexential mengoperasikan 10 generator, termasuk unit redundan, dan mampu menanggung seluruh beban fasilitas
- Fasilitas juga bisa dioperasikan hanya dengan utility feed yang tersisa
- Cloudflare tidak menerima jawaban yang jelas mengapa Flexential menjalankan utility power dan generator power bersama-sama
Penyebab yang belum terkonfirmasi dan generator berhenti
- Penyebab utama rangkaian kejadian berikutnya dan beberapa keputusan belum dikonfirmasi secara jelas oleh Flexential
- Salah satu kemungkinan yang tersisa adalah Flexential mungkin berpartisipasi dalam program DSG PGE
- DSG adalah program yang memungkinkan perusahaan listrik regional memanfaatkan generator data center untuk memasok daya tambahan ke jaringan listrik
- Sebagai imbalannya, perusahaan listrik mendukung pemeliharaan generator dan pasokan bahan bakar
- Cloudflare tidak menemukan catatan bahwa Flexential pernah menginformasikan program DSG
- Mereka juga tidak menerima jawaban apakah DSG aktif saat insiden terjadi
- Sekitar pukul 11:40 UTC, terjadi ground fault pada transformer PGE di PDX-04
- Cloudflare menduga transformer ini adalah perangkat yang menurunkan tegangan feed kedua yang masuk ke data center, tetapi belum mendapatkan konfirmasi
- Juga belum dikonfirmasi apakah ground fault ini berasal dari pemeliharaan tak terencana PGE yang memengaruhi feed pertama
- Ground fault pada jalur tegangan tinggi 12.470V dirancang agar sistem listrik cepat terputus untuk mencegah kerusakan
- Tindakan proteksi ini juga mematikan semua generator PDX-04
- Akibatnya, utility line dan 10 generator semuanya offline
- PDX-04 memiliki bank baterai UPS yang diketahui dapat mempertahankan fasilitas selama sekitar 10 menit
- Waktu ini dimaksudkan untuk menjembatani gangguan listrik dan restart otomatis generator
- Berdasarkan observasi kegagalan perangkat Cloudflare, baterai mulai gagal dalam 4 menit
- Flexential membutuhkan jauh lebih dari 10 menit untuk memulihkan generator
Keterlambatan pemulihan listrik dan pemberitahuan pertama
- Meski Cloudflare tidak menerima konfirmasi resmi, mereka mendengar dari staf Flexential tentang tiga faktor yang menghambat pemulihan generator
- Karena cara circuit trip akibat ground fault, generator harus diakses secara fisik dan di-restart secara manual
- Sistem kontrol akses Flexential tidak mendapat daya cadangan dari baterai sehingga offline
- Staf shift malam tidak memiliki operator atau ahli listrik berpengalaman; yang ada hanya petugas keamanan dan teknisi tanpa pendamping yang baru bekerja satu minggu
- Antara 11:44–12:01 UTC, ketika generator belum sepenuhnya di-restart, baterai UPS habis dan semua pelanggan data center kehilangan listrik
- Selama proses ini, Flexential tidak memberi tahu Cloudflare tentang masalah fasilitas
- Cloudflare pertama kali menyadari masalah data center pada 11:44 UTC ketika 2 router yang menghubungkan fasilitas ke dunia luar menjadi offline
- Karena tidak dapat mengakses router secara langsung atau melalui out-of-band management, Cloudflare menghubungi Flexential dan mengirim tim lokal ke fasilitas
- Pesan gangguan pertama yang dikirim Flexential kepada Cloudflare adalah pada 12:28 UTC
- Pesan tersebut menyatakan bahwa masalah listrik PDX-04 dimulai sekitar 12:00 UTC, engineer sedang melakukan pemulihan, dan pembaruan progres akan diberikan setiap 30 menit
Masalah dependensi yang terungkap dalam desain high-availability
- PDX-04 memiliki desain bersertifikasi Tier III sebelum konstruksi dan diharapkan menyediakan SLA high-availability, tetapi Cloudflare juga merencanakan kemungkinan fasilitas ini offline
- Dampak yang diperkirakan adalah terhentinya analitik, antrean dan keterlambatan log di edge, serta penghentian sementara layanan prioritas rendah yang belum terintegrasi ke klaster high-availability
- Operasi di mana dua data center lainnya mengambil alih klaster high-availability dan menjaga layanan inti tetap online secara umum berjalan sesuai rencana
- Masalahnya adalah beberapa layanan yang seharusnya berada di klaster high-availability bergantung pada layanan yang hanya berjalan di PDX-04
- Kafka dan ClickHouse yang menangani pemrosesan log dan analitik hanya disediakan di PDX-04
- Beberapa layanan yang berjalan di klaster high-availability bergantung pada keduanya
- Dependensi ini seharusnya lebih longgar, seharusnya gagal dengan lebih anggun, dan seharusnya ditemukan sebelumnya
- Dalam pengujian klaster high-availability, Cloudflare pernah membuat masing-masing dari dua fasilitas lain, dan keduanya sekaligus, sepenuhnya offline
- Pengujian yang membuat bagian high-availability PDX-04 offline juga dilakukan
- Namun, pengujian yang membuat seluruh fasilitas PDX-04 sepenuhnya offline tidak dilakukan
- Standar yang mewajibkan produk baru dan database terkaitnya terintegrasi ke klaster high-availability juga terlalu longgar
- Tim produk memiliki jalur yang berbeda-beda untuk menuju tahap alpha
- Seiring waktu, backend dipindahkan mengikuti best practice, tetapi hal ini tidak dijadikan persyaratan resmi sebelum deklarasi GA
- Akibatnya, perlindungan redundansi bekerja tidak konsisten antarproduk
Peralihan ke situs disaster recovery
- Pada 12:48 UTC, Flexential me-restart generator dan sebagian fasilitas kembali mendapat listrik
- Pemulihan listrik data center biasanya dilakukan bertahap, satu sirkuit demi satu sirkuit
- Saat hendak menyalakan kembali sirkuit Cloudflare, diketahui bahwa circuit breaker mengalami kerusakan
- Tidak diketahui apakah breaker ini rusak karena ground fault atau surge, atau sudah bermasalah sebelumnya
- Flexential mulai mengganti breaker yang rusak
- Jumlah breaker yang rusak lebih banyak daripada stok yang tersedia di fasilitas, sehingga breaker baru harus didatangkan
- Karena lebih banyak layanan daripada perkiraan berada offline dan Flexential tidak dapat memberikan estimasi waktu pemulihan, Cloudflare memutuskan failover ke situs disaster recovery di Eropa pada 13:40 UTC
- Hanya sebagian kecil dari keseluruhan control plane yang perlu di-failover
- Sebagian besar layanan tetap berjalan di sistem high-availability pada dua core data center lainnya
- Pada 13:43 UTC, layanan pertama dijalankan di situs disaster recovery
- Situs ini dirancang untuk menyediakan layanan control plane inti saat terjadi bencana
- Beberapa layanan pemrosesan log tidak didukung
- Setelah layanan berjalan, panggilan API yang sebelumnya gagal membanjir dan menyebabkan masalah thundering herd
- Cloudflare menerapkan rate limit untuk mengendalikan volume permintaan
- Selama periode ini, pelanggan sebagian besar produk dapat melihat error sesekali saat melakukan perubahan melalui dashboard atau API
- Hingga 17:57 UTC, layanan yang dipindahkan ke situs disaster recovery sudah stabil dan dampak langsung bagi sebagian besar pelanggan berkurang
- Beberapa sistem seperti Magic WAN masih memerlukan konfigurasi manual
- Pemrosesan log dan beberapa layanan terkait API bespoke tidak tersedia sampai PDX-04 pulih
Pemulihan tertunda pada beberapa produk dan restart PDX-04
- Beberapa produk tidak berjalan dengan baik di situs disaster recovery
- Terutama produk baru yang prosedur disaster recovery-nya belum sepenuhnya diimplementasikan dan diuji
- Termasuk layanan Stream untuk unggahan video baru serta beberapa layanan lain
- Tim Cloudflare menempuh dua jalur secara bersamaan
- Mengimplementasikan kembali layanan tersebut di situs disaster recovery
- Memindahkannya ke klaster high-availability
- Flexential mengganti circuit breaker yang rusak, memulihkan kedua utility feed, dan mengonfirmasi listrik stabil pada 22:48 UTC
- Karena tim telah melakukan respons darurat sepanjang hari, Cloudflare memutuskan sebagian besar personel beristirahat dan mulai pekerjaan mengembalikan PDX-04 ke operasi pada pagi berikutnya
- Keputusan ini menunda pemulihan keseluruhan, tetapi diambil untuk mengurangi kemungkinan terjadinya kesalahan tambahan
- Mulai pagi 3 November, pemulihan layanan PDX-04 dimulai
- Perangkat jaringan di-boot secara fisik
- Ribuan server dinyalakan dan layanan dipulihkan
- Karena kemungkinan terjadi beberapa siklus daya selama insiden, status layanan di dalam data center tidak diketahui
- Prosedur pemulihan yang aman adalah mengikuti bootstrap penuh seluruh fasilitas
- Server manajemen konfigurasi dibuat online secara manual, dan pembangunan ulangnya memakan waktu 3 jam
- Setelah itu, server lainnya dibangun ulang dengan metode bootstrap
- Pembangunan ulang tiap server memakan waktu 10 menit hingga 2 jam
- Walau dijalankan paralel di banyak server, beberapa harus dipulihkan berurutan karena dependensi antarlayanan
- Semua layanan sepenuhnya pulih pada 4 November 2023 pukul 04:25 UTC
- Bagi sebagian besar pelanggan, data analitik juga disimpan di core data center Eropa, sehingga diperkirakan tidak ada kehilangan data pada sebagian besar analitik di dashboard dan API
- Beberapa dataset yang tidak direplikasi ke UE memiliki gap permanen
- Pelanggan yang menggunakan Logpush tidak mendapatkan pemrosesan log selama sebagian besar durasi insiden, dan log yang tidak diterima tidak dapat dipulihkan
Code Orange dan rencana perbaikan
- Cloudflare memiliki banyak pertanyaan yang harus dijawab oleh Flexential, tetapi menilai bahwa kegagalan seluruh data center juga harus diantisipasi
- Mirip dengan Code Yellow dan Code Red milik Google, Cloudflare memperkenalkan Code Orange, proses internal untuk memfokuskan resource engineering pada penyelesaian masalah saat terjadi insiden atau krisis besar
- Fungsi engineering non-inti dialihkan ke pekerjaan untuk memastikan keandalan tinggi control plane
- Perubahan yang direncanakan adalah sebagai berikut
- Menghapus dependensi pada core data center dari konfigurasi control plane semua layanan, dan jika memungkinkan memindahkannya agar jaringan terdistribusi Cloudflare berjalan lebih dulu
- Memastikan control plane yang berjalan di jaringan tetap berfungsi meski semua core data center offline
- Mewajibkan produk dan fitur GA yang bergantung pada core data center untuk bergantung pada klaster high-availability tanpa dependensi software pada fasilitas tertentu
- Mewajibkan produk dan fitur GA memiliki rencana disaster recovery yang teruji dan dapat diandalkan
- Menguji blast radius kegagalan sistem dan meminimalkan jumlah layanan yang terdampak gangguan
- Mengimplementasikan chaos testing yang lebih ketat untuk semua fungsi data center, termasuk penghapusan penuh tiap fasilitas core data center
- Mengaudit semua core data center secara menyeluruh dan menyusun rencana audit ulang untuk memastikan kepatuhan terhadap standar
- Menyiapkan rencana disaster recovery logging dan analitik agar log tidak hilang bahkan saat semua core facility gagal
- Cloudflare menyimpulkan bahwa meski memiliki sistem dan prosedur yang diperlukan, mereka kurang ketat dalam memaksa kepatuhan terhadapnya dan menguji dependensi yang tidak diketahui
1 komentar
Pendapat di Hacker News
Agak aneh bahwa sebagian besar tulisan dipakai untuk menyebut nama vendor tertentu, mengalihkan tanggung jawab, dan berspekulasi tentang akar penyebabnya
Mengungkap bahwa mereka adalah pelanggan besar di fasilitas tersebut, lalu memasukkan diagram kelistrikan yang ditandai Confidential oleh vendor ke dalam postmortem juga terlihat cukup tidak pantas
Menjelaskan pemicu insiden dan konteksnya bisa dimengerti, tetapi fokus postmortem seharusnya pada gangguan Cloudflare, bukan pada vendor
Flexential juga perlu membuat postmortem sendiri, tetapi Cloudflare tidak perlu berspekulasi dan memublikasikannya atas nama mereka
Bisa juga tujuannya agar Cloudflare lebih dulu menjelaskan sebelum pihak lain membentuk narasi
Dalam situasi yang melibatkan tiga pihak dan beberapa sistem yang saling terhubung, wajar jika Cloudflare ingin tahu sampai tuntas apa yang terjadi agar ke depannya mode kegagalan majemuk seperti ini bisa dimasukkan ke desain mereka
Secara pribadi, saya berterima kasih atas informasi yang dibagikan Cloudflare
99% tanggung jawab ada pada Cloudflare yang gagal menjalankan tugas intinya
Mengulik pihak ketiga sedalam ini justru menunjukkan betapa memalukannya kejadian ini bagi Cloudflare
Sepertinya pemeriksaan breaker pun tidak dilakukan dengan benar, dan meski fasilitasnya relatif baru, mereka bahkan tidak punya setengah dari 10 jam yang diperlukan untuk mengisi baterai generator
Selama pemeliharaan ini, seharusnya mereka sepenuhnya beralih ke generator, dan kemungkinan mereka tidak bisa melakukannya karena membantu PGE
Menurut saya CEO Cloudflare benar. Untuk layanan datacenter, kita membayar dengan ekspektasi redundansi penuh, dan katanya ada 18MW di lokasi ini, tetapi dari yang terlihat bahkan tidak jelas apakah feed-nya hanya 2
Jika satu feed mati, konfigurasi 2N seharusnya masuk, dan kalau ada generator, semestinya tidak ada masalah
Kalau begitu, memang tepat jika ada penjelasan tentang event awal yang sudah diketahui sejauh ini
Sepertinya besar kemungkinan akan ada analisis lanjutan
https://twitter.com/eastdakota/status/1720688383607861442?t=...
Dari kutipan tersebut, akar penyebab gangguan adalah ketergantungan pada satu datacenter
Disebutkan bahwa sebagian besar sistem control plane inti sudah dipindahkan ke cluster high availability, tetapi sebagian produk baru belum; beberapa layanan yang seharusnya berada di cluster high availability masih bergantung pada layanan yang hanya berjalan di PDX-04; dan sebagian produk tidak naik dengan benar di situs disaster recovery
Untuk perusahaan seperti Cloudflare yang menopang bagian penting dari internet, ini cukup memalukan
Katanya, karena Cloudflare mengizinkan banyak tim berinovasi dengan cepat, produk-produk mengambil jalur berbeda masing-masing hingga alpha awal, dan meski seiring waktu akan dipindahkan ke praktik terbaik, itu tidak diwajibkan sebagai syarat sebelum rilis umum
Ini murni kegagalan manajemen. Bukankah itu berarti pelanggan dijual software yang menurut standar internal Cloudflare masih berkualitas alpha?
https://news.ycombinator.com/item?id=38113503
Terlihat kurang punya kesadaran diri
Ini level amatir, dan terutama serius bahwa layanan baru diluncurkan tanpa high availability
Sebagai pihak yang sedikit terdampak oleh gangguan ini, menurut saya postmortem ini kurang memadai
75% isinya membahas gangguan listrik di PDX-04 dan tanggung jawab Flexential; dari teksnya, apa yang terjadi di sana memang tampaknya mendekati bencana, jadi itu bisa dimengerti
Namun disebutkan bahwa daya sudah pulih sepenuhnya pada 2 November UTC, lalu setelah itu Cloudflare masih membutuhkan sekitar 30 jam lagi untuk pulih sepenuhnya
Pemulihannya lebih lama daripada gangguannya, tetapi tulisan itu hanya mengatakan terlalu banyak layanan saling bergantung. Saya ingin tahu lebih detail mengapa pemulihan operasi secara keseluruhan memakan waktu selama itu
Apakah tidak ada pelajaran dari proses pemulihan itu sendiri? Atau memang waktu itu hanya habis untuk menyinkronkan ulang data dari edge ke “otak”?
Bagian lain yang hilang adalah terutama kurangnya komunikasi dengan pelanggan enterprise. Dukungan Cloudflare pada dasarnya diam selain status page, dan meski secara realistis mungkin tidak banyak yang bisa dilakukan, tetap perlu ada upaya komunikasi
Apalagi setelah postmortem ini menyalahkan kurangnya komunikasi dari Flexential; saya menyukai produk Cloudflare, tetapi menurut saya mereka perlu menarik lebih banyak kesimpulan dari insiden ini
Namun menyebutnya postmortem agak kurang tepat. Jika ini postmortem lengkap, harus ada detail pada tingkat yang disebutkan di atas
Jika logging turun, layanan apa persisnya yang gagal? Apakah memang tidak sengaja dibuat begitu? Mengapa tidak ada yang menyadarinya?
Bagus bahwa postmortem Cloudflare sangat menyeluruh
Penjelasan yang jujur dan transparan terasa menyegarkan dibandingkan strategi komunikasi samar dari hampir semua perusahaan lain
Kami juga terdampak, tetapi tulisan seperti ini justru membuat saya tidak ingin pergi. Semua orang bisa membuat kesalahan dan mengalami hari buruk; yang membedakan adalah bagaimana mereka merespons setelahnya
Gangguan listrik cukup dijelaskan dalam satu paragraf, lalu seharusnya beralih ke sisi Cloudflare. Gangguan pusat data bisa saja terjadi
Pelajaran sebenarnya ada pada respons Cloudflare yang gagal mempertimbangkan dan memulihkan kondisi itu dengan benar
Kami sangat bergantung pada CloudFlare Images, dan dalam 30 hari terakhir layanannya down lebih dari 67 jam
22 jam pada 9 Oktober, 42 jam pada 2–4 November, ditambah beberapa gangguan sekitar 1 jam di antaranya; ketersediaan bulan lalu adalah 90,6%
Transparansi adalah pembeda yang bagus di antara penyedia yang bersaing di kisaran ketersediaan 99,9%, tetapi kalau bahkan satu angka 9 saja nyaris tidak terlampaui, itu tidak banyak berarti
Itu tidak banyak membantu memperbaiki tindakan, dan bisa membuat insentif menjadi lebih buruk
Saya menghargai komitmen mereka untuk memperbaiki kesalahan proses di sini. Namun ada ketegangan antara bergerak cepat dan memastikan semuanya benar
Biasanya hal seperti ini diperlakukan seperti cuaca: baru membeli jas hujan setelah kehujanan
Saya penasaran bagaimana menjadikan keandalan sebagai bagian dari budaya tanpa membuat pengembangan terikat oleh proses
Sistem juga bisa dimodelkan dengan perangkat lunak, lalu model itu divalidasi lewat analisis trafik. Jika eksperimen virtual bisa menurunkan biaya eksperimen keandalan, mungkin lebih banyak masalah bisa ditangkap sebelum rilis
Aneh bahwa setelah membaca tulisan ini, kepercayaan saya pada Cloudflare justru menurun
Mereka sangat keras menekan Flexential karena bertindak tidak profesional, dan itu mungkin saja benar
Namun fakta bahwa seluruh sistem yang diandalkan orang-orang tumbang adalah kegagalan redundansi besar di pihak Cloudflare. Satu pusat data seperti ini seharusnya bisa hilang tanpa menghentikan layanan
Yang terutama mengkhawatirkan adalah desain yang dimaksud memang dimulai dengan “control plane dan sistem analitik Cloudflare terutama berjalan di server pada 3 pusat data di sekitar Hillsboro, Oregon”
Untuk control plane yang dipakai orang di seluruh dunia, diperlukan distribusi geografis yang jauh lebih luas. Lebih mengejutkan lagi bahwa ini bukan implementasi yang cacat, melainkan sudah pada tahap desain yang disengaja
Kalau meluncurkan produk baru ke konsumen, bukankah desain redundansi seharusnya menjadi prioritas utama? Mengejutkan bahwa itu ternyata bersifat opsional
Saya juga memakai Cloudflare untuk sebagian sistem, karena percaya bahwa kalau insiden seperti ini terjadi, akan ada failover yang sangat baik. Sekarang saya jadi mempertimbangkan ulang apakah Cloudflare Workers benar-benar aman dari keputusan desain seperti ini
Saat situs disaster recovery dinyalakan, panggilan API yang gagal membanjiri layanan hingga kewalahan; menurut saya itu juga pada akhirnya karena desain inti Cloudflare tidak memiliki redundansi yang memadai
Saya kecewa dengan tulisan ini yang tampak mencoba mengalihkan tanggung jawab ke Flexential. Dari sudut pandang pelanggan, saya berharap Cloudflare bisa menanganinya dengan elegan meski Flexential lenyap karena gempa besok
Apakah menempatkan seluruh klaster sepenting ini di zona risiko gempa dan tsunami yang sudah diketahui merupakan ide bagus?
Disaster recovery di Eropa juga sepertinya tidak berjalan dengan baik
“Kami belum pernah melakukan pengujian yang sepenuhnya membuat seluruh fasilitas PDX-04 offline” adalah pelajaran yang menyakitkan
Namun jika tidak mematikan listrik pusat data secara fisik, atau setidaknya memutus jaringannya dari dunia luar, berarti belum benar-benar menguji bencana nyata
Operator fasilitas bisa saja disalahkan, tetapi pada akhirnya mereka harus bisa pulih meski satu pusat data sepenuhnya offline dan tidak pernah kembali
Bencana alam bisa saja menghapus fasilitas itu dari muka bumi
Saya suka bagian “Karena tim sudah dikerahkan penuh dan melakukan respons darurat sepanjang hari, kami memutuskan bahwa sebagian besar orang sebaiknya beristirahat dan memulai pekerjaan kembali ke PDX-04 pada pagi hari. Keputusan ini menunda pemulihan penuh, tetapi kami percaya itu mengurangi kemungkinan menumpuknya kesalahan tambahan”
Dalam laporan seperti ini, kelelahan manusia sering diremehkan. Jika mencoba memperbaiki gangguan besar dalam kondisi terlalu lelah, yang bertambah hanya kesalahan yang sebenarnya bisa dihindari
Saya tidak tahu bagaimana ini berjalan di organisasi sebesar Cloudflare, tetapi kami juga punya rencana agar staf bekerja dan tidur bergiliran saat ada gangguan besar
Masalahnya adalah perlu ada cara untuk menyerahkan status gangguan saat ini kepada personel baru yang bangun atau baru masuk
Seperti kata Mike Tyson, semua orang punya rencana sampai terkena pukulan di wajah
Struktur tulisannya cukup mengejutkan. 75% blog diisi cerita tentang pihak ketiga, sementara upaya pemulihan Cloudflare sendiri dibahas dalam jauh lebih sedikit paragraf
Menyajikan langkah ke depan adalah hal positif, tetapi saya bertanya-tanya mengapa mereka sekarang tidak cukup mengakui kegagalan dan situasinya, lalu menerbitkan postmortem lengkap tanpa spekulasi setelah keadaan mereda
Investor bisa saja hanya membaca tulisan ini atau ringkasannya, lalu menganggapnya sekadar isu pemasok, bukan masalah mendalam yang membutuhkan berbulan-bulan pengerjaan ulang dan biaya jutaan dolar
Dokumennya kurang bagus
Mereka punya konfigurasi ketersediaan tinggi dengan 3 pusat data, tetapi gagal total
Mengapa bagian awal dokumen dipenuhi dengan menyalahkan operator pusat data? Pengelolaan fasilitas pusat data berada di luar kendali Cloudflare
Cloudflare berjudi bahwa tidak apa-apa jika tidak menguji konfigurasi ketersediaan tinggi yang berada dalam kendalinya dengan benar
Masalah operasi pusat data memang harus dibahas dengan operatornya, tetapi itu urusan di antara kedua pihak, bukan sesuatu yang perlu masuk ke postmortem ini
Bagian pentingnya benar-benar dikubur sangat dalam. Setelah menggulir cukup lama, barulah muncul kalimat seperti ini
“Sebagian layanan yang seharusnya berada di klaster high availability ternyata bergantung pada layanan yang hanya berjalan di PDX-04”
Inilah inti masalahnya
Jika membuat situs “disaster”, rasanya harus mencari cara apa pun untuk mengujinya
Saat layanan menyala, terjadi masalah thunder herd ketika panggilan API yang sebelumnya gagal membanjir masuk, dan katanya mereka menerapkan rate limiting untuk mengendalikan volume request
Namun bagian ini tampaknya tidak masuk dalam butir-butir di akhir tulisan
Yang kini membuat penasaran adalah bagaimana merancang cold failover ketika sistem cukup kompleks hingga bisa menyebabkan kegagalan metastabil[1], dan tidak ada kelonggaran untuk mengujinya dengan traffic nyata
Saya bisa membayangkan teknik yang dipakai dalam implementasinya, tetapi masalahnya adalah desain dan pengujian untuk memastikan teknik itu benar-benar bekerja dalam situasi nyata
Satu hal lain yang tampaknya benar-benar terlewat adalah bahwa gangguan dimulai pada 2 November pukul 11:43 UTC, tetapi keputusan untuk beralih ke situs disaster recovery di Eropa baru dibuat pada 13:40 UTC
Mengapa keputusan itu memakan waktu begitu lama? Saya paham ini bukan keputusan yang bisa diambil ringan, tetapi meski selama sebagian besar waktu mereka berharap listrik segera pulih, 2 jam terlihat seperti terlalu banyak ragu-ragu
Apa pun komitmennya, harus ada titik ambang yang sudah ditentukan sebelumnya untuk menekan sakelar. Apakah ambang itu memang ditetapkan sejauh itu?
[1] http://charap.co/metastable-failures-in-distributed-systems/
Yang sering memicu kegagalan justru sistem redundan itu sendiri