Pelacakan insiden

Selesai

Insiden memiliki siklus hidup. Untuk merespons dengan paling efektif, Anda harus mampu melacak evolusi insiden itu sendiri, dan 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 bertanya pada diri sendiri serangkaian pertanyaan:

  • 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 Kata dan serumit perangkat lunak dan layanan pelacakan insiden yang sangat khusus. Di antara dua ekstrem ini adalah sistem tiket dan pelacakan kerja yang dapat digunakan untuk tugas ini. Sistem mana yang Anda pilih sebenarnya kurang penting daripada cara penggunaannya. Apa pun sistem yang Anda gunakan, setiap orang yang mungkin memiliki hubungan sama sekali dengan insiden (teknisi, dukungan pelanggan, manajemen, hubungan masyarakat, hukum, dan sebagainya...) perlu tahu ke mana harus pergi untuk menemukan sistem, bagaimana mengangkat insiden, dan bagaimana mengakses data bila perlu. 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 kami akan menggunakan fungsionalitas item kerja Azure DevOps untuk sistem pelacakan contoh kami.

Membuat bridge percakapan

Untuk menjawab beberapa pertanyaan di bagian "Menilai apa yang Anda ketahui" di atas 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 bridge telepon juga berfungsi. Panggilan konferensi/bridge telepon kurang disukai karena lebih sulit untuk meninjau komunikasi insiden secara surut (karenanya peran "penulis" yang disebutkan sebelumnya).

Media apa pun yang Anda pilih, Anda harus memastikan untuk membuat 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 kita.

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 ditentukan untuk mereka)
  • peran yang dapat kita tetapkan kepada orang-orang yang mengerjakan insiden
  • tempat tertentu kami akan mengumumkan insiden itu dan melacaknya
  • saluran unik bagi orang-orang yang mengerjakan insiden itu untuk mengomunikasikannya

Penciptaan dan pengelolaan semua hal ini dapat dan harus diotomatisasi semaksimal 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 Azure Logic Apps yang dapat menyederhanakan pekerjaan penjadwalan, mengotomatisasi, 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 data memenuhi kriteria yang ditentukan. Tindakan adalah operasi yang kemudian dilakukan dalam alur kerja Aplikasi Logika.

Untuk contoh kami, akan menggunakan konektor Aplikasi Logika 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 dihubungi sehingga Anda dapat menugaskan orang yang tepat untuk menanggapi insiden tersebut. Dalam contoh kami, kami akan menggunakan tabel Azure karena menawarkan penyimpanan "nilai kunci" yang sangat sederhana yang memudahkan untuk menyimpan daftar teknisi dan status panggilan mereka.
  • Microsoft Teams, yang dapat Anda gunakan untuk membuat saluran insiden baru yang unik untuk melacak percakapan tim teknisi Anda secara real time saat mereka berkomunikasi tentang insiden tertentu. Ini akan memungkinkan Anda untuk mempertahankan interaksi dalam kaitannya 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 pada Perancang Azure Logic Apps, lalu kita akan menelusurinya selangkah demi selangkah.

Memperkecil tampilan logic apps seperti yang ditampilkan di Perancang Logic Apps.

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:

 HTTP dan blok Respons dalam tampilan Perancang Logic Apps dari Logic Apps.

Dengan menggunakan informasi ini, kami membuat item kerja baru di organisasi Azure DevOps kami yang mewakili insiden ini.

Buat blok item kerja dalam tampilan Desainer Logic Apps dari Logic Apps.

Kemudian akan membuat saluran tim baru untuk insiden tersebut.

 Buat blok saluran Teams dalam tampilan Perancang Logic Apps dari Logic Apps.

Setelah ini dibuat, item pekerjaan 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.

Perbarui blok item kerja dalam tampilan Perancang Logic Apps dari Logic Apps.

Sekarang saatnya untuk membawa orang yang dipanggil ke dalam foto. Kami melakukan pencarian di tabel Azure untuk alamat email teknisi yang tercantum sebagai sedang dalam panggilan. Ini mengembalikan respons JSON yang kemudian kami urai.

Dapatkan blok entitas dalam tampilan Perancang Logic Apps dari Logic Apps.

Karena kueri kami akan mengembalikan daftar, kami perlu mengulangi setiap item dalam daftar itu sebagai langkah berikutnya. Kami menetapkan item pekerjaan untuk setiap orang (mereka sekarang adalah "pemilik" insiden).

 Foreach block dalam tampilan Perancang Logic App dari Logic App.

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 resmi untuk insiden itu disimpan.

Posting pesan sebagai blok saluran bot Flow dalam tampilan Perancang Logic Apps dari Logic Apps.

Jadi, itu hanya salah satu contoh bagaimana kami dapat mengotomatiskan pengaturan mekanisme untuk pelacakan insiden dan komunikasi. Di pelajaran berikutnya, kita akan menyelami sedikit lebih dalam aspek komunikasi seputar sebuah insiden.

Uji pengetahuan Anda

1.

Manakah dari pertanyaan-pertanyaan ini yang tidak langsung berguna untuk ditanyakan tentang suatu insiden ketika Anda mengevaluasi proses pelacakan insiden Anda?

2.

Saat membuat bridge percakapan untuk mengomunikasikan tentang suatu insiden, mengapa penting untuk membuat saluran yang unik untuk itu?

3.

Manakah dari berikut ini yang benar?

4.

Alat mana yang dapat Anda gunakan untuk otomatisasi tanpa kode untuk mengotomatiskan respons awal Anda?