Remediasi
Membalik siklus hidup respons insiden menjadi lima fase seperti yang telah Anda lihat dalam modul ini membantu Anda memahami prosesnya, tetapi fasenya tidak selalu berbeda seperti yang muncul dalam diagram. Secara khusus, garis antara fase respons dan remediasi sering kali mulai kabur. Ini terutama benar ketika tindakan yang dimaksudkan untuk mengurangi atau memperbaiki situasi memiliki efek sebaliknya. 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 memiliki daftar periksa untuk remediasi yang sudah ada, itu sering menjadi indikator bahwa sudah waktunya untuk membawa otomatisasi ke dalam foto. 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.
Di mana untuk memulai
Anda belajar tentang pentingnya mengurangi waktu yang dibutuhkan untuk menanggapi suatu insiden. Sekarang mari kita lihat beberapa hal yang dapat membantu mempercepat proses remediasi, 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 memberikan konteks dan panduan kepada orang-orang tentang ke mana mereka harus pergi dan apa yang harus mereka lihat.
Bagaimana dan kepada siapa untuk meningkatkan
Pertanyaan penting yang harus dijawab dalam merumuskan titik awal remediasi Anda adalah: ketika Anda buntu, siapa yang dapat Anda hubungi untuk meningkatkan masalah? Anda harus mencoba untuk melepaskan lebih banyak tanggung jawab panggilan ke tim secara umum, bukan hanya Operasi atau Rekayasa Keandalan Situs. Ini harus menjadi tanggung jawab semua anggota tim untuk memiliki sistem dan berjalan untuk memenuhi tujuan keandalan Anda.
Sumber daya apa yang berguna bagi penanggap pertama?
Pertimbangan selanjutnya adalah menentukan hal-hal yang dapat digunakan oleh penanggap 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 untuk menanggapi dan memulihkan masalah secepat mungkin, membantu orang menemukan jawaban atas pertanyaan tanpa harus mencari dokumen atau URL yang tepat akan mempercepat prosesnya.
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 menjaga mereka tetap terimbas dari 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 tentang pengakuan kepada 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 kami tahu.
- Ini adalah apa yang kita lakukan.
- Kami akan kembali kepada Anda dalam 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 pelajaran 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 Azure di bawah Azure Monitor. Anda akan menemukan Panduan Pemecahan Masalah Azure Insights di portal 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 dapat menambahkan ke halaman:
- Teks arbitrer, seperti daftar item berpoin yang harus dilakukan atau informasi bermanfaat lainnya bagi seseorang yang berkonsultasi dengan halaman
- Tautan ke sistem lain, misalnya, tautan ke dasbor atau dokumentasi lain
- Kueri Kusto Query Language (KQL)
Ini adalah item terakhir yang membuat dokumen "langsung." Dalam modul sebelumnya di jalur pembelajaran ini, kami menjelajahi bahasa kueri KQL yang disertakan dalam Analitik Log dan bagian lain dari Azure Monitor. Dengan menggunakan bahasa ini, kami dapat menulis kueri kami sendiri untuk mengembalikan dan menampilkan informasi diagnostik dari aplikasi dan infrastruktur Azure kami. 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 menunjukkan grafik saat ini untuk tingkat kesalahan itu di sebelah petunjuk. Itu dapat memiliki tautan seperti "ini adalah dokumentasi hidupkan ulang server web" yang membawa penanggap 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 sudah jadi yang mungkin ditawarkan kepada Anda:
Ada fitur editor Tingkat Lanjut untuk Buku Kerja dan panduan pemecahan masalah yang memungkinkan Anda mengakses dan menyisipkan representasi templat JSON atau 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 breadcrumb untuk menemukan penyebab kesalahan (misalnya, format URL yang salah).
- Anda dapat menggunakan Analitik Log untuk mengkueri bagian mana pun dari sistem.
Semua alat sebelumnya sangat berharga dalam memulihkan masalah.