Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Tahap 5: Menanggapi dan belajar

Bagaimana aplikasi Anda merespons peristiwa yang mengganggu memengaruhi keandalannya. Belajar dari pengalaman dan bagaimana aplikasi Anda merespons gangguan di masa lalu juga penting untuk meningkatkan keandalannya. 

Tahap Menanggapi dan belajar berfokus pada praktik yang dapat Anda terapkan untuk merespons peristiwa yang mengganggu dalam aplikasi Anda dengan lebih baik. Ini juga mencakup praktik untuk membantu Anda menyaring jumlah pembelajaran maksimum dari pengalaman tim operasi dan insinyur Anda.

Membuat laporan analisis insiden

Ketika suatu insiden terjadi, tindakan pertama adalah mencegah kerugian lebih lanjut bagi pelanggan dan bisnis secepat mungkin. Setelah aplikasi pulih, langkah selanjutnya adalah memahami apa yang terjadi dan mengidentifikasi langkah-langkah untuk mencegah terulangnya kembali. Analisis pasca-insiden ini biasanya ditangkap sebagai laporan yang mendokumentasikan serangkaian peristiwa yang menyebabkan gangguan aplikasi, dan efek gangguan pada aplikasi, pelanggan, dan bisnis. Laporan semacam itu menjadi artefak pembelajaran yang berharga dan harus dibagikan secara luas di seluruh bisnis.

Laporan analisis insiden yang baik, seperti yang didokumentasikan dalam proses Amazon Correction of Error (COE), mengikuti format standar dan mencoba menangkap, sedetail mungkin, kondisi yang menyebabkan gangguan aplikasi. Laporan tersebut merinci serangkaian peristiwa yang dicap waktu dan menangkap data kuantitatif (seringkali metrik dan tangkapan layar dari dasbor pemantauan) yang menggambarkan keadaan aplikasi yang dapat diukur selama garis waktu. Laporan tersebut harus menangkap proses pemikiran operator dan insinyur yang mengambil tindakan, dan informasi yang membawa mereka pada kesimpulan mereka. Laporan tersebut juga harus merinci kinerja indikator yang berbeda―misalnya, alarm mana yang dinaikkan, apakah alarm tersebut secara akurat mencerminkan keadaan aplikasi, jeda waktu antara peristiwa dan alarm yang dihasilkan, dan waktu untuk menyelesaikan insiden tersebut. Garis waktu juga menangkap runbook atau otomatisasi yang dimulai dan bagaimana mereka membantu aplikasi mendapatkan kembali status yang berguna. Elemen-elemen timeline ini membantu tim Anda memahami efektivitas respons otomatis dan operator, termasuk seberapa cepat mereka mengatasi masalah dan seberapa efektif mereka dalam mengurangi gangguan tersebut.

Gambaran rinci tentang peristiwa sejarah ini adalah alat pendidikan yang ampuh. Tim harus menyimpan laporan ini di repositori pusat yang tersedia untuk seluruh bisnis sehingga orang lain dapat meninjau peristiwa dan belajar dari mereka. Ini dapat meningkatkan intuisi tim Anda tentang apa yang bisa salah dalam produksi.

Repositori laporan insiden terperinci juga menjadi sumber materi pelatihan bagi operator. Tim dapat menggunakan laporan insiden untuk menginspirasi hari pertandingan atas meja atau langsung, di mana tim diberi informasi yang memutar kembali garis waktu yang diambil dalam laporan. Operator dapat berjalan melalui skenario dengan sebagian informasi dari timeline dan menjelaskan tindakan apa yang akan mereka ambil. Moderator untuk hari permainan kemudian dapat memberikan panduan tentang bagaimana aplikasi merespons berdasarkan tindakan operator. Ini mengembangkan keterampilan pemecahan masalah operator, sehingga mereka dapat lebih mudah mengantisipasi dan memecahkan masalah.

Tim terpusat yang bertanggung jawab atas keandalan aplikasi harus memelihara laporan ini di perpustakaan terpusat yang dapat diakses oleh seluruh organisasi. Tim ini juga harus bertanggung jawab untuk memelihara template laporan dan tim pelatihan tentang cara menyelesaikan laporan analisis insiden. Tim reliabilitas harus meninjau laporan secara berkala untuk mendeteksi tren di seluruh bisnis yang dapat diatasi melalui pustaka perangkat lunak, pola arsitektur, atau perubahan pada proses tim.

Melakukan tinjauan operasional

Seperti yang dibahas dalam Tahap 4: Beroperasi, tinjauan operasional adalah kesempatan untuk meninjau rilis fitur terbaru, insiden, dan metrik operasional. Tinjauan operasional juga merupakan kesempatan untuk berbagi pembelajaran dari rilis fitur dan insiden dengan komunitas teknik yang lebih luas di organisasi Anda. Selama tinjauan operasional, tim meninjau penyebaran fitur yang dibatalkan, insiden yang terjadi, dan bagaimana penanganannya. Ini memberi para insinyur di seluruh organisasi kesempatan untuk belajar dari pengalaman orang lain dan mengajukan pertanyaan.

Buka ulasan operasional Anda ke komunitas teknik di perusahaan Anda sehingga mereka dapat mempelajari lebih lanjut tentang aplikasi TI yang menjalankan bisnis dan jenis masalah yang dapat mereka hadapi. Mereka akan membawa pengetahuan ini bersama mereka saat mereka merancang, mengimplementasikan, dan menyebarkan aplikasi lain untuk bisnis.

Meninjau kinerja alarm

Alarm, seperti yang dibahas dalam tahap operasi, dapat mengakibatkan peringatan dasbor, tiket dibuat, email dikirim, atau operator dihalaman.  Sebuah aplikasi akan memiliki banyak alarm yang dikonfigurasi untuk memantau berbagai aspek operasinya. Seiring waktu, keakuratan dan efektivitas alarm ini harus ditinjau untuk meningkatkan presisi alarm, mengurangi positif palsu, dan mengkonsolidasikan peringatan duplikat.

Alarm presisi

Alarm harus sespesifik mungkin untuk mengurangi jumlah waktu yang harus Anda habiskan untuk menafsirkan atau mendiagnosis gangguan spesifik yang menyebabkan alarm. Ketika alarm dinyalakan sebagai respons terhadap gangguan aplikasi, operator yang menerima dan menanggapi alarm harus terlebih dahulu menafsirkan informasi yang disampaikan alarm. Informasi tersebut mungkin kode kesalahan sederhana yang memetakan ke tindakan seperti prosedur pemulihan, atau mungkin termasuk baris dari log aplikasi yang harus Anda tinjau untuk memahami mengapa alarm dinyalakan. Saat tim Anda belajar mengoperasikan aplikasi dengan lebih efektif, mereka harus memperbaiki alarm ini untuk membuatnya sejelas dan sesingkat mungkin.

Anda tidak dapat mengantisipasi semua kemungkinan gangguan pada suatu aplikasi, sehingga akan selalu ada alarm umum yang mengharuskan operator untuk menganalisis dan mendiagnosis. Tim Anda harus bekerja untuk mengurangi jumlah alarm umum untuk meningkatkan waktu respons dan mengurangi mean time to repair (MTTR). Idealnya, harus ada one-to-one hubungan antara alarm dan respons otomatis atau yang dilakukan manusia.  

Positif palsu

Alarm yang tidak memerlukan tindakan dari operator tetapi menghasilkan peringatan karena email, halaman, atau tiket akan diabaikan oleh operator dari waktu ke waktu.  Secara berkala, atau sebagai bagian dari analisis insiden, tinjau alarm untuk mengidentifikasi alarm yang sering diabaikan atau tidak memerlukan tindakan dari operator (positif palsu).  Anda harus bekerja untuk menghapus alarm, atau meningkatkan alarm sehingga mengeluarkan peringatan yang dapat ditindaklanjuti kepada operator.

Negatif palsu

Selama insiden, alarm yang dikonfigurasi untuk memperingatkan selama insiden mungkin gagal, mungkin karena peristiwa yang memengaruhi aplikasi dengan cara yang tidak terduga.  Sebagai bagian dari analisis insiden, Anda harus meninjau alarm yang seharusnya dinaikkan tetapi tidak. Anda harus bekerja untuk meningkatkan alarm ini sehingga mereka lebih mencerminkan kondisi yang mungkin timbul dari suatu peristiwa. Atau, Anda mungkin harus membuat alarm tambahan yang memetakan ke gangguan yang sama tetapi dipicu oleh gejala gangguan yang berbeda.

Peringatan duplikatif

Gangguan yang mengganggu aplikasi Anda kemungkinan akan menyebabkan banyak gejala dan dapat mengakibatkan beberapa alarm.  Secara berkala, atau sebagai bagian dari analisis insiden, Anda harus meninjau alarm dan peringatan yang dikeluarkan.  Jika operator menerima peringatan duplikat, buat alarm agregat untuk mengkonsolidasikannya menjadi satu pesan peringatan.

Melakukan tinjauan metrik

Tim Anda harus mengumpulkan metrik operasional tentang aplikasi Anda, seperti jumlah insiden berdasarkan tingkat keparahan per bulan, waktu untuk mendeteksi insiden, waktu untuk mengidentifikasi penyebabnya, waktu untuk memulihkan, dan jumlah tiket yang dibuat, peringatan yang dikirim, dan halaman yang diangkat. Tinjau metrik ini setidaknya setiap bulan untuk memahami beban staf operasional, signal-to-noise rasio yang mereka tangani (misalnya, peringatan informasi versus yang dapat ditindaklanjuti), dan apakah tim meningkatkan kemampuannya untuk mengoperasikan aplikasi di bawah kendali mereka. Gunakan ulasan ini untuk memahami tren dalam aspek terukur dari tim operasi. Mintalah ide dari tim tentang cara meningkatkan metrik ini.  

Memberikan pelatihan dan pemberdayaan

Sulit untuk menangkap deskripsi rinci tentang aplikasi dan lingkungannya yang menyebabkan insiden atau perilaku tak terduga. Selain itu, memodelkan ketahanan aplikasi Anda untuk mengantisipasi skenario seperti itu tidak selalu mudah. Organisasi Anda harus berinvestasi dalam materi pelatihan dan pemberdayaan untuk tim operasi dan pengembang Anda untuk berpartisipasi dalam kegiatan seperti pemodelan ketahanan, analisis insiden, hari permainan, dan eksperimen rekayasa kekacauan. Ini akan meningkatkan kesetiaan laporan yang dihasilkan tim Anda dan pengetahuan yang mereka tangkap. Tim juga akan menjadi lebih siap untuk mengantisipasi kegagalan tanpa bergantung pada kelompok insinyur yang lebih kecil dan lebih berpengalaman yang harus memberikan wawasan mereka melalui tinjauan terjadwal.

Menciptakan basis pengetahuan insiden

Laporan insiden adalah output standar dari analisis insiden. Anda harus menggunakan laporan yang sama atau serupa untuk mendokumentasikan skenario di mana Anda mendeteksi perilaku aplikasi anomali, meskipun aplikasi tidak mengalami gangguan. Gunakan struktur laporan standar yang sama untuk menangkap hasil eksperimen chaos dan hari permainan. Laporan tersebut mewakili snapshot dari aplikasi dan lingkungannya yang menyebabkan insiden atau perilaku yang tidak terduga. Anda harus menyimpan laporan standar ini di repositori pusat yang dapat diakses oleh semua insinyur dalam bisnis.  

Tim operasi dan pengembang kemudian dapat mencari basis pengetahuan ini untuk memahami apa yang telah mengganggu aplikasi di masa lalu, jenis skenario apa yang dapat menyebabkan gangguan, dan apa yang mencegah kerusakan aplikasi. Basis pengetahuan ini menjadi akselerator untuk meningkatkan keterampilan tim operasi Anda dan pengembang Anda, dan memungkinkan mereka untuk berbagi pengetahuan dan pengalaman mereka. Selain itu, Anda dapat menggunakan laporan sebagai materi pelatihan atau skenario untuk hari permainan atau eksperimen kekacauan untuk meningkatkan intuisi dan kemampuan tim operasional untuk memecahkan masalah gangguan.

Menerapkan ketahanan secara mendalam

Seperti dibahas sebelumnya, organisasi tingkat lanjut akan menerapkan beberapa tanggapan terhadap alarm. Tidak ada jaminan bahwa respons akan efektif, sehingga dengan melapisi tanggapan aplikasi akan lebih siap untuk gagal dengan anggun. Kami menyarankan Anda menerapkan setidaknya dua tanggapan untuk setiap indikator untuk memastikan bahwa respons individu tidak menjadi satu titik kegagalan yang mungkin mengarah pada skenario DR.  Lapisan ini harus dibuat dalam urutan serial, sehingga respons berturut-turut dilakukan hanya jika respons sebelumnya tidak efektif. Anda tidak boleh menjalankan beberapa respons berlapis ke satu alarm. Sebagai gantinya, gunakan alarm yang menunjukkan apakah respons tidak berhasil, dan, jika demikian, memulai respons berlapis berikutnya.