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

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?

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.

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.

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

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".

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.

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.

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.