Qu'est-ce qui est nécessaire pour le succès d'une entreprise IT en 2019 ? Les conférenciers lors de conférences et de meetups lancent beaucoup de mots percutants et pas toujours compréhensibles pour les gens normaux. La bataille pour le temps de déploiement, les microservices, l'abandon du monolithe, la transformation DevOps et encore beaucoup d'autres choses. Si l'on laisse de côté la beauté verbale et que l'on parle clairement, tout se résume à un simple principe : faites un produit de qualité, et faites-le dans le confort de l'équipe.
Cela est devenu critique. Les entreprises ont enfin compris que des processus de développement confortables augmentent la productivité. Et si tout est bien réglé et fonctionne comme sur des roulettes, cela offre également une certaine marge de manœuvre en cas de situations critiques. Autrefois, pour cette marge de manœuvre, un certain homme intelligent a inventé les sauvegardes, mais l'industrie évolue, et nous en sommes venus aux ingénieurs DevOps — des gens qui transforment le processus d'interaction entre le développement et l'infrastructure externe en quelque chose de pertinent et de non lié au chamanisme.
Toute cette histoire de « par module » est magnifique, mais… Il s'avère que certains administrateurs ont été soudainement baptisés DevOps, et des ingénieurs DevOps sont désormais censés posséder, au minimum, des compétences de télépathie et de clairvoyance.
Avant de parler des problèmes modernes d'approvisionnement en infrastructure, définissons ce que nous entendons par ce terme. À l'heure actuelle, la situation a abouti à une dualité de ce concept : l'infrastructure peut être conditionnellement externe et conditionnellement interne.
Par infrastructure externe, nous entendons tout ce qui garantit la fonctionnalité du service ou du produit que l'équipe développe. Cela inclut les serveurs d'application ou de site, . C'est très pratique d'avoir tout au même endroit. Grâce à cela, en cas de problème, nos spécialistes vous aideront à le résoudre dans les plus brefs délais. et d'autres services assurant la fonctionnalité du produit.
L'infrastructure interne comprend les services et équipements utilisés par l'équipe de développement elle-même et d'autres employés, qui sont généralement également nombreux. Cela inclut les serveurs internes de systèmes de stockage de code, un gestionnaire de tâches déployé localement, et tout ce qui existe dans le cadre de l'intranet de l'entreprise.
Que fait un administrateur système dans une entreprise ? En plus de l’administration de l’intranet d’entreprise, il s’occupe souvent de l’équipement de bureau pour en assurer le bon fonctionnement. L'admin est ce gars qui amène rapidement un nouvel ordinateur fixe ou un ordinateur portable de secours prêt à l'emploi, fournit un nouveau clavier et rampe dans les bureaux en tirant un câble Ethernet. L'admin est le maître et le souverain local, non seulement des systèmes internes et externes, serveurs, mais aussi des équipements. Oui, certains administrateurs peuvent travailler uniquement sur la partie système, sans matériel. Ils devraient être classés comme un sous-groupe distinct « d'administrateurs systèmes d'infrastructure ». D'autres se spécialisent dans l'entretien exclusif de l'équipement de bureau, d'autant plus que dans une entreprise de plus de cent personnes, le travail ne s'arrête jamais. Mais ni les premiers ni les seconds ne sont des DevOps.
Qui sont les DevOps ? Les DevOps sont des professionnels qui s'occupent de l'interaction entre le développement de logiciels et l'infrastructure externe. Plus précisément, les DevOps modernes sont bien plus impliqués dans les processus de développement et de déploiement que ne l'ont jamais été les administrateurs, qui se contentaient de télécharger des mises à jour sur un serveur FTP. L'une des principales tâches d'un ingénieur DevOps aujourd'hui est d'assurer un processus d'interaction fluide et efficace entre les équipes de développement et l'infrastructure du produit. Ce sont ces personnes qui sont responsables du déploiement des systèmes de retour en arrière et de déploiement, qui allègent une partie de la charge des développeurs et se concentrent au maximum sur leur tâche extrêmement importante. Cependant, un DevOps ne tirera jamais un nouveau câble ni ne sortira un nouvel ordinateur portable d'un stockage (c) K.O.
Quelle est la ruse ?
La question «Qu'est-ce que DevOps ?» fait que la moitié des employés du secteur commencent à répondre quelque chose comme «Eh bien, c'est, en gros, un administrateur qui…» et ainsi de suite. Oui, autrefois, lorsque la profession d'ingénieur DevOps émergeait à peine des admins les plus talentueux en matière de service, les différences entre eux n'étaient pas évidentes pour tout le monde. Mais maintenant, lorsque les fonctions du DevOps et de l'admin dans l'équipe diffèrent radicalement, les confondre ou même les égaliser est inacceptable.
Mais que cela signifie-t-il pour les affaires ?
Le recrutement, tout est là.
Vous ouvrez une offre d'emploi «Administrateur système», et là, les exigences énumérées sont «interaction avec les développeurs et les clients», «système de livraison CI/CD», «maintenance des serveurs et du matériel de l'entreprise», «administration des systèmes internes», etc. Vous comprenez que l'employeur dit n'importe quoi. Le hic est que le titre de l'offre d'emploi devrait être «Ingénieur DevOps», et si ce titre est changé, alors tout devient clair.
Cependant, quelle impression est donnée à la lecture d'une telle offre ? Que l'entreprise recherche un homme à tout faire qui peut déployer à la fois un système de contrôle de version et de monitoring, et serrer une bouteille avec les dents…
En fait, pour ne pas aggraver la situation sur le marché du travail, il suffit de nommer les offres d'emploi par leur vrai nom et de bien comprendre que l'ingénieur DevOps et l'administrateur système sont deux entités différentes. Mais le désir insatiable de certains employeurs d'imposer une liste d'exigences aussi large que possible conduit à ce que les «classiques» administrateurs systèmes ne comprennent plus ce qui se passe autour d'eux. Qu'est-ce que, la profession muté et ils ont pris du retard ?
Non, non et encore une fois non. Les administrateurs d'infrastructure qui géreront les serveurs internes de l'entreprise, ou occuperont des postes de support L2/L3 et aideront d'autres employés, n'ont pas disparu et ne comptent pas disparaître.
Ces spécialistes peuvent-ils devenir des ingénieurs DevOps ? Bien sûr, ils le peuvent. En fait, c'est un environnement connexe qui nécessite des compétences en administration système, mais en plus, cela inclut la gestion de la surveillance, des systèmes de livraison et, de manière générale, une interaction étroite avec l'équipe de développement et de test.
Un autre problème de DevOps
En réalité, tout ne se limite pas à l'embauche et à la confusion constante entre administrateurs et DevOps. À un moment donné, l'entreprise a été confrontée à un problème de livraison de mises à jour et d'interaction entre l'équipe de développement et l'infrastructure finale.
C'est peut-être à ce moment-là qu'un oncle avec des yeux brillants a pris la parole sur la scène d'une conférence et a dit : « Regardez comment nous faisons cela et nous appelons ça DevOps. Ces gars-là résoudront tous vos problèmes » - et a commencé à expliquer à quel point la vie est bonne dans l'entreprise après l'adoption des pratiques DevOps.
Cependant, il ne suffit pas d'embaucher un ingénieur DevOps pour que tout fonctionne « comme il se doit ». L'entreprise doit complètement passer par une transformation DevOps, c'est-à-dire que le rôle et les capacités de notre DevOps doivent également être clairement compris du côté de l'équipe de développement et de test du produit. À ce sujet, nous avons une « belle » histoire qui illustre pleinement toute l'horreur qui se produit parfois.
Situation. A DevOps engineer is asked to set up a version rollback system without delving into how it will work. Suppose that within the Users system there are separate fields for first name, last name, and password. A new product version is released, but for the developers, the 'rollback' is just a magic wand that fixes everything, and they have no idea how it operates. For example, the developers merged the first name and last name fields in a recent patch, deployed it to production, and the version starts to lag for some reason. What happens? Management approaches the DevOps engineer and says, 'Pull the switch!', meaning they ask him to revert to the previous version. What does the DevOps engineer do? He rolls back to the previous version, but since the developers didn't want to figure out how to perform this rollback, no one informed him that the database also needed to be rolled back. As a result, everything crashes, and users see a '500' error instead of the lagging site because the old version is incompatible with the new database fields. The DevOps engineer is unaware of this. The developers remain silent. Management begins to lose their nerves and money and recalls the backups, suggesting they revert with them to get at least something working. Consequently, users lose all their data for a certain period.
Naturally, the DevOps engineer takes the heat for 'not having set up the proper rollback system,' while the developers, who are the real culprits in this story, go unscathed.
The conclusion is simple: without a proper approach to DevOps as such, there's not much benefit from it.
The main thing to remember is that a DevOps engineer is not a magician, and without quality communication and mutual interaction with the development team, he won't be able to handle his tasks. DevOps engineers shouldn't be left alone with their 'problems' or given the order 'don't interfere with the developers, their job is to code,' and then expect everything to work as it should in a critical moment. That's just not how it works.
En réalité, le DevOps représente des compétences à la frontière entre la gestion et la technologie. Et il n'est pas du tout évident que dans ce cocktail technologique, la gestion doit être moins prépondérante que la technologie. Si vous souhaitez vraiment construire des processus de développement plus rapides et plus efficaces, vous devez faire confiance à votre DevOps. Il connaît les outils nécessaires, a mis en œuvre des projets similaires et sait comment faire. Aidez-le, écoutez ses conseils, ne cherchez pas à l'isoler dans une unité autonome. Si les administrateurs peuvent travailler de manière indépendante, les DevOps, dans ce cas, deviennent inutiles, car ils ne pourront pas vous aider à vous améliorer si vous ne voulez pas accepter cette aide.
Et enfin, un dernier point : cessez de dénigrer les administrateurs d'infrastructure. Ils ont leur propre front de travail, qui est extrêmement important. Oui, un administrateur peut devenir ingénieur DevOps, mais cela doit se faire par son propre désir, et non sous contrainte. Il n'y a rien de mal à ce qu'un administrateur système souhaite rester administrateur système — c'est une profession distincte et son droit. Si l'envie de se transformer professionnellement existe, il ne faut en aucun cas oublier que le développement ne doit pas uniquement porter sur les compétences techniques, mais également sur les compétences en gestion. Il est probable que ce soit à vous, en tant que responsable, de rassembler toutes ces personnes et de leur apprendre à communiquer dans un langage commun.
Source : habr.com
