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

Voici l'histoire qui a définitivement changé ma façon d'aborder le travail en DevOps. Cela remonte à l'époque d'avant la pandémie, bien avant que cela se produise, lorsque mes collègues et moi envisagions de créer notre propre entreprise et faisions du freelancing pour des commandes occasionnelles. Une proposition m'est parvenue sur Telegram.

L'entreprise qui a formulé la demande était spécialisée dans l'analyse de données. Chaque jour, elle traitait des milliers de requêtes. Ils sont venus vers nous en disant : les gars, nous avons ClickHouse et nous voulons automatiser son installation et sa configuration. Nous voulons Ansible, Terraform, Docker et que tout cela soit conservé dans Git. Nous voulons un cluster de quatre nœuds avec deux réplicas chacun.

Une demande classique, parmi des dizaines d'autres, avec le besoin d'une solution standard tout aussi efficace. Nous avons dit « d'accord » et après 2-3 semaines, tout était prêt. Ils ont accepté le travail et ont commencé à migrer vers le nouveau cluster ClickHouse avec notre utilitaire.

Personne chez eux ne voulait ou ne savait s'occuper de ClickHouse. À ce moment-là, nous pensions que c'était leur principal problème, c'est pourquoi le CTO de l'entreprise a donné le feu vert à mon équipe pour automatiser autant que possible les opérations, afin de ne plus avoir à s'en mêler.

Nous avons accompagné la migration et d'autres tâches ont surgi : mettre en place des sauvegardes et une surveillance. À ce moment-là, le CTO de cette entreprise s'est retiré pour un autre projet, nous laissant comme commandant l'un de ses gars — Leonid. Léonid n'était pas très doué. C'était un simple développeur qui s'est soudainement retrouvé chef de ClickHouse. Il semblait que c'était sa première nomination à un poste responsable et l'honneur qui lui était conféré lui a donné un peu de prétention.

Ensemble, nous avons commencé à travailler sur les sauvegardes. J'ai proposé de sauvegarder immédiatement les données sources. Simplement les prendre, les compresser et les envoyer élégamment dans un S3 quelconque. Les données sources sont précieuses. Il existait aussi une autre option : sauvegarder les tables mêmes dans ClickHouse, en utilisant des freezes et des copies. Mais Léonid a inventé sa propre solution.

Il a annoncé qu'il nous fallait un second cluster ClickHouse. Désormais, nous écririons des données sur deux clusters — le principal et le de sauvegarde. Je lui ai dit, écoute Léonid, cela ne sera pas une sauvegarde mais une réplique active. Et si des données commencent à disparaître en production, ta sauvegarde ne contiendra pas autre chose.

Mais Léonid s'accrochait fermement au pilotage et refusait d'écouter mes arguments. Nous avons longtemps discuté dans le chat, mais il n'y avait rien à faire — Léonid dirigeait le projet, nous n'étions que des gars embauchés de la rue.

Nous avons surveillé l'état du cluster et avons facturé uniquement le travail des administrateurs. Administration propre de ClickHouse sans interférer avec les données. Le cluster était accessible, les disques en bon état, les nœuds en ordre.

Nous ne soupçonnions pas encore que nous avions reçu cette commande en raison d'une terrible incompréhension au sein de leur équipe.

Le responsable était mécontent que ClickHouse fonctionne lentement et que des données soient parfois perdues. Il a demandé à son CTO de s'en occuper. Ce dernier a fait de son mieux et a conclu qu'il fallait simplement automatiser ClickHouse — et c'était tout. Mais comme il s'est rapidement avéré, ils n'avaient pas du tout besoin d'une équipe de devops.

Tout cela a été découvert de manière très, très douloureuse. Et le plus ennuyeux, c'était le jour de mon anniversaire.

Vendredi soir. J'avais réservé une table dans mon bar à vin préféré et j'avais invité des amis.

Presque juste avant de sortir, nous avons reçu une petite tâche pour faire une alternative, nous l'avons accomplie, tout était OK. L'alternative est passée, ClickHouse a confirmé. Nous étions déjà prêts à aller au bar, et on nous écrit qu'il manque des données. Nous avons compté — apparemment, tout est suffisant. Et nous sommes partis faire la fête.

Le restaurant était bruyant comme un vendredi. Après avoir commandé des boissons et de la nourriture, nous nous sommes affalés sur des canapés. Pendant tout ce temps, ma Slack était lentement inondée de messages. Ils parlaient de manque de données. J'ai pensé — le matin est plus sage que le soir, surtout en ce jour.

Vers onze heures, ils ont commencé à m'appeler. C'était le responsable de l'entreprise... "Il a probablement décidé de me féliciter", ai-je pensé très incertainement, puis j'ai décroché.

Et j'ai entendu quelque chose du genre : "Vous avez perdu nos données ! Je vous paie, mais rien ne fonctionne ! Vous étiez responsables des sauvegardes, et vous n'avez rien fait ! Réparez ça !" — mais encore plus grossièrement.

— Tu sais quoi, va te faire voir ! Aujourd'hui, c'est mon anniversaire, et je vais picoler, pas m'occuper de tes bricolages douteux !

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

Non, j'étais en furie, j'étais vraiment en colère ! J'ai balancé dans le chat des "je l'avais dit" acerbes — parce que la sauvegarde, qui n'était pas du tout une sauvegarde, n'a bien sûr rien sauvé.

Avec les gars, nous avons trouvé comment arrêter manuellement l'enregistrement et tout vérifier. Nous avons vraiment confirmé qu'une partie des données ne s'écrivait pas.

Nous avons arrêté l'enregistrement, compté le nombre d'événements qui s'y trouvaient au cours de la journée. Nous avons ajouté encore des données, mais seulement un tiers n'a pas été enregistré. Trois shards avec 2 répliques. Tu insères 100 000 lignes — 33 000 ne s'enregistrent pas.

C'était le chaos total. Tout le monde s'envoyait balader à tour de rôle : le premier à partir là-bas était Léon, suivi de moi et du fondateur de l'entreprise. Le CTO, qui venait juste de rejoindre, essayait de gérer nos appels avec des cris et nos messages pour trouver une solution au problème.

Ce qui se passait réellement — personne ne comprenait.

Nous étions complètement sidérés, réalisant qu'un tiers de toutes les données ne s'enregistraient pas juste — elles étaient perdues ! Il s'est avéré que l'ordre dans l'entreprise était tel : après insertion, les données étaient supprimées de manière irréversible, les événements se perdaient par paquets. J'ai imaginé comment Sergey convertissait tout cela en roubles non perçus.

Mon anniversaire aussi a été jeté à la poubelle. Nous étions assis dans un bar, générant des idées, essayant de résoudre le rébus lancé. La raison de la chute de ClickHouse n'était pas évidente. Peut-être était-ce le réseau, peut-être un problème de configuration de Linux. N'importe quoi, suffisamment d'hypothèses ont été formulées.

Je n'avais pas prêté le serment des développeurs, mais abandonner les gars au bout du fil était déloyal — même s'ils nous blâmaient pour tout. J'étais sûr à 99 % que le problème ne venait pas de nos solutions, pas de notre côté. 1 % de chance que ce soit nous qui ayons merdé me brûlait d'angoisse. Mais peu importe où se trouvait le problème — il fallait le corriger. Laisser les clients, peu importe qui ils étaient, avec une telle terrible fuite de données — c'était trop cruel.

Nous avons travaillé jusqu'à trois heures du matin à la table d'un restaurant. Nous ajoutions des événements, faisions des insert select — et nous avons commencé à combler les lacunes. Quand tu as perdu des données, tu procèdes de cette façon : tu prends les données moyennes des jours précédents et tu les insères dans celles qui sont perdues.

Après trois heures du matin, mon pote et moi sommes rentrés chez moi, avons commandé de la bière à un magasin d'alcool. Je me suis retrouvé avec mon ordinateur portable et les problèmes de ClickHouse, mon ami me racontait quelque chose. Au bout d'une heure, il s'est fâché parce que je travaillais et ne buvais pas de bière avec lui, et est parti. Classique — il a été ami avec un devops.

À 6 heures du matin, j'ai recréé la table à nouveau, et les données ont commencé à être chargées. Tout a fonctionné sans pertes.

Après cela, c'était difficile. Tout le monde s'accusait mutuellement de la perte de données. Si un nouveau bug apparaissait, je suis sûr qu'une fusillade aurait commencé.

Dans ces disputes, nous avons enfin commencé à comprendre — dans l'entreprise, ils pensaient que nous étions les gars qui s'occupent des données et veillent à la structure des tables. Ils ont confondu les admins avec les DBA. Et ils sont venus nous demander non pas en tant qu'administrateurs.

Leur principale plainte était — c'est quoi ce bordel, vous étiez responsables des sauvegardes et vous ne les avez pas faites correctement, vous avez perdu des données. Et tout cela avec des gros mots.

Je voulais de la justice. J'ai déterré la correspondance et j'ai joint tous les écrans où Leonid exige de toutes ses forces de faire une sauvegarde comme celle qui avait été faite. Leur CTO s'est rangé de notre côté après mon appel téléphonique. Par la suite, Leonid a reconnu sa faute.

Le chef de l'entreprise, au contraire, ne voulait pas blâmer les siens. Les captures d'écran et les mots n'avaient pas d'effet sur lui. Il pensait que puisque nous étions des experts ici, nous aurions dû convaincre tout le monde et maintenir notre décision. Il semblerait que notre tâche était d'enseigner à Leonid et, en plus de contourner lui, le responsable du projet, d'arriver au chef et de lui exprimer toutes nos doutes sur le concept des sauvegardes.

Le chat débordait de haine, d'agressivité cachée et non cachée. Je ne savais pas quoi faire. Tout semblait être dans une impasse. Et là, on m'a conseillé la méthode la plus simple — écrire en privé au directeur et convenir d'une réunion avec lui. Vasya, les gens dans la vie ne sont pas aussi osés que dans le chat. En réponse à mon message, le patron a dit : viens, pas de problème.

C'était la rencontre la plus désagréable de ma carrière. Mon allié chez le client — le CTO — n'a pas pu trouver le temps. Sur le chemin, j'allais voir le patron et Leonid.

Je repassais encore et encore dans ma tête notre dialogue possible. J'ai même réussi à arriver très en avance, une demi-heure à l'avance. Le stress a commencé, j'ai fumé dix cigarettes. Je comprenais, c'était fini — j'étais seul. Je ne pouvais pas les convaincre. Et j'ai pénétré dans l'ascenseur.

Pendant que je montais, j'ai tellement fait couiner mon briquet que je l'ai cassé.

Finalement, Leonid n'était pas présent à la réunion. Et nous avons très bien parlé avec le patron ! Sergey m'a parlé de sa douleur. Il ne voulait pas « automatiser ClickHouse » — il voulait que « les requêtes fonctionnent ».

Je n'ai pas vu un salaud, mais un bon gars, préoccupé par son entreprise, plongé dans le travail 24/7. Le chat nous dépeint souvent des méchants, des scélérats et des idiots. Mais dans la vie, ce sont des gens comme toi.

Sergey n'avait pas besoin de quelques DevOps freelance. Le problème qu'ils avaient rencontré était beaucoup plus important.

J'ai dit que je pouvais résoudre ses problèmes — c'est juste un tout autre travail, et j'ai un ami DBA pour cela. Si nous avions su dès le départ que c'était pour eux, nous aurions évité beaucoup de choses. Il est trop tard, mais nous avons compris que le problème venait d'un mauvais travail sur les données, et non de l'infrastructure.

Nous avons échangé des poignées de main, notre tarif a grimpé de deux fois et demie, mais avec la condition — je prends absolument tout le casse-tête de leurs données et de ClickHouse sur moi. Dans l'ascenseur, j'ai contacté le DBA Max et l'ai intégré au projet. Il fallait refondre tout le cluster.

Il y avait beaucoup de déchets dans le projet accepté. À commencer par le « backup » mentionné. Il s'est avéré que ce même cluster de « backup » n'était pas isolé. On testait tout dessus, et parfois même on le mettait en production.

Les développeurs internes avaient créé leur propre « injecteur » de données. Il fonctionnait comme ceci : il traitait des fichiers en lot, exécutait un script et ajoutait des données dans la table. Mais le principal problème était que d'énormes quantités de données étaient acceptées pour une simple requête. La requête joignait les données par seconde. Tout cela pour un seul chiffre — la somme de la journée.

Les développeurs internes utilisaient mal l'outil d'analyse. Ils allaient sur Grafana, écrivaient leur requête royale. Elle extrayait des données sur 2 semaines. Cela faisait un joli graphique. Mais en réalité, la requête de données s'exécutait toutes les 10 secondes. Tout cela s'accumulait dans la file d'attente, car ClickHouse ne pouvait tout simplement pas traiter le tout. C'est là que se cachait la vraie raison. Rien ne fonctionnait dans Grafana, les requêtes étaient bloquées en attente, et des données anciennes et non pertinentes arrivaient constamment.

Nous avons reconfiguré le cluster, retravaillé l'insertion. Les développeurs internes ont réécrit leur « injecteur », et il a commencé à sharder les données correctement.

Max a effectué un audit complet de l'infrastructure. Il a détaillé un plan de transition vers un backend complet. Mais cela n'a pas satisfait l'entreprise. Ils attendaient de Max un secret magique qui permettrait de travailler de la vieille manière, mais de manière efficace. Le projet était toujours sous la responsabilité de Léna, qui n'avait rien appris. Parmi tout ce qui avait été proposé, il a une fois de plus choisi sa propre alternative. Comme d'habitude, c'était la plus audacieuse... la plus courageuse. Léna pensait que son entreprise avait un chemin spécial. Semé d'embûches et rempli d'icebergs.

En fait, c'est là-dessus que nous nous sommes séparés — nous avons fait ce que nous avons pu.

Avec des expériences passées et enrichis de cette histoire, nous avons lancé notre entreprise et défini plusieurs principes pour nous-mêmes. Aujourd'hui, nous ne commençons jamais un projet de la même manière qu'à l'époque.

Le développeur Max a rejoint notre équipe après ce projet et nous travaillons toujours très bien ensemble. Le cas de ClickHouse nous a appris à réaliser un audit complet et approfondi de l'infrastructure avant de commencer un travail. Nous comprenons comment tout fonctionne, puis nous acceptons les tâches. Si auparavant nous étions tentés de gérer l'infrastructure immédiatement, nous faisons maintenant d'abord un projet ponctuel qui aide à comprendre comment la remettre en état de marche.

Et oui, nous évitons les projets avec une infrastructure défaillante. Même pour beaucoup d'argent, même par amitié. Gérer des projets problématiques n'est pas rentable. Prendre conscience de cela nous a permis de grandir. Soit nous faisons un projet ponctuel pour remettre en ordre l'infrastructure, suivi d'un contrat de maintenance, soit nous passons tout simplement notre chemin. En évitant un autre iceberg.

P.S. Donc, si vous avez des questions sur votre infrastructure, n'hésitez pas à laisser une demande.

Nous proposons 2 audits gratuits par mois, peut-être que votre projet sera sélectionné.

Source : habr.com