Qui sont les DevOps ?

Pour le moment, c’est presque le poste le plus cher du marché. L’agitation autour des ingénieurs « DevOps » dépasse toutes les limites imaginables, et pire encore avec les ingénieurs Senior DevOps.
Je travaille en tant que chef du département d'intégration et d'automatisation, devinez le décodage anglais - DevOps Manager. Il est peu probable que la transcription anglaise reflète nos activités quotidiennes, mais la version russe dans ce cas est plus précise. De par la nature de mon activité, il est naturel que j'aie besoin d'interviewer les futurs membres de mon équipe, et depuis un an, une cinquantaine de personnes sont passées par mon intermédiaire, et autant ont été coupées en présélection avec mes collaborateurs.

Nous sommes toujours à la recherche de collègues, car derrière le label DevOps se cache 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 elle, mais j'avoue que cela ajoutera de la couleur à votre attitude sur le sujet. Malgré le risque de tomber en disgrâce, je publie mon avis parce que je crois qu'il a sa place.

Les entreprises ont une compréhension différente de qui sont les ingénieurs DevOps et, dans le but d'embaucher rapidement une ressource, elles apposent cette étiquette à tout le monde. La situation est assez étrange, puisque les entreprises sont prêtes à payer des rémunérations irréalistes à ces personnes, recevant, dans la plupart des cas, un outil d'administrateur pour elles.

Alors qui sont les ingénieurs DevOps ?

Commençons par l'histoire de son apparition - Les opérations de développement sont apparues comme une autre étape vers l'optimisation de l'interaction au sein de petites équipes afin d'augmenter la vitesse de production des produits, 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 son produit fonctionne dans certaines conditions, doit comprendre comment déployer son produit, quelles caractéristiques de l'environnement peuvent être ajustées pour améliorer les performances. Ainsi, depuis quelques temps, des développeurs avec une approche DevOps sont apparus. Les développeurs DevOps ont écrit des scripts de build et de packaging pour simplifier leurs activités et les performances de l'environnement de production. Cependant, la complexité de l'architecture de la solution et l'influence mutuelle des composants de l'infrastructure au fil du temps ont commencé à détériorer les performances des environnements ; à chaque itération, une compréhension de plus en plus approfondie de certains composants était nécessaire, réduisant la productivité du développeur en raison de la complexité supplémentaire les coûts liés à la compréhension des composants et des systèmes de réglage pour une tâche spécifique. Le coût du développeur a augmenté, le coût du produit avec lui, les exigences pour les nouveaux développeurs dans l'équipe ont fortement augmenté, car ils devaient également assumer les responsabilités de la « star » du développement et, naturellement, les « stars » sont devenues moins nombreuses. et moins disponible. Il convient également de noter que, d'après mon expérience, peu de développeurs s'intéressent aux spécificités du traitement des paquets par le noyau du système d'exploitation, aux règles de routage des paquets et aux aspects de sécurité de l'hôte. L'étape logique était d'attirer un administrateur familier avec cela et de lui confier des responsabilités similaires, ce qui, grâce à son expérience, a permis d'atteindre les mêmes indicateurs à un coût inférieur par rapport au coût d'un développement « star ». Ces administrateurs étaient placés dans une équipe, et sa tâche principale était de gérer les environnements de test et de production, selon les règles d'une équipe spécifique, avec des ressources allouées à cette équipe particulière. C’est ainsi qu’en fait le DevOps est apparu dans l’esprit de la majorité.

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 faciliter la vie des développeurs et des testeurs, comment déployer une mise à jour et ne pas avoir à passer la nuit vendredi à le bureau, corrigeant les erreurs de déploiement. Le temps a passé, et désormais les « stars » étaient les administrateurs système qui comprenaient ce que voulaient les développeurs. Afin de minimiser l'impact, des utilitaires de gestion ont commencé à apparaître ; tout le monde se souvenait des méthodes anciennes et fiables d'isolation au niveau du système d'exploitation, qui permettaient de minimiser les exigences de sécurité, de gestion de la partie réseau et de configuration de l'hôte en tant que dans son ensemble et, par conséquent, réduire les besoins en nouvelles « étoiles ».

Une chose « merveilleuse » est apparue : Docker. Pourquoi merveilleux ? Oui, uniquement parce que la création d'un isolement dans un chroot ou une prison, ainsi qu'OpenVZ, nécessitait une connaissance non triviale du système d'exploitation, en revanche, l'utilitaire vous permet de créer simplement un environnement d'application isolé sur un certain hôte avec tout le nécessaire à l'intérieur et à la main. reprend les rênes du développement, et l'administrateur système ne peut gérer qu'avec un seul hôte, garantissant sa sécurité et sa haute disponibilité - une simplification logique. Mais les progrès ne s'arrêtent pas et les systèmes deviennent à nouveau de plus en plus complexes, il y a de plus en plus de composants, un hôte ne répond plus aux besoins du système et il faut construire des clusters, on revient à nouveau aux administrateurs système qui sont capable de construire ces systèmes.

Cycle après cycle, divers systèmes apparaissent qui simplifient le développement et/ou l'administration, des systèmes d'orchestration apparaissent qui, jusqu'à ce que vous deviez vous écarter du processus standard, sont faciles à utiliser. L'architecture des microservices est également apparue dans le but de 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 microservices, je dirais que 50 à 50 - 50 % des microservices, des boîtes noires, sont entrés, sont sortis traités, les 50 autres sont un monolithe déchiré, les services incapables de fonctionner séparément des autres. Composants. Tout cela a encore une fois imposé des restrictions sur le niveau de connaissances des développeurs et des administrateurs.

Des « oscillations » similaires dans le niveau de connaissance experte d’une ressource particulière se poursuivent encore aujourd’hui. Mais on s'éloigne un peu, il y a de nombreux points qui méritent d'être soulignés.

Ingénieur de construction/ingénieur de publication

Des ingénieurs très hautement spécialisés qui sont apparus comme un moyen de normaliser les processus et les versions de création de logiciels. Dans le processus de généralisation de l'Agile, il semblerait qu'ils aient cessé d'être demandés, mais c'est loin d'être le cas. Cette spécialisation est apparue comme un moyen de standardiser l'assemblage et la livraison des 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, puisque 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 visant à livrer le plus rapidement possible sans tenir compte de la qualité, ils se sont finalement transformés en un frein aux changements, puisque le respect des normes de qualité ralentit inévitablement les livraisons. Ainsi, progressivement, une partie des fonctionnalités des ingénieurs Build/Release a migré vers les épaules des administrateurs système.

Les opérations sont si différentes

On avance et encore une fois la présence d'un large éventail de responsabilités et le manque de personnel qualifié nous poussent vers une spécialisation stricte, comme les champignons après la pluie, diverses opérations apparaissent :

• TechOps - Administrateurs système enikey alias HelpDesk Engineer
• LiveOps - administrateurs système principalement responsables des environnements de production
• CloudOps - administrateurs système spécialisés dans les cloud publics 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, correctifs, etc.

DevOps est (en théorie) une personne qui comprend de première main tous les processus du cycle de développement - développement, tests, comprend l'architecture du produit, est capable d'évaluer les risques de sécurité, est familiarisée avec les approches et les outils d'automatisation, au moins à un niveau élevé. En plus de cela, le niveau comprend également le support de pré- et post-traitement de la version du produit. Une personne capable d'agir à titre de défenseur à la fois des opérations et du développement, ce qui permet une coopération favorable entre ces deux piliers. Comprend les processus de planification du travail des équipes et de gestion des attentes des clients.

Pour effectuer ce genre de travail et de responsabilités, cette personne doit avoir les moyens de gérer non seulement les processus de développement et de tests, mais également la gestion de l'infrastructure du produit, ainsi que la planification des ressources. Dans cette acception, le DevOps ne peut se situer ni dans l'informatique, ni dans la R&D, ni même dans le PMO ; il doit avoir une influence dans tous ces domaines - le directeur technique de l'entreprise, le directeur technique.

Est-ce vrai dans votre entreprise ? - Je doute. Dans la plupart des cas, il s’agit soit d’informatique, soit de R&D.

Le manque de fonds et la capacité d'influencer au moins un de ces trois domaines d'activité déplaceront le poids des problèmes vers les domaines où ces changements sont plus faciles à appliquer, comme l'application de restrictions techniques sur les versions liées au code « sale » selon les normes statiques. systèmes d’analyse. Autrement dit, lorsque le PMO fixe un délai strict pour la sortie d'une fonctionnalité, la R&D ne peut pas produire un résultat de haute qualité dans ces délais et le produit du mieux qu'elle peut, laissant le refactoring pour plus tard, le DevOps lié à l'informatique bloque la publication par des moyens techniques. . Le manque d'autorité pour changer la situation, dans le cas des employés responsables, conduit à la manifestation d'une hyper-responsabilité pour ce qu'ils ne peuvent pas influencer, surtout si ces employés comprennent et voient les erreurs, et comment les corriger - « Le bonheur est l'ignorance », et par conséquent l'épuisement professionnel et la perte de ces employés.

Marché des ressources DevOps

Examinons plusieurs postes vacants pour des postes DevOps dans différentes entreprises.

Nous sommes prêts à vous rencontrer si vous :

1. Vous possédez Zabbix et savez ce qu'est Prometheus ;
2. Iptables ;
3. Étudiant au doctorat BASH ;
4. Professeur Ansible ;
5. Gourou Linux ;
6. Savoir utiliser le débogage et trouver les problèmes d'application en collaboration avec les développeurs (php/java/python);
7. Le routage ne rend pas hystérique ;
8. Accorder une attention particulière à la sécurité du système ;
9. Sauvegardez « tout et n'importe quoi », et restaurez également avec succès ce « tout et n'importe quoi » ;
10. Vous savez configurer le système de manière à tirer le maximum du minimum ;
11. Configurez la réplication avant de vous coucher sur Postgres et MySQL ;
12. La configuration et le réglage du CI/CD sont aussi nécessaires pour vous que le petit-déjeuner/déjeuner/dîner.
13. Avoir de l'expérience avec AWS ;
14. Prêt à développer avec l'entreprise;

Donc:

• de 1 à 6 - administrateur système
• 7 - un peu d'administration réseau, qui s'intègre également dans l'administrateur système, niveau intermédiaire
• 8 - un peu de sécurité, obligatoire pour un administrateur système de niveau intermédiaire
• 9-11 – Administrateur système intermédiaire
• 12 — En fonction des tâches assignées, soit un administrateur système intermédiaire, soit un ingénieur de construction
• 13 - Virtualisation - Administrateur système intermédiaire, ou ce qu'on appelle CloudOps, connaissance avancée des services d'un site d'hébergement spécifique, pour une utilisation efficace des fonds et une réduction de la charge de maintenance

En résumant ce poste vacant, nous pouvons dire qu'un administrateur système intermédiaire/senior est suffisant pour les gars.

À propos, il ne faut pas diviser fortement les administrateurs sous Linux/Windows. Bien sûr, je comprends que les services et systèmes de ces deux mondes sont différents, mais la base de tout est la même et tout administrateur qui se respecte connaît à la fois l'un et l'autre, et même s'il ne le connaît pas, il le fera. il ne sera pas difficile pour un administrateur compétent de s'y familiariser.

Considérons un autre poste vacant :

1. Expérience dans la construction de systèmes à forte charge ;
2. Excellente connaissance du système d'exploitation Linux, des logiciels système généraux et de la pile Web (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK) ;
3. Expérience avec les systèmes de virtualisation (KVM, VMWare, LXC/Docker);
4. Maîtrise des langages de script ;
5. Compréhension des principes de fonctionnement des réseaux à protocole réseau ;
6. Compréhension des principes de construction de systèmes tolérants aux pannes ;
7. Indépendance et initiative ;

Regardons:

• 1 – Administrateur système principal
• 2 - Selon le sens donné à cette pile - Administrateur système intermédiaire/sénior
• 3 - L'expérience professionnelle, notamment, peut signifier - "Le cluster n'a pas généré, mais a créé et géré des machines virtuelles, il y avait un hôte Docker, l'accès aux conteneurs n'était pas disponible" - Administrateur système intermédiaire
• 4 - Administrateur système junior - oui, un administrateur qui ne sait pas écrire des scripts d'automatisation de base, quelle que soit la langue, pas un administrateur - enikey.
• 5 - Administrateur système intermédiaire
• 6 – Administrateur système principal

Pour résumer - Administrateur système intermédiaire/senior

Un de plus:

1. Expérience Devops ;
2. Expérience dans l'utilisation d'un ou plusieurs produits pour créer des processus CI/CD. Gitlab CI sera un avantage ;
3. Travailler avec des conteneurs et la virtualisation ; Si vous avez utilisé Docker, bien, mais si vous avez utilisé K8, super !
4. Expérience de travail dans une équipe agile;
5. Connaissance de n'importe quel langage de programmation ;

Nous verrons:

• 1 - Hmm... Que veulent dire les gars ? =) 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 - Les compétences générales, nous n'y parlerons pas pour l'instant, même si l'Agile est une autre chose qui est interprétée d'une manière pratique.
• 5 - Trop verbeux - il peut s'agir d'un langage de script ou d'un langage compilé. Je me demande si écrire en Pascal et en Basic à l'école leur conviendra ? =)

Je voudrais également laisser une note concernant le point 3 afin de renforcer la compréhension de la raison pour laquelle ce point est couvert par l'administrateur système. Kubernetes n'est qu'une orchestration, un outil qui regroupe les commandes directes vers les pilotes réseau et les hôtes de virtualisation/isolation en quelques commandes et vous permet de rendre la communication avec eux abstraite, c'est tout. Par exemple, prenons Make 'build framework', que, soit dit en passant, je ne considère pas comme un framework. Oui, je connais la mode de pousser Make n'importe où, là où c'est nécessaire et pas nécessaire - envelopper Maven dans Make, par exemple, sérieusement ?
Essentiellement, Make n'est qu'un wrapper sur le shell, simplifiant les commandes d'environnement de compilation, de liaison et de compilation, tout comme k8.

Une fois, j'ai interviewé un gars qui utilisait des k8 dans son travail sur OpenStack, et il a expliqué comment il y avait déployé des services. Cependant, lorsque j'ai posé des questions sur OpenStack, il s'est avéré qu'il était administré et géré par le système. administrateurs. Pensez-vous vraiment qu'une personne qui a installé OpenStack, quelle que soit la plateforme qu'elle utilise derrière elle, n'est pas capable d'utiliser les k8 ? =)
Ce candidat n'est pas réellement un DevOps, mais un administrateur système et, pour être plus précis, un administrateur Kubernetes.

Résumons encore une fois : un administrateur système intermédiaire/senior leur suffira.

Combien pendre en grammes

La fourchette des salaires proposés pour les postes vacants indiqués est de 90 200 à XNUMX XNUMX
Je voudrais maintenant faire un parallèle entre les récompenses monétaires des administrateurs système et des ingénieurs DevOps.

En principe, pour simplifier les choses, vous pouvez répartir les notes en fonction de l'expérience professionnelle, même si cela ne sera pas exact, mais pour les besoins de l'article, cela suffira.

Expérience:

1. jusqu'à 3 ans – Junior
2. jusqu'à 6 ans – Moyen
3. plus de 6 – Senior

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

1. Junior - 2 ans - 50 XNUMX roubles.
2. Milieu - 5 ans - 70 XNUMX roubles.
3. Senior - 11 ans - 100 XNUMX roubles.

Ingénieurs DevOps :

1. Junior - 2 ans - 100 XNUMX roubles.
2. Moyen - 3 ans - 160 XNUMX roubles.
3. Senior - 6 ans - 220 XNUMX roubles.

Selon l'expérience de « DevOps », une expérience a été utilisée qui a au moins affecté d'une manière ou d'une autre le SDLC.

De ce qui précède, il s'ensuit qu'en réalité les entreprises n'ont pas besoin de DevOps et qu'elles pourraient économiser au moins 50 pour cent des coûts initialement prévus en embauchant un administrateur ; en outre, elles pourraient définir plus clairement les responsabilités de la personne qu'elles recherchent. et combler le besoin plus rapidement. Il ne faut pas non plus oublier qu'une répartition claire des responsabilités nous permet de réduire les besoins en personnel, ainsi que de créer une atmosphère plus favorable au sein de l'équipe, grâce à l'absence de chevauchements. La grande majorité des postes vacants regorgent d'utilitaires et de labels DevOps, mais ils ne sont pas basés sur les exigences réelles d'un ingénieur DevOps, mais uniquement sur les demandes d'un administrateur d'outils.

Le processus de formation des ingénieurs DevOps se limite également à un ensemble de travaux et d'utilitaires spécifiques et ne fournit pas une compréhension générale des processus et de leurs dépendances. C'est certainement bien quand une personne peut déployer AWS EKS à l'aide de Terraform, 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 si elle ne comprend pas le principe de traitement lui-même des journaux et à quoi ils sont nécessaires, si vous ne savez pas comment collecter des métriques sur eux et suivre la dégradation du service, alors ce sera toujours le même enikey qui sait utiliser certains utilitaires.

Cependant, la demande crée l'offre et nous constatons 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?

Les employeurs devraient formuler leurs exigences avec plus de précision et rechercher exactement celles dont ils ont besoin, plutôt que de lancer des é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, examinez l'image globale des processus et suivez le chemin vers votre objectif. Vous pouvez devenir qui vous voulez, il vous suffit d'essayer.

Source: habr.com