Dziiiiiin! Jam 3 esuk, sampeyan lagi ngimpi apik banget, lan dumadakan ana telpon. Sampeyan lagi tugas minggu iki, lan ketoke ana kedadeyan. Sistem otomatis nelpon kanggo ngerteni apa sing salah. Iki minangka aspek penting kanggo ngatur sistem komputer modern, nanging ayo goleki carane nggawe kabar luwih apik kanggo wong.
Kenali filosofi pemantauan, lair sajrone pirang-pirang dekade tugasku ing tim pemantauan sing beda-beda. Dheweke umume dipengaruhi dening Kitab Suci nyata saka Rob Evashchuk (Filosofi Notifikasi Kula) kalebu ing buku ing , lan buku dening John Alspaugh (Cathetan babagan nyetel tandha).
, и - matur nuwun kanggo bantuan sampeyan kanggo nyunting kiriman.
Apa iku CASE?
Aku mutusaké kanggo teka munggah karo singkatan ayu kaya utawa . Aku nelpon Metode CASE. Dheweke nerangake papat poin sing kudu digatekake nalika nggarap pemantauan otomatis:
- (terikat konteks)
- (nilai praktis)
- (penekanan ing gejala)
- (kelas)
Yen sampeyan nggunakake CASE, sampeyan nambani kabar kanthi ora peduli lan ora nggugah wong ing wayah wengi. Pemantauan kudu ditaksir kanthi rutin kanggo migunani lan efektifitas. Nalika wong nampa kabar, dheweke bakal duwe model mental sing luwih apik lan luwih percaya diri.
Kanggo nggampangake ngeling-eling, bayangake yen sampeyan butuh CASE [yaiku kasus, alesan - cathetan penerjemah] kanggo mbenerake saben tandha. :kacamata:
Lan kenapa kabeh iki?
. Amarga akeh alasan. Lan CASE ora bakal ngilangi kabeh. Nanging kanthi iku, sampeyan bakal tangi ing wayah wengi kanggo kabar sing luwih apik. Cara iki nyakup macem-macem proses organisasi sing uga bakal mbantu ing perkara iki.
Kaendahan metode RED lan USE yaiku kanthi bantuan kita ora mung ngerti cara kerja, nanging uga nganggo basa sing padha. Pangarep-arepku yaiku metode CASE bakal nggampangake kanggo ngrembug kabar sing nglindhungi sistem kita nanging nggawe kanca-kanca sibuk.
Intine sampeyan kudu nggawe budaya ing organisasi sampeyan ing ngendi kabar kasebut dianggep kanthi ora peduli sing sehat. Kabar bisa digawe kanggo tujuan tartamtu, nanging ora kasunyatan sing padha ora bakal kelangan nilai mengko. Napa kita nyiyapake kabar iki? Suwene suwene kritéria kasebut wis direvisi? Kanthi CASE, pitakonan kasebut bisa dijawab.
Konteks-Abot - konteks naleni
3 am dudu wektu sing paling apik kanggo maca pesen sing ngemot akeh tembung sing cerdas. Kanggo nanggapi kanthi efektif, sampeyan butuh informasi. Saenipun, iki kudu dadi informasi babagan masalah tartamtu, sing kontekse langsung jelas, lan kabar kudu dikonfigurasi supaya bisa ditindakake. Iki "pengamatan" lan "orientasi" saka . Ora isin nglampahi wektu ing persiyapan iki, amarga terus-terusan ngganggu wong malah luwih larang. Ayo padha ngurmati.
Masalah duwe akeh sumber. Utamane memedi.
Kepiye carane bisa nulungi petugas? Babagan pisanan sing dideleng petugas tugas yaiku kabar, mula dheweke nggawe kabeh hipotesis kanthi basis. Banjur katon ing instruksi lan dashboard, nanging tansah ana data ing kabar tartamtu, lan ora mung informasi umum? Alspaugh menehi saran "mikir babagan carane sampeyan bisa napsirake utawa nanggapi kabar" (slide 29). Kabar sing apik difokusake marang wong sing tugas, ora mung dikonfigurasi kanthi ambang.
Mangkene sawetara ide babagan carane nambah konteks kabar:
- Tampilake pangguna sing migunani lan digawe khusus, lan ora mung instruksi biasa utawa dasbor. Sadurunge, aku lan wong lanang nggunakake dashboard investigasi sing dikonfigurasi kanggo kabar tartamtu. Iki bakal mbantu yen masalah dikenal, nanging mung bakal mbingungake wong liya. Kita kudu golek imbangan ing kene.
- Dakkandhani babagan sejarah kabar kasebut: apa anyar? Apa kerjane asring? Apa musiman?
- Tampilake owah-owahan anyar ing negara sistem. Apa ana owah-owahan? (Contone, panyebaran utawa ngaktifake / mateni fungsi.)
- Tampilake hubungan lan nyedhiyakake informasi kanggo model mental: dependensi sistem kudu katon kanthi jelas, luwih apik kanthi indikasi fungsi.
- Sambungake pangguna kanthi cepet karo tim: apa dheweke bisa ndeleng kedadeyan sing terus-terusan utawa bisa ngerteni sapa wae ing perusahaan sing wis nampa kabar? Program diaktifake?
Saenipun, program manajemen insiden bakal menehi saran babagan carane nambah konteks kabar babagan investigasi kedadeyan. Ana tansah soko bisa ing!
Actionable - Nilai praktis
Apa petugas tugas kudu nindakake apa wae kanggo nanggepi kabar kasebut? Yen sampeyan ora perlu nindakake apa-apa utawa ora jelas apa sing kudu ditindakake, kenapa sampeyan nggugah dheweke? Sampeyan kudu ngindhari kabar sing ngganggu wong sing tugas lan ora mbutuhake tumindak.
Aku kudu piye? Apa sing dikarepake?
Ing jaman biyen, nalika sistem prasaja lan tim cilik, kita nyiyapake ngawasi supaya tetep ana ing ndhuwur. Kabar yen beban ing tumpukan wis tambah bakal menehi konteks yen layanan kasebut gagal. Ing skala gedhe, kabar kasebut mung bakal nggawe kebingungan amarga sistem kita tansah operasi ing kahanan degradasi kanthi tingkat keruwetan sing beda-beda. Iki cepet ndadékaké kanggo lan, mesthi, kanggo mundhut saka sensitivitas. Mula, petugas tugas ora nggatekake utawa malah nyaring kabar kasebut lan ora mesthi nanggapi yen dibutuhake. Aja tiba ing jebakan iki! Aja nyiyapake kabeh kabar kanthi berturut-turut banjur dikirim kanthi email menyang folder sing ditinggalake.
Mangkene kabar kanthi nilai praktis:
- Kabar mbutuhake tumindak tinimbang mung nglaporake kabar.
- Tumindak iki angel utawa beboyo kanggo otomatis. Yen tumindak bisa otomatis, banjur otomatis, mungkasi pestering wong!
- Kabar kasebut ngemot rekomendasi penting ing formulir kasebut (SLA) utawa (RTO). Petugas tugas banjur bisa ngaktifake program manajemen insiden organisasi.
Aku pengin njlentrehake: Aku ora ngomong yen kabar mung kudu teka kanggo SLO sing paling penting (tujuan tingkat layanan) kanggo API. Pemantauan SLO terus-terusan dipérang lan dipérang lan mbutuhake pendekatan sing padha kanggo kabeh layanan. Cetha yen sampeyan bakal nglacak SLO sing paling penting kanggo klien sing mbayar sampeyan. Nanging SLO infrastruktur, kayata database, uga kudu dipantau. Ora suwe sampeyan kudu ngatasi pelanggan internal lan ndhukung. Lan sateruse ad infinitum.
adhedhasar gejala - emphasis ing gejala
Apa sampeyan seneng utawa ora, sampeyan lagi kerja ing sistem sing disebarake (Kavaj). Akibaté, sampeyan nggunakake taktik sing beda kanggo ngisolasi layanan lan nglindhungi saka kegagalan (Trainor et al.)3. Lan sanajan koleksi sampah sing ditundha utawa pitakon database sing mandheg nuduhake masalah, ora perlu cepet-cepet ndandani yen pangguna ora duwe masalah ing mangsa ngarep.
Iki minangka sinyal penting lan bisa uga nduweni nilai praktis, nanging yen ora ngganggu pangguna, mula ora cukup penting kanggo ngganggu petugas. Kabar adhedhasar sabab minangka gambar saka model mental kita babagan kegagalan sistem. Iku luwih apik kanggo nglacak gejala penting saka nyoba kanggo dhaptar kabeh bisa nimbulaké Gagal.
Kanggo nggawe kabar sing migunani, fokus ing , penting kanggo pangguna. Evashchuk nyebat iki "ngawasi pangguna." Elinga yen filosofi iki kudu ditrapake ing saindhenging organisasi. Yen layanan duwe masalah sing penting ing endi wae ing infrastruktur, tim sing cocog bakal ngurus. Nglindhungi sistem saka kegagalan kasebut minangka prakara sing kapisah (Trainer et al., bagean babagan strategi kanggo nyuda dependensi kritis).
Gejala ora kaya variabel
Richard Cook ngelingake yen sistem kompleks kebak cacat, kekurangan lan masalah. Nyoba dhaptar kabeh alasan sing bisa ditindakake yaiku tugas Sisyphean. Sampeyan nyoba kanggo njlèntrèhaké masalah, nanging padha ngganti kabeh wektu. Cindy Sridharan percaya yen "sistem ora kudu ing kondisi sampurna saben detik" lan luwih becik nggunakake pendekatan sing luwih manungsa ( (“Sistem Distribusi Monitoring”), 7).
Ngindhari kabar sawise kedadeyan
Biasane, kabar kanggo sabab dikonfigurasi kanggo mbenerake kedadeyan. Lan kabar winates iki babagan kasunyatan sing kedadeyan nggawe rasa aman sing palsu, amarga sistem saben wektu teka kanthi cara anyar kanggo ngilangi.
Aja ditipu dening kabar sabab. Luwih becik mikir:
- Napa kabar adhedhasar gejala ora ngerteni masalah kasebut?
- Apa migunani kanggo nambah konteks kanggo pangguna?
- Kepiye alat ngawasi bisa ditingkatake kanggo nggawe diagnosis luwih cepet, tinimbang ngumpulake kabar babagan kedadeyan kasebut?
Alat ngawasi kanggo diagnosis mung bakal mbantu yen sampeyan nganggep minangka cara kanggo pindhah saka gejala menyang solusi. Tanpa umpan balik iki, sampeyan mung bakal dibombardir karo kabar telat lan grafik babagan kegagalan kepungkur-lan ora ana tembung babagan sing bakal teka. Iki minangka kesempatan sing apik kanggo organisasi kanggo pindhah saka pertahanan menyang serangan. Lan pangembang lan manajer produk bakal duwe pangarepan sing padha lan tujuan sing jelas. Kasus - CASE (: wink :) - cetha kanggo saben kabar.
Kabar adhedhasar alasan bisa ditrima kanthi moderat
Kadhangkala sistem kita menehi pilihan sethithik babagan kabar adhedhasar sabab. Lan kadhangkala wong-wong sing tugas ngerti kanthi becik yen gejala kasebut bakal nyebabake kegagalan, lan mulane ngemot nilai praktis. Mungkin sampeyan ora yakin apa sing kedadeyan lan nyetel kabar supaya aman. Muga-muga tumindak iki sementara nganti kita bisa ngganti sistem kanggo ngrampungake masalah kinerja.
Elinga komponen liyane saka CASE nalika nangani kahanan kasebut. Mung amarga iku sak wentoro ora ateges sampeyan bisa mungkasi mikir karo sirah.
Evaluasi - evaluasi
Sembarang owah-owahan ing sistem (kode anyar, infrastruktur anyar, apa wae sing anyar) nggedhekake sawetara kegagalan (Cook, 3). Apa kabar iki isih bisa digunakake kaya sing dikarepake? Model mental sistem lan pengalaman sing jelas lan saiki nanggapi sawetara kabar dhukungan - iki fitur tombol . Cacat ing sistem terus berkembang, lan kita kudu ngetutake.
Sampeyan kudu terus-terusan ngevaluasi kualitas saben kabar supaya bisa digunakake kaya sing dikarepake. Para pemimpin ingkang kinurmatan! Bakal luwih gampang kanggo tim sampeyan yen sampeyan mbantu nggawe proses iki! Ing ngisor iki sawetara gagasan penilaian:
- Gunakake , utawa cara testing kabar liyane. Tim bisa nindakake dhewe tanpa kudu ngandelake sistem manajemen insiden sing abot!
- Gabungke koleksi kabeh kabar sing gegandhengan karo insiden menyang program manajemen insiden sampeyan. Tandhani migunani, mbebayani, ora cocog, ora jelas, lsp. Gunakake minangka umpan balik.
- Kabar sing bener ora kerep dipicu lan diuji kanthi ati-ati. Priksa manawa kabeh pranala bisa digunakake, arahake menyang konteks sing bener, lsp.
- Yen kabar ora tau murub utawa asring murub, ana sing salah. Ndandani utawa mbusak. Waspada karo pasif utawa aktivitas sing berlebihan!
- Setel cap wektu kabar kanthi tanggal kadaluwarsa. Yen tanggal kadaluwarsa wis kadaluwarsa, evaluasi kabar nggunakake metode CASE lan nganyari stempel wektu. Kaya panganan, priksa tanggal kadaluwarsa kanthi rutin.
- Gampang proses nambah kabar. Gunakake pemantauan minangka kode lan nyimpen kabar ing repositori Git. Panjaluk tarik mbantu melu tim lan menehi riwayat kabar kepungkur. Lan sampeyan ora bakal wedi maneh ngganti kabar utawa njaluk ijin saka sing tanggung jawab.
- Setel umpan balik kanggo kabar, sanajan gampang , supaya petugas tugas menehi tandha kabar minangka ora ana gunane utawa ngganggu. Sematake link utawa ajakan tumindak menyang kabar kasebut lan deleng tanggapan sampeyan kanthi rutin.
- Nggawe aturan ing tim - supaya wong-wong sing duwe tugas bisa nyederhanakake tugas nalika ora ana karya. Muga-muga kabeh sawise sampeyan dadi luwih apik tinimbang sadurunge.
kesimpulan
Aku yakin cara CASE mbantu para pangembang lan organisasi ngrembug babagan nyetel lan ngirim kabar otomatis. Siji pangembang bisa miwiti ngevaluasi kabar nggunakake metode CASE, banjur kabeh organisasi bakal gabung karo pangembang, manajemen, lan program manajemen insiden liyane kanggo njaga kabar kanthi apik. Iki ora mbutuhake alat khusus utawa proses rumit.
Kabeh industri kudu mikir babagan faktor manungsa nalika nindakake tugas tanpa ngorbanake layanan pelanggan sing paling dhuwur. Kabeh alat lan praktik kasebut bisa lan kudu ditingkatake. Muga-muga cara CASE bakal mbantu.
Seneng kabar apik!
Source: www.habr.com