La définition du DevOps est très complexe, nous devons donc à chaque fois recommencer la discussion à ce sujet. Il existe un millier de publications sur ce sujet rien que sur Habré. Mais si vous lisez ceci, vous savez probablement ce qu'est DevOps. Parce que je ne suis pas. Bonjour, je m'appelle Alexandre Titov (@), et nous parlerons juste de DevOps et je partagerai mon expérience.
Je réfléchis depuis longtemps à la manière de rendre mon histoire utile, il y aura donc ici beaucoup de questions - celles que je me pose et celles que je pose aux clients de notre entreprise. En répondant à ces questions, la compréhension devient meilleure. Je vais vous expliquer pourquoi DevOps est nécessaire de mon point de vue, ce que c'est, encore une fois, de mon point de vue, et comment comprendre que vous vous dirigez à nouveau vers DevOps de mon point de vue. Le dernier point passera par des questions. En y répondant par vous-même, vous pouvez comprendre si votre entreprise s'oriente vers DevOps ou s'il y a des problèmes d'une manière ou d'une autre.
À une époque, je surfais sur les vagues de fusions et d’acquisitions. J’ai d’abord travaillé pour une petite startup appelée Qik, puis elle a été rachetée par une société légèrement plus grande appelée Skype, qui a ensuite été rachetée par une société légèrement plus grande appelée Microsoft. À ce moment-là, j’ai commencé à voir comment l’idée du DevOps se transformait dans des entreprises de différentes tailles. Après cela, je me suis intéressé au DevOps d'un point de vue marché, et mes collègues et moi avons fondé la société Express 42. Depuis 6 ans maintenant, nous évoluons au gré des vagues du marché.
Entre autres choses, je suis l'un des organisateurs de la communauté DevOps Moscou et l'organisateur des DevOps-Days 2017, mais je n'ai pas organisé 2018. Express 42 travaille avec de nombreuses entreprises. Nous y développons le DevOps, observons comment cela se produit, tirons des conclusions, analysons, communiquons nos conclusions à tout le monde et formons les gens aux pratiques DevOps. De manière générale, nous faisons de notre mieux pour accroître notre expérience et notre expertise à cet égard.
Pourquoi DevOps
La première question qui hante tout le monde et toujours est : pourquoi ? Beaucoup de gens pensent que DevOps n’est qu’une automatisation ou quelque chose de similaire que toutes les entreprises possédaient déjà.
— Nous avions l'intégration continue – cela signifie que nous avions déjà DevOps, et pourquoi tout cela est-il nécessaire ? Ils s'amusent à l'étranger, mais ils nous empêchent de travailler !
Après 9 ans de développement de la communauté et de la méthodologie, il est déjà devenu clair qu'il ne s'agit toujours pas de paillettes marketing, mais on ne sait toujours pas exactement pourquoi c'est nécessaire. Comme tout outil et processus, DevOps a des objectifs spécifiques qu’il atteint en fin de compte.
Tout cela est dû au fait que le monde change. Il s'éloigne de l'approche d'entreprise, lorsque les entreprises se dirigent directement vers un rêve, comme le chantait notre classique de Saint-Pétersbourg, d'un point A à un point B selon une certaine stratégie, avec une certaine structure construite à cet effet.
En principe, tout en informatique devrait être construit selon cette approche. Ici, l’informatique est utilisée exclusivement pour automatiser les processus.
L’automatisation ne change pas souvent, car lorsqu’une entreprise s’enfonce dans une ornière bien tracée, que peut-on changer ? Cela fonctionne - n'y touchez pas. Aujourd’hui, les approches dans le monde changent, et celle appelée Agile suggère que le point final B n’est pas immédiatement visible.
Lorsqu'une entreprise parcourt le marché, travaille avec un client, elle explore constamment le marché et change le point final B. De plus, plus l'entreprise change de direction, plus elle réussit au final, car elle choisit davantage le marché. niches.
La stratégie est démontrée par une entreprise intéressante dont j'ai récemment entendu parler. One Box Shave est un service de livraison par abonnement de rasoirs et d'accessoires de rasage dans une boîte. Ils savent personnaliser leur « box » pour différents clients. Cela est fait par un certain logiciel, qui envoie ensuite la commande à l'usine coréenne qui produit les marchandises.
Ce produit a été acheté par Unilever pour 1 milliard de dollars. Elle concurrence désormais Gillette et a conquis une part importante des consommateurs sur le marché américain. One Box Shave dit :
— 4 lames ? Êtes-vous sérieux? Pourquoi en avez-vous besoin - cela n'améliore pas la qualité du rasage. Une crème, un parfum spécialement sélectionnés et un rasoir de haute qualité à deux lames résolvent bien plus de problèmes que ces stupides 4 lames Gillette ! Arriverons-nous bientôt à 10 heures ?
C'est ainsi que le monde change. Unilever affirme disposer d'un système informatique performant qui vous permet de le faire. Au final ça ressemble à un concept Délai de mise sur le marché, dont personne n'a encore parlé.
L’importance du délai de mise sur le marché n’est pas la fréquence à laquelle nous déployons. Vous pouvez souvent déployer, mais les cycles de publication seront longs. Si les cycles de sortie de trois mois se superposent, en les décalant d'une semaine, il s'avère que l'entreprise semble déployer une fois par semaine. Et de l’idée à la mise en œuvre finale, cela prend 3 mois.
Le délai de mise sur le marché consiste à minimiser le temps écoulé entre l’idée et la mise en œuvre finale.
Dans ce cas, le logiciel interagit avec le marché. C’est ainsi que le site One Box Shave interagit avec le client. Ils n'ont pas de vendeurs, juste un site Web sur lequel les visiteurs cliquent et laissent leurs souhaits. Ainsi, quelque chose de nouveau doit être constamment publié sur le site et mis à jour conformément aux souhaits. Par exemple, en Corée du Sud, ils se rasent différemment qu'en Russie et ils n'aiment pas l'odeur du pin, mais, par exemple, celle des carottes et de la vanille.
Puisqu’il est nécessaire de modifier rapidement le contenu du site, le développement logiciel évolue grandement. Grâce à un logiciel, nous devons découvrir ce que veut le client. Auparavant, nous l’apprenions par des moyens détournés, par exemple grâce à la gestion d’entreprise. Ensuite, nous l'avons conçu, mis les exigences dans le système informatique, et tout s'est bien passé. Aujourd’hui, c’est différent : les logiciels sont conçus par toutes les personnes impliquées dans le processus, y compris les ingénieurs, car grâce aux spécifications techniques, ils apprennent comment fonctionne le marché et partagent également leurs idées avec l’entreprise.
Par exemple, chez Qik, nous avons soudainement appris que les gens aimaient vraiment télécharger des listes de contacts sur le serveur et ils nous ont fourni une application. Au début, nous n'y avions pas pensé. Dans une entreprise classique, tout le monde aurait décidé qu'il s'agissait d'un bug, puisque la spécification ne disait pas que cela devrait fonctionner très bien et était généralement implémentée sur le genou, ils auraient désactivé la fonctionnalité et auraient déclaré : « Personne n'a besoin de ça, le plus important est que la fonctionnalité principale fonctionne. » . Et l'entreprise technologique voit cela comme une opportunité et commence à modifier le logiciel en conséquence.
En 1968, un visionnaire, Melvin Conway, a formulé l’idée suivante.
L'organisation qui crée le système est contrainte par une conception qui reproduit la structure de communication de cette organisation.
Plus en détail, pour réaliser des systèmes d'un type différent, il faut également disposer d'une structure de communication au sein d'une entreprise d'un type différent. Si votre structure de communication est hiérarchique, cela ne vous permettra pas de créer des systèmes capables de fournir un indicateur de temps de mise sur le marché très élevé.
Lire on peut . C'est important pour comprendre la culture ou la philosophie DevOps car la seule chose qui change fondamentalement dans DevOps est la structure de communication entre les équipes.
D'un point de vue processus, avant DevOps, toutes les étapes : analyse, développement, tests, exploitation, étaient linéaires.
Dans le cas du DevOps, tous ces processus se déroulent simultanément.
Le délai de mise sur le marché est le seul moyen d'y parvenir. Pour les personnes qui travaillaient selon l’ancien processus, cela semble quelque peu cosmique, et généralement médiocre.
Alors pourquoi avez-vous besoin de DevOps ?
Pour le développement de produits numériques. Si votre entreprise ne dispose pas de produit numérique, DevOps n’est pas nécessaire – c’est très important.
DevOps surmonte les limitations de vitesse de la production séquentielle de logiciels. Dans ce document, tous les processus se déroulent simultanément.
La difficulté augmente. Lorsque les évangélistes DevOps vous disent que cela facilitera la publication de logiciels, cela n’a aucun sens.
Avec DevOps, les choses ne feront que devenir plus compliquées.
Lors de la conférence sur le stand Avito, vous avez pu voir à quoi ressemblait le déploiement d'un conteneur Docker - une tâche irréaliste. La complexité devient prohibitive, il faut jongler avec plusieurs balles en même temps.
DevOps change complètement le processus et l'organisation de l'entreprise — plus précisément, ce n'est pas le DevOps qui change, mais le produit numérique. Pour arriver au DevOps, il faut encore changer complètement ce processus.
Questions à un spécialiste
Qu'est-ce que tu as? Des questions que l'on peut se poser en travaillant dans une entreprise et en se développant en tant que spécialiste.
Avez-vous une stratégie pour créer un produit numérique ? Si c’est le cas, c’est déjà bien. Cela signifie que votre entreprise s'oriente vers DevOps.
Votre entreprise crée-t-elle déjà un produit numérique ? Cela signifie que vous pouvez passer à un autre niveau et faire les choses de manière plus intéressante – toujours du point de vue DevOps. Je ne parle que de ce point de vue.
Votre entreprise est-elle l’un des leaders du marché dans le créneau des produits numériques ? Spotify, Yandex, Uber sont des entreprises qui sont actuellement au sommet du progrès technologique.
Posez-vous ces questions, et si toutes les réponses sont non, alors vous ne devriez peut-être pas faire du DevOps dans cette entreprise. Si le sujet du DevOps vous intéresse vraiment, peut-être devriez-vous déménager dans une autre entreprise ? Si votre entreprise souhaite se lancer dans le DevOps, mais que vous avez répondu « Non » à toutes les questions, alors c'est comme ce beau rhinocéros qui ne changera jamais.
organisation
Comme je l'ai dit, selon la loi de Conway, l'organisation d'une entreprise change. Je commencerai par ce qui empêche le DevOps de pénétrer à l’intérieur de l’entreprise du point de vue organisationnel.
Le problème des "puits"
Le mot anglais « Silo » est ici traduit en russe par « puits ». Le point de ce problème est que il n'y a pas d'échange d'informations entre les équipes. Chaque équipe approfondit son expertise, sans construire une carte commune pour naviguer.
D'une certaine manière, cela me rappelle une personne qui vient d'arriver à Moscou et qui ne sait pas encore comment s'orienter sur le plan du métro. Les Moscovites connaissent généralement très bien leur quartier et peuvent s'orienter dans tout Moscou à l'aide du plan du métro. Lorsque vous venez à Moscou pour la première fois, vous n’avez pas cette compétence et vous êtes simplement désorienté.
DevOps suggère de traverser ce moment de désorientation et que tous les départements travaillent ensemble pour construire une carte d'interaction commune.
Deux facteurs y font obstacle.
Conséquence du système de gestion d'entreprise. Il est construit dans des « puits » hiérarchiques séparés. Par exemple, certains KPI dans les entreprises prennent en charge ce système. D'un autre côté, le cerveau d'une personne qui a du mal à dépasser les limites de son expertise et à naviguer dans l'ensemble du système fait obstacle. C'est juste inconfortable. Imaginez que vous êtes à l’aéroport de Bangkok : vous ne vous y retrouverez pas rapidement. DevOps est également difficile à naviguer, et c'est pourquoi les gens disent qu'il faut trouver un guide pour y arriver.
Mais le plus important est que le problème des « puits » pour un ingénieur imprégné de l'esprit DevOps, qui a lu Fowler et bien d'autres livres, s'exprime dans le fait que les "puits" ne permettent pas de faire des choses "évidentes". Nous nous réunissons souvent après DevOps Moscou, nous parlons et les gens se plaignent :
— Nous voulions juste lancer CI, mais il s'est avéré que la direction n'en avait pas besoin.
Cela se produit précisément parce que CI и Processus de livraison continue sont à la frontière de nombreux examens. Sans surmonter le problème des « puits » au niveau organisationnel, vous ne pourrez pas avancer, quoi que vous fassiez et aussi triste que cela soit.
Chaque participant au processus dans l'entreprise : développeurs backend et frontend, tests, DBA, exploitation, réseau, creuse dans sa propre direction, et personne n'a de carte commune sauf le manager, qui les surveille et les gère en quelque sorte à l'aide du « diviser ». et conquérir ».
Les gens se battent pour des étoiles ou des drapeaux, chacun approfondit son expertise.
En conséquence, lorsque se pose la tâche de relier tout cela et de construire un pipeline commun, et qu'il n'est plus nécessaire de se battre pour les étoiles et les drapeaux, la question se pose : que faire de toute façon ? Nous devons parvenir à un accord d’une manière ou d’une autre, mais personne ne nous a appris comment procéder à l’école. On nous l'apprend depuis l'école : huitième année - wow ! - par rapport à la septième année ! C'est la même chose ici.
Est-ce la même chose dans votre entreprise ?
Pour vérifier cela, vous pouvez vous poser les questions suivantes.
Les équipes utilisent-elles des outils communs et contribuent-elles aux modifications de ces outils communs ?
À quelle fréquence les équipes se réorganisent-elles : certains spécialistes d'une équipe passent à une autre équipe ? C'est dans un environnement DevOps que cela devient normal, car parfois une personne ne peut tout simplement pas comprendre ce que fait un autre domaine d'expertise. Il déménage dans un autre service, y travaille pendant deux semaines pour se créer une carte d'orientation et d'interaction avec ce service.
Est-il possible de former un comité de changement et de changer les choses ? Ou cela nécessite-t-il la main ferme de la plus haute direction et de la direction ? J'ai récemment écrit sur Facebook comment une banque peu connue met en œuvre des outils via des commandes : nous rédigeons une commande, nous la mettons en œuvre pendant un an et voyons ce qui se passe. Bien sûr, c’est long et triste.
Dans quelle mesure est-il important pour les managers de recevoir des réalisations personnelles sans tenir compte des réalisations de l'entreprise ?
Si vous répondez vous-même à ces questions, vous comprendrez plus clairement si vous rencontrez un tel problème dans votre entreprise.
Infrastructure en tant que code
Une fois ce problème résolu, la première pratique importante, sans laquelle il est difficile d'avancer davantage dans DevOps, est infrastructure en tant que code.
Le plus souvent, l'infrastructure en tant que code est perçue comme suit :
— Automatisons tout dans bash, couvrons-nous de scripts pour que les administrateurs aient moins de travail manuel !
Mais ce n'est pas vrai.
L'infrastructure en tant que code signifie que vous décrivez le système informatique avec lequel vous travaillez sous forme de code afin de comprendre en permanence son état.
Avec d'autres équipes, vous créez une carte sous forme de code que tout le monde peut comprendre et naviguer et naviguer. Peu importe sur quoi cela est fait – Chef, Ansible, Salt ou utilisation de fichiers YAML dans Kubernetes – il n'y a aucune différence.
Lors de la conférence, un collègue de 2GIS a expliqué comment ils avaient créé leur propre élément interne pour Kubernetes, qui décrit la structure des systèmes individuels. Pour décrire 500 systèmes, ils avaient besoin d'un outil distinct qui génère cette description. Lorsqu'il y a cette description, chacun peut vérifier entre eux, suivre les changements, comment la modifier et l'améliorer, ce qui manque.
D'accord, les scripts bash individuels ne fournissent généralement pas cette compréhension. Dans l'une des entreprises où je travaillais, il y avait même un nom pour un script « en écriture seule » - lorsque le script est écrit, mais qu'il n'est plus possible de le lire. Je pense que cela vous est familier aussi.
L'infrastructure en tant que code est code qui décrit l’état actuel de l’infrastructure. De nombreuses équipes de produits, d'infrastructure et de services travaillent ensemble sur ce code et, plus important encore, elles doivent toutes comprendre comment ce code fonctionne réellement.
Le code est maintenu selon les meilleures pratiques de code: développement conjoint, révision de code, programmation XP, tests, pull request, CI pour les infrastructures de code - tout cela est adapté et peut être utilisé.
Le code devient un langage commun à tous les ingénieurs.
Changer l'infrastructure dans le code ne prend pas beaucoup de temps. Oui, le code des infrastructures peut aussi avoir une dette technique. Habituellement, les équipes le rencontrent un an et demi après avoir commencé à implémenter « l'infrastructure en tant que code » sous la forme d'un tas de scripts ou même d'Ansible, qu'elles écrivent comme du code spaghetti, et elles ajoutent également des scripts bash au mélange !
Il est important: Si vous n'avez pas encore essayé ce genre de choses, rappelez-vous que Ansible n'est pas bash! Lisez attentivement la documentation, étudiez ce qu'ils écrivent à ce sujet.
L'infrastructure en tant que code est la séparation du code d'infrastructure en couches distinctes.
Dans notre entreprise, nous distinguons 3 couches de base, très claires et simples, mais il peut y en avoir davantage. Vous pouvez consulter votre code d'infrastructure et savoir si vous avez cette condition ou non. Si aucun calque n'est mis en surbrillance, vous devez alors prendre un peu de temps et refactoriser un peu.
couche de base - c'est ainsi que le système d'exploitation, les sauvegardes et autres éléments de bas niveau sont configurés, par exemple, comment Kubernetes est déployé au niveau de base.
Niveau de service - ce sont les services que vous fournissez au développeur : journalisation en tant que service, surveillance en tant que service, base de données en tant que service, équilibreur en tant que service, file d'attente en tant que service, livraison continue en tant que service - un ensemble de services que les équipes individuelles peut apporter au développement. Tout cela doit être décrit dans des modules distincts de votre système de gestion de configuration.
La couche où les applications sont faites et décrit comment ils se dérouleront au-dessus des deux couches précédentes.
Questions de contrôle
Votre entreprise dispose-t-elle d’un référentiel d’infrastructure commun ? Gérez-vous la dette technique dans votre infrastructure ? Utilisez-vous des pratiques de développement dans un référentiel d'infrastructure ? Votre infrastructure est-elle découpée en couches ? Vous pouvez consulter le diagramme Base-service-APP. Est-il difficile de faire un changement ?
Si vous avez constaté qu'il fallait un jour et demi pour apporter des modifications, cela signifie que vous avez une dette technique et que vous devez travailler avec. Vous venez de tomber sur une dette technique dans votre code d’infrastructure. Je me souviens de nombreuses histoires de ce type où, pour modifier certains CCTL, il faut réécrire la moitié du code de l'infrastructure, car la créativité et le désir de tout automatiser ont conduit au fait que tout est corrodé partout, toutes les poignées ont été supprimées, et il est nécessaire de refactoriser.
Livraison continue
Comparons le débit avec le crédit. Vient d’abord une description de l’infrastructure, qui peut être assez basique. Vous n'êtes pas obligé de tout décrire en détail, mais une description de base est requise pour que vous puissiez travailler avec. Sinon, on ne sait pas quoi faire ensuite de la livraison continue. Toutes ces pratiques se déroulent simultanément lorsque vous abordez DevOps, mais cela commence par comprendre ce que vous avez et comment le gérer. C’est précisément la pratique de l’infrastructure en tant que code.
Une fois qu'il devient clair que vous l'avez et comment le gérer, vous commencez à comprendre comment envoyer le code du développeur en production le plus rapidement possible. Je veux dire, avec le développeur, nous nous souvenons du problème des "puits", c'est-à-dire que ce ne sont pas des personnes individuelles qui proposent cela, mais une équipe.
Quand nous sommes avec Vania Evtukhovitch j'ai vu le premier livre Jez Humble et groupes d'auteurs "Livraison continue", sorti en 2009, nous avons longuement réfléchi à la manière de traduire son titre en russe. Ils voulaient le traduire par « Livraison constante », mais malheureusement, cela a été traduit par « Livraison continue ». Il me semble qu'il y a quelque chose de russe dans notre nom, avec pression.
Fournir constamment des moyens
Le code présent dans le référentiel du produit peut toujours être téléchargé en production. Il n’est peut-être pas dégonflé, mais il est toujours prêt à le faire. En conséquence, vous écrivez toujours du code avec un sentiment difficile à expliquer d’anxiété sous le coccyx. Cela apparaît souvent lorsque vous déployez du code d’infrastructure. Ce sentiment d'anxiété devrait être présent - il déclenche des processus cérébraux qui vous permettent d'écrire du code un peu différemment. Cela doit être enregistré dans les règles du développement.
Pour garantir une prestation cohérente, vous avez besoin d'un format d'artefact qui s'exécute sur une plate-forme d'infrastructure. Si vous jetez des « déchets de vie » de différents formats sur une plate-forme d'infrastructure, celle-ci devient alors unifiée, elle est difficile à maintenir et le problème de la dette technique se pose. Le format de l'artefact doit être aligné - c'est aussi une tâche collective : nous devons tous nous réunir, nous remuer la cervelle et proposer ce format.
L'artefact est continuellement amélioré et change pour s'adapter à l'environnement de production au fur et à mesure de son évolution dans le pipeline de livraison. Lorsqu'un artefact se déplace le long du pipeline, il rencontre constamment des éléments qui lui sont gênants, qui sont similaires à ceux rencontrés par l'artefact que vous mettez en production. Si dans le développement classique cela est fait par un administrateur système qui effectue le déploiement, alors dans le processus DevOps cela se produit tout le temps : ici ils l'ont testé avec quelques tests, ici ils l'ont jeté dans un cluster Kubernetes, qui est plus ou moins similaire en production, puis tout à coup, ils ont commencé les tests de charge.
Cela rappelle un peu le jeu Pac-Man - l'artefact traverse une sorte d'histoire. Dans le même temps, il est important de contrôler si le code traverse réellement l’histoire et s’il est lié d’une manière ou d’une autre à votre production. Les histoires de production peuvent être glissées dans le processus de livraison continue : c'était comme ça quand quelque chose est tombé, maintenant programmons simplement ce scénario dans le système. À chaque fois, le code passera également par ce scénario et vous ne rencontrerez pas ce problème la prochaine fois. Vous en prendrez connaissance bien avant qu’il n’atteigne votre client.
Différentes stratégies de déploiement. Par exemple, vous utilisez les tests AB ou les déploiements Canary pour tester le code différemment sur différents clients, obtenir des informations sur le fonctionnement du code, et bien plus tôt que lorsqu'il est déployé auprès de 100 millions d'utilisateurs.
« Livrer systématiquement » ressemble à ceci.
Le processus de livraison Dev, CI, Test, PreProd, Prod n'est pas un environnement distinct, ce sont des étapes ou des stations aux sommes ignifuges par lesquelles passe votre artefact.
Si vous disposez d'un code d'infrastructure décrit comme Base Service APP, cela aide n'oublie pas tous les scripts, et écrivez-les comme code pour cet artefact, promouvoir l'artefact et changez-le au fur et à mesure.
Questions d'autotest
Le délai entre la description des fonctionnalités et la mise en production dans 95 % des cas est inférieur à une semaine ? La qualité de l’artefact s’améliore-t-elle à chaque étape du pipeline ? Y a-t-il une histoire qu'il traverse ? Utilisez-vous différentes stratégies de déploiement ?
Si toutes les réponses sont oui, alors vous êtes incroyablement cool ! Écrivez vos réponses dans les commentaires - je serai heureux).
Contactez-nous
C’est la pratique la plus difficile de toutes. Lors de la conférence DevOpsConf, un collègue d'Infobip, en parlant, était un peu confus dans ses propos, car il s'agit vraiment d'une pratique très complexe sur le fait qu'il faut tout surveiller !
Par exemple, il y a longtemps, lorsque je travaillais chez Qik et que nous avons réalisé qu'il fallait tout surveiller. Nous l'avons fait et nous avons désormais 150 000 éléments dans Zabbix, qui sont constamment surveillés. C'était effrayant, le directeur technique s'est tordu le doigt sur la tempe :
- Les gars, pourquoi violez-vous le serveur avec quelque chose de peu clair ?
Mais ensuite, un incident s'est produit qui a montré que c'était vraiment une stratégie très intéressante.
L'un des services a commencé à planter constamment. Au départ, il n'a pas planté, ce qui est intéressant, le code n'y a pas été ajouté, car il s'agissait d'un courtier de base qui n'avait pratiquement aucune fonctionnalité commerciale - il envoyait simplement des messages entre des services individuels. Le service n'a pas changé pendant 4 mois, et tout à coup, il a commencé à planter avec l'erreur « Défaut de segmentation ».
Nous avons été choqués, avons ouvert nos graphiques dans Zabbix, et il s'est avéré qu'il y a une semaine et demie, le comportement des requêtes dans le service API utilisé par ce courtier a considérablement changé. Ensuite, nous avons vu que la fréquence d’envoi d’un certain type de message avait changé. Plus tard, nous avons découvert qu'il s'agissait de clients Android. Nous avons demandé:
— Les gars, que vous est-il arrivé il y a une semaine et demie ?
En réponse, nous avons entendu une histoire intéressante sur la façon dont ils avaient repensé l'interface utilisateur. Il est peu probable que quiconque dise immédiatement qu'il a modifié la bibliothèque HTTP. Pour les clients Android, c'est comme changer de savon dans la salle de bain : ils ne s'en souviennent tout simplement pas. En conséquence, après 40 minutes de conversation, nous avons découvert qu'ils avaient modifié la bibliothèque HTTP et que ses horaires par défaut avaient changé. Cela a entraîné un changement du comportement du trafic sur le serveur API, ce qui a conduit à une situation qui a provoqué une course au sein du courtier, et celui-ci a commencé à planter.
Sans une surveillance approfondie, il est généralement impossible d'ouvrir ce. Si l’organisation est toujours confrontée au problème des « puits », lorsque tout le monde se jette de l’argent, cela peut perdurer pendant des années. Vous redémarrez simplement le serveur car il est impossible de résoudre le problème. Lorsque vous surveillez, suivez, suivez tous les événements dont vous disposez et utilisez la surveillance comme test - écrivez du code et indiquez immédiatement comment le surveiller, également sous forme de code (nous avons déjà l'infrastructure sous forme de code), tout devient clair comment sur la paume. Même des problèmes aussi complexes sont faciles à suivre.
Collectez toutes les informations sur ce qui arrive à l’artefact à chaque étape du processus de livraison – et non en production.
Téléchargez la surveillance sur CI, et certaines choses de base y seront déjà visibles. Plus tard, vous les verrez dans Test, PredProd et les tests de charge. Collectez des informations à toutes les étapes, non seulement des métriques, des statistiques, mais aussi des journaux : comment l'application a été déployée, les anomalies - collectez tout.
Sinon, il sera difficile de s'en rendre compte. J'ai déjà dit que DevOps est plus complexe. Pour faire face à cette complexité, vous devez disposer d'analyses normales.
Questions pour la maîtrise de soi
Votre surveillance et votre journalisation sont-elles l'outil de développement qu'il vous faut ? Lorsqu’ils écrivent du code, vos développeurs, y compris vous, réfléchissent-ils à la manière de le surveiller ?
Avez-vous entendu parler de problèmes de la part des clients ? Comprenez-vous mieux le client grâce à la surveillance et à la journalisation ? Comprenez-vous mieux le système grâce à la surveillance et à la journalisation ? Changez-vous le système simplement parce que vous avez vu que la tendance du système s'accentue et que vous comprenez que dans 3 semaines tout va mourir ?
Une fois que vous disposez de ces trois composants, vous pouvez réfléchir au type de plate-forme d’infrastructure dont vous disposez dans votre entreprise.
Plateforme d'infrastructures
Le fait n’est pas qu’il s’agisse d’un ensemble d’outils disparates dont dispose chaque entreprise.
L’intérêt d’une plateforme d’infrastructure est que toutes les équipes utilisent ces outils et les développent ensemble.
Il est clair qu’il existe des équipes distinctes responsables du développement de différents éléments de la plate-forme d’infrastructure. Mais en même temps, chaque ingénieur assume la responsabilité du développement, des performances et de la promotion de la plateforme d’infrastructure. Au niveau interne, cela devient un outil commun.
Toutes les équipes développent la plateforme d'infrastructure et la traitent avec soin comme leur propre IDE. Dans votre IDE, vous installez différents plugins pour que tout soit agréable et rapide, et configurez les raccourcis clavier. Lorsque vous ouvrez Sublime, Atom ou Visual Studio Code, les erreurs de code affluent et vous réalisez qu'il est impossible de travailler du tout, vous vous sentez immédiatement triste et vous courez réparer votre IDE.
Traitez votre plateforme d'infrastructure de la même manière. Si vous comprenez qu'il y a quelque chose qui ne va pas, laissez une demande si vous ne pouvez pas le réparer vous-même. S'il y a quelque chose de simple, modifiez-le vous-même, envoyez une pull request, les gars l'examineront et l'ajouteront. Il s'agit d'une approche légèrement différente des outils d'ingénierie dans la tête du développeur.
La plateforme d'infrastructure assure le transfert de l'artefact du développement au client avec une amélioration continue de la qualité.. L'IP est programmée avec un ensemble d'histoires qui arrivent au code en production. Au fil des années de développement, de nombreuses histoires de ce type ont été créées, certaines d'entre elles sont uniques et ne concernent que vous - elles ne peuvent pas être recherchées sur Google.
À ce stade, la plateforme d'infrastructure devient votre avantage concurrentiel, car il contient quelque chose qui n’est pas disponible dans l’outil du concurrent. Plus votre propriété intellectuelle est profonde, plus votre avantage concurrentiel est grand en termes de délai de mise sur le marché. Apparaît ici problème de verrouillage du fournisseur: Vous pouvez utiliser la plateforme de quelqu'un d'autre, mais en utilisant l'expérience de quelqu'un d'autre, vous ne comprendrez pas à quel point elle est pertinente pour vous. Oui, toutes les entreprises ne peuvent pas créer une plateforme comme Amazon. Il s’agit d’une ligne difficile dans laquelle l’expérience de l’entreprise est pertinente par rapport à sa position sur le marché, et vous ne pouvez pas y utiliser de verrou de fournisseur. Il est également important d’y réfléchir.
Conduire
Il s'agit d'un schéma de base d'une plateforme d'infrastructure qui vous aidera à mettre en place toutes les pratiques et processus dans une entreprise DevOps.
Voyons en quoi cela consiste.
Système d'orchestration des ressources, qui fournit le processeur, la mémoire, le disque aux applications et à d'autres services. En plus de ça - services de bas niveau: surveillance, journalisation, moteur CI/CD, stockage d'artefacts, infrastructure en tant que code système.
Prestations de niveau supérieur: base de données en tant que service, files d'attente en tant que service, Load Balance en tant que service, redimensionnement d'images en tant que service, Big Data factory en tant que service. En plus de ça - pipeline qui fournit du code constamment modifié à votre client.
Vous recevez des informations sur le fonctionnement de votre logiciel pour le client, vous le modifiez, vous fournissez à nouveau ce code, vous recevez des informations - et vous développez ainsi en permanence à la fois la plate-forme d'infrastructure et votre logiciel.
Dans le diagramme, le pipeline de livraison comprend de nombreuses étapes. Mais il s’agit d’un diagramme schématique donné à titre d’exemple – il n’est pas nécessaire de le répéter un par un. Les étapes interagissent avec les services comme s'il s'agissait de services : chaque brique de la plate-forme porte sa propre histoire : comment les ressources sont allouées, comment l'application est lancée, fonctionne avec les ressources, est surveillée et change.
Il est important de comprendre que chaque partie de la plateforme porte une histoire, et demandez-vous quelle histoire porte cette brique, peut-être devrait-elle être jetée et remplacée par un service tiers. Par exemple, est-il possible d'installer Okmeter à la place d'une brique ? Peut-être que les gars ont déjà développé cette expertise bien plus que nous. Mais peut-être pas - peut-être avons-nous une expertise unique, nous devons installer Prometheus et le développer davantage.
Création de la plateforme
Il s’agit d’un processus de communication complexe. Lorsque vous disposez de pratiques de base, vous démarrez la communication entre différents ingénieurs et spécialistes qui développent des exigences et des normes, et les modifiez constamment vers différents outils et approches. La culture que nous avons dans DevOps est importante ici.
Avec la culture, tout est très simple - c'est une question de collaboration et de communication, c'est-à-dire le désir de travailler ensemble dans un domaine commun, le désir de manier un seul instrument ensemble. Il n'y a pas de sorcier ici - tout est très simple, banal. Par exemple, nous vivons tous dans l'entrée et la gardons propre - un tel niveau de culture.
Qu'est-ce que tu as?
Encore une fois, des questions que vous pouvez vous poser.
La plateforme d'infrastructure est-elle dédiée ? Qui est responsable de son développement ? Comprenez-vous les avantages concurrentiels de votre plateforme d’infrastructure ?
Vous devez constamment vous poser ces questions. Si quelque chose peut être transféré vers des services tiers, il doit être transféré ; si un service tiers commence à bloquer votre mouvement, vous devez alors construire un système en vous.
Alors, DevOps...
... c'est un système complexe, il doit avoir :
- Produit numérique.
- Modules métiers qui développent ce produit numérique.
- Équipes produit qui écrivent du code.
- Pratiques de livraison continue.
- Plateformes en tant que service.
- Infrastructure en tant que Service.
- Infrastructure en tant que code.
- Pratiques distinctes pour maintenir la fiabilité, intégrées à DevOps.
- Une pratique de feedback qui décrit tout.
Vous pouvez utiliser ce diagramme en y mettant en évidence ce que vous avez déjà dans votre entreprise sous une forme ou une autre : a-t-il évolué ou doit-il encore être développé.
Ce sera fini dans quelques semaines . dans le cadre du RIT++. Venez à la conférence, où vous trouverez de nombreux rapports intéressants sur la livraison continue, l'infrastructure as code et la transformation DevOps. , la dernière date limite de prix est le 20 mai
Source: habr.com