Projenizde Otopsi: Postmortem
Projenizde başarısızlık gerçekleşmeden premortem ile önlemeye bir önceki yazımda göz atmıştık. Ancak teknoloji dünyası hızla gelişen bir yer ve öngöremediğimiz sebeplerden dolayı projemiz kesintilere veya başarısızlığa uğrayabilir. Her hatanın sonuçları dramatik değildir. Ancak hataları hızlıca çözmemiz gereken anlar vardır. Bu hataları, postmortem ile bir nevi otopsi yaparak sonucu analiz edebiliriz.
Postmortem, sistem veya hizmetlerimizin çöktüğü durumlarda, neyin yanlış gittiği sorusuna cevap verir. Geçmişten ders çıkarıp bir daha bu gibi durumlarla karşılaşmamak için doğru teknik analiz (postmortem) önemlidir. Böylece aynı hataları yapmaktan kaçınabiliriz. Ayrıca analizi doğru yapan ekipler, her hatadan daha gelişmiş bir şekilde çıkacaklardır.
Postmortem yöntemi olarak, temelde 4 sorunun cevabı aranır. Ne oldu? Neden oldu? Nasıl reaksiyon gösterdik, ve Benzer bir durumun yaşanmaması için ne yapabiliriz?
Öncelikle olayın ne olduğunu anlamak analiz etmemizi kolaylaştıracaktır. Problemi tetikleyen olayların neler olabileceğini çıkararak ana nedeni saptamaya çalışırız. Bunun yanında teknik olmayan sebepleri: iç iletişim, çalışma atmosferi gibi konularda analizde bulunmak stratejik olarak mantıklıdır.
DevOps uzmanı ve yazar Kristian Erbou’nun Build Better Software: How to Enhance Digital Product Quality and Organizational Performance adlı kitabında Erbou, “Five Whys”i benimseyerek temel nedenin nasıl belirleneceğini ve olay analizinin nasıl gerçekleştirileceğine değiniyor. Örneklendirecek olursak;
insanları taklit eden otomasyon robotları, iş birimlerinin yüklediği input dosyasından beslenerek çalışmaktadır. Burada bir kesinti olduğunu varsayalım ve 5 Whys tekniğini uygulayalım.
Sorun neydi?
Schedule vaktinde (çalışma zamanında) çalışması gereken süreç çalışmadı.
Neden çalışmadı?
İş biriminin yüklemesi gereken INPUT dosyasında hatalı veri bulunuyor.
Hatalı veri nedir?
Veriler arasında yer alan tarih formatında yanlıştı.
Tarih formatı neden yanlıştı?
Beklenen format GÜN.AY.YIL olması gerekirken INPUT dosyasında ki tarih formatı AY/GUN/YIL şeklindeydi.
Format neden değişmiş olabilir?
İş birimi INPUT dosyası hazırlarken manuel tarih girme işlemini yanlış yapmış olabilir.
Buradaki 5 kesin bir sayı değildir. Kök sebebe ulaşana kadar Neden? sorusunu sorabilirsiniz.
Ana sebep bulunduktan sonra hızlı ve doğru reaksiyon alınması gerekir. Büyük kesintiler, şirketin marka adını, itibarını, müşteri memnuniyeti ve pazar payını olumsuz etkileyebilir. Bunun hızla giderilmesi için organizasyon işbirliğine ihtiyaç vardır. Bir daha benzer durumun yaşanmaması için knowledgebase oluşturulmalı ve ekipler bundan faydalanmalıdır.
Postmortem, ekibinizin alışık olmadığı bir süreç ise otopsi yapmak zor olabilir. Sonunda kimseye fayda sağlamayan suçlamaya dönüşebilir. Bunun önüne geçmek için parmakla işaret etmekten uzak durulmalı, kişi odaklı değil olay odaklı konuşulmalıdır. Amaç suçlu aramaktan ziyade ekibin ders çıkarmasını sağlamaktır. Bunun için özel bir yönetici atanmalıdır. Olayı baştan sona ele alıp, önemli detayları yakalamalıdır. Oluşturulan knowledgebase ekiple paylaşılmalıdır. Böylece bir hata karşısında hızla ve doğru reaksiyon alabilen ekiplerle, yeni projelerde aynı hatalardan uzak durarak projenizi başarıya ulaştırabilirsiniz.
Hoşça kalın.
