La tragédie (de l'
allemand Tragödie du
latin tragoedia de l'
autre grec τραγωδία) est un genre d'œuvres d'art destiné à être mis en scène sur une scène dans laquelle l'intrigue mène les personnages à une issue catastrophique.
La plupart des tragédies sont écrites en vers. Cette tragédie a été écrite par Baruch Sadogursky (
@jbaruch ) et Leonid Igolnik (
@ligolnik ). Si nous parlons de DevOps à grande échelle, qu'est-ce qu'une tragédie?
Cet article est marqué par la sévérité du réalisme, dépeint la réalité d'un grand développement de manière plus précise, comme un tas de contradictions internes. Il révèle les conflits les plus profonds de la réalité sous une forme extrêmement intense et saturée, acquérant la valeur d'un symbole artistique.
Et maintenant, nous avons fini de jouer à Belinsky et bienvenue dans la coupe! Il y a du texte et de la vidéo. Ne prenez pas d'otages!
Comme vous le savez, les Grecs adoraient les diagrammes de Venn. Et nous vous en montrerons jusqu'à trois - et tout sur DevOps.
Il existe une description traditionnelle de DevOps - il s'agit de l'intersection des domaines des opérations, du développement et de l'assurance qualité. Il est historiquement intéressant que l'AQ y ait été ajoutée plus tard.
Mais aujourd'hui, nous allons parler d'autre chose - l'intersection de la technologie, des processus et des personnes. À propos de ce que vous devez faire avec ces trois composants pour obtenir DevOps.
Comparez maintenant deux autres graphiques:
Cela arrive parfois.
Pentagon Inc.
Commençons l'histoire avec une entreprise mythique appelée Pentagone, qui s'occupe des transactions par carte de crédit.
Acte I - Pompiers
Les gens . L'entreprise vient de commencer son travail, elle compte trois ingénieurs. Tous les trois provenaient de la même entreprise de défense. Les gars sont assez intelligents, ils ont donc tout: JavaScript, Node, React, Docker, microservices.
Processus . À quoi pourrait ressembler le processus lorsqu'il y a trois personnes dans une équipe? Kanban: soit sur une feuille de papier, soit sur Trello. Les gars sont intelligents et comprennent que l'AQ est nécessaire dès le début, donc TDD, tests unitaires et d'intégration. Pas d'opérations, toutes ont racine.
Des outils En conséquence, pour trois personnes qui ne font que soulever quelque chose:
JIRA ,
GitHub ,
Travis CI , etc.
Parlons de la façon dont ces gens vivent sur cette belle pile. Tout d'abord, comme dans les bonnes startups - nous scions, scions un produit et attendons le premier client.
Soudain, un miracle s'est produit - une organisation qui organise les meilleures conférences dans l'espace post-soviétique a décidé de faire confiance à ces gars et de faire leurs transactions à travers eux.
Que fait une vraie startup lorsqu'elle obtient son premier client? Fête! Et quelque part vers trois heures du soir, quand tout est dans un état
spécial , le client appelle et dit que rien ne fonctionne.
Bien sûr, tout d'abord, paniquez!
La prochaine étape est de se battre! Nous regardons les journaux, par exemple.
Nous avons regardé, regardé, il s'est avéré que l'un de nos trois héros - Vasya, revenu à la maison après le festival, avait commis sa petite idée. Nous nous souvenons qu'après la validation et les tests réussis, tout s'envole en production.
Eh bien, lequel d'entre nous n'a pas échoué à la production? Nous ne blâmerons pas Vasya. Revenez à la validation précédente. Ça ne va pas! Pour une raison quelconque, il n'y a pas assez de bibliothèque, appelée left-pad.
Pour ceux qui ne savent pas ce qui est arrivé au pavé gauche, nous le disons. Ainsi,
le 23 mars 2016, la moitié d'Internet s'est cassée . En général, le module du pavé gauche en JavaScript insère simplement des espaces sur le côté gauche des lignes. Et la moitié d'Internet dépendait directement ou transitoirement de ce module. L'auteur de la gauche-pad a réussi à se quereller avec les propriétaires du dépôt central npm, alors il s'est éloigné d'eux, prenant tout son travail. npm est généralement un système mystérieux: non seulement ils vérifient lorsque vous ajoutez un nouveau module à télécharger, ils vérifient également tous les anciens modules.
Ainsi, maintes et maintes fois, la lutte contre le feu continue. Et les problèmes sont toujours les mêmes.
Acte II - Installateurs d'alarme incendie
Nouvelles de l'entreprise: levé la pâte, trouvé un investisseur, embauché 27 personnes, dont une avec une expérience opérationnelle. 100 clients sont apparus et même un support technique.
En conséquence, le processus doit également obtenir une mise à niveau. Scrum normal, tests exploratoires, est apparu. Nous avons réalisé que NoOps n'existe pas du tout, car il y a Ops (si l'architecture est sans serveur, alors le serveur est toujours là, ce n'est tout simplement pas le vôtre). Puisqu'il est mal de réveiller toute l'équipe la nuit, un développeur sur appel est apparu.
En conséquence, l'ensemble d'outils s'est élargi. Au minimum, la base de connaissances est apparue, car il y a maintenant un préposé et il doit chercher des informations quelque part. Une autre nouveauté est
JFrog Artifactory : un système qui vous permet de stocker ce qui a été amarré hier afin que vous puissiez facilement revenir en arrière (la leçon avec le pavé gauche n'a pas été en vain), plutôt que de tout reconstruire à nouveau. Nous avons mis en place un système de collecte et de recherche des journaux.
Pingdom a été ajouté - système de surveillance enchanteur: vous lui donnez une URL, et il vous indique si cela fonctionne ou s'il est tombé en panne.
Donc, à ce stade, ils ont à nouveau collecté de l'argent. Donc, notons-le. Vendredi, à trois heures du matin, le client appelle. Quelque chose ne fonctionne pas: Visa et MasterCard passent, mais American Express ne fonctionne pas.
Et comment le support réagit-il pour la première fois lorsqu'un client appelle à trois heures du matin? Panique!
Ensuite, nous appelons le préposé. Devinez qui est en service? Bien sûr, Vasya! Devinez dans quel état se trouve Vasya. Ouais Mais Vasya se ressaisit, examine le soutien qui lui a été envoyé et dit qu'il est tous étrangement familier avec cela et qu'il l'a déjà fait. Par conséquent, Vasya prend simplement et répare. Tout le monde va dormir. Le débriefing commence lundi.
Voici un exemple de document spécifique que nous produisons pour la base de connaissances, de sorte que si quelque chose se répète, il peut être rapidement trouvé. De plus, il est parfois montré aux clients:
Le document affiche les principales rubriques, les raisons, les caractéristiques, une liste d'événements. Les symptômes doivent être indiqués, une description technique est donnée de ce qui s'est exactement cassé et comment y remédier. La partie la plus importante du document est la raison principale pour laquelle quelque chose est tombé.
Dans le cas de Vasya, nous avons un dépassement de file d'attente de journal. Vous devez l'effacer des transactions par carte de crédit et, en outre, augmenter sa taille. Par exemple, à 42 ans!
Un tel procédé est très bon pour l'amélioration continue interne et il garantit l'installation de ces mêmes "détecteurs de fumée". La deuxième raison pour laquelle ce document est important est le rapport au client. Certains services, après avoir «pondu» pendant un certain temps, en publient les raisons.
Parfois, le problème s'avère si catastrophique qu'il ne vaut pas la peine d'en parler.
Dans GitLab
en février 2017 , une personne a supprimé une base de données de production. Voici l'analyse que GitLab a téléchargée:
Donc, quelque part, il y a une sauvegarde, personne ne sait où. Ensuite, des sauvegardes ont été trouvées, mais elles se sont avérées vides. Oui, il y a un vidage de base. Mais il a été fabriqué dans une version différente de PostgreSQL, donc il ne convient pas. Nous avons des instantanés, mais ils n'ont pas de base de données. La réplication à partir de S3 n'a pas fonctionné non plus en raison du manque de données.
Ainsi, cinq techniques différentes de sauvegarde des données n'ont pas fonctionné. Nous pensons que cela ne peut pas être publié, car personne d'autre ne leur fera confiance. Mais, selon la façon dont vous en parlez, le client peut pardonner. C'est vrai, une seule fois.
Soit dit en passant, le gars qui l'a fait a obtenu une promotion. En outre, il a changé son statut Twitter en
spécialiste de la
base de
données (suppression) chez GitLab .
Acte III - Climax
Que se passe-t-il donc dans notre entreprise? Ils ont à nouveau collecté de l'argent, embauché un groupe de personnes - nous avons maintenant cinq ingénieurs opérationnels et une personne engagée dans la performance. Il y a un architecte en chef. Une équipe de réussite client est apparue, couvrant toutes les industries qui peuvent avoir besoin de soutien. Ils sont ralentis pour que le reste de l'équipe puisse continuer à travailler. Souvent, dans une telle équipe, il y a un groupe qui peut établir des relations avec les opérations ou le support, et aussi périodiquement, vous devez déposer des ingénieurs en mêlée, ou en sprint, ou pendant un mois. L'entreprise a grandi, un avocat, un directeur financier est apparu. La base de clients est passée à 1000.
À mesure que l'équipe grandit, le processus de développement doit changer.
SAFE est apparu - un cadre qui explique quoi faire Scrum quand il y a beaucoup d'équipes ou de centres de développement - plus d'un. Le nombre de processus présents dans Safe peut tuer un cheval, mais si seulement tous peuvent être pris en même temps. Si vous n'enlevez que les pièces nécessaires à ce stade du développement de l'entreprise, tout devrait bien se passer.
Les tests système apparaissent lorsque de grandes équipes ont certains besoins ou si vous avez un énorme système à partir duquel vous devez construire quelque chose. Les équipes de mêlée individuelles peuvent bien tester leurs systèmes, mais quelqu'un doit être responsable du fait que l'ensemble du système doit être assemblé en production.
Et Ops Team? Comme nous l'avons dit, il existe deux options pour effectuer des DevOps. Le premier concerne le livre et les instructions de Netflix, Google et Twitter. Le second est dans la vie réelle, où tous les ingénieurs ne peuvent pas faire confiance à la racine de la production.
Le chemin d'escalade est un concept important qui vous permet de résoudre tout problème à un moment donné, car à la fin du chemin d'escalade, il y a un téléphone portable du PDG, après un appel vers lequel tous les problèmes disparaissent en 5 heures 58 minutes.
SOC II - un ensemble de normes que le fournisseur fournit au client. Ces normes confirment que l'entreprise dispose de certaines solutions de sécurité, d'approches de la division du travail.
Arriéré - une liste de problèmes qui doivent être résolus pour améliorer le système. Habituellement, l'architecte arrière devient l'architecte en chef, qui doit examiner les besoins du système et les besoins du produit et hiérarchiser ces tâches.
Bien entendu, les outils sont également améliorés.
Il y a plus de nouvelles. Vasya a été promu. Il est maintenant vice-président de l'ingénierie.
Vendredi, samedi, dimanche passe - rien ne vient. Tout fonctionne. Tout le monde est sous le choc. Lundi arrive, un avocat vient à Vasya et dit qu'il était à une conférence d'avocats et qu'il a entendu parler de LGPL 2.2 là-bas. Vasya n'a aucune idée s'ils ont LGPL 2.2.
Les gens ont travaillé longtemps, puis ont trouvé LGPL 2.2. Besoin de couper. Mais cela est coupé par un élément sain du système, et personne n'a annulé la sortie demain. Eh bien, rien n'a été réglé.
Le directeur du fonds vient à Vasya:
- De combien d'argent avez-vous besoin pour les serveurs et la production? Faire le budget de l'année prochaine ...
- 42 - dit Vasya.
Nous avons également résolu ce problème.
Ils viennent à Vasya et disent qu'il y a un client potentiel, mais il a peur que nous n'ayons jamais eu un client aussi important et veut être convaincu que ce sera bon. Nous savons par l'histoire qu'à ce stade, tout le monde est mort.
Mais comme nous devons avoir une fin heureuse, nous l'avons attachée à la tragédie grecque.
Épilogue - Amélioration proactive
Parlons maintenant de la dernière étape de la mise à l'échelle de DevOps - Amélioration proactive. Il s'agit de prévention des incendies.
Aucun changement n'arrive aux gens. Mais avec le processus - très bien.
Puisque nous avons un ingénieur de performance, il doit en quelque sorte surveiller le système. La gestion des licences et de la sécurité est apparue. Performance proactive - nous observons maintenant attentivement où les indicateurs clés se déplacent et réparons les choses avant qu'un énorme incendie ne se déclare. Lors de l'extension d'un produit, il est conseillé d'avoir quelque chose qui dit: si vous voulez avoir un microservice, alors au moins il devrait avoir une surveillance standard, des journaux et ainsi de suite.
En conséquence, il existe des outils qui prennent en charge tout cela. Par exemple, un outil de surveillance des licences et de la sécurité est
JFrog Xray .
Blazemeter - puisqu'il existe désormais des performances proactives, vous devez en quelque sorte générer une charge. Des choses apparaissent comme la virtualisation des services, qui vous permet d'utiliser des objets fictifs pour les API distantes, car tous les fournisseurs avec lesquels vous travaillez ne peuvent pas fournir une API de test.
Analyse
Analysons quelques événements d'actes précédents.
Rappelez-vous le cas où Vasily a prévu un budget avec un doigt dans le ciel? En travaillant sur l'un de nos produits, nous avons voulu déterminer les ressources dépensées. Après avoir regroupé tout ce qui était dans l'arriéré, nous avons obtenu ce diagramme:
Nous pensions à tort que nous dépensions 80% pour le Big Feature A - en fait, cela ne prend que 13%. Dans le même temps, jusqu'à 34% vont à Keep the lights on - les choses qui doivent être faites dans les produits: réparer les bugs, mettre à jour les bibliothèques, etc.
En fait, il n'y a qu'une seule métrique objective de la qualité du produit: la satisfaction du client, qui s'exprime dans les appels au support.
Deuxième exemple. Nous avons brisé tous les défauts de criticité:
65% des tickets appartiennent aux premiers niveaux de criticité. Est-ce un cauchemar?
Maintenant, prenez les mêmes données et regardez-les sous un angle différent.
Maintenant, le graphique reflète la situation après le débriefing. Il s'est avéré que 52% des billets ont été fermés par l'ingénieur en utilisant les informations fournies, c'est-à-dire qu'il a écrit au support ce qu'il ne savait pas. Seulement environ 20% des billets ont été fermés avec une sorte de changement de code. Ainsi, il s'avère que la R&D n'est pas en cause. Même le soutien n'est pas à blâmer. En fait, nous manquions de formation - et Vasya, comme vice-président de l'ingénierie, après avoir vu combien de temps il passe sur toutes sortes de bêtises, il a envoyé un tas d'ingénieurs pour former le support.
Les gars ont corrigé la documentation dans des goulots d'étranglement, corrigé les journaux. En conséquence, la pièce, qui a pris beaucoup de temps aux développeurs, a disparu.
Conclusions
À toutes les étapes, de la lutte contre l'incendie à l'installation d'alarmes et à la résolution proactive de problèmes, de nombreux processus, personnes, spécialistes, approches et outils doivent être installés. Tout cela ne peut se faire en une seule journée. De plus, certaines choses ne sont pas nécessaires à certains stades de développement.
Il est important de comprendre que dans les personnes, les processus et les outils, certaines améliorations sont constamment nécessaires.
Ce qui doit être amélioré, nous serons aidés à découvrir les chiffres dont nous avons parlé. Ce n'est que sur la base de ces données que nous pourrons prendre les bonnes décisions quant à savoir où investir du temps et quoi avancer.
Et n'oubliez pas les deux principes fondamentaux de DevOps:
- Vous le construisez - vous le possédez.
- La douleur est pédagogique.
Dimanche prochain, Baruch et Leonid présenteront un rapport «#DataDrivenDevOps» au DevOops 2018 à Saint-Pétersbourg. Venez, il y aura beaucoup de choses intéressantes: voici les reportages , voici John Willis , et voici une soirée avec BoFs et karaoké . Vous attend!