De nombreuses organisations suivent les principes devops et souhaitent adopter une culture devops. Parmi les pratiques clés du domaine figurent le contrôle des versions, l’intégration et la livraison continues (CI/CD), l’infrastructure as code (IaC, consistant à gérer le provisioning de l’infrastructure à travers du code plutôt que par des processus manuels), l’application de l’apprentissage machine aux opérations (AIOps) et les tests continus. Les équipes les plus avancées y ajoutent la planification continue, la conception d’applications cloud natives, le développement de microservices, le contrôle de code avec les features flags (marqueurs de fonctionnalités qui permettent d’activer ou de désactiver certaines portions de code), la promotion de pratiques de sécurité dites « shift-left » (consistant à faire remonter la sécurité plus tôt dans les pratiques de développement), la mise en place d’objectifs de niveau de service (SLO), la gestion des budgets d'erreur (en ingénierie de la fiabilité des sites, SRE, c'est le seuil maximal admissible d'erreurs et d'interruptions) et la volonté d’être davantage tiré par les données.

Ces pratiques contribuent à transformer deux fonctions principales d’une organisation devops : le développement (la conception de nouvelles applications et la livraison fréquente d’améliorations) et les opérations (qui garantissent la fiabilité et les performances des systèmes de l’entreprise, des bases de données et des applications). De nombreuses organisations étendent le devops au devsecops et incluent la sécurité au même niveau. Avec devsecops, les trois principales pratiques IT doivent maintenir l’équilibre entre la vitesse, l’agilité et l’innovation dont les entreprises ont besoin pour assurer la fiabilité, la sécurité et la performance exigées aujourd’hui par leurs activités.

Au-delà des bonnes pratiques, il faut intégrer les outils

Pour atteindre ces objectifs, les pratiques devsecops ne suffisent pas à elles seules à cimenter la collaboration nécessaire pour réunir les fonctions de développement, les opérations et les fonctions de sécurité. Il faut mettre en œuvre, suivre et mesurer les flux de travail que recouvrent ces fonctions. Pour de nombreuses organisations, ces workflows réunissent des méthodologies agiles utilisées par les équipes de développement, incluant scrum et kanban, avec des pratiques de gestion des services IT (ITSM) assurées par les équipes opérationnelles. Ces pratiques ITSM incluent la gestion des demandes, des incidents, des problèmes et des changements, ainsi que la maintenance d’une base de données de gestion des configurations (CMDB). Cependant, très souvent, les départements IT n’arrivent pas à intégrer leurs outils agiles et ITSM. 

Les équipes de développement peuvent utiliser Azure DevOps, Digital.ai, Jira ou un autre outil agile pour gérer les demandes des utilisateurs à traiter, les sprints et les livraisons du processus de développement. Indépendamment, les équipes devops peuvent utiliser différentes solutions, comme celles de BMC, Cherwell, Ivanti, Micro Focus, ServiceNow, Jira (Service Management) ou un autre outil ITSM pour gérer les tickets, le suivi et superviser la gestion du changement. L’automatisation et l’intégration peuvent aider à connecter les workflows supportés par ces outils agiles et ITSM mais, malheureusement, le plus souvent, la connexion de ces fonctions résulte de différents processus manuels combinant e-mails, réunions, échanges Slack et Zoom, etc. Ce que l’on ne peut pas vraiment considérer comme une bonne pratique devsecops.

Pour ceux qui se demanderaient pourquoi il est important de connecter ces outils et workflows, voici trois points d’intégration communs à considérer en matière de devsecops. Ils sont nécessaires pour supporter une livraison rapide, la sécurité et des opérations stables.

1 - Accélérer le déploiement des changements à faible risque 

Les grandes organisations et celles qui travaillent dans des industries réglementées mettent en place un Comité d’approbation des changements (en anglais CAB pour Change advisory board) pour vérifier la conformité et les risques lorsque l’on doit déployer des changements dans les environnements de production. Ces comités exigent souvent que les équipes devops soumettent de la documentation, démontrent la conformité des tests, passent en revue les risques de sécurité et partagent les dépendances avant de programmer et d’exécuter les déploiements en production. Cette approche peut s’avérer nécessaire pour orchestrer les déploiements les plus complexes qui impliquent de nombreuses équipes, des dépendances de systèmes ou des risques opérationnels pour l’activité. De nombreuses pratiques devops sont déjà destinées à minimiser ces problèmes. Par exemple, les microservices associés à des tests continus et du CI/CD robuste permettent aux équipes devops de déployer de petits changements associés à de faibles risques. Les autres types de changements à faibles risques peuvent inclure les composants UX déployés dans les architectures serverless, les changements dans des tableaux de bord analytiques embarqués, des améliorations d’applications low code ou de petits changements de configuration dataops. Si ces changements sont vraiment petits et à faibles risques, est-ce que l’IT peut en automatiser l’approbation en connectant du CI/CD déclenché à partir des outils agiles avec des workflows de gestion du changement géré dans les outils ITSM ?

Bien sûr, les métiers, les développeurs, la sécurité et les équipes opérationnelles doivent être d’accord sur ce qu’ils entendent par « petits changements » à « faibles risques ». En outre, les pipelines CI/CD doivent prendre en charge les rollbacks (retours en arrière à un moment précis) et, dans l’idéal, les gestionnaires d’incidents doivent être capables de les déclencher si les changements entraînent des problèmes imprévus. Dans un contexte où les équipes devops cherchent à déployer plus fréquemment tout en réduisant la taille, l’échelle et les dépendances des composants logiciels, l’automatisation de l’approbation du changement devrait être l’une des intégrations clés entre les outils agiles et ITSM.

2 - Prioriser et résoudre les défauts en production 

Vos pratiques d’automatisation du test et des tests en continu sont-elles assez robustes pour garantir que vous pouvez déployer des versions de production zéro défaut de façon régulière ? Lorsque les équipes opérationnelles ou les SRE (site reliability engineers), ingénieurs de fiabilité du site, analysent l’origine des problèmes en production, ou que les utilisateurs signalent au service desk des problèmes sur les applications, la prise en compte de ces problèmes devrait apparaître en tant que défauts dans la liste des tâches à prioriser (backlog) des équipes de développement agile. Quand ces dernières donnent la priorité à l’examen d’un problème et, dans l’idéal, résolvent ces défauts, alors les incidents et autres types de tickets saisis dans les outils d’ITSM devraient en refléter le statut en cours.

La mise en oeuvre de ce mapping n’a rien de trivial parce que les équipes doivent mettre en relation les statuts des flux de travail entre, d’une part, les défauts gérés dans les outils agiles et, d’autre part, les tickets de l’ITSM. Sans compter que certains tickets peuvent donner lieu à plusieurs défauts, ou à l’inverse, plusieurs tickets peuvent être réunis dans un seul défaut. D’autres exceptions sont également susceptibles d’apparaître dans les flux de travail, par exemple lorsque le service desk relie une demande de ticket à un défaut, mais que l’équipe de développement indique que la demande de l’utilisateur porte en fait sur une nouvelle fonctionnalité. 

Pourtant, il est tout à fait problématique de maintenir une séparation entre demandes utilisateurs et incidents signalés à travers le service desk, d’une part, et le backlog de l’équipe de développement agile, d’autre part. Cela peut signifier que les problèmes opérationnels et les besoins des utilisateurs ne sont pas examinés et priorisés par les équipes de développement agile. En tout état de cause, ce n’est pas une bonne pratique agile pour ces équipes qui devraient au contraire être sensibles aux problèmes des clients et des responsables IT chargés des opérations. La bonne pratique vise à connecter ces deux workflows et à développer des politiques pour prioriser les défauts. 

3 - Connecter les déploiements avec le monitoring et les plateformes AIOps

Quand des incidents de production se produisent, l’un des indicateurs-clés de performance pour le service desk consiste à les résoudre aussi rapidement et efficacement que possible. De nombreuses équipes ITSM suivent le MTTR, temps moyen de résolution des incidents de production, et augmentent le nombre de points de surveillance et d’alertes pour identifier plus rapidement les problèmes.

Les organisations IT exploitant des architectures multiclouds ou de nombreux outils de monitoring différents peuvent maintenant utiliser des plateformes AIOps pour centraliser les données de surveillance et d’observabilité. Une fois que les données sont centralisées, les plateformes d’AIOps mettent en oeuvre l’apprentissage machine pour aider à corréler les alertes de multiples systèmes en un incident unique et gérable. Mais une pratique souvent ignorée consiste à intégrer les changements de développement à ces outils de surveillance et d’AIOps.

Est-ce que le centre d’exploitation du réseau (NOC) ou le centre d’opérations de sécurité (SOC) ont une connaissance complète de toutes les données d’observabilité, de tous les déploiements, changements sur les indicateurs de fonctionnalités (feature flag) ou autres changements de configuration ? Si je suis dans le centre d’exploitation du réseau et qu’une base de données envoie une alerte, je n’ai pas envie de chercher qui a fait quoi, quand et où dans les outils agiles, ITSM, de contrôle de version, de marquage de fonctionnalités (feature flags) ou dans d’autres outils. De plus, quand les équipes de développement sont vraiment engagées dans des pratiques SRE et dans la mesure des budgets d’erreur, elles devraient recevoir des analyses consolidées de la production sur les performances et la fiabilité de leurs applications, services, bases de données et de l’infrastructure sous-jacente.

Pour des pratiques devops de bout en bout

Ces intégrations pourraient être le Saint Graal pour soutenir les pratiques devops de bout en bout, mais elles nécessitent de connecter les données à travers plusieurs systèmes :

- Les outils de développement agile, de contrôle de version, de marquage des fonctionnalités, d’automatisation des tests et de CI/CD utilisés par les équipes de développement,

- Les outils d’ITSM utilisés pour capturer les incidents, les demandes et les changements gérés par le service desk,

- Les outils de CMDB, base de données de gestion de configuration, et de DDM (discovery and dependency mapping), utilisés pour la détection et la cartographie des dépendances, qui capturent les états précis de l’infrastructure,

- Les outils de surveillance et d’AIOps utilisés par les centres d’exploitation du réseau et les centres d'opérations de sécurité,

- Les outils de VSM (value stream mapping), cartographie des chaînes de valeur, et autres outils de gestion produit qui procurent de la transparence et des contrôles aux équipes dirigeantes. 

Parmi les outils de gestion pour les AIOps, l’observabilité et les objectifs au niveau des services, on trouve les solutions de BigPanda, Broadcom, DataDog, Devo, Digitate, Dynatrace, Elastic, Micro Focus, Moogsoft, New Relic, Nobl9, OpsRamp, Resolve, ScienceLogic, Splunk, entre autres. Ils apportent des capacités d’intégration, d’analyse, de workflow, d’automatisation et d’autres fonctionnalités pour suivre les résoudre les problèmes opérationnels.

Le point-clé, pour les équipes informatiques, c’est de reconnaître que si l’on se concentre de plus en plus sur le devops, cela nécessite d’intégrer et de moderniser les flux de développement, les flux opérationnels et flux de sécurité.