Le directeur de l'exploitation du portail Banki.ru, Andreï Nikolsky, a pris la parole lors de la conférence de l'année dernière sur les services orphelins : comment identifier un orphelin dans l'infrastructure, quelles sont les faiblesses des services orphelins, que faire avec eux et comment agir si rien ne fonctionne.
Sous ce lien, la version textuelle de la présentation.
Bonjour collègues ! Je m'appelle Andreï, je dirige l'exploitation chez Banki.ru.
Nous avons de grands services, ce sont des monolithes, il y a des services dans un sens plus classique, et il y a des tout petits. Dans mon jargon de travail, je dirais que si un service est simple et petit, alors c'est un microservice, et si ce n'est pas tellement simple et pas petit, alors c'est simplement un service.
Les avantages des services
Je vais passer rapidement en revue les avantages des services.
Le premier avantage est l'évolutivité. Vous pouvez rapidement mettre en place quelque chose sur le service et le lancer en production. Si le trafic arrive, vous clonez le service. Si encore du trafic arrive, vous clonez encore et vous continuez à gérer cela. C’est un bon bonus, et en fait, lorsque nous avons commencé, c’était considéré comme le plus important : pourquoi faisons-nous tout cela ?
Deuxièmement, le développement isolé, lorsque vous avez plusieurs équipes de développement, plusieurs développeurs différents dans chaque équipe, et chaque équipe construit son propre service.
Il y a un aspect à considérer avec les équipes. Les développeurs peuvent être très différents. Par exemple, . J'ai vu cela pour la première fois chez Maxim Dorofeev. Parfois, il y a des gens flocons dans certaines équipes, mais pas dans d'autres. Cela rend les différents services utilisés dans l'entreprise un peu déséquilibrés.
Regardez cette image : c'est un bon développeur, il a de grandes mains, il peut faire beaucoup de choses. Le principal problème est de savoir d'où viennent ces mains.
Les services permettent d'utiliser différents langages de programmation, plus adaptés à différentes tâches. Un service en Go, un autre en Erlang, un autre en Ruby, quelque chose en PHP, quelque chose en Python. En gros, on peut s'étendre très largement. Il y a aussi des nuances ici.
L'architecture orientée services concerne avant tout le devops. Cela signifie que si vous n'avez pas d'automatisation, pas de processus de déploiement, si vous configurez manuellement, vos configurations peuvent changer d'une instance de service à une autre, et vous devez vous y connecter pour faire quelque chose, alors vous êtes dans l'enfer.
Par exemple, vous avez 20 services, et vous devez déployer manuellement, vous avez 20 consoles, et vous appuyez simultanément sur « entrer » comme un ninja. Ce n'est pas très bien.
Si votre service après les tests (s'il y a des tests, bien sûr) nécessite encore quelques ajustements pour fonctionner en production, j'ai également de mauvaises nouvelles pour vous.
Si vous dépendez de services spécifiques d'Amazon et que vous travaillez en Russie, alors il y a deux mois, vous aviez aussi « Tout autour brûle, je vais bien, tout est super ».
Nous utilisons Ansible pour automatiser le déploiement, Puppet pour la convergence, Bamboo pour automatiser le déploiement, Confluence pour essayer de documenter tout cela.
Je ne vais pas m'attarder longuement là-dessus, car la présentation concerne plutôt les pratiques d'interaction que la mise en œuvre technique.
Nous avons par exemple eu des problèmes où Puppet sur le serveur fonctionne avec Ruby 2, tandis qu'une certaine application est écrite pour Ruby 1.8, et ils ne fonctionnent pas ensemble. Ça coince. Et lorsque vous devez maintenir plusieurs versions de Ruby sur une seule machine, vous commencez généralement à avoir des problèmes.
Par exemple, nous fournissons à chaque développeur une plateforme où se trouve presque tout ce que nous avons, tous les services que l'on peut développer, afin qu'il ait un environnement isolé où il peut l'endommager et le construire comme il le souhaite.
Il arrive qu'un paquet spécialement compilé avec support pour quelque chose soit nécessaire. C'est assez strict. J'ai écouté une présentation où l'image Docker pèse 45 Go. Sous Linux, bien sûr, c'est plus simple, tout est plus léger, mais il n'y aura quand même pas assez de place.
Et il y a des dépendances contradictoires, lorsque vous avez une partie du projet qui dépend d'une bibliothèque d'une version, et une autre partie du projet d'une autre version, et les bibliothèques ne peuvent absolument pas être installées ensemble.
Nous avons des sites et des services sur PHP 5.6, nous en avons honte, mais que faire. C'est sur une plateforme. Il y a des sites et des services sur PHP 7, qui sont plus nombreux, dont nous ne sommes pas honteux. Et chaque développeur a sa propre base où il est heureux de faire des modifications.
Si vous travaillez dans une entreprise avec un même langage, avoir trois machines virtuelles par développeur semble raisonnable. Si vous utilisez différents langages de programmation, la situation se complique.
Vous vous retrouvez avec des sites et des services ici, là, puis une plateforme pour Go, une pour Ruby, et un Redis à côté. Au final, tout cela devient un vaste champ de support où quelque chose peut toujours tomber en panne.
C'est pourquoi nous avons remplacé les avantages du langage de programmation par l'utilisation de différents frameworks, car les frameworks PHP sont assez variés, ayant des capacités, des communautés et des supports différents. Et vous pouvez écrire un service de manière à ce qu'il y ait déjà quelque chose de prêt pour lui.
Chaque service a sa propre équipe.
Notre principal avantage, qui s'est crystallisé au fil des ans, est que chaque service a sa propre équipe. C'est pratique pour un grand projet, cela permet d'économiser du temps sur la documentation, les managers connaissent bien leur projet.
Les tâches de support peuvent être facilement confiées. Par exemple, si le service d'assurance tombe en panne. Et immédiatement, l'équipe qui s'occupe de l'assurance va le réparer.
De nouvelles fonctionnalités peuvent être mises en œuvre rapidement, car lorsque vous avez un petit service atomique, vous pouvez y intégrer rapidement quelque chose.
Et lorsque votre service tombe en panne, ce qui arrive inévitablement, vous n'affectez pas les services des autres, et les développeurs des autres équipes ne viennent pas en se plaignant : « Attention, ne faites pas cela ».
Comme toujours, il y a des nuances. Nos équipes sont stables, les managers sont solidement attachés à l'équipe. Il existe des documents clairs, les managers veillent attentivement à tout cela. Chaque équipe a plusieurs services avec un manager et un domaine de compétence spécifique.
Si les équipes sont fluides (ce qui arrive parfois chez nous), il existe une bonne méthode appelée « carte des étoiles ».
Vous avez une liste de services et de personnes. Une étoile signifie qu'une personne est experte dans ce service, un livre signifie qu'une personne étudie ce service. L'objectif pour une personne est de changer le livre en étoile. Si rien n'est inscrit en face d'un service, des problèmes commencent à surgir, dont je vais parler plus en détail.
Comment apparaissent les services orphelins ?
Le premier problème, la première façon d'avoir un service orphelin dans votre infrastructure, c'est le licenciement de personnes. Est-ce que quelqu'un a déjà connu des délais serrés arrivant avant que les tâches ne soient évaluées ? Parfois, les délais sont si serrés qu'il n'y a tout simplement pas de temps pour la documentation. « Il faut livrer le service en production, nous compléterons ensuite. »
Si l'équipe est petite, il arrive qu'il n'y ait qu'un seul développeur qui écrit tout, les autres sont en soutien. « J'ai écrit l'architecture principale, tu peux te charger des interfaces. » Ensuite, à un moment donné, le manager, par exemple, part. Et durant cette période, pendant que le manager est parti et qu'aucun nouveau n'est encore nommé, les développeurs décident eux-mêmes de la direction du service, de ce qui se passe. Et comme nous le savons (revenons à quelques diapositives en arrière), dans certaines équipes, il y a des personnes uniques, parfois un leader unique. Puis, il part, et nous nous retrouvons avec un service orphelin.
Cependant, les tâches provenant du support et des affaires n'ont pas disparu, elles s'accumulent dans le backlog. Si des erreurs architecturales ont été commises lors du développement du service, elles s'accumulent également dans le backlog. Le service se dégrade lentement.
Comment identifier un orphelin ?
Cette liste décrit assez bien la situation. Qui a reconnu quelque chose d'équivalent dans son infrastructure ?
Concernant les work-arounds documentés : il y a un service et, en gros, il fonctionne, il a un manuel de deux pages sur la façon de travailler avec lui, mais personne ne sait comment il fonctionne à l'intérieur.
Ou, par exemple, il y a un service de raccourcissement de liens. Par exemple, nous utilisons actuellement trois services de raccourcissement de liens pour différents objectifs dans différents services. Ce sont précisément les conséquences.
Maintenant, je vais devenir le capitaine de l'évidence. Que faut-il faire ? Tout d'abord, il faut transmettre le service à un autre manager, à une autre équipe. Si votre leader n'est pas encore parti, alors dans cette autre équipe, lorsque vous réalisez que le service ressemble à un orphelin, il faut inclure quelqu'un qui comprend au moins un peu le service.
La chose principale : vous devez avoir des procédures de transfert bien définies. Dans notre cas, je surveille cela généralement, car j'ai besoin que tout cela fonctionne. Les managers veulent que cela soit livré rapidement, et ce qui va se passer ensuite, cela les préoccupe moins.
Une autre façon de créer une application orpheline est de se dire : « Nous allons externaliser, ce sera plus rapide, et ensuite nous le passerons à l'équipe ». Il est clair que chacun a ses propres plans au sein de l'équipe, une certaine file d'attente. Souvent, le client commercial pense que l'externaliseur fera les choses de la même manière que le service technique de l'entreprise. Pourtant, leurs motivations sont différentes. Les externaliseurs peuvent avoir des solutions technologiques étranges et des approches algorithmiques inhabituelles.
Par exemple, nous avions un service qui utilisait Sphinx à des endroits inattendus. J'en dirai plus tard sur ce qu'il a fallu faire.
Les externaliseurs peuvent avoir des frameworks maison. C'est juste du PHP brut avec du copié-collé d'un projet précédent, où l'on trouve de tout. Il y a de gros bétons dans les scripts de déploiement, lorsque vous devez modifier plusieurs lignes dans un fichier via des scripts Bash complexes, ces scripts de déploiement étant appelés par un autre script. En fin de compte, vous changez le système de déploiement, vous choisissez autre chose, et hop, votre service ne fonctionne plus. Parce qu'il fallait encore ajouter 8 liens entre différents dossiers. Ou il arrive qu'un millier d'enregistrements fonctionne, mais pas cent mille.
Je continue à diriger. L'acceptation d'un service d'externalisation est une procédure obligatoire. Qui a déjà vécu un cas où un service d'externalisation arrive et n'est accepté nulle part ? Ce n'est pas aussi courant, bien sûr, que le service orphelin, mais tout de même.
Il faut vérifier le service, le revoir, changer les mots de passe. Nous avions un cas où un service nous a été refilé, avec une interface admin « if login == ‘admin’ && password == ‘admin’… », écrit directement dans le code. Nous nous asseyons et nous nous demandons, et c'est écrit par des gens en 2018 ?
Tester la capacité de stockage est également nécessaire. Il faut voir ce qui se passera avec cent mille enregistrements, même avant de mettre ce service en production.
Il ne faut pas avoir honte d'envoyer un service en révision. Quand vous dites : « Nous n'accepterons pas ce service, nous avons 20 tâches, faites-les, et alors nous l'accepterons », c'est normal. La conscience ne doit pas vous peser car vous exposez un manager ou que l'entreprise dépense de l'argent. En fin de compte, l'entreprise dépensera plus après.
Nous avons eu un cas où nous avons décidé de lancer un projet pilote en externalisation.
Il a été livré à temps, et c'était le seul critère de qualité. C'est pourquoi un autre projet pilote a été réalisé, qui n'était même plus tout à fait pilote. Ces services ont été acceptés, par des moyens administratifs on a dit : voici votre code, voilà l'équipe, voici votre responsable. Les services ont réellement commencé à générer des revenus. Pourtant, ils sont restés des orphelins, personne ne comprend comment ils fonctionnent, et les responsables se défilent de leurs tâches.
Il y a encore un autre concept intéressant : le développement clandestin. Quand un certain département, généralement celui du marketing, veut tester une hypothèse et commande un service entier en sous-traitance. Le trafic commence à affluer, ils finalisent les documents, signent des actes avec le contractant, passent en exploitation et disent : « Les gars, nous avons ici un service, il a déjà du trafic, il nous rapporte de l'argent, acceptons-le ». Nous sommes là : « Oh là là, comment est-ce possible ? »
Et encore une façon d'obtenir un service orphelin : lorsque l'une des équipes se retrouve soudainement surchargée, la direction dit : « Transférons ce service de cette équipe à une autre équipe, qui a moins de charge de travail ». Et ensuite, nous transférons à une troisième équipe et changeons le responsable. Et au final, nous avons encore un orphelin.
Quel est le problème avec les orphelins ?
Pour ceux qui ne le savent pas, il s'agit du navire de ligne Wasa, construit en Suède, célèbre pour avoir coulé cinq minutes après son lancement. Et le roi de Suède, d'ailleurs, n'a exécuté personne pour cela. Il a été construit par deux générations d'ingénieurs qui ne savaient pas construire de tels navires. Un effet prévisible.
Le navire aurait pu couler, d'ailleurs, beaucoup plus mal, par exemple lorsque le roi serait déjà à bord en pleine tempête. Ainsi, il a coulé immédiatement, ce qui est bon en agile — échouer tôt.
Si nous avons échoué tôt, il n'y a généralement pas de problèmes. Par exemple, lors de la réception, nous avons envoyé pour retouches. Mais si nous échouons déjà en production, lorsque des investissements ont été réalisés, cela peut poser des problèmes. Des conséquences, comme on les appelle dans le monde des affaires.
Quels sont les dangers des services orphelins :
- Le service peut tomber en panne soudainement.
- Le service prend du temps à être réparé ou ne l'est pas du tout.
- Problèmes de sécurité.
- Problèmes de retouches et de mises à jour.
- Si un service important tombe en panne, la réputation de l'entreprise en souffre.
Que faire des services orphelins ?
Je répète encore une fois ce qu'il faut faire. Tout d'abord, il doit y avoir de la documentation. Mes sept années chez Banki.ru m'ont appris que les testeurs ne doivent pas croire sur parole les développeurs, et que l'exploitation ne doit pas croire sur parole qui que ce soit. Il faut vérifier.
Deuxièmement, il est nécessaire d'écrire des schémas d'interaction, car il arrive que des services, qui ne sont pas très bien acceptés, contiennent des dépendances qui n'ont été révélées à personne. Par exemple, les développeurs ont connecté le service à leur clé pour des cartes Yandex ou à Dadata. Votre quota gratuit est épuisé, tout s'arrête et vous ne savez pas du tout ce qui s'est passé. Tous ces pièges doivent être décrits : le service utilise Dadata, Sms, ou autre chose.
Troisièmement, il s'agit de travailler sur la dette technique. Lorsque vous créez des solutions temporaires ou adoptez un service en disant que quelque chose doit être fait, il faut suivre pour s'assurer que cela se réalise. Parce qu'il peut s'avérer qu'un petit trou n'est pas si petit, et que vous pouvez y tomber.
Nous avons eu une histoire avec les problèmes d'architecture concernant Sphinx. Dans l'un des services, Sphinx était utilisé pour entrer des listes. Simplement une liste avec une pagination, mais il était réindexé chaque nuit. Il était constitué de deux index : un index grand qui était réindexé chaque nuit, et un petit index qui lui était associé. Chaque jour, avec une probabilité de 50%, soit ça fonctionnait, soit non, lors du déploiement, l'index se cassait et les actualités cessaient de se mettre à jour sur la page d'accueil. Au début, cela prenait 5 minutes tant que l'index était réindexé, puis l'index a grossi, et à un moment donné, il a commencé à se réindexer pendant 40 minutes. Lorsque nous avons éliminé cela, nous avons poussé un soupir de soulagement, car il était clair qu'il ne faudrait pas longtemps avant que nous ayons un index qui se réindexerait pendant une journée de travail complète. Ce serait un échec pour notre portail, huit heures sans nouvelles — c'est tout, les affaires s'arrêtent.
Plan de travail avec le service orphelin
En réalité, c'est très difficile à faire, car le DevOps concerne la communication. On a envie d'être en bonnes relations avec ses collègues, mais lorsque vous frappez vos collègues et managers avec des règlements, ils peuvent éprouver des sentiments contradictoires envers ceux qui agissent ainsi.
En plus de tous ces points, il y a une chose importante : pour chaque service spécifique, pour chaque partie spécifique du processus de déploiement, des personnes spécifiques doivent être responsables. Quand ces personnes ne sont pas disponibles et qu'il faut faire appel à d'autres, étudier tout cela devient compliqué.
Si tout cela n'a pas aidé et que le service orphelin reste toujours sans preneur, que personne ne veut l'adopter, que la documentation n'est pas écrite, et que l'équipe qui a été affectée à ce service refuse de faire quoi que ce soit, il y a une solution simple : tout recommencer.
C'est-à-dire que vous prenez les exigences du service à nouveaux et vous écrivez un nouveau service, meilleur, sur une meilleure plateforme, sans solutions technologiques étranges. Et vous migrez vers lui en production.
Nous avons eu une situation où nous avons repris un service sur Yii 1 et compris que nous ne pouvions pas le développer davantage, car nous n'avions plus de développeurs capables d'écrire correctement en Yii 1. Tous les développeurs maîtrisent bien Symfony 3. Que faire ? Nous avons alloué du temps, constitué une équipe, désigné un manager, réécrit le projet et lentement redirigé le trafic vers lui.
Après cela, l'ancien service peut être supprimé. C'est ma procédure préférée, lorsque l'on doit retirer un service du système de gestion de configuration et ensuite vérifier que toutes les machines en production ont été éteintes, pour qu'aucune trace ne reste chez les développeurs. Le dépôt dans git reste.
Voilà tout ce que je voulais dire, je suis prêt à discuter, c'est un sujet polémique, beaucoup y ont été impliqués.
Dans les diapositives, il était question de l'unification des langages. Un exemple était le redimensionnement des images. Est-il vraiment nécessaire de se limiter à un seul langage ? Parce que le redimensionnement d'une image en PHP, eh bien, cela aurait vraiment pu être fait en Golang.
En réalité, ce n'est pas nécessaire, comme toutes les pratiques. Dans certains cas, cela peut même être indésirable. Mais il faut comprendre que si vous avez dans votre entreprise un service technique de 50 personnes, dont 45 sont des développeurs PHP, 3 autres sont des DevOps maîtrisant Python, Ansible, Puppet et d'autres outils, et qu'un seul d'entre eux écrit un service de redimensionnement d'images en Go, alors, lorsqu'il part, son expertise part avec lui. Et vous devrez chercher un développeur spécifique sur le marché qui connaît ce langage, surtout s'il est rare. Donc, d'un point de vue organisationnel, c'est problématique. D'un point de vue DevOps, vous devez non seulement cloner un ensemble de playbooks que vous utilisez pour déployer des services, mais vous devrez les écrire à nouveau.
Nous développons actuellement un service en Node.js, et ce sera en fait un espace séparé pour chaque développeur avec un langage distinct. Mais nous avons réfléchi et décidé que le jeu en valait la chandelle. C'est donc un point à méditer.
Comment surveillez-vous vos services ? Comment collectez-vous et suivez-vous les logs ?
Nous collectons les logs dans Elasticsearch et les stockons dans Kibana, et selon qu'il s'agit d'environnements de production ou de test, différents collecteurs sont utilisés. Parfois Lumberjack, parfois d'autres outils, je ne me souviens plus. Et il y a aussi certains endroits dans certains services où nous installons Telegraf et les envoyons ailleurs séparément.
Comment vivre avec Puppet et Ansible dans un même environnement ?
En réalité, nous avons actuellement deux environnements, l'un avec Puppet, l'autre avec Ansible. Nous travaillons pour les hybrider. Ansible est un bon environnement pour la configuration initiale, Puppet est une solution moins adéquate pour cela, car il nécessite une intervention manuelle directe avec la plateforme, et Puppet garantit la convergence de la configuration. Cela signifie que la plateforme se maintient à jour par elle-même, tandis que pour qu'une machine gérée par Ansible reste à jour, il faut exécuter les playbooks à intervalles réguliers. Voilà la différence.
Comment maintenez-vous la compatibilité ? Avez-vous des configurations à la fois dans Ansible et Puppet ?
C'est notre grande douleur, nous assurons la compatibilité manuellement et réfléchissons à comment tout cela pourrait être migré ailleurs. Nous avons Puppet qui déploie des paquets et maintient certains liens, tandis qu'Ansible, par exemple, déploie du code et ajuste les configurations appliquées.
La présentation parlait des différentes versions de Ruby. Quelle est la solution ?
Nous avons déjà rencontré cela à un moment donné, et nous devons constamment y penser. Nous avons simplement désactivé la partie qui fonctionnait sur cette version de Ruby incompatible avec les applications, et nous l'avons maintenue séparément.
Cette année la conférence aura lieu le 7 décembre au « Technopolis ». Nous acceptons les soumissions de présentations jusqu'au 11 novembre. si vous souhaitez prendre la parole.
L'inscription des participants est ouverte, rejoignez-nous !
Source : habr.com
