Pendant que tout le monde fêtait mon anniversaire, je réparais le cluster jusqu'au matin - et les développeurs m'ont imputé leurs erreurs

Voici une histoire qui a changé à jamais mon approche du travail devops. À l'époque pré-Covid, bien, bien avant eux, alors que les gars et moi planifiions simplement notre propre entreprise et travaillions en indépendant sur des commandes aléatoires, une offre est tombée dans mon panier.

L'entreprise qui a écrit ceci était une société d'analyse de données. Elle traitait quotidiennement des milliers de demandes. Ils nous ont dit : les gars, nous avons ClickHouse et nous voulons automatiser sa configuration et son installation. Nous voulons qu'Ansible, Terraform, Docker et tout cela soient stockés dans Git. Nous voulons un cluster de quatre nœuds avec deux répliques chacun.

C’est une demande standard, il y en a des dizaines, et vous avez besoin d’une solution standard tout aussi bonne. Nous avons dit « ok » et après 2-3 semaines, tout était prêt. Ils ont accepté le poste et ont commencé à migrer vers un nouveau cluster Clickhouse à l'aide de notre utilitaire.

Personne ne voulait ni ne savait comment bricoler Clickhouse. Ensuite, nous avons pensé que c'était leur principal problème, et c'est pourquoi la station-service de l'entreprise a simplement donné le feu vert à mon équipe pour automatiser le travail au maximum, afin de ne plus jamais y aller moi-même.

Nous avons accompagné le déménagement, d'autres tâches sont apparues : mise en place des sauvegardes et du monitoring. Au même moment, la station-service de cette compagnie a fusionné avec un autre projet, nous laissant comme commandant l'un des nôtres - Leonid. Lenya n'était pas un gars très doué. Un simple développeur qui s'est soudainement retrouvé à la tête de Clickhouse. Il semble que c’était sa première mission de gérer quelque chose, et cet immense honneur l’a fait se sentir frappé par les étoiles.

Ensemble, nous avons commencé à faire des sauvegardes. J'ai suggéré de sauvegarder immédiatement les données originales. Prenez-le, zippez-le et jetez-le élégamment dans du c3. Les données brutes valent de l’or. Il y avait une autre option : sauvegarder les tables elles-mêmes dans Clickhouse, en les gelant et en les copiant. Mais Lenya a trouvé sa propre solution.

Il a annoncé que nous avions besoin d'un deuxième cluster Clickhouse. Et à partir de maintenant, nous écrirons les données sur deux clusters : le cluster principal et le cluster de sauvegarde. Je lui dis, Lenya, ce ne sera pas une sauvegarde, mais une réplique active. Et si des données commencent à se perdre en production, la même chose se produira sur votre sauvegarde.

Mais Lenya a fermement saisi le volant et a refusé d'écouter mes arguments. Nous avons longuement discuté avec lui dans le chat, mais il n'y avait rien à faire - Lenya était en charge du projet, nous étions juste embauchés par des enfants de la rue.

Nous avons surveillé l'état du cluster et facturé uniquement le travail des administrateurs. Administration pure de Clickhouse sans entrer dans les données. Le cluster était disponible, les disques allaient bien, les nœuds allaient bien.

Nous ne savions pas que nous avions reçu cette commande suite à un terrible malentendu au sein de leur équipe.

Le responsable était mécontent de la lenteur de Clickhouse et de la perte parfois de données. Il a confié à sa station-service la tâche de le découvrir. Il a compris du mieux qu'il pouvait et a conclu que nous avions juste besoin d'automatiser Clickhouse - c'est tout. Mais comme il est vite devenu évident qu’ils n’avaient pas du tout besoin d’une équipe de développeurs.

Tout cela s’est avéré très, très douloureux. Et le plus offensant, c'est que c'était le jour de mon anniversaire.

Vendredi soir. J'ai fait une réservation dans mon bar à vins préféré et j'ai invité les potes.

Presque avant de partir, nous recevons une tâche pour créer un alter, nous la terminons, tout va bien. Modification passée, Clickhouse confirmé. Nous allons déjà au bar et ils nous écrivent qu'il n'y a pas assez de données. Nous avons calculé que tout semble suffire. Et ils sont partis faire la fête.

Le restaurant était bruyant un vendredi. Après avoir commandé des boissons et de la nourriture, nous nous sommes allongés sur les canapés. Pendant tout ce temps, mon slack était lentement inondé de messages. Ils ont écrit quelque chose sur le manque de données. J'ai pensé : le matin est plus sage que le soir. Surtout aujourd'hui.

Vers onze heures, ils ont commencé à appeler. C'était le chef de l'entreprise... «Il a probablement décidé de me féliciter», ai-je pensé avec beaucoup d'hésitation et j'ai décroché le téléphone.

Et j'ai entendu quelque chose comme : « Vous avez foiré nos données ! Je te paie, mais rien ne marche ! Vous étiez responsable des sauvegardes, et vous n’avez rien fait ! Réparons-le !" - mais encore plus grossier.

- Tu sais quoi, fous le camp ! Aujourd'hui, c'est mon anniversaire, et maintenant je vais boire, et ne pas me lancer dans vos produits faits maison de juin à partir de merde et de bâtons !

C'est ce que je n'ai pas dit. Au lieu de cela, j’ai sorti mon ordinateur portable et je me suis mis au travail.

Non, j'ai bombardé, j'ai bombardé comme un diable ! Il a lancé un «Je vous l'avais bien dit» caustique dans le chat - parce que la sauvegarde, qui n'était pas du tout une sauvegarde, - bien sûr, n'a rien sauvegardé.

Les garçons et moi avons compris comment arrêter manuellement l'enregistrement et tout vérifier. Nous nous sommes en fait assurés que certaines données n'étaient pas écrites.

Nous avons arrêté l'enregistrement et compté le nombre d'événements qui se produisaient chaque jour. Ils ont téléchargé davantage de données, dont seulement un tiers n’a pas été enregistré. Trois fragments avec 2 répliques chacun. Vous insérez 100.000 33.000 lignes – XNUMX XNUMX ne sont pas enregistrées.

La confusion était totale. Tout le monde se disait de se faire foutre à tour de rôle : Lenya y est allée en premier, suivie de moi et du fondateur de l'entreprise. Seule la station-service qui nous a rejoint a tenté de détourner nos appels et notre correspondance vers la recherche d'une solution au problème.

Personne n'a compris ce qui se passait réellement

Les gars et moi avons été tout simplement époustouflés lorsque nous avons réalisé qu'un tiers de toutes les données non seulement n'étaient pas enregistrées, mais étaient perdues ! Il s'est avéré que l'ordre dans l'entreprise était le suivant : après insertion, les données étaient supprimées de manière irrévocable, les événements étaient gaspillés par lots. J'imaginais comment Sergei convertirait tout cela en roubles perdus.

Mon anniversaire a également été jeté à la poubelle. Nous nous sommes assis au bar et avons généré des idées, essayant de résoudre l'énigme qui nous avait été lancée. La raison de la chute de Clickhouse n’était pas évidente. C'est peut-être le réseau, peut-être les paramètres Linux. Oui, quoi que vous vouliez, il y a eu suffisamment d'hypothèses.

Je n'ai pas prêté le serment du développeur, mais c'était malhonnête d'abandonner les gars à l'autre bout du fil - même s'ils nous blâmaient pour tout. J’étais sûr à 99 % que le problème ne résidait pas dans nos décisions, ni de notre côté. Les 1% de chances que nous ayons fait une erreur brûlaient d'anxiété. Mais peu importe de quel côté se trouvait le problème, il fallait le régler. Laisser les clients, quels qu’ils soient, avec une fuite de données aussi terrible est trop cruel.

Nous avons travaillé à la table du restaurant jusqu'à trois heures du matin. Nous avons ajouté des événements, inséré une sélection et nous sommes partis combler les lacunes. Lorsque vous gâchez les données, voici comment procéder : vous prenez les données moyennes des jours précédents et vous les insérez dans celles qui sont foutues.

Après trois heures du matin, mon ami et moi sommes allés chez moi et avons commandé une bière au marché de l'alcool. J'étais assis avec un ordinateur portable et des problèmes avec Clickhouse, un ami me disait quelque chose. En conséquence, au bout d'une heure, il a été offensé par le fait que je travaillais et que je ne buvais pas de bière avec lui, et il est parti. Classique - J'étais un ami de Devops.

À 6 heures du matin, j'ai recréé la table et les données ont commencé à affluer. Tout a fonctionné sans aucune perte.

Ensuite, c'était dur. Tout le monde s’est reproché la perte de données. Si un nouveau bug était survenu, je suis sûr qu'il y aurait eu une fusillade

Dans ces combats, nous avons finalement commencé à comprendre : l'entreprise pensait que nous étions ceux qui travaillaient avec des données et surveillions la structure des tableaux. Ils ont confondu les administrateurs avec les revendeurs. Et ils sont venus nous demander quelque chose de différent des administrateurs.

Leur principal reproche est le suivant : bon sang, vous étiez responsable des sauvegardes et vous ne les avez pas faites correctement, vous avez continué à gaspiller les données. Et tout cela avec des tapis rembobinables.

Je voulais justice. J'ai déterré la correspondance et joint des captures d'écran de tout le monde, où Leonid les oblige de toutes ses forces à faire la sauvegarde qui a été effectuée. Leur station-service a pris notre parti après mon appel téléphonique. Plus tard, Lenya a admis sa culpabilité.

Le chef d’entreprise, au contraire, n’a pas voulu rejeter la faute sur ses propres collaborateurs. Les captures d’écran et les mots n’ont eu aucun effet sur lui. Il pensait que puisque nous étions des experts ici, nous devions convaincre tout le monde et insister sur notre décision. Apparemment, notre tâche était d'apprendre à Lenya et, de plus, de le contourner, qui a été nommé chef de projet, pour aller à l'essentiel et lui faire personnellement part de tous nos doutes sur le concept de sauvegarde.

La conversation débordait de haine, d’agression cachée et non cachée. Je ne savais pas quoi faire. Tout est au point mort. Et puis ils m'ont conseillé le moyen le plus simple : écrire un message personnel au manager et organiser un rendez-vous avec lui. Vasya, les gens dans la vraie vie ne sont pas aussi rapides que dans le chat. Le patron a répondu à mon message : viens, pas de question.

C'était la rencontre la plus effrayante de ma carrière. Mon allié du client - STO - n'a pas trouvé le temps. Je suis allé à la réunion avec le patron et Lena.

Encore et encore, je rejouais notre possible dialogue dans ma tête. J'ai réussi à arriver très tôt, une demi-heure à l'avance. J'ai commencé à devenir nerveux, j'ai fumé 10 cigarettes, j'ai compris, c'est tout, je suis seul, putain. Je ne pourrai pas les convaincre. Et il entra dans l'ascenseur.

Alors qu'il se relevait, il frappa si fort le briquet qu'il le cassa.

En conséquence, Lenya n'était pas présente à la réunion. Et nous avons eu une super conversation sur tout avec le patron ! Sergei m'a parlé de sa douleur. Il ne voulait pas « automatiser Clickhouse » – il voulait « faire fonctionner les requêtes ».

Je n’ai pas vu de chèvre, mais un type bien, soucieux de ses affaires, plongé dans le travail 24h/7 et XNUMXj/XNUMX. Le chat nous attire souvent des méchants, des canailles et des gens stupides. Mais dans la vie, ce sont des gens comme vous.

Sergei n'avait pas besoin de quelques développeurs à embaucher. Le problème qu’ils s’étaient posé s’était avéré bien plus important.

J’ai dit que je pouvais résoudre ses problèmes – c’est juste un travail complètement différent, et j’ai un ami qui travaille pour ça. Si nous avions su dès le début que c’était un accord pour eux, nous aurions évité beaucoup de choses. Il est tard, mais nous avons réalisé que le problème résidait dans une mauvaise gestion des données et non dans l'infrastructure.

Nous nous sommes serrés la main, ils ont augmenté notre salaire deux fois et demie, mais à condition que je prenne absolument tout le désordre avec leurs données et Clickhouse pour moi. Dans l'ascenseur, j'ai communiqué avec ce même type DI Max et je l'ai mis en contact avec le travail. Il a fallu pelleter toute la grappe.

Il y avait beaucoup de déchets dans le projet adopté. En commençant par la « sauvegarde » mentionnée. Il s’est avéré que ce même cluster « de secours » n’était pas isolé. Ils ont tout testé dessus, le mettant parfois même en production.

Nos développeurs internes ont créé leur propre outil d'insertion de données personnalisé. Il a travaillé comme ceci : il a regroupé les fichiers, exécuté le script et fusionné les données dans un tableau. Mais le principal problème était qu’une énorme quantité de données était acceptée pour une simple demande. La requête rejoint les données toutes les secondes. Tout cela pour un seul chiffre : le montant par jour.

Les développeurs internes ont mal utilisé l’outil d’analyse. Ils se rendirent à la grafana et rédigèrent leur demande royale. Il a téléchargé des données pendant 2 semaines. Il s’est avéré que c’était un beau graphique. Mais en réalité, la demande de données était toutes les 10 secondes. Tout cela s'accumulait dans une file d'attente parce que Clickhouse n'avait tout simplement pas supprimé le traitement. C’est là que se cachait la raison principale. Rien ne fonctionnait dans Grafana, les demandes restaient dans une file d'attente et des données anciennes et non pertinentes arrivaient constamment.

Nous avons reconfiguré le cluster, refait l'insertion. Les développeurs internes ont réécrit leur « inserteur » et celui-ci a commencé à partager correctement les données.

Max a réalisé un audit complet de l'infrastructure. Il a présenté un plan de transition vers un backend à part entière. Mais cela ne convenait pas à l’entreprise. Ils attendaient de Max un secret magique qui leur permettrait de travailler à l'ancienne, mais seulement efficacement. Lenya était toujours en charge du projet et il n'a rien appris. Parmi tout ce qui lui était proposé, il choisit à nouveau son alternative. Comme toujours, ce fut la décision la plus sélective… la plus audacieuse. Lenya pensait que son entreprise avait un chemin particulier. Épineux et plein d'icebergs.

En fait, c’est là que nous nous sommes séparés – nous avons fait ce que nous pouvions.

Pleins de connaissances et de sagesse issues de cette histoire, nous avons ouvert notre propre entreprise et nous sommes forgés plusieurs principes. Nous ne commencerons plus jamais à travailler de la même manière qu’à l’époque.

DJ Max nous a rejoint après ce projet, et nous travaillons toujours très bien ensemble. Le cas Clickhouse m'a appris à réaliser un audit complet et approfondi de l'infrastructure avant de commencer les travaux. Nous comprenons comment tout fonctionne et acceptons ensuite les tâches. Et si auparavant nous nous précipitions immédiatement pour entretenir l'infrastructure, nous réalisons désormais d'abord un projet ponctuel, qui nous aide à comprendre comment la mettre en état de marche.

Et oui, nous évitons les projets avec des infrastructures merdiques. Même si c'est pour beaucoup d'argent, même si c'est par amitié. Il n’est pas rentable de mener des projets malades. Réaliser cela nous a aidé à grandir. Soit un projet ponctuel pour remettre de l'ordre dans l'infrastructure, puis un contrat de maintenance, soit nous passons par là. Passé un autre iceberg.

PS Donc si vous avez des questions sur votre infrastructure, N'hésitez pas à faire une demande.

Nous organisons 2 audits gratuits par mois, peut-être que votre projet en fera partie.

Source: habr.com