Mühendislik ekibiniz alarm yorgunluğu mu yaşıyor? Bu 8 soruyu sorun

Uyarı yorgunluğu, operasyonları yürüten ve altyapıyı koruyan mühendislik ekipleri arasında yaygın bir sorundur.

Sorun genellikle ekipler büyüdükçe ve artan karmaşıklığa sahip daha fazla altyapı kullanmaya başladıkça uyarı yazmaya yönelik gelişigüzel bir yaklaşımdan kaynaklanır. Bu oldukça normaldir – bir şirket veya ekip büyüdükçe, bir gözlemlenebilirlik kültürünün ve sağlam uyarı uygulamalarının şekillenmesi genellikle zaman alır.

Fazla hassas, fazla gürültülü ve fazla ihtiyatlı uyarılar oluşturmak kolaydır. Başlangıçta, her şey dikkatli görünüyor çünkü bir ürünün erken aşamalarında dikkatli olmak ve üretim sinyalini en üst düzeye çıkarmak daha iyidir.

"Özelliklerin ve altyapının sayısı ve karmaşıklığı arttıkça, uyarıları iyileştirmek genellikle öncelik listesinin çok altındadır."

Doğal olarak, bu yaklaşım çok iyi ölçeklenmez, ancak özelliklerin ve altyapının sayısı ve karmaşıklığı arttıkça, uyarıları iyileştirmek genellikle öncelik listesinin çok altındadır. Sonuç, çağrı mühendisi için çok sayıda yarı anlamlı uyarı, gürültü, bağlam değiştirme ve çoklu görevdir. Aşırı durumlarda, ekip arkadaşları tükenir, uyarılar göz ardı edilir ve görevdeki ekibiniz, hizmet kalitesini iyileştirmekten, anlamlı bir etkisi olmayan sürekli yangınla mücadeleye geçer.

Tüm şirketler gibi Intercom da bu verimsizliklere karşı bağışık değildir. Bu nedenle, alarm yorgunluğuyla mücadele etmek için nispeten hafif bir süreç tasarladık.

Uyarı stratejisi hakkında nasıl düşünüyoruz?

“Uyarı disiplini” kavramı, uyarıları kontrol altına almanın merkezinde yer alır. Özellik çalışması gibi, uyarılara ve uyarı stratejisine de kasıtlı, yapılandırılmış bir şekilde yaklaşılmalıdır. Ancak özellik çalışmasından farklı olarak, önceden iyi planlanabilecek bir şey değildir.

Ne de olsa, yeni özelliğinizi göndermeden önce çalışma durumunu ve gürültüsünü tahmin edebilmeniz pek olası değildir. Uyarı zahmetinin sürdürülemez seviyelere gelmemesi için uyarıları düzenli ve planlı bir şekilde izlemelisiniz.

Ekibinizin uyarılarını değerlendirirken sorulacak 8 soru

Sık uyarılarla uğraşan ekipler için düzenli uyarı inceleme oturumları başlattık. Bunlar başlangıçta altı haftalık mühendislik döngüsünde bir veya birden çok kez gerçekleşti, ancak uyarıların ve monitörlerin durumu daha yönetilebilir bir düzeye yükseldikçe daha fazla aralıklı hale geldi.

Her uyarı inceleme oturumu, tetiklenme sıklığına göre sıralanmış, önceki dönemde tetiklenen uyarıların sıralı bir listesiyle başlar. Uyarı kaynağımız olarak PagerDuty platformunu kullanıyoruz ve analitik özellikleri bize uyarı sıklığını ve yanıtını kırmak için ihtiyaç duyduğumuz bilgileri veriyor. Genel gürültüye en fazla katkıda bulunan uyarılar (yani en sık yangın) önce gözden geçirilir.

Her uyarı daha sonra bir soru kontrol listesinden geçirilir:

1. Uyarı hâlâ geçerli mi?

Eski veya bakımı yapılmamış sistemler tarafından tetiklenen herhangi bir uyarı, nöbetçi mühendisi rahatsız etmemelidir ve derhal kaldırılmalıdır.

2. Uyarı uygulanabilir mi?

Bir çağrı mühendisi uyarıyı alırsa, altta yatan nedeni düzeltmek veya iyileştirmek için hemen şimdi bir şeyler yapabilir mi? Uyarı uygulanabilir ve kullanışlı değilse kaldırılmalıdır. Sorunların veya performans düşüşlerinin haftalık bir özeti, uyarı içindeki bilgiler için daha iyi bir yer olabilir.

3. Uyarıdaki bilgiler, eyleme geçirilemez olsa bile hemen faydalı mı?

Uyarı bilgilerini iki geniş kategoriye ayırabiliriz.

• Sinyaller: Bu uyarılar, bir sistemin limitinde çalıştığı konusunda uyarır, ancak mutlaka hizmetin etkilendiği anlamına gelmez. Bir örnek, %100 CPU'da çalışan sunucularınızdan biri olabilir. Hizmet hala iyi çalışıyorsa, arama sırasında değerli zamanınızı araştırmak için harcamalı mısınız? Sonuçta, sunucunuz sadece en iyi iş-maliyet oranında performans gösteriyor!
• Belirtiler: Bu uyarılar, müşteri deneyimi etkilendiğinde tetiklenir. Burada bir örnek, hizmetinizin arayanlara döndürdüğü 5XX HTTP hatalarının sayısı olabilir.

Bu iki kategori birlikte en iyi şekilde çalışır. Nöbetçi bir kişi semptomlara tepki vermeli ve sorunları gidermeli ve sinyallere yalnızca daha fazla bilgi kaynağı olarak bakmalıdır.

4. Uyarı uygulanabilir ve çağrılıysa, hemen ele alınması gerekiyor mu?

Sorunun hemen çözülmesi gerekmiyorsa gece yarısı kimseyi uyandırmamalıdır. Ekip, bu durumlarda uyarıdaki bilgileri açığa çıkarmanın alternatif yollarına karar vermelidir, örneğin, bir Slack veya pano bildirimi veya bir sorun izleme mekanizmasında açılmış bir görev.

5. İşlem yapılabilirse, bir runbook veya sorun giderme bağlantısı var mı? Adımlar, ekipteki herhangi bir mühendis tarafından takip edilebilecek kadar açık mı?

Nöbetçi mühendis olmanın en kötü deneyimlerinden biri - özellikle yeni bir mühendis - mühendislik ekiplerinde zamanla biriken kabile bilgisi miktarıdır. Sırf sistemin o alanına aşina olmadığınızı ve bunun iyi belgelenmediğini anlamak için yüksek önemdeki bir üretim olayına atlamak korkutucudur.

“ Uyarı sorun giderme bilgilerini açık, basit ve güncel tutmak, bir olayı azaltmak ve kurtarmak için ortalama sürenizi kısaltmak için uzun bir yol kat eder ”

Uzmanlığınız olsa bile, kodu o kadar uzun zaman önce yazmış olabilirsiniz ki, ne yapması gerektiğini net olarak hatırlamıyorsunuzdur. Uyarı sorun giderme bilgilerini açık, basit ve güncel tutmak, bir olayı (MTTM ve MTTR) azaltmak ve kurtarmak için ortalama sürenizi kısaltmak için uzun bir yol kat eder.

6. İşlem yapılabilirse, bir gösterge panosu bağlantısı var mı ve bilinen tüm olası nedenleri gösteriyor mu?

Gösterge tabloları, büyük miktarda sistem bilgisini bir kerede yüzeye çıkarmak için harika bir yoldur, yani mühendislerin bir sorunun nedenini bulmak için çeşitli günlükleri, ölçümleri ve izleri araştırmaları gerekmez. Verileri bir gösterge panosunda toplamak ve bağlantının uyarının bir parçası olarak sağlanması, çok daha hızlı sorun gidermeye olanak tanır.

7. Uyarı çok hassas mı yoksa yeterince spesifik değil mi? Duyarsızlaştırma veya kapsam değişikliğinden fayda sağlar mı?

Birçok uyarı yararlıdır ancak yanlış kalibre edilmiştir. Ya çok geniş olabilirler ve her zaman ateş etmeyebilirler ya da aynı olay için çok spesifik ve birkaç kez ateş edebilirler, bu da sadece gürültüye katkıda bulunur.

8. Son olarak, bir insan iyileştirmeyi yapmak zorunda mı?

Bir bakıma, tüm bilgisayar kodları, bir insanın yapabileceği bir şeyi otomatikleştirir. Öyleyse neden uyarıları tetikleyen sorunların giderilmesini otomatikleştirmiyorsunuz? Koddaki bir hata veya sistemdeki bir performans sorunu gibi belirli daha zorlu uyarıların otomatik olarak düzeltilmesi zor olsa da, otomatik eylemler birçok yaygın sorunu çözebilir.

Bu, özellikle AWS gibi bir bulut platformunda çalışıyorsanız ve ek donanım talep etme konusunda endişelenmenize gerek kalmadan altyapı sağlayabiliyorsanız geçerlidir. Örneğin, arama kümenizdeki bir düğüm arızalı diskler gösteriyorsa neden otomatik olarak değiştirmiyorsunuz? Hizmet, trafik artışı nedeniyle bilgi işlem kaynaklarında düşükse neden ölçeği büyütüp ek VM'ler veya kapsayıcılar eklemiyorsunuz? Düzeltmenin ayrıntıları, boş zamanlarında gözden geçirebilmeleri için uyarı vermeyen kanallar aracılığıyla ekibe gönderilebilir.

Bu sorulardan herhangi birine “hayır” cevabı verdiniz mi?

Bu sorulardan herhangi birine hayır yanıtı vermek, ekibin uyarıyı iyileştirmek için bazı çalışmalar yapması için yüksek öncelikli bir görevi gündeme getirir; bu, ister çağrıyı durdurmak, sorun giderme adımlarını iyileştirmek, otomatikleştirmek veya temeldeki sistem sorununu düzeltmek anlamına gelebilir.

Yaklaşımın püf noktası, bunu düzenli ve planlı bir şekilde yapmaktır. Gürültü seviyelerini düşük tutar ve operasyonlarınızı ve nöbetçi mühendislerinizi mutlu ve üretken tutar. Yangınla mücadele yerine kaliteyi iyileştirmeye ve etki sağlamaya odaklanabilirler.

Intercom'da çalışma şeklimizle ilgileniyor musunuz? Sizinle konuşmayı çok isteriz – açık mühendislik rollerimize göz atın.