Sizing, Mimari Alternatifler ve Karar Kayıtları

Capstone’un ikinci dersinde ilk oturumun Discovery ve Requirement Register çıktısını mimari çalışmaya taşırken sayıları icat etmeyeceksin. Arven’in kanonik bilgisi yaklaşık çalışan sayısı, iki lokasyonun varlığı, VMware ve Veeam kullanımı, altyapı yaşı ve modernizasyon değerlendirmesinden ibarettir. VM adedi, CPU/RAM tahsisi, gerçek kullanım, storage kapasitesi, IOPS, gecikme, ağ trafiği, büyüme, iş akışı eşikleri ve DR hedefleri bilinmiyor. Bu nedenle kesin sunucu veya disk önerisi üretmek için dayanak yoktur. Ders çıktısı sayı içermeyen bir sizing yöntemi, sentetik veriyle açıkça etiketlenmiş hassasiyet örneği, üç mimari alternatif ve sürümlü ADR/HLD iskeletidir. Yaklaşık 25 dakika ölçüm planı, 35 dakika alternatif analizi ve 20 dakika karar kaydı ayır. Microsoft’un kapasite planlama rehberi sürekli ve pik yükü, büyümeyi, performans hedeflerini ve kaynak sınırlarını birlikte ele alır. Bu Azure rehberi Arven’e platform seçtirmez; eksik veriyi görünür kılan yöntem kaynağıdır.

Ölçüm planını iş akışından başlat. Önce hangi uygulamanın hangi saatte, hangi kullanıcı veya batch işlemiyle yük ürettiğini belirle; ardından compute, storage, SAN/ağ, veritabanı ve yedekleme sinyallerini aynı zaman çizgisinde bağla. CPU ortalaması tek başına kapasite değildir: pik, kuyruk, hazır bekleme, memory pressure, IO latency, throughput ve başarısız işlem birlikte incelenir. Sanal tahsis ile fiziksel tüketimi ayrı tut; thin provisioning, deduplikasyon veya sıkıştırmayı doğrulanmamış tasarruf olarak kesin BoM’a yazma. Örnekleme süresi bir normal dönem ve bilinen pik davranışı kapsamalı; dönem bilinmiyorsa müşteriyle belirlenir. Kaynak ölçümünün nasıl toplandığı, erişim izni, veri gizliliği ve export biçimi de planlanır. Gerçek veri bu eğitim deposuna yüklenmez. Her metrik için ölçüm kaynağı, birim, pencere, yüzde dilim, tekrarlanabilirlik ve owner vardır. Eksik veri için varsayım değil açık ölçüm isteği aç. Ölçüm geldikten sonra hesap güncellenebilir; başlangıçta yalnız yöntem ve aralık sunulabilir.

Veri eksikken iki kötü uç vardır: hiç analiz yapmamak veya sahte kesinlikte BoM üretmek. Capstone orta yolu görünür varsayım senaryolarıyla kurar. Eğitim örneği olarak yalnız yöntem göstermek için düşük, orta ve yüksek talep düzeyi tanımla; bunların Arven müşteri tahmini olmadığını her tabloda belirt. Örnek büyüme yüzdesi seçiyorsan sayıdan önce kaynağın 'eğitim varsayımı' olduğunu yaz; gerçek tekliften çıkar. Her senaryoda kapasite hesabının sürücülerini ayır: korunan veri hacmi, değişim oranı, saklama süresi, pik IO, eşzamanlı işlem, headroom ve arıza anındaki kalan kapasite. Tek ortalama çarpanla bütün katmanları büyütme. Maliyet de aynı senaryonun çıktısıdır; lisans, destek ve geçiş başlıkları farklı ölçeklenebilir. Microsoft kapasite planlama rehberindeki tahmin ve kaynak sınırı yaklaşımını burada pedagojik olarak kullanıyoruz. Onaylı müşteri gereksinimi gelince örnek senaryo yerine ölçülen aralık ve yetkili hedef geçer.

Hassasiyet analizi 'hangi bilinmeyen kararı değiştiriyor?' sorusunu yanıtlar. Örneğin 30 günlük saklama ile 365 günlük saklama arasında yedek kapasitesi ve maliyet çok değişebilir; ama gerçek süre bilinmiyorsa doğru sonuç bir disk markası değil, veri politikası sorusudur. Aynı şekilde tek site toleransı ile uygulama düzeyinde bölgesel kurtarma birbirinden farklı mimari ve işletim maliyeti taşır; RTO/RPO bilinmeden ikisini eşdeğer kabul etme. Kırılma noktalarını tablonun yanında belirt: hangi eşik geçilirse host adedi, storage tier, replika yöntemi veya lisans modeli yeniden açılır? Aritmetik bir örnek varsa formülü, birimi, yuvarlama ve headroom gerekçesini açık tut. Bir öğrenci hesap tablosundaki sayıyı kaynak belge olmadan müşteri olgusu diye kopyalayamamalı. İş sahibinin onaylamadığı kabul süresini SLO diye yazma. Karar paketi seçilebilir aralıklar, açık ölçüm planı ve durdurucu bilinmeyenler gösterdiğinde değer üretir.

İlk dersin REQ kayıtları ve bu dersin ölçüm planı üzerine üç aday mimari düşün: mevcut VMware ortamını kontrollü yenileme, belirli iş yüklerini ayrıştırarak kademeli dönüşüm ve daha kapsamlı platform geçişi. Bunlar müşteri tarafından onaylı yol veya vendor kısa listesi değildir. Her seçenek aynı iş sonucuna, güvenlik/operasyon koşuluna, ölçüm boşluğuna ve test planına göre değerlendirilir. A seçeneğinin geçiş kolaylığını, B’nin esnekliğini ve C’nin potansiyel standardizasyonunu yazarken karşı maliyetleri de eşit ayrıntıda sun. Hangi bileşen korunur, hangisi taşınır, hangi veri kopyalanır, rollback nerede zorlaşır? Site/DR bağımlılıkları, uygulama sahipleri, SAN/storage uyumluluğu, Veeam koruma modeli, lisans hakları ve bakım döngüsü ayrı risk başlıklarıdır. Bu başlıkların her biri ek keşif gerektirebilir. Microsoft mimari tasarım spesifikasyonu rehberi alternatiflerin, operasyon ve olağanüstü durum kararlarının iş gereksinimiyle gerekçelendirilmesini ister. Bu kaynak Azure seçimini zorunlu kılmaz; Arven’de teknoloji bağımsız karşılaştırma disiplini sağlar.

Alternatif matrisi puan oyunu olarak değil, izlenebilir tartışma olarak tasarla. Her satırda REQ ID, kanıt ID, hedef statüsü, etkilenmiş iş akışı, avantaj, dezavantaj, açık lisans/uyum noktası ve deney gereksinimi olsun. Örneğin daha ucuz görünen yerinde yenileme fiziksel alan veya destek sonu nedeniyle risk taşıyabilir; kapsamlı geçiş ise kısa vadede çift işletim ve veri taşıma riski oluşturabilir. Kanıt yoksa 'eşit' veya 'uygun' işaretleme; Inconclusive kullan. Güvenlik veya DR kabulü bilinmiyorsa genel bir 'yüksek erişilebilir' etiketi koyma. Karar ağırlıkları iş sahibi ve teknik/operasyon rollerince doğrulanmalıdır; satıcı ekibinin kendi önceliği gizlice ağırlık haline gelmez. Sonuç şu aşamada kesin seçim olmayabilir: iki seçenek kontrollü POC’a kalır, biri kritik uyum açığı nedeniyle elenir veya daha fazla Discovery gerekir. Her seçimin nedenini ve koşulunu yaz. Farklı kapsamdaki fiyatları kıyaslamayı üçüncü derste BoM/TCO kapısı altında yapacaksın; burada teknik alternatiflerin kapsamını netleştir.

Alternatif karşılaştırmasını ADR’ye çevir. ADR başlığı bir kararı adlandırır; bağlam ve iş gereksinimi, değerlendirilen alternatifler, seçilen veya ertelenen yol, gerekçe, beklenen sonuç, bilinen olumsuzluk, açık kanıt ve yeniden açılma tetiği içerir. Microsoft ADR rehberi elenen alternatiflerin de belgelenmesini ve karar değiştiğinde eski kaydı sessizce düzenlemek yerine yeni kaydın eskisinin yerine geçtiğini göstermeyi önerir. Capstone v1 ADR’si 'kademeli ayrıştırma koşullu aday' gibi geçici statü taşıyabilir; müşteri onayı, gerçek ölçüm ve lisans teyidi gelmeden APPROVED değildir. Karar kaydını REQ ID ve risk/varsayım defterine bağla. Örneğin storage gecikmesinin uygulama kuyruğunun nedeni olduğu henüz ispatlanmadıysa mimariyi buna göre kesinleştirme. ADR, başarılı görünmesi için karşı argümanı atmaz. Operasyon ekibi mevcut yedek işleyişinin yeni platformda nasıl sürdürüleceğini bilmiyorsa bu kararın önemli sonucu ve doğrulama işidir. Her yeni bilgi ADR’nin geçerliliğini etkileyecek şekilde etiketlenir.

HLD iskeleti ayrıntılı ürün konfigürasyonu yerine iş akışı, bileşen sınırı, veri yönü, güvenlik bölgesi, koruma ve kurtarma akışı, izleme ve operasyon sahiplerini gösterir. Her çizgi için kaynak ve hedef, veri sınıfı ve failure domain düşün. İstanbul ile Ankara arasında ok çizmek otomatik veri sürekliliği kanıtı değildir; aktarım modu, gecikme, veri tutarlılığı ve failback planı UNKNOWN olabilir. Tasarım diyagramı, varsayımlar ve değişiklik tarihiyle birlikte sürümlenir. Microsoft mimari spesifikasyon rehberi functional/nonfunctional ihtiyaçlar, geri dönüş, DR, güvenlik, test ve operasyon belgelerinin tutarlı olmasını ister. Bu HLD’nin teslim şartı değildir; öğrenciye boş alanları dürüstçe gösteren bir denetim listesidir. Son teslimde REQ → ADR → HLD → test planı zinciri geriye ve ileriye yürünebilmeli. Bir teknik bileşenin hangi gereksinime hizmet ettiği görünmüyorsa BoM’da da gerekçesiz maliyet olacaktır. Üçüncü derse yalnız koşullu mimari ve açık sayı aralıkları devredilir; vendor adı ve kesin fiyat için henüz kanıt yoktur.