Bir gateway’in request timeout değeri 20 saniyeden 60 saniyeye çıkmış. Aynı dönemde booking servisinde gecikme şikâyeti var. Bu iki bilgi aynı incelemenin parçası, ama henüz “buna sebep oldu” diye tek cümlede birleştirilecek kadar değil. Microsoft’un Mission Critical blogundaki yazı tam olarak bu ayrımı korumayı anlatıyor.
Azure; Azure Monitor, Activity Log ve Azure Resource Graph üzerinden zaten bol miktarda kanıt sunuyor. Sorun, workload ölçeğinde bu kanıtı kaynaklar, kimlikler ve zaman arasında ilişkilendirirken gözlem ile yorum arasındaki sınırı kaybetmemek. Azure Support Agent bu noktada birbirine bağlı ama ayrı üç araç ekliyor: Change Explorer, Evidence Locker ve Case Files.
Yazı, kurgusal bir Contoso Booking incelemesi üzerinden ilerliyor. Amaç kök nedeni bulmak değil; soruyu daraltmak, kanıtı saklamak ve bir sonraki kararı açıkça yazmak. Görsellerdeki tüm kayıtlar sentetik ve backend, Azure ya da AI çağrısı olmadan tarayıcı içi fixture’larla çekilmiş.
Hükümle değil, hipotezle başla
Timeout’un uzatılması gecikmenin sebebi olabilir, ama var olan bir sorunun ardından yapılmış bir müdahale de olabilir. Daha uzun bir timeout, bir isteğin ne kadar bekleyebileceğini değiştirir; isteklerin gerçekte ne kadar sürdüğünü ölçmez. Hangi bileşenin yavaş olduğunu ya da ayarın neden değiştirildiğini de söylemez.
Bu yüzden önerilen başlangıç cümlesi şöyle: “Gateway request timeout değeri inceleme penceresinde arttı. Bildirilen gecikmeyle ilişkisi henüz doğrulanmadı.” Yeni kanıt geldiğinde de ayakta kalabilen bir cümle bu.
Üç aracın rolleri farklı. Change Explorer, değişiklik aktivitesinin sınırları belli bir analizini kaydediyor; attribution, property farkları ve inceleyici notlarıyla birlikte. Evidence Locker seçilen içeriğin belirli bir andaki paketini saklıyor. Case Files ise sorular, kararlar, referanslar ve takip işleri için süren kaydı tutuyor. Bir Change Explorer run’ı otomatik olarak Evidence Locker snapshot’ı değil, içindeki gömülü case dosyası da ayrı bir Case Files kaydı değil.
Pencereye kaynak ve sınır ver
Change Explorer’da workload ya da subscription, bağlantı ve net bir başlangıç-bitiş zamanı seçerek başlıyorsunuz. Kayıtlı bir run’ı yeniden açtığınızda seçicileri oynatmak veriyi yeniden toplamaz. Arayüz kayıtlı pencerenin mevcut seçimden farklı olduğunu söylüyorsa, ya o tarihi analizi yükleyin ya da istediğiniz pencereyi baştan analiz edin. Eski bir sonuca sessizce yeni bir anlam yüklememek gerekiyor.
Release kaydı, kaynak olaylar ve uygulama telemetrisi karşılaştırılırken mutlak zaman damgaları ve saat dilimi kaydedilmeli. Scope etiketleri de göründüğünden dar ya da farklı çalışıyor: “Workload + dependencies” gerçek bir bağımlılık grafiğini gezmiyor, sadece kaynakları içeren resource group’lara genişliyor. “Tenant-wide” ise yalnızca çözümlenmiş subscription’ları kapsıyor.
Kaynak diagnostiklerini de sonuçla birlikte okumak gerekiyor. Yazıda geçen bazı limitler önemli:
- Activity Log yalnızca ilk 25 çözümlenmiş subscription’ı ve Succeeded ya da Accepted işlemleri topluyor; başarısız denemeler sonuçta yok.
- Birleşik run en fazla 5.000 olay tutuyor ve bunlar tüm kaynaklardaki en yeni 5.000 olay olmak zorunda değil.
- Resource Graph değişiklikleri mevcut kaynaklarla join edildiği için silinmiş kaynaklar görünmeyebilir.
- İki kaynak da eventually consistent; kısa bir sonuç “hiçbir şey olmadı” anlamına gelmiyor.
Olay gerçekte neyi gösteriyor
Summary ve Risk Insights dikkati gateway olayına çekebilir, Operations ilgili aktiviteleri gruplayabilir. Ama bir operation grubu tek ve yetkili bir işlem demek değil. Correlation ID varsa olaylar arasındaki ilişkiyi destekleyebilir; yoksa gruplama sadece aynı aktör ve yakın zaman aralığına dayanıyor olabilir.
Yazıda dikkat çeken bir uyarı var: “Perform AI analysis” kutusu varsayılan olarak kapalı, ama AI analizi yapılmamış bir run’da bir değişikliği açmak yine de enrichment başlatıyor. Yani kutunun kapalı olması sonradan bir provider çağrısı yapılmayacağını garanti etmiyor. AI kullanımının onaylı olmadığı ortamlarda bu etkileşimden kaçınmak gerekiyor.
Actor çözümlemesi best-effort çalışıyor. Microsoft Graph erişimi yoksa bir kimlik çözümlenmemiş kalabilir, bu da aktivitenin anonim olduğu anlamına gelmez. Tersine, okunaklı bir görünen ad da pipeline’ı hangi insanın onayladığını ya da neden çalıştığını kanıtlamaz. Risk ve güvenlik etiketleri önceliklendirmeye yardım eden türetilmiş değerlendirmeler; kötü niyetin kanıtı değil. Mesai dışı aktivite planlı bir release olabilir.
Technical diff soruyu daraltır
Hikâyenin merkezi technical diff: önce ve sonra değerleri timeout’un 20’den 60 saniyeye çıktığını gösteriyor. Bu, “gateway güncellendi” demekten çok daha faydalı, çünkü servis sahibinin açıklayabileceği ve test edebileceği somut bir karar.
Yine de birkaç sınır var. Önceki değerin olmaması, önceki yapılandırmanın şimdikiyle aynı olduğunu kanıtlamaz. Collector her Resource Graph satırında en fazla 40 property tutuyor ve string değerler 1.500 karakterde kesilebiliyor. “Raw” içerik de Azure’un dokunulmamış yanıtı değil, collector’ın sakladığı payload. Dependency Impact önerileri gerçek bir runtime grafiğinden değil, kaynak türü ve adından türetilen heuristic’lerden geliyor.
Drawer’daki “Diff & revert” etiketi de geri alma işlemi yapmıyor; ipuçları sadece kopyalanabilir metin. Timeout’u eski değerine döndürmek, onaylı değişiklik süreci içinde verilecek yeni bir operasyonel karar.
İki run’ı karşılaştırmak
İki kayıtlı Change Explorer run’ını karşılaştırarak bir baseline release penceresiyle timeout güncellemesinin olduğu pencereyi kıyaslayabilirsiniz. Önce iki run’ın scope’unu, süresini, kaynak durumunu ve limitlerini kontrol etmek gerekiyor; daha geniş bir subscription seçimi davranışta değişiklik olmadan büyük bir fark gösterebilir.
Karşılaştırmadaki Added ve Removed, run’ların olay setlerindeki üyeliği ifade ediyor. Bir gateway’in sadece sonraki run’da görünmesi fiziksel olarak oluşturulduğunu kanıtlamaz; olay setinden kaybolması da silindiğini göstermez. “Changed in both” ise iki pencerede de olay olduğunu söylüyor, aynı property’nin iki kez değiştiğini ya da bir değişikliğin geri alındığını değil.
Paylaşım için “Copy link” sadece olay referansını içeriyor, kayıtlı run ve scope bilgisini değil. Bu yüzden run ID, event ID, pencere ve scope’u birlikte kaydetmek gerekiyor.
Evidence Locker ile amaçlı snapshot
Soru daraldıktan sonra Evidence Locker seçili materyali saklamak için devreye giriyor. Amaç her bölümü yakalamak değil, incelemeyi yeniden kurmak için gereken kanıtı tutmak. “Booking gateway configuration review” adlı bir snapshot, “full incident evidence” adlı bir snapshot’tan çok daha net bir niyet anlatıyor.
Capture, Azure kaynaklarını değiştirmiyor ama uygulama tarafında kanıt oluşturuyor. Bazı limitler yine önemli: inventory en fazla 1.000 kaynak tutuyor ve bu yolda workload hariç tutmaları uygulanmıyor. Recent changes son 14 günden en fazla 200 değişiklik tutabiliyor, ancak sorgu workload ya da kaynak filtresi uygulamıyor; yani içindeki her değişiklik Booking ile ilgili olmayabilir. Findings yeni bir assessment başlatmıyor, son başarılı assessment’lardan geliyor. Key metrics seçimi şu an boş bir koleksiyon ve açıklama notu üretiyor; yani gecikme kanıtı buradan gelmiyor.
Yanlış scope ya da eksik ön koşul varsa mevcut snapshot’ın yenilenmesini beklemek yerine düzeltilmiş yeni bir snapshot almak gerekiyor. Saklamanın değeri zaten yakalanan şeyi, limitleriyle birlikte sabitlemesinden geliyor.
Digest bir tutarlılık kontrolü, gerçeklik belgesi değil
Evidence Locker, snapshot içeriği için bir SHA-256 digest kaydediyor ve detay açıldığında ya da export istendiğinde bu digest’i kontrol ediyor. Ancak içerik sekmesi, diff ve paylaşılan içerik istekleri bu kontrolü bağımsız olarak yapmıyor; her okumanın kriptografik olarak doğrulandığını söylemek yanlış olur. JSON export metadata, içerik ve sha_verified alanını içeriyor; bu bir ZIP paketi ya da import-replay akışı değil.
En önemli nokta: tutarlılık, kaynağın doğru olduğu anlamına gelmiyor. Tutarlı bir snapshot eksik bir sonucu, scope dışı bir kaynağı ya da eski bulguları da aynı tutarlılıkla saklayabilir. Digest tamlığı, nedenselliği ya da hukuki geçerliliği olan bir chain of custody’yi kanıtlamaz. Doğrulama başarısız olursa paket bir kenara bırakılmalı ve yetkili kaynaklardan yeni bir snapshot alınmalı.
Snapshot karşılaştırması
Evidence karşılaştırması, iki snapshot’taki inventory ve findings verisini kıyaslıyor. Önce baseline, sonra sonraki snapshot seçilip “Diff selected” kullanılıyor; karşılaştırma başlığındaki yönü kontrol etmek gerekiyor, çünkü üçüncü bir snapshot seçildiğinde son iki seçim tutuluyor.
Karşılaştırmaya sadece inventory ve findings giriyor. Boş bir diff; memory, activity ya da architecture hakkında bir şey söylemiyor ve kesinlikle gecikmenin değişmediği anlamına gelmiyor. Konfigürasyon karşılaştırması bir performans testine dönüşmüyor.
Gerekçeyi ayrı bir case’te tut
Case Files, incelemeye belirli bir run ya da sohbetten bağımsız kalıcı bir anlatı sağlıyor. Oluşturma formu sadece başlık ve severity istiyor; ilk not bildirilen etkiyi, bilinenleri, bilinmeyenleri, sorumlu kişiyi ve doğrulama kriterlerini anlatmalı. Booking için ilk not, gözlenen timeout farkını doğrulanmamış gecikme ilişkisinden ayırmalı.
İlişkilendirme otomatik değil. Change Explorer notları kendi run’ında kalıyor. Evidence Locker’daki “Attach to RCA” sadece snapshot metadata’sına bir işaret ekliyor, belirli bir case’i güncellemiyor. Kanıtı case’e bağlamak için snapshot ve event ID’lerini bir nota yazmak ya da yetkili bir Case Files entegrasyonu kullanmak gerekiyor.
Status değerleri (open, investigating, remediating, verifying, resolved, closed) işi organize ediyor ama işi yapmıyor. Backend, çözüme geçmeden önce doğrulama kanıtı istemiyor; yani “resolved” bir case kayıtlı bir karar, doğrulanmış bir sonuç değil. Timeline append-only olduğu için yanlış bir ifade silinmek yerine yeni bir notla düzeltilmeli.
Paylaşırken maruziyeti genişletme
Yazının son bölümü handoff ve paylaşımla ilgili, ve operasyonel açıdan belki en önemli kısım:
- Change Explorer export’ları kayıtlı run’ı okuyor, ekrandaki filtreleri değil. Filtrelenmiş bir görünüm export’u sadece gateway’e indirmiyor.
- Her workload ya da subscription için en fazla 30 aktif run tutuluyor; eskiler Trash’e taşınmadan silinebiliyor.
- Paylaşım token’ları çağıranın tenant’ına bağlı değil, UI’da iptal kontrolü yok ve Trash geçerli bir token’ı geçersiz kılmıyor.
- “Attach to ticket” connector seçildiği anda metadata ve SHA içeren yeni bir ticket oluşturuyor.
- Standard ve audit etiketleri zorunlu bir silme takvimi ya da legal hold değil. Case Files’taki Delete case’i gizliyor ama backend’de tutuyor.
- changeexplorer.read, evidence.write ve cases.write izinleri ayrı düşünülmeli; “read-only Azure incelemesi” hiçbir şeyin saklanmadığı anlamına gelmiyor.
Handoff öncesinde bir sonraki inceleyiciyi, inceleme zamanını ve o noktada beklenen kanıtı yazmak; inceleme talebi ile onaylı bir konfigürasyon değişikliği talebini ayırmak öneriliyor.
İnceleme nasıl değerlendirilmeli
Ölçüt şu: başka bir operatör, bir AI özetine, risk etiketine ya da case durumuna güvenmek zorunda kalmadan kanıtı bulup kararı anlayabiliyor mu? Değişiklik tanımlanabilir olmalı, kanıtın sınırları görünür olmalı, saklanan materyal incelenebilir olmalı ve gerekçe test edilebilir kalmalı. Booking örneğinde timeout değişikliği tek bir gözlem; nedensellik hipotezi için başka kanıt gerekiyor ve neyin onu destekleyeceği, neyin çürüteceği açıkça yazılmalı.
Yazı aslında bir ürün tanıtımından çok bir inceleme disiplini rehberi. Azure Support Agent araçlarının nerede durduğunu, hangi limitlerle çalıştığını dürüstçe anlatması değerli; özellikle kapalı AI kutusunun yine de enrichment tetikleyebilmesi, paylaşım token’larının tenant’a bağlı olmaması ve iptal edilememesi gibi detaylar üretime almadan önce bilinmesi gereken şeyler. Pratik öneri basit: onaylı bir ortamda tek bir bilinen değişiklik ve dar bir pencereyle başlayın, kaydı oluşturun ve bir meslektaşınızdan sizin tarayıcı oturumunuz olmadan bu kaydı yeniden kurmasını isteyin.
