msp onboarding süreci: ilk 14 gün, gün gün

Yeni müşteri, yeni cihazlar ve işlemekte olan bir SLA — ilk iki hafta, onboarding'in istikrarlı bir yönetilen ilişki mi yoksa tekrarlayan bir kriz senaryosu mu olacağını belirler. Bu makale, bir müşteri filosunun ilk 14 günü için uygulanabilir, gün gün MSP onboarding sürecini sunar: ne dağıtılmalı, ne kontrol edilmeli, ne otomatikleştirilmeli ve ne zaman tırmandırılmalı.

Hedefler, kapsam ve varsayımlar

Bu playbook şu varsayımlara dayanır: 25–500 uç noktadan oluşan bir filo, karışık Windows ve macOS makineler ile birkaç Linux sunucu, merkezi bir ticket kuyruğu (SLA: P2 için 4 iş saati) ve sizin kontrol ettiğiniz bir RMM. Odak, gözetimsiz erişim, envanter, güvenli temel yapı, izleme ve denetim izleri üzerinedir. Müşteri yalnızca kurum içi altyapı istiyorsa (veri yerleşimi, üçüncü taraf relay yok), self‑hosting'i bir uyumluluk gereksinimi olarak ele alın — aksi takdirde managed relay operasyonel varsayılanlıktır.

Araçlar, mimari ve önerilen varsayılanlar

• Uzak erişim: Windows/macOS/Linux için yerel Tenvo istemcileri ve tarayıcı istemcisi (açık beta). Varsayılan olarak Tenvo'nun çok bölgelik managed relay'ini kullanın: bu, nöbet yükünü, sertifika döndürmeyi ve bölge arası failover çabasını azaltır. Tenvo planları: Free $0, Lite $2.99/mo, Pro $7.99/mo — özelliklere ve oturum sınırlarına göre seçin.
• Ticketing/RMM: oturum başlatma/durdurma webhook'larını ticket sisteminize ve RMM'e entegre edin. Bir yardım masası iş akışının başlangıç noktasını bağlamak için bir kontrol listesine ihtiyacınız varsa, bkz. Yardım Masası Uzak Destek Kurulumu.
• Denetim ve kayıt: ilk günden itibaren denetim kaydı planlayın. Sözleşmeniz uzun saklama gerektiriyorsa, depolamayı ticket sistemi yakınında tasarlayın; örnekler için bkz. Uzak Masaüstü Denetim Kaydı.
• Ne zaman self‑host: yalnızca yazılı uyumluluk zorunlulukları, izole ağlar veya katı veri yerleşimi kuralları için. Self‑hosting sertifika operasyonları, nöbetçi relay failover'ı ve yama yükü getirir — bu genellikle managed relay'den daha fazla operasyonel personel maliyeti çıkarır. Takasları görmek için bkz. Self-Hosted Remote Desktop: Why, How, and What Breaks.
• Araç seçimi: bu playbook varsayılan olarak Tenvo-managed relay'i hedefler. Önce alternatifleri karşılaştırmak isterseniz, bkz. MSP uzak destek araçları: 2026 için doğru yığını seçmek.

Gün gün: ilk 14 gün (pratik kontrol listesi)

1. Gün 1 — Sözleşme ve erişim başlatması (isteğe bağlı olarak Gün 0): kapsamı, SLA'ları, ayrıcalıklı hesap devrini ve bakım pencerelerini doğrulayın. Yönetici kimlik bilgilerini, VPN bilgilerini ve her iş birimi için sahip listesini toplayın. Domain/kontrolör yöneticileri için acil durum irtibatını ekleyin.
2. Gün 2 — Envanter ve temel anlık görüntü: ajanı bir pilot gruba (10–20 cihaz) dağıtın. Donanım/işletim sistemi ayrıntılarını, yüklü AV'yi, disk kullanımını ve temel performansı kaydedin. İşletim sistemi, departman ve ortam (prod/test) için ajan etiketleri kullanın.
3. Gün 3 — Gözetimsiz erişim yapılandırması (pilot): pilot cihazlarda gözetimsiz erişimi etkinleştirin. Teknisyenler için role‑dayalı erişimi yapılandırın ve desteklenen durumlarda güçlü parolalar veya SSO gerektirin. Oturum başlatma olaylarının ticket sistemine kaydedildiğini doğrulayın.
4. Gün 4 — Sertifika & ağ doğrulaması: her cihazın sertifika kaydını ve bağlantısını doğrulayın. NAT geçişini kontrol edin: hangi cihazların P2P ile bağlandığını, hangilerinin relay kullandığını teyit edin. Not: trafik relay üzerinden geçtiğinde, TLS relay'de sonlanır; bu nedenle relay işletmecisi oturum verilerini görebilir. Hangi alt ağların firewall ayarı gerektirdiğini kaydedin.
5. Gün 5 — Firewall ve gateway kuralları: gerekli FQDN/IP izin kurallarını ve müşteri trafiği inceliyorsa HTTP/S TLS inceleme istisnalarını dağıtın. Engellenmişten izinliyete geçişi ve zorunlu relay yolunu test ederek oturumların hala bağlandığını doğrulayın.
6. Gün 6 — Kimlik bilgisi ve kasa entegrasyonu: ayrıcalıklı oturumlar için oturum kimlik bilgisi enjeksiyonu veya bir gizli kasa (Vault, Bitwarden, CyberArk) entegre edin. Paylaşılan yönetici parolalarını e‑tabloda saklamayı bırakın; 30–90 gün aralığında bir döndürme takvimi oluşturun ve döndürme sürecini runbook'ta belgeleyin.
7. Gün 7 — İzleme ve uyarı tabanı: uzaktan erişim sağlık kontrollerini izlemeye ekleyin (ajan çevrimiçi %, bağlantı süre yüzdelikleri, başarısız kimlik doğrulama sayıları). Uyarı eşiklerini belirleyin: örn. 15 dakikada >3 başarısız oturum, ajan 30 dakikadan fazla çevrimdışı.
8. Gün 8 — Dağıtımı ölçeklendirme: ajan dağıtımını cihazların %50–75'ine genişletin. Kurulumları otomatikleştirmek için MSI/GPO veya RMM'inizi kullanın. Kesintiyi sınırlamak ve kurulum sorununda hızlı geri alma yapmak için departman başına bir dağıtım penceresi tutun.
9. Gün 9 — Oturum politikaları & izinler: en az ayrıcalık ilkesini uygulayın: teknisyenler sadece ihtiyaç duydukları gruplara erişsin. Onaylı ve denetim kaydı etkin olan ayrı bir 'break‑glass' prosedürü oluşturun.
10. Gün 10 — Ticketing ve SSO ile entegrasyon: oturum API'lerini ticket'lara oturum ID'lerini ve logları otomatik ekleyecek şekilde bağlayın. Teknisyen girişleri için SAML/SSO (Okta, Azure AD) etkinleştirin ve provisioning/deprovisioning akışlarını test edin.
11. Gün 11 — Kayıtlar ve saklama politikası: destek oturumlarını kaydediyorsanız, saklama süresini sözleşme ve gizlilik kurallarına göre belirleyin. Denetlenebilirlik için kayıtların yanında metadata (kullanıcı, teknisyen, ticket ID) saklayın. Gerekli yerlerde oynatma ve sansürleme iş akışlarını test edin.
12. Gün 12 — Performans ve UX ayarı: oturum gecikmesini, kare hızı ve bant genişliğini ölçün. Yüksek kullanım grupları (tasarımcılar, video editörleri) için codec ayarlarını, pano senkronizasyonunu ve çevre aygıt yönlendirme politikalarını ayarlayın ve normal destek için gereksiz özellikleri kilitleyin.
13. Gün 13 — Yedekleme & failover testi: bir relay kesintisini simüle edin ve alternatif bölgelere veya yerel VPN yollarına failover'ı doğrulayın. Müşteri dış relay'leri yasaklıyorsa, self‑hosted relay kümesi failover'ını, sertifika yenilemeyi ve izlemeyi doğrulayın.
14. Gün 14 — Gözden geçirme, SLA onayı ve runbook devri: müşteriyle 60–90 dakikalık bir gözden geçirme yapın: envanter kapsamı, olay müdahale adımları, nöbette yükseltme ve 30/60/90 günlük sürekli plan. Runbook'ları ve 'neyi izliyoruz' panosunu yayınlayın. Ticket'lı onboarding maddelerini kapatın ve tekrarlayan onboarding görevlerini otomasyona çevirin.

14. günden sonra operasyonel kontrol listesi

• Günlük/haftalık izlenecek KPI'lar: ajan kapsama %, ortalama bağlantı süresi, ilk aramada çözüm oranı, break‑glass olay sayısı.
• Aylık: kimlik bilgisi döndürme, sertifika sona erme kontrolleri ve simüle edilmiş bir olay müdahale tatbikatı (bir cihazı yedekten geri yükleyip SLA içinde bağlanma).
• Runbook'lar: yaygın hatalar için kısa bir runbook muhafaza edin (başarısız ajan kurulumu, sertifika uyumsuzluğu, relay erişilebilirliği). Düzeltme betiklerini değişiklik geçmişiyle birlikte kaynak kontrolde tutun.
• Denetim ve uyumluluk: oturum loglarının sözleşmeye göre saklandığından emin olun; düzenlemeye tabi müşteriler için daha uzun saklama süresini düşünün. Uygulama örnekleri için bkz. Uzak Masaüstü Denetim Kaydı.
• Yardım masası bağlantısı: teknisyenlerin güvenlik ve hız için gerekli asgari araç setine sahip olduğundan emin olun. İş akışı playbook'ları ve ticket odaklı oturumlar için bkz. Yardım Masası Uzak Destek Kurulumu.

Managed relay ile self-host arasında ne zaman seçim yapılmalı

Varsayılan: Tenvo'nun managed relay'ini kullanın. Bu, bölge failover'ı, sertifika dağıtımı ve 7/24 relay operasyonları yükünü kaldırır. Managed relay'ler onarım ortalama süresini düşürür çünkü relay altyapısını çalıştırmaz, sertifikaları bölgeler arasında yenilemez veya anahtar yönetimiyle uğraşmazsınız.

Self-host yalnızca müşteri sözleşmesi açıkça üçüncü taraf relay'leri yasaklıyorsa veya ağ izoleyse tercih edilmelidir. Self‑hosting, bir HA relay kümesi çalıştırmayı, otomatik sertifika yenilemeyi, izlemeyi ve yama yönetimini gerektirir — sürekli operasyonel personel ihtiyacını ve SLA riskini hesaba katın. Self-host takaslarının teknik bir anlatımı için bkz. Self-Hosted Remote Desktop: Why, How, and What Breaks. Tedarikçileri karşılaştırıyorsanız, bu MSP uzak destek araçları makalesi operasyonel farkların boyutlandırılmasına yardımcı olur.

Pratik betikler, kurucu örnekleri ve doğrulama komutları

REM Windows MSI silent install (example)
msiexec /i "tenvo-agent.msi" /qn /norestart /l*v "C:\Windows\Temp\tenvo-install.log"

# PowerShell: verify agent is installed and running
Get-Service -Name TenvoAgent | Select-Object Name, Status

# Powershell: check certificate thumbprint and expiry (local store)
Get-ChildItem -Path Cert:\LocalMachine\My | Where-Object { $_.Subject -like "CN=tenvo-*" } | Select-Object Subject, Thumbprint, NotAfter

# macOS: pkg install and verify
sudo installer -pkg tenvo-agent.pkg -target /
launchctl list | grep com.tenvo.agent

# Test connectivity: verify P2P vs relay (example agent tool)
tenvo-agent --diag --show-connection
# Expect output: P2P:true or Relay:us-east.tenvo.net

Güvenlik notları ve gerçeklik kontrolü

Tehdit modeli konusunda müşteriye açık olun: doğrudan peer‑to‑peer oturum iki cihaz arasında uçtan uca şifrelidir. Bağlantı relay'e döndüğünde, TLS relay'de sonlanır; bu nedenle relay'i işleten kişi oturum trafiğini görebilir. Tenvo'nun managed relay'i varsayılan olarak cihaz başına sertifikalar ve çok bölgelik relay'ler kullanır; bu operasyonel riski azaltır ama relay'leri erişim gücüne sahip bir altyapı olarak ele alma ihtiyacını ortadan kaldırmaz. Müşteri üçüncü taraf relay operatörlerini tolere edemiyorsa, self‑hosting planlayın ve sürekli operasyonel işi bütçeleyin.

Yaygın tuzaklar ve nasıl kaçınılır

• Herkese aynı anda dağıtım: yardım masasında aşırı yük oluşturur. Dağıtımı departmana göre kademeli yapın ve dağıtım sırasında ticket kuyruğunu izleyin.
• Sertifika kontrollerini atlamak: otomatik sona erme kontrolleri planlayın ve <30 gün kalan sertifikalar için uyarı oluşturun.
• Break‑glass denetim izi yok: herhangi bir acil erişim kötüye kullanımı önlemek için denetim ticket'ı ve kayıt gerektirmelidir.
• Self‑host'un daha ucuz olduğunu varsaymak: maliyet modellerine nöbet, yama, yedeklemeler ve failover testi maddelerini dahil edin. Gerçekçi bir TCO karşılaştırması için ilgili MSP araç analizine bakın: MSP uzak destek araçları: 2026 için doğru yığını seçmek.

Yeni bir müşteri filosunun onboarding'i büyük ölçüde koordinasyon ve otomasyon gerektirir: envanteri doğru alın, erişimi ve kimlik bilgilerini kilitleyin, izlemeyi işe yarar hale getirin ve tekrarlayan düzeltmeleri ilk 14 gün içinde otomatikleştirerek yangın söndürmeyi bırakıp istikrarlı operasyon sunmaya başlayın. Eğer relay operasyonlarını atlamak için müşteri‑hazır bir ajan ve yönetilen relay istiyorsanız, istemcileri indirip bugün bir pilot test başlatın.

Tenvo'yu indir ve bir pilot dağıtımı başlatıp bu 14 günlük playbook'u takip edin. Daha derin yapılandırma örneklerine veya bir geçiş kontrol listesine ihtiyacınız varsa, belgelerimiz ve yukarıdaki bağlantılı makaleler adım adım rehberler içerir.