Dziiiiiin! Sekarang pukul 3 pagi, anda sedang bermimpi indah, dan tiba-tiba ada panggilan. Anda bertugas minggu ini, dan nampaknya sesuatu telah berlaku. Sistem automatik memanggil untuk mengetahui apa yang salah. Ini merupakan aspek penting dalam mengurus sistem komputer moden, tetapi mari kita lihat cara membuat pemberitahuan lebih baik untuk orang ramai.
Berkenalan dengan falsafah pemantauan, yang lahir selama beberapa dekad tugas saya dalam pasukan pemantauan yang berbeza. Dia banyak dipengaruhi oleh bible sebenar dari Rob Evashchuk (Falsafah Pemberitahuan Saya) disertakan dalam buku pada , dan buku oleh John Alspaugh (Nota mengenai penyediaan makluman).
, ΠΈ β terima kasih atas bantuan anda dalam menyunting siaran.
Apakah CASE?
Saya memutuskan untuk menghasilkan singkatan yang indah seperti atau . Saya memanggilnya kaedah KES. Beliau menerangkan empat perkara yang perlu diberi perhatian apabila bekerja dengan pemantauan automatik:
- (terikat konteks)
- (nilai praktikal)
- (penekanan kepada gejala)
- (gred)
Jika anda menggunakan CASE, anda melayan pemberitahuan dengan sikap acuh tak acuh yang sihat dan tidak membangunkan orang pada waktu malam. Pemantauan harus selalu dinilai untuk kegunaan dan keberkesanan. Apabila seseorang menerima pemberitahuan, mereka akan mempunyai model mental yang lebih baik dan lebih yakin.
Untuk memudahkan ingatan, bayangkan anda memerlukan KES [iaitu, kes, sebab - nota penterjemah] untuk mewajarkan setiap makluman. :cermin mata hitam:
Dan mengapa semua ini?
. Atas pelbagai sebab. Dan CASE tidak akan menghapuskan kesemuanya. Tetapi dengan itu, anda akan bangun pada waktu malam untuk menerima pemberitahuan yang lebih baik. Kaedah ini merangkumi pelbagai proses organisasi yang juga akan membantu dalam perkara ini.
Keindahan kaedah RED dan USE ialah dengan bantuan mereka kita bukan sahaja tahu cara bekerja, tetapi juga bercakap bahasa yang sama antara satu sama lain. Harapan saya ialah kaedah CASE akan memudahkan untuk membincangkan pemberitahuan yang melindungi sistem kami tetapi membuat rakan sekerja kami sibuk.
Intinya ialah anda perlu mencipta budaya dalam organisasi anda di mana pemberitahuan dilayan dengan sikap acuh tak acuh yang sihat. Pemberitahuan boleh dibuat untuk tujuan tertentu, tetapi bukan fakta bahawa ia tidak akan kehilangan nilai kemudian. Mengapa kami menyediakan pemberitahuan ini? Berapa lama dahulu kriterianya telah disemak? Dengan CASE, soalan-soalan ini boleh dijawab.
Konteks-Berat - mengikat konteks
3 pagi bukanlah masa terbaik untuk membaca mesej yang mengandungi banyak perkataan pintar. Untuk bertindak balas dengan berkesan, anda memerlukan maklumat. Sebaik-baiknya, ini mestilah maklumat tentang isu tertentu, yang konteksnya jelas serta-merta, dan pemberitahuan harus dikonfigurasikan supaya ini dapat dilakukan. Ini adalah "pemerhatian" dan "orientasi" daripada . Ia tidak memalukan untuk meluangkan masa pada persediaan ini, kerana sentiasa mengalih perhatian seseorang adalah lebih mahal. Mari saling hormat menghormati.
Masalah mempunyai banyak sumber. Terutamanya hantu.
Bagaimanakah saya boleh membantu pegawai bertugas? Perkara pertama yang dilihat oleh pegawai bertugas ialah pemberitahuan, jadi dia membina semua hipotesis berdasarkannya. Kemudian dia melihat arahan dan papan pemuka, tetapi adakah sentiasa ada data pada pemberitahuan tertentu, dan bukan hanya maklumat am? Alspaugh menasihati "berfikir tentang cara anda boleh mentafsir atau membalas pemberitahuan" (slaid 29). Pemberitahuan yang baik tertumpu kepada orang yang bertugas, bukan hanya dikonfigurasikan oleh ambang.
Jadi berikut ialah beberapa idea tentang cara memperbaik konteks pemberitahuan:
- Tunjukkan kepada pengguna sesuatu yang berguna dan dicipta khas, dan bukan hanya arahan biasa atau papan pemuka. Sebelum ini, saya dan lelaki itu menggunakan papan pemuka penyiasatan yang dikonfigurasikan untuk pemberitahuan tertentu. Ini akan membantu jika masalah itu diketahui, tetapi hanya akan mengelirukan orang lain. Kita perlu mencari keseimbangan di sini.
- Beritahu kami tentang sejarah pemberitahuan: adakah ia baharu? Adakah ia berfungsi dengan kerap? Adakah ia bermusim?
- Tunjukkan perubahan terkini pada keadaan sistem. Adakah sesuatu yang berubah baru-baru ini? (Sebagai contoh, penggunaan atau mendayakan/melumpuhkan fungsi.)
- Tunjukkan perhubungan dan berikan maklumat untuk model mental: kebergantungan sistem harus jelas kelihatan, sebaik-baiknya dengan petunjuk kefungsian.
- Hubungkan pengguna dengan pasukan dengan cepat: bolehkah mereka melihat insiden yang sedang berlaku atau bolehkah mereka mengetahui siapa lagi dalam syarikat yang telah menerima pemberitahuan? Program diaktifkan?
Sebaik-baiknya, program pengurusan insiden akan memberikan nasihat tentang cara menambah baik konteks pemberitahuan penyiasatan insiden. Sentiasa ada sesuatu untuk diusahakan!
Boleh bertindak - nilai praktikal
Sekiranya pegawai bertugas melakukan sesuatu sebagai tindak balas kepada pemberitahuan itu? Jika anda tidak perlu melakukan apa-apa atau tidak jelas apa yang perlu dilakukan, mengapa anda membangunkannya? Anda perlu mengelakkan pemberitahuan yang mengganggu mereka yang bertugas dan tidak memerlukan tindakan.
Apa patut saya buat? Apa yang kamu mahu?
Pada masa lalu, apabila sistem adalah mudah dan pasukan kecil, kami menyediakan pemantauan hanya untuk mengetahui perkara utama. Pemberitahuan bahawa beban pada timbunan telah meningkat akan memberi kita konteks jika perkhidmatan tersebut kemudiannya tidak berfungsi. Pada skala besar, pemberitahuan sedemikian hanya akan menimbulkan kekeliruan kerana sistem kami sentiasa beroperasi dalam keadaan kemerosotan yang berbeza-beza. Ini dengan cepat membawa kepada dan, sudah tentu, kehilangan sensitiviti. Oleh itu, pegawai bertugas mengabaikan atau menapis pemberitahuan tersebut dan tidak selalu bertindak balas kepada mereka seperti yang diperlukan. Jangan jatuh ke dalam perangkap ini! Jangan sediakan semua pemberitahuan berturut-turut dan kemudian hantarkannya melalui e-mel ke beberapa folder yang ditinggalkan.
Begini rupa notis dengan nilai praktikal:
- Pemberitahuan memerlukan tindakan dan bukannya hanya melaporkan berita.
- Tindakan ini sukar atau berisiko untuk diautomatikkan. Jika sesuatu tindakan boleh diautomasikan, kemudian automatikkannya, berhenti mengganggu orang!
- Notis itu mengandungi cadangan segera dalam borang (SLA) atau (RTO). Pegawai bertugas kemudiannya boleh mengaktifkan program pengurusan insiden organisasi.
Saya ingin menjelaskan: Saya tidak mengatakan bahawa pemberitahuan hanya perlu datang untuk SLO (objektif peringkat perkhidmatan) yang paling penting untuk API. Pemantauan SLO sentiasa berpecah-belah dan dibahagikan dan memerlukan pendekatan yang sama untuk semua perkhidmatan. Jelas sekali bahawa anda akan menjejaki SLO yang paling penting untuk pelanggan yang membayar anda. Tetapi SLO infrastruktur, seperti pangkalan data, juga perlu dipantau. Tidak lama lagi anda perlu berurusan dengan pelanggan dalaman dan menyokong mereka. Dan seterusnya ad infinitum.
Berasaskan gejala - penekanan kepada gejala
Sama ada anda suka atau tidak, anda bekerja dalam sistem teragih (Kavaj). Akibatnya, anda menggunakan taktik yang berbeza untuk mengasingkan perkhidmatan dan melindunginya daripada kegagalan (Trainor et al.)3. Dan walaupun pengumpulan sampah yang tertunda atau pertanyaan pangkalan data yang terhenti menunjukkan masalah, tidak perlu tergesa-gesa untuk memperbaikinya jika pengguna tidak menghadapi masalah dalam masa terdekat.
Ini adalah isyarat penting dan mungkin mempunyai nilai praktikal, tetapi jika ia tidak mengganggu pengguna, maka ia tidak cukup mendesak untuk mengalih perhatian atendan. Pemberitahuan berasaskan sebab ialah gambar model mental kami tentang kegagalan sistem. Adalah lebih baik untuk mengesan gejala penting daripada cuba menyenaraikan semua kemungkinan punca kegagalan.
Untuk membuat pemberitahuan bermakna, fokus pada , penting kepada pengguna. Evashchuk memanggil ini "pemantauan untuk pengguna." Ingat bahawa falsafah ini mesti diterapkan di seluruh organisasi. Jika perkhidmatan mempunyai masalah mendesak di suatu tempat yang jauh di dalam infrastruktur, pasukan yang sesuai akan menguruskannya. Melindungi sistem daripada kegagalan sedemikian adalah satu perkara yang berasingan (Trainer et al., bahagian strategi untuk meminimumkan kebergantungan kritikal).
Gejala tidak berubah-ubah
Richard Cook mengingatkan kita bahawa sistem yang kompleks penuh dengan kelemahan, kekurangan dan masalah. Cuba untuk menyenaraikan semua sebab yang mungkin adalah tugas Sisyphean. Anda cuba menerangkan masalah, tetapi ia berubah sepanjang masa. Cindy Sridharan percaya bahawa "sistem tidak perlu berada dalam keadaan sempurna setiap saat" dan lebih baik menggunakan pendekatan yang lebih manusiawi ( (βMemantau Sistem Teragihβ), 7).
Elakkan pemberitahuan selepas kejadian
Biasanya, pemberitahuan untuk punca dikonfigurasikan untuk membetulkan insiden. Dan pemberitahuan terhad ini tentang fakta apa yang berlaku mewujudkan rasa selamat yang palsu, kerana sistem setiap kali muncul dengan cara baharu untuk memecahkan.
Jangan terpedaya dengan notis sebab. Lebih baik fikirkan:
- Mengapa pemberitahuan berasaskan gejala tidak menyedari masalah itu?
- Adakah berguna untuk menambah baik konteks untuk pengguna?
- Bagaimanakah alat pemantauan boleh dipertingkatkan untuk membuat diagnosis dengan lebih cepat, dan bukannya mengumpul pemberitahuan tentang perkara yang berlaku?
Alat pemantauan untuk diagnosis hanya akan membantu jika anda menganggapnya sebagai cara untuk beralih daripada gejala kepada penyelesaian. Tanpa maklum balas ini, anda hanya akan dihujani dengan pemberitahuan lewat dan carta tentang kegagalan masa laluβdan bukan perkataan tentang kegagalan masa hadapan. Ini adalah peluang yang baik untuk organisasi bergerak dari pertahanan ke serangan. Dan pembangun dan pengurus produk akan mempunyai jangkaan yang sama dan matlamat yang jelas. Kes - CASE (:wink:) - adalah jelas untuk setiap pemberitahuan.
Pemberitahuan berasaskan sebab boleh diterima secara sederhana
Kadangkala sistem kami memberi kami sedikit pilihan dari segi pemberitahuan berasaskan sebab. Dan kadangkala mereka yang bertugas memahami dengan baik bahawa gejala pasti akan membawa kepada kegagalan, dan oleh itu mengandungi nilai praktikal. Mungkin anda tidak pasti apa yang sedang berlaku dan sedang menyediakan pemberitahuan untuk berada di bahagian yang selamat. Semoga tindakan ini bersifat sementara sehingga kami boleh menukar sistem untuk menyelesaikan isu prestasi.
Ingat komponen CASE yang lain apabila berhadapan dengan situasi ini. Hanya kerana ia sementara tidak bermakna anda boleh berhenti berfikir dengan kepala anda.
Dinilai - penilaian
Sebarang perubahan pada sistem (kod baharu, infrastruktur baharu, apa-apa yang baharu) meluaskan julat kegagalan (Cook, 3). Adakah pemberitahuan ini masih berfungsi seperti yang diharapkan? Model sistem mental yang jelas dan terkini serta pengalaman bertindak balas kepada beberapa pemberitahuan sokongan - ini adalah ciri utama . Kecacatan dalam sistem sentiasa berkembang, dan kita mesti mengikutinya.
Anda perlu sentiasa menilai kualiti setiap pemberitahuan untuk memastikan ia berfungsi seperti yang diharapkan. Pemimpin yang dihormati! Ia akan menjadi lebih mudah untuk pasukan anda jika anda membantu mereka mewujudkan proses ini! Berikut ialah beberapa idea penilaian:
- Gunakan , atau kaedah ujian pemberitahuan lain. Pasukan boleh melakukannya sendiri tanpa perlu bergantung pada sistem pengurusan insiden yang berat!
- Menggabungkan koleksi semua pemberitahuan berkaitan insiden ke dalam program pengurusan insiden anda. Tandai berguna, berbahaya, tidak sesuai, tidak jelas, dsb. Gunakannya sebagai maklum balas.
- Pemberitahuan yang betul jarang dicetuskan dan diuji dengan teliti. Pastikan semua pautan berfungsi, tuding ke konteks yang betul, dsb.
- Jika pemberitahuan tidak pernah menyala atau menyala terlalu kerap, terdapat sesuatu yang tidak kena dengannya. Betulkan atau keluarkannya. Berhati-hati dengan pasif atau aktiviti yang berlebihan!
- Tetapkan cap waktu pemberitahuan dengan tarikh tamat tempoh. Jika tarikh tamat tempoh telah tamat, nilai pemberitahuan menggunakan kaedah CASE dan kemas kini cap waktu. Sama seperti makanan, semak tarikh luput dengan kerap.
- Permudahkan proses menambah baik pemberitahuan. Gunakan pemantauan sebagai kod dan pemberitahuan kedai dalam repositori Git. Permintaan tarik membantu melibatkan pasukan dan memberi anda sejarah pemberitahuan masa lalu. Dan anda tidak lagi takut untuk menukar pemberitahuan atau meminta kebenaran daripada mereka yang bertanggungjawab untuknya.
- Sediakan maklum balas untuk pemberitahuan, walaupun ia mudah , supaya pegawai bertugas menandakan pemberitahuan sebagai tidak berguna atau mengganggu. Benamkan pautan atau seruan tindak ke dalam pemberitahuan itu sendiri dan semak maklum balas anda dengan kerap.
- Tetapkan peraturan dalam pasukan - biarkan mereka yang bertugas bekerja untuk memudahkan tugas apabila ada sedikit kerja. Semoga segala-galanya selepas anda menjadi lebih baik daripada sebelumnya.
Kesimpulan
Saya percaya kaedah CASE membantu pembangun dan organisasi membincangkan penyediaan dan penghantaran pemberitahuan automatik. Seorang pembangun boleh mula menilai pemberitahuan menggunakan kaedah CASE, dan kemudian seluruh organisasi akan bergabung dengan pembangun, pengurusan dan program pengurusan insiden lain untuk memastikan pemberitahuan dalam keadaan baik. Ini tidak memerlukan sebarang alat khas atau proses yang kompleks.
Seluruh industri perlu memikirkan faktor manusia semasa bertugas tanpa mengorbankan perkhidmatan pelanggan yang terbaik. Semua alat dan amalan ini boleh dan harus diperbaiki. Saya harap kaedah CASE akan membantu dengan ini.
Nikmati pemberitahuan yang dipertingkatkan!
Sumber: www.habr.com