Yanlış Soruya Doğru Çözüm

Müşteri yaşlanan sanallaştırma altyapısını yenilemek istediğini söylüyor. İki haftalık çalışmayla güçlü bir yerel altyapı tasarlıyorsun. Sunumda yönetim, asıl hedefin buluta kontrollü geçiş olduğunu açıklıyor.

Talep, ihtiyaç, gereksinim ve çözümü ayırmak müşterinin söylediğini değersizleştirmek değildir. “Yeni storage istiyoruz” cümlesi geçmiş deneyim, üretici tercihi veya gerçek bir kapasite sorunu taşıyabilir. Bu cümleyi çözüm hipotezi olarak kaydet ve arkasındaki iş/operasyon etkisini aç. Kim etkileniyor, hangi süreç aksıyor, ne sıklıkta oluyor ve hiçbir şey yapılmazsa maliyet ne? İhtiyaç bu etkiyi anlatır. Gereksinim ise seçeneğin karşılaması gereken ölçülebilir koşula dönüşür. Gereksinim yazarken çözümü içine gizleme. “All-flash sistem olmalı” teknoloji seçimidir; “tanımlı yoğunlukta sipariş işlemlerinin yüzde 95’i iki saniyenin altında tamamlanmalı” test edilebilir gereksinimdir. Bazı kısıtlar teknoloji içerir: mevcut protokol veya zorunlu entegrasyon korunacak olabilir. Bunları da nedenleriyle yaz. Her gereksinim için ölçüm yöntemi, veri sahibi, kabul eşiği ve öncelik gerekir. Zorunlu, tercih edilen ve keşifte kalan maddeleri ayırmak seçenek karşılaştırmasını dürüst kılar. Yeniden çerçeveleme dilinde müşteriyle yarışma. “Buna ihtiyacınız yok” savunma yaratır. “İstediğiniz yaklaşımı doğru boyutlandırmak ve alternatifleri adil karşılaştırmak için hangi sonucu değiştirmemiz gerektiğini netleştirelim” de. Talebin arkasındaki uzmanlığı kabul et, fakat kararın ölçütlerini birlikte görünür yap. Sonuçta müşterinin ilk talebi doğru çıkabilir. Fark şudur: seçim artık varsayıma değil, problem, kısıt ve kabul kanıtına dayanır; değişirse hangi gerekçeyle değiştiği de açıklanabilir.

‘Sistem yavaş’ semptomdur. İş etkisi sipariş gecikmesi olabilir; neden storage latency, ağ kaybı, bellek baskısı, sorgu kilidi veya yedekleme çakışması olabilir. Semptomdan ürüne atlamak kök neden doğrulanmadan tedavi seçmektir.

Kök neden çalışmasını hipotez yarışması olarak kur. Her olası neden için beklenen belirtiyi, onu destekleyecek ölçümü ve hipotezi çürütecek sonucu yaz. Storage latency hipotezi doğruysa geciken işlemlerle aynı pencerede kuyruk ve yanıt süresi artışı beklenir. Uygulama kilidi hipotezinde altyapı metrikleri normal kalabilirken sorgu beklemeleri yükselir. Yedekleme çakışması yalnız belirli saatlerde tekrar eden desen üretir. Bu öngörüler olmadan toplanan çok miktarda veri karar değil gürültü oluşturabilir. Zaman hizası kritiktir. Günlük ortalama, beş dakikalık yoğunluğu gizleyebilir; farklı saat dilimleri veya örnekleme aralıkları yanlış korelasyon yaratabilir. Olay zamanı, kullanıcı işlemi, uygulama logu, host, ağ ve storage ölçümlerini ortak zaman çizgisinde birleştir. Korelasyon tek başına nedensellik değildir, fakat hipotezleri daraltır. Sorun başlamadan önceki değişiklikleri de kaydet: yazılım sürümü, veri büyümesi, bakım işi, ağ politikası veya kullanıcı hacmi. Değişiklik listesi suçlu seçmek için değil, test sırasını önceliklendirmek için kullanılır. Bir hipoteze erken bağlanmayı önlemek için kanıt karşıtı ara. Storage ekibi storage sorununa, uygulama ekibi sorguya odaklanabilir. Review sırasında her ekip kendi hipotezinin hangi veriyle yanlışlanacağını söylemelidir. Kanıt yetersizse pahalı platform değişimi yerine sınırlı test, geçici ölçüm veya geri döndürülebilir iyileştirme seç. Amaç kusursuz teşhis raporu hazırlamak değil, müşteri etkisini kabul edilebilir riskle azaltacak kararı yeterli kanıtla vermektir.

Doğrulama planı her açık soruyu aynı önemde ele almaz. Önce karar etkisini ve geri dönüş maliyetini değerlendir. Yanlış çıkarsa veri kaybı, uzun kesinti, uyumsuzluk veya büyük bütçe değişikliği yaratacak varsayımlar erken kapanmalıdır. Düşük etkili ayrıntılar zaman kutulu varsayımla ilerleyebilir. Her doğrulama maddesinde iddia, mevcut kanıt, eksik veri, yöntem, sahip, tarih ve sonuçtan sonra verilecek karar bulunur. “Test edilecek” tek başına plan değildir. Kanıtın kabul ölçütünü testten önce yaz. Performans testi hangi iş yükünü, eşzamanlılığı, veri setini ve süreyi temsil edecek? Restore denemesinde sayaç ne zaman başlayıp bitecek? Uyumluluk kontrolü hangi sürüm ve konfigürasyonu kapsayacak? Ölçüt sonuç görüldükten sonra değiştirilirse ekip istenen cevaba göre hedefi oynatabilir. Test ortamının üretimi temsil etmediği noktaları ayrıca kaydet ve sonuç güvenini buna göre sınırla. Kararı kapatırken üç olasılık vardır: kanıt hipotezi destekler ve seçenek ilerler; hipotezi çürütür ve alternatif değerlendirilir; sonuç belirsiz kalır ve ek testin değeri/maliyeti tartılır. Sonsuz analizden kaçınmak için durdurma kuralı belirle. Ek kanıt karar sonucunu değiştirmeyecekse veya test maliyeti riskten yüksekse, varsayım ve artık risk açıkça kabul edilerek ilerlenebilir. Karar kaydına kullanılan veri, tarih, onaylayanlar ve yeniden açma koşulu eklenir. Böylece discovery, görüşme notu olmaktan çıkıp mimari kararın denetlenebilir temeline dönüşür.

Arven doğrulama atölyesini doksan dakikalık karar oturumu olarak tasarla. İlk on beş dakikada problem cümlesini ve iş etkisini yeniden teyit et: ay sonu kapanışındaki gecikme hangi iş adımını durduruyor, kabul edilebilir süre nedir ve mevcut geçici çözümün maliyeti nedir? Sonraki bölümde hipotez tablosunu aç. Storage gecikmesi, host kaynak baskısı, uygulama kilidi, ağ kaybı ve yedekleme çakışması için beklenen belirti, gerekli metrik ve hipotezi yanlışlayacak sonucu yan yana göster. Katılımcılardan yeni açıklamalar iste, fakat her yeni hipotezi bir test ve karar etkisiyle ilişkilendir. Ölçüm planında saat, örnekleme aralığı ve veri kaynağı ortaklaştırılır. Finans uygulamasının işlem süresi ile altyapı metrikleri aynı zaman çizgisine gelmezse korelasyon kurulamaz. Ortalama değerlerin yoğunluk anını gizlememesi için hem olay penceresi hem karşılaştırma baz çizgisi seçilir. Veri sahibi her metriğin güvenilirliğini açıklar: sayaç neyi ölçüyor, hangi katmanı kapsamıyor, saat senkronizasyonu doğru mu ve veri kaybı var mı? Katılımcılar yalnız kendi sistemlerinin normal olduğunu savunmak yerine, hipotezlerinin hangi sonuçla eleneceğini kabul eder.

Atölyeden sonra kanıtı tek cümlelik sonuçlara indirgeme. Hangi zaman penceresinin incelendiğini, verinin hangi sınırlarla yorumlandığını ve sonucun hangi seçeneği neden güçlendirdiğini karar notuna yaz. Aynı belirti tekrarlandığında ekip bu kayda dönerek eski varsayımı körü körüne kullanmak yerine koşulların hâlâ geçerli olup olmadığını kontrol edebilmelidir. Bu izlenebilirlik, doğru sorunun tek bir görüşmede bulunmasından çok daha değerlidir; sonraki kararların da aynı kanıt disiplinini kullanmasını sağlar.

Atölyenin üçüncü bölümünde karar dallarını önceden yaz. Gecikme storage kuyruğuyla aynı anda yükselir ve uygulama/host göstergeleri normal kalırsa sınırlı storage iyileştirmesi test edilir. Uygulama kilitleri baskınsa platform alımı ertelenir ve sorgu/işlem tasarımı ele alınır. Birden fazla katman etkiliyse küçük ve geri döndürülebilir müdahaleler sıralanır; her adımın ölçümü tekrarlanır. Sonuç belirsizse ek testin karar değerine bakılır. Daha fazla veri seçimi değiştirmeyecekse ekip sonsuz analize devam etmez; varsayımı, artık riski ve yeniden açma koşulunu onaylar. Kapanışta herkesin aynı şeyi duyduğunu doğrula. Seçilen sonraki adım, elenen seçenekler, beklenen kanıt, kabul eşiği, sahip ve tarih yüksek sesle okunur. Ürün veya BoM ancak bu karar omurgasından sonra konuşulur. Böylece “daha büyük storage” talebi reddedilmeden sınanmış olur; doğruysa ölçüyle boyutlandırılır, yanlışsa müşteri gereksiz yatırımdan korunur. Pre-Sales burada müşterinin sorusuna doğrudan ürün cevabı vermek yerine, müşterinin güvenle karar verebileceği daha doğru soruyu ve kanıt yolunu kurar.