De quoi a-t-on besoin pour réussir une entreprise informatique en 2019? Les conférenciers des konfs et des mitaps parlent beaucoup de mots forts et pas toujours clairs aux gens normaux. La lutte pour le déploiement, les microservices, le rejet du monolithe, la transformation DevOps et bien plus encore. Si vous vous débarrassez de la beauté verbale et parlez directement et en russe, tout se résume à une thèse simple: fabriquer un produit de qualité, et le faire avec confort pour l'équipe.
Ce dernier est devenu extrêmement important. Les entreprises sont finalement parvenues à la conclusion qu'un processus de développement confortable améliore la productivité, et si tout est débogué et fonctionne comme sur des roulettes, il donne également une certaine marge de manœuvre dans les situations critiques. Une fois, pour cette manœuvre, une personne intelligente a inventé des sauvegardes, mais l'industrie se développe, et nous sommes venus aux ingénieurs DevOps - des personnes qui transforment le processus d'interaction entre le développement et l'infrastructure externe en quelque chose d'adéquat et non lié au chamanisme.
Toute l'histoire de "modulo" est belle, mais ... Il se trouve qu'une partie des administrateurs ont été brutalement surnommés DevOps, et les ingénieurs DevOps eux-mêmes ont commencé à exiger au moins des compétences en télépathie et en clairvoyance.
Avant de parler des problèmes modernes de fourniture d'infrastructures, décidons de ce que nous entendons par ce terme. À ce jour, la situation a évolué de telle manière que nous avons atteint la dualité de ce concept: l'infrastructure peut être conditionnellement externe et conditionnellement interne.
Une infrastructure externe doit signifier tout ce qui garantit la facilité de service d'un service ou d'un produit que l'équipe développe. Il s'agit de serveurs d'applications ou de sites, d'hébergement et d'autres services qui garantissent les performances 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 nombreux. Ce sont des serveurs internes de systèmes de stockage de code, un gestionnaire de tâches déployé localement et tout-tout-tout qui existe dans l'intranet de l'entreprise.
Que fait l'administrateur système dans l'entreprise? En plus d'administrer cet intranet d'entreprise lui-même, il impose souvent le fardeau des soucis économiques pour assurer la disponibilité du matériel de bureau. L'administrateur est le même gars qui traîne rapidement une nouvelle unité centrale hors de l'arrière-salle ou un ordinateur portable de rechange prêt à travailler, donne un nouveau clavier et rampe à quatre pattes dans les bureaux, étirant le câble Ethernet. L'administrateur est le propriétaire local et maître non seulement des 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 doivent être distingués dans une sous-classe distincte des «administrateurs de système d'infrastructure». Et quelqu'un se spécialise dans l'entretien de matériel de bureau exclusivement, heureusement, si l'entreprise compte plus d'une centaine de personnes, le travail ne s'arrête jamais. Mais ni l'un ni l'autre ne le sont.
Et 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 beaucoup plus profondément que les administrateurs qui ont simplement inondé les mises à jour sur ftp n'ont jamais été impliqués. L'une des tâches clés de l'ingénieur DevOps est désormais d'assurer un processus d'interaction confortable 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 rollback et de déploiement, ce sont ces personnes qui prennent 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 devops n'allongeront jamais un nouveau câble ou ne distribueront pas un nouvel ordinateur portable dans l'arrière-salle (s)
Quelle est la prise?
À la question "Qui est DevOps?" la moitié des employés de la sphère commencent à répondre par quelque chose comme "Eh bien, c'est, en bref, un tel administrateur qui ..." et ci-après. Oui, il était une fois, alors que la profession d'ingénieur DevOps commençait à peine par les administrateurs les plus talentueux en termes de service, les différences entre eux n'étaient pas évidentes pour tout le monde. Mais maintenant, lorsque les fonctions des devops et des administrateurs dans l'équipe ont commencé à différer radicalement, les confondre entre elles, ou même mettre un signe égal entre elles, est inacceptable.
Mais qu'est-ce que cela signifie pour les entreprises?
L'embauche, c'est tout pour lui.
Vous ouvrez le poste vacant «Administrateur système», et là les exigences sont répertoriées: «interaction avec le développement et les clients», «Système de livraison CI / CD», «entretien des serveurs et des équipements de l'entreprise», «administration des systèmes internes» et ainsi de suite; vous comprenez que l'employeur porte un non-sens. Le hic est qu'au lieu de "Administrateur système" dans le titre du poste vacant devrait être "DevOps-ingénieur", et si ce titre est modifié, alors tout se met en place.
Cependant, quelle impression se crée en lisant un tel poste? Que l'entreprise est à la recherche d'un opérateur multi-outils, qui déploiera à la fois un système de contrôle et de surveillance des versions et secouera les dents 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 leurs noms propres et de bien comprendre que l'ingénieur DevOps et l'administrateur système sont deux entités différentes. Le seul désir irrépressible de certains employeurs de présenter au candidat la liste d'exigences la plus large possible conduit au fait que les administrateurs de systèmes «classiques» cessent de comprendre ce qui se passe autour d'eux. Quoi, la profession mute et ils sont en retard sur la vie?
Non, non et encore une fois. Les administrateurs d'infrastructure qui dirigeront les serveurs internes de l'entreprise, ou occuperont les postes de support L2 / L3 et aideront d'autres employés, ne sont allés nulle part et n'iront pas.
Ces spécialistes peuvent-ils devenir des ingénieurs DevOps? Bien sûr qu'ils le peuvent. En fait, il s'agit de leur environnement frère, qui nécessite des compétences en administration de système, mais en plus, le travail avec la surveillance, les systèmes de livraison et, en général, une interaction étroite avec l'équipe de développement et de test est ajouté.
Un autre problème DevOps
En fait, tout ne se limite pas à l'embauche et à la confusion constante entre administrateurs et devops. À un moment donné, l'entreprise a été confrontée au problème de la livraison des mises à jour et de l'interaction de l'équipe de développement avec l'infrastructure finale.
C'était peut-être quand un oncle aux yeux brûlants est venu sur les lieux d'une conférence et a dit: «Et nous le faisons et nous l'appelons DevOps. Ces gars vont résoudre tous vos problèmes »- et ont commencé à dire à quel point il vivait dans l'entreprise après la mise en œuvre des pratiques DevOps.
Cependant, il ne suffit pas d'engager un ingénieur DevOps pour que tout fonctionne comme il se doit. L'entreprise doit passer complètement par la transformation DevOps, c'est-à-dire que le rôle et les capacités de nos développeurs doivent être clairement compris également du côté de l'équipe de développement et de test des produits. Nous avons une «belle» histoire sur ce sujet, qui illustre pleinement toute l'étain par endroits.
La situation. Les Devops sont nécessaires pour déployer un système de restauration de version, sans se pencher particulièrement sur son fonctionnement. Supposons que, dans le système Utilisateurs, ce soient des champs séparés sous le prénom, le nom et le mot de passe. Une nouvelle version du produit est sortie, mais pour les développeurs, le "rollback" est juste une baguette magique qui résoudra tout, et ils ne savent même pas comment cela fonctionne. Ainsi, par exemple, les développeurs du prochain patch ont combiné les champs du prénom et du nom, l'ont déployé dans la prod et la version ralentit pour une raison quelconque. Que se passe-t-il Le manuel vient au devoop et dit "Tirez sur l'interrupteur du couteau!", C'est-à-dire, lui demande de revenir à la version précédente. Que font les devops? Il revient à la version précédente, mais comme les développeurs ne voulaient pas comprendre comment ce retour en arrière est effectué, personne n'a dit au devo qu'il était également nécessaire de faire reculer la base. En conséquence, tout tombe pour nous, et au lieu du ralentissement du site, les utilisateurs voient l'erreur "500", car l'ancienne version ne fonctionne pas avec les champs de la nouvelle base de données. Devops n'en est pas conscient. Les développeurs sont silencieux. La direction commence à perdre des nerfs et de l'argent et rappelle des sauvegardes, proposant de les annuler afin que «au moins quelque chose fonctionne». En conséquence, les utilisateurs perdent toutes leurs données pendant une certaine période de temps.
Les noix vont, bien sûr, aux devops, qui «n'ont pas fait le bon système de restauration», et le fait que les orignaux dans cette histoire sont des développeurs ne dérange personne.
La conclusion est simple: sans une approche normale du DevOps en tant que tel, il n'y en a pas beaucoup.
La principale chose à retenir: l'ingénieur DevOps n'est pas un magicien, et sans communications de haute qualité et interaction bidirectionnelle avec le développement, il ne sera pas en mesure de faire face à ses tâches. Les Devops ne peuvent pas être laissés seuls avec leurs «problèmes» ou recevoir la commande «ne pas aller aux développeurs, coder leur entreprise», puis espérer qu'à un moment critique tout fonctionnera comme il se doit. Donc ça ne marche pas.
Essentiellement, les DevOps sont des compétences à la frontière entre la gestion et la technologie. De plus, il est loin d'être évident que dans ce cocktail de technologies, il devrait y avoir plus que de la gestion. Si vous voulez vraiment construire des processus de développement plus rapides et plus efficaces, vous devez faire confiance à vos développeurs. 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 vous isoler dans une unité autonome. Si les administrateurs peuvent travailler seuls, les devops sont inutiles dans ce cas, ils ne pourront pas vous aider à devenir meilleur si vous-même ne voulez pas accepter cette aide.
Et la dernière chose: arrêtez d'offenser les administrateurs d'infrastructure. Ils ont leur propre domaine de travail extrêmement important. Oui, l'administrateur peut devenir un ingénieur DevOps, mais cela doit se produire à la demande de la personne elle-même, et non sous le bâton. 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. S'il y a une volonté de subir une transformation professionnelle, il ne faut en aucun cas oublier qu'il faudra développer non seulement des compétences technologiques, mais aussi des compétences managériales. Il est très probable que vous, en tant que leader, devrez rassembler toutes ces personnes et apprendre à communiquer dans une seule langue.