Apakah tim teknik Anda mengalami kelelahan waspada? Ajukan 8 pertanyaan ini

Kelelahan waspada adalah masalah umum di antara tim teknik yang menangani operasi dan memelihara infrastruktur.

Masalahnya biasanya berasal dari pendekatan yang serampangan untuk menulis peringatan saat tim tumbuh dan mulai menggunakan lebih banyak infrastruktur dengan kompleksitas yang meningkat. Hal ini cukup normal – seiring dengan pertumbuhan perusahaan atau tim, seringkali dibutuhkan waktu untuk membentuk budaya observasi dan praktik peringatan yang solid.

Sangat mudah untuk membuat peringatan yang terlalu sensitif, terlalu berisik, dan terlalu berhati-hati. Pada awalnya, semuanya tampak layak waspada hanya karena lebih baik berhati-hati dan memaksimalkan sinyal produksi pada tahap awal suatu produk.

“Seiring bertambahnya jumlah dan kompleksitas fitur dan infrastruktur, meningkatkan peringatan biasanya jauh di bawah daftar prioritas”

Secara alami, pendekatan ini tidak berskala dengan baik, tetapi dengan bertambahnya jumlah dan kompleksitas fitur dan infrastruktur, meningkatkan peringatan biasanya jauh di bawah daftar prioritas. Hasilnya adalah banyak peringatan semi-bermakna, kebisingan, pengalihan konteks, dan multitasking untuk insinyur panggilan. Dalam kasus yang ekstrem, rekan satu tim kelelahan, peringatan diabaikan, dan tim panggilan Anda beralih dari meningkatkan kualitas layanan menjadi pemadam kebakaran terus-menerus tanpa dampak yang berarti.

Seperti semua perusahaan, Intercom tidak kebal terhadap inefisiensi ini. Jadi kami merancang proses yang relatif ringan untuk melawan kelelahan yang waspada.

Bagaimana kami berpikir tentang strategi peringatan

Konsep "disiplin kewaspadaan" adalah inti dari pengendalian peringatan. Seperti pekerjaan fitur, peringatan dan strategi peringatan harus didekati dengan cara yang disengaja dan terstruktur. Tidak seperti pekerjaan fitur, itu bukan sesuatu yang dapat direncanakan dengan baik sebelumnya.

Lagi pula, sangat kecil kemungkinannya Anda dapat memprediksi kesehatan operasional dan kebisingan fitur baru Anda sebelum mengirimkannya. Anda harus memantau peringatan secara teratur dan terencana sehingga upaya peringatan tidak merambat ke tingkat yang tidak berkelanjutan.

8 pertanyaan untuk ditanyakan saat menilai peringatan tim Anda

Kami memperkenalkan sesi tinjauan lansiran reguler untuk tim yang menangani lansiran sering. Ini awalnya terjadi sekali – atau beberapa kali – per siklus rekayasa enam minggu, tetapi menjadi lebih jauh karena status peringatan dan monitor meningkat ke tingkat yang lebih mudah dikelola.

Setiap sesi peninjauan lansiran dimulai dengan daftar lansiran yang diurutkan yang diaktifkan pada periode sebelumnya, diurutkan berdasarkan frekuensi pengaktifannya. Kami menggunakan platform PagerDuty sebagai sumber peringatan kami, dan fitur analitiknya memberi kami informasi yang kami butuhkan untuk merinci frekuensi dan respons peringatan. Peringatan yang paling berkontribusi terhadap kebisingan secara keseluruhan (yaitu kebakaran paling sering) ditinjau terlebih dahulu.

Setiap peringatan kemudian melewati daftar pertanyaan:

1. Apakah lansiran masih relevan?

Peringatan apa pun yang dipicu oleh sistem yang ketinggalan zaman atau tidak terawat tidak boleh mengganggu teknisi panggilan dan harus segera dihapus.

2. Apakah peringatan tersebut dapat ditindaklanjuti?

Jika teknisi panggilan menerima peringatan, dapatkah mereka melakukan sesuatu sekarang untuk memperbaiki atau meningkatkan penyebab yang mendasarinya? Jika lansiran tidak dapat ditindaklanjuti dan bermanfaat, lansiran tersebut harus dihapus. Ringkasan masalah atau penurunan kinerja mingguan mungkin menjadi tempat yang lebih baik untuk informasi dalam peringatan.

3. Apakah informasi dalam peringatan segera berguna meskipun tidak dapat ditindaklanjuti?

Kami dapat membagi informasi peringatan menjadi dua kategori besar.

• Sinyal: Peringatan ini memperingatkan sistem yang beroperasi pada batasnya, tetapi tidak berarti layanan terpengaruh. Contohnya adalah salah satu server Anda berjalan pada CPU 100%. Jika layanan masih beroperasi dengan baik, apakah panggilan harus menghabiskan waktu yang berharga untuk menyelidiki? Lagi pula, server Anda hanya bekerja pada rasio pekerjaan-untuk-biaya terbaik!
• Gejala: Peringatan ini aktif saat pengalaman pelanggan terpengaruh. Contoh di sini adalah jumlah kesalahan HTTP 5XX yang dikembalikan layanan Anda ke penelepon.

Kedua kategori ini bekerja paling baik bersama-sama. Orang yang siap dihubungi harus bereaksi dan memecahkan masalah gejala, dan melihat sinyal hanya sebagai sumber informasi lebih lanjut.

4. Jika alert dapat ditindaklanjuti dan paging, apakah perlu segera ditangani?

Jika masalah tidak perlu segera ditangani, seharusnya tidak membangunkan siapa pun di tengah malam. Tim harus memutuskan cara alternatif untuk memunculkan informasi dalam peringatan dalam situasi ini, misalnya, pemberitahuan Slack atau dasbor, atau tugas yang dibuka dalam mekanisme pelacakan masalah.

5. Jika dapat ditindaklanjuti, apakah ada runbook atau tautan pemecahan masalah? Apakah langkah-langkahnya cukup jelas untuk diikuti oleh insinyur mana pun dalam tim?

Salah satu pengalaman terburuk menjadi insinyur panggilan – terutama yang baru – adalah jumlah pengetahuan suku yang menumpuk di tim teknik dari waktu ke waktu. Mengintimidasi untuk melompat pada insiden produksi dengan tingkat keparahan tinggi hanya untuk menyadari bahwa Anda tidak terbiasa dengan area sistem itu dan itu tidak didokumentasikan dengan baik.

“ Menjaga agar informasi pemecahan masalah peringatan tetap jelas, sederhana, dan terkini sangat membantu mengurangi waktu rata-rata Anda untuk mengurangi dan memulihkan dari suatu insiden ”

Bahkan jika Anda memang memiliki keahlian, Anda mungkin telah menulis kodenya sejak lama sehingga Anda tidak ingat dengan jelas apa yang seharusnya dilakukan. Menjaga agar informasi pemecahan masalah peringatan tetap jelas, sederhana, dan terkini sangat membantu mengurangi waktu rata-rata Anda untuk mengurangi dan memulihkan dari suatu insiden (MTTM dan MTTR).

6. Jika dapat ditindaklanjuti, apakah ada tautan dasbor dan apakah itu menunjukkan semua penyebab potensial yang diketahui?

Dasbor adalah cara yang bagus untuk menampilkan sejumlah besar informasi sistem sekaligus, artinya para insinyur tidak perlu menggali berbagai log, metrik, dan jejak untuk mencari tahu penyebab masalah. Menggabungkan data ke dalam dasbor dan menyediakan tautan sebagai bagian dari peringatan memungkinkan pemecahan masalah yang lebih cepat.

7. Apakah peringatan terlalu sensitif atau tidak cukup spesifik? Apakah akan mendapat manfaat dari desensitisasi atau perubahan ruang lingkup?

Banyak peringatan berguna tetapi salah dikalibrasi. Mereka bisa terlalu luas dan tidak menembak setiap kali seharusnya, atau terlalu spesifik dan menembak beberapa kali untuk insiden yang sama, yang hanya menambah kebisingan.

8. Terakhir, apakah manusia harus melakukan remediasi?

Di satu sisi, semua kode komputer mengotomatiskan sesuatu yang dapat dilakukan manusia. Jadi mengapa tidak mengotomatiskan perbaikan masalah yang memicu peringatan? Sementara peringatan sulit tertentu akan sulit untuk diperbaiki secara otomatis, seperti bug dalam kode atau masalah kinerja dalam sistem, tindakan otomatis dapat memecahkan banyak masalah umum.

Ini terutama benar jika Anda menjalankan platform cloud seperti AWS dan dapat menyediakan infrastruktur tanpa harus khawatir meminta perangkat keras tambahan. Misalnya, jika sebuah node di cluster pencarian Anda menunjukkan disk yang rusak, mengapa tidak menggantinya secara otomatis? Jika layanan memiliki sumber daya komputasi yang rendah karena peningkatan lalu lintas, mengapa tidak meningkatkan dan menambahkan VM atau penampung tambahan? Rincian perbaikan kemudian dapat dikirim ke tim melalui saluran non-peringatan sehingga mereka dapat meninjau di waktu luang mereka.

Sudahkah Anda menjawab "tidak" untuk semua pertanyaan ini?

Menjawab tidak untuk salah satu pertanyaan ini menimbulkan tugas prioritas tinggi bagi tim untuk melakukan beberapa pekerjaan untuk meningkatkan peringatan – apakah itu berarti menghentikannya dari paging, meningkatkan langkah pemecahan masalah, mengotomatiskannya, atau hanya memperbaiki masalah sistem yang mendasarinya.

Inti dari pendekatan ini adalah melakukan ini secara teratur dan terencana. Ini menjaga tingkat kebisingan tetap rendah dan ops serta teknisi panggilan Anda senang dan produktif. Mereka dapat fokus pada peningkatan kualitas dan memberikan dampak daripada pemadaman kebakaran.

Apakah Anda tertarik dengan cara kami bekerja di Intercom? Kami ingin berbicara dengan Anda – lihat peran teknik terbuka kami.