{"id":33725,"date":"2019-10-31T21:54:21","date_gmt":"2019-10-31T18:54:21","guid":{"rendered":"https:\/\/prohoster.info\/blog\/chto-takoe-devops\/"},"modified":"2019-10-31T21:54:21","modified_gmt":"2019-10-31T18:54:21","slug":"chto-takoe-devops","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/chto-takoe-devops","title":{"rendered":"Qu'est-ce que DevOps","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

La d\u00e9finition de DevOps est tr\u00e8s complexe, c'est pourquoi il faut chaque fois relancer la discussion \u00e0 ce sujet. Rien que sur Habr, il y a des milliers de publications \u00e0 ce propos. Mais si vous lisez ceci, vous savez probablement ce qu'est DevOps. Parce que moi, je ne le sais pas. Bonjour, je m'appelle Alexandre Titov (@osminog<\/a><\/noindex><\/b>), et nous allons simplement parler de DevOps et je vais partager mon exp\u00e9rience.<\/p>\n

\"Qu'est-ce
\n
\nJ'ai longuement r\u00e9fl\u00e9chi \u00e0 la mani\u00e8re de rendre mon r\u00e9cit utile, c'est pourquoi il y aura beaucoup de questions ici - celles que je me pose et celles que je pose aux clients de notre entreprise. En r\u00e9pondant \u00e0 ces questions, la compr\u00e9hension s'am\u00e9liore. Je vais vous expliquer pourquoi DevOps est n\u00e9cessaire selon mon point de vue, ce que c'est, encore une fois, de ma position, et comment comprendre si vous vous dirigez vers DevOps, encore une fois de ma perspective. Le dernier point viendra \u00e0 travers des questions. En r\u00e9pondant \u00e0 celles-ci, vous pourrez comprendre si votre entreprise \u00e9volue vers DevOps ou si elle rencontre des probl\u00e8mes.
\n<\/a><\/noindex>
\n

\r\n \"Lire\r\n
<\/div>\r\n <\/div><\/center>
\nUn temps, j'ai navigu\u00e9 dans les eaux des fusions et acquisitions. D'abord, j'ai travaill\u00e9 dans une petite startup llamada Qik, puis elle a \u00e9t\u00e9 achet\u00e9e par une entreprise un peu plus grosse, Skype, qui a ensuite \u00e9t\u00e9 acquise par une entreprise encore plus grande, Microsoft. \u00c0 ce moment-l\u00e0, j'ai eu acc\u00e8s \u00e0 une vision sur la fa\u00e7on dont la perception de DevOps se transforme dans des entreprises de diff\u00e9rentes tailles. Par la suite, j'ai commenc\u00e9 \u00e0 m'int\u00e9resser \u00e0 DevOps du point de vue du march\u00e9 et, avec mes coll\u00e8gues, nous avons cr\u00e9\u00e9 l'entreprise Express 42. Cela fait d\u00e9j\u00e0 6 ans que nous naviguons sur les vagues du march\u00e9.<\/p>\n

En plus de cela, je suis l'un des organisateurs de la communaut\u00e9 DevOps Moscow et l'organisateur de DevOps Days 2017, mais je n'ai pas organis\u00e9 l'\u00e9dition de 2018. Express 42 travaille avec de nombreuses entreprises. Nous y d\u00e9veloppons DevOps, observons comment cela se passe, tirons des conclusions, analysons, partageons nos r\u00e9flexions avec tout le monde, et formons les gens aux pratiques DevOps. En gros, nous cultivons toutes sortes d'exp\u00e9riences et d'expertises dans ce domaine.<\/p>\n

Pourquoi DevOps<\/h2>\n

\nLa premi\u00e8re question qui taraude tout le monde tout le temps - pourquoi ? Beaucoup pensent que DevOps n'est qu'une simple automatisation ou quelque chose de semblable, qui a d\u00e9j\u00e0 \u00e9t\u00e9 mis en place dans chaque entreprise.<\/p>\n

\u2014 Nous avions d\u00e9j\u00e0 une int\u00e9gration continue - cela signifie qu'il y avait d\u00e9j\u00e0 du DevOps, alors \u00e0 quoi bon tout \u00e7a ? L\u00e0-bas, ils s'amusent, tandis que nous, on nous emp\u00eache de travailler !<\/i><\/p>\n

Apr\u00e8s 9 ans d'\u00e9volution de la communaut\u00e9 et de la m\u00e9thodologie, il est d\u00e9j\u00e0 clair que ce ne sont pas des paillettes marketing, mais on ne sait toujours pas vraiment \u00e0 quoi \u00e7a sert. Comme pour tout outil et processus, DevOps a des objectifs concrets qu'il r\u00e9sout finalement.<\/p>\n

Tout cela est li\u00e9 au fait que le monde change. Il s'\u00e9loigne de l'approche entreprise, o\u00f9 les soci\u00e9t\u00e9s avancent tout de suite vers leur r\u00eave, comme le chantait notre classique de Saint-P\u00e9tersbourg, du point A au point B selon une strat\u00e9gie d\u00e9finie, avec une structure sp\u00e9cifique construite pour cela. <\/p>\n

\"Qu'est-ce
\n<\/p>\n

En principe, tout dans l'IT devrait \u00eatre construit selon cette approche. Ici, l'IT est utilis\u00e9e exclusivement pour l'automatisation des processus.<\/p><\/blockquote>\n

\nL'automatisation ne change pas souvent, car quand une entreprise suit une voie tr\u00e9buchante - que changer ? Si \u00e7a fonctionne, ne touche pas. Actuellement, le monde \u00e9volue, et celui qui s'appelle Agile parle du fait que la destination finale B n'est pas imm\u00e9diatement visible.<\/p>\n

\"Qu'est-ce
\n
\nLorsque l'entreprise op\u00e8re sur le march\u00e9, travaille avec le client - elle explore constamment le march\u00e9 et modifie le point final B. De plus, plus une entreprise change souvent sa direction, plus elle est finalement r\u00e9ussie, car elle choisit davantage de niches de march\u00e9.<\/p>\n

Une strat\u00e9gie est d\u00e9montr\u00e9e par une entreprise int\u00e9ressante dont j'ai r\u00e9cemment entendu parler. One Box Shave - un service de livraison de rasoirs et d'articles de rasage par abonnement dans une bo\u00eete. Ils savent personnaliser leur \u00ab bo\u00eete \u00bb pour diff\u00e9rents clients. Cela est g\u00e9r\u00e9 par un logiciel sp\u00e9cifique qui envoie ensuite la commande \u00e0 une usine cor\u00e9enne produisant le produit.<\/p>\n

Ce produit a \u00e9t\u00e9 achet\u00e9 par la soci\u00e9t\u00e9 Unilever pour 1 milliard de dollars. Il est maintenant en concurrence avec Gillette et a pris une part significative des consommateurs sur le march\u00e9 am\u00e9ricain. One Box Shave d\u00e9clare :<\/p>\n

\u2014 4 lames ? Vous \u00eates s\u00e9rieux ? Pourquoi avez-vous besoin de cela - cela n'am\u00e9liore en rien la qualit\u00e9 du rasage. Une cr\u00e8me sp\u00e9cialement s\u00e9lectionn\u00e9e, un parfum et un rasoir de qualit\u00e9 avec deux lames r\u00e9solvent bien plus de probl\u00e8mes que ces stupides 4 lames Gillette ! Bient\u00f4t, nous atteindrons 10 ?<\/i><\/p>\n

Ainsi, le monde change. Unilever d\u00e9clare disposer d'un super syst\u00e8me IT qui permet cela. Au final, cela ressemble \u00e0 un concept Time-to-market<\/b>, dont beaucoup ont d\u00e9j\u00e0 parl\u00e9.<\/p>\n

\"Qu'est-ce
\n
\nLe sens du Time-to-market ne r\u00e9side pas dans la fr\u00e9quence de nos d\u00e9ploiements. On peut d\u00e9ployer souvent, mais les cycles de release peuvent \u00eatre longs. Si l'on superpose des cycles de release de trois mois en les d\u00e9calant d'une semaine, on a l'impression que l'entreprise d\u00e9ploie une fois par semaine. Pourtant, il faut trois mois entre l'id\u00e9e et la r\u00e9alisation finale.<\/p>\n

Le Time-to-market concerne la minimisation du temps entre l'id\u00e9e et la r\u00e9alisation finale.<\/p><\/blockquote>\n

\nDans ce cas, le logiciel interagit avec le march\u00e9. Ainsi, le site de One Box Shave interagit avec le client. Ils n'ont pas de vendeurs - juste un site o\u00f9 les visiteurs cliquent et laissent leurs souhaits. Par cons\u00e9quent, le site doit constamment proposer quelque chose de nouveau, l'actualiser en fonction des souhaits. Par exemple, en Cor\u00e9e du Sud, on se rase diff\u00e9remment qu'en Russie, et ils pr\u00e9f\u00e8rent des senteurs telles que la vanille plut\u00f4t que l'odeur du pin.<\/p>\n

\u00c9tant donn\u00e9 qu'il faut changer rapidement le contenu du site, le d\u00e9veloppement logiciel \u00e9volue consid\u00e9rablement. \u00c0 travers le logiciel, nous devons comprendre ce que veut le client. Autrefois, nous le d\u00e9couvrions par des moyens d\u00e9tourn\u00e9s, par exemple, via la gestion des affaires. Ensuite, nous concevions le projet en int\u00e9grant les exigences dans le syst\u00e8me informatique, et tout \u00e9tait parfait. Maintenant, c'est diff\u00e9rent - le logiciel est con\u00e7u par tous ceux qui sont impliqu\u00e9s dans le processus, y compris les ing\u00e9nieurs, car ils apprennent \u00e0 travers les caract\u00e9ristiques techniques comment fonctionne le march\u00e9 et partagent \u00e9galement leurs insights avec le business.<\/p>\n

Par exemple, dans l'entreprise Qik, nous avons soudainement d\u00e9couvert que les gens adoraient t\u00e9l\u00e9charger des listes de contacts sur le serveur, et ils ont d\u00e9velopp\u00e9 une application pour cela. \u00c0 l'origine, nous n'y avions pas pens\u00e9. Dans une entreprise classique, tout le monde aurait consid\u00e9r\u00e9 cela comme un bug, car ce n\u2019\u00e9tait pas sp\u00e9cifi\u00e9 que cela devait fonctionner correctement et c'\u00e9tait en fait d\u00e9velopp\u00e9 \u00e0 la va vite, on aurait d\u00e9sactiv\u00e9 cette fonction en disant : \u00ab Ce n\u2019est pas n\u00e9cessaire, l\u2019essentiel est que la fonctionnalit\u00e9 de base fonctionne. \u00bb Alors qu'une entreprise technologique voit une opportunit\u00e9 et commence \u00e0 modifier le logiciel en cons\u00e9quence.<\/p>\n

\"Qu'est-ce
\n
\nEn 1968, le visionnaire Melvin Conway a formul\u00e9 l'id\u00e9e suivante.<\/p>\n

Une organisation qui cr\u00e9e un syst\u00e8me est limit\u00e9e par le design qui reproduit la structure de communication au sein de cette organisation.<\/p><\/blockquote>\n

\nPour en savoir plus, pour cr\u00e9er des syst\u00e8mes d'un autre type, il est en plus n\u00e9cessaire d'avoir une structure de communication au sein de l'entreprise d'un autre type. Si vous avez une structure de communication hi\u00e9rarchique, cela ne vous permettra pas de cr\u00e9er des syst\u00e8mes qui peuvent garantir un tr\u00e8s bon d\u00e9lai de mise sur le march\u00e9.<\/p>\n

Lire sur la loi de Conway<\/a><\/noindex> est possible via les liens<\/a><\/noindex>. Elle est importante pour comprendre la culture ou la philosophie DevOps, car la seule chose qui change fondamentalement dans DevOps, c'est pr\u00e9cis\u00e9ment la structure de communication entre les \u00e9quipes.<\/b>.<\/p>\n

D'un point de vue processuel, avant DevOps, toutes les \u00e9tapes : analyse, d\u00e9veloppement, tests, exploitation, se d\u00e9roulaient de mani\u00e8re lin\u00e9aire.\"Qu'est-ce
\nAvec DevOps, tous ces processus se d\u00e9roulent simultan\u00e9ment.<\/p>\n

\"Qu'est-ce
\n
\nLe d\u00e9lai de mise sur le march\u00e9 ne peut \u00eatre respect\u00e9 que de cette mani\u00e8re. Pour les personnes qui ont travaill\u00e9 dans l'ancien process, cela semble quelque peu futuriste, et m\u00eame pas terrible.<\/p>\n

Alors, pourquoi DevOps est-il n\u00e9cessaire?<\/h3>\n

\nPour le d\u00e9veloppement de produits num\u00e9riques<\/b>. Si vous n'avez pas de produit num\u00e9rique dans votre entreprise, DevOps n'est pas n\u00e9cessaire \u2014 c'est tr\u00e8s important.<\/p>\n

DevOps surmonte les limitations de vitesse du sch\u00e9ma de production s\u00e9quentiel du logiciel<\/b>. Dans celui-ci, tous les processus se d\u00e9roulent simultan\u00e9ment.<\/p>\n

La complexit\u00e9 augmente.<\/b> Lorsque les \u00e9vang\u00e9listes DevOps affirment qu'avec lui vous trouverez plus facile de publier du logiciel, c'est des absurdit\u00e9s.<\/p>\n

Avec DevOps, ce sera juste plus complexe.<\/p><\/blockquote>\n

\nLors de la conf\u00e9rence, sur le stand d'Avito, il \u00e9tait possible de voir ce que signifie d\u00e9ployer un conteneur Docker \u2014 une t\u00e2che irr\u00e9elle. La complexit\u00e9 devient abyssale, il faut jongler avec plusieurs \u00e9l\u00e9ments en m\u00eame temps.<\/p>\n

DevOps change compl\u00e8tement le processus et l'organisation dans l'entreprise<\/b>\u00a0\u2014 en fait, ce n'est pas DevOps qui change, mais le produit num\u00e9rique. Pour arriver \u00e0 DevOps, il faut n\u00e9anmoins changer compl\u00e8tement ce processus.<\/p>\n

Questions pour le sp\u00e9cialiste<\/h3>\n

\nEt chez vous ? Questions que vous pouvez vous poser en travaillant dans l'entreprise et en vous d\u00e9veloppant en tant que sp\u00e9cialiste.<\/p>\n

Avez-vous une strat\u00e9gie pour cr\u00e9er un produit num\u00e9rique ?<\/b> S'il y en a une, c'est d\u00e9j\u00e0 bien. Cela signifie que votre entreprise progresse vers DevOps.<\/p>\n

Votre entreprise cr\u00e9e-t-elle d\u00e9j\u00e0 un produit num\u00e9rique ?<\/b> Cela signifie que vous pouvez monter d'un cran, vous occuper de choses plus int\u00e9ressantes \u2014 du point de vue de DevOps, encore une fois. C'est uniquement sous cet angle que je parle.<\/p>\n

Votre entreprise est-elle l'un des leaders du march\u00e9 dans le secteur des produits num\u00e9riques ?<\/b> Spotify, Yandex, Uber - des entreprises qui sont \u00e0 la pointe du progr\u00e8s technologique aujourd'hui.<\/p>\n

Posez-vous ces questions, et si toutes les r\u00e9ponses sont n\u00e9gatives, peut-\u00eatre qu'il ne vaut mieux pas s'engager dans le DevOps au sein de cette entreprise. En revanche, si le DevOps vous int\u00e9resse r\u00e9ellement, peut-\u00eatre devriez-vous envisager de changer d'entreprise ? Si votre compagnie souhaite se tourner vers le DevOps, mais que vous avez r\u00e9pondu \u00ab Non \u00bb \u00e0 toutes les questions, alors elle ressemble \u00e0 ce magnifique rhinoc\u00e9ros qui ne changera jamais.<\/p>\n

\"Qu'est-ce
\n<\/p>\n

Organisation<\/h2>\n

\nComme je l'ai d\u00e9j\u00e0 mentionn\u00e9, selon la loi de Conway, l'organisation au sein de l'entreprise \u00e9volue. Commen\u00e7ons par ce qui entrave l'infiltration du DevOps au sein de l'entreprise, notamment du point de vue de l'organisation.<\/p>\n

Le probl\u00e8me des \u00ab silos \u00bb<\/h3>\n

\nLe mot anglais \u00ab Silo \u00bb est traduit ici par \u00ab silo \u00bb en fran\u00e7ais. La signification de ce probl\u00e8me r\u00e9side dans le fait que il n'y a pas d'\u00e9change d'informations entre les \u00e9quipes<\/b>. Chaque \u00e9quipe approfondit son expertise sans \u00e9tablir de carte commune sur laquelle se rep\u00e9rer.<\/p>\n

C'est quelque chose qui rappelle une personne qui vient d'arriver \u00e0 Moscou et qui ne sait pas encore s'orienter avec la carte du m\u00e9tro. Les Moscovites connaissent g\u00e9n\u00e9ralement tr\u00e8s bien leur quartier, et se d\u00e9placent dans toute la ville gr\u00e2ce \u00e0 la carte du m\u00e9tro. Lorsque vous arrivez \u00e0 Moscou pour la premi\u00e8re fois, vous n'avez pas cette comp\u00e9tence, et vous \u00eates juste d\u00e9sorient\u00e9.<\/p>\n

Le DevOps propose de surmonter ce moment de d\u00e9sorientation et de construire ensemble une carte d'interaction pour tous les d\u00e9partements.<\/p><\/blockquote>\n

\nDeux facteurs entravent cela.<\/p>\n

Un effet du syst\u00e8me de gestion d'entreprise.<\/b> Il est construit sur des \u00ab silos \u00bb hi\u00e9rarchiques s\u00e9par\u00e9s. Par exemple, il existe des KPI dans les entreprises qui soutiennent ce syst\u00e8me. D'autre part, les mentalit\u00e9s des individus emp\u00eachent souvent de sortir de leurs zones d'expertise et de s'orienter dans l'ensemble du syst\u00e8me. C'est simplement inconfortable. Imaginez-vous en train d'arriver \u00e0 l'a\u00e9roport de Bangkok - il n'est pas facile de s'y retrouver rapidement. Il est \u00e9galement difficile de s'orienter dans le DevOps, et c'est pourquoi les gens disent qu'il faut trouver un guide pour y arriver.<\/p>\n

Mais surtout, le probl\u00e8me des \u00ab silos \u00bb pour un ing\u00e9nieur qui a \u00e9t\u00e9 impr\u00e9gn\u00e9 de l'esprit DevOps, qui a lu Fowler et beaucoup d'autres livres, se traduit par le fait que les \u00ab silos \u00bb ne permettent pas de faire des choses \u00ab \u00e9videntes \u00bb<\/b>. Nous nous r\u00e9unissons souvent apr\u00e8s le DevOps Moscow, parlons entre nous, et les gens se plaignent :<\/p>\n

\u2014 Nous voulions simplement lancer CI, mais il s'av\u00e8re que la direction n'en a pas besoin.<\/i><\/p>\n

Cela se produit justement \u00e0 cause de\u00a0CI <\/b>et\u00a0Processus de livraison continue<\/b> se trouvent \u00e0 la fronti\u00e8re de nombreuses expertises. Il est tout simplement impossible d'avancer sans surmonter le probl\u00e8me des \u00ab puits \u00bb au niveau organisationnel, peu importe ce que vous faites et \u00e0 quel point cela peut para\u00eetre triste.<\/p>\n

\"Qu'est-ce
\n
\nChaque participant au processus dans l'entreprise : d\u00e9veloppeurs backend et frontend, testeurs, DBA, op\u00e9rations, r\u00e9seau, creuse dans son propre sens, et personne n\u2019a de carte commune, except\u00e9 le gestionnaire qui les observe d'une certaine mani\u00e8re et g\u00e8re selon la m\u00e9thode \u00ab diviser pour r\u00e9gner \u00bb.<\/p>\n

Les gens se battent pour des \u00e9toiles ou des drapeaux, chacun creuse dans sa propre expertise.<\/p><\/blockquote>\n

\nAu final, lorsque la t\u00e2che se pr\u00e9sente de tout rassembler et de construire un pipeline commun, et qu'il n'est plus n\u00e9cessaire de se battre pour des \u00e9toiles et des drapeaux, la question se pose \u2014 que faire alors ? Il faut trouver un moyen de se mettre d'accord, mais personne ne nous a appris \u00e0 le faire \u00e0 l'\u00e9cole. Nous avons \u00e9t\u00e9 \u00e9duqu\u00e9s \u00e0 l'\u00e9cole : la huiti\u00e8me classe \u2014 wow ! \u2014 par rapport \u00e0 la septi\u00e8me classe ! C'est exactement la m\u00eame chose ici.<\/p>\n

Est-ce aussi le cas dans votre entreprise ?<\/h3>\n

\nPour v\u00e9rifier cela, on peut se poser les questions suivantes.<\/p>\n

Les \u00e9quipes utilisent-elles des outils communs, contribuent-elles aux modifications de ces outils communs ?<\/p>\n

\u00c0 quelle fr\u00e9quence les \u00e9quipes se r\u00e9organisent-elles \u2014 des sp\u00e9cialistes d'une \u00e9quipe passent-ils \u00e0 une autre \u00e9quipe ?<\/b> C'est pr\u00e9cis\u00e9ment dans l'environnement DevOps que cela devient normal, car parfois une personne ne peut tout simplement pas comprendre ce que fait une autre zone d'expertise. Elle passe \u00e0 un autre service, y travaille deux semaines pour \u00e9tablir une carte d'orientation et d'interaction avec ce service.<\/p>\n

Peut-on cr\u00e9er un comit\u00e9 de changement et modifier quelque chose ? <\/b>Ou est-ce qu\u2019il faut une main forte de la haute direction et un ordre ? R\u00e9cemment, j'ai \u00e9crit sur Facebook comment une banque peu connue impl\u00e9mente des outils par des ordres : ils ont \u00e9crit un ordre, l'ont mis en \u0153uvre pendant un an et regardent ce qui se passe. C'est, bien s\u00fbr, long et triste.<\/p>\n

\u00c0 quel point est-il important pour les managers d'obtenir des r\u00e9alisations personnelles ind\u00e9pendamment des r\u00e9alisations de l'entreprise ? <\/b><\/p>\n

Si vous r\u00e9pondez \u00e0 ces questions, il sera plus clair si vous avez un tel probl\u00e8me dans votre entreprise.<\/p>\n

Infrastructure en tant que code<\/h2>\n

\nUne fois ce probl\u00e8me r\u00e9solu, la premi\u00e8re pratique essentielle pour progresser dans DevOps est de l'infrastructure en tant que code<\/b>. <\/p>\n

L'infrastructure en tant que code est souvent per\u00e7ue comme suit :<\/p>\n

\u2014 Automatisons tout avec bash, empilons les scripts pour r\u00e9duire le travail manuel des administrateurs !<\/i><\/p>\n

Mais ce n'est pas le cas.<\/p>\n

L'infrastructure en tant que code signifie que vous d\u00e9crivez le syst\u00e8me informatique avec lequel vous travaillez sous forme de code, afin de toujours comprendre son \u00e9tat.<\/p><\/blockquote>\n

\nEn collaboration avec d'autres \u00e9quipes, vous cr\u00e9ez une carte sous forme de code, compr\u00e9hensible par tous, sur laquelle vous pouvez vous orienter et naviguer. Peu importe la technologie utilis\u00e9e \u2014 Chef, Ansible, Salt, ou l'utilisation de fichiers YAML dans Kubernetes \u2014 la m\u00e9thode n'a pas d'importance.<\/p>\n

Lors d'une conf\u00e9rence, un coll\u00e8gue de 2GIS a parl\u00e9 de leur outil interne pour Kubernetes, qui d\u00e9crit le fonctionnement de syst\u00e8mes distincts. Pour d\u00e9crire 500 syst\u00e8mes, ils ont eu besoin d'un outil distinct qui g\u00e9n\u00e8re cette description. Lorsqu'il existe cette description, tout le monde peut se r\u00e9f\u00e9rer les uns aux autres, surveiller les modifications, voir comment il peut \u00eatre modifi\u00e9 et am\u00e9lior\u00e9, et ce qui manque. <\/p>\n

Vous conviendrez que les scripts bash individuels ne fournissent g\u00e9n\u00e9ralement pas cette compr\u00e9hension. Dans l'une des entreprises o\u00f9 j'ai travaill\u00e9, il y avait m\u00eame un terme \u00ab script write only \u00bb \u2014 lorsque le script est \u00e9crit, mais qu'il est impossible de le relire. Je pense que cela vous est familier \u00e9galement.<\/p>\n

L'infrastructure en tant que code est du code qui d\u00e9crit l'\u00e9tat actuel de l'infrastructure<\/b>. Ce code est co\u00e9crit par de nombreuses \u00e9quipes produit, infrastructure et service, et, surtout, tous doivent comprendre comment ce code fonctionne.<\/p>\n

Le code est maintenu selon les meilleures pratiques de d\u00e9veloppement<\/b>: d\u00e9veloppement collaboratif, revues de code, XP-programming, tests, pull requests, CI pour l'infrastructure en tant que code \u2014 tout cela est pertinent et peut \u00eatre utilis\u00e9.<\/p>\n

Le code devient un langage commun pour tous les ing\u00e9nieurs.<\/p><\/blockquote>\n

\nModifier l'infrastructure dans le code ne prend pas beaucoup de temps<\/b>. Oui, le code d'infrastructure peut \u00e9galement accumuler une dette technique. En g\u00e9n\u00e9ral, les \u00e9quipes y font face environ un an et demi apr\u00e8s avoir commenc\u00e9 \u00e0 mettre en \u0153uvre \u00ab l'infrastructure en tant que code \u00bb sous forme d'une multitude de scripts ou m\u00eame d'Ansible qu'ils \u00e9crivent comme du code spaghetti, tout en y ajoutant encore des scripts bash dans le tas ! <\/p>\n

Important<\/b>: Si vous n'avez pas encore essay\u00e9 cette chose, souvenez-vous que Ansible n'est pas bash<\/b>! Lisez attentivement la documentation, \u00e9tudiez ce qui s'\u00e9crit \u00e0 ce sujet.<\/p>\n

L'infrastructure en tant que code est la s\u00e9paration du code d'infrastructure en couches distinctes.<\/p><\/blockquote>\n

\nNous dans notre entreprise identifions 3 couches de base, qui sont tr\u00e8s claires et simples, mais il peut y en avoir plus. Vous pouvez examiner votre code d'infrastructure et dire si vous avez ce crit\u00e8re ou non. Si aucune couche n'est identifi\u00e9e, il faut prendre le temps de faire un peu de refactorisation.
\n\"Qu'est-ce
\n
\nCouche de base<\/b>\u00a0\u2014 c'est comment le syst\u00e8me d'exploitation, les sauvegardes et d'autres choses de bas niveau sont configur\u00e9s, par exemple, comment Kubernetes est d\u00e9ploy\u00e9 \u00e0 un niveau fondamental.<\/p>\n

Niveau des services<\/b>\u00a0\u2014 ce sont les services que vous offrez aux d\u00e9veloppeurs : journalisation en tant que service, surveillance en tant que service, base de donn\u00e9es en tant que service, \u00e9quilibreur de charge en tant que service, file d'attente en tant que service, livraison continue en tant que service \u2014 une multitude de services que diff\u00e9rentes \u00e9quipes peuvent fournir au d\u00e9veloppement. Tous ceux-ci doivent \u00eatre d\u00e9crits en modules distincts dans votre syst\u00e8me de gestion de configuration.<\/p>\n

Couche o\u00f9 les applications sont d\u00e9velopp\u00e9es<\/b> et d\u00e9crite, comment elles seront d\u00e9ploy\u00e9es sur les deux couches pr\u00e9c\u00e9dentes.<\/p>\n

Questions de contr\u00f4le<\/h3>\n

\nAvez-vous dans votre entreprise un r\u00e9f\u00e9rentiel d'infrastructure commun ? Contr\u00f4lez-vous la dette technique dans l'infrastructure ? Utilisez-vous des pratiques de d\u00e9veloppement dans le r\u00e9f\u00e9rentiel d'infrastructure ? Votre infrastructure est-elle d\u00e9coup\u00e9e en couches ? Vous pouvez v\u00e9rifier avec le sch\u00e9ma Base-service-APP. \u00c0 quel point est-il difficile d'apporter une modification ? <\/p>\n

Si vous avez rencontr\u00e9 des situations o\u00f9 apporter des modifications prenait un jour et demi, cela signifie que vous avez accumul\u00e9 une dette technique avec laquelle il faut travailler. Vous \u00eates juste tomb\u00e9 sur les pi\u00e8ges de la dette technique dans le code d'infrastructure. Je me souviens de nombreuses histoires, o\u00f9 pour changer un CCTL, il fallait r\u00e9\u00e9crire la moiti\u00e9 du code d'infrastructure, parce que la cr\u00e9ativit\u00e9 et le d\u00e9sir d'automatiser tout ont conduit \u00e0 une situation o\u00f9 tout est compliqu\u00e9, toutes les manipulations sont supprim\u00e9es, et il est n\u00e9cessaire de faire une refactorisation.<\/p>\n

Livraison continue<\/h2>\n

\nFaisons le point sur le d\u00e9bit et le cr\u00e9dit. D'abord, une description de l'infrastructure appara\u00eet, qui peut \u00eatre assez basique. Il n'est pas n\u00e9cessaire de tout d\u00e9crire en d\u00e9tail, mais une description de base est requise pour que vous puissiez travailler avec cela. Sinon, il est difficile de comprendre sur quoi construire la livraison continue par la suite. Toutes ces pratiques se d\u00e9roulent simultan\u00e9ment lorsque vous arrivez \u00e0 DevOps, mais il faut d'abord commencer par comprendre ce que vous avez et comment le g\u00e9rer. C'est pr\u00e9cis\u00e9ment la pratique de l'infrastructure en tant que code.<\/p>\n

Apr\u00e8s avoir compris ce que vous avez et comment le g\u00e9rer, vous commencez \u00e0 r\u00e9fl\u00e9chir \u00e0 la mani\u00e8re d'envoyer le code du d\u00e9veloppeur en production le plus rapidement possible. Je parle de le faire en collaboration avec le d\u00e9veloppeur - n'oublions pas le probl\u00e8me des \u00ab puits \u00bb, c'est-\u00e0-dire que ce ne sont pas des personnes distinctes qui le pensent, mais une \u00e9quipe.<\/p>\n

Quand nous avons\u00a0Ren\u00e9 Evtoukhovitch<\/b> vu le premier livre Jez Hammble<\/b> et le groupe d'auteurs \u00ab Continuous Delivery \u00bb<\/b>, qui est sorti en 2009, nous avons longtemps r\u00e9fl\u00e9chi \u00e0 la mani\u00e8re de traduire son titre en fran\u00e7ais. Nous voulions le traduire par \u00ab Livraison continue \u00bb, mais malheureusement, nous l'avons traduit par \u00ab Livraison ininterrompue \u00bb. Je pense qu'il y a quelque chose de russe dans notre titre, avec du caract\u00e8re.<\/p>\n

Livrer constamment signifie<\/h3>\n

\nLe code qui se trouve dans le d\u00e9p\u00f4t produit peut toujours \u00eatre d\u00e9ploy\u00e9 en production<\/b>. Il peut ne pas \u00eatre d\u00e9ploy\u00e9, mais il est toujours pr\u00eat pour cela. Par cons\u00e9quent, vous \u00e9crivez toujours le code avec un sentiment difficile \u00e0 expliquer d'une certaine inqui\u00e9tude au creux du ventre. Ce sentiment d'inqui\u00e9tude doit \u00eatre pr\u00e9sent - il d\u00e9clenche des processus mentaux qui permettent d'\u00e9crire le code d'une mani\u00e8re l\u00e9g\u00e8rement diff\u00e9rente. Cela doit \u00eatre enregistr\u00e9 dans les r\u00e8gles au sein du d\u00e9veloppement.<\/p>\n

Pour livrer constamment, il faut un format d'art\u00e9fact qui traverse la plateforme d'infrastructure. <\/b>Si vous jetez diff\u00e9rents formats de \u00ab d\u00e9chets de fonctionnement \u00bb sur la plateforme d'infrastructure, elle devient non unifi\u00e9e, difficile \u00e0 entretenir, et cela cr\u00e9e un probl\u00e8me de dette technique. Le format d'art\u00e9fact doit \u00eatre align\u00e9 - c'est aussi une t\u00e2che collective : tout le monde doit se rassembler, r\u00e9fl\u00e9chir ensemble et inventer ce format.<\/p>\n

L'objet est constamment am\u00e9lior\u00e9 et \u00e9volue en fonction de l'environnement de production tout au long de son parcours dans le pipeline de livraison. <\/b>Lorsque l'objet progresse dans le pipeline, il se heurte tout le temps \u00e0 des \u00e9l\u00e9ments qui lui posent probl\u00e8me, semblables \u00e0 ceux que rencontre l'objet que vous d\u00e9ployez en production. Si, dans le d\u00e9veloppement classique, cela est g\u00e9r\u00e9 par un administrateur syst\u00e8me qui effectue le d\u00e9ploiement, dans le processus DevOps, cela se produit en permanence : ici, il a \u00e9t\u00e9 soumis \u00e0 des tests, l\u00e0, il a \u00e9t\u00e9 plac\u00e9 dans un cluster Kubernetes qui ressemble plus ou moins \u00e0 la production, et l\u00e0, des tests de charge ont \u00e9t\u00e9 soudainement lanc\u00e9s.<\/p>\n

Cela ressemble un peu \u00e0 un jeu de Pac-Man : l'objet traverse une sorte d'histoire. Il est important de contr\u00f4ler si le code suit r\u00e9ellement cette histoire et si elle est li\u00e9e \u00e0 votre production. Les histoires li\u00e9es \u00e0 la production peuvent \u00eatre int\u00e9gr\u00e9es dans le processus de Continuous Delivery : cela se passait ainsi, lorsque quelque chose \u00e9chouait, maintenant programmons simplement ce sc\u00e9nario dans le syst\u00e8me. \u00c0 chaque fois, le code passera \u00e9galement par ce sc\u00e9nario, et vous ne rencontrerez plus ce probl\u00e8me la prochaine fois. Vous serez au courant bien avant qu'il n'apparaisse pour votre client.<\/p>\n

Diff\u00e9rentes strat\u00e9gies de d\u00e9ploiement. <\/b>Par exemple, vous utilisez des tests A\/B ou des d\u00e9ploiements canari pour tester le code sur diff\u00e9rents clients, recueillant des informations sur le fonctionnement du code, bien avant qu'il ne soit lanc\u00e9 pour 100 millions d'utilisateurs.<\/p>\n

Le terme \u00ab livraison continue \u00bb se pr\u00e9sente comme suit.<\/p>\n

\"Qu'est-ce
\n<\/p>\n

Le processus de livraison Dev, CI, Test, PreProd, Prod n'est pas un environnement distinct, ce sont des \u00e9tapes ou des stations avec des montants non br\u00fblables que votre objet traverse.<\/p><\/blockquote>\n

\nSi vous avez un code d'infrastructure d\u00e9crit comme Base Service APP, alors il aide \u00e0 ne pas oublier tous les sc\u00e9narios<\/b>, et \u00e0 les enregistrer \u00e9galement sous forme de code pour cet objet, \u00e0 faire progresser l'objet<\/b> et \u00e0 le modifier en cours de route.<\/p>\n

Questions d'auto-\u00e9valuation<\/h3>\n

\nLe temps entre la description d'une fonctionnalit\u00e9 et le d\u00e9ploiement en production est-il inf\u00e9rieur \u00e0 une semaine dans 95 % des cas ? La qualit\u00e9 de l'objet s'am\u00e9liore-t-elle \u00e0 chaque \u00e9tape du pipeline ? Y a-t-il une histoire \u00e0 travers laquelle il passe ? Utilisez-vous diff\u00e9rentes strat\u00e9gies de d\u00e9ploiement ?<\/p>\n

Si toutes les r\u00e9ponses sont oui, alors vous \u00eates incroyablement g\u00e9niaux ! \u00c9crivez vos r\u00e9ponses dans les commentaires - je serais ravi).<\/p>\n

Retour d'information<\/h3>\n

\nC'est la pratique la plus complexe de toutes. Lors de la conf\u00e9rence DevOpsConf, un coll\u00e8gue d'Infobip, en parlant de cela, avait un peu de mal \u00e0 trouver ses mots, car c'est vraiment une pratique tr\u00e8s complexe qui consiste \u00e0 surveiller absolument tout !<\/p>\n

\"Qu'est-ce
\n
\nPar exemple, il y a longtemps, quand je travaillais chez Qik et que nous avons r\u00e9alis\u00e9 qu'il fallait surveiller absolument tout. Nous l'avons fait, et nous avons eu 150 000 \u00e9l\u00e9ments dans Zabbix qui \u00e9taient surveill\u00e9s en continu. C'\u00e9tait effrayant, le directeur technique se moquait :<\/p>\n

\u2014 Les gars, pourquoi abusez-vous du serveur sans raison ?<\/i><\/p>\n

Mais ensuite, il y a eu un cas qui a montr\u00e9 que c'est en effet une strat\u00e9gie vraiment g\u00e9niale.<\/p>\n

L'un des services a commenc\u00e9 \u00e0 tomber constamment. Au d\u00e9part, il ne tombait pas, ce qui est int\u00e9ressant, aucun code n'y \u00e9tait ajout\u00e9, car c'\u00e9tait un courtier de base, qui n'avait pratiquement pas de fonctionnalit\u00e9 m\u00e9tier \u2014 il ne faisait que transmettre des messages entre diff\u00e9rents services. Le service n'avait pas chang\u00e9 pendant 4 mois, et soudain il a commenc\u00e9 \u00e0 tomber avec une erreur \u00ab Segmentation fault \u00bb.<\/p>\n

Nous \u00e9tions sous le choc, nous avons ouvert nos graphiques dans Zabbix, et il s'est av\u00e9r\u00e9 qu'il y a une semaine et demie, le comportement des requ\u00eates dans le service API avait fortement chang\u00e9. Ensuite, nous avons regard\u00e9 et vu que la fr\u00e9quence d'envoi d'un certain type de messages avait chang\u00e9. Nous avons d\u00e9couvert que c'\u00e9tait les clients Android. Nous avons demand\u00e9 :<\/p>\n

\u2014 Les gars, qu'est-ce qui s'est pass\u00e9 il y a une semaine et demie ?<\/i><\/p>\n

En r\u00e9ponse, nous avons entendu une histoire int\u00e9ressante sur le fait qu'ils avaient refait l'interface utilisateur. Peu de gens diraient imm\u00e9diatement qu'ils ont chang\u00e9 la biblioth\u00e8que HTTP. Pour les clients Android, c'est comme changer de savon dans la salle de bain \u2014 ils ne s'en souviennent tout simplement pas. Au final, apr\u00e8s 40 minutes de conversation, nous avons d\u00e9couvert qu'ils avaient effectivement chang\u00e9 la biblioth\u00e8que HTTP, et que les temps par d\u00e9faut avaient chang\u00e9. Cela a entra\u00een\u00e9 un changement de comportement du trafic sur le serveur API, ce qui a caus\u00e9 une course \u00e0 l'int\u00e9rieur du courtier, et il a commenc\u00e9 \u00e0 tomber.<\/p>\n

Sans une surveillance approfondie, il serait impossible de d\u00e9tecter cela.<\/b>. Cependant, s'il y a encore un probl\u00e8me de \u00ab puits \u00bb dans l'organisation, o\u00f9 chacun renvoie la faute \u00e0 l'autre, cela peut durer des ann\u00e9es. Vous red\u00e9marrez simplement le serveur, car il est impossible de r\u00e9soudre le probl\u00e8me. Lorsque vous surveillez, suivez et tracez tous les \u00e9v\u00e9nements que vous avez et utilisez la surveillance comme un test \u2014 vous \u00e9crivez du code et indiquez imm\u00e9diatement comment le surveiller, \u00e9galement sous forme de code (nous avons d\u00e9j\u00e0 une infrastructure comme code), tout devient clair comme de l'eau de roche. M\u00eame les probl\u00e8mes complexes sont facilement tra\u00e7ables.<\/p>\n

\"Qu'est-ce
\n<\/p>\n

Collectez toutes les informations sur ce qui se passe avec l'artefact \u00e0 chaque \u00e9tape du processus de livraison \u2014 pas en production.<\/p><\/blockquote>\n

\nChargez la surveillance sur le CI, et l\u00e0-bas, certaines choses de base seront visibles. Ensuite, vous les verrez \u00e0 la fois en Test, en PredProd, et lors des tests de charge. Collectez des informations \u00e0 toutes les \u00e9tapes, non seulement des m\u00e9triques et des statistiques, mais aussi des journaux : comment l'application a \u00e9t\u00e9 d\u00e9ploy\u00e9e, les anomalies \u2014 collectez tout. <\/p>\n

Dans le cas contraire, il sera difficile de s'y retrouver. J'ai d\u00e9j\u00e0 dit que le DevOps repr\u00e9sente une plus grande complexit\u00e9. Pour faire face \u00e0 cette complexit\u00e9, il est n\u00e9cessaire d'avoir une bonne analytique.<\/b>.<\/p>\n

Questions pour l'auto-\u00e9valuation<\/h3>\n

\nVotre surveillance et votre journalisation sont-elles des outils de d\u00e9veloppement pour vous ?<\/b> Vos d\u00e9veloppeurs, y compris vous-m\u00eame, lorsqu'ils \u00e9crivent du code, pensent-ils \u00e0 la fa\u00e7on de le surveiller ?<\/p>\n

Apprenez-vous les probl\u00e8mes de la part des clients ? Comprenez-vous mieux le client gr\u00e2ce \u00e0 la surveillance et \u00e0 la journalisation ?<\/b> Comprenez-vous mieux le syst\u00e8me gr\u00e2ce \u00e0 la surveillance et \u00e0 la journalisation ?<\/b> Changez-vous le syst\u00e8me simplement parce que vous avez vu que la tendance dans le syst\u00e8me augmente et que vous comprenez qu'encore trois semaines et tout sera \u00e0 l\u2019arr\u00eat ? <\/p>\n

Lorsque vous avez ces trois composants, vous pouvez r\u00e9fl\u00e9chir \u00e0 l'infrastructure de votre entreprise.<\/p>\n

Plateforme d'infrastructure <\/h2>\n

\nLe sens n'est pas que ce soit un ensemble d'outils disparates qui existent dans chaque entreprise.<\/p>\n

Le sens de la plateforme d'infrastructure est que toutes les \u00e9quipes utilisent ces outils et les d\u00e9veloppent ensemble.<\/p><\/blockquote>\n

\nIl est clair qu'il y a des \u00e9quipes distinctes qui sont responsables du d\u00e9veloppement de morceaux sp\u00e9cifiques de la plateforme d'infrastructure. Mais en m\u00eame temps, la responsabilit\u00e9 du d\u00e9veloppement, de la fonctionnalit\u00e9 et de la promotion de la plateforme d'infrastructure incombe \u00e0 chaque ing\u00e9nieur. Au niveau interne, cela devient un outil commun.<\/b>. <\/p>\n

Toutes les \u00e9quipes d\u00e9veloppent la plateforme d'infrastructure, en prenant soin d'elle comme de leur propre IDE.<\/b>. Dans votre IDE, vous installez diff\u00e9rents plugins pour que tout soit beau et rapide, vous configurez des raccourcis. Lorsque vous ouvrez Sublime, Atom ou Visual Studio Code, vous \u00eates envahis par des erreurs de code et vous r\u00e9alisez qu'il est impossible de travailler, cela vous rend imm\u00e9diatement triste et vous vous d\u00e9p\u00eachez de r\u00e9parer votre IDE.<\/p>\n

Traitez votre plateforme d'infrastructure de la m\u00eame mani\u00e8re. Si vous sentez qu'il y a un probl\u00e8me, laissez une demande si vous ne pouvez pas le r\u00e9parer vous-m\u00eame. Si c'est quelque chose de simple, corrigez-le vous-m\u00eame, envoyez une demande de tirage - les gars l'examinent, ajoutent. C'est une approche un peu diff\u00e9rente de l'outillage ing\u00e9nierie dans l'esprit du d\u00e9veloppeur.<\/p>\n

La plateforme d'infrastructure permet le transfert d'artefacts du d\u00e9veloppement au client avec une am\u00e9lioration continue de la qualit\u00e9.<\/b>. Dans la plateforme d'infrastructure, un ensemble d'histoires est programm\u00e9, qui se produisent avec le code en production. Au fil des ann\u00e9es de d\u00e9veloppement, le nombre d'histoires devient tr\u00e8s important, certaines d'entre elles sont uniques et ne vous concernent que vous - elles sont impossibles \u00e0 trouver sur Google. <\/p>\n

\u00c0 ce moment-l\u00e0, la plateforme d'infrastructure devient votre avantage concurrentiel.<\/b>, parce qu'elle int\u00e8gre des \u00e9l\u00e9ments qui ne se trouvent pas dans l'outil des concurrents. Plus votre plateforme d'infrastructure est profonde, plus votre avantage concurrentiel en termes de temps de mise sur le march\u00e9 est important. Ici, se pose le probl\u00e8me du verrouillage fournisseur.<\/b>: Vous pouvez adopter une plateforme tierce, mais en utilisant l'exp\u00e9rience d'autrui, vous ne serez pas en mesure de juger de sa pertinence pour vous. Oui, toute entreprise ne peut pas construire une plateforme comme Amazon. C'est une d\u00e9marche complexe o\u00f9 l'exp\u00e9rience de l'entreprise est pertinente en fonction de sa position sur le march\u00e9, et il ne faut pas permettre un verrouillage fournisseur. Il est \u00e9galement important d'y r\u00e9fl\u00e9chir.<\/p>\n

Configuration<\/h3>\n

\nC'est le sch\u00e9ma de base de la plateforme d'infrastructure qui vous aidera \u00e0 \u00e9tablir toutes les pratiques et processus dans une entreprise DevOps.<\/p>\n

\"Qu'est-ce
\n
\nExaminons de quoi elle se compose.<\/p>\n

Syst\u00e8me d'orchestration des ressources<\/b>, qui fournit CPU, m\u00e9moire, disque aux applications et \u00e0 d'autres services. Au-dessus de cela - services de niveau inf\u00e9rieur<\/b>: surveillance, journalisation, moteur CI\/CD, stockage d'artefacts, infrastructure en tant que code.<\/p>\n

Services de niveau sup\u00e9rieur.<\/b>: base de donn\u00e9es comme service, files d'attente comme service, Load Balance comme service, redimensionnement d'images comme service, Big Data fabrique comme service. En plus de cela \u2014 pipeline qui fournit un code constamment modifi\u00e9 \u00e0 votre client<\/b>.<\/p>\n

Vous obtenez des informations sur le fonctionnement de votre logiciel chez le client, vous modifiez, vous renvoyez ce code, vous obtenez des informations \u2014 et vous d\u00e9veloppez constamment \u00e0 la fois votre infrastructure et votre logiciel.<\/p>\n

Sur le sch\u00e9ma, le delivery pipeline se compose de plusieurs \u00e9tapes. Mais c'est un sch\u00e9ma principal, pr\u00e9sent\u00e9 \u00e0 titre d'exemple \u2014 il ne faut pas le reproduire \u00e0 l'identique. Les \u00e9tapes interagissent avec des services, comme des services \u2014 chaque brique de la plateforme a sa propre histoire : comment les ressources sont allou\u00e9es, comment l'application est lanc\u00e9e, fonctionne avec les ressources, est surveill\u00e9e, et modifi\u00e9e.<\/p>\n

Il est important de comprendre que chaque partie de la plateforme a une histoire, et de se poser la question \u2014 quelle histoire porte cette brique, peut-\u00eatre vaut-il mieux la jeter et la remplacer par un service tiers. Par exemple, peut-on remplacer une brique par Okmeter ? Peut-\u00eatre que les gars ont d\u00e9j\u00e0 d\u00e9velopp\u00e9 cette expertise bien plus que nous. Mais peut-\u00eatre que non \u2014 peut-\u00eatre que nous avons une expertise unique, nous devons mettre en place Prometheus et d\u00e9velopper cela davantage.<\/p>\n

Cr\u00e9ation de plateforme<\/h3>\n

\nC'est un processus de communication complexe. Lorsque vous avez des pratiques de base, vous lancez la communication entre diff\u00e9rents ing\u00e9nieurs et sp\u00e9cialistes, qui d\u00e9veloppent des exigences et des normes, et les modifient continuellement \u00e0 propos des diff\u00e9rents outils et approches. Ici, la culture qui existe dans le DevOps est importante.<\/p>\n

\"Qu'est-ce
\nAvec la culture, tout est tr\u00e8s simple \u2014 c'est la collaboration et la communication<\/b>, c'est-\u00e0-dire le d\u00e9sir de travailler ensemble dans un m\u00eame espace, le d\u00e9sir de ma\u00eetriser un seul outil ensemble. Il n'y a rien de rocket science ici \u2014 tout est tr\u00e8s simple, banale. Par exemple, nous vivons tous dans le m\u00eame immeuble et maintenons sa propret\u00e9 \u2014 c'est ce niveau de culture.<\/p>\n

Et chez vous ?<\/h3>\n

\nEncore une fois des questions que vous pouvez vous poser.<\/p>\n

La plateforme d'infrastructure est-elle d\u00e9finie ? Qui est responsable de son d\u00e9veloppement ? Comprenez-vous les avantages concurrentiels de votre plateforme d'infrastructure ?<\/p>\n

Ces questions doivent toujours \u00eatre pos\u00e9es. Si quelque chose peut \u00eatre externalis\u00e9 \u00e0 des services tiers, il faut le faire. Si un service tiers commence \u00e0 bloquer vos activit\u00e9s, il faut alors construire un syst\u00e8me en interne.<\/p>\n

Donc, DevOps...<\/h2>\n

\n\u2026 c'est un syst\u00e8me complexe, il doit contenir :<\/p>\n