Un des sujets Majeurs : La Supervision
Prod, Poc, recette, lignes de développements, il y a tellement de types d’environnements qu’il est parfois difficile de s’y retrouver. Que superviser, comment ? Là aussi chaque entreprise a sa façon de penser et je vous assure que chez bon nombre de clients il y a quelques « trous » dans la raquette.
Le schéma habituel :
L’infrastructure de supervision est gérée par les équipes infra/systèmes. Dans cette façon de travailler, les projets, les métiers et les développeurs n’ont aucune visu sur cet ensemble.
On se retrouve donc parfois avec des situations comme une alerte qui sonne pour un serveur d’intégration qui est « down ». Ce qui oblige l’ingénieur système en charge de la supervision à se demander si cette alerte est bien justifiée sur de l’intégration. Premier tour du service :
Mais à qui est ce serveur ?
Il faut que tu contactes telle équipe ..
D’accord, merci.
Deuxième tour du service :
Ils ne connaissent pas ce serveur …
Ah bon ? Ah, OK, demande donc à Mrs X …
Et ainsi de suite.
Finalement le serveur n’était plus utilisé depuis 1 an, nous sommes en droit de nous demander pourquoi il n’a pas été arrêté plus tôt. Finalement dans ce type de situation il y a une réelle perte de temps et d’argent ….
Le schéma hybride :
L’infrastructure de supervision est installée et mise à disposition par les équipes infra/systèmes et ce sont les projets, les métiers et les dev qui ont la possibilité de mettre en place différents « checks », ce sont aussi eux qui reçoivent les alertes et qui seront responsables de leurs environnements : ici on est déjà dans le DevOps, et c’est évident que si c’est une équipe DevOps qui reçoit les alertes, il faut que l’équipe ait les droits et les compétences pour résoudre l’incident (sauf incident lié à l’infrastructure sous-jacente).
Le schéma DevOps :
Je vois l’équipe DevOps comme une Startup, comme une TPE au sein même de l’entreprise. Si l’on veut atteindre le dynamisme de ces Startups, il faut donner aux équipes DevOps la même liberté que possède la Startup. Et la supervision est un point important. Laissons aux SysOps des équipes cross-fonctionnelles la possibilité de monter leur propre supervision dans leurs propres environnements.
C’est évident qu’un projet avec 50 machines à superviser saura quoi, quand et comment superviser leurs serveurs, avec leurs applicatifs. En ce qui concerne l’infrastructure de supervision, les besoins en ressources seront en fonction de la taille des projets et à la finale, la totalité des petits besoins ne feront pas plus qu’une énorme infrastructure groupe qui supervise 10000 serveurs. Par contre il y aura une énorme différence en terme de qualité et de service rendu : et là on est vraiment dans le DevOps !
En plus des gains évidents, il y aura une véritable dynamique entre les différentes équipes ce qui fait gagner en motivation. (évidement la possibilité d’inclure ou d’exclure certains outils peut être envisagée afin d’avoir une certaine homogénéité et de pouvoir enrichir une base de connaissances qui puisse servir à tous).
Et vous ? Êtes vous prêts à laisser vos équipes projets recruter des SysOps qui mettront en place leur supervision dans leurs environnements ?