Qu'est-ce que DevOps

La définition de DevOps est très compliquée, vous devez donc relancer la discussion à ce sujet à chaque fois. Uniquement sur Habré mille publications sur ce sujet. Mais si vous lisez ceci, vous savez probablement ce qu'est DevOps. Parce que non. Bonjour, je m'appelle Alexander Titov (@ osminog ) et nous ne parlerons que de DevOps et je partagerai mon expérience.



J'ai longtemps réfléchi à la façon de rendre mon histoire utile, donc il y aura beaucoup de questions ici - celles que je me pose et celles que je pose aux clients de notre entreprise. En répondant à ces questions, la compréhension s'améliore. Je vais vous dire pourquoi DevOps est nécessaire de mon point de vue, ce que c'est, encore une fois, de ma position, et comment comprendre que vous passez de nouveau à DevOps de mon point de vue. Le dernier élément sera à travers des questions. En répondant vous-même, vous pouvez comprendre si votre entreprise évolue vers DevOps ou s'il y a des problèmes dans quelque chose.


À une époque, j'ai marché le long des vagues de fusions et d'acquisitions. Au début, je travaillais dans une petite startup Qik, puis il a été acheté par une société légèrement plus grande Skype, qui a ensuite été achetée par une société légèrement plus grande Microsoft. À ce moment-là, une vision est devenue disponible pour moi comment l'idée de DevOps se transformait dans différentes entreprises. Après cela, il est devenu intéressant pour moi de regarder DevOps du point de vue du marché, et mes collègues et moi avons organisé la société Express 42. Depuis 6 ans, nous évoluons sur les ondes du marché.

Entre autres choses, je suis l'un des organisateurs de la communauté DevOps Moscou et l'organisateur de DevOps -Days 2017, mais je n'ai pas organisé 2018. Express 42 travaille avec de nombreuses entreprises. Nous y faisons germer DevOps, voyons comment cela se produit, tirons des conclusions, analysons, communiquons nos résultats à tout le monde, enseignons aux gens les pratiques DevOps. En général, nous développons de toutes les manières l'expérience et l'expertise.

Pourquoi DevOps

La première question qui hante tout le monde et toujours - pourquoi? Beaucoup de gens pensent que DevOps est juste une automatisation ou une chose similaire que chaque entreprise avait déjà.

- Nous avions une intégration continue - cela signifie qu'il y avait déjà des DevOps, et pourquoi tous ces sommets sont-ils nécessaires? Ils s'amusent à l'étranger, mais ils interfèrent avec notre travail!

Au cours des 9 années de développement de la communauté et de la méthodologie, il est déjà devenu clair que ce ne sont pas des paillettes marketing, mais on ne sait toujours pas pourquoi cela est nécessaire. Comme tout outil et processus, DevOps a des objectifs spécifiques qu'il résout finalement.

Tout cela est dû au fait que le monde change. Il s'éloigne de l'approche d'entreprise, lorsque les entreprises vont directement au rêve, comme le chantait notre classique de Saint-Pétersbourg, du point A au point B selon une certaine stratégie, avec une certaine structure construite pour cela.

En principe, en informatique, tout doit être construit pour cette approche. Ici, l'informatique est utilisée exclusivement pour l'automatisation des processus.

L'automatisation ne change pas souvent, car lorsqu'une entreprise roule sur une piste défoncée - qu'y a-t-il à changer? Cela fonctionne - ne touchez pas. Maintenant dans le monde, les approches changent, et celui appelé le mot Agile dit que le point final B n'est pas immédiatement visible.



Lorsqu'une entreprise se déplace sur le marché, travaille avec un client, elle recherche constamment le marché et modifie son point final B.De plus, plus l'entreprise change de direction, plus elle réussit à la fin, car elle sélectionne plus de niches de marché.

La stratégie est démontrée par une entreprise intéressante, dont j'ai appris récemment. One Box Shave - Un service de livraison pour les rasoirs et rasoirs par boîte. Ils savent personnaliser leur "box" pour différents clients. Cela se fait par certains logiciels, qui envoient ensuite une commande à une usine coréenne qui produit des marchandises.

Ce produit a été acheté par Unilever pour 1 milliard de dollars. Maintenant, il fait concurrence à Gillette et lui a volé une part importante des consommateurs sur le marché américain. One Box Shave dit:

- 4 lames? Êtes-vous sérieux? Pourquoi avez-vous besoin de cela - cela n'améliore pas la qualité du rasage. Une crème spécialement sélectionnée, un parfum et un rasoir de haute qualité à deux lames résolvent bien plus de questions que ces stupides 4 lames de Gillette! Bientôt, nous atteindrons 10?

Le monde change donc. Unilever prétend avoir un système informatique sympa qui le permet. Au final, cela ressemble à un concept de Time-to-market dont personne n'a déjà parlé.



L'intérêt du Time-to-market n'est pas la fréquence de déploiement. Vous pouvez souvent déployer, mais les cycles de publication seront longs. Si les cycles de publication de trois mois se chevauchent, décalant d'une semaine, il s'avère que l'entreprise semble être déployée une fois par semaine. Et de l'idée à la mise en œuvre finale, 3 mois s'écoulent.

Le time-to-market consiste à minimiser le temps entre une idée et la mise en œuvre finale.

Dans ce cas, le logiciel interagit avec le marché. C'est ainsi que One Box Shave interagit avec le site. Ils n'ont pas de vendeurs - juste un site où le visiteur clique et laisse des souhaits. En conséquence, le site doit constamment publier quelque chose de nouveau, le mettre à jour en fonction des souhaits. Par exemple, en Corée du Sud, ils se rasent différemment qu'en Russie, et ils aiment l'odeur du pin, mais, par exemple, les carottes vanillées dans le parfum.

Comme vous devez changer rapidement le contenu du site, le développement logiciel évolue considérablement. Grâce à un logiciel, nous devons savoir ce que veut le client. Auparavant, nous avons appris cela par certaines solutions de contournement, par exemple, grâce à la gestion d'entreprise. Ensuite, ils ont conçu, défini les exigences du système informatique, et tout était cool. Maintenant, c'est différent - le logiciel est conçu par tous ceux qui sont impliqués dans le processus, y compris les ingénieurs, car ils apprennent à travers les spécifications techniques comment fonctionne le marché, et partagent également leurs idées avec l'entreprise.

Par exemple, chez Qik, nous avons soudainement découvert que les gens aiment vraiment télécharger des listes de contacts sur le serveur, et ils nous ont mis l'application. Au départ, nous n'y avons pas pensé. Dans une entreprise classique, tout le monde déciderait qu'il s'agissait d'un bug, car la spécification ne dit pas que cela devrait fonctionner correctement et était généralement implémentée sur le genou, ils désactiveraient la fonctionnalité et diraient: "Cela n'a besoin de personne, la chose la plus importante est que la fonctionnalité principale fonctionne" . Et l'entreprise technologique voit cela comme une opportunité et commence à changer de logiciel en conséquence.



En 1968, le visionnaire Melvin Conway a formulé l'idée suivante.

L'organisation qui crée le système est limitée à une conception qui copie la structure de communication dans cette organisation.

Plus en détail, pour produire des systèmes d'un type différent, il faut également avoir une structure de communication au sein d'une entreprise d'un autre type. Si votre structure de communication est hiérarchique supérieure, cela ne vous permettra pas de créer des systèmes pouvant fournir un indicateur de délai de commercialisation très élevé.

Vous pouvez lire sur la loi de Conway en suivant les liens . Il est important pour comprendre la culture ou la philosophie de DevOps, car la seule chose qui change fondamentalement dans DevOps est la structure de communication entre les équipes .

Du point de vue du processus, avant DevOps, toutes les étapes: analyse, développement, test, fonctionnement, étaient linéaires.
Dans le cas de DevOps, tous ces processus se déroulent simultanément.



Le time-to-market ne peut se faire que de cette façon. Pour les personnes qui ont travaillé dans l'ancien processus, cela semble quelque peu cosmique, et généralement moyen.

Alors pourquoi avez-vous besoin de DevOps?

Pour le développement de produits numériques . Si vous n'avez pas de produit numérique dans votre entreprise, DevOps n'est pas nécessaire - c'est très important.

DevOps dépasse les limites de vitesse d'un schéma de production logicielle cohérent . Dans ce document, tous les processus se produisent simultanément.

Augmente la difficulté. Lorsque les évangélistes DevOps vous disent qu'il sera plus facile pour vous de publier des logiciels avec, cela n'a aucun sens.

Avec DevOps, les choses ne feront que se compliquer.

Lors de la conférence sur le stand d'Avito, on pouvait voir ce que c'était que de déployer un conteneur Docker - une tâche irréaliste. La complexité devient prohibitive, vous devez jongler avec plusieurs balles en même temps.

DevOps change complètement le processus et l'organisation dans l'entreprise - plus précisément, il ne change pas DevOps, mais un produit numérique. Pour venir à DevOps, vous devez encore changer complètement ce processus.

Questions pour un spécialiste

Et vous? Questions que vous pouvez vous poser lorsque vous travaillez dans une entreprise et que vous vous développez en tant que spécialiste.

Avez-vous une stratégie produit numérique? S'il y en a, c'est déjà bien. Cela signifie que votre entreprise évolue vers DevOps.

Votre entreprise crée-t-elle déjà un produit numérique? Cela signifie que vous pouvez monter d'un cran et faire des choses plus intéressantes - encore une fois, du point de vue de DevOps. Je ne parle que de ce point de vue.

Votre entreprise est-elle l'un des leaders du marché dans un créneau avec un produit numérique? Spotify, Yandex, Uber - des entreprises qui sont actuellement au sommet du progrès technologique.

Posez-vous ces questions, et si toutes les réponses sont négatives, alors vous ne devriez peut-être pas traiter avec DevOps dans cette entreprise. Si le thème DevOps vous intéresse vraiment, peut-être ... devriez-vous passer à une autre entreprise? Si votre entreprise veut aller à DevOps, mais que vous avez répondu «Non» à toutes les questions, cela ressemble à ce beau rhinocéros qui ne changera jamais.

Organisation

Comme je l’ai dit, selon la loi de Conway, une organisation change dans une entreprise. Tout d'abord, ce qui empêche DevOps d'entrer dans l'entreprise du point de vue de l'organisation.

Le problème des "puits"

Le mot anglais "Silo" est traduit ici en russe également. Le sens de ce problème est qu'entre les équipes il n'y a pas d'échange d'informations . Chaque équipe approfondit son expertise, sans construire de carte commune dans laquelle vous pouvez naviguer.

À certains égards, cela ressemble à une personne qui vient d'arriver à Moscou et ne sait toujours pas comment naviguer sur la carte du métro. Les Moscovites connaissent généralement très bien leur région et, dans tout Moscou, ils sont guidés par la carte du métro. Lorsque vous venez à Moscou pour la première fois, il n'y a pas cette compétence et vous êtes simplement désorienté.

DevOps propose de passer ce moment de désorientation et à tous les services de construire ensemble une carte d'interaction commune.

Deux facteurs interfèrent avec cela.

Une conséquence du système de gestion d'entreprise. Il est construit par des "puits" hiérarchiques séparés. Par exemple, certains indicateurs de performance clés dans les entreprises prennent en charge ce système. En revanche, le cerveau d'une personne difficile à dépasser les limites de son expertise et à naviguer dans le système interfère. C'est tout simplement inconfortable. Imaginez que vous êtes arrivé à l'aéroport de Bangkok - là, vous ne trouverez pas rapidement vos repères. DevOps est également difficile à naviguer, et les gens disent donc que vous devez trouver un guide pour le trouver pour y arriver.

Mais le plus important, le problème des «puits» pour un ingénieur qui a été inspiré par l'esprit de DevOps, a été lu par Fowler et un tas d'autres livres, s'exprime dans le fait que les «puits» ne vous permettent pas de faire des choses «évidentes» . Nous nous réunissons souvent après DevOps Moscou, nous 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 est précisément dû au fait que CI et le processus de livraison continue sont à la frontière de nombreux examens. Si vous ne surmontez pas le problème des «puits» au niveau organisationnel, vous ne pourrez pas avancer davantage, quoi que vous fassiez et à quel point cela peut être triste.



Chaque participant au processus dans l'entreprise: développeurs backend et frontend, tests, DBA, opération, réseau, creuse dans sa propre direction, et personne n'a une carte commune à l'exception d'un gestionnaire qui observe et contrôle d'une manière ou d'une autre la méthode diviser pour mieux régner.

Les gens se battent pour quelques petites étoiles ou drapeaux, chacun creuse sa propre expertise.

En conséquence, lorsque la tâche semble relier tout cela ensemble et construire un pipeline commun, et qu'il n'est pas nécessaire de se battre pour les étoiles et les drapeaux, la question se pose - que dois-je faire? Nous devons en quelque sorte être d'accord, mais personne ne nous a appris comment faire cela. Nous avons appris de l'école: la 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, contribuent-elles à modifier ces outils communs?

À quelle fréquence les équipes se réforment-elles? Certains spécialistes d'une équipe passent-ils à une autre? C'est dans l'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 département, y travaille pendant deux semaines pour se créer une carte d'orientation et d'interaction avec ce département.

Est-il possible de créer un comité du changement et de changer quelque chose? Ou cela nécessite-t-il une main forte de la plus haute direction et direction? J'ai récemment écrit sur Facebook comment une banque peu connue implémente des outils via des commandes: nous avons écrit une commande, nous l'avons mise en œuvre depuis un an et nous verrons ce qui se passera. Bien sûr, cela 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 à ces questions par vous-même, cela deviendra plus clair si vous rencontrez un tel problème dans l'entreprise.

L'infrastructure comme code

Une fois ce problème résolu, la première pratique importante, sans laquelle il est difficile d'aller plus loin dans DevOps, est l' infrastructure en tant que code .

Le plus souvent, l'infrastructure en tant que code est perçue comme suit:

- Automatisons tout sur bash, couvrons-nous de scripts pour que la zone d'administration ait moins de travail manuel!

Mais ce n'est pas le cas.

L'infrastructure en tant que code implique que vous décriviez le système informatique avec lequel vous travaillez afin de comprendre constamment son statut.

Avec d'autres équipes, vous créez une carte sous la forme d'un code que tout le monde comprend, dans lequel vous pouvez naviguer et naviguer. Peu importe ce qui est fait - les fichiers Chef, Ansible, Salt ou YAML sont utilisés dans Kubernetes - il n'y a pas de différence.

Lors de la conférence, un collègue de 2GIS a expliqué comment ils avaient créé leur propre truc 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. Quand il y a cette description, tout le monde peut vérifier les uns avec les autres, suivre les changements, comment les changer et les améliorer, ce qui manque.

D'accord, les scripts bash séparés ne donnent généralement pas cette compréhension. Dans l'une des entreprises où je travaillais, il y avait même un nom «écriture seule» - un script - lorsque le script est écrit, et il est déjà impossible de le lire. Je pense que cela vous est également familier.

Infrastructure en tant que code est un code qui décrit l'état actuel de l'infrastructure . De nombreuses équipes de produits, d'infrastructures et de services travaillent ensemble sur ce code et, surtout, elles doivent toutes comprendre comment ce code fonctionne généralement.

Le code est accompagné selon les meilleures pratiques de travail avec le code : développement conjoint, révision de code, programmation XP, tests, pull-quests, CI pour les infrastructures de code - tout cela est approprié et peut être utilisé.

Le code devient un langage commun à tous les ingénieurs.

Changer l'infrastructure du code ne prend pas beaucoup de temps . Oui, il peut également y avoir une dette technique dans le code des infrastructures. 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 Ansible, qu'ils écrivent sous forme de code spaghetti, et même des scripts bash le mettent dans la chambre de combustion!

Important : si vous n'avez pas encore essayé ce truc, n'oubliez pas qu'Ansible n'est pas bash ! Lisez attentivement la documentation, étudiez ce qu'ils écrivent généralement à ce sujet.

L'infrastructure en tant que code est la division du code d'infrastructure en couches distinctes.

Dans notre entreprise, nous distinguons 3 couches de base, qui sont très claires et simples, mais il peut y en avoir plus. Vous pouvez consulter votre code d'infrastructure et dire si vous avez cette condition ou non. Si aucun calque n'est mis en surbrillance, vous devez allouer du temps et remanier un peu.


La couche de base est la façon dont le système d'exploitation, les sauvegardes et d'autres éléments de bas niveau sont configurés, par exemple, comment Kubernetes est déployé à un niveau de base.

Le niveau de services correspond aux services que vous offrez 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 des équipes individuelles peuvent fournir pour le développement. Tout cela doit être décrit comme des modules distincts dans votre système de gestion de configuration.

Couche où les applications sont créées et comment elles seront déployées par-dessus les deux couches précédentes.

Questions de sécurité

Avez-vous un référentiel d'infrastructure commun dans votre entreprise? Contrôlez-vous la dette technique dans les infrastructures? Utilisez-vous des pratiques de développement dans le référentiel d'infrastructure? Votre infrastructure est-elle découpée? Vous pouvez vérifier le schéma Base-service-APP. Est-il difficile de faire un changement?

Si vous êtes confronté au fait que l'introduction des changements a pris un jour et demi, cela signifie que vous avez une dette technique et que vous devez travailler avec elle. Vous venez de tomber sur un rake de dette technique dans le code des infrastructures. Je me souviens de beaucoup de ces histoires quand, pour changer un CCTL, il est nécessaire de réécrire la moitié du code d'infrastructure, car la créativité et le désir d'automatiser tout ont conduit au fait que partout où tout est court-circuité, tous les stylos sont supprimés et vous devez refactoriser.

Livraison continue

Débit similaire avec un prêt. Tout d'abord, une description de l'infrastructure apparaît, qui peut être assez basique. Il n'est pas nécessaire de tout décrire en détail, mais une description de base est requise pour que vous puissiez travailler avec. Sinon, il n'est pas clair de savoir quoi faire de plus pour une livraison continue. Toutes ces pratiques se déroulent en même temps lorsque vous arrivez à DevOps, mais vous devez commencer par comprendre ce que vous avez et comment le gérer. C'est juste la pratique de l'infrastructure comme code.

Une fois qu'il est devenu clair que vous savez comment gérer cela, vous commencez à réfléchir à la façon d'envoyer le code 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 n'est pas des personnes individuelles qui le proposent, mais de l'équipe.

Lorsque Vanya Yevtukhovich et moi avons vu le premier livre de Jes Hamble et le groupe d'auteurs «Continuous Delivery» , sorti en 2009, nous avons longtemps réfléchi à la façon de traduire son nom en russe. Ils voulaient le traduire par «livrer constamment», mais malheureusement traduit par «livraison continue». Il me semble qu'il y a quelque chose de russe dans notre titre sous pression.

Livrer constamment - cela signifie

Le code qui se trouve dans le référentiel d'épicerie peut toujours être téléchargé en production . Il ne peut pas être dégonflé, mais il est toujours prêt pour cela. En conséquence, vous écrivez toujours du code avec un sentiment de préoccupation difficile à expliquer sous le coccyx. Il apparaît souvent lorsque vous déployez le code d'infrastructure. — , -. .

, , . « », , , . — : , .

- . , - , , , . , , DevOps- : - , — Kubernetes- , - , .

- — - . , - . Continuous Delivery : , - , . , . , .

. , AB- , - «» , , , , 100 .

« » .

Dev, CI, Test, PreProd, Prod — , , .

, Base Service APP, , , .

95 % ? ? , ? ?

, ! — ).

Rétroaction

. DevOpsConf Infobip, , , , !



, -, Qik , . , Zabbix 150 000 items, . , :

— , ?

, , .

. , , , , - — . 4 , «Segmentation fault».

, Zabbix, , , , API-, . , . , android-. :

— , ?

, UI. , HTTP-. android- — . , 40 , , - HTTP-, . , API , , , .

. «», , . , . , , , , — , , ( ), . .

, — .

CI, - . Test, PredProd, . , , , : , — .

. , DevOps — . , .

— ? , , , , ?

? ? ? , , , 3 ?

, , .

, , .

, .

, , . , , . .

, IDE . IDE , , . Sublime, Atom Visual Studio Code, , , IDE.

. , - , , . - — , pull request — , . .

. , . , — .

, , . , Time-to-market. vendor lock : , , , . , . , , vendor lock . .

, DevOps-.



, .

, CPU, , . — : , , CI/CD Engine, , .

: , , , Load Balance , resizing , Big Data . — , .

, , , , — , .

delivery pipeline . , — . , — : , , , , .

, , — , , . , Okmeter? , , . — , , Prometheus .

. , , , . , DevOps.


— , , . rocket science — , . , — .

?

, .

? ? ?

. - — , , .

, DevOps...

… , :

• .
  
• , .
  
• , .
  
• Continuous Delivery.
  
• .
  
• .
  
• .
  
• , DevOps.
  
• , .
  

, , - : .

DevOpsConf 2019 . ++. , , DevOps-. , 20