Bu hem bir “referans numarası” hem bir observability hikâyesi olacak. İkisi birbirine bağlı çünkü.
Bir mobil uygulamaya giriş yapmaya çalışıyorum. SMS geliyor, içinde bir referans numarası var. Ama ne yaparsam yapayım giriş tamamlanmıyor. İlginç olan şu: o numara uygulamanın hiçbir ekranında yazmıyor, sadece SMS’te görünüyor.
UX tarafından bakınca bu bir eksik; kullanıcı hangi işlemde olduğunu doğrulayamıyor.
Referans numarası neden bir observability meselesidir
Mühendislik tarafından bakınca daha önemlisi var. O referans numarası, arka tarafta correlationId ile eşleştirilmişse bir korelasyon anahtarına dönüşür. Hangi kullanıcı, hangi akışta, hangi adımda takıldı sorusunun cevabı orada. Loglar ve trace’lerle bağlıysa on-call’daki kişi problemi tek sorguda bulur, hotfix ya da öncelikli bir operasyonel task devreye girer. Bağlı değilse o numara kullanıcının cebinde duran işe yaramaz bir metin olarak kalır.
Bir de şu var: bu arızayı fark eden kişi bir kullanıcı. Yani ben. Giriş gibi kritik bir akışta synthetic monitoring yoksa böyle oluyor. Kullanıcının size haber vermesi bir geri bildirim değil, ölçüm eksikliğinin faturasıdır.
Ortak infra olmadan observability kurulmuyor
Bu konudaki fikrim yeni değil. Pazaryeri tarafında Pazarama ve Beymen Merchant’ta, kredi tarafında Bondora ve Riverty’de (eski adıyla Arvato Financial Solutions) çalıştım. Bir dönem de bu işin hiç kurulmadığı bir yerde mimar oldum: iki ekip, iki ayrı monitoring aracı, ortak infra yok, merkezi log yok. Logları sunucu sunucu aramak gerekiyordu, çoğu zaman da elde bir şey kalmıyordu. Çözüm olarak yeni bir ürün alınması gündeme geldi, karşı çıktım; problem lisans değildi. Bunu defalarca kanıtladım ama kimin umurundaydı? O da ayrı bir hikâye; adı da “CTO Paradoksu” olsun.
Aynı konuyu daha önce teknik vizyon ve geliştirici araçları ve test ortamlarının prod kadar sağlıklı olması üzerinden de yazmıştım. Üçünün ortak noktası aynı: görünmeyen temeller.
Araç konuşmadan önce sorulacak yedi soru
Ben araç konuşmadan önce biraz aykırı sorular sormayı seviyorum:
- Bir akış kırıldığında ilk kim öğreniyor, ekip mi kullanıcı mı?
- Loglar tek yerde mi toplanıyor, sunucularda mı duruyor?
- Tanımlı SLI ve SLO’nuz var mı? Dashboard’daki verinin doğruluğunu nasıl teyit ettiniz?
- correlationId, traceId ya da sessionId ile kullanıcının akışını uçtan uca görebiliyor musunuz?
- Alarm bir kişiye mi gidiyor, kimsenin okumadığı bir kanala mı?
- On-call yürüten biri var mı? Incident management ve post-mortem var mı?
- Aynı arıza ikinci kez olduğunda çözüm süresi kısalıyor mu?
Bu yedi sorunun cevabı, hangi observability aracını kullandığınızdan çok daha fazla şey anlatır. Araç, cevapları olan bir ekibin işini hızlandırır; cevapları olmayan bir ekibin eksiğini kapatmaz.
Sıfırdan observability kurmak için ilk üç adım
Büyük bir bütçe olmadan da yol alınır. Sırası şöyle:
- Merkezi log. Tüm servislerin logu tek yerde toplanmadan hiçbir soruşturma dakikalar içinde bitmez. İlk yatırım burada.
- Korelasyon anahtarı. Kullanıcıya gösterdiğiniz her referans numarası, arka tarafta bir correlationId ile eşleşsin ve loga o anahtarla yazılsın.
- Tek kişiye giden alarm. Kritik akışlar için synthetic kontrol koyun ve alarmı bir kanala değil, o an on-call olan kişiye yönlendirin.
Bu üçü kurulduğunda geri kalanı (SLO’lar, dashboard doğrulaması, post-mortem disiplini) doğal olarak üzerine biniyor.
Açık mikrofon kültürü olmadan çalışmıyor
Şu an çalıştığım yerden bu sorulara cevap verebiliyorum, çünkü ekibime güveniyorum; doğru soruları soruyor, doğru cevapları arıyorlar. Geçtiğimiz günlerde Hepsiburada tarafında çıkan ciddi bir sorunu müşterilerimizden önce biz gördük. Sebebi olağanüstü bir araç değil; observability, on-call ve incident management kaslarının çalışıyor olması.
Ama bunların hiçbiri açık mikrofon kültürü olmadan mümkün değil. Müşteriden ve en önemlisi kendi personelinizden geri bildirim almayı biliyorsanız başaramayacağınız şey yok. Bir arızayı en erken gören kişi genelde en kıdemli kişi olmuyor; sevkiyatta o ürünü toplayan kişi bile olabiliyor. O kişinin söylediğinin bir alarma dönüşebildiği yerde observability zaten yarı yarıya kurulmuş demektir.
Observability bir lisans kalemi değil. Sahiplik, mühendislik disiplini ve konuşabilme meselesi.