Pelajaran dari 20 Tahun Rekayasa Keandalan Situs

• Google SRE merangkum pengalaman meningkatkan keandalan, dari operasi berbasis pusat data kecil dan skrip Python hingga lingkungan yang tumbuh lebih dari 1.000 kali dalam skala komputasi dan lebih dari 10.000 kali dalam skala jaringan
• Dalam respons insiden, keamanan langkah mitigasi lebih penting daripada tindakan cepat, karena prosedur pemulihan yang keliru dapat memperbesar kegagalan berantai alih-alih mengurangi gangguan
• Kasus YouTube dan Google Calendar menunjukkan perlunya deploy canary yang membatasi perubahan global, Big Red Button yang bisa segera membatalkan perubahan, dan pengujian integrasi yang memverifikasi jalur nyata
• Seperti insiden token OAuth pada 2017, ketika dependensi inti runtuh, bukan hanya pengguna tetapi juga sistem respons internal ikut terguncang, sehingga dibutuhkan saluran komunikasi cadangan dan graceful degradation
• Rollout yang sering, mitigasi otomatis, latihan pemulihan bencana, dan keberagaman perangkat keras adalah prinsip praktik untuk menurunkan MTTR dan menghindari single point of failure dalam sistem terdistribusi yang kompleks

---

Perubahan skala yang dialami Google SRE selama 20 tahun

• Dua puluh tahun lalu Google mengoperasikan dua pusat data kecil, masing-masing berisi ribuan server, dan keduanya terhubung dalam bentuk ring dengan dua tautan jaringan 2.4G
• Pada saat itu operasi sangat bergantung pada skrip Python seperti Assigner, Autoreplacer, Babysitter, serta file konfigurasi yang berisi nama server individual
• Basis data mesin kecil bernama MDB digunakan untuk mengatur dan memelihara informasi tiap server secara berkelanjutan
• Kini daya komputasi telah tumbuh lebih dari 1.000 kali, jaringan lebih dari 10.000 kali, tetapi upaya operasional per server menurun dan keandalan stack layanan meningkat
• Alat operasional berevolusi dari kumpulan skrip menjadi ekosistem layanan, lalu menjadi platform terintegrasi yang menyediakan keandalan dasar

Prinsip respons dari gangguan YouTube

• Pada 2016, YouTube mengalami gangguan global selama 15 menit akibat bug pada sistem caching memori terdistribusi, yang menghentikan kemampuan penyajian video
• Langkah mitigasi gangguan harus sepadan dengan tingkat keparahan insiden
  • Selama gangguan YouTube, prosedur load-shedding yang berisiko tidak memperbaiki masalah dan justru memicu kegagalan berantai
  • Langkah mitigasi yang berisiko mungkin menyelesaikan insiden dalam skenario terbaik, tetapi dalam skenario terburuk dapat salah bekerja dan memperpanjang durasi gangguan
  • Bahkan jika situasinya terasa mendesak hingga perlu melewati prosedur standar, pilihan tetap harus diambil setelah mengamati dan menilai tingkat keparahan terlebih dahulu
• Mekanisme pemulihan harus diuji secara memadai sebelum keadaan darurat nyata terjadi
  • Menjalankan prosedur mitigasi berisiko untuk pertama kalinya saat insiden berlangsung ibarat pertama kali mencoba tangga ketika sedang evakuasi kebakaran gedung tinggi
  • Perlu dipastikan lebih dulu bahwa prosedur pemulihan benar-benar melakukan pekerjaan yang dibutuhkan dan bahwa penanggung jawab tahu cara menjalankannya
  • Pengujian itu sendiri juga membantu mengurangi risiko saat tindakan tersebut benar-benar dijalankan
• Semua perubahan harus membatasi cakupan dampaknya dengan deploy canary
  • Perubahan konfigurasi caching menyebabkan hasil yang tidak diinginkan dan sangat melumpuhkan layanan YouTube selama 13 menit
  • Jika perubahan global itu dirilis bertahap dengan strategi canary, insiden bisa dibatasi sebelum berdampak global
  • Materi terkait mencakup makalah strategi canary dan video presentasi SREcon

Rollback dan pengujian yang dipelajari dari gangguan Calendar

• Perubahan berisiko memerlukan Big Red Button yang sudah didefinisikan sebelumnya
  • Big Red Button adalah pengaman sederhana dan mudah dijalankan untuk membalikkan penyebab yang menciptakan keadaan yang tidak diinginkan
  • Ada kasus ketika seorang engineer nyaris menghindari gangguan besar dengan mencabut daya komputer desktop sebelum perubahan menyebar
  • Saat merencanakan rollout besar, perlu mempertimbangkan “Apa Big Red Button saya?”, dan semua dependensi layanan harus memiliki mekanisme yang bisa dijalankan saat darurat
  • Tulisan terkait: Generic Mitigations
• Unit test saja tidak cukup; diperlukan pengujian integrasi
  • Unit test memverifikasi apakah komponen individual bekerja sesuai harapan, tetapi tidak sepenuhnya mereproduksi lingkungan runtime dan kebutuhan produksi
  • Pengujian integrasi digunakan untuk memverifikasi apakah job dan task dapat melakukan cold start, dan apakah komponen-komponen bersama-sama membentuk sistem yang diinginkan
  • Dalam gangguan Calendar, jalur pengujian berbeda dari jalur penggunaan nyata, sehingga meskipun ada banyak pengujian, hal itu tidak membantu menilai bagaimana perubahan akan bekerja di kondisi sebenarnya

Gangguan token OAuth 2017 dan kesinambungan operasional

• Pada Februari 2017, token OAuth yang tidak dapat digunakan membuat jutaan pengguna logout dari perangkat dan layanan, dan 32.000 perangkat OnHub serta Google WiFi melakukan reset pabrik
• Karena kegagalan login, permintaan pemulihan akun manual meningkat 10 kali, dan Google membutuhkan sekitar 12 jam untuk pulih sepenuhnya dari insiden tersebut
• Respons insiden membutuhkan saluran cadangan yang terpisah dari saluran komunikasi utama
  • Saat itu tim berharap dapat mengelola insiden lewat Google Hangouts dan Google Meet
  • Namun ketika 350 juta pengguna logout dari perangkat dan layanan, bergantung pada layanan Google sendiri bukan pilihan yang tepat
  • Saluran komunikasi cadangan dengan dependensi yang terpisah harus disiapkan dan diuji
• Layanan harus tetap berfungsi dengan graceful degradation bahkan dalam situasi pengecualian
  • Tidak cukup membagi ketersediaan hanya menjadi “sepenuhnya normal” atau “sepenuhnya berhenti”
  • Jika fungsi minimum tetap dipertahankan dalam mode degradasi, pengalaman pengguna bisa menjadi lebih konsisten
  • Degradasi mungkin tidak selalu terlihat oleh pengguna, dan layanan harus dirancang agar terus berjalan bahkan dalam kondisi luar biasa

Bencana, otomatisasi, rollout, dan keberagaman perangkat keras

• Ketahanan terhadap bencana dan pengujian pemulihan adalah elemen inti strategi kesinambungan bisnis
  • Pengujian ketahanan memverifikasi apakah layanan atau sistem dapat bertahan dalam situasi kegagalan, latensi, dan gangguan
  • Pengujian pemulihan memastikan bahwa layanan dapat kembali ke keadaan normal setelah penghentian total
  • Situasi ekstrem seperti bencana alam atau serangan siber juga perlu diasumsikan, seperti dalam Weathering the Unexpected
  • Kegiatan ketika tim meninjau skenario secara tabletop game, seperti “apa yang terjadi jika sebagian koneksi jaringan tiba-tiba terputus?”, juga berguna
• Untuk insiden dengan sinyal yang jelas, otomatisasi mitigasi menjadi cara untuk menurunkan MTTR
  • Pada Maret 2023, beberapa perangkat jaringan di beberapa pusat data gagal hampir bersamaan, menyebabkan packet loss yang meluas
  • Selama insiden 6 hari ini, sekitar 70% layanan terdampak pada tingkat yang berbeda-beda tergantung lokasi, beban layanan, dan konfigurasi saat kegagalan jaringan terjadi
  • Persentase layanan yang terdampak: {p:70}
  • Jika sinyal bahwa kegagalan tertentu telah terjadi cukup jelas, langkah mitigasi manual dapat dimulai secara otomatis untuk menurunkan MTTR
  • Dalam beberapa kasus, lebih baik terlebih dahulu menghindari dampak ke pengguna lalu menganalisis akar masalahnya
• Semakin panjang jarak antar-rollout, semakin sulit menilai keamanan perubahan
  • Pada Maret 2022, gangguan sistem pembayaran menghalangi penyelesaian transaksi pelanggan dan menunda Pokémon GO Community Day
  • Penyebabnya adalah penghapusan satu field basis data, dan perubahan itu tampak aman karena penggunaan field tersebut sudah dihapus dari kode
  • Namun, karena siklus rollout yang lambat pada sebagian sistem, sistem live ternyata masih menggunakan field itu
  • Dalam sistem multi-komponen yang kompleks, penundaan rollout yang panjang membuat penilaian keamanan suatu perubahan menjadi sangat sulit
  • Dengan pengujian yang tepat dan rollout yang sering, jenis kegagalan tak terduga ini bisa dikurangi
• Satu versi perangkat keras global dapat menjadi single point of failure
  • Menyerahkan fungsi penting hanya pada satu model peralatan dapat menyederhanakan operasi dan pemeliharaan
  • Namun jika model itu mengalami masalah, fungsi penting tersebut tidak lagi bisa dijalankan
  • Pada Maret 2020, perangkat jaringan dengan bug zero-day yang belum terdeteksi memunculkan bug tersebut akibat perubahan pola lalu lintas, dan karena model serta versi yang sama digunakan di seluruh jaringan, terjadilah gangguan regional yang signifikan
  • Karena ada beberapa backbone jaringan, lalu lintas berprioritas tinggi masih bisa dialihkan ke jalur alternatif yang tetap berfungsi sehingga gangguan total dapat dihindari
  • Bug potensial dalam infrastruktur penting dapat tersembunyi hingga peristiwa yang tampak tidak berbahaya memicunya, dan pemeliharaan infrastruktur yang beragam bisa menjadi pembeda antara gangguan bermasalah dan gangguan total

[GN⁺]

Opini Hacker News

• Tulisannya sangat bagus dan tampak bisa diterapkan secara luas. Tidak ada bagian yang terasa seperti “ini cuma berlaku di Google”
  Kanal komunikasi, kanal cadangan, bahkan cadangan untuk kanal cadangan itu benar-benar penting. Di Netflix, saat memilih vendor untuk sistem yang dipakai selama insiden, kami selalu memastikan sistem itu tidak berjalan di atas AWS; di reddit, kami menaruh IRC cadangan di server kantor untuk berjaga-jaga jika IRC utama tidak bisa dipakai
  Saya pernah dengar Google juga punya server IRC cadangan di AWS, tapi itu mungkin cuma legenda. Intinya adalah memiliki kanal kontak tambahan yang sebisa mungkin tidak bergantung pada infrastruktur sendiri

  • Baru sekarang saya sadar. Saya dulu mengejek Google karena membuat Google Talk, Hangouts, Allo, Duo, Messages, Spaces, Wave, Buzz, Plus, Meet, padahal pada skala itu semuanya sebenarnya adalah langkah SRE yang diperlukan
  • Puncak dari “hanya berlaku di Google” adalah mereka perlu menyiapkan kanal komunikasi cadangan yang tidak bergantung pada Google. Saat on-call sebagai SRE di tim trafik internet Google, komunikasi respons insiden secara alami dilakukan lewat Google Meet, tetapi masalahnya: bagaimana kalau Google Meet tumbang?
    Tim itu berada di jalur kritis, jadi kalau kami dipanggil karena sistem kami, kemungkinan Google Meet dan juga Google.com ikut tumbang sama sekali bukan hal yang kecil. Email juga tidak bisa karena Gmail, ponsel kerja juga tidak bisa karena Google Fi, ISP rumah pun Google Fiber/Webpass, jadi kami perlu lapisan cadangan tambahan
    Karena itu Google memang benar-benar punya server IRC cadangan untuk komunikasi. Saya tidak akan menyebut lokasinya, tetapi justru karena alasan itulah server itu secara eksplisit ditempatkan di luar infrastruktur Google
  • Seingat saya Google menjalankan IRC di jaringan internal perusahaan, dan jaringan itu sepenuhnya terpisah dari lingkungan produksi. Jadi tidak mengejutkan kalau server itu ada di ruang server kecil di suatu kantor
    Dalam konteks “bisa diterapkan secara luas dan bukan cuma berlaku di Google”, hal yang hampir tidak pernah saya lihat di tempat lain adalah ruang panik operasional. Maksudnya ruang aman dengan VPN cadangan menuju lingkungan produksi
  • Sebelum spin-off, tanggung jawab TI dibagi oleh dua grup, dan tim DevOps hanya bisa mengendalikan sebagian. Saat itu kami berada dalam kondisi operasi heterogen, memakai satu data center on-premises bersama layanan cloud
    Suatu hari SAN produksi bermasalah, data center on-premises tumbang, dan Atlassian ikut mati di sana. Tidak ada Jira, tidak ada Confluence, CI/CD mungkin juga tidak ada, tidak ada dokumen prosedur pemulihan yang rapi—yang tersisa hanya pengetahuan kesukuan
    Orang-orang marah besar, dan itu wajar. Menaruh sistem yang berhadapan dengan pelanggan dan sistem terkait infrastruktur dalam satu keranjang benar-benar berbahaya
  • Server IRC cadangan Google memang benar-benar ada, tetapi tidak berjalan di atas AWS atau penyedia cloud besar lainnya
    Setidaknya begitu keadaannya dua tahun lalu saat saya masih bekerja di sana

• Suatu saat saya ingin mendengar solusi untuk masalah cold start sepenuhnya. Perusahaan dengan stack internal raksasa punya dependensi melingkar pada infrastruktur inti
  Software-defined networking membutuhkan perangkat lunak tertentu berjalan agar routing paket bisa dimulai kembali, mesin tanpa disk membutuhkan storage untuk boot, dan layanan autentikasi membutuhkan akses storage untuk melakukan bootstrap pemberian hak akses keamanan
  Saat ini hal itu ditangani dengan mengoperasikan beberapa region independen, lalu melakukan bootstrap data center yang benar-benar mati dari infrastruktur yang sudah ada. Namun saya belum pernah mendengar ada yang berhasil menaikkan kembali seluruh stack dari kondisi benar-benar tanpa daya
  Ketika Facebook merusak total jaringan operasionalnya beberapa tahun lalu pun, mesin-mesinnya masih menyala dan sebagian konektivitas internal masih tersisa. Jika peristiwa seperti badai matahari besar membuat jaringan listrik di seluruh dunia padam lama sampai generator pun habis, tidak ada jaminan cloud seperti AWS atau GCP pasti bisa hidup kembali
  Mungkin ada data center kecil khusus dengan daya cadangan yang sangat baik dan kemampuan untuk sepenuhnya terisolasi dari lonjakan pada jaringan listrik

  • Saat di Google SRE, ada sistem yang memantau dan menegakkan peer RPC yang diizinkan maupun dilarang. Jika suatu sistem mencoba memakai sistem lain, sistem itu akan menggagalkannya atau mengirim peringatan
    Di bagian atas stack, ini berguna untuk melacak dependensi yang diam-diam ditambahkan penulis library; di bagian bawah, ini membantu memastikan hal-hal yang seharusnya berada di dasar benar-benar berada di dasar
    Kami juga menjalankan start-up dan shutdown cluster virtual otomatis agar prosedur terdokumentasi tidak menjadi usang, dan selama enam tahun saya sebagai SRE, saya melihat prosedur itu turun dari 90 hari menjadi kurang dari 1 jam
    Hal-hal seperti manajemen kunci enkripsi global yang membutuhkan objek fisik juga rutin dilatih untuk dimulai ulang dari nol, dan latihan DiRT tahunan berusaha memastikan tidak ada individu, tim, atau kantor mana pun yang menjadi syarat wajib agar sistem terus beroperasi
  • Solusinya harus dimulai lebih awal, tetapi sederhana: biasakan menghancurkan dan membuat ulang semuanya
    Jika dimulai terlambat, ini sangat menyakitkan, tetapi kalau dilakukan sejak awal, Anda akan cepat terbiasa dan bisa menemukan perubahan yang merusak atau dependensi aneh lebih dini
    Ini juga berlaku untuk hardware. Arsitektur akan berubah agar mampu menghadapi situasi ketika sesuatu dicabut atau diinisialisasi ulang. Dibutuhkan lebih banyak otomasi, version control, dan change management; sebagai hasilnya, selain mencegah insiden dan mempercepat pemulihan, seluruh pekerjaan juga menjadi lebih cepat dan sederhana. Ini perubahan budaya yang besar
  • Azure punya prosedur untuk mencegah dependensi melingkar, dan mereka rutin melatihnya saat menaikkan region baru
    Seingat saya sebagian pendekatannya dianggap informasi sensitif, jadi saya tidak akan menjelaskan lebih jauh
  • Di sisi jaringan listrik, katanya rencana cold start sudah disiapkan, tetapi saya tidak yakin apakah itu benar-benar akan berfungsi. Saya penasaran apakah ada yang pernah melihat postmortem yang menunjukkan seberapa baik cold start jaringan listrik nyata berjalan
    Menarik juga jaringan listrik mana yang paling sering melakukan cold start. Idealnya, tempat seperti itu sudah mahir melakukannya. Mungkin di Karibia atau suatu tempat di Afrika
    Namun cold start jaringan listrik kecil—misalnya pulau terpencil dengan satu generator diesel dan panel surya—mungkin terlalu mudah sehingga kurang cocok sebagai studi kasus
    Jelas bahwa internet itu sendiri tidak bisa di-cold-start seperti jaringan listrik AC. AS terlalu banyak. Jika Anda berpikir sebentar tentang arti AS, Anda akan paham mengapa cold start yang terkoordinasi dan sudah dilatih sebelumnya mustahil dilakukan
  • AWS mempelajari pelajaran ini saat insiden S3 pada 2017, dan setelah itu ada banyak perubahan internal

• Untuk mendalami topik ini, saya hampir selesai membaca Building Secure and Reliable Systems dari Google, dan ini bukan bacaan ringan, melainkan lebih seperti buku teks yang serius
  Bukunya cukup menarik, dan banyak isinya tampak seperti akal sehat, tetapi seperti ungkapan bahwa istilah “akal sehat” itu sendiri kontradiktif, buku ini berguna untuk menyegarkan kembali seluruh pengetahuan sekaligus

  • Yang ingin membaca bisa melihatnya di sini: https://google.github.io/building-secure-and-reliable-system...

• Belakangan saya mendengar beberapa perusahaan membubarkan organisasi SRE dan memindahkan anggotanya ke tim SWE. Ada rumor bahwa LinkedIn, Adobe, dan Robinhood melakukan hal itu
  Jadi saya jadi berpikir apakah SRE adalah produk sampingan ekonomi gelembung ketika uang mudah masih melimpah. Apakah tidak bisa beroperasi tanpa menanggung biaya besar untuk memiliki tim SRE terpisah?
  Seperti admin sistem atau penguji QA yang sebagian besar menghilang dan banyak fungsinya berpindah ke tim pengembangan perangkat lunak, saya penasaran apakah SRE masih akan ada 10 tahun lagi

  • Jika fungsi itu diambil alih oleh tim pengembangan, kemungkinan besar mereka tidak akan melakukannya sebaik tim SRE khusus
    Namun saat ini PHK terus berlanjut, sehingga tidak banyak perusahaan yang peduli dengan hal seperti itu. Tren industri untuk menugaskan developer ke masalah meski bukan bidang keahlian mereka tidak akan hilang, dan akan makin menonjol saat resesi
    Full-stack developer adalah contoh bagus bagaimana dua peran digabungkan tanpa membayar kompensasi dua kali lipat
  • SRE bukan produk sampingan ekonomi gelembung. Sejauh yang saya tahu, Google sudah memiliki SRE hampir sejak masa-masa awalnya
    Namun saya tetap menganggap inti argumen lainnya benar. Karena DevOps belakangan ini, kemampuan yang dibutuhkan developer makin luas dan banyak tumpang tindih dengan SRE. Perusahaan kemungkinan besar akan mengurangi tim SRE dan menyebarkan tanggung jawabnya ke developer
    Alasan besar lainnya adalah otomatisasi. Jika membaca situs yang ditautkan itu cukup lama, kita bisa melihat bahwa pada masa awal Google, SRE melakukan banyak pekerjaan manual, seperti memantau grafik secara manual saat deployment
    Saat itu bahkan Google belum memiliki otomatisasi sistem yang memadai, sehingga SRE menjadi penting. Jika melihat cerita Sisyphus https://www.usenix.org/sites/default/files/conference/protec..., kita bisa sedikit memahami bagaimana kegagalan Google dalam memperkenalkan otomatisasi standar pada awalnya justru menjamin keamanan kerja SRE
  • Saya selalu tidak terlalu memahami mengapa peran bernama SRE itu ada. Jabatan saya sendiri pernah SRE, tetapi menurut saya monitoring, log, performa, dan metrik adalah hal yang seharusnya ditangani oleh developer yang kompeten
    Tidak logis menyerahkan operasi software yang kita tulis sendiri kepada orang lain. Cukup jadikan SWE sebagai on-call. Jika mereka menganggap pekerjaan manual adalah cara terbaik, biarkan mereka melakukannya sendiri; dan jika levelnya seperti itu, mereka seharusnya dipecat sebagai engineer yang buruk
    Aneh rasanya wawancara dibuat sedemikian sulit, tetapi orangnya tidak tahu bagaimana komputer yang mereka program sebenarnya bekerja. Hal seperti cara kerja sistem operasi pun ada di kurikulum sarjana, dan aneh juga jika itu dialihkan ke banyak peran dan jabatan yang terutama diisi mantan admin sistem otodidak
    Semua SWE bagus yang saya kenal memahami bagaimana sistem operasi, komputer, dan jaringan bekerja
    Pekerjaan yang umum dilakukan SRE saat ini, seperti otomatisasi umum, penyediaan alat pengembangan, dan peningkatan developer experience, sedang berpindah ke tim platform. Saya pikir perannya akan berubah besar ke depannya
  • Sebagai SWE SRE, menurut saya dalam beberapa kasus lebih baik masuk ke dalam tim, dan dalam kasus lain tidak selalu demikian
    Satu tim SRE bisa mendukung beberapa tim pengembangan, dan tim pengembangan sering kali hampir tidak menghabiskan waktu untuk aspek infrastruktur kompleks atau sistem terdistribusi, karena itu bukan area yang mereka khawatirkan sehari-hari
    Karena itu masuk akal adanya organisasi infrastruktur yang bergerak sebagai unit berbeda dari tim pengembangan khusus. Entah disebut SRE, tim SRE SWE, atau sekadar infrastruktur, di atas skala tertentu ada banyak perhatian lintas tim sehingga memisahkannya seperti itu menjadi lebih murah
  • Google juga sekarang bergerak ke arah ini
    Dengan SRE khusus, ada orang yang benar-benar ahli dalam operasi serta sistem, alat, dan alert terkait, dan ada tanggung jawab yang jelas atas hasilnya. Namun karena mereka tidak sepenuhnya memiliki sistem yang mereka pelihara, masalah organisasi bisa muncul
    Bisa terjadi “kami ingin merilis X tetapi SRE menentang,” atau sebaliknya, dan orang-orang non-SRE mungkin tidak mau bertanggung jawab atas kode yang sulit didukung
    Sebaliknya, tim engineering tanpa SRE dapat mengurangi masalah organisasi dan sosial semacam itu, tetapi keandalan operasional menjadi hanya salah satu dari banyak prioritas
    Dalam praktiknya, saya pikir banyak perusahaan sedang memutuskan bahwa mereka tidak terlalu menganggap keandalan penting sebagai hasil bisnis. Terutama ketika biaya peluang pengembangan fitur makin besar

• Mitigasi otomatis perlu benar-benar dipikirkan lama-lama. Selama 30 tahun berkarier, saya beberapa kali melihat mitigasi otomatis justru memperburuk masalah. Jadi perlu dipertimbangkan dengan cermat apakah self-healing memang benar-benar dibutuhkan
  Pada 2014 saya membuat solusi pelaporan crash mobile untuk internal perusahaan, dan sebagian backend berjalan di satu server yang menjadikan Redis sebagai single point of failure. Proses failover-nya semi-otomatis, jadi manusia harus memastikan dulu apakah peringatannya valid sebelum memulainya
  Kalaupun turun, tidak ada kerugian uang nyata; paling buruk developer aplikasi mobile hanya sedikit terganggu sementara. Selama 10 tahun beroperasi, jumlah kejadian yang perlu failover bisa dihitung dengan dua jari
  Meski sistem ini tidak punya SLA, uptime-nya jauh lebih baik daripada sistem internal lain yang jauh lebih penting
  Sebaliknya, lihat saja kasus-kasus GitHub: https://github.blog/2023-05-16-addressing-githubs-recent-ava..., https://github.blog/2018-10-30-oct21-post-incident-analysis/, https://www.datacenterknowledge.com/archives/2012/12/27/gith...
  Tentu saja GitHub beroperasi pada skala yang jauh lebih besar. Intinya, redundansi dan mitigasi otomatis menambah kompleksitas, dan secara definisi berjalan dalam keadaan yang nyaris tidak pernah diuji, pada situasi yang tidak terduga
  Jadi pertimbangkan SLA dan biaya downtime, lalu seimbangkan dengan kompleksitas yang akan ditambahkan untuk mencegah gangguan. Sekitar 1998, saya menggabungkan dua NetApp dalam konfigurasi high availability, dan pelajaran pertama saya adalah saat satu unit gagal lalu ikut merusak semua disk di unit lainnya
  Pada periode yang mirip, hal yang sama juga terjadi dengan dua firewall Cisco PIX, dan sejak itu saya selalu berhati-hati terhadap high availability serta failover/mitigasi otomatis

• Saya penasaran bagaimana big red button dan degradasi performa bertahap yang disengaja ditangani di praktik nyata. Terutama bagaimana memastikan hal-hal ini tetap bekerja saat sistem sedang bermasalah
  Misalnya, apakah memakai feature flag berbasis database; kalau ya, bagaimana jika database itu sendiri atau API aksesnya sedang overload?
  Atau apakah memakai flag startup statis seperti environment variable; dalam kasus itu, bagaimana memastikan deployment-nya cukup cepat? Atau apakah ada pendekatan yang sama sekali berbeda?

  • Saat perusahaan masih kecil, pendekatan sederhana biasanya benar-benar lebih baik. Dalam kasus rata-rata, lebih baik menjaga kesederhanaan agar mudah dipulihkan daripada membuat solusi kompleks yang tampak andal tetapi rapuh di kondisi batas
    Meski tidak memakai redundansi di sebagian jalur kritis, jika sistem cukup sederhana untuk ada di kepala semua maintainer dan mudah di-reboot atau di-rollback, itu bisa jadi lebih baik
    Namun ketika perusahaan mulai memberi jaminan seperti “uptime five nines”, sebagian kompleksitas memang diperlukan untuk merancang sistem yang dapat terus dikembangkan dan ditingkatkan sambil mempertahankan jaminan itu
  • Di buku SRE ada bab tentang pembatasan sisi klien: https://sre.google/sre-book/handling-overload/
    Di Google, jika suatu cluster dinilai tidak sehat, mereka rutin melakukan “backend drain”, dan ada sistem di lapisan API/load balancer yang menanganinya dengan cepat
    Di tempat lain, saya juga pernah melihat ini ditangani dengan flag level aplikasi. Caranya seperti melakukan kubectl edit, jadi jelas tidak ideal, tetapi berhasil
  • Detail implementasinya bergantung pada stack, tetapi ada tiga hal yang perlu diingat
    Pertama, jaga agar tetap sederhana. Cukup mengecek flag secara sederhana tanpa logika rumit atau penyimpanan data kompleks
    Kedua, tempatkan sedekat mungkin dengan sumbernya, tetapi jangan terlalu memercayai klien. Bisa ada versi lama, keterlambatan propagasi, atau bug, jadi lebih baik jika mode degradasi bisa dipilih di sisi klien dan server; jika hanya bisa salah satu, sisi server lebih baik
    Ketiga, uji secara sering dengan traffic nyata. Jangan percaya lingkungan pengujian; lakukan pengujian berkala skala kecil seperti 0,1% dan pengujian skala besar yang terjadwal. Jika belum diuji, itu tidak akan bekerja saat dibutuhkan; jika pernah bekerja setahun lalu, besar kemungkinan sekarang tidak. Perangkat yang tidak diuji bisa memperbesar kerusakan alih-alih menyelesaikannya
  • Tergantung situasi
    Misalnya, katakanlah Anda menambahkan fitur baru yang menampilkan foto profil di sebelah komentar di Hacker News. Karena tentu saja semuanya dibuat sebagai microservice, anggap saja generator halaman frontend mengirim panggilan ke layanan profil, lalu layanan profil melakukan lookup dan mengembalikan lokasi gambar
    Sebagai bagian dari rencana peluncuran, dokumentasikan prosedur big red button yang harus diikuti jika komponen baru membebani layanan profil atau penyimpanan gambar. Artinya, jalankan perintah di lapisan jaringan untuk membatasi laju request keluar dari layanan saya, dan dalam keadaan darurat mungkin setel ke 0
    Lookup akan gagal, tetapi generator halaman dirancang untuk melakukan degradasi bertahap sehingga tetap merender teks komentar tanpa foto profil
    Ini bukan dokumen desain sungguhan dan bukan saran tentang apa atau bagaimana membangunnya; ini hanya gambar dengan krayon untuk menjelaskan poinnya
  • Di beberapa perusahaan, saya sering melihat konsep “mendistribusikan konfigurasi pusat ke edge dan memperbaruinya saat runtime”
    Saya pernah melakukannya dengan CDB (constant database) milik djb, dan juga melihat kasus polling file konfigurasi JSON lewat API atau memakai dbm/gdbm/Berkeleydb/leveldb
    Pendekatan ini bisa diperluas ke big red button lain. Tidak elegan, tetapi saya beberapa kali mengoperasikan layanan yang memeriksa keberadaan file untuk menentukan apakah health check akan disediakan. Mengeluarkan node dari rotasi load balancer semudah membuat satu file
    Kuncinya adalah jika database mengalami gangguan, sistem harus memakai konfigurasi terakhir yang diketahui baik sebagai default

• Saya benar-benar ingin menekankan kalimat “mekanisme pemulihan harus diuji sepenuhnya sebelum keadaan darurat”. Sebagai orang yang tanpa diduga menjadi SRE di Google dan dikenal di seluruh perusahaan karena salah memakai double negative, ini adalah hal yang sangat penting untuk dilakukan dengan benar sejak awal
  Jika ada Googler yang penasaran, coba cari nama pengguna saya secara internal; Anda bisa menemukan bagaimana saya menciptakan dampak yang tak terukur besarnya

• Cara paling murah untuk mencegah insiden adalah menangkapnya sejak awal siklus hidup. Bug perangkat lunak mirip dengan serangga sungguhan. Awalnya berupa telur, yaitu ide perubahan, lalu nimfa yang menetas adalah POC pertama. Saat mencapai lingkungan produksi, ia sudah menjadi serangga dewasa
  Bukankah ada tahap sebelum dewasa? Betul. Aplikasi harus melewati beberapa tahap sebelum matang. Jauh lebih murah menemukan bug sebelum ia tumbuh penuh dan bertelur
  Jika deployment canary sulit dan rollback juga bermasalah, kita perlu menambahkan lebih banyak pengujian sebelum deployment produksi. Temukan bug sedini mungkin dengan sebanyak mungkin cara: linter, unit test, end-to-end test, profiler, monitor sintetis, replika produksi read-only, performance test, dan sebagainya
  Feature flag, kompatibilitas ke belakang, dan lainnya juga berguna, tetapi tidak bisa mengalahkan Shift Left

• Jika tertarik pada daftar serupa dari sudut pandang seseorang yang 15 tahun menjadi SRE di bidang FinTech, perbankan, hedge fund, dan kripto, saya merekomendasikan tulisan ini: https://x.com/alexpotato/status/1432302823383998471?s=20
  Cuplikan: “25. Jika ada rule engine yang membuat aturan baru lebih mudah daripada mencari aturan yang sudah ada lewat kondisi filter, pada akhirnya akan muncul banyak sekali aturan duplikat”

• “Seorang engineer yang mengajukan perubahan yang hampir menyebabkan insiden besar nyaris menghindarinya dengan mencabut daya komputer desktopnya sebelum perubahan menyebar”—maksudnya apa?

  • Perubahan itu sedang diorkestrasi dari desktop engineer tersebut, dan ketika ia melihat ada sesuatu yang berjalan salah, ia mencabut daya desktopnya untuk menghentikan deployment. Bisa dibilang ia menekan big red button
  • Selalu lucu bahwa Google adalah perusahaan paling berbasis web di dunia, tetapi peta politik internalnya menempatkan Infra, Search, dan Ads di atas yang lain
    Akibatnya, para SWE infrastruktur menghabiskan sepanjang hari menulis CLI bodoh alih-alih membuat tombol sungguhan. Saat saya pergi, banyak hal sudah mulai berubah
    Menurut saya Google seharusnya lebih terbuka soal insiden internal. Insiden ini khususnya sangat terkenal secara internal
  • Ini adalah konsekuensi logis dari zero-trust network. Jika workstation seorang engineer bisa mengirim RPC ke sistem produksi, dan engineer itu memenuhi syarat untuk mengambil peran berhak istimewa, tidak ada bedanya apakah otomatisasi dijalankan di lingkungan produksi atau di workstation
    Bahkan pada skala yang sangat besar, shell tool dan CLI klien RPC dapat menjangkau semua mesin di seluruh dunia dengan cukup cepat
  • Saya ingat suatu ketika harus menjalankan skrip pada sebagian besar fleet server Google, dalam skala ratusan ribu mesin, dan menjalankannya dari desktop dengan utilitas bergaya pssh
    Itu 10 tahun lalu, jadi saya tidak tahu apakah masih dipakai seperti itu, tetapi cara itu luar biasa cepat. Mungkin kejadian itu juga semacam ini
  • Anekdot yang menarik. Saat ini, terdengar gila bahwa komputer desktop seorang engineer bisa menyebabkan insiden seperti itu
    Namun 20 tahun lalu hal itu mungkin lebih umum, dan bahkan sekarang masih bisa terjadi di organisasi kecil