🎙 En Solo #11 - Qu'est-ce qu'un Ingénieur DevOps, un SysOps ou AdminSys?

Général Annonces
#1

:question: Ingénieur DevOps, un SysOps, cloudOps ou un AdmynSys ? On s’y perd.

Aujourd’hui je réponds à une question d’Olivier qui me demande :

Bonjour compagnon, Je souhaiterais que tu nous parle plus précisément de la définition de ce qu’est un DevOps Engineer en rapport avec un SysOps ou Admin Sys qui ont durant quelques temps semé la confusion.

Et toi, quel métier tu fait ou lequel tu aimerais faire ?
Et lesquels te font rĂŞver ?

#Mouvement #DevOps #SysOps #CloudOps #AdminSys #Recrutement

#2
#3

J’avais répondu à ton poste LinkedIn à ce sujet mais peut être serait-t-il intéressant aussi de lancer le débat ici.

D’après ta conclusion, l’ingénieur DevOps s’occuperait exclusivement du CI/CD… donc pas de l’infrastructure de production, de la partie opérations. Il y aurait donc une équipe dédiée à l’infra et l’opérationnel spécifiquement (ce qu’on pourrait appeler aussi le “run”) ?!

Ce positionnement me semble problématique car cela casse la synergie entre dev et ops que prône la culture DevOps.

Pour moi le poste est plus complexe et plus large que ça

#4

Je ne suis pas d’accord avec la formulation dans le podcast. “S’il y a ops dedans c’est que c’est lié à l’infra et au systeme d’opération mais pas au code”.

C’est justement ce que je demande à mes collaborateurs (que je considère comme devops) : qu’ils sachent comprendre comment une application tournent, se déploient, ses contraintes - le côté dev - et les contraintes/besoins côté infrastructure.

Je ne leur demande bien entendu pas d’être expert en tout, sur toutes les solutions… et chacun à des zones d’expertises différentes. Ils partagent par contre une bonne culture des 2 mondes, ils savent s’adapter, comprendre et travailler avec à la fois les devs/lead dev comme avec des hébergeurs.

En conséquence, je ne suis pas d’accord sur le fait qu’une personne ne peut pas dev et faire de l’ops ou que s’il fait le 2 il le fait mal.
Par contre clairement ça demande un investissement pour dépasser ces fonctions de bases.

Pour compléter je m’étais exprimé le ce qu’était un devops sur Twitter : https://twitter.com/jygastaud/status/1202680012270383104?s=19

Au plaisir d’en discuter.

1 « J'aime »
#5

Cette vision aussi me semble problématique, la culture DevOps prône le rapprochement des deux corps de métier mais pas la fusion à ce que je sache.

D’un autre coté, dans la mouvance SRE qui se veut une implémentation concrète du DevOps, l’ingénieur SRE serait un développeur qui s’occupe de la partie ops.

Perso, je pense que lorsqu’on est sysops ou ingénieur système, de part la formation, on a forcément un background en développement car ça me semble représenter un tronc commun des formations en informatique (je parle de cycle universitaire).

#6

Si on peut pas être un bon dévelopeur et Ops mais alors qui sont ces gens qui contribuent à des outils comme Docker ou mieux : Kubernetes ?? Avec des problématiques réseaux, storage, isolation, sécurité… :slight_smile:

Pour ma part je suis passionné depuis +15 ans par Linux et tout ce qui gravite autour et j’ai également fait +6 ans de Dev. et je mélange les deux dans mon quotidien. Alors oui, je suis pas un bon dév si tu attends de moi que je maitrise 5 langages et 20 frameworks.

Comment définir un bon dev ? un bon ops ?

Comme tu le dis, l’essentiel est de maitriser les concepts et des outils de bases. Le reste, c’est facile.

#7

Ce sont des ingénieurs logiciels, des ingénieurs systèmes.

Et comme je le disais, il me semble logique qu’un Ops ait des connaissances en développement à partir du moment qu’il à un certain niveau de formation.

J’ai l’impression qu’on voit trop les Ops comme des gens ayant des BTS réseau.

#8

Admin sys, CloudOps, SysOps… Pour moi tout ça c’est la même chose.
Les gens essayent juste de se démarquer en disant “Non non je ne suis pas un admin sys à l’ancienne, je sais utiliser Terraform donc je suis maintenant un CloudOps”, mais en réalité c’est juste l’évolution du métier d’admin sys.

Là aussi, selon moi ce que tu décris c’est juste l’évolution du métier de dev qui doivent maintenant prendre en compte des choses comme le monitoring, la tolérance aux pannes, la façon dont les apps se déploient… Pas un nouveau poste appelé “Devops”.

Il est possible d’avoir des compétences dev et ops, mais au quotidien on travaille quand même majoritairement sur un sujet ou un autre selon moi.

Si je prends par exemple mon cas personnel, je fais aujourd’hui majoritairement du développement mais comme tu le décris appliqué à de l’infra (je développe des produits chez un cloud provider, je prépare un talk qui montrera ce genre de projets mélangeant dev et ops d’ailleurs).
Avant j’étais admin sys. Donc je peux en effet faire les deux (et je touche pas mal à l’ops encore aujourd’hui, et fais beaucoup d’architecture), mais aujourd’hui je gère une équipe “dev”. Si j’étais côté ops, le métier serait complètement différent.

Donc oui, on peut avoir une sorte de double compétence mais à un instant T on fait quand même selon moi majoritairement l’un ou l’autre (même si il y a toujours porosité), sauf éventuellement dans les petites structures. D’ailleurs, sur ce genre de projets mélangeant dev et ops, les deux mondes sont obligés de travailler ensemble.

#9

Salut,

Je dois représenter les plus petites boites ou les grosses boites mais avec peu de développeurs ce qui est mon cas et qui je pense ne faut pas oublier.

On est 1000 personnes mais uniquement 8 développeurs couper entre divisions sans avoir de contacts, je suis le seul à travailler avec 3 autres divisions difficilement car pas dans l’ADN de la boîte. Et même dans ma division où nous sommes trois devs, les supérieurs nous ont collés des étiquettes et nous mettent seul sur un projet la plus part du temps.

J’essaye de faire changer les choses sans succès à ce jour.

Je suis donc obligé de faire du dev (ma formation de base) et de l’ops.

Forcément j’ai des lacunes en ops et forcément à passer du temps à faire de l’ops (ci/cd, bonne pratique, etc…) je n’arrive pas à progresser en dev comme je le voudrais.
Mais j’essaye toujours de faire du mieux que je peux, faire un max de veille technologique etc…

Tout ça pour dire qu’il n’y a pas forcément assez de budget ou de personnes pour pouvoir spécialiser la chose.
Et malgré tout essayer d’appliquer des méthodes et bonne pratiques du mouvement DevOps.

#10

C’est intéressant de voir comment chacun organise et implémente l’approche DevOps dans sont entreprise.

#11

J’ai l’impression qu’il y a un malentendu dans la qualification du « dev » qui est donc très générique. Il peut y avoir des spécialisations dans le dev : dev web, dev php, dev symphonie, dev système, dev java, dev python, dev cobol, dev assembleur, dev embarqué …

Pour définition, un « développeur » c’est un nom de métier qui est venu remplacer le boulot de « analyste programmeur ». Un développeur, c’est donc un gars qui va comprendre une problématique et savoir la résoudre à travers un process programmé/automatisé.

L’« ops » va faire en sorte que les environnements techniques fonctionnent (dev, intégration, preprod, prod, …). Il va mettre des logiciels dans des containers, mettre en place de la supervision, automatiser des déploiements de VM, …

Partant de ces définitions, un « ops » peut très bien être aussi un développeur, je dirais même que c’est indispensable. Un « ops » va prendre une problématique du genre « Je veux surveiller l’état d’un composant », et il saura coder un soft ou un plugin pour répondre à son besoin. Aujourd’hui, on trouve surtout du développement Python pour piloter divers composants cloud. C’est du développement.

Je pense que selon la catégorie de « dev » dont on parle (et c’est cette info que je ne trouve pas), l’ « Ops » ne sera pas en mesure de remplir la mission. J’aurai du mal à imaginer (bien que ce ne soit pas impossible) un même profil faire un développement métier en java/tomcat, puis passer 1H sur le packaging/déploiement et finalement répondre à des alertes de monitoring sur l’état du système.

A priori ce qu’il manque dans la plupart des post et le podcast c’est la tâche précise du « dev ». Je suppose que les « pro ops+dev» ont en tête du développement lié à l’Ops. Les « anti ops+dev » font probablement allusion à du développement d’application métier.

Mon opinion est :

  • Une mĂŞme personne peut savoir fair du « dev » et de l’« ops ».
  • Un « ops » peut (doit) ĂŞtre un « dev »
  • Un « dev » n’est pas forcĂ©ment un « ops » (mais devrait au moins avoir des notions)
  • Selon le type de dĂ©veloppement on peut ou non faire en mĂŞme temps « dev » et « ops »

Un « développeur système » va développer des applications proches du système, qui vont bien exploiter les appels système et fonctionner sur les OS supportés. Parfois, selon les contraintes, il va faire en sorte que le logiciel soit facilement exploitable (log, debug, …), parfois qu’il soit performant, ou économe en ressources, … Les gens qui développent Docker ou Kubernetes sont des développeur système, cela ne signifie rien sur leur qualité d’ « Ops ».

Généralement ces deux profils travaillent de concert. L’« ops » va remonter une liste de features au « dev système » qui lui serait très pratiques pour effectuer son boulot. Le « dev système » à pour tâche d’écouter les demande de l’ « ops » qui est son utilisateur principal.

Rapprocher deux cœurs de métier, et c’est vraiment une bonne chose de mettre un terme à la guerre « les dev ont livré de la merde » vs « c’est encore l’infra qui est pétée ». La question est « est ce que ce rapprochement passe par une seule personne qui connait tous les métiers et les pratiques en même temps » ?

J’ai l’impression que devops signifie plutôt une équipe multi-compétences qui travaillent ensemble. Cette équipe est composée d’ops qui ont de bonnes notions de dev, sans nécessairement être un bon développeur java/tomcat qui connait « Spring » ou « maven ». Cette équipe est également composée de dev qui ont de bonnes notions d’ops sans nécessairement savoir comment configurer la taille des buffers réseau de ton système ou connaitre strace.

+1

#12

Oui c’est exactement ce que je dis, la culture ou l’approche DevOps consiste à briser les silos entre équipes Dev et équipes Ops afin de mettre en place une équipe pluridisciplinaire qui travaille en harmonie afin d’optimiser les livraisons en prod et réduire le time-to-market.

Pour se faire l’approche DevOps s’appuie sur un ensemble de pratiques (infra as code, CI/CD, monitoring, …) qui nécessitent une panoplie d’outils, ce que l’on appelle communément la DevOps toolchain.

Le dev et les ops ont donc besoin de maitriser ces pratiques et ces outils, c’est pour cela qu’on a vu de plus en plus apparaitre le terme d’ingénieur DevOps, pour différencier de l’ops ordinaire qui bosse d’une façon plutôt artisanale.

Et je suis entièrement d’accord avec toi sur le fait que de nos jours l’ops doit savoir coder un minimum et comprendre le monde du développement.

Je pense aussi que tu as raison sur le manque de définition ici du terme “dev”, dans une approche devops, le dev est la personne qui travaille sur le produit, qui développe des features, corrige des bugs, écrit des tests …etc. Il ne développe pas d’outils pour la plateforme. Il peut cependant aider les ops par exemple en exposant des metrics dans son application (produit).

En gros, c’est une évolution du métier d’ops ou de sysadmin, comme cela été le cas avec le métier de dev et la naissance de la mouvance agile avec l’adoption des architectures modernes, de l’intégration continue, …etc.

D’ailleurs DevOps est pour moi une réponse du corps IT pour s’adapter aux changements issues de l’agilité.

Nos métiers se sont complexifiés et requièrent un niveau de qualification plus élevé, ce qui est plutôt valorisant et une bonne chose.

1 « J'aime »
#13

Pourtant, c’est selon moi aux devs de savoir comment leurs applis se déploient (et être autonomes pour réaliser ces déploiements), et également à eux de faire le monitoring de leurs applications (et recevoir les alertes).
Un ops qui reçoit une alerte d’une application qu’il n’a pas développé, qu’est ce qu’il va en faire ? C’est le dev qui saura comment réagir et résoudre si besoin le problème. C’est aussi aux dev de savoir quelles métriques exposer, et quels thresholds configurer (même si les ops peuvent aussi participer à la discussion).

J’ai commencé ce matin ma semaine d’astreinte “dev”, toutes les alertes applicatives vont arriver sur mon téléphone, et non chez les ops. Par contre, si un incident arrive sur la plateforme hébergeant ces applications (par exemple, un hyperviseur saute), là ce sera l’astreinte ops qui recevra l’alerte.

Les ops fournissent donc une plateforme pour déployer les applications, les monitorer (Kubernetes, Prometheus, Consul…), une façon de stocker/exploiter les logs… mais après c’est les devs, qui eux connaissent leurs applications, qui doivent déployer ces applications, exposer les métriques/logs qui vont bien, et recevoir les alertes. Bien sûr, les ops aideront les devs si besoin, comme les devs peuvent aider les ops sur certaines tâches.

Personnellement j’essaye d’avoir toujours la “big picture” en tête sur les applications que je gère (de l’architecture logicelle à l’architecture générale, comment l’application s’intègre dans le reste de l’infra, est monitorée etc…). Et cela demande des compétences dev ET ops :wink:

#14

Comme on dit, YOU BUILT IT, YOU RUN IT.

Le problème est que le build et le run est si diffèrent, que la plupart des gens ne sont intéressés (voir compétents) que par un seul coté

#15

Je suis presque d’accord avec toi. C’est mieux si un dev sais comment son application se déploie. Seulement, il y a des tas de cas ou le dev n’est pas en mesure de savoir car ce n’est pas son métier.

Par exemple, tu déploie une application à fort traffic. Du genre 1000 requêtes / secondes. Les temps d’accès disque sont critique. Les caches et le load balancing deviennent obligatoire. Tu va par exemple:

  • Mettre du content switching pour sĂ©parer les requĂŞte dynamique, des requĂŞtes dynamique, mais cacheable des objets statiques.
  • CotĂ© requĂŞte non cachable, tu va faire du load balancing sur tes serveurs d’application PHP ou tu va en dĂ©marrer 5.
  • Ton PHP va ĂŞtre dĂ©ployĂ© avec du cache opcode
  • Tes requĂŞtes cacheables vont ĂŞtre load balancĂ© vers des varnish
  • Tes varnish vont ĂŞtre configurĂ© pour mettre en cache des rĂ©ponses 1H
  • Tes objets statiques vont ĂŞtre servis par des nginx depuis des disques SSD.
  • Tu va mettre des switch 10Gbps pour rĂ©duire les temps de latence entre les composants

Et bien, je pense que tout ça, ton dev ne le connais pas car ce n’est pas son métier, et ca ne doit pas être son métier.

En revanche, le dev répondre a tes exigences d’intégration. Par exemple pour le load balancing, tu doit savoir si les session sont centralisées en base ou si il faut faire du stick de session. Seul le dev peut te le dire.

Le dev doit aussi te dire comment différencier une requête cacheable d’une requête non cacheable. Idéalement, il utilise les bon header HTTP, mais ca ne fonctionne pas toujours.

Le dev doit te dire comme superviser l’application, par exemple un url qui te donne l’état de l’instance.

Bref, c’est une coopération entre dev et ops au sein d’une équipe devops. Après pour les astreinte, si le code peut tomber en panne, peut être faut-il qu’il y a systématiquement un dev et un ops qui soient d’astreinte. Je reconnais que lorsque on ne se fait pas réveiller la nuit, on pourrait être moins soucieux de la robustesse de ce que l’on produit.

#16

Ce que tu décris rentre selon moi en partie dans le “Les ops fournissent donc une plateforme pour déployer les applications”, car en effet c’est pas le dev qui va maintenir le load balancer ou l’infra d’autoscaling.

Mais comme tu le dis, seul le dev pourra dire quoi cacher, quelle application est stateful/stateless, comment accéder aux métriques etc…

Quand parle d’être autonome dans le déploiement des applications, je veux dire que c’est l’équipe dev qui doit réaliser les déploiements (et donc être capable de comprendre le format de l’artefact qui sort de la CI, et donc comment l’application est packagée).

#17

Oui et non.

Non ce n’est pas uniquement aux dev de savoir comment l’application se déploie, c’est à l’ensemble de l’équipe de savoir comment l’application fonctionne, connaitre ses besoins spécifiques, ses flux de données…etc.

Oui c’est aux dev de déployer leur application lorsque la release est validée, cela n’empêche pas les ops d’être au courant, il ne faut pas qu’ils soient déconnectée du cycle de développement.

Oui, l’approche DevOps confère plus de libertés aux équipes de dev mais cela va aussi avec plus de responsabilité, dont le monitoring. Mais là encore, tu ne peux pas juste dire aux ops de s’occuper de l’infra et aux dev des applications/services, ce n’est pas la bonne façon de penser car c’est une façon de penser orientée métier, il faut avoir une façon de penser orientée business/produit, mesurer l’impact des incidents sur celui-ci, ce qui va permettre d’établir les priorités, les niveaux d’alertes et les gens concernés… et pour avoir cette vue là il faut impliquer tout le monde et y réfléchir ensemble et non individuellement.

Pour pouvoir designer et opérer une plateforme performante et optimisée il faut comprendre les besoins et le fonctionnement de ce qui tournera dessus.
Et oui, il faut s’entendre sur des normes et des process pour fluidifier les développement : format des logs, gestion de la configuration/secrets, monitoring …etc.
Il faut aussi que les ops (au sens large) accompagnent les dev dans leur utilisation des outils qui sont mis à leur disposition, pour s’assurer que c’est fait correctement, que cela soit des approches standardisées, que les prérequis en terme de sécurité et de fiabilité soient respectés, …etc.
Il ne s’agit pas de laisser les dev “jouer” et de s’en laver les mains.

Je trouve aussi important que les Ops soient impliqués en amont, dès le début de la réflexion sur un projet (produit).

Oui les ops doivent avoir la “big picture” et oui le métier d’ops dans un environnement devops requière des connaissances en développement logiciel.
Mais là encore, ce n’est pas bizarre ! A partir d’un certain niveau de formation tu es forcément passé par un tronc commun où tu as étudié la partie liée au développement, à l’architecture des SI, …etc.

#18

Oui, si je déploie une nouvelle application sur Kubernetes par exemple les ops savent dans quel namespace ça tourne, sur quels workers si l’app est liée à un type spécifique… Je n’ai pas dit que les ops ne devaient pas le savoir, mais que le dev devait :wink:

D’ailleurs, quand on travaille sur un nouveau projet, on commence par écrire une spec décrivant le projet, son archi, son fonctionnement, les différents besoins infras … et cette spec est lue/validée par tout le monde. Les ops font la même chose quand de nouveaux outils sont mis en place. Donc on est tous au courant de ce qui se passe

Par contre quand je fais une nouvelle release ne demandant pas de changements d’infrastructures (donc la majorité des releases une fois le projet sorti) je ne demande pas aux ops avant de valider quelque chose, mon équipe est autonome pour déployer en prod.

Si c’est une nouvelle feature on fera une démo (où les ops sont présents), et on continue de faire des réunions régulières entre les différentes équipes (dev et ops) pour discuter des sujets en cours et des features qui arrivent, mais le déploiement en lui même sera géré par les devs.

Mais là encore, tu ne peux pas juste dire aux ops de s’occuper de l’infra et aux dev des applications/services

Ça dépend de comment l’alerting est fait. Je pense quand même qu’une alerte générée par une application doit arriver en priorité aux devs. Cela n’empêche pas d’avoir d’autres alertes qui arrivent également chez les ops en parallèle.
Si demain une application A n’arrive pas à contacter une application B, cela peut être un bug dans le code (dev), un problème réseau (ops), un problème de perf (dev et ops à la fois selon le problème etc…), et pleins d’autres raisons de ce style. Voir même une fausse alerte (qui s’est jamais planté dans un script de monitoring ? :slight_smile: ).

Mais dans tous les cas l’application A enverra probablement son alerte au dev oncall, et peut être qu’en parallèle un autre système de monitoring (réseau par exemple) enverra une alerte aux ops, chaque équipe pouvant escalader à l’autre si besoin (si l’astreinte sonne cette nuit et que je vois que la plateforme est down je vais pas attendre 2 heures pour escalader).

Ce que je veux dire, c’est que ce n’est pas nécessairement aux ops de recevoir en premier toutes les alertes. Et dans tous les cas, la résolution peut se faire à plusieurs.

Il ne s’agit pas de laisser les dev “jouer” et de s’en laver les mains.

Je suis d’accord, surtout que ça peut avoir des conséquences assez importantes. Par exemple, un dev qui met un request ID en tag dans prometheus risque de tuer l’outil.

Mais là encore, ce n’est pas bizarre ! A partir d’un certain niveau de formation tu es forcément passé par un tronc commun où tu as étudié la partie liée au développement, à l’architecture des SI, …etc.

L’expérience est plus importante que la formation je pense. Si je devais appliquer ce que j’ai vu en cours, je coderai en Java en suivant les principes du gang of four et en faisant des FactoryFactory :wink:

1 « J'aime »
#19

Oui dans l’ensemble nous sommes d’accord, l’objectif du DevOps s’est de permettre aux dev de bosser avec le plus d’autonomie possible, d’ailleurs, dans les équipes il y a en général plus de dev que d’ops, si tu dois tenir la main des dev à chaque release ce n’est pas possible.

Chez nous aussi c’est pareil, on intervient pas du tout lorsque c’est du déploiement de features dans la majorité des cas sauf si cela requière d’adapter l’infra. Ce qui nous libère du temps pour bosser sur d’autres choses : audit & sécurité, mises à jour, réduction des couts, …etc.

1 « J'aime »