Remediasi

Selesai

Membagi siklus hidup respons insiden menjadi lima fase seperti yang telah Anda lihat dalam modul ini membantu Anda memahami prosesnya, tetapi fase-fase tersebut tidak selalu berbeda seperti yang terlihat 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.

Diagram siklus lingkaran yang diberi label dengan fase respons insiden, lingkaran terhubung ke lingkaran berikutnya dengan panah dari fase ke fase, Deteksi, Respons, dan Remediasi disorot

Di pelajaran ini, Anda akan mempelajari lebih lanjut tentang remediasi dan langkah-langkah yang membentuk fase ini, serta beberapa tips dan alat yang berguna. Satu hal penting yang perlu diperhatikan: langkah-langkah yang diuraikan di sini tidak boleh dianggap 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 urutan apa untuk memperbaiki masalah, inilah saat 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 cara kerja dan ide yang berbeda tentang langkah pertama yang harus dilakukan. Seseorang mungkin pertama-tama melihat log, sementara yang lain mungkin terlebih dahulu 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 yang ingin dan perlu mengetahui apa yang sedang terjadi.

Penting untuk berkomunikasi dengan tim internal lainnya dan memberi tahu mereka tentang apa yang terjadi saat insiden terjadi. Jika Anda tidak memberi mereka pembaruan yang konsisten, mereka kemungkinan akan muncul, meminta pembaruan status. Mereka memiliki hak atas informasi ini, tetapi Anda memerlukan cara yang lebih baik untuk membuat mereka menyadari masalah ini dan apa yang sedang dilakukan tentang hal itu.

Anda harus jelas tentang pengakuan kepada tim internal Anda. Jelas dalam menyajikan apa yang Anda ketahui dan apa yang sedang dilakukan dan tentukan harapan dalam hal kapan mereka akan mendengar kabar dari Anda.

Rumus untuk komunikasi Anda kepada pemangku kepentingan sederhana:

  • Inilah yang kami tahu.
  • Inilah yang kami lakukan.
  • Kami akan kembali kepada Anda dalam waktu X.

Ini akan membantu mencegah pemangku kepentingan datang kepada Anda dan mengganggu Anda saat Anda sedang 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 halaman eksternal untuk pelanggan Anda. Rumus di atas 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. Buku Kerja Azure Monitor dapat ditemukan di portal Microsoft Azure di bawah Azure Monitor, Panduan Pemecahan Masalah Azure Insights ditemukan di portal saat instans Application Insight telah dipilih.

Buku kerja dan panduan pemecahan masalah dapat dianggap sebagai "dokumen langsung" yang dapat Anda buat menggunakan antarmuka pembuatan halaman. Saat membuat yang baru, Anda dapat menambahkan ke halaman:

  • teks arbitrer seperti daftar berpoin item yang harus dilakukan atau informasi bermanfaat lainnya untuk seseorang yang membuka halaman tersebut
  • tautan ke sistem lain, misalnya, tautan ke dasbor atau dokumentasi lain
  • Kueri Kusto Query Language (KQL)

Item terakhir itulah yang membuat dokumen "hidup". Dalam modul sebelumnya di jalur pembelajaran ini, kami menjelajahi bahasa kueri KQL yang ada di dalam Log Analytics 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 tersebut saat ini ditampilkan, langsung, kepada 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:

Cuplikan layar panduan pemecahan masalah contoh default seperti yang ditemukan di portal Azure.

Ada fitur "penyunting tingkat lanjut" untuk Buku Kerja dan panduan pemecahan masalah yang memungkinkan Anda mengakses dan menyisipkan representasi templat JSON atau Azure Resource Manager dari dokumen itu. Ini berarti dimungkinkan untuk melacak dan mendistribusikan dokumen-dokumen ini menggunakan sistem kontrol sumber pilihan Anda. Ini juga memungkinkan Anda untuk mengotomatiskan provisi buku kerja atau panduan pemecahan masalah, berguna saat provisi infrastruktur lain. Membuat satu set dokumen pemecahan masalah kustom untuk digunakan dengan layanan baru pada saat layanan tersedia menjadi mudah menggunakan praktik terbaik ini.

Tips dan alat bermanfaat lainnya

Sepanjang modul ini, Anda telah belajar tentang berbagai alat dan pintasan yang dapat Anda gunakan untuk meningkatkan efisiensi dan mengurangi waktu respons insiden Anda. Saat kami menyelesaikan pelajaran terakhir ini, kami akan melakukan gambaran umum singkat tentang beberapa alat dan teknik yang membantu dalam mendiagnosis masalah dalam sistem Anda.

  • Tautan Dasbor Aplikasi di Application Insights dapat digunakan untuk membuat dasbor secara otomatis yang memiliki sebagian besar item utama yang Anda perlukan 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.
  • Peta Aplikasi di Application Insights dapat digunakan untuk menelusuri apa yang sebenarnya terjadi yang menyebabkan masalah. Anda dapat mengikuti breadcrumb untuk menemukan penyebab kesalahan (misalnya, format URL yang salah).
  • Log Analytic dapat digunakan untuk mengkueri bagian mana pun dari sistem.

Semua hal di atas adalah alat yang sangat berharga dalam memperbaiki masalah.

Uji pengetahuan Anda

1.

Saat berkomunikasi dengan pemangku kepentingan, item mana yang bukan bagian dari rumus yang kami sarankan?

2.

Mengapa buku kerja dan panduan pemecahan masalah dianggap sebagai dokumen langsung dalam deskripsi kami?