Monofor kurulum projelerini teslim etmek
Neler değişti
Her içerik güncellemesi sürümlenir. Bir sürümü seçerek öncekiyle karşılaştırın.
Sürüm 8 → 9
GüncellemeDört yeni ders MCIP sınavına göre eksikleri kapatıyor: ürünlerin içinde değişiklik yönetimi, keşifte bulunması gereken tasarım kısıtları, ilk üretim değişiklikleri için güvenceler ve operasyon görevleriyle birlikte kabul kanıtları. Her bilgi kontrolüne iki yeni soru eklendi. Yeni derslere diyagramlar eklendi.
4 ders güncellendi
İçerik güncellemesi. Kayıtlı öğrenciler bilgilendirildi.
Bir değişiklik planı, birisi `Save` düğmesine bastığında ürünün ne yaptığını ne kadar doğru bildiğinizle sınırlıdır. Özenle hazırlanmış bir planın sahada tutup tutmayacağını birkaç ürün davranışı belirler. Bu ders, teslim sırasında en çok önem taşıyanları ve her birinin gerektirdiği çalışma kuralını bir araya getirir.
### Devam ya da dur kararı bir kontroldür, bir his değil
Her dalgadan önce ölçülebilir çıkış ölçütlerini yazın: kayıt oranı, oturum açma hata oranı, yüz kullanıcı başına yardım masası kaydı. Eşikleri dalga başlamadan kararlaştırın ve geri dönüşü toplantıdan önce test edin. Böylece yönlendirme kurulu izlenimleri tartışmak yerine sayıları eşiklerle karşılaştırır. Yanlış bir karar da ucuza kapanır, çünkü geri dönüş yolu önceden kanıtlanmıştır.
### Monosync: değişiklik geçmişi bir kayıttır, geri alma değildir
Bir entegrasyonun her kaydedilişi, yorumu ve kayıt (ticket) numarası olan bir commit'tir. `Show Commits` kimin neyi değiştirdiğini listeler ve farkı gösterir. Geri yükleme denetimi yoktur.
| Ürün davranışı | Çalışma kuralı |
| --- | --- |
| İki kişi aynı entegrasyonu düzenler. İkinci kayıt `Integration Is Changed` uyarısını gösterir ve `Overwrite` sonrasında ilk kişinin işinin yerini alır | Bir entegrasyonda aynı anda tek düzenleyici, her commit'te kayıt numarası, `Show Commits` ile gözden geçirme |
| Önceki sürüm tek tıkla geri yüklenemez | Değişiklik planı önceki değerleri kaydeder, böylece elle yeniden girilebilir |
| Hedef sisteme yazılmış değerler orada kalır | Geri dönüş planı hedef veriyi kimin, nasıl onaracağını belirtir |
### Zamanlamalar ve bakım pencereleri
Zamanlamalar **UTC** cinsinden cron ifadeleridir. Etkin bir entegrasyonda yeni ya da düzenlenmiş bir zamanlama, bir sonraki çalışma zamanı zaten geçmişte kaldığı için genellikle kayıttan hemen sonra bir kez çalışır. Bu yüzden cumartesi penceresi için zamanlamayı cuma günü "hazırlamak", cuma günü bir çalışma başlatır. Zamanlama değişikliklerini pencerenin içinde kaydedin. Bir entegrasyon aynı anda iki iş çalıştırmaz.
Bir hedef sistem bakıma alındığında `Start Maintenance` entegrasyonları duraklatır. Runbook'a üç ayrıntı yazılmalıdır:
- Çalışan işleri beklemez. Hedef kapatılmadan önce `Integration Jobs` sayfasını açıp hiçbir işin çalışmadığını doğrulayın ya da işleri durdurmak için `Start Maintenance with stopping tasks.` seçeneğini kullanın.
- `Run Once` duraklatılmış bir entegrasyonda da çalışır. Operatörlere pencere boyunca kullanmamalarını söyleyin.
- Pencereden sonra zamanlamalar durdurulma anından devam eder. Pencere sırasında kaçan çalışmalar telafi edilmez.
### Monosign: pilot uygulanamayan üç değişiklik
**Yükseltmeler.** Tam yol için sürüm notlarını okuyun. v2026.07 sürümünden v2026.09 sürümüne yükseltme, tüm uygulama düğümlerinin tamamen durdurulmasını ve aynı migrator sürümlerini gerektirir, çünkü karışık bir küme işleri yineler ve önbellek geçersiz kılmalarını kaçırır. Bu yolda düğüm düğüm kademeli yükseltme mümkün değildir, bu nedenle kesinti penceresini erkenden kararlaştırın.
**Özelleştirilmiş metinler.** Düzenlenmiş bir içerik öğesi, örneğin bir e-posta şablonu metni, ya da düzenlenmiş bir çeviri, yükseltmeden ancak o öğenin ürünle gelen sürümü değişmediği sürece sağ çıkar. Bir sürüm bu numarayı yükselttiğinde, ürünle gelen varsayılan metin her tenant'ta düzenlemenin yerini alır. Sürüm notu bu öğeler için uyarı taşır. Her özelleştirmenin kopyasını saklayın ve yeniden uygulamak için zaman ayırın.
**API Security.** Anahtar (switch) uygulamaya aittir ve o uygulamanın tüm anahtarlarını aynı anda denetime sokar. Tek bir anahtar üzerinde pilot yapılamaz. Her anahtarın çağırdığı uç noktaları listeleyin, bu izinleri anahtarın `Permissions` sekmesinde verin, ardından switch'i bir değişiklik penceresinde açın. "Master anahtarla çalışıyor" bir kanıt değildir: master uygulama, sıradan bir anahtarın izin sahibi olması gereken denetimlerden geçer.
::diagram del-change-control
### Örnek çalışma
Bir iş ortağı cumartesi 22:00'de bir üretim entegrasyonunun eşlemesini değiştirecek ve zamanlamasını taşıyacak. Ürüne uygun bir plan şöyle görünür:
1. Adı belli tek düzenleyici. O akşam entegrasyonu başka kimse açmaz.
2. Önceki eşleme değerleri ve önceki cron kayda yapıştırılır.
3. Zamanlama 22:05'te, pencerenin içinde kaydedilir ve hemen bir çalışma beklenir.
4. Devam ölçütü: bu ilk çalışmada başarısız nesne olmaması. Aksi halde önceki değerler elle yeniden girilir.
5. Hedef sistemde adı belli bir sahip, yazılmış olan değerleri onarır.
Boyutlandırma "ne kadar büyük" sorusunu yanıtlar. Bazı keşif bulguları ise başka bir soruyu yanıtlar: "hiç çalışacak mı". Bunları bir atölyede sormanın maliyeti yoktur, canlıya geçtikten sonra öğrenmenin maliyeti ise yüksektir. Şu beş maddeyi keşif şablonunuza ekleyin.
### 1. Monosign sunucuları lisans servisine ulaşabiliyor mu?
Monosign, Monofor lisans servisiyle düzenli olarak iletişim kurar. Varsayılan adres `services.monofor.com` adresidir. Çevrimiçi denetim açıkken, son başarılı iletişimin üzerinden 7 günden fazla geçtiğinde oturum açma reddedilir. Bu nedenle dışa çıkışı olmayan bir müşteri ağı, çevrimiçi denetimi kapalı olarak düzenlenmiş bir lisans gerektirir. Böyle bir lisansta da süre sonu ve ana bilgisayar doğrulaması geçerlidir. Lisans arayüzden içe aktarılamaz. Bu yüzden konuyu kurulum gününde değil, tasarım imzalanmadan önce Monofor temsilcinizle çözün.
### 2. Dizin ne kadar büyük?
Bir Active Directory ya da LDAP kaynağı, her çalışmada en çok `Limit` kadar nesne okur (varsayılan 500000) ve bunu `Page Size` büyüklüğünde sayfalarla yapar (varsayılan 1000). Daha büyük bir dizin **kısmen ve hata vermeden** eşitlenir. Her dizinin nesne sayısını sorun. Sayı varsayılana yakın ya da üzerindeyse, tasarıma `Limit` değerinin yükseltileceğini ve ilk eşitlemenin dizinin kendi sayısıyla karşılaştırılacağını yazın.
### 3. Kullanıcılar ile Monopam arasında ne var?
Monopam'da yerel parola yoktur. Kullanıcılar kimlik sağlayıcıda, normalde Monosign'da oturum açar. Monopam sonucu, kullanıcının gruplarını ve izinlerini taşıyan bir çerezde tutar. Bu da oturum açma yanıtını büyütür. Yol üzerindeki her ters vekil sunucu ve yük dengeleyici büyük yanıt başlıklarını kabul etmelidir. Varsayılan arabelleklerle bırakılmış tek bir durak, çok sayıda grubu olan kullanıcıların oturum açmasını bozmaya yeter. Belirti genellikle `502 Bad Gateway` olur. Her durağı ve sahibini listeleyin.
### 4. Monosync yük altında nasıl çalışacak?
Monosync tek bir kapsayıcı imajı olarak gelir. Bir düğümün rolünü iki ortam değişkeni belirler:
| Düğüm rolü | Ayar |
| --- | --- |
| Yalnızca arayüz | `MONOSYNC_DISABLE_SERVICE=true` |
| Yalnızca servis düğümü (entegrasyon çalıştırıcı) | `MONOSYNC_DISABLE_UI=true` |
| İki rol birlikte | İki değişken de ayarlanmaz |
Tüm düğümler **tek** bir veritabanını ve kimlik doğrulamalı **tek** bir Redis'i paylaşır. Redis iş durumunu ve ana düğüm seçimini tutar. Operatörler arayüzde çalışırken çok sayıda entegrasyonun paralel çalışması gerekiyorsa rolleri ayırın ve servis düğümü ekleyin. Düğümlere ayrı Redis örnekleri vermeyin, çünkü eşgüdümleri kopar.
### 5. Oturum kayıtları nerede duracak?
Bir Monopam Gateway, bir oturumu ancak iki yakalama yolu da yapılandırılmışsa kaydeder. Bu yollar olmadan da oturum açar, ama kaydetmez. Yollar Gateway ana bilgisayarına aittir: yapılandırma dosyasından ya da kapsayıcıda `MONOPAM_GW_CAPTURE_TEMP_PATH` ve `MONOPAM_GW_CAPTURE_VIDEO_PATH` ortam değişkenlerinden gelir. Tenant için bir CDN yapılandırılmamışsa kayıtlar Gateway üzerinde kalır. Bu nedenle kapsayıcı olarak çalışan bir Gateway, iki yol için de beklenen kayıt hacmine göre boyutlandırılmış kalıcı birimlere ihtiyaç duyar. Aksi halde kayıtlar kapsayıcıyla birlikte kaybolur.
::diagram del-design-constraints
### Senaryo
Bir banka her ayrıcalıklı oturumun kaydedilmesini istiyor, Gateway'leri kapsayıcı olarak çalıştırıyor ve dışa internet erişimini engelliyor. Boyutlandırma başlamadan önce üç tasarım satırı ortaya çıkar:
| Bulgu | Tasarım satırı |
| --- | --- |
| Lisans servisine yol yok | Monofor temsilcisinden istenen, çevrimiçi denetimi kapalı bir lisans |
| Kapsayıcı Gateway'ler, kayıt zorunlu | Her Gateway'in iki yakalama yolunda kalıcı birimler |
| Monopam'ın önünde iki vekil sunucu | İkisinde de büyük yanıt başlığı arabellekleri ve adı belli bir sahip |
Bu satırların hiçbiri sunucu sayısını değiştirmez. Her biri ise projeyi üretimdeki ilk haftasında durdurabilir.
Bir projenin en riskli saatleri, canlı bir tenant üzerindeki ilk değişikliklerdir: zorunlu kılınan ilk politika, ilk dizin eşitlemesi, ilk sertifika ve ilk anahtar değişikliği. Her birinin basit bir güvencesi vardır. Dördünü de devreye alma planına koyun.
### MFA zorunlu olmadan önce içeri dönüş yolu
Yanlış yapılandırılmış bir kimlik doğrulama politikası, yöneticiler dahil herkesi dışarıda bırakabilir. Bir politika tüm kullanıcılara uygulanmadan önce, politikanın kilitleyemeyeceği bir acil durum yönetici hesabının var olduğundan emin olun ve bunu kanıtlayın: o gün, bir olay anında kullanacağınız ağdan bu hesapla oturum açın. Böyle bir hesap için genel iyi uygulama şudur:
- Adı belli bir hesaptır, runbook'ta belgelenir ve sahibi müşteridir.
- Kimlik bilgileri mühürlü tutulur, örneğin her teslim almayı kaydeden bir vault içinde.
- Her kullanım sonradan gözden geçirilir.
Tüm yöneticileri MFA'nın dışında bırakmak aynı şey değildir. Bu, tek bir kötü günü karşılamak için en güçlü hesapları her gün zayıflatır.
### Büyük bir dizinin ilk eşitlemesi: dar başlayın
Bir eşleme hatası, eşitlemenin dokunduğu her kullanıcıya yayılır. Bu yüzden ilk çalışmayı küçük tutun:
1. `User Base DN` alanını bir pilot OU'ya yönlendirin ve `Test` düğmesine basın.
2. Eşitlemeyi çalıştırın ve birkaç kullanıcıyı elle denetleyin: öznitelikler, grup üyelikleri, durum.
3. Yalnızca pilot grup etkilenirken eşlemeleri ve filtreleri düzeltin.
4. Base DN'i tam kapsama genişletin ve eşitlenen sayıyı dizinin kendi sayısıyla karşılaştırın.
4. adım geçilmeden, hesapları devre dışı bırakan ya da silen hiçbir otomasyonu bağlamayın.
### Sertifikayı `monofor cert install` ile değiştirmek
| Davranış | Planınız için anlamı |
| --- | --- |
| Herhangi bir şeyi değiştirmeden önce sertifika ile anahtarın geçerli bir çift oluşturduğunu denetler | Yanlış dosya çifti reddedilir ve çalışan sisteme dokunulmaz |
| Sonraki bir adım başarısız olursa önceki sertifikayı ve yapılandırmayı geri yükler | Başarısız bir deneme yeniden kurulum gerektirmez |
| Süresi dolmuş bir sertifika `--allow-expired` gerektirir, süresi zaten dolmuş bir sertifikayı kurar | Bu seçeneği yalnızca bilerek kullanın, örneğin bir test ortamında |
| `monofor status` süre sonundan 30 gün önce uyarır | Bitiş tarihini ve yenileme sahibini devir belgelerine yazın |
### Monopam vault anahtarı: sıra önemlidir
Vault anahtar halkası, bir süreç başlarken ortamdan okunur. Çalışan bir süreç değişen bir değişkeni fark etmez. Güvenli sıra şudur:
1. Aynı `MONOPAM_VAULT_KEY` değerini ve sürümünü, sır okuyan **her** süreçte ayarlayın: Web, vekilleriyle birlikte Gateway, Automator ve RemoteSession.
2. Hepsini yeniden başlatın.
3. Yeniden şifreleme işini ancak bundan sonra çalıştırın.
İş, Gateway hâlâ eski anahtar halkasını tutarken çalışırsa, Web satırları Gateway'in çözemeyeceği biçimde yeniden yazar ve Gateway üzerinden geçen her bağlantı başarısız olur. Kaybolan bir anahtar için kurtarma yolu da yoktur. Bu nedenle anahtarın kendisini değil, nerede tutulduğunu ve sahibini kaydedin.
::diagram del-commissioning-day
### Senaryo
Bu güvenceler üzerine kurulmuş bir devreye alma günü planı:
| Saat | Adım | Kanıt |
| --- | --- | --- |
| 09:00 | Acil durum yönetici oturumu test edildi | Adı belli test eden, sonuç not edildi |
| 09:30 | AD kaynağı pilot OU ile sınırlandı ve eşitlendi | 40 kullanıcı elle denetlendi |
| 11:00 | Müşteri sertifikası kuruldu | `monofor status` çıktısında Certificate satırı uyarısız |
| 13:00 | Vault anahtarı beş süreçte ayarlandı, hepsi yeniden başlatıldı, iş çalıştırıldı | Gateway üzerinden bir RDP ve bir SSH oturumu açıldı |
Her satırın bir adı ve bir saati vardır. Aynı liste ilk kabul kanıtınızdır.
Kabul, müşterinin üzerinde anlaşılan kapsamın çalıştığını onayladığı andır. Devir, müşterinin operatörlerinin onu çalışır tutmaktan sorumlu olduğu andır. İkisi de ürünün kendi kayıtlarını doğru okumaya dayanır.
### Bir şeyi kanıtlayan UAT
Bir tanıtım turu etkinlik gösterir. Bir test ise kapsamı kanıtlar. İmza için üç şey doğru olmalıdır:
- Her test senaryosu, üzerinde anlaşılan kapsamdaki bir gereksinime dayanır ve her gereksinimin en az bir test senaryosu vardır.
- Senaryoları müşterinin kişileri yürütür ya da sizinle birlikte yürütür. Yalnızca iş ortağının yaptığı test, yalnızca iş ortağının memnun olduğunu kanıtlar.
- Her sonuç tarih, test eden, sonuç ve kanıtla kaydedilir. Kanıt bir rapor satırı ya da bir ekran görüntüsü olabilir.
| Gereksinim | Test senaryosu | Kanıt |
| --- | --- | --- |
| Monosign'da grup atamak kullanıcıyı AD grubuna ekler | Bir pilot kullanıcı atayın ve geri yazmayı bekleyin | Reports → `Provisions` satırı ve `View Logs` geçmişi |
::diagram del-uat-evidence
### Provizyon raporunu sonuna kadar okuyun
Reports → `Provisions`, dizin grubu geri yazmalarını ve kaynak provizyonlarını, her biri **en son** denemesiyle listeler. `Provisioned` durumundaki bir satır, başarılı olmadan önce birkaç kez başarısız olmuş olabilir. Satır menüsündeki `View Logs`, her denemeyi tarih, durum ve iletiyle açar. Müşteri bir provizyonun yolda hata alıp almadığını sorduğunda bunu kullanın. Sınırını da bilin: SCIM gönderimlerinin durumu bu raporda yer almaz.
### Sessizce başarısız olan şeyler
Management → System → Services altındaki `Dead Letters`, teslim edilemeden kalan bildirimleri, provizyon işlerini ve webhook'ları toplar. **Bunlar için hiçbir uyarı üretilmez.** Birinin sayfayı açması gerekir. Bu nedenle runbook bir sahip ve bir gözden geçirme sıklığı belirler, iki eylem için de ölçüt verir:
| Eylem | Etki | Ne zaman kullanılır |
| --- | --- | --- |
| `Requeue` | Öğeyi hazır durumuna döndürür. Öğe yeniden başarısız olup listeye geri gelebilir | Neden giderildiğinde, örneğin posta sunucusu yeniden erişilebilir olduğunda |
| `Discard` | Satırı listeden kaldırır ve hiçbir şey göndermez. Satır ve hatası veritabanında kalır | Öğeyi göndermenin artık bir anlamı kalmadığında |
### Lisans bandı
Çevrimiçi denetim açıkken, lisans sunucusuna 3 saat boyunca ulaşılamadığında Management bir uyarı bandı gösterir. Son başarılı iletişimin üzerinden 7 günden fazla geçtiğinde oturum açma reddedilir. Operatörlere bandı acil saymayı öğretin. 7 gün, dışa erişimi yeniden sağlamak için ellerindeki süredir, beklemek için bir neden değildir.
### Saklama süresi imzalı bir karardır
| Ürün | Davranış | Kaydedilecek karar |
| --- | --- | --- |
| Monosign | `Data Retention` içindeki `Audit` kuralını etkinleştirmek, eski denetim satırlarını kalıcı olarak siler ve silmeden önce arşivlemez | Gün sayısı ve uyum daha uzun süre gerektiriyorsa eski kayıtların nerede tutulacağı |
| Monosync | Kayıt temizliklerinde de arşiv yoktur ve artımlı çalışmalar son başarılı çalışmanın kaydına dayanır | Başarılı çalışmalar arasında beklediğiniz en uzun aralığın üzerinde gün değerleri |
Devir paketindeki iki satırı da müşterinin uyum sorumlusuna imzalatın. Kimsenin seçmediği bir saklama değeri, bir yıl sonra bir denetimde ortaya çıkan türden bir bulgudur.
### Bu konular için devir kontrol listesi
- Her satır için gereksinim, senaryo, test eden, sonuç ve kanıt içeren UAT kaydı
- Runbook'a yazılmış `Dead Letters` sahibi ve gözden geçirme sıklığı
- Lisans bandının açıklaması ve dışa erişimi yeniden sağlayacak kişi
- Uyum sorumlusunun imzaladığı saklama değerleri