📗 ✏️ 🤙🏾 Qui est DevOps? 👦🏽 ♋️ 🛩️

À l'heure actuelle, c'est presque la position la plus chère du marché. L'agitation autour des ingénieurs DevOps dépasse toutes les limites imaginables, encore moins avec les ingénieurs DevOps seniors.
Je travaille en tant que chef du département d'intégration et d'automatisation, devinez le décryptage anglais - DevOps Manager. Il est peu probable que le décodage anglais reflète exactement nos activités quotidiennes, mais la version russe dans ce cas est plus précise. De par la nature de mon travail, il est naturel que je doive interviewer les futurs membres de mon équipe et, au cours de la dernière année, environ 50 personnes sont passées par moi, et le même montant a été coupé à l'écran avec mes employés.

Nous recherchons toujours des collègues, car derrière le label DevOps se trouve une très grande couche d'ingénieurs de différents types.

Tout ce qui est écrit ci-dessous est mon opinion personnelle, vous n'êtes pas obligé d'être d'accord avec cela, mais j'avoue que cela apportera une touche à votre attitude envers le sujet. Malgré le risque de tomber en disgrâce, je publie mon avis, car je pense qu'il a sa place.

Les entreprises comprennent différemment qui sont les ingénieurs DevOps et, pour recruter rapidement une ressource, elles accrochent cette étiquette pour tout le monde. La situation est assez étrange, car les entreprises sont prêtes à payer des récompenses irréalistes à ces personnes, recevant pour elles, dans la plupart des cas, un outil d'administration.

Alors, qui sont les ingénieurs DevOps?

Commençons par l'histoire - les opérations de développement sont apparues comme une autre étape vers l'optimisation de l'interaction en petites équipes pour augmenter la vitesse de production du produit, comme conséquence attendue. L'idée était de renforcer l'équipe de développement avec une connaissance des procédures et des approches de gestion de l'environnement produit. En d'autres termes, le développeur doit comprendre et savoir comment fonctionne son produit dans certaines conditions, doit comprendre comment déployer son produit, quelles caractéristiques environnementales resserrer, afin d'augmenter la productivité. Ainsi, pendant un certain temps, les développeurs sont apparus avec l'approche DevOps. Les développeurs de DevOps ont écrit des scripts de construction et de packaging pour simplifier leurs activités et les performances d'un environnement productif. Cependant, la complexité de l'architecture de décision et l'influence mutuelle des composants d'infrastructure au fil du temps ont commencé à aggraver les performances des environnements, à chaque itération, une compréhension toujours plus approfondie de certains composants était nécessaire, réduisant la productivité du développeur lui-même en raison du coût supplémentaire de la compréhension des composants et des systèmes de réglage pour une tâche spécifique . Le coût propre du développeur augmentait, le coût du produit avec lui, les exigences pour les nouveaux développeurs de l'équipe ont fortement augmenté, car ils devaient également couvrir les responsabilités de la «star» du développement et, naturellement, la «star» est devenue moins accessible. Il convient également de noter que, selon mon expérience, peu de développeurs sont intéressés par les spécificités du traitement des paquets par le noyau du système d'exploitation, les règles de routage des paquets et les aspects de sécurité de l'hôte. L'étape logique était d'attirer un administrateur connaissant cette responsabilité particulière et de lui attribuer la responsabilité d'un format similaire qui, grâce à son expérience, a permis de réaliser les mêmes indicateurs à moindre coût par rapport au coût de la «star» du développement. Ces administrateurs ont été placés dans une équipe et sa tâche principale était de gérer les environnements de test et de production, sur la base des règles d'une équipe particulière, avec des ressources allouées à cette équipe particulière. Donc, en fait, DevOps est apparu dans l'opinion majoritaire.

Partiellement ou complètement, au fil du temps, ces administrateurs système ont commencé à comprendre les besoins de cette équipe particulière dans le domaine du développement, comment simplifier la vie des développeurs et des testeurs, comment déployer la mise à jour et ne pas passer la nuit au bureau vendredi, corrigeant les erreurs de déploiement. Avec le temps, les administrateurs système qui comprennent ce que veulent les développeurs deviennent les "stars". Afin de minimiser l'impact, les utilitaires de gestion ont commencé à rattraper leur retard, tout le monde se souvenait des méthodes anciennes et fiables d'isolement du niveau du système d'exploitation, qui permettaient de minimiser les exigences de sécurité, de gérer la partie réseau et la configuration de l'hôte dans son ensemble et, par conséquent, de réduire les exigences pour les nouvelles "étoiles".

Une chose «merveilleuse» est apparue - docker. Pourquoi merveilleux? Oui, tout simplement parce que la création d'isolement en chroot ou en prison, ainsi qu'OpenVZ, nécessitait une connaissance non triviale du système d'exploitation, dans un utilitaire de compteur qui vous permet de créer simplement un environnement d'application isolé sur un certain hôte avec tout ce dont vous avez besoin à l'intérieur et de transférer à nouveau les rênes au développement, et de ne gérer que l'administrateur système. un seul hôte, assurant sa sécurité et sa haute disponibilité - une simplification logique. Mais les progrès ne s'arrêtent pas et les systèmes deviennent de plus en plus compliqués, de plus en plus de composants, un hôte ne satisfait plus aux besoins du système et il est nécessaire de construire des clusters, nous revenons encore aux administrateurs système qui sont capables de construire ces systèmes.

Cycle par cycle, divers systèmes apparaissent pour simplifier le développement et / ou l'administration, des systèmes d'orchestration apparaissent, qui, jusqu'à ce que vous ayez besoin de vous éloigner du processus standard, soient faciles à utiliser. L'architecture de microservice semble également simplifier tout ce qui est décrit ci-dessus - moins de relations, plus facile à gérer. D'après mon expérience, je n'ai pas trouvé d'architecture entièrement microservice, je dirais que 50 à 50 à 50% des microservices, des boîtes noires, sont entrés, traités, les 50 autres - un monolithe déchiré, des services incapables de fonctionner séparément des autres composants. Tout cela a de nouveau imposé des restrictions sur le niveau de connaissance des développeurs et des administrateurs.

Des «fluctuations» similaires du niveau d'expertise d'une ressource particulière se poursuivent encore aujourd'hui. Mais nous étions un peu distraits, il y a beaucoup de points qui méritent d'être soulignés.

Ingénieur de construction / ingénieur de version

Des ingénieurs très hautement spécialisés qui sont apparus comme un moyen de standardiser les processus d'assemblage de logiciels et leurs versions. Dans le processus d'introduction du Agile en vrac, il semblerait qu'ils aient cessé d'être en demande, mais c'est loin d'être le cas. Cette spécialisation est apparue comme un moyen de standardisation de l'assemblage et de la livraison de logiciels à l'échelle industrielle, c'est-à-dire en utilisant des techniques standard pour tous les produits de l'entreprise. Avec l'avènement de DevOps, les développeurs ont partiellement perdu leurs fonctions, car ce sont les développeurs qui ont commencé à préparer le produit pour la livraison, et compte tenu de l'évolution de l'infrastructure et de l'approche de la livraison la plus rapide sans égard à la qualité, au fil du temps, ils se sont transformés en bouchon de changements, car le respect des normes de qualité ralentit inévitablement les livraisons. Ainsi, progressivement, une partie de la fonctionnalité Build / Release des ingénieurs a migré vers les épaules des administrateurs système.

Les opérations sont si différentes

Nous passons et encore la présence d'un large éventail de responsabilités et le manque de personnel qualifié nous pousse à une spécialisation difficile, comme les champignons après la pluie, diverses opérations apparaissent:

TechOps - Administrateurs système enike alias HelpDesk Engineer
LiveOps - administrateurs système principalement responsables des environnements productifs
CloudOps - administrateurs système spécialisés dans les «clouds» publics d'Azure, AWS, GCP, etc.
PlatOps / InfraOps / SysOps - administrateurs de 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, correctifs, etc.

DevOps - (en théorie) une personne qui connaît de première main tous les processus du cycle de développement - développement, test, compréhension de l'architecture du produit, est capable d'évaluer les risques de sécurité, connaît les approches et les moyens d'automatisation, au moins à un niveau élevé, et comprend également le pré et le post prise en charge de la version du produit. Une personne est capable de plaider à la fois pour les Opérations et le Développement, ce qui permet de construire une coopération favorable entre les deux piliers. Comprendre les processus de planification d'équipe et gérer les attentes des clients.

Pour effectuer ce genre de travail et de responsabilités, cette personne doit avoir les moyens de contrôler non seulement le développement, les tests, mais aussi la gestion de l'infrastructure produit, ainsi que la planification des ressources. Les DevOps en ce sens ne peuvent se situer ni en informatique, ni en R&D, ni même en PMO, il doit avoir une influence dans tous ces domaines - le directeur technique de l'entreprise, Chief Technical Officer.

En est-il ainsi dans votre entreprise? - J'en doute. Dans la plupart des cas, il s'agit de l'informatique ou de la R&D.

Le manque de fonds et la possibilité d'influencer au moins l'un de ces trois secteurs d'activité déplaceront le poids des problèmes du côté où ces changements sont plus faciles à appliquer, comme l'application de restrictions techniques sur les versions en rapport avec le code sale selon les données des systèmes d'analyseurs statiques. Autrement dit, lorsque le PMO fixe un délai serré pour la publication des fonctionnalités, la R&D ne peut pas donner un résultat de haute qualité dans ces délais et le donne comme il peut, laissant le refactoring pour plus tard, les DevOps liés à l'informatique, par des moyens techniques bloquent la publication. Le manque d'autorité pour changer la situation, dans le cas d'employés responsables, conduit à la manifestation d'une hyper-responsabilité pour ce qu'ils ne peuvent pas influencer, en outre, si ces employés comprennent et voient des erreurs, et comment les corriger est «le bonheur dans l'ignorance», et par conséquent l'épuisement professionnel et la perte de ces employés.

Ressources DevOps de marché

Examinons quelques offres d'emploi DevOps de différentes entreprises.

Nous sommes prêts à vous rencontrer si vous:
Posséder Zabbix et savoir ce qu'est Prométhée;
Iptables;
Étudiant diplômé BASH;
Le professeur Ansible;
Gourou de Linux
Savoir utiliser le débogage et trouver les problèmes d'application avec les développeurs (php / java / python);
Le routage ne vous provoque pas de crises de colère;
Portez une attention particulière à la sécurité du système;
Sauvegardez «tout et tout», et aussi restaurer avec succès ce «tout et tout»;
Vous savez comment configurer le système de manière à ce qu'il sorte d'un minimum - maximum;
Configurer la réplication du coucher sur Postgres et MySQL;
Mettre en place et ajuster CI / CD pour vous est une nécessité comme le petit déjeuner / déjeuner / dîner.
Avoir de l'expérience avec AWS;
Prêt à évoluer avec l'entreprise;

Donc:

1 à 6 - administrateur système
7 - un peu d'administration du réseau, qui s'adapte également à l'administrateur système, niveau intermédiaire
8 - un peu de sécurité, ce qui est obligatoire pour un administrateur système de niveau intermédiaire
9-11 - Administrateur système intermédiaire
12 - Selon les tâches définies, soit l'administrateur système intermédiaire, soit l'ingénieur de construction
13 - Virtualisation - Middle System Administrator, ou le soi-disant CloudOps, connaissance avancée des services d'une plate-forme d'hébergement particulière, pour une utilisation efficace des fonds et réduire la charge sur le service

En résumant cette vacance, nous pouvons dire que l'administrateur système moyen / senior est suffisant pour les gars.

Soit dit en passant, ne séparez pas fortement les administrateurs sous Linux / Windows. Bien sûr, je comprends que les services et les systèmes de ces deux mondes sont différents, mais tout le monde a une base et tout administrateur qui se respecte connaît l'un ou l'autre, et même s'il n'est pas familier, il ne sera pas difficile pour un administrateur compétent de se familiariser avec cela.

Considérons un autre poste vacant:

Expérience dans la construction de systèmes très chargés;
Excellente connaissance du système d'exploitation Linux, des logiciels à l'échelle du 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);
Connaissance des langages de script;
Comprendre les principes de fonctionnement des réseaux de protocoles réseau;
Comprendre les principes de construction de systèmes tolérants aux pannes;
Indépendance et initiative;

Analyser:

1 - Administrateur système senior
2 - Selon le sens investi dans cette pile - Administrateur système moyen / senior
3 - L'expérience, y compris, peut signifier - «Le cluster n'a pas augmenté, mais a créé et géré des machines virtuelles, il y avait un hôte Docker, l'accès aux conteneurs était tendu» - Administrateur système intermédiaire
4 - Administrateur système junior - oui, l'administrateur n'est pas en mesure d'écrire des scripts d'automatisation élémentaires, quelle que soit la langue, pas l'administrateur.
5 - Administrateur système intermédiaire
6 - Administrateur système senior

Résumé - Administrateur système moyen / senior

Un autre:

Expérience devops;
Expérience dans l'utilisation d'un ou plusieurs produits pour former des processus CI / CD. Gitlab CI sera un avantage;
Travailler avec des conteneurs et la virtualisation; Si vous avez utilisé docker - très bien, mais si k8s - super!
Expérience dans une équipe agile;
Connaissance de tout langage de programmation;

Voyons voir:

1 - Hmm ... qu'est-ce que les gars veulent dire? =) Très probablement, ils ne savent pas eux-mêmes ce qui se cache derrière
2 - Ingénieur de construction
3 - Administrateur système intermédiaire
4 - Soft-skill, nous ne le considérerons pas encore, bien que Agile soit encore une chose qui est interprétée de manière pratique.
5 - Trop volumineux - il peut s'agir d'un langage de script ou compilé. Fait intéressant, a-t-il écrit à l'école sur Pascal et Basic? =)

Je voudrais également laisser une remarque concernant 3 points afin de mieux comprendre pourquoi ce point est couvert par l'administrateur système. Kubernetes n'est qu'une orchestration, un outil qui encapsule des commandes directes aux pilotes réseau et aux hôtes de virtualisation / isolation en quelques commandes et vous permet de rendre la communication abstraite avec eux, c'est tout. Par exemple, prenez le «build framework» Make, que je ne considère d'ailleurs pas comme un framework. Oui, je connais la façon de pousser Make partout où cela est nécessaire et non nécessaire - pour envelopper Maven dans Make, par exemple, sérieusement?
En gros, Make n'est qu'un wrapper sur le shell, ce qui simplifie la compilation, la liaison, l'environnement de compilation, ainsi que les k8.

Une fois, j'ai interviewé un gars qui utilisait k8 dans son travail sur OpenStack, et il a parlé de la façon de déployer des services dessus, cependant, quand j'ai posé des questions sur OpenStack, il s'est avéré qu'il est administré, ainsi que soulevé par les administrateurs système. Pensez-vous vraiment que la personne qui a lancé OpenStack, quelle que soit la plateforme qu'il utilise derrière lui, ne peut pas utiliser k8s? =)
Ce demandeur n'est en fait pas DevOps, mais le même administrateur système et, pour être plus précis, l'administrateur Kubernetes.

Nous résumons encore une fois - un administrateur système moyen / senior leur suffira.

Combien accrocher en grammes

La répartition des salaires offerts pour les postes vacants indiqués est de 90k-200k
Maintenant, je voudrais faire un parallèle entre les récompenses monétaires des administrateurs système et des ingénieurs DevOps.

En principe, pour simplifier, vous pouvez disperser les niveaux d'expérience, bien que cela ne soit pas exact, aux fins de l'article, c'est suffisant.

Expérience:

moins de 3 ans - Junior
moins de 6 ans - Moyen
plus de 6 ans - Senior

Le site de recherche d'employés propose:
Administrateurs de système:

Junior - 2 ans - 50k rub.
Moyen - 5 ans - 70k roubles.
Senior - 11 ans - 100k roubles.

Ingénieurs DevOps:

Junior - 2 ans - 100k rub.
Milieu - 3 ans - 160k rub.
Senior - 6 ans - 220k rub.

Selon l'expérience de «DevOps», nous avons utilisé l'expérience, affectant au moins en quelque sorte le SDLC.

De ce qui précède, il s'ensuit qu'en fait, les entreprises n'ont pas besoin de DevOps, et aussi qu'elles pourraient économiser au moins 50% des coûts initialement prévus en embauchant l'administrateur, de plus, elles pourraient déterminer plus clairement les responsabilités de la personne et fermer rapidement le besoin. N'oubliez pas qu'une répartition claire des responsabilités vous permet de réduire les besoins en personnel, ainsi que de créer une atmosphère plus favorable dans l'équipe, en raison de l'absence d'intersections. La grande majorité des postes vacants sont remplis d'utilitaires et d'étiquettes DevOps, cependant, ils n'ont pas vraiment les exigences pour DevOps Engineer, ce ne sont que des demandes pour l'administrateur administrateur.

Le processus de formation des ingénieurs DevOps n'est également limité que par un ensemble de travaux spécifiques, d'utilitaires, ne fournissant pas une compréhension générale des processus et de leurs dépendances. C'est certainement bien quand une personne peut utiliser Terraform pour déployer AWS EKS, en conjonction avec le side-car Fluentd dans ce cluster et la pile AWS ELK pour le système de journalisation en 10 minutes, en utilisant une seule commande dans la console, mais s'il ne comprend pas le principe du traitement les journaux et pourquoi ils sont nécessaires, sans savoir comment collecter des métriques sur eux et suivre la dégradation du service, alors ce sera la même chose, capable d'utiliser certains utilitaires.

Cependant, la demande crée l'offre, et nous voyons un marché extrêmement surchauffé pour le poste DevOps, où les exigences ne correspondent pas au rôle réel, mais permettent uniquement aux administrateurs système de gagner plus.

Alors qui sont-ils? DevOps ou administrateurs système gourmands? =)

Comment vivre plus loin?

Pour les employeurs - il est plus précis de formuler des exigences et de rechercher exactement celles qui sont nécessaires, et non de disperser les étiquettes. Vous ne savez pas ce que font les DevOps - vous n'en avez pas besoin dans ce cas.

Travailleurs - Apprenez. Améliorez constamment vos connaissances, regardez la vue d'ensemble des processus et suivez le chemin vers l'objectif. Vous pouvez devenir ce que vous voulez, vous n'avez qu'à essayer.