D’accord, on dit ingénieur DevOps, mais le titre est trompeur et en théorie, il ne devrait pas être utilisé.
DevOps n’est pas la responsabilité d’une seule personne. C’est dans le nom lui-même. C’est l’objectif continu d’améliorer les processus entre les développeurs et les opérateurs. On a souvent l’impression que donner à quelqu’un ce titre place la responsabilité des pratiques DevOps sur cette seule personne, au lieu de partager la responsabilité entre tous les ingénieurs.
Suggérer que quelqu’un est purement un ingénieur DevOps semble presque impliquer qu’il est un coach Agile ou quelque chose de similaire. Comme tel, ils ne font aucun codage, ils poussent simplement les gens vers de meilleures pratiques DevOps.
Mais en réalité, l’ingénieur DevOps est toujours un opérateur qui code. Alors pourquoi utiliser le terme DevOps ? Eh bien, probablement parce que c’est déroutant quant à ce que font les opérateurs en premier lieu et utiliser un terme vague pour quelqu’un dont les responsabilités sont vagues semble s’aligner.
Donc, dans cet article de blog, je vais parler des nombreux travaux qu’un ingénieur DevOps peut effectuer, des titres correspondants et de ce que je pense être le titre réel.
Les titres
Ingénieur pipeline
Je n’ai jamais vu personne utiliser réellement ce terme, bien que je pense que cela pourrait certainement en être un. Les ingénieurs DevOps passent beaucoup de temps à créer et à configurer les pipelines qui automatisent les tâches de génération, de test et de déploiement d’une application.
Je pense que le travail est suffisant pour que vous puissiez embaucher quelqu’un qui se consacre uniquement à ces tâches. Surtout lorsque vous plongez dans la myriade d’emplois de sécurité et de performance qui peuvent être ajoutés.
Vous pouvez également utiliser les titres CI Engineer, CD Engineer ou CI/CD Engineer. Ceux-ci seraient probablement plus clairs car un ingénieur de pipeline ressemble à un emploi dans le secteur pétrolier et gazier.
Ingénieur Cloud
En un sens, l’ ingénieur DevOps provisionne, configure et maintient l’infrastructure, les réseaux et les bases de données. Ainsi, vous pourriez être tenté d’utiliser des titres comme :
- Ingénieur Infrastructures
- Ingénieur réseau
- Administrateur de base de données
Sauf que ces rôles impliquent vraiment de travailler de manière plus tangible avec ces objets, comme travailler avec des serveurs sur site, créer des routeurs ou se concentrer sur le réglage des performances de la base de données, par opposition à travailler avec ces objets dans le cloud.
Cloud Engineer est un terme plus approprié. Cependant, je ne pense pas que cela englobe vraiment le rôle complet. J’en suis venu à utiliser le terme Cloud Engineer pour désigner les ingénieurs qui ne savent que travailler avec une plate-forme cloud. Ce sont souvent des personnes avec des certifications cloud et sans solide expérience en ingénierie. Ils ont tendance à ne pas posséder les compétences de ligne de commande d’un administrateur système.
Administrateur systèmes
La plupart des ingénieurs « DevOps » vraiment expérimentés que je rencontre étaient des administrateurs système. Ce terme suggère que vous installez et configurez de nombreux logiciels sur des serveurs tout en configurant leurs connexions réseau. Mais comme il s’agit d’un terme plus ancien, il n’inclut souvent pas d’expérience avec les plates-formes cloud.
Combiner un administrateur système avec un ingénieur cloud serait ce qui se rapproche le plus d’un ingénieur « DevOps ».
Ingénieur fiabilité site
Vous pourriez être tenté d’utiliser le titre Site Reliability Engineer, mais ce terme a été inventé par des ingénieurs de Google et pour en être un, vous devez suivre tous les principes énoncés dans le livre qu’ils ont publié. Je ne pense pas que cela corresponde à l’esprit de DevOps, qui est une discussion ouverte.
Je n’ai jamais vraiment été un grand fan du titre d’ailleurs, car je pense que le titre suggère une portée plus étroite pour un ingénieur en fiabilité de site que ce que l’on attend probablement d’un.
Par exemple, vous pourriez dire que créer une tâche de build est assez loin de travailler sur la fiabilité du site. Mais je pense que c’est un travail auquel on s’attendrait à faire partie du travail.
Opérateur
Eh bien, que diriez-vous d’un simple opérateur ? J’utilise le terme tout le temps, mais probablement pas pour une raison suffisante. DevOps est en fait un portemanteau de « développement » et « opérations », et non de « développeur » et « opérateur ».
Mais il est facile de confondre. Les développeurs travaillent sur le développement et s’appellent eux-mêmes « devs ». La logique s’ensuivrait que les opérateurs travaillent sur les opérations et s’appellent eux-mêmes « ops ».
Au final, je trouve ce titre trop vague et certes un titre que je ne devrais pas utiliser autant. Si vous dites à quelqu’un que vous travaillez dans les opérations, cela pourrait vraiment être n’importe quelle division de l’entreprise. Opérations de quoi ? Opérateur de quoi ?
J’ai également rencontré une confusion si je fais référence à une personne opérateur ou à une application opérateur (un opérateur Kubernetes).
Ingénieur plateforme
C’est le titre qui, je pense, englobe vraiment le rôle. Nous fournissons des serveurs, des réseaux, des bases de données et d’autres infrastructures. Nous créons des pipelines automatisés pour créer, tester et déployer des applications. Nous avons configuré tout cela pour qu’il soit hautement disponible et mis en place une surveillance pour améliorer la disponibilité et les performances de tout. Et nous nous retrouvons souvent à faire un peu d’administration système sur le serveur occasionnel ou le nœud hérité.
Mais toutes ces choses que nous créons et gérons créent une plate-forme sur laquelle les applications s’exécutent. C’est un titre délibérément vague parce que le travail est un peu vague. Mais ce n’est pas trop vague puisqu’il utilise le périmètre de la plateforme.
C’est aussi un peu adapté à l’ambiance du rôle. Lorsqu’une personne entre dans une maison, elle regarde souvent les luminaires, les murs, les fenêtres, les portes, etc., comme quelqu’un qui regarde les boutons, les pages et les données d’une application.
Mais une maison ne peut exister sans une base solide, tout comme une application ne peut exister sans une plate-forme solide. L’ingénieur de plate-forme est crucial pour la santé d’une entreprise technologique, mais vous ne le remarquez pas vraiment à moins qu’il y ait une fissure dans la fondation.
Conclusion
Voilà donc mes 2 cents sur les titres. J’ai utilisé le titre d’ingénieur DevOps dans le passé. Il est difficile de s’en éloigner. C’est le titre le plus reconnaissable du rôle.
J’utilise en fait le titre Kubernetes DevOps Engineer pour moi-même. Non pas parce que je pense que cela décrit avec précision le travail que je fais, mais parce que c’est quelque chose dont les entreprises ont souvent besoin et qu’il est extrêmement difficile de trouver quelqu’un qui ait vraiment de grandes compétences pour mettre en place les meilleures pratiques DevOps sur Kubernetes.
Mais je suppose que si les titres étaient parfaits, nous serions des ingénieurs de plate-forme spécialisés dans ceci, cela et l’autre. De la même manière que les médecins se spécialisent dans un domaine.
Article source: https://ericfossas.medium.com/theres-no-such-thing-as-a-devops-engineer-68eb8075a6ef