Get best of the week

Ingénierie de la résilience: notes de la conférence REDeploy



Alors que les conférences du monde entier recherchent des formats optimaux en ligne, il est temps de se rappeler comment elles (et nous tous) vivions à l'époque pré-virale. À la fin de l'année dernière, j'ai assisté à la conférence REDeploy 2019 consacrée à l'ingénierie de la résilience. Pendant très longtemps, j'ai essayé de comprendre comment traduire ce terme en russe, jusqu'à ce que je découvre qu'il a longtemps été utilisé dans des niches non écrites - comme «l'ingénierie de la résilience». De plus, il serait nécessaire d'écrire une définition de la résilience, mais il est difficile de le faire avec une simple phrase. Il s'est également avéré que les sujets soulevés il y a six mois sont très pertinents dans notre nouvelle réalité.

Tout d'abord, il est important de comprendre que l'ingénierie de la résilience est un domaine scientifique interdisciplinaire, qui vise la recherche, la formalisation et la formation de pratiques qui augmentent la capacité des systèmes socio-techniques complexes à se préparer à des situations inhabituelles et des accidents, à s'y adapter et à améliorer leurs capacités adapter.

Pendant de nombreuses années, l'image mécanique du monde a prévalu dans le processus de développement de logiciels - la conviction que nous sommes en mesure de développer des logiciels qui fonctionneront sans plantages, et si un accident se produit, il aura une cause profonde, qui peut être corrigée prévenir la réapparition de telles erreurs à l'avenir - et donc, puisque le nombre d'erreurs est bien sûr, en fin de compte, corriger toutes les erreurs qui entraînent des accidents (voir excellent articleDev, Ops et déterminisme à ce sujet).

La même approche «d'ingénierie» est également appliquée à la façon dont les gens interagissent pendant un accident: il suffit de créer des outils, en utilisant lesquels les gens peuvent résoudre le problème (tout en évitant les erreurs).

Mais le hic, c'est que le logiciel continue d'être mis à jour, il devient complexe, fragmenté et ramifié, et les accidents qui se produisent n'ont pas une seule raison (de plus, ils peuvent même être localisés en dehors du système), et les personnes en cours de communication pour corriger cet accident peuvent commettre des erreurs.

Ainsi, la tâche n'est pas presque impossible d'éviter les erreurs et les accidents dans le système, mais de préparer les personnes et le système afin qu'un accident potentiel ait le moins d'impact sur le système, ses utilisateurs et ses créateurs.

Le développement de logiciels est resté longtemps à l'écart des autres disciplines de l'ingénierie "hors ligne", alors que la pratique de la "réduction des risques" des accidents y est utilisée depuis longtemps. Et ces pratiques sont plus susceptibles de concerner les personnes que les services publics et les solutions techniques pour prévenir les accidents.

Les questions posées par l'ingénierie de la résilience sont donc les suivantes:
  1. Quelles caractéristiques culturelles et sociales de l'interaction des personnes devraient être prises en compte afin de mieux comprendre ce qui peut et ne peut pas se produire dans la communication des personnes en cas d'accident? Comment améliorer le processus d'adaptation et de communication? Et vice versa, comment aggraver la situation?
  2. Quelles connaissances d'autres disciplines pouvons-nous appliquer afin de rendre le système plus flexible et stable en cas d'accident?
  3. Comment organiser l'entraînement et l'interaction humaine pour qu'en cas d'accident, les dégâts et le stress, pour ceux qui l'élimineront, soient les moins importants?
  4. Quelles solutions techniques, quelles pratiques peuvent être appliquées pour cela? Comment, par des actions conscientes, pouvons-nous augmenter la stabilité du système et son adaptabilité aux accidents?


À ce sujet était la conférence. Et ci-dessous - ce dont certains orateurs ont parlé.

Quelques observations sur la merveilleuse résilience de l'os et l'ingénierie de la résilience. Richard Cook


Tout d'abord, il faut dire à propos de la personne de l'orateur. Richard Cook est médecin, scientifique et l'un des principaux «vulgarisateurs» de l'ingénierie de la résilience informatique. Avec David Woods et John Olspau (la personne qui a réellement lancé DevOps comme référence), il a cofondé Adaptive Capacity Labs, une entreprise qui met en œuvre l'ingénierie de la durabilité dans d'autres organisations.

Il convient de noter que REDeploy n'est pas une conférence informatique, et ce rapport en est un exemple frappant.

La majeure partie du rapport est une analyse détaillée de la façon dont l'os brisé guérit, dont la guérison est un archétype de résilience. Les os eux-mêmes ne sont pas fusionnés correctement. La médecine a étudié comment traiter les fractures, en comprenant le processus de guérison. En fait, la médecine ne traite même pas l'os lui-même, elle crée des processus qui favorisent la guérison.

En général, l'historique du traitement peut être divisé en deux directions:
  • traitement comme un processus qui crée les conditions les plus favorables à la cicatrisation osseuse (dans le processus de traitement, nous appliquons du gypse pour que l'os ne bouge pas).
  • le traitement comme un processus «d'amélioration» du processus de guérison (comprendre - au niveau biochimique - comment se déroule le processus de guérison, nous utilisons des médicaments qui l'accélèrent).


Et ici, la thèse principale est en fait «programmatique» pour toute la discipline du rapport: pourquoi faut-il comprendre comment les processus sociotechniques se produisent lors d'un accident?

En comprenant le fonctionnement du mécanisme de «traitement» (par exemple, la résolution d'une urgence), nous pouvons au moins organiser des conditions si favorables que l'accident cause un minimum de dommages et, au maximum, accélère le processus de résolution de l'accident. Nous ne pouvons pas empêcher les cas où une personne se casse un os, mais nous pouvons améliorer le processus de guérison.

L'art d'embrasser l'échec à grande échelle. Adrian hornsby


Et maintenant, un rapport technique sur l'évolution de la tolérance aux pannes dans l'infrastructure AWS.
Sans entrer dans les détails techniques (vous pouvez les voir dans la présentation ), nous considérerons la thèse principale du rapport. AWS, dans le processus de construction de divers systèmes, développe l'architecture en tenant compte du fait qu'un accident peut survenir tôt ou tard et, en conséquence, l'architecture du système doit être conçue de manière à limiter le "rayon d'explosion" en cas d'accident. Par exemple, les bases de données clientes, les stockages sont divisés en groupes de "cellules" et la charge créée par un client affecte uniquement les utilisateurs de cette cellule. Les clients des répliques de cellules ne dupliquent pas les cellules principales, mais sont mélangés ensemble, limitant ainsi le rayon d'impact au minimum.







En augmentant le nombre de ces combinaisons, nous réduisons le risque d'implication des clients en cas d'impact.



Se sentir bien sous l'eau. Ronnie chen


Un rapport d'un gestionnaire Twitter ayant de l'expérience en plongée technique en haute mer sur les caractéristiques de sécurité pendant la plongée.

La plongée en équipe est un travail à haut risque. Et si l'organisation de ces plongées procède de la possibilité de plonger uniquement dans le cas d'un nivellement complet de ces risques - il n'y aura pas de plongées en haute mer du tout. D'une manière ou d'une autre, des problèmes peuvent survenir, et c'est normal - le locuteur dans son ensemble compare la prise de risques consciente comme méthode de développement du potentiel humain. Si nous atténuons les risques, cela limitera notre potentiel. La tâche, encore une fois, est d'organiser la résolution la plus simple des situations au cas où ces risques se réaliseraient.

Comment pouvez-vous essayer de vivre avec la pression qui pèse sur l'équipe en cas d'activités risquées?

Un exemple des règles d'interaction d'une équipe de plongeurs:
  • Communication fiable et constante entre les participants et sécurité psychologique maximale: chaque membre de l'équipe doit se sentir en sécurité, tout participant à la plongée peut arrêter de plonger à tout moment (et les charges sont interdites).
  • Acceptation des erreurs. Toute personne peut faire des erreurs et les erreurs sont inévitables dans le processus de travail; blâmer les erreurs est également inacceptable.
  • L'équipe peut redéfinir les objectifs du projet et déterminer le succès du projet dans le processus de plongée en fonction des conditions changeantes.
  • , .
  • — . , , .
  • ( ) , root cause ( ), , .


The Practice of Practice: Teamwork in Complexity. Matt Davis


En cas d'accident, les ingénieurs sont largement intuitifs et l'intuition du rapport est comparée à l'improvisation musicale. L'improvisation est un processus de lecture intuitive de la musique, mais cette intuition se fonde sur l'expérience - la connaissance des gammes musicales, l'expérience de l'improvisation précédente, le travail d'équipe. De plus, il s'agit d'un processus bidirectionnel: l'intuition est construite sur l'expérience, et les processus sont construits sur l'analyse des actions intuitives (en musique - les notes d'une composition composée sont écrites, dans les technologies - le processus de correction d'un accident est décrit).

Deux façons d'enseigner / former l'intuition:
- L'autopsie n'est pas un moyen de blâmer ou de prévenir les problèmes à l'avenir, mais un moyen de formation et un moyen de partager l'expérience. Partagez régulièrement votre expérience en matière de résolution d'accidents sous la forme d'un rapport d'autopsie / d'accident afin de partager votre expérience de résolution de problèmes avec d'autres personnes.
- Chaos Engineering comme moyen de générer de l'expérience dans un environnement contrôlé. En créant artificiellement un accident dans le système qui doit être résolu, nous formons l'expérience de l'intuition avec les ingénieurs qui géreront sa solution. Dans le même temps, nous pouvons déterminer la pile nécessaire dans laquelle nous voulons développer des compétences en limitant le rayon de l'impact dans le système.

Voici les rapports les plus mémorables pour moi. Il me semble que ce sont des choses très utiles en ce moment, quand il peut sembler qu'en général toute la réalité s'est effondrée, «en porter une autre». Peut-être que certains points vous aideront à regarder la réalité et les accidents sous un nouvel angle.

Et je suis un peu plus régulier que le blog ici, je garde ma chaîne de télégramme , abonnez-vous :-)

More articles:


All Articles