Mühendislikte Otopsi (post-mortem)

Bir yazılım mühendisi ya da sistem mühendisi için en önemli öğrenim zamanları sistemlerin çöktüğü (outage / downtime) zamanlardır. Meslek hayatımızda görece seyrek olarak karşılaşsak, hatta hiç karşılaşmak istemesek de birim zamanda maksimum tecrübeyi kazanmamıza fayda sağlayabilirler. Sistemlerin çöktüğü senaryolarla şirketimizin bir daha karşılaşmaması için, hatta kendi mesleğimizde bir daha karşılaşmamak için, doğru teknik otopsi (post-mortem) yapabilmek büyük önem taşır. Bu yazıda büyük şirketlerin yayınladıkları otopsi raporlarından örnekler vererek iyi bir otopsi yapabilmenin yöntemlerinden bahsedeceğim.

iyzico’da bir post-mortem sonrası

Teknik otopsilerde temel olarak aşağıdaki 4 sorunun cevabını ararız:

1. Ne oldu?: Ne olduğunu iyi anlamadan problemi analiz etmemiz zor olacaktır.
2. Neden oldu?: Sistemsel problem yaşanmasını tetikleyen en önemli ve büyük olayların neler olduğunu çıkarıp ana nedene (root cause) inebilmek önem taşır. Teknik hatanın asıl sebebini bulup bununla yetinmemek gerekir. Ek olarak problemi tetiklemesi muhtemel yönetim yapısı, şirket kültürü ve takımların çalışma ortamları gibi teknik olmayan konular ile ilgili analiz yapmak da stratejik olarak fayda sağlayacaktır.
3. Nasıl tepki gösterdik ve düzelttik?: Oluşan problemi ne kadar hızlı farkettiğimiz, nasıl farkettiğimiz, temel sebebi ne kadar hızlı bulduğumuz ve problemi ne kadar hızlı çözdüğümüze bakmamız gerekir. Büyük sistemsel çöküşler şirketin gelirini, müşteri memnuniyetini, pazar payını ve marka güvenilirliğini negatif etkiler. Dolayısıyla iyi bir teknik otopsinin kabul edilebilir seviyede bir şeffaflığa, veriye dayalı etki analizine ve tüm organizasyonla işbirliğine ihtiyacı vardır. Otopsinin çıktısı olarak “iyi çalışan” süreçleri ve “çalışmayan” süreçleri görebilmemiz gerekir.
4. Bir daha benzer bir beklenmedik olayın olmamasını nasıl sağlarız?: Sadece karşılaşılan olayı analiz edip yazılı bir rapor çıkarmamız tek başına yeterli olmayacaktır. Problemden öğrenimler çıkarıp bir daha olmaması için uygulanabilir planlar ve eylemler çıkarabilmek önemlidir. İyi bir otopsi hem teknik hem de yönetimsel konulara odaklanır. Kötü otopsiler ise ekiplerin birbirini suçlamasına, hatta daha da ileri giderek kişilerin suçlanmasına yol açabilir. Dolayısıyla organizasyonların, dürüstlüğü cezalandırmaktansa dinleyip veriye dayalı analiz etmesi büyük önem taşır.

Büyük sistem çöküşlerinden dersler çıkarmak kariyerimiz için çok önemlidir. Bu tür olaylarla çalıştığımız şirketlerde seyrek karşılaşırız. Bu nedenle başka şirketlerin yayınladığı otopsi raporlarını okumanın kişisel gelişimimiz için çok önemli olduğunu düşünüyorum. Michael T. Nygard “Release It!” isimli kitabında çok fazla teknik otopsi raporuna yer vermiştir ve tecrübeli mühendisler için çok faydalı bir kitaptır (Başlangıç seviyesi için önermiyorum). CloudFlare’in yakın zamanda gerçekleşen çöküşünün otopsi raporunda yer alan, bir veri bilimcinin görselleştirdiği kayıt durumu tüm şeffaflığıyla anlatmış. CloudFlare’in internetten yavaş yavaş yok oluşunu görsel olarak anlatıyor:

https://www.youtube.com/watch?time_continue=3&v=wMRaKtydILI

Yayınlanmış önemli otopsi raporları:

• Yakın zamanda gerçekleşen CloudFlare çöküşü: https://blog.cloudflare.com/todays-outage-post-mortem-82515/
• AWS’in S3 çöküşü: https://aws.amazon.com/message/41926/
• 2015'te Facebook ve Instagram’ın aynı anda çökmesi: https://blog.thousandeyes.com/facebook-outage-deep-dive/
• Gitlab’ın veri kaybının da yaşandığı veri tabanı çöküşü: https://about.gitlab.com/2017/02/10/postmortem-of-database-outage-of-january-31/

Bu sayfada da sebeplerine göre gruplanmış birçok rapor bulunuyor: https://github.com/danluu/post-mortems

Sizin de beğendiğiniz faydalı teknik otopsi (post-mortem) raporları varsa yorum olarak paylaşabilirsiniz.

Referanslar:

• https://www.fiixsoftware.com/blog/4-questions-effective-technical-post-mortem/
• https://github.com/danluu/post-mortems
• https://blog.cloudflare.com/todays-outage-post-mortem-82515/
• https://www.portent.com/blog/project-management/tips-for-a-successful-post-mortem.htm
• https://www.loomsystems.com/blog/top-5-it-outages-in-history-of-the-internet
• https://www.amazon.com/Release-Production-Ready-Software-Pragmatic-Programmers/dp/0978739213
• https://hackernoon.com/post-mortems-are-for-learning-and-sharing-1b6a38526923