Çok lokasyonlu yapılarda bulut altyapısı yönetimi, çoğu zaman teknik bir tercih olmanın ötesine geçer ve doğrudan operasyonun parçası haline gelir. İstanbul’daki ekip farklı bir ağ kuralı uygular, Ankara’daki ekip yedeklemeyi başka saatlerde çalıştırır, yurt dışı ofisi ise erişim izinlerini yerel ihtiyaçlara göre genişletir. İlk bakışta esnek görünen bu yaklaşım, 6 ay içinde denetimi zor, maliyeti belirsiz ve müdahalesi yavaş bir yapıya dönüşebilir.

Standartlaştırma burada “her şeyi tek kalıba sokmak” demek değildir. Amaç, lokasyonlar arasında ortak bir çekirdek model oluşturmaktır: aynı kimlik politikaları, benzer log formatları, onaylı altyapı şablonları, ölçülebilir servis seviyeleri ve merkezi görünürlük. İyi kurgulanmış bir modelde yeni bir şubenin devreye alınması, 2-3 haftalık dağınık kurulumlar yerine günler içinde tamamlanabilir. Dahası, bu hız güvenlikten ödün verilerek değil, standardın sağladığı düzen sayesinde elde edilir.

Standartlaştırma neden çok lokasyonlu yapıda kritik hale gelir?

Tek lokasyonlu bir şirkette küçük farklar bir süre tolere edilebilir. Ancak işin içine birden fazla şehir, ülke ya da depo girdiğinde tablo değişir. Her lokasyonda farklı sanal ağ isimlendirmesi, farklı yedekleme saklama süresi veya farklı erişim rolü kullanılıyorsa, merkezi ekip aynı sorunu üç ayrı dille çözmek zorunda kalır.

Somut bir örnek verelim. 12 şubeli bir dağıtım şirketinde her lokasyonun ERP’ye API ile bağlandığını düşünün. IP whitelist kuralları, sertifika yenileme tarihleri ve izleme alarmları standart değilse, tek bir sertifika süresinin dolması yalnızca o şubeyi değil, sipariş akışını da etkileyebilir. Sorun teknik görünür; etkisi ise doğrudan ciroya ve müşteri memnuniyetine yansır.

  • Olay müdahale süreleri uzar; çünkü her ortamı yeniden anlamak gerekir.
  • Güvenlik açıkları sessizce büyür; zayıf bir lokasyon tüm yapıyı etkiler.
  • Maliyet kontrolü bozulur; kaynak etiketleme yoksa hangi birimin ne tükettiği netleşmez.
  • Denetim hazırlığı zorlaşır; log, erişim kaydı ve politika dokümantasyonu parçalı kalır.

Standartlaştırmanın hedefi tam olarak bu sürtünmeyi azaltmaktır. Her lokasyonun birebir aynı olması gerekmez. Fakat ortak çerçevenin dışına çıkan her farkın bilinçli, kayıtlı ve onaylı olması gerekir.

İlk adım: ortak bir bulut işletim modeli tanımlamak

Başarılı bir yapı, teknik araçla değil işletim modeliyle başlar. Çok lokasyonlu şirketlerde şu sorunun yanıtı net olmalıdır: hangi kararlar merkezden alınır, hangileri lokasyona bırakılır? Bu ayrım yazılı değilse, standart yalnızca kâğıt üzerinde kalır.

Pratikte işe yarayan model, merkezi platform ekibi ile yerel operasyon ekipleri arasında net bir görev sınırı çizer. Merkez ekip; kimlik yönetimi, ağ tasarımı, loglama standardı, yedekleme politikası ve altyapı şablonlarından sorumlu olur. Lokasyon ekipleri ise iş birimine özel uygulama ihtiyaçlarını bu çerçeve içinde talep eder.

RACI benzeri net sorumluluk matrisi kurun

Örneğin 5 ana başlık için sahiplik belirlenebilir: IAM, network, backup, monitoring, cost management. Her başlıkta tek bir “owner” olması önemlidir. İki farklı ekip aynı politikayı sahipleniyorsa, kritik anda aslında hiç kimse sahiplenmiyor olabilir.

Bu çerçevede şirketler genellikle 30-60 günlük bir keşif dönemi planlar. Mevcut lokasyonlar, hesap yapıları, erişim rolleri, veri akışları ve bağımlılıklar envantere alınır. Envanter çıkarılmadan standart tasarlamak, çizimi yapılmamış bir fabrikanın güvenlik planını hazırlamaya benzer.

Hesap, abonelik ve kaynak hiyerarşisini baştan kurgulayın

Bulut altyapısı yönetimi dağınıklaşıyorsa, bunun nedenlerinden biri hesap yapısının kontrolsüz biçimde büyümesidir. Şube açıldıkça yeni abonelikler, test hesapları ve geçici projeler açılır. 18 ay sonra hangi hesabın aktif, hangisinin kritik, hangisinin sahipsiz olduğu anlaşılamaz hale gelir.

Bu yüzden hiyerarşi ilk günden tanımlanmalıdır. En azından şu seviyeler net olmalıdır: şirket, iş birimi, ortam, lokasyon. Üretim ve test kaynaklarını aynı hesapta tutmak kısa vadede kolay görünebilir; ancak hata alanını büyütür. Özellikle çok lokasyonlu yapılarda üretim ortamını ayrı sınırlar içinde tutmak, erişim ve denetim açısından daha güvenlidir.

Etiketleme standardı teknik değil, finansal bir gerekliliktir

Kaynak etiketleri çoğu ekipte sonradan akla gelir. Oysa etiket olmadan maliyet ayrıştırması zayıf kalır. En az 6 zorunlu etiket alanı çoğu senaryoda iş görür: location, environment, application, owner, cost-center, data-class.

Küçük bir örnek:

{
  "location": "izmir-dc-link",
  "environment": "prod",
  "application": "wms-api",
  "owner": "platform-team",
  "cost-center": "logistics-04",
  "data-class": "internal"
}

Bu yapı sayesinde aylık maliyet raporunda “depo yönetim sistemi hangi lokasyonda ne kadar kaynak tüketiyor” sorusu tahminle değil, veriyle cevaplanır.

Altyapıyı kod ile yönetmek: standartlaşmanın omurgası

Bir lokasyonda elle açılan ağ kuralı, başka bir lokasyonda farklı biçimde tekrarlandığında standart bozulur. Bu nedenle altyapının kod ile tanımlanması artık bir tercih değil, temel bir gereksinimdir. Terraform, OpenTofu, Pulumi ya da sağlayıcının kendi şablon araçları kullanılabilir. Buradaki asıl değer araç isminde değil, tekrar üretilebilirliktedir.

Örneğin her yeni depo için aynı ağ topolojisi açılıyorsa, bu yapı modül haline getirilmelidir. VPC/VNet, alt ağlar, güvenlik grupları, VPN veya SD-WAN entegrasyonu, log hedefleri ve izleme ajanları tek bir şablondan gelmelidir. Böylece Bursa’daki depo ile Gaziantep’teki depo arasında güvenlik farkı, “unutulan bir ayar” yüzünden oluşmaz.

Altın şablon yaklaşımı

Kurumsal ölçekte sık kullanılan yöntemlerden biri “golden template” mantığıdır. Diyelim ki şirket yılda ortalama 4 yeni lokasyon açıyor. Her seferinde sıfırdan kurulum yapmak yerine, onaylı bir lokasyon şablonu kullanılır. Bu şablonda ağ, erişim, loglama, yedekleme ve alarm kuralları hazır gelir. Yerel ekip yalnızca lokasyona özgü birkaç parametreyi girer.

Bu yaklaşımın faydası yalnızca hız değildir. Değişiklik denetimi de kolaylaşır. Kod deposundaki fark kayıtları üzerinden hangi kuralın ne zaman güncellendiği görülebilir.

Kimlik, erişim ve güvenlik politikalarını merkezileştirin

Çok lokasyonlu şirketlerde en sık zayıflayan alanlardan biri erişim yönetimidir. “Şimdilik verelim, sonra daraltırız” yaklaşımı zamanla kalıcı hale gelir. Bir süre sonra aynı göreve sahip kullanıcıların yetkileri lokasyon bazında farklılaşır. Burada standartlaştırma, rol tabanlı erişim modeliyle başlar.

Merkezi kimlik sağlayıcı üzerinden tekil oturum açma, çok faktörlü kimlik doğrulama ve koşullu erişim politikaları uygulanmalıdır. Özellikle üretim ortamları için kalıcı yönetici hesabı sayısı mümkün olduğunca sınırlı tutulmalı, ayrıcalıklı erişimler süreli olmalıdır. 8 saatlik geçici yetki penceresi, süresiz yönetici rolüne göre çok daha yönetilebilir bir yapı sunar.

  • Her lokasyonda aynı parola ve MFA politikası uygulanmalı.
  • Yerel ekipler yalnızca ihtiyaç duydukları kaynakları görmeli.
  • Servis hesapları kişi hesabından ayrılmalı, anahtar rotasyonu takvime bağlanmalı.

Güvenlik politikaları da kod gibi versiyonlanabilir. Örneğin güvenlik grubu kuralları veya policy as code araçlarıyla, uygunsuz kaynak açılışları daha en başta engellenebilir.

Gözlemlenebilirlik, loglama ve olay müdahalesi tek dilden konuşmalı

Standart olmayan izleme yapısı, olay anında en pahalı gecikmelerden birini üretir. Bir lokasyonda CPU alarmı yüzde 85’te, diğerinde yüzde 95’te çalışıyorsa merkezi ekip sağlıklı bir karşılaştırma yapamaz. Aynı sorun log formatlarında da ortaya çıkar.

Bu yüzden ortak bir gözlemlenebilirlik katmanı kurmak gerekir. Metrikler, loglar ve izler mümkünse merkezi platformda toplanmalı; lokasyon bazlı filtrelenebilmelidir. En kritik 10-15 alarm standardı tüm lokasyonlarda aynı mantıkla tanımlanmalıdır. Örneğin API hata oranı 5 dakikalık pencerede belirli eşiği aşarsa, tüm lokasyonlar için benzer alarm üretmelidir.

Gerçek senaryo: depo uygulamasında 20 dakikalık kesinti

Bir depo lokasyonunda el terminali uygulamasının yanıt süresi 300 ms’den 2 saniyenin üzerine çıkıyor. Ağ mı, veritabanı mı, API mi? Standart dashboard, ortak log alanı ve korelasyon kimliği yoksa ekipler farklı ekranlarda aynı sorunun izini sürer. Oysa merkezi izleme modelinde uygulama yanıt süresi, VPN tünel durumu, veritabanı bağlantı sayısı ve kuyruk uzunluğu aynı panelde görülebilir. Müdahale süresinin dramatik biçimde kısaldığını söylemek kolaydır; ancak asıl önemli nokta ölçülebilirliktir. Şirket, örneğin ilk yanıt süresini ve kök neden bulma süresini aylık olarak takip edebilir.

Yedekleme, felaket kurtarma ve veri yerleşimi lokasyon bazında değil, politika bazında yönetilmeli

Her lokasyonun kendi yedekleme alışkanlığını geliştirmesi ciddi risk yaratır. Bir şube 7 gün saklama yaparken diğeri 30 gün tutuyorsa, geri dönüş beklentileri boşa çıkabilir. Burada ortak bir RPO/RTO matrisi tanımlanmalıdır. Her sistemin aynı hedefe sahip olması gerekmez. Ancak hedefler sınıflandırılmış olmalıdır.

Örneğin kritik sipariş sistemi için RPO 15 dakika, RTO 1 saat belirlenebilir. Daha az kritik raporlama sistemi için bu değerler farklı olabilir. Esas mesele, bu hedeflerin lokasyon yöneticisinin tercihine göre değişmemesidir.

Veri yerleşimi de benzer şekilde ele alınmalıdır. Özellikle farklı ülkelerde faaliyet gösteren şirketler için hangi verinin hangi bölgede tutulacağı, hangi logların merkezi ortama kopyalanacağı açıkça tanımlanmalıdır. Teknik mimari ile hukuki yükümlülük aynı belge setinde buluşmalıdır.

Maliyet yönetimini rapor değil, kontrol mekanizması haline getirin

Bulutta standartlaştırma yalnızca güvenlik ve operasyon için yapılmaz. Fatura disiplini de işin bir parçasıdır. Çok lokasyonlu şirketlerde maliyet sıçramaları genellikle sessizce başlar: unutulan diskler, fazla boyutlandırılmış veritabanları, gece kapanmayan test ortamları.

Bu noktada aylık rapor tek başına yeterli olmaz. Bütçe alarmı, etiket zorunluluğu, kullanılmayan kaynak tespiti ve rezervasyon/taahhüt analizi gibi kontroller devreye alınmalıdır. Örneğin etiketsiz kaynakların 24 saat içinde raporlanması veya üretim dışı makinelerin mesai dışında kapatılması için otomasyon kurulabilir.

Maliyet standardı iyi kurulduğunda finans ve teknoloji ekipleri aynı veriye bakar. “Bulut pahalı” gibi genel yorumlar, yerini “hangi uygulama, hangi lokasyon, hangi sebeple arttı” sorusuna bırakır.

Standartlaşmayı proje değil, yaşayan yönetişim modeli olarak ele alın

En sık yapılan hatalardan biri, standartlaşmayı tek seferlik bir dönüşüm projesi sanmaktır. Oysa yeni lokasyonlar açıldıkça, yeni SaaS servisleri bağlandıkça ve ekip yapısı değiştikçe çerçevenin de güncellenmesi gerekir. Bu nedenle 90 günde bir gözden geçirme döngüsü, çoğu kurum için iyi bir başlangıçtır.

Bu gözden geçirmede şu başlıklar incelenebilir: politika ihlalleri, şablon dışı kaynaklar, erişim istisnaları, yedekleme başarısızlıkları, alarm gürültüsü, maliyet sapmaları. Hedef kusursuzluk değildir. Amaç, sapmaları görünür kılmak ve kontrollü biçimde azaltmaktır.

Özetle, çok lokasyonlu şirketlerde bulut altyapısı yönetimi standartlaştırılırken başarı tek bir araç seçiminden gelmez. Ortak işletim modeli, kod ile tanımlanan altyapı, merkezi güvenlik politikaları, ölçülebilir izleme ve disiplinli maliyet kontrolü birlikte çalışmalıdır. Sağlam kurulan bu yapı, yeni lokasyon açılışlarını hızlandırır, denetimi kolaylaştırır ve teknoloji ekiplerinin enerjisini yangın söndürmekten iyileştirmeye yönlendirir.