Approche DevOps : Des métiers et une approche aux enjeux techniques et organisationnels

Apparu en 2009, le mot devOps est un combiné des termes ‘développement’ et ‘opérations’. Il définit à la fois une approche et une culture, des pratiques et des outils, et le rôle d’ingénieur devOps.
Dans chaque cas, il symbolise la collaboration entre les équipes de développement et d’administration système.

Collaboration - par Andrew Moca

Julien — SRE et Paul-Henry et Ruaraidh — devOps partagent leur vision de leur poste respectif et de cette approche.
Ils évoquent leur parcours et leurs outils de prédilection, mais également la perception de leur métier et de son évolution.

Peux-tu nous décrire ton domaine d’expertise ?

Julien : Je suis SRE, Site Reliability Engineer. Mon travail concerne les méthodes d’action et de maintenance pour faire en sorte qu’un site ou un système soit en ligne et fonctionnel en permanence.
Je suis plutôt sur la partie observabilité du système. Il s’agit d’un point assez important dans la culture devOps, qui consiste à être toujours au courant de l’état actuel du site.
Pour cela je suis plusieurs indicateurs, comme le nombre d’utilisateurs en concurrence sur le site ou le nombre de commandes par minute.
On peut avoir cette vision de penser que l’observabilité est uniquement sur le CPU ou la RAM utilisée par nos serveurs. Aujourd’hui ça c’est également vraiment démocratisé sur une vision user journey.
Les indicateurs se rapportent toutefois toujours aux deux principes fondamentaux : la disponibilité et la fiabilité. Ce sont des indicateurs choisis très précisément, car s’il y a un problème ce sont souvent les premiers à le signaler.
Si je vois que j’ai moins de commandes comparé à d’habitude, je peux me douter qu’il y a quelque chose qui se passe mal. Ce sont donc des indicateurs de disponibilité et de fiabilité qui sont importants et que l’on regarde en priorité.

Paul-Henry : Je suis devOps. Au quotidien : J’accompagne les développeurs dans les mises en production, je fais en sorte que les infrastructures et les services qu’on déploie fonctionnent correctement et que l’on puisse déployer, scaler, créer des plateformes, services et applications.
Il y a donc toute une partie de travail de préparation en amont, puis de suivi des plateformes, pour s’assurer que tout fonctionne correctement, qu’on soit en maîtrise et qu’on puisse intervenir en cas de besoin.

Ruaraidh : J’ai le rôle d’ingénieur devOps. Dans ma mission, il s’agit d’un rôle d’intermédiaire entre la partie système et les développeurs, tout en ayant mes propres responsabilités.
Cela passe donc par la maîtrise des infrastructures, mais aussi par une bonne connaissance des projets de développement.
Il y a une volonté partagée d’avoir un système régulier et de pouvoir adopter une méthodologie de changements fréquents sur des cycles courts. C’est-à-dire de favoriser le changement continu, plutôt que de longues périodes statiques suivies de phases de mises à jour conséquentes. Cette approche est encouragée et facilitée par la méthodologie devOps et passe beaucoup par l’automatisation des tâches.
Le rôle est donc d’apporter cette notion d’intégration et de changement continu et de mettre en place et maintenir les systèmes qui permettent et facilitent ces méthodologies.
Il y a aussi un fort côté social, car en tant qu’intermédiaire on est souvent sollicité sur des désaccords vis-à-vis des volontés et besoins de chacun. Il est donc nécessaire de savoir écouter et argumenter. Pour ma part, mon expérience en développement m’aide à bien comprendre les deux parties.

Comment as-tu découvert cette discipline ?

Julien : Il s’agit d’une évolution assez naturelle. J’ai fait une prépa intégrée avec un BTS informatique qui amenait à une spécialisation soit en développement, soit en administration système et réseaux. J’ai pris la seconde option. J’ai donc pu voir tout ce qui est création et mise en place de services. Puis, en école d’ingé j’ai fait une alternance en gestion d’applications en production : faire de la maintenance, assurer le service, résoudre des erreurs, … Et petit à petit, je me suis rapproché de ce milieu où non seulement je mets en place des services, mais j’en assure aussi leur bon fonctionnement.
Par la suite, je me suis formé en autonomie sur le métier de SRE. Une notion assez récente à l’époque.
Et en appliquant ce que je connaissais de mes précédentes expériences et ce que j’avais appris par moi-même, je me suis progressivement tourné vers ce métier, que j’occupe exclusivement aujourd’hui.
C’est un titre qui reste assez étendu et qui recoupe un panel de missions avec différentes spécialisations possibles. Par exemple, j’occupe actuellement une mission pour laquelle je suis responsable d’une brique d’infrastructure particulière. C’est toujours de la SRE, mais très concentrée sur cette partie.

Paul-Henry : J’ai découvert ce métier par hasard. Je savais que je voulais faire de l’informatique. Toutefois, j’aimais bien le développement, mais pas forcément assez pour en faire mon métier.
J’ai donc fait une école d’ingénieur informatique assez générale. Et en troisième année, j’ai passé un entretien pour un stage en développement sur un projet autour de la santé. On m’annonce alors que l’offre de stage a été annulée, mais qu’il y a un besoin en devOps. En écoutant la description des missions, cela a finalement mis un mot sur une pratique que je connaissais déjà et que j’appréciais. Et c’est ainsi que j’ai découvert cette partie de l’informatique !
L’expérience m’a beaucoup plu car elle m’a permis de travailler avec des profils différents, comme des développeurs back et des data scientists. J’ai pu comprendre ce qu’ils faisaient, ce dont ils avaient besoin et aussi découvrir tous les aspects d’une plateforme.
Finalement ce fut une évidence que c’était le métier auquel j’aspirais, car je le pratiquais déjà de mon côté, mais sans avoir mis un terme dessus.

Ruaraidh : Avec le recul, c’était évident que je souhaitais faire ce rôle.
J’ai toujours eu une appétence pour les systèmes au sens large : comment faire fonctionner des mécanismes ensemble pour faire fonctionner des systèmes plus grands et plus complexes, avec tout l’aspect mécanique et réseau.
J’ai commencé par étudier la biologie mécanique. Puis je me suis réorienté vers l’ingénierie électronique. Avant de m’inscrire à Epitech, après m’être auto formé en développement avec le site du 0 et d’autres ressources.
Et dans cette formation, j’ai pu découvrir le monde d’AdminSys. J’y ai aussi découvert l’outillage que j’utilise encore aujourd’hui : Kafka, Docker, Hadoop. Et dès mon premier stage, il m’a paru clair que j’avais trouvé ma voie, même si le terme devOps n’était pas encore démocratisé.
Ce rôle me permet aujourd’hui d’allier ma double casquette de développeur et d’ingénieur système, et s’adapte parfaitement à mes compétences et mes envies.

Quels sont vos outils de prédilection dans vos métiers ?

Il s’agit d’une liste non exhaustive car il y existe énormément d’outils. Il est d’ailleurs nécessaire de faire une veille constante pour s’informer et tester les nouveaux outils qui apparaissent régulièrement.

• Docker et Kubernetes travaillent de pair. Docker et son principe de conteneurisation permettent d’embarquer des applications dans un environnement d’exécution isolé et indépendant. Et Kubernetes permet d’organiser cet environnement pour l’allocation et la gestion des ressources.
  Docker est vraiment l’outil incontournable qui permet d’adopter la méthodologie devOps : être dans le micro changement, la livraison continue, … On passe d’un modèle avec une infrastructure maintenue et connue à un univers où on peut facilement tout changer et recréer. Docker permet justement de créer des images que l’on peut conteneuriser pour pouvoir imager nos applications et en faire ce que l’on souhaite via l’orchestration et l’intégration continue.
  Kubernetes est un orchestrateur qui assure et garantit la stabilité des infrastructures et des systèmes.
  On n’est plus sur un modèle d’une application qui tourne sur un serveur, mais sur un environnement avec plusieurs nœuds, serveurs et machines. Cela permet plus de résilience en ayant une réplication des services et applications. Ainsi, si une instance tombe, d’autres peuvent prendre la relève.
  Et il y a aussi une partie monitoring qui permet de veiller au bon fonctionnement des applications.
• Terraform, en tant qu’outil d’infrastructure as code. Il permet, sur AWS par exemple, de créer des machines virtuelles, de pouvoir faire des configurations plus orientées hardware, de pouvoir créer des services, les interconnecter, pouvoir créer des groupes de sécurité, …
  Il répond au besoin de pouvoir détruire et recréer des applications à la volée, mais aussi tout un environnement. Il permet d’avoir de la flexibilité et une capacité à déployer rapidement. Mais aussi de maintenir une certaine source de vérité avec la conservation du contrôle et de la traçabilité des ressources.
  On est sur un système qu’on essaie d’industrialiser au maximum. Et si on veut par exemple standardiser des mécanismes d’alertes, on va écrire du code qui utilise l’API de Datadog pour créer ces mécanismes et gérer l’écosystème. Pour résumer on écrit du code sur Terraform pour gérer notre infrastructure.
• Datadog est un outil de data visualisation sur lequel on va avoir une agrégation des données de nos systèmes, à partir desquelles on va pouvoir créer des indicateurs particuliers.
  Il s’agit d’un outil de monitoring qui permet à partir de ressources complexes d’apporter une solution de facilité assez bluffante.
  D’ailleurs, il ne propose pas de support technique client, car il part du principe qu’il n’y en n’a pas besoin. C’est une prise de position ambitieuse mais attirante.
• PagerDuty est un mécanisme d’alerte configuré pour alerter quand les indicateurs de Datadog sont en erreur. Un alerte est lancée si un incident est en train de se produire afin de pouvoir rapidement entamer une action corrective.
• Pour les outils de CI/CD, il y a Jenkins, majoritairement pour la partie déploiement et création d’artefact ou d’images Docker.
  Et aussi Circle CI. L’équipe produit cherche constamment à innover. C’est parfois pénible car on est un peu bêta testeur, mais ça part d’une volonté d’avoir une grande flexibilité et de faire des choses optimisées.
• Ansible et Salt sont des outils de déploiement sur des serveurs pour pouvoir installer des composants, créer des fichiers de configuration, installer des applications, …
• En termes de plateformes AWS ou GCP.
  Bien sûr, il y a une méfiance du monopole d’Amazon sur le cloud. Mais malgré une volonté d’être agnostique, facilitée par Kubernetes, il est compliqué de se passer de solutions propriétaires dès lors qu’on consomme sur un cloud provider. AWS reste le plus simple et le plus répandu, avec GCP et Azure.
• En langage Bash, Python pour du tooling et un peu de Go pour certaines applications un peu plus poussées.
• Sans oublier Slack ! Notre travail est aussi beaucoup dans la communication. Nous n’avons pas réponse à tout et il s’agit aussi d’aiguiller et d’accompagner d’autres postes, comme des développeurs, pour qu’ils apportent des solutions ou un correctif. Ce n’est pas nous qui allons forcément tout corriger, car nous n’avons pas forcément toujours les compétences pour, mais aussi car ce n’est pas notre rôle.
  Notre rôle est assez central, avec le besoin de faire interagir plusieurs entités entre elles. Il y a donc parfois même plus de communication que de technique !

Quel a été l’impact de ces technologies dans la vision de ton métier ?

Julien : Quand tu arrives dans une entreprise, ton travail va être orienté en fonction des outils existants et de la manière dont ils sont utilisés.
D’ailleurs, même si aujourd’hui j’effectue la même mission qu’auparavant, mon travail est assez différent, car les outils sont différents. Les outils apportent donc du changement, même si l’objectif visé reste similaire.
Et dans ce milieu, il y a plusieurs grandes catégories d’outils. Il faut donc être plutôt polyvalent et être capable d’apprendre et de s’adapter à de nouveaux outils.
Avant j’étais sur la solution de Cloud Provider d’Amazon, et maintenant je suis sur celle de Google. Les concepts sont similaires, mais pas l’implémentation. Il y a donc une période de transition à avoir, bien qu’on ne reparte pas de zéro en termes de connaissances. Idem sur la partie visualisation et alerte, il existe différents outils, mais il y a toujours la même idée : observer une valeur, paramétrer un système d’alerte, …

Paul-Henry : Les outils ont beaucoup changé au fil du temps, donc je continue d’apprendre constamment.
Docker a beaucoup révolutionné ma façon de voir mon métier. La possibilité de faire des choses reproductibles, isolées et facilement déployables permet de remanier les choses, de les mettre en perspective et d’avoir cette notion d’orchestration. Là où avant j’aurais fait un serveur pour chaque application, je réfléchis maintenant différemment. Et puis tout est déjà prêt. Je n’ai qu’à faire le travail une fois, avant de pouvoir l’automatiser.
Les notions de reproduction et d’automatisation sont importantes. Elles imposent une certaine rigueur, mais simplifient les choses sur le long terme. Il faut avoir la discipline de s’y tenir, mais ensuite cela permet d’être plus serein dans son approche de l’infrastructure et de son déploiement.

Ruaraidh : Le métier c’est les outils et les outils c’est le métier.
Dans notre domaine, il s’agit d’outils très structurants, qui apportent un changement de paradigme et de façon de travailler. Ce qui implique un changement à tous les niveaux, y compris pour les développeurs. Car ils façonnent non seulement notre manière d’imaginer le déploiement, mais aussi le développement. Par exemple, avec Docker on partage un même environnement du développement jusqu’en production. Et il s’agit d’un atout majeur en termes de process, de communication et de transparence entre équipes.
Ces outils proposent, et tiennent, beaucoup de promesses. Mais ils imposent aussi des contraintes et des conditions à la fois techniques et organisationnelles. Ils sont un vecteur fort de changement d’organisation du travail.

La reconnaissance de ton poste est-elle à la hauteur de tes responsabilités ?

Julien : Même si le métier est parfois moins reconnu, il reste très valorisant et gratifiant. Il permet de traduire son implication en résultats concrets, comme passer d’une disponibilité de service de 98% à 99,5%.
Après c’est une reconnaissance plus indirecte, donc la manière de la percevoir dépend plus de la manière dont on va être fier et satisfait de son travail. Pour ma part je suis satisfait quand le service est fiable et rigoureux.

Paul-Henry : C’est un métier avec un haut niveau de responsabilités, car nous sommes gardiens de la production. Donc si nous ne sommes pas capables de tout mettre en place pour que tout se passe bien et de pouvoir le vérifier, le mesurer et l’observer, alors nous sommes fautifs. S’il y a un dysfonctionnement, c’est vers nous que l’on se tourne et c’est à nous d’identifier l’origine du problème (machine, flux, applicatif). Il faut donc être proactif et réactif.
Mais parallèlement à ces enjeux, on oublie parfois que les devOps existent. C’est surtout le cas dans la phase de conception. Nous sommes bien identifiés et sollicités sur les phases de run, mais moins souvent lors de la conception. Or nous sommes à même d’être utiles dès cette étape pour répondre à des questions sur la faisabilité, proposer des alternatives existantes, échanger sur les impacts possibles dans l’ensemble, …

Ruaraidh : Je ne ressens pas forcément un fort besoin de reconnaissance pour le rôle. Mais très clairement c’est un sujet important et parfois sensible dans les équipes Infra et devOps.

On a effectivement de fortes responsabilités. Car en tant que garant du système, on a besoin d’y avoir accès. On est donc administrateur des outils, avec un accès à l’ensemble des ressources. Il faut alors s’imposer une rigueur pour ne pas se retrouver dans une situation où l’on pourrait faire des erreurs qui créeraient un incident majeur.
Je ne sais pas si tout le monde réalise bien ce niveau de responsabilités et les implications de ce pouvoir. Et pour d’autres profils, comme des développeurs, ce peut aussi être frustrant de ne pas pouvoir prendre eux-mêmes ces responsabilités.

Une autre faiblesse du rôle, c’est qu’on peut parfois y voir un fourre-tout : On y met par exemple des notions de sécurité ou d’optimisation financière. Ce sont des sujets très intéressants, et c’est important qu’on y soit sensible, mais il s’agit de vrais rôles et de métiers à part entière en termes de compétences et de temps. Ce sont des sujets complexes et profonds, qui ne doivent pas faire partie de tâches annexes.

Appliques-tu des notions d’éco-conception ?

Julien : Ce métier utilise beaucoup d’infrastructures cloud. Il y a donc forcément un impact qu’on peut améliorer.
Il y a justement un pan du métier qui tourne sur une meilleure utilisation des ressources dans le cloud, et c’est notre rôle de bien veiller à leur juste utilisation. Il faut avoir cette dimension en tête et avoir un rôle de recommandation, d’autant plus qu’il y a à la fois un impact écologique mais aussi financier.
Il nous revient d’insuffler cette démarche, pour faire des choses plus propres et sobres et éviter des lignes inutiles consommatrices de ressources.
Après ce n’est qu’un pan de l’écosystème numérique. On essaye donc d’avoir ce rôle de sensibilisation dans les équipes, mais souvent c’est davantage l’aspect financier qui convainc et qui du coup est mis en avant en premier.

Paul-Henry : J’y suis sensibilisé, mais c’est une notion qui me semble difficile à évaluer sur mon périmètre. Bien qu’il y ait des actions possibles, notamment en infrastructure. Par exemple, avec Kubernetes, on mutualise davantage les ressources donc ça peut avoir un impact positif.
Avant j’étais également fan des blockchains et je le suis moins maintenant. J’ai davantage conscience que ça nécessite beaucoup de composants, de calculs, de serveurs et de stockage et que cela a un fort impact environnemental. Donc j’adhère moins au concept.

Ruaraidh : Je pense qu’on y va naturellement. L’optimisation fait clairement partie du métier. Ce n’est pas forcément aussi simple, mais il y a une volonté de créer des systèmes optimisés qui permettent un gain financier, et aussi d’impact environnemental. Et même si une majorité d’entreprise ne le fait pas dans un but éco responsable, l’impact économique et écologique reste corrélé.
Après, ça reste plus problématique dans de grandes structures. On y rencontre plus d’inertie, et ce n’est pas toujours facile de reprendre entièrement ce qui a été fait historiquement. On peut donc facilement optimiser le nouveau, mais ce peut être plus lent pour l’optimisation de l’existant, qui lui implique plus de responsabilités.
Quand on parle d’écologie on se demande toujours si on a le temps. Mais même si ça peut paraître lent, il y a de plus en plus de personnes sensibilisées qui sont motrices de ces changements en entreprise.

Pourquoi et pour qui recommanderais-tu ton métier ?

Julien : Il faut être honnête, c’est un métier avec de la pression, car il y a des responsabilités. En tant que garant du bon fonctionnement, on est aussi responsable en cas de dysfonctionnement. Tu peux ne pas être responsable d’une erreur, mais tu restes responsable du bon fonctionnement global. Il faut en être conscient car ça ne convient pas à tout le monde.
Mais pour les personnes qui aiment le sens du service rendu et de la rigueur, c’est très épanouissant.
Quand je fais un bon travail, c’est qu’on oublie que je suis là. Il faut vraiment être préoccupé par ses clients. Car s’il y a un problème il peut y avoir des impacts concrets importants, que ce soit financiers, mais aussi logistiques ou physiques selon le domaine d’application. Avant je travaillais dans un service de domotique avec des serrures connectées. Donc en cas de soucis, des personnes pouvaient se retrouver bloquées devant leurs portes.
Il faut aimer la rigueur, être attentif aux détails et avoir un esprit analytique.
Il faut également être polyvalent. Il y a aussi des éléments de programmation à connaître, en termes de langage déclaratif, pour décrire les comportements attendus. Ce n’est pas extrêmement difficile à apprendre et ne nécessite pas de savoir très bien coder.
Je conseille aussi de savoir parler anglais. Il y a une grande part de veille sur des problématiques parfois précises, et une majorité des forums et des ressources utiles sont en anglais. Donc il est important d’au moins le comprendre et le lire.

Paul-Henry : Je le recommanderai à beaucoup de développeurs, notamment back. Je pense que c’est toujours intéressant de savoir ce qui se passe derrière, de la même façon que je m’intéresse à leur code. On a ainsi une vision plus profonde des choses pour comprendre comment elles fonctionnent et interagissent.
Je le recommande aussi à des personnes qui aiment bien communiquer et sont curieuses.
Le devOps est d’abord une manière de penser. Avec l’idée de rapprocher les développeurs de la plateforme et d’arrêter de faire des choses silotées. Et aussi de mieux comprendre ce qui se passe autour et de savoir poser, déployer une architecture en en comprenant la raison. C’est abordable par pas mal de monde, et c’est de toute façon intéressant d’y être sensibilisé en tant que développeur.
Ce domaine peut paraître abstrait, mais au final c’est presque de la mécanique. D’ailleurs il ne faut pas forcément savoir coder, mais au moins réussir à lire le code. Cela permet d’avoir de l’autonomie pour comprendre ou aider à résoudre un bug.
Et comme on utilise pas mal d’outils qui sont dans des langages différents, ça permet aussi de mieux comprendre leur fonctionnement, leur évolution, et d’en comprendre la logique et l’intention. Ce qui permet de ne pas en détourner l’utilisation.

Ruaraidh : Je ne pense pas qu’une certaine logique ou un état d’esprit soit nécessaire pour travailler dans l’informatique. Au contraire ! Il faut des idées neuves et fraîches.
Contrairement au développement, le système demande tout de même des connaissances assez larges qui nécessitent d’être acquises sur la durée pour être opérationnel, et de maîtriser une boîte à outils fournie. Il faut donc une réelle appétence.
Mais le poste reste accessible à tous types de profils. Et surtout à ceux qui ont une appétence pour le système dans son ensemble, pas forcément que d’un point de vue informatique. D’ailleurs ce n’est pas obligé d’être passionné par l’informatique pour apprendre. Le système informatique est un système comme d’autres. On peut donc apprendre à aimer l’informatique par la suite, alors que l’attirance pour le système est plus innée.
Je suis persuadé que n’importe qui peut faire n’importe quoi. Et il faut plus de diversité et inciter plus de monde à s’intéresser à ce métier, donc je le conseille vraiment à tout le monde.

Nous publions régulièrement des articles sur des sujets de développement produit web et mobile, data et analytics, sécurité, cloud, hyperautomatisation et digital workplace.
Suivez-nous pour être notifié des prochains articles et réaliser votre veille professionnelle.

Retrouvez aussi nos publications et notre actualité via notre newsletter, ainsi que nos différents réseaux sociaux : LinkedIn, Twitter, Youtube, Twitch et Instagram

Vous souhaitez en savoir plus ? Consultez notre site web et nos offres d’emploi.