Ambil tanggung jawab atas layanan setelah deployment

Tentukan layanan yang diandalkan pengguna

Deployment membuat perangkat lunak tersedia. Operasi menjaganya tetap berguna ketika pengguna, dependensi, traffic, dan persyaratan berubah. Pembuat kode tidak menghilangkan pekerjaan berkelanjutan ini.

Untuk ekspor pelanggan fiktif, pengguna memerlukan lebih dari halaman yang dapat diakses. Mereka memerlukan data yang diizinkan dalam format yang diminta dan waktu yang dapat diterima. Mereka juga memerlukan layanan yang mencegah akses ke data organisasi lain.

Tetapkan penanggung jawab sebelum rilis. Catat siapa yang merespons di luar jam kerja normal jika hal itu termasuk komitmen layanan. Pemasok dapat menjalankan sebagian pekerjaan, tetapi organisasi tetap memerlukan jalur keputusan dan komunikasi yang jelas.

Pilih sinyal yang mendukung tindakan

Service-level indicator, atau SLI, mengukur sifat perilaku layanan yang telah ditentukan. Service-level objective, atau SLO, menetapkan target indikator tersebut selama periode tertentu. Pilih target berdasarkan kebutuhan pengguna dan kemampuan operasi.

Panduan SRE Google menjelaskan pendekatan ini dan penggunaan error budget untuk keputusan keandalan. Jangan menyalin target layanan lain tanpa memeriksa maknanya. Panduan SLO, contoh kebijakan error budget.

Untuk ekspor, tentukan syarat permintaan yang memenuhi kriteria dan dianggap berhasil. Pisahkan penolakan yang diharapkan dari kegagalan sistem. Dokumentasikan pengecualian agar metrik tidak membaik hanya karena permintaan sulit disembunyikan.

Hindari mencatat seluruh ekspor dalam log untuk meningkatkan visibilitas. Kumpulkan informasi minimum yang diperlukan untuk mendiagnosis masalah dan lindungi aksesnya.

Siapkan respons insiden

Tentukan siapa yang mengoordinasikan, menyelidiki, dan berkomunikasi. Peran tersebut dapat digabung dalam tim kecil, tetapi tanggung jawab harus tetap jelas. Simpan catatan pengamatan dan tindakan.

Panduan respons insiden Google menekankan koordinasi dan komunikasi bersama mitigasi teknis. Perbaikan yang benar secara teknis masih dapat membuat pengguna tidak mendapat informasi atau beberapa petugas melakukan perubahan yang saling bertentangan. Respons insiden.

Agen dapat merangkum log atau membandingkan hipotesis dalam batas data yang disetujui. Agen tidak boleh memperoleh kewenangan produksi tanpa batas hanya karena insiden mendesak. Gunakan jalur eskalasi yang ditentukan untuk akses khusus.

Latih pemulihan dan danai pemeliharaan

Uji prosedur pemulihan dengan data fiktif yang mewakili penggunaan nyata. Identifikasi hal yang tidak dapat dibatalkan oleh rollback kode, termasuk data yang telah dihapus atau pesan yang telah dikirim. Catat waktu dan informasi yang diperlukan untuk memulihkan layanan.

Tetapkan tanggung jawab pekerjaan berkelanjutan: pembaruan dependensi, peninjauan akses, perpanjangan sertifikat jika berlaku, perubahan kapasitas, dan perbaikan dokumentasi. Layanan tanpa kapasitas pemeliharaan terus mengumpulkan kewajiban setelah anggaran peluncurannya berakhir.

Setelah insiden, pilih perbaikan yang mengatasi penyebab yang diamati. Hubungkan perbaikan dengan implementasi dan verifikasi. Ini melengkapi siklus hidup: bukti operasi mengubah hal yang ditentukan dan dibangun tim berikutnya.