Mimari ve çalışma modeli
Free/busy paylaşımı, toplantı ayrıntısını taşımadan belirli zaman aralıklarının uygunluk durumunu sorgular. Aynı tenant içi izin, dış organizasyon paylaşımı ve geçiş dönemindeki Google Workspace–Microsoft 365 birlikte çalışabilirliği farklı akışlardır. Arızayı kullanıcı arayüzü yerine kaynak tenant, hedef tenant, kullanıcı eşleme ve sorgu yönüyle tanımlamak gerekir.
Microsoft 365 tarafında organization relationship, sharing policy ve federation/availability uçları; Google Workspace tarafında Calendar Interop yapılandırması, servis hesabı/yetkilendirme ve kullanıcı eşleme etkili olabilir. DNS Autodiscover, TLS güveni ve proxy erişimi bazı hibrit akışların ön koşuludur. Bir yönde çalışan görünürlük diğer yönün doğru olduğunu kanıtlamaz.
Gizlilik sınırı önemlidir: yalnız free/busy izni, konu/konum/katılımcı ayrıntılarını vermemelidir. Teşhis hesapları en az yetkiyle kullanılmalı, takvim verisi loglara tam içerikle yazılmamalıdır. Sonuçları kaynak kullanıcı × hedef kullanıcı × yön × zaman aralığı matrisiyle kaydetmek rastgele kullanıcı testlerinden daha güvenilir kanıt üretir.
- 1Kaynak kullanıcı ve paylaşım politikası
- 2Organizasyonlar arası availability sorgusu
- 3Hedef kullanıcı eşleme ve takvim okuma
- 4Free/busy yanıtı ve gizlilik filtresi
Tasarım parametreleri
- Paylaşım kapsamı
- Yalnız uygunluk, sınırlı ayrıntı veya tam ayrıntı seviyesini politika ve kullanıcı izniyle eşleyin.
- Kimlik eşleme
- Birincil adres, alias, accepted domain ve geçişteki hedef hesabı açıkça doğrulayın.
- Sorgu yönü
- Workspace→M365 ve M365→Workspace akışlarını bağımsız kabul testleri olarak ele alın.
- Zaman penceresi
- Çok uzun aralık, çok sayıda öğe ve saat dilimi davranışını kontrollü örneklerle sınayın.
Platformlardaki uygulama karşılıkları
Servis adları teknik karşılıklardır. Kapsam, varsayılanlar, bölge kullanılabilirliği ve işletim koşulları farklıdır; birebir aynı garanti anlamına gelmez.
| Katman | Google Workspace | Microsoft 365 |
|---|---|---|
| Organizasyon ayarı | Calendar Interop ve paylaşım ayarları | Organization relationship ve sharing policy |
| Kimlik/erişim | Yetkilendirilmiş servis hesabı ve kullanıcı eşleme | Federation/availability erişimi ve kabul edilen domain |
| İlk kanıt | Admin ayarı, interop logu ve test kullanıcı sonucu | Get-OrganizationRelationship ve availability testi |
Hesap ve uygulama örneği
Geçişte 2.000 kullanıcının 1.600'ü M365, 400'ü Workspace'te kalmışsa en az dört test hücresi gerekir: her platform içinde ve iki çapraz yön. Her hücre için aynı 7 günlük aralıkta bilinen iki meşgul blok ve bir boş blok kullanın; sonuçları adres alias'ı ve saat dilimiyle kaydedin.
Yalnız 90 günlük sorgular başarısız, 7 günlük sorgular başarılıysa kimlik doğrulamayı değiştirmeden pencere ve öğe hacmini inceleyin. 1.000 öğe sınırı gibi istemci/servis kısıtlarıyla aşırı yoğun takvimleri normal takvimlerden ayırın.
Örnek komutlar: laboratuvar değerlerini değiştirin; kullanmadan önce yetkiyi ve yazılım sürümünü doğrulayın.
# Exchange Online PowerShell
Get-OrganizationRelationship | Format-List Name,DomainNames,FreeBusyAccessEnabled,FreeBusyAccessLevel
Get-SharingPolicy | Format-List Name,Domains,Enabled
Get-AcceptedDomain | Format-Table Name,DomainName,DomainType
# Sonuçları iki yönlü test matrisiyle kaydedin; gerçek takvim içeriğini loglamayın.Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Bir yön çalışıyor, diğeri çalışmıyor | Karşılıklı ilişki veya Calendar Interop yönlerinden biri eksik olabilir. | Aynı kullanıcı çiftiyle iki yönü ayrı sorgulayıp organizasyon ayarlarını karşılaştırın. |
| Bazı kullanıcılar unknown görünüyor | Alias, accepted domain veya geçiş hedefi yanlış eşlenmiş olabilir. | Birincil SMTP adresi, alias ve gerçek posta kutusu/takvim konumunu doğrulayın. |
| Kısa aralık çalışıyor, uzun aralık hata veriyor | Öğe hacmi, servis sınırı veya istemci timeout'u etkili olabilir. | Aynı kullanıcıda 7, 30 ve 90 günlük sorguları süre ve hata koduyla karşılaştırın. |
Kabul ve doğrulama kontrolleri
- İki sorgu yönü için ayrı test matrisi oluşturun.
- Paylaşımın yalnız onaylanan ayrıntı seviyesini döndürdüğünü doğrulayın.
- Birincil adres ve alias eşlemesini her pilot kullanıcıda kontrol edin.
- Organization relationship ve Calendar Interop ayarlarını dışa aktarın.
- DNS/TLS/proxy yolunu hibrit uçlar için doğrulayın.
- 7, 30 ve 90 günlük sorgularda başarı oranı ve p95 süreyi kaydedin.
İlgili kavramlar
Kimlik doğrulama ve oturum
Kimlik doğrulama kullanıcının veya iş yükünün kim olduğunu kanıtlar; yetkilendirme ise bu kimliğin ne yapabileceğini belirler. Başarılı oturum açma, bütün kaynaklara erişim izni anlamına gelmez. Kullanıcı oturumları, servis kimlikleri, API belirteçleri ve cihaz sertifikaları farklı yaşam döngülerine sahiptir. İlk giriş kadar oturum süresi, belirteç yenileme, işten ayrılma, kayıp cihaz ve acil erişim senaryolarını da tasarlayın. Kimlik sağlayıcı erişilemez olduğunda hangi oturumların süreceğini ve hangi yeni erişimlerin engelleneceğini ölçün.
Dosya izinleri ve servis kimliği
Dosya erişimi kullanıcı/grup, izin bitleri, ACL ve güvenlik politikalarının birleşimine bağlıdır. Bir uygulamanın root olarak çalışması izin sorununu gizleyebilir; üretim için gerekçeli ve sınırlı servis kimliği tercih edilir. Dizin üzerinde arama/geçiş izni ile dosya okuma izni farklıdır. Paylaşım katmanında verilen izin, dosya sistemindeki kısıtı her zaman aşmaz. Hata araştırmasında uygulamanın gerçekten hangi kullanıcıyla çalıştığını, dizin zincirini ve ACL’leri inceleyin. İzinleri topluca açmak yerine gereken erişimi dar kapsamda test edin.
DNS önbelleği ve bağımlılık
DNS cevabı yalnız kaydın authoritative sunucudaki değerine bağlı değildir; istemci ve recursive resolver önbellekleri de sonucu etkiler. TTL değişikliği daha önce önbelleğe alınmış yanıtların ömrünü geriye dönük kısaltmaz. A/AAAA, CNAME, MX ve TXT kayıtları farklı işlevlere sahiptir. İç ve dış görünümü ayrı test edin; split DNS nedeniyle cevapların farklı olması tasarlanmış olabilir. Arıza araştırmasında kullanılan resolver, yanıt türü, TTL ve sorgu zamanını kaydedin. IP ile erişimin çalışması tek başına DNS yapılandırmasının doğru olduğunu göstermez.
TLS ve sertifika doğrulaması
TLS iletişimin gizliliğini ve bütünlüğünü sağlar; sertifika doğrulaması karşı taraf kimliğinin kontrolüne yardımcı olur. Sertifika adı, zincir, geçerlilik süresi ve güvenilen kökler birlikte değerlendirilmelidir. Bir bağlantının şifreli olması uygulamanın yetkilendirmesinin doğru olduğu anlamına gelmez. Reverse proxy veya inspection kullanılıyorsa TLS oturumunun hangi noktada sonlandırıldığını çizimde açıkça gösterin. Hata teşhisinde sertifika kontrolünü kapatmak kalıcı çözüm değildir; yanlış hostname, eksik ara sertifika ve cihaz saatini ayrı inceleyin.
Telemetri ve zaman eşleştirmesi
Telemetri, sistemin ne yaptığını açıklayan log, metrik ve olay kayıtlarının bütünüdür. Log bir olayın ayrıntısını, metrik zaman içindeki davranışı, dağıtık iz ise isteğin bileşenler arasındaki yolunu gösterir. Saat farkları aynı olayı farklı zamanlarda olmuş gibi gösterebilir. Merkezi zaman senkronizasyonu, kaynak kimliği ve tutarlı saat dilimi kullanın. Alarm tasarımında yalnız eşik değil, ne kadar sürdüğü ve kullanıcıya etkisi de değerlendirilmelidir. Kayıtların kesildiği durum ayrıca izlenmeli; günlük kaydı bulunmaması, olay yaşanmadığı şeklinde yorumlanmamalıdır.
Yüksek erişilebilirlik ile kurtarma ayrımı
Yüksek erişilebilirlik, belirli arızalarda hizmetin kısa kesintiyle sürmesini hedefler; yedekleme, kaybolan veya bozulan veriyi önceki bir noktadan geri getirir. Bir küme yanlış silinen kaydı diğer düğüme de aktarabilir. Bu nedenle HA ve yedekleme birbirinin yerine geçmez. Hizmetin DNS, kimlik, ağ, depolama ve enerji bağımlılıklarını birlikte düşünün. Başarılı düğüm geçişi tek başına yeterli değildir: kullanıcı oturumunun, uygulama yazmasının ve dış entegrasyonların geçiş sonrası davranışı da ölçülmelidir.
Birincil teknik dokümantasyon
Doz Teknoloji teknik ekibi tarafından aşağıdaki birincil kaynaklar temel alınarak hazırlanmıştır. Hesaplar ve laboratuvar senaryoları varsayımlarını belirtir; uygulamadan önce kullanılan ürün sürümünü doğrulayın.