Buluta, iş yükü iş yükü, gözünüz açık.
Değerlendirme odaklı geçiş — rehost, replatform veya yeniden düzenleme kararı iş yükü bazında verilir; provalar, geri alma planları ve önce sizin onayladığınız bir maliyet modeliyle yürütülür.
- Değerlendir & modelle
- Landing zone
- Dalgalar
- Optimize et
Maliyet modeli geçişten önce gelir.
Bulut geçişleri iki şekilde başarısız olur: her şeyi lift-and-shift ile taşıyıp eski sorunlarınızı daha yüksek bir bedelle devralmak ya da her şeyi yeniden düzenlemeye kalkıp hiç bitirememek. İkisi de aynı hatadan doğar — envanteri tek bir karar gibi ele almak. Ayda iki kez çalışan bir bordro sistemiyle bir an bile aksamaması gereken, müşteriye açık bir API aynı sorun değildir; ikisine aynı kararı vermek, birinin yanlış olacağını garanti eder.
Her iş yükünü kendi koşullarına göre ele alırız — yedi R, bir slogan olarak değil, bir hesap tablosuyla uygulanır. Her uygulama bağımlılıklar, veri ağırlığı, lisanslama, uyum kısıtları ve bir değişikliğin gerçekte ne kadar değer döndüreceği üzerinden puanlanır ve her biri tartışabileceğiniz bir karar alır: rehost, replatform, yeniden düzenleme, yeniden satın alma, yer değiştirme, koruma veya kapatma. Kapatma bu işte az başvurulan bir yanıttır ve artık kimsenin ihtiyaç duymadığı iş yüklerini bulmak programda gerçek bir tasarruf sağlayabilir.
Öngörülen aylık faturayı — ve arkasındaki varsayımları — hiçbir şey taşınmadan önce bilirsiniz; böylece iş gerekçesi faturayla karşılaşınca ayakta kalır, fatura etrafında yeniden yazılmaz.
Programın dayandığı dört disiplin.
Sıra önemlidir. Landing zone olmadan yapılan bir değerlendirme, ineceği yer olmayan bir plan üretir; FinOps olmadan kurulan bir landing zone ise yönetilebilir ama yerini aldığı veri merkezinden hâlâ pahalı bir envanter üretir.
Portföy değerlendirmesi
Her iş yükü puanlanır: bağımlılıklar, veri ağırlığı, uyum kısıtları ve doğru R — rehost, replatform, yeniden düzenleme, kapatma. Keşif, CMDB’nin söylediğini ağın ve çalışma zamanının fiilen gösterdiğiyle birleştirir; çünkü ikisi nadiren örtüşür. Çıktı, uygulama başına adı konmuş bir karar ve gerekçesiyle birlikte bağımlılık sırasına göre dizilmiş bir dalga planıdır; böylece bir karar sonradan esasına göre tartışılabilir.
Landing zone mühendisliği
Hesaplar, ağ, kimlik ve koruma kuralları kod olarak — envanteri taşımadan sonra da yönetilebilir tutan temel. Organizasyon yapısı, abonelik veya hesap sınırları, özel bağlantı, loglama ve politika, ilk commit’ten itibaren Terraform olarak durur. Veri konumu, şifreleme ve etiketleme plan aşamasında zorunlu kılınır; böylece denetçilerinizin sorduğu kontroller sonradan yapılacak bir proje değil, platformun özellikleridir.
Provalı canlıya geçişler
Her geçiş dalgası canlı ortam benzeri veriyle prova edilir ve geri alma yalnızca yazılmakla kalmaz, test edilir. Prova; runbook’u, süreleri ve go/no-go kriterlerini üretir ve süreler oturana kadar tekrarlanır. Planın en az bir kez baştan sona — ters gittiği kısım dâhil — uygulanmadığı hiçbir hafta sonunda taşıma yapılmaz.
Baştan itibaren FinOps
Bütçeler, etiketleme disiplini ve doğru boyutlandırma landing zone’un içine yerleştirilir; böylece fatura bir sürpriz değil, bir tasarım çıktısıdır. Her kaynak bir sahip ve bir masraf merkezi taşır, çünkü politika aksi hâlde var olmasına izin vermez. Taahhüt ve rezerve kapasite planlaması, envanter gerçek şeklini gösterecek kadar uzun süre çalışana dek bekler — yanlış boyutlara indirim satın almak, bir hatayı kalıcılaştırmanın yaygın ve pahalı bir yoludur.
İş günlük olarak nasıl yürür?
İş yükü başına bir karar ve gerekçesi.
Program değerlendirmede kazanılır ya da kaybedilir. Belgelenen değil, fiilen çalışan sistemleri envantere alır; bağımlılıkları ağ ve çalışma zamanı kanıtlarından çıkarır ve her iş yükünü veri ağırlığı, lisanslama, mevzuat kısıtı, değişim iştahı ve bir replatform’un gerçekte getireceği kazanç üzerinden puanlarız. Ardından her uygulama yedi R’den birini ve nedenini açıklayan bir satırı alır. Kapatma ve koruma gerçek yanıtlardır: bir envanterde genellikle kapatılabilecek uygulamalar ve başka bir yerde bir iş kararı verilene kadar olduğu yerde kalması gereken uygulamalar bulunur. Sonuç, hangi ekibin önce gönüllü olduğuna göre değil, bağımlılığa göre sıralanmış bir dalga planıdır.
- Çalışma zamanı ve ağ kanıtlarından envanter; CMDB’ye güvenmek yerine onunla karşılaştırılır
- Veri ağırlığı açıkça değerlendirilir — verinin bulunduğu yer genellikle iş yükünün nereye gideceğini belirler
- Lisans ve destek koşulları, taşımadan sonra değil, karar kesinleşmeden önce kontrol edilir
- Her karar gerekçesini taşır; böylece bir kısıt değiştiğinde yeniden ele alınabilir
Ekibinizin yönetmeye devam edebileceği bir landing zone.
Envanterler çoğu zaman, hızın yapıdan daha önemli olduğu ve herkese bir hesap açıldığı ilk dönemde yönetilemez hâle gelir. Landing zone bunu, yapıyı koda dönüştürerek önler: organizasyon ve hesap sınırları, ağ topolojisi ve özel bağlantı, dizininize federe edilmiş kimlik, merkezî loglama ve bir kuralı çiğneyen kaynağı reddeden politika. Ortamlar bundan sonra bir talep kaydıyla değil, bir CI hattı çalıştırmasıyla oluşturulur. Tamamı Terraform olduğu için bölge eklemek, bir iş birimini ayırmak veya sıfırdan yeniden kurmak bir arkeoloji projesi değil, gözden geçirilebilir bir değişikliktir. DevOps & Bulut çalışmalarımızın teslimatı üzerine inşa ettiği temel de aynı temeldir.
- Koruma kurallarının ekip başına kopyalanmadığı, devralındığı hesap ve abonelik yapısı
- Dizininize federe edilmiş kimlik ve kod olarak tanımlı en az ayrıcalık rolleri
- GDPR / KVKK yükümlülükleri için her planda zorunlu kılınan bölge sabitleme, şifreleme ve etiketleme
- Sonradan eklenen değil, ilk ortamdan itibaren var olan merkezî loglama ve maliyet verisi
Dalgalar, provalar ve gerçekten kullanılmış bir geri alma.
İş yükleri bağımlılık sırasına göre dalgalar hâlinde taşınır ve her dalga gerçek olmadan önce prova edilir. Prova, canlı ortam benzeri veriyle çalışır, gerçek süreleri üretir ve geri almayı fiilen uygular — çünkü hiç çalıştırılmamış bir geri alma planı plan değil, paragraftır. Veritabanları replikasyon ve paralel çalışma doğrulama penceresiyle taşınır; böylece canlıya geçiş umut dolu bir hafta sonu değil, kontrollü bir anahtarlamadır. Her dalga doğrulama kanıtıyla biter: hangi kontrollerin yapıldığı, ne döndürdükleri ve kimin imzaladığı.
- Bağımlılık sırasına göre dalgalar — hiçbir sistem, konuştuğu sistemler hazır ya da köprülenmiş olmadan taşınmaz
- Canlı ortam benzeri veriyle prova; süreler değişmeyi bırakana kadar tekrarlanır
- Veritabanı taşımaları replikasyon ve anahtarlama öncesi paralel çalışma karşılaştırmasıyla
- Önceden mutabık kalınan go/no-go kriterleri ve en az bir kez çalıştırılmış bir geri alma
Önce onayladığınız fatura, sonra iyileştirdiğiniz fatura.
Canlıya geçişte biten bir geçiş iş gerekçesi, yarım bir iş gerekçesidir. Hiçbir şey taşınmadan önce iş yükü başına bir maliyet modeli kurarız — işlem gücü profili, depolama katmanı, veri çıkışı, lisanslama, destek — ve varsayımlar gerçekle karşılaştırılabilsin diye yazıya dökülür. Her dalgadan sonra model gerçek faturayla karşılaştırılır ve fark yutulmak yerine açıklanır. Ardından optimizasyon aşaması gösterişsiz işi yapar: ölçülen kullanıma göre doğru boyutlandırma, depolama yaşam döngüsü kuralları, mesai dışında kapanan canlı dışı ortamlar ve şekil oturduğunda taahhüt planlaması.
- Adı konmuş varsayımlarla iş yükü başına maliyet modeli, taşımadan önce onaylanır
- Her dalgadan sonra model ile fatura mutabakatı ve sapmanın açıklanması
- Doğru boyutlandırma ve depolama yaşam döngüsü, gerçek kullanım verisi oluştuktan sonra
- Rezerve ve taahhütlü kapasite en son, envanter hareketsizleştiğinde planlanır
Masanın her tarafına ne düşer.
Envanter, okuyabileceğiniz kod olarak gelir.
Platform mühendisleriniz, sonunda bitmiş bir ortam teslim alan taraf değil, değerlendirmeden itibaren programın parçasıdır. Landing zone, dalga runbook’ları ve prova süreleri onlarla birlikte, çalışmaya devam edecekleri depoya yazılır. Yetkinlik aktarımı, son haftada akla gelen bir ek değil, planda zamanı belirlenmiş bir iştir.
- İlk commit’ten itibaren Terraform modülleri ve runbook’lar
- Provalarda birlikte çalışma; böylece canlıya geçiş ekibinizin gördüğü ilk sefer olmaz
- Ortam oluşturma talep kaydıyla değil, CI hattıyla
Tek seferde tek dalga ve tutan bir tarih.
Uygulama sahipleri; itiraz edebilecekleri bir karar, bir prova tarihi, bir doğrulama kontrol listesi ve bir geri alma penceresi alır. Sahibi go/no-go kararını imzalamadan hiçbir şey taşınmaz. Bir iş yükü rehost yerine replatform ediliyorsa, değişiklik kendi testleriyle birlikte ayrı bir iş olarak kapsamlandırılır; böylece geçiş riski ile değişiklik riski tek bir hafta sonunda birbirine karışmaz.
- Uygulama başına doğrulama kontrol listesi, provadan önce mutabık kalınır
- Canlıya geçişten sonra geri alma penceresi; eski yol sıcak tutulur
- Replatform işi, taşımanın kendisinden ayrı kapsamlandırılır
Veri konumu ve erişim tasarımda kararlaştırılır.
GDPR ve KVKK kapsamındaki veri konumu yükümlülükleri ait oldukları yerde ele alınır — landing zone tasarımında; bir planın ihlal etmeyi reddedeceği bölge sabitleme, şifreleme ve erişim kontrolü olarak. Her dalga doğrulama kanıtı bırakır; her altyapı değişikliği bir commit, bir gözden geçiren ve bir politika sonucu bırakır. Kontrollerimizi ISO 27001’e göre belgeliyoruz ve envanter daha derin bir güvence gerektirdiğinde Siber Güvenlik ekibimizi devreye alırız.
- Politikayla zorunlu kılınan ve denetçileriniz için belgelenen bölge sabitleme ve şifreleme
- Dizininize federe edilmiş, kod olarak tanımlı en az ayrıcalıklı erişim
- Dalga başına saklanan doğrulama kanıtı ve adı konmuş onaylayanlar
Taşımadan önce bir rakam, sonrasında bir sapma.
Finans, taşımadan önce maliyet modelini, arkasındaki varsayımları ve her dalgadan sonra bir mutabakatı görür. Etiketleme plan aşamasında zorunlu kılınır; böylece harcama, ayrı bir eşleştirme çalışmasına gerek kalmadan bir ekibe, bir ürüne ve bir ortama atfedilebilir. Taahhüt alımları, envanter şekil değiştirmeyi bırakana kadar bilinçli olarak ertelenir; indirim ile bağımlılık arasındaki fark budur.
- Adı konmuş varsayımlarla iş yükü başına maliyet modeli
- Harcama, aylık bir yeniden kurguyla değil, zorunlu etiketlerle atfedilir
- Taahhütler envanter kararlı hâle geldikten sonra planlanır
Her programa dâhil olanlar ve envanterinize bağlı olanlar.
Dalga başına tekrarlanan dört aşama.
Değerlendir & modelle
Envanter, bağımlılık haritası, iş yükü başına karar ve maliyet modeli — taşımadan önce onaylanır. Keşif, CMDB’ye güvenmek yerine çalışma zamanı ve ağ kanıtlarını kullanır ve her uygulama bu aşamadan yedi R’den biri ve gerekçesiyle çıkar. Dalga planı bağımlılığa göre sıralanır ve iş gerekçesi bir aralık değil, savunabileceğiniz bir belgedir.
Landing zone
Kod olarak güvenli ve uyumlu temel: kimlik, ağ, koruma kuralları, loglama. Hesap yapısı, özel bağlantı, politika, merkezî loglama ve maliyet etiketlemesi Terraform olarak kurulur. İlk iş yükü hesabı CI hattı tarafından oluşturulur; bu da hiçbir şey ona bağımlı hâle gelmeden temeli kanıtlar.
Dalgalar
İş yükleri bağımlılık sırasına göre dalgalar hâlinde taşınır — prova, canlıya geçiş, doğrulama, sonra bir sonraki dalga. Her prova canlı ortam benzeri veriyle çalışır ve süreler değişmeyi bırakana kadar geri almayı fiilen uygular. Veritabanları replikasyon ve paralel çalışma karşılaştırmasıyla taşınır; her canlıya geçiş imzalı doğrulama kanıtı ve açık kalan bir geri alma penceresiyle biter.
Optimize et
Taşıma sonrası doğru boyutlandırma, rezerve kapasite planlaması ve bunu hak eden iş yükleri için replatform iş listesi. Artık kullanım verisi mevcut olduğundan boyutlandırma kararları varsayıma değil ölçüme dayanır. Aşama aynı zamanda programı kapatır: eski envanter bilinçli biçimde hizmetten çıkarılır ve replatform adayları hevese göre değil, getiriye göre sıralanır.
Sonunda elinizde kalanlar.
- İş yükü başına karar ve maliyet modelini içeren değerlendirme raporu
- Terraform kodu olarak landing zone
- Dalga başına doğrulama kanıtıyla taşınmış iş yükleri
- Geri alma planları — teorik değil, test edilmiş
- Geçiş sonrası optimizasyon raporu ve FinOps panosu
- Prova edilmiş süreler ve go/no-go kriterleriyle dalga runbook’ları
- Geride bıraktığınız envanter için bir hizmetten çıkarma planı
Bunun doğru tercih olduğu durumlar.
Bir veri merkezi sözleşmesi, bir donanım yenilemesi ya da bir destek sonu tarihi karar vermeyi zorunlu kılıyorsa ve bu kararın tek hamlede değil, iş yükü bazında verilmesini istiyorsanız bunu seçin. Önceki bir geçiş yarıda kalıp envanterin yarısını her iki tarafta bıraktıysa, bulut faturası kimse sahiplenmeden şimdiden büyüyorsa ya da veri konumu yükümlülükleri tasarımın bir düzenleyiciye karşı savunulabilir olmasını gerektiriyorsa yine bunu seçin. Yeni envanteri bir teslimat kabiliyetine dönüştüren DevOps & Bulut hizmetinden hemen önce ve iş yüklerinin bir kısmı taşınmaktan fazlasını hak ettiğinde Yazılım Modernizasyonu ile birlikte doğal olarak konumlanır.
Asıl sorun altyapı değil uygulamanın kendisiyse bu yanlış tercihtir. Güvenli biçimde değiştirilemeyen bir sistem, başka bir yerde çalıştığı için değiştirilebilir hâle gelmez; bu Legacy Yeniden Yapılandırma işidir ve önce taşımak bunu daha da zorlaştırabilir. Kurum bir değerlendirmeden önce tarih istediğinde de yanlış tercihtir. Kimsenin envanterini çıkarmadığı bir sistem ortamı için canlıya geçiş takvimi taahhüt etmeyiz; çünkü kötü giden dalgalar genellikle haritada olmayan bir bağımlılığı olanlardır.
Sık sorulan sorular
Bu hizmetin genellikle konumlandığı yer.
Ne inşa ettiğinizi bize anlatın.
Bugün elinizde ne olduğunu ve neye ihtiyacınız olduğunu anlatın. Bir mühendis okur; nasıl yaklaşacağımızı ve size uyan modeli yazılı olarak iletir.