Dziiiiiiin! Pada jam 3 pagi, Anda menonton mimpi indah, dan tiba-tiba - sebuah bel. Minggu ini Anda bertugas, dan ternyata sesuatu terjadi. Sistem otomatis memanggil untuk mencari tahu apa masalahnya. Ini adalah poin penting dalam mengelola sistem komputer modern, tetapi mari kita lihat bagaimana membuat notifikasi lebih nyaman bagi orang.
Berkenalan dengan filosofi pemantauan yang lahir selama beberapa dekade tugas saya di berbagai tim pemantauan. Itu sebagian besar dipengaruhi oleh Alkitab yang sebenarnya dari Rob Evashchuk My Philosophy on Alerting , termasuk dalam buku Google SRE , dan buku John Alspo, Pertimbangan untuk Alert Design .
Kelly Dunn , Aridzhit Mukheryi dan Maxim Petazzoni - terima kasih atas bantuannya dalam mengedit posting.
Apa itu KASUS?
Saya memutuskan untuk membuat akronim yang indah seperti metode USE Brendan Gregg atau metode RED Tom Wilkie . Saya menyebutnya metode KASUS . Dia menjelaskan empat poin yang perlu Anda perhatikan ketika bekerja dengan pemantauan otomatis:
Jika Anda menggunakan CASE, Anda memperlakukan pemberitahuan dengan ketidakpedulian yang sehat dan tidak membangunkan orang di malam hari. Pemantauan harus dievaluasi secara berkala untuk utilitas dan efektivitas. Ketika seseorang menerima pemberitahuan, ia akan memiliki model mental yang lebih baik dan lebih percaya diri.
Untuk membuatnya lebih mudah diingat, bayangkan Anda membutuhkan KASUS [yaitu, kasus, alasannya adalah komentar juru bahasa ] untuk membenarkan setiap peringatan. : kacamata hitam:
Dan mengapa hanya itu?
Tugas bisa menjadi siksaan . Karena banyak alasan. Dan KASUS tidak akan menghilangkan semuanya. Tetapi dengan itu di malam hari Anda akan bangun dari notifikasi yang lebih baik. Metode ini mencakup berbagai proses organisasi yang juga akan membantu dalam hal ini.
Keindahan metode RED dan USE adalah bahwa dengan bantuan mereka, kami tidak hanya tahu cara bekerja, tetapi kami juga berbicara bahasa yang sama satu sama lain. Saya berharap bahwa dengan metode CASE akan lebih mudah untuk membahas pemberitahuan yang melindungi sistem kami, tetapi jangan memberi istirahat kepada kolega.
Intinya adalah bahwa Anda perlu menciptakan budaya di organisasi tempat notifikasi diperlakukan dengan ketidakpedulian yang sehat. Pemberitahuan dapat dibuat dalam kasus ini, tetapi bukan fakta bahwa mereka tidak akan kehilangan nilainya nanti. Mengapa kami mengatur pemberitahuan ini? Apakah kriterianya sudah lama direvisi? Dengan CASE, pertanyaan-pertanyaan ini dapat dijawab.
Konteks-Berat - pengikatan konteks
Jam 3 pagi bukan waktu terbaik untuk membaca pesan yang memiliki banyak kata kunci. Untuk merespons secara efektif, Anda memerlukan informasi. Idealnya, ini harus berupa informasi tentang masalah tertentu, yang konteksnya segera jelas, dan Anda perlu mengonfigurasi pemberitahuan sehingga memungkinkan. Ini adalah "pengamatan" dan "orientasi" dari siklus NORD . Sayang sekali untuk menghabiskan waktu pada pengaturan ini, karena terus-menerus mengganggu seseorang bahkan lebih mahal. Mari kita saling menghormati.
Masalah memiliki banyak sumber. Terutama hantu.
Bagaimana cara membantu petugas? Petugas jaga melihat pemberitahuan terlebih dahulu, jadi dia membangun semua hipotesis berdasarkan itu. Lalu dia melihat instruksi dan dashboard, tetapi apakah selalu ada informasi tentang pemberitahuan tertentu, dan bukan hanya informasi umum? Alspo menyarankan "untuk memikirkan bagaimana menafsirkan pemberitahuan atau meresponsnya" (slide 29) 1 . Notifikasi yang baik difokuskan pada petugas, dan tidak hanya dikonfigurasi pada nilai ambang batas.
Karenanya, berikut adalah ide untuk meningkatkan konteks pemberitahuan:
- Tunjukkan pada pengguna sesuatu yang bermanfaat dan dibuat khusus, dan bukan hanya instruksi biasa atau dasbor. Sebelumnya, saya dan orang-orang menggunakan dasbor untuk menyelidiki, dikonfigurasi untuk pemberitahuan khusus. Ini akan membantu jika masalahnya diketahui, dan hanya membingungkan dalam kasus lain. Di sini Anda perlu menemukan keseimbangan.
- Beri tahu kami tentang riwayat pemberitahuan: apakah ini baru? Apakah ini sering berhasil? Apakah ini musiman?
- Tampilkan perubahan terbaru dalam status sistem. Apakah ada yang berubah baru-baru ini? (Misalnya, gunakan atau aktifkan / nonaktifkan fungsionalitas.)
- Tunjukkan hubungan dan berikan informasi untuk model mental: ketergantungan sistem harus terlihat jelas, lebih disukai dengan indikasi operabilitas.
- Dengan cepat mengaitkan pengguna dengan tim: apakah dia melihat insiden saat ini atau dapatkah dia mencari tahu siapa lagi di perusahaan yang menerima pemberitahuan? Apakah program manajemen insiden diaktifkan?
Idealnya, program manajemen insiden memberikan kiat tentang cara meningkatkan konteks pemberitahuan saat menyelidiki insiden. Selalu ada sesuatu untuk dikerjakan!
Dapat ditindaklanjuti - nilai praktis
Haruskah petugas melakukan sesuatu sebagai tanggapan terhadap pemberitahuan? Jika tidak ada yang perlu dilakukan atau tidak jelas apa yang harus dilakukan, mengapa Anda dibangunkan? Hal ini diperlukan untuk menghindari pemberitahuan yang bertugas dan tidak memerlukan tindakan.
Apa yang harus dilakukan Apa yang kamu butuhkan
Sebelumnya, ketika sistemnya sederhana dan timnya kecil, kami mengatur pemantauan agar tetap terkini. Pemberitahuan bahwa beban pada heap telah meningkat akan memberi kita konteks jika layanan mengalami kegagalan fungsi. Dalam skala besar, pemberitahuan semacam itu hanya akan membingungkan, karena sistem kami selalu bekerja dalam kondisi degradasi dengan tingkat keparahan yang berbeda-beda. Ini dengan cepat menyebabkan kelelahan karena pemberitahuan dan, tentu saja, hilangnya kepekaan. Oleh karena itu, petugas mengabaikan atau bahkan menyaring pemberitahuan tersebut dan tidak selalu menanggapinya sesuai kebutuhan. Jangan jatuh ke dalam perangkap ini! Jangan mengonfigurasikan semua notifikasi secara berturut-turut, sehingga nanti Anda dapat mengirimkannya melalui pos ke beberapa folder terkutuk.
Begini tampilannya dengan nilai praktis:
- Pemberitahuan membutuhkan tindakan, bukan hanya melaporkan berita.
- Tindakan ini sulit atau berisiko untuk diotomatisasi. Jika tindakan dapat diotomatisasi, maka ambil dan otomatisasi, hentikan mengganggu orang!
- Pemberitahuan tersebut berisi rekomendasi mendesak dalam bentuk perjanjian tingkat layanan (SLA) atau waktu pemulihan target (RTO). Kemudian petugas dapat menggunakan program manajemen insiden di organisasi.
Saya ingin mengklarifikasi: Saya tidak mengatakan bahwa pemberitahuan harus datang hanya pada SLO yang paling penting (sasaran tingkat layanan, sasaran tingkat layanan) untuk API. Pemantauan SLO secara konstan terfragmentasi dan terbagi dan membutuhkan pendekatan yang sama untuk semua layanan. Jelas bahwa Anda akan melacak SLO paling penting bagi pelanggan yang membayar Anda. Tetapi infrastruktur SLO, seperti database, juga perlu dipantau. Segera Anda harus berurusan dengan pelanggan internal dan mendukung mereka. Demikian seterusnya ad infinitum.
Berbasis gejala - fokus pada gejala
Suka atau tidak, Anda bekerja di sistem terdistribusi (Kavaj) 2 . Akibatnya, Anda menggunakan taktik yang berbeda untuk mengisolasi layanan dan melindunginya dari kegagalan (Trainor et al.) 3. Dan meskipun pengumpulan sampah yang berlarut-larut atau permintaan yang cermat ke database menunjukkan masalah, tidak perlu terburu-buru untuk memperbaikinya jika pengguna tidak memiliki masalah dalam waktu dekat.
Ini adalah sinyal penting, dan mereka bisa bernilai praktis, tetapi jika mereka tidak mengganggu pengguna, maka ini tidak begitu mendesak untuk mengalihkan perhatian petugas. Pemberitahuan berbasis sebab adalah snapshot dari model mental kegagalan sistem kami. Lebih baik melacak gejala-gejala penting daripada mencoba membuat daftar semua kemungkinan penyebab kegagalan.
Agar notifikasi bernilai praktis, fokuskan pada indikator kinerja yang penting bagi pengguna. Evashchuk menyebut ini "pemantauan untuk pengguna." Ingatlah bahwa filosofi ini perlu diterapkan di seluruh organisasi. Jika layanan memiliki masalah mendesak di suatu tempat jauh di dalam infrastruktur, tim yang sesuai akan menanganinya. Melindungi sistem dari kegagalan tersebut adalah masalah yang benar-benar terpisah (Trainer et al., Bagian strategi untuk meminimalkan ketergantungan kritis) 3 .
Gejalanya tidak begitu mudah menguap
Richard Cook ingat bahwa dalam sistem yang kompleks ada banyak kekurangan, kekurangan dan masalah 4 . Mencoba membuat daftar semua penyebab yang mungkin terjadi - persalinan Sisyphean. Anda mencoba menggambarkan masalahnya, dan mereka berubah setiap saat. Cindy Sridharan percaya bahwa "sistem tidak harus dalam kondisi sempurna setiap detik" dan lebih baik menggunakan pendekatan yang lebih manusiawi ( "Sistem Terdistribusi Observability" , 7) 5 .
Hindari pemberitahuan insiden
Biasanya, pemberitahuan untuk alasan dikonfigurasi untuk memperbaiki insiden. Dan pemberitahuan terbatas tentang fakta yang terjadi ini menciptakan rasa percaya diri yang salah, karena setiap kali sistem muncul dengan cara baru untuk memecah.
Jangan terkecoh dengan pemberitahuan alasan. Berpikir Lebih Baik:
- Mengapa notifikasi berbasis gejala tidak memperhatikan masalah?
- Apakah akan bermanfaat untuk meningkatkan konteks bagi pengguna?
- Bagaimana cara meningkatkan alat pemantauan untuk mendiagnosis lebih cepat dan tidak mengumpulkan pemberitahuan tentang apa yang terjadi?
Alat pemantauan untuk diagnosis hanya akan membantu jika Anda menggunakannya sebagai cara untuk beralih dari gejala ke solusi. Tanpa umpan balik ini, Anda hanya akan kewalahan dengan notifikasi dan diagram yang terlambat tentang kegagalan masa lalu - dan tidak sepatah kata pun tentang yang akan datang. Untuk sebuah organisasi, ini adalah peluang besar untuk beralih dari pertahanan ke serangan. Dan pengembang dan manajer produk akan memiliki harapan dan tujuan yang sama. Kasus - KASUS (: mengedipkan mata :) - untuk setiap pemberitahuan jelas.
Pemberitahuan berbasis toleransi moderat
Terkadang sistem kami hampir tidak memberi kami pilihan dalam hal pemberitahuan berdasarkan alasannya. Dan kadang-kadang petugas sangat menyadari bahwa gejala tentu akan menyebabkan kerusakan, yang berarti mengandung nilai praktis. Mungkin Anda tidak yakin apa yang sedang terjadi dan mengatur pemberitahuan untuk reasuransi. Semoga saja tindakan ini diperlukan sementara hingga kami mengubah sistem untuk menyelesaikan masalah penurunan kinerja.
Waspadai komponen KASUS lain saat menghadapi situasi seperti itu. Jika ini bersifat sementara, bukan berarti Anda tidak bisa berpikir dengan kepala.
Dievaluasi - Peringkat
Setiap perubahan dalam sistem (kode baru, infrastruktur baru, apa pun yang baru) memperluas rentang kegagalan (Cook, 3). 4 Apakah pemberitahuan ini masih berfungsi seperti yang diharapkan? Model dan pengalaman sistem mental yang jelas dan relevan menanggapi beberapa pemberitahuan untuk mendukung pendekatan pencegahan adalah fitur utama dari organisasi yang berorientasi pada pembelajaran . Cacat dalam sistem terus berkembang, dan kita harus mengikutinya.
Anda harus terus-menerus mengevaluasi kualitas setiap notifikasi sehingga berfungsi seperti yang diharapkan. Para pemimpin yang terhormat! Akan lebih mudah bagi tim Anda jika Anda membantu mereka mengatur proses ini! Berikut adalah beberapa ide untuk mengevaluasi:
- Gunakan teknik chaos , hari bermain game, atau metode pengujian pemberitahuan lainnya. Tim dapat melakukan ini sendiri tanpa menggunakan sistem manajemen insiden kelas berat!
- Sertakan pengumpulan data pada semua pemberitahuan insiden dalam program manajemen insiden. Tandai bermanfaat, berbahaya, tidak pantas, tidak bisa dipahami, dll. Gunakan sebagai umpan balik.
- Notifikasi yang benar jarang dan diperiksa dengan cermat. Pastikan semua tautan berfungsi, arahkan ke konteks yang benar, dan sebagainya.
- Jika pemberitahuan tidak pernah menyala atau terbakar terlalu sering, ada yang salah dengan itu. Perbaiki atau hapus. Waspadalah terhadap kepasifan atau aktivitas yang berlebihan!
- Tetapkan cap waktu kedaluwarsa untuk notifikasi. Jika tanggal kedaluwarsa telah lewat, evaluasi pemberitahuan menggunakan metode KASUS dan perbarui stempel waktu. Periksa tanggal kedaluwarsa secara teratur, seperti halnya makanan.
- Sederhanakan proses peningkatan notifikasi. Gunakan pemantauan dalam bentuk kode dan simpan notifikasi di repositori Git. Kumpulan permintaan membantu menarik tim, dan Anda akan memiliki riwayat pemberitahuan sebelumnya. Dan Anda akan berhenti takut untuk mengubah pemberitahuan atau meminta izin dari mereka yang bertanggung jawab untuk itu.
- Siapkan pemberitahuan umpan balik, meskipun itu hanya formulir Google , sehingga orang-orang yang bertugas menandai pemberitahuan sebagai tidak berguna atau mengganggu. Sematkan tautan atau ajakan bertindak dalam pemberitahuan itu sendiri dan secara teratur periksa umpan baliknya.
- Tetapkan aturan dalam tim - biarkan petugas bekerja untuk menyederhanakan tugas ketika ada sedikit pekerjaan. Biarkan semuanya menjadi sedikit lebih baik setelah Anda daripada sebelumnya.
Kesimpulan
Saya percaya metode CASE membantu pengembang dan organisasi mendiskusikan pengaturan dan mengirim pemberitahuan otomatis. Satu pengembang dapat mulai mengevaluasi notifikasi menggunakan metode CASE, dan kemudian seluruh organisasi akan bergabung dengannya dengan pengembang lain, program manajemen dan manajemen insiden untuk menjaga notifikasi dalam kondisi baik. Tidak diperlukan alat khusus atau proses rumit untuk ini.
Seluruh industri harus memikirkan faktor manusia saat bertugas tanpa mengorbankan layanan pelanggan kelas satu. Semua alat dan praktik ini dapat dan harus ditingkatkan. Saya harap metode KASUS membantu dengan ini.
Nikmati notifikasi yang ditingkatkan!
