Player Unknown’s Bug: Nedeni bilinmeyen sorunları kaydetmek gelişmemizi sağlar mı?
(engineering.ab180.co)Tesadüfen oluşturulan bir issue sayfası aracılığıyla, ekibin psikolojik güvenliğini artırıp bilgi paylaşımını çoğaltarak daha sağlam bir organizasyon ve hizmet inşa etme hikâyesini paylaşıyoruz.
Geliştirme yaparken bazen nedeni bilinmeyen sorunlarla karşılaşılır.
Özellikle web frontend, sunucu gibi bileşenlerin durumunun yanı sıra tarayıcı türü veya sürümü, Chrome eklentileri gibi sayısız dış etkenden de etkilenir.
Sorunun nedenini bilmiyorsak ya da sorunun nedeni bizde değilse, yalnızca postmortem ile sağlam bir yapı kurmanın yeterli olup olmayacağı bir anda aklıma takıldı (acaba eksik mi kalıyor?).
Çıkış noktası
Nedeni anlaşılamayan bir issue raporunu alıp kapatma sürecinin 9 saat sürdüğü bir olay olmuştu.
Issue’yu debug etmeye 4 saat ayırdıktan sonra, sorunun nedeninin iç kod ya da altyapıda değil, kullanıcının Chrome Extension hatasından kaynaklandığını anlayabildim.
Sorunun nedeninin nerede olduğunu anlamak zaten zordu ama nedenin dışarıda olduğunu fark etmenin bile tam 4-5 saat sürmüş olmasına kendime kızmıştım.
Notion’da Player Unknown’s Bug(PUB) adlı bir sayfa oluşturup, öfkemle birlikte issue’yu ele alırken denediklerimi, eksik kalanları ve iyileştirilebilecek noktaları düzenledim.
Kültüre yerleşmesi ve gelişmesi
Geriye dönüp bakarken, issue’nun nedenini, araştırırken ek olarak öğrendiğim şeyleri ve yanlış değerlendirdiğim noktaları anlattım. Ekip arkadaşlarım merak ettikleri konuları ve iyileştirilebilecek noktaları işaret etti; bu başlıkları toplayıp bir incident response süreci oluşturduk.
Bu sürecin güzel yanı şuydu: issue’ya müdahale ederken yaşadığım zorluklara ekip arkadaşlarım empati gösterdi ve yeni öğrendiklerimi paylaşmak keyifliydi. Ayrıca bir checklist hazırlayarak benzer bir durum olduğunda sorunu daha hızlı tespit edebilir hale geldik. Bunu ekiple paylaşıp resmî bir kültür olarak benimsedik.
AB180 mühendislik organizasyonu temelde postmortem yürütüyor. Şirket içindeki postmortem daha çok Resolution ve Action Items odaklıyken, PUB’nin amacı Lesson Learn, issue müdahalesine dair psikolojik güvenlik oluşturmak ve bilinmeyen sorunlarda önce kontrol edilmesi gereken etkenleri düzenlemek.
Bilginin gönüllü olarak paylaşıldığı bir kültür
Bu yaklaşım ekipte yerleştikçe, diğer ekip arkadaşlarının müdahale ettiği issue’lar da yavaş yavaş birikmeye başladı.
Geriye dönük değerlendirmelerde daha önce bilmediğimiz noktaları konuşmak ve daha derine inmek için ayrılan zaman, küçük ama gönüllü birer “bilgi paylaşım oturumu” gibi işlemeye başladı.
Bu kültürü biraz daha büyütmek için, öğrendiğimiz ve fark ettiğimiz şeyleri düzenli olarak paylaştığımız bir Slack kanalı işletiyoruz. Şimdilik iyi gidiyor.
Lesson Learn
- Incident’a müdahale eden tüm ekibin psikolojik güvenliğini artırmak gerekiyor; bunun için de daha fazla konuşmalıyız.
- Bu yapılmadığında sorunlar tekrar eder ve organizasyon içinde “sorun = konuşulmaması gereken şey” düşüncesi yerleşir.
- Bilgi paylaşımı yoluyla organizasyonun psikolojik güvenliğini oluşturmak, hatta artırmak mümkündür.
- Ve böyle bir bilgi paylaşımı kültürü, sanıldığından daha küçük bir şeyle başlayabilir.
5 yorum
Ben ise tam tersine bugün, nedeninin belirli bir dış etken olduğu çok açık olmasına rağmen iç koşullar yüzünden kolayca müdahale edilemeyeceği sanılıp çaresizce beklenen bir arızanın, aslında yapılandırma dosyasındaki tek bir satırı değiştirmekle çözülebildiği bir vakayla bütün gün uğraşıp işten çıktım. Bu yazıyı görünce gerçekten çok yardımcı oluyor.
Bugün de gerçekten çok emek verdiniz. Yine de sorunu çözmüş olmanız sevindirici. Yukarıdaki yazıda bahsettiğim sorunlar da bazen aklıma geliyor. O zamanlar zordu ama şimdi onları keyifle karşılayabildiğimi düşünüyorum.
kunggom'un bugün yaşadığı zor şeyi de zaman geçince keyifle hatırlayabiliriz, değil mi? haha
Yetersiz yazımı okuduğunuz için teşekkür ederim.
Açıkçası ne eskiden ne de şimdi, arıza müdahalesi yüzünden zorlanmayı keyifli bulduğumu hiç sanmıyorum.
Örneğin bugün çözdüğüm arıza da tam bizim ekibin üretim sunucusuna doğrudan erişiminin engelli olduğu bir üründe meydana geldiği için, arızayı fark edip durum tespitine başladığımız ilk bölüm ile sunucu erişim yetkisini zar zor alabildiğimiz son bölüm dışında, görece çaresiz kalmaktan başka çaremiz yoktu. Bizim ekip şu ve şu önlemlerin alınmasını rica ettiğinde, sunucu operasyon ekibi kendi koşullarını gerekçe göstererek bunu reddetti. Böyle bir çaresizliği keyifle karşılamak mümkün değil.
Bu yüzden mesai bitimine kadar postmortem belgesini yazarken hissettiğim şey, galiba daha çok şuna yakındı: “Bıktırdı artık; bari bir dahaki sefere böyle bir hata yapmayayım!”
Anlattıklarınızı duyunca bunun sizi epey yıpratmış olabileceğini düşünüyorum. Dediğiniz gibi, aynı hataları bir daha yapmamayı öğrenerek insan ancak yavaş yavaş ilerleyebiliyor... hıçkırık
Aslında söz konusu ürün oldukça eski bir legacy ürünü ve devralalı çok olmadı; devralır almaz da işlev değişikliği talebi geldiği için yakın zamanda kodu düzenlemiş olsam da bu, bugün yaşanan arızayla hiçbir ilgisi olmayan bir bölümdü. Bu yüzden gerçekten sorun olan kısım benim doğrudan yazdığım bir içerik değildi ama yine de bu ürünü daha en ince ayrıntısına kadar biliyor olsaydım sorunu daha hızlı çözebilirdim. Buna gerçekten üzülüyorum.
Ayrıca en başta, tam kapsamlı kesinti durumunu gördükten sonra ilk anda emin olduğum neden tahmini de aslında sadece yarı yarıya doğruydu. Sanırım o tahmine duyduğum kesin güven, bugünün asıl hatasıydı.