Dans le premier épisode, nous avons vu la genèse d’une équipe d’OPS sur un nouveau socle et en parallèle de l’arrivée de nouveaux projets en production. L’activité était tournée vers la construction du socle, l’accompagnement des équipes de développement et la rédaction de documentation. Maintenant que les applications sont en prod, voyons comment l’OPS s’adapte entre l’accompagnement projet et le maintient en conditions opérationnelles.
Épisode 2 : J’ai testé pour vous « l’OPS entre build et run journalier »
Le modèle d’organisation
Toujours dans le même contexte client (cf épisode 1), de nouveaux projets sont arrivés, et on s’est retrouvé avec 15 à 20 projets à accompagner, entre ceux qui sont déjà en production et qui commencent à avoir des demandes de déploiement, d’opérations sur l’environnement de prod etc, et ceux qui démarrent et qui sont renvoyés vers nous pour les questions relatives au socle, aux environnements, etc.
L’autre nouvelle contrainte que nous avions était que le RSSI du groupe nous a demandé de prouver que les architectures et les applications respectaient les exigences en termes de sécurité (confidentialité, intégrité, RGPD, droits et permissions, exposition). La compliance des ressources cloud est devenue un sujet de priorité 0.
Concernant le Build, on avançait correctement sur les produits que l’on développait (monitoring, backup, landing zone et mise en place d’environnement, CI/CD), mais il a fallu se focaliser sur un seul produit : la mise en place des contrôles de sécurité opérationnelle et le reporting aux RSSI du pôle d’innovation et de l’entreprise.
Afin de respecter cette priorisation, de donner l’état d’avancement au RSSI du groupe et son homologue de l’entité dans laquelle je travaillais, l’équipe Ops s’est tournée vers le framework Scrum (4-5 personnes). Ce modèle couramment employé par des équipes de développement logiciel, offrait un cadre rigoureux et une visibilité des travaux en cours.
Concernant le Run, nous avons décidé collégialement de créer un rôle tournant, où chaque jour un OPS différent traite les tickets de support et de changement. Comme nous étions 4 avec une nouvelle recrue, cette dernière portait cette casquette d’exploitation de niveau 2 pendant 2 jours afin de mieux monter en compétence et se familiariser avec les applications et le socle AWS.
Les avantages
Le rôle de « l’exploitant » tourne vite entre les membres de l’équipe, permettant de toucher à tous les produits, sans pénaliser le build. On estimait bien les contenus de sprint de développement du produit de compliance sécurité connaissant d’avance notre charge sur le Run.
De plus, ayant déjà mis en place de l’automatisation et de la documentation dans la première phase d’accompagnement des projets de développement, la passation entre nous n’était pas très douloureuse, nous étions assez autonomes et assez sereins sur notre capacité individuelle à traiter tout type de demande (sauf bien évidemment quelques rares exceptions).
Le plus grand avantage de ce mode de fonctionnement est que le build n’est pas négligé, bien au contraire, il est au centre du quotidien d’un OPS et est valorisé grâce au mode Scrum.
Les incidents passent bien évidemment avant, mais ayant bien posé le cadre initialement, avec de l’accompagnement, des travaux de fond d’automatisation des environnements infra et appli, la mise en place de sondes de supervision dès l’environnement de test, la charge de run était moins importante que dans des prods qui subissent ou qui n’ont pas pu construire des automatisations en amont. Ce mode limite les sollicitations directes ironiquement, puisque la personne qui fait le run change tous les jours, les projets ont arrêté très vite de contacter l’individu et ont compris que créer un ticket était le moyen le plus rapide et fiable pour avoir une réponse.
Un dernier avantage, ou plutôt une opportunité du contexte, est que les membres de l’équipe étaient tous volontaires et motivés. La personne qui était sur le RUN le faisait consciencieusement et rigoureusement, documentait ses actions dans le ticket au cas où elle ne terminerait pas et devrait passer la main à une autre le lendemain, et faisait de son mieux pour en terminer un maximum dans sa journée de RUN.
Les limitations
Même si nous étions autonomes, motivés, et assez flexibles, le « turnover » entre build et run était trop rapide parfois, certaines demandes nécessitaient des allers-retours entre différentes parties prenantes et une réflexion profonde. Les demandes pouvaient aller de la simple attribution d’un rôle sur la plateforme pouvant être assimilées à des demandes pour un support Niveau 1 dans le jargon ITIL, à l’évolution d’une architecture de référence pour prendre en considération une problématique de performance pouvant être assimilées à des demandes pour un niveau 3.
Encore une fois, même si on était tous des profils confirmés, la polyvalence a ses limites. On n’est tous très à l’aise avec l’implémentation des règles du firewall, ou avec la définition d’un rôle complet sous AWS.
Une petite frustration s’est installée quant à la non-réalisation de bout en bout de ticket par la même personne dans l’équipe, mais aussi quant à la passation d’information entre celui qui fait le run aujourd’hui et celui qui le fait le lendemain ?
Pour remédier en partie à cela, on a instauré un petit daily de 15 min en début de journée entre les 2 personnes qui s’occupent du run 2 jours de suite, facilitant l’échange direct plutôt que de la prise en main d’un backlog de tickets sans explications préalables.
Un dernier inconvénient que n’avions pas anticipé était qu’en réalisant 1 jour de run par semaine, l’opérationnel ne voyait pas forcément toutes les demandes projets. Certains avaient des tickets plus complexes, d’autres plus simples et rapides. C’est très aléatoire en réalité, mais inégalitaire souvent. Une personne a remonté lors de diverses discussions qu’elle ne laissait aucun ticket ouvert à la fin de sa journée de run, alors que quand elle démarrait elle en avait de la veille. Ce qui pose des questions quant à la pérennité de ce modèle.
Rendez-vous au prochain épisode pour connaître l’évolution de ce modèle d’organisation.