Infogérance

Infogérance

L'infogérance d'une plateforme englobe l'ensemble des tâches entre la fourniture des infrastructures (machines physiques ou virtuelles, routeurs, SAN…) et le déploiement des applications métier. 

Dans un monde idyllique, vous n'avez pas besoin d'infogérance, parce que vos machines ne tombent jamais en panne, vous disposez toujours de suffisamment de place disque, de mémoire, et de temps CPU sur vous serveurs ; vous ne perdez jamais de données, personne ne réinitialise accidentellement la base de données de production en pensant que c'était celle de pré-prod' ; vous n'avez donc pas besoin de backups ; personne ne tente jamais de s'introduire sur vos serveurs à des fins hostiles, et les failles de sécurité n'existent pas.

Dans le monde réel, vous devez composer avec tous ces aléas (et quelques autres!), ce qui constitue une distraction qui vous éloigne de votre cœur de métier et vous fait perdre du temps et de l'argent. À moins que votre métier ne soit précisément l'administration système, vous avez tout intérêt à confier l'infogérance de vos machines à des spécialistes rompus à cet exercice.

L'infogérance selon Enix

Quand un client nous confie la gestion d'une infrastructure, nous suivons un ensemble de principes et appliquons un ensemble de procédures qui sont les mêmes que pour nos propres équipements.

  1. Visiblité : quels sont les services ? Sait-on à tout moment dans quel état ils se trouvent ?
  2. Réactivité : si quelque chose ne tourne pas rond, combien de temps faut-il pour rétablir ?
  3. Proactivité : peut-on anticiper les problèmes, au lieu de passer son temps à jouer aux pompiers ?

Une visibilité absolue sur votre infrastructure

« Si un service ou un serveur n'est pas dans mon Nagios, il n'existe pas ! » — Le vénérable Nagios a laissé la place à des alternatives plus modernes, mais nous suivons toujours ce vieux principe : pour assurer la disponibilité d'un service, il faut commencer par savoir qu'il existe ! À partir de là, il faut aussi être capable de dire s'il fonctionne en ce moment ou pas.

Une de nos premières tâches lors de la prise en main d'une infrastructure est donc sa carthographie, suivie de la mise en place de health checks qui vérifient en permanence la santé des composants identifiés.

Après le qualitatif, vient le quantitatif. C'est donc là qu'on ajoute une collecte de métriques la plus complète possible : c'est la métrologie. L'identification des problèmes passe très souvent par la comparaison et la corrélation des données de supervision dans le temps - les métriques - par rapport à un état nominal. Il faut être le plus méthodique et exhaustif possible. Peut-être qu'aujourd'hui, cela n'intéresse personne de savoir combien il y a connexions actives sur la base de données MySQL (il y en a 87!), mais le jour où celle-ci ne répond plus, cela fait partie des données à analyser — et ce jour là, il sera indispensable de savoir si 87 est une valeur typique ou anormale pour cette métrique.

Une bonne métrologie doit englober des métriques d'infrastructure (fournies, par exemple, par les équipements réseau), serveur (incluant, par exemple, des données environnementales de température, pour les serveurs physiques), système, applicatives, mais aussi métier. Ce dernier point est particulièrement important, car pour citer Charity Majors : « Five nines don't matter if your users aren't happy » — autrement dit, ça ne sert à rien d'avoir un taux de disponibilité de 99,999% (ce qui constitue un score exceptionnellement haut) si vos utilisateurs, qui demeurent les seuls vrais juges, ne sont pas satisfaits du service rendu. En termes concrets, cela veut dire qu'au lieu de s'inquiéter lorsque le taux d'utilisation CPU relevé sur le serveur web n°42 dépasse 95% pendant plus de dix minutes, il conviendrait plutôt de s'inquiéter (par exemple) d'un nombre d'utilisateurs actifs en dehors de la moyenne sur cette période.

Toutes ces informations doivent être centralisées, de manière à être accessibles rapidement (lorsqu'il faut être capable d'avoir une vue d'ensemble pour comparer, superposer et synthétiser les données disponibles) et uniformément (pour faciliter la seconde phase qui est la mise en place d'alertes et de remédiations automatiques).

Être alerté et répondre rapidement

Une fois que l'on dispose d'une mine d'informations qualitatives et quantitatives sur une application et son socle technique, c'est le moment de mettre en place des alertes sur les éléments clés. C'est là que l'expérience est indispensable, pour juger et arbitrer entre ce qui nécessite une réponse rapide (indisponibilité d'un site, élévation des temps de réponse au-delà de l'acceptable…) et ce qui ne justifie pas de réveiller (et donc d'user...) une équipe d'astreinte à 3h du matin (élévation de l'utilisation CPU, indisponibilité d'un seul serveur sur un ensemble redondé situé derrière un load balancer…)

Idéalement, à chaque alerte est associé un runbook, qui indique un ensemble de vérifications et d'actions à entreprendre. Le but est de mettre un maximum d'information à disposition de l'équipe d'astreinte. Lorsqu'une alerte se reproduit plusieurs fois, nos équipes font preuve de pragmatisme : d'un côté, nous œuvrons pour identifier la cause profonde de l'alerte et la corriger afin qu'elle ne se produise plus ; de l'autre, nous automatisons les correctifs. Dans de nombreux cas, l'exécution automatique d'un correctif permet de résoudre l'alerte, permettant d'allouer davantage de temps au travail de fond plutôt qu'à « éteindre des feux ».

Avoir un coup d'avance

Lorsqu'on maîtrise l'ensemble d'un système, on est capable de prédire certains problèmes avant qu'ils n'impactent les utilisateurs. Un exemple tout simple : s'il reste 10 giga-octets d'espace disque sur un serveur et que cet espace diminue à la vitesse d'un giga-octet par jour, on sera à court d'espace disque dans 10 jours. Les solutions de métrologie actuelles sont capables d'anticiper ce genre de tendances. Cela permet de lever une alerte « douce », non urgente, qui peut être gérée en heures ouvrables, plutôt que de déclencher une astreinte.

Être proactif, c'est aussi se donner les moyens de déployer de nouvelles ressources en cas de pic de charge. Si le passage de 4 frontaux à 8 nécessite l'intervention de l'équipe réseau pour allouer des adresses IP, puis de l'équipe système pour descendre l'O/S sur les machines, il y a peu de chances que l'ensemble de l'opération se déroule rapidement. En revanche, si ce passage à l'échelle se résume à un script effectuant une requête API déclenchant le provisioning des 4 nouvelles machines, et que partant de là, tout se déroule automatiquement — alors vous êtes dans de bien meilleures conditions pour absorber un pic de charge, même si celui-ci arrive sans prévenir.

Une des clés de notre réussite dans ces domaines est un fort accent sur l'automatisation, permettant le déploiement ou redéploiement en des temps très courts, et avec des résultats fiables, grâce à la maîtrise du configuration management et des containers, par exemple.

Être autonome pour le déploiement

Parfois, l'infogérance inclut aussi le déploiement et/ou les opérations des applicatifs métier. Cependant, la mouvance DevOps encourage tant que possible les développeurs à être autonomes sur ces aspects. Dans cette optique, nous pouvons bien sûr prendre en charge la mise en production de vos applicatifs, mais nous préférons vous accompagner pour automatiser les tâches que représentent cette dernière, et les rendre suffisamment simples et robustes pour que vos équipes puissent se passer de nous en toute sécurité pour les actions les plus courantes.

En pratique, cela passe par une analyse du besoin et des moyens. Que déployez-vous ? À quelle fréquence ? Qui doit pouvoir le faire ? Cela nous permet de vous conseiller sur la meilleure technique à employer. Nos équipes sont rodées à l'utilisation d'Ansible, Puppet, Terraform, et Docker. Nous pouvons choisir avec vous le meilleur outil selon le périmètre de votre application, puis vous accompagner dans son implémentation. Écrire son premier playbook Ansible, son premier manifest Puppet, son premier plan pour Terraform, ou son premier Dockerfile est toujours un challenge ; sauf quand on peut s'appuyer sur un expert qui a l'habitude de le faire, et pourra vous mettre sur les bons rails, et vous fournir des modèles que vous pourrez ensuite décliner de manière autonome sur vos autres applicatifs !

Sur des infrastructure Enix … et ailleurs

Ces prestations ne sont pas systématiquement associées à un service d'hébergement chez Enix, bien au contraire : nous accompagnons de nombreux clients dans leur transition vers le cloud, ainsi que dans des stratégies dites "hybrides" combinant une infrastructure classique (chez nous ou notre client) et une infrastructure cloud (chez nous ou un opérateur public comme AWS, Azure, Google…) assurant la redondance ou de la capacité additionnelle pour encaisser des pointes de traffic.