Karşılaştırma · Kurumsal E-posta ve İş Birliği
Ortak Posta Kutusu, Delegasyon ve Grup: Workspace ile Microsoft 365
Dağıtım grubu mesajı üyelere dağıtır; ortak posta kutusu ortak bir mesaj deposu ve gönderim kimliği sağlar. Google Workspace Gmail delegasyonu ve Groups Collaborative Inbox, Microsoft…
Teknik gözden geçirme:
Mimari ve çalışma modeli
Dağıtım grubu mesajı üyelere dağıtır; ortak posta kutusu ortak bir mesaj deposu ve gönderim kimliği sağlar. Google Workspace Gmail delegasyonu ve Groups Collaborative Inbox, Microsoft 365 shared mailbox veya Microsoft 365 Group ile birebir aynı işlev kümesi değildir.
Destek taleplerinde kimin yanıtladığı, mesaj sahipliği, silme ve çakışan yanıt önemlidir. Ortak hesap parolasını paylaşmak yerine kişisel kimlik ve delegasyon kullanın. Lisans, depolama, arşiv ve retention koşullarını seçilen platform ve sürüme göre doğrulayın.
Teknik seçim mesaj gönderme yetkisi ile mesaj okuma yetkisini ayırmalıdır. İstemci desteği ve mobil erişim de pilotta sınanır. Ticket atama, SLA ve otomasyon gerekiyorsa mail kutusunu zorlamak yerine helpdesk uygulamasını değerlendirin.
- 1Mesaj teslimi
- 2Ortak depo veya dağıtım
- 3Kişisel yetki
- 4Yanıt ve kayıt
Tasarım parametreleri
- Gönderim kimliği
- Send-as ile on-behalf-of davranışını ve alıcıya görünen kimliği doğrulayın.
- İş akışı
- Mesaj atama, durum ve çift yanıt önleme ihtiyacını yazın.
- Saklama
- Kullanıcı ayrılınca ortak mesajların kalmasını ve audit erişimini test edin.
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.
| Seçenek | Temel davranış | Kontrol |
|---|---|---|
| Dağıtım grubu | Kopyaları üyelere yollar | Ortak durum takibi sınırlı |
| Gmail delegasyonu | Yetkili kullanıcı ortak mailbox’a erişir | Gönderim ve lisans koşulu |
| Groups Collaborative Inbox | Grup iş akışı ve atama | Mail istemcisi ve süreç uyumu |
| M365 shared mailbox | Ortak Exchange deposu | Send-as, saklama ve lisans |
Hesap ve uygulama örneği
Üç destek çalışanı support@example.test adresinde çalışsın. Aynı mesajı iki kişi açıp yanıt hazırladığında çakışma kontrolünü ölçün. Bir çalışanı çıkarınca ortak içerik korunmalı ve onun kişisel erişimi kapanmalıdır. Bu iki test, yalnız “mail geliyor” kontrolünden daha değerlidir.
Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Yanıt farklı kimlikle gidiyor | Send-as/delegation ayarı veya istemci davranışı. | Alıcı mesaj header’ını ve sent-items kaydını inceleyin. |
| Ayrılan çalışan erişiyor | Delegasyon veya grup üyeliği kaldırılmamış. | Tüm erişim yollarını ve aktif oturumları kontrol edin. |
Kabul ve doğrulama kontrolleri
- Okuma/gönderim yetkisini ayırın.
- Mobil istemciyi test edin.
- Çift yanıt senaryosunu sınayın.
- Retention koşulunu doğrulayın.
- Offboarding’i tamamlayın.
- Gerekirse helpdesk’e çıkış planlayın.
İ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 ACLleri inceleyin. İzinleri topluca açmak yerine gereken erişimi dar kapsamda test edin.
Saklama politikası ve kapasite
Retention, hangi kurtarma noktalarının ne kadar süre tutulacağını tanımlar. Günlük, haftalık ve aylık noktalar aynı veri değişim oranını temsil etmez; tam kopya üretme şekli ve zincir bağımlılığı fiziksel kapasiteyi değiştirir. Saklama kararı, iş gereksinimi ve geçerli yükümlülükler ile teknik kapasitenin birlikte değerlendirilmesini gerektirir. Daha uzun saklama, otomatik olarak daha iyi kurtarma anlamına gelmez: doğru noktanın bulunması ve okunabilmesi gerekir. Politika değiştirildiğinde mevcut noktaların hemen silinip silinmediğini ürün davranışı üzerinden sınayın.
Uygulama tutarlılığı
Bir kopyanın açılabilir olması, uygulama verisinin tutarlı olduğunu kanıtlamaz. İşletim sistemi önbelleği, veritabanı günlükleri ve birden fazla disk veya servis arasındaki işlem sırası sonucu etkiler. Crash-consistent kopya beklenmedik kapanma sonrasındaki duruma benzer; application-consistent kopya uygulamanın desteklediği hazırlık ve yazma düzenini dikkate alır. Geri dönüşte yalnız dosya sayısını değil, işlem bütünlüğünü, kayıt ilişkilerini ve uygulama testini kontrol edin. Yedek ürününün desteklediği entegrasyonu, uygulama sürümünü ve hata çıktısını doğrulamadan tutarlılık varsaymayın.
Sürüm ve destek yaşam döngüsü
Bir ürünün kurulabilir olması üretim için desteklendiğini kanıtlamaz. İşletim sistemi, uygulama, sürücü, eklenti ve yönetim aracının uyumluluk zincirini birlikte kontrol edin. Güncelleme planında paket sürümü, destek bitişi, yeniden başlatma gereksinimi ve geri alma yöntemi bulunmalıdır. Test ortamı üretimdeki bağımlılıkları temsil etmezse sonuç yanıltıcı olabilir. Değişiklik sonrası yalnız sürüm numarasını değil, hizmet sağlığını ve önceki iş akışlarını doğrulayın. Bir sürümü sabitlemenin gelecekteki güvenlik düzeltmelerini engelleyebileceğini de dikkate alın.
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; log yokluğu, olay yokluğu şeklinde yorumlanmamalıdır.
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.