Dokumen dalam Framework Arsitektur Google Cloud memberikan praktik terbaik untuk mengelola layanan dan menentukan proses untuk merespons insiden. Insiden dapat terjadi pada semua layanan, jadi Anda perlu proses yang terdokumentasi dengan baik untuk dapat secara efisien menanggapi masalah ini dan melakukan mitigasi.
Ringkasan manajemen insiden
Tidak dapat dipungkiri bahwa sistem yang Anda desain dengan baik pada akhirnya gagal memenuhi SLO-nya. Tanpa adanya SLO, pelanggan Anda secara longgar menentukan tingkat layanan yang dapat diterima dari pengalaman mereka sebelumnya. Pelanggan mengeskalasi ke dukungan teknis atau grup serupa, terlepas dari apa yang ada dalam SLA Anda.
Untuk melayani pelanggan Anda dengan tepat, buat dan uji rencana manajemen insiden secara teratur. Rencana ini bisa sesingkat checklist satu halaman yang berisi sepuluh item. Proses ini membantu tim Anda mengurangi Waktu Untuk Mendeteksi (TTD) dan Waktu Untuk Memitigasi (TTM).
TTM lebih disukai dibandingkan TTR, yang mengharuskan R untuk perbaikan atau pemulihan sering digunakan untuk menunjukkan perbaikan penuh versus mitigasi. TTM menekankan mitigasi yang cepat untuk mengakhiri dampak pemadaman layanan pada pelanggan dengan cepat, lalu memulai proses yang sering kali lebih lama untuk memperbaiki masalah sepenuhnya.
Sistem yang dirancang dengan baik dengan operasi yang berjalan sangat baik akan meningkatkan waktu antara kegagalan (TBF). Dengan kata lain, prinsip operasional keandalan, termasuk manajemen insiden yang baik, bertujuan untuk mengurangi frekuensi kegagalan.
Untuk menjalankan layanan yang andal, terapkan praktik terbaik berikut dalam proses manajemen insiden Anda.
Tetapkan kepemilikan layanan yang jelas
Semua layanan dan dependensi pentingnya harus memiliki pemilik yang jelas yang bertanggung jawab untuk mematuhi SLO mereka. Jika ada reorganisasi atau pengurangan tim, pimpinan engineer harus memastikan bahwa kepemilikan secara eksplisit diserahkan kepada tim baru, beserta dokumentasi dan pelatihan yang diperlukan. Pemilik layanan harus mudah ditemukan oleh tim lain.
Kurangi waktu untuk mendeteksi (TTD) dengan pemberitahuan yang disetel dengan baik
Sebelum Anda dapat mengurangi TTD, tinjau dan terapkan rekomendasi di build kemampuan observasi ke dalam infrastruktur dan aplikasi Anda serta Bagiantentukan sasaran keandalan Anda dari kategori keandalan Framework Arsitektur. Misalnya, membedakan antara masalah aplikasi dan masalah cloud yang mendasarinya.
Serangkaian SLI yang disesuaikan dengan baik akan memberi tahu tim Anda pada waktu yang tepat tanpa kelebihan beban pemberitahuan. Untuk mengetahui informasi selengkapnya, lihat bagian membuat pemberitahuan yang efisien dari kategori keandalan Framework Arsitektur atau Menyiapkan metrik SLI Anda: CRE life lessons.
Kurangi waktu untuk memitigasi (TTM) dengan pelatihan manajemen insiden
Untuk mengurangi TTM, tentukan rencana manajemen insiden yang terdokumentasi dan dilakukan dengan baik. Memiliki data yang tersedia tentang apa yang berubah di lingkungan. Pastikan bahwa tim mengetahui mitigasi generik yang dapat dengan cepat mereka terapkan untuk meminimalkan TTM. Teknik mitigasi ini mencakup pengosongan, roll back perubahan, penambahan resource, dan penurunan kualitas layanan.
Seperti yang telah dibahas dalam dokumen kategori keandalan Framework Arsitektur lainnya, buat alat dan proses operasional yang andal untuk mendukung rollback perubahan yang aman dan cepat.
Desain tata letak dasbor dan konten untuk meminimalkan TTM
Atur tata letak dan navigasi dasbor layanan Anda sehingga operator dapat menentukan dalam waktu satu atau dua menit apakah layanan dan semua dependensi pentingnya sedang berjalan. Untuk menemukan penyebab potensial masalah dengan cepat, operator harus dapat memindai semua bagan di dasbor agar dapat dengan cepat mencari grafik yang berubah secara signifikan pada saat pemberitahuan muncul.
Daftar contoh grafik berikut mungkin ada di dasbor Anda untuk membantu memecahkan masalah. Responden insiden harus dapat melihatnya dalam satu tampilan:
- Indikator tingkat layanan, seperti permintaan yang berhasil dibagi dengan total permintaan yang valid
- Konfigurasi dan peluncuran biner
- Permintaan per detik ke sistem
- Respons error per detik dari sistem
- Permintaan per detik dari sistem ke dependensi-dependensinya
- Respons error per detik ke sistem dari dependensi-dependensinya
Grafik umum lainnya untuk membantu memecahkan masalah mencakup latensi, saturasi, ukuran permintaan, ukuran respons, biaya kueri, penggunaan kumpulan thread, dan metrik Java virtual machine (JVM) (jika berlaku). Saturasi mengacu pada kapasitas penuh oleh beberapa batas, seperti kuota atau ukuran memori sistem. Penggunaan kumpulan thread mencari regresi karena kehabisan kumpulan.
Uji penempatan grafik ini terhadap beberapa skenario pemadaman layanan untuk memastikan bahwa grafik yang paling penting berada di dekat bagian atas, dan urutan grafik sesuai dengan alur kerja diagnostik standar Anda. Anda juga dapat menerapkan machine learning dan deteksi anomali statistik untuk menampilkan subset yang tepat dari grafik ini.
Mendokumentasikan prosedur diagnostik dan mitigasi untuk skenario gangguan yang diketahui
Tulis playbook dan link ke playbook tersebut dari notifikasi pemberitahuan. Jika dokumen ini dapat diakses dari notifikasi pemberitahuan, operator bisa dengan cepat mendapatkan informasi yang diperlukan untuk memecahkan dan mengurangi masalah.
Gunakan postmortem blameless untuk belajar dari gangguan dan mencegah pengulangan
Membangun budaya postmortem blameless dan proses peninjauan insiden. Blameless berarti tim Anda mengevaluasi dan mendokumentasikan kesalahan secara objektif, tanpa perlu menyalahkan.
Kesalahan adalah peluang untuk belajar, bukan alasan untuk dikritik, Selalu berupaya untuk membuat sistem lebih tangguh sehingga dapat pulih dengan cepat dari kesalahan manusia, atau bahkan lebih baik lagi, mendeteksi dan mencegah kesalahan manusia. Ekstrak sebanyak mungkin pembelajaran dari setiap postmortem dan tindak lanjuti dengan cermat setiap item tindakan postmortem untuk mengurangi frekuensi gangguan, sehingga meningkatkan TBF.
Contoh rencana manajemen insiden
Masalah produksi telah terdeteksi, melalui pemberitahuan atau halaman, atau dilaporkan kepada saya:
- Haruskah saya mendelegasikan kepada orang lain?
- Ya, jika Anda dan tim Anda tidak dapat menyelesaikan masalah tersebut.
- Apakah masalah ini merupakan pelanggaran privasi atau keamanan?
- Jika ya, delegasikan ke tim privasi atau keamanan.
- Apakah masalah ini bersifat darurat atau apakah SLO berisiko?
- Jika ragu, perlakukan hal ini sebagai keadaan darurat.
- Haruskah saya melibatkan lebih banyak orang?
- Ya, jika masalah memengaruhi lebih dari X% pelanggan atau jika penyelesaian masalah memerlukan waktu lebih dari Y menit. Jika ragu, selalu libatkan lebih banyak orang, terutama dalam jam kerja.
- Menentukan saluran komunikasi utama, seperti IRC, Hangouts Chat, atau Slack.
- Delegasikan peran yang telah ditentukan sebelumnya, seperti berikut:
- Komandan insiden yang bertanggung jawab atas koordinasi keseluruhan.
- Pemimpin komunikasi yang bertanggung jawab atas komunikasi internal dan eksternal.
- Pemimpin operasi yang bertanggung jawab untuk mengurangi masalah.
- Tentukan kapan insiden berakhir. Keputusan ini mungkin memerlukan konfirmasi dari perwakilan dukungan atau tim serupa lainnya.
- Berkolaborasilah dalam postmortem tanpa menyalahkan.
- Menghadiri rapat peninjauan insiden postmortem untuk mendiskusikan dan mengelola item tindakan.
Rekomendasi
Untuk menerapkan panduan dalam Framework Arsitektur ke lingkungan Anda sendiri, ikuti rekomendasi berikut:
- Membuat rencana manajemen insiden, dan melatih tim Anda untuk menggunakannya.
- Untuk mengurangi TTD, terapkan rekomendasi untuk membangun kemampuan observasi ke dalam infrastruktur dan aplikasi Anda.
- Membuat dasbor "Apa yang berubah?" yang dapat Anda lihat sekilas ketika terjadi suatu insiden.
- Dokumentasikan cuplikan kueri atau buat dasbor Looker Studio dengan kueri log yang sering digunakan.
- Evaluasi Firebase Remote Config untuk memitigasi masalah peluncuran aplikasi seluler.
- Uji pemulihan kegagalan, termasuk memulihkan data dari cadangan, untuk mengurangi TTM sebagian insiden Anda.
- Desain dan uji konfigurasi serta rollback biner.
- Replikasi data di seluruh region untuk pemulihan dari bencana dan gunakan uji pemulihan dari bencana untuk mengurangi TTM setelah pemadaman layanan regional.
- Desain arsitektur multi-region untuk ketahanan terhadap pemadaman layanan regional jika kebutuhan bisnis akan ketersediaan tinggi sesuai biaya, untuk meningkatkan TBF.
Langkah selanjutnya
Pelajari lebih lanjut cara membangun proses manajemen insiden kolaboratif dengan referensi berikut:
- Dasbor Status Google Cloud
- Manajemen insiden di Google
- Proses respons insiden data
- Bab buku SRE tentang pengelolaan insiden
Pelajari kategori lainnya dalam Framework Arsitektur seperti desain sistem, keunggulan operasional, serta keamanan, privasi, dan kepatuhan.