Dans ce deuxième article de la série DevOps et DevSecOps, je vais expliquer certaines des motivations les plus classiques pour utiliser les paradigmes mentionnés ci-dessus.
Comme je l’ai déjà mentionné dans mon article précédent, outre le fait de dire simplement « travaillez mieux, pas plus dur » ou que le DevOps sert à améliorer les cycles de livraison et la qualité de celle-ci, je vais maintenant essayer d’expliquer comment l’utilisation de ces pratiques a un lien plus profond avec l’amélioration des produits et, espérons-le, un effet plus général sur l’expérience de l’utilisateur final.
La chaîne de valeur
Là encore, je dois insister sur l’utilisation des 3 « P » de mon domaine d’intérêt : les personnes, les processus et le produit.
Il devrait sembler évident que nous travaillons tous à l’augmentation de la valeur que nous allons délivrer au client final. Chacun, dans la chaîne de valeur, reçoit quelque chose sous forme de « demande » pour le transformer en un résultat donné. En d’autres termes, nous avons tous un client envers lequel nous avons un devoir de livrable. Une équipe DevOps se reconnaît comme étant une chaîne de personnes travaillant ensemble en plusieurs étapes. Chacune d’entre elles essaie de tirer parti d’une proximité ainsi que d’une base de connaissances similaire pour s’assurer que le travail commandé et livré est transmis, tout au long de la chaîne, aussi facilement que possible. Autrement dit, un processus.
En outre, ces personnes centrées sur la livraison de valeur au client et sur l’enrichissement du cycle de vie des produits utilisent une technologie et des outils pour accélérer et augmenter la qualité de la livraison finale du produit.
C’est la synergie de ces 3 domaines d’intérêt qui crée « les grandes lignes » dans lesquelles nous pouvons trouver où nous devons investir notre énergie pour améliorer nos façons de faire. Mais il y a une commande qui est souvent mal comprise, et il est profitable d’en comprendre l’impact sur notre production, notre produit ou notre application.
Les Personnes, les processus, les outils
C’est le fait que l’humain, passe en premier. Ce sont eux que nous devons accommoder le plus. Même s’ils sont l’élément le plus flexible, c’est celui qui demande le plus d’efforts pour comprendre comment coordonner efficacement. Il s’agit donc d’un travail sans fin pour affiner ces notions, c’est pourquoi, dans le but de les rendre claires, nous utilisons des processus.
Les processus sont visuels. Ils constituent un flux de travail, un programme, où chaque sous-processus a une entrée et une sortie attendue. Grâce à ce flux, l’élément d’entrée est enrichi et devient une version améliorée de lui-même et, finalement, l’élément de sortie souhaité. Cela peut être observé et mesuré objectivement tout au long du flux. De cette manière, nous pouvons identifier les domaines d’amélioration que nous pouvons modifier et ainsi obtenir de meilleurs résultats lors du prochain cycle de livraison, quelle que soit la méthodologie utilisée.
Quant aux outils, il est bon de le répéter, cela revient à faire du « dogfooding ». Nous sommes des concepteurs de solutions informatiques, il serait malhonnête de notre part de proposer des systèmes qui aident les gens à améliorer leur activité et, en retour, de ne pas utiliser nos propres systèmes. Il existe une bibliothèque d’outils extraordinairement vaste pour aider à réguler, automatiser, accélérer et consolider nos processus. Mais cela est subordonné aux processus qui, à leur tour, sont soumis aux personnes.
« This is the way »
Nous sommes tous dans le même bateau. Je ne suis même pas très métaphorique quand je dis cela. Nous avons tous une mission unique : apporter une valeur ajoutée et une expérience utilisateur exceptionnelle. À cet égard, nous devons coopérer au maximum pour y parvenir. C’est la raison pour laquelle nous faisons des Devops et des DevSecOps.
De ce fait, il nous est plus utile d’inclure tous les intérêts des parties prenantes dans toutes les phases de la production de notre produit ou de notre application. Nous ne pouvons pas créer quelque chose, le jeter par-dessus bord à un autre équipage et s’attendre à ce que tout se passe bien, peu importe le soin avec lequel nous avons documenté le produit.
Le changement, qui est inévitable à chaque itération de notre produit, rend cette proposition presque impossible à suivre, manuellement. Automatisez-la et vous en garderez obligatoirement la trace. Le fonctionnement du produit sera tout simplement interrompu si vous ne l’avez pas automatisé et si vous n’avez pas tenu compte de la plate-forme technologique de destination. C’est pourquoi il est si important que les équipes DEV et OPS travaillent ensemble à bord de notre navire. Et encore une fois, cela explique pourquoi le DevOPS n’est pas un département ou un spécialiste mais une façon de faire les choses.
La façon dont cela s’applique aux DevSecOps est la même. Ce qui change, c’est l’intégration des impératifs de sécurité dans l’équipage et la façon dont vous allez le faire. Tout cela peut être lié à ce que vous avez planifié en matière de sécurité. J’aime le décomposer dans les domaines suivants :
- Accès
- Résilience
- Intégrité des données
- Isolation des données et vie privée
- Amélioration de la qualité (plus d’informations à ce sujet à venir)
- Suivi
Votre besoin peut varier, mais ce sont de bons domaines pour commencer.
Encore une fois, si tous les secteurs de l’entreprise sont conscients et responsables de ces préoccupations, vous aurez davantage de chances d’obtenir un meilleur produit, de pouvoir le créer et l’entretenir plus facilement. Et finalement, cela devient un vecteur d’amélioration du bien-être des équipes chargées de mettre en œuvre ces préoccupations. « Pas de surprises, pas de déceptions », comme j’aime à le dire.
Plus un domaine est susceptible d’être négligé, plus j’aime faire une « inspection minutieuse » de mes processus. Et il s’agit bien souvent des domaines de la Qualité et du Contrôle.
Il n’y a pas de qualité sans sécurité et vice versa
Il y a peu de principes que je puisse garantir autant que cela. En toute honnêteté, je n’aime pas trop parler des pratiques DevOps. Le fait que nous devions peut-être réinventer nos façons de faire pour inclure la sécurité me fait très franchement peur. Nos systèmes sont de plus en plus exposés et disponibles par le biais d’un réseau commun et accessible. Cette exposition s’accompagne d’avantages supplémentaires mais aussi de risques et je ne peux tout simplement pas considérer mon produit comme ayant une « qualité » mesurable sans avoir pris en compte la sûreté et la sécurité de son utilisation.
Je ne peux pas garantir que tout sera parfait et c’est ce qui me permettra de continuer à m’améliorer. Ainsi, la seule motivation raisonnable que j’ai pour parler de DevOps en premier lieu, est de permettre l’assimilation de ses principes directeurs.
Mais si l’on peut se rappeler que le produit doit répondre à une norme de qualité, il est tout aussi facile de se rappeler qu’il doit également répondre à une norme de sécurité. Et si vous traitez ces deux préoccupations séparées comme une seule, alors le terme que vous utilisez n’a pas vraiment d’importance car en fait ils sont synonymes. Mais pour rappel, je préfère utiliser DevSecOps chaque fois que je le peux pour que les utilisateurs soient prêts et qu’on leur rappelle d’inclure la sécurité comme une préoccupation au même titre que le reste. Vous obtenez ainsi le DevSecOps et la raison pour laquelle il est pertinent.
Conclusion
Si nous pouvons convenir qu’une approche plus unifiée de notre main-d’œuvre, les processus qui la guident et les meilleures sélections d’outils et de produits ciblés sont des idées précieuses, alors nous pouvons convenir que DevOps est une bonne pratique. Ensuite, si nous pouvons convenir que la sécurité n’est qu’un autre aspect de la qualité, alors SecDevOps est à peine une extension de l’imagination sur la façon dont nous pouvons nous améliorer en intégrant cette préoccupation. J’espère sincèrement que vous constaterez facilement les avantages de ces pratiques. Et si c’est le cas, je vous invite à me suivre dans le prochain article dans lequel j’expliquerai comment nous nous y prenons, ici à Emyode.
JP