Dziiiiin! Saat itu jam 3 pagi, kamu bermimpi indah, dan tiba-tiba ada telepon. Anda sedang bertugas minggu ini, dan tampaknya sesuatu telah terjadi. Sistem otomatis memanggil untuk mencari tahu apa yang salah. Ini adalah aspek penting dalam mengelola sistem komputer modern, namun mari kita lihat cara membuat notifikasi lebih baik bagi orang-orang.
Kenali filosofi pemantauan, yang lahir selama beberapa dekade dari tugas saya di tim pemantauan yang berbeda. Dia sangat dipengaruhi oleh Alkitab asli dari Rob Evashchuk (Filosofi Pemberitahuan Saya) termasuk dalam buku tentang , dan buku oleh John Alspaugh (Catatan tentang pengaturan peringatan).
, и — terima kasih atas bantuan Anda dalam mengedit postingan.
Apa itu KASUS?
Saya memutuskan untuk membuat singkatan yang indah seperti или . Saya menyebutnya metode KASUS. Dia menjelaskan empat hal yang perlu diperhatikan ketika bekerja dengan pemantauan otomatis:
- (terikat konteks)
- (nilai praktis)
- (penekanan pada gejala)
- (nilai)
Jika Anda menggunakan CASE, Anda memperlakukan notifikasi dengan ketidakpedulian yang sehat dan tidak membangunkan orang di malam hari. Pemantauan harus dinilai secara berkala untuk mengetahui kegunaan dan efektivitasnya. Ketika seseorang menerima pemberitahuan tersebut, mereka akan memiliki model mental yang lebih baik dan lebih percaya diri.
Agar lebih mudah mengingatnya, bayangkan Anda memerlukan KASUS [yaitu, kasus, alasan - catatan penerjemah] untuk membenarkan setiap peringatan. :kacamata hitam:
Dan mengapa semua ini terjadi?
. Untuk banyak alasan. Dan CASE tidak akan menghilangkan semuanya. Namun dengan itu, Anda akan bangun di malam hari untuk mendapatkan notifikasi yang lebih baik. Metode ini mencakup berbagai proses organisasi yang juga akan membantu dalam hal ini.
Keindahan metode RED dan USE adalah dengan bantuannya kita tidak hanya mengetahui cara bekerja, tetapi juga berbicara dalam bahasa yang sama satu sama lain. Harapan saya adalah metode CASE akan mempermudah pembahasan notifikasi yang melindungi sistem kita namun tetap membuat rekan kerja kita sibuk.
Intinya adalah Anda perlu menciptakan budaya di organisasi Anda di mana notifikasi diperlakukan dengan ketidakpedulian yang sehat. Pemberitahuan dapat dibuat untuk tujuan tertentu, tetapi bukan fakta bahwa pemberitahuan tersebut tidak akan kehilangan nilainya di kemudian hari. Mengapa kami menyiapkan notifikasi ini? Sudah berapa lama kriterianya direvisi? Dengan CASE, pertanyaan-pertanyaan ini dapat dijawab.
Konteks-Berat - pengikatan konteks
Jam 3 pagi bukanlah waktu terbaik untuk membaca pesan yang banyak mengandung kata-kata cerdas. Untuk merespons secara efektif, Anda memerlukan informasi. Idealnya, ini harus berupa informasi tentang masalah tertentu, yang konteksnya jelas, dan pemberitahuan harus dikonfigurasi sehingga hal ini dapat dilakukan. Ini adalah "observasi" dan "orientasi" dari . Tidaklah sayang untuk menghabiskan waktu pada pengaturan ini, karena terus-menerus mengalihkan perhatian seseorang bahkan lebih mahal. Mari kita saling menghormati.
Masalah mempunyai banyak sumber. Terutama hantu.
Bagaimana saya bisa membantu petugas jaga? Hal pertama yang dilihat petugas jaga adalah pemberitahuan, jadi dia membangun semua hipotesis berdasarkan pemberitahuan tersebut. Lalu dia melihat instruksi dan dashboard, tapi apakah selalu ada data tentang notifikasi tertentu, dan bukan hanya informasi umum? Alspaugh menyarankan “memikirkan bagaimana Anda dapat menafsirkan atau menanggapi pemberitahuan” (slide 29). Notifikasi yang baik difokuskan pada orang yang bertugas, bukan hanya dikonfigurasikan berdasarkan ambang batas.
Berikut beberapa ide tentang cara meningkatkan konteks notifikasi:
- Tunjukkan kepada pengguna sesuatu yang berguna dan dibuat khusus, dan bukan sekadar instruksi atau dasbor biasa. Sebelumnya, saya dan teman-teman menggunakan dasbor investigasi yang dikonfigurasi untuk pemberitahuan tertentu. Ini akan membantu jika masalahnya diketahui, namun hanya akan membingungkan orang lain. Kita perlu menemukan keseimbangan di sini.
- Beritahu kami tentang riwayat pemberitahuan tersebut: apakah ini baru? Apakah ini sering berhasil? Apakah ini musiman?
- Tampilkan perubahan terkini pada status sistem. Apakah ada yang berubah akhir-akhir ini? (Misalnya, penerapan atau mengaktifkan/menonaktifkan fungsionalitas.)
- Tunjukkan hubungan dan berikan informasi untuk model mental: ketergantungan sistem harus terlihat jelas, sebaiknya dengan indikasi fungsionalitas.
- Hubungkan pengguna dengan tim dengan cepat: dapatkah mereka melihat insiden yang sedang berlangsung atau dapatkah mereka mengetahui siapa saja di perusahaan yang telah menerima pemberitahuan? Program diaktifkan?
Idealnya, program manajemen insiden akan memberikan saran tentang cara meningkatkan konteks pemberitahuan investigasi insiden. Selalu ada sesuatu untuk dikerjakan!
Dapat ditindaklanjuti - nilai praktis
Haruskah petugas jaga melakukan sesuatu sebagai tanggapan atas pemberitahuan tersebut? Jika Anda tidak perlu melakukan apa pun atau tidak jelas harus berbuat apa, mengapa Anda membangunkannya? Anda perlu menghindari pemberitahuan yang mengganggu petugas dan tidak memerlukan tindakan.
Apa yang harus saya lakukan? Apa yang kamu inginkan?
Di masa lalu, ketika sistem masih sederhana dan jumlah tim masih kecil, kami menyiapkan pemantauan hanya untuk terus memantau perkembangan. Pemberitahuan bahwa beban pada heap telah meningkat akan memberi kita konteks jika layanan kemudian mengalami malfungsi. Dalam skala besar, pemberitahuan seperti itu hanya akan menimbulkan kebingungan karena sistem kami selalu beroperasi dalam kondisi degradasi dengan tingkat keparahan yang berbeda-beda. Hal ini dengan cepat mengarah ke dan, tentu saja, hilangnya kepekaan. Oleh karena itu, petugas jaga mengabaikan atau bahkan memfilter pemberitahuan tersebut dan tidak selalu menanggapinya sesuai kebutuhan. Jangan jatuh ke dalam perangkap ini! Jangan mengatur semua notifikasi secara berurutan lalu mengirimkannya melalui email ke folder terkutuk.
Berikut tampilan pemberitahuan yang memiliki nilai praktis:
- Pemberitahuan memerlukan tindakan, bukan sekadar melaporkan berita.
- Tindakan ini sulit atau berisiko untuk diotomatisasi. Jika suatu tindakan dapat diotomatisasi, maka otomatiskanlah, berhentilah mengganggu orang!
- Pemberitahuan tersebut berisi rekomendasi mendesak dalam bentuk (SLA) atau (RTO). Petugas jaga kemudian dapat mengaktifkan program manajemen insiden organisasi.
Saya ingin mengklarifikasi: Saya tidak mengatakan bahwa notifikasi hanya boleh datang untuk SLO (tujuan tingkat layanan) yang paling penting untuk API. Pemantauan SLO terus-menerus terfragmentasi dan terpecah serta memerlukan pendekatan yang sama untuk semua layanan. Jelas bahwa Anda akan melacak SLO terpenting untuk klien yang membayar Anda. Namun SLO infrastruktur, seperti database, juga perlu dipantau. Anda akan segera harus berurusan dengan pelanggan internal dan mendukung mereka. Dan seterusnya tanpa batas.
Berbasis gejala - penekanan pada gejala
Suka atau tidak suka, Anda bekerja dalam sistem terdistribusi (Kavaj). Akibatnya, Anda menggunakan taktik berbeda untuk mengisolasi layanan dan melindunginya dari kegagalan (Trainor et al.)3. Dan meskipun pengumpulan sampah yang tertunda atau permintaan database yang terhenti menunjukkan adanya masalah, tidak perlu terburu-buru memperbaikinya jika pengguna tidak mengalami masalah dalam waktu dekat.
Ini adalah sinyal penting dan mungkin memiliki nilai praktis, namun jika tidak mengganggu pengguna, maka hal tersebut tidak cukup mendesak untuk mengalihkan perhatian petugas. Pemberitahuan berbasis penyebab adalah gambaran model mental kita tentang kegagalan sistem. Lebih baik melacak gejala-gejala penting daripada mencoba membuat daftar semua kemungkinan penyebab kegagalan.
Untuk membuat notifikasi bermakna, fokuslah pada , penting bagi pengguna. Evashchuk menyebutnya sebagai “pemantauan untuk pengguna.” Ingatlah bahwa filosofi ini harus diterapkan di seluruh organisasi. Jika suatu layanan memiliki masalah mendesak di suatu tempat jauh di dalam infrastruktur, tim yang tepat akan menanganinya. Melindungi sistem dari kegagalan semacam itu adalah masalah yang berbeda (Trainer dkk., bagian tentang strategi untuk meminimalkan ketergantungan kritis).
Gejalanya tidak bervariasi
Richard Cook mengingatkan kita bahwa sistem yang kompleks penuh dengan kekurangan, kekurangan dan masalah. Mencoba membuat daftar semua kemungkinan alasan adalah tugas Sisyphean. Anda mencoba menggambarkan masalah, tetapi masalah itu berubah setiap saat. Cindy Sridharan percaya bahwa “sistem tidak harus berada dalam kondisi sempurna setiap detiknya” dan lebih baik menggunakan pendekatan yang lebih manusiawi ( (“Pemantauan Sistem Terdistribusi”), 7).
Hindari pemberitahuan setelah kejadian
Biasanya, pemberitahuan penyebab dikonfigurasi untuk memperbaiki insiden. Dan pemberitahuan terbatas tentang fakta tentang apa yang terjadi menciptakan rasa aman yang salah, karena sistem selalu menemukan cara baru untuk menerobos.
Jangan tertipu oleh pemberitahuan sebab akibat. Lebih baik pikirkan:
- Mengapa pemberitahuan berdasarkan gejala tidak mengetahui masalahnya?
- Apakah akan membantu jika meningkatkan konteks bagi pengguna?
- Bagaimana cara meningkatkan alat pemantauan untuk membuat diagnosis lebih cepat, daripada mengumpulkan pemberitahuan tentang apa yang terjadi?
Alat pemantauan untuk diagnosis hanya akan membantu jika Anda menganggapnya sebagai cara untuk beralih dari gejala ke solusi. Tanpa umpan balik ini, Anda hanya akan dibombardir dengan pemberitahuan dan grafik yang terlambat tentang kegagalan di masa lalu—dan tidak ada kabar tentang kegagalan di masa depan. Ini adalah peluang besar bagi organisasi untuk beralih dari bertahan ke menyerang. Dan pengembang serta manajer produk akan memiliki ekspektasi dan tujuan yang jelas yang sama. Kasus - CASE (:wink:) - jelas untuk setiap notifikasi.
Pemberitahuan berdasarkan alasan dapat ditoleransi dalam jumlah sedang
Terkadang sistem kami memberi kami sedikit pilihan dalam hal pemberitahuan berdasarkan penyebab. Dan terkadang mereka yang bertugas memahami betul bahwa suatu gejala pasti akan berujung pada kegagalan, dan oleh karena itu mengandung nilai praktis. Mungkin Anda tidak yakin dengan apa yang terjadi dan sedang menyiapkan notifikasi agar aman. Semoga tindakan ini bersifat sementara hingga kami dapat mengubah sistem untuk menyelesaikan masalah kinerja.
Ingatlah komponen CASE yang lain ketika menghadapi situasi ini. Hanya karena ini hanya sementara bukan berarti Anda bisa berhenti berpikir keras.
Dievaluasi - evaluasi
Setiap perubahan pada sistem (kode baru, infrastruktur baru, segala sesuatu yang baru) memperluas jangkauan kegagalan (Cook, 3). Apakah notifikasi ini masih berfungsi sebagaimana mestinya? Model mental sistem dan pengalaman yang jelas dan terkini dalam menanggapi beberapa pemberitahuan dukungan - ini adalah fitur utamanya . Cacat dalam sistem terus berkembang, dan kita harus mengimbanginya.
Anda harus terus mengevaluasi kualitas setiap notifikasi untuk memastikannya berfungsi sesuai harapan. Para pemimpin yang terhormat! Akan lebih mudah bagi tim Anda jika Anda membantu mereka membangun proses ini! Berikut adalah beberapa ide penilaian:
- Gunakan , atau metode pengujian notifikasi lainnya. Tim dapat melakukannya sendiri tanpa harus bergantung pada sistem manajemen insiden yang berat!
- Gabungkan kumpulan semua pemberitahuan terkait insiden ke dalam program manajemen insiden Anda. Tandai berguna, berbahaya, tidak pantas, tidak jelas, dll. Gunakan hal tersebut sebagai umpan balik.
- Notifikasi yang tepat jarang dipicu dan diuji dengan cermat. Pastikan semua tautan berfungsi, arahkan ke konteks yang benar, dll.
- Jika notifikasi tidak pernah terpicu atau terlalu sering terpicu, berarti ada yang salah dengan notifikasi tersebut. Perbaiki atau hapus. Waspadai kepasifan atau aktivitas berlebihan!
- Tetapkan stempel waktu pemberitahuan dengan tanggal kedaluwarsa. Jika tanggal kedaluwarsa telah kedaluwarsa, evaluasi notifikasi menggunakan metode CASE dan perbarui stempel waktunya. Sama seperti makanan, periksa tanggal kadaluwarsanya secara rutin.
- Sederhanakan proses peningkatan notifikasi. Gunakan pemantauan sebagai kode dan simpan notifikasi di repositori Git. Permintaan tarik membantu melibatkan tim dan memberi Anda riwayat pemberitahuan sebelumnya. Dan Anda tidak lagi takut untuk mengubah notifikasi atau meminta izin dari pihak yang bertanggung jawab.
- Siapkan masukan untuk notifikasi, meskipun sederhana , sehingga petugas jaga menandai pemberitahuan sebagai tidak berguna atau mengganggu. Sematkan tautan atau ajakan bertindak ke dalam notifikasi itu sendiri dan tinjau masukan Anda secara berkala.
- Tetapkan aturan dalam tim - biarkan mereka yang bertugas bekerja untuk menyederhanakan tugas ketika ada sedikit pekerjaan. Semoga segalanya setelah Anda menjadi sedikit lebih baik dari sebelumnya.
Kesimpulan
Saya yakin metode CASE membantu pengembang dan organisasi mendiskusikan penyiapan dan pengiriman notifikasi otomatis. Satu pengembang dapat mulai menilai notifikasi menggunakan metode CASE, lalu seluruh organisasi akan bergabung dengan pengembang lain, manajemen, dan program manajemen insiden untuk menjaga notifikasi tetap dalam kondisi yang baik. Ini tidak memerlukan alat khusus atau proses yang rumit.
Seluruh industri perlu memikirkan faktor manusia saat bertugas tanpa mengorbankan layanan pelanggan terbaik. Semua alat dan praktik ini dapat dan harus ditingkatkan. Saya harap metode CASE akan membantu dalam hal ini.
Nikmati notifikasi yang ditingkatkan!
Sumber: www.habr.com