Perbaikan
Membagi siklus hidup respons insiden menjadi lima fase seperti yang telah Anda lihat dalam modul ini membantu Anda memahami prosesnya, tetapi fasenya tidak selalu sejelas yang muncul dalam diagram. Secara khusus, garis antara fase respons dan remediasi sering mulai kabur. Ini terutama berlaku ketika tindakan yang dimaksudkan untuk mengurangi atau meningkatkan situasi memiliki efek yang berlawanan. Dalam hal ini, respons dan remediasi cenderung tumpang tindih atau bolak-balik di antara keduanya.
Di unit ini, Anda akan mempelajari lebih lanjut tentang remediasi dan langkah-langkah yang membentuk fase ini, serta beberapa tips dan alat yang bermanfaat. Satu hal penting yang perlu diperhatikan: Anda tidak boleh mengambil langkah-langkah yang diuraikan di sini sebagai daftar periksa preskriptif.
Jika Anda memang sudah memiliki daftar periksa untuk remediasi, itu sering menjadi indikasi bahwa sudah saatnya untuk menggunakan otomatisasi. Ketika Anda dapat menjelaskan dengan tepat apa yang perlu dilakukan dan dalam rangka apa untuk memulihkan masalah, ini adalah waktu yang tepat untuk mengajarkan langkah-langkah ini ke mesin sehingga sistem dapat melakukannya untuk Anda.
Tempat memulai
Anda mempelajari tentang pentingnya mengurangi waktu yang diperlukan untuk menanggapi insiden. Sekarang mari kita lihat beberapa hal yang dapat membantu mempercepat proses perbaikan, atau memperbaiki masalah.
Anggota tim yang berbeda mungkin memiliki model mental yang berbeda tentang bagaimana hal-hal bekerja dan ide yang berbeda tentang apa langkah pertama seharusnya. Seseorang mungkin terlebih dahulu melihat log, sementara yang lain mungkin pertama kali menjalankan kueri dan melihat metrik. Tidak ada satu pun jalur yang benar untuk sukses.
Namun, ini membantu memberi orang konteks dan panduan tentang ke mana mereka harus pergi dan apa yang harus mereka lihat.
Bagaimana dan kepada siapa untuk meningkatkan
Pertanyaan penting untuk dijawab dalam merumuskan titik awal remediasi Anda adalah: ketika Anda terjebak, siapa yang dapat Anda panggil untuk meningkatkan masalah? Anda harus mencoba mendelegasikan lebih banyak tanggung jawab tugas siaga kepada tim secara keseluruhan, bukan hanya Operasi atau Rekayasa Keandalan Situs. Harus menjadi tanggung jawab semua anggota tim agar sistem aktif dan berjalan untuk memenuhi tujuan keandalan Anda.
Sumber daya apa yang berguna bagi responden pertama?
Pertimbangan selanjutnya adalah menentukan hal-hal yang dapat digunakan responden pertama untuk memulai proses. Ini dapat mencakup metrik, log, kueri, dan sebagainya yang relevan. Ini harus disediakan dalam panduan buku kerja/pemecahan masalah Azure jika memungkinkan. Kita akan membicarakannya sebentar lagi.
Ini juga berguna untuk menyediakan tautan sederhana ke sumber daya (seringkali dalam panduan pemecahan masalah). Jika tujuan Anda adalah merespons dan memulihkan masalah secepat mungkin, membantu orang menemukan jawaban atas pertanyaan tanpa harus mencari dokumen atau URL yang tepat akan mempercepat proses.
Memperbarui pemangku kepentingan
Anda dapat menjadi begitu fokus untuk memperbaiki masalah sehingga Anda mungkin lupa bahwa ada banyak orang yang tidak terlibat langsung dalam respons terhadap insiden tersebut, tetapi siapa yang ingin dan perlu tahu apa yang terjadi.
Penting untuk berkomunikasi dengan tim internal lain dan memberitahu mereka tentang apa yang terjadi ketika insiden terjadi. Jika Anda tidak memberi mereka pembaruan yang konsisten, mereka cenderung datang meminta pembaruan status. Mereka memiliki hak atas informasi ini, tetapi Anda memerlukan cara yang lebih baik untuk membuat mereka menyadari masalah dan apa yang sedang dilakukan tentang hal itu.
Anda harus jelas mengenai pengakuan terhadap tim internal Anda. Perjelas dalam menyajikan apa yang Anda ketahui dan apa yang sedang dilakukan dan menetapkan harapan dalam hal kapan mereka akan mendengar kembali dari Anda.
Rumus untuk komunikasi Anda kepada pemangku kepentingan sederhana:
- Inilah yang kita tahu.
- Ini adalah apa yang kita lakukan.
- Kami akan menghubungi Anda kembali dalam jangka waktu X.
Ini akan membantu mencegah pemangku kepentingan datang kepada Anda dan mengganggu Anda ketika Anda berada di tengah-tengah mencoba memperbaiki masalah.
Salah satu cara untuk mendistribusikan informasi ini adalah melalui penggunaan halaman web status yang mudah diedit seperti yang kami sebutkan di unit terakhir. Dalam banyak kasus, Anda mungkin ingin memiliki halaman status terpisah yang lebih rinci untuk pemangku kepentingan internal dan yang eksternal untuk pelanggan Anda. Rumus sebelumnya berfungsi untuk kedua kasus.
Menggunakan Buku Kerja Azure Monitor dan Panduan Pemecahan Masalah
Azure memiliki dua fitur terkait erat yang dapat sangat membantu tim dalam fase remediasi: Buku Kerja Azure Monitor dan Panduan Pemecahan Masalah Application Insights. Untuk tujuan modul ini, modul ini dapat dipertukarkan, termasuk memiliki antarmuka pengguna yang sama. Anda dapat menemukan Buku Kerja Azure Monitor di portal Microsoft Azure di bawah Azure Monitor. Anda akan menemukan Panduan Pemecahan Masalah Azure Insights di portal Microsoft Azure saat instans Application Insight telah dipilih.
Anda dapat menganggap buku kerja dan panduan pemecahan masalah sebagai "dokumen langsung" yang bisa Anda buat menggunakan antarmuka pembuatan halaman. Saat membuat yang baru, Anda bisa menambahkan ke halaman:
- Teks sembarang, seperti daftar dengan poin untuk dilakukan atau informasi bermanfaat lainnya bagi seseorang yang berkonsultasi dengan halaman ini.
- Tautan ke sistem lain, misalnya, tautan ke dasbor atau dokumentasi lain
- Kueri Bahasa Kueri Kusto (KQL)
Ini adalah item terakhir yang membuat dokumen menjadi "aktif." Dalam modul sebelumnya di jalur pembelajaran ini, kami menjelajahi bahasa kueri KQL (Kusto Query Language) yang disertakan dalam Analitik Log dan bagian lain dari Azure Monitor. Dengan menggunakan bahasa ini, kita dapat menulis kueri kita sendiri untuk mengembalikan dan menampilkan informasi diagnostik dari aplikasi dan infrastruktur Azure kita. Saat kueri KQL disisipkan ke dalam buku kerja atau panduan pemecahan masalah, hasil kueri saat ini ditampilkan langsung ke pembaca dokumen. Ini berarti bahwa panduan pemecahan masalah Anda dapat mengatakan tidak hanya "Pastikan untuk memeriksa tingkat kesalahan di server web" tetapi juga dapat menampilkan grafik saat ini untuk tingkat kesalahan tersebut tepat di sebelah instruksi. Ini dapat memiliki tautan seperti "di sini adalah dokumentasi hidupkan ulang server web" yang mengambil responden pertama langsung ke dokumentasi yang mereka butuhkan.
Azure juga menyediakan beberapa templat yang sudah ada untuk membantu Anda mulai menulis dokumen Anda sendiri. Berikut adalah cuplikan layar dari beberapa templat yang telah dibuat sebelumnya yang mungkin Anda tawarkan:
Ada fitur editor Tingkat Lanjut untuk Buku Kerja dan panduan pemecahan masalah yang memungkinkan Anda mengakses dan menyisipkan JSON atau representasi templat Azure Resource Manager dari dokumen tersebut. Ini berarti dimungkinkan untuk melacak dan mendistribusikan dokumen-dokumen ini menggunakan sistem kontrol sumber pilihan Anda. Ini juga memungkinkan Anda mengotomatiskan provisi buku kerja atau panduan pemecahan masalah, yang berguna saat Anda menyediakan infrastruktur lain. Membuat sekumpulan dokumen pemecahan masalah kustom untuk menggunakan layanan baru pada saat layanan disediakan menjadi mudah menggunakan praktik terbaik ini.
Tips dan alat bermanfaat lainnya
Sepanjang modul ini, Anda telah mempelajari berbagai alat dan pintasan yang dapat Anda gunakan untuk meningkatkan efisiensi dan mengurangi waktu respons insiden Anda. Saat kami membungkus unit terakhir ini, kami akan melakukan gambaran singkat tentang beberapa alat dan teknik yang berguna dalam mendiagnosis masalah dalam sistem Anda.
- Anda dapat menggunakan tautan Dasbor Aplikasi di Application Insights untuk secara otomatis menghasilkan dasbor yang memiliki sebagian besar item utama yang akan Anda butuhkan sebagai titik awal. Perhatikan bahwa itu tidak termasuk Azure Service Health. Anda harus menyematkan ini ke dasbor Sehingga Anda dapat memeriksa apakah masalahnya ada pada sistem Anda atau dengan layanan cloud itu sendiri.
- Anda dapat menggunakan Peta Aplikasi di Application Insights untuk menelusuri dengan tepat apa yang terjadi untuk menyebabkan masalah. Anda dapat mengikuti jejak navigasi untuk menemukan penyebab kesalahan (misalnya, URL yang salah bentuk).
- Anda dapat menggunakan Analitik Log untuk mengkueri bagian mana pun dari sistem.
Semua alat sebelumnya sangat berharga dalam memulihkan masalah.