Nöbet düzeni ve olay komutanlığı: olaya hazırlıklı bir ekip kurmak
Nöbet rotasyonu, uyarı kalitesi, olay komutanı ve rol ayrımı: BT olaylarına hazırlıklı olmak için nöbet düzeni ve komuta yapısını kurma rehberi.
Nöbet ve komuta neden ayrı konulardır
On-call nöbeti, bir mühendisin belirli bir süre boyunca hizmet için ulaşılabilir olması, uyarı geldiğinde dakikalar içinde cevap verebilmesidir. Olay komutanlığı ise büyüyen bir olayda koordinasyonu üstlenen role verilen addır. Bunlar birbirini tamamlar ama aynı şey değildir. Nöbet düzeni, olayı kimin ilk karşılayacağını belirler; komuta yapısı, olay tek kişinin çözemeyeceği kadar büyüdüğünde işin nasıl örgütleneceğini belirler.
Bu yapılardan biri eksik olduğunda tipik sorunlar ortaya çıkar. Nöbet düzeni sağlam ama komuta yapısı yoksa, karmaşık bir olayda herkes aynı anda müdahale eder, kimse durumu bütün olarak izlemez. Komuta yapısı var ama nöbet düzeni dengesizse, ilk müdahale eden kişi yorgun ve bilgisiz kalır. ITIL tabanlı olay yönetimi süreçleri bu konunun süreç boyutunu anlatır; burada odak, SRE pratiğinde nöbet ve komuta nasıl çalıştığıdır.
Nöbet rotasyonunu tasarlamak
Google'ın nöbet pratiği nicelik ve nitelik dengesi üzerine kuruludur. Nicelikte, nöbet süresi mühendisin zamanının makul bir bölümüyle sınırlanır ki geri kalan zaman mühendisliğe ayrılabilsin. Birincil ve ikincil nöbetçi tanımlanır; ikincil çoğu zaman kaçan uyarıları yakalar ya da acil olmayan işleri üstlenir. Tek bölgeli bir ekipte, hem birincil hem ikincil nöbet tutulacaksa yeterli kişi sayısı gerekir; çok bölgeli ekipte rotasyon küçülebilir ve gece vardiyaları ortadan kalkar. Gün boyu nöbet (follow the sun düzeni) sağlığı korur, ama koordinasyon yükü getirir.
Nitelikte, bir vardiyada ele alınabilecek olay sayısı sınırlıdır; bir olay yalnızca müdahaleyi değil, kök neden analizini, düzeltmeyi ve postmortem'i de içerir. Hedef, uyarıların zamana eşit yayılması ve çoğu gün uyarısız geçmesidir. Bir bileşen her gün uyarı üretiyorsa, bu bir risk işaretidir: başka bir arıza geldiğinde yük taşar.
Ayrıca nöbet dışı saatlerde yapılan iş uygun biçimde karşılanmalıdır: izin ya da ek ödeme. Çok sessiz bir nöbet de sorun olabilir; üretimle yeterince temas etmeyen mühendis olay anında özgüven ve beceri eksikliği yaşar. Bu yüzden tatbikatlar yapılır.
Uyarı kalitesi: nöbetin asıl maliyeti
Nöbet yükünü belirleyen, mühendis sayısı kadar uyarı kalitesidir. Çağrı gönderen uyarılar kullanıcıyı ya da SLO'yu tehdit eden belirtilere bağlı olmalı ve harekete geçirilebilir olmalıdır. Sık gelen düşük öncelikli uyarılar, ciddi olanlara olan dikkati aşındırır.
Pratik adımlar: ilişkili uyarıları gruplamak; uyarı başına bir olay oranına yaklaşmak için gürültülü uyarıları ayarlamak; olay sırasında yinelenen uyarıları sessize almak. Nöbet yükü sürdürülebilir seviyenin üstüne çıkarsa şu çözüm yolları vardır: izleme yapılandırmasını düzeltmek, geliştirici ekiple ortak güvenilirlik hedefi belirlemek ve aşırı durumlarda çağrı cihazını geliştirici ekibe geri vermek (hizmet SRE standardına gelene kadar). Bir başka seçenek, deneyimli bir mühendisi aşırı yüklü ekibe geçici olarak ödünç vermektir.
Olay komutanlığı ve roller
Büyük bir olayda herkesin aynı şeyi yapmaya çalışması, kimsenin bütünü görmemesi anlamına gelir. Olay Komuta Sistemi, sorumlulukları ayırarak herkesin rolünü bilmesini ve o rolün içinde kalmasını sağlar. Rol dağılımı şöyledir:
- Olay komutanı: olayın üst düzey durumunu tutar, görev gücünü ihtiyaca ve önceliğe göre yapılandırır. Devretmediği her pozisyonu örtük olarak üstlenir ve operasyonu yavaşlatan engelleri kaldırır.
- Operasyon lideri: komutanla birlikte sorunu çözmek için operasyonel araçları uygular. Olay sırasında sisteme müdahale eden tek grup olmalıdır.
- İletişim lideri: yanıtın kamusal yüzüdür. Ekibe ve paydaşlara düzenli güncelleme gönderir, olay belgesini güncel tutar.
- Planlama lideri: uzun vadeli işleri üstlenir ki operasyon çözüme odaklanabilsin: hata kaydı açmak, devir teslimleri koordine etmek, sistemin normalden ne kadar saptığını izleyip çözüm sonrası geri döndürmek.
İş yükü bir kişiye fazla gelirse, planlama liderinden destek istenir ya da alt olay açılır.
Canlı olay belgesi, komuta noktası ve devir teslim
Komutanın en önemli işi, canlı bir olay durum belgesini sürdürmektir; mümkünse birden çok kişinin aynı anda düzenleyebileceği bir belge. Düzenli olması şart değildir ama işlevsel olmalıdır; şablon kullanmak ve en önemli bilgiyi en üste yazmak kullanılabilirliği artırır. Belge, postmortem için saklanır. Paydaşların komutana ulaşabileceği bilinen bir yer de gerekir: fiziksel bir oda ya da uzaktan çalışan ekipler için sohbet kanalı. Kanal aynı zamanda iletişim kaydı işlevi görür; olay trafiğini ve uyarıları kaydeden botlar postmortem'de işe yarar. Kritik altyapıdan sorumlu ekipler, olayda onarmaya çalıştıkları yazılımla aynı araca bağımlı olmamaya dikkat etmelidir.
Devir teslimde giden komutan gelen komutanı eksiksiz bilgilendirir, devri açıkça teyit eder ve kesin onay alana kadar görüşmeden ayrılmaz. Devir herkese duyurulur ki kimin yönettiği her an net olsun.
Ne zaman olay ilan edilir, nasıl hazırlanılır
Olayı erken ilan etmek, saatlerce tek başına uğraşıp sonra çerçeveyi devreye almaktan iyidir. Google'ın verdiği ölçütler: sorunu çözmek için başka bir ekibin dahil olması gerekiyorsa, kesinti müşteri tarafından görülüyorsa ya da odaklı analizden bir süre sonra sorun hâlâ çözülmediyse olay ilan edilir.
Yanıt sürecinin önceliği sırayla şudur: zararı durdur, hizmeti geri getir, kök neden analizi için kanıtı koru. Hazırlıkta yöntemleri önceden belgeleyin, rolleri döndürün ki herkes her rolü tanısın, ve süreci rutin işlerde bile deneyin. Becerilerin kullanılmadığında zayıfladığı bilinir; bu yüzden geçmişte çözülmüş olayları rol oyunu olarak yeniden canlandırmak ve felaket kurtarma testlerine olay yönetimini eklemek önerilir. Stres altında hızlı sezgisel kararlara kaymak insani bir eğilimdir; net yükseltme yolları, tanımlı olay prosedürleri ve suçlamasız postmortem kültürü bu baskıyı azaltır.
Bu beceri Mindset programlarında nerede çalışılır
Site Reliability Engineering (SRE) Pratikleri programında Incident Yönetimi modülü, SRE Kültürü programında ise Olay Yönetimi ve Blameless Post-Mortem modülü bu konuyu işler. İçerik, nöbet tutan mühendisler, operasyon ve platform ekip liderleri ile olay anında rol dağılımını ve nöbet düzenini kurumsal bir pratiğe dönüştürmek isteyen yöneticiler için uygundur.
İlgili Mindset programı
Site Reliability Engineering (SRE) Pratikleri
Sık sorulan sorular
Olay komutanı olay çözümünü bizzat mı yapar?
Hayır. Komutan durumu bütün olarak izler ve görevleri dağıtır; teknik müdahaleyi operasyon lideri yürütür. Komutan devretmediği tüm rolleri örtük olarak üstlenir, ama pratikte sorunu çözmek yerine koordinasyonu yönetir. Aynı kişi hem komutan hem uygulayıcı olursa bütünü kaçırması kolaylaşır.
Birincil ve ikincil nöbetçi ne işe yarar?
Birincil nöbetçi ilk müdahaleyi yapar. İkincil nöbetçi, kaçan uyarıları yakalayabilir, acil olmayan işleri üstlenebilir ya da yükü paylaşan bir yedek olabilir. Görev dağılımı ekipten ekibe değişir; önemli olan, tek kişiye bağımlılığı azaltmak ve her uyarının yanıtsız kalmamasını sağlamaktır.
Nöbet yükü çok yüksekse ilk ne yapılmalı?
Önce uyarı kalitesine bakın: çağrı gönderen her uyarı gerçekten harekete geçirilebilir mi, gruplanabilir mi, SLO'yu tehdit eden belirtiye bağlı mı? Yük kalıcıysa geliştirici ekiple ortak güvenilirlik hedefi belirleyin. Aşırı durumlarda çağrı cihazı geçici olarak geliştirici ekibe verilebilir.
Ne zaman resmî olay ilan etmeliyim?
Çözüm için başka bir ekibin katılımı gerekiyorsa, kesinti müşteri tarafından görülüyorsa ya da odaklı bir analizden sonra sorun hâlâ çözülmediyse. Erken ilan etmek, geç ilan etmekten ucuzdur; çünkü rol yapısı ve iletişim düzeni daha baştan devreye girer.
Olay yönetimi becerisi nasıl geliştirilir?
Uygulayarak. Çerçeveyi ekipler arası ya da saat dilimleri arası rutin değişikliklerde kullanın, felaket kurtarma testlerine olay yönetimi ekleyin ve çözülmüş olayları rol oyunu olarak yeniden canlandırın. Rolleri döndürmek, herkesin her rolün zorluklarını tanımasını sağlar.