Auteur/autrice : Chris

Les entreprises qui ont des équipes de développement prennent toutes (plus ou moins) le grand virage de l’agilité et du DevOps.

HOP !

Toute l’entreprise est passée à ce nouvel air rempli d’agilité 🙂
Enfin ? Toutes les équipes projets/développements, parce que les autres, pas encore, voire pas vraiment. Bref, pas du tout !

Et pourquoi les autres équipes n’iraient pas chercher dans les méthodes agiles certaines pratiques qui les aideraient dans la réussite de leurs objectifs ?

• Daily meeting
• Sprint
• Management Visuel

Et vous ? Qu’en pensez vous 🙂

La mise en place du DevOps semble bien agréable, fluide, fini les blocages, méthode Agile .. Mais il est une question que l’on se pose à un moment ou à un autre  : Et côté exploitation ? Comment cela se passe ?

En effet, dans le monde idéal DevOps (le mien) il y a des services transverses comme l’administration de cloud privé ou public. La mise à disposition d’outils pré-packagés.
Ces services restent sur un schéma assez proche de ce que nous connaissons tous.

Par contre avec la mise en place du DevOps, on se retrouve avec des « SysOps » qui vont déployer des VM sur le cloud. Des Ops qui vont regarder les DEV lancer des déploiements automatisés et ce jusqu’à la prod alors que précédemment c’était le service production/exploitation qui s’occupait de cette partie.

Les services productions/exploitations ont des procédures qui sont censées garantir la fiabilité et la robustesses des plateformes (Est-ce toujours le cas ?). DevOps semble casser ce fonctionnement. Il est donc légitime que les services exploitations ne veulent pas laisser la mains aux Ops car ce ne sont pas eux qui supervisent et se réveillent la nuit en cas d’incident.

Le schéma idéal : l’exploitation des applications est gérée par les Ops dans les équipes DevOps.
C’est déjà le cas dans une startup ou une PME : l’Administrateur système gère l’ensemble des aspects lié à l’exploitation.
Par contre dans ce schéma, le service production, exploitation, garde la main sur les briques transverses (Cloud, SAN, Infrastructure).

Et les astreintes ?
Ils faut envisager un schéma où le projet est concerné par les astreintes. Si nous sommes 12 dans une équipe projet : ça fait une semaine d’astreinte toutes les 12 semaines ….. donc 4 dans l’année.
Dans une de mes précédentes missions nous avions mis en place un point « Astreinte » tous les 15 jours. A chaque point nous abordions un nouveau sujet permettant aux personnes de l’équipe de monter en compétence sur ce sujet. Les collaborateurs orientés Système présentaient des sujets systèmes, les collaborateurs orientés fonctionnalité présentaient des sujets fonctionnels. Et cela permettait de créer une certaines cohésions et aussi de découvrir le métier de l’autre au travers ces astreintes partagées. Cela permettait aussi de mettre en place des solutions simples pour que les actions à effectuer en astreintes soient le plus simple possible voir inexistantes ! : Supervision, scripting, Automatisation !

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 ?