Pelacakan insiden
Insiden memiliki siklus hidup. Untuk merespons secara paling efektif, Anda harus dapat melacak evolusi insiden itu sendiri, dan evolusi respons Anda terhadapnya, sejak awal siklus hidup itu.
Menilai apa yang Anda ketahui
Cara yang baik untuk mengevaluasi prosedur pelacakan insiden Anda menggunakan insiden tertentu adalah dengan mengajukan serangkaian pertanyaan kepada diri Anda:
- Kapan pertama kali Anda menyadari masalahnya? Jika tujuan Anda adalah untuk mengurangi waktu yang diperlukan untuk pulih dari insiden, Anda harus mulai menangkap informasi dari saat Anda menyadari masalah tersebut.
- Bagaimana kau bisa tahu tentang masalahnya? Apakah sistem pemantauan Anda memberi tahu Anda tentang insiden tersebut? Apakah Anda pertama kali mendengarnya dari keluhan pelanggan Anda, baik secara langsung maupun di media sosial?
- Jika Anda hanya mencari tahu tentang masalahnya, apakah Anda yang pertama tahu? Jika demikian, siapa yang perlu Anda beri tahu? Jika tidak, siapa lagi yang mengetahui masalah ini?
- Jika orang lain sadar, bagaimana (jika ada) yang dilakukan? Apakah semua orang berasumsi bahwa orang lain sedang menyelidikinya, atau apakah seseorang mulai mengambil tindakan untuk mengatasinya?
- Seberapa buruk itu? Kami mungkin tidak memiliki gagasan tentang tingkat keparahan atau dampak, dan tidak ada tempat bagi kami untuk mengetahui seberapa buruk masalah sebenarnya dan siapa yang terpengaruh.
Ini bisa menjadi pertanyaan sulit untuk dijawab jika tidak ada yang dilacak.
Menstandarkan tempat informasi insiden akan dilacak
Ada banyak tempat yang memungkinkan Anda dapat menyimpan dan membagikan daftar insiden Anda (aktif atau tidak) dan semua informasi terkini tentang insiden tersebut. Ini bisa sesederhana area file bersama dengan dokumen Word dan serumit perangkat lunak dan layanan pelacakan insiden yang sangat khusus. Di antara kedua ekstrem ini adalah sistem tiket dan pelacakan kerja yang dapat Anda tekan ke layanan untuk tugas ini. Sistem mana yang Anda pilih sebenarnya kurang penting daripada cara Anda menggunakannya. Tidak peduli sistem mana yang Anda gunakan, semua orang yang mungkin memiliki koneksi sama sekali ke insiden (insinyur, dukungan pelanggan, manajemen, hubungan publik, hukum, dan sebagainya) perlu tahu ke mana harus pergi untuk menemukan sistem, cara meningkatkan insiden, dan cara mengakses data jika sesuai. Salah satu cara pasti untuk gagal dengan pelacakan insiden adalah membuat orang-orang yang didukungnya tidak tahu cara mengakses sistem ("apa URL untuk sistem kami lagi?") saat mereka membutuhkannya.
Dalam modul ini, kita akan menggunakan fungsionalitas item kerja Azure DevOps untuk contoh sistem pelacakan kita.
Membuat bridge percakapan
Untuk menjawab beberapa pertanyaan di bagian Menilai apa yang Anda ketahui sebelumnya dan untuk memulai proses respons insiden, Anda harus memiliki cara untuk berkomunikasi dengan orang lain tentang insiden tersebut. Idealnya, ini akan menjadi semacam media elektronik "kolaborasi tim" untuk percakapan, meskipun jembatan telepon juga berfungsi. Panggilan konferensi/jembatan telepon kurang disukai, karena lebih sulit untuk secara retroaktif meninjau komunikasi insiden (karenanya peran "Scribe" yang disebutkan sebelumnya).
Media apa pun yang Anda pilih, Anda harus yakin untuk mengukir saluran unik yang sangat terbatas pada diskusi tentang insiden ini dan tidak ada yang lain. Penting untuk menjauhkan diskusi yang tidak relevan dari saluran ini, karena Anda harus dapat mengambil data dan menganalisisnya nanti dalam tinjauan pasca-insiden Anda.
Dalam modul ini, kita akan menggunakan Microsoft Teams sebagai metode komunikasi insiden.
Mengotomatiskan peluncuran pelacakan insiden
Jadi, mari kita tinjau kembali bagian-bagian yang telah kita kumpulkan sejauh ini. Kami memiliki:
- Daftar orang yang dipanggil (dan rotasi yang ditentukan untuk mereka).
- Peran yang dapat kami tetapkan kepada orang-orang yang mengerjakan insiden.
- Tempat khusus kita akan mendeklarasikan insiden dan melacaknya.
- Saluran unik bagi orang-orang yang mengerjakan insiden itu untuk berkomunikasi tentang hal itu.
Anda dapat dan harus mengotomatiskan pembuatan dan pengelolaan semua hal ini sejauh mungkin. Ketika masalah mendesak muncul, Anda tidak ingin harus mengenali semua langkah yang diperlukan untuk mengangkat insiden, membawa orang yang tepat, dan melacaknya. Yang benar-benar ingin Anda lakukan adalah dapat menekan tombol "pergi" sehingga pekerjaan dapat segera mulai menangani masalah.
Gunakan Azure Logic Apps untuk otomatisasi tanpa kode
Salah satu cara untuk mengotomatiskan respons awal Anda adalah dengan menggunakan Logic Apps, yang dapat menyederhanakan pekerjaan penjadwalan, mengotomatiskan, dan mengatur tugas, proses bisnis, dan alur kerja.
Azure Logic Apps adalah layanan cloud Azure untuk membangun solusi integrasi. Ini menggunakan konektor untuk membuat alur kerja otomatis. Pemicu memulai Aplikasi Logika saat peristiwa tertentu terjadi atau saat data memenuhi kriteria yang ditentukan. Tindakan adalah operasi yang kemudian dilakukan dalam alur kerja Aplikasi Logika.
Misalnya, kita akan menggunakan logika Konektor aplikasi berikut untuk pelacakan insiden:
- Azure Boards (bagian dari Azure DevOps), yang dapat Anda gunakan untuk membuat dan melacak masalah/insiden.
- Azure Storage, tempat Anda dapat menyimpan dan mengambil informasi tentang siapa yang sedang dalam panggilan sehingga Anda dapat menetapkan orang yang tepat untuk menanggapi insiden tersebut. Dalam contoh kami, kita akan menggunakan Azure Table Storage karena menawarkan penyimpanan "kunci-nilai" yang sangat sederhana yang memudahkan untuk menyimpan daftar insinyur dan status panggilan mereka.
- Microsoft Teams, yang dapat Anda gunakan untuk membuat saluran insiden unik baru untuk melacak percakapan tim teknik Anda secara real time saat mereka berkomunikasi tentang insiden tertentu. Ini memungkinkan Anda untuk mempertahankan interaksi sehubungan dengan garis waktu peristiwa nanti saat melakukan tinjauan pasca-insiden.
Sekarang mari kita ikat semua ini bersama-sama dengan Aplikasi Logika. Pertama, lihat aplikasi lengkap seperti yang ditunjukkan di Logic Apps Designer, lalu kita akan menelusurinya langkah demi langkah.
Langkah pertama adalah menangani pemicu, permintaan HTTP yang kami sebutkan. Permintaan HTTP POST dibuat ke aplikasi logika kami yang berisi muatan JSON dengan informasi tentang insiden yang ingin kami nyatakan. Kami mengurai muatan itu dan mengirim kembali pengakuan bahwa kami telah menerimanya:
Dengan menggunakan informasi ini, kami membuat item kerja baru di organisasi Azure DevOps kami yang mewakili insiden ini.
Kemudian akan membuat saluran Teams baru untuk insiden tersebut:
Setelah saluran dibuat, item kerja yang kami buat beberapa saat yang lalu akan diperbarui dengan tautan ke saluran baru. Ini menyimpan semua informasi di tempat yang sama (item pekerjaan) dan memungkinkan orang yang melihatnya nanti untuk mengetahui ke mana harus pergi jika mereka ingin bergabung dengan saluran itu.
Sekarang, saatnya untuk membawa orang yang sedang menelepon ke dalam gambar. Kami melakukan pencarian di Azure Table Storage untuk alamat email teknisi yang tercantum sebagai sedang dalam panggilan. Ini mengembalikan respons JSON, yang kemudian kita uraikan.
Karena kueri kami akan mengembalikan daftar, kita perlu melakukan iterasi pada setiap item dalam daftar tersebut sebagai langkah berikutnya. Kami menetapkan item pekerjaan untuk setiap orang (mereka sekarang adalah "pemilik" insiden).
Kemudian, sebagai langkah terakhir, kami mengirim pesan ke saluran Teams dengan penunjuk kembali ke item kerja untuk orang-orang yang bergabung dengan saluran dan ingin tahu di mana informasi otoritatif untuk insiden tersebut disimpan.
Itu hanya salah satu contoh bagaimana kita dapat mengotomatiskan pengaturan mekanisme untuk pelacakan insiden dan komunikasi. Di pelajaran berikutnya, kita akan menyelami sedikit lebih dalam aspek komunikasi seputar sebuah insiden.