Le sujet du DevOps est devenu très populaire ces dernières années. Beaucoup rêvent d'y entrer, mais comme le montre la pratique, c'est souvent uniquement en raison des niveaux de salaires.
Certains mentionnent DevOps dans leur CV, bien qu'ils ne comprennent pas toujours la signification du terme. Certains pensent qu'en étudiant Ansible, GitLab, Jenkins, Terraform et d'autres outils similaires (la liste peut se prolonger), ils deviendront immédiatement des « devops ». Ce n'est bien sûr pas le cas.
Depuis quelques années, je m'occupe principalement de l'implémentation du DevOps dans diverses entreprises. Avant cela, j'ai travaillé pendant plus de 20 ans à divers postes allant d'administrateur système à directeur informatique. Actuellement, je suis DevOps Lead Engineer chez Playgendary.
Qui est DevOps
L'idée d'écrire cet article est née après une nouvelle question : « qui est DevOps ? ». Il n'existe pas encore de terme établi pour désigner cela ou cette personne. Une partie des réponses se trouve déjà ici. . Je vais d'abord mettre en avant les principaux points de ce texte, puis je partagerai mes observations et réflexions.
DevOps n'est pas un spécialiste que l'on peut embaucher, ce n'est pas un ensemble d'outils, et ce n'est pas un département de développeurs et d'ingénieurs.
DevOps est une philosophie et une méthodologie.
En d'autres termes, c'est un ensemble de pratiques qui aide à promouvoir l'interaction active entre les développeurs et les administrateurs systèmes. En d'autres termes, cela vise à relier et intégrer les processus de travail les uns aux autres.
Avec l'émergence de DevOps, la structure et les rôles des spécialistes sont restés les mêmes (il y a des développeurs, il y a des ingénieurs), mais les règles d'interaction ont changé. Les frontières entre les départements se sont estompées.
Les objectifs de DevOps peuvent être décrits en trois points :
- Le logiciel doit être mis à jour régulièrement.
- Le logiciel doit être produit rapidement.
- Le logiciel doit être déployé de manière pratique et dans des délais courts.
Il n'y a pas d'outil unique pour DevOps. Configurer, installer et étudier plusieurs produits ne signifie pas qu'une entreprise a adopté DevOps. Il existe de nombreux outils qui sont utilisés à différentes étapes, mais qui servent un objectif commun.
Et ceci n'est qu'une partie des outils DevOps.
Cela fait plus de 2 ans que j'interroge des personnes pour le poste d'ingénieur DevOps, et j'en suis venu à réaliser à quel point il est important de bien comprendre la signification du terme. J'ai accumulé de l'expérience spécifique, des observations et des réflexions que je veux partager.
D'après mon expérience des entretiens, je vois le tableau suivant : les spécialistes qui considèrent DevOps comme un poste ont généralement des malentendus avec leurs collègues..
Il s'agissait d'un exemple frappant. Lors de l'entretien, un jeune homme est venu avec plein de mots techniques dans son CV. Dans ses trois derniers emplois, il n'a effectué que des stages de 5-6 mois. Il a quitté deux startups parce qu'elles « n'ont pas fonctionné ». Quant à la troisième entreprise, il a dit que personne ne le comprenait : les développeurs écrivent du code sous Windows, tandis que le directeur exige de « mettre » ce code dans un Docker classique et de l'intégrer dans le pipeline CI/CD. Le jeune homme a partagé de nombreuses critiques négatives sur son emploi actuel et ses collègues — j'avais envie de lui répondre : « Tu n'iras pas loin avec ça ».
Puis je lui ai posé une question qui figure parmi les premières de ma liste pour chaque candidat.
— Qu'est-ce que DevOps signifie pour toi personnellement ?
— En général ou selon ma perception ?
J'étais intéressé par son avis personnel. Il maîtrisait la théorie et l'origine du terme, mais n'était absolument pas d'accord avec eux. Il considérait que DevOps était un poste. C'est là que réside la racine de ses problèmes. Comme pour d’autres spécialistes avec le même avis.
Les employeurs, séduits par la « magie du DevOps », souhaitent trouver quelqu'un qui viendra créer cette « magie ». Et les candidats qui pensent que « DevOps est un poste » ne comprennent pas qu'avec cette approche, ils ne pourront pas répondre aux attentes. Et, en fait, ils ont inscrit DevOps dans leur CV parce que c'est à la mode et que cela paie bien.
La méthodologie et la philosophie du DevOps
La méthodologie peut être théorique ou pratique. Dans notre cas, c'est la seconde. Comme j'ai mentionné précédemment, DevOps est un ensemble de pratiques et de stratégies appliquées pour atteindre les objectifs déclarés. Et dans chaque cas, selon les processus métier de l'entreprise, elle peut différer considérablement. Ce qui ne la rend ni meilleure ni pire.
La méthodologie DevOps n'est qu'un moyen d'atteindre les objectifs fixés.
Maintenant, parlons de ce qu'est la philosophie DevOps. Et c'est probablement la question la plus difficile.
Formuler une réponse courte et concise est assez difficile, car elle n'est pas encore formalisée. Et comme les adeptes de la philosophie DevOps passent plus de temps dans la pratique, il n'y a tout simplement pas de temps pour philosopher. Néanmoins, c'est un processus très important. De plus, cela est directement lié à l'activité d'ingénierie. Il existe même un domaine de connaissance spécialisé — .
Dans mon établissement, il n'y avait pas ce cours, j'ai donc dû tout étudier moi-même à partir des matériaux que j'ai pu trouver dans les années 90. Le sujet n'est pas obligatoire pour une formation d'ingénieur, d'où l'absence de formalisation de la réponse. Mais ceux qui se sont sérieusement plongés dans le DevOps commencent à ressentir une certaine « esprit » ou « universalité inconsciente » de tous les processus de l'entreprise.
J'ai essayé de formaliser certains « postulats » de cette philosophie à partir de mon expérience. Voici ce que j'en ai retenu :
- Le DevOps n'est pas quelque chose de séparé, qu'on peut distinguer comme un domaine de connaissances ou une activité à part.
- Tous les employés de l'entreprise doivent être guidés par la méthodologie DevOps dans la planification de leur travail.
- Le DevOps touche tous les processus au sein de l'entreprise.
- Le DevOps existe pour réduire le temps consacré à tous les processus internes de l'entreprise afin d'assurer le développement de ses services et le maximum de confort pour le client.
- Le DevOps, en termes modernes, représente une position proactive de chaque employé de l'entreprise, visant à réduire les coûts temporels et à améliorer la qualité des produits IT qui nous entourent.
Je pense que mes « postulats » sont un sujet de discussion à part entière. Mais maintenant, nous avons une base sur laquelle nous appuyer.
Que fait le DevOps
Le mot clé ici est la communication. Il y a beaucoup de communications, initiées précisément par ce DevOps ingénieur. Pourquoi ? Parce que c'est une philosophie et une méthodologie, et seulement après des connaissances techniques.
Je ne peux pas parler du marché du travail occidental avec une certitude à 100%. Mais concernant le marché du DevOps en Russie, j'en sais assez. En plus de centaines d'entretiens, j'ai participé ces dix-huit derniers mois à une centaine de préventes techniques pour le service « Mise en œuvre du DevOps » pour de grandes entreprises et banques russes.
En Russie, DevOps est encore un sujet très jeune, mais déjà en vogue. D'après ce que je sais, il y a eu un manque de plus de 1000 spécialistes dans ce domaine à Moscou rien qu'en 2019. Le mot Kubernetes est presque comme un chiffon rouge pour les employeurs. Les adeptes de cet outil sont prêts à l'utiliser même là où cela n'est pas nécessaire et n'est pas rentable. L'employeur ne comprend pas toujours dans quels cas il est plus approprié d'utiliser tel ou tel outil, alors que lorsque le cluster Kubernetes est correctement déployé, son contenu coûte 2 à 3 fois plus cher que le déploiement d'une application selon un schéma de cluster classique. Utilisez-le là où il est vraiment nécessaire.
La mise en œuvre de DevOps, en termes financiers, est coûteuse. Elle n'est justifiée que si elle apporte un avantage économique dans d'autres domaines, et non par elle-même.
Les ingénieurs DevOps sont en réalité des pionniers — ce sont eux qui doivent d'abord mettre en œuvre cette méthodologie dans les entreprises et établir les processus. Pour que cela réussisse, le spécialiste doit interagir en permanence avec les employés et les collègues à tous les niveaux. Comme je le dis souvent, tous les employés de l'entreprise doivent être impliqués dans le processus de mise en œuvre de DevOps : du personnel de nettoyage au CEO. C'est une condition essentielle. Si le membre le plus junior de l'équipe ne sait pas et ne comprend pas ce qu'est DevOps et pourquoi certaines actions organisationnelles sont réalisées, la mise en œuvre ne pourra pas être réussie.
De plus, l'ingénieur DevOps doit de temps en temps utiliser des ressources administratives. Par exemple, pour surmonter la "résistance de l'environnement" — lorsque l'équipe n'est pas prête à accepter les outils et la méthodologie DevOps.
Le développeur ne doit écrire que du code et des tests. Pour cela, il n'a pas besoin d'un ordinateur portable super puissant sur lequel il va déployer et maintenir toute l'infrastructure du projet localement. Par exemple, un développeur front-end garde sur son ordinateur portable tous les éléments de l'application, y compris la base de données, un émulateur S3 (minio) et d'autres éléments. Cela signifie qu'il consacre beaucoup de temps à maintenir cette infrastructure locale et qu'il se bat seul contre tous les problèmes que cette solution engendre, au lieu de développer le code pour le front. De telles personnes peuvent résister fortement à tout changement.
Mais il existe des équipes qui, au contraire, sont ravies d'intégrer de nouveaux outils et méthodes, et participent activement à ce processus. Même dans ce cas, la communication entre l'ingénieur DevOps et l'équipe reste essentielle.
Quand DevOps n'est pas nécessaire
Il existe des situations où DevOps n'est pas nécessaire. C'est un fait — il faut le comprendre et l'accepter.
Cela concerne en premier lieu toutes les entreprises (en particulier les petites entreprises), lorsque leur profit ne dépend pas directement de la présence ou de l'absence de produits informatiques fournissant des services d'information aux clients. Et ici, il ne s'agit pas du site de l'entreprise, qu'il s'agisse d'une simple « carte de visite » statique ou de blocs d'actualités dynamiques, etc.
DevOps est nécessaire lorsque la satisfaction de votre client et son désir de revenir vers vous dépendent de la présence de ces services d'information pour interagir avec le client, de leur qualité et de leur ciblage.
Un exemple frappant est une banque bien connue. La société n'a pas de bureaux clients traditionnels, la gestion des documents se fait par courrier ou par coursiers, et de nombreux employés travaillent à domicile. L'entreprise a cessé d'être simplement une banque et, à mon avis, s'est transformée en entreprise IT avec des technologies DevOps développées.
De nombreux autres exemples et conférences peuvent être trouvés dans les enregistrements de meetups thématiques et de conférences. J'en ai personnellement assisté à quelques-uns — c'est une expérience très enrichissante pour ceux qui souhaitent progresser dans ce domaine. Voici des liens vers des chaînes YouTube avec de bonnes conférences et du matériel sur DevOps :
Maintenant, regardez votre entreprise et réfléchissez à ceci : dans quelle mesure votre entreprise et ses bénéfices dépendent-ils des produits informatiques qui assurent l'interaction avec le client ?
Si votre entreprise vend du poisson dans un petit magasin et que le seul produit informatique est deux configurations 1C: Entreprise (Comptabilité et UHF), il est peu probable qu'il soit pertinent de parler de DevOps.
En revanche, si vous travaillez dans une grande entreprise commerciale et industrielle (par exemple, si vous produisez des fusils de chasse), il est intéressant d'y réfléchir. Vous pouvez prendre l'initiative et faire part de votre vision de l'intégration de DevOps à votre direction. Et au passage, vous pouvez mener ce processus. Une position proactive est l'un des principes importants de la philosophie DevOps.
La taille et le volume du chiffre d'affaires annuel ne sont pas le principal critère pour déterminer si votre entreprise a besoin de DevOps.
Imaginons une grande entreprise industrielle qui n'interagit pas directement avec les clients. Par exemple, certaines marques automobiles et sociétés de construction automobile. Je ne suis pas sûr en ce moment, mais d'après mon expérience passée, durant de nombreuses années, toute l'interaction avec les clients se faisait par e-mail et téléphone.
Leurs clients sont une liste restreinte de concessionnaires automobiles. Et un spécialiste du fabricant est affecté à chacun d'eux. Tout le flux documentaire interne se fait via ERP SAP. Les employés internes sont, en fait, des clients du système d'information. Mais la gestion de ce système d'information est effectuée par des moyens classiques de gestion des systèmes en cluster. Ce qui exclut la possibilité d'utiliser les pratiques DevOps.
D'où la conclusion : pour de telles entreprises, l'implémentation de DevOps n'est pas quelque chose de critique, si l'on se souvient des objectifs de la méthodologie évoqués au début de l'article. Mais je ne doute pas que certains outils DevOps sont utilisés par eux aujourd'hui.
D'autre part, il existe de nombreuses petites entreprises qui développent des logiciels en utilisant la méthodologie, la philosophie, les pratiques et les outils DevOps. Et elles considèrent que les coûts liés à l'implémentation de DevOps sont des dépenses leur permettant de rivaliser efficacement sur le marché du logiciel. On peut voir des exemples de telles entreprises. .
Le critère principal pour comprendre si DevOps est nécessaire : quelle importance vos produits informatiques ont-ils pour l'entreprise et les clients.
Si le produit principal de l'entreprise, qui génère des bénéfices, est un logiciel - vous avez besoin de DevOps. Et il n'importe pas tant que vous gagnez de l'argent avec d'autres produits. Cela inclut également les boutiques en ligne ou les applications mobiles avec des jeux.
Tous les jeux existent grâce à un financement : direct ou indirect de la part des joueurs. Chez Playgendary, nous développons des jeux mobiles gratuits, dans la création desquels participent plus de 200 personnes. Comment utilisons-nous DevOps ?
De la même manière que décrit ci-dessus. Je communique constamment avec les développeurs et les testeurs, je réalise des formations internes pour les employés sur la méthodologie et les outils DevOps.
Nous utilisons actuellement Jenkins comme outil pour les pipelines CI/CD afin d'exécuter tous les processus de compilation avec Unity et de déployer ensuite dans l'App Store et le Play Market. Également dans notre ensemble classique d'outils :
- Asana - pour la gestion de projets. Une intégration avec Jenkins est configurée.
- Google Meet - pour organiser des visioconférences.
- Slack - pour la communication et diverses notifications, y compris les alertes de Jenkins.
- Atlassian Confluence - pour la documentation et le travail en groupe.
Dans nos plans les plus proches, nous prévoyons d'implémenter une analyse statique du code avec SonarQube et de réaliser des tests automatisés de l'interface utilisateur avec Selenium lors de l'intégration continue.
En conclusion
Je souhaite terminer par cette pensée : pour devenir un ingénieur DevOps de haut niveau, il est vital d'apprendre à communiquer efficacement avec les gens.
Un ingénieur DevOps est un joueur d'équipe. Et rien d'autre. L'initiative de communication avec les collègues doit venir de lui-même, et non sous l'influence de circonstances extérieures. Un spécialiste DevOps doit voir et proposer la meilleure solution pour l'équipe.
Et oui, l'implémentation de toute solution nécessitera de nombreuses discussions, et à la fin, elle peut même changer. En se développant de manière autonome, en proposant et en réalisant ses idées - une telle personne représente une valeur de plus en plus grande tant pour l'équipe que pour l'employeur. Ce qui, en fin de compte, se reflète également sur le montant de sa rémunération mensuelle ou sous forme de primes supplémentaires.
Source : habr.com
