Temel neden analizi: Kusurları daha hızlı gidermek için 4 ipucu

Şunu resmedin: Siz ve ekibiniz, yazılım ürününüzün bir sonraki ana sürümünü tamamlamak için gece gündüz çalışıyorsunuz. İyi bir hızla yeni özellikler oluşturuyorsunuz. Ekip, QA bildirir bildirmez hataları gideriyor. Birim testlerinin hiçbirinde sorun yok. Uygulama, daha kapsamlı bir dizi testi geçtikten sonra kullanıma sunuluyor. Ve güm! Uygulama, üretim ortamına girer girmez fena bir şekilde çöküyor. Yanlış giden şey ne?

Görünüşe göre, test ortamları üretime düşündüğünüz kadar yakın değilmiş. Ortamda herhangi bir kayıt olmadan altyapı değişiklikleri yapılmış. Sonuç olarak, ortam yavaşça çökmüş.

Teknoloji sektöründeki uzmanlar olarak, zamanımızın önemli bir kısmı kusurları gidermekle geçiyor. Ve evet, sorunları düzeltmek için de zaman harcıyoruz ancak ne olduğunu bilmediğiniz bir sorunu çözemezsiniz. Bir hata ayıklayıcının önünde saatler geçiren herhangi bir yazılım geliştiricisi size genellikle gerçekten zor olan kısmın hatayı bulmak olduğunu söyler. Sorunun ne olduğunu bulduğunuz anda, sorunu çözmek önemsiz hale bile gelebilir.

Dolayısıyla, bir yazılım geliştiricisi veya genel olarak bir BT çalışanı olarak yapabileceğiniz en iyi yatırımlardan biri daha hızlı sorun gidermeyi öğrenmektir.

Sorunları nasıl hızla bulabileceğimizden ve nasıl daha hızlı şekilde çözebileceğimizden bahsedelim.

Temel neden analizi: Nedir ve neden önemlidir?

Temel neden analizi (RCA), sorunları gidermek için kullanabileceğiniz özel bir tekniktir. Bu teknikle, sorunun ana nedenini tespit etmek için bir dizi adım kullanarak sorunu analiz edersiniz. RCA, bir sorunun temellerini yok sayarak semptomlarına odaklanmanın faydalı olmadığı ilkesine dayanır.

RCA'yı kullanarak ne olduğunu anlayabilirsiniz. Genellikle, sadece semptomları gözlemleyerek eksiksiz bir resim elde edemezsiniz. Ancak ne olduğunu belirlemek yalnızca ilk adımdır. Daha sonra, daha ileri gitmeniz ve sorunun neden yaşandığını ortaya çıkarmanız gerekir. Bu bilgiye sahip olduktan sonra sıra sorunun yeniden yaşanma olasılığını azaltmak için bir plan veya strateji geliştirerek uygulamaya koymaya gelir.

"Ne" ve "neden" sorularını elde aldığımıza göre, daha az sorun yaşamak için RCA'yı kullanmanıza yardımcı olacak dört ipucunu burada bulabilirsiniz.

Lastik ördek yaklaşımını kullanın
Evet, ciddiyim: lastik ördek yaklaşımı. Uydurmuyorum. Bu yaklaşım, lastik ördek hata ayıklama olarak da bilinir ve muhtemelen daha pek çok adı vardır. Bu yaklaşım, sorununuzu bir lastik ördeğe açıklamaktan oluşur. Lastik ördeğiniz yok mu? Endişelenmeyin! Elinizdeki herhangi bir cansız objeyi de kullanabilirsiniz. Hatta bir kişiyle de konuşabilirsiniz!

Peki bu lastik ördek yaklaşımı tam olarak nedir? Bu yaklaşım, bir şeyi birisine açıklayarak düşüncelerinizi düzenlemeye çalıştığınız gözlemlenen etkiye dayalıdır. Düşünce süreçlerimiz genellikle kaotik veya dağınıktır. Bir şeyi birisine gerçekten açıklamak zorunda kalma ihtimaliyle karşılaştığımızda, düşüncelerimizi düzene koymaktan başka seçeneğimiz kalmaz. Popüler Soru-Cevap sitesi Stack Overflow'un kurucusu Jeff Atwood, yazılım geliştiricilerin kendisine kaç kez siteye yeni bir soru yazmaktan bahsettiğini, bu süreçte cevabı kendilerinin bulunduğunu ve soruyu hiç göndermediklerini anlatıyor!

Lastik ördek yaklaşımı tüm sorunları çözmek için yeterli mi? Tabii ki hayır. Yeterli de olabilir ancak genellikle daha geniş bir stratejinin ilk adımıdır.

Cansız objelerle konuştuğunuz için insanların garip olduğunuzu düşüneceğinden mi korkuyorsunuz? Aslına bakarsak lastik ördek fikri kısmen şaka. Saçma ama akılda kalıcı bir figürdür. Çok ciddiye almanıza gerek yok. Önemli olan, kendinizi kafanızdaki düşünceleri düzenli bir şekilde ifade etmeye, elinizdeki sorunu olabildiğince açık bir şekilde açıklamaya zorlamanızdır.

Aşağıdaki yaklaşımları kullanabilirsiniz:
1. Bir Stack Overflow sorusu yazın. Bir Stack Overflow sorusu yazıyor gibi de davranabilirsiniz ancak bunun yerine soruyu bir not defterine yazın.
2. Ayrıntılı bir hata raporu oluşturun. Muhtemelen birinin yapması gerekecek. Neden bir taşla iki kuş vurmayasınız?
3. İş arkadaşınızın odasına/ofisine gidin ve birkaç dakika konuşun. Tabii ki arkadaşınız da konuşmak isterse. İş arkadaşlarınızı gereksiz yere rahatsız etmeyin.


Çok sayıda günlük verisi toplayın (ve verimli şekilde arama yapın)

Sorunu bariz şekilde başarıyla açıklayabildiyseniz ancak hâlâ temel nedene ulaşamıyorsanız daha ileri gitmeniz gerekir. Şimdi yapmanız gereken, sorunla ilgili veri toplamak ve bu verilerden öngörüler çıkarmaktır.

Çökme günlükleri, uygulama ve sunucu günlükleri ve diğer günlükleri kaydetmek ve izlemek burada faydalı olabilir. Sorunun gerçekleştiğine dair kanıt toplamalısınız ancak mümkünse sorunun ne kadar süredir ve ne sıklıkla gerçekleştiğini de öğrenmelisiniz.

Yine de burada duramazsınız. Çok sayıda veri toplamak önemlidir ancak ihtiyacınız olan parçaları hızlı bir şekilde bulamazsanız tüm bu veriler pek de faydalı olmaz. "Samanlıkta iğne" aramak zorunda kalmak, ne eğlenceli ne de verimli bir durumdur.

Bu nedenle, topladığınız tüm günlük verilerini gerçek zamanlı olarak aramanıza ve analiz etmenize ve bunları sorunları daha hızlı tespit edip çözmek için kullanabileceğiniz değerli öngörülere dönüştürmenize olanak tanıyan araçlar kullanmalısınız.


Beş neden tekniğinden yararlanın
Bilgileri topladıktan sonra nedensel faktörleri belirleyerek devreye alma zamanı. "Nedensel faktör" burada, elinizdeki sorunun doğrudan nedeni anlamına gelir. Ancak tek bir nedensel faktör belirleyip durmamalısınız. Daha ileri gitmeniz gerekir. Bu konuda en iyi bilinen tekniklerden biri de beş neden tekniğidir.

Bu teknik, sorunun temeline inene kadar sürekli olarak "Neden?" sorusunu sormaktan oluşur. Hızlı bir örneği inceleyelim:

Sorun: Web sitesi 500 hatasını veriyor.
1. Neden? Web çerçevesinin yönlendirme bileşeni arızalandığı için.
2. Neden? Başka bir bileşen gerektirdiği ve bu bileşen arızalı olduğu için.
3. Neden? Web çerçevesinin bu bileşeni, intl uzantısını gerektirdiği ve bu uzantı çalışmadığı için.
4. Neden? Sunucu yazılımı güncellendikten sonra yanlışlıkla devre dışı bırakıldığı için.

Gördüğünüz gibi, beş numara sadece örnek niteliğindedir. Temel soruna daha az adımda ulaşmak da mümkündür. Ya da daha fazla adıma da ihtiyaç duyabilirsiniz.

Beş neden tekniği mükemmellikten uzaktır. Eleştirilerden payını almıştır ve kesinlikle sınırlamalara sahiptir. Ancak mühendisleri, bir çözüme yaklaşmaya dair ilk işarette durmak yerine, sorunların temel nedenini aramaya devam etmeye teşvik etme konusunda faydalı olabilir.


Başka bir bakış açısından yararlanın
Kod inceleme, yazılım geliştirme kariyerimde takdir ettiğim bir uygulamadır. Tarafsız başka bir kişinin kodunuza bakması gibi basit bir gerçeğin, daha önce fark edemediğiniz pek çok sorunu ortaya çıkarabilmesi şaşırtıcı değil. Başka bir kişinin kodunuza bakacağını bilmek, sizi zamanla kod hakkında daha bilinçli hale getirir. Koda, normalden daha fazla dikkat vermeye başlarsınız.

Peki, bu noktada kod incelemelerini tavsiye ediyor muyum? Evet ancak başka bir bakış açısından yararlanmanın tek yolu bu değil. Bir mühendisin yaptığı neredeyse her işlemde inceleme benzeri süreçler kullanmanızı öneriyorum. Veya daha da iyisi çiftler halinde çalışmak. Programlama, sunucu yapılandırma, hata ayıklama ve müşteri desteğinde çiftler halinde çalışın. Kısacası: Sorunları çiftler halinde giderin.

Bilim mi, sanat mı?

Kusur giderme, bilimden çok sanatla ilgili bir aşamadır. Ancak bu sizi teknikler ve kusur gidermeyi daha etkili hale getirecek araçlar kullanmaktan alıkoymasın.

Dolayısıyla, RCA için şu tekniklerden yararlanın:
1. Lastik ördek yaklaşımını kullanın
2. Çok sayıda günlük verisi toplayıp aramak ve analiz etmek için uygun araçları kullanın
3. Beş neden tekniğinden yararlanın
4. Başka bir bakış açısından yararlanın

Lastik ördeğinizi alıp sorunlarınızın temel nedenini analiz etmeye başlama zamanı geldi.

Amazon OpenSearch Service fiyatlandırması hakkında daha fazla bilgi edinin

Fiyatlandırma sayfasını ziyaret edin
Oluşturmaya hazır mısınız?
Amazon OpenSearch Service'ı kullanmaya başlayın
Başka sorularınız mı var?
Bize ulaşın