Yazılım Kesintisi Sonrası: Olay Müdahalesi ve Öğrenme Raporu

İlk soru kimin hatası değil, kimin etkilendiği olsun

Olayın başında etkilenen müşteri işleri, başlangıç zamanı ve kapsamı belirlemeye çalışın. Giriş mi çalışmıyor, siparişler mi bekliyor, sadece raporlar mı gecikiyor? Bütün siteyi “kapalı” veya “açık” olarak etiketlemek gerçek kullanıcı etkisini gizleyebilir.

Google SRE olay müdahalesi yaklaşımı, koordinasyon ve görev ayrımının önemini ele alır. [1] Bir kişi müdahaleyi koordine ederken başkaları teknik araştırma ve iletişim görevini yürütebilir. Küçük ekipte aynı kişi birkaç rol taşısa bile sorumluluklar açık olmalıdır.

Güvenli iyileştirmeyi tam teşhisten ayırın

Her olayda kök neden tamamen bulunmadan önce etki azaltılabilir. Son sürümü geri alma, riskli özelliği kapatma veya belirli işi geçici olarak durdurma seçenekleri değerlendirilebilir. Bu kararların yeni veri hatası yaratıp yaratmayacağı kontrol edilmelidir.

Kesinti sırasında aynı anda birden fazla değişiklik yapmak hangi işlemin işe yaradığını belirsizleştirebilir. Yapılan müdahale, zamanı, sorumlusu ve beklenen etkisi olay kaydına yazılsın. Üretim değişiklikleri uygun yetkiyle ve tanımlı süreçle yapılmalıdır.

Örnek: siparişler alınıyor ama ERP’ye gitmiyor

Varsayımsal mağaza müşteriden sipariş alıyor, fakat aktarım kuyruğu büyüyor. Ana sayfa açık olduğu için basit sağlık kontrolü sorun göstermiyor. Etkilenen iş siparişin operasyon sistemine geçmesidir. İlk hedef yeni kayıpları önlemek ve bekleyen siparişleri korumaktır.

Bu senaryo gerçek bir olay anlatımı değildir. Süreç provasının örneğidir; müşteri etkisi ve çözüm süresi hakkında uydurma sonuç içermez.

Kullanıcıya doğrulanmış bilgi verin

Kesin olmayan neden veya bitiş zamanı açıklamayın. Bilinen etkiyi, devam eden incelemeyi ve doğrulanmış sonraki güncellemeyi aktarın. Teknik ekip ve destek ekibi farklı mesajlar vermemelidir. Müşteriden aynı işlemi tekrar etmesini istemeden önce çift işlem riskini değerlendirin.

Olay iletişiminde hassas sistem bilgileri veya müşteri verileri paylaşılmamalıdır. İç teknik kayıtla dış durum mesajını ayırın. Bir sorunun giderildiği söylenirken hangi kontrolün geçtiği belli olsun; yalnızca hata grafiğinin düşmesi tüm bekleyen işlerin tamamlandığını kanıtlamayabilir.

İyileşme sonrasında veri uzlaştırması yapın

Servis yeniden çalışınca kayıp, tekrar veya yarım işlem kalmış olabilir. Kaynak ve hedef kayıtları karşılaştırın. Yeniden deneme kuyruğunun temizlenmesiyle iş doğruluğunu aynı kabul etmeyin. Özellikle sipariş ve bildirim akışlarında yinelenen sonuçlar araştırılmalıdır.

Olayın kapanış ölçütü önceden tanımlanabilir: kritik işlerin çalışması, bekleyen kapsamın incelenmesi ve bilinen risklerin kayda alınması. Bütün belirsizlikler giderilmemişse bunu gizlemek yerine takip görevleriyle açıkça belirtin.

Öğrenme raporunu kişisel suçlamadan çıkarın

Google SRE postmortem yaklaşımı, olaylardan öğrenmeyi ve sistem koşullarını incelemeyi vurgular. [2] Raporda zaman çizelgesi, etki, tetikleyici, katkıda bulunan koşullar ve iyileştirme işleri yer alsın. “Bir çalışan yanlış düğmeye bastı” açıklaması, yanlış işlemin neden mümkün olduğunu tek başına anlatmaz.

Her aksiyonun sorumlusu ve doğrulama yöntemi bulunsun. “Daha dikkatli olacağız” yerine test ekleme, yetki sınırı, yayın kontrolü veya alarm iyileştirmesi gibi somut işler tanımlayın. Aksiyon kapandığında gerçekten işe yarayıp yaramadığı prova edilsin.

Sık sorulan sorular

### Sistem açılınca olay kapatılabilir mi? Kritik iş sonuçları ve veri tutarlılığı doğrulanmalıdır. Teknik erişim geri gelmiş olsa bile bekleyen veya tekrarlı işlemler kalabilir.

Her küçük hata için uzun rapor gerekir mi?

Kapsam olayın etkisine göre değişebilir. Önemli olan öğrenilen sorunun kaybolmaması ve tekrarını azaltacak somut aksiyonun takip edilmesidir.