Je viens de parler à un gars de DevOps qui a soulevé de très bons points au sujet de la difficulté d'être un ingénieur de DevOps et de se sentir parfois comme une armée composée d'un seul homme, même s'il fait partie d'une équipe de 16 ingénieurs.

Il porte beaucoup de chapeaux différents, mais fait partie de l'équipe de développement effectuant des travaux d'infrastructure. Il aime la technologie cool avec laquelle il travaille: automatisation, cloud, conteneurisation, etc. Mais il a du mal à être le seul à le faire ops, en devéquipe. Il relève du responsable du développement, mais travaille plus étroitement avec le responsable de l'infrastructure.

Cela semble être le cas de nombreux professionnels de DevOps à qui je parle. Que pourrait-on faire pour aider les ingénieurs de DevOps à se sentir moins comme un loup solitaire?

Ma première pensée est: "Pourquoi est-il la seule personne à faire des opérations, dans une équipe de développement, en particulier quand il doit travailler avec beaucoup d'automatisation?". Je pense qu'il est possible de s'attaquer au syndrome du loup solitaire. particulièrement dans un environnement de développement, infrastructure en tant que code fournit un cadre idéal pour partager la charge. Les responsables des opérations doivent être des experts dans la détermination et la définition des besoins d’infrastructure d’application, mais ils doivent également être en mesure de créer une plate-forme permettant aux rôles de développeur d’agir de manière autonome.

Cela ressemble à un silo au sein d'une équipe; les vieilles habitudes ont la vie dure. Un codeur ne se sent peut-être pas à l'aise pour faire tourner et renforcer un serveur, mais dans un modèle pur devops, il devrait avoir les outils pour le faire. Un responsable des opérations dans une équipe de développement ne devrait pas être responsable de la fourniture de l'infrastructure pour l'application elle-même, mais devrait fournir des informations sur les besoins et des conseils sur la manière dont les développeurs d'applications peuvent le faire eux-mêmes. C'est presque un modèle de méta-infrastructure; Les ingénieurs ops construisent une infrastructure capable de créer une infrastructure à la demande à la demande de l'équipe de développement.

La consultation, la communication et la combinaison des responsabilités sont toutes essentielles au succès d’une équipe de développement.

Je pense que le premier défaut est dans cette phrase:

Il relève du responsable du développement, mais travaille plus étroitement avec le responsable de l'infrastructure.

DevOps est un changement culturel visant à éliminer les silos. Si les silos restent, alors cet ingénieur est ce que vous voulez nommer, appelez-le; un ingénieur en développement opérationnel, un expert en automatisation, un développeur automatisant une infrastructure - mais cet ingénieur n'est pas un ingénieur DevOps.
En fait, "Ingénieur DevOps" n'est pas un rôle réel , mais plutôt un "chapeau", car il peut englober les développeurs, les administrateurs système, les testeurs d'assurance qualité et les architectes travaillant dans une équipe commune.

Un problème que je vois souvent, c’est que les gens tombent dans l’usage de DevOps, qu’ils considèrent comme un titre, mais ils ne comprennent pas vraiment ce qu’est DevOps. En observant DevOps de cette façon, ils finissent souvent par être isolés et se sentent seuls, accusant les échecs et les faiblesses d'être un "loup solitaire" sans le soutien de la direction et de l'organisation.

Comme vous le décrivez, cet ingénieur est le seul à effectuer des opérations dans une équipe de développement. Cela ne fait pas de lui un "ingénieur DevOps". (Peu importe ce que cela signifie dans son organisation) Il travaille dans l'isolement car le travail est présenté comme "Ingénieur DevOps", mais il semble que les autres membres de son équipe ne souhaitent pas travailler dans des opérations.

Soyons honnêtes, il y aura toujours des ops et des devs, l’idée principale derrière devops est de partager les responsabilités de manière à ce qu’il n’y ait pas de transfert de produit d’un dev à un autre, ou tout simplement de fournir une plateforme par ops pour dev. L'objectif principal consiste à apporter plus de collaboration dans une équipe. Dire que ce rôle est un "ingénieur DevOps", c'est briser cette idée en suggérant au nom que vous pouvez faire les deux au même niveau d'expertise, ce qui est rarement vrai.

La première chose à faire à mon avis serait de présenter les outils opérationnels à l'équipe et de donner à chacun une connaissance de base des outils, puis de transférer la responsabilité de configurer / coder les outils opérationnels à l'ensemble de l'équipe. L'idée principale derrière ceci est de passer de "celui qui fait tout ce qui est op" à "celui qui soutient et donne des implémentations de références à l'équipe".

Cela complète les autres réponses en fournissant, dans un premier temps, une action plus simple qu'une réorganisation de la gestion.

La chose la plus importante pour les ingénieurs DevOps dans ce type de situation consiste à obtenir (a) un engagement de la direction et (b) des budgets requis . Lisez la suite pour plus de détails sur les deux ...

Obtenir l'engagement de la direction

Une fois que cela est en place, les choses deviennent faciles pour de tels ingénieurs DevOps. Particulièrement lorsque la résistance (de toutes sortes de partis) entre en jeu. Croyez-moi, il y aura une telle résistance, avec des défis tels que:

• Pourquoi devons-nous changer? Je veux continuer à faire ce que je faisais depuis X ans déjà!
• Je ne veux pas perdre le pouvoir (technique) que j'ai et compléter toutes sortes de procédures de workflow pour obtenir une solution idiote en production qui devrait me prendre environ 5 minutes au lieu de 5 heures (ou jours ...).
• ... (Je pourrais ajouter une douzaine de balles ici ...).

Tous les ingénieurs DevOps devraient avoir à répondre à chaque fois que de tels problèmes se présentent:

Je suis désolé, je ne fais que mon travail ... basé sur les instructions de la haute direction.

Obtenir les budgets requis

Un moyen efficace d'obtenir les budgets requis consiste à créer / soumettre une analyse de rentabilisation appropriée expliquant les avantages tangibles et intangibles des différentes pratiques de DevOps en les appliquant à des cas concrets s'appliquant à l'entreprise elle-même.

Vous trouverez ci-dessous des cas concrets que j'ai moi-même vécus, en tant que consultant SCM recruté par certaines entreprises. Je sais que SCM n’est qu’une partie de DevOps, mais c’est le domaine dans lequel j’ai une certaine expertise ...

1. Avantages de l'automatisation

En raison de la grève de seulement 2 (!!!) opérateurs informatiques (qui ne tapaient plus les commandes de la console qu’ils étaient censés taper), les trains ont dû être arrêtés à mi-chemin entre 2 usines (car le système de l’usine où le train se dirigeait vers le bas était en panne, les données cruciales sur la manipulation du train n’étaient pas disponibles).

En mettant en œuvre un système SCM, de nombreuses commandes d'opérateur ont été automatisées.

2. Réduire les coûts de licence logicielle

Certains éditeurs de logiciels avaient décidé d’augmenter les frais annuels du logiciel SCM (obsolète), ce que la direction n’a pas accepté. Ils ont donc créé un projet spécial pour le remplacer par un autre logiciel SCM.

Le budget du projet était égal aux frais annuels qu’ils ne voulaient pas continuer à payer. Cela impliquait de faire venir des ingénieurs d’autres continents (comme moi) pour mener à bien le projet.

3. Réduire les coûts d'exploitation

Une grande compagnie d’assurance utilisait un logiciel FTP pour transférer des correctifs logiciels vers environ 13 000 ordinateurs de milieu de gamme (AS / 400) dans tout le pays, et ce, chaque fois qu’un "correctif" était disponible. Le coût d'un tel transfert était d'environ 4 USD (13 000 x 4 = 52 000 USD pour un seul transfert ...). Le logiciel comprenait 120 000 composants, développés / maintenus par environ 150 développeurs. Faites le calcul sur la probabilité qu'un développeur fasse une (petite) erreur dans l'un de ces 120 000 composants, ce qui l'a rendu à la production et nécessitait une solution urgente, ce qui coûterait 52 000 USD supplémentaires (juste pour le transfert!).

En mettant en place un système de gestion de la chaîne logistique adéquat (avec environnements de test gérés, approbations, etc.), cette société a pu réduire considérablement ses coûts. Pensez-y, si le système SCM pouvait éviter la nécessité de ne transférer que 20 transferts de correctifs urgents, il entraînait une réduction des coûts de 52 000 x 20 = 1 040 000 USD (un budget considérable pour mettre en œuvre un système SCM, il ne leur fallait qu'une fraction de ce montant pour faire le travail).

4. Réduire les coûts d'indisponibilité

Si les cas ci-dessus ne sont pas suffisamment convaincants, imaginez le système d’une grande société de cartes de crédit indisponible dans le monde entier. On m'a dit qu'une seconde d'indisponibilité leur coûte 1 000 000 USD.

C'est probablement aussi la raison pour laquelle, pendant très longtemps, de telles sociétés ont mis en place des outils sophistiqués DevOps, et ce depuis plusieurs décennies déjà. Parce que chaque seconde, ils ne sont pas en affaires leur coûte une fortune.

TL; DR: Étant donné que la haute direction est généralement instable et sujette à la colère, je suggérerais d'essayer de plier un peu son esprit pour avoir une perspective différente, tout en améliorant progressivement les choses, pour le rendre meilleur.

(Je suppose que son problème est principalement avec les récalcitrants devs , pas ses autres ops collègues qui semblent faire principalement des opérations classiques.)

OMI, même si vous avez DevOps en cours, cela ne signifie pas nécessairement que chaque développeur doit être un véritable gourou de DevOps. Je trouve assez normal qu’il y ait un ou deux vrais experts dans un groupe de personnes donné et que les autres suivent plus ou moins. Tant que la charge de travail n'est pas trop lourde pour ce gars-là, et tant qu'il réussit à encapsuler ses connaissances dans des scripts, etc. au lieu de construire son propre silo, tout va bien pour moi.

La seule chose qui ne devrait pas se produire est que le responsable de DevOps effectue son automatisation et que tout le monde fait de son mieux pour éviter cette automatisation (c'est-à-dire aller au-delà du pipeline CI / CD et effectuer des tâches manuellement dans l'un des environnements). Ceci, l'OMI est la principale chose qui doit s'arrêter. Une solution serait d’appuyer très fort sur l’approche bétail-pas-animal, c’est-à-dire de démanteler sans relâche les ordinateurs virtuels ou les conteneurs à gauche et à droite dès que vous pourrez, et d’en créer de nouveaux en permanence.

Deuxièmement, bien sûr, tout le monde doit savoir ce que fait l’automatisation, et au moins en théorie, avec quelques recherches, peut-être en mesure de démarrer les machines de l’automatisation (c’est-à-dire que si tout se passe à partir d’un commit / push, alors les développeurs doivent être conscients et très au courant du fait qu’il se passera des choses à l’arrière-plan lorsqu’ils s’engageront). Le pipeline de CI (/ CD) doit être assez visible et doit être une chose dont tout le monde est constamment au courant (c'est-à-dire lorsqu'un développeur le casse).

Troisièmement, le "one guy" doit bien sûr veiller à ne pas effectuer de tâches journalières pour ses collègues (par exemple, créer Dockerfile après Dockerfile pour leurs artefacts ...).

Quatrièmement, les solutions créées par le responsable de DevOps doivent bien sûr être supérieures aux approches manuelles du passé de manière mesurable. Dans ce cas, il devrait être en mesure de démontrer ses améliorations; c'est-à-dire, montrer comment les choses deviennent plus faciles pour tout le monde, ou qu'il semble impossible d'introduire des bogues dans les étapes ultérieures du pipeline, etc. Si cela ne semble pas possible, le responsable de DevOps doit alors examiner de près ce qu'il est bien. il fait. Si cela est possible, cela nécessite des séances de bacs à linge et beaucoup d’évangélisation dans son équipe.

Évidemment, dans un environnement aussi réticent, vous n'arriverez probablement pas à une solution de CD entièrement automatisée, ni à un développement basé sur une ligne de réseau. Mais je ne voudrais pas trop m'inquiéter d'être distingué. Il est l'expert, et s'il fait bien son travail, toute l'équipe s'améliorera très progressivement.

Enfin, si après des années et des années de labeur, il n'y a aucune amélioration visible avec ses collègues, il est toujours possible de rechercher d'autres voies (que ce soit à l'intérieur ou à l'extérieur de l'entreprise). Avoir toute cette expérience DevOps à son actif est un excellent point de départ pour chercher un emploi, ces jours-ci ...

Je vois beaucoup de bonnes réponses ici en parlant de DevOps en tant que culture, de suggestions sur la façon de travailler avec la direction et en aidant à définir les choses à faire et à ne pas faire d'une équipe ou d'un ingénieur de DevOps. Je pense que chacune d’elles est excellente et qu’une très bonne illustration de beaucoup de réponses peut être exacte à 100%, tout en restant très différente, voire complètement ambiguë les unes des autres ... C’est DevOps!

Cette réponse n’est que le point de vue unique de mon expérience et peut ne pas être un indicateur de normes ou de meilleures pratiques ...

Mais ce dont se plaignait votre collègue DevOps, c’est la nature même de ce qui rend DevOps difficile et difficile , en particulier lorsqu’il est nommé ingénieur DevOps, et non pas simplement comme un état d’esprit culturel.

Personnellement, j'aime être un loup solitaire, car je continue d'apporter une contribution précieuse, mais j'arrive aussi à fixer mes propres limites, tout en persuadant les autres de s'aider eux-mêmes, m'aidant ainsi, en brisant les silos informatiques.

Certains silos restent intacts , et ce n'est pas grave, la mission de DevOps est de contourner ce problème et d'essayer de rendre ce silo aussi insignifiant ou invisible que possible.

Il est possible que votre collègue réalise ou ne se soit pas encore rendu compte qu'il n'aime pas être un ingénieur DevOps .

Relativement parlant, le concept de devops est nouveau et se définit toujours à mon avis. Je remplis actuellement un rôle d'ingénieur devops. Pour moi, cela signifie que je facilite et développe les outils et les processus utilisés par nos équipes de développement et d’opération, ce qui leur permet de se concentrer sur le produit qui génère des revenus pour la société. Les équipes op et dev développent leurs propres serveurs et ceux dont ils ont besoin. Je connecte simplement le CI pour nos produits, m'assure que nos processus ont un sens et cherche quel processus peut être amélioré / automatisé. Je rencontre tous nos départements, des ventes aux entrepôts, en passant par les développeurs et les opérations (responsables de l'assurance de la qualité et des responsables des versions) pour voir ce qu'ils font et comment je peux améliorer leurs processus.

Pour moi, DevOps signifie que le développement et l'exploitation d'un logiciel deviennent la responsabilité d'une seule équipe, au lieu d'équipes de développement et d'opérations distinctes. C'est une rue à double sens. Les meilleures équipes sont composées de personnes en " T-Shaped " qui sont des experts dans un domaine et connaissent plusieurs domaines connexes.

• Les membres d’équipe expérimentés doivent faire ce qu’ils font le mieux (c’est-à-dire les opérations), enseigner les bases de ce qu’ils font le mieux (c.-à-d. Les opérations) aux autres et apprendre et occuper des emplois dans des domaines connexes (c.-à-d. Tâches de dev).
• Les membres d’équipe expérimentés sont censés faire ce qu’ils font le mieux (c’est-à-dire les dev), enseigner les bases de ce qu’ils font le mieux (c.-à-d. Dev), et apprendre et faire des métiers dans des domaines connexes (c.-à-d. Tâches Ops).

Alors, pour que l’ingénieur DevOps se sente moins comme un loup solitaire, invitez-le à enseigner aux développeurs comment utiliser les systèmes, tout en reconnaissant qu’il est l’expert de la conception de l’infrastructure.

Faites-le dès le début impliqué dans l'architecture de haut niveau, afin qu'il puisse présenter les préoccupations de sa spécialité. (Avant le développement de DevOps, nos dessins d'architecture couvraient toujours de "petites choses" telles que des équilibreurs de charge et des serveurs redondants. De telles choses font désormais partie des tout premiers croquis.)

Attendez-vous à ce que les développeurs prennent en charge certaines tâches quotidiennes liées aux opérations, à la fois pour renforcer la redondance au sein de l'équipe et pour répartir équitablement les tâches "rudimentaires".

Attendez-vous à ce qu’il contribue à l’effort de développement s’il n’y a aucune tâche à effectuer semblable à une opération. Certains DevOps que je connais semblent considérer le travail de base de données comme une extension naturelle de leur domaine de compétence, ne sachant pas si cela peut être généralisé.

Que pourrait-on faire pour aider les ingénieurs de DevOps à se sentir moins comme un loup solitaire?

Pour paraphraser - ce qui peut faire un ingénieur DevOps lui - même / elle - même de se sentir moins comme un loup solitaire?

Le manque de culture et de soutien de la part de la direction n’est qu’une partie de l’équation. L'autre partie est à mon avis que les connaissances détaillées de DevOps se réfèrent souvent à des contextes complexes et qu'il est important de disposer de conseils et de références à des exemples concrets.

Par conséquent, ne vous sentez pas comme un loup solitaire; participez à des communautés DevOps comme celle-ci ou à des groupes spécifiques à un outil et à GitHub - vous avez au moins le sentiment que vous n'êtes pas le seul loup solitaire ;-)