Gece saat üçte kimse on sayfalık bir olay politikasını okumaz. Nöbetçi mühendisin dört şeyi hızla bilmesi gerekir: bu gerçek mi, bir olay mı, başka kimin haberdar olması gerekiyor ve önce ne yapılmalı. Tek sayfalık bir akış şeması bu soruları ortaya çıktıkları sırayla yanıtlar ve politikanın insanların gerçekten uyduğu kısmı odur.
Bu yazı, üretimde bir servis işleten bir mühendislik ekibi için olay müdahale akış şeması oluşturuyor: triyaj, olay ilan etme ölçütleri, önem seviyesi ve roller, hafifletme ve döngüyü kapatan postmortem. Son bölümde, stres altında da kullanılabilir kalan bir akış şeması çizmek için öneriler var.
Akış şemasının vermesi gereken kararlar
Bir olay süreci, aralarında birkaç uzun süreli etkinlik bulunan bir dizi karardan oluşur. Kararlar şemada yer almalı ve yanıtları etiketlenmiş sorular olarak yazılmalıdır:
- Alarm gerçek ve üzerinde işlem yapılabilir mi? Değilse sorun alarmın kendisidir.
- Bu bir olay mı? Değilse bir kayıtla (ticket) ele alınan sıradan bir iştir.
- Ne kadar ciddi? Önem seviyesi kimin çağrılacağını ve kime haber verileceğini belirler.
- Hizmet geri geldi mi? Gelmediyse sıradaki hafifletme adımını deneyin ya da olayı yükseltin.
Geri kalan her şey, örneğin bir dağıtımın nasıl geri alınacağı ya da bir veritabanının nasıl yedeğe devredileceği, şemanın bağlantı verdiği runbook'lara aittir.
Ne zaman olay ilan edilir
Olay ilan etmek, ekiplerin tereddüt ettiği adımdır ve bu tereddüt pahalıya mal olur. Google'ın SRE kitabındaki olay yönetimi bölümü erken ilan etmeyi savunur: büyüyen bir sorunda süreci saatler sonra başlatmaktansa olayı ilan edip basit bir çözüm bulmak ve olayı kapatmak daha iyidir. O bölümdeki ekip, şunlardan herhangi biri doğru olduğunda olay ilan eder:
- Sorunu çözmek için ikinci bir ekibe ihtiyaç var.
- Kesinti müşteriler tarafından görülebiliyor.
- Sorun, bir saatlik yoğun analize rağmen çözülemedi.
Kendi ölçütlerinizi şemaya, kararın yanına yazın. Net ölçütler, olay ilan etmenin sosyal maliyetini ortadan kaldırır.
Roller
Aynı bölüm, Incident Command System'e (Olay Komuta Sistemi) dayanan bir yapı anlatır. Küçük bir ekip bile rolleri adlandırmaktan fayda görür, çünkü en yaygın başarısızlık tüm rolleri tek kişinin üstlenmesidir:
| Rol | Sorumluluk |
|---|---|
| Olay komutanı | Genel durumu takip eder, iş dağıtır, karar verir; devretmediği her rolü kendisi üstlenir |
| Operasyon lideri | Olay sırasında sistemde değişiklik yapan tek kişi ya da grup |
| İletişim | Paydaşlara düzenli güncellemeler gönderir ve olay belgesini güncel tutar |
| Planlama | Uzun vadeli işleri izler: açılacak hata kayıtları, devirler, sonradan geri alınacaklar |
Olay komutanı ayrıca canlı bir olay belgesi tutar ve vardiya sonunda görevi açıkça devreder: görevi bırakan komutan devri açıkça bildirir ve onay bekler.
Olay yönetimi becerileri kullanılmadıkça körelir. Aynı bölüm, bu çerçevenin ekipleri ya da saat dilimlerini aşan operasyonel değişikliklere de uygulanmasını ve geçmiş olayların canlandırılarak prova edilmesini önerir; böylece süreç, bir sonraki gerçek olaydan önce tanıdık hale gelir. Yeni bir nöbetçi mühendise akış şemasını eski bir olay üzerinden adım adım göstermek, başlamanın ucuz bir yoludur.
Önem seviyeleri
Önem seviyesi tanımları şirketten şirkete değişir; bu yüzden aşağıdakileri bir örnek olarak görün ve kendi tanımlarınızı şemaya yazın:
| Önem seviyesi | Örnek tanım | Müdahale |
|---|---|---|
| SEV-1 | Müşterinin gördüğü kesinti ya da veri kaybı | Olay komutanını ve iletişim sorumlusunu çağırın, durum sayfasını güncelleyin |
| SEV-2 | Birçok müşteriyi etkileyen ciddi performans düşüşü | Olay komutanını çağırın, durum sayfasını güncelleyin |
| SEV-3 | Küçük etki, geçici bir çözüm var | Mesai saatlerinde nöbetçi tarafından ele alınır |
Adım adım akış şeması
- Onaylayın ve triyaj yapın. Alarm tetiklendiğinde, çağrının yükselmesini durdurmak için alarmı onaylayın, ardından kapsamına ve etkisine bakın.
- Gerçek ve üzerinde işlem yapılabilir mi? Yanlış ya da işlem yapılamayan bir alarm ayarlanır veya silinir, ardından kapatılır.
- Bu bir olay mı? Ölçütleri uygulayın. Değilse bir kayıtla sıradan iş olarak ele alın.
- İlan edin. Olay komutanını belirleyin, bir kanal ve olay belgesini açın.
- Önem seviyesi. SEV-1 ve SEV-2 için bir iletişim sorumlusu durum sayfasında paylaşım yapar ve düzenli güncellemeler gönderir.
- Önce hafifletin. Geri alın, yedeğe devredin, özellik bayrağını kapatın ya da yük atın. SRE kitabına göre ilk öncelik kanamayı durdurmak, hizmeti geri getirmek ve kanıtları korumaktır; kök neden sonra gelir.
- Hizmet geri geldi mi? Gelmediyse sıradaki hafifletme adımını deneyin ya da olayı yükseltin ve döngüye devam edin.
- Çözün. Metriklerle doğrulayın, izlemeye devam edin ve sistemi normal operasyona geri teslim edin.
- Postmortem ve aksiyonlar. Suçlamasız bir postmortem yazın, gözden geçirin ve aksiyonlar takibe alındığında olayı kapatın.
Diyagram içeriği
- Alert fires
- Real and actionable?
- Tune or delete the alert
- Acknowledge and triage
- Is it an incident?
- Handle as normal work
- Done
- Declare: IC, channel, incident doc
- SEV-1 or SEV-2?
- Comms lead: status page, updates
- Mitigate: roll back, fail over, flag off
- Service restored?
- Resolve and hand back
- Blameless postmortem
- Closed when action items are tracked
- Yes
- No
- No: next step or escalate
Nasıl okunur:
- Evet sağa, Hayır aşağı gider. Her karar aynı kuralı kullanır; böylece ana yol sağa doğru ilerler, erken çıkışlar aşağı iner.
- Solda, ilk müdahale. Alarm onaylanır ve triyajı yapılır. Gerçek ya da işlem yapılabilir olmayan alarmlar ve olay sayılmayan durumlar Done ile biter.
- Üçüncü sütunda, olay. Olay ilan edilir, önem seviyesi kontrol edilir ve hafifletilir. SEV-1 ve SEV-2'de sağda bir iletişim sorumlusu devreye girer.
- Döngü. “Service restored?” kararı, yanıt evet olana kadar sizi hafifletme adımına geri gönderir.
- Sağ sütunda, kapanış. Olayı çözün, suçlamasız postmortem'i yazın ve aksiyonlar takibe alındığında kapatın.
- Notlar olay ilan etme ölçütlerini ve önem seviyelerini içerir; böylece kimsenin başka bir belge açması gerekmez.
Postmortem döngüyü kapatır
SRE kitabının postmortem kültürü bölümü, kullanıcıların gördüğü kesinti ya da belirli bir eşiği aşan performans düşüşü ve her türlü veri kaybı gibi yaygın tetikleyicileri sıralar. Bir postmortem, katkıda bulunan nedenleri insanları suçlamadan sistemlerde ve süreçlerde aradığında suçlamasızdır; aksi halde insanlar sorunları dile getirmeyi bırakır. Postmortem'i şemada sahibi ve son tarihi olan bir belge olarak çizin ve aksiyonlar takibe alınmadan olayı kapalı olarak işaretlemeyin.
Güvenlik olayları bu şemadan fazlasını gerektirir: kanıtların korunması, hukuki ve düzenleyici adımlar ve çoğu zaman ayrı bir ekip. Nisan 2025'te yayımlanan NIST SP 800-61 Rev. 3 bu konudaki yaygın başvuru kaynağıdır. Bir güvenlik dalını doğaçlama oluşturmak yerine o sürece bağlayın.
Stres altında kullanılan akış şemaları için çizim önerileri
- Tek başlangıç, net bitişler. Her yol bir yerde bitmeli, o yer “Done” olsa bile.
- Evet-hayır soruları olarak kararlar; iki çıkış da etiketli olsun, Evet ve Hayır her seferinde aynı kenarlardan çıksın.
- Döngüleri açıkça gösterin. “Sıradaki hafifletmeyi dene” bir döngüdür, dipnot değil.
- En fazla on beş şekil. Ayrıntılar, adımlardan bağlantı verilen runbook'lara gider.
- Sorumluluğun el değiştirdiği yerleri gösterin. Rol başına kulvarları olan bir sürüm için çapraz fonksiyonel akış şeması şablonundan başlayın.
- Nöbetçilerin baktığı yerde tutun. Runbook'a ekran görüntüsü yapıştırmak yerine bağlantı verin ya da canlı diyagramı gömün.
Süreciniz birçok ekibi ve resmi devirleri içeriyorsa bir BPMN diyagramı onu daha kesin modelleyebilir; nöbet sırasında ise akış şemasını izlemek daha kolaydır.
Archboard'da oluşturun
- Google ya da GitHub ile giriş yapın ve bir diyagram oluşturun.
- Akış Şeması paketinden başlangıç ve her bitiş için bir Başla / Bitir, her adım için bir Süreç ve her soru için bir Karar ekleyin.
- Postmortem için bir Belge ekleyin.
- Şekilleri bağlayın. Karar şekli sağ köşesinde Y, alt köşesinde N işareti gösterir; bu yüzden Evet'i sağa, Hayır'ı aşağı çizin, ikisini de etiketleyin ve “hizmet geri gelmedi” çıkışını hafifletme adımına geri yönlendirin.
- Olay ilan etme ölçütleriniz ve önem seviyelerinizle Temel paketinden Not düğümleri ekleyin.
Örnek 15 diyagram düğümü kullanıyor ve Free planın sınırları içinde kalıyor. Akış şeması oluşturucu sayfası diğer şekilleri ve kulvar düzenini gösteriyor.
SSS
Olay müdahale akış şemasının sahibi kim olmalı? Nöbet rotasyonunu yürüten ekip. Birinin sıradaki adımı bilemediği her olaydan sonra şemayı gözden geçirin.
Her alarm bir olay mı olmalı? Hayır. Çoğu alarm sıradan iş olarak ele alınmalıdır. Ölçütleriniz karşılandığında olay ilan edin; emin değilseniz erken ilan edin.
Küçük olaylar için olay komutanı gerekir mi? Birinin genel resmi tutması gerekir. Küçük bir olayda komutan nöbetçi mühendistir ve bunu yüksek sesle söylemek, iki kişinin aynı şeyi farklı yollarla düzeltmeye çalışmasını önler.
Postmortem ne zaman yazılmalı? Ayrıntılar tazeyken, kısa sürede. Ekibinizin tutabileceği bir son tarih belirleyin, şemaya yazın ve aksiyonları takip edin.
Akış şeması güvenlik olaylarını da kapsamalı mı? Bunları güvenlik olayı sürecinize devreden bir dal ekleyin. O sürecin kanıtların korunması ve hukuki inceleme gibi farklı adımları vardır.