S.A. Arkadaşlar,
Bugün biraz dertli olarak bir konuyu ele alacağım. Olan problemi hala çözmüş değiliz, ancak sıcağı sıcağına bazı notlar paylaşmak istiyorum. Bazen olay bu kadar sıcak iken doğru sonuçlar çıkmayabilir, ama o andaki düşünce ve psikolojik durumu anlamak ve bunu daha iyi yönetebilmek adına belki güzel ipuçları içerebilir. Hazırsak başlayalım.
Bir önceki gün, uzun süredir üzerinde çalıştığımız platform değişikliği (AWS -> GCP) ile ilgili son testleri tamamlamış ve hataları çözmüştük. Kanallardan gerekli bilgilendirmeler yapmış, gelen tebrikleri kabul ediyorduk. Her şey çok güzeldi. Canlı geçişleri için planlamalar konuşmalar da bir yandan devam ediyordu, fakat bu farklı bir problem yüzünden çok da uzun sürmedi... Sabah üzerinde çalıştığımız IoT projesindeki servislerle ilgili saptamaya çalıştığımız birkaç nokta vardı, bizler de belirli yerlere log kayıtları ekleyerek durumu tespit etmeye çalışacaktık. Ne olacak ki 2-3 tane log attık sadece deyip gün içinde çoğu zaman yaptığımız gibi canlıya çıktık (CI/CD işlemleri ile mikroservisleri koşturduğumuz için bu bizim çok büyütülecek bir şey değil açıkçası). Bir anda sentry'den mesaj gelmeye başladı, ne oluyor deyip log kayıtlarını inceleyince önceki gün test için denediğimiz GCP url'lerine istek attığımızı fark ettik (buraya geliştirmeyi direkt test branch'inde yaptığımız için de, dev'den gelen değişiklik bunu ezmedi ve bizler de maalesef bunu fark edememiştik). Hızlı bir şekilde geliştirmeyi tamamladık (en fazla 10dk, fark edip çözüp canlıya alma süresi) ve yeni halini canlıya aldık. Ohh derin bir nefes aldık derken o kadar da derin bir nefes almadığımızı fark ettik. Sahadaki cihazların %80'lik bir kısmının servis dışı olduğunu fark ettik...
Bunun sebebini incelediğimizde herkesin teorik olarak çok iyi bildiği bir servis çökerse diğer servisler ayakta kalmaya devam etmeli prensibi aslında. Nasıl mı? Şöyle ki IoT olan servisimiz başka bir servise istek atıyor, o servisten timeout hatası alıyoruz (çünkü yanlış yere istek (GCP) atıyorduk). Birkaç defa cihazlar bu isteği tamamlayıp istedikleri cevapları da almayınca kendilerini kapatıyorlar. Bu bizim için hayra alamet bir durum değildi maalesef. Çünkü cihazlar kendilerini kapatıp bize komut göndermiyorsa bu onlara uzaktan erişemiyoruz anlamına geliyordu ve galiba cihazlar fiziksel reset istiyordu, bu da Türkiye'nin dört bir yanına dağılmış cihazlar için hiç de kolay bir şey değil...
Tüm bu olumsuzluklardan sonra bir başarı hikayesi arıyorsanız maalesef böyle bir durum yok :( Çok fazla şey denedik ama üstesinden gelemedik, en sonunda bayrağı kaldırıp cihazlara fiziksel erişim için operasyon ekibiyle iletişime geçtik ve onlar da farklı şekillerde bunu hala çözmeye çalışıyor. Şu an cihazların yarısı aktif durumda ve biz hala uğraşıyoruz.
Peki ben bunca şeyi niye mi yazdım, yaşadığımız bu stresli süreci biraz da olsa anlatmak ve rahatlamak. Ayrıca çok küçük gördüğümüz 2-3 satır log'un bazen de nelere sebep olabileceğini hatırlatmak...
Kuzenimin bana anlattığı ufak bir olayı anlatayım. Kendisi diş hekimi ve bir hastanın dişini çekerken çok fazla parametreye baktığını o yüzden bazen bir dişi çekmek için oldukça vakit harcadığını söyledi, sonra da yeni hekimler görüyorum, hemen çat diye dişi çekiyorlar ve hayatlarına devam ediyorlar. Aslında o an çekilen dişin nelere sebep olacaklarını bilseler bu işi bu kadar da hızlı yapamazlardı demişti. O an güzel bir tecrübeyi dinlemiştim ama bunu şimdi daha acı bir şekilde anlıyorum.
İşlerin yan etkilerini çok düşün(e)meden farklı sebeplerden dolayı hızlar işler yapmak durumunda kalıyoruz. Daha sonra da dilimiz yandıkça (tecürbe kazandıkça) o hız yerini olgunluğa bırakıyor. Bu tecrübe bizi her ne kadar frene basmamıza vesile olsa da güvenli şekilde sistemi ilerletmek çoğu zaman çok daha önemli oluyor. Ayrılıklar nasıl sevdaya dahil ise başarısızlıklar da başarıya dahildir diyerekten müsadenizi istiyorum.
(Akıllı ve olgun) Mü'min aynı delikten iki defa sokulmaz, ısırılmaz." [Detayı]
(Buhârî, Edeb, 83; Müslim, Zühd, 63)
Hiç yorum yok:
Yorum Gönder