Problemi tanımlamaya başladığımızda kendimize sormamız gereken ilk soru budur. Bu sorunun yanıtlarını technical ve/veya non technical paydaşlar ile verebilmek ve hizalanabilmek oldukça önemlidir. Kriz masaları içerisinde technical paydaşların bu soruya varsayımdan uzak ortak bir yanıt verebiliyor olması önemidir.

• Sanırım db de sorun var..
• Benzer bir durum geçen hafta oluşmuştu, sorun aynıdır..
• X Api’ye erişilemiyor olabilir..

Gibi varsayıma dayanan ve netlik içermeyen cümleler kriz masalarında vakit kaybedilmesine ve diğer paydaşlar nezdinde bilgi zehirlenmesine sebebiyet verecektir. Bu tutumdan olabildiğince uzak durmak gerekiyor.

Probleme dair gelen sorulara hızlı bir yanıt verebilmenin elzem olduğu anlarda incelemenin devam ettiğine dair bir ifade tercih edilmesi yeterlidir.

İlk soruya verdiğimiz yanıt akabinde pek çok sistem bileşeni arasında (software component, database, network, devops process etc. ) en doğru bileşeni kritik ilan edebilmek adına tespitte bulunmamız gerekiyor.

Bu noktada nedenler ile sonuçların karıştırıldığına ve hatanın uzun süre yanlış yerde incelendiğine çok kez tanık olmaktayız.

Örneğin /  X sistemi Y sistemine bağımlı olarak çalışmaktadır. Aralarında olan bu bağımlılık bağımsız çalışma rutinlerine imkan veremiyor olsun, günün birinde X sistemi Y sisteminden aldığı token’lar ile iş süreçlerini ilerletemediğinde;

• Sorun tespiti için hatalı bir tespit örneği : X sistemimiz yanıt veremedi çünkü Y sistemine erişemiyoruz. Bu cümle bir sebep değil non technical bir sonuç cümlesi gibi görünmektedir.
• Sorun tespiti için doğru bir tespit örneği : Y sisteminden aldığımız token’lar geçerli değil. Aslında sisteme erişebiliyoruz ancak 401 response code alıyoruz.

1st Conflict:

Hatalı olan tespit için konu erişimsel gibi görünürken doğru tespit için 401 teknik olarak erişim problemini anlatmamaktır.

Evet iş süreçleri açısından konu bir erişim problemi gibi görünebilir fakat teknik süreçler açısından bir erişim sorunu yoktur. Erişim sorunu olsa 401 yanıtını alamazdık.

2nd Conflict:

Hatalı tespit için konu network ekipleri ile birlikte değerlendirilmesi gerekirken doğru tespit için Y sisteminin paydaşları ile görüşmek yeterli olacaktır.

Not: Bu noktada iki sistem arasında entegrasyon süreçlerini best practise’lere uygun olarak geliştirmek, hateoas spesifikasyonlarını netleştirmek ve hata code’larını iyi yorumlamak olası bir sorun anında hız kazanabilmek için önemlidir.

• Sorun sadece günün belirli saatlerinde mi oluyor?
• Sorun sistemsel yoğunlukla ilişki kuruyor mu?
• Sorunun bizlere bildirildiği zamana kadar geçen süre nedir?
• Bir deployment, sistemsel bir geçiş vs. gibi konular mı bu duruma sebep oldu?
• Hatalar transient mi yoksa non transient mi?

Ekibin bu soruları teknik süreçleri göz önünde bulundurarak artırması ve tecrübe kazandıkça sorulara verilen her bir cevap ile bir flow takip edebilmesi önemlidir.

Bu çalışmaları iş süreçleri nezdinde olan support süreçleri ile karıştırmak sık yapılan hatalar arasında yer almaktadır. Troubleshooting ile işlediğimiz süreç ürünün non technical süreçlerine anlam yüklemek degil yazılımın yaşam döngüsü üzerinde bir problemi adreslemektir.

Not: Uygulama mimarisinde transient ve non transient durumların net bir şekilde ortaya konulması ve reactive sistemler geliştirilmesi troubleshooting süreçlerinin hızı ve verimliliği açısından önemlidir.

(Bkz: https://www.reactivemanifesto.org/)

(Bkz: https://agile-academy.com/en/agile-dictionary/fail-fast/)

Bu sorunun yanıtını verebilmek için sistemde yer alan as is bağımlılıkları ilişkilendirebilmek oldukça önemlidir.

• İlgili süreç her çalıştığında bu sorun gerçekleşiyor mu?
• Sorunun ortaya çıkabilmesi için x bir durumun gerçekleşmesi gibi bir zorunluluk var mı?
• Mevcut diğer sistemler aynı anda başarısız oluyor mu?

Tam olarak bundan sebep kriz masalarının ilgili teknik paydaşlarla, yetkin kişilerle kurulabilmesi önemlidir.

Geleneksel hata ayıklama yöntemleri için bu durum oldukça önemlidir. Local ortamlarda debug yapabilmek, pre prod ortamlarında hatayı simule edebilmek hataya dair daha detaylı inceleme imkanını bizlere sunmaktadır.

Fakat bu durum oldukça fazla vakit alırken ilgiliyi hatayı anlatan datalar ile çalışsak bile state’ler kaybolmuş olabilir. Bu yöntemin bizi yanlış yönlendirme ihtimali her zaman için değerlendirilmelidir.

Örneğin/ Support konularının konuşulduğu bir kanalda iş birimlerinden bir arkadaş BO ekranlarında hata aldığını iletmektedir. Bu durumda BO ekranlarını kontrol etmek ve ekranların çalıştığını görmek problemin olmadığı anlamına gelmez. Çünkü hatalar state’leri ile yaşarlar ve süreçler bizi ilgili state’e tekrar götürürse hata alma ihtimalimiz kaçınılmazdır.

Lakin modern sistemler için ilgili hatayı reproduce etmek gibi bir zorunluluk olmamalıdır. Hataları kendi state’leri ile yaşayan varlıklar olarak anlamlandırabilir hale geliriz.

Birbiriyle sıklıkla karıştırılan ve birbiri yerine kullanılan kavramlar: Data, State, Status, Time Audit

Hatayı reproduce ederek debug almak problem çözme süreçleri bir kenara dursun development süreçleri için dahi günümüzde bir anti-pattern olarak görünmektedir.