Demander une solution de serveur sans engagement
Virtualisation - VMware, VirtualBox
La virtualisation a toujours été une étape naturelle, et ce, dès le lancement de nos solutions sur serveur. Le moyen le plus simple de déployer Easy Project consiste à faire cela sur nos machines virtuelles préconfigurées pour des performances optimales. Les machines compatibles VMware et VirtualBox sont fournies sans frais supplémentaires. Pour un coût très réduit, nous pouvons également fournir une machine virtuelle Hyper-V.
Nous avons également lancé deux versions gratuites de VM pour la communauté Easy Project.
Installateur Easy Project
Notre outil le plus demandé à ce jour. Si vous choisissez d’installer Easy Project directement sur le serveur, cet outil vous facilitera grandement les choses. Il suffit de lancer une simple commande, puis suivre les instructions de l’assistant. Vous n’avez nullement besoin d’effectuer manuellement des installations, des migrations, des tâches « rake », des mises à jour de « gem », etc. L’installateur Easy Project fait tout de façon automatique, réduisant ainsi au minimum le risque d’erreur humaine.
Le programme d’installation d’Easy Project est également disponible sur nos machines virtuelles. Vous pouvez donc l’utiliser pour des mises à jour régulières.
Vérification des exigences du serveur Easy
Le fonctionnement d’Easy Project dépend de divers systèmes d’exploitation, ce qui est absolument normal dans cette ère de technologie intégrée. Pour que cette dépendance entre divers systèmes puisse fonctionner de façon bien cohérente, nous avons conçu un outil très simple qui vérifie la disponibilité et la validité des composants les plus importants sur le serveur. L’administrateur n’a qu’à lancer une simple commande pour trouver le statut de chaque exigence. Les informations obtenues sont importantes non seulement pour l’administrateur avant qu’il ne procède à toute installation ou mise à jour, mais également pour notre personnel d’assistance qui peut les consulter pour vous répondre clairement si d’éventuels problèmes surviendraient.
Manuel et lignes directrices
L’environnement serveur est une jungle informatique où diversesentités devraient cohabiter en une parfaite synchronisation. Pour assurer cela, il faut avoir une expérience considérable et être continuellement au courant de tout progrès récent dans les nouvelles technologies. Pour toutes les configurations et tous les composants les plus importants liés à nos applications, nous publions des manuels d’instructions et des lignes directrices qui aident les administrateurs à effectuer les maintenances régulières des serveurs.
Cela comprend : manuels d’installation, mises à jour Ruby, configurations serveur, commandes utiles ou erreurs de serveur courantes, etc.
Limitations de la solution serveur
Flexibilité d’assistance
Bien que nous nous efforcions toujours de fournir aux clients autant d’informations et d’outils utiles pour le bon fonctionnement de leurs applications autohébergées, nous ne pouvons malheureusement pas avoir un contrôle direct et complet sur leur environnement. Cela signifie que nous ne pouvons pas effectuer des maintenances directement sur le serveur et que nous ne pouvons pas non plus rechercher les causes des éventuelles erreurs qui pourraient y survenir, ce qui nous contraint à deviner seulement des solutions envisageables lors de notre assistance.
L’assistance serveur à distance assurée par nos administrateurs est accessible en tant que service payant. De plus, le temps de résolution est toujours plus long par rapport à une solution de Cloud - tout simplement à cause des dispositions nécessaires avant que l’accès au serveur client puisse être établi. Voilà qui nous mène au point suivant:
Restrictions et problèmes d’accès
Dans la plupart des cas, lorsqu’un client fait appel à une assistance serveur, celui-ci ne peut pas fournir d’accès direct au serveur, mais plutôt une session de contrôle à distance via des applications telles que TeamViewer. C’est toujours mieux que de ne pas avoir d’accès du tout, mais de par notre expérience, nous avons remarqué qu’il y a une diminution significative en flexibilité et une augmentation en temps de résolution dans le cas de l’utilisation d’outils de contrôle à distance contrairement à l’accès direct (SSH), c’est-à-dire des problèmes de connexion avec l’hôte hébergeant, retard et perte de contrôle lorsque le client utilise l’ordinateur, etc. Cela peut aller jusqu’à 50 % de plus en temps de résolution qu’avec un accès SSH.
Planification
La demande d’administrateurs de serveur est plus importante que l’offre, ceci est malheureusement une triste réalité. L’assistance serveur n’en fait pas exception. C’est pour cette simple raison que toute assistance serveur doit être programmée à l’avance afin de disposer du temps nécessaire et suffisant pour une résolution complète du problème en question.
Cela est particulièrement vrai si la seule option d’accès consiste en un contrôle à distance où l’administrateur du client doit alors être présent. Si le client nous fournit un accès SSH, notre intervention est plus efficace. Dans ce cas, notre administrateur peut commencer la résolution des problèmes du serveur immédiatement après qu’il en obtient l’accès et n’a pas besoin de s’adresser à l’administrateur du client.
Vérification des rapports de bogue
Il n’est pas exagéré de dire que chaque environnement de serveur est différent. Avec autant d’options de configuration, on pourrait penser qu’il est pratiquement impossible d’avoir deux serveurs identiques. C’est souvent la raison pour laquelle nous ne pouvons pas simuler en interne un comportement spécifique décrit par le client et susceptible de créer un bogue.
Si un service utilisant notre application est configuré différemment de nos recommandations, cela ne signifie pas nécessairement que ce service est incompatible, mais qu’il pourrait entraîner des problèmes dans l’application qu’il est difficile de retracer dans la configuration recommandée.
