Bulut Durduğunda İş de Durmalı mı? Microsoft 365 Kesintisi ve Azure Local Disconnected Üzerinden Hibrit Mimariyi Yeniden Düşünmek

Perşembe günü öğleden sonra, Türkiye saatiyle 19:17’de, dünyanın dört bir yanındaki kullanıcılar Outlook’un açılmadığını fark etti. Birkaç saat içinde sorun Teams’e, SharePoint’e, Copilot’a ve en kritik olarak security ve device management araçlarına yayıldı. Outage ertesi sabah Asya’nın iş gününe ve Avrupa’nın sabahına sarktı.

Bu yazı bir “cloud’dan kaçış” manifestosu değil. Amacımız, bu olayı somut bir vaka olarak kullanıp Microsoft’un sovereign cloud stratejisinin en uç noktası olan Azure Local disconnected operations modelini ayrıntılı biçimde incelemek, “o akşam ne farklı olurdu?” sorusunu dürüstçe cevaplamak ve en sonunda çoğu kurum için doğru cevabın neden hybrid bir tasarım olduğunu göstermek.

Ne oldu?

Microsoft, outage’ı Exchange Online için EX1550543 numaralı incident ile 12 Kasım 2026 saat 16:17 UTC’de açtı. Incident kaydı, kullanıcıların birden fazla connection method ile mailbox’larına bağlanamayabileceğini söylüyordu. Yaklaşık iki saat sonra, 18:26 UTC’de, Microsoft 365’in geri kalanı için ikinci bir advisory (MO1550821) açıldı. 13 Kasım sabahına gelindiğinde bu advisory Exchange Online dışında 18 servisi listeliyordu; consumer tarafında Outlook.com, OneDrive, OneNote, To Do ve Teams da etkilenmişti.

Microsoft’un açıklamasına göre sorunun kaynağı, çok sayıda server’ın beklenmedik biçimde unavailable olması ve bunun ayakta kalan altyapıya aşırı load bindirmesiydi. Şirket malicious activity tespit etmediğini, outage çözüldükten sonra root cause raporu (PIR) yayımlayacağını belirtti. Kurtarma süreci de kolay olmadı: restart edilen server’ların traffic almaya başladıktan sonra tekrar unresponsive hale gelebildiği bildirildi; Microsoft traffic’i throttle ederek capacity’yi kademeli geri getirmeye çalıştı ve bu süreçte deployment’ları durdurdu.

Ölçek de dikkat çekiciydi. Downdetector, ABD’de Outlook için perşembe öğleden sonra kısa sürede yaklaşık 130 bin outage report kaydetti ve bildirimler bir saat içinde 74 ülke ve bölgeye yayıldı. Microsoft 365 connector’ları üzerinden çalışan third-party AI servisleri bile etkilendi.

Blast radius neden bu kadar büyüktü?

Bu outage’ı diğerlerinden ayıran şey, etkilenen servislerin çeşitliliği. Yalnızca e-posta ve chat değil, security ve management plane de aynı anda sorun yaşadı. Defender for Office 365’in Safe Links özelliğinin URL’leri verify edemeyebileceği bildirildi; bu, kullanıcıların Outlook ve Teams içindeki link’lere security check olmadan tıklayabileceği bir pencere demek. Customer Key kullanan bazı Windows 365 tenant’larında Cloud PC bağlantısı da etkilendi.

Mimari açıdan bakınca tablo şu: Modern bir Microsoft 365 tenant’ında identity, iletişim, içerik, security telemetry ve device policy aynı provider’ın aynı global altyapısında yaşıyor. Bu, normal günlerde büyük bir avantaj; ama ortak bir altyapı layer’ı sorun yaşadığında blast radius da ortak oluyor.

Gözden kaçan risk

Bir outage sırasında çalışanlar alternatif kanallara yönelir: kişisel e-posta, WhatsApp grupları, USB bellekle dosya taşıma. Aynı anda security telemetry ve link protection da zayıflamışsa, outage saatleri saldırganlar için en verimli saatler haline gelebilir. Business continuity planı, security planının bir parçasıdır.

Azure Local’a kısa bakış

Azure Local (eski adıyla Azure Stack HCI), Microsoft’un Azure yeteneklerini müşterinin kendi datacenter’ına, şubesine ve edge lokasyonlarına taşıyan distributed infrastructure çözümü. Müşterinin sahip olduğu, Microsoft tarafından doğrulanmış donanım üzerinde çalışır; VM’ler, Kubernetes cluster’ları ve seçili Azure servisleri bu donanımda koşar. Platform iki operating model sunar.

Connected mode

Default model budur. Management plane Azure’dadır; kaynaklar Azure Arc üzerinden Azure portalında görünür ve Azure Policy, Azure Monitor, Defender for Cloud gibi cloud servisleri kullanılabilir. Connected deployment’larda sistemin en az 30 ardışık günde bir Azure ile başarılı biçimde sync olması gerekir. Yani workload’lar on-premises çalışsa bile management, billing ve update Azure’a bağlıdır.

Disconnected mode

Bu modelde Azure control plane’inin seçili fonksiyonları, müşterinin ortamında çalışan bir local control plane ile değiştirilir. Portal, Azure Resource Manager, RBAC ve policy engine local bir virtual appliance üzerinde koşar. Microsoft’un ifadesiyle veri, operasyon ve kontrol kurumun sınırları içinde kalır.

Not: “disconnected” neyi kesiyor?

“Disconnected” ifadesi öncelikle management ve control plane’in Azure’a bağımlı olmamasını anlatır. Microsoft bu modeli bağlantının sınırlı, kesintili ya da hiç olmadığı ortamlar için konumlandırıyor. Dolayısıyla tamamen air-gapped bir savunma ortamı ile internet erişimi olan ama management’ını cloud’a bağlamak istemeyen bir kurum aynı platformu kullanabilir. Workload’larınızın internete çıkıp çıkmayacağı ise sizin network tasarımınızın kararıdır.

Disconnected operations mimarisi

Disconnected operations, Azure Local’a eklenen ve bir virtual appliance olarak teslim edilen bir add-on’dur. Bu appliance, normalde Azure’da çalışan portal, Resource Manager ve servis backend’lerinin bir subset’ini barındırır. Sonuç: admin’ler Azure portal’a çok benzeyen bir arayüz ve aynı Azure CLI komutlarıyla çalışır, ARM template’leri ve subscription/resource group yapısı aynen korunur.

Desteklenen servisler

Microsoft’un güncel dokümantasyonuna göre disconnected mode’da kullanılabilen servisler aşağıdaki gibidir. Listenin Azure public cloud’un tamamı olmadığına, bilinçli olarak sınırlı bir subset olduğuna dikkat edin.

Servis	Disconnected mode’da ne sağlar?
Azure portal	Azure public cloud’a benzeyen local portal deneyimi
Azure Resource Manager	Subscription’lar, resource group’lar, ARM template’leri ve CLI
RBAC	Subscription ve resource group seviyesinde role-based access
Managed identity	Destekleyen resource type’lar için system-assigned managed identity
Arc-enabled servers	Azure Local VM’lerinin guest OS yönetimi
Azure Local VMs	Windows ve Linux VM oluşturma ve yönetimi
Arc-enabled Kubernetes	VM’ler üzerindeki CNCF uyumlu Kubernetes cluster’larının yönetimi
AKS on Azure Local	Managed Kubernetes cluster’ları
Azure Local device management	Cluster oluşturma, node ekleme ve çıkarma
Azure Container Registry	Container image ve artifact’ler için local registry
Azure Key Vault	Secret ve key’ler için local vault
Azure Policy	Yeni resource’lar oluşturulurken standartların enforce edilmesi

Burada en önemli kazanım governance tutarlılığı. Cloud’da yazdığınız ARM template’leri, RBAC role definition’ları ve Azure Policy kuralları on-premises ortamda da aynı mantıkla çalışır. Bu, “cloud’da bir yöntem, on-prem’de başka bir yöntem” ikiliğini ortadan kaldırır ve hybrid bir mimarinin operasyonel maliyetini düşürür.

Management cluster ve donanım

Local control plane’in kendisi de bir workload olduğu için kendi donanımına ihtiyaç duyar. Microsoft, production ortamlarında control plane’i barındırmak üzere dedicated, 3 node’lu bir Azure Local management cluster şart koşuyor. Bu cluster yalnızca control plane ve management bileşenlerine ayrılır, uygulama veya tenant workload’larından izole edilir. Gerekçe üç başlıkta toplanıyor: control plane’in availability’si, workload’lardan operational isolation ve upgrade/maintenance süreçlerinde öngörülebilirlik.

Özellik	Datacenter configuration	Standard configuration
Minimum node sayısı	3	3
Node başına memory	512 GB	128 GB
Node başına core	24 physical core	24 physical core
Node başına storage	8 sürücü, her biri en az 2 TB (SSD/NVMe)	6 sürücü, her biri en az 2 TB (SSD/NVMe)
Boot disk	960 GB SSD/NVMe	960 GB SSD/NVMe
Hedef scale	Büyük datacenter, 1000+ node	Orta ölçek, 100+ node

Topoloji olarak Microsoft, management cluster için switchless storage network tasarımını öneriyor; bu, control plane için quorum ve resiliency sağlarken network karmaşıklığını azaltıyor. Capacity planning’de de net kurallar var: management cluster’ı general-purpose compute pool gibi kullanmamak, update’ler için capacity headroom bırakmak ve node failure/replacement senaryolarını önceden planlamak. Donanım tarafında yalnızca Premier Solutions for Azure Local kategorisindeki, kataloğunda “disconnected operations” yeteneği işaretli çözümler destekleniyor.

POC için 4 node

Hızlı bir deneme için Microsoft 4 node’luk bir donanım seti öneriyor ve bu node’ların test hedefinize göre üç farklı biçimde konumlandırılabileceğini belirtiyor:

Pratik tavsiye

Microsoft, POC için bile production’da kullanılabilecek donanımla başlamayı öneriyor. Farklı bir donanım tercih edilirse control plane node’ları için minimum olarak 256 GB memory, 24 core, 4 TB dedicated SSD/NVMe storage ve 960 GB boot disk belirtiliyor. POC’yi atılacak bir deneme olarak değil, production’ın ilk adımı olarak planlamak bütçe açısından daha akıllıca.

Identity: Entra ID olmadan

12 Kasım outage’ının dersi açısından belki de en kritik bölüm bu. Cloud tabanlı Microsoft 365’te identity’nin merkezi Microsoft Entra ID’dir. Disconnected mode’da ise Entra ID yoktur; control plane kurumun mevcut identity altyapısıyla entegre olur. Desteklenen ve doğrulanmış çözümler şunlar:

• Active Directory: group ve group membership’ler için. Yalnızca Universal scope’lu group’lar destekleniyor.
• Active Directory Federation Services (AD FS): authentication için.

Mekanizma şöyle işliyor: OpenID Connect (OIDC) endpoint’i kullanıcıların sign-in yapmasını sağlarken, LDAP endpoint’i kurumdaki group ve membership’leri control plane’e sync eder. Entegrasyon tamamlandıktan sonra bildiğimiz Azure RBAC role’leri istenen scope’lara atanır.

Operator modeli

Deployment sırasında bir root operator belirlenir. Bu kullanıcı, özel bir operator subscription’ın owner’ıdır ve deployment sonrasında diğer operator’leri ekler. Operator’ler bu subscription scope’unda yeni subscription oluşturma, service principal (SPN) yönetimi, sync edilen group’ları görüntüleme, log collection ve syslog forwarding gibi işlemleri yapabilir. Önemli bir ayrıntı: role assignment’lar ve policy’ler operator subscription’dan diğer subscription’lara inherit edilmez; her subscription kendi scope’una sahiptir.

Bilinmesi gereken sınırlamalar

• Sync’ten sonra AD’den silinen user ve group’lar control plane’de otomatik temizlenmez; bu durum group membership sorgularında hatalara yol açabilir.
• Force sync seçeneği yok; ilk sync altı saate kadar sürebilir.
• Management group’lar ve subscription’ların üstünde bir root level bulunmuyor.
• Support kapsamında validate edilen identity provider’lar yalnızca Active Directory ve AD FS.

Cloud outage’larında kullanıcılar çoğu zaman uygulamaya değil, authentication’a takılır. Disconnected mode’da identity zinciri tamamen kurum içindedir: AD ve AD FS ayaktaysa sign-in yapılır. Elbette bu, identity altyapınızın kendisinin high availability ile tasarlanmasını zorunlu kılar; birden fazla domain controller ve bir AD FS farm burada opsiyonel değildir.

Network, DNS ve PKI

Cloud’da görünmez olan pek çok infrastructure servisi, disconnected mode’da sizin sorumluluğunuza geçer. Microsoft’un planlama adımları bunu açıkça yansıtıyor: network requirement’ların yapılandırılması, identity entegrasyonu, security control’leri, PKI ile endpoint’lerin güvenceye alınması ve management cluster donanımının planlanması deployment’tan önce tamamlanması gereken başlıklar.

Pratikte bu şu anlama geliyor. Local portal, ARM ve identity endpoint’leri kurumunuzun kendi Certificate Authority’sinden imzalanmış sertifikalarla publish edilir; LDAP ve OIDC endpoint’lerinin certificate chain bilgileri deployment parametreleri arasında yer alır. LDAP endpoint’i için FQDN kullanılacaksa, disconnected operations appliance’ının bu adı resolve edebilecek bir DNS’e yönlendirilmesi gerekir. Identity entegrasyonu için de AD üzerinde read-only bir LDAP hesabı ve sync’in başlayacağı root group önceden hazırlanmalıdır.

Deployment öncesi toplanması gereken parametrelerin tipik bir örneği şöyle görünüyor:

$idpConfig = @{
  authority                     = 'https://adfs.kurum.local/adfs'
  clientId                      = '<AD FS client app ID>'
  rootOperatorUserPrincipalName = '[email protected]'
  ldapServer                    = 'ldap.kurum.local'
  LdapCredential                = $ldapReadOnlyCredential
  syncGroupIdentifier           = '<root AD group ObjectGUID>'
}

Fully automated deployment’lar için bir automation certificate da tanımlanabiliyor; bu sayede operator olarak login olup subscription oluşturma, resource provider register etme gibi işlemler script’lerle yürütülebiliyor. Infrastructure as Code ile çalışan ekipler için bu önemli bir kolaylık.

Update ve lifecycle yönetimi

Cloud’da update’ler sizin yerinize yapılır; disconnected mode’da ise lifecycle management tamamen operasyon ekibinize aittir. Microsoft burada aylık bir update package sunuyor. Bu paket appliance’ın kendisini, Azure Local yazılımını, AKS’i ve Arc-enabled servis agent’larını kapsıyor ve tüm Azure Local instance’ının internet bağlantısı olmadan local control plane üzerinden update edilmesine imkan veriyor.

Bu modelin doğal bir sonucu var: update döngüleri public cloud’un gerisinde kalır. Cloud’da bir security fix Microsoft tarafından saatler içinde rollout edilebilirken, disconnected ortamda bu fix sizin maintenance window’unuza kadar bekler. Bu nedenle disiplinli bir patch takvimi, test ortamı ve RACI matrisi şart.

Observability tarafında ise ürün, troubleshooting için on-demand ve fallback log collection mekanizmaları sunuyor; operator’ler syslog forwarding’i yapılandırarak log’ları kurumun kendi SIEM’ine aktarabiliyor. Appliance Azure’a geçici olarak bağlanabildiğinde log’ların doğrudan Microsoft Support’a gönderilmesi de mümkün.

Microsoft 365 Local, SQL Server ve Foundry Local

Microsoft 365 Local

Outage tartışmasının merkezindeki workload bu. Microsoft 365 Local, Exchange Server, SharePoint Server ve Skype for Business Server’ı Azure Local üzerinde çalıştırmak için bir deployment framework; Azure Local Premier Solutions üzerine kurulu validated bir reference architecture’a dayanıyor. Microsoft 365 Local Kasım 2025’te connected mode’da GA olmuş, fully disconnected desteği ise 2026’da geldi. Licensing açısından Exchange Server ve SharePoint Server’ın Subscription Edition (SE) sürümleri kullanılıyor. Uzun vadeli planlama için önemli bir taahhüt de var: bu server workload’larının en az 2035’e kadar desteklenmesi.

Security tarafında platform, network’leri izole etmek için SDN ile yönetilen Network Security Group’lardan yararlanıyor ve hem host’lara hem de workload VM’lerine 300’ü aşkın ayardan oluşan bir security baseline default olarak uygulanıyor.

Dürüst olmak gerekirse, Microsoft 365 Local, Microsoft 365 cloud’un on-premises bir kopyası değildir. Teams yerine Skype for Business Server, Exchange Online’ın cloud özellikleri yerine Exchange Server SE, SharePoint Online yerine SharePoint Server SE çalışır. Copilot, Loop, cloud tabanlı Defender ve Intune bu pakette yoktur. User experience bilinçli olarak daha klasik ve daha sınırlıdır.

SQL Server on Azure Local

Microsoft, 28 Eylül 2026’da SQL Server on Azure Local’ın connected ve disconnected operations için GA olduğunu duyurdu. SQL Server, Azure Local üzerindeki Windows Server veya Linux VM’lerinde çalışıyor ve Azure Local’dan ayrı lisanslanıyor. Microsoft’un resiliency guidance’ı, host protection’ın database-native high availability ve disaster recovery mekanizmalarıyla birleştirilmesini, düzenli backup ve restore testlerini öneriyor.

Foundry Local

Copilot’un olmadığı bir ortamda AI ihtiyacı nasıl karşılanacak? Microsoft’un cevabı Foundry Local. Uygun müşteriler multimodal LLM’leri kendi on-premises, private cloud ortamlarında çalıştırabiliyor; inference ve API’ler tamamen müşterinin kontrolündeki boundary içinde kalıyor. Ancak Foundry Local on Azure Local için bazı kaynaklar hâlâ preview durumunu ve request-based erişimi işaret ediyor; kurumsal planlamada güncel durumu hesap ekibinizle teyit etmeniz yerinde olur.

Eligibility ve onboarding süreci

Disconnected operations herkesin bir tıkla açabileceği bir özellik değil. Microsoft net eligibility criteria uyguluyor:

Criteria	Açıklama
Eligible agreement	Microsoft ile uygun bir agreement gerekir; Microsoft Online Subscription Program (MOSA) uygun değildir.
Support plan	Microsoft ile Standard veya üzeri aktif support plan ya da aktif support plan’ı olan bir partner.
Business need	Connectivity sorunları veya regülasyon kısıtları nedeniyle Azure’a bağlanamama; geçerli bir disconnected çalışma ihtiyacı.
Operational & technical prerequisites	Deployment ve operasyonu yapabilecek personel ya da bunu sizin adınıza yapacak bir partner; workload ve uygulama requirement’larının belirlenmiş olması.
Hardware	Premier Solutions for Azure Local; kendi donanımınız ve dedicated bir management cluster.

Senaryo: iki dünyada 12 Kasım akşamı

Şimdi düşünce deneyimine geçelim. Elimizde 3.000 çalışanlı, Türkiye’de faaliyet gösteren bir kurum var; bir hastane grubu, bir enerji şirketi ya da bir kamu kurumu olabilir.

Birinci dünyada kurum tamamen Microsoft 365 cloud’u kullanıyor. İkinci dünyada ise kritik iletişim ve içerik workload’ları Azure Local disconnected üzerinde Microsoft 365 Local ile çalışıyor.

Dünya A: Cloud-only saat 19:17’den itibaren ekip vardiya devrini e-postayla yapamıyor outlook bağlanamıyor, mobile app de yanıt vermiyor. Kriz toplantısı Teams’te açılamıyor yöneticiler kişisel whatsApp grubuna geçiyor prosedür dokümanları SharePoint’te kilitli Local cache’i olmayanlar erişemiyor SOC ekibi Defender XDR’da blind spot’ta safe links verification zayıflamış durumda IT ekibi yalnızca bekleyebiliyor müdahale imkanı yok, Microsoft’un status update’ini izliyor.

Dünya B: Azure Local disconnected aynı saat, aynı global incidentKurum içi e-posta akmaya devam ediyor Exchange Server SE on-prem, identity AD/AD FS üzerindeIM ve voice çalışıyor. Skype for Business Server; Teams kadar zengin değil dokümanlar SharePoint Server SE’de erişilebilir data kurum boundary’si içinde management plane bağımsız local portal, policy ve key vault etkilenmez ama: copilot yok, cloud security araçları yok local security monitoring ve SIEM sizin sorumluluğunuzda

Aynı global incident, iki farklı mimari. Dünya B’nin kazancı business continuity; bedeli ise daha sınırlı feature set ve tamamen kurum içine geçen operasyon yükü.

Tablonun en sağdaki sütunu sadece yeşil değil; bu bilinçli. Dünya B’de 12 Kasım akşamı sakin geçerdi. Ama aynı kurumun başka bir akşamı, örneğin kendi datacenter’ında bir storage controller’ın arızalandığı bir gece, Dünya A’da hiç fark edilmezken Dünya B’de bir kriz olabilirdi. Disconnected, riski ortadan kaldırmaz; riskin sahibini ve türünü değiştirir.

Disconnected’ın bedeli

Sorumluluk yer değiştirir

Cloud’da Microsoft’un server’ları çöktü; on-prem’de kendi server’larınız, storage’ınız, enerji ve soğutma altyapınız çökebilir. Patch management, backup, disaster recovery ve capacity planning ekibinizin işidir. Bir analizde de vurgulandığı gibi, bağlantısız bir site için asıl test, yöneticilerin sistemi yalnızca o ortamın içindeki kaynaklarla işletip kurtarabilmesidir.

Disaster recovery’yi yeniden düşünmek gerekir

Connected mode’da Azure Site Recovery gibi cloud tabanlı recovery seçenekleri vardır. Fully disconnected bir ortamda ise recovery, uygulamaların kendi native mekanizmalarıyla ve bir secondary site ile tasarlanmalıdır: Exchange için Database Availability Group (DAG), SQL Server için Always On Availability Groups, SharePoint için farm seviyesinde redundancy ve düzenli restore testleri. Tek bir datacenter’daki disconnected kurulum, cloud outage’ına karşı korur ama kendi tesisinizdeki bir felakete karşı korumaz.

Maliyet ve donanım

Yalnızca control plane için üç ayrı physical node, üstüne workload cluster’ları, secondary site ve Premier Solutions donanım kategorisi. Ek olarak SQL Server gibi workload’lar ayrıca lisanslanır. TCO, subscription tabanlı cloud modelinden belirgin biçimde farklı bir profil çizer.

İnsan kaynağı

Azure Local, AD/AD FS, PKI, Exchange, SharePoint, Kubernetes ve security monitoring konularında derinlik gerektiren bir ekip ya da güvenilir bir partner şart. Microsoft’un eligibility criteria’sında bu yetkinliği açıkça araması tesadüf değil.

Feature ve hız farkı

Disconnected ortam bilinçli olarak public cloud’un gerisinden gelir. Yeni feature’lar, AI entegrasyonları ve security iyileştirmeleri cloud’a önce gelir; on-prem ortama ya geç gelir ya da hiç gelmez.

Asıl ders: hybrid tasarım

Bu outage’dan çıkarılacak en sağlıklı sonuç, herkesin bağlantısız bir ortama geçmesi gerektiği değil. Asıl ders: workload’ları criticality seviyesine göre sınıflandırmak ve single point of failure’a bağımlılığı bilinçli olarak yönetmek. Azure Local’ın değeri de tam burada: aynı platform, aynı ARM/RBAC/Policy dili ile workload bazında connected ya da disconnected kararı verebilmek.

Tier 2 için bile yapılabilecekler

Tamamen cloud’da kalan kurumlar için de 12 Kasım’ın öğrettiği somut adımlar var. Microsoft 365’e bağımlı olmayan bir emergency communication kanalı (örneğin farklı bir provider’da host edilen bir notification sistemi veya yöneticiler için ayrı bir messaging çözümü), kritik prosedür dokümanlarının offline erişilebilir kopyaları, outage senaryosunu içeren bir BCP tatbikatı ve outage sırasında security ekibinin hangi alternatif telemetry kaynaklarına bakacağının önceden belirlenmesi bunların başında geliyor.

Türkiye perspektifi

Türkiye’de faaliyet gösteren kurumlar için bu tartışmanın bir de düzenleyici boyutu var. Kişisel verilerin korunması mevzuatı yurt dışına veri aktarımına özel şartlar getiriyor; kamu kurumları Bilgi ve İletişim Güvenliği Rehberi kapsamında kritik verilerin yurt içinde tutulmasına yönelik beklentilerle çalışıyor; bankacılık gibi sektörlerde de birincil ve ikincil bilgi sistemlerinin konumuna ilişkin özel düzenlemeler bulunuyor. Bu kurumlar için Azure Local disconnected, “sovereignty mi, modern management mı?” ikileminde ikisini birlikte sunan nadir seçeneklerden biri. Kendi yükümlülüklerinizi değerlendirirken hukuk ve uyum ekiplerinizden görüş almayı unutmayın.

Bir sonraki outage’a hazırlık checklist’i

• Dependency envanteri çıkarın. Hangi iş süreci hangi cloud servisine, hangi identity provider’a ve hangi security aracına bağlı? 12 Kasım’da etkilenen her servisi kendi süreçlerinizle eşleştirin.
  
• Workload’ları tier’lara ayırın. Tier 0 var mı? Varsa, bu workload’lar için RTO ve RPO değerleri tanımlı mı?
  
• Emergency communication kanalı kurun. Ana platformunuzdan bağımsız, düzenli test edilen bir kanal.
  
• Break-glass hesaplarını gözden geçirin. Cloud identity servisi erişilemezken kritik sistemlere nasıl girileceği belgelenmiş mi?
  
• Security visibility için yedek planlayın. Defender XDR erişilemezken hangi telemetry kaynaklarına bakılacak?
  
• Tier 0 için Azure Local seçeneklerini değerlendirin. Eligibility criteria’yı, hardware requirement’ları ve ekip yetkinliğini account team’iniz ve partner’ınızla birlikte inceleyin; POC’yi production’a dönüşebilecek donanımla planlayın.
  
• Identity altyapınızı güçlendirin. Disconnected bir gelecek düşünüyorsanız AD ve AD FS’in high availability’si, Universal group yapısı ve PKI olgunluğu bugünden ele alınmalı.
  
• Tatbikat yapın. Bir öğleden sonra boyunca Microsoft 365 outage’ını simüle etmeyi deneyin. Kağıt üzerindeki planla gerçek davranış arasındaki fark genellikle şaşırtıcıdır.

12–13 Kasım outage’ı cloud’un kötü olduğunu göstermedi. Gösterdiği şey, dependency’nin görünmez hale geldiğiydi. Pek çok kurum e-postasının, dosyalarının, security console’unun ve device management’ının aynı anda aynı altyapıya bağlı olduğunu ancak hepsi birden durduğunda fark etti.

Azure Local disconnected operations, bu dependency’yi kırmak isteyen kurumlar için artık gerçek, dokümante edilmiş ve desteklenen bir seçenek: local control plane, tanıdık Azure management deneyimi, on-prem identity, aylık offline update’ler ve üzerinde Microsoft 365 Local, SQL Server ve local AI. Ama bedeli de gerçek: dedicated donanım, derin yetkinlik gerektiren operasyon, daha sınırlı feature set ve tamamen size geçen sorumluluk.

Doğru cevap çoğu kurum için “her şeyi on-prem’e çekmek” değil; hangi workload’un nerede çalışacağına bilinçli karar vermek, kritik süreçler için bağımsız bir çalışma alanı tasarlamak ve bunu düzenli olarak test etmek. Bir sonraki outage geldiğinde sorulması gereken soru “Microsoft ne zaman düzeltecek?” değil, “Biz bu süre zarfında nasıl çalışmaya devam ediyoruz?” olmalı.

Hybrid mimari bir uzlaşma değil, bir tasarım kararıdır: Cloud’un hızını, on-prem’in bağımsızlığıyla aynı governance dili altında birleştirmek.