Beaucoup de DSI adoptent une démarche Agile pour le développement logiciel. Face à cette transformation des modes de travail au sein des projets informatiques, la production se retrouve confrontée à un rythme de travail différent et à des exigences plus fortes de la part du métier et par conséquent des développeurs. Pour faire face à ce rythme, l’automatisation des infrastructures, des déploiements ou encore des opérations s’imposent.
Lors de nos différentes missions autour de la transformation de la production, nous avons été confronté à une problématique bien connue et toujours d’actualité : comment concilier les demandes, les incidents et les changements, ce qu’on appelle couramment le « Run », et les projets d’automatisation, de migration, de sécurité, de déploiement, ce qu’on appelle le « build » ?
Nous avons eu la chance d’expérimenter différents Frameworks Agile dans le cadre de développement d’outillage de production puis d’accompagner des équipes de production vers une démarche DevOps en appliquant et en adaptant des démarches agiles. Ceci nous a permis d’en dégager quelques leçons sur ce fameux équilibre à trouver entre le build et le run.
Cette série de 5 articles a été rédigée dans le but de partager des modèles d’organisation, d’inspirer des organisations et de les inciter à suivre le modèle qui leur convient le mieux, au-delà de l’effet de mode de certains mots-clés.
Épisode 1 : J’ai testé pour vous « l’OPS en rodage » : L’accompagnement de nouveaux projets
Le modèle d’organisation
Un grand groupe français a monté un pôle d’innovation afin d’accélérer la mise en service de nouveaux produits sur le cloud public AWS.
5 projets étaient incubés au même moment pour un MVP de 6 mois.
Je suis intervenue initialement pour concevoir et mettre en place la sauvegarde des données. Puis en fin de MVP, pour accompagner les techleads des projets sur les premières mises en production.
L’équipe OPS constituée de 4 personnes était rattachée à une équipe transverse qui accompagnait les développeurs sur le socle AWS. Des architectes, des data scientists et des Ops constituaient cette équipe centrale.
Les avantages
Dans cette configuration, nous étions assez autonomes et libres sur nos tâches. Quelques post-it étaient accrochés à un mur, et un daily où chacun disait ce qu’il avait fait la veille et ce qu’il comptait faire en journée.
Étant donné les tailles des équipes et la proximité géographique (nous étions tous sur le même plateau), nous n’avions même pas d’outil de ticketing au début. Les demandes étaient collectées au fil de l’eau. Globalement, il y en avait peu, et pour cause : les équipes de développement avaient les droits de créer et de modifier des ressources sur les environnements hors production, et les architectes se concertaient avec les techleads des projets pour les choix d’architecture et les problématiques techniques sur AWS. Ces derniers proposaient des patterns d’architecture standards sur AWS pour accélérer le démarrage et faciliter la prise en main du cloud.
Nous avons commencé à intervenir à M-3 des premières mises en service (donc des premières MEP) et à partir de l’environnement de préprod qui nous servait d’environnement de test des procédures et du déploiement de 0.
Mon rôle de consultante, avec deux collègues d’enioka ITTS, était de définir les fondations pour une production dans ce contexte particulier tels que la supervision, la sauvegarde, les changements, les incidents, les demandes, etc, puis d’accompagner les développeurs dans le passage d’un mode « j’ai une liberté totale » sur des environnements hors production à un mode « j’ai une liberté maîtrisée » en production.
Les forces de ce modèle sont en premier lieu la proximité que l’OPS a avec les équipes de dév et le fait d’être extrêmement force de proposition car nous étions l’équipe référente sur toute problématique technique autre que du développement. Enfin l’OPS est très agile et s’adapte facilement aux contraintes projet vu qu’il ne planifie pas de projets sur du long terme mais organise ses tâches au quotidien.
Au delà de la démarche agile, arriver en début de projet et accompagner les équipes de développement en amont facilitent énormément l’intégration à la prod et fluidifient les échanges entre les dév et les ops. Pour cela, comprendre le cycle projet, les sprints et leur contenu, ce qui va être livré et comment, s’avèrent être un avantage de taille.
Les limitations
Cette organisation s’applique à un contexte particulier. Dans le cas de figure présenté plus haut, nous avions la « chance » d’avoir un socle commun, vierge, tout était à construire (pas de legacy à opérer), des processus établis dès le démarrage des projets, et peu d’équipes à accompagner. Un accélérateur de cette organisation était l’état d’esprit global qui régnait. L’agilité et l’esprit startup au sein du pôle d’innovation favorisent l’échange direct, la proximité, l’ouverture aux changements et aux nouveautés.
Le volet opérationnel n’ayant pas été très structuré et les OPS travaillant selon une démarche Agile informelle, une autre limitation à ce modèle fut le rattrapage des devs dans leur élan de liberté. Même en ayant une proximité importante, intervenir en tant que OPS au moment du passage en prod est déjà presque trop tard pour sensibiliser les devs à l’exploitation de cet environnement et au maintient en conditions opérationnelles. Il a été nécessaire de revoir beaucoup de choses dans les fichiers de configuration par exemple pour automatiser le déploiement et variabiliser les configurations par environnement. Nous n’avons pas été à l’abri de quelques surprises.
Dès que le nombre de projets a augmenté, que les contraintes techniques se sont diversifiées, et que les opérations se sont intensifiées, le mode d’échange direct et d’organisation sans réelle organisation deviennent un frein, une sollicitation qui perturbe les travaux de fond. Il faut une certaine maturité dans l’organisation des OPS, c’est-à-dire une méthode claire et un cadre précis pour arriver à suivre à la fois les projets en cours, les projets déjà en prod, et les chantiers transverses liés au socle et à l’outillage de prod. C’est ce qui nous a amené à changer de méthodologie que je détaille dans l’épisode suivant.
Rendez-vous au prochain épisode pour connaître l’évolution de ce modèle d’organisation !