Get best of the week

Qui est DevOps et quand n'est-il pas nécessaire



Le thème DevOps est devenu très populaire au cours des dernières années. Beaucoup rêvent de le rejoindre, mais, comme le montre la pratique, souvent uniquement en raison du niveau des salaires.

Certains indiquent DevOps dans leur CV, bien qu'ils ne connaissent pas et ne comprennent pas toujours l'essence du terme. Quelqu'un pense qu'après avoir étudié Ansible, GitLab, Jenkins, Terraform et autres (la liste peut être prolongée à votre convenance), il deviendra immédiatement un «devoop». Ce n'est bien sûr pas le cas.

Au cours des dernières années, j'ai été principalement impliquée dans la mise en œuvre de DevOps dans diverses entreprises. Avant cela, il a travaillé pendant plus de 20 ans dans des postes d'administrateur système à directeur informatique. Maintenant - DevOps Lead Engineer sur Playgendary.

Qui est DevOps


L'idée d'écrire un article est venue après une autre question: "qui est DevOps?". Il n'y a toujours pas de terme établi de quoi ou de qui il s'agit. Certaines des réponses figurent déjà dans cette vidéo . Tout d'abord, j'en soulignerai les principaux points, puis je partagerai mes observations et réflexions.

DevOps n'est pas un spécialiste que vous pouvez embaucher, ni un ensemble d'utilitaires, ni un service de développement 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, pour connecter et intégrer les processus de travail les uns dans les autres.

Avec l'avènement 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é. Brouillé les frontières entre les départements.

Les objectifs de DevOps peuvent être décrits de trois manières:

  • Le logiciel doit être mis à jour régulièrement.
  • Le logiciel doit être fait rapidement.
  • Le logiciel doit être déployé de manière pratique et en peu de temps.

DevOps n'a pas un seul outil. La configuration, la livraison et l'exploration de plusieurs produits ne signifie pas que DevOps est apparu dans l'entreprise. Il existe de nombreux outils et chacun est impliqué à différentes étapes, mais ils servent un objectif commun.


Et ceci n'est qu'une partie des outils DevOps.

Depuis plus de 2 ans, j'interroge des personnes pour le poste d'ingénieur DevOps et j'ai réalisé à quel point il est important de comprendre clairement l'essence du terme. J'ai accumulé des expériences, des observations et des pensées spécifiques que je veux partager.

De l'expérience de l'entretien, je vois l'image suivante: les spécialistes qui considèrent le DevOps comme un travail ont généralement des malentendus avec leurs collègues .

Il y avait un exemple frappant. Un jeune homme est venu à l'entrevue avec un tas de mots intelligents dans le curriculum vitae. Dans les trois derniers lieux de travail, il avait 5-6 mois d'expérience. Il a quitté deux startups parce qu’elles «n’ont pas décollé». Mais en ce qui concerne la troisième société, il a déclaré que personne ne le comprenait: les développeurs écrivent du code sur Windows, et le directeur force ce code à être «enveloppé» dans un Docker ordinaire et intégré dans un pipeline CI / CD. Le gars a dit beaucoup de choses négatives sur son emploi actuel et ses collègues - je voulais répondre: "Donc, vous ne vendrez pas l'éléphant."

Ensuite, je lui ai posé une question, qui est l'une des premières de ma liste pour chaque candidat.

- Que signifie DevOps pour vous personnellement?
- Généralement ou comment le perçois-je?

J'étais intéressé par son opinion personnelle. Il connaissait la théorie et l'origine du terme, mais était fortement en désaccord avec eux. Il pensait que DevOps était un poste. C'est là que réside la racine de ses problèmes. Comme d'autres professionnels ayant la même opinion.

Les employeurs, ayant entendu parler de la "magie des DevOps", veulent trouver une personne qui viendra créer cette "magie". Et les candidats de la catégorie "DevOps - cette position" ne comprennent pas qu'avec cette approche, ils ne pourront pas répondre aux attentes. Et, en général, DevOps a écrit dans leur CV, car c'est une tendance et ils paient beaucoup pour cela.

DevOps Méthodologie et Philosophie


La méthodologie est théorique et pratique. Dans notre cas, le second. Comme je l'ai mentionné ci-dessus, DevOps est un ensemble de pratiques et de stratégies utilisées pour atteindre les objectifs fixés. Et dans chaque cas, selon les processus commerciaux de l'entreprise, cela peut différer considérablement. Ce qui ne le rend ni meilleur ni pire.

La méthodologie DevOps n'est qu'un moyen d'atteindre vos objectifs.

Maintenant, quelle est la philosophie de 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 puisque 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, c'est un processus très important. Et directement lié aux activités d'ingénierie. Il existe même un domaine de connaissances spécialisé - la philosophie de la technologie .

Dans mon université, il n'y avait pas une telle matière, j'ai dû tout étudier moi-même sur la base de 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 ces gens qui sont sérieusement plongés dans DevOps, commencent à ressentir une sorte d '«esprit» ou «exhaustivité inconsciente» de tous les processus de l'entreprise.

J'ai essayé de formaliser certains des "postulats" de cette philosophie. Il s'est avéré ce qui suit:

  • DevOps n'est pas quelque chose d'indépendant, qui peut être distingué dans un domaine distinct de connaissances ou d'activités.
  • La méthodologie DevOps doit être guidée par tous les employés de l'entreprise qui planifient leurs activités.
  • DevOps affecte tous les processus au sein de l'entreprise.
  • DevOps existe pour réduire le temps consacré à tous les processus au sein de l'entreprise afin d'assurer le développement de ses services et un confort client maximum.
  • DevOps, dans un 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 maintenant, il y a quelque chose à construire.

Que fait DevOps


Le mot clé ici est la communication. Il y a beaucoup de communications dont l'initiateur devrait être l'ingénieur très DevOps. Pourquoi donc? Parce que c'est de la philosophie et de la méthodologie, et alors seulement des connaissances en ingénierie.

Je ne peux pas parler du marché du travail occidental avec 100% de certitude. Mais je connais beaucoup le marché DevOps en Russie. En plus des centaines d'entretiens, au cours de la dernière année et demie, j'ai participé à des centaines de préventes techniques pour le service «Implémentation de DevOps» pour les grandes entreprises et banques russes.

En Russie, DevOps est encore un sujet très jeune, mais déjà tendance. Pour autant que je sache, ce n'est qu'à Moscou que la pénurie de tels spécialistes en 2019 s'élevait à plus de 1000 personnes. Et le mot Kubernetes pour les employeurs est presque comme un chiffon rouge pour un taureau. Les adeptes de cet outil sont prêts à l'utiliser même s'il n'est pas nécessaire et économiquement viable. Un employeur ne comprend pas toujours dans quels cas il est plus approprié de l'utiliser, et avec un déploiement approprié, la maintenance d'un cluster Kubernetes est 2-3 fois plus coûteuse 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 en termes d'argent coûte cher. Et elle n'est justifiée que lorsqu'elle apporte des avantages économiques dans d'autres domaines, et non en elle-même.

Les ingénieurs DevOps sont en fait des pionniers - ils sont les premiers à introduire cette méthodologie dans l'entreprise et à construire des processus. Pour que cela réussisse, le spécialiste doit constamment interagir avec les employés et les 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 de DevOps: d'une femme de ménage à un PDG. Et c'est une condition préalable. Si le plus jeune membre de l'équipe ne sait pas et ne comprend pas ce qu'est DevOps et pourquoi certaines actions organisationnelles sont effectuées, une implémentation réussie échouera.

De plus, l'ingénieur DevOps doit utiliser de temps à autre une ressource administrative. Par exemple, surmonter la «résistance de l'environnement» - lorsque l'équipe n'est pas prête à accepter les outils et la méthodologie de 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 super puissant sur lequel il déploiera et supportera localement l'ensemble de l'infrastructure du projet. Par exemple, le front-end conserve sur votre ordinateur portable tous les éléments de l'application, y compris la base de données, l'émulateur S3 (minio) et plus encore. Autrement dit, il passe beaucoup de temps à entretenir cette infrastructure locale et se débat seul avec tous les problèmes d'une telle solution. Au lieu de développer du code pour le front. Ces personnes peuvent fortement résister à tout changement.

Mais il y a des équipes qui, au contraire, sont heureuses de présenter de nouveaux outils et méthodes, et sont activement impliquées dans ce processus. Bien que même dans ce cas, la communication entre l'ingénieur DevOps et l'équipe n'a pas été annulée.

Lorsque 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 à toute entreprise (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 qui fournissent des services d'information aux clients. Et ici, nous ne parlons pas du site Web de l'entreprise, qu'il s'agisse d'une "carte de visite" statique ou de blocs d'actualités dynamiques, etc.

DevOps est requis lorsque la satisfaction de votre client et son désir de revenir vers vous dépendent de la disponibilité 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. L'entreprise ne dispose pas des bureaux habituels des clients, le flux de travail est effectué par courrier ou par messagerie 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 entreprise informatique dotée de technologies DevOps développées.

De nombreux autres exemples et conférences peuvent être trouvés dans les enregistrements de réunions et conférences thématiques. J'ai personnellement visité certains d'entre eux - c'est une expérience très utile pour ceux qui veulent évoluer dans ce sens. 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 de produits informatiques qui permettent une 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 UNF), il n'est guère logique de parler de DevOps.

Si vous travaillez dans une grande entreprise commerciale et industrielle (par exemple, produisez des fusils de chasse), cela vaut la peine d'être considéré. Vous pouvez prendre l'initiative et transmettre à votre direction les perspectives de mise en œuvre de DevOps. Eh bien, en même temps, dirigez ce processus. Une attitude proactive est l'un des postulats importants de la philosophie DevOps.

La taille et le volume du chiffre d'affaires financier annuel ne sont pas le critère principal pour déterminer si votre entreprise a besoin de DevOps.

Imaginez une grande entreprise industrielle qui n'interagit pas directement avec les clients. Par exemple, certains constructeurs automobiles et entreprises automobiles. Maintenant, je ne suis pas sûr, mais, d'après mon expérience passée, pendant de nombreuses années, toutes les interactions avec les clients ont été effectuées par courrier électronique et par téléphone.

Leurs clients sont une liste limitée de concessionnaires automobiles. Et un spécialiste du fabricant est attaché à chacun. Tout le flux de travail interne se produit via SAP ERP. Les employés internes sont en effet des clients du système d'information. Mais la gestion de cette IP s'effectue par des moyens classiques de gestion des systèmes de cluster. Ce qui exclut la possibilité d'utiliser les pratiques DevOps.

D'où la conclusion: pour ces entreprises, la mise en œuvre de DevOps n'est pas quelque chose d'important, si nous rappelons les objectifs de la méthodologie depuis le début de l'article. Mais je n'exclue pas que certains outils DevOps soient utilisés par eux aujourd'hui.

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 croient que les coûts de mise en œuvre de DevOps sont des coûts qui leur permettent de rivaliser efficacement sur le marché des logiciels. Des exemples de telles entreprises peuvent être vus ici .

Le critère principal pour comprendre si DevOps est nécessaire: l'importance de vos produits informatiques pour l'entreprise et les clients.

Si le principal produit rentable de l'entreprise est le logiciel, vous avez besoin de DevOps. Et ce n'est pas si important si vous gagnez de l'argent réel avec l'aide d'autres biens. Cela inclut également les magasins en ligne ou les applications mobiles avec des jeux.

Tous les jeux existent grâce au financement: direct ou indirect des joueurs. Chez Playgendary, nous développons des jeux mobiles gratuits dans lesquels plus de 200 personnes sont directement impliquées. Comment utilisons-nous DevOps?

Oui, comme décrit ci-dessus. Je communique constamment avec les développeurs et les testeurs, mène des formations internes pour le personnel et les outils de méthodologie DevOps.

Maintenant, nous utilisons activement Jenkins comme outil de pipelines CI / CD pour exécuter tous les pipelines d'assemblage avec Unity, puis déployer sur l'App Store et Play Market. Plus de la boîte à outils classique:

  • Asana - pour la gestion de projet. Intégration configurée avec Jenkins.
  • Google Meet - pour les appels vidéo.
  • Slack - pour les communications et diverses alertes, y compris les notifications de Jenkins.
  • Atlassian Confluence - pour la documentation et le travail de groupe.

Dans un avenir proche, nous introduirons l'analyse de code statique à l'aide de SonarQube et effectuerons des tests d'interface utilisateur automatisés avec les outils Selenium au stade de l'intégration continue.

Au lieu d'une conclusion


Je veux terminer avec la pensée suivante: pour devenir un ingénieur DevOps de haute qualification, il est essentiel d'apprendre à communiquer de manière vivante avec les gens.

L'ingénieur DevOps est un joueur d'équipe. Et pas d'autre moyen. L'initiative de communiquer avec des collègues doit venir de lui-même et ne pas être influencée par des circonstances. Le spécialiste DevOps doit voir et proposer la meilleure solution pour l'équipe.

Et oui, la mise en œuvre de toute solution nécessitera beaucoup de discussions et, à la fin, elle pourrait même changer. En développant, en offrant et en mettant en œuvre leurs idées de manière indépendante, une telle personne est d'une valeur croissante à la fois pour l'équipe et pour l'employeur. Ce qui, au final, se traduit par le montant de sa rémunération mensuelle ou sous forme de bonus supplémentaires.

More articles:


All Articles