On-Call’a Giden Yolculuk: Teknoloji Ekipleri için On-Call ve Alarm Yönetimi
On-call, alarm ve buna bağlı olarak incident yönetimi birçok IT ve teknoloji ekibi için kritik bir öneme sahiptir. Vermiş olduğunuz hizmet veya servisin (bir platform veya online ürün olabilir) erişebilirliğinin yüksek olması, bir problem anında ne kadar hızlı yanıt verip müdahil olmanızla büyük ölçüde ilişkilidir.
Bu yazımda sizlere on-call ve alarm yönetimi hakkındaki tecrübelerimden bahsediyor olacağım.
Giriş
Sorumlusu olduğunuz platformu veya servisi, 360 derece alan hakimiyeti mottosu ile izlediğinizi varsayalım. Bu yapı için eminim platform metriklerini, logları, uygulama performansı metriklerini çeşitli araçlarla toplayıp buradan alarmlar türetiyorsunuzdur. Şimdi gelen alarmları yönetme sürecine gelelim. . .
Alarm Yönetimi
Alarmları iletmiş olduğunuz iletişim kanalları çoğu zaman çok gürültülü olabilir. Yani çok fazla gerekli gereksiz alarm türetirseniz bir süre sonra bu size körlük oluşturacak ve aralarında gerçekten oluşan bir sorunu muhtemelen atlayacaksınızdır. Öncelikle burayı doğru threshold değerleri ile tune etmek gerekiyor. Bu iş biraz da disipline bağlı bir süreç. Gelen alarmlarda bir şekilde aranmıyorsanız (Noc hizmeti veya on-call araçlarıyla) muhtemelen çoğu zaman burayı tune etmek için önceliğiniz olmayacaktır. Bu sebepten dolayı ilk tavsiyem gelen alarmlardan bir yöntemle aranarak bilginizin olması ve sonrasında bununla ilgili olarak bu alarm gerçekten gelmeli mi? False positive mi? Threshold’u doğru mu? gibi soruları sorarak tune etmeniz. Buradaki diğer tavsiyem; scrum, kanban vb. bir süreciniz varsa bir backlog oluşturarak bu işi parçalara bölerek yapmanız olur.
On-Call Yönetimi
Alarm yönetimi sürecini çözdünüz. Sonraki aşama doğru eskalasyon politikalarını oluşturmak ve nöbet yapısını kurgulamak olacaktır. Öncelikle eskalasyon seviyeleri belirlemeniz gerekiyor. Level 1 ne yapar? nereye kadar çözebilir? Aynı şekilde Level 2, Level 3 ve Level 4. Bir alarm ne kadar süre hangi statüde cevapsız kalırsa bir sonraki level’a eskale edilecek gibi kurallarınızı ayrıca oluşturmalısınız. Eskalasyon kurallarınızı oluşturduktan sonra gelelim nöbet listesini oluşturma bölümüne. Bunun için çeşitli algoritmalar var. En popüler kullanılan Panama shift(bknz. https://en.wikipedia.org/wiki/Shift_plan). Biz genel olarak on-call yapacak mühendis arkadaşımızın bu işe max. %25 vaktini ayırmasını istiyoruz. Günde iki vardiya dönülecekse 8 kişilik bir on-call ekibi ile bu değerleri yakalayabilirsiniz. Burada dikkat edilmesi gereken konu nöbetçi arkadaşımızın ulaşılabilir ve yanında bilgisayarının bulunuyor olması. Bence 7/24 bilgisayar başında durmasına gerek yok. On-call management yapılarıyla problem anında zaten telefon araması alarak bilgilendiriyor oluyorsunuz. Buradaki %25 vaktinizide optimum bir şekilde kullanabilirsiniz.
Sonuç
Yazıma başlarken dediğim gibi On-call management, platformlarınızın ve servislerinizin erişilebilirliğini yüksek seviyede tutabilmeniz açısından çok büyük bir öneme sahiptir. Yukarıda bahsetmiş olduğum yaklaşımı operasyon ekipleriniz için bir rehber olarak görebilir, sürdürülebilir ve yönetilebilir bir yapı oluşturmak için kendi modelinize uyarlayarak kullanabilirsiniz.
