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 !