Mimari ve çalışma modeli
Toplantı odası rezervasyonu, görünen takvim etkinliğinden daha fazla bileşen içerir. Kaynak dizinde doğru bina, kapasite ve adresle yayımlanır; kullanıcının kaynağı bulma izni vardır; booking policy isteği otomatik kabul eder, reddeder veya delegelere yollar. Sorun teşhisi keşif, yetki, uygunluk ve işleme kararını ayrı incelemelidir.
Google Workspace'te oda ve kaynaklar Admin Console'da yönetilir; kullanıcı etkinliğe odaları kaynak olarak ekler. Microsoft 365'te room mailbox ve room list yapıları kullanılır; CalendarProcessing kuralları otomatik kabul, delegasyon, booking window ve maksimum süreyi belirler. Platformlar aynı amacı farklı nesnelerle uygular. Bir kullanıcı takvimini oda gibi paylaşmak, kaynak yaşam döngüsü ve politika yönetimini zorlaştırır.
Çift rezervasyon şikâyetinde önce iki isteğin aynı kaynak kimliğine gidip gitmediğini kontrol edin. Yeniden adlandırılmış odalar, eski alias, yinelenen kaynak ve senkronize olmayan mobil istemci farklı takvimleri gösteriyor olabilir. Reddin nedeni doluluk, yinelenen etkinlik, booking window, süre, çalışma saati, dış kullanıcı veya delegate policy olabilir. Kullanıcı ekran görüntüsü yerine işlem zamanları ve organizer/resource kimlikleri toplanmalıdır.
Düzeltmeden önce test hesabıyla tek seferlik 30 dakikalık basit toplantı oluşturun. Odanın dizinde bulunduğunu, isteğin kaynak takvimine ulaştığını ve kabul/ret yanıtını doğrulayın. Ardından recurrence, dış organizer ve kapasite gibi boyutları tek tek ekleyin. Geniş paylaşım yetkisi vermek yerine booking policy ve doğru resource delegation ayarlanmalıdır.
- 1Kullanıcı ve kaynak keşfi
- 2Toplantı isteği ve kaynak kimliği
- 3Booking policy veya delegate kararı
- 4Kabul/ret yanıtı ve takvim görünümü
Tasarım parametreleri
- Kaynak kimliği
- Oda adı, benzersiz e-posta/kimlik, bina ve eski alias kayıtlarını merkezi envanterde tutun.
- Rezervasyon penceresi
- İleri tarih sınırı, maksimum süre, recurrence ve çalışma saati kurallarını kullanıcıya görünür yapın.
- Onay modeli
- Otomatik kabul, kapsamlı kullanıcı grubu veya delegate onayını tek kaynak için açıkça seçin.
- Görünürlük ve gizlilik
- Kullanıcıların uygunluğu görmesi için gereken en düşük takvim ayrıntısını paylaşın.
- Değişiklik yayılımı
- Dizin ve policy değişikliğinden sonra istemci cache ve servis yayılım süresini test planına ekleyin.
Hesap ve uygulama örneği
Bir odanın ileri rezervasyon sınırı 180 gün ve istek 200 gün sonrası içinse boş görünmesi kabul edileceği anlamına gelmez. Aynı organizatörle 30 gün ve 200 gün testleri yapın. İlk istek kabul, ikincisi reddediliyorsa kaynak sağlıklı; policy beklenen sonucu üretmektedir. Kullanıcı mesajını booking window değerini belirtecek biçimde düzenleyin.
50 odalı iki binada adlandırmayı `IZM-A-08-06p` gibi konum ve kapasiteyle standardize edin. Oda listeleri/binaya göre arama, yanlış kaynağa rezervasyonu azaltır. Yeniden adlandırmada eski aliası hemen silmek yerine kullanım kaydını izleyin; yinelenen bağımsız kaynak oluşturarak aynı fiziksel odayı iki takvimde açmayı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 örneği
Get-Mailbox -RecipientTypeDetails RoomMailbox | Select DisplayName,PrimarySmtpAddress
Get-CalendarProcessing [email protected] | Format-List AutomateProcessing,BookingWindowInDays,MaximumDurationInMinutes,AllBookInPolicy,ResourceDelegates
Set-CalendarProcessing [email protected] -AutomateProcessing AutoAccept -BookingWindowInDays 180
# Google Workspace: Admin Console kaynak kimliğini ve Calendar audit olaylarını aynı zaman aralığında inceleyin.Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Oda aramada görünmüyor | Yanlış bina/resource tanımı, room list üyeliği veya kullanıcı görünürlüğü eksik olabilir. | Kaynak kimliğini yönetim dizininde ve etkilenen kullanıcının aramasında karşılaştırın. |
| Boş oda isteği reddediliyor | Booking window, maksimum süre, recurrence veya kapsam politikası tetiklenmiş olabilir. | Aynı kullanıcıyla kısa/yakın tarihli kontrol isteği yapıp karar nedenini inceleyin. |
| İki ekip aynı odayı rezerve etmiş görünüyor | Aynı fiziksel oda için iki kaynak veya eski alias üzerinden ayrı takvim olabilir. | Her etkinliğin resource ID/e-posta değerini ve merkezi envanteri eşleştirin. |
| Delegate onayı gelmiyor | Yönlendirme, delegate üyeliği veya otomatik işlem ayarı çelişebilir. | Kaynak booking configuration ile delegate mailbox teslimat kaydını birlikte kontrol edin. |
Kabul ve doğrulama kontrolleri
- Kaynak kimliği, bina, kapasite ve alias envanterini doğrulayın.
- Etkilenen kullanıcının odaları arayıp uygunluk görebildiğini test edin.
- Booking window, süre, recurrence ve delegate kurallarını kaydedin.
- Basit yakın tarihli toplantıyla kabul/ret yolunu sınayın.
- Reddetme yanıtını resource kimliği ve organizer ile eşleştirin.
- Düzeltme sonrası mobil ve web istemcide aynı sonucu doğrulayın.
İlgili kavramlar
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.
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.
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.
Politikanın yaşam döngüsü
Bir politika yalnız etkinleştirildiği anda değil, kapsamı değiştikçe de yönetilmelidir. Taslak, gözlem, pilot, uygulama ve periyodik inceleme aşamalarını ayırın. Her istisnanın sahibi, gerekçesi, kapsamı ve sona erme tarihi olmalıdır. Test verileri gerçek kullanıcı davranışını temsil etmezse başarılı pilot üretimde yanlış engellemelere dönüşebilir. Önce kimin ve hangi uygulamanın etkilenebileceğini belirleyin; sonra ölçülebilir kabul koşullarıyla devreye alın. Geri alma yolu yalnız düğme konumunu değil, değişikliğin kim tarafından ve hangi koşulda geri alınacağını da tanımlamalıdır.
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.
Bağımlılık ve yeniden başlatma sırası
Bir hizmet çoğu zaman kimlik, DNS, zaman, ağ, veritabanı ve lisans servislerine bağlıdır. Bağımlılıkları yalnız cihaz listesi olarak değil, hangi hizmetin hangi koşulla çalışabildiğini gösteren bir grafik olarak kaydedin. Hizmetlerin yeniden başlatılma sırası buna göre belirlenir; bazı döngüsel bağımlılıklar özel acil erişim gerektirir. Çalışan altyapı bileşenleri ile işin yeniden başlayabildiği anı ayırın. Her bağımlılığa sorumlu, doğrulama yöntemi ve alternatif erişim yolu atayın. Uçtan uca testte bir bileşeni bilerek erişilemez hale getirerek varsayımları sınayın.
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.