GoMyid’i Kendi Altyapınızda Çalıştırmayı Planlama

Uzak masaüstü hizmetini kendi altyapınızda barındırdığınızda, bağlantının arkasındaki sistemi işletme sorumluluğu da kuruluşunuza geçer. Yalnızca istemci uygulamasını değil, erişimin sürekliliğini sağlayan ortamı da planlamanız gerekir. Sorumlulukların dağılımı, kurulum ayarları, bakım, kurtarma ve arıza durumunda izlenecek süreç bu planın parçalarıdır. Daha fazla denetim sahibi olmak, bakım ve işletim görevlerinin sorumlularını açıkça belirlemeyi de gerektirir.

Bu rehber, GoMyid’i kendi altyapısında çalıştırmayı değerlendiren kuruluşlara planlama konusunda yardımcı olur. Bir kurulum talimatı değildir ve güncel ürün gereksinimlerinin yerine geçmez. Kurulum öncesinde neleri doğrulamanız gerektiğini, sınırlı bir pilot çalışmayı nasıl düzenleyebileceğinizi ve platformu günlük destek işlerinde kullanmaya başlamadan önce hangi işletim sorularını yanıtlamanız gerektiğini açıklar.

Kendi altyapınızdaki pilot çalışma sırasında Android bağlantı kaynağını kontrol edin

Mobil pilot çalışmadaki bir sorunu sunucu kesintisi olarak değerlendirmeden önce, Android uygulamasının hangi hizmeti kullanacak şekilde yapılandırıldığını kontrol edin. Belgelenen yol Ayarlar > İş > Bağlantı kaynağı'dır. Üç seçenekte girilmesi gereken bilgiler farklıdır.

1. Ücretsiz Bulut: GoMyid'in genel bağlantı sunucularını otomatik olarak kullanır. Kılavuzda, bu mod için Business ID'nin gerekli olmadığı belirtiliyor.
2. Bulut: kuruluş tarafından sağlanan Business ID ile GoMyid Cloud hizmetini kullanır. İş cihazlarına erişmek için oturum açın.
3. Şirket İçi: kuruluşun kendi GoMyid sunucusunu kullanır. Yönetici tarafından sağlanan DNS adını veya IP adresini ve İşletme Kimliğini girin.

Şirket içi pilot için örnek çizimi kopyalamak yerine bu değerleri kurulumdan sorumlu kişiden alın. Eksik iş cihazı listesini teşhis etmeden önce seçilen kaynağı kontrol edin. Kaydedilmiş bir yerel kısayol ile kurumsal cihaz dizini farklı şeylerdir: Android kılavuzu, yerel listenin çevrimiçi/çevrimdışı durumunu görüntülemediğini söylerken iş listesinde yeşil ve gri durum noktaları kullanılır. Başka bir teknisyenin aynı kontrolü yeniden yapabilmesi için hangi kaynağı ve listeyi doğruladığınızı kaydedin. Bu bir istemci yapılandırma adımıdır; sunucunun kendisini kurmanın veya doğrulamanın yerine geçmez.

Kendi altyapınızda barındırılan uzak masaüstü ne anlama geliyor?

Kendi altyapınızda barındırdığınız bir yapıda kuruluşunuz, ilgili hizmet altyapısını yönettiği veya yönetmeyi ayarladığı bir ortamda çalıştırır. Tam bileşenler ve sorumluluklar ürüne ve dağıtıma bağlıdır. Mimarinin tamamını yalnızca ifadeden çıkarmayın. Gerçek GoMyid kurulum kılavuzunu inceleyin ve istemcilerin, yönetim işlevlerinin ve destek hizmetlerinin birbirine nasıl uyduğunu doğrulayın.

Kendi altyapısında barındırma (self-hosted) ve şirket içi kurulum (on-premises) ilişkili kavramlardır, ancak her zaman aynı durumu anlatmazlar. Şirket içi genellikle bir kuruluşun bulunduğu yerdeki altyapıyı ifade eder. Hizmeti kendi altyapınızda barındırmak, hizmeti kimin işlettiğini vurgular ve başka bir kontrollü barındırma ortamını içerebilir. Herkesin sistemin nerede çalıştığını ve bundan kimin sorumlu olduğunu anlaması için planınızda net bir dil kullanın.

Asıl soru, bir etiketin kulağa daha güvenli mi yoksa profesyonel mi geldiği değildir. Düzenlemenin gereksinimlerinizi karşılayıp karşılamadığı ve ekibinizin bunu sürdürüp sürdüremeyeceğidir. İyi anlaşılmış bir çalışma modeli, bir etiket için seçilen mimariden daha değerlidir. İş ve sorumluluklarla başlayın, ardından bunları destekleyen teknik tasarımı onaylayın.

Bir kuruluş neden hizmeti kendi altyapısında barındırmayı düşünebilir?

Bazı kuruluşların dağıtım kararları, altyapı yönetimi veya bir hizmetin mevcut operasyonlara uyum şekli üzerinde doğrudan kontrole ihtiyacı vardır. Diğerleri ise destek ekipleri ve yönetilen cihazları için tanımlanmış bir ortam istiyor. Bunlar tartışılması yararlı gereksinimlerdir ancak somut terimlerle yazılmaları gerekir. Neyin dağıtılması veya sürdürülmesi gerektiğine karar vermek için "Kontrol istiyoruz" yeterli değildir.

Doğrudan söz sahibi olmanız gereken kararları listeleyin. Örnekler arasında bakımın planlanması, yönetilen ortamın seçilmesi, operasyonel sorumluluğun atanması veya kurtarmanın diğer dahili hizmetlerle koordine edilmesi yer alabilir. Ardından önerilen GoMyid düzenlemesinin size ilgili kontrolü verip vermediğini ve bununla birlikte hangi yükümlülüklerin geldiğini sorun. Bu seçeneğin sunulup sunulmadığını varsayımlara dayanmak yerine güncel ürün bilgileriyle doğrulayın.

Ayrıca işletim modelini daha basit tutmanın nedenlerini de göz önünde bulundurun. Ekipte altyapıdan sorumlu belirli bir kişi yoksa veya bakım ve kurtarmayı destekleyemiyorsa, hizmeti kendi altyapınızda barındırmak, yönetmeye hazır olmadığı bir bağımlılık yaratabilir. Bu uzaktan erişimi dışlamaz. Bu, dağıtım seçiminin kuruluşun tercihlerinin yanı sıra yetenekleriyle de eşleşmesi gerektiği anlamına gelir.

Kurulumdan önce sorumluları belirleyin

Hizmet ortamından, uygulama yapılandırmasından ve günlük destekten sorumlu kişiyi veya ekibi adlandırın. Bunlar farklı sorumluluklar olabilir, ancak görevlerin birbirine nasıl devredileceği açık olmalıdır. Kullanıcılar başarısız bir bağlantı bildirirse, sorunun kime ait olduğunu tahmin etmeden istemcinin mi, yönetilen cihazın mı yoksa destek ortamının mı araştırılacağını birisinin bilmesi gerekir.

Değişiklikleri kimlerin onaylayabileceğini ve bunları kimlerin gerçekleştirebileceğini tanımlayın. Uç noktaları destekleyen bir teknisyenin mutlaka her altyapı ayarı üzerinde yetkiye ihtiyacı yoktur. Sorumlulukları işle uyumlu tutun. Harici bir sağlayıcı söz konusu olduğunda, hangi görevleri yerine getirdiğini ve kuruluşunuzun bu görevleri nasıl talep ettiğini veya doğruladığını belgeleyin.

Asıl sorumlunun bulunmadığı durumlar için plan yapın. Başka bir yetkili kişi, mevcut dağıtım bilgilerini bulabilmeli ve asıl sorumlunun müsait olmaması durumunda temel işlemlere devam edebilmelidir. Bu bilgileri yalnızca kişisel bir not defterinde veya bir sohbet dizisinde değil, onaylanmış idari konumda saklayın. Kimlik bilgilerini genel bir işletim kılavuzuna yerleştirmek yerine kuruluşun uygun güvenli sürecinde saklayın.

Ürün kılavuzundan mevcut gereksinimleri doğrulayın

Desteklenen ortamı oluşturmak için mevcut GoMyid’in kendi altyapınızda kurulumla ilgili bilgilerini ve kurulum materyalini kullanın. Gerçekte dağıtmakta olduğunuz teklif için gerekli bileşenleri, desteklenen sürümleri ve yapılandırma sorumluluklarını onaylayın. Ürüne genel bakış, iş akışlarını anlamak açısından faydalıdır ancak tam bir bağımlılık veya kurulum spesifikasyonu değildir.

Başka bir uzak masaüstü ürününün ayarlarını GoMyid’e olduğu gibi aktarmaktan kaçının. Tanıdık bağlantı noktası numaraları, hesap varsayımları veya Windows yapılandırma adımları GoMyid'in mimarisiyle ilgisiz olabilir. Bunları kopyalamak gereksiz güvenlik açıkları oluşturabilir veya sorun gidermeyi zorlaştırabilir. İlgili belgelerden ve ortamınızın onaylanmış standartlarından dağıtım kontrol listesini oluşturun.

Destek açısından önemli olan sürümleri ve yapılandırma kararlarını kaydedin. Bu size bir güncelleme veya ortam değişikliği sonrasında davranış değiştiğinde bir temel sağlar. Kaydı sürdürecek kadar kısa tutun. Kısa sürede güncelliğini yitiren ayrıntılı bir belge, sistemi çalıştırmak için gereken bileşenler, sorumlular ve kararlardan oluşan güncel bir listeden daha az kullanışlıdır.

Erişimi kişiler ve cihaz grupları etrafında tasarlayın

Çok sayıda bilgisayar eklemeden önce, destek ekibinin bunları nasıl tanımlayıp onlara nasıl ulaşması gerektiğine karar verin. GoMyid'in yönetime genel bakışı cihaz gruplarını, istasyon kayıtlarını, yönetici yeteneklerini ve sayfa izinlerini gösterir. Bu kontroller, farklı destek sorumluluklarına sahip ekipler veya konumlar gibi grup yapısı gerçek operasyonel sınırları yansıttığında faydalıdır.

Diğer yöneticilerin anlayabileceği grup adlarını seçin. Yalnızca bir kişinin anlayabildiği kısaltmalara dayanan bir yapı kullanmaktan kaçının. Çalışanlar veya ofisler değiştiğinde cihazların gruplar arasında nasıl taşınacağını planlayın. Dağıtım statik değildir ve erişim modeli, sorumlulukların takibini kaybetmeden normal yeniden atamayı mümkün kılmalıdır.

Yetenek ve kapsamı birlikte inceleyin. Bir teknisyenin, her testin başarılı olmasını sağlayacak tek bir geniş role değil, doğru cihazlar için uygun eylem izinlerine ihtiyacı vardır. Yönetilen erişim kılavuzu bu ilişkiyi açıklamaktadır. Erişimi genişletmeden önce amaçlanan davranışı sınırlı yetkili bir grupla doğrulayın.

Uç noktaların kaydını ve tanımlanmasını planlayın

İlk kullanıma hangi cihazların dahil olacağına ve her birinin nasıl tanımlanacağına karar verin. Başlangıç ​​grubunu, her kaydı gerçek bir bilgisayarla doğrulayabilecek kadar küçük tutun. Pilot uygulamayı hemen tam dağıtıma dönüştürmeden, standart bir iş istasyonu ve ikinci konumdaki bir cihaz gibi sıradan işleri temsil edecek yeterli varyasyonu ekleyin.

Onaylanan uç nokta süreci aracılığıyla kurulumu veya yapılandırmayı koordine edin. Çalışanlar nelerin değiştiğini, nasıl destek talep edeceklerini ve cihazlarına hangi erişim düzenlemesinin geçerli olduğunu bilmelidir. Bir istemci kurmanın cihazı kullanıma hazırlamak için gereken bütün çalışma olduğunu varsaymayın. Cihaz sahipliği, destek kapsamı ve kullanıcı beklentileri aynı anda belirlenmelidir.

Kayıt işleminin bir parçası olarak kaldırmayı planlayın. Kullanımdan kaldırılan veya yeniden atanan bir bilgisayar süresiz olarak belirsiz bir durumda kalmamalıdır. Kaydı kimin güncelleyeceğine ve sürekli erişimi kimin inceleyeceğine karar verin. cihaz dizini kılavuzu, ortam büyüdükçe bu bağlamın korunmasına yönelik pratik bir yaklaşım sunar.

Ağ ve kimlik kararlarını koordine edin

Altyapıdan sorumlu kişilerle ürünün belgelenen bağlantı gereksinimlerini gözden geçirin. Amaçlanan bağlantı yollarını ve ilgili idari sınırları tanımlayın. Geniş erişimi açıp daha sonra daraltmayı ummak yerine gereksinimleri açıkça belirtin. Dağıtımın gerekli her bağlantı için bir nedeni olmalıdır.

Adları, adresleri ve kimlikle ilgili yapılandırmayı onaylanmış tasarımla tutarlı tutun. Ortamda sertifikalar veya başka aktarım yapılandırması kullanılıyorsa dağıtımın bir parçası olarak bunların bakımından sorumlu kişileri belirleyin. İlk başarılı bağlantıyı bu ayrıntıların sonsuza kadar doğru kalacağının kanıtı olarak görmeyin. Bazı yapılandırmaların kurulum gününün ötesine uzanan bir yaşam döngüsü vardır.

Desteklemeyi beklediğiniz gerçek konumlardan ve cihaz türlerinden test yapın. Bir ofis içindeki bağlantı her uzak yolu göstermez. Pilotun nerede test edildiğini ve nerede yapılmadığını kaydedin. Bu, daha sonraki kararların sistemin "her yerde çalıştığına" dair genel bir ifade yerine kanıtlara dayalı olmasını sağlar.

Hizmet gerekli hale gelmeden önce kurtarmayı planlayın

Seçilen dağıtımda nelerin kurtarılabilir olması gerektiğini belirleyin. Bu, uygulama yapılandırmasını, gerekli verileri ve ürün ile işletim modeliniz tarafından tanımlanan diğer bileşenleri içerebilir. Gerçek kapsamı belirlemek için mevcut kurulum ve çalıştırma kılavuzunu kullanın. Görünür bir klasörün kopyalanmasının, hizmetin tam durumunu yakaladığını varsaymayın.

Yedekleme işlemi ve geri yükleme doğrulaması için sorumluluk atayın. Başarıyı bildiren bir yedekleme işi faydalıdır ancak tek başına hizmetin çalışır duruma getirilebileceğini kanıtlamaz. Ortama uygun kontrollü bir kurtarma kontrolü planlayın. Doğrulamanın önlenebilir bir kesinti yaratmaması için bunu müşteriye yönelik çalışmalardan ayrı tutun.

Kurtarma sürecindeki görev dağılımını da belirleyin. Geri yüklemenin gerekli olduğuna kim karar veriyor, bunu kim gerçekleştiriyor ve daha sonra uç nokta erişimini kim doğruluyor? Normal destek yolu etkilenen sisteme bağlıysa kullanıcılar güncellemeleri nasıl alacak? Kurtarma planı, yalnızca teknolojileri listelemek yerine, baskı altındaki bir sonraki eylemi açıklamalıdır.

Güncellemelere ve bakıma öngörülebilir bir süreç kazandırın

Bakımdan sorumlu kişiyi ve iletişim yöntemini belirleyin. Bir değişiklik yapmadan önce mevcut durumu ve amaçlanan sonucu kaydedin. Kullanıcıların erişimi geçici olarak kaybedip kaybedemeyeceğini ve hangi işlerin kaydedilmesi veya yeniden planlanması gerektiğini belirleyin. Az miktarda koordinasyon, planlı bir güncellemenin destek ekibine açıklanamayan bir kesinti gibi görünmesini engelleyebilir.

Ürünün desteklenen güncelleme sürecini kullanın ve ilgili uyumluluk gereksinimlerini inceleyin. Ortamda zaten bakım yapılıyor diye ilgisiz değişiklikleri birleştirmeyin. Birden fazla bileşenin aynı anda güncellenmesi, arızanın teşhis edilmesini zorlaştırabilir. Odaklanmış bir değişiklik, sonucu doğrulamanız ve kurtarmanın gerekli olup olmadığına karar vermeniz için size daha net bir yol sunar.

Bakımdan sonra temsili bir destek iş akışını tekrarlayın. Hedeflenen yöneticinin amaçlanan cihaza ulaşabildiğini ve beklenen eylemi tamamlayabildiğini doğrulayın. Bir oturum açma sayfasının veya çalışan bir işlemin varlığından daha fazlasını kontrol edin. Yararlı sonuç, yalnızca bir bileşenin başladığının kanıtı değil, insanların güvendiği çalışan hizmettir.

Operasyonel soruları yanıtlayan bir pilot çalışma yürütün

Normal kullanımı temsil eden birkaç görev seçin: bir masaüstü destek oturumu, onaylanmış bir dosya aktarımı ve yönetim dizini aracılığıyla bir cihaz bulma. Destek alacak kişilerin yanı sıra desteği sağlayacak operatörleri de dahil edin. İş akışının nerede kafa karıştırıcı olduğunu ve hangi talimatların açıklığa kavuşturulması gerektiğini sorun.

Çalışmanın sonunu test edin. Bağlantıyı kesin, sonucu kullanıcıyla doğrulayın ve erişimin devam edip etmeyeceğini inceleyin. Cihaz kapsamının nasıl güncellendiğini bilmeniz için normal bir sorumluluk değişikliği ekleyin. Yalnızca yöneticilerin bağlantı kurabildiğini kanıtlayan bir pilot program, erişimin doğru bir şekilde sürdürülüp kaldırılamayacağına ilişkin aynı derecede önemli olan soruyu gözden kaçırıyor.

Test edilen koşulların, gözlemlenen sınırlamaların ve çözülmemiş gereksinimlerin kısa bir kaydını tutun. Üretim ortamını gereksiz tanıtım kayıtlarıyla doldurmayın. Amaç, yaygınlaştırma kararını destekleyecek kanıt toplamaktır. Daha geniş bir değerlendirme yapısı için uzak masaüstü yazılımı kontrol listesini kullanın.

Normal çalışma sırasında nelere dikkat etmeniz gerektiğine karar verin

Hizmet ve destek sürecinin işe yarayıp yaramadığını size bildiren küçük bir sinyal kümesi seçin. Dağıtıma bağlı olarak bunlar, bağlantı sonuçlarını, oturum açma olaylarını veya yönetim çalışma alanındaki mevcut yönetim değişikliklerini içerebilir. Gerçekte nelerin kaydedildiğini ve sorumlu kişilerin bunları nasıl inceleyeceğini doğrulayın.

İncelenen her sinyale bir amaç verin. Tekrarlayan bir bağlantı arızası, yalnızca rapordaki bir sayıya değil, tanımlanmış bir araştırmaya yol açmalıdır. İdari bir değişiklik, onaylanmış bir görev bağlamında anlaşılabilir olmalıdır. Hangi soruyu yanıtlaması gerektiğini bilmeden geniş kapsamlı bilgileri toplamaktan veya dışa aktarmaktan kaçının.

İnceleme sırasında zaman ve kapsamı tutarlı tutun. Bir şubeden gelen destek talebi ilgisiz genel toplamlarla değil, ilgili cihaz ve dönemle karşılaştırılmalı. Sorun giderme aktarma kılavuzu, tahminleri sonuca dönüştürmeden teknik incelemenin ilerlemesine yardımcı olan bilgileri açıklar.

Nöbetçi ekip için bir işletim kılavuzu hazırlayın

Yararlı bir işletim kılavuzu, hizmet amacı, sorumlu ilgili kişiler ve bildirilen bir hataya yönelik ilk kontrollerle başlar. Onaylanan destek kanalını ve mevcut dağıtım bilgilerinin nerede muhafaza edildiğini tanımlamalıdır. Günlük işlemlerin adımlarını kolayca bulunabilecek şekilde düzenleyin. İşleme geçmeden önce kurulum geçmişinin tamamının okunmasını gerektiren bir belgenin kesinti sırasında kullanılması zordur.

Rutin gözlemleri önemli sonuçlar doğurabilecek işlemlerden ayırın. Bir hedefin kullanılabilir olup olmadığını kontrol etmek, bir hizmeti yeniden başlatmaktan veya verileri geri yüklemekten farklıdır. Bu son işlemleri kimin yetkilendirebileceğini ve gerçekleştirebileceğini belirtin. Operatörün başarılı bir sonucu nasıl anlayacağını bilmesi için değişiklik sonrasında beklenen doğrulamayı ekleyin.

İşletim kılavuzunu sistemi oluşturmayan biriyle birlikte inceleyin. Soruları, ilk kurulumu yapan kişinin fark etmeyebileceği varsayımları ortaya koyuyor. Anlamlı değişiklikler ve gerçek olaylardan sonra güncelleyin. Amaç sürekliliktir: Yetkili başka bir kişi mevcut ortamı anlayabilmeli ve bir sonraki uygun kararı verebilmelidir.

Dağıtımın genişletilmeye hazır olup olmadığına karar verin

Pilot programı orijinal gereksinimlere göre inceleyin. Hangi görevler işe yaradı, hangi yerler test edildi ve hangi sorumluluklar atanmadı? Boşluklar konusunda spesifik olun. Kurtarma işlemlerinden kimin sorumlu olduğu veya rutin bakım belirsizliğini koruyorsa başarılı bir masaüstü bağlantısı yeterli değildir. Sisteme bağlı olacak cihazları eklemeden önce önemli operasyonel belirsizliği çözün.

Yönetilebilir gruplar halinde genişletin ve yeni sorunları tanımlamanın bir yolunu tutun. Aşamalı dağıtım, konuma özgü bir sorunu genel bir dağıtım değişikliğinden ayırmayı kolaylaştırır. Çalışanların ne beklemesi gerektiğini ve nasıl yardım istemeleri gerektiğini anlatın. Destek süreci, istemciler kullanıma hazır olduğunda hazır olmalı, sonradan icat edilmemelidir.

Sistem rutin kullanıma girdikten sonra iş değiştiğinde planı yeniden gözden geçirin. Yeni konumlar, farklı cihaz türleri veya yeni bir destek sağlayıcı, işletim gereksinimlerini değiştirebilir. Hizmeti kendi altyapınızda barındırmak, tek seferlik bir kurulum aşaması olmaktan ziyade devam eden bir sorumluluktur. Sorumluluk atamalarını ve doğrulama uygulamalarını yazılımın kendisi kadar güncel tutun.

Bir çıkış ve geçiş planı tutun

Kuruluşun dağıtımı daha sonra nasıl değiştireceğini düşünün. Bir sunucu değiştirilebilir, bir destek sağlayıcı değişebilir veya işletme farklı bir işletim düzenlemesi seçebilir. Bu geçiş sırasında hangi kayıtların ve yapılandırma bilgilerinin bir sahibine ihtiyaç duyduğunu belirleyin. Ürünün desteklenen prosedürlerini kullanın ve bir taşıma işlemini görünürdeki dosyaların doğaçlama bir kopyası olarak görmekten kaçının.

Geçiş sürecine uç nokta kullanıcılarıyla iletişimi ve erişim incelemesini dahil edin. Kullanıcılar nelerin değişeceğini, daha sonra bunları kimin destekleyeceğini ve meşru bağlantı sürecini nasıl tanıyacaklarını bilmelidir. Yöneticiler, eski erişimin uygun kontroller yoluyla kaldırıldığını doğrulamalıdır. Sistem sağlıklıyken değişimi planlamak, aceleye gelen bir geçiş veya beklenmedik bir kesinti sırasında bu sorumlulukları keşfetmekten daha kolaydır.

Planlama toplantısında teknik bileşenlerin yanında günlük işletim görevlerini de isimlendirin. Güncellemeyi kimin değerlendireceği, bakım zamanını kimin duyuracağı, bir kesinti sırasında kimin karar vereceği ve kullanıcıların hangi kanaldan destek isteyeceği açık olmalıdır. Bu görevlerin tümü aynı kişide toplanıyorsa o kişi bulunmadığında ne olacağını da düşünün. Kendi altyapınızda çalıştırmak, yalnızca sunucunun fiziksel konumunu seçmek değildir; hizmetin devamlılığı için gereken kararların ve kontrollerin kuruluş içinde karşılığının bulunmasıdır.

Pilot çalışmayı küçük tutarken değerlendirmeyi de gereğinden daraltmayın. Bir bağlantının açılması başlangıç için önemlidir, fakat günlük işletimi tek başına kanıtlamaz. Yetkili kullanıcıların doğru cihazlara erişmesi, bağlantının kapatılması, bakım sırasında iletişimin sürmesi ve geri dönüş adımlarının anlaşılması da incelenmelidir. Bir kurtarma planının yazılı olmasıyla uygulanabilir olduğunun doğrulanması farklıdır. Denemeyi kurumun onayladığı kapsamda yürütün ve sonucu kaydedin. Açık kalan gereksinimleri tamamlanmış gibi göstermeyin; hangi konunun ürün desteğiyle, hangi konunun altyapı ekibiyle netleştirileceğini belirtin. Böylece yaygınlaştırma kararı tek bir başarılı gösterime değil, işletim koşullarını kapsayan somut bulgulara dayanır.

Sık sorulan sorular

Kendi altyapınızda barındırılan uzak masaüstü otomatik olarak daha güvenli midir?

Hiçbir dağıtım etiketi bir sonucu garanti etmez. Gerçek mimari, yapılandırma, erişim kontrolleri, bakım ve işletim uygulamaları önemlidir. Hizmeti kendi altyapınızda barındırmak, sorumlulukları değiştirir ve gereksinimlerinizle ilgili kontrolü sağlayabilir, ancak bu sorumlulukların yine de yerine getirilmesi gerekir. Etiketi tek başına bir kanıt olarak ele almak yerine, gerçekte faaliyet göstereceğiniz ortamı değerlendirin.

Bu makale kurulum kılavuzunun yerini alabilir mi?

Hayır. Sorumluluk dağılımı, pilot tasarım, bakım ve kurtarma için bir planlama kılavuzudur. Desteklenen bileşenler ve teknik gereksinimler için GoMyid'in mevcut kurulum malzemelerini kullanın. Başka bir üründeki genel uzak masaüstü ayarlarını uygulamaktan kaçının. Planlama ve kurulum birbirini tamamlar ancak farklı sorulara yanıt verirler.

Hizmeti kendi altyapısında barındırmak yalnızca büyük kuruluşlara mı uygundur?

Kuruluşun büyüklüğü dikkate alınan tek şey değildir. Küçük bir şirket, altyapı için açıkça belirlenmiş sorumlulara ve hizmeti işletmek için bir nedene sahip olabilirken, daha büyük bir şirket başka bir düzenlemeyi tercih edebilir. Gereksinimleri, mevcut becerileri ve devam eden iş yükünü değerlendirin. küçük işletme işletim modeli bölümü başka bir bakış açısı sağlar.

Pilot çalışma ne kadar sürmelidir?

Güvenmeyi düşündüğünüz önemli iş akışlarını ve olağan işletim olaylarını test edecek kadar uzun. Sabit sayıda gün, cevaplanan soruların net bir listesinden daha az faydalıdır. İlgili yerlerde temsili konumları, erişim değişikliklerini ve bakım sonrası doğrulamayı ekleyin. Pilot çalışmayı, sonuçları ve kalan işlerin sorumlularını belgeleyerek tamamlayın.

Başarılı bir kurulumdan sonra genellikle gözden kaçırılan şey nedir?

Devam eden insan sorumlulukları: Güncellemeleri kim yönetir, kurtarmayı kim doğrular, cihaz atamalarını kim sürdürür ve erişim başarısız olduğunda kim müdahale eder. Kurulum bilgili bir kişi tarafından tamamlanabilir ancak rutin operasyonun sürekliliği gerekir. Hizmet, ekibin destek çalışması için zorunlu hale gelmeden önce bu sorumlulukları görünür hale getirin.

GoMyid’i kendi altyapımızda çalıştırmayı düşünüyorsak ilk olarak ne yapmalıyız?

Hizmeti kendi altyapınızda barındırmanın nedenini yazın ve işletimden sorumlu kişiyi belirtin. Daha sonra mevcut ürün gereksinimlerini gözden geçirin ve sınırlı yetkili bir pilot planlayın. Yalnızca oturum açma işleminin başarılı olup olmadığını kontrol etmek yerine destek görevlerinin tamamını bu pilot uygulamaya dahil etmek için erişim kapsamı kılavuzunu ve ekip dosya aktarımı iş akışını kullanın.

Arayüz referansı: GoMyid Android Ürün Kılavuzu, sürüm 1.0.68, Eylül 2026, sayfa 9. Bu makalede belgelenen örnek arayüz kullanılmaktadır; canlı bir kurulumda test yapıldığı iddiasında bulunmaz.