IT ekipleri için olay yönetimi uygulaması: iş akışlarından postmortemlere

İçsel bir olay uygulamasının gerçekte hangi problemi çözdüğü

Kesinti olduğunda çoğu ekip açık olan her şeye sarılır: bir sohbet dizisi, e-posta zinciri, belki biri ara sıra güncellediği bir e-tablo. Baskı altında bu düzen her seferinde aynı şekillerde bozulur: sahiplik belirsizleşir, zaman damgaları kaybolur ve kararlar akışta kaybolur.

Basit bir olay yönetimi uygulaması temelleri düzeltir. Olayın yaşadığı tek bir yer verir; net bir sahibi, herkesin üzerinde anlaştığı bir şiddet seviyesi ve ne olduğuna dair bir zaman çizelgesi ile birlikte. Bu tek kayıt önemlidir çünkü aynı sorular her olayda tekrar eder: Kim liderlik ediyor? Ne zaman başladı? Güncel durum nedir? Neler denendi?

Bu ortak kayıt olmadan devralmalar zaman kaybettirir. Destek müşterilere bir şey söylerken mühendislik başka bir şey yapabilir. Yöneticiler, müdahale edenleri düzeltmeden güncelleme ister. Sonrasında kimse zaman çizelgesini güvenle yeniden kuramaz, bu yüzden postmortem tahmine dönüşür.

Ama amaç izleme, sohbet veya biletleme sistemlerinizi değiştirmek değil. Uyarılar hâlâ başka yerlerden başlayabilir. Amaç karar izini yakalamak ve insanları hizalı tutmaktır.

IT operasyonları ve nöbetçi mühendisler yanıtı koordine etmek için kullanır. Destek doğru güncellemeyi hızlıca vermek için kullanır. Yöneticiler müdahale edenleri bölmeden ilerlemeyi görmek için kullanır.

Örnek senaryo: bir P1 kesintisi — uyarıdan kapanışa

Saat 09:12'de izleme, müşteri portalında 500 hatalarında bir sıçrama olduğunu işaretler. Bir destek görevlisi ayrıca "Çoğu kullanıcı için giriş başarısız" diye rapor eder. Nöbetçi IT lideri olay uygulamasında bir P1 olayı açar ve ilk uyarıyı ile destekten bir ekran görüntüsünü ekler.

P1 ile davranış hızla değişir. Olay sahibi backend sahibini, veritabanı sahibini ve bir destek bağlantısını çağırır. Gerekli olmayan işler durur. Planlı dağıtımlar durdurulur. Ekip güncelleme sıklığına karar verir (örneğin her 15 dakika). Ortak bir çağrı başlar, fakat olay kaydı gerçek kaynak olmaya devam eder.

09:18'de biri "Ne değişti?" diye sorar. Zaman çizelgesi 08:57'de bir dağıtım gösterir, ancak ne dağıtıldığı yazmaz. Backend sahibi yine de geri alır. Hatalar düşer, sonra geri gelir. Şimdi ekip veritabanından şüphelenir.

Gecikmeler çoğunlukla birkaç öngörülebilir yerde görülür: belirsiz devralmalar ("Ben bununla ilgilendiğini sanmıştım"), eksik bağlam (son değişiklikler, bilinen riskler, güncel sahip) ve sohbet, bilet ve e-postada dağılmış güncellemeler.

09:41'de veritabanı sahibi, zamanlanmış bir iş tarafından başlatılan kontrolsüz bir sorgu bulur. İşi devre dışı bırakır, etkilenen servisi yeniden başlatır ve iyileşmeyi doğrular. Şiddet P2'ye düşürülür ve gözlemlenir.

İyi kapanış "tekrar çalışıyor" demek değildir. Temiz bir kayıt demektir: dakika dakika zaman çizelgesi, nihai kök neden, hangi kararı kim verdi, nelerin durdurulduğu ve sahipleri ve teslim tarihleri olan takip işleri. Böylece stresli bir P1, tekrarlayan acı yerine öğrenmeye dönüşür.

Veri modeli: hâlâ işe yarayan en basit yapı

İyi bir olay aracı çoğunlukla iyi bir veri modelidir. Kayıtlar belirsizse insanlar olayın ne olduğunu, ne zaman başladığını ve nelerin hâlâ açık olduğunu tartışır.

Temel varlıkları IT ekiplerinin zaten konuştuğu şekilde yakın tutun:

• Incident: olan bitenin konteyneri
• Service: işletmenin yürüttüğü şey (API, veritabanı, VPN, faturalama)
• User: müdahale edenler ve paydaşlar
• Update: zaman içinde kısa durum notları
• Task: olay sırasında (ve sonrasında) somut işler
• Postmortem: olaya bağlı tek bir yazı, aksiyon maddeleriyle

Sonradan karışıklığı önlemek için Incident'e her zaman doldurulan birkaç yapılandırılmış alan verin. Serbest metin yardımcı olur, ama tek gerçek kaynak olmamalıdır. Pratik bir minimum: net bir başlık, etki (kullanıcıların ne yaşadığı), etkilenen servisler, başlangıç zamanı, güncel durum ve şiddet.

İlişkiler ekstra alanlardan daha önemlidir. Bir olayın birçok güncellemesi ve birçok görevi olmalı, artı servislerle çoktan-çoğa bağlantı (çünkü kesintiler genellikle birden fazla sistemi vurur). Bir postmortem bir olayla bire bir olmalı, böylece tek bir nihai hikaye olur.

Örnek: "Ödeme hataları" olayı "Payments API" ve "PostgreSQL" servislerine bağlı olur, her 15 dakikada güncellemeler içerir ve "Dağıtımı geri al" ve "Retry guard ekle" gibi görevleri vardır. Sonrasında postmortem kök nedeni yakalar ve daha uzun vadeli görevler oluşturur.

Şiddet seviyeleri ve yanıt hedefleri

İnsanlar stresliyken basit etiketlere ihtiyaç duyarlar; herkes için aynı anlama gelsin. P1'den P4'e kadar açık dili tanımlayın ve şiddet alanının hemen yanında tanımı gösterin.

• P1 (Kritik): Temel servis çalışmıyor veya veri kaybı olası. Birçok kullanıcı bloke.
• P2 (Yüksek): Büyük özellik bozuk, ama bir geçici çözüm veya sınırlı etki alanı var.
• P3 (Orta): Acil olmayan sorun, küçük bir grup etkileniyor, minimal iş etkisi.
• P4 (Düşük): Kozmetik veya küçük hata, daha sonra planlanır.

Yanıt hedefleri taahhüt gibi okunmalı. Basit bir temel (kendi gerçekliğinize göre ayarlayın):

Yükseltme kurallarını mekanik tutun. Bir P2 güncelleme sıklığını kaçırırsa veya etki büyürse sistem bir şiddet gözden geçirmesi önermeli. Kararsızlığı önlemek için kimlerin şiddeti değiştirebileceğini sınırlayın (genellikle olay sahibi veya olay komutanı), ama yine de herkesin yorumla gözden geçirme talep etmesine izin verin.

Hızlı bir etki matrisi ekiplerin şiddeti hızlı seçmesine yardımcı olur. Bunu birkaç zorunlu alan olarak yakalayın: etkilenen kullanıcı sayısı, gelir riski, güvenlik/uyumluluk, ve bir geçici çözümün olup olmadığı.

Stres sırasında insanlara yol gösteren iş akışı durumları

Bir olay sırasında insanların daha fazla seçeneğe değil, sonraki adımı açıkça gösteren az sayıda duruma ihtiyacı vardır.

İyi gününüzde zaten takip ettiğiniz adımlarla başlayın, sonra listeyi kısa tutun. 6 veya 7'den fazla durumunuz varsa ekipler söylem üzerine tartışır, sorunu çözmek yerine.

Pratik bir set:

• New: uyarı alındı, henüz doğrulanmadı
• Acknowledged: birisi sahiplenmiş, ilk yanıt başlatıldı
• Investigating: etki onaylanıyor, muhtemel neden daraltılıyor
• Mitigating: etkiyi azaltmak için eylemler sürüyor
• Monitoring: servis stabil gözüküyor, nüks izleniyor
• Resolved: servis geri döndü, incelemeye hazır

Her durumun net giriş ve çıkış kuralları olmalı. Örneğin:

• Bir sahip atanıp sonraki eylem bir cümleyle yazılmadan Acknowledged durumuna geçilemez.
• Mitigating durumuna en az bir somut hafifletme görevi olmadan geçilemez (geri alma, özellik bayrağı kapama, kapasite ekleme).

Geçişleri insanların unuttuğu alanları zorlamak için kullanın. Yaygın bir kural: bir olay kapatılmadan önce kısa bir kök neden özeti ve en az bir takip maddesi zorunlu olsun. "RCA: TBD" izin verilirse, çoğunlukla öyle kalır.

Olay sayfası üç soruyu anında cevaplamalı: bunun sahibi kim, sonraki eylem ne ve son güncelleme ne zaman yapıldı.

Atama ve yükseltme kuralları

Olay gürültülü olduğunda zaman kaybetmenin en hızlı yolu belirsiz sahipliktir. Uygulamanız bir kişiyi net şekilde sorumlu yapmalı, diğerlerinin yardım etmesini de kolaylaştırmalı.

Sürüp giden bir desen:

• Birincil sahip: yanıtı yönlendirir, güncellemeleri yayınlar, sonraki adımlara karar verir
• Yardımcılar: görevler alır (tanılama, geri alma, iletişim) ve geri rapor verir
• Onaylayıcı: riskli işlemleri onaylayabilecek lider

Atama açık ve denetlenebilir olmalı. Kimin sahibi belirlediğini, kimin kabul ettiğini ve sonrasında yapılan tüm değişiklikleri izleyin. "Kabul edildi" önemli, çünkü uyuyan veya çevrimdışı birine atama gerçek sahiplik sayılmaz.

Nöbetçi vs ekip bazlı atama genellikle şiddete bağlıdır. P1/P2 için varsayılan olarak nöbetçi rotasyonuna yönelin ki her zaman isimli bir sahip olsun. Daha düşük şiddetlerde ekip bazlı atama işe yarayabilir, ama kısa süre içinde tek bir birincil sahip gerektirin.

İzinler ve otomasyonla tatil ve kesintileri insan sürecinde planlayın, sadece sistemlerde değil. Atanan kişi kullanılabilir olarak işaretlenmemişse, ikincil nöbetçiye veya ekip liderine yönlendirilsin. Otomatik ama görünür tutun ki hızlıca düzeltilebilsin.

Yükseltme hem şiddeti hem sessizliği tetiklemeli. Başlangıç için faydalı bir nokta:

• P1: 5 dakika içinde sahip kabulü yoksa yükselt
• P1/P2: 15–30 dakika içinde güncelleme yoksa yükselt
• Herhangi şiddet: "Investigating" durumu yanıt hedefini aşıyorsa yükselt

Zaman çizelgeleri, güncellemeler ve bildirimler

İyi bir zaman çizelgesi paylaşılan hafızadır. Bir olay sırasında bağlam hızla kaybolur. Doğru anları tek bir yerde yakalarsanız devralmalar kolaylaşır ve postmortem çoğu zaman bir belge açılmadan önce yazılmış olur.

Zaman çizelgesinin yakalaması gerekenler

Zaman çizelgesini fikirli tutun. Bunu sohbet kaydına çevirmeyin. Çoğu ekip küçük bir giriş setine dayanır: tespit, onay, ana hafifletme adımları, geri dönüş ve kapama.

Her giriş bir zaman damgası, bir yazar ve kısa düz bir açıklama içermeli. Sonradan katılan biri beş girdiyi okuyup ne olduğunu anlayabilmeli.

Açık tutan güncelleme türleri

Farklı güncellemeler farklı kitlelere hizmet eder. Girdilerin bir türü olması yardımcıdır; örneğin iç not (ham ayrıntılar), müşteri odaklı güncelleme (güvenli ifade), karar (neden A seçildi) ve devralma (sonraki kişinin bilmesi gerekenler).

Hatırlatmalar kişisel tercihe değil şiddete göre çalışmalı. Zamanlayıcı çaldığında önce mevcut sahibi uyarın, sonra tekrar tekrar kaçırılırsa yükseltin.

Bildirimler hedeflenmiş ve öngörülebilir olmalı. Küçük bir kural seti genellikle yeterlidir: oluşturma, şiddet değişikliği, geri dönüş ve gecikmiş güncellemelerde bildirim gönder. Her değişiklikte tüm şirketi bildirmekten kaçının.

Gerçek takip işi yapan postmortemler

Postmortem iki işi yapmalı: basit bir dille ne olduğunu açıklamak ve aynı hatanın tekrarlama olasılığını azaltmak.

Yazımı kısa tutun ve çıktıyı eylemlere zorlayın. Pratik bir yapı: özet, müşteri etkisi, kök neden, uygulanan düzeltmeler ve takipler.

Takipler asıl noktadır. Onları paragraf halinde bırakmayın. Her takibi bir sahip ve bir teslim tarihi olan izlenen bir göreve dönüştürün, teslim tarihi "bir sonraki sprint" olsa bile. Bu, "izlemeyi geliştirmeliyiz" ile "Alex Cuma'ya kadar DB bağlantı doygunluğu uyarısı ekler" arasındaki farktır.

Etiketler postmortemleri sonra kullanışlı kılar. Her olaya 1 ila 3 tema ekleyin (izleme boşluğu, dağıtım, kapasite, süreç). Bir ay sonra temel soruları cevaplayabilirsiniz: çoğu P1 sürümlere mi yoksa eksik uyarılara mı bağlı?

Kanıt eklemeyi kolay ama zorunlu olmayan hale getirin. Ekran görüntüleri, log parçaları ve harici sistem referanslarına (bilet ID'leri, sohbet dizileri, satıcı vaka numaraları) izin veren isteğe bağlı alanlar destekleyin. Hafif tutun ki insanlar gerçekten doldursun.

Adım adım: mini sistemi tek bir iç uygulama olarak inşa etmek

Bunu bir e-tabloya ekstra sütun eklenmiş bir ürün gibi değil de küçük bir ürün gibi ele alın. İyi bir olay uygulaması aslında üç görünümden oluşur: şimdi olanlar, sonraki ne yapılmalı ve sonrasında öğrenilecekler.

İnsanların baskı altındayken açacağı ekranları taslak olarak çizin:

• Kuyruk: birkaç filtre ile açık olaylar (Open, Needs update, Waiting on vendor, Closed)
• Olay sayfası: şiddet, sahip, güncel durum, zaman çizelgesi, görevler ve son güncelleme
• Postmortem sayfası: etki, kök neden, eylem maddeleri, sahipler

Veri modeli ve izinleri birlikte oluşturun. Herkes her şeyi düzenleyebiliyorsa geçmiş karışır. Yaygın bir yaklaşım: IT için geniş görüntüleme erişimi, durum/şiddet değişiklikleri kontrollü, müdahale edenler güncelleme ekleyebilir ve postmortem onayı için net bir sahip.

Sonra yarı dolu olayları engelleyen iş akışı kuralları ekleyin. Zorunlu alanlar duruma bağlı olmalı. "New" durumunu sadece başlık ve rapor edenle izin verebilirsiniz, ama "Mitigating" için bir etki özeti ve "Resolved" için kök neden özeti artı en az bir takip görevi zorunlu kılabilirsiniz.

Son olarak 2–3 geçmiş olayı yeniden oynatarak test edin. Bir kişi olay komutanı, bir kişi müdahale eden olarak rol yapsın. Hangi durumların belirsiz olduğunu, hangi alanların atlandığını ve nerede daha iyi varsayılanlara ihtiyaç olduğunu hızlıca göreceksiniz.

Yaygın hatalar ve bunlardan nasıl kaçınılır

Çoğu olay sistemi basit nedenlerle başarısız olur: insanlar stresliyken kuralları hatırlayamaz ve uygulama sonradan ihtiyaç duyduğunuz gerçekleri yakalamaz.

Hata 1: Çok fazla şiddet veya durum

Altı şiddet seviyesi ve on durum varsa insanlar tahminde bulunur. Şiddetleri 3–4 ile, durumları ise bir sonraki adımı ne yapacaklarını gösterir şekilde tutun.

Hata 2: Tek bir sahip yok

Herkes "izliyor" olduğunda kimse yönetmiyor. Olay ilerlemeden önce bir isimli sahip zorunlu kılın ve devralmaları açıkça kaydedin.

Hata 3: Güvenilir olmayan zaman çizelgeleri

"Ne oldu, ne zaman" sohbet geçmişine bağlıysa postmortemler tartışmaya dönüşür. Açma, kabul etme, hafifletme ve çözme zaman damgalarını otomatik yakalayın ve zaman çizelgesi girdilerini kısa tutun.

Ayrıca "network sorunuydu" gibi belirsiz kök neden notlarıyla kapatmayın. Bir net kök neden açıklaması artı en az bir somut sonraki adım zorunlu kılın.

Lansman kontrol listesi ve sonraki adımlar

Bunu tüm IT organizasyonuna açmadan önce temel özellikleri stres test edin. İnsanlar ilk iki dakikada doğru düğmeyi bulamazsa sohbet dizilerine ve e-tablolara geri dönerler.

Kısa bir lansman kontrolüne odaklanın: roller ve izinler, net şiddet tanımları, zorunlu sahiplik, hatırlatma kuralları ve yanıt hedefleri kaçırıldığında bir yükseltme yolu.

Bir ekip ve sık uyarı üreten birkaç servis ile pilot çalıştırın. İki hafta çalıştırın, sonra gerçek olaylara göre ayarlayın.

Eğer bunu e-tablolar ve ayrı uygulamaları birleştirmeden tek bir iç araç olarak inşa etmek isterseniz, AppMaster (appmaster.io) bir seçenek olabilir. Veri modeli, iş akışı kuralları ve web/uygulama arayüzlerini tek bir yerde oluşturmanıza izin verir; bu, olay kuyruğu, olay sayfası ve postmortem takibi ile iyi uyum sağlar.