Alors que tout le monde fêtait mon anniversaire, j'ai réparé le cluster jusqu'au matin - et les développeurs ont déversé leurs erreurs sur moi





Voici une histoire qui a changé à jamais mon approche des devops. À l'époque des chantiers navals, bien, bien avant eux, quand les gars et moi ne faisions que penser à notre entreprise et à la pige sur des commandes aléatoires, une offre est tombée dans mon panier.



L'entreprise qui a écrit était dans l'analyse de données. Elle traitait des milliers de demandes chaque jour. Ils nous sont venus avec les mots: 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 la gita. Nous voulons un cluster de quatre nœuds avec deux répliques dans chacun.



Une demande standard, il y en a des dizaines, et vous avez besoin de la même bonne solution standard. Nous avons dit "d'accord" et en 2-3 semaines, tout était prêt. Ils ont accepté le poste et ont commencé à déménager vers le nouveau cluster Klickhaus en utilisant notre utilitaire.



Personne avec eux ne voulait ou ne savait comment bricoler Klickhaus. Ensuite, nous avons pensé que c'était leur problème principal, et donc la station service de l'entreprise a simplement donné le feu vert à mon équipe pour automatiser au maximum le travail pour ne pas y retourner.



Nous avons accompagné le déménagement, d'autres tâches sont apparues - mettre en place des sauvegardes et une surveillance. Au même moment, la station-service de cette société a fusionné dans un autre projet, nous laissant pour le commandant de l'un des nôtres - Leonid. Lenya n'était pas un gars très doué. Un simple développeur qui a soudainement été chargé de Klickhaus. Il semble que ce fût sa première mission à diriger quelque chose, et de l'honneur accumulé, il avait la fièvre des étoiles.



Ensemble, nous avons commencé les sauvegardes. J'ai proposé de sauvegarder immédiatement les données originales. Prenez, zippez et jetez élégamment dans certains c3. Les données brutes sont de l'or. Il y avait une autre option - sauvegarder les tables elles-mêmes dans Klickhaus, en utilisant une frise et en copiant. Mais Lenya a proposé sa propre solution.



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



Mais Lenya a fermement saisi le volant et a refusé d'écouter mes arguments. Nous avons passé un long moment avec lui dans la salle de discussion, mais il n'y avait rien à faire - Lenya dirigeait le projet, nous étions juste embauchés dans la rue.



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



Nous n'avions toujours aucune idée que nous avions reçu cette commande en raison d'un terrible malentendu au sein de leur équipe.



Le directeur était mécontent que Klickhaus soit lent et parfois des données étaient perdues. Il a confié à son STO la tâche de le comprendre. Il l'a compris du mieux qu'il pouvait, et a conclu qu'il vous fallait juste automatiser Klickhaus - et c'est tout. Mais comme cela est vite devenu clair, 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'était le jour de mon anniversaire.






Vendredi soir. J'ai réservé une table dans mon bar à vin préféré et j'ai appelé mes potes.



Presque avant de partir, nous avons la tâche de faire un changement, nous le faisons, tout va bien. Alter a réussi, a confirmé Clickhouse. Nous nous sommes déjà rassemblés dans un bar, et ils nous écrivent qu'il n'y a pas assez de données. Ils ont compté - tout semble être suffisant. Et ils sont partis fêter ça.



Le restaurant était bruyant un vendredi soir. Après avoir commandé des boissons, de la nourriture, ils se prélassent sur les canapés. Pendant tout ce temps, mon relâchement était lentement rempli de messages. Ils ont écrit quelque chose sur le manque de données. Je pensais que le matin était plus sage que le soir. Surtout aujourd'hui.



Plus près de onze heures, ils ont commencé à appeler. C'était le chef de l'entreprise ... "Probablement, il a décidé de me féliciter," - Je pensais très incertain, j'ai pris le téléphone.



Et j'ai entendu quelque chose comme: «Vous avez foiré nos données! Je vous paie, mais rien ne fonctionne! Vous étiez en charge des sauvegardes, et vous n'avez pas fait de merde! Fixons-le! " - seulement plus rugueux.



- Tu sais quoi, va te faire foutre! C'est mon anniversaire aujourd'hui, et maintenant je vais boire, pas faire votre merde maison et vos bâtons de juin!



Je n'ai pas dit ça. Au lieu de cela, il a sorti son ordinateur portable et s'est mis au travail.



Non, j'ai bombardé, j'ai bombardé comme l'enfer! J'ai versé caustique "Je vous l'avais dit" dans le chat - parce que la sauvegarde, qui n'était pas une sauvegarde, bien sûr, n'a rien sauvegardé.



Les gars et moi avons trouvé comment arrêter manuellement l'enregistrement et tout vérifier. Vraiment fait en sorte que certaines des données ne soient pas écrites.



Nous avons arrêté l'enregistrement, compté le nombre d'événements qui sont là par jour. Ils ont ajouté plus de données, dont seulement un tiers n'a pas été enregistré. Trois fragments de 2 répliques. Vous insérez 100 000 lignes - 33 000 ne sont pas écrites.



Il y avait une confusion totale. Tout le monde s'est envoyé baiser à son tour: Lenya y est allée la première, suivie de moi et du fondateur de l'entreprise. Seul le SRT joint a essayé d'apporter nos appels avec des cris et de la correspondance dans le sens de trouver une solution au problème.



Ce qui se passait vraiment - personne n'a compris



Les gars et moi avons flippé quand nous avons réalisé qu'un tiers de toutes les données n'étaient pas simplement pas enregistrées - elles étaient perdues! Il s'est avéré que l'ordre dans l'entreprise était le suivant: après l'insertion, les données étaient supprimées de manière irrévocable, les événements étaient déchiquetés par lots. J'ai imaginé comment Sergei convertissait tout cela en roubles perdus.



Mon anniversaire allait aussi à la poubelle. Nous nous sommes assis au bar et avons généré des idées, essayant de résoudre le puzzle lancé. La raison de la chute de Klickhaus n'était pas évidente. C'est peut-être un réseau, peut-être qu'il s'agit des paramètres Linux. Oui, n'importe quoi, les hypothèses sonnaient suffisamment.



Je n’ai pas prêté serment de développement, mais c’était malhonnête de laisser les gars à l’autre bout de la ligne - même s’ils nous blâmaient pour tout. J'étais sûr à 99% que le problème n'était pas dans nos décisions, ni de notre côté. 1% de la chance que nous ayons foiré était toujours brûlée par l'anxiété. Mais quel que soit le côté du problème, il fallait le réparer. Laisser les clients, quels qu'ils soient, avec une fuite de données aussi terrible est trop cruel.



Jusqu'à trois heures du matin, nous avons travaillé à une table de restaurant. Lancer des événements, insérer sélectionnez - et conduit à remplir les blancs. Lorsque vous avez foiré les données, c'est fait comme ceci - vous prenez les données moyennes des jours précédents et les insérez dans les données qui ont été foirées.



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



À 6 heures du matin, j'ai recréé le tableau et les données ont commencé à se remplir. Tout a fonctionné sans perte.






Ensuite, c'était dur. Tout le monde s'est blâmé pour la perte de données. S'il y avait un nouveau bug, je suis sûr qu'une fusillade commencerait



Dans ces srachs, nous avons finalement commencé à comprendre que l'entreprise pensait que nous étions les gars qui travaillaient avec des données et surveillaient la structure des tables. Ils ont confondu les administrateurs avec les dibieys. Et ils sont venus nous demander pas comme des administrateurs.



Leur principale plainte est - putain, vous étiez responsable des sauvegardes et ne les faites pas normalement, vous avez continué les données. Et tout cela avec des coéquipiers de retour.



Je voulais la justice. J'ai déterré la correspondance et joint le tout avec des captures d'écran, où Leonid, de toutes ses forces, a fait la sauvegarde qui a été faite. Leur STO a pris notre parti après mon appel téléphonique. Après cela, Lenya a admis sa culpabilité.



Le chef d'entreprise, en revanche, ne voulait pas blâmer son propre peuple. Les écrans et les mots ne fonctionnaient pas 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'enseigner à Lenya et, de plus, de le contourner, nommé par le chef de projet, à atteindre le point principal et à déverser personnellement tous nos doutes sur le concept de sauvegarde.



Chatik suintait de haine, d'agression cachée et non déguisée. Je ne savais pas quoi faire. Tout est au point mort. Et puis on m'a conseillé le moyen le plus simple - d'écrire au directeur dans une note personnelle et de prendre rendez-vous avec lui. Vasya, les gens dans la vie ne sont pas aussi lévriers que dans le chat. Le patron a répondu à mon message: viens, pas de question.






Ce fut la rencontre la plus drôle de ma carrière. L'allié de mon client - STO - n'a pas pu trouver l'heure. Je suis allé à la réunion avec le patron et Lena.



À maintes reprises, je rejouais notre possible dialogue dans ma tête. J'ai réussi à arriver beaucoup à l'avance, une demi-heure à l'avance. Nerveux a commencé, j'ai fumé 10. J'ai tout compris - moi, putain, seul. Je ne pourrai pas les convaincre. Et est entré dans l'ascenseur.



Pendant qu'il montait, il a frappé avec un briquet pour le casser.



En conséquence, Leni n'était pas à la réunion. Et nous avons eu une bonne discussion sur tout avec le principal! Sergei m'a parlé de sa douleur. Il ne voulait pas «automatiser Clickhouse» - il voulait que les requêtes fonctionnent.



Je n'ai pas vu une chèvre, mais un bon gars, inquiet pour ses affaires, plongé dans le travail 24/7. Le chat nous attire souvent des méchants, des scélérats et des idiots. Mais dans la vie, ce sont des gens comme vous.



Sergei n'avait pas besoin de quelques développeurs à embaucher. Le problème auquel ils étaient confrontés s'est avéré beaucoup 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 DIBI pour elle. Si nous avions découvert au départ que c'était un accord pour eux, nous aurions évité beaucoup. Tard, mais nous avons réalisé que le problème résidait dans le travail de merde avec les données, et non dans l'infrastructure.



Nous nous sommes serrés la main, les frais ont été augmentés deux fois et demie, mais à condition - je prends absolument tout le charbon avec leurs données et Klickhaus pour moi. Dans l'ascenseur, j'ai contacté le même dibieyschik Max et l'ai connecté au travail. Il était nécessaire de pelleter la grappe entière.






Treshak dans le projet adopté était en vrac. En commençant par la "sauvegarde" mentionnée. Il s'est avéré que le même cluster «de sauvegarde» n'était pas isolé. Ils ont tout testé dessus, parfois ils l'ont même laissé en production.



Les développeurs du personnel ont composé leur propre «insert» de données personnalisé. Cela fonctionnait comme ceci: des fichiers batch, exécuter un script et fusionner des données dans une plaque. Mais le principal problème était qu'une énorme quantité de données était acceptée pour une simple demande. Demande de données jointes par seconde. Tout cela pour un seul chiffre - le montant par jour.



Les développeurs internes ont mal utilisé l'outil d'analyse. Ils sont allés au grafana, ont écrit leur demande royale. Il a vidé les données en 2 semaines. Cela s'est avéré être un beau graphique. Mais en fait, la demande de données allait toutes les 10 secondes. Tout cela s'est accumulé dans une file d'attente, puisque Klickhaus n'a tout simplement pas retiré le traitement. Voici la raison principale. Rien ne fonctionnait dans Grafan, les demandes étaient dans une file d'attente, d'anciennes données non pertinentes arrivaient constamment.



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



Max a effectué un audit complet de l'infrastructure. Il a présenté un plan pour passer à 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, qui n'avait rien appris. De tout ce qui était proposé, il a de nouveau choisi son alternative. Comme toujours, c'était la décision la plus sélective ... audacieuse. Lyonya pensait que son entreprise avait un chemin spécial. Épineux et plein d'icebergs.



En fait, sur ce point, nous nous sommes séparés - nous avons fait ce que nous pouvions.






Avec plein de cônes, sages avec cette histoire, nous avons ouvert notre propre entreprise et formé plusieurs principes pour nous-mêmes. Nous ne commencerons jamais à travailler aussi bien maintenant qu'alors.



Après ce projet, Max, le lecteur Debian nous a rejoint, et nous travaillons toujours très bien ensemble. Case with Klickhaus a enseigné comment effectuer un audit complet et approfondi de l'infrastructure avant de commencer les travaux. Nous nous penchons sur la façon dont tout fonctionne, et alors seulement nous acceptons les tâches. Et si auparavant on se précipitait immédiatement pour maintenir l'infrastructure, maintenant on fait d'abord un projet ponctuel, ce qui permet de comprendre comment la mettre en ordre de marche.



Et oui, nous contournons les projets avec des infrastructures de merde. Même si pour beaucoup d'argent, même si c'est par amitié. Il n'est pas rentable de mener des projets malades. Cette prise de conscience nous a aidés à grandir. Soit un projet ponctuel de mise en ordre de l'infrastructure puis un contrat de service, soit nous passons simplement en revue. Passé un autre iceberg.



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



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



All Articles