Kariyerimin ilk yıllarında, adeta hastalık derecesinde takıntılı bir mükemmeliyetçiydim. Yazdığım tek bir satır kodu, küçük bir fonksiyonu veya basit bir veritabanı sorgusunu yayına (production) almadan önce günlerce test eder, defalarca üzerinden geçer, olası her kötü senaryoyu düşünmekten uykularımı kaçırırdım. Bir şeyler yanlış giderse dünyanın sonunun geleceğine inanırdım. Sonuç ne mi oldu? Projeler asla zamanında bitmezdi. Teslim tarihleri (deadline) hep kaçırılırdı. Ve en komiği, onca strese ve teste rağmen yayına alınan o "kusursuz" kod, ilk gün hiç aklıma gelmeyen absürt bir kullanıcı hareketi yüzünden yine patlardı.
Bir gün, devasa bir e-ticaret altyapısını yönetirken hayatımın en büyük aydınlanmalarından birini yaşadım. Bir şeyi fark etmiştim: Hata yapmayı engellemeye, her şeyi kusursuz tasarlamaya çalışmak, aslında o ekibin ve şirketin ilerlemesini, yenilik yapmasını engellemekti. Sürekli savunmada kalarak devrimsel hiçbir şey inşa edemezsiniz.
DevOps kültürü bana çok sert ama paha biçilemez bir şey öğretti. Sektördeki en iyi mühendislerin odaklandığı metrik, sistemin ne kadar süre hatasız çalıştığı (Mean Time Between Failures - MTBF) değildir. Asıl odaklandıkları şey, sistem çöktüğünde ne kadar hızlı toparlanabildiğidir (Mean Time To Recovery - MTTR). Kısacası, önemli olan yere hiç düşmemek değil, düştüğünüz yerden ne kadar hızlı kalkabildiğinizdir. Biz buna mühendislikte "Resilience" (esneklik/dayanıklılık) diyoruz. Netflix'in icat ettiği "Chaos Engineering" (Kaos Mühendisliği) konsepti tam da buna dayanır. Adamlar kendi production sunucularını kasıtlı olarak çökerten yazılımlar ("Chaos Monkey") yaptılar, sadece sistemlerinin bu felaketlerden nasıl otomatik kurtulabildiğini test etmek için! Bu benim için zihin açıcıydı.
Artık kodun veya altyapının %100 kusursuz olması için haftalarımı harcamıyorum. Onun yerine zamanımı ve enerjimi harika bir CI/CD pipeline'ı kurmaya, muazzam bir loglama yapısına ve anlık izleme (monitoring) sistemlerine harcıyorum. Sistemi auto-scaling (otomatik ölçekleme) ve self-healing (kendi kendini onarma) prensipleriyle tasarlıyorum. Artık bir şeyler patladığında paniklemiyorum, çünkü anında haberim oluyor. Nerede, neden patladığını görüyor, birkaç dakika içinde hatayı geri alıyor (rollback), düzeltip yola devam ediyorum. Deployment (yayına alma) korkusu tamamen bitti.
İlginçtir ki, DevOps'tan öğrendiğim bu teknik yaklaşım, zamanla benim kişisel hayatıma ve liderlik felsefeme de sızdı. Sürekli "en doğru" veya "en mükemmel" kararı vermek için felç olmak (analysis paralysis) yerine, artık sadece karar veriyorum ve deniyorum. Şirket (Suku Tech) için yeni bir teknoloji mi deneyeceğiz? Hemen prototipini yapıyoruz. Eğer hata yaparsam, eğer o teknoloji bizi yolda bırakırsa, bu artık benim gözümde bir "başarısızlık" değil; sadece sistemime düşen, incelenmesi gereken bir "log kaydı".
Hatayı analiz ediyor, dersimi alıyor, yamayı (patch) atıyor ve yoluma çok daha güçlü bir şekilde devam ediyorum. Mükemmeliyetçilik sadece bir illüzyon. Sizi yavaşlatan, korkutan, risk almanızı engelleyen koca bir yalan. Sık sık hata yapan, ama hatalarından saniyeler içinde öğrenip kendini düzelten bir sistem, masada duran ve hiç yayına alınmamış o "kusursuz" plandan her zaman, ama her zaman daha iyidir. Hata yapmayı kucaklayın, çünkü gerçek büyüme orada başlıyor.