Que faut-il pour qu’une entreprise informatique réussisse en 2019 ? Les conférenciers lors de conférences et de rencontres prononcent beaucoup de mots forts qui ne sont pas toujours compréhensibles pour les gens normaux. La lutte pour le temps de déploiement, les microservices, l'abandon du monolithe, la transformation DevOps et bien plus encore. Si nous abandonnons la beauté verbale et parlons directement et en russe, alors tout se résume à une thèse simple : fabriquer un produit de haute qualité et le faire avec le confort de l'équipe.
Ce dernier est devenu d’une importance cruciale. Les entreprises sont finalement arrivées à la conclusion qu'un processus de développement confortable augmente la productivité et que si tout est débogué et fonctionne comme une horloge, cela donne également une certaine marge de manœuvre dans les situations critiques. Il était une fois, pour cette manœuvre, une certaine personne intelligente a proposé des sauvegardes, mais l'industrie se développe et nous sommes tombés sur des ingénieurs DevOps - des gens qui transforment le processus d'interaction entre le développement et l'infrastructure externe en quelque chose d'adéquat et sans rapport avec le chamanisme.
Toute cette histoire « modulaire » est merveilleuse, mais... Il se trouve que certains administrateurs ont été brusquement surnommés DevOps, et les ingénieurs DevOps eux-mêmes ont commencé à devoir avoir au moins des compétences de télépathie et de clairvoyance.
Avant de parler des problèmes modernes liés à la fourniture d'infrastructures, définissons ce que nous entendons par ce terme. À l'heure actuelle, la situation a évolué de telle manière que nous sommes arrivés à la dualité de ce concept : l'infrastructure peut être conditionnellement externe et conditionnellement interne.
Par infrastructure externe, nous entendons tout ce qui assure la fonctionnalité du service ou du produit que l'équipe développe. Il s'agit de serveurs d'applications ou de sites Web, d'hébergement et d'autres services qui assurent la fonctionnalité du produit.
L'infrastructure interne comprend des services et des équipements qui sont utilisés par l'équipe de développement elle-même et par d'autres employés, généralement nombreux. Ce sont des serveurs internes des systèmes de stockage de code, un gestionnaire de tâches déployé localement et tout, tout, tout ce qui existe au sein de l'intranet de l'entreprise.
Que fait un administrateur système dans une entreprise ? En plus du travail d'administration de cet intranet d'entreprise, il supporte souvent le fardeau des préoccupations économiques pour assurer le fonctionnement des équipements de bureau. L'administrateur est le même gars qui fera rapidement glisser une nouvelle unité centrale ou un ordinateur portable de rechange prêt à l'emploi depuis l'arrière-boutique, distribuera un nouveau clavier et rampera à quatre pattes dans les bureaux, en étirant le câble Ethernet. Un administrateur est un propriétaire local et un dirigeant non seulement de serveurs internes et externes, mais également un dirigeant d'entreprise. Oui, certains administrateurs ne peuvent travailler que dans le plan système, sans matériel. Ils devraient être séparés en une sous-classe distincte d’« administrateurs système d’infrastructure ». Et certains se spécialisent dans l'entretien exclusivement du matériel de bureau ; heureusement, si l'entreprise compte plus d'une centaine de personnes, le travail ne s'arrête jamais. Mais aucun d’eux n’est développeur.
Qui sont les DevOps ? Les Devops sont des gars qui parlent de l'interaction du développement logiciel avec l'infrastructure externe. Plus précisément, les développeurs modernes sont impliqués dans les processus de développement et de déploiement bien plus profondément que les administrateurs qui téléchargent simplement les mises à jour sur FTP ne l'ont jamais été. L'une des tâches clés d'un ingénieur DevOps est désormais d'assurer un processus d'interaction confortable et efficacement structuré entre les équipes de développement et l'infrastructure produit. Ce sont ces personnes qui sont responsables du déploiement des systèmes de restauration et de déploiement, ce sont ces personnes qui soulagent une partie de la charge des développeurs et se concentrent autant que possible sur leur tâche extrêmement importante. Dans le même temps, les développeurs n'exécuteront jamais de nouveau câble ni ne délivreront un nouvel ordinateur portable depuis l'arrière-boutique (c) KO
Quelle est la prise?
À la question « Qui est DevOps ? » la moitié des travailleurs sur le terrain commencent à répondre quelque chose comme "Eh bien, bref, c'est l'administrateur qui..." et plus loin dans le texte. Oui, il était une fois, alors que le métier d'ingénieur DevOps émergeait à peine des administrateurs les plus talentueux en termes de maintenance de services, les différences entre eux n'étaient pas évidentes pour tout le monde. Mais maintenant, alors que les fonctions de devops et d'administrateur dans l'équipe sont devenues radicalement différentes, il est inacceptable de les confondre, voire de les assimiler.
Mais qu’est-ce que cela signifie pour les entreprises ?
L'embauche, c'est tout.
Vous ouvrez un poste vacant pour « Administrateur système », et les exigences qui y sont répertoriées sont « l'interaction avec le développement et les clients », « le système de livraison CI/CD », « la maintenance des serveurs et des équipements de l'entreprise », « l'administration des systèmes internes », etc. sur; vous comprenez que l'employeur dit des bêtises. Le problème est qu'au lieu de « Administrateur système », le titre du poste vacant devrait être « Ingénieur DevOps », et si ce titre est modifié, alors tout se met en place.
Cependant, quelle impression a-t-on en lisant une telle offre d’emploi ? Que l'entreprise recherche un opérateur multi-machines qui déploiera à la fois un système de contrôle de version et de surveillance et serrera le twister avec ses dents...
Mais pour ne pas augmenter le degré de toxicomanie sur le marché du travail, il suffit d'appeler les postes vacants par leur nom propre et de bien comprendre qu'un ingénieur DevOps et un administrateur système sont deux entités différentes. Mais la volonté irrépressible de certains employeurs de présenter à un candidat la liste d'exigences la plus large possible conduit au fait que les administrateurs système « classiques » cessent de comprendre ce qui se passe autour d'eux. Quoi, le métier est en train de muter et ils sont en retard ?
Non non et encore une fois non. Les administrateurs d’infrastructures qui géreront les serveurs internes de l’entreprise, ou occuperont des postes de support L2/L3 et aideront d’autres collaborateurs, ne sont pas partis et ne vont pas disparaître.
Ces spécialistes peuvent-ils devenir des ingénieurs DevOps ? Bien sûr qu’ils le peuvent. En fait, il s'agit d'un environnement connexe qui nécessite des compétences en administration système, mais à cela s'ajoute le travail avec les systèmes de surveillance, de livraison et, en général, une interaction étroite avec l'équipe de développement et de test.
Un autre problème DevOps
En fait, tout ne se limite pas au simple recrutement et à la confusion constante entre administrateurs et développeurs. À un moment donné, l'entreprise a été confrontée au problème de la fourniture des mises à jour et de l'interaction de l'équipe de développement avec l'infrastructure finale.
C'est peut-être lorsqu'un oncle aux yeux pétillants s'est levé sur la scène d'une conférence et a déclaré : « Nous faisons cela et appelons cela DevOps. Ces gars résoudront tous vos problèmes » - et a commencé à raconter à quel point la vie est belle dans l'entreprise après la mise en œuvre 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 subir une transformation DevOps complète, 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 des produits. Nous avons une « merveilleuse » histoire sur ce sujet qui illustre pleinement toute la brutalité qui se produit dans certains endroits.
Situation. DevOps est nécessaire pour déployer un système de restauration de version sans vraiment se pencher sur son fonctionnement. Supposons que dans le système Utilisateurs, il existe des champs distincts pour le prénom, le nom et le mot de passe. Une nouvelle version du produit sort, mais pour les développeurs, un « rollback » n'est qu'une baguette magique qui va tout arranger, et ils ne savent même pas comment cela fonctionne. Ainsi, par exemple, dans le prochain patch, les développeurs ont combiné les champs prénom et nom et l'ont mis en production, mais la version est lente pour une raison quelconque. Ce qui se passe? La direction s'adresse aux développeurs et leur dit « Appuyez sur l'interrupteur ! », c'est-à-dire qu'elle lui demande de revenir à la version précédente. Que fait DevOps ? Il revient à la version précédente, mais comme les développeurs ne voulaient pas comprendre comment cette restauration avait été effectuée, personne n'a dit à l'équipe de développement que la base de données devait également être restaurée. En conséquence, tout plante pour nous, et au lieu d'un site Web lent, les utilisateurs voient une erreur « 500 », car l'ancienne version ne fonctionne pas avec les champs de la nouvelle base de données. Devops n'est pas au courant. Les développeurs restent silencieux. La direction commence à perdre ses nerfs et son argent et se souvient des sauvegardes, proposant de les annuler pour qu '«au moins quelque chose fonctionne». En conséquence, les utilisateurs perdent toutes leurs données au fil du temps.
Les noix, bien sûr, vont aux développeurs, qui « n’ont pas créé un système de restauration approprié », et personne ne se soucie du fait que les élans dans cette histoire sont des développeurs.
La conclusion est simple : sans une approche normale du DevOps en tant que tel, il ne sert à rien.
La principale chose à retenir : un ingénieur DevOps n'est pas un magicien, et sans communication de qualité et sans interaction bidirectionnelle avec le développement, il ne fera pas face à ses tâches. Les développeurs ne peuvent pas être laissés seuls avec leurs « problèmes » ou recevoir l’ordre « ne vous mêlez pas des développeurs, leur travail est de coder », puis espérer qu’à un moment critique, tout fonctionnera comme il se doit. Ce n'est pas comme ça que ça marche.
Essentiellement, DevOps est une compétence à la frontière entre la gestion et la technologie. Par ailleurs, il est loin d’être évident qu’il y ait plus de technologie que de management dans ce cocktail. Si vous souhaitez vraiment créer des processus de développement plus rapides et plus efficaces, vous devez faire confiance à votre équipe de développement. Il connaît les bons outils, il a mis en place des projets similaires, il sait comment le faire. Aidez-le, écoutez ses conseils, n'essayez pas de l'isoler dans une sorte d'unité autonome. Si les administrateurs peuvent travailler seuls, alors les développeurs sont inutiles dans ce cas : ils ne pourront pas vous aider à devenir meilleur si vous ne souhaitez pas vous-même accepter cette aide.
Et une dernière chose : arrêtez d’offenser les administrateurs d’infrastructure. Ils ont leur propre front de travail extrêmement important. Oui, un administrateur peut devenir ingénieur DevOps, mais cela doit se faire à la demande de la personne elle-même, et non sous pression. Et il n'y a rien de mal à ce qu'un administrateur système veuille rester administrateur système - c'est sa profession distincte et son droit. Si vous souhaitez entreprendre une transformation professionnelle, il ne faut jamais oublier que vous devrez développer non seulement des compétences technologiques, mais aussi des compétences managériales. Très probablement, ce sera à vous, en tant que leader, de rassembler toutes ces personnes et de leur apprendre à communiquer dans la même langue.
Source: habr.com