İş akışlarından veri modeline ve UX'e kadar, olay takibi ve postmortem yönetimi için bir web uygulamasını tasarlama, oluşturma ve başlatma hakkında pratik bir yol haritası.
Ekran tasarlamadan veya veritabanı seçmeden önce, ekibinizin olay izleme web uygulaması ile ne demek istediği ve “postmortem yönetimi”nin neyi başarması gerektiği konusunda uzlaşın. Ekipler aynı kelimeleri farklı şekillerde kullanır: bir grup için olay her müşteri bildirimi olabilir; bir başkası içinse yalnızca on-call yükseltmesi gerektiren Sev-1 kesintisi olabilir.
Kısa bir tanım yazın ve şu soruları yanıtlayın:
Bu tanım, olay müdahale iş akışınızı yönlendirir ve uygulamanın ya çok katı (kimse kullanmaz) ya da çok gevşek (veri tutarsız) olmasını engeller.
Bir postmortem’in kuruluşunuz için ne olduğunu belirleyin: her olay için hafif bir özet mi, yoksa yalnızca yüksek şiddetli olaylar için tam bir RCA mı? Hedefin öğrenme, uyumluluk, tekrarlayan olayları azaltma veya bunların tümü olup olmadığını açıkça belirtin.
Yararlı bir kural: postmortem’in değişim üretmesini bekliyorsanız, aracınız eylem öğeleri takibini desteklemelidir; sadece belge depolamak yeterli değildir.
Çoğu ekip bu tür bir uygulamayı tekrar eden birkaç ağrılı noktayı çözmek için kurar:
Bu listeyi kısa tutun. Eklediğiniz her özellik en az bir probleme karşılık gelmelidir.
Uygulamanızın veri modelinden otomatik olarak ölçebileceğiniz birkaç metrik seçin:
Bunlar ilk sürüm için operasyonel metrikleriniz ve “yapıldı tanımınız” olur.
Aynı uygulama nöbet operasyonları içinde farklı rollerin ihtiyaçlarını karşılar:
Hepsini aynı anda tasarlarsanız karışık bir UI elde edersiniz. Bunun yerine, v1 için birincil kullanıcıyı seçin—ve diğerlerinin ihtiyaçlarını daha sonra özelleştirilmiş görünümler, panolar ve izinlerle almasını sağlayın.
Net bir iş akışı iki yaygın başarısızlık biçimini önler: kimsenin “sonraki adım”ı bilmediği için duraklayan olaylar ve “bitmiş” görünen ama öğrenme üretmeyen olaylar. Yaşam döngünüzü baştan sona haritalayın ve her adıma roller ve izinler atayın.
Çoğu ekip basit bir çizgiyi takip eder: tespit → ön değerlendirme → hafifletme → çözüm → öğrenme. Uygulamanız bunu küçük ve öngörülebilir adımlarla yansıtmalı, sonsuz bir seçenek menüsüyle değil.
Her aşama için “tamam” tanımını yapın. Örneğin, hafifletme müşteri etkisinin durdurulması anlamına gelebilir; kök neden hâlâ bilinmiyor olabilir.
Rolleri açık tutun ki insanlar toplantıları beklemeden hareket edebilsin:
UI’niz “güncel sahip”i görünür kılmalı ve iş akışı devretmeyi desteklemelidir (yeniden atama, yanıtlayıcı ekleme, komutan döndürme).
Gerekli durumları ve izin verilen geçişleri seçin, örneğin İnceleniyor → Hafifletildi → Çözüldü. Koruyucular ekleyin:
Dahili güncellemeler (hızlı, taktiksel, dağınık olabilir) ile paydaşlara yönelik güncellemeler (net, zaman damgalı, seçilmiş) arasında ayrım yapın. Farklı şablonlar, görünürlük ve onay kurallarıyla iki güncelleme akışı oluşturun—çoğu durumda komutan, paydaş güncellemelerinin tek yayımlayıcısıdır.
İyi bir olay aracı UI'da “basit” hissi verir çünkü altında tutarlı bir veri modeli vardır. Ekranları oluşturmadan önce hangi nesnelerin var olduğunu, nasıl ilişkili olduklarını ve hangi verilerin tarihsel olarak doğru tutulması gerektiğini belirleyin.
Küçük bir ilk sınıf nesne setiyle başlayın:
Çoğu ilişki bire çoktur:
Olaylar ve olay içi etkinlikler için kararlı tanımlayıcılar (UUID) kullanın. İnsanların yine de INC-2025-0042 gibi okunabilir bir anahtara ihtiyacı olur; bunu sıra numarasından üretebilirsiniz.
Bunları erken modelleyin ki filtreleme, arama ve raporlama yapabilesiniz:
Olay verileri hassas olabilir ve sonra incelenir. Düzenlemeleri verinin bir parçası olarak ele alın—üst yazma yapmayın:
Bu yapı, daha sonra arama, metrikler ve izinler gibi özellikleri yeniden çalışmadan uygulamayı kolaylaştırır.
Bir şey bozulduğunda uygulamanın görevi yazma işini azaltmak ve netliği artırmaktır. Bu bölüm “yazma yolu”nu kapsar: insanların nasıl olay oluşturduğu, güncellediği ve sonra ne olduğunu nasıl yeniden kurduğu.
Kayıt formunu, sorun giderirken tamamlanabilecek kadar kısa tutun. İyi bir varsayılan zorunlu alan seti şunlardır:
Diğer her şey oluşturma sırasında isteğe bağlı olmalı (etki, müşteri talep bağlantıları, şüpheli neden). Akıllı varsayılanlar kullanın: başlangıç zamanını “şimdi”ye, kullanıcının nöbet ekibini ön seçime ayarlayın ve bir dokunuşla “Olay odası oluştur ve aç” eylemi sunun.
Güncelleme UI'nız tekrarlanan küçük düzenlemeler için optimize edilmeli. Kompakt bir güncelleme paneli sağlayın:
Güncellemeleri eklemeye uygun yapın: her güncelleme zaman damgalı bir giriş olsun, önceki metnin üstüne yazılmasın.
Aşağıdakileri karıştıran bir zaman çizelgesi oluşturun:
Bu, insanların her tıklamayı kaydetmelerini zorlamadan güvenilir bir anlatı oluşturur.
Bir kesinti sırasında birçok güncelleme telefondan gelir. Hızlı, düşük engelli bir ekran önceliklendirin: büyük dokunmatik hedefler, tek kaydırmalı sayfa, çevrimdışı taslaklar ve “Güncelleme gönder” ve “Olay bağlantısını kopyala” gibi tek dokunuş eylemler.
Şiddet, olay müdahalesinin “hız düğmesi”dir: insanlara ne kadar acil davranacaklarını, ne kadar geniş iletişim yapılacağını ve hangi ödünlerin kabul edilebilir olduğunu söyler.
“yüksek/orta/düşük” gibi belirsiz etiketlerden kaçının. Her şiddet seviyesini açık operasyonel beklentilerle—özellikle yanıt süresi ve iletişim takvimi—eşleştirin.
Örneğin:
Bu kuralları, şiddetin seçildiği her yerde UI’da görünür yapın ki yanıtlayanlar olağanüstü durum dokümanlarında arama yapmak zorunda kalmasın.
Stres altındayken kontrol listeleri bilişsel yükü azaltır. Kısa, uygulanabilir ve rollere bağlı tutun.
Yararlı bir desen birkaç bölüm içerir:
Kontrol listesi maddelerini zaman damgalı ve atfedilebilir yapın ki bunlar olay kaydının bir parçası olsun.
Olaylar nadiren tek bir araçta yaşar. Yanıtlayıcıların bağlayabileceği bağlantılar sunun:
Filtrelenebilir olsun diye “tiplenmiş” bağlantıları tercih edin (ör. Runbook, Ticket).
Kuruluşunuz güvenilirlik hedefleri tutuyorsa, SLO etkilendi (evet/hayır), tahmini hata bütçesi tüketimi ve müşteri SLA riski gibi hafif alanlar ekleyin. Bunları isteğe bağlı tutun—ama olay sırasında veya hemen sonra doldurulması kolay olsun.
İyi bir postmortem başlamak için kolay, unutması zor ve ekipler arasında tutarlı olmalıdır. Bunu sağlamanın en basit yolu varsayılan bir şablon sunmak (az zorunlu alanla) ve postmortemi olay kaydından otomatik doldurmaktır, böylece insanlar düşünmeye zaman harcar—tekrar yazmaya değil.
Yerleşik şablonunuz yapı ile esnekliği dengelemeli:
“Kök neden”i hızlı yayımlama için başta isteğe bağlı yapabilirsiniz; ancak nihai onaydan önce zorunlu kılın.
Postmortem ayrı bir belgede yüzmesin. Bir postmortem oluşturulduğunda otomatik olarak ekleyin:
Bunları postmortem bölümlerini ön-doldurmak için kullanın. Örneğin, “Etkİ” bloğu olayın başlama/bitiş zamanları ve mevcut şiddetiyle başlayabilir; “Yaptıklarımız” zaman çizelgesi girdilerinden çekilebilir.
Postmortemlerin takılı kalmaması için hafif bir iş akışı ekleyin:
Her adımda karar notları kaydedin: ne değişti, neden değişti ve kim onayladı. Bu, “sessiz düzenlemeler”i önler ve gelecekteki denetimler veya öğrenme incelemeleri için kolaylık sağlar.
UI'yi basit tutmak isterseniz, incelemeleri yorumlar gibi ele alın ve açık sonuçlarla (Onayla / Değişiklik iste) saklayın; nihai onayı değiştirilemez bir kayıt olarak tutun.
Dilerseniz “Yayınlandı”yı durum güncellemeleri iş akışınıza bağlayın (ör. /blog/integrations-status-updates) ama içeriği elle kopyalamadan.
Postmortemler sadece takip işleri yapıldığında gelecekteki olayları azaltır. Eylem öğelerini bir belgenin alt paragrafı olarak değil, uygulamanızda birinci sınıf nesneler olarak ele alın.
Her eylem öğesi tutarlı alanlara sahip olmalıdır ki ölçülebilsin:
Küçük ama faydalı meta veriler ekleyin: etiketler (örn. “izleme”, “dokümantasyon”), bileşen/servis ve “oluşturulduğu yer” (olay ID ve postmortem ID).
Eylem öğelerini tek bir postmortem sayfasına hapsetmeyin. Sunun:
Bu, takipleri dağınık notlardan ziyade operasyonel bir kuyruğa dönüştürür.
Bazı görevler yinelenir (çeyreklik oyun günleri, runbook incelemeleri). Bir yinelenen şablon destekleyin; bu, programlı olarak yeni öğeler oluşturur ama her örneği bağımsız izlenebilir kılar.
Ekipler başka bir takip aracı kullanıyorsa, bir eylem öğesinin dış referans bağlantısı ve dış ID içermesine izin verin; yine de uygulamanız olay bağlantısı ve doğrulama için kaynak olsun.
Hafif hatırlatmalar ekleyin: bitiş tarihine yaklaşanlarda sahipleri uyarın, gecikmiş öğeleri takım liderine işaretleyin ve kronik gecikmeleri raporlarda gösterin. Kuralları yapılandırılabilir tutun ki ekipler kendi nöbet operasyonlarına ve iş yükü gerçeklerine uyarlayabilsin.
Olaylar ve postmortemler genellikle hassas detaylar içerir—müşteri kimlikleri, dahili IP’ler, güvenlik bulguları veya tedarikçi sorunları. Net erişim kuralları aracı işbirliği için yararlı tutar ve veri sızıntılarını engeller.
Anlaşılır, küçük bir rol setiyle başlayın:
Birden fazla takımınız varsa, rolleri servis/ekip bazında kapsamlandırmayı düşünün (ör. “Ödemeler Editörleri”)—genel geniş erişim vermektense.
İnsanlar alışkanlık kazanmadan önce içeriği sınıflandırın:
Pratik bir desen, bölümleri Dahili veya Paylaşılabilir olarak işaretlemek ve dışa aktarma ile durum sayfalarında bunu zorunlu kılmaktır. Güvenlik olayları daha sıkı varsayılanlara sahip ayrı bir olay tipi gerektirebilir.
Olaylar ve postmortemlerdeki her değişiklik için: kim değiştirdi, ne değişti ve ne zaman kaydedin. Şiddet, zaman damgaları, etki ve “nihai” onaylar gibi düzenlemeleri dahil edin. Denetim günlüklerini aranabilir ve düzenlenemez yapın.
E-posta + MFA veya magic link gibi güçlü kimlik doğrulamayı yerleşik destekleyin ve kullanıcılarınız bekliyorsa SSO (SAML/OIDC) ekleyin. Kısa ömürlü oturumlar, güvenli çerezler, CSRF koruması ve rol değişikliklerinde otomatik oturum iptali kullanın. Rollout ile ilgili daha fazla düşünce için /blog/testing-rollout-continuous-improvement adresine bakabilirsiniz.
Bir olay aktifken insanlar tarama yapar—okumaz. UX’iniz güncel durumu saniyeler içinde açık hale getirmeli, aynı zamanda yanıtlayanların detaylara kaybolmadan inmesine izin vermelidir.
Çoğu iş akışını kapsayan üç ekranla başlayın:
Basit bir kural: olay detay sayfası üstte “Şu an ne oluyor?” sorusunu, altta “Buraya nasıl geldik?” sorusunu yanıtlamalı.
Olaylar hızla birikir; keşfi hızlı ve hoşgörülü yapın:
Nöbetçi mühendislerin her nöbet için filtreleri yeniden kurmaması için Benim açık olaylarım veya Bu hafta Sev-1 gibi kaydedilmiş görünümler sunun.
Uygulama genelinde tutarlı, renk açısından güvenli rozetler kullanın (stres altındaki görüş için başarısız olan ince tonlardan kaçının). Aynı durum sözlüğünü liste, detay başlığı ve zaman çizelgesi olaylarında kullanın.
Bir bakışta yanıtlayanlar şunu görmelidir:
Tarama kolaylığını önceliklendirin:
En kötü anı düşünün: birisi uykusuz ve telefondan çağırılıyor; UI hala doğru eyleme hızlıca yönlendirmeli.
Entegrasyonlar, bir olay izleyiciyi “not almak için bir yer”den ekibin gerçekten olayları yönettiği sisteme dönüştürür. Bağlanmanız gereken sistemleri listeleyerek başlayın: izleme/observability (PagerDuty/Opsgenie, Datadog, CloudWatch), sohbet (Slack/Teams), e-posta, ticketing (Jira/ServiceNow) ve bir durum sayfası.
Çoğu ekip karışık bir yaklaşım kullanır:
Alarmlar gürültülüdür, tekrar edilir ve sırası karışabilir. Sağlayıcı olay başına kararlı bir idempotency key tanımlayın (örn: provider + alert_id + occurrence_id) ve bunu benzersiz kısıtlama ile saklayın. Tekilleştirme için kurallar belirleyin: “aynı servis + aynı imza 15 dakika içinde” yeni olay oluşturmak yerine mevcut olaya eklenmelidir.
Uygulamanızın neyi sahiplenip neyi kaynak araçta bırakacağı konusunda açık olun:
Bir entegrasyon başarısız olduğunda, kibarca düşüşe geçin: yeniden deneme için kuyruklayın, olay üzerinde bir uyarı gösterin (“Slack gönderimi gecikti”) ve operatörlerin manuel devam etmesine her zaman izin verin.
Durum güncellemelerini birinci sınıf çıktı olarak ele alın: UI’daki yapılandırılmış bir “Güncelleme” eylemi sohbete yayınlayabilmeli, olay zaman çizelgesine ekleyebilmeli ve isteğe bağlı olarak durum sayfasına senkronize edebilmelidir—yanıtlayandan aynı mesajı üç kez yazmasını istemeden.
Olay aracınız "kesinti sırasında" çalışacak bir sistemdir; bu yüzden yenilikten çok sadelik ve güvenilirlik tercih edin. En iyi yığın genellikle ekibinizin inşa edip gece 2'de hata ayıklayıp işletmeye alabileceği yığındır.
Mühendislerinizin zaten üretimde gönderdiği şeyi seçin. Yaygın bir web framework (Rails, Django, Laravel, Spring, Express/Nest, ASP.NET) genellikle tek bir kişinin bildiği yeni bir frameworkten daha güvenli bir tercihtir.
Veri depolama için ilişkisel bir veritabanı (PostgreSQL/MySQL) olay kayıtları için uygundur: olaylar, güncellemeler, katılımcılar, eylem öğeleri ve postmortemler tümü işlemler ve net ilişkilerden faydalanır. Redis yalnızca gerçekten cache, kuyruk veya geçici kilitlere ihtiyaç varsa ekleyin.
Barındırma, yönetilen bir platform (Render/Fly/Heroku-benzeri) veya mevcut bulutunuz (AWS/GCP/Azure) olabilir. Mümkünse yönetilen veritabanları ve yedeklemeleri tercih edin.
Aktif olaylar gerçek zamanlı güncellemelerle daha iyi hissedilir, ancak ilk gün websocket zorunlu değildir.
Pratik bir yaklaşım: API/olay tasarımınızı polling ile başlamak ve daha sonra websocket'e yükseltmek üzere hazırlayın.
Bu uygulama bir olay sırasında başarısız olursa, olayın bir parçası haline gelir. Şunları ekleyin:
Bunu üretim sistemi gibi ele alın:
İş akışını ve ekranları doğrulamak için tam bir yapıya yatırım yapmadan önce bir prototip isterseniz, vibe-coding yaklaşımı işe yarayabilir: Koder.ai gibi bir araçla detaylı bir sohbet spesifikasyonundan çalışan bir prototip üretin ve ardından gerçek olay tatbikatlarıyla yineleyin. Koder.ai, gerçek React ön yüzleri ile Go + PostgreSQL arka uç üretebildiği ve kaynak kodu dışa aktarabildiği için erken sürümleri “atılacak prototip” veya sertleştirilebilecek bir başlangıç olarak ele alabilirsiniz—gerçek tatbikatlardan elde ettiğiniz öğrenmeleri kaybetmeden.
Bir olay takip uygulamasını prova etmeden yayınlamak kumarlıktır. En iyi ekipler aracı diğer operasyonel sistemler gibi ele alır: kritik yolları test edin, gerçekçi tatbikatlar yapın, kademeli yayımlar yapın ve gerçek kullanım verisine göre ayarlayın.
İnsanların stres altındayken güveneceği akışlara odaklanın:
Zaman damgaları, saat dilimleri ve olay sıralaması gibi kırılmaması gerekenleri doğrulayan regresyon testleri ekleyin. Olaylar bir anlatıdır—zaman çizelgesi yanlışsa güven kaybolur.
İzin hataları operasyonel ve güvenlik riski taşır. Şunları kanıtlayan testler yazın:
Erişim kaybı veya ekip yeniden yapılanması gibi “yakın kaçış” durumlarını da test edin.
Geniş yayımdan önce uygulamayı birincil kaynak olarak kullanarak masaüstü tatbikatları düzenleyin. Kuruluşunuzun tanıdığı senaryoları seçin (ör. kısmi kesinti, veri gecikmesi, üçüncü taraf arızası). Sürtünce noktalarını gözlemleyin: kafa karıştırıcı alanlar, eksik bağlam, çok fazla tıklama, belirsiz sahiplik.
Geri bildirimi hemen yakalayın ve küçük, hızlı iyileştirmelere dönüştürün.
Bir pilot ekip ve birkaç ön yapılandırılmış şablonla (olay tipleri, kontrol listeleri, postmortem formatları) başlayın. Kısa eğitim verin ve uygulamadan bağlantılı kısa bir “bu şekilde olay yönetiriz” kılavuzu sağlayın (ör. /docs/incident-process).
Benimsenme metriklerini izleyin ve sürtünce noktalarını yineleyin: oluşturma süresi, % güncellemeye sahip olaylar, postmortem tamamlama oranı ve eylem öğesi kapatma süresi. Bunları uyum değil, ürün metrikleri gibi ele alın ve her sürümde iyileştirin.
Start by writing a concrete definition your org agrees on:
That definition should map directly to your workflow states and required fields so data stays consistent without becoming burdensome.
Treat postmortems as a workflow, not a document:
If you expect change, you need action-item tracking and reminders—not just storage.
A practical v1 set is:
Skip advanced automation until these flows work smoothly under stress.
Use a small number of predictable stages aligned to how teams actually work:
Define “done” for each stage, then add guardrails:
This prevents stalled incidents and improves the quality of later analysis.
Model a few clear roles and tie them to permissions:
Make the current owner/commander unmistakable in the UI and allow delegation (reassign, rotate commander).
Keep the data model small but structured:
Use stable identifiers (UUIDs) plus a human-friendly key (e.g., INC-2025-0042). Treat edits as history with created_at/created_by and an audit log for changes.
Separate streams and apply different rules:
Implement different templates/visibility, and store both in the incident record so you can reconstruct decisions later without leaking sensitive details.
Define severity levels with explicit expectations (response urgency and comms cadence). For example:
Surface the rules in the UI wherever severity is chosen so responders don’t need external docs during an outage.
Treat action items as structured records, not free text:
Then provide global views (overdue, due soon, by owner/service) and lightweight reminders/escalation so follow-ups don’t vanish after the review meeting.
Use provider-specific idempotency keys and dedup rules:
provider + alert_id + occurrence_idAlways allow manual linking as a fallback when APIs or integrations fail.