Manajemen insiden untuk beban kerja SaaS di Azure
Vendor perangkat lunak independen (ISV) untuk solusi software as a service (SaaS) harus mengoperasikan solusi untuk pelanggan mereka. Melakukannya membutuhkan pengaturan dan budaya organisasi yang menangani situasi produksi yang tidak terduga dengan lancar. Sebagai arsitek, Anda harus merancang proses dan alat manajemen yang sesuai.
Artikel ini memandu Anda dalam menyelaraskan budaya, proses, dan alat organisasi Anda untuk mendukung manajemen insiden solusi SaaS produksi.
Memahami tanggung jawab Anda sebagai penyedia layanan
Mengoperasikan solusi SaaS berarti Anda adalah departemen TI dan operasi 24x7 pelanggan Anda. Anda harus siap dengan staf, budaya, proses, dan alat yang tepat.
Pertimbangan Desain
Bertanggung jawab atas dukungan 24x7x365. Mengoperasikan solusi SaaS mengharuskan organisasi Anda untuk selalu siap untuk respons insiden. Persiapan ini termasuk selalu memiliki anggota tim yang tersedia karena insiden dapat terjadi di luar jam kerja.
Dukungan situs langsung melibatkan pemantauan real-time dan merespons insiden yang memengaruhi ketersediaan sistem, keamanan, performa, atau penyebaran. Anda atau pelanggan Anda dapat mendeteksi insiden tersebut. Untuk menangani insiden tersebut, Anda memerlukan keterampilan khusus, termasuk kemampuan untuk menganalisis dan menyelesaikan masalah di bawah tekanan.
Dukungan situs langsung bisa membuat stres, dan penting untuk mendukung anggota tim Anda. Jika tim baru dalam tanggung jawab ini, rencanakan transisi dengan hati-hati. Atasi kekhawatiran tentang tugas panggilan, kompensasi, dan pengelolaan tidak tersedia selama insiden.
Risiko: Manajemen keterampilan dan ekspektasi. Tidak semua teknisi cocok untuk peran dukungan 24x7x365. Saat melakukan transisi tim yang sudah ada sebelumnya untuk mendukung solusi SaaS, pastikan harapan yang tepat telah ditetapkan dan peluang pendidikan disediakan.
Menerapkan budaya situs langsung. Pertimbangkan bagaimana Anda mengelola kasus dan insiden dukungan serta bagaimana eskalasi terjadi. Tujuannya adalah untuk memastikan bahwa anggota tim memahami tanggung jawab mereka dan memiliki keterampilan dan alat yang diperlukan untuk menangani insiden.
Startup dan organisasi yang lebih kecil mungkin memiliki rencana ringan untuk masalah situs langsung. Teknisi awalnya mungkin berfungsi sebagai dukungan garis depan dengan menanggapi kasus dukungan pelanggan. Organisasi dewasa, atau penyedia SaaS dengan pelanggan perusahaan, membutuhkan dukungan yang lebih terstruktur dan tim khusus.
Tradeoff: Keunggulan dan biaya operasional. Mengelola peristiwa situs langsung dapat mengurangi waktu pengembangan untuk fitur baru atau perbaikan bug. Jika kecepatan pengembangan menjadi perhatian, pertimbangkan untuk mempekerjakan sumber daya situs langsung khusus.
Rekomendasi desain
Rekomendasi | Keuntungan |
---|---|
Perkenalkan tim garis depan untuk menangani kasus dukungan. Untuk kasus yang kompleks, tim ini mengumpulkan informasi yang dibutuhkan tim teknik untuk penyelidikannya. Vendor dapat berfungsi sebagai tim dukungan garis depan Anda dan melakukan analisis masalah awal dan menyelesaikan masalah sederhana. |
Anda menghindari membebani tim teknik dengan tanggung jawab penanganan insiden dan berurusan dengan gangguan terhadap tugas rutin mereka. |
Berinvestasi dalam fungsi panggilan agar teknisi menangani kasus yang kompleks, menyelidiki, dan mengambil tindakan. Jika memungkinkan, putar tanggung jawab saat panggilan di antara anggota tim, dengan setiap insinyur sedang dipanggil selama beberapa hari pada satu waktu. |
Dengan tanggung jawab dan jalur eskalasi yang terdefinisi dengan baik, Anda dapat dengan cepat mengidentifikasi dan mengatasi masalah tanpa mengganggu alur kerja teknik Anda. |
Mendapatkan alat yang khusus untuk manajemen insiden. Pastikan semua responden memiliki akses ke dan memahami cara menggunakan alat ini secara efektif. Pilih alat yang dapat memantau status sistem, melacak masalah yang dilaporkan pelanggan, mengidentifikasi masalah, meningkatkan ke teknisi panggilan, mengelola insinyur yang tidak responsif, dan memungkinkan membuat perubahan dalam produksi. |
Memiliki alat yang tepat membantu tim on-call Anda dengan cepat mengidentifikasi dan menyelesaikan insiden sambil menjaga keamanan dan kontrol operasional. |
Tingkatkan pemantauan, penyebaran, pembaruan, dan operasi manajemen reguler lainnya. | Dengan berinvestasi dalam kematangan operasional, Anda mengurangi kemungkinan masalah situs langsung. Jika masalah terjadi, memiliki operasi yang terdefinisi dengan baik di tempat mempersingkat waktu resolusi. |
Tentukan rencana respons Anda
Mengakui bahwa insiden tidak dapat dihindari dan mempersiapkannya dengan menentukan rencana respons insiden. Pendekatan proaktif ini mencegah Anda harus menyusun strategi respons selama insiden pertama Anda.
Rencanakan ke depan untuk insiden besar, yang biasanya memengaruhi kemampuan pelanggan Anda untuk menggunakan layanan Anda. Persiapan ini membantu meminimalkan stres dan kompleksitas ketika Anda mengelola insiden saat terjadi.
Pertimbangan Desain
Tentukan jalur eskalasi. Pastikan bahwa tim memahami proses eskalasi untuk tugas dukungan. Dalam banyak solusi SaaS, pelanggan menghubungi tim dukungan garis depan, yang kemudian berkomunikasi dengan tim teknik. Pastikan pelanggan tahu dengan siapa berinteraksi dan mengapa mereka tidak boleh melewati proses ini. Selain itu, pastikan tim teknik Anda mengetahui kapan dan cara mencari bantuan dari vendor, termasuk tim dukungan di Microsoft.
Tentukan tingkat keparahan. Insiden yang berbeda bervariasi penting bagi Anda dan pelanggan Anda. Cara Anda menangani pemadaman produksi utama berbeda dari cara Anda mengatasi bug kecil. Tentukan tingkat keparahan berdasarkan dampak pelanggan dan tetapkan ekspektasi dan garis waktu yang sesuai untuk setiap tingkat.
Informasi dokumen yang Anda butuhkan untuk triase. Menjaga dokumentasi tetap terbaru sangat penting untuk respons insiden yang efektif. Dokumentasi ini mencakup tata letak arsitektur sistem, detail tingkat komponen, pemilik, dan kontak utama. Informasi yang tidak akurat atau ketinggalan jaman dapat menyebabkan tim respons insiden membuang waktu berharga untuk mencari tahu operasi sistem, tanggung jawab, dan dampak potensial dari insiden tersebut.
Rencanakan komunikasi yang efektif kepada pelanggan. Menyediakan pembaruan status adalah kunci dalam manajemen insiden. Pembaruan status membantu pelanggan Anda memahami sifat insiden dan juga mengurangi volume kasus dukungan dari pelanggan yang mengalami masalah serupa.
Rekomendasi desain
Rekomendasi | Keuntungan |
---|---|
Berikan proses pelaporan insiden yang jelas, seperti membuka kasus dukungan dengan tim dukungan garis depan Anda, kepada pelanggan Anda. | Anda memastikan konsistensi dalam cara Anda menemukan dan merespons insiden, yang mengurangi waktu penyelesaian dan mencegah informasi hilang atau diabaikan. |
Dokumentasikan tata letak arsitektur, detail tingkat komponen, klasifikasi privasi atau keamanan, pemilik, dan kontak utama. | Tim triase memiliki informasi yang tersedia dan dapat fokus pada penyelidikan dan menilai dampak. |
Pastikan tim respons insiden Anda dapat mengakses aset dan sistem yang diperlukan, seperti log. Mereka juga harus dapat membuat perubahan produksi melalui proses yang aman dan terkontrol. | Anda memulihkan operasi dengan lebih cepat dengan memastikan bahwa tim Anda tidak membuang-buang waktu. |
Gunakan halaman status komersial alih-alih membangun halaman Anda sendiri. | Hemat waktu dengan menggunakan halaman status komersial. Halaman status yang dihosting oleh organisasi lain juga tetap dapat diakses oleh pelanggan selama pemadaman pada sistem Anda. |
Mengelola insiden secara metodis
Mematuhi rencana yang ditentukan sangat penting untuk menghindari improvisasi selama waktu respons. Pendekatan ini membantu meminimalkan stres dan kompleksitas pengelolaan situasi ini.
Pertimbangan Desain
Tetapkan tingkat keparahan insiden. Gunakan rencana respons insiden Anda untuk menentukan tingkat keparahan insiden. Pelanggan sering frustrasi selama insiden. Penting bagi Anda untuk memahami dampak yang mereka lihat sehingga Anda dapat memprioritaskan. Komunikasikan tingkat keparahan insiden dengan jelas sehingga pelanggan memiliki harapan yang realistis.
Tetap tenang dan berpikir jernih. Insiden dapat membuat stres dan ambigu, dengan beberapa pemangku kepentingan menuntut perhatian. Memiliki proses yang jelas untuk siapa yang memimpin dalam insiden. Insiden triase sebaik mungkin sambil mengakui bahwa Anda mungkin harus beroperasi dengan informasi yang tidak sempurna. Cobalah untuk tetap mengendalikan situasi.
Pemimpin organisasi dapat membantu dengan melindungi anggota tim yang secara aktif menyelidiki atau mengurangi insiden.
Mengomunikasikan status kepada pelanggan Anda. Perbarui halaman status untuk menerbitkan informasi yang cukup. Berkomunikasi dengan segera dan berikan informasi yang diperlukan seperti perkiraan waktu resolusi. Beri pelanggan pembaruan yang sering untuk menjaga kepercayaan mereka.
Rekomendasi desain
Rekomendasi | Keuntungan |
---|---|
Selama insiden, prioritaskan pemulihan daripada penemuan. Ketika insiden terjadi, prioritaskan pemulihan operasi dengan cepat untuk meminimalkan gangguan pada pelanggan Anda. |
Anda mungkin dapat memulihkan dengan merutekan sekitar komponen yang terpengaruh atau dengan mengembalikan pembaruan, bahkan jika Anda belum memahami apa yang menyebabkan masalah. |
Berikan pembaruan yang tepat waktu, jelas, dan sering selama pemadaman. | Anda dapat menanamkan kepercayaan pelanggan dan mengurangi beban pada tim dukungan garis depan Anda. |
Menunjuk manajer komunikasi selama insiden aktif. Manajer ini mungkin satu orang, atau Anda mungkin memutar tanggung jawab di antara anggota tim antar insiden. | Dengan memiliki satu suara untuk tim teknik Anda, Anda memusatkan percakapan dan mengurangi gangguan kepada anggota tim lain. Anda juga mencegah informasi yang bertentangan menjangkau pelanggan atau pemangku kepentingan selama insiden kacau. |
Pastikan Anda memiliki rencana dukungan misi penting untuk vendor seperti Microsoft. | Jika pemadaman terjadi, Anda memerlukan komunikasi responsif dengan vendor platform seperti Microsoft untuk membantu Anda menentukan di mana masalahnya dan untuk mempersingkat durasi pemadaman. |
Melakukan tinjauan pasca-insiden
Setelah Anda pulih dari insiden, tinjau dan analisis apa yang terjadi untuk dipelajari dari insiden tersebut. Menerapkan tindakan remediasi, yang mungkin mencakup perubahan teknis, penyesuaian proses, atau lebih banyak pelatihan.
Pertimbangan Desain
Belajar dari insiden. Pemadaman menawarkan peluang belajar yang berharga. Lakukan tinjauan menyeluruh setelah insiden untuk mengidentifikasi pelajaran dan menerapkan perbaikan. Insiden besar sering memiliki beberapa penyebab. Evaluasi apakah lapisan lain dari solusi Anda, seperti proses operasional, dapat mencegah atau mendeteksi masalah sebelum meningkat. Selain itu, cari pola serupa di tempat lain dalam solusi Anda yang mungkin juga berisiko terhadap masalah yang sama.
Berkomunikasi dengan pelanggan Anda. Banyak ISV menyediakan komunikasi pasca-insiden, terutama untuk pelanggan perusahaan yang mengharapkan pembaruan berkualitas tinggi. Bersikap transparan dan berikan informasi yang cukup bagi pelanggan untuk memahami masalah dan langkah-langkah mitigasi. Namun, untuk menjaga keamanan dan integritas, hindari berbagi detail internal yang berlebihan tentang arsitektur atau komponen solusi Anda.
Rekomendasi desain
Rekomendasi | Keuntungan |
---|---|
Buat proses untuk melakukan tinjauan pasca-insiden internal. Fokus pada mengidentifikasi alasan yang berkontribusi pada masalah. Pertimbangkan penyebab teknis, bagaimana proses Anda mungkin berkontribusi pada pemadaman, dan bagaimana Anda merespons insiden tersebut. |
Tinjauan pasca-insiden internal membantu Anda belajar dari pemadaman produksi dan meminimalkan risiko masalah serupa terjadi lagi. |
Buat rencana terstruktur untuk mengatasi item apa pun yang memerlukan remediasi. Sertakan akuntabilitas dan garis waktu yang jelas. | Akuntabilitas yang jelas membantu Anda memastikan bahwa setiap peran memenuhi harapan fungsionalnya, meningkatkan kejelasan, dan memungkinkan pelaporan transparan pada tingkat yang diinginkan. |
Terbitkan ulasan pasca-insiden yang dihadapi pelanggan. Berikan pelanggan detail yang cukup untuk memahami masalah dan langkah-langkah mitigasi tanpa mengungkapkan detail internal atau arsitektur sistem yang tidak perlu. Komunikasi pasca-insiden harus selalu ditulis dan diterbitkan oleh manusia. Pemangku kepentingan teknis dan nonteknis harus meninjau komunikasi untuk akurasi dan kejelasan. |
Pendekatan ini membantu menjaga kepercayaan pelanggan dan meyakinkan mereka bahwa Anda belajar dari insiden dan mengatasi masalah yang diidentifikasi. |
Langkah selanjutnya
Setelah meninjau area desain, lanjutkan ke alat penilaian untuk mengevaluasi desain Anda.