Le fondateur et directeur d'Otomato Software, l'un des initiateurs et instructeurs de la première certification DevOps en Israël, Anton Weiss, a parlé l'année dernière de la théorie du chaos et des principaux principes de l'ingénierie du chaos, ainsi que de l'organisation DevOps idéale du futur.
Nous avons préparé une version texte du rapport.
Bonjour!
DevOpsDays à Moscou pour la deuxième année consécutive, je suis sur cette scène pour la deuxième fois, beaucoup d'entre vous sont dans cette salle pour la deuxième fois. Qu'est-ce que cela signifie ? Cela signifie que le mouvement DevOps en Russie grandit, se multiplie, et surtout, cela signifie qu'il est temps de parler de ce qu'est DevOps en 2018.
Levez la main ceux qui pensent qu'en 2018, DevOps est déjà une profession ? Il y en a. Y a-t-il des ingénieurs DevOps dans la salle dont le poste est inscrit « Ingénieur DevOps » ? Y a-t-il des managers DevOps dans la salle ? Personne. Des architectes DevOps ? Aucun. Ça fait peu. Vraiment, personne n'a inscrit qu'il est ingénieur DevOps ?
Cela signifie que la plupart d'entre vous pensent que c'est un anti-modèle ? Que cette profession ne devrait pas exister ? On peut penser ce qu'on veut, mais pendant que nous réfléchissons, l'industrie avance solennellement sous le son du trompette du DevOps.
Qui a entendu parler du nouveau sujet appelé DevDevOps ? C'est une nouvelle méthodologie permettant d'assurer une collaboration efficace entre les développeurs et les DevOps. D'ailleurs, ce n'est pas si nouveau. Si l'on se fie à Twitter, ça fait déjà 4 ans qu'on en parle. Et l'intérêt pour cela grandit encore et encore, donc il y a un problème. Ce problème doit être résolu.
Nous sommes des personnes créatives et nous ne nous contentons pas de peu. Nous disons : DevOps est un terme trop étroit, il manque encore diverses choses intéressantes. Nous allons dans nos laboratoires secrets et commençons à créer des mutations curieuses : DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.
La logique est implacable, non ? Notre système de livraison n'est pas fonctionnel, nos systèmes sont instables et les utilisateurs sont mécontents, nous ne sommes pas à jour pour déployer les logiciels à temps, nous ne respectons pas le budget. Comment allons-nous résoudre tout cela ? Nous allons inventer un nouveau mot ! Cela se terminera par « Ops », et le problème sera résolu.
J'appelle cette approche « Ops, et le problème est résolu ».
Tout cela passe au second plan si nous nous rappelons pourquoi nous avons tout imaginé. Nous avons créé tout ce DevOps pour rendre la livraison de logiciels et notre propre travail dans ce processus aussi fluide, sans douleur, efficace, et surtout, agréable que possible.
DevOps est né de la douleur. Et nous en avons assez de souffrir. Pour que cela se réalise, nous nous appuyons sur des pratiques intemporelles : une collaboration efficace, des pratiques de flux, et surtout, une pensée systémique, car sans cela, aucun DevOps ne fonctionne.
Qu'est-ce qu'un système ?
Et puisque nous avons évoqué la pensée systémique, rappelons-nous ce qu'est un système.
Si vous êtes un hacker révolutionnaire, alors pour vous, un système est un mal indéniable. C'est un nuage qui plane au-dessus de vous et vous force à faire ce que vous ne voulez pas faire.
D'un point de vue systémique, un système est un tout constitué de parties. En ce sens, chacun de nous est un système. Les organisations dans lesquelles nous travaillons sont des systèmes. Et ce que nous construisons ensemble s'appelle aussi un système.
Tout cela fait partie d'un grand système sociotechnique. Et ce n'est que si nous comprenons comment ce système sociotechnique fonctionne ensemble que nous pourrons vraiment optimiser quelque chose.
D'un point de vue systémique, un système a différentes propriétés intéressantes. Tout d'abord, il est constitué de parties, ce qui signifie que son comportement dépend de celui des parties. De plus, toutes ses parties sont également interdépendantes. Cela signifie que plus un système a de parties, plus il devient difficile de comprendre ou de prévoir son comportement.
Du point de vue du comportement, il existe également un autre fait intéressant. Un système peut faire quelque chose que aucune de ses parties séparées ne peut faire.
Comme l'a dit le Dr Russell Ackoff (l'un des pionniers de la pensée systémique), cela peut être facilement prouvé par un expérience de pensée. Par exemple, qui ici sait coder ? Beaucoup de mains se lèvent, et c'est normal, car c'est une des exigences fondamentales de notre profession. Vous savez écrire, mais vos mains, séparément de vous, peuvent-elles écrire du code ? Il y a des gens qui diront : « Ce n'est pas mes mains qui écrivent du code, c'est mon cerveau qui écrit du code ». Mais le cerveau peut-il écrire du code séparément de vous ? Probablement pas.
Le cerveau est une machine incroyable, nous ne savons même pas 10 % de son fonctionnement, mais il ne peut pas fonctionner séparément du système qu'est notre corps. Et cela peut être prouvé facilement : ouvrez votre boîte crânienne, sortez le cerveau, posez-le devant un ordinateur et essayez d'écrire quelque chose de simple. 'Hello, world' en Python, par exemple.
Si un système peut accomplir quelque chose que ses parties individuelles ne peuvent pas faire, cela signifie que son comportement n'est pas déterminé par le comportement de ses parties. Alors, qu'est-ce qui le détermine ? Cela est déterminé par l'interaction entre ces parties. Ainsi, plus il y a de parties, plus les interactions sont complexes, plus il devient difficile de comprendre et de prédire le comportement du système. Cela rend un tel système chaotique, car le moindre changement, même le plus insignifiant et invisible à l'œil nu, dans l'une des parties du système peut conduire à des résultats totalement imprévisibles.
Cette sensibilité aux conditions initiales a été découverte et étudiée pour la première fois par le météorologue américain Edward Lorenz. Par la suite, elle a été appelée « l'effet papillon » et a conduit au développement d'un courant de pensée scientifique connu sous le nom de « théorie du chaos ». Cette théorie est devenue l'un des principaux changements de paradigme dans la science du 20ème siècle.
Théorie du chaos
Les personnes qui étudient le chaos se qualifient de chaosologues.
La véritable raison de ce discours est que, en travaillant avec des systèmes complexes distribués et de grandes organisations internationales, j'ai réalisé à un moment donné que c'était ainsi que je me percevais. Je suis chaosologue. C'est en gros une manière rusée de dire : 'Je ne comprends pas ce qui se passe ici et je ne sais pas comment y faire face.'
Je pense que beaucoup d'entre vous se sentent souvent ainsi aussi, donc vous êtes aussi chaosologues. Je vous invite à rejoindre la guilde des chaosologues. Les systèmes que nous, chers collègues chaosologues, allons étudier sont appelés « systèmes adaptatifs complexes ».
Qu'est-ce que l'adaptabilité ? L'adaptabilité signifie que le comportement individuel et collectif des parties dans un tel système adaptatif change et s'auto-organise, en réponse à des événements ou des chaines de micro-événements dans le système. En d'autres termes, le système s'adapte aux changements par le biais de l'auto-organisation. Cette capacité à s'auto-organiser repose sur la coopération volontaire et entièrement décentralisée d'agents autonomes libres.
Une autre caractéristique intéressante de ces systèmes est qu'ils sont librement évolutifs. Ce qui devrait, en tant qu'ingénieurs en chaos, éveiller notre intérêt. Donc, si nous avons dit que le comportement d'un système complexe est déterminé par l'interaction de ses parties, qu'est-ce qui devrait nous intéresser ? L'interaction.
Il y a encore deux conclusions intéressantes.
Premièrement, nous comprenons qu'il est impossible de simplifier un système complexe en simplifiant ses parties. Deuxièmement, le seul moyen de simplifier un système complexe est de simplifier les interactions entre ses parties.
Comment interagissons-nous ? Nous sommes tous des parties d'un grand système d'information que l'on appelle la société humaine. Nous interagissons par le biais d'une langue commune, si nous en avons une, si nous la trouvons.
Mais la langue elle-même est un système adaptatif complexe. Ainsi, pour interagir plus efficacement et simplement, nous avons besoin de créer certains protocoles. C'est-à-dire une séquence de symboles et d'actions qui rendront l'échange d'informations entre nous plus simple, plus prévisible et plus compréhensible.
Je veux dire que les tendances à la complexification, à l'adaptabilité, à la décentralisation et au chaos se retrouvent partout. Dans les systèmes que nous construisons et dans les systèmes dont nous faisons partie.
Pour ne pas rester dans l'abstrait, examinons comment évoluent les systèmes que nous créons.
Vous attendiez ce mot, je le comprends. Nous sommes à la conférence DevOps, aujourd'hui ce mot sera prononcé quelque part autour de cent mille fois et ensuite, il nous hanter à la nuit.
Les microservices sont la première architecture logicielle qui est née en réponse aux pratiques DevOps, visant à rendre nos systèmes plus flexibles, plus évolutifs et à assurer une livraison continue. Comment y parviennent-ils ? En réduisant le volume des services, en diminuant les frontières des problèmes que ces services traitent et en raccourcissant les délais de livraison. Autrement dit, nous réduisons et simplifions les parties du système, augmentons leur nombre, ce qui accroît inévitablement la complexité des interactions entre ces parties, engendrant ainsi de nouveaux problèmes que nous devons résoudre.
Les microservices ne sont pas une fin en soi, ils sont en fait déjà un vestige du passé, car le Serverless arrive. Tous les serveurs ont disparu, il n'y a plus de serveurs, plus de systèmes d'exploitation, seulement du code exécutable pur. Les configurations sont séparées, les états sont séparés, tout est géré par des événements. C'est la beauté, la pureté, le silence, aucun événement, rien ne se passe, tout est en ordre.
Où se situe la complexité ? Il est évident que la complexité réside dans les interactions. Que peut faire une fonction par elle-même ? Comment interagit-elle avec d'autres fonctions ? File de messages, bases de données, équilibreurs de charge. Comment recréer un événement lorsque quelque chose échoue ? Une multitude de questions et peu de réponses.
Les microservices et le Serverless sont tout ce que nous, les hipsters de l'informatique, appelons Cloud Native. Tout tourne autour du cloud. Mais, par essence, le cloud est également limité en termes d'évolutivité. Nous avons tendance à le considérer comme un système distribué. En réalité, où résident les serveurs des fournisseurs de cloud ? Dans des centres de données. Ainsi, nous avons ici un modèle distribué très limité et, pour le moins, centralisé.
Aujourd'hui, nous comprenons que l'internet des objets n'est plus simplement de belles paroles ; selon des prévisions modestes, nous attendons des milliards de dispositifs connectés à Internet dans les cinq à dix prochaines années. Un énorme volume de données, utiles et inutiles, qui sera déversé dans le cloud et en sera extrait.
Le cloud ne pourra pas supporter tout cela, c'est pourquoi nous parlons de plus en plus des ce que l'on appelle le « edge computing ». J'aime aussi cette définition merveilleuse de « fog computing ». Cela apporte une touche de mystère romantique et d'intrigue.
Les calculs brumeux. Il s'agit des nuages, qui sont des agrégats centralisés d'eau, de vapeur, de glace et de pierres. Et le brouillard, ce sont des gouttes d'eau dispersées autour de nous dans l'atmosphère.
Dans la paradigme brumeux, la majeure partie du travail est effectuée par ces gouttes de manière totalement autonome ou en coopération avec d'autres gouttes. Elles ne se tournent vers le nuage que lorsque cela devient vraiment nécessaire.
C'est-à-dire encore une fois décentralisation, autonomie, et bien sûr, beaucoup d'entre vous comprennent déjà où tout cela mène, car on ne peut pas parler de décentralisation sans mentionner la blockchain.
Il y a ceux qui croient, ce sont ceux qui ont investi dans les cryptomonnaies. Il y a ceux qui croient mais qui ont peur, comme moi par exemple. Et il y a ceux qui ne croient pas. On peut avoir différentes opinions à ce sujet. Il y a une technologie, un nouveau domaine incompris, et des problèmes. Comme toute nouvelle technologie, elle soulève plus de questions qu'elle ne donne de réponses.
Le buzz autour de la blockchain est compréhensible. Même si l'on met de côté la ruée vers l'or, la technologie elle-même offre des promesses fantastiques d'un avenir radieux : plus de liberté, plus d'autonomie, une confiance mondiale distribuée. Que pourrait-on vouloir de plus ?
Par conséquent, de plus en plus d'ingénieurs à travers le monde commencent à développer des applications décentralisées. Et c'est une force à laquelle il est impossible d'échapper, en disant simplement : « Ah, la blockchain n'est qu'une base de données distribuée mal implémentée ». Ou comme aiment le dire les sceptiques : « Il n'y a pas d'applications réelles pour la blockchain ». Si l'on y pense, il y a 150 ans, ils disaient la même chose à propos de l'électricité. Et d'une certaine manière, ils avaient raison, car ce que l'électricité rend possible aujourd'hui était totalement irréaliste au XIXe siècle.
Au fait, qui sait quel est le logo à l'écran ? C'est Hyperledger. C'est un projet développé sous l'égide de la Linux Foundation, qui regroupe un ensemble de technologies blockchain. C'est vraiment la force de notre communauté open source.
Ingénierie chaotique
Ainsi, le système que nous développons devient de plus en plus complexe, de plus en plus chaotique, de plus en plus adaptatif. Netflix est un pionnier des systèmes de microservices. Ils ont été parmi les premiers à comprendre cela et ont développé un ensemble d'outils qu'ils ont appelés Simian Army, dont le plus connu est . Cela a défini ce qui est devenu connu comme .
Au fait, lors du travail sur le rapport, nous avons même traduit ce texte en russe, alors n'hésitez pas à visiter , lisez, commentez, critiquez.
En bref, les principes de l'ingénierie de la chaos disent ceci. Les systèmes distribués complexes sont fondamentalement imprévisibles et contiennent intrinsèquement des erreurs. Les erreurs sont inévitables, ce qui signifie que nous devons les accepter et travailler avec ces systèmes d'une manière complètement différente.
Nous devons essayer d'introduire nous-mêmes ces erreurs dans nos systèmes de production pour tester leur adaptabilité, leur capacité d'auto-organisation et de survie.
Et cela change tout. Non seulement la façon dont nous déployons le système en production, mais aussi comment nous les développons et les testons. Il n'y a aucun processus de stabilisation, de gel du code, au contraire, il s'agit d'un processus constant de déstabilisation. Nous essayons de tuer le système et de voir s'il continue de survivre.
Protocoles d'intégration de systèmes distribués
En conséquence, cela exige que nos systèmes changent également d'une certaine manière. Pour qu'ils deviennent plus résilients, ils ont besoin de nouveaux protocoles d'interaction entre leurs parties. Pour que ces parties puissent convenir et parvenir à une certaine auto-organisation. De nouveaux outils, de nouveaux protocoles émergent, que j'appelle «protocoles d'interaction des systèmes distribués».
De quoi je parle ? Tout d'abord, le projet . Une tentative de créer un protocole commun de traçage distribué, qui est un outil absolument indispensable pour le débogage de systèmes distribués complexes.
Ensuite — . Nous disons que nous ne pouvons pas prédire ce qui se passera avec le système, donc nous devons améliorer son observabilité. Opentracing fait partie de la famille d'outils qui fournissent la visibilité de nos systèmes. Mais nous avons besoin de visibilité pour déterminer si le système fonctionne comme nous l'attendons ou non. Comment déterminer le comportement attendu ? En définissant une certaine politique, un ensemble de règles. Le projet Open Policy Agent s'occupe de la définition de cet ensemble de règles sur une large gamme : de l'accès à l'allocation des ressources.
Comme nous l'avons dit, nos systèmes sont de plus en plus gérés par événements. Serverless est un excellent exemple de systèmes gérés par événements. Pour que nous puissions transférer des événements entre les systèmes et les suivre, nous avons besoin d'un langage commun, d'un protocole commun sur la manière dont nous discutons des événements et comment nous les transmettons. C'est ce que fait le projet appelé .
Un flux continu de changements, qui inonde nos systèmes, les déstabilisant constamment, est un flux continu d'artefacts logiciels. Pour que nous puissions maintenir ce flux constant de changements, nous avons besoin d'un protocole commun, grâce auquel nous pourrons discuter de ce qu'est un artefact logiciel, comment il est vérifié, quelle vérification il a subie. C'est ce que fait le projet appelé . Donc, un protocole commun de métadonnées pour les artefacts logiciels.
Enfin, si nous voulons que nos systèmes soient entièrement autonomes, adaptatifs et s'auto-organisent, nous devons leur donner le droit à l'auto-identification. Le projet appelé s'occupe justement de cela. C'est aussi un projet sous l'égide de la Cloud Native Computing Foundation.
Tous ces projets sont jeunes, ils ont tous besoin de notre amour, de notre vérification. Tout cela est du code ouvert, notre test, notre mise en œuvre. Ils nous montrent dans quelle direction la technologie évolue.
Mais DevOps n'a jamais été principalement une question de technologie, il a toujours été avant tout question de collaboration entre les personnes. Et donc, si nous voulons que les systèmes que nous développons changent, nous devons changer nous-mêmes. En réalité, nous changeons déjà, nous n'avons pas vraiment le choix.
Il y a un excellent livre de l'écrivaine britannique Rachel Botsman, dans lequel elle aborde l'évolution de la confiance à travers l'histoire humaine. Elle dit qu'à l'origine, dans les sociétés primitives, la confiance était locale, c'est-à-dire que nous ne faisions confiance qu'à ceux que nous connaissions personnellement.
Ensuite, il y a eu une très longue période — une époque sombre, lorsque la confiance est devenue centralisée, quand nous avons commencé à faire confiance à des personnes que nous ne connaissions pas en nous basant sur notre appartenance à une même institution sociale ou étatique.
Et voici ce que nous voyons dans notre monde moderne : la confiance devient de plus en plus décentralisée et repose sur la liberté des flux d'informations et sur l'accessibilité de l'information.
Si l'on y réfléchit, c'est cette accessibilité même, qui rend cette confiance possible, que nous réalisons. Cela signifie que la façon dont nous collaborons et la manière dont nous le faisons doivent également changer, car les organisations informatiques centralisées et hiérarchiques de l'ancienne école cessent de fonctionner. Elles commencent à disparaître.
Les fondements des organisations DevOps
L'organisation DevOps idéale du futur est un système décentralisé et adaptatif, composé d'équipes autonomes, chacune constituée d'individus autonomes. Ces équipes sont dispersées à travers le monde, elles collaborent efficacement entre elles grâce à une communication asynchrone et à des protocoles d'échange d'informations hautement transparents. C'est très beau, n'est-ce pas ? Un avenir très prometteur.
Bien sûr, tout cela est impossible sans des changements culturels. Nous avons besoin d'un leadership transformationnel, de responsabilité personnelle, de motivation interne.
Voici la base des organisations DevOps : transparence de l'information, communications asynchrones, leadership transformationnel, décentralisation.
L'épuisement professionnel
Les systèmes dont nous faisons partie, et ceux que nous construisons, sont de plus en plus chaotiques, et nous, en tant qu'êtres humains, avons du mal à accepter cette idée, nous peinons à abandonner l'illusion de contrôle. Nous essayons de continuer à les contrôler, et cela conduit souvent à l'épuisement. Je le dis par expérience, j'ai moi aussi connu cela, je suis aussi une victime des pannes imprévues en production.
L'épuisement professionnel survient lorsque nous essayons de contrôler ce qui, par essence, échappe au contrôle. Lorsque nous nous épuisons, tout perd son sens, car nous perdons l'envie de créer quelque chose de nouveau, nous prenons une position défensive et commençons à protéger ce qui existe.
Le métier d'ingénieur, comme j'aime souvent me le rappeler, est avant tout une profession créative. Si nous perdons l'envie de créer quelque chose, nous nous transformons en cendres, nous devenons des résidus. Les gens s'épuisent, des organisations entières s'épuisent.
À mon avis, seule l'acceptation de la puissance créative du chaos, seule la construction d'une collaboration selon ses principes - c'est ce qui nous aidera à ne pas perdre ce qu'il y a de bon dans notre profession.
C'est ce que je vous souhaite : aimer votre travail, aimer ce que nous faisons. Ce monde se nourrit d'informations, nous avons l'honneur de le nourrir. Alors explorons le chaos, devenons des chaosologues, apportons de la valeur, créons quelque chose de nouveau, et les problèmes, comme nous l'avons déjà constaté, sont inévitables. Quand ils se présenteront, nous dirons simplement « Ops ! », et le problème sera résolu.
Que se passe-t-il en dehors de Chaos Monkey ?
En réalité, tous ces outils sont très récents. Même Netflix a construit des outils pour ses propres besoins. Construisez des outils pour vous-même. Lisez les principes de l'ingénierie du chaos et conformez-vous à ces principes, plutôt que de chercher d'autres outils que d'autres ont déjà construits.
Essayez de comprendre comment vos systèmes échouent et commencez à les casser pour observer comment ils résistent aux chocs. C'est avant tout cela. Quant aux outils, il y a plein de projets à explorer.
Je n'ai pas tout à fait compris le moment où vous avez dit que l'on ne doit pas simplifier un système en simplifiant ses composants, pour ensuite enchaîner sur les microservices qui, justement, simplifient le système en simplifiant les composants et compliquant les interactions. Cela représente en fait deux parties qui se contredisent.
C'est tout à fait vrai, les microservices sont un sujet très controversé. En réalité, simplifier les parties augmente la flexibilité. Que nous apportent les microservices ? Ils nous donnent de la flexibilité et de la rapidité, mais ils ne nous apportent aucune simplicité. Ils augmentent la complexité.
Ainsi, dans la philosophie DevOps, les microservices ne sont pas un si grand bien ?
Tout bien a son revers. Il y a des avantages : cela augmente la flexibilité, nous permet d'apporter des modifications plus rapidement, mais cela augmente la complexité et, par conséquent, la fragilité de l'ensemble du système.
En fin de compte, où mettre le plus l'accent : sur la simplification des interactions ou sur celle des parties ?
L'accent est sans aucun doute mis sur la simplification des interactions, car si nous regardons cela à travers le prisme de notre collaboration, il est primordial de privilégier la simplification des interactions plutôt que celle du travail de chacun d'entre nous individuellement. Simplifier le travail, c'est transformer les gens en robots. Cela fonctionne très bien chez McDonald's où il est dicté : ici, on met le burger, là, on verse la sauce. Cela ne marche absolument pas dans notre travail créatif.
Est-il vrai que tout ce que vous avez décrit existe dans un monde sans concurrence, où le chaos est bienveillant, sans contradictions internes, où personne ne veut manger ou tuer personne ? Comment la concurrence et DevOps doivent-elles coexister ?
Eh bien, cela dépend de la concurrence à laquelle nous faisons référence. S'agit-il de la concurrence au sein de l'entreprise ou de la concurrence entre les entreprises ?
De la concurrence entre les services existants, parce que les services ne se limitent pas à quelques entreprises. Nous créons un nouveau type d'environnement informationnel, et tout environnement ne peut exister sans concurrence. La concurrence est omniprésente.
Prenons Netflix comme modèle. Pourquoi ont-ils eu cette idée ? Parce qu'ils avaient besoin d'être compétitifs. Cette flexibilité et rapidité sont justement ces exigences concurrentielles qui apportent du chaos dans nos systèmes. Ainsi, le chaos n'est pas quelque chose que nous créons délibérément parce que nous le désirons, c'est ce qui survient parce que le monde l'exige. Nous devons simplement nous adapter. Et le chaos est précisément le résultat de la concurrence.
Cela signifie-t-il que le chaos est l'absence d'objectifs ? Ou les objectifs que nous ne voulons pas voir ? Nous sommes dans notre bulle et ne comprenons pas les objectifs des autres. La concurrence, en réalité, découle du fait que nous avons des objectifs clairs et savons où nous allons à chaque instant suivant. C'est à mon avis l'essence de DevOps.
C'est une autre perspective. Je pense que notre objectif commun est de survivre et de le faire avec
le plus de plaisir possible. L'objectif concurrentiel de toute organisation est le même. La survie se déroule souvent dans la lutte concurrentielle, c'est inévitable.
Cette année la conférence aura lieu le 7 décembre au « Technopolis ». Nous acceptons les soumissions de présentations jusqu'au 11 novembre. si vous souhaitez prendre la parole.
Les inscriptions pour les participants sont ouvertes, le billet coûte 7000 roubles. Rejoignez-nous !
Source : habr.com
