Giriş ------ Olaylar (incidents) kaçınılmazdır. Önemli olan tepkimizdir. "Suçsuz" (blameless) postmortem, hatayı bulmaktan çok sistemi ve süreçleri iyileştirmeye odaklanır. Bu taslak, altyapı yöneticisi bakış açısıyla, profesyonel ama samimi bir üslupla olay sonrası raporun nasıl yazılacağını anlatır. Amaç: öğrenmek, tekrarı azaltmak ve eyleme dönüştürülebilir sonuç üretmektir.
Temel ilkeler ------------- - Blameless yaklaşım: Bireyleri hedef almak yerine sistemik nedenleri araştırın. - Gerçekçilik: Ne olduğunu açık ve net yazın; belirsizlikleri belirtin. - Ölçülebilir eylemler: Her düzeltici faaliyet (action item) sahibi, önceliği ve son tarihi olmalı. - Tetkik edilebilirlik: İddialar verilerle desteklenmeli; kaynaklar ve log arama sorguları paylaşılmalı. - Zamanında yayın: Olayın hafızası taze iken draft hazırlayın; revizyonlarla son haline getirin.
Postmortem yapısı (Önerilen başlıklar) ------------------------------------- 1. Özet (Summary) - Kısa, bir paragraf: ne oldu, etki, süresi. 2. Zaman Çizelgesi (Timeline) - Kronolojik olay akışı; zaman damgalarıyla. 3. Etki (Impact) - Kim/kaç kullanıcı/servis etkilendi; iş ayağı üzerindeki sonuçları. 4. Kök Neden Analizi (Root Cause Analysis) - Hipotezler, testler ve sonuçlar. Sistem, süreç veya konfigürasyon hatalarına odaklanın. 5. Alındı/Alınmayan Önlemler (Mitigations/Workarounds) - Olay sırasında uygulanan kısa vadeli çözümler. 6. Kalıcı Düzeltmeler (Permanent Fixes) - Planlanan ve tamamlanan kalıcı iyileştirmeler. 7. Öğrenilenler (Lessons Learned) - Ne işe yaradı/yaramadı; süreçsel gözlemler. 8. Eylem Listesi (Action Items) - Sorumlu, öncelik ve hedef tarih ile somut maddeler. 9. Ekler (Appendices) - Log arama sorguları, konfigürasyon snippetleri, dashboard ekran görüntüleri (gerekliyse).
Dil ve ton ---------- - Nesnel ve açıklayıcı olun. "Yanlış yaptı" yerine "bu süreç bu davranışı teşvik etti" gibi yapılandırılmış cümleler kullanın. - Kısa cümleler, aktif dil. Teknik okuyucular için yeterince detay; yönetim için özet. - Kişisel saldırı, itham veya alay içeren ifadeler yasak.
Zaman çizelgesi nasıl yazılır (pratik notlar) --------------------------------------------- - Her adım: zaman damgası (UTC veya yerel saat belirtilmiş), aktör (insan/otomasyon), yapılan eylem ve gözlem. - Belirsizlik varsa "saat XX:YY civarı" veya "log bulgusu: ..." gibi açıklayın. - Örnek format (JSON-like veya basit satır): - 2026-09-25T04:12:03Z — alert: load spike on api-prod — paging: on-call - 2026-09-25T04:13:10Z — on-call investigated; restarted worker pool
Kısa kod/snippet: log sorgusu ve timeline çıkarma ------------------------------------------------ Aşağıdaki örnek, merkezi log sisteminde basit sorgu ile ilgili aralıkta hata sayısını ve önemli mesajları filtreleme amaçlıdır. (Sorgu kullandığınız sisteme göre uyarlanmalıdır.)
Örnek: Elasticsearch/Opensearch _search ile zaman aralığı ve hata seviyesi filtreleme curl -s -X POST "http://logs.example.local:9200/_search" -H 'Content-Type: application/json' -d' { "query": { "bool": { "must": [ { "range": { "@timestamp": { "gte": "2026-09-25T04:00:00Z", "lte": "2026-09-25T05:00:00Z" } } }, { "match": { "log.level": "error" } } ] } }, "sort": [{ "@timestamp": { "order": "asc" } }], "size": 500 } ' | jq '.hits.hits[]._source | {ts: ."@timestamp", service, message}'
Kök neden (örnek yaklaşım, kurgu yok) ------------------------------------- Root Cause Analysis (RCA) şu adımları içermeli: - Faktların toplanması: loglar, metricler, konfigürasyon geçmişi, deploy geçmişi. - Hipotez oluşturma: "A, B veya C olmuş olabilir" şeklinde sıralama. - Test etme: rollback, konfigürasyon karşılaştırması, reprodüksiyon denemeleri. - Sonuç: hangi koşullar birleştiğinde hata tetiklendiğini netleştirin.
Eylem maddeleri örnekleri (her madde SMART olmalı) ------------------------------------------------- - "API worker restart scriptine eksik hata kontrolü eklenecek" — sahibi: altyapı ekibi, öncelik: yüksek, hedef tarih: 2026-10-12. - "Deployment geri alım prosedürü runbook'a adım adım eklenecek ve ekip eğitimine konulacak" — sahibi: SRE lead, öncelik: orta, hedef tarih: 2026-10-19. - "Metric alert eşik değeri gözden geçirilecek; false positive'ler azaltılacak" — sahibi: monitoring sahibi, öncelik: yüksek, hedef tarih: 2026-10-08.
Kontrol listesi (Postmortem yayınlamadan önce) --------------------------------------------- - [ ] Olayın kısa özeti (1 paragraf) yazıldı. - [ ] Zaman çizelgesi kronolojik ve doğrulanabilir. - [ ] Root cause açık ve veriyle desteklenmiş. - [ ] En az bir kalıcı düzeltme (permanent fix) planlandı. - [ ] Her action item için sorumlu ve tarih belirlendi. - [ ] Kişisel suçlama içeren ifadeler çıkarıldı veya yenilendi. - [ ] İlgili ekipler/kişiler taslağı inceledi (gerekliyse anonimleştirme yapıldı). - [ ] İlgili dashboard, log sorgusu ve gerekliyse ekran görüntüleri eklendi. - [ ] Yayın için gerekli güvenlik/gizlilik kontrolleri yapıldı (özellikle müşteri verisi içeriyorsa).
Yaygın hatalar ve kaçınma yolları ------------------------------- - "Suçlayıcı" dil kullanmak: Metni üçüncü bir gözle okuyun; kişiselleştiren ifadeleri çıkarın. - Eksik veri: İddiaları destekleyecek log/metric bağlantıları eklememek. - Belirsiz eylemler: "iyileştirme yapılacak" yerine "kimin, ne zaman, ne yapacağı" net olmalı. - Tekrar eden hataların kayıt altına alınmaması: Postmortem'leri bir arada aranan bir KB (knowledge base) yapın.
Kapanış ------- Bir postmortem iyi yazıldığında ekiplerin öğrenmesini hızlandırır, tekrarı azaltır ve güveni artırır. Suçsuz (blameless) yaklaşım, davranış değişimi yaratmanın ön koşuludur. Bu taslak, sahadan gelen pratik önerilerle postmortemleri daha etkili hale getirmeye yönelik bir başlangıç sunar. Yorumlarınızı, eksik gördüğünüz adımları veya kendi rutininize uyarlama önerilerinizi beklerim.