Lors de la conférence de l'année dernière
DevOpsDays Moscou, le directeur des opérations du portail Banki.ru Andrei Nikolsky a parlé des services orphelins: comment identifier un orphelin dans l'infrastructure, quels sont les mauvais services orphelins, que faire avec eux et comment être si rien n'y fait.
Sous la coupe se trouve la version texte du rapport.
Bonjour collègues! Je m'appelle Andrey, je dirige l'opération chez Banki.ru.
Nous avons d'excellents services, ce sont des services monolithiques, il y a des services dans un sens plus classique, il y en a de très petits. Dans la terminologie de mon travailleur et de mon paysan, je dis que si le service est simple et petit, alors il est micro, et s'il n'est pas très simple et pas petit, alors c'est juste un service.
Service Pros
Je vais passer rapidement en revue les avantages des services.
Le premier est la mise à l'échelle. Vous pouvez rapidement faire quelque chose sur le service et démarrer la production. Vous êtes arrivé du trafic, vous avez cloné le service. Vous avez toujours du trafic, vous clonez toujours et vivez avec. C'est un bon bonus et, en principe, lorsque nous avons commencé, il était considéré comme le plus important d'entre nous, 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 voit une sorte de service.
Il y a une nuance avec les équipes. Les développeurs sont différents. Et il y a, par exemple, des
gens-flocons de neige . J'ai vu cela pour la première fois avec Maxim Dorofeev. Parfois, les gens ont des flocons de neige dans certaines équipes, et d'autres non. Cela rend les différents services utilisés dans l'entreprise un peu inégaux.
Regardez l'image: c'est un bon développeur, il a de grandes mains, il peut faire beaucoup. Le principal problème est d'où ces mains poussent.
Les services permettent d'utiliser différents langages de programmation plus adaptés à différentes tâches. Certains services sur Go, certains sur Erlang, certains sur Ruby, certains sur PHP, certains sur Python. En général, vous pouvez vous retourner très largement. Il y a aussi des nuances ici.
L'architecture orientée services concerne principalement les devops. Autrement dit, si vous n'avez pas d'automatisation, il n'y a pas de processus de déploiement, si vous configurez avec vos mains, vos configurations peuvent passer d'une instance de service à une instance, et vous devez y aller pour faire quelque chose, alors vous êtes en enfer.
Par exemple, vous avez 20 services et vous devez déployer avec vos mains, vous avez 20 consoles et vous appuyez simultanément sur "Entrée", comme un ninja. Ce n'est pas très bon.
Si vous avez un service après les tests (s'il y a des tests, bien sûr), et que vous devez également le terminer avec un fichier pour qu'il fonctionne en production, j'ai aussi de mauvaises nouvelles pour vous.
Si vous comptez sur les services spécifiques d'Amazon et travaillez en Russie, il y a deux mois, vous aviez également "Tout est en feu, ça va, tout est cool".
Nous utilisons Ansible pour l'automatisation du déploiement, Puppet pour la convergence, Bamboo pour l'automatisation du déploiement, Confluence pour tout décrire en quelque sorte.
Je ne m'attarderai pas là-dessus en détail, car le rapport concerne davantage la pratique des interactions et non la mise en œuvre technique.
Par exemple, nous avons eu des problèmes que Puppet sur le serveur fonctionne avec Ruby 2, et certaines applications ont été écrites sous Ruby 1.8, et ensemble, elles ne fonctionnent pas. Il se produit une sorte de jambage. Et lorsque vous devez conserver plusieurs versions de Ruby sur la même machine, vous rencontrez généralement des problèmes.
Par exemple, nous donnons à chaque développeur une plate-forme sur laquelle il y a à peu près tout ce que nous avons, tous les services qui peuvent être développés pour qu'il ait un environnement isolé, il peut le décomposer et le construire comme il veut.
Il arrive que vous ayez besoin d'une sorte de paquet spécialement compilé avec le support de quelque chose. C'est assez difficile. J'ai écouté un rapport où l'image docker pèse 45 Go. Sous Linux, bien sûr, c'est plus simple, tout y est plus petit, mais de toute façon, il n'y aura pas assez de places.
Eh bien, il existe des dépendances conflictuelles lorsque vous avez une partie d'un projet en fonction de la bibliothèque d'une version, une autre partie du projet sur une version différente et les bibliothèques ne sont pas du tout réunies.
Nous avons des sites et des services en PHP 5.6, nous en avons honte, mais que faire. Ceci est notre seul site. Il existe des sites et des services en PHP 7, il y en a plus, on n'a pas honte d'eux. Et chaque développeur a sa propre base, où il voit joyeusement.
Si vous écrivez dans l'entreprise dans une seule langue, alors trois machines virtuelles par développeur - cela semble normal. Si vous avez différents langages de programmation, la situation empire.
Vous avez des sites et des services là-dessus, là-dessus, puis une autre plate-forme pour Go, une plate-forme pour Ruby, une autre Redis sur le côté. En conséquence, tout cela se transforme en un grand champ de support, et tout le temps, une partie de cela peut se casser.
Par conséquent, nous avons remplacé les petits pains du langage de programmation par l'utilisation de différents frameworks, car les frameworks en PHP sont assez différents, ils ont des capacités différentes, des communautés différentes, un support différent. Et vous pouvez écrire un service pour que vous ayez déjà quelque chose de prêt.
Chaque service a sa propre équipe.
Notre principal atout, qui s'est cristallisé sur plusieurs années, est que chaque service dispose de sa propre équipe. C'est pratique pour un grand projet, vous pouvez gagner du temps sur la documentation, les managers connaissent bien leur projet.
Les tâches du support peuvent être parfaitement lancées. Par exemple, le service d'assurance est tombé en panne. Et immédiatement, l'équipe d'assurance va réparer.
De nouvelles fonctionnalités sont rapidement créées, car lorsque vous avez un service atomique, vous pouvez rapidement y visser quelque chose.
Et lorsque vous avez interrompu votre service, et cela se produit inévitablement, vous n'avez pas blessé les services de quelqu'un d'autre, et les développeurs avec des éléments d'autres équipes ne recourent pas à vous et ils ne disent pas: "Aw, ne fais pas ça."
Comme toujours, il y a des nuances. Nous avons des équipes stables, les managers sont cloués à l'équipe. Il existe des documents clairs, les gestionnaires surveillent de près tout cela. Chaque équipe avec un manager a plusieurs services, et il y a un point de compétence spécifique.
Si les équipes flottent (cela est également parfois utilisé avec nous), il existe une bonne méthode appelée la carte des étoiles.
Vous avez une liste de services et de personnes. Un astérisque signifie qu'une personne est experte dans ce service, un livre signifie qu'une personne étudie ce service. La tâche de l'homme est de changer un petit livre pour un astérisque. Et si rien n'est écrit en face du service, alors les problèmes commencent, dont je vais continuer à parler.
Comment apparaissent les services orphelins?
Le premier problème, la première façon, pour obtenir un service orphelin dans votre infrastructure, c'est le licenciement. Quelqu'un s'est-il déjà produit lorsque les délais arrivent de l'entreprise avant d'évaluer les tâches? Il arrive parfois que les délais soient serrés et qu'il n'y ait tout simplement pas assez de temps pour la documentation. «Nous devons remettre le service à la production, puis nous l'ajouterons.»
Si l'équipe est petite, il arrive qu'il y ait un développeur qui écrit tout, les autres sont dans les coulisses. "J'ai écrit l'architecture de base, vous me donnez les interfaces." Puis, à un moment donné, le manager, par exemple, s'en va. Et pendant cette période, lorsque le gestionnaire est parti et qu'un nouveau n'a pas encore été nommé, les développeurs décident eux-mêmes où le service se déplace, ce qui se passe là-bas. Et comme nous le savons (revenons quelques diapositives), dans certaines équipes, il y a des gens-flocons de neige, parfois un flocon de neige-timlid. Puis il quitte, et nous obtenons un orphelin de service.
Dans le même temps, les tâches du support et de l'entreprise ne disparaissent pas, elles s'installent dans l'arriéré. S'il y a eu des erreurs architecturales lors du développement du service, elles se sont également installées dans l'arriéré. Le service se dégrade lentement.
Comment identifier un orphelin?
Cette liste décrit bien la situation. Qui a appris quoi que ce soit dans l'infrastructure?
À propos des solutions de contournement documentées: il existe un service et, en général, il fonctionne, il a un manuel de deux pages, comment travailler avec, mais personne ne sait comment il fonctionne à l'intérieur.
Ou, par exemple, il existe une sorte de raccourcisseur de lien. Par exemple, nous utilisons maintenant trois raccourcisseurs de liens à des fins différentes dans différents services. Ce sont les conséquences.
Maintenant, je serai le capitaine des preuves. Que faut-il faire? Tout d'abord, vous devez transférer le service à un autre manager, une autre équipe. Si votre chef d'équipe n'a pas encore démissionné, dans cette autre équipe, lorsque vous comprenez que le service est comme un orphelin, vous devez inclure quelqu'un qui comprend au moins quelque chose à son sujet.
L'essentiel: vous devez avoir des procédures de transmission sanguines. Dans notre cas, j'ai l'habitude de suivre cela, car j'ai besoin que cela fonctionne. Les gestionnaires ont besoin que cela soit livré rapidement, et ce qui lui arrivera plus tard n'est pas si important pour eux.
La prochaine façon de faire un orphelin est "Faisons-le en externalisant, ce sera plus rapide, puis nous le transférerons à l'équipe." Il est clair que tout le monde a des plans dans l'équipe, la file d'attente. Souvent, un client professionnel pense qu'un sous-traitant fera la même chose que le service technique de l'entreprise. Bien que leurs motivations soient différentes. L'externalisation a d'étranges solutions technologiques et d'étranges solutions algorithmiques.
Par exemple, nous avions un service dans lequel Sphinx se trouvait dans divers endroits inattendus. Je te dirai plus tard ce que je devais faire.
Les sous-traitants ont des cadres auto-écrits. C'est juste du PHP nu avec du copier-coller du projet précédent, où vous pouvez tout trouver. Grands béquilles dans les scripts de déploiement, lorsque vous devez modifier plusieurs lignes dans un fichier avec des scripts Bash complexes, tandis que ces scripts de déploiement sont appelés par un troisième script. Par conséquent, vous modifiez le système de déploiement, choisissez autre chose, hop, et votre service ne fonctionne pas. Parce qu'il y avait 8 autres liens à mettre entre différents dossiers. Ou il arrive qu'un millier d'enregistrements fonctionnent, mais cent mille ont disparu.
Je vais continuer à capitaine. Accepter un service d'externalisation est une procédure qui est nécessaire. Qui est arrivé qu'un service d'un sous-traitant arrive, mais il n'est accepté nulle part? Ce n'est pas, bien sûr, aussi populaire qu'un orphelin de service, mais quand même.
Le service doit être vérifié, le service doit être revu, les mots de passe doivent être modifiés. Nous avons eu un cas où le service nous a jeté, là le panneau d'administration "si login == 'admin' && mot de passe == 'admin' ..." est écrit directement dans le code. Nous nous asseyons et pensons, et les gens écrivent ceci en 2018?
Le test du volume de stockage est également un must. Vous devez regarder ce qui se passera sur cent mille enregistrements, avant même de lancer ce service quelque part en production.
Envoyer le service pour révision ne devrait pas avoir honte. Quand vous dites: «Nous n'accepterons pas ce service, nous avons 20 tâches, faites-les, alors nous accepterons», c'est normal. La conscience ne devrait pas nuire au fait que vous remplacez un gestionnaire ou qu'une entreprise dépense de l'argent. L'entreprise dépensera alors plus.
Nous avons eu un cas lorsque nous avons décidé de faire un projet pilote sur l'externalisation.
Elle a été livrée à temps, et c'était le seul critère de qualité. Par conséquent, ils ont réalisé un autre projet pilote, pas même un pilote du tout. Ces services ont été acceptés, ont-ils dit de manière administrative, voici votre code, voici une équipe, voici votre manager. Les services ont vraiment déjà commencé à faire du profit. De plus, en fait, ils sont restés orphelins, personne ne comprend comment ils travaillent et les managers renient de toutes les manières possibles leurs tâches.
Il existe un autre excellent concept - le développement partisan. Lorsqu'un service, en règle générale, est un service marketing, il souhaite tester une hypothèse et ordonner l'externalisation de l'ensemble du service. La circulation commence à affluer sur lui, ils ferment des documents, signent des actes avec l'entrepreneur, entrent en service et disent: «Mec, nous avons un service ici, il a déjà du trafic, il nous rapporte de l'argent, prenons-le». Nous sommes: "Oppa, comment ça."
Et une autre façon d'obtenir un service orphelin: lorsqu'une équipe est soudainement chargée, la direction dit: «Transférons le service de cette équipe à une autre équipe, elle a moins de charge.» Et puis nous passerons à la troisième équipe, et nous changerons de manager. Et à la fin, nous avons à nouveau un orphelin.
Quel est le problème avec les orphelins?
Qui ne sait pas, c'était le navire de la ligne Wasa levé en Suède, célèbre pour le fait qu'il a coulé 5 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 pouvaient pas construire de tels navires. L'effet naturel.
Au fait, le navire pourrait couler bien pire, par exemple, lorsque le roi le conduirait quelque part dans une tempête. Et donc, il s'est noyé tout de suite, selon Ajail, il est bon d'échouer tôt.
Si nous échouons tôt, il n'y a généralement aucun problème. Par exemple, lors de l'acceptation, ils ont envoyé pour révision. Et si nous avons déjà échoué dans la production, lorsque l'argent est investi, il peut y avoir des problèmes. Les conséquences, comme on les appelle dans les affaires.
Pourquoi des services orphelins dangereux:
- Le service peut s'arrêter subitement.
- Le service est réparé depuis longtemps ou pas réparé du tout.
- Problèmes de sécurité.
- Problèmes d'améliorations et de mises à jour.
- Si un service important tombe en panne, la réputation de l'entreprise en souffre.
Que faire des services orphelins?
Encore une fois, que faire. Premièrement, il devrait y avoir de la documentation. Pendant 7 ans à Banki.ru, on m'a enseigné que les testeurs ne devraient pas prendre un mot pour les développeurs, et le fonctionnement ne devrait pas prendre un mot pour tout le monde. Il faut vérifier.
Deuxièmement, il est nécessaire d'écrire des schémas d'interaction, car il arrive que des services mal reçus contiennent des dépendances dont personne n'a parlé. Par exemple, les développeurs ont mis le service sur leur clé à certains Yandex.Maps ou à Dadata. Vous n'avez plus de limite gratuite, tout est cassé et vous ne savez pas du tout ce qui s'est passé. Tous ces râteaux doivent être décrits: le service utilise Dadata, Sms, autre chose.
Troisièmement, travaillez avec la dette technique. Lorsque vous faites des béquilles ou acceptez le service et dites que quelque chose doit être fait, vous devez vous assurer qu'ils le font. Parce qu'alors, il se peut que le petit trou ne soit pas si petit et que vous y tombiez.
Avec des tâches architecturales, nous avions une histoire sur le Sphinx. Dans l'un des services, Sphinx a été utilisé pour saisir des listes. Juste une liste de pagination, mais elle a été réindexée tous les soirs. Il a été compilé à partir de deux indices: l'un était indexé tous les soirs de grande taille, et il y avait encore un petit index qui y était vissé. Chaque jour, avec une probabilité de 50%, il bombardera ou non, lors du calcul, l'index battait, et l'actualité cessait de se mettre à jour sur la page principale. Au début, c'était 5 minutes, alors que l'indice était réindexé, puis l'indice a augmenté et, à un moment donné, il a commencé à se réindexer 40 minutes. Lorsque nous l'avons supprimé, nous avons poussé un soupir de soulagement, car il était clair qu'un peu plus de temps passerait, et notre indice serait réindexé à temps plein. Ce sera un fichier pour notre portail, huit heures il n'y a pas de nouvelles - c'est tout, l'entreprise s'est levée.
Plan de travail avec un service orphelin
En fait, c'est très difficile à faire, car devops concerne la communication. Je veux être en bonnes relations avec mes collègues, et lorsque vous battez des collègues et des managers avec des règlements sur la tête, ils peuvent avoir des sentiments contradictoires pour les gens qui font ça.
En plus de tous ces points, il y a une autre chose importante: pour chaque service spécifique, pour chaque section spécifique de la procédure de déploiement, des personnes spécifiques doivent être responsables. Quand il n'y a personne et que vous devez attirer d'autres personnes, pour étudier le tout, cela devient difficile.
Si tout cela n'aide pas et que le service orphelin est toujours orphelin, personne ne veut vous le rapporter, la documentation n'est pas écrite, l'équipe qui a été appelée à ce service refuse de faire quelque chose, il y a un moyen facile de tout refaire .
Autrement dit, vous prenez à nouveau les exigences de service et écrivez un nouveau service, mieux, sur une meilleure plate-forme, sans solutions technologiques étranges. Et migrez vers lui au combat.
Nous avons eu une situation lorsque nous avons pris le service sur Yii 1 et nous avons réalisé que nous ne pouvions pas le développer davantage, car nous manquons de développeurs qui peuvent bien écrire sur Yii 1. Tous les développeurs écrivent bien sur le troisième Symfony. Que faire Nous avons pris le temps, réparti l'équipe, attribué le gestionnaire, réécrit le projet et transféré le trafic en douceur.
Après cela, l'ancien service peut être supprimé. C'est ma procédure préférée, lorsque vous devez retirer et nettoyer certains services du système de gestion de la configuration, puis vérifier que toutes les voitures de la production ont été remboursées afin que les développeurs n'aient plus de traces. Le référentiel dans le git reste.
C'est tout ce dont je voulais parler, je suis prêt à discuter, le sujet est holistique, beaucoup flottaient dedans.
Sur les diapositives, il s'agissait du fait que vous avez unifié les langues. Un exemple était le redimensionnement des images. Mais est-il vraiment nécessaire de durcir dans une seule langue? Parce que le redimensionnement des images en PHP, eh bien, vous pourriez vraiment le faire dans Golang.En fait, ce n'est pas nécessaire, comme toutes les pratiques. Peut-être, dans certains cas, même indésirable. Mais vous devez comprendre que si vous avez 50 personnes dans le département technique, 45 d'entre eux sont des développeurs PHP, 3 autres sont des devops qui peuvent faire Python, Ansible, Puppet et quelque chose comme ça, et un seul d'entre eux écrit sur certains Rendez-vous au service de redimensionnement des photos, puis quand il part, l'examen part avec lui. Et en même temps, vous devrez rechercher un développeur spécifique au marché qui connaît ce langage, surtout s'il est rare. Autrement dit, d'un point de vue organisationnel, cela pose problème. Du point de vue des devops, vous devrez non seulement cloner un ensemble de playbooks prêt à l'emploi que vous utilisez pour déployer des services, mais vous devrez les réécrire.
Nous voyons maintenant le service sur Node.js, et ce sera juste une plate-forme à proximité pour chaque développeur avec une langue distincte. Mais nous nous sommes assis en pensant que le jeu en valait la chandelle. Autrement dit, la question ici est de s'asseoir et de réfléchir.
Comment surveillez-vous vos services? Comment collectez-vous et suivez-vous les journaux?Nous collectons les journaux dans Elasticsearch et les mettons dans Kibana, et selon les environnements de production ou de test, différents collecteurs y sont utilisés. Quelque part bûcheron, quelque part ailleurs quelque chose, je ne me souviens plus. Et il y a encore des endroits dans certains services où nous mettons Telegraf et bullet ailleurs séparément.Comment vivre avec Puppet et Ansible dans un même environnement?En fait, nous avons maintenant deux environnements, l'un est Puppet, l'autre est Ansible. Nous travaillons pour les hybrider. Ansible est un bon environnement pour la configuration initiale, Puppet est une mauvaise chose pour la configuration initiale car il nécessite des mains pour travailler directement avec le site, et Puppet assure la convergence de la configuration. Cela signifie que le site lui-même est tenu à jour, et pour que la machine ansiblized soit tenue à jour, vous devez poursuivre les playbooks avec lui à n'importe quelle fréquence. Voici une telle différence.Comment maintenez-vous la compatibilité? Avez-vous des configurations dans Ansible et Puppet?C'est notre grande douleur, nous maintenons la compatibilité avec nos mains et pensons, comme si maintenant, à passer de tout cela quelque part. Il s'avère que Puppet déploie des packages et prend en charge certains liens là-bas, tandis qu'Ansible, par exemple, récupère le code et génère de nouvelles configurations d'application là-bas.La présentation portait sur différentes versions de Ruby. Quelle est la solution?Nous sommes confrontés à cela en un seul endroit, et nous devons garder cela à l'esprit tout le temps. Nous venons de désactiver la partie qui fonctionnait sur le Ruby, qui était incompatible avec les applications, et l'avons gardé séparé.Cette année, la conférence DevOpsDays Moscou se tiendra le 7 décembre à Technopolis. Jusqu'au 11 novembre, nous acceptons les demandes de rapports. Écrivez- nous si vous souhaitez parler.
L'inscription des participants est ouverte, inscrivez-vous!