Telekom Cloud. Avec un concept d'exploitation clair.

Au départ se pose la question de ce dont votre application a réellement besoin : puissance de calcul, gestion des données, accessibilité et connexions aux systèmes existants. Une liste de serveurs souhaités ne dit pas encore quels composants doivent collaborer ni comment la charge et le volume de données vont évoluer. Nous recensons ensemble ces relations et distinguons les exigences fermes des hypothèses. Sur cette base, nous préparons une sélection appropriée de services Telekom Cloud. Les ressources déjà existantes sont prises en compte, afin que des structures qui fonctionnent ne soient pas remplacées sans raison métier.

Pour la mise en place, les environnements, les droits et les zones réseau sont attribués de façon à ce que votre équipe puisse comprendre la structure. Les systèmes de test et les applications de production bénéficient chacun du cloisonnement nécessaire. Nous clarifions en outre comment de nouvelles ressources viennent s'ajouter et qui approuve les changements. La documentation décrit non seulement l'état initial, mais aussi les voies d'extension prévues. C'est particulièrement important lorsque plusieurs équipes internes ou partenaires applicatifs externes travailleront ensuite sur le même environnement.

Une application dans la Telekom Cloud peut continuer à dépendre d'une gestion des utilisateurs locale, de sources de données ou d'autres sites. Ces connexions doivent donc être prises en compte tôt dans la planification. Nous vérifions ensemble les flux de données, la résolution de noms et les règles d'accès nécessaires. Nous examinons aussi quels processus doivent encore fonctionner en cas de connexion interrompue. De ces exigences résulte un périmètre de test qui reflète la communication de l'application et ne se limite pas à l'accessibilité isolée de ressources individuelles.

Lors de la reprise des données, le mode de transfert, l'état des données et la vérification métier sont coordonnés entre eux. Qui confirme que l'application fonctionne correctement avec les données reprises ? Jusqu'à quand des modifications sont-elles autorisées dans l'ancien système ? Quelle sauvegarde est disponible avant une bascule ? Les réponses déterminent le déroulement et les responsabilités. Après la mise en place technique, nous accompagnons les tests convenus et consignons les points encore ouverts. La reprise devient ainsi une transition coordonnée, dont le succès peut être évalué sur le plan métier par votre équipe applicative.

Un service cloud fourni ne prend pas automatiquement en charge toutes les tâches liées au système d'exploitation, aux données et à l'application. Avant le début de la prise en charge, nous distinguons donc la prestation de plateforme souscrite des travaux qui interviennent dans votre environnement. Cela comprend par exemple les changements de configuration, la gestion des autorisations, les tests métier après les mises à jour et le traitement des incidents. Les responsabilités de Telekom ou de T-Systems, d'OTOKO® et de vos propres équipes sont consignées pour l'existant concret, plutôt que de se limiter à désigner des domaines de responsabilité généraux.

Le périmètre de prise en charge qui en découle décrit les composants, les horaires de service et les circuits de notification. Pour les incidents, il est précisé qui assure la première évaluation et comment les autres parties concernées sont associées. Des responsables sont également désignés pour la maintenance et la restauration. Si une partie des tâches reste à votre service informatique, cette part qui vous revient est explicitement documentée. Cela facilite la planification des capacités et permet de discuter des extensions ultérieures : une nouvelle application peut être confrontée au périmètre existant avant que des tâches d'exploitation supplémentaires n'apparaissent tacitement.