Anton Weiss, fondateur et directeur d'Otomato Software, l'un des initiateurs et instructeurs de la première certification DevOps en Israël, a pris la parole lors de la conférence de l'année dernière. sur la théorie du chaos et les grands principes de l'ingénierie du chaos, et a également expliqué comment fonctionne 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, c'est ma deuxième fois sur cette scène, vous êtes nombreux dans cette salle pour la deuxième fois. Qu'est-ce que ça veut dire? Cela signifie que le mouvement DevOps en Russie se développe, se multiplie et, surtout, cela signifie que le moment est venu de parler de ce qu'est le DevOps en 2018.
Levez la main qui pense que DevOps est déjà un métier en 2018 ? Il y en a. Y a-t-il des ingénieurs DevOps dans la salle dont la description de poste indique « Ingénieur DevOps » ? Y a-t-il des responsables DevOps dans la salle ? Il n'y a pas de. Architectes DevOps ? Aussi non. Pas assez. Est-il vraiment vrai que personne ne se dit ingénieur DevOps ?
Donc la plupart d’entre vous pensent qu’il s’agit d’un anti-modèle ? Qu'une telle profession ne devrait pas exister ? Nous pouvons penser ce que nous voulons, mais pendant que nous réfléchissons, l’industrie avance solennellement au son de la trompette DevOps.
Qui a entendu parler d'un nouveau sujet appelé DevDevOps ? Il s'agit d'une nouvelle technique qui permet une collaboration efficace entre les développeurs et les développeurs. Et pas si nouveau. À en juger par Twitter, ils ont déjà commencé à en parler il y a 4 ans. Et jusqu'à présent, l'intérêt pour cela ne cesse de croître, c'est-à-dire qu'il y a un problème. Le problème doit être résolu.
Nous sommes des gens créatifs, nous ne restons pas tranquilles. Nous disons : DevOps n’est pas un mot assez complet ; il lui manque encore toutes sortes d’éléments différents et intéressants. Et nous allons dans nos laboratoires secrets et commençons à produire des mutations intéressantes : DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.
La logique est à toute épreuve, non ? Notre système de livraison n'est pas fonctionnel, nos systèmes sont instables et nos utilisateurs sont insatisfaits, nous n'avons pas le temps de déployer les logiciels à temps, nous ne respectons pas le budget. Comment allons-nous résoudre tout cela ? Nous trouverons un nouveau mot ! Cela se terminera par "Ops" et le problème sera résolu.
J'appelle donc cette approche : « Ops, et le problème est résolu ».
Tout cela passe au second plan si nous nous rappelons pourquoi nous avons imaginé tout cela. Nous avons imaginé toute cette histoire DevOps pour rendre la livraison de logiciels et notre propre travail dans ce processus aussi fluides, indolores, efficaces et, surtout, agréables que possible.
DevOps est né de la douleur. Et nous sommes fatigués de souffrir. Et pour que tout cela se produise, nous nous appuyons sur des pratiques persistantes : une collaboration efficace, des pratiques de flux et, surtout, une pensée systémique, car sans elle, aucun DevOps ne fonctionne.
Qu'est-ce qu'un système ?
Et si nous parlons déjà de pensée systémique, rappelons-nous ce qu’est un système.
Si vous êtes un hacker révolutionnaire, alors pour vous, le système est clairement mauvais. C'est un nuage qui pèse sur vous et vous oblige à faire des choses que vous ne voulez pas faire.
Du point de vue de la pensée systémique, un système est un tout composé 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 vous et moi construisons s’appelle un système.
Tout cela fait partie d’un grand système socio-technologique. Et ce n’est que si nous comprenons comment ce système socio-technologique fonctionne ensemble que nous pourrons véritablement optimiser quelque chose dans ce domaine.
Du point de vue de la pensée systémique, un système possède diverses propriétés intéressantes. Premièrement, il est constitué de pièces, ce qui signifie que son comportement dépend du comportement des pièces. De plus, toutes ses parties sont également interdépendantes. Il s’avère que plus un système comporte de composants, plus il est difficile de comprendre ou de prédire son comportement.
D’un point de vue comportemental, il existe un autre fait intéressant. Le système peut faire quelque chose qu’aucune de ses parties individuelles ne peut faire.
Comme l’a dit le Dr Russell Ackoff (l’un des fondateurs de la pensée systémique), cela est assez facile à prouver par une expérience de pensée. Par exemple, qui dans la salle sait écrire du code ? Il y a beaucoup de mains, et c'est normal, car c'est l'une des principales exigences de notre métier. Savez-vous écrire, mais vos mains peuvent-elles écrire du code séparément de vous ? Il y a des gens qui diront : « Ce ne sont pas mes mains qui écrivent le code, c’est mon cerveau qui écrit le code ». Votre cerveau peut-il écrire du code séparément de vous ? Eh bien, probablement pas.
Le cerveau est une machine étonnante, on ne connaît 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 est facile à prouver : ouvrez votre crâne, sortez votre cerveau, placez-le devant l'ordinateur, laissez-le essayer d'écrire quelque chose de simple. "Bonjour le monde" en Python, par exemple.
Si un système peut faire quelque chose qu’aucune de ses parties ne peut faire séparément, cela signifie que son comportement n’est pas déterminé par le comportement de ses parties. Par quoi est-il alors déterminé ? Elle est déterminée par l'interaction entre ces parties. Et par conséquent, plus il y a de pièces, plus les interactions sont complexes, plus il est difficile de comprendre et de prédire le comportement du système. Et cela rend un tel système chaotique, car tout changement invisible, même le plus insignifiant, dans n'importe quelle partie du système peut conduire à des résultats complètement 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 Ed Lorenz. Par la suite, on l’a appelé « l’effet papillon » et a conduit au développement d’un mouvement de pensée scientifique appelé « théorie du chaos ». Cette théorie est devenue l’un des changements de paradigme majeurs dans la science du XXe siècle.
Théorie du chaos
Les gens qui étudient le chaos s’appellent des chaosologues.
En fait, la raison de ce rapport était qu'en travaillant avec des systèmes distribués complexes et de grandes organisations internationales, j'ai réalisé à un moment donné que c'était ce que je ressens. Je suis un chaosologue. C’est en fait une façon intelligente de dire : « Je ne comprends pas ce qui se passe ici et je ne sais pas quoi faire. »
Je pense que beaucoup d’entre vous ressentent souvent cela aussi, c’est pourquoi vous êtes aussi des chaosologues. Je vous invite à la guilde des chaosologues. Les systèmes que vous et moi, 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 éléments d'un tel système adaptatif change et s'auto-organise, en réponse à des événements ou à des chaînes de micro-événements dans le système. Autrement dit, le système s’adapte aux changements grâce à l’auto-organisation. Et cette capacité d’auto-organisation repose sur la coopération volontaire et totalement décentralisée d’agents libres et autonomes.
Une autre propriété intéressante de ces systèmes est qu’ils sont librement évolutifs. Ce qui devrait sans doute nous intéresser, en tant que chaosologues-ingénieurs. Donc, si nous disons que le comportement d'un système complexe est déterminé par l'interaction de ses parties, alors à quoi devrions-nous nous intéresser ? Interaction.
Il y a deux autres découvertes intéressantes.
Premièrement, nous comprenons qu’un système complexe ne peut pas être simplifié en simplifiant ses parties. Deuxièmement, la seule façon de simplifier un système complexe est de simplifier les interactions entre ses parties.
Comment interagissons-nous ? Vous et moi faisons tous partie d’un vaste système d’information appelé société humaine. Nous interagissons à travers un langage commun, si nous l'avons, si nous le trouvons.
Mais le langage lui-même est un système adaptatif complexe. Par conséquent, afin d'interagir plus efficacement et plus simplement, nous devons créer une sorte de 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 complexité, à l’adaptabilité, à la décentralisation, au chaos se retrouvent partout. Et dans les systèmes que vous et moi construisons, et dans les systèmes dont nous faisons partie.
Et pour ne pas être sans fondement, regardons comment les systèmes que nous créons évoluent.
Vous attendiez ce mot, je comprends. Nous sommes à une conférence DevOps, aujourd'hui ce mot sera entendu environ cent mille fois et ensuite nous en rêverons la nuit.
Les microservices sont la première architecture logicielle apparue en réaction aux pratiques DevOps, conçue pour rendre nos systèmes plus flexibles, plus évolutifs et garantir une livraison continue. Comment fait-elle cela? En réduisant le volume des services, en réduisant l'étendue des problèmes que ces services traitent, en réduisant les délais de livraison. Autrement dit, nous réduisons et simplifions les parties du système, augmentons leur nombre et, par conséquent, la complexité des interactions entre ces parties augmente invariablement, c'est-à-dire que de nouveaux problèmes surgissent que nous devons résoudre.
Les microservices ne sont pas la fin, les microservices sont, en général, déjà hier, car le sans serveur arrive. Tous les serveurs ont brûlé, pas de serveurs, pas de systèmes d'exploitation, juste du pur code exécutable. Les configurations sont séparées, les états sont séparés, tout est contrôlé par des événements. Beauté, propreté, silence, aucun événement, rien ne se passe, ordre complet.
Où est la complexité ? La difficulté, bien sûr, réside dans les interactions. Que peut faire une fonction à elle seule ? Comment interagit-il avec les autres fonctions ? Files d'attente de messages, bases de données, équilibreurs. Comment recréer un événement lorsqu'une panne s'est produite ? Beaucoup de questions et peu de réponses.
Les microservices et le sans serveur sont ce que nous, les hipsters geek, appelons Cloud Native. Tout tourne autour du cloud. Mais le cloud est également intrinsèquement limité en termes d’évolutivité. Nous sommes habitués à le considérer comme un système distribué. En fait, où résident les serveurs des fournisseurs de cloud ? Dans les centres de données. Autrement dit, nous avons ici une sorte de modèle centralisé, très limité et distribué.
Aujourd'hui, nous comprenons que l'Internet des objets n'est plus que de grands mots et que même selon de modestes prévisions, des milliards d'appareils connectés à Internet nous attendent dans les cinq à dix prochaines années. Une énorme quantité de données utiles et inutiles qui seront fusionnées dans le cloud et téléchargées depuis le cloud.
Le cloud ne durera pas, c'est pourquoi nous parlons de plus en plus de ce qu'on appelle l'informatique de pointe. Ou j’aime aussi la merveilleuse définition du « fog computing ». Il est enveloppé du mysticisme du romantisme et du mystère.
Calcul du brouillard. Le fait est que les nuages sont des amas centralisés d’eau, de vapeur, de glace et de pierres. Et le brouillard est constitué de gouttelettes d'eau qui se dispersent autour de nous dans l'atmosphère.
Dans le paradigme du brouillard, la majeure partie du travail est effectuée par ces gouttelettes de manière totalement autonome ou en collaboration avec d’autres gouttelettes. Et ils ne se tournent vers le cloud que lorsqu’ils sont vraiment pressés.
C’est-à-dire encore une fois la décentralisation, l’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 évoquer 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. Ici, vous pouvez traiter différemment. Il y a de la technologie, une nouvelle inconnue, il y a des problèmes. Comme toute nouvelle technologie, elle soulève plus de questions qu’elle n’en répond.
Le battage médiatique autour de la blockchain est compréhensible. Mis à part la ruée vers l’or, la technologie elle-même recèle des promesses remarquables pour un avenir meilleur : plus de liberté, plus d’autonomie, une confiance mondiale distribuée. Qu'est-ce qu'il ne faut pas vouloir ?
En conséquence, de plus en plus d’ingénieurs du monde entier commencent à développer des applications décentralisées. Et c’est un pouvoir qui ne peut être écarté en disant simplement : « Ahh, 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 de véritables applications pour la blockchain. » Si vous y réfléchissez bien, il y a 150 ans, on disait la même chose à propos de l’électricité. Et ils avaient même raison à certains égards, car ce que l’électricité rend possible aujourd’hui ne l’était en aucun cas au XIXe siècle.
Au fait, qui sait quel type de logo se trouve sur l’écran ? C'est Hyperledger. Il s'agit d'un projet développé sous les auspices de la Linux Foundation et comprenant un ensemble de technologies blockchain. C’est véritablement la force de notre communauté open source.
Ingénierie du chaos
Ainsi, le système que nous développons devient de plus en plus complexe, de plus en plus chaotique et de plus en plus adaptatif. Netflix est un pionnier des systèmes de microservices. Ils furent parmi les premiers à comprendre cela, ils développèrent un ensemble d'outils qu'ils appelèrent Armée Simienne, dont le plus célèbre était . Il a défini ce qui est devenu connu sous le nom .
D'ailleurs, en travaillant sur le rapport, nous avons même traduit ce texte en russe, alors allez sur , lire, commenter, gronder.
En bref, les principes de l’ingénierie du chaos disent ce qui suit. Les systèmes distribués complexes sont intrinsèquement imprévisibles et bogués. 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 nous-mêmes essayer d’introduire ces erreurs dans nos systèmes de production afin de tester nos systèmes sur cette même adaptabilité, cette même capacité d’auto-organisation, de survie.
Et ça change tout. Non seulement la façon dont nous lançons les systèmes en production, mais aussi la façon dont nous les développons et dont nous les testons. Il n’y a pas de processus de stabilisation ou de gel du code ; au contraire, il y a un processus constant de déstabilisation. Nous essayons de tuer le système et de le voir continuer à survivre.
Protocoles d'intégration de systèmes distribués
Par conséquent, cela nécessite que nos systèmes changent d’une manière ou d’une autre. Pour qu’ils deviennent plus stables, ils ont besoin de nouveaux protocoles d’interaction entre leurs parties. Pour que ces parties puissent s’entendre et parvenir à une sorte d’auto-organisation. Et toutes sortes de nouveaux outils, de nouveaux protocoles apparaissent, que j'appelle « protocoles pour l'interaction des systèmes distribués ».
De quoi je parle ? Tout d'abord, le projet . Certains tentent de créer un protocole général de suivi distribué, qui constitue un outil absolument indispensable pour déboguer des systèmes distribués complexes.
Plus loin - . Nous disons que nous ne pouvons pas prédire ce qui arrivera au système, c'est-à-dire que nous devons augmenter son observabilité, son observabilité. Opentracing appartient à une famille d'outils qui donnent de l'observabilité à nos systèmes. Mais nous avons besoin d’observabilité pour déterminer si le système se comporte comme prévu ou non. Comment définir le comportement attendu ? En définissant une sorte de politique, un ensemble de règles. Le projet Open Policy Agent s'efforce de définir cet ensemble de règles sur un spectre allant de l'accès à l'allocation des ressources.
Comme nous l'avons dit, nos systèmes sont de plus en plus axés sur les événements. Le sans serveur est un excellent exemple de systèmes pilotés par événements. Pour pouvoir transférer des événements entre systèmes et les suivre, nous avons besoin d'un langage commun, d'un protocole commun sur la façon dont nous parlons des événements, comment nous les transmettons les uns aux autres. C'est ce qu'un projet appelé .
Le flux constant de changements qui inonde nos systèmes et les déstabilise constamment est un flux continu d’artefacts logiciels. Afin de maintenir ce flux constant de changements, nous avons besoin d'une sorte de protocole commun grâce auquel nous pouvons parler de ce qu'est un artefact logiciel, comment il est testé, quelle vérification il a réussi. C'est ce qu'un projet appelé . Il s'agit d'un protocole de métadonnées commun pour les artefacts logiciels.
Et enfin, si nous voulons que nos systèmes soient complètement indépendants, adaptatifs et auto-organisés, nous devons leur donner le droit à l’auto-identification. Projet appelé C'est exactement ce qu'il fait. Il s'agit également d'un projet sous les auspices de la Cloud Native Computing Foundation.
Tous ces projets sont jeunes, ils ont tous besoin de notre amour, de notre validation. Tout cela est open source, nos tests, notre implémentation. Ils nous montrent où va la technologie.
Mais DevOps n’a jamais été principalement une question de technologie, il a toujours été une question de collaboration entre les personnes. Et, par conséquent, si nous voulons que les systèmes que nous développons changent, alors nous devons nous-mêmes changer. En fait, nous changeons de toute façon ; nous n’avons pas vraiment le choix.
Il y a un merveilleux L'écrivain britannique Rachel Botsman, dans lequel elle écrit sur l'évolution de la confiance tout au long de l'histoire de l'humanité. Elle dit qu’au départ, dans les sociétés primitives, la confiance était locale, c’est-à-dire que nous ne faisions confiance qu’à ceux que nous connaissons personnellement.
Ensuite, il y a eu une très longue période – une période sombre où la confiance était centralisée, où nous avons commencé à faire confiance à des personnes que nous ne connaissions pas sur la base du fait que nous appartenions à la même institution publique ou étatique.
Et c'est ce que nous constatons dans notre monde moderne : la confiance est de plus en plus distribuée et décentralisée, et elle repose sur la liberté des flux d'informations, sur la disponibilité de l'information.
Si vous y réfléchissez, cette accessibilité même, qui rend cette confiance possible, est ce que vous et moi mettons en œuvre. Cela signifie que la façon dont nous collaborons et la manière dont nous le faisons doivent changer, car les anciennes organisations informatiques centralisées et hiérarchiques ne fonctionnent plus. Ils commencent à mourir.
Fondamentaux de l'organisation DevOps
L’organisation DevOps idéale du futur est un système décentralisé et adaptatif composé d’équipes autonomes, chacune composée d’individus autonomes. Ces équipes sont dispersées dans le monde entier et collaborent efficacement entre elles grâce à une communication asynchrone et à des protocoles de communication hautement transparents. Très beau, n'est-ce pas ? Un très bel avenir.
Bien entendu, rien de tout cela n’est possible sans un changement culturel. Nous devons avoir un leadership transformationnel, une responsabilité personnelle, une motivation interne.
C'est la base des organisations DevOps : transparence de l'information, communications asynchrones, leadership transformationnel, décentralisation.
Burnout
Les systèmes dont nous faisons partie et ceux que nous construisons sont de plus en plus chaotiques, et il est difficile pour nous, les humains, de faire face à cette pensée, il est difficile d'abandonner l'illusion du contrôle. Nous essayons de continuer à les contrôler, ce qui conduit souvent au burn-out. Je dis cela de ma propre expérience, j'ai aussi été brûlé, j'ai également été handicapé par des échecs imprévus de production.
L’épuisement professionnel survient lorsque nous essayons de contrôler quelque chose qui est intrinsèquement incontrôlable. Lorsque nous nous épuisons, tout perd son sens car nous perdons l’envie de faire quelque chose de nouveau, nous nous mettons sur la défensive et commençons à défendre ce que nous avons.
Le métier d’ingénieur, comme j’aime souvent me le rappeler, est avant tout un métier de création. Si nous perdons le désir de créer quelque chose, alors nous nous transformons en cendres, nous nous transformons en cendres. Les gens s’épuisent, des organisations entières s’épuisent.
À mon avis, c'est seulement en acceptant le pouvoir créateur du chaos, en construisant une coopération selon ses principes, que nous ne perdrons pas ce qu'il y a de bon dans notre profession.
C'est ce que je vous souhaite : aimer votre métier, aimer ce que nous faisons. Ce monde se nourrit d’informations, nous avons l’honneur de le nourrir. Alors étudions le chaos, soyons des chaosologues, apportons de la valeur, créons quelque chose de nouveau, eh bien, les problèmes, comme nous l'avons déjà découvert, sont inévitables, et quand ils apparaissent, nous dirons simplement « Ops ! » Et le problème est résolu.
Quoi d'autre que Chaos Monkey ?
En fait, tous ces instruments sont si jeunes. Le même Netflix a créé des outils pour lui-même. Créez vos propres outils. Lisez les principes de l'ingénierie du chaos et respectez ces principes plutôt que d'essayer de trouver d'autres outils que quelqu'un d'autre a déjà construit.
Essayez de comprendre comment vos systèmes tombent en panne, commencez à les décomposer et voyez comment ils résistent. Cela vient en premier. Et vous pouvez rechercher des outils. Il existe toutes sortes de projets.
Je n'ai pas bien compris le moment où vous avez dit que le système ne peut pas être simplifié en simplifiant ses composants, et je suis immédiatement passé aux microservices, qui simplifient le système en simplifiant les composants eux-mêmes et en compliquant les interactions. Ce sont essentiellement deux parties qui se contredisent.
C'est vrai, les microservices sont un sujet très controversé en général. En fait, simplifier les pièces augmente la flexibilité. Que fournissent les microservices ? Ils nous apportent flexibilité et rapidité, mais ils ne nous apportent certainement pas de simplicité. Ils augmentent la difficulté.
Alors, dans la philosophie DevOps, les microservices ne sont pas une si bonne chose ?
Tout bien a un revers. L’avantage est que cela augmente la flexibilité, nous permettant d’effectuer des changements plus rapidement, mais cela augmente la complexité et donc la fragilité de l’ensemble du système.
Pourtant, qu’est-ce qui met davantage l’accent : sur la simplification de l’interaction ou sur la simplification des parties ?
L'accent est bien sûr mis sur la simplification des interactions, car si nous envisageons cela du point de vue de la façon dont nous travaillons avec vous, nous devons tout d'abord prêter attention à la simplification des interactions, et non à la simplification du travail. de chacun de nous séparément. Parce que simplifier le travail, c’est se transformer en robots. Ici chez McDonald's ça marche normalement quand on a des consignes : ici on met le burger, là on verse la sauce dessus. Cela ne fonctionne pas du tout dans notre travail créatif.
Est-il vrai que tout ce que vous avez dit vit dans un monde sans concurrence, et que le chaos y est si gentil, et qu'il n'y a aucune contradiction dans ce chaos, que personne ne veut manger ou tuer qui que ce soit ? Comment la concurrence et le DevOps doivent-ils se comporter ?
Eh bien, cela dépend du type de compétition dont nous parlons. S’agit-il de concurrence sur le lieu de travail ou de concurrence entre entreprises ?
A propos de la concurrence des services qui existe parce que les services ne sont pas plusieurs entreprises. Nous créons un nouveau type d’environnement informationnel, et aucun environnement ne peut vivre sans concurrence. Il y a de la concurrence partout.
Le même Netflix, nous les prenons comme modèle. Pourquoi ont-ils inventé ça ? Parce qu'ils avaient besoin d'être compétitifs. Cette flexibilité et cette rapidité de mouvement constituent précisément l’exigence la plus concurrentielle ; elles introduisent le chaos dans nos systèmes. Autrement dit, le chaos n’est pas quelque chose que nous faisons consciemment parce que nous le voulons, c’est quelque chose qui se produit parce que le monde l’exige. Nous devons juste nous adapter. Et le chaos, c’est justement le résultat de la compétition.
Cela signifie-t-il que le chaos est, pour ainsi dire, l’absence d’objectifs ? Ou ces objectifs que nous ne voulons pas voir ? Nous sommes à la maison et ne comprenons pas les objectifs des autres. La concurrence, en fait, est due au fait que nous avons des objectifs clairs et que nous savons où nous aboutirons à chaque instant. C’est, de mon point de vue, l’essence du DevOps.
Jetez également un œil à la question. Je pense que nous avons tous le même objectif : survivre et y parvenir avec
le plus grand plaisir. Et l’objectif concurrentiel de toute organisation est le même. La survie passe souvent par la compétition, on ne peut rien y faire.
La conférence de cette année aura lieu le 7 décembre à Technopolis. Nous acceptons les demandes de rapports jusqu'au 11 novembre. nous si vous souhaitez parler.
L'inscription des participants est ouverte, les billets coûtent 7000 XNUMX roubles. Rejoignez-nous!
Source: habr.com