👋🏿 🐰 👂🏽 Expérience personnelle: comment construire une carrière dans le département DevOps 💄 😎 🍃

Bonjour à tous! Je m'appelle Timur Gilmullin, je suis le chef adjoint du département des technologies et des processus de développement chez Positive Technologies, je suis engagé dans l'automatisation et implémente les idées de DevOps. Aujourd'hui, je vais vous dire comment je suis entré dans la profession, comment, dans notre département, nous voyons la carrière d'un ingénieur DevOps, ce qu'est une carte des compétences et comment elle contribue à assurer la croissance des employés.

Avertissement

Cet article n'est pas une tentative de décrire le cheminement de carrière idéal d'un ingénieur DevOps. Notre objectif est de partager l'expérience et de dire comment cela fonctionne avec nous. Il existe des entreprises spécialisées ( express 42 , flant ) et des communautés ( devops deflope ) qui contribuent de manière significative au développement des idées DevOps en Russie, et nous avons sélectionné une pile de technologies et de techniques qui nous conviennent.

Sur la façon dont nous avons développé les idées DevOps dans notre département et dans l'entreprise, vous pouvez lire sur Habré:

Et maintenant, c'est parti!

Pourquoi avons-nous besoin de DevOps

Chaque entreprise a ses spécificités propres au département d'automatisation. En règle générale, les tâches difficiles ou trop coûteuses à réaliser au niveau de plusieurs services distincts sont transférées vers un groupe centralisé ou un service d'automatisation. Dans notre entreprise, l' objectif global de la mise en œuvre des idées DevOps est d'assurer une réduction cohérente du coût de production et du support produit en termes quantitatifs (heures-homme ou heures-machine, CPU, RAM).

Sur la base de cet objectif, le rôle du département d'automatisation au niveau de l'ensemble de l'entreprise est mis en évidence - il s'agit de minimiser le coût de l'exécution des tâches série typiques à toutes les étapes de la production.

Comment ça fonctionne

Les responsabilités fonctionnelles des services d'automatisation dépendent également fortement des spécificités d'une entreprise particulière. Notre entreprise est un développeur et un fournisseur de solutions de sécurité des informations, et le département d'automatisation est responsable du convoyeur de production - de l'assemblage des composants individuels des produits à leur envoi pour les tests et la livraison des mises à jour de l'infrastructure du client. Nous aidons à automatiser les principaux processus de développement en équipes et assurons la performance de nos systèmes (intégration continue et livraison continue (CI / CD)).

Notre travail est divisé en plusieurs domaines fonctionnels. La direction de l'intégration continue prend en charge les pipelines d'assemblage et de test pour les développeurs et les testeurs. La direction de l'infrastructure est engagée dans le fonctionnement et l'optimisation de l'utilisation de toutes les ressources "fer" du département, ainsi que l'automatisation du déploiement des machines virtuelles et de leur environnement (infrastructure comme code). La direction du suivi permet de contrôler la disponibilité quotidienne des services. Nous proposons également une surveillance en tant que service aux développeurs (surveillance en tant que service).

La direction du flux de travail fournit aux équipes des outils pour gérer les processus de développement et de test, analyser l'état du code et obtenir des analyses de projet. Enfin, webdev fournit des versions de publication sur des serveurs de mise à jour d'entreprise (GUS et FLUS), ainsi que des licences de produits à l'aide du service License Lab.

Pour prendre en charge le pipeline de production, nous avons mis en place et maintenons de nombreux services de support différents pour les développeurs. Des histoires sur certains d'entre eux peuvent être entendues sur nos anciens mitaps: Op! DevOps! 2016 et Op! DevOps! 2017 . Nous développons également des outils d'automatisation internes, dont DevOpsHQ .

L'expérience de nos ingénieurs

Les gars de notre département d'automatisation (pour simplifier, appelé officieusement le département DevOps) ont une formation complètement différente: il y a d'anciens testeurs, programmeurs, ingénieurs et administrateurs informatiques. Je suis professeur diplômé en mathématiques et informatique. Il s'est avéré que grâce à la diversité des expériences, nous avons pu faire face aux tâches de tous nos domaines.

Il n'y a pas un seul ingénieur dans notre département qui puisse à lui seul résoudre tous les problèmes dans tous les domaines. Mais ensemble, nous, en tant qu'unité administrative, sommes ainsi SRE(tout simplement pas un site, un service de fiabilité des ingénieurs, puisque nous supportons des services pour les développeurs), que recherchent sans succès des spécialistes RH en la personne d'un ingénieur. Nous pensons qu'une grande variété de tâches liées aux produits de l'entreprise ne peuvent être résolues que dans le cadre d'une équipe d'ingénieurs diversifiés.

Nous avons un grand nombre de cas techniques pour implémenter l'automatisation. Mais l'essentiel est d'expliquer aux gens pourquoi ils ont besoin de cette automatisation. Le moyen le plus simple est lorsque la tâche technique vient des affaires, c'est-à-dire lorsque les personnes qui apportent de l'argent à l'entreprise ont une compréhension claire: quoi, comment et quand faire ou optimiser. Je vous suggère de regarder nos cas d'automatisation: " Expérience personnelle: à quoi ressemble notre système d'intégration continue ."

À propos d'une carrière dans notre département DevOps

Je voudrais dire que tout était prêt et planifié à l'avance, mais ce n'est pas le cas. Au début, nous n'avions rien dans nos plans de croissance et de développement. En 2014, lorsque je suis passé au département technologie et processus de développement, le développement produit vivait dans l'esprit d'une startup: tout doit être fait ici et maintenant, les plans à long terme n'ont pas été acceptés, il y avait beaucoup de «legs». Il y avait alors quatre ingénieurs et nous avions de nombreuses tâches techniques: nous devions de toute urgence faire du CI, faire évoluer le pipeline d'assemblage, avant cela, bien sûr, créer ce pipeline, et également créer une interaction avec nos clients internes - des programmeurs des départements de développement.

Cependant, au fil du temps, les processus se sont améliorés, le département s'est développé. Avec lui, il y avait une compréhension croissante de ce que nos ingénieurs voulaient savoir: quelles sont leurs perspectives de développement en tant que spécialistes, que peut offrir le département aux nouveaux ingénieurs? La première chose qui en découle logiquement est que nous aurons besoin d'une table de croissance pour les postes et les catégories d'ingénieurs. Comme dit le proverbe: lorsque la société n'a pas de différenciation des couleurs des pantalons, alors il n'y a pas de raison! Et quand il n'y a pas d'objectif ...

Nous avons rendu tout aussi simple que possible. La structure organisationnelle interne de notre département comprend trois postes de direction (chef de département, chef adjoint et chefs de groupe) et quatre postes de direction (junior, régulier, senior et principaux ingénieurs logiciels), qui sont à leur tour divisés en trois catégories. Le service des ressources humaines utilise souvent un titre d'emploi similaire, mais sans division en catégories. Pour notre service, les catégories ont contribué à assurer une croissance plus régulière et plus progressive des employés à mesure que leurs domaines de responsabilité et leur charge de travail augmentaient.

Pour chaque catégorie, nous avons développé des documents avec des descriptions de travail, où les fonctions et les rôles des employés étaient prescrits, ainsi que les domaines de responsabilité des employés pour les services et les domaines de travail étaient indiqués.

Mais comme nous, en plus de l'ingénierie, aimons aussi programmer, et qu'aucun de nous n'aime lire des documents ennuyeux, ici aussi nous avons un peu simplifié notre vie. Nous n'avons pas écrit chaque instruction dans Word, mais sous forme de texte brut formaté avec un langage de balisage Markdown spécial . Dans le même temps, sa lisibilité par une personne dans n'importe quel éditeur n'est pas perdue. Après cela, nous avons enregistré ces textes dans notre référentiel GitLab. GitLab lui-même peut très bien afficher différents formats de documents, y compris les tirages Markdown afin qu'il ne puisse pas être distingué de Word. Et le client Git standard possède de nombreuses fonctionnalités supplémentaires, par exemple, il peut afficher la différence (différence) entre deux documents.

Cela simplifie grandement la vie d'un ingénieur qui souhaite savoir quelles exigences formelles il doit suivre pour passer à la prochaine étape (catégorie) de croissance personnelle dans notre département. Pour découvrir la différence entre les exigences formelles des deux descriptions de travail, vous devez effectuer quelques étapes simples: télécharger le référentiel avec les descriptions de travail depuis notre GitLab, rechercher des documents, exécuter la commande Git dans la console pour afficher une comparaison des deux fichiers. Par exemple, vous pouvez voir la différence entre un ingénieur senior des 2ème et 1ère catégories comme suit:

git --no-pager diff --no-index 
level_08__DevOps_Senior_Software_Engineer_2nd_category.md
level_09__DevOps_Senior_Software_Engineer_1st_category.md

Dans la console, à laquelle tous les ingénieurs logiciels sont habitués, le signe moins et la couleur rouge se distinguent pour les exigences qui ont changé ou ont été supprimées, et les lignes ajoutées se distinguent par un signe plus et une couleur verte: chaque ligne est plus une nouvelle exigence.

Oui, nous sommes un peu des fous de technophiles, mais alors cela nous a semblé une excellente solution:

Carte des compétences des ingénieurs DevOps

Au fur et à mesure que notre département s'est développé et que le nombre de convoyeurs de produits soutenus par nous a augmenté, nous avons réalisé que pour chacun des domaines de travail dans lesquels nous sommes engagés, il ne sera pas possible de décrire un rôle unique et de trouver un ingénieur approprié sur le marché. Nous avons nos propres spécificités de travail et, par exemple, nous n'avons pas besoin d'un développeur de logiciel de programmation méga-qualifié pour résoudre les problèmes de CI, mais néanmoins, un ingénieur de CI doit être capable de programmer de petits modules et scripts en Python à un niveau acceptable. De même, nous n'avons pas besoin d'un administrateur Linux méga-qualifié, mais nous avons besoin d'une personne ayant une connaissance suffisante du système d'exploitation Debian ou Ubuntu pour pouvoir installer les agents de génération CI GitLab, et encore mieux, automatiser ces travaux via SaltStack, Ansible ou d'autres outils.

Alors, que devrait faire un ingénieur DevOps travaillant dans notre département? Pour ce faire, vous devez d'abord déterminer quelles sont les connaissances, les compétences et les capacités (en abrégé ZUN ) au sens général.

La connaissance est les principales lois du domaine, permettant à une personne de résoudre des problèmes de production spécifiques, scientifiques et autres, c'est-à-dire des faits, des concepts, des jugements, des images, des relations, des estimations, des règles, des algorithmes, des heuristiques, ainsi que des stratégies de prise de décision dans ce domaine. Les connaissances sont également des éléments d'information liés entre eux et avec le monde extérieur.
Compétences - elles sont comprises comme maîtrisées par une personne sur la façon d'exécuter une action, avec un certain corpus de connaissances. La capacité s'exprime dans la capacité d'appliquer consciemment les connaissances dans la pratique.
— , . , , , , .

Si nous définissons le ZUN plus spécifiquement par rapport aux produits développés dans l'entreprise, nous obtiendrons une liste générale des compétences. Sans maîtriser ces compétences, l'ingénieur ne pourra pas travailler qualitativement dans notre département. La liste s'est avérée très longue, car elle prend immédiatement en compte les spécificités du travail dans tous les domaines, technologies et produits.

Ainsi, nous sommes arrivés à la nécessité de décrire et de classer toutes nos exigences pour un ingénieur sous forme de tableau, et nous avons un « DevOps Engineers 1.0 Competency Map ». Il ressemble à ceci: Le tableau est divisé en quatre grandes sections:

Description des compétences générales des employés de notre service DevOps, nécessaires à la bonne réussite des tâches quotidiennes.
La connaissance est la connaissance spécifique et orientée produit des ingénieurs DevOps.
— ; .
— ; , .

Dans les cellules du tableau, les évaluations qualitatives sont indiquées: à quel niveau un ingénieur devrait-il avoir approximativement l'une ou l'autre compétence. Malheureusement, je ne peux pas imaginer la version complète du tableau ici, mais ce n'est pas nécessaire, car chaque entreprise et chaque département doit créer son propre tableau similaire, en tenant compte des spécificités du travail.

En 2018, mes collègues et moi avons développé et créé la soi-disant carte technologique du processus de production (lire l'article sur le Habr « Gestion du chaos: nous mettons les choses en ordre en utilisant la carte technologique »). Grâce à elle, nous avons frôlé la création d'un vecteur de croissance et de développement des compétences des ingénieurs DevOps en fonction du produit, des technologies utilisées et des étapes du convoyeur de produit.

Une telle carte décrit toutes les étapes et étapes qui composent le convoyeur technologique pour la fabrication de nos produits. L'essentiel, du point de vue du produit, est de comprendre combien d'ingénieurs, quelles qualifications et avec quelles compétences nous avons besoin pour assurer le fonctionnement continu de ce convoyeur. Mieux encore, planifiez et sécurisez les personnes afin que, malgré le soutien des services essentiels, elles puissent, par exemple, partir en vacances sereinement, sachant qu'il y a une personne aux compétences transversales dans le département et qui peut les remplacer.

Dans l'ensemble, cela devrait nous conduire à la «Carte des compétences des ingénieurs DevOps 2.0», qui décrira clairement le ZUN en fonction du produit et des compétences nécessaires pour le travail d'automatisation de ce produit. Autrement dit, une certaine liaison des étapes de la carte technologique à la carte des compétences des ingénieurs devrait apparaître. Dans le prochain article, je vais essayer de vous dire ce qui en est sorti.

PS L'article a été écrit sur la base de l'histoire de la réunion de janvier, à laquelle des collègues de Hays nous ont aimablement invités à échanger des expériences (vous pouvez voir la présentation et le texte ).

Auteur : Timur Gilmullin- député. Responsable des technologies et processus de développement (DevOps), Positive Technologies.