Les équipes de développement peuvent être faiblement couplées et travailler dans des directions différentes, sans savoir et sans vouloir utiliser DevOps. Dans l'article d'aujourd'hui, nous parlerons de la manière dont les pratiques DevOps peuvent être déformées et transformées afin qu'elles puissent être mises en œuvre dans des entreprises avec des réglementations, des politiques et des habitudes des gens établies de longue date.



Le matériel est basé sur un rapport de dialogue de Sergey Berdnikov (Golden Crown) et Artem Kalichkin (CFT) de la conférence DevOops d' octobre 2017 . Sous la coupe - transcription vidéo et texte du rapport.




Sergey: Je suis le chef du département opérationnel de notre entreprise. Artem et moi avons commencé une petite révolution-évolution. Tout a commencé avec la révolution, maintenant il est passé au stade de l'évolution.



Artem: L'entreprise opère sur le marché financier depuis 1992. Le travail se compose de deux parties principales. La première partie est le développement de logiciels, le Core Banking, la comptabilité bancaire, etc. Ici, nous agissons en tant que fournisseur: nous avons développé et vendu une boîte, et vous l'avez déployée et exploitée.

La deuxième partie concerne les services de traitement. Ici, nous fournissons des services soit directement aux particuliers, soit par l'intermédiaire de nos partenaires. Il s'agit de grands réseaux commerciaux, de banques et d'autres acteurs du marché des services financiers. Ici, nous élaborons le cycle complet de l'idée au développement, à la mise en œuvre et à l'exploitation ultérieure.

Nous travaillons avec Sergey dans la partie traitement de notre entreprise. Nous allons vous raconter comment nous en sommes arrivés à l'histoire avec DevOps dans ce traitement.

Quel était

Sergey: Notre héritage était complètement bancaire. La société a initialement fabriqué des produits bancaires, respectivement, tout était familier: toute l'infrastructure de SPARC uniquement, ses propres centres de données, le cœur entier a été écrit dans Oracle. Code PL / SQL, beaucoup de choses - ce n'est pas facile à mettre à l'échelle.

Nous avons évolué uniquement verticalement: nous avons acheté un morceau de fer puissant, l'avons utilisé jusqu'à ce qu'il devienne obsolète, l'avons remplacé par un nouveau et l'ancien a été mis en scène.

A également écrit beaucoup de code en Java. Nous avons réservé par le biais d'une réserve chaleureuse: il y a un centre de données et toute la structure copiée - commutateurs, serveurs, tout en un, boulon à boulon.



Ici, vous pouvez voir à quoi ressemblait toute la structure du point de vue des processus. Il y avait des directions techniques distinctes Dev, puis des Firewalls avec feu. Ensuite, il y avait l'informatique centralisée, qui était impliquée dans la suppression, le déploiement, etc. Autrement dit, les développeurs ont écrit une grande instruction, et les opérations informatiques ont été divisées en trois divisions:

• Administrateurs appliqués qui étaient engagés dans un déploiement. Ils n'avaient pas de racine, il y avait des utilisateurs sur les machines, ils pouvaient exécuter des instructions - c'est ce qu'on appelle le code Monkey.
• Administrateurs Unix qui pouvaient et savaient comment configurer, ajouter du matériel, etc.
• Il y avait des spécialistes individuels des bases de données. Et comme les bases de données sont pour nous l'objectif principal, l'essence de notre existence depuis longtemps, de nombreux processus s'y sont déroulés.

Artem: DevOps n'est pas encore là à ce stade, nous avons travaillé selon le règlement, ce dont Sergey n'était pas content.

Sergey: J'ai rejoint l'équipe d'administrateurs appliqués et je me souviens de ce que «les grands moments» ont été. Nous pourrions faire une demande pendant trois semaines. Une application arrive, ils y ont trouvé une sorte d'erreur et l'ont annulée, croyant que les imbéciles eux-mêmes ne pouvaient pas écrire d'applications. Et la connaissance qui était nécessaire pour la rédaction correcte de la demande était avec moi.

Puis les gens sont venus en courant dans une journée: "Et qu'avons-nous écrit de façon incorrecte?" J'ai expliqué que quelque part, ils n'avaient pas mis de plus ou de moins, ils avaient oublié une virgule. Ils écrivent une application, je donne une sorte d'expertise sur la façon de travailler dans Oracle et l'envoient plus loin au DBA, où des personnes spécialement formées qui savent comment remplir ces applications sont assises.

Et ils travaillent aussi avec moi, ils disent: "Pourquoi n'avez-vous pas indiqué l'indicateur principal ici, n'avez-vous pas écrit un point-virgule?" L'application est annulée, le cycle recommence. Maintenant, pour une telle honte, mais que faire, avant de travailler de cette façon.

Artem: Ensuite, nous avons commencé à changer. Il y avait vraiment beaucoup d'applications. Lorsque Sergey a rejoint notre équipe, il était le résultat d'une petite évolution et transformation. J'ai été l'auteur d'un nombre assez important de réglementations pour différents types d'applications, car je devais survivre. En général, toute notre transformation a eu lieu non pas à cause du battage médiatique ou de la mode, mais à cause de la nécessité de résoudre des problèmes spécifiques.

Par exemple, des changements de configuration conduisent au fait que mon combat a éclaté et n'a pas fonctionné correctement. J'ai découvert cela dans la journée ou la nuit: il arrivait qu'à six heures du soir, ils roulaient quelque chose, et jusqu'à trois heures du matin, tout cela fonctionnait mal.

Il y avait des installations de la version avant laquelle personne n'allait et n'a pas discuté de quoi faire en cas de problème. Les fameuses instructions d'installation multi-pages bien connues ont été transmises à tous littéralement une demi-heure avant le début des travaux. Il était nécessaire de résoudre quelque chose, et à ce moment-là, nous avons trouvé une solution - la mise en œuvre adaptative des processus ITIL.

Nous avons commencé à vérifier si tout s'est déroulé correctement après le lancement du combat, si le service et les principaux indicateurs clés fonctionnent normalement. Nous avons commencé à sortir ensemble avant d'installer les versions. Et puis, en fait, c'était le tout début de DevOps, lorsque l'équipe de développement, qui transmet le kit de distribution, a commencé au moins à rencontrer l'équipe d'exploitation, pour discuter de ce qui se passerait dans le travail de nuit.

Sergey: Et il y avait quelque chose à discuter: nous avions quatre pages d'instructions d'installation - exécuter une commande, exécuter un plan. Il était presque impossible d'écrire sans erreurs. Nous avons constamment juré entre le développement que nous avons écrit incorrectement, le lire et des trucs comme ça. Les réunions se transformaient parfois en enfer.

Artem: Nous avons essayé de migrer avec des applications vers Confluence, car il n'est pas pratique de transmettre dans Word - il était possible de former quelque chose de mal. Dans Confluence, ils ont toujours prévu de télécharger la version actuelle avec toutes les modifications.

Nous avons inséré un morceau de code pour rouler au combat. Confluence a mâché le méta-balisage, publié quelque chose d'autre incorrect, l'administrateur a pris le code, qui s'est transformé en nouilles et a commencé à travailler avec - c'était un désastre.

Nous avons réalisé que, quelle que soit la façon dont la page était pervertie, tout cela se transformait en un non-sens complet, quelle que soit la façon dont elle était encadrée.

Il y avait des conditions préalables importantes pour un temps d'arrêt prolongé la nuit, ce qui a conduit à un mauvais décollage après l'installation, aux jambages et à un grand nombre de conflits entre le développement et l'exploitation.

• Beaucoup d'erreurs humaines dans la transmission des changements;
• Recherche constante des coupables;
• Le taux de suppression des nouveaux modules jusqu'à 3 semaines;
• Points de défaillance uniques (uniquement mise à l'échelle verticale), manque d'équilibrage;
• Temps d'arrêt prévu pendant les mises à jour pendant 2 heures.

Contexte de la transformation

Sergey: Il y a eu beaucoup de changements, nous avons constamment foiré. Chaque semaine, nous nous réunissions, maudits, calmés. Ce processus a été répété pour toujours, ils ont cherché le coupable: «Ce sont tous des développeurs qui écrivent du code incurvé, même le module Java ne peut pas être transmis.»

Artem: Mais les développeurs pensaient qu'il s'agissait de choses élémentaires: une erreur dans les journaux est tombée - triez-la, recherchez-la sur Google et comprenez ce qui doit être corrigé dans les configurations.

Sergey: Ils ont également lancé de nouveaux produits pendant très longtemps. Ceci est juste structurellement lié: ils ont créé une demande pour nous, nous avons dû créer une demande pour créer un utilisateur sur le serveur, puis créer un schéma. Ensuite, le football a commencé avec des applications. Les développeurs ont publié des modules, mais nous ne pouvons pas les utiliser, nous avons tout conformément à la réglementation.

De plus, nous nous sommes installés très longtemps. L'instruction est énorme, pendant que vous lisez, pendant que vous le faites, la bobine a pris environ deux heures. Les actions elles-mêmes n'ont pas été achevées en une seconde.

Artem: Il y avait aussi des actions de routine, par exemple, 30 modules Java. En tout, il y a une configuration, dans chaque configuration, vous devez entrer et apporter des modifications. Tout d'abord, vous pouvez devenir fou pour faire le même changement: vous vous détestez et le reste de l'humanité. Deuxièmement, la probabilité de faire une erreur sur la 25e configuration devient extrêmement élevée.

Sergey: Je me souviens comment j'ai obtenu une offre de mise à l'échelle horizontale. Et nous avons 150 modules avec différentes configurations: si l'erreur est dans une version de la configuration, ils m'en mettront une deuxième, et je vais y faire une erreur. Nous ne sommes pas des robots, après tout.

Artem: Un temps d'arrêt planifié de 2 heures de mise à jour est l'un des facteurs critiques pour lesquels nous avons commencé à chercher une solution, comment s'en sortir.

Le fait est que nous fournissons des services financiers, des services de traitement. Nous travaillons à l'étranger. A cette époque, ils travaillaient déjà dans 11 fuseaux horaires, en 2013 nous n'avions qu'une heure de fenêtres, lorsque l'utilisation du service était minime, le nombre d'appels clients était minimisé, le calme est venu et quelque chose pouvait être fait.

Conditionnellement, nous pourrions effectuer des travaux d'une heure à deux heures du soir. Deux heures, c'est bien plus que cette fenêtre. Nous approchions d'un désastre, sinon pour la transformation, car maintenant nous n'avons physiquement pas de fenêtres.

La réponse à tous ces problèmes, j'ai eu une idée, une tentative de découvrir ce qu'est DevOps.

A cette époque, notre collègue est venu avec HighLoad, j'étais occupé à l'implémentation de CMBD, car j'avais besoin pour que les configurations ne cassent pas et que je puisse au moins gérer quelque chose. Il a écouté le rapport de Sasha Titov, qui a parlé d'un chef. Il semble que ce soit aussi la gestion de la configuration

En 2013, j'ai tout lu à ce sujet, j'ai décidé que certains déchets n'étaient pas ce dont j'avais besoin. J'ai besoin de contrôler, et ils forcent le code à y écrire. Cependant, la situation n'a pas changé, les problèmes se sont accumulés et je me suis forcé à m'asseoir à la maison et à commencer à régler les choses. Je pensais qu'il y avait là quelque chose, une sorte de salut.

Et puis j'ai découvert les postulats et les valeurs que nous devrions avoir le même environnement, le même script de déploiement et de mise à jour, que nous devrions vérifier ces scénarios, en commençant par l'environnement de test.

Il était possible de minimiser les instructions et les actions manuelles, et d'automatiser tout autant que possible, pas seulement avec des scripts bash disparates, dans lesquels un autre administrateur se casserait la jambe plus tard.

C'est alors que j'ai eu cette idée, avec la première déclaration de ce que je veux recevoir. Il s'agit du document 2013, le premier créé au sein de l'entreprise sur DevOps.

Sergey: Voici une idée clé: réduire la vitesse de suppression des nouveaux modules, réduire le nombre d'erreurs lors de la suppression au combat. Autrement dit, il y avait des objectifs spécifiques que nous voulions atteindre lors de la première étape de la sortie des nouvelles versions.



Il y avait de nombreux arguments contre. Par exemple, la peur que l'automatisation brise tout: cela fonctionne de manière incompréhensible, il est effrayant d'exécuter le code de quelqu'un d'autre, c'est un excellent service, les gens obtiennent de l'argent grâce à nous. Pas grave.

Le prochain à rejoindre les gardes. Ils nous ont traversés en entier: une sorte de scène identique! Et ils ont une image parfaite du monde: sur le lecteur flash, transférez les versions, nous les signerons avec une clé PGP, et tout ira bien - le service parfait. Nous avons travaillé avec eux pendant si longtemps pour arriver à la fin, mais grâce aux activités du projet, nous avons fait quelque chose.

Artem: Ici nous partons des valeurs: c'est là que l'on perd de l'argent, cette simple est inacceptable.

Les gars et moi avons trouvé un moyen de minimiser ces pertes. Avez-vous une meilleure option? Sinon, gardez le silence; si vous l'êtes, critiquez et offrez. Rien à offrir? Ensuite, nous essayons.

Il y a eu un processus de persuasion et de forçage: nous avons suggéré d'utiliser nos idées sur un nombre limité de systèmes.

Sergey: On nous a demandé d'écrire tous les risques, comment nous les publierons. Il fallait se coordonner avec les gens qui pouvaient perdre de l'argent. En outre, les programmeurs ont déclaré: "Nous avons écrit une sorte de code, nous avions l'habitude de transmettre zip normalement, nous avons écrit des instructions et une autre sorte de code à écrire dans un souci de suppression?!"

Artem: «J'écris du code d'application de logique métier, j'utilise des frameworks pour minimiser toute partie inutile du code. Et vous demandez plus de code à écrire. À emporter et à retirer, à la fin »- de tels dialogues étaient au début. Néanmoins, tout cela a progressivement fonctionné à travers des manifestations et des croyances.



Sergey: Dans les premières itérations, nous avons pris de nombreuses décisions importantes en termes de structure de notre entreprise et en termes de technologie. Tout d'abord, nous avons implémenté la gestion de la configuration. Cela nous a évité de retirer la mauvaise configuration avec une instruction de 10 pages A4.

Ensuite, les opérations ont commencé à couler et les administrateurs d'applications sont passés à la direction technique avec les développeurs. Cela donnait une sensation de commande, une sensation de coude. Nous avons commencé à comprendre que nous fabriquions un produit et ne remplissions pas des applications incompréhensibles avec le désir de les rejeter - il y avait des objectifs spécifiques.

Le travail d'équipe se rapproche lorsque vous vous asseyez à côté des gens, quand vous voyez comment ils fonctionnent, quand ils voient comment nous travaillons. Nous avons même eu un dialogue entre les équipes: c'est la première étincelle de vrais DevOps. Il n'y avait pas de technologie, pas de nouvelle technologie. Du point de vue de la technologie, nous pensions que rien ne prendrait racine, nous travaillions différemment, dans un autre monde.

La première idée est d'écrire nous-mêmes la gestion de la configuration, il y a beaucoup de développeurs. Ensuite, nous nous sommes souvenus de tout ce que nous avions écrit nous-mêmes et avons refusé - nous avons tous fait semblant.

Artem: Je vais corriger mon collègue. Sergey a tort: ​​tout ce que nous écrivons nous-mêmes fonctionnait parfaitement dans notre domaine appliqué, dans lequel nous sommes forts. Et quand ils ont essayé d'écrire certaines de leurs araignées pour construire automatiquement CMDB ou une sorte de système de surveillance auto-écrit pour contrôler la logique métier - oui, voici un système d'une autre classe.

À ce stade, il s'est avéré que les administrateurs d'application sont passés du service informatique à notre service technique. Comme l'a dit Sergey, ils ont commencé à ressentir toute la valeur commerciale, élémentaire à cause des choses mercantiles.

Nous avons eu la possibilité de leur verser des primes de projet pour leurs réalisations, c'était très motivant. Au début du dialogue, la suppression des modules a été réduite de trois semaines à une semaine ou plus, et certains progrès se sont déroulés même sans aucune automatisation profonde.



Sergey: En ce moment, si nous ne comprenions pas quelque chose avec l'application, nous avons demandé au développeur de venir: "Décidons ensemble et écrivons comment l'application devrait sonner".

Artem: Et sur cette structure de commandement conditionnelle, nous avons commencé à passer à la technologie.

Sergey: Maintenant, nous allons vous dire comment nous avons choisi le système. C'était assez intéressant. Tout d'abord, nous avons essayé Chef, pour une raison simple - nous connaissions un gourou qui connaît Chef. Ensuite, nous avons essayé Puppet, car à cette époque, Oracle a annoncé la prise en charge de Puppet.

Ansible a également essayé, mais les deux équipes ne l'ont pas aimé comme système. Il y avait aussi des problèmes de sécurité: Ansible en 2013 était très différent de l'actuel.

Nous avons lancé deux projets différents avec la même fonctionnalité en parallèle. Et tout fonctionnait bien, il y avait le sentiment que quelque chose n'allait pas ici et devait être laissé seul. Comment avons-nous choisi?

Artem: Les programmeurs ont écrit sur Chef, les admins ont écrit sur Puppet. L'idée était ce que nous allons essayer, puis comparer où c'est mieux et choisir. Mais lorsque nous nous sommes réunis, lorsque le temps a finalement passé, la dualité a commencé à créer des problèmes, car le volume de code augmente, il continue de croître et tout le monde aime tout, les développeurs écrivent et automatisent.

J'ai rassemblé tout le monde et demandé sur quoi nous allions écrire. Les programmeurs ont dit: "Nous aimons vraiment le chef." Et les administrateurs: "Et pour nous sur Puppet!". C'était une boîte complète. J'ai comparé et compris que dans l'environnement actuel et les paramètres actuels, il n'y a aucun moyen objectif de choisir tel ou tel produit.

En conséquence, j'ai fait, comme ils aiment à le dire dans notre pays, des élections avec un résultat prévisible. Une sorte de vote "fermé" entre les participants. Mais il n'y a pas eu de falsification, il y a eu un effet conditionnel sur le cerveau, à la suite duquel Puppet a été choisi. J'ai décidé de calmer les développeurs offensés plus rapidement que les administrateurs offensés. Il n'y avait tout simplement aucun autre critère de sélection.

Sergey: A ce moment, nous avons longuement réfléchi à la façon de mettre le binarisme. Sur la diapositive, vous pouvez voir une photo de notre conseil d'administration et de la réunion. Nous avons décidé que vous devez utiliser une sorte de système d'emballage et non votre vélo. Encore gagné l'esprit.

En fait, nous n'avons pas choisi RPM, mais IPS - le gestionnaire de packages Solaris. Nous nous sommes importés de la 11e version dans le top 10, qui se tenait, et avons commencé à l'utiliser. Refuser des béquilles et des fermetures à glissière auto-écrites à ce moment-là était la décision la plus correcte.

Artem: C'est pourquoi il était toujours important: dans la recette, le résultat apparaît sous la forme d'un changement de numéro de version, il s'étire de plus en plus du référentiel et devient nécessaire.

Quand nous sommes venus pour former DevOps, Chef, toutes ces choses, et nous avons pensé: "Maintenant, ils vont nous dire comment transférer les binaires", mais ils ne nous ont rien dit à ce sujet. Les réponses sont généralement: "Chacun décide à sa manière et sort comme il peut". Par conséquent, ils ont réalisé que la réponse de l'industrie à cela est «42», comme dans le «Guide des auto-stoppeurs de la galaxie», la réponse à la question principale de l'univers.

Sergey: Nous avons également eu un long débat sur la façon de construire un CI / CD, ce que c'est. Comme Configuration Management - un utilitaire, ils ont pris et livré. Et voici beaucoup d'options et de choix, ont-ils soutenu pendant longtemps, les développeurs ont créé leur propre système et, en fonctionnement, nous avons fait le nôtre pour la suppression.

À ce moment-là, nous avons réalisé qu'il n'y avait pas de solution parfaite. Prenez tout ce que nous avons gagné et endurez. Les développeurs avaient leur propre système d'assemblage, nous avons fait notre livraison nous-mêmes. Il n'y avait pas de choix parfait, et toujours travailler avec différentes équipes de différentes manières. Il n'y a pas d'idéal.

Nous avons également une grande pile, la plupart de notre code est intégré dans la base de données: tous les traitements financiers, qui, malheureusement, conservent le paradigme du «plus proche des données, plus vite elles fonctionnent». Oracle vend, Fowler est d'accord. Les transactions financières se bloquent dans PS / SQL, nous n'avons trouvé aucun produit open source qui pourrait résoudre notre problème de version et de livraison. Peut-être qu'il l'était, mais nous avons commencé à écrire notre propre instrument.

Artem: En fait, nous avons un gros problème, car, comme mentionné dans la diapositive initiale, la production est un grand serveur vertical. Par conséquent, élever le même grand serveur vertical sur Stage est terriblement cher et très difficile. Ce n'est pas si mal.

Le fait est que nous devons élever un environnement qui est à peu près similaire en termes de performances et le remplir de données qui sont similaires en volume et, non moins important, en cardinalité, afin que nos tests Stage passent correctement.

Il s'agissait de décisions très difficiles. Tout d'abord, ce que nous avons fait en termes de mise à l'échelle - nous avons réalisé que nous ne pouvions pas fournir les mêmes véhicules verticaux sur la scène qu'au combat.Mais nous pouvons, au temps X, fixer les indicateurs de référence des demandes de performances système sur l'environnement Stage et les comparer lors du déploiement de nouveaux packages. S'ils commencent à changer anormalement, cela signifie que quelque chose a flotté en nous et que quelque chose ne fonctionne pas mal. C'est un problème.

Ensuite, nous avons découvert un problème avec le transfert de données de la bataille à la scène afin de les remplir avec la même quantité de données. Il est impossible qu'aucune des personnes qui n'ont pas accès aux données clients selon les documents n'y ait accès.

Nous n'avons pas le droit de divulguer les données personnelles et les secrets bancaires des clients dans Stage. Pour transférer ces données, j'ai écrit des scripts d'obfuscation de données afin qu'ils ne soient pas récupérables et ne soient pas comparables aux vrais. Dans le même temps, il est important qu'il soit impossible de remplacer tous les noms par aaa bbb, car nous perdons la cardinalité des données et tous nos contrôles sur scène affichent des informations incorrectes.

Par conséquent, nous avons également écrit ce script dans le but de générer une cardinalité conditionnellement aléatoire de ces données de texte afin que nos demandes montrent une image adéquate comparable à une bataille, et nous pourrions comprendre les changements.

On s'éloigne d'un état de performance absolu, on regarde les changements. La situation n'a pas empiré par rapport à la version précédente, qui, à notre avis, n'était pas mauvaise en termes de performances.



Ceci est la deuxième itération. La phrase clé ici est probablement que le projet s'est terminé ici. Il n'y avait pas de projet DevOps. C'était à l'origine un client interne - moi. J'ai obtenu mon résultat: l'instruction a été réduite, les erreurs lors de la sortie de la version ont été réduites, la configuration de combat a commencé à changer, gérée via Puppet, elle est devenue maîtrisée, compréhensible. Ce que je voulais, c'était ce que j'avais.

Sergey: Il y a eu des changements mineurs par rapport à votre soumission. Une fois encore, les responsabilités sont passées de l'informatique centralisée à la direction technique.

Il est devenu un OPS à part entière avec une racine. Cela a en fait aidé à remplir les tâches en termes de suppression de nouveaux modules. Nous avons commencé à rendre les modules plus rapides, après trois semaines, l'exécution en seulement trois jours nous a semblé idéale. Le résultat était tangible: il y a eu un élan, l'équipe a commencé à générer des idées sur comment et comment s'améliorer.



Ce que nous avons fait du point de vue des départements concernés: nous avons une équipe de plus de 200 personnes, 150 développeurs, 6 OPS. Il y avait beaucoup d'escortes, d'agents de sécurité. Premièrement - la réalisation est venue que la meilleure application idéale qui n'a pas besoin d'être faite. Ils ont commencé à y aller et à essayer: si une personne a la possibilité de faire quelque chose sans créer d'application - tout le monde va bien. Et cela se fait parfaitement rapidement.

Artyom:Voici un exemple, nous faisons une offre via git. Le manager lui-même entre et fait une offre pour la bataille.

Sergey: Nous avons trouvé des outils comme Gitlab, nous avons aimé qu'une personne puisse travailler avec une interface graphique. Il y a un bouton «télécharger», l'utilisateur peut même ne pas comprendre ce que fait réellement la validation.

Dans le même temps, nous avons écrit des scripts pour vérifier le contenu, par exemple, que pdf est pdf, vérifier la taille du fichier et toute autre logique selon les règles émises par l'équipe de sécurité. Les gens ont eu l'occasion de mettre à jour ces documents sans créer d'applications. La charge sur les opérations a diminué.

Une autre difficulté était de savoir comment calculer ces moments. Dans la routine, il n'est pas clair comment rechercher les zones à problème. Par conséquent, nous avons créé notre propre échelle et l'avons appelé «Jackals».

Nous nous sommes inspirés de la vieille photo. Nous avons considéré que nous attribuions à chaque application exécutée le nombre de chacals, à quel point c'est ennuyeux et ennuyeux et nous ne voulons pas le faire. À la fin du mois, ils ont examiné les applications les plus marquées par les chacals.

Ils se sont assis dans leur ensemble et ont pensé comment se débarrasser de cette honte. Comment faire pour qu'il ne soit pas nécessaire de créer des applications pour cela, c'était cool et a conduit les gens.

L'étape suivante, où nous avons trouvé des méthodes d'automatisation, est celle des bots. Nous maîtrisons l'API Telegram, nous avons commencé à réduire les bots pour tout le monde d'affilée, en particulier pour nous-mêmes. Nous avons conclu les derniers déclencheurs.



Les entreprises ont aimé: il y a des situations où quelque chose ment, tout le monde commence à appeler et à demander ce qui se passe. Et pour qu'une personne puisse prendre le téléphone, sélectionner la commande «incidents» et lire les derniers incidents. Les gens ont commencé à mener des incidents plus en détail afin que personne ne les appelle ou ne les interroge.

Ensuite, nous avons commencé à écrire des fonctionnalités supplémentaires pour obtenir des informations qui étaient auparavant des requêtes dans Jira. L'entreprise veut savoir si le transfert a été effectué: saisit un nombre, obtient le résultat. Cela a également grandement facilité la vie en termes d'applications.

Artyom:Dans le même temps, nous avons fait une autre transformation organisationnelle, mais déjà locale, au sein du département de Sergey. Ensuite, nous avons été très infectés par l'idée d'un ingénieur de garde, et grâce à Sergey, nous avons pu construire ce programme dans le département. Il y a un ingénieur assis sur les incidents, il y a un ingénieur assis sur les applications, tous les autres détruisent les chacals, sont engagés dans leur tir.

Travailler avec DEV

Sergey: Ce que l'unité a commencé à faire: des réarrangements sont apparus, les gens étaient engagés non seulement dans des chacals, mais aussi dans d'autres domaines. Tout d'abord, nous avons eu un dialogue avec le développement. Nous avons expliqué aux nouvelles équipes ce qu'est DevOps, comment le cuisiner correctement, avons appris la CM.

Nous avons fait un long chemin depuis que nous avons nous-mêmes écrit des recettes, puis ils ont appris à les éditer, puis à écrire par eux-mêmes. Nous parlons également de CI, aidons à configurer le pipeline et collectons les packages. Nous aidons à créer un environnement de développement sécurisé.

Artem: Du point de vue de CI, tout cela est très important. En parallèle, j'agis en tant que produit-oouner, dirige des projets et dirige des équipes de développement. Et voici un cas très intéressant.

Sur de petites équipes, nous avons combiné les fonctions d'opération, c'est-à-dire Stage et Prod dans la même unité. Sur ces petits projets, petits produits, équipes et infrastructures, cela s'est avéré très pratique. Vous voyez à travers comment vous allez mener la bataille.

Sergey: Quand un ingénieur de combat met en place un environnement de test, il le fait un à un, sachant qu'elle viendra à lui plus tard, et il en souffrira. C'est un facteur psychologique important qui ne peut pas être gratuit, il vaut mieux tout faire à la fois et normalement.



Qu'est-il arrivé? Ici, beaucoup disent qu'il n'y a pas de département DevOps, nous pensons que nous avons un département DevOps. Quelles sont les principales tâches du département?

Il marche, promeut, parle de DevOps. Tout le monde comprend ce que c'est et comment le cuisiner. Ils racontent et montrent comment un nouveau produit avec une base de données peut être déployé en cinq minutes.

Notre seule limite est la sécurité, la coordination des schémas. Lorsque nous avons une machine virtuelle et que les schémas sont convenus, alors tout prend cinq minutes. Tout roule complètement automatiquement.

Artem: Quand en août j'ai eu un lancement d'un nouveau produit dans la bataille, c'est-à-dire un tout nouveau, nous avons déployé 15 à 20 versions par jour sans conflits ni tensions. Il y a un sens de la valeur ici: c'est cool quand vous vous êtes tranquillement installé et que vous passez au suivant.



Sergey:Je vais parler de douleur. Nous prenons en charge le plan de récupération DRP à partir de zéro. Et quand il n'y avait pas d'automatisation, nous y copions presque des configurations. De nouveaux modules ont été constamment ajoutés et le plan doit être constamment mis à jour. Avec l'avènement de DevOps et de l'automatisation, le plan a rétréci: nous prenons la dernière version actuelle de Git et y ajoutons des plans.

Ce plan de déploiement devient honnête. Ceci est pris en charge, entre autres, par les tests de déploiement. Nous faisons des essais et, lors d'un combat, nous courons avec le passage à la réserve. Toute l'histoire de routine a disparu. Cela nous a d'ailleurs aidé à déplacer un peu la pile.

Nous avions l'habitude d'utiliser SPARC Solaris, maintenant x86 est apparu pour une raison simple: aujourd'hui, personne n'écrit ni ne teste des applications hipster pour Sparc. Et nous utilisons par exemple Haproxy, avec les développeurs, nous avons vu des corrections de bugs pour Solaris. Cela nous dérangeait, je ne voulais plus le supporter. Nous avons choisi une plate-forme sur laquelle tout le monde teste des produits, et maintenant nous y travaillons normalement. Cela nous a également poussés à accélérer l'ensemble du processus.

Artem: Cela a généralement ouvert la porte à un nouveau monde plein de miracles. Parce que l'avènement de x86 nous a permis d'utiliser des utilitaires vraiment pertinents et utiles pour nos tâches. De plus, lorsque nous avons eu cette opportunité, nous avons simultanément évolué vers le clustering.

En fait, maintenant tout, à l'exception du traitement central et nucléaire, est regroupé et fonctionne bien avec nous. Nous ne nous inquiétons pas: soit il n'y a pas de temps d'arrêt ou cela prend au maximum une minute, même en l'absence de cluster.

Le seul endroit où il est resté et qui avait au moins deux heures était la migration des systèmes de traitement centralisés. Maintenant, cela prend huit minutes.



Sergey: Sur la diapositive se trouve un nouveau document, une application sur une ligne: fusionner dans git. Il n'y a plus ces dix feuilles A4.

Le déploiement de nouveaux modules prend jusqu'à trois heures. Ce sont des cas difficiles lorsque vous devez faire quelque chose dans Oracle, par exemple, obtenir une machine virtuelle. Les décalages ont disparu. Je ne me souviens pas que quelqu'un ait passé quelque chose de mal. Bien sûr, il y a des rugosités, mais elles sont toutes petites, frivoles, très rapidement corrigées.



Qu'est-ce qui nous a permis de réussir? Tout d'abord, nous n'avons pas commencé une révolution ici et maintenant. Je n'ai pas dit: "Nous devons implémenter DevOps en trois semaines." Nous avons abordé ce processus de manière méthodique, fait campagne pendant longtemps, avons dit aux gens, nous avons coulé la cervelle, parlé des objectifs que nous atteignons.

Artem: J'ai repoussé les questions des autorités: "Artem, quand est DevOps?" Il a dit qu'il n'y aura pas de date limite, nous essayons dans Prod, ne demandez rien.

Sergey:D'un autre côté, tout est également très cool. Nous n'avons pas imposé à toutes les unités les technologies que nous utilisons. L'entreprise est grande, les voisins regardent, ils disent: "Eh bien, oui, très bien, mais nous déploierons tous les six mois." Ils n'en ont pas besoin. Nous ne marchons pas, ne disons pas, que nous avons la seule bonne décision. Quelque part, nous ne voulons pas utiliser notre pile, pour eux, nous avons assemblé des scripts bash simples qui permettent l'intégration avec d'autres commandes.

Artem: Ici, je suis convaincu que le top ne peut pas être contraint d'implémenter DevOps. Ce n'est pas réaliste pour un tel projet.



Sergey: Nous avons analysé où nous perdons la plupart de notre temps: aujourd'hui, nous perdons la plupart de notre temps sur la sécurité.

Nous savons comment travailler rapidement, déployer rapidement, mais nous sommes d'accord sur un schéma de déploiement - c'est une sorte d'enfer. Maintenant que nous l'avons regardé, cela rappelle la même chose quand il y avait des divisions complètement différentes de Dev et d'Ops. Maintenant que nous n'avons pas de plan, nous réfléchissons à la manière d'inclure la sécurité dans notre processus afin qu'ils puissent analyser les changements.

Artem: Par exemple, vous pouvez utiliser Fusionner pour cela, voir ce qui a changé dans la recette. Le gardien de sécurité est également ingénieur.

Sergey:Souvent, nos processus formels n'offrent pas une réelle sécurité. Lorsque nous procédons à un audit, nous comprenons que toutes les procédures ont réussi, mais nous n'avons pas reçu le niveau de sécurité souhaité, et beaucoup de temps et de ressources ont été dépensés. Nous trouvons constamment des problèmes survenus en raison d'une mauvaise intégration des processus de sécurité et des CI / CD.

Du point de vue de l'OPS, nous avons toujours le problème de perdre du temps sur CI et d'ajuster les recettes. Cette chose commence déjà à gagner des «chacals». Par conséquent, nous examinons les systèmes pour présenter des cadres pour les développeurs, nous regardons vers Docker, Kubernetes, afin que nous puissions écrire: "Les gars, il y a des outils, il n'y a pas de gros documents, vous pouvez unifier le processus de livraison."

Nous voulons faire avancer cette idée, mais la sécurité résiste à nouveau. Ils disent: "Quel type de réseaux virtuels avez-vous, comment ces services vont-ils se passer d'un pare-feu?" Il y a des contradictions, mais je pense que nous gagnerons quand même.

Artem: J'ai ma propre douleur, j'aimerais la finir. Nous avons un très gros problème: nous sommes une entreprise, et nous ne sommes pas la seule entreprise de ce type, il y a des représentants qui sont dans la même situation. Nous sommes sous le contrôle constant du régulateur, la Banque centrale vient constamment avec un audit. Nous procédons à une vérification, à une vérification apparemment indépendante.

Il est difficile de blâmer l'auditeur, il fait le travail sur la base de normes qui stipulent que le matériel physique doit être une machine distincte et non virtuelle. Pas de conteneurs.

À l'heure actuelle, aucune norme internationale n'a fait un pas vers les nouvelles technologies. Il y a un trou noir. Ils ne remarquent pas que c'est un gros problème. Je ne peux pas blâmer les auditeurs, ils effectuent des audits selon les normes. Ils n'ont nulle part où prendre cela, mais aucune norme n'essaie dans ce sens de changer, de se transformer quelque part et de bouger.

J'ai besoin de comprendre comment faire une image de l'entreprise avec ces mots terribles pour que tout soit correct et honnête.

Si vous en avez assez des longues lectures - nous vous recommandons d'écouter la sortie du podcast «Five Minute PHP» avec nos amis Baruch Sadogursky et Vyacheslav Kuznetsov. Tendances DevOps, DecSecOps, victoire de Kubernetes et rapport State of DevOps 2018 de DORA.

Et si vous voulez plus de reportages sympas, venez à la conférence DevOops 2018. Il y aura Baruch, et Glory, et même John Willis ! Tous les intervenants et le programme sont sur le site .

Un bon bonus: jusqu'au 1er octobre, un billet pour DevOops 2018 peut être réservé à prix réduit .