Actuellement, c'est presque la position la plus chère sur le marché. L'agitation autour des ingénieurs « DevOps » dépasse toutes les limites imaginables, et c'est encore plus vrai pour les ingénieurs Senior DevOps.
Je suis responsable du département d'intégration et d'automatisation, devinez l'acronyme anglais — DevOps Manager. L'acronyme anglais reflète-t-il vraiment notre activité quotidienne ? Probablement pas, tandis que la version russe est ici plus précise. De par ma fonction, il est naturel que je doive interviewer les futurs membres de mon équipe et, au cours de l'année écoulée, environ 50 personnes sont passées par mes soins, autant ont été écartées lors de présélections avec mes employés.
Nous sommes toujours à la recherche de collègues, car derrière le label DevOps se cache une très grande diversité d'ingénieurs.
Tout ce qui est écrit ci-dessous est mon opinion personnelle, vous n'avez pas à être d'accord avec moi, mais je suppose que cela apportera une nuance à votre perspective sur le sujet. En dépit du risque de déplaire, je publie mon opinion, car je pense qu'elle mérite d'être exprimée.
Les entreprises ont des compréhensions différentes de ce que sont les ingénieurs DevOps et, pour embaucher rapidement des ressources, elles attribuent ce label à tout le monde. La situation est assez étrange, car les entreprises sont prêtes à payer des sommes exorbitantes à ces personnes, en obtenant dans la plupart des cas, un administrateur-outil.
Alors, qui sont vraiment les ingénieurs DevOps ?
Commençons par l'histoire de son apparition — les Operations de développement (DevOps) sont devenues une étape supplémentaire pour optimiser la collaboration au sein des petites équipes afin d'accélérer la production de produits, comme en était l'attente. L'idée était de renforcer l'équipe de développement avec des connaissances sur les procédures et approches de gestion de l'environnement produit. En d'autres termes, un développeur doit comprendre et savoir comment son produit fonctionne dans différentes conditions, savoir comment déployer son produit et quelles caractéristiques de l'environnement ajuster pour améliorer la performance. Ainsi, au fil du temps, des développeurs ayant une approche DevOps ont vu le jour. Les développeurs DevOps écrivaient des scripts de construction et de packaging pour simplifier leur travail et la fonctionnalité de l'environnement de production. Cependant, la complexité architecturale des solutions et l'interaction mutuelle des composants d'infrastructure ont commencé à détériorer les performances des environnements au fil du temps, nécessitant une compréhension de plus en plus approfondie de certains composants à chaque itération, ce qui a diminué la productivité même du développeur en raison des efforts supplémentaires requis pour comprendre les composants et peaufiner les systèmes pour des tâches spécifiques. Le coût associé à un développeur a augmenté, le coût du produit avec lui, et les exigences envers les nouveaux développeurs au sein de l'équipe ont fortement augmenté, étant donné qu'ils devaient aussi couvrir les responsabilités de la « star » du développement, devenant de plus en plus rares et moins accessibles. Il convient également de noter que, d'après mon expérience, peu de développeurs s'intéressent à la spécificité du traitement des paquets par le noyau du système d'exploitation, aux règles de routage des paquets, ou aux aspects de sécurité de l'hôte. Il était donc logique de faire appel à un administrateur, qui connaît bien ces sujets, et de lui assigner ces responsabilités, grâce à son expérience permettant d'atteindre les mêmes résultats à un coût moindre par rapport à celui d'une « star » du développement. Ces administrateurs étaient intégrés dans l'équipe et leur tâche principale était de gérer les environnements de test et de production, suivant les règles de l'équipe spécifique, avec des ressources allouées à cette équipe. C'est ainsi que les DevOps ont été perçus par la majorité.
Partiellement ou totalement, au fil du temps, les administrateurs systèmes ont commencé à comprendre les besoins de cette équipe spécifique en matière de développement, comment simplifier la vie des développeurs et des testeurs, comment déployer une mise à jour sans passer la nuit au bureau à corriger des erreurs de déploiement. Le temps a passé, et maintenant, les « stars » sont devenus les administrateurs systèmes qui comprennent ce que les développeurs désirent. Dans un souci de minimiser l'impact, des outils de gestion ont commencé à apparaître, et tous se sont rappelés de ces anciennes méthodes fiables d'isolation au niveau du système d'exploitation, permettant de minimiser les exigences en matière de sécurité, de gestion réseau et de configuration de l'hôte dans son ensemble, et par conséquent, de réduire les exigences pour les nouvelles « stars ».
Une chose « merveilleuse » est apparue : Docker. Pourquoi merveilleuse ? Tout simplement parce que créer une isolation dans un chroot ou un jail, tout comme OpenVZ, nécessitait des connaissances non triviales du système d'exploitation, tandis que l'outil permettant de créer simplement un environnement isolé d'application sur un hôte avec tout le nécessaire à l'intérieur, et de transférer la direction aux développeurs, permettait à l'administrateur système de ne gérer qu'un seul hôte, garantissant sa sécurité et sa haute disponibilité — une simplification logique. Mais le progrès ne s'arrête pas, et les systèmes deviennent de plus en plus complexes, avec de plus en plus de composants, un seul hôte ne satisfait plus les besoins du système et il devient nécessaire de construire des clusters, nous revenons alors aux administrateurs systèmes capables de bâtir ces systèmes.
Cycle après cycle, diverses systèmes apparaissent pour simplifier le développement et/ou l'administration, des systèmes d'orchestration émergent qui, tant que l'on reste dans le processus standard, sont simples à utiliser. L'architecture microservices est également apparue pour simplifier tout ce qui a été décrit ci-dessus — moins d'interconnexions, plus facile à gérer. Dans mon expérience, je n'ai pas vécu une architecture microservices complète, je dirais 50-50 : 50 % de microservices, des boîtes noires, ce qui est entré, est sorti transformé, et les 50 % restants — un monolithe déchiré, des services incapables de fonctionner indépendamment des autres composants. Tout cela a de nouveau imposé des limites au niveau de connaissances tant pour les développeurs que pour les administrateurs.
Ces « balancements » de niveau expert concernant telle ou telle ressource se poursuivent encore aujourd'hui. Mais nous nous sommes un peu écartés, il y a de nombreux points à éclaircir.
Ingénieur Build / Ingénieur Release
Des ingénieurs très spécialisés, apparus comme moyen de standardiser les processus de construction et de publication de logiciels. Avec l'avènement généralisé de l'Agile, on aurait pu penser qu'ils avaient perdu de leur pertinence, mais c'est tout le contraire. Cette spécialisation est née comme un moyen de standardiser la construction et la livraison de logiciels à grande échelle, c'est-à-dire en utilisant des techniques standards pour tous les produits de l'entreprise. Avec l'émergence de DevOps, les développeurs ont partiellement perdu certaines fonctions, car ce sont maintenant eux qui préparent le produit pour la livraison. Considérant l'infrastructure en évolution et l'approche visant une livraison rapide sans se soucier de la qualité, ils se sont finalement transformés en un frein à l'évolution, car le respect des normes de qualité ralentit inévitablement les livraisons. Ainsi, progressivement, une partie des fonctions des ingénieurs Build/Release a été transférée aux administrateurs système.
Des Ops si différents
Nous avançons et encore une fois, la multitude de responsabilités et le manque de personnel qualifié nous poussent vers une spécialisation stricte, comme des champignons après la pluie, divers Operations émergent :
- TechOps — administrateurs système en informatique, également appelés HelpDesk Engineer
- LiveOps — administrateurs système, principalement responsables des environnements de production
- CloudOps — administrateurs système spécialisés dans les « nuages » publics comme Azure, AWS, GCP, etc.
- PlatOps / InfraOps / SysOps — administrateurs système d'infrastructure.
- NetOps — administrateurs réseau
- SecOps — administrateurs système spécialisés dans la sécurité de l'information — conformité PCI, conformité CIS, mise à jour, etc.
DevOps — une personne qui, en théorie, comprend en profondeur tous les processus du cycle de développement — développement, test, architecture produit, capable d'évaluer les risques de sécurité, familière avec les approches et outils d'automatisation, au moins à un niveau élevé, et qui comprend également le support pré et post-lancement du produit. Une personne capable de défendre tant les opérations que le développement, permettant ainsi d'établir une coopération fructueuse entre ces deux piliers. Comprenant les processus de planification des travaux par les équipes et la gestion des attentes des clients.
Pour effectuer ce type de travail et ces responsabilités, cette personne doit disposer d'outils de gestion non seulement des processus de développement et de test, mais aussi de gestion de l'infrastructure produit et de planification des ressources. DevOps, dans cette compréhension, ne peut se trouver ni dans l'IT, ni dans la R&D, ni même dans le PMO, il doit avoir un impact dans tous ces domaines — directeur technique de l'entreprise, Chief Technical Officer.
Est-ce le cas dans votre entreprise ? — J'en doute. Dans la plupart des cas, c'est soit l'IT, soit la R&D.
Un manque de moyens et d'influence sur au moins l'un de ces trois domaines d'activité produira un déplacement du poids des problèmes vers des zones où ces changements sont plus faciles à appliquer, comme l'imposition de restrictions techniques sur les versions dues à un code « sale » selon les données des systèmes d'analyse statique. C'est-à-dire que lorsque le PMO fixe un délai strict pour le lancement de fonctionnalités, la R&D ne peut pas fournir un résultat de qualité dans ces délais et le délivre comme elle peut, laissant le refactoring pour plus tard, DevOps lié à l'IT bloque alors la version avec des moyens techniques. Un manque de pouvoir pour changer la situation, dans le cas des employés responsables, conduit à une hyper-responsabilité pour ce sur quoi ils ne peuvent pas influencer, d'autant plus si ces employés comprennent et voient les erreurs, et comment les corriger — « Le bonheur est dans l'ignorance », menant ainsi à l'épuisement et à la perte de ces employés.
Marché des ressources DevOps
Examinons quelques offres d'emploi pour des postes DevOps dans différentes entreprises.
Nous sommes prêts à vous rencontrer si vous :
- Maîtrisez Zabbix et savez ce qu'est Prometheus ;
- Iptables ;
- Doctorant BASH ;
- Professeur Ansible ;
- Gourou Linux ;
- Vous savez utiliser le débogage et collaborer avec les développeurs pour identifier les problèmes des applications (php/java/python) ;
- Le routage ne vous provoque pas de crises ;
- Vous accordez une attention particulière à la sécurité du système ;
- Vous effectuez des sauvegardes de "tout et n'importe quoi", et vous réussissez à restaurer "tout et n'importe quoi" ;
- Vous savez configurer le système pour maximiser le rendement à partir du minimum ;
- Vous configurez des répliques avant de dormir sur Postgres et MySQL ;
- Pour vous, la configuration et l'ajustement de CI/CD sont aussi nécessaires que le petit-déjeuner/le déjeuner/le dîner.
- Vous avez de l'expérience avec AWS ;
- Vous êtes prêts à évoluer avec l'entreprise ;
Donc :
- de 1 à 6 — administrateur système
- 7 — un peu d'administration réseau, qui s'inscrit également dans le rôle d'administrateur de niveau moyen
- 8 — un peu de sécurité, ce qui est indispensable pour un administrateur de niveau moyen
- 9-11 — Administrateur Système de Niveau Moyen
- 12 — Selon les tâches attribuées, soit Administrateur Système de Niveau Moyen, soit Ingénieur Build
- 13 — Virtualisation — Administrateur Système de Niveau Moyen, ou ce qu'on appelle CloudOps, avec des connaissances approfondies des services spécifiques . C'est très pratique d'avoir tout au même endroit. Grâce à cela, en cas de problème, nos spécialistes vous aideront à le résoudre dans les plus brefs délais. de la plateforme, pour un usage efficace des fonds et pour réduire la charge de maintenance
Pour résumer cette offre d'emploi, on peut dire que les candidats doivent être au niveau Administrateur Système de Niveau Moyen/Senior.
Au fait, il ne faut pas trop séparer les administrateurs entre Linux/Windows. Je comprends bien que les services et systèmes de ces deux mondes diffèrent, mais la base est la même et tout administrateur respectueux de soi se familiarise avec l'un comme avec l'autre, et même s'il n'est pas familier, un bon administrateur n'aura aucune difficulté à s'en informer.
Considérons une autre offre d'emploi :
- Expérience dans la construction de systèmes hautement performants ;
- Excellentes connaissances des systèmes d'exploitation Linux, de logiciels système et de la pile web (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK) ;
- Expérience avec les systèmes de virtualisation (KVM, VMWare, LXC/Docker) ;
- Maîtrise des langages de script ;
- Compréhension des principes de fonctionnement des réseaux et des protocoles ;
- Compréhension des principes de construction de systèmes tolérants aux pannes ;
- Autonomie et initiative ;
Décomposons :
- 1 — Administrateur Système Senior
- 2 — Selon la signification que l'on attribue à cette pile — Administrateur Système de Niveau Moyen/Senior
- 3 — L'expérience de travail peut également signifier — « Je n'ai pas monté de cluster, mais j'ai créé et géré des machines virtuelles, j'avais un hôte Docker, l'accès aux conteneurs était redirigé » — Administrateur Système de Niveau Moyen
- 4 — Junior System Administrator — oui, un administrateur qui ne sait pas écrire des scripts d'automatisation élémentaires, quel que soit le langage, n'est pas un administrateur — c'est un technicien.
- 5 — Middle System Administrator
- 6 — Senior System Administrator
En résumé — Middle/Senior System Administrator
Une autre :
- Expérience en devops ;
- Expérience dans l'utilisation d'un ou plusieurs produits pour la mise en place de processus CI/CD. Gitlab CI est un atout ;
- Travail avec des conteneurs et de la virtualisation ; si vous avez utilisé Docker – c'est bien, et si c'est k8s – c'est excellent !
- Expérience de travail en équipe agile ;
- Connaissance de n'importe quel langage de programmation ;
Voyons :
- 1 — Hmm… Que veulent dire les gars ? =) Ils ne savent probablement pas eux-mêmes ce que cela cache.
- 2 — Build Engineer
- 3 — Middle System Administrator
- 4 — Les soft skills, nous n'allons pas les examiner pour l’instant, bien qu’Agile soit une autre chose qui est interprétée comme bon leur semble.
- 5 — Trop vague — cela peut être un langage script ou compilé. Je suis curieux, est-ce que le fait d'avoir écrit en Pascal et Basic à l'école les satisferait ? =)
Je voudrais également faire une remarque concernant le point 3, afin de clarifier pourquoi ce point est couvert par un administrateur système. Kubernetes n'est qu'une orchestration, un outil qui enveloppe des commandes directes pour les pilotes réseau et les hôtes de virtualisation/isolement en quelques commandes et permet de rendre leur interaction abstraite, et voilà. Prenons par exemple le ‘build framework’ Make, que je, en passant, ne considère pas comme un framework. Oui, je sais qu'il y a cette mode de mettre Make partout où c'est nécessaire et inutile — envelopper Maven dans Make par exemple, sérieusement ?
En gros, Make est juste un wrapper autour de shell, simplifiant les commandes de compilation, de liaison, d'environnement de compilation, tout comme k8s.
Une fois, j'ai interrogé un gars qui utilisait k8s dans son travail sur OpenStack, et il racontait comment il déployait des services dessus, mais quand j'ai posé des questions précisément sur OpenStack, il s'est avéré qu'il était administré, tout comme il était mis en place par des administrateurs système. Pensez-vous vraiment qu'une personne qui a mis en place OpenStack, peu importe quelle plateforme il utilise derrière elle, n'est pas capable d'utiliser k8s ?=)
Ce candidat n'est en fait pas DevOps, mais le même administrateur système et, pour être plus précis, un Kubernetes Administrator.
En résumant encore une fois — Middle/Senior System Administrator, cela leur suffira.
Combien en grammes
Écart des salaires proposés pour les postes indiqués — 90k-200k
Nous aimerions maintenant établir un parallèle entre les récompenses monétaires des Administrateurs Systèmes et des DevOps Engineers.
Essentiellement, pour simplifier, nous pouvons répartir les niveaux en fonction de l'expérience, même si ce ne sera pas précis, cela suffira pour les objectifs de cet article.
Expérience :
- jusqu'à 3 ans — Junior
- jusqu'à 6 ans — Middle
- plus de 6 ans — Senior
Le site de recherche d'employés propose :
Administrateurs Systèmes :
- Junior — 2 ans — 50k roubles.
- Middle — 5 ans — 70k roubles.
- Senior — 11 ans — 100k roubles.
DevOps Engineers :
- Junior — 2 ans — 100k roubles.
- Middle — 3 ans — 160k roubles.
- Senior — 6 ans — 220k roubles.
Pour l'expérience, on a pris en compte toute expérience touchant au SDLC.
Il en découle que les entreprises n'ont en réalité pas besoin de DevOps, et qu'elles auraient pu économiser au moins 50 % des coûts initialement prévus en engageant un Administrateur. De plus, elles auraient pu définir plus clairement les responsabilités de la personne recherchée et répondre plus rapidement à leurs besoins. Il ne faut pas oublier qu'une séparation claire des responsabilités permet de réduire les exigences envers le personnel et de créer une atmosphère de travail plus favorable en raison de l'absence de chevauchements. Dans la grande majorité des annonces, on trouve des termes liés aux utilitaires et aux labels DevOps, mais qui ne reposent pas véritablement sur des exigences envers un DevOps Engineer, mais plutôt des demandes pour un administrateur outil.
Le processus de formation des ingénieurs DevOps est également limité à un ensemble de travaux spécifiques et d'outils, sans donner une compréhension générale des processus et de leurs dépendances. C'est certes bien qu'une personne puisse déployer un AWS EKS en utilisant Terraform, en association avec un sidecar Fluentd dans ce cluster et un stack AWS ELK pour le logging en 10 minutes avec une seule commande dans le terminal, mais si elle ne comprend pas le principe même du traitement des logs et à quoi ils servent, ne sachant pas comment collecter des métriques sur ceux-ci et suivre la dégradation du service, elle restera un simple technicien capable d'utiliser certains outils.
Cependant, la demande engendre l'offre, et nous voyons un marché des DevOps extrêmement surchauffé, où les exigences ne correspondent pas à la véritable fonction, mais permettent simplement aux administrateurs systèmes de gagner plus.
Alors, qui sont-ils vraiment ? Des DevOps ou de simples administrateurs systèmes avides ? =)
Comment avancer ?
Pour les employeurs : formuler les exigences de manière plus précise et chercher exactement ceux dont vous avez besoin, au lieu de vous disperser avec des étiquettes. Si vous ne savez pas ce que font les DevOps, ils ne sont pas nécessaires dans ce cas.
Pour les travailleurs : apprenez. Améliorez constamment vos connaissances, observez l'ensemble des processus et suivez le chemin vers votre objectif. Vous pouvez devenir ce que vous voulez, il suffit d'y mettre du vôtre.
Source : habr.com
