Pourquoi ne devrais-je pas essayer d'embaucher un «ingénieur DevOps»?


32

L'idée d'avoir un ingénieur DevOps est devenue très populaire récemment , et il semble attrayant de ne pouvoir compter que sur une personne capable de prendre part aux nombreux avantages de DevOps, comme décrit dans le blog de Puppet :

Les organisations qui utilisent les pratiques de DevOps fonctionnent énormément: elles déploient du code jusqu'à 30 fois plus souvent que leurs concurrents et leur déploiement échoue de 50%, selon notre rapport 2015 sur l'état de DevOps.

Cependant, j'ai constaté de nombreuses oppositions à l'idée d'un ingénieur DevOps pour essayer d'apporter les améliorations suivantes:

Même avec un large accord sur les attributs fondamentaux de DevOps, le terme «ingénieur DevOps» fait l'objet de controverses. Certains disent que le terme lui-même contredit les valeurs de DevOps. Jez Humble, co-auteur de Continuous Delivery, souligne que le simple fait d'appeler un ingénieur de DevOps peut créer un troisième silo, en plus des développeurs et des opérateurs - "... un moyen clairement (et ironique) de résoudre ces problèmes. . "

Pourquoi est-ce que ce ne serait pas une si bonne idée pour une entreprise de faire appel à un ingénieur DevOps pour essayer de mettre en œuvre DevOps, par opposition au changement organisationnel prôné par des blogs comme celui-ci ? Les avantages seront-ils annulés simplement en ayant un rôle isolé dans DevOps?


Vous devez faire tout ce qui est le plus efficace pour votre entreprise, votre équipe et votre projet. Vous devriez expérimenter pour savoir ce qui est le plus efficace. L'agilité opère un changement adapté à votre situation spécifique. Comme le dit Kent Beck, "toute réponse décente à une question intéressante commence," ça dépend ... ""
Adrian

Réponses:


24

TL; DR : vous ne devriez jamais essayer de recruter une équipe DevOps


Il existe essentiellement trois rôles les plus communs à recruter pour:

  1. DevOps Architecte / Evangéliste
  2. Ingénieur DevOps
  3. Ingénieur CI / CD

Ces rôles sont distincts de vos 6 rôles essentiels de développement logiciel qui composent traditionnellement l’organisation de génie logiciel:

  1. Gestion des produits
  2. Développement de logiciels
  3. Développement d'outils
  4. Sécurité et conformité
  5. Qualité et test
  6. Opérations système (SRE)

Passons en revue les trois rôles un à un et voyons comment ils s’insèrent


DevOps Architecte ou Evangéliste

  • Pourquoi : Si vous êtes perdu, lent, brisé et que vous ne savez pas quoi faire.
  • Quand : au début du processus dans les étapes de planification.
  • Quoi : rôle de niveau de gestion pour guider tous les gestionnaires et les responsables de l'ensemble de l'organisation du génie logiciel. Cette personne planifiera la transformation complète de votre organisation d'ingénierie en un état de fonctionnement optimal.
  • Qui : Un membre consultant expérimenté dans les domaines de la théorie, des pratiques de gestion, de la culture et des opérations, qui relève directement du vice-président du génie logiciel.

Dans certains cas, et pour les petites et moyennes entreprises, vous pouvez engager le processus en embauchant une société de conseil telle que DORA.

Ingénieur DevOps

  • Pourquoi :
    1. Combler les lacunes entre les équipes si elles sont organisées en fonction des rôles fonctionnels mentionnés ci-dessus, afin de garantir une coopération entre niveaux fonctionnels.
    2. S'intégrer aux équipes axées sur les produits, qui ont chacun des 6 rôles traditionnels inclus, pour aider à combler les lacunes en matière de connaissances et pour aider à la mise en œuvre et à l'adoption de pratiques et d'outils novateurs.
  • Quand : Une fois que vous avez défini vos plans et que la transformation organisationnelle commence et que toute l'équipe de direction est impliquée.
  • Quoi : Activer la coopération interfonctionnelle, veiller à ce que les limites des équipes soient décomposées, à ce que les optimisations locales au sein des équipes ne créent pas d'obstacle à un débit de travail élevé tout au long de la chaîne de valeur, des souhaits des clients aux livraisons.
  • Qui : Ingénieur expérimenté ayant des compétences à la fois en développement de logiciels et en exploitation de systèmes. Il devrait être compétent dans les meilleures pratiques, les processus et les changements de culture liés à la transformation de DevOps.

Ingénieur CI / CD

  • Pourquoi : pour vous aider à implémenter les pipelines CI / CD, intégrez votre chaîne d'outils, apportez les outils qui permettront un meilleur fonctionnement de l'entreprise.
  • Quand : lors de la transition dans une organisation plus grande, les rôles ci-dessus ont déjà été remplis.
  • Quoi : Ingénieur, qui fait essentiellement partie de l'équipe des outils qui sera en mesure de configurer les pipelines CI / CD et de commencer à intégrer les systèmes internes de manière à éliminer les frictions du débit de travail.
  • Qui : Ingénieur expérimenté dans les outils, le processus d’intégration, la gestion des versions et les pratiques de DevOps. Quelqu'un qui comprend qu’il remplace le gating humain dans le processus de publication par Automation.

11
J'ai du mal à faire le lien entre votre tl; dr et le reste de la réponse où vous donnez des raisons pour embaucher ...
Tensibai

Le reste des réponses explique qu'aucun des rôles liés à DevOps ne permet de créer une équipe de ces personnes. N'embauchez pas de nouvelle équipe, ne placez pas des personnes dans des endroits spécifiques de votre organisation en fonction de vos besoins.
Jiri Klouda

5
@JiriKlouda excellente réponse, je suis presque à 100% d'accord avec le terme "Opérations système (SRE)" - Opérations système! = Site Reliability Engineer, ce dernier est le modèle de Google pour DevOps, qui incarne toujours les principes de base de DevOps mais conserve les avantages d'avoir une équipe d'opérateurs spécialisés.
Richard Slater

Ce que je voulais dire, c’est une équipe opérationnelle sous quelque forme que ce soit, traditionnelle ou SRE ou toute autre forme d’infrastructure ou de gestion de plate-forme. Et croyez-moi, vous pouvez avoir des équipes de Site Reliabikity sans adopter complètement DevOps :)
Jiri Klouda

1
Honnêtement, il n'y en a tout simplement pas assez. Les ingénieurs CI / CD doivent en savoir assez pour concevoir les pipelines. L'architecte DevOps peut effectuer le travail de haut niveau au niveau organisationnel. J'ai séparé le rôle de l'ingénieur DevOps car il présente des caractéristiques différentes. C’est un travail d’ingénierie orienté outils, il peut facilement faire partie d’une équipe (équipe outils / intégration / applications internes). C'est ce que les gens confondent le plus souvent avec les ingénieurs de DevOps. C'est l'évolution des ingénieurs de publication, mais avec l'automatisation. Au lieu de gating, ils se contentent maintenant de construire et de surveiller l'automatisation.
Jiri Klouda

10

Je dirais que Devops Engineer, tel que décrit dans votre question, est principalement un rôle de sysadmin. Citer les compétences ici pour le contexte de cette réponse:

Votre équipement d'escalade.

  • Solide expérience de l'administration Linux / Unix en automatisation / gestion de la configuration avec Puppet, Chef ou un équivalent
  • Capacité à utiliser une grande variété de technologies open source et de services cloud (une expérience de AWS est requise)
  • Solide expérience de SQL et de MySQL (expérience NoSQL est également un atout, car nous utilisons également Redis)
  • Compréhension pratique du code et du script (PHP, Python, Perl et / ou Ruby)
  • Connaissance des meilleures pratiques et des opérations informatiques dans un service toujours actif et toujours disponible

Dans cet exemple de description de travail, DevOps Engineer est juste un mot à la mode pour un administrateur système familiarisé avec une infrastructure en nuage, une automatisation, capable de lire du code pour faciliter le diagnostic et conscient des pratiques et des solutions de haute disponibilité.

Ceci est vaguement lié aux pratiques de DevOps et à la rupture de silo entre développement et opérations, comme le montre cette question Quelle est la différence entre Sysadmin et DevOps Engineer?

Ce ne sera pas une bonne idée, car un administrateur système, à quel point il / elle peut être à l'aise avec la pratique et la culture de devops, n'est pas la bonne personne pour conduire la transformation de l'entreprise. Vous ne serez pas embaucher cette personne avec un changement de culture à l'esprit, mais avec une vue de configuration de l'outil, ce qui ne aidera pas vraiment briser les processus. Cela peut aussi être mal reçu par ses collègues et vous ne ferez que résister au changement si aucun changement de culture n'est prévu à l'avance.

La réponse de @ Jiri Klouda donne un bon aperçu du rôle acceptable d’un ingénieur DevOps Engineer, ainsi que de la mesure dans laquelle le changement apporterait de la valeur et contribuerait au succès.


1
Comment suggérez-vous une distinction entre un administrateur système qui lit aisément le code pour diagnostiquer les problèmes, l'infrastructure et l'automatisation du cloud et les administrateurs système traditionnels qui ont beaucoup d'expérience mais aucune de ces compétences?
avi

@avi par leur CV, le mien pour l'exemple que je suis plus à l'aise de comparer, a ceux tout en étant intitulé Net / Sysadmin. J'ai des références à devops organisation pour certains projets avec lesquels j'ai travaillé. Et je ne cours généralement pas pour une proposition utilisant devops comme mot à la mode en raison des mises en garde que je mentionne dans cette réponse (été touché une fois pendant un contrat)
Tensibai

@Avi si vous voulez dire dans une proposition d'emploi, dans les détails de la proposition, les qualifications requises sont bien différentes de celles de la question et de celles de la réponse de Jiri pour conserver les titres de poste en conséquence. IMHO
Tensibai

1
J'ai tendance à dire qu'un administrateur système qui n'est pas à l'aise avec l'automatisation est simplement un administrateur système peu qualifié, et non un titre différent. Voir aussi cet essai de John Allspaw .
Xiong Chiamiov

6

Je me rends compte que cette réponse pourrait ne pas vous convenir parfaitement, mais voici ce que j'ai fait

J'étais le premier développeur travaillant dans une startup très active du commerce électronique, avec un trafic incroyablement élevé. Je me rends compte que la société était encore jeune et que, pendant un certain temps, je serais la seule ressource technique interne.

Sachant cela, j'ai décidé de structurer mon infrastructure de telle sorte que je devrais faire l'administration de systèmes ZÉRO.

J'ai décidé d'héberger sur le cloud, car cela me libérait de la maintenance des systèmes. Je recherchais un ingénieur AWS ayant une expérience de la marionnette. Ensemble, nous avons conçu une infrastructure autoscalable, écrite sous forme de code dans cloudformation. Tous les fichiers de configuration étaient versionnés dans marionnette.

Cela m'a permis, en tant que développeur, d'assumer ce rôle de devops. J'ai construit des outils de libération de code, en python, en tissu. J'ai utilisé le même script pour amorcer mon application sur de nouveaux serveurs automatiquement mis à l'échelle.

Cela a très bien fonctionné et aujourd'hui, 3 ans plus tard, je ne fais toujours aucune maintenance du système. Nous avons un administrateur système (le même ingénieur AWS) pendant 10 heures par mois et j'essaie de structurer ses sprints de manière à ne pas devenir une gêne pour lui. De cette manière, je respecte son temps et gère ses sprints de la meilleure façon possible.

Si un système a une performance dégradée, je le résilie simplement et un autre tourne à sa place.

J'espère que cette réponse pourrait vous être bénéfique


Très utile, merci. Il est intéressant d’entendre comment vous êtes essentiellement devenus ce que d’autres appellent un «ingénieur DevOps» indirectement, et je pense (d’après ce que les autres réponses ont dit) que votre façon de faire est plus conforme à la philosophie de DevOps de ne pas avoir un «DevOps complètement séparé». ' département. On dirait que cela a bien fonctionné pour vous jusqu'à présent!
Aurora0001

Donc, fondamentalement, vous gérez tout vous-même? Que se passe-t-il si vous quittez l'entreprise? L'entreprise pourra-t-elle survivre? Quel est le point de vue de votre direction à ce sujet?
030

L'infrastructure se gère elle-même. Il est entièrement documenté et nous utilisons Terraform & Puppet pour orchestrer l’infrastructure et gérer les configurations de serveur. Ainsi, en réalité, tout ingénieur marionnettes / terraform possédant une expérience AWS peut s'y connecter directement. Je suis désormais actionnaire de l'entreprise et notre équipe de développement s'est considérablement développée. Heureusement, tout le monde sait maintenant comment l'infrastructure
évolue

4

Vous ne devriez pas embaucher d'ingénieur DevOps car DevOps englobe une telle variété de disciplines qu'il est impossible pour un individu d'être un expert dans tous les aspects de ces disciplines. En embauchant un homme à tout faire, vous embaucheriez un maître sans exception.

DevOps est nécessairement une entreprise basée sur une équipe et vous ne pouvez pas vous attendre à ce qu'une seule personne réponde aux attentes de toute une équipe. Considérez la portée de DevOps. Une personne ne peut éventuellement:

  • Devenir développeur rockstar en [langue]
  • Soyez un gourou du réseautage, connaissant tous les RFC requis
  • Être un administrateur de systèmes exerçant
  • Soyez un testeur QA expert
  • Être un administrateur de base de données
  • Spécialisé dans le stockage et la sauvegarde
  • Connaître la fiabilité du site
  • Potentiellement d'autres disciplines aussi

Certains des domaines ci-dessus ont même des sous- disciplines, telles que l’administrateur de systèmes Windows vs l’administrateur de systèmes Linux / Unix ou vous utilisez peut-être plus d’un langage de codage dans votre.

Personne ne peut être expert en la matière, ce qui signifie que si vous recherchez un ingénieur DevOps, lorsque le domaine le plus faible de votre équipe DevOps est la mise en réseau, vous ne faites pas un très bon travail pour faire valoir votre besoin de spécialiste en réseau. pour votre équipe DevOps . Bien qu'aucun individu ne doive se voir attribuer un rôle spécifique dans l'équipe de DevOps, vous rendriez un mauvais service à votre équipe en prétendant qu'il n'y a aucun spécialiste ou expert en la matière dans le champ d'application de DevOps. Basculer le pendule d’un extrême à l’autre - passer de la mise en silo à la prétention comme si tous les rôles de votre équipe DevOps étaient identiques - pouvait poser autant de problèmes.

Même si former des membres de l'équipe dans plus d'une discipline - en particulier dans les domaines qui se chevauchent, est une bonne chose, s'attendre à ce qu'ils soient capables de maîtriser un aussi grand volume de connaissances n'est tout simplement pas pratique.

Cela signifie que quiconque vous dit connaître tous les aspects de DevOps vous ment probablement. Embauchez un spécialiste dans le domaine dans lequel vous êtes le plus faible et qui a travaillé pour une équipe DevOps - pas un "ingénieur DevOps".


Toutes ces descriptions de postes ne sont donc que des exemples pour voir qui postule? Ils semblent vouloir tout dans le monde. Je regarde cela et je pense, je sais ceci, ceci, cela, et pas ça, pas ça, pas ça ... Peut-être que toutes les entreprises ont mis le monde dans une description et voir ce qu'elles ont.
johnny

1
@johnny J'ai entendu des récits d'entreprises nécessitant 7 ans d'expérience dans les technologies qui ont été créées il y a seulement 5 ans ... oui, ce sont des listes de souhaits. Pas des exigences difficiles.
James Shewey

Merci. La liste de souhaits est la phrase que je cherchais.
johnny

3

J'ai eu ce défi précis lors de la mise en œuvre chez ASOS. L’objectif pour nous est d’avoir des équipes autosuffisantes et jouer un rôle spécifique peut donc être un anti-modèle, mais nous vivons dans le monde réel et pour de nombreux développeurs, penser à de bonnes pratiques DevOps n’est pas leur principale préoccupation. Ils ont donc besoin d’aide. y arriver.

Ce que nous avons fait était:

  • perdre le mandat d'ingénieur DevOps, DevOps est quelque chose que nous devrions tous faire, et non pas le titre de notre travail. Nous les avons donc appelés quelque chose de différent.

  • les a distribués aux équipes mais seulement 1 pour 3, cela signifiait qu'ils ne pouvaient pas être un faiseur mais devaient être considérés comme une compétence permettant aux équipes de s'améliorer et de résoudre leurs propres problèmes (avec des conseils)

  • a également conservé une fonction centrale qui fait office de centre de compétences et gère les considérations relatives à l'entreprise, tout ce qui concerne toutes les équipes

Au fur et à mesure que nous évoluons, nous examinons ce modèle, mais pour nous, il fonctionne efficacement jusqu'à présent.


3

Je ne pense pas que vous puissiez obtenir une réponse définitive à cette question car il semble que beaucoup de facteurs entrent en ligne de compte.

  • À quel point la société est-elle intégrée à la pratique du DevOps?
  • Quel type d'application ou de service l'entreprise fournit
  • La structure de votre entreprise

Je viens juste de terminer les entretiens pour les postes et je me suis retrouvé avec un titre d'ingénieur DevOps, mais ce que je fais est en partie un travail d'administrateur système. C'est simplement par nécessité en raison de la taille de l'entreprise et de la nature de la gestion des applications. Certains postes pour lesquels j'avais eu une entrevue portaient le même titre et recherchaient davantage quelqu'un du secteur développement. Ils s'attendaient à plus d'écriture de code et non à un administrateur système qui effectue l'automatisation. SRE semble être un titre qui gagne en popularité, ce pourrait être la voie à suivre. J'avais moi-même mon dernier emploi en tant qu'administrateur système et ingénieur en automatisation, car j'écrivais ansible et des postes de chef une partie du temps. La société suivait un assez bon modèle de devops où tout le monde était à bord et les développeurs travaillaient aux côtés des opérations, mais je pense que leur avenir ne l’était pas.

Maintenant que je suis dans cette position, j'essaie d'intégrer une corne d'automatisation et nous avons des problèmes de personnel que nous devrons régler. Les gens vont et viennent et certains des flux de travail ont été conçus pour quelqu'un d'autre, et non parce que cela correspond à la façon dont les gens travaillent.

Donc, fondamentalement, je pense que vous devriez comprendre la description de poste et ne pas trop vous préoccuper du titre, à moins que son prix ne soit lié au paiement ou que vous pensiez que l'un ou l'autre attirerait le bon type de personnes.


1

Si vous vous intéressez à la signification de DevOps et suivez un "chemin unique". Vous ne devriez pas embaucher un ingénieur DevOps. Vous devez embaucher un ingénieur en automatisation, un ingénieur en déploiement, un architecte de plate-forme ou un certain nombre de rôles qui répondent à vos besoins.

Si être un vrai praticien DevOps n'a pas d'importance pour vous, vous pouvez l'appeler comme vous voulez.


1
Veuillez développer un peu votre position, cette réponse est un peu trop courte pour le sujet dans cette question.
Tensibai

1
@Tensibai - Mon seul point est que ce n'est qu'un titre. Appeler quelqu'un comme ingénieur DevOps n'a pas d'importance si vous ne suivez pas vraiment les principes de DevOps
Erik Funkenbusch
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.