Le DevOps est devenu un sujet très populaire ces dernières années. Beaucoup de gens rêvent d'y rejoindre, mais, comme le montre la pratique, souvent uniquement en raison du niveau des salaires.
Certaines personnes mentionnent DevOps sur leur CV, même si elles ne connaissent pas ou ne comprennent pas toujours l’essence du terme. Certains pensent qu’après avoir étudié Ansible, GitLab, Jenkins, Terraform et autres (la liste peut être continuée selon vos goûts), vous deviendrez immédiatement un « devopsist ». Ceci n'est bien sûr pas vrai.
Depuis quelques années, je suis principalement impliqué dans la mise en œuvre du DevOps dans diverses entreprises. Avant cela, il a travaillé pendant plus de 20 ans dans des postes allant d'administrateur système à directeur informatique. Actuellement ingénieur principal DevOps chez Playgendary.
Qui est DevOps
L’idée d’écrire un article est née suite à une autre question : « qui est DevOps ? Il n’existe toujours pas de terme établi pour désigner de quoi il s’agit ou qui il s’agit. Certaines des réponses sont déjà là . Tout d’abord, j’en soulignerai les principaux points, puis je partagerai mes observations et mes réflexions.
DevOps n'est pas un spécialiste qui peut être embauché, ni un ensemble d'utilitaires, ni un département de développeurs avec des ingénieurs.
DevOps est une philosophie et une méthodologie.
En d’autres termes, il s’agit d’un ensemble de pratiques qui aident les développeurs à interagir activement avec les administrateurs système. Autrement dit, connecter et intégrer les processus de travail les uns dans les autres.
Avec l'avènement du 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 départements se sont estompées.
Les objectifs du DevOps peuvent être décrits en trois points :
- Le logiciel doit être mis à jour régulièrement.
- Le logiciel doit être réalisé rapidement.
- Le logiciel doit être déployé facilement et en peu de temps.
Il n’existe pas d’outil unique pour DevOps. Configurer, livrer et étudier plusieurs produits ne signifie pas que le DevOps soit apparu dans l’entreprise. Il existe de nombreux outils et ils sont tous utilisés à différentes étapes, mais servent un objectif commun.
Et ce n'est qu'une partie des outils DevOps
Cela fait plus de 2 ans que j'interviewe des personnes pour le poste d'ingénieur DevOps et j'ai réalisé à quel point il est important de bien comprendre l'essence du terme. J'ai accumulé des expériences, des observations et des réflexions spécifiques que je souhaite partager.
D’après mon expérience d’entretien, je vois l’image suivante : les spécialistes qui considèrent DevOps comme un titre de poste ont généralement des malentendus avec leurs collègues.
Il y avait un exemple frappant. Un jeune homme est venu à un entretien avec beaucoup de mots intelligents sur son CV. Lors de ses trois derniers emplois, il avait 5 à 6 mois d'expérience. J’ai quitté deux startups parce qu’elles « n’ont pas décollé ». Mais à propos de la troisième société, il a dit que personne ne le comprend là-bas : les développeurs écrivent du code sous Windows, et le directeur force ce code à être « encapsulé » dans Docker standard et intégré dans le pipeline CI/CD. Le gars a dit beaucoup de choses négatives sur son lieu de travail actuel et ses collègues - je voulais juste répondre : "Alors vous ne vendrez pas d'éléphant."
Ensuite, je lui ai posé une question qui figure en tête de ma liste pour chaque candidat.
— Que signifie DevOps pour vous personnellement ?
- En général ou comment je le perçois ?
J'étais intéressé par son opinion personnelle. Il connaissait la théorie et l’origine du terme, mais il n’était pas du tout d’accord avec celles-ci. Il pensait que DevOps était un titre de poste. C’est là que réside la racine de ses problèmes. Ainsi que d’autres spécialistes partageant le même avis.
Les employeurs, ayant beaucoup entendu parler de la « magie du DevOps », souhaitent trouver une personne qui viendra créer cette « magie ». Et les candidats de la catégorie « DevOps est un métier » ne comprennent pas qu'avec cette approche ils ne pourront pas répondre aux attentes. Et, en général, ils ont écrit DevOps sur leur CV parce que c'est une tendance et qu'ils paient cher pour cela.
Méthodologie et philosophie DevOps
La méthodologie peut être théorique et pratique. Dans notre cas, c’est le deuxième. Comme je l'ai mentionné ci-dessus, DevOps est un ensemble de pratiques et de stratégies utilisées pour atteindre des objectifs déclarés. Et dans chaque cas, selon les processus commerciaux de l’entreprise, cela peut différer considérablement. Ce qui ne rend pas les choses meilleures ou pires.
La méthodologie DevOps n'est qu'un moyen d'atteindre des objectifs.
Parlons maintenant de la philosophie DevOps. Et c’est probablement la question la plus difficile.
Il est assez difficile de formuler une réponse courte et succincte, car elle n’a pas encore été formalisée. Et comme les adeptes de la philosophie DevOps sont plus engagés dans la pratique, il n'y a tout simplement pas de temps pour philosopher. Cependant, il s'agit d'un processus très important. De plus, elle est directement liée aux activités d'ingénierie. Il existe même un domaine de connaissance spécialisé - .
Une telle matière n'existait pas dans mon université, j'ai dû tout étudier par moi-même en utilisant les matériaux que je pouvais trouver dans les années 90. Le sujet est facultatif pour la formation d’ingénieur, d’où le manque de formalisation de la réponse. Mais les personnes qui s’immergent sérieusement dans DevOps commencent à ressentir un certain « esprit » ou une « exhaustivité inconsciente » de tous les processus de l’entreprise.
Fort de ma propre expérience, j’ai tenté de formaliser certains des « postulats » de cette philosophie. Le résultat est le suivant :
- DevOps n'est pas quelque chose d'indépendant qui peut être séparé en un domaine de connaissances ou d'activité distinct.
- Tous les employés de l'entreprise doivent être guidés par la méthodologie DevOps lors de la planification de leurs activités.
- DevOps affecte tous les processus au sein d'une entreprise.
- DevOps existe pour réduire les coûts de temps pour tout processus au sein d'une entreprise afin d'assurer le développement de ses services et un confort client maximal.
- DevOps, en langage moderne, est la position proactive de chaque employé de l'entreprise, visant à réduire les coûts de temps et à améliorer la qualité des produits informatiques qui nous entourent.
Je pense que mes « postulats » sont un sujet de discussion distinct. Mais il y a maintenant quelque chose sur lequel bâtir.
Ce que fait DevOps
Le mot clé ici est la communication. Il existe de nombreuses communications dont l'initiateur devrait être exactement le même ingénieur DevOps. Pourquoi donc? Parce qu'il s'agit de philosophie et de méthodologie, et alors seulement de connaissances en ingénierie.
Je ne peux pas parler avec 100 % de confiance du marché du travail occidental. Mais j'en sais beaucoup sur le marché DevOps en Russie. En plus de centaines d'entretiens, j'ai participé au cours de la dernière année et demie à des centaines de préventes techniques pour le service « Implémentation DevOps » pour de grandes entreprises et banques russes.
En Russie, le DevOps est encore un sujet très jeune, mais déjà tendance. Autant que je sache, rien qu'à Moscou, le manque de ces spécialistes en 2019 s'élevait à plus de 1000 2 personnes. Et le mot Kubernetes pour les employeurs ressemble presque à un chiffon rouge pour un taureau. Les adeptes de cet outil sont prêts à l'utiliser même là où cela n'est pas nécessaire et économiquement rentable. L'employeur ne comprend pas toujours dans quels cas ce qu'il est plus approprié d'utiliser, et avec un déploiement approprié, la maintenance d'un cluster Kubernetes coûte 3 à XNUMX fois plus cher que le déploiement d'une application à l'aide d'un schéma de cluster conventionnel. Utilisez-le là où vous en avez vraiment besoin.
La mise en œuvre de DevOps coûte cher en termes d’argent. Et cela n’est justifié que lorsqu’il apporte des avantages économiques dans d’autres domaines, et non en soi.
Les ingénieurs DevOps sont en fait des pionniers : ce sont eux qui devraient être les premiers à mettre en œuvre cette méthodologie dans l'entreprise et à construire des processus. Pour que cela réussisse, le spécialiste doit interagir constamment avec les employés et collègues à tous les niveaux. Comme je le dis habituellement, tous les employés de l'entreprise doivent être impliqués dans le processus de mise en œuvre du DevOps : de la femme de ménage au PDG. Et c'est une condition préalable. Si le membre le plus jeune de l’équipe ne sait pas et ne comprend pas ce qu’est DevOps et pourquoi certaines actions organisationnelles sont effectuées, une mise en œuvre réussie ne fonctionnera pas.
De plus, un ingénieur DevOps doit utiliser une ressource administrative de temps en temps. Par exemple, pour surmonter la « résistance environnementale » - 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 ce faire, il n’a pas besoin d’un ordinateur portable surpuissant sur lequel il déploiera et supportera localement l’ensemble de l’infrastructure du projet. Par exemple, un développeur front-end conserve tous les éléments de l’application sur son ordinateur portable, notamment la base de données, l’émulateur S3 (minio), etc. Autrement dit, il passe beaucoup de temps à entretenir cette infrastructure locale et lutte seul avec tous les problèmes liés à une telle solution. Au lieu de développer du code pour le front. Ces personnes peuvent être très résistantes à tout changement.
Mais il existe des équipes qui, au contraire, sont heureuses d’introduire 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 n'a pas été annulée.
Quand DevOps n'est pas nécessaire
Il existe des situations où DevOps n'est pas nécessaire. C’est un fait : il doit être compris et accepté.
Tout d'abord, cela s'applique à toutes les entreprises (en particulier les petites entreprises) lorsque leur bénéfice 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, nous ne parlons pas du site Internet de l’entreprise, qu’il s’agisse d’une « carte de visite » statique ou avec des blocs d’actualités dynamiques, etc.
DevOps s'impose lorsque la satisfaction de votre client et son envie de revenir vers vous dépendent de la disponibilité de ces services d'information pour l'interaction avec le client, de leur qualité et de leur ciblage.
Un exemple frappant est celui d’une banque bien connue. L'entreprise ne dispose pas de bureaux clients traditionnels, le flux de documents s'effectue par courrier ou par coursier et de nombreux employés travaillent à domicile. L'entreprise a cessé d'être une simple banque et, à mon avis, s'est transformée en une société informatique dotée de technologies DevOps développées.
De nombreux autres exemples et conférences peuvent être retrouvés dans les enregistrements de rencontres et conférences thématiques. J'en ai visité personnellement certains - c'est une expérience très utile pour ceux qui souhaitent évoluer dans cette direction. Voici des liens vers des chaînes YouTube proposant de bonnes conférences et du matériel sur DevOps :
Examinez maintenant votre entreprise et réfléchissez à ceci : dans quelle mesure votre entreprise et ses bénéfices dépendent-ils des produits informatiques pour permettre l'interaction avec les clients ?
Si votre entreprise vend du poisson dans un petit magasin et que le seul produit informatique est constitué de deux configurations 1C : Entreprise (Comptabilité et UNF), alors cela n'a guère de sens de parler de DevOps.
Si vous travaillez dans une grande entreprise commerciale et manufacturière (par exemple, vous produisez des fusils de chasse), vous devriez y penser. Vous pouvez prendre l'initiative et transmettre à votre management les perspectives de mise en œuvre de DevOps. Eh bien, et en même temps, dirigez ce processus. Une position proactive est l'un des principes importants de la philosophie DevOps.
La taille et le volume du chiffre d'affaires financier 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, certains constructeurs automobiles et constructeurs automobiles. Je n'en suis pas sûr maintenant, mais d'après mon expérience passée, pendant de nombreuses années, toutes les interactions avec les clients se faisaient par courrier électronique et par téléphone.
Leurs clients sont une liste limitée de concessionnaires automobiles. Et chacun se voit attribuer un spécialiste du fabricant. Tous les flux de documents internes s'effectuent via SAP ERP. Les collaborateurs internes sont essentiellement des clients du système d’information. Mais ce SI est piloté par les moyens classiques de gestion des systèmes de clusters. Ce qui exclut la possibilité d'utiliser des pratiques DevOps.
D'où la conclusion : pour de telles entreprises, la mise en œuvre de DevOps n'est pas quelque chose d'une importance cruciale, si l'on rappelle les objectifs de la méthodologie dès le début de l'article. Mais je n’exclus pas qu’ils utilisent aujourd’hui certains outils DevOps.
D’un autre côté, de nombreuses petites entreprises développent des logiciels en utilisant la méthodologie, la philosophie, les pratiques et les outils DevOps. Et ils estiment que le coût de mise en œuvre de DevOps est celui qui leur permet d’être compétitifs efficacement sur le marché des logiciels. Des exemples de telles entreprises peuvent être vus .
Le principal critère pour comprendre si DevOps est nécessaire : quelle valeur vos produits informatiques ont pour l'entreprise et les clients.
Si le principal produit générant des bénéfices de l’entreprise est un logiciel, vous avez besoin de DevOps. Et ce n’est pas si important si vous gagnez de l’argent réel en utilisant d’autres produits. Cela inclut également les boutiques en ligne ou les applications mobiles proposant des jeux.
Tous les jeux existent grâce au financement : direct ou indirect des joueurs. Chez Playgendary, nous développons des jeux mobiles gratuits avec plus de 200 personnes directement impliquées dans leur création. Comment utilisons-nous DevOps ?
Oui, exactement la même chose que celle décrite ci-dessus. Je communique constamment avec les développeurs et les testeurs, et dispense des formations internes aux employés sur la méthodologie et les outils DevOps.
Nous utilisons désormais activement Jenkins comme outil de pipelines CI/CD pour exécuter tous les pipelines d'assemblage avec Unity et le déploiement ultérieur sur l'App Store et le Play Market. En savoir plus sur la boîte à outils classique :
- Asana - pour la gestion de projet. L'intégration avec Jenkins a été configurée.
- Google Meet – pour les visioconférences.
- Slack - pour les communications et diverses alertes, y compris les notifications de Jenkins.
- Atlassian Confluence - pour la documentation et le travail de groupe.
Nos plans immédiats incluent l'introduction de l'analyse de code statique à l'aide de SonarQube et la réalisation de tests automatisés d'interface utilisateur à l'aide de Selenium au stade de l'intégration continue.
Au lieu d'une conclusion
Je voudrais terminer par la réflexion suivante : pour devenir un ingénieur DevOps hautement qualifié, il est essentiel d'apprendre à communiquer en direct avec les gens.
Un ingénieur DevOps est un joueur d’équipe. Et rien d'autre. L'initiative de communiquer avec des collègues doit venir de lui et non sous l'influence de certaines circonstances. Un spécialiste DevOps doit voir et proposer la meilleure solution pour l’équipe.
Et oui, la mise en œuvre de toute solution nécessitera de nombreuses discussions et, à la fin, elle pourrait complètement changer. Se développant de manière autonome, proposant et mettant en œuvre ses idées, une telle personne revêt une valeur croissante tant pour l'équipe que pour l'employeur. Ce qui, in fine, se traduit par le montant de sa rémunération mensuelle ou sous forme de primes complémentaires.
Source: habr.com