🐬 💪🏽 🕢 Top Fakapov Cyan 😎 ⚫️ 🕡

Bon à tous!

Je m'appelle Nikita, je suis chef d'équipe d'ingénieurs cyan. L'une de mes responsabilités au sein de l'entreprise est de réduire à zéro le nombre d'incidents liés à l'infrastructure de la prod.
Ce qui sera discuté plus tard nous a apporté beaucoup de souffrance, et le but de cet article est d'empêcher d'autres personnes de répéter nos erreurs ou au moins de minimiser leur impact.

Préambule

Il était une fois, lorsque Cyan consistait en monolithes, et qu'il n'y avait pas encore d'indices de microservices, nous avons mesuré la disponibilité de la ressource en vérifiant 3-5 pages.

Réponse - tout va bien, ne répondez pas longtemps - alerte. Combien de temps ils ne devraient pas travailler pour que cela soit considéré comme un incident, ont décidé les gens lors des réunions. Une équipe d'ingénieurs a toujours été impliquée dans l'enquête sur l'incident. Une fois l'enquête terminée, ils ont écrit un post-mortem - une sorte de rapport au bureau de poste dans le format: ce qui était, combien de temps, ce qu'ils ont fait sur le moment, ce que nous ferons à l'avenir.

Les pages principales du site, ou si nous comprenons bien, ont cassé le fond

Afin de comprendre d'une manière ou d'une autre la priorité de l'erreur, nous avons mis en évidence les pages les plus critiques du site pour la fonctionnalité commerciale. Selon eux, nous considérons le nombre de demandes réussies / infructueuses et de délais d'attente. Nous mesurons donc la disponibilité.

Supposons que nous découvrions qu'il existe un certain nombre de sections super importantes du site qui sont responsables du service principal - recherche et soumission d'annonces. Si le nombre de demandes qui ont échoué est supérieur à 1%, il s'agit d'un incident critique. Si, dans les 15 minutes en prime time, le pourcentage d'erreurs dépasse 0,1%, cela est également considéré comme un incident critique. Ces critères couvrent la plupart des incidents, les autres dépassent le cadre de cet article.

Les meilleurs incidents cyan

Donc, nous avons précisément appris à déterminer le fait que l'incident s'est produit.

Maintenant, chaque incident dans notre pays est décrit en détail et reflété dans l'épopée de Jira. Soit dit en passant: pour cela, nous avons lancé un projet distinct, appelé FAIL - seules des épopées peuvent y être créées.

Si vous collectez tous les échecs au cours des dernières années, les dirigeants sont:

incidents liés au mssql;
incidents causés par des facteurs externes;
erreurs d'administration.

Arrêtons-nous plus en détail sur les erreurs des administrateurs, ainsi que sur quelques autres échecs intéressants.

Cinquième place - «Mettre de l'ordre dans le DNS»

C'était un mardi pluvieux. Nous avons décidé de nettoyer le cluster DNS.

Je voulais transférer les serveurs DNS internes de bind vers powerdns, en mettant en évidence des serveurs complètement séparés, où il n'y a rien à part DNS.

Nous avons placé un serveur DNS à chaque emplacement de nos contrôleurs de domaine et le moment est venu de déplacer les zones de bind vers powerdns et de basculer l'infrastructure vers de nouveaux serveurs.

Au plus fort du déménagement, parmi tous les serveurs indiqués dans la liaison de mise en cache locale sur tous les serveurs, un seul se trouvait dans le centre de données de Saint-Pétersbourg. Ce DC a été initialement déclaré non critique pour nous, mais est soudainement devenu un point de défaillance unique.
Juste au cours d'une telle période de délocalisation, le canal entre Moscou et Saint-Pétersbourg est tombé. Nous sommes restés sans DNS pendant cinq minutes et nous nous sommes levés lorsque l'hébergeur a résolu les problèmes.

Conclusions:

Si auparavant nous avons négligé les facteurs externes lors de la préparation du travail, maintenant ils sont également inclus dans la liste de ce pour quoi nous nous préparons. Et maintenant, nous nous efforçons de garantir que tous les composants sont réservés n-2, et pour la durée du travail, nous pouvons abaisser ce niveau à n-1.

Lors de l'élaboration d'un plan d'action, marquez les points où le service peut tomber et réfléchissez à l'avance au scénario où tout s'est «pire que nulle part».
Distribuez les serveurs DNS internes par différentes géolocalisations / centres de données / racks / commutateurs / entrées.
Sur chaque serveur, placez un serveur DNS de mise en cache local, qui redirige les demandes vers les serveurs DNS principaux, et s'il n'est pas disponible, il répondra à partir du cache.

Quatrième place - «Nettoyage de Nginx»

Un beau jour, notre équipe a décidé que «assez pour le supporter», et le processus de refactoring des configurations nginx a commencé. L'objectif principal est d'apporter des configs à une structure intuitive. Auparavant, tout était «historiquement établi» et il n'y avait pas de logique en soi. Maintenant, chaque nom_serveur a été extrait du fichier du même nom et distribué toutes les configurations dans des dossiers. À propos, la configuration contient 253949 lignes ou 7836520 caractères et occupe près de 7 mégaoctets. Structure de haut niveau:

Structure Nginx

├── access
│   ├── allow.list
...
│   └── whitelist.conf
├── geobase
│   ├── exclude.conf
...
│   └── geo_ip_to_region_id.conf
├── geodb
│   ├── GeoIP.dat
│   ├── GeoIP2-Country.mmdb
│   └── GeoLiteCity.dat
├── inc
│   ├── error.inc
...
│   └── proxy.inc
├── lists.d
│   ├── bot.conf
...
│   ├── dynamic
│   └── geo.conf
├── lua
│   ├── cookie.lua
│   ├── log
│   │   └── log.lua
│   ├── logics
│   │   ├── include.lua
│   │   ├── ...
│   │   └── utils.lua
│   └── prom
│       ├── stats.lua
│       └── stats_prometheus.lua
├── map.d
│   ├── access.conf
│   ├── .. 
│   └── zones.conf
├── nginx.conf
├── robots.txt
├── server.d
│   ├── cian.ru
│   │   ├── cian.ru.conf
│   │   ├── ...
│   │   └── my.cian.ru.conf
├── service.d
│   ├── ...
│   └── status.conf
└── upstream.d
    ├── cian-mcs.conf
    ├── ...
    └── wafserver.conf

C'est devenu beaucoup mieux, mais dans le processus de changement de nom et de distribution des configurations, certaines d'entre elles avaient la mauvaise extension et ne tombaient pas dans la directive include * .conf. En conséquence, une partie des hôtes est devenue indisponible et a renvoyé 301 au principal. Étant donné que le code de réponse n'était pas 5xx / 4xx, cela n'a pas été remarqué immédiatement, mais seulement le matin. Après cela, nous avons commencé à écrire des tests pour tester les composants d'infrastructure.

Résultats:

Structurez correctement les configurations (pas seulement nginx) et réfléchissez à la structure à un stade précoce du projet. Vous les rendrez ainsi plus compréhensibles pour l'équipe, ce qui réduira à son tour le TTM.
Pour certains composants d'infrastructure, écrivez des tests. Par exemple: vérifier que tous les noms de serveur clés renvoient l'état correct, + corps de réponse. Il suffira d'avoir à portée de main quelques scripts qui vérifient les fonctions de base du composant pour que vous ne vous souveniez pas frénétiquement à 3 heures du matin de ce qui doit être vérifié.

Troisième place - «Place soudainement terminée à Cassandra»

Les données augmentaient régulièrement et tout allait bien jusqu'au moment où la réparation des gros cas a commencé à tomber dans le cluster Cassandra, car le compactage ne pouvait pas fonctionner sur eux.

Un jour de pluie, la grappe s'est presque transformée en citrouille, à savoir:

les places sont restées environ 20% du cluster total;
il est impossible d'ajouter complètement des nœuds, car le nettoyage ne fonctionne pas après l'ajout d'un nœud en raison du manque d'espace sur les partitions;
les performances diminuent légèrement, car le compactage ne fonctionne pas;
le cluster est en mode d'urgence.

Quitter - a ajouté 5 autres nœuds sans nettoyage, après quoi ils ont commencé à supprimer systématiquement du cluster et à les ressaisir en tant que nœuds vides sur lesquels la place s'est terminée. Le temps a passé beaucoup plus que nous ne le souhaiterions. Il y avait un risque d'inaccessibilité partielle ou totale du cluster.

Résultats:

Tous les serveurs cassandra ne devraient pas occuper plus de 60% de l'espace sur chaque partition.
Ils ne doivent pas être chargés à plus de 50% de CPU.
N'obstruez pas la planification des capacités et réfléchissez-y pour chaque composant, en fonction de ses spécificités.
Plus il y a de nœuds dans le cluster, mieux c'est. Les serveurs contenant une petite quantité de données sont migrés plus rapidement et un tel cluster est plus facile à réanimer.

Deuxième place - «Les données du stockage de valeur-clé du consul ont disparu»

Pour la découverte de services, nous, comme beaucoup, utilisons le consul. Mais ici, sa valeur-clé est également utilisée pour les calculs de monolithes bleu-vert. Il stocke les informations en amont actives et inactives, qui changent de place pendant le déploiement. Pour cela, un service de déploiement a été écrit qui interagit avec KV. À un moment donné, les données de KV ont disparu. Récupéré de la mémoire, mais avec un certain nombre d'erreurs. En conséquence, lors du calcul, la charge sur l'amont a été inégalement répartie et nous avons eu beaucoup d'erreurs 502 en raison de la surcharge des backends sur le CPU. En conséquence, nous sommes passés du consul KV aux postgres, d'où il n'est pas si facile de les retirer.

Résultats:

- . , ES — , , , action.destructive_requires_name: true.
. , ( , python), .

— « »

À un moment donné, nous avons remarqué une répartition inégale de la charge sur le nginx en amont dans les cas où il y avait 10+ serveurs dans le backend. Étant donné que le round-robin envoyait les demandes de 1 au dernier en amont dans l'ordre, et que chaque rechargement de nginx commençait depuis le début, le premier en amont avait toujours plus de demandes que les autres. En conséquence, ils travaillaient plus lentement et l'ensemble du site en souffrait. Cela est devenu plus visible à mesure que la quantité de trafic augmentait. La simple mise à jour de nginx pour activer random n'a pas fonctionné - vous devez refaire un tas de code lua qui n'a pas décollé sur la version 1.15 (à ce moment). J'ai dû patcher notre nginx 1.14.2, en y introduisant un support aléatoire. Cela a résolu le problème. Ce bug remporte la nomination "non-évidence du capitaine".

Conclusions:

Il était très intéressant et passionnant d'étudier ce bug).

Configurez la surveillance de sorte qu'elle aide à trouver rapidement de telles fluctuations. Par exemple, vous pouvez utiliser ELK pour surveiller les rps sur chaque backend de chaque amont, et surveiller leur temps de réponse du point de vue de nginx. Dans ce cas, cela nous a aidés à identifier le problème.

En conséquence, la plupart des échecs auraient pu être évités avec une approche plus scrupuleuse de ce que vous faites. Vous devez toujours vous souvenir de la loi de Murphy: tout ce qui peut mal tourner va mal, et construire des composants en fonction de cela.

Top Fakapov Cyan