Andrey Nikolsky, directeur des opérations du portail Banki.ru, 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, pourquoi les services orphelins sont mauvais, que faire avec eux et que faire si rien n'y fait.
Sous la coupe se trouve une version texte du rapport.
Bonjour collègues! Je m'appelle Andrey, je dirige les opérations chez Banki.ru.
Nous avons de grands services, ce sont des services tellement monolithiques, il y a des services dans un sens plus classique, et il y en a de très petits. Dans ma terminologie d’ouvrier-paysan, je dis que si un service est simple et petit, alors il est micro, et s’il n’est pas très simple et petit, alors ce n’est qu’un service.
Avantages des services
Je vais rapidement passer 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 avez reçu du trafic, vous avez cloné le service. Vous avez plus de trafic, vous l'avez cloné et vivez avec. C'est un bon bonus et, en principe, lorsque nous avons commencé, la raison pour laquelle nous faisons tout cela était considérée comme la chose la plus importante pour nous.
Deuxièmement, le développement isolé, lorsque vous avez plusieurs équipes de développement, plusieurs développeurs différents dans chaque équipe, et que chaque équipe développe son propre service.
Avec les équipes, il y a une nuance. Les développeurs sont différents. Et il y a par exemple . J'ai vu cela pour la première fois avec Maxim Dorofeev. Parfois, les flocons de neige font partie de certaines équipes et pas d’autres. Cela rend les différents services utilisés au sein de l’entreprise un peu inégaux.
Regardez la photo : 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. Certains services sont en Go, certains sont en Erlang, certains sont en Ruby, quelque chose est en PHP, quelque chose est en Python. En général, vous pouvez vous étendre très largement. Il y a ici aussi des nuances.
L'architecture orientée services concerne principalement les développeurs. Autrement dit, si vous n’avez pas d’automatisation, il n’y a pas de processus de déploiement, si vous le configurez manuellement, vos configurations peuvent changer d’une instance de service à l’autre, et vous devez y aller pour faire quelque chose, alors vous êtes en enfer.
Par exemple, vous disposez de 20 services et vous devez déployer manuellement, vous disposez de 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 test (s'il y a des tests, bien sûr), et que vous devez encore le terminer avec un fichier pour qu'il fonctionne en production, j'ai aussi une mauvaise nouvelle pour vous.
Si vous comptez sur des services Amazon spécifiques et travaillez en Russie, alors il y a deux mois, vous aviez également « Tout est en feu autour, je vais bien, tout va bien ».
Nous utilisons Ansible pour automatiser le déploiement, Puppet pour la convergence, Bamboo pour automatiser le déploiement et Confluence pour tout décrire d'une manière ou d'une autre.
Je ne m'étendrai pas sur ce point en détail, car le rapport porte davantage sur les pratiques d'interaction que sur la mise en œuvre technique.
Par exemple, nous avons eu des problèmes lorsque Puppet sur le serveur fonctionne avec Ruby 2, mais certaines applications sont écrites pour Ruby 1.8 et elles ne fonctionnent pas ensemble. Quelque chose ne va pas là-bas. Et lorsque vous devez exécuter plusieurs versions de Ruby sur une seule machine, vous commencez généralement à avoir des problèmes.
Par exemple, nous donnons à chaque développeur une plateforme 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 dispose d'un environnement isolé, qu'il puisse le casser et le construire comme il le souhaite.
Il arrive que vous ayez besoin d'un package spécialement compilé prenant en charge quelque chose. C'est assez dur. 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 quand même, il n'y aura pas assez d'espace.
Eh bien, il existe des dépendances conflictuelles, lorsqu'une partie du projet dépend d'une bibliothèque d'une version, une autre partie du projet dépend d'une autre version et les bibliothèques ne sont pas du tout installées ensemble.
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 sur PHP 7, ils sont plus nombreux, on n'en a pas honte. Et chaque développeur a sa propre base, où il scie avec plaisir.
Si vous écrivez dans une entreprise dans une seule langue, trois machines virtuelles par développeur semblent normales. Si vous utilisez différents langages de programmation, la situation empire.
Vous avez des sites et des services là-dessus, là-dessus, puis un autre site pour Go, un site pour Ruby et quelques autres Redis sur le côté. En conséquence, tout cela se transforme en un vaste champ de support, et une partie de celui-ci peut toujours se briser.
Par conséquent, nous avons remplacé les avantages du langage de programmation par l'utilisation de différents frameworks, car les frameworks PHP sont assez différents, ils ont des capacités différentes, des communautés différentes et un support différent. Et vous pouvez écrire un service de manière à avoir déjà quelque chose de prêt pour celui-ci.
Chaque service a sa propre équipe
Notre principal avantage, cristallisé depuis plusieurs années, est que chaque service dispose de sa propre équipe. C'est pratique pour un gros projet, vous pouvez gagner du temps sur la documentation, les managers connaissent bien leur projet.
Vous pouvez facilement soumettre des tâches depuis le support. Par exemple, le service d’assurance est tombé en panne. Et immédiatement, l'équipe qui s'occupe de l'assurance va réparer le problème.
De nouvelles fonctionnalités sont créées rapidement, car lorsque vous disposez d'un service atomique, vous pouvez rapidement y insérer quelque chose.
Et lorsque vous interrompez votre service, et cela arrive inévitablement, vous n'avez pas affecté les services des autres, et les développeurs d'autres équipes ne viennent pas vers vous avec des fragments et vous disent : « Ouais, 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 managers surveillent tout de près. Chaque équipe avec un manager dispose de plusieurs services, et il y a un point de compétence précis.
Si les équipes flottent (nous l'utilisons aussi parfois), il existe une bonne méthode appelée « carte des étoiles ».
Vous disposez d'une liste de services et de personnes. Un astérisque signifie que la personne est un expert dans ce service, un livre signifie que la personne étudie ce service. La tâche de la personne est de remplacer le livret par un astérisque. Et si rien n'est écrit devant le service, alors des problèmes commencent, dont je parlerai plus loin.
Comment apparaissent les services orphelins ?
Le premier problème, la première façon d'obtenir un service orphelin dans votre infrastructure est de licencier des personnes. Quelqu’un a-t-il déjà demandé à une entreprise de respecter les délais avant que les tâches ne soient évaluées ? 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 confier 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, ajoutons les interfaces." Puis, à un moment donné, le manager, par exemple, s'en va. Et pendant cette période, lorsque le manager est parti et qu'un nouveau n'a pas encore été nommé, les développeurs décident eux-mêmes où va le service et ce qui s'y passe. Et comme on le sait (remontons quelques slides), dans certaines équipes il y a des gens flocon de neige, parfois un chef d’équipe flocon de neige. Puis il démissionne et nous bénéficions d'un service orphelin.
Dans le même temps, les tâches du support et du business ne disparaissent pas : elles finissent dans le backlog. S’il y a eu des erreurs architecturales lors du développement du service, elles se retrouvent également dans le backlog. Le service se détériore peu à peu.
Comment identifier un orphelin ?
Cette liste décrit bien la situation. Qui a appris quelque chose sur leur infrastructure ?
À propos des solutions de contournement documentées : il existe un service et, en général, il fonctionne, il contient un manuel de deux pages sur la façon de l'utiliser, mais personne ne sait comment il fonctionne à l'intérieur.
Ou, par exemple, il existe une sorte de raccourcisseur de liens. Par exemple, nous utilisons actuellement trois raccourcisseurs de liens à des fins différentes dans différents services. Ce ne sont que les conséquences.
Désormais, je serai le capitaine de l'évidence. Qu'est-ce qui devrait être fait? Dans un premier temps, il faut transférer le service vers un autre manager, une autre équipe. Si votre chef d'équipe n'a pas encore démissionné, alors dans cette autre équipe, lorsque vous comprenez que le service est comme orphelin, vous devez inclure quelqu'un qui en comprend au moins quelque chose.
L'essentiel : vous devez faire écrire avec du sang les procédures de transfert. Dans notre cas, je surveille généralement cela, car j'ai besoin que tout fonctionne. Les managers ont besoin que ce soit livré rapidement, et ce qui se passe plus tard n'est plus aussi important pour eux.
La prochaine façon de rendre un orphelin est « Nous le ferons en sous-traitance, ce sera plus rapide, puis nous le remettrons à l'équipe. » Il est clair que chacun a des projets dans l'équipe, un tour. Souvent, un client professionnel pense que le sous-traitant fera la même chose que le service technique dont dispose l'entreprise. Bien que leurs motivations soient différentes. Il existe d’étranges solutions technologiques et d’étranges solutions algorithmiques en matière d’externalisation.
Par exemple, nous avions un service qui plaçait Sphinx dans divers endroits inattendus. Je vous dirai plus tard ce que je devais faire.
Les sous-traitants ont des cadres auto-écrits. Il s'agit simplement de PHP pur avec un copier-coller d'un projet précédent, où vous pouvez trouver toutes sortes de choses. Les scripts de déploiement sont un gros inconvénient lorsque vous devez utiliser des scripts Bash complexes pour modifier plusieurs lignes dans un fichier, et ces scripts de déploiement sont appelés par un troisième script. Du coup, vous changez de système de déploiement, choisissez autre chose, hop, mais votre service ne fonctionne pas. Car là il a fallu mettre 8 liens supplémentaires entre différents dossiers. Ou bien il arrive que mille disques fonctionnent, mais que cent mille ne fonctionnent plus.
Je continuerai à être capitaine. Accepter une prestation externalisée est une démarche obligatoire. Quelqu'un a-t-il déjà vu un service externalisé arriver et n'avoir été accepté nulle part ? Ce n'est bien sûr pas aussi populaire qu'un service orphelin, 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ù ils nous ont donné un service, il y a un panneau d'administration "if login == 'admin' && password == 'admin'...", c'est écrit directement dans le code. Nous nous asseyons et réfléchissons, et les gens écrivent ceci en 2018 ?
Tester la capacité de stockage est également une chose nécessaire. Vous devez examiner ce qui se passera sur cent mille enregistrements, avant même de mettre ce service en production quelque part.
Il ne devrait y avoir aucune honte à envoyer un service pour amélioration. Quand vous dites : « Nous n'accepterons pas ce service, nous avons 20 tâches, faites-les, alors nous l'accepterons », c'est normal. Votre conscience ne devrait pas être blessée par le fait que vous nommez un dirigeant ou que l'entreprise gaspille de l'argent. L’entreprise dépensera alors davantage.
Nous avons eu un cas où nous avons décidé d'externaliser un projet pilote.
Il a été livré dans les délais, et c'était le seul critère de qualité. C’est pourquoi nous avons réalisé un autre projet pilote, qui n’était même plus vraiment un pilote. Ces services ont été acceptés, et par voie administrative ils ont dit, voici votre code, voici l'équipe, voici votre manager. Les services ont en fait déjà commencé à générer des bénéfices. En même temps, en fait, ils sont encore orphelins, personne ne comprend comment ils travaillent et les managers font de leur mieux pour renier leurs tâches.
Il existe un autre concept génial : le développement de la guérilla. Lorsqu'un service, généralement le service marketing, souhaite tester une hypothèse et commande l'externalisation de l'intégralité du service. Le trafic commence à y affluer, ils ferment les documents, signent des documents avec l'entrepreneur, entrent en service et disent : « Les mecs, nous avons un service ici, il y a déjà du trafic, ça nous rapporte de l'argent, acceptons-le. Nous nous sommes dit : « Oppa, comment est-ce possible ? »
Et une autre façon d'obtenir un service orphelin : lorsqu'une équipe se retrouve soudainement chargée, la direction dit : « Transférons le service de cette équipe à une autre équipe, elle a une charge plus petite. Et puis nous le transférerons dans une troisième équipe et changerons de manager. Et à la fin, nous nous retrouvons à nouveau orphelins.
Quel est le problème avec les orphelins ?
Qui ne sait pas, il s'agit du cuirassé Wasa élevé en Suède, célèbre pour avoir 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 savaient pas construire de tels navires. Effet naturel.
Le navire aurait d'ailleurs pu couler d'une manière bien pire, par exemple, alors que le roi se trouvait déjà dessus quelque part en pleine tempête. Et donc, il s’est noyé tout de suite, selon Agile c’est bien 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, il a été envoyé pour révision. Mais si nous échouons déjà dans la production, au moment où l’argent est investi, alors des problèmes peuvent survenir. Conséquences, comme on les appelle en affaires.
Pourquoi les services orphelins sont dangereux :
- Le service peut s'interrompre soudainement.
- Le service prend beaucoup de temps à réparer ou n'est pas réparé du tout.
- Problèmes de sécurité.
- Problèmes avec les améliorations et les mises à jour.
- Si un service important tombe en panne, la réputation de l’entreprise en souffre.
Que faire des services orphelins ?
Je vais répéter quoi faire. Premièrement, il doit y avoir de la documentation. 7 ans chez Banki.ru m'ont appris que les testeurs ne doivent pas croire les développeurs sur parole et que les opérations ne doivent pas croire tout le monde sur parole. Nous devons vérifier.
Deuxièmement, il est nécessaire d'écrire des diagrammes d'interaction, car il arrive que des services qui ne sont pas très bien reçus contiennent des dépendances dont personne n'a parlé. Par exemple, les développeurs ont installé le service sur leur clé pour certains Yandex.Maps ou Dadata. Vous avez dépassé la limite gratuite, tout est cassé et vous ne savez pas du tout ce qui s'est passé. Tous ces rakes doivent être décrits : le service utilise Dadata, SMS, autre chose.
Troisièmement, travailler avec la dette technique. Lorsque vous faites une sorte de béquilles ou acceptez un service et dites que quelque chose doit être fait, vous devez vous assurer que cela est fait. Parce qu'alors il se peut que le petit trou ne soit pas si petit et que vous tombiez à travers.
Avec les tâches architecturales, nous avons eu une histoire sur le Sphinx. L'un des services utilisait Sphinx pour saisir des listes. Juste une liste paginée, mais elle était réindexée tous les soirs. Il était assemblé à partir de deux index : un grand index était indexé chaque nuit, et il y avait aussi un petit index qui y était vissé. Chaque jour, avec une probabilité de 50 % qu'il y ait un bombardement ou non, l'index s'est écrasé pendant le calcul et nos actualités ont cessé de se mettre à jour sur la page principale. Au début, la réindexation de l'index prenait 5 minutes, puis l'index a augmenté et, à un moment donné, la réindexation a commencé à prendre 40 minutes. Lorsque nous avons supprimé cela, nous avons poussé un soupir de soulagement, car il était clair qu'un peu plus de temps s'écoulerait et que notre index serait réindexé à plein temps. Ce sera un échec pour notre portail, il n'y a pas de nouvelles pendant huit heures, ça y est, les affaires sont arrêtées.
Plan pour travailler avec un service orphelin
En fait, c’est très difficile à faire, car le DevOps est une question de communication. Vous voulez être en bons termes avec vos collègues, et lorsque vous frappez vos collègues et vos managers avec des réglementations, ils peuvent avoir des sentiments contradictoires à l'égard de ceux qui font cela.
À tous ces points s'ajoute une autre chose importante : des personnes spécifiques doivent être responsables de chaque service spécifique, de chaque section spécifique de la procédure de déploiement. Lorsqu’il n’y a personne et qu’il faut attirer d’autres personnes pour étudier toute cette question, cela devient difficile.
Si tout cela n'a pas aidé et que votre service orphelin est toujours orphelin, personne ne veut le prendre en charge, la documentation n'est pas écrite, l'équipe qui a été appelée dans ce service refuse de faire quoi que ce soit, il existe un moyen simple : refaire tout.
Autrement dit, vous reprenez les exigences du service et écrivez un nouveau service, meilleur, sur une meilleure plate-forme, sans solutions technologiques étranges. Et vous y migrez au combat.
Nous avons eu une situation où nous avons pris un service sur Yii 1 et avons réalisé que nous ne pouvions pas le développer davantage, car nous manquions de développeurs capables de bien écrire sur Yii 1. Tous les développeurs écrivent bien sur Symfony XNUMX. Ce qu'il faut faire? Nous avons alloué du temps, alloué une équipe, affecté un responsable, réécrit le projet et y avons 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 prendre et nettoyer un service du système de gestion de configuration, puis vérifier que toutes les voitures en production ont été désactivées, afin que les développeurs n'aient plus aucune trace. Le référentiel reste dans Git.
C'est tout ce dont je voulais parler, je suis prêt à en discuter, le sujet est holivar, beaucoup s'y sont baignés.
Les diapositives disaient que vous aviez unifié les langues. Un exemple était le redimensionnement des images. Est-il vraiment nécessaire de le limiter strictement à une seule langue ? Parce que le redimensionnement d’image en PHP pourrait en fait être effectué en Golang.
En fait, c’est facultatif, comme toutes les pratiques. Peut-être que dans certains cas, cela n’est même pas souhaitable. Mais il faut comprendre que si vous avez un service technique dans une entreprise de 50 personnes, 45 d'entre eux sont des spécialistes PHP, 3 autres sont des développeurs qui connaissent Python, Ansible, Puppet et quelque chose comme ça, et un seul d'entre eux écrit dans certains sorte de langage. Un service de redimensionnement d'image Go, puis quand il part, l'expertise l'accompagne. Et en parallèle, 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 développeurs, vous n'aurez pas seulement besoin de cloner un ensemble de playbooks prêts à l'emploi que vous utilisez pour déployer des services, mais vous devrez tout réécrire.
Nous construisons actuellement un service sur Node.js, et ce ne sera qu'une plate-forme à proximité pour chaque développeur avec un langage distinct. Mais nous nous sommes assis et avons pensé que le jeu en valait la chandelle. Autrement dit, c’est une question à laquelle vous devez vous asseoir et réfléchir.
Comment contrôlez-vous vos services ? Comment collectez-vous et surveillez-vous les journaux ?
Nous collectons les logs dans Elasticsearch et les mettons dans Kibana, et selon qu'il s'agit d'environnements de production ou de test, différents collecteurs y sont utilisés. Quelque part Bûcheron, ailleurs autre chose, je ne me souviens plus. Et il y a encore des endroits dans certains services où nous installons Telegraf et tournons ailleurs séparément.
Comment vivre avec Puppet et Ansible dans le même environnement ?
En fait, nous avons désormais deux environnements, l’un est Puppet, l’autre est Ansible. Nous travaillons à les hybrider. Ansible est un bon framework pour la configuration initiale, Puppet est un mauvais framework pour la configuration initiale car il nécessite un travail pratique directement sur la plateforme, et Puppet assure la convergence de la configuration. Cela signifie que la plate-forme se maintient à jour et que pour que la machine ansibilisée soit maintenue à jour, vous devez y exécuter des playbooks à tout moment et avec une certaine fréquence. C'est la différence.
Comment maintenir la compatibilité ? Avez-vous des configurations dans Ansible et Puppet ?
C'est notre grande douleur, nous maintenons la compatibilité avec nos mains et réfléchissons à la manière de sortir de tout cela quelque part maintenant. Il s'avère que Puppet déploie des packages et y maintient certains liens, et Ansible, par exemple, y déploie le code et y ajuste les dernières configurations d'application.
La présentation portait sur différentes versions de Ruby. Quelle solution?
Nous avons rencontré cela à un endroit et nous devons le garder en tête tout le temps. Nous avons simplement désactivé la partie exécutée sur Ruby qui était incompatible avec les applications et l'avons gardée séparée.
La conférence de cette année aura lieu le 7 décembre à Technopolis. Nous acceptons les demandes de rapports jusqu'au 11 novembre. nous si vous souhaitez parler.
Les inscriptions des participants sont ouvertes, rejoignez-nous !
Source: habr.com