Hata var, Panik yok!
Bir yazılımcıyı en çok mutlu eden şey uygulamasının insanlar tarafından kullanılmasıdır. Yani uygulamanızın “production”,“live”, “canlı” ortamda olmasıdır. Production ortamdadır, yani üreten bir ürüne sahipsiniz demektir. Live ortamdadır, yani canlıdır, yaşıyor, gelişiyor, kendini yenileyerek sürekli büyüyen bir ekosistemdedir. Üretken olmak biz ademoğulları, havvakızları için doğuştan gelen bir arzu olduğundan yazılımcının da yaşayan bir ürüne sahip olması büyük bir hazdır. Tabi bu sorumluluk getirir. Ürünün gelişime açık olması, kullanıcısını tabiri caizse üzmemesi gerekir.
Canlı olan her şeyde olduğu gibi yazılımlarda da yaşarken sorunlar çıkar. Bu yazıyı yazma sebebim, biz ekip olarak, göz bebeği gibi sahip çıktığımız ürünlerimizde bir hata ile karşılaştığımızda nasıl hareket ederiz, sorunu nasıl tespit eder, gözlemler, inceler ve çözüm üretiriz sorularına cevap aramaktır.
Hepsiburada, milyonların alış veriş yaptığı, yine milyonlarca ürünün satıldığı, müşteri memnuniyetinin en öncelikli konu olduğu bir şirket. Ben ise Payment ekibinin Takım Liderliğini üstleniyorum. Hem müşteri için hem de şirket için en önemli takımlardan biri olmamızın verdiği sorumluluk ile ekip olarak elimizden gelenin en iyisini yapmaya çalışıyoruz.😇
Bir ekip için çok önemli olarak gördüğüm, sorun olduğu an sahip olunması gereken iki yetenek var;
- sorunu hızlı tespit edebilme
- tespit ettikten sonra hızlı çözüm üreterek, hızlı reaksiyon alabilme
Haydi bu başlıkları biraz irdeleyelim..
1. Sorunun tespit edilebilmesi
Hepsiburada olarak tamamen microservice mimarisi üzerine inşa edilmiş teknoloji/product ekiplerine sahibiz. Titizlikle bir örümcek ağı gibi kurulmuş microservice mimarisi ile ekipler arası iletişimler ve ekip içi servis iletişimleri kurulmuş durumda.
Distributed bir architecture’a sahip olduğunuz zaman iki konu başlığı sizin için çok önem arz ediyor. Servislerinizin up-time ve response-time verileri. Bunun dışında elbette Scaling, Consistency, Idempotency, Data Durability, Security, Caching vs gibi bir çok başlık var değinmek gereken. Fakat bir hata anında müşteriye de etki eden en mühim konular Availability ve Latency diye düşünüyorum. Bu iki parametreyi eğer takip edebilirsek, sistem üzerinde müşteriye de etki eden bir sorun var mı görebilme şansını da yakalamış oluyoruz. Bunun için sorun tespitlerinin ilk ana maddesi olarak mantıklı Alarmlar üretebilmeyi koyuyorum.
Şimdi gelin bu konuda neler yapıyoruz inceleyelim..
a. Metric ve Alarm
Öncelikle alarm üretebilmeniz için elinizde bir veri olmalı, bunu da metricler ya da loglarınız üzerinden yapabilirsiniz. Bazı alarmlar loglar üzerinden mantıklı olabileceği gibi, bazıları için ise sadece metric loglamanız gerekebilir. Payment ekibi olarak güvenlik zaafiyetlerinden arındırılmış logları tutma zorunluluklarımız var. Bu zorunluluk bize bir açıdan metric de sağlamış oluyor. Loglarımızı Elasticsearch üzerinde tutuyoruz. Bunun için ise en iyi yöntem olarak front-controller diye tabir ettiğim bölümde çalışan pipeline’lar ile ve CQRS kullandığımız için Command/Query resolver’larımıza inject ettiğimiz logging, exception handling gibi konuları yöneten decorator’larımız ile çözüyoruz. Bu noktalarda Nlog ile dosyaya logladığımız bilgileri filebeat ile elastic’e gönderiyoruz. Artık elimizde log olduğuna göre bu verilerden Kibana üzerinde Xpack kullanarak alarmlar üretiyoruz. Log kaybı yaşar mısınız diye sorabilirsiniz. Bunun önüne geçebilmek için Elasticsearch api için Zabbix üzerinde health check tanımlarımız ile alert üretiyoruz ve uygulamanın cevap verip vermediği ile ilgili de Netscaler üzerinde health check tanımlarımız bulunmakta. Loglarımız içerisinde hangi sunucudan log’un atıldığı bilgisi de bulunduğu için yine kibana üzerinden de hangi sunucuya log gelmediği gibi verilere de ulaşabiliyoruz. Yoğun log akma ve bir search esnasında yaşanabilecek heap sorunlarına karşı da belirli aralıklar ile elastic üzerindeki geçmiş index’lerin kapatılması hatta bazılarının arşivlenmesini de yönetiyoruz.
Eğer çok fazla log atacak bir yerde iseniz burada metricler logmalısınız. Biz Metrics.Net i kullanıyoruz. Metrics.Net ile Prometheus a attığımız logları, Prometheus UI ya da Grafana üzerinden alarmlar üreterek takip edebiliyoruz. Ayrıca loglarınızı incelerken sorunu daha iyi tespit edebilmek için, log yapınızda mutlaka Correlation Id kullanın..
Burada dikkat edilmesi gereken bir husus var. Olur olmaz her şeye alarm oluşturmayın. Aksi halde false positive alarmlar oluşacaktır ve takibi zor, önemli alarmların gözden kaçırıldığı bir alarm yapınız olur.
b. Dashboards
Elinizde sadece metric ve alarmların olması yeterli olmayacaktır. Eğer bu alarmlar sonucunda sistemlerinizi gözleyebileceğiniz dashboard/graph larınız olmazsa adeta kör olursunuz. Önünüzü görmeden ilerliyorsunuz demektir. Bunun için daha önce bahsettiğim metric ve loglardan oluşturduğumuz Kibana, Grafana ya da custom hazırlayabileceğiniz dashboardlar ile takip edebiliyoruz. Özellikle Grafana ile Prometheus’a attığınız metriclerden çok güzel grafikler oluşturabiliyor ve alarmlar üretebiliyoruz. Örneğin Grafana’da bir RabbitMq Exporter ile RabbitMq dashboard oluşturabilirsiniz. Grafana ya ait bir çok dashboard ve plugini incelemenizi tavsiye ederim.
Kibana’da ise aşağıdaki gibi visualize’lar ile bir dashboard oluşturabilir hatta belirli aralıklar ile buradan rapor bile üretebilirsiniz. Örneğin;
. En uzun süren process’leriniz
. En çok aldığınız hatalar ve açıklamaları
. Unhandled exceptions
. Timeouts
c. APM Tools ve Network Monitoring
APM toolları size bir çok metric verebilir ve transactionlarınızı, sunucularınızı ya da isteklerinizin detaylarına kadar görüntüleyebilmenize olanak sağlar. Bir sorun anında sorun sunucularınızdan kaynaklı mı ya da servisinizden mi anlayabilirsiniz. Gelen requestleri inceleyerek bir bottleneck varsa görebilir, hatta database transactionlarınıza kadar inceleme şansınız olur. Ekip olarak iki farklı tool kullandık şu ana kadar. New Relic ve Riverbed. İkisinin de üstünlükleri, sağladığı hoş özellikler mevcut. İnceleyip size en uygun olanı seçebilirsiniz.
d. Network Monitoring ve Healt Check
Network monitoring için Nagios kullanabilirsiniz. Böylece makinelerin kaynak durumları, disk, işlemci kullanımları, Http/s servisleri inceleyebilir, hatta buralarda da alarmlar tanımlayabilirsiniz. Sunucularınızın cpu,ram ve disk durumlarını takip etmek için de yukarıda bahsettiğim gibi Grafana dashboard’ları kullanabilirsiniz.
Load balancer olarak kullandığımız NetScaler dashboard’unu da takip etmemiz işimize yarıyor. Tabi bu konuları daha çok Sistem/Network ekipleri detaylı olarak takip etse de yazılım ekiplerinin dashboardları yorumlayabilmesi ve sorunu tespit edebilmesi çok önemli. NetScaler ya da Zabbix üzerinde tanımlı healt check’leri kontrol edebilirsiniz, böylece herhangi bir sunucuda bulunan servisinizin cevap verip vermediğini takip edebilirsiniz. Hatta bir servis yazarak, sadece iç network’den healt check yapmak değil de dış network üzerinden de servislerinizi çağıran ve sizi uyaran bir yapı kullanabilirsiniz. Dış servisleriniz için alerta kullanabilirsiniz..
2. Sorunu tespit ettikten sonra hızlı çözüm üretilebilmesi
Sorunu tespit etmek ve sorunun daha kötüye gitmesini engellemek için yukarıda bahsettiğim adımlara uydunuz, ama çözümü nasıl üreteceksiniz? Burada ilk madde olarak çözümün en hızlı nasıl üretilebileceğini ve müşteri/şirket açısından en az etki ile nasıl giderilebileceğine değinmek istiyorum.
a. En hızlı çözüm, en düşük etki
Bu konuya şöyle yaklaşabiliriz. Bug var, buldunuz, nasıl çözmelisiniz? Şu an birileri bu Bug ile karşılaşıyor ve düzeltilmesi gerek. Buradaki yaklaşımınız Bug fix’i en hızlı şekilde çıkmanız olmalıdır. Bug fix yaparken başka bir bug’a yol açmadığınıza emin olun. Deployment öncesi çalışan Unit test, Integration test ve Automation testleriniz olduğunu varsayıyorum, buranın konusu değil..
Genelde hata tespit edildikten sonra yapılan yanlış bir yaklaşımdan bahsetmek istiyorum. Yazılımcı şöyle düşünmeye başlıyor;
“Hatayı en iyi yazılım teknikleri ile nasıl çözeriz acaba?”
“Offf ya şimdi burada şu pattern a uymayacak yazdığım..”
“Ya ama ben Anti-If campaign üyesiydim buraya “if” koymak istemiyorum..”
bıdı bıdı bıdı.. Evet bıdı bıdı! Hatayı tespit ettiğinizde önemli olan hatayı çözmektir en iyi çözümü üretmek değil. Olası bir çok etkiyi minimum düzeyde tutabilmenin yolunu aramanız gerekir. ToDo olarak not alın ve Bug fix çıkıp sorunu düzelttikten sonra istediğinize uygun olacak şekilde değişikliğinizi yapın..
b. Alarm sonrasında alınacak aksiyonlar
Alarmlarınızı oluşturdunuz, her şey sorunsuz ve alarm geldi, ee şimdi? Alarmlarınız esnasında nasıl hareket etmeniz gerektiği ile ilgili bir aksiyon planı oluşturmalısınız. Aşağıdaki gibi bir plan mantıklı olabilir;
- Alarm Başlığı (Id)
- Alarm Açıklaması
- Etkilediği ekipler ve sistemler
- Aksiyon için gerekli koşul (x dakika/saniye içinde y kadar Alarm 1 den oluştu ise gibi..)
- Aksiyon (Aranacak kişiler, haber verilecek ekipler, izlenecek monitor’ler gibi..)
c. Durumu daha kötü yapmayın
Aaaa şu servis cevap vermiyor, Allah Allah, dur 100 kere daha çağırayım belki düzelir, biraz daha tokat atayım 😁
Bu davranıştan kaçınmanız gerekiyor. Nedense işin içinde olmamıza rağmen durumun daha kötü olmasına hatta sürekli dile getirerek sorunu çözmeye çalışanların daha fazla stres altında olmasına sebep olma eğiliminde insanlar görüyorum. Geri çekilin ve soruna farklı açılardan bakmaya çalıştığınızı düşünün. Gerekirse sorunu daha kötü yapacak servisleri stop edin. Bunlar elbette bir bottleneck, yük, saldırı ya da response-time’ınızı etkileyebilecek farklı bir konudan kaynaklı ise olabilir fakat alacağınız aksiyonlar arasında olduğuna emin olun.
Son olarak şunları belirtmeliyim. Sorumluluğunuz büyük olabilir, karşılaştığınız hata büyük kayıplara da yol açıyor/açacak olabilir. Eğer ekip olarak soruna odaklanıp sakin kalmayı ve hatayı doğru yöntemler ile aramayı denerseniz çok kısa süre içinde tespit edebilirsiniz. Eğer ekip olarak bulunduğunuz domain’e hakimseniz hatayı hızlı tespit edebilirsiniz. Ve eğer ekibiniz biz de olduğu gibi sorumluluk alan ve işini bilen insanlardan oluşuyor ise ne yapacağınızı bilirsiniz. Burada bana düşen sadece yönlendirmek, çözüm üretilmesini sağlamak, çözüm üretmek, sakin ve soğuk kanlı yorum yapabilmek, hatanın kısa süre içinde giderilmesinin sorumluluğunu almak kalıyor.
Unutmayalım, yazılımın temelinde insan vardır ve insan hata yapar. Hata sadece sizden kaynaklı da olmayabilir, sistemleriniz saldırı altında olabilir ya da belki de bağımlı olduğunuz dış kaynaklı servislerden kaynaklıdır. Hatta hatayı tespit etmek için kullandığınız anlattığım tool’larda da hata olabilir. Bu sebeple sorun her yerde, her an olabilir.
