Entegre Teklif ve POC Karar Simülasyonu

Ekin Lojistik’in kurgusal sevkiyat akışında üç ayrı lab tamamladın: yazılı kapsam ve kanıt günlüğü, uçtan uca ölçüm ile arıza teşhisi, kontrollü hata ve kurtarma provası. Bu son dersin görevi, etkileyici grafiklerden bir satın alma vaadi üretmek değildir. Test edilen iş akışını, kullanılan sentetik veriyi, koşu sayısını, geçersiz koşuları, izolasyon düzeyini ve onaylı kabul ölçütlerini bir karar dosyasında birleştirmektir. Ekin gerçek müşteri değildir; rakamlar, bütçe ve roller eğitim örneğidir. Microsoft Learn test rehberi strateji, plan, hazırlık, yürütme ve analiz ayrımını; giriş/çıkış ölçütlerini, ortamın temsiliyetini ve paydaş onayını vurgular. Bu çerçeveyi Ekin için yöntem olarak uyarlıyoruz. Yaklaşık 30 dakika kanıt birleştirme, 35 dakika teklif/POC karar provası ve 15 dakika değerlendirme planla. Nihai çıktı, dört olası karardan birini gerekçelendiren sürümlü karar paketi: koşullu POC, yeniden keşif, sınırlı teklif veya dur.

Karar sorusunu önce operasyon sonucu olarak yaz: sevkiyat kaydının doğru, izlenebilir ve beklenen zamanda tamamlanması için hangi kanıt yeterli? Laboratuvarın ilk koşusunda görülen gecikme artışı, ikinci koşudaki kuyruk birikimi ve üçüncü koşudaki restore uzlaştırması birbirinin yerine geçmez. Her bulguyu deney kimliği, başlangıç durumu, veri seti, yapılandırma sürümü, gözlenen sonuç ve tekrarlanabilirlik ile kaydet. Bir ölçüm iş hedefini karşılıyor görünse bile izinli erişim testi başarısızsa bütün teklifin kabulü çıkmaz. Tersine tek bir geçersiz koşu da mimariyi otomatik olarak mahkûm etmez; geçersizlik nedeni ve tekrar planı gerekir. Müşterinin gerçek iş hedefi, bütçesi, RTO/RPO’su ve karar takvimi açıklanmadığından bu alanlar UNKNOWN kalır. Lab hedefi olarak örnek bir eşik kullanılabilir, fakat teklif metninde müşterinin onayladığı SLA gibi gösterilemez. Karar dosyasındaki her sayı 'sentetik alıştırma sonucu' etiketi taşır.

Ekin için tek bir ürün listesi yerine üç hipotez kur. A seçeneği mevcut kuyruk ve uygulama akışının iyileştirilmesi, B seçeneği ölçülen darboğaz için sınırlı kaynak artışı, C seçeneği mimarinin daha büyük bir yeniden tasarımı olabilir. Bunlar müşteriye önerilmiş veya fiyatlanmış ürünler değil, karar pratiği için tasarlanmış kurgusal alternatiflerdir. Her seçeneği aynı iş hedefi, aynı sentetik yük profili, aynı süre ve aynı risk ölçeğiyle karşılaştır. A’nın yalnız düşük maliyetini B’nin yalnız yüksek kapasitesiyle yan yana koymak adil kıyas değildir. İlgili bulguyu REQ, risk, ADR, HLD, BoM ve POC koşusuna bağla. Bir alternatif için POC yapılmadıysa satıra 'kanıt yok' yaz; üç nokta atıp sessizce olumlu puan verme. Teknik gerekçe, seçilmeyen seçeneklerin neden elendiğini de kaydetmelidir. Maliyet tarafında satın alma, lisans, işletim, izleme, yedekleme, destek, geçiş ve olası çift çalıştırma aynı dönem için ele alınır. Bunlardan herhangi biri eksikse toplam sahip olma maliyeti kesinleştirilmez.

Karar brifinde mimariyi iş sonucuna bağlayan üç tür delil bulunur: ölçülmüş performans, ispatlanmış kurtarma/işletim ve desteklenmiş ticari varsayım. Örneğin B seçeneği gecikmeyi düşürürken kurtarma provasında daha fazla veri uzlaştırma adımı gerektiriyorsa 'en hızlı' olması otomatik kazanan yapmaz. C seçeneği teoride ölçeklenebilir olabilir, fakat entegrasyon, geçiş süresi ve güvenlik değişikliği maliyeti sınanmamışsa bu sadece tasarım hipotezidir. A seçeneği ucuz görünürken tek hata alanını koruyorsa işletim riski açık tutulur. Her alternatif için kabul edilemez koşul ayrı yazılır; ortalama puanla kritik veri bütünlüğü kusuru saklanmaz. BoM’da her satırın kapasite varsayımı, sürümü ve hangi test sonucuna dayandığı görülmelidir. Teklif fiyatına henüz alınmamış vendor lisans hakkı veya müşteri indirimi eklenmez. Eğer eşit kapsamlı maliyet verisi yoksa 'karşılaştırma eksik' kararı da meşrudur.

Şimdi teknik aday için ikinci aşama POC gerekip gerekmediğini belirle. POC sorusu 'ürün çalışıyor mu?' kadar belirsiz olamaz; örneğin kuyruk darboğazının çözümü, sevkiyat işlem doğruluğu ve restore sonrası tekrar işleme davranışı aynı sürümde ölçülmelidir. Giriş koşulunda yazılı test yetkisi, izole ortam, sentetik veri, hedef iş akışı, onaylı metrik, ekip rolleri, durdurma eşiği ve güvenli geri dönüş yer alır. NIST SP 800-115 teknik güvenlik değerlendirmesinde planlama, yürütme, bulgu analizi ve azaltım süreçlerini açıklar; Rules of Engagement tanımı izinli testin önceden kararlaştırılmış sınırını ifade eder. Burada güvenlik testi müşterinin gerçek ortamında otomatik yapılacak bir faaliyet değildir. Yetkili kapsam yoksa yeni POC koşusu başlamaz. Çıkış koşulunda başarılı ve başarısız koşular, geçersiz koşular, ölçümlerin temsiliyet sınırı, veri uzlaştırması ve operasyon kabulü görülür. Hedef aşılırsa sonuç 'lab koşulu sağlandı' olarak yazılır; müşteri üretim SLO’su veya tedarik kabulü olarak genişletilmez.

Teklifin teknik bölümü POC raporunun kopyası değildir. Teklif, müşterinin doğruladığı gereksinimlerle uyumlu mimari kapsamı, dahil/dışarıda olan bileşenleri, lisans ve destek koşullarını, geçiş varsayımlarını, teslim kabulünü ve riskleri açıkça yazar. Henüz müşteri tarafından doğrulanmamış sevkiyat hacmi, RTO/RPO, bütçe veya güvenlik istisnası 'teklif koşulu / TBD' olarak tutulur. İstisna satırı görünür ve sahipli olmalıdır; küçük dipnotta gizlenmez. POC kanıt ID’si teklif iddiasına bağlanır; ortam temsiliyetinin düşük olduğu satırda kesin performans garantisi verilemez. Fiyat tablosundaki donanım veya bulut tüketim miktarı, aynı sürümdeki BoM ve kullanım tahminiyle tutarlı olmalıdır. Müşteri yeni bir hacim değeri verirse REQ, sizing, HLD, BoM/TCO, POC test planı ve teklif sürümü birlikte gözden geçirilir. Bu etki kontrolü yapılmadan sadece fiyatı değiştirmek teknik olarak dürüst değildir.

Son simülasyonda dört rol konuşur: iş sonucu sahibi hedef ve kabulü, mimar alternatif gerekçesini, operasyon/güvenlik temsilcisi kurtarma ve değişiklik riskini, ticari sahip teklif ve lisans sınırını değerlendirir. Bu kişiler eğitim rolüdür; Ekin adına gerçek bir onay verilmez. Bir sayfalık yönetici özeti, kanıt eki, karşı görüş, açık TBD ve karar tutanağı hazırlanır. Karar seçenekleri nettir: sınırlı kapsamla ilerle, belirli kanıt koşuluyla ilerle, POC/keşfi tekrarla veya dur. Kurul puan ortalamasını körlemesine kullanmaz. Restore veri bütünlüğü başarısızsa operasyon itirazı kayda geçer ve kapanış kanıtı olmadan 'tam kabul' yazılmaz. Güvenlik politikası yetkili kullanıcıyı kesiyorsa başarılı negatif erişim testi tek başına yetmez. Her koşul ölçülebilir eşik, owner, tarih, karar etkisi ve yeniden kurul tetikleyicisi taşır. Kritik bir TBD için kimse sahip çıkmıyorsa teklifin kapsamı daraltılır veya karar durdurulur.

Karar günlüğünün değişiklik yönetimi de sınanır. Diyelim ki Ekin senaryosunda sonradan daha yüksek bir sevkiyat hacmi bildirildi; bunun gerçek müşteri açıklaması değil, eğitimde gelen yeni bilgi olduğunu açıkça etiketle. Eski lab koşusunu silme. Hangi baseline artık geçersiz, hangi kapasite varsayımı değişti, hangi ADR/BoM ve fiyat satırı yeniden hesaplanacak, hangi POC koşusu tekrar edilecek göster. Yeni sürümün önceki sürümü neden geçersiz kıldığını yaz. Karar tutanağında 'kanıtlandı', 'varsayıldı', 'bilinmiyor' ve 'yeniden doğrulanacak' statüleri ayrı kalsın. Bir sonraki modülün capstone çalışmasında öğrenci aynı disiplinle daha geniş bir müşteri teklif dosyası kuracak; bu Ekin labının otomatik üretim onayı olduğu anlamına gelmez. Son teslimde iç kurul önerisi ile yetkili müşteri kararını ayrı satırda göster. Karşı görüşü, geçersiz koşuları ve açık maliyeti temiz bir sunum uğruna saklamak teknik dürüstlüğü bozar.