Perjelas arti keputusan
Server bisa sehat sementara pekerjaan pelanggan macet. Pantau hasil yang harus dihasilkan aplikasi bersama kegagalan teknis. Untuk alur penting, tetapkan pemicu, keadaan perantara permanen, dan bukti penyelesaian. Jarak antarkeadaan sering menjelaskan masalah yang luput dari jumlah kesalahan.
Peran dan alternatif
Mulai dengan sedikit sinyal yang bisa ditindaklanjuti. Ketersediaan dan respons menggambarkan aplikasi; usia tugas tertua, kegagalan selesai, dan tidak adanya peristiwa yang diharapkan menggambarkan proses. Google SRE membedakan gejala dan penyebab. Prioritaskan gejala yang dirasakan pelanggan, lalu selidiki detail teknis.
Telusuri perubahan
Dalam contoh penawaran, formulir menyimpan permintaan dan mengantrekan notifikasi. Web berhasil, tetapi worker email berhenti. Perhatikan usia notifikasi tertua yang belum dikirim. Peringatan menyebut antrean, pemeriksaan aman, dan kapan mencoba ulang. Pemulihan terbukti saat tugas tertunda terkirim tanpa kehilangan atau menggandakan permintaan.
Periksa jalur kegagalan
Dasbor sepi bisa berarti tanpa permintaan, pengumpul data rusak, atau pintu masuk macet. Bedakan semuanya. Hindari peringatan tanpa pemilik atau tindakan serta pesan pribadi dalam muatannya. Hentikan worker lokal atau simulasikan ketergantungan gagal untuk menguji peringatan dan pemulihan.
Berikan respons praktis untuk setiap peringatan
Jelaskan pekerjaan pelanggan tertunda, bukan hanya nama proses. Sertakan antrean, usia item tertua, waktu pengamatan, serta jalur inspeksi berizin. Hindari isi pesan pribadi. Penanggap perlu membedakan worker berhenti dari layanan email gagal tanpa semua detail pelanggan.
Tentukan tindakan aman. Panduan memeriksa kesehatan, kegagalan tersanitasi terakhir, serta status dicadangkan atau selesai. Jelaskan kapan ulang, ambil lease kedaluwarsa, atau eskalasi. Mengulang semua bisa menduplikasi tindakan eksternal selesai yang responsnya hilang. Bila tidak pasti, catat dan cocokkan, jangan buat keberhasilan semu.
Uji seluruh jalur secara terkendali: hentikan worker, buat permintaan fiktif, amati antrean. Pastikan peringatan tiba ke penerima lokal, pulihkan dan periksa penyelesaian serta pemulihan. Uji pengumpul juga; pengamatan berhenti tidak boleh tampak seperti antrean kosong sehat. Setelah insiden, hapus kebisingan ganda, perbaiki pemilik dan diagnosis awal. Jangan menekan gejala karena sudah terbiasa.
Daftar tinjauan operasi
| Pertanyaan | Bukti berguna |
|---|---|
| Tanpa pekerjaan atau tanpa ukuran? | Pengamatan sukses terakhir terlihat terpisah dari jumlah tertunda. |
| Peringatan punya pemilik? | Peran tertentu tahu waktu respons, inspeksi, dan eskalasi. |
| Pemulihan sungguh selesai? | Pekerjaan mencapai hasil bisnis; restart proses saja tidak menutup insiden. |
| Bisakah percobaan menggandakan efek? | Panduan memeriksa bukti selesai dan memperlakukan hasil eksternal ambigu sebagai rekonsiliasi. |
Sepakati aturan ini
Apa arti berhasil? Berapa lama tugas boleh menunggu? Siapa menerima peringatan dan apa tindakan amannya? Peninjauan sebaiknya menghasilkan peta operasi ringkas, bukan tembok metrik yang tidak digunakan.