Evolusi SRE di Google

• SRE Google telah berhasil mengurangi insiden meski skala layanan makin besar, tetapi menilai pendekatan lama saja tidak cukup untuk kerugian yang mutlak harus dicegah seperti pelanggaran privasi atau kehilangan data, sehingga mengadopsi STAMP
• STAMP berfokus pada interaksi sistem dan kegagalan kontrol alih-alih kerusakan komponen individual; CAST digunakan untuk investigasi insiden, dan STPA untuk analisis risiko
• Model aliran data dan rantai sebab-akibat linear makin terbatas ketika berhadapan dengan diagram RPC berisi lebih dari 100 node, model arsitektur yang usang, dan persyaratan yang terlewat
• Dalam insiden internal quota rightsizer pada 2021, umpan balik penggunaan resource yang keliru dan pending change yang tidak tersampaikan menciptakan kondisi berisiko selama beberapa minggu, hingga akhirnya berujung pada gangguan
• Google mengerahkan upaya berskala engineer-weeks untuk analisis STPA, menemukan ratusan skenario, dan memperluas cakupan SRE ke desain keselamatan Google Cloud, jaringan internal, serta berbagai produk

---

Batasan yang Dihadapi Pendekatan SRE Lama

• Produk Google digunakan setiap hari oleh miliaran orang di seluruh dunia, dan selama 25 tahun terakhir skala layanannya meningkat besar, tetapi gangguan menjadi lebih jarang
• SRE selama ini memperluas keandalan melalui SLO, error budget, strategi isolasi, postmortem yang menyeluruh, dan rollout bertahap
• Tantangan kini bukan sekadar menurunkan frekuensi gangguan, melainkan menangani kerugian yang harus dicegah agar tidak terjadi sejak awal
  • Pelanggaran privasi
  • Kehilangan data
  • Kegagalan kepatuhan regulasi
• Error budget lama umumnya cocok untuk layanan web dengan sedikit state, tetapi tidak memadai untuk menangani kerugian yang mendekati error budget 0
• Ketika AI dan ML menjadi inti hampir semua produk, dan otomasi memungkinkan skalabilitas, biaya serta efisiensi energi menjadi sama pentingnya dengan fitur bagi pengguna

Struktur Cara Berpikir SRE Lama

• Analisis risiko tradisional secara garis besar terdiri dari tiga elemen
  • Cara memodelkan sistem
  • Teori sebab-akibat yang menjelaskan bagaimana masalah terjadi
  • Algoritme pencarian untuk menemukan risiko
• Pendekatan lama SRE Google tidak pernah diformalkan sebagai teori eksplisit, tetapi selama ini menganalisis risiko dengan berpusat pada arsitektur perangkat lunak dan model aliran data
• Model aliran data menunjukkan bagaimana request jaringan atau data bergerak di antara berbagai bagian sistem
• Model ini secara alami mengarah pada penalaran sebab-akibat linear
  • Memahami jaminan keandalan dengan melihat SLO tiap komponen
  • Memastikan apakah persyaratan caller terpenuhi atau terlampaui
• Dalam postmortem, digunakan penalaran induktif yang menurunkan pola umum dari peristiwa individual
  • Tidak berhenti pada memperbaiki satu insiden, tetapi mencari cara mencegah seluruh kelas insiden serupa
  • Berupaya mengubah alert berulang menjadi solusi engineering untuk menghilangkan akar masalah

Batasan Model Aliran Data dan Analisis Sebab Linear

• Seiring kompleksitas sistem meningkat setiap tahun, model aliran data makin sulit menampung kompleksitas pada skala Google
• Diagram RPC dan model arsitektur perangkat lunak menjadi terlalu rumit bila abstraksi tidak digunakan secara konsisten, dan biasanya tetap tidak lengkap atau usang
• Model seperti ini tidak cukup menunjukkan dinamika sistem
  • RPC mana yang dapat memulai aliran
  • Bagaimana error menyebar
  • Komponen mana yang dapat menyebabkan gangguan serius, dan komponen mana yang hanya dapat menimbulkan masalah kecil
  • Apakah interaksi tertentu aman dalam satu konteks tetapi tidak aman dalam konteks lain
  • Apa tujuan sistem secara keseluruhan
  • Tanggung jawab apa yang dimiliki tiap komponen terhadap tujuan keseluruhan
• Diagram aliran data dengan lebih dari 100 node sudah terasa sangat berat sejak titik awal pencarian cacat
• Jika persyaratan keselamatan terlewat atau salah pada tahap definisi persyaratan, keselamatan sistem dapat rusak meski desain mengimplementasikan persyaratan tersebut dengan sempurna
• Cara belajar dari data gangguan memiliki keterbatasan untuk memprediksi dan mencegah kerugian yang belum pernah terjadi sekalipun

Cara STAMP Mengubah Pola Pikir

• SRE Google menerima teori sistem dan teori kontrol, serta mengadopsi framework STAMP yang dikembangkan Nancy Leveson dari MIT
• STAMP memandang kecelakaan bukan sebagai rangkaian kegagalan komponen, melainkan sebagai akibat dari kontrol sistem yang tidak bekerja secara memadai
• CAST digunakan untuk investigasi setelah insiden, sedangkan STPA digunakan untuk analisis risiko
• STAMP memperlakukan keselamatan bukan sebagai properti komponen individual, melainkan sebagai properti emergen pada level sistem
• Pertanyaan analisis pun berubah
  • Pertanyaan lama: layanan perangkat lunak mana yang gagal?
  • Pertanyaan STAMP: interaksi apa di antara tiap bagian sistem yang tidak dikontrol secara memadai?
• Banyak kecelakaan pada sistem kompleks dapat terjadi ketika tiap komponen bekerja sesuai desain, tetapi bersama-sama menciptakan keadaan yang tidak aman

Empat Syarat dalam Teori Kontrol

• Syarat kontrol dari 『An Introduction to Cybernetics』 karya W.R. Ashby diintegrasikan ke dalam metodologi STAMP Leveson
• Untuk mengontrol sebuah proses, diperlukan empat syarat
  • Syarat tujuan: controller harus memiliki tujuan
  • Syarat tindakan: controller harus dapat memengaruhi keadaan sistem
  • Syarat model: controller harus memiliki model sistem
  • Syarat observabilitas: controller harus dapat memahami keadaan sistem
• Dalam praktik SRE, syarat-syarat ini dapat digunakan sebagai kriteria untuk memastikan elemen yang diperlukan agar sistem kompleks dapat dikontrol secara efektif

Ruang Respons yang Diciptakan Kondisi Berisiko

• Model rantai sebab-akibat linear biasanya hanya menunjukkan dua keadaan: operasi normal dan operasi dengan kerugian
• Transisi dari operasi normal ke operasi dengan kerugian biasanya mendadak, dan nyaris tidak ada waktu respons untuk mencegah kerugian
• Alasan SRE menggunakan SLO burn cepat dan burn lambat sekaligus adalah untuk mendeteksi masalah sebelum kerugian nyata terjadi, tetapi SLO seperti ini biasanya merupakan properti komponen individual
• STAMP memformalkan hal ini sebagai kondisi berisiko pada level sistem
  • Kondisi berisiko adalah keadaan sistem atau kumpulan kondisi yang, ketika dikombinasikan dengan kondisi lingkungan terburuk tertentu, menimbulkan kerugian bagi satu atau lebih pemangku kepentingan
• Kondisi berisiko bukan fenomena pada level event individual atau komponen individual
• Sistem dapat bertahan lama dalam kondisi berisiko sebelum kecelakaan terjadi
  • Bug sudah masuk tetapi belum terpicu
  • Alert muncul tetapi tidak diterima siapa pun
  • Server kurang diprovisikan tetapi tiba-tiba menerima traffic dari fitur populer
• Tujuan engineering bukan menghapus setiap kegagalan tunggal, melainkan mencegah sistem masuk ke kondisi berisiko atau mengembalikannya dari kondisi berisiko ke operasi normal

Contoh quota rightsizer pada 2021

• Google menetapkan dan menegakkan quota resource untuk sebagian perangkat lunak di infrastruktur internalnya
• Untuk meningkatkan efisiensi, Google memantau berapa banyak quota yang digunakan tiap layanan, dan bila pemakaian terus-menerus rendah, quota dikurangi secara otomatis
• Dari perspektif STPA, quota rightsizer memiliki tindakan kontrol untuk mengurangi quota layanan
• Tindakan ini menjadi tidak aman ketika rightsizer menurunkan quota di bawah kebutuhan nyata layanan
  • Layanan masuk ke kondisi kekurangan resource
  • Dalam STPA, ini disebut tindakan kontrol yang tidak aman, atau UCA
• UCA memiliki empat jenis
  • Tindakan kontrol yang diperlukan tidak diberikan
  • Tindakan kontrol yang tidak akurat atau tidak memadai diberikan
  • Tindakan kontrol diberikan pada waktu atau urutan yang salah
  • Tindakan kontrol dihentikan terlalu cepat atau diterapkan terlalu lama
• Mengurangi quota di bawah kebutuhan nyata merupakan UCA jenis kedua

Kerentanan yang Terlihat pada Jalur Umpan Balik

• Persyaratan keselamatan dapat dirumuskan sebagai “quota rightsizer tidak boleh mengurangi quota di bawah kebutuhan layanan saat ini”
• Persyaratan ini berguna untuk desain masa depan, rencana pengujian, dan pemahaman sistem
• STPA menstrukturkan analisis agar dapat menemukan skenario konkret yang membuat persyaratan keselamatan ini dilanggar
• Dalam kasus rightsizer, empat skenario representatif dapat diselidiki
  • Rightsizer itu sendiri berperilaku salah
  • Rightsizer menerima umpan balik yang salah atau tidak menerima umpan balik sama sekali
  • Rightsizer mencoba mengirim tindakan, tetapi sistem quota tidak menerimanya
  • Sistem quota itu sendiri berperilaku salah
• Skenario yang benar-benar menonjol adalah ketika umpan balik penggunaan resource saat ini dihitung terlalu rendah
  • Perhitungan penggunaan resource melibatkan beberapa pengumpul data dan logika agregasi yang kompleks
  • Jika hasil perhitungan lebih rendah daripada kenyataan, rightsizer tetap bekerja sesuai desain tetapi menurunkan quota secara keliru
• Sebelumnya, banyak perhatian diberikan pada algoritme penyesuaian quota dan akurasi output, tetapi jalur umpan balik kurang dipahami
• STPA membantu menemukan masalah tidak hanya pada jalur kontrol, tetapi juga pada jalur umpan balik; dalam banyak analisis sistem di Google, jalur umpan balik sering kali kurang dipahami

Alur yang Membuat Insiden Berujung pada Kerugian

• Dalam insiden 2021, umpan balik yang salah tentang resource yang digunakan layanan penting di infrastruktur Google dikirim ke rightsizer
• Rightsizer menghitung quota baru, sehingga mengalokasikan resource jauh lebih sedikit daripada penggunaan sebenarnya
• Sebagai langkah pencegahan, pengurangan quota tidak langsung diterapkan, melainkan ditahan selama beberapa minggu untuk memberi waktu bagi intervensi manusia
• Namun, umpan balik tentang pending change tidak disampaikan kepada siapa pun
• Sistem berada dalam kondisi berisiko selama beberapa minggu, tetapi karena kondisi itu tidak sedang dicari, peluang untuk mencegah kerugian terlewat
• Beberapa minggu kemudian, ketika pengurangan quota diterapkan, terjadilah gangguan yang signifikan
• Google menggunakan STPA untuk memprediksi sebelumnya masalah serupa di berbagai sistem

Arah SRE Google ke Depan

• SRE Google tidak memandang kompleksitas sebagai bug, dan bergerak menuju pendekatan keandalan yang lebih komprehensif dan proaktif dengan memanfaatkan teori kontrol, STPA, dan CAST
• Tujuannya bukan berhenti pada merespons gangguan, melainkan merancang sistem yang lebih aman sejak awal
• Google telah menganalisis beberapa sistem paling kompleksnya dengan STPA, dan dengan upaya sekitar engineer-weeks per analisis, menemukan ratusan skenario dengan berbagai cakupan dampak
• Skenario yang ditemukan dimitigasi sebelum berujung pada gangguan
  • Perbaikan sementara yang cepat
  • Rekayasa perangkat lunak yang direncanakan lebih hati-hati
  • Memanfaatkan proses perencanaan rutin Google untuk meminimalkan biaya dan gangguan
• Pekerjaan saat ini difokuskan pada sistem Google Cloud yang sangat kompleks, sistem jaringan internal berskala besar, dan berbagai produk Google
• Peralihan SRE ke metodologi keselamatan sistem memberikan cara baru bagi engineer untuk memahami sistem yang mereka bangun, dan mengarah pada pemberian jaminan yang lebih kuat tentang cara sistem bekerja