View a markdown version of this page

Menggunakan analisis 5 Mengapa dalam laporan insiden - Amazon CloudWatch
Apa itu analisis 5 Mengapa?Manfaat untuk pelaporan insidenContoh skenario dalam laporan insidenMenggunakan alur kerja 5 Whys yang dipanduMenangani insiden kompleks dengan berbagai penyebabPraktik terbaik untuk analisis 5 Whys yang efektif

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

Menggunakan analisis 5 Mengapa dalam laporan insiden

Saat membuat laporan insiden, CloudWatch investigasi dapat melakukan analisis akar penyebab 5 Whys untuk secara sistematis mengidentifikasi penyebab yang mendasari masalah operasional. Pendekatan terstruktur ini meningkatkan laporan insiden Anda dengan wawasan yang lebih dalam dan langkah-langkah remediasi yang dapat ditindaklanjuti.

Fitur ini menggunakan Amazon Q untuk menyediakan obrolan percakapan. Pengguna yang masuk ke Konsol Manajemen AWS harus memiliki izin berikut:

{ 
    "Sid" : "AmazonQAccess",
    "Effect" : "Allow",
    "Action" : [
       "q:StartConversation", 
       "q:SendMessage", 
       "q:GetConversation", 
       "q:ListConversations", 
       "q:UpdateConversation", 
       "q:DeleteConversation", 
       "q:PassRequest" 
     ],
    "Resource" : "*"
 }

Anda dapat menambahkan izin ini secara langsung, atau dengan melampirkan kebijakan AIOpsConsoleAdminPolicy atau kebijakan yang AIOpsOperatorAccess dikelola ke pengguna atau peran.

Apa itu analisis 5 Mengapa?

The 5 Whys adalah teknik analisis akar penyebab yang menanyakan “mengapa” berulang kali untuk menelusuri dari gejala insiden ke penyebab mendasar. Setiap jawaban menjadi dasar untuk pertanyaan berikutnya, menciptakan rantai logis yang mengungkapkan akar penyebab sebenarnya daripada hanya gejala tingkat permukaan.

Selama pembuatan laporan insiden, CloudWatch investigasi menggunakan metode ini untuk menganalisis temuan investigasi dan memberikan analisis akar penyebab terstruktur yang melampaui kegagalan teknis langsung untuk mengidentifikasi proses, konfigurasi, atau masalah sistemik.

Manfaat untuk pelaporan insiden

Memasukkan analisis 5 Mengapa dalam laporan insiden memberikan beberapa keuntungan:

  • Identifikasi akar penyebab komprehensif - Bergerak melampaui penyebab teknis langsung untuk mengidentifikasi proses yang mendasarinya atau masalah sistem

  • Rencana remediasi yang dapat ditindaklanjuti - Menyediakan tindakan spesifik yang ditargetkan untuk mencegah terulangnya daripada perbaikan sementara

  • Pembelajaran organisasi - Mendokumentasikan rantai sebab-akibat lengkap untuk referensi di masa depan dan berbagi pengetahuan tim

  • Analisis terstruktur - Memastikan penyelidikan sistematis daripada pemecahan masalah ad-hoc

Contoh skenario dalam laporan insiden

Insiden kegagalan koneksi database

Insiden awal: E-commerce aplikasi mengalami 500 kesalahan yang meluas

  1. Mengapa 1: Mengapa pengguna mendapatkan 500 kesalahan? Aplikasi tidak dapat terhubung ke database utama.

  2. Mengapa 2: Mengapa aplikasi tidak dapat terhubung ke database? Instance database kehabisan koneksi yang tersedia.

  3. Mengapa 3: Mengapa database kehabisan koneksi? Pekerjaan pemrosesan batch membuka banyak koneksi tanpa menutupnya dengan benar.

  4. Mengapa 4: Mengapa pekerjaan batch tidak menutup koneksi dengan benar? Penanganan kesalahan pekerjaan tidak menyertakan pembersihan koneksi dalam skenario kegagalan.

  5. Mengapa 5: Mengapa penanganan kesalahan yang tepat tidak diterapkan? Proses peninjauan kode tidak menyertakan pemeriksaan khusus untuk pola manajemen sumber daya.

Akar penyebab: Standar tinjauan kode yang tidak memadai untuk manajemen sumber daya

Tindakan yang disarankan: Perbarui daftar periksa tinjauan kode, terapkan pemantauan pengumpulan koneksi, tambahkan deteksi kebocoran sumber daya otomatis

Insiden penurunan kinerja

Insiden awal: Waktu respons API meningkat dari 200ms menjadi 5000ms selama lonjakan lalu lintas

  1. Mengapa 1: Mengapa waktu respons meningkat? Pemanfaatan CPU mencapai 100% pada semua instance aplikasi.

  2. Mengapa 2: Mengapa penskalaan otomatis tidak menambahkan lebih banyak instance? Penskalaan otomatis dipicu tetapi instans baru gagal dalam pemeriksaan kesehatan.

  3. Mengapa 3: Mengapa instans baru gagal dalam pemeriksaan kesehatan? Proses startup aplikasi memakan waktu 8 menit, lebih lama dari batas waktu pemeriksaan kesehatan.

  4. Mengapa 4: Mengapa startup memakan waktu begitu lama? Aplikasi mengunduh file konfigurasi besar dari S3 pada setiap startup.

  5. Mengapa 5: Mengapa penundaan startup ini tidak dipertimbangkan dalam konfigurasi penskalaan otomatis? Pengujian kinerja dilakukan dengan contoh yang sudah dipanaskan sebelumnya, bukan start dingin.

Akar penyebab: Metodologi pengujian kinerja tidak mencerminkan skenario penskalaan otomatis produksi

Tindakan yang disarankan: Ser takan pengujian start dingin, optimalkan startup aplikasi, sesuaikan batas waktu pemeriksaan kesehatan, terapkan cache konfigurasi

Insiden kompleks dengan analisis cabang

Insiden awal: Pel OpenSearch anggan tanpa server mengalami penurunan ketersediaan 48,3% selama 11 jam

RanTAI analisis utama:

  1. Mengapa 1: Mengapa pelanggan mengalami degradasi layanan? Ketersediaan layanan turun menjadi 48,3% karena penskalaan ingester yang salah.

  2. Mengapa 2: Mengapa penskalaan ingester salah? CortexOperator mengurangi ingester dari 223 menjadi 174 karena kesalahan perhitungan saldo AZ.

  3. Mengapa 3: Mengapa saldo AZ CortexOperator salah menghitung? Kode tidak dapat memproses format label Kubernetes baru setelah peningkatan versi 1.17.

  4. Mengapa 4 (Cabang A - Teknis): Mengapa kode tidak menangani format label baru? Kode diharapkan 'failure-domain.beta.kubernetes. io/zone' label tetapi Kubernetes 1.17 diubah menjadi 'topology.kubernetes. io/zone'.

  5. Mengapa 5 (Cabang A): Mengapa kompatibilitas mundur tidak diterapkan? Perubahan format label tidak didokumentasikan dalam catatan peningkatan yang ditinjau selama perencanaan penerapan.

Cabang B - Analisis Proses:

  1. Mengapa 4 (Cabang B - Proses): Mengapa ini tidak tertangkap dalam pengujian? Tes integrasi menggunakan cluster pra-konfigurasi dengan format label lama.

  2. Mengapa 5 (Cabang B): Mengapa pengujian tidak menyertakan validasi format label? Pengaturan lingkungan pengujian tidak mencerminkan urutan peningkatan versi Kubernetes produksi.

Akar penyebab diidentifikasi:

  • Teknis: Hilangnya kompatibilitas mundur untuk perubahan format label Kubernetes

  • Proses: Metodologi pengujian tidak memvalidasi dampak peningkatan versi

Rencana remediasi terintegrasi: Menerapkan logika deteksi format label, tingkatkan prosedur pengujian peningkatan, tambahkan validasi kompatibilitas otomatis, dan buat proses penilaian dampak perubahan versi.

Menggunakan alur kerja 5 Whys yang dipandu

CloudWatch investigasi menyediakan alur kerja analisis 5 Whys yang dipandu untuk membantu Anda mengatasi fakta yang hilang dan memperkuat laporan insiden Anda. Fitur ini muncul sebagai alur kerja yang disarankan ketika sistem mengidentifikasi peluang untuk meningkatkan analisis akar penyebab.

Pengalaman analisis interaktif

Analisis 5 Mengapa dalam CloudWatch investigasi menggunakan pendekatan interaktif berbasis obrolan yang memandu Anda melalui proses investigasi. Metode percakapan ini membantu memastikan analisis komprehensif sambil mempertahankan aliran logis antar pertanyaan.

Fitur utama dari pengalaman interaktif:

  • Fact-based inisialisasi - Sistem menyajikan fakta-fakta yang relevan dari penyelidikan Anda di muka, menggunakannya untuk mengisi jawaban yang jelas sebelumnya dan dengan jelas menunjukkan saran berbasis fakta versus saran berbasis inferensi

  • Penyelidikan terpandu - Untuk setiap pertanyaan “mengapa”, sistem menyarankan jawaban berdasarkan fakta yang tersedia, meminta konteks tambahan tertentu, dan memandu Anda untuk mempertimbangkan aspek-aspek penting sebelum melanjutkan

  • Manajemen cabang - Ketika beberapa faktor yang berkontribusi diidentifikasi, sistem dengan jelas menyajikan opsi cabang, menjelaskan hubungan antar cabang, dan membantu memprioritaskan investigasi paralel

  • Validasi progresif - Untuk setiap respons, sistem merumuskan ulang jawaban untuk kejelasan, mencari konfirmasi, menyoroti wawasan utama, dan menghubungkan temuan ke konteks yang lebih luas

Pendekatan ini memastikan bahwa Anda menangkap semua informasi yang relevan sambil mempertahankan fokus pada hubungan sebab-akibat yang paling kritis.

Mengakses alur kerja yang dipandu:

  1. Selama pembuatan laporan insiden, tinj au bagian Fakta perlu perhatian di panel kanan.

  2. Cari saran analisis 5-Mengapa Terpandu di bawah Alur kerja yang disarankan.

  3. Pilih Panduan saya untuk memulai proses 5 Whys interaktif.

  4. Ikuti petunjuk yang dipandu untuk secara sistematis mengerjakan setiap pertanyaan “mengapa”, membangun rantai sebab-akibat lengkap dari gejala hingga akar penyebab.

Alur kerja yang dipandu membantu memastikan Anda menangkap informasi akar penyebab yang komprehensif dengan memandu Anda melalui setiap langkah metodologi 5 Mengapa. Hasil analisis secara otomatis dimasukkan ke dalam laporan insiden Anda, menyediakan dokumentasi terstruktur untuk tinjauan pasca-insiden dan pembelajaran organisasi.

Anda juga dapat meminta analisis 5 Mengapa melalui antarmuka obrolan dengan mengajukan pertanyaan seperti “Lakukan analisis 5 Mengapa untuk insiden ini” atau “Apa akar penyebab menggunakan metodologi 5 Mengapa?”

Menangani insiden kompleks dengan berbagai penyebab

Beberapa insiden melibatkan beberapa faktor yang berkontribusi yang memerlukan jalur analisis paralel. CloudWatch Investigasi mendukung analisis cabang untuk memastikan semua penyebab signifikan diidentifikasi dan diatasi.

Ketika analisis cabang diperlukan:

  • Beberapa kegagalan independen terjadi secara bersamaan

  • Komponen sistem yang berbeda berkontribusi pada dampak pelanggan yang sama

  • Kegagalan teknis dan proses memainkan peran penting

  • Kegagalan berjenjang menciptakan beberapa rantai sebab-akibat

Proses analisis cabang:

  1. Identifikasi cabang - Sistem mengidentifikasi titik-titik di mana beberapa penyebab bertemu atau menyimpang

  2. Investig asi paralel - Setiap cabang dianalisis menggunakan metodologi 5 Whys lengkap

  3. Pemetaan koneksi - Hubungan antar cabang didokumentasikan untuk menunjukkan bagaimana mereka berinteraksi

  4. Resolusi terpadu - Rencana remediasi mengatasi semua akar penyebab yang teridentifikasi dan interaksinya

Pendekatan komprehensif ini memastikan bahwa insiden kompleks menerima analisis menyeluruh dan bahwa semua faktor yang berkontribusi ditangani dalam rencana perbaikan akhir.

Praktik terbaik untuk analisis 5 Whys yang efektif

Untuk memaksimalkan efektivitas analisis 5 Whys dalam laporan insiden Anda, ikuti praktik terbaik berikut yang berasal dari pengalaman operasional:

Pedoman formulasi pertanyaan

  • Mulailah dengan dampak pelanggan - Mulailah setiap analisis dengan masalah yang dihadapi pelanggan untuk mempertahankan fokus pada dampak bisnis

  • Tingkatkan kedalaman teknis secara progresif - Beralih dari dampak bisnis ke detail teknis saat Anda maju melalui pertanyaan

  • Pertahankan kontinuitas logis - Pastikan setiap jawaban secara alami mengarah ke pertanyaan berikutnya tanpa celah logis

  • Sertakan bukti pendukung - Referensikan metrik spesifik, log, atau peristiwa timeline untuk memvalidasi setiap jawaban

Validasi analisis

Validasi analisis 5 Mengapa Anda menggunakan kriteria ini:

  • Aliran logis - Hapus perkembangan dari gejala ke akar penyebab tanpa langkah yang hilang

  • Akurasi teknis - Terminologi yang benar, deskripsi perilaku sistem yang akurat, dan interaksi komponen yang valid

  • Kelengkapan - Analisis menjelaskan semua gejala yang diamati dan mencapai penyebab mendasar yang, jika ditangani, akan mencegah kekambuhan

  • Tindaklanjuti - Akar penyebab yang diidentifikasi mengarah ke tindakan remediasi yang spesifik dan dapat diterapkan

Perangkap umum yang harus dihindari

  • Berhenti pada gejala - Jangan menyimpulkan analisis pada kegagalan teknis pertama; lanjutkan sampai Anda mencapai penyebab sistemik atau proses

  • Blame-focused Analisis - Fokus pada kegagalan sistem dan proses daripada tindakan individu

  • Single-path berpikir - Pertimbangkan beberapa faktor yang berkontribusi dan gunakan analisis cabang bila sesuai

  • Bukti yang tidak mencukupi - Pastikan setiap jawaban didukung oleh data konkret dari penyelidikan Anda

Integrasi dengan bagian laporan insiden

Analisis 5 Whys terintegrasi dengan bagian lain dari laporan insiden Anda untuk memberikan dokumentasi yang komprehensif:

  • Korelasi garis waktu - Setiap pertanyaan “mengapa” dapat mereferensikan peristiwa garis waktu tertentu, memberikan konteks temporal untuk hubungan sebab-akibat

  • Validasi metrik - Jawaban didukung oleh metrik dan grafik yang menunjukkan perilaku teknis yang dijelaskan

  • Penyelarasan penilaian dampak - “mengapa” pertama secara langsung terhubung ke metrik dampak pelanggan yang didokumentasikan di bagian penilaian dampak

  • Dasar pelajaran yang di petik - Akar penyebab yang diidentifikasi melalui analisis 5 Mengapa secara langsung menginformasikan pelajaran yang dipetik dan bagian tindakan korektif

Integrasi ini memastikan konsistensi di seluruh laporan insiden Anda dan memberi para pemangku kepentingan narasi yang lengkap dan koheren mulai dari gejala awal hingga akar penyebab hingga rencana remediasi.