{"id":38981,"date":"2019-10-31T22:27:10","date_gmt":"2019-10-31T19:27:10","guid":{"rendered":"https:\/\/prohoster.info\/blog\/servisy-siroty-obratnaya-storona-mikro-servisnoj-arhitektury\/"},"modified":"2019-10-31T22:27:10","modified_gmt":"2019-10-31T19:27:10","slug":"servisy-siroty-obratnaya-storona-mikro-servisnoj-arhitektury","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/servisy-siroty-obratnaya-storona-mikro-servisnoj-arhitektury","title":{"rendered":"Services orphelins : le revers de l'architecture (micro)services","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Le directeur de l'exploitation du portail Banki.ru, Andre\u00ef Nikolsky, a pris la parole lors de la conf\u00e9rence de l'ann\u00e9e derni\u00e8re DevOpsDays Moscou<\/a><\/noindex> 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.<\/p>\n

Sous ce lien, la version textuelle de la pr\u00e9sentation. <\/p>\n

\r\n \"Lire\r\n
<\/div>\r\n <\/div><\/center><\/a><\/noindex>
\nBonjour coll\u00e8gues ! Je m'appelle Andre\u00ef, je dirige l'exploitation chez Banki.ru.<\/p>\n

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. <\/p>\n

Les avantages des services<\/b><\/h3>\n

\nJe vais passer rapidement en revue les avantages des services. <\/p>\n

\"Services
\n
\nLe premier avantage est l'\u00e9volutivit\u00e9. 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 \u00e0 g\u00e9rer cela. C\u2019est un bon bonus, et en fait, lorsque nous avons commenc\u00e9, c\u2019\u00e9tait consid\u00e9r\u00e9 comme le plus important : pourquoi faisons-nous tout cela ?<\/p>\n

\"Services
\n
\nDeuxi\u00e8mement, le d\u00e9veloppement isol\u00e9, lorsque vous avez plusieurs \u00e9quipes de d\u00e9veloppement, plusieurs d\u00e9veloppeurs diff\u00e9rents dans chaque \u00e9quipe, et chaque \u00e9quipe construit son propre service.<\/p>\n

Il y a un aspect \u00e0 consid\u00e9rer avec les \u00e9quipes. Les d\u00e9veloppeurs peuvent \u00eatre tr\u00e8s diff\u00e9rents. Par exemple, les gens flocons<\/a><\/noindex>. J'ai vu cela pour la premi\u00e8re fois chez Maxim Dorofeev. Parfois, il y a des gens flocons dans certaines \u00e9quipes, mais pas dans d'autres. Cela rend les diff\u00e9rents services utilis\u00e9s dans l'entreprise un peu d\u00e9s\u00e9quilibr\u00e9s. <\/p>\n

\"Services
\n
\nRegardez cette image : c'est un bon d\u00e9veloppeur, il a de grandes mains, il peut faire beaucoup de choses. Le principal probl\u00e8me est de savoir d'o\u00f9 viennent ces mains. <\/p>\n

\"Services
\n
\nLes services permettent d'utiliser diff\u00e9rents langages de programmation, plus adapt\u00e9s \u00e0 diff\u00e9rentes t\u00e2ches. 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'\u00e9tendre tr\u00e8s largement. Il y a aussi des nuances ici.<\/p>\n

\"Services
\n
\nL'architecture orient\u00e9e services concerne avant tout le devops. Cela signifie que si vous n'avez pas d'automatisation, pas de processus de d\u00e9ploiement, si vous configurez manuellement, vos configurations peuvent changer d'une instance de service \u00e0 une autre, et vous devez vous y connecter pour faire quelque chose, alors vous \u00eates dans l'enfer. <\/p>\n

Par exemple, vous avez 20 services, et vous devez d\u00e9ployer manuellement, vous avez 20 consoles, et vous appuyez simultan\u00e9ment sur \u00ab entrer \u00bb comme un ninja. Ce n'est pas tr\u00e8s bien. <\/p>\n

Si votre service apr\u00e8s les tests (s'il y a des tests, bien s\u00fbr) n\u00e9cessite encore quelques ajustements pour fonctionner en production, j'ai \u00e9galement de mauvaises nouvelles pour vous. <\/p>\n

Si vous d\u00e9pendez de services sp\u00e9cifiques d'Amazon et que vous travaillez en Russie, alors il y a deux mois, vous aviez aussi \u00ab Tout autour br\u00fble, je vais bien, tout est super \u00bb.<\/p>\n

\"Services
\n
\nNous utilisons Ansible pour automatiser le d\u00e9ploiement, Puppet pour la convergence, Bamboo pour automatiser le d\u00e9ploiement, Confluence pour essayer de documenter tout cela.<\/p>\n

Je ne vais pas m'attarder longuement l\u00e0-dessus, car la pr\u00e9sentation concerne plut\u00f4t les pratiques d'interaction que la mise en \u0153uvre technique. <\/p>\n

\"Services
\n
\nNous avons par exemple eu des probl\u00e8mes o\u00f9 Puppet sur le serveur fonctionne avec Ruby 2, tandis qu'une certaine application est \u00e9crite pour Ruby 1.8, et ils ne fonctionnent pas ensemble. \u00c7a coince. Et lorsque vous devez maintenir plusieurs versions de Ruby sur une seule machine, vous commencez g\u00e9n\u00e9ralement \u00e0 avoir des probl\u00e8mes. <\/p>\n

Par exemple, nous fournissons \u00e0 chaque d\u00e9veloppeur une plateforme o\u00f9 se trouve presque tout ce que nous avons, tous les services que l'on peut d\u00e9velopper, afin qu'il ait un environnement isol\u00e9 o\u00f9 il peut l'endommager et le construire comme il le souhaite. <\/p>\n

Il arrive qu'un paquet sp\u00e9cialement compil\u00e9 avec support pour quelque chose soit n\u00e9cessaire. C'est assez strict. J'ai \u00e9cout\u00e9 une pr\u00e9sentation o\u00f9 l'image Docker p\u00e8se 45 Go. Sous Linux, bien s\u00fbr, c'est plus simple, tout est plus l\u00e9ger, mais il n'y aura quand m\u00eame pas assez de place. <\/p>\n

Et il y a des d\u00e9pendances contradictoires, lorsque vous avez une partie du projet qui d\u00e9pend d'une biblioth\u00e8que d'une version, et une autre partie du projet d'une autre version, et les biblioth\u00e8ques ne peuvent absolument pas \u00eatre install\u00e9es ensemble. <\/p>\n

\"Services
\n
\nNous 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\u00e9veloppeur a sa propre base o\u00f9 il est heureux de faire des modifications. <\/p>\n

Si vous travaillez dans une entreprise avec un m\u00eame langage, avoir trois machines virtuelles par d\u00e9veloppeur semble raisonnable. Si vous utilisez diff\u00e9rents langages de programmation, la situation se complique.<\/p>\n

\"Services
\n
\nVous vous retrouvez avec des sites et des services ici, l\u00e0, puis une plateforme pour Go, une pour Ruby, et un Redis \u00e0 c\u00f4t\u00e9. Au final, tout cela devient un vaste champ de support o\u00f9 quelque chose peut toujours tomber en panne.<\/p>\n

\"Services
\n
\nC'est pourquoi nous avons remplac\u00e9 les avantages du langage de programmation par l'utilisation de diff\u00e9rents frameworks, car les frameworks PHP sont assez vari\u00e9s, ayant des capacit\u00e9s, des communaut\u00e9s et des supports diff\u00e9rents. Et vous pouvez \u00e9crire un service de mani\u00e8re \u00e0 ce qu'il y ait d\u00e9j\u00e0 quelque chose de pr\u00eat pour lui. <\/p>\n

Chaque service a sa propre \u00e9quipe.<\/b><\/h3>\n

\n\"Services
\n
\nNotre principal avantage, qui s'est crystallis\u00e9 au fil des ans, est que chaque service a sa propre \u00e9quipe. C'est pratique pour un grand projet, cela permet d'\u00e9conomiser du temps sur la documentation, les managers connaissent bien leur projet. <\/p>\n

Les t\u00e2ches de support peuvent \u00eatre facilement confi\u00e9es. Par exemple, si le service d'assurance tombe en panne. Et imm\u00e9diatement, l'\u00e9quipe qui s'occupe de l'assurance va le r\u00e9parer. <\/p>\n

De nouvelles fonctionnalit\u00e9s peuvent \u00eatre mises en \u0153uvre rapidement, car lorsque vous avez un petit service atomique, vous pouvez y int\u00e9grer rapidement quelque chose. <\/p>\n

Et lorsque votre service tombe en panne, ce qui arrive in\u00e9vitablement, vous n'affectez pas les services des autres, et les d\u00e9veloppeurs des autres \u00e9quipes ne viennent pas en se plaignant : \u00ab Attention, ne faites pas cela \u00bb. <\/p>\n

\"Services
\n
\nComme toujours, il y a des nuances. Nos \u00e9quipes sont stables, les managers sont solidement attach\u00e9s \u00e0 l'\u00e9quipe. Il existe des documents clairs, les managers veillent attentivement \u00e0 tout cela. Chaque \u00e9quipe a plusieurs services avec un manager et un domaine de comp\u00e9tence sp\u00e9cifique. <\/p>\n

Si les \u00e9quipes sont fluides (ce qui arrive parfois chez nous), il existe une bonne m\u00e9thode appel\u00e9e \u00ab carte des \u00e9toiles \u00bb.<\/p>\n

\"Services
\n
\nVous avez une liste de services et de personnes. Une \u00e9toile signifie qu'une personne est experte dans ce service, un livre signifie qu'une personne \u00e9tudie ce service. L'objectif pour une personne est de changer le livre en \u00e9toile. Si rien n'est inscrit en face d'un service, des probl\u00e8mes commencent \u00e0 surgir, dont je vais parler plus en d\u00e9tail. <\/p>\n

Comment apparaissent les services orphelins ?<\/b><\/h3>\n

\n\"Services
\n
\nLe premier probl\u00e8me, la premi\u00e8re fa\u00e7on d'avoir un service orphelin dans votre infrastructure, c'est le licenciement de personnes. Est-ce que quelqu'un a d\u00e9j\u00e0 connu des d\u00e9lais serr\u00e9s arrivant avant que les t\u00e2ches ne soient \u00e9valu\u00e9es ? Parfois, les d\u00e9lais sont si serr\u00e9s qu'il n'y a tout simplement pas de temps pour la documentation. \u00ab Il faut livrer le service en production, nous compl\u00e9terons ensuite. \u00bb <\/p>\n

Si l'\u00e9quipe est petite, il arrive qu'il n'y ait qu'un seul d\u00e9veloppeur qui \u00e9crit tout, les autres sont en soutien. \u00ab J'ai \u00e9crit l'architecture principale, tu peux te charger des interfaces. \u00bb Ensuite, \u00e0 un moment donn\u00e9, le manager, par exemple, part. Et durant cette p\u00e9riode, pendant que le manager est parti et qu'aucun nouveau n'est encore nomm\u00e9, les d\u00e9veloppeurs d\u00e9cident eux-m\u00eames de la direction du service, de ce qui se passe. Et comme nous le savons (revenons \u00e0 quelques diapositives en arri\u00e8re), dans certaines \u00e9quipes, il y a des personnes uniques, parfois un leader unique. Puis, il part, et nous nous retrouvons avec un service orphelin. <\/p>\n

\"Services
\n
\nCependant, les t\u00e2ches provenant du support et des affaires n'ont pas disparu, elles s'accumulent dans le backlog. Si des erreurs architecturales ont \u00e9t\u00e9 commises lors du d\u00e9veloppement du service, elles s'accumulent \u00e9galement dans le backlog. Le service se d\u00e9grade lentement. <\/p>\n

Comment identifier un orphelin ?<\/b> <\/h3>\n

\nCette liste d\u00e9crit assez bien la situation. Qui a reconnu quelque chose d'\u00e9quivalent dans son infrastructure ?<\/p>\n

\"Services
\n
\nConcernant les work-arounds document\u00e9s : il y a un service et, en gros, il fonctionne, il a un manuel de deux pages sur la fa\u00e7on de travailler avec lui, mais personne ne sait comment il fonctionne \u00e0 l'int\u00e9rieur. <\/p>\n

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\u00e9rents objectifs dans diff\u00e9rents services. Ce sont pr\u00e9cis\u00e9ment les cons\u00e9quences. <\/p>\n

\"Services
\n
\nMaintenant, je vais devenir le capitaine de l'\u00e9vidence. Que faut-il faire ? Tout d'abord, il faut transmettre le service \u00e0 un autre manager, \u00e0 une autre \u00e9quipe. Si votre leader n'est pas encore parti, alors dans cette autre \u00e9quipe, lorsque vous r\u00e9alisez que le service ressemble \u00e0 un orphelin, il faut inclure quelqu'un qui comprend au moins un peu le service. <\/p>\n

La chose principale : vous devez avoir des proc\u00e9dures de transfert bien d\u00e9finies. Dans notre cas, je surveille cela g\u00e9n\u00e9ralement, car j'ai besoin que tout cela fonctionne. Les managers veulent que cela soit livr\u00e9 rapidement, et ce qui va se passer ensuite, cela les pr\u00e9occupe moins. <\/p>\n

\"Services
\n
\nUne autre fa\u00e7on de cr\u00e9er une application orpheline est de se dire : \u00ab Nous allons externaliser, ce sera plus rapide, et ensuite nous le passerons \u00e0 l'\u00e9quipe \u00bb. Il est clair que chacun a ses propres plans au sein de l'\u00e9quipe, une certaine file d'attente. Souvent, le client commercial pense que l'externaliseur fera les choses de la m\u00eame mani\u00e8re que le service technique de l'entreprise. Pourtant, leurs motivations sont diff\u00e9rentes. Les externaliseurs peuvent avoir des solutions technologiques \u00e9tranges et des approches algorithmiques inhabituelles.<\/p>\n

\"Services
\n
\nPar exemple, nous avions un service qui utilisait Sphinx \u00e0 des endroits inattendus. J'en dirai plus tard sur ce qu'il a fallu faire. <\/p>\n

Les externaliseurs peuvent avoir des frameworks maison. C'est juste du PHP brut avec du copi\u00e9-coll\u00e9 d'un projet pr\u00e9c\u00e9dent, o\u00f9 l'on trouve de tout. Il y a de gros b\u00e9tons dans les scripts de d\u00e9ploiement, lorsque vous devez modifier plusieurs lignes dans un fichier via des scripts Bash complexes, ces scripts de d\u00e9ploiement \u00e9tant appel\u00e9s par un autre script. En fin de compte, vous changez le syst\u00e8me de d\u00e9ploiement, vous choisissez autre chose, et hop, votre service ne fonctionne plus. Parce qu'il fallait encore ajouter 8 liens entre diff\u00e9rents dossiers. Ou il arrive qu'un millier d'enregistrements fonctionne, mais pas cent mille. <\/p>\n

Je continue \u00e0 diriger. L'acceptation d'un service d'externalisation est une proc\u00e9dure obligatoire. Qui a d\u00e9j\u00e0 v\u00e9cu un cas o\u00f9 un service d'externalisation arrive et n'est accept\u00e9 nulle part ? Ce n'est pas aussi courant, bien s\u00fbr, que le service orphelin, mais tout de m\u00eame. <\/p>\n

\"Services
\n
\nIl est n\u00e9cessaire de v\u00e9rifier le service, d'examiner le service et de changer les mots de passe. Nous avons eu un cas o\u00f9 on nous a pr\u00e9sent\u00e9 un service, dans lequel l'interface admin contenait \u00ab if login == 'admin' && password == 'admin'\u2026 \u00bb, \u00e9crit directement dans le code. Nous sommes assis l\u00e0 \u00e0 r\u00e9fl\u00e9chir, et c'est ce que les gens \u00e9crivent en 2018 ?<\/p>\n

Tester la capacit\u00e9 de stockage est \u00e9galement n\u00e9cessaire. Il faut voir ce qui se passera avec cent mille enregistrements, m\u00eame avant de mettre ce service en production. <\/p>\n

\"Services
\n
\nIl ne faut pas avoir honte d'envoyer un service en r\u00e9vision. Quand vous dites : \u00ab Nous n'accepterons pas ce service, nous avons 20 t\u00e2ches, faites-les, et alors nous l'accepterons \u00bb, c'est normal. La conscience ne doit pas vous peser car vous exposez un manager ou que l'entreprise d\u00e9pense de l'argent. En fin de compte, l'entreprise d\u00e9pensera plus apr\u00e8s.<\/p>\n

Nous avons eu un cas o\u00f9 nous avons d\u00e9cid\u00e9 de lancer un projet pilote en externalisation.<\/p>\n

\"Services
\n
\nIl a \u00e9t\u00e9 livr\u00e9 \u00e0 temps, et c'\u00e9tait le seul crit\u00e8re de qualit\u00e9. C'est pourquoi un autre projet pilote a \u00e9t\u00e9 r\u00e9alis\u00e9, qui n'\u00e9tait m\u00eame plus tout \u00e0 fait pilote. Ces services ont \u00e9t\u00e9 accept\u00e9s, par des moyens administratifs on a dit : voici votre code, voil\u00e0 l'\u00e9quipe, voici votre responsable. Les services ont r\u00e9ellement commenc\u00e9 \u00e0 g\u00e9n\u00e9rer des revenus. Pourtant, ils sont rest\u00e9s des orphelins, personne ne comprend comment ils fonctionnent, et les responsables se d\u00e9filent de leurs t\u00e2ches. <\/p>\n

\"Services
\n
\nIl y a encore un autre concept int\u00e9ressant : le d\u00e9veloppement clandestin. Quand un certain d\u00e9partement, g\u00e9n\u00e9ralement celui du marketing, veut tester une hypoth\u00e8se et commande un service entier en sous-traitance. Le trafic commence \u00e0 affluer, ils finalisent les documents, signent des actes avec le contractant, passent en exploitation et disent : \u00ab Les gars, nous avons ici un service, il a d\u00e9j\u00e0 du trafic, il nous rapporte de l'argent, acceptons-le \u00bb. Nous sommes l\u00e0 : \u00ab Oh l\u00e0 l\u00e0, comment est-ce possible ? \u00bb<\/p>\n

\"Services
\n
\nEt encore une fa\u00e7on d'obtenir un service orphelin : lorsque l'une des \u00e9quipes se retrouve soudainement surcharg\u00e9e, la direction dit : \u00ab Transf\u00e9rons ce service de cette \u00e9quipe \u00e0 une autre \u00e9quipe, qui a moins de charge de travail \u00bb. Et ensuite, nous transf\u00e9rons \u00e0 une troisi\u00e8me \u00e9quipe et changeons le responsable. Et au final, nous avons encore un orphelin.<\/p>\n

Quel est le probl\u00e8me avec les orphelins ?<\/b><\/h3>\n

\n\"Services
\n
\nPour ceux qui ne le savent pas, il s'agit du navire de ligne Wasa, construit en Su\u00e8de, c\u00e9l\u00e8bre pour avoir coul\u00e9 cinq minutes apr\u00e8s son lancement. Et le roi de Su\u00e8de, d'ailleurs, n'a ex\u00e9cut\u00e9 personne pour cela. Il a \u00e9t\u00e9 construit par deux g\u00e9n\u00e9rations d'ing\u00e9nieurs qui ne savaient pas construire de tels navires. Un effet pr\u00e9visible.<\/p>\n

Le navire aurait pu couler, d'ailleurs, beaucoup plus mal, par exemple lorsque le roi serait d\u00e9j\u00e0 \u00e0 bord en pleine temp\u00eate. Ainsi, il a coul\u00e9 imm\u00e9diatement, ce qui est bon en agile \u2014 \u00e9chouer t\u00f4t. <\/p>\n

Si nous avons \u00e9chou\u00e9 t\u00f4t, il n'y a g\u00e9n\u00e9ralement pas de probl\u00e8mes. Par exemple, lors de la r\u00e9ception, nous avons envoy\u00e9 pour retouches. Mais si nous \u00e9chouons d\u00e9j\u00e0 en production, lorsque des investissements ont \u00e9t\u00e9 r\u00e9alis\u00e9s, cela peut poser des probl\u00e8mes. Des cons\u00e9quences, comme on les appelle dans le monde des affaires.<\/p>\n

Quels sont les dangers des services orphelins :<\/p>\n