HighLoad++, Evgeniy Kuzovlev (EcommPay IT) : que faire lorsqu'une minute d'arrêt coûte 100000 XNUMX $

Tout le monde parle des processus de développement et de test, de formation du personnel, d'augmentation de la motivation, mais ces processus ne suffisent pas lorsqu'une minute d'arrêt de service coûte d'énormes sommes d'argent. Que faire lorsque vous effectuez des transactions financières dans le cadre d’un SLA strict ? Comment augmenter la fiabilité et la tolérance aux pannes de vos systèmes, en éliminant le développement et les tests de l'équation ?

La prochaine conférence HighLoad++ se tiendra les 6 et 7 avril 2020 à Saint-Pétersbourg. Détails et billets sur lien. 9 novembre, 18h00. HighLoad++ Moscou 2018, salle Delhi + Kolkata. Thèses et présentation.

Evgeniy Kuzovlev (ci-après – CE) : - Les amis, bonjour ! Je m'appelle Kuzovlev Evgeniy. Je suis de la société EmmPay, une division spécifique est EmmPay IT, la division informatique du groupe de sociétés. Et aujourd'hui, nous parlerons des temps d'arrêt - de la manière de les éviter, de la manière de minimiser leurs conséquences s'ils ne peuvent être évités. Le sujet est énoncé comme suit : « Que faire lorsqu'une minute d'arrêt coûte 100 000 $ » ? Pour l’avenir, nos chiffres sont comparables.

Que fait EcomPay IT ?

Qui sommes nous? Pourquoi je me tiens ici devant toi ? Pourquoi ai-je le droit de vous dire quelque chose ici ? Et de quoi parlerons-nous ici plus en détail ?

Le groupe de sociétés EmmPay est un acquéreur international. Nous traitons les paiements partout dans le monde – en Russie, en Europe, en Asie du Sud-Est (partout dans le monde). Nous avons 9 bureaux, 500 employés au total, et environ un peu moins de la moitié d'entre eux sont des informaticiens. Tout ce que nous faisons, tout ce qui nous rapporte de l’argent, nous l’avons fait nous-mêmes.

Nous avons écrit nous-mêmes tous nos produits (et nous en avons un grand nombre - dans notre gamme de grands produits informatiques, nous avons environ 16 composants différents) ; On s'écrit, on se développe. Et à l’heure actuelle, nous effectuons environ un million de transactions par jour (des millions est probablement la bonne façon de le dire). Nous sommes une entreprise relativement jeune – nous n’avons que six ans environ.

Il y a 6 ans, c'était une telle startup lorsque les gars se sont lancés dans l'entreprise. Ils étaient unis par une idée (il n’y avait rien d’autre qu’une idée) et nous avons couru. Comme toute startup, nous avons couru plus vite... Pour nous, la rapidité était plus importante que la qualité.

À un moment donné, nous nous sommes arrêtés : nous avons réalisé que nous ne pouvions plus vivre à cette vitesse et avec cette qualité et que nous devions d’abord nous concentrer sur la qualité. À ce moment-là, nous avons décidé d'écrire une nouvelle plateforme qui serait correcte, évolutive et fiable. Ils ont commencé à écrire cette plateforme (ils ont commencé à investir, à développer, à tester), mais à un moment donné, ils ont réalisé que le développement et les tests ne nous permettaient pas d'atteindre un nouveau niveau de qualité de service.

Vous fabriquez un nouveau produit, vous le mettez en production, mais quelque chose va quand même mal quelque part. Et aujourd'hui, nous parlerons de la manière d'atteindre un nouveau niveau de qualité (comment nous y sommes parvenus, de notre expérience), en excluant le développement et les tests de l'équation ; nous parlerons de ce qui est disponible pour l'exploitation - de ce que l'exploitation peut faire elle-même, de ce qu'elle peut offrir aux tests afin d'influencer la qualité.

Temps d'arrêt. Commandements de fonctionnement.

Toujours la pierre angulaire, ce dont nous parlerons aujourd’hui est le temps d’arrêt. Un mot terrible. Si nous avons des temps d’arrêt, tout va mal pour nous. Nous courons pour le relever, les administrateurs tiennent le serveur - Dieu nous préserve qu'il ne tombe pas, comme le chante cette chanson. C'est de cela dont nous parlerons aujourd'hui.

Lorsque nous avons commencé à changer nos approches, nous avons formé 4 commandements. Je les ai présentés sur les slides :

Ces commandements sont assez simples :

• Identifiez rapidement le problème.
• Débarrassez-vous-en encore plus rapidement.
• Aidez à comprendre la raison (plus tard, pour les développeurs).
• Et standardiser les approches.

Je voudrais attirer votre attention sur le point n°2. Nous nous débarrassons du problème, nous ne le résolvons pas. Décider est secondaire. Pour nous, l’essentiel est que l’utilisateur soit protégé de ce problème. Il existera dans un environnement isolé, mais cet environnement n'aura aucun contact avec lui. En fait, nous passerons en revue ces quatre groupes de problèmes (certains plus en détail, d'autres moins), je vous dirai ce que nous utilisons, quelle expérience pertinente nous avons en matière de solutions.

Dépannage : quand surviennent-ils et que faire à leur sujet ?

Mais commençons dans le désordre, commençons par le point n°2 : comment se débarrasser rapidement du problème ? Il y a un problème – nous devons le résoudre. "Que devons-nous faire à ce sujet?" - la question principale. Et lorsque nous avons commencé à réfléchir à la manière de résoudre le problème, nous avons élaboré nous-mêmes certaines exigences que le dépannage doit suivre.

Pour formuler ces exigences, nous avons décidé de nous poser la question : « Quand avons-nous des problèmes » ? Et il s'est avéré que les problèmes surviennent dans quatre cas :

• Défaillance matérielle.
• Les services externes ont échoué.
• Changement de version du logiciel (même déploiement).
• Croissance de charge explosive.

Nous ne parlerons pas des deux premiers. Un dysfonctionnement matériel peut être résolu tout simplement : il faut que tout soit dupliqué. S'il s'agit de disques, les disques doivent être assemblés en RAID ; s'il s'agit d'un serveur, le serveur doit être dupliqué ; si vous disposez d'une infrastructure réseau, vous devez fournir une deuxième copie de l'infrastructure réseau, c'est-à-dire que vous la prenez et dupliquez-le. Et si quelque chose tombe en panne, vous passez en réserve de puissance. Il est difficile d’en dire plus ici.

La seconde est l’échec des services externes. Pour la plupart, le système ne pose aucun problème, mais pas pour nous. Puisque nous traitons les paiements, nous sommes un agrégateur qui se situe entre l'utilisateur (qui saisit les données de sa carte) et les banques, les systèmes de paiement (Visa, MasterCard, Mira, etc.). Nos services externes (systèmes de paiement, banques) ont tendance à échouer. Ni nous ni vous (si vous disposez de tels services) ne pouvons influencer cela.

Que faire alors ? Il y a deux options ici. Tout d’abord, si vous le pouvez, vous devez dupliquer ce service d’une manière ou d’une autre. Par exemple, si nous le pouvons, nous transférons le trafic d'un service à un autre : par exemple, les cartes ont été traitées via la Sberbank, la Sberbank a des problèmes - nous transférons le trafic [sous condition] vers Raiffeisen. La deuxième chose que nous pouvons faire est de constater très rapidement la défaillance des services externes, c'est pourquoi nous parlerons de la rapidité de réponse dans la prochaine partie du rapport.

En fait, parmi ces quatre, nous pouvons spécifiquement influencer le changement de versions logicielles - prendre des actions qui conduiront à une amélioration de la situation dans le contexte des déploiements et dans le contexte d'une croissance explosive de la charge. En fait, c'est ce que nous avons fait. Là encore, une petite note...

Parmi ces quatre problèmes, plusieurs sont résolus immédiatement si vous disposez d’un cloud. Si vous êtes dans les nuages ​​Microsoft Azhur, Ozone, ou utilisez nos nuages, depuis Yandex ou Mail, alors au moins un dysfonctionnement matériel devient leur problème et tout se passe immédiatement bien pour vous dans le contexte d'un dysfonctionnement matériel.

Nous sommes une entreprise légèrement non conventionnelle. Ici, tout le monde parle de « Kubernets », de nuages ​​- nous n'avons ni « Kubernets » ni nuages. Mais nous avons des racks de matériel dans de nombreux centres de données, et nous sommes obligés de vivre avec ce matériel, nous sommes obligés d'être responsables de tout cela. Nous parlerons donc dans ce contexte. Donc, à propos des problèmes. Les deux premiers ont été retirés des parenthèses.

Modification de la version du logiciel. Socles

Nos développeurs n'ont pas accès à la production. Pourquoi donc? C'est juste que nous sommes certifiés PCI DSS, et nos développeurs n'ont tout simplement pas le droit d'entrer dans le « produit ». C'est tout, point final. Du tout. Par conséquent, la responsabilité du développement prend fin exactement au moment où le développement soumet la version pour publication.

Notre deuxième base, qui nous aide également beaucoup, est l'absence de connaissances uniques et non documentées. J'espère que c'est pareil pour toi. Car si ce n’est pas le cas, vous aurez des problèmes. Des problèmes surgiront lorsque ces connaissances uniques et non documentées ne seront pas présentes au bon moment et au bon endroit. Disons que vous avez une personne qui sait déployer un composant spécifique - la personne n'est pas là, elle est en vacances ou malade - ça y est, vous avez des problèmes.

Et la troisième base à laquelle nous sommes arrivés. Nous y sommes arrivés à travers la douleur, le sang, les larmes - nous sommes arrivés à la conclusion que chacune de nos versions contient des erreurs, même si elle est exempte d'erreurs. Nous l'avons décidé nous-mêmes : lorsque nous déployons quelque chose, lorsque nous mettons quelque chose en production, nous avons une version avec des erreurs. Nous avons formé les exigences auxquelles notre système doit satisfaire.

Conditions requises pour changer la version du logiciel

Il y a trois exigences :

• Nous devons rapidement annuler le déploiement.
• Nous devons minimiser l’impact d’un déploiement infructueux.
• Et nous devons pouvoir nous déployer rapidement en parallèle.
  Exactement dans cet ordre ! Pourquoi? Parce que, tout d'abord, lors du déploiement d'une nouvelle version, la vitesse n'est pas importante, mais il est important pour vous, en cas de problème, de revenir rapidement en arrière et d'avoir un impact minimal. Mais si vous avez un ensemble de versions en production, pour lesquelles il s'avère qu'il y a une erreur (à l'improviste, il n'y a pas eu de déploiement, mais il y a une erreur) - la vitesse de déploiement ultérieur est importante pour vous. Qu'avons-nous fait pour répondre à ces demandes ? Nous avons eu recours à la méthodologie suivante :

  
  
  C'est bien connu, nous ne l'avons jamais inventé - c'est le déploiement Bleu/Vert. Ce que c'est? Vous devez disposer d'une copie pour chaque groupe de serveurs sur lesquels vos applications sont installées. La copie est « chaude » : il n'y a pas de trafic dessus, mais à tout moment ce trafic peut être envoyé vers cette copie. Cette copie contient la version précédente. Et au moment du déploiement, vous déployez le code sur une copie inactive. Ensuite, vous basculez une partie du trafic (ou la totalité) vers la nouvelle version. Ainsi, pour modifier le flux de trafic de l'ancienne version à la nouvelle, vous ne devez effectuer qu'une seule action : vous devez changer l'équilibreur en amont, changer la direction - d'un amont à l'autre. Ceci est très pratique et résout le problème de la commutation rapide et de la restauration rapide.

  Ici, la solution à la deuxième question est la minimisation : vous ne pouvez envoyer qu'une partie de votre trafic vers une nouvelle ligne, vers une ligne avec un nouveau code (que ce soit, par exemple, 2 %). Et ces 2% ne sont pas 100% ! Si vous avez perdu 100 % de votre trafic à cause d’un déploiement infructueux, c’est effrayant ; si vous avez perdu 2 % de votre trafic, c’est désagréable, mais ce n’est pas effrayant. De plus, les utilisateurs ne le remarqueront probablement même pas, car dans certains cas (pas dans tous), le même utilisateur, en appuyant sur F5, sera redirigé vers une autre version fonctionnelle.

  Déploiement bleu/vert. Routage

  Cependant, tout n’est pas si simple « Déploiement Bleu/Vert »… Tous nos composants peuvent être divisés en trois groupes :

  • c'est le frontend (pages de paiement que nos clients voient) ;
  • noyau de traitement;
  • adaptateur pour travailler avec les systèmes de paiement (banques, MasterCard, Visa...).

  Et il y a une nuance ici – la nuance réside dans le routage entre les lignes. Si vous changez simplement 100 % du trafic, vous n’aurez pas ces problèmes. Mais si vous voulez changer de 2 %, vous commencez à vous poser des questions : « Comment faire ça ? Le plus simple est simple : vous pouvez configurer Round Robin dans nginx par choix aléatoire, et vous avez 2 % à gauche, 98 % à droite. Mais cela ne convient pas toujours.

  Par exemple, dans notre cas, un utilisateur interagit avec le système avec plusieurs requêtes. C'est normal : 2, 3, 4, 5 requêtes - vos systèmes peuvent être les mêmes. Et s'il est important pour vous que toutes les requêtes de l'utilisateur arrivent sur la même ligne sur laquelle la première requête est arrivée, ou (deuxième point) que toutes les requêtes de l'utilisateur arrivent sur la nouvelle ligne après le changement (il aurait pu commencer à travailler plus tôt avec le système, avant le changement), - alors cette distribution aléatoire ne vous convient pas. Ensuite, il y a les options suivantes :

  
  
  La première option, la plus simple, repose sur les paramètres de base du client (IP Hash). Vous avez une IP, et vous la divisez de droite à gauche par adresse IP. Ensuite, le deuxième cas que j'ai décrit fonctionnera pour vous, lorsque le déploiement aura lieu, l'utilisateur pourrait déjà commencer à travailler avec votre système, et à partir du moment du déploiement, toutes les demandes iront vers une nouvelle ligne (sur la même, par exemple).

  Si, pour une raison quelconque, cela ne vous convient pas et que vous devez envoyer des demandes à la ligne d'où est arrivée la demande initiale de l'utilisateur, alors vous avez deux options...
  Première option : vous pouvez acheter du nginx+ payant. Il existe un mécanisme de sessions Sticky qui, à la demande initiale de l'utilisateur, attribue une session à l'utilisateur et la lie à l'un ou l'autre en amont. Toutes les demandes utilisateur ultérieures au cours de la durée de vie de la session seront envoyées au même amont où la session a été publiée.

  Cela ne nous convenait pas car nous avions déjà nginx régulier. Passer à nginx+ n’est pas que c’est cher, c’est juste que c’était un peu douloureux pour nous et pas très bien. Les « Sticks Sessions », par exemple, n'ont pas fonctionné pour nous pour la simple raison que les « Sticks Sessions » ne permettent pas de routage basé sur « Soit-ou ». Là, vous pouvez spécifier ce que font nos « Sticks Sessions », par exemple, par adresse IP ou par adresse IP et cookies ou par post-paramètre, mais « Soit-ou » est ici plus compliqué.

  Nous sommes donc arrivés à la quatrième option. Nous avons pris nginx sous stéroïdes (c'est openresty) - c'est le même nginx, qui prend en outre en charge l'inclusion des derniers scripts. Vous pouvez écrire un dernier script, lui donner un « repos ouvert », et ce dernier script sera exécuté lorsque la demande de l'utilisateur arrivera.

  Et nous avons en fait écrit un tel script, nous nous sommes fixés "openresti" et dans ce script nous trions 6 paramètres différents par concaténation "Ou". Selon la présence de l'un ou l'autre paramètre, on sait que l'utilisateur est arrivé sur telle page ou telle autre, telle ligne ou telle autre.

  Déploiement bleu/vert. Avantages et inconvénients

  Bien sûr, il serait probablement possible de le rendre un peu plus simple (utiliser les mêmes « Sticky Sessions »), mais nous avons aussi une telle nuance que non seulement l'utilisateur interagit avec nous dans le cadre d'un traitement d'une transaction... Mais les systèmes de paiement interagissent également avec nous : après avoir traité la transaction (en envoyant une demande au système de paiement), nous recevons un coolback.
  Et disons, si à l'intérieur de notre circuit nous pouvons transmettre l'adresse IP de l'utilisateur dans toutes les requêtes et diviser les utilisateurs en fonction de l'adresse IP, alors nous ne dirons pas le même « Visa » : « Mec, nous sommes une entreprise tellement rétro, on dirait être international (sur le site et en Russie)... Merci de nous fournir l'adresse IP de l'utilisateur dans un champ supplémentaire, votre protocole est standardisé » ! Il est clair qu’ils ne seront pas d’accord.

  
  
  Par conséquent, cela n'a pas fonctionné pour nous - nous avons fait openresty. En conséquence, avec le routage, nous avons obtenu quelque chose comme ceci :

  Le déploiement bleu/vert présente donc les avantages et les inconvénients que j’ai mentionnés.

  Deux inconvénients :

  • vous devez vous soucier du routage ;
  • le deuxième inconvénient principal est la dépense.

  Vous avez besoin de deux fois plus de serveurs, vous avez besoin de deux fois plus de ressources opérationnelles, vous devez consacrer deux fois plus d'efforts pour entretenir l'ensemble de ce zoo.

  D'ailleurs, parmi les avantages, il y a encore une chose que je n'ai pas mentionnée auparavant : vous disposez d'une réserve en cas d'augmentation de la charge. Si vous avez une croissance explosive de la charge, vous avez un grand nombre d'utilisateurs, alors vous incluez simplement la deuxième ligne dans la distribution 50 à 50 - et vous avez immédiatement des serveurs x2 dans votre cluster jusqu'à ce que vous résolviez le problème d'avoir plus de serveurs.

  Comment faire un déploiement rapide ?

  Nous avons parlé de la façon de résoudre le problème de la minimisation et de la restauration rapide, mais la question demeure : « Comment déployer rapidement ?

  
  
  C'est court et simple ici.

  • Vous devez disposer d’un système de CD (Continuous Delivery) – vous ne pouvez pas vous en passer. Si vous disposez d'un serveur, vous pouvez le déployer manuellement. Nous avons bien sûr environ un millier et demi de serveurs et un millier et demi de handles - nous pouvons implanter un département de la taille de cette salle juste pour le déployer.
  • Le déploiement doit être parallèle. Si votre déploiement est séquentiel, alors tout va mal. Un serveur est normal, vous déployerez un millier et demi de serveurs toute la journée.
  • Encore une fois, pour l’accélération, cela n’est probablement plus nécessaire. Lors du déploiement, le projet est généralement construit. Vous avez un projet Web, il y a une partie front-end (vous y faites un pack Web, vous compilez npm - quelque chose comme ça), et ce processus est, en principe, de courte durée - 5 minutes, mais ces 5 minutes peuvent être critique. C’est pour ça, par exemple, qu’on ne fait pas ça : on supprime ces 5 minutes, on déploie des artefacts.

    Qu'est-ce qu'un artefact ? Un artefact est une construction assemblée dans laquelle toutes les pièces d’assemblage sont déjà terminées. Nous stockons cet artefact dans le stockage des artefacts. À une époque, nous utilisions deux de ces stockages - c'était Nexus et maintenant jFrog Artifactory).Nous avons initialement utilisé « Nexus » parce que nous avons commencé à mettre en pratique cette approche dans les applications Java (cela convenait bien). Ensuite, ils y ont placé certaines des applications écrites en PHP ; et « Nexus » ne convenait plus, et nous avons donc choisi jFrog Artefactory, qui peut presque tout artéfactiser. Nous sommes même arrivés au point que dans ce référentiel d'artefacts, nous stockons nos propres packages binaires que nous collectons pour les serveurs.

  Croissance de charge explosive

  Nous avons parlé de changer la version du logiciel. La prochaine chose que nous avons est une augmentation explosive de la charge. Ici, j'entends probablement par croissance explosive de la charge, ce n'est pas tout à fait la bonne chose...

  Nous avons écrit un nouveau système - il est axé sur le service, à la mode, beau, avec des travailleurs partout, des files d'attente partout, une asynchronie partout. Et dans de tels systèmes, les données peuvent circuler via différents flux. Pour la première transaction, le 1er, le 3ème, le 10ème travailleur peut être utilisé, pour la deuxième transaction - le 2ème, le 4ème, le 5ème. Et aujourd'hui, disons que le matin, vous avez un flux de données qui utilise les trois premiers travailleurs, et le soir, il change radicalement, et tout utilise les trois autres travailleurs.

  Et ici, il s'avère que vous devez d'une manière ou d'une autre faire évoluer les travailleurs, vous devez d'une manière ou d'une autre faire évoluer vos services, tout en évitant la surcharge des ressources.

  
  
  Nous avons défini nos besoins. Ces exigences sont assez simples : qu'il y ait une découverte de service, un paramétrage - tout est standard pour construire de tels systèmes évolutifs, à l'exception d'un point - la dépréciation des ressources. Nous avons dit que nous n'étions pas prêts à amortir des ressources pour que les serveurs chauffent l'air. Nous avons pris "Consul", nous avons pris "Nomad", qui gère nos ouvriers.

  Pourquoi est-ce un problème pour nous ? Revenons un peu en arrière. Nous disposons désormais d’environ 70 systèmes de paiement derrière nous. Le matin, le trafic passe par la Sberbank, puis la Sberbank est tombée, par exemple, et nous la basculons vers un autre système de paiement. Nous avions 100 employés avant la Sberbank, et après cela, nous devons fortement augmenter 100 employés pour un autre système de paiement. Et il est souhaitable que tout cela se déroule sans participation humaine. Parce que s'il y a une participation humaine, il devrait y avoir un ingénieur assis 24 heures sur 7, 70 jours sur XNUMX, qui ne devrait faire que cela, car de telles pannes, lorsque XNUMX systèmes sont derrière vous, se produisent régulièrement.

  Par conséquent, nous avons examiné Nomad, qui a une adresse IP ouverte, et avons écrit notre propre truc, Scale-Nomad - ScaleNo, qui fait à peu près ce qui suit : il surveille la croissance de la file d'attente et réduit ou augmente le nombre de travailleurs en fonction de la dynamique. de la file d'attente. Lorsque nous l’avons fait, nous avons pensé : « Peut-être pourrions-nous l’ouvrir en open source ? Puis ils l'ont regardée - elle était aussi simple que deux kopecks.

  Jusqu'à présent, nous ne l'avons pas open source, mais si soudainement après le rapport, après avoir réalisé que vous avez besoin d'une telle chose, vous en avez besoin, mes contacts sont dans la dernière diapositive - écrivez-moi s'il vous plaît. S'il y a au moins 3 à 5 personnes, nous le parrainerons.

  
  
  Comment ça fonctionne? Jetons un coup d'oeil ! Pour l'avenir : sur le côté gauche se trouve une partie de notre surveillance : c'est une ligne, en haut se trouve l'heure de traitement des événements, au milieu se trouve le nombre de transactions, en bas se trouve le nombre de travailleurs.

  Si vous regardez, il y a un problème sur cette image. Sur le graphique du haut, l'un des graphiques s'est écrasé en 45 secondes - l'un des systèmes de paiement est tombé en panne. Immédiatement, le trafic a été introduit en 2 minutes et la file d'attente a commencé à s'allonger sur un autre système de paiement, où il n'y avait pas de travailleurs (nous n'avons pas utilisé les ressources - au contraire, nous avons éliminé les ressources correctement). Nous ne voulions pas chauffer - il y avait un nombre minime, environ 5 à 10 travailleurs, mais ils ne pouvaient pas s'en sortir.

  Le dernier graphique montre une « bosse », ce qui signifie simplement que « Skaleno » a doublé ce montant. Et puis, lorsque le graphique a un peu baissé, il l'a un peu réduit - le nombre d'ouvriers a changé automatiquement. C'est comme ça que ça marche. Nous avons parlé du point numéro 2 - "Comment se débarrasser rapidement des raisons".

  Surveillance. Comment identifier rapidement le problème ?

  Maintenant, le premier point est « Comment identifier rapidement le problème ? » Surveillance! Il faut comprendre certaines choses rapidement. Quelles choses devons-nous comprendre rapidement ?

  
  
  Trois choses!

  • Nous devons comprendre et comprendre rapidement la performance de nos propres ressources.
  • Nous devons rapidement comprendre les pannes et surveiller les performances des systèmes qui nous sont externes.
  • Le troisième point consiste à identifier les erreurs logiques. C'est à ce moment-là que le système fonctionne pour vous, tout est normal selon tous les indicateurs, mais quelque chose ne va pas.

  Je ne vous dirai probablement rien d’aussi cool ici. Je serai Captain Obvious. Nous avons cherché ce qu'il y avait sur le marché. Nous avons un « zoo amusant ». Voici le genre de zoo que nous avons actuellement :

  
  
  Nous utilisons Zabbix pour surveiller le matériel, pour surveiller les principaux indicateurs des serveurs. Nous utilisons Okmeter pour les bases de données. Nous utilisons « Grafana » et « Prometheus » pour tous les autres indicateurs qui ne correspondent pas aux deux premiers, certains avec « Grafana » et « Prometheus », et certains avec « Grafana » avec « Influx » et Telegraf.

  Il y a un an, nous voulions utiliser New Relic. Chose cool, il peut tout faire. Mais même si elle peut tout faire, elle coûte très cher. Lorsque nous avons atteint un volume de 1,5 mille serveurs, un fournisseur est venu nous voir et nous a dit : « Concluons un accord pour l'année prochaine ». Nous avons regardé le prix et avons dit non, nous ne ferons pas ça. Maintenant, nous abandonnons New Relic, il nous reste environ 15 serveurs sous la surveillance de New Relic. Le prix s'est avéré absolument sauvage.

  Et il existe un outil que nous avons implémenté nous-mêmes : c'est Debugger. Au début, nous l'appelions « Bagger », mais ensuite un professeur d'anglais est passé par là, a éclaté de rire et l'a renommé « Debagger ». Ce que c'est? Il s'agit en effet d'un outil qui, en 15 à 30 secondes sur chaque composant, comme une « boîte noire » du système, exécute des tests sur les performances globales du composant.

  Par exemple, s’il existe une page externe (page de paiement), il l’ouvre simplement et regarde à quoi elle devrait ressembler. S'il s'agit d'un traitement, il envoie une « transaction » test et s'assure que cette « transaction » arrive. S'il s'agit d'une connexion avec des systèmes de paiement, nous lançons une demande de test en conséquence, là où nous le pouvons, et constatons que tout va bien pour nous.

  Quels indicateurs sont importants pour le suivi ?

  Que surveillons-nous principalement ? Quels indicateurs sont importants pour nous ?

  
  

  • Le temps de réponse/RPS sur les fronts est un indicateur très important. Il répond immédiatement que quelque chose ne va pas chez vous.
  • Le nombre de messages traités dans toutes les files d'attente.
  • Nombre de travailleurs.
  • Mesures d'exactitude de base.

  Le dernier point est la métrique « business », « business ». Si vous souhaitez surveiller la même chose, vous devez définir une ou deux métriques qui seront pour vous les principaux indicateurs. Notre mesure est le débit (c'est le rapport entre le nombre de transactions réussies et le flux total de transactions). Si quelque chose change à un intervalle de 5-10-15 minutes, cela signifie que nous avons des problèmes (si cela change radicalement).

  Pour nous, cela ressemble à un exemple de l'un de nos tableaux :

  
  
  Sur le côté gauche, il y a 6 graphiques, selon les lignes - le nombre de travailleurs et le nombre de messages dans les files d'attente. Sur le côté droit – RPS, RTS. Vous trouverez ci-dessous la même mesure « entreprise ». Et dans la métrique « business », nous pouvons immédiatement voir que quelque chose s'est mal passé dans les deux graphiques du milieu... C'est juste un autre système qui se tient derrière nous et qui est tombé.

  La deuxième chose que nous devions faire était de surveiller la chute des systèmes de paiement externes. Ici, nous avons pris OpenTracing - un mécanisme, un standard, un paradigme qui vous permet de tracer les systèmes distribués ; et cela a été un peu modifié. Le paradigme standard OpenTracing dit que nous construisons une trace pour chaque requête individuelle. Nous n’en avions pas besoin et nous l’avons enveloppé dans une trace récapitulative et d’agrégation. Nous avons créé un outil qui nous permet de suivre la vitesse des systèmes derrière nous.

  
  
  Le graphique nous montre qu'un des systèmes de paiement a commencé à répondre en 3 secondes - nous avons des problèmes. De plus, cette chose réagira lorsque les problèmes commenceront, à un intervalle de 20 à 30 secondes.

  Et la troisième classe d’erreurs de surveillance qui existe est la surveillance logique.

  Pour être honnête, je ne savais pas quoi dessiner sur cette diapositive, car nous cherchions depuis longtemps sur le marché quelque chose qui nous conviendrait. Nous n'avons rien trouvé, nous avons donc dû le faire nous-mêmes.

  
  
  Qu'est-ce que j'entends par surveillance logique ? Eh bien, imaginez : vous vous créez un système (par exemple, un clone de Tinder) ; vous l'avez fait, vous l'avez lancé. Le manager à succès Vasya Pupkin l'a mis sur son téléphone, y voit une fille, l'aime bien... et la même chose ne va pas à la fille - la même chose va à l'agent de sécurité Mikhalych du même centre d'affaires. Le directeur descend et se demande ensuite : « Pourquoi cet agent de sécurité Mikhalych lui sourit-il si agréablement ?

  Dans de telles situations... Pour nous, cette situation semble un peu différente, car (je l'ai écrit) il s'agit d'une perte de réputation qui entraîne indirectement des pertes financières. Notre situation est inverse : nous pouvons subir des pertes financières directes - par exemple, si nous avons mené une transaction aussi réussie, mais qu'elle a échoué (ou vice versa). J'ai dû écrire mon propre outil qui suit le nombre de transactions réussies au fil du temps à l'aide d'indicateurs commerciaux. Je n'ai rien trouvé sur le marché ! C’est exactement l’idée que je voulais transmettre. Il n’existe rien sur le marché pour résoudre ce genre de problème.

  Il s'agissait de savoir comment identifier rapidement le problème.

  Comment déterminer les raisons du déploiement

  Le troisième groupe de problèmes que nous résolvons est qu'après avoir identifié le problème, après l'avoir éliminé, il serait bon de comprendre la raison du développement, des tests et de faire quelque chose à ce sujet. En conséquence, nous devons enquêter, nous devons augmenter les journaux.

  
  
  Si nous parlons de journaux (la raison principale est les journaux), la majeure partie de nos journaux se trouvent dans ELK Stack - presque tout le monde a la même chose. Pour certains, ce n'est peut-être pas en ELK, mais si vous écrivez des journaux en gigaoctets, tôt ou tard vous arriverez à ELK. Nous les écrivons en téraoctets.

  
  
  Il y a un problème ici. Nous l'avons corrigé, corrigé l'erreur pour l'utilisateur, commencé à creuser ce qui s'y trouvait, sommes montés dans Kibana, y avons entré l'identifiant de la transaction et avons obtenu un chausson comme celui-ci (cela montre beaucoup). Et absolument rien n'est clair dans ce chausson. Pourquoi? Oui, car on ne sait pas clairement quelle partie appartient à quel travailleur, quelle partie appartient à quel composant. Et à ce moment-là, nous avons réalisé que nous avions besoin de traçage – le même OpenTracing dont j'ai parlé.

  Nous l'avons pensé il y a un an, avons tourné notre attention vers le marché, et il y avait deux outils là-bas - "Zipkin" et "Jaeger". « Jager » est en fait un tel héritier idéologique, un successeur idéologique de « Zipkin ». Tout va bien dans Zipkin, sauf qu'il ne sait pas agréger, il ne sait pas inclure les logs dans la trace, seulement la trace temporelle. Et "Jager" a soutenu cela.

  Nous avons regardé "Jager": vous pouvez instrumenter des applications, vous pouvez écrire en Api (le standard Api pour PHP à l'époque n'était cependant pas approuvé - c'était il y a un an, mais maintenant il a déjà été approuvé), mais là n'était absolument aucun client. «D'accord», avons-nous pensé et avons écrit à notre propre client. Qu'avons-nous obtenu ? Voilà à peu près à quoi cela ressemble :

  
  
  Dans Jaeger, des spans sont créés pour chaque message. Autrement dit, lorsqu'un utilisateur ouvre le système, il voit un ou deux blocs pour chaque demande entrante (1-2-3 - le nombre de demandes entrantes de l'utilisateur, le nombre de blocs). Pour faciliter la tâche des utilisateurs, nous avons ajouté des balises aux journaux et aux traces temporelles. Par conséquent, en cas d'erreur, notre application marquera le journal avec la balise Error appropriée. Vous pouvez filtrer par balise d'erreur et seuls les intervalles contenant ce bloc avec une erreur seront affichés. Voici à quoi cela ressemble si nous élargissons la durée :

  
  
  À l’intérieur de la travée se trouve un ensemble de traces. Dans ce cas, il s'agit de trois traces de test, et la troisième trace nous indique qu'une erreur s'est produite. En même temps, on voit ici une trace temporelle : on a une échelle de temps en haut, et on voit à quel intervalle de temps tel ou tel log a été enregistré.

  En conséquence, les choses se sont bien passées pour nous. Nous avons écrit notre propre extension et nous l'avons open source. Si vous voulez travailler avec le traçage, si vous voulez travailler avec « Jager » en PHP, il y a notre extension, bienvenue à utiliser, comme on dit :

  
  
  Nous avons cette extension - c'est un client pour l'API OpenTracing, elle est conçue comme une extension php, c'est-à-dire que vous devrez l'assembler et l'installer sur le système. Il y a un an, il n'y avait rien de différent. Il existe désormais d'autres clients qui ressemblent à des composants. Ici, c'est à vous de décider : soit vous pompez les composants avec un compositeur, soit vous utilisez une extension à votre guise.

  Normes d'entreprise

  Nous avons parlé des trois commandements. Le quatrième commandement est de standardiser les approches. Ca parle de quoi? Il s'agit de ça :

  
  
  Pourquoi le mot « entreprise » est-il utilisé ici ? Pas parce que nous sommes une grande entreprise ou une entreprise bureaucratique, non ! Je voulais utiliser le mot « entreprise » ici dans le contexte où chaque entreprise, chaque produit devrait avoir ses propres normes, y compris vous. De quelles normes disposons-nous ?

  
  

  • Nous avons des règles de déploiement. Nous n’avançons nulle part sans lui, nous ne pouvons pas. Nous déployons environ 60 fois par semaine, c'est-à-dire que nous déployons presque constamment. Dans le même temps, nous avons par exemple dans le règlement de déploiement un tabou sur les déploiements le vendredi - en principe, nous ne déployons pas.
  • Nous avons besoin de documents. Pas un seul nouveau composant n'entre en production s'il n'existe pas de documentation, même s'il est né sous la plume de nos spécialistes RnD. Nous leur demandons des instructions de déploiement, une carte de surveillance et une description approximative (enfin, comme peuvent l'écrire les programmeurs) du fonctionnement de ce composant, de la façon de le dépanner.
  • Nous ne résolvons pas la cause du problème, mais le problème – ce que j'ai déjà dit. Il est important pour nous de protéger l'utilisateur des problèmes.
  • Nous avons les autorisations. Par exemple, nous ne considérons pas comme un temps d'arrêt si nous perdons 2 % du trafic en deux minutes. Ceci n’est fondamentalement pas inclus dans nos statistiques. Si c'est plutôt en pourcentage ou temporaire, on compte déjà.
  • Et nous écrivons toujours des post-mortems. Quoi qu’il nous arrive, toute situation dans laquelle quelqu’un s’est comporté anormalement en production se reflétera dans l’autopsie. Un post-mortem est un document dans lequel vous écrivez ce qui vous est arrivé, un timing détaillé, ce que vous avez fait pour le corriger et (c'est un blocage obligatoire !) ce que vous ferez pour éviter que cela ne se reproduise à l'avenir. Ceci est obligatoire et nécessaire pour une analyse ultérieure.

  Qu’est-ce qui est considéré comme un temps d’arrêt ?

  
  
  A quoi tout cela a-t-il conduit ?

  Cela a conduit au fait que (nous avons eu certains problèmes de stabilité, cela ne convenait ni aux clients ni à nous) au cours des 6 derniers mois, notre indicateur de stabilité était de 99,97. On peut dire que ce n'est pas grand-chose. Oui, nous avons quelque chose à atteindre. De cet indicateur, environ la moitié est la stabilité, pour ainsi dire, non pas de la nôtre, mais de notre pare-feu d'applications Web, qui se tient devant nous et est utilisé comme service, mais les clients s'en moquent.

  Nous avons appris à dormir la nuit. Enfin! Il y a six mois, nous ne pouvions pas. Et sur cette note avec les résultats, je voudrais faire une note. Hier soir, il y a eu un merveilleux reportage sur le système de contrôle d'un réacteur nucléaire. Si les personnes qui ont écrit ce système peuvent m'entendre, oubliez ce que j'ai dit à propos de « 2 % n'est pas un temps d'arrêt ». Pour vous, 2 % représentent un temps d'arrêt, même de deux minutes !

  C'est tout! Vos questions.

  
  

  À propos des équilibreurs et de la migration des bases de données

  Question du public (ci-après – B) : – Bonsoir. Merci beaucoup pour un tel rapport administratif ! Une petite question sur vos équilibreurs. Vous avez mentionné que vous disposez d'un WAF, c'est-à-dire, si je comprends bien, que vous utilisez une sorte d'équilibreur externe...

  EK : – Non, nous utilisons nos services comme équilibreur. Dans ce cas, WAF est pour nous exclusivement un outil de protection DDoS.

  В: – Pouvez-vous dire quelques mots sur les équilibreurs ?

  EK : – Comme je l'ai déjà dit, il s'agit d'un groupe de serveurs en openresty. Nous avons maintenant 5 groupes de réserve qui répondent exclusivement... c'est-à-dire un serveur qui exécute exclusivement openresty, il ne fait que proxy le trafic. Ainsi, pour comprendre combien nous détenons : nous disposons désormais d’un flux de trafic régulier de plusieurs centaines de mégabits. Ils s’en sortent, ils se sentent bien, ils ne se fatiguent même pas.

  В: – Aussi une question simple. Voici le déploiement Bleu/Vert. Que faites-vous, par exemple, des migrations de bases de données ?

  EK : - Bonne question! Regardez, dans le déploiement Bleu/Vert, nous avons des files d'attente distinctes pour chaque ligne. Autrement dit, si nous parlons de files d'attente d'événements transmises d'un travailleur à l'autre, il existe des files d'attente distinctes pour la ligne bleue et pour la ligne verte. Si nous parlons de la base de données elle-même, nous l'avons délibérément réduite autant que possible, avons tout déplacé pratiquement dans des files d'attente ; dans la base de données, nous ne stockons qu'une pile de transactions. Et notre pile de transactions est la même pour toutes les lignes. Avec la base de données dans ce contexte : nous ne la séparons pas en bleu et vert, car les deux versions du code doivent savoir ce qui se passe avec la transaction.

  Mes amis, j'ai aussi un petit prix pour vous encourager : un livre. Et je devrais le recevoir pour la meilleure question.

  В: - Bonjour. Merci pour le rapport. La question est la suivante. Vous surveillez les paiements, vous surveillez les services avec lesquels vous communiquez... Mais comment contrôler qu'une personne vienne d'une manière ou d'une autre sur votre page de paiement, effectue un paiement et que le projet lui crédite de l'argent ? Autrement dit, comment contrôler que le marchant est disponible et a accepté votre rappel ?

  EK : – « Marchand » pour nous dans ce cas est exactement le même service externe que le système de paiement. Nous surveillons la vitesse de réponse du commerçant.

  À propos du chiffrement de la base de données

  В: - Bonjour. J'ai une question légèrement connexe. Vous disposez de données sensibles PCI DSS. Je voulais savoir comment stocker les PAN dans des files d'attente dans lesquelles vous devez effectuer un transfert ? Utilisez-vous un cryptage ? Et cela nous amène à la deuxième question : selon PCI DSS, il est nécessaire de rechiffrer périodiquement la base de données en cas de modifications (licenciement des administrateurs, etc.) - qu'arrive-t-il à l'accessibilité dans ce cas ?

  
  
  EK : - Merveilleuse question ! Premièrement, nous ne stockons pas les PAN dans les files d'attente. En principe, nous n'avons pas le droit de stocker des PAN n'importe où sous forme claire, c'est pourquoi nous utilisons un service spécial (nous l'appelons « Kademon ») - c'est un service qui ne fait qu'une seule chose : il reçoit un message en entrée et l'envoie. un message crypté. Et nous stockons tout avec ce message crypté. En conséquence, la longueur de notre clé est inférieure à un kilo-octet, ce qui la rend sérieuse et fiable.

  В: – Avez-vous besoin de 2 kilo-octets maintenant ?

  EK : – On dirait qu'hier encore, il était 256... Eh bien, où d'autre ?!

  C’est donc le premier. Et deuxièmement, la solution qui existe, elle prend en charge la procédure de re-chiffrement - il y a deux paires de "keks" (clés), qui donnent des "decks" qui chiffrent (les clés sont les clés, les dek sont des dérivés des clés qui chiffrent) . Et si la procédure est engagée (cela arrive régulièrement, de 3 mois à ± certains), on télécharge une nouvelle paire de « gâteaux », et on ré-chiffre les données. Nous disposons de services distincts qui extraient toutes les données et les chiffrent d'une nouvelle manière ; Les données sont stockées à côté de l'identifiant de la clé avec laquelle elles sont cryptées. En conséquence, dès que nous chiffrons les données avec de nouvelles clés, nous supprimons l'ancienne clé.

  Parfois, les paiements doivent être effectués manuellement...

  В: – Autrement dit, si un remboursement arrive pour une opération, le déchiffrez-vous toujours avec l’ancienne clé ?

  EK : - Oui.

  В: – Alors encore une petite question. Lorsqu'une panne, une chute ou un incident se produit, il est nécessaire d'effectuer la transaction manuellement. Une telle situation existe.

  EK : - Oui, parfois.

  В: – D’où tirez-vous ces données ? Ou allez-vous vous-même dans ce dépôt ?

  EK : – Non, bien sûr, nous avons une sorte de système back-office qui contient une interface pour notre support. Si nous ne savons pas dans quel statut se trouve la transaction (par exemple, jusqu'à ce que le système de paiement ait répondu avec un délai d'attente), nous ne le savons pas a priori, c'est-à-dire que nous attribuons le statut final uniquement en toute confiance. Dans ce cas, nous transférons la transaction dans un statut spécial pour un traitement manuel. Le lendemain matin, dès que le support reçoit l'information que telles ou telles transactions restent dans le système de paiement, il les traite manuellement dans cette interface.

  
  
  В: - J'ai quelques questions. L’un d’eux est le maintien de la zone PCI DSS : comment loguer leur circuit ? Cette question est due au fait que le développeur aurait pu mettre n'importe quoi dans les journaux ! Deuxième question : comment déployer les correctifs ? L'utilisation de handles dans la base de données est une option, mais il peut y avoir des correctifs gratuits - quelle est la procédure à suivre ? Et la troisième question est probablement liée au RTO, au RPO. Votre disponibilité était de 99,97, presque quatre neuf, mais si je comprends bien, vous avez un deuxième centre de données, un troisième centre de données et un cinquième centre de données... Comment les synchroniser, les répliquer et tout le reste ?

  EK : - Commençons par le premier. La première question concernait-elle les journaux ? Lorsque nous écrivons des journaux, nous disposons d'une couche qui masque toutes les données sensibles. Elle regarde le masque et les champs supplémentaires. En conséquence, nos journaux contiennent des données déjà masquées et un circuit PCI DSS. C'est l'une des tâches régulières assignées au service de tests. Ils sont tenus de vérifier chaque tâche, y compris les journaux qu'ils rédigent, et c'est l'une des tâches régulières lors des revues de code, afin de contrôler que le développeur n'a pas écrit quelque chose. Des contrôles ultérieurs sont effectués régulièrement par le service de sécurité de l'information environ une fois par semaine : les journaux du dernier jour sont sélectionnés de manière sélective et sont passés par un scanner-analyseur spécial à partir de serveurs de test pour tout vérifier.
  À propos des correctifs. Ceci est inclus dans nos règles de déploiement. Nous avons une clause distincte sur les correctifs. Nous pensons que nous déployons des correctifs XNUMX heures sur XNUMX, lorsque nous en avons besoin. Dès que la version est assemblée, dès qu'elle est exécutée, dès que nous avons un artefact, nous avons un administrateur système de garde sur appel du support, et il le déploie au moment où cela est nécessaire.

  A propos de "quatre neuf". Le chiffre que nous avons aujourd'hui a vraiment été atteint et nous nous sommes efforcés de l'atteindre dans un autre centre de données. Nous disposons désormais d'un deuxième centre de données et nous commençons à établir un itinéraire entre eux, et la question de la réplication entre centres de données est vraiment une question non triviale. Nous avons essayé de le résoudre à un moment donné en utilisant différents moyens : nous avons essayé d'utiliser la même « Tarentule » - cela n'a pas fonctionné pour nous, je vous le dis tout de suite. C'est pourquoi nous avons fini par commander les "sens" manuellement. En fait, chaque application de notre système exécute de manière asynchrone la synchronisation « changement – ​​effectué » nécessaire entre les centres de données.

  В: – Si vous en avez un deuxième, pourquoi n’en avez-vous pas eu un troisième ? Parce que personne n'a encore le cerveau divisé...

  EK : – Mais nous n’avons pas Split Brain. Etant donné que chaque application est pilotée par un multimaître, le centre auquel la demande est parvenue n'a pas d'importance pour nous. Nous sommes prêts au fait que si l'un de nos centres de données tombe en panne (nous comptons sur cela) et qu'au milieu d'une demande d'utilisateur, nous passons au deuxième centre de données, nous sommes effectivement prêts à perdre cet utilisateur ; mais ce seront des unités, des unités absolues.

  В: - Bonne soirée. Merci pour le rapport. Vous avez parlé de votre débogueur, qui exécute certaines transactions de test en production. Mais parlez-nous des transactions tests ! Jusqu'à quelle profondeur va-t-il ?

  EK : – Il parcourt le cycle complet de l’ensemble du composant. Pour un composant, il n'y a pas de différence entre une transaction de test et une transaction de production. Mais d'un point de vue logique, il s'agit simplement d'un projet distinct dans le système, sur lequel seules des transactions de test sont exécutées.

  В: -Où est-ce que tu le coupes ? Ici Core envoyé...

  EK : – Nous sommes derrière « Kor » dans ce cas pour les transactions tests... Nous avons une chose telle que le routage : « Kor » sait à quel système de paiement il doit être envoyé - nous l'envoyons à un faux système de paiement, qui donne simplement un signal http et c'est tout.

  В: – Dites-moi, s'il vous plaît, votre application a-t-elle été écrite dans un énorme monolithe, ou l'avez-vous découpée en certains services ou même en microservices ?

  EK : – Nous n’avons bien sûr pas de monolithe, nous avons une application orientée services. Nous plaisantons en disant que notre service est constitué de monolithes - ils sont vraiment assez grands. Il est difficile d’appeler cela des microservices, mais ce sont des services au sein desquels opèrent les travailleurs des machines distribuées.

  Si le service sur le serveur est compromis...

  В: – Alors j’ai la question suivante. Même s'il s'agissait d'un monolithe, vous avez quand même dit que vous aviez beaucoup de ces serveurs instantanés, ils traitent tous essentiellement des données, et la question est : « En cas de compromission de l'un des serveurs instantanés ou d'une application, tout lien individuel , ont-ils une sorte de contrôle d'accès ? Lequel d’entre eux peut faire quoi ? Qui dois-je contacter pour quelles informations ?

  
  
  EK : - Oui définitivement. Les exigences de sécurité sont assez sérieuses. Premièrement, nous avons des mouvements de données ouvertes, et les ports sont uniquement ceux par lesquels nous anticipons à l’avance les mouvements de trafic. Si un composant communique avec la base de données (par exemple avec Muskul) via 5-4-3-2, seul le 5-4-3-2 lui sera ouvert, et les autres ports et autres directions de trafic ne seront pas disponibles. De plus, vous devez comprendre que dans notre production, il existe environ 10 boucles de sécurité différentes. Et même si l'application était compromise d'une manière ou d'une autre, Dieu nous en préserve, l'attaquant ne pourra pas accéder à la console de gestion du serveur, car il s'agit d'une zone de sécurité réseau différente.

  В: – Et dans ce contexte, ce qui m'intéresse le plus, c'est qu'il y a certains contrats avec les services - ce qu'ils peuvent faire, par quelles « actions » ils peuvent se contacter... Et dans un flux normal, certains services spécifiques demandent des rangée, une liste d’« actions » sur l’autre. Ils ne semblent pas se tourner vers les autres dans une situation normale et ils ont d’autres domaines de responsabilité. Si l’un d’eux est compromis, pourra-t-il perturber les « actions » de ce service ?

  EK : - Je comprends. Si, dans une situation normale, avec un autre serveur, la communication était autorisée, alors oui. Selon le contrat SLA, nous ne contrôlons pas que vous n'êtes autorisé qu'aux 3 premières « actions », et que vous n'êtes pas autorisé aux 4 « actions ». C'est probablement redondant pour nous, car nous disposons déjà en principe d'un système de protection à 4 niveaux pour les circuits. Nous préférons nous défendre par les contours plutôt qu'au niveau de l'intérieur.

  Comment fonctionnent Visa, MasterCard et Sberbank

  В: – Je souhaite clarifier un point concernant le passage d’un utilisateur d’un centre de données à un autre. Autant que je sache, Visa et MasterCard fonctionnent en utilisant le protocole binaire synchrone 8583, et il existe des mélanges. Et je voulais savoir, maintenant nous parlons de changer – est-ce directement « Visa » et « MasterCard » ou avant les systèmes de paiement, avant le traitement ?

  EK : - C'est avant les mixages. Nos mix sont situés dans le même centre de données.

  В: – Grosso modo, avez-vous un seul point de connexion ?

  EK : – « Visa » et « MasterCard » - oui. Tout simplement parce que Visa et MasterCard nécessitent des investissements assez sérieux en infrastructures pour conclure des contrats séparés pour obtenir une deuxième paire de mix, par exemple. Ils sont réservés au sein d'un seul centre de données, mais si, Dieu nous en préserve, notre centre de données, où il y a des mélanges pour la connexion à Visa et MasterCard, meurt, alors nous aurons une connexion avec Visa et MasterCard perdue...

  В: – Comment les réserver ? Je sais que Visa n'autorise en principe qu'une seule connexion !

  EK : – Ils fournissent eux-mêmes le matériel. En tout cas, nous avons reçu du matériel entièrement redondant à l’intérieur.

  В: – Alors le stand vient de leur Connects Orange ?..

  EK : - Oui.

  В: – Mais qu’en est-il de ce cas : si votre data center disparaît, comment pouvez-vous continuer à l’utiliser ? Ou est-ce que la circulation s'arrête tout simplement ?

  EK : - Non. Dans ce cas, nous déplacerons simplement le trafic vers un autre canal, ce qui, naturellement, sera plus cher pour nous et plus cher pour nos clients. Mais le trafic ne passera pas par notre connexion directe à Visa, MasterCard, mais par la Sberbank conditionnelle (très exagérée).

  Je m'excuse énormément si j'ai offensé les employés de la Sberbank. Mais selon nos statistiques, parmi les banques russes, la Sberbank chute le plus souvent. Il ne se passe pas un mois sans que quelque chose ne tombe à la Sberbank.

  
  
  

  Quelques publicités 🙂

  Merci de rester avec nous. Vous aimez nos articles ? Vous voulez voir du contenu plus intéressant ? Soutenez-nous en passant une commande ou en recommandant à vos amis, cloud VPS pour les développeurs à partir de 4.99 $, un analogue unique des serveurs d'entrée de gamme, que nous avons inventé pour vous : Toute la vérité sur le VPS (KVM) E5-2697 v3 (6 Cores) 10Go DDR4 480Go SSD 1Gbps à partir de 19$ ou comment partager un serveur ? (disponible avec RAID1 et RAID10, jusqu'à 24 cœurs et jusqu'à 40 Go de DDR4).

  Dell R730xd 2 fois moins cher dans le centre de données Equinix Tier IV à Amsterdam ? Ici seulement 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV à partir de 199$ aux Pays-Bas! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - à partir de 99$ ! En savoir plus Comment construire une infrastructure corp. classe avec l'utilisation de serveurs Dell R730xd E5-2650 v4 qui valent 9000 XNUMX euros pour un sou ?

Source: habr.com