Get best of the week

Resilience Engineering: Notizen von der REDeploy-Konferenz



Während Konferenzen auf der ganzen Welt online nach optimalen Formaten suchen, ist es an der Zeit, sich daran zu erinnern, wie sie (und wir alle) in der vorviralen Ära gelebt haben. Ende letzten Jahres nahm ich an der REDeploy 2019- Konferenz zum Thema Resilience Engineering teil. Ich habe sehr lange versucht zu verstehen, wie man diesen Begriff ins Russische übersetzt, bis ich herausfand, dass der Begriff seit langem in ungeschriebenen Nischen verwendet wird - wie zum Beispiel "Engineering of Resilience". Ferner wäre es notwendig, eine Definition der Belastbarkeit zu schreiben, aber es ist schwierig, dies mit einem einfachen Satz zu tun. Es stellte sich auch heraus, dass die vor sechs Monaten angesprochenen Themen in unserer neuen Realität sehr relevant sind.

Zunächst ist es wichtig zu verstehen, dass Resilience Engineering ein interdisziplinäres Gebiet der Wissenschaft ist, das auf die Erforschung, Formalisierung und Bildung von Praktiken abzielt, die die Fähigkeit komplexer sozio-technischer Systeme verbessern, auf ungewöhnliche Situationen und Unfälle vorbereitet zu sein, sich an diese anzupassen und ihre Fähigkeiten zu verbessern anpassen.

Viele Jahre lang herrschte im Softwareentwicklungsprozess das mechanische Bild der Welt vor - die Überzeugung, dass wir in der Lage sind, Software zu entwickeln, die ohne Abstürze funktioniert, und im Falle eines Unfalls eine Grundursache hat, die behoben werden kann um zu verhindern, dass solche Fehler in Zukunft erneut auftreten - und daher, da die Anzahl der Fehler natürlich am Ende liegt, alle Fehler zu korrigieren, die zu Unfällen führen (siehe ausgezeichneten Artikel)Dev, Ops und Determinismus darüber).

Der gleiche „Engineering“ -Ansatz wird auch auf die Interaktion von Personen während eines Unfalls angewendet: Es reicht aus, einige Tools zu erstellen, mit denen Personen das Problem beheben können (ohne Fehler zu machen).

Der Haken ist jedoch, dass die Software weiterhin aktualisiert wird, komplex, fragmentiert und verzweigt wird und die auftretenden Unfälle keinen einzigen Grund haben (außerdem können sie sich sogar außerhalb des Systems befinden), und dass Personen, die sich im Kommunikationsprozess befinden, um diesen Unfall zu korrigieren, sich verpflichten können Fehler.

Daher ist es praktisch nicht unmöglich, Fehler und Unfälle im System zu vermeiden, sondern Personen und das System so vorzubereiten, dass ein potenzieller Unfall die geringsten Auswirkungen auf das System, seine Benutzer und Urheber hat.

Die Softwareentwicklung blieb lange Zeit fern von anderen "Offline" -Diplomdisziplinen, während die Praxis der "Schadensminderung" durch Unfälle dort seit langem angewendet wird. Und diese Praktiken beziehen sich eher auf Menschen als auf Versorgungsunternehmen und technische Lösungen, um Unfälle zu vermeiden.

Die Fragen, die von der technischen Belastbarkeit gestellt werden, lauten daher wie folgt:
  1. Welche kulturellen und sozialen Merkmale der Interaktion von Menschen sollten berücksichtigt werden, um besser zu verstehen, was bei der Kommunikation von Menschen im Verlauf eines Unfalls passieren kann und was nicht? Wie kann der Anpassungs- und Kommunikationsprozess verbessert werden? Und umgekehrt, wie kann sich die Situation verschlechtern?
  2. Welche Kenntnisse aus anderen Disziplinen können wir anwenden, um das System im Falle eines Unfalls flexibler und stabiler zu machen?
  3. Wie sollten Training und menschliche Interaktion so organisiert werden, dass im Falle eines Unfalls sowohl der Schaden als auch der Stress für diejenigen, die ihn beseitigen, am geringsten sind?
  4. Welche technischen Lösungen, Praktiken können hierfür angewendet werden? Wie können wir durch bewusstes Handeln die Stabilität des Systems und seine Anpassungsfähigkeit an Unfälle erhöhen?


Darüber war die Konferenz. Und unten - worüber einige Redner gesprochen haben.

Einige Beobachtungen zur hervorragenden Belastbarkeit von Bone and Resilience Engineering. Richard Cook


Zunächst muss über die Person des Sprechers gesagt werden. Richard Cook ist Arzt, Wissenschaftler und einer der wichtigsten „Popularisierer“ des IT-Resilienz-Engineerings. Zusammen mit David Woods und John Olspau (dem Mann, der DevOps tatsächlich als Empfehlung ins Leben gerufen hat) war er Mitbegründer von Adaptive Capacity Labs, einem Unternehmen, das Sustainability Engineering in anderen Organisationen implementiert.

Es ist zu beachten, dass REDeploy keine IT-Konferenz ist, und dieser Bericht ist ein anschauliches Beispiel dafür.

Der größte Teil des Berichts ist eine detaillierte Analyse der Heilung des gebrochenen Knochens, dessen Heilung ein Archetyp der Belastbarkeit ist. Die Knochen selbst sind nicht richtig verwachsen. Die Medizin untersuchte die Behandlung von Frakturen und verstand den Heilungsprozess. In der Tat behandelt die Medizin nicht einmal den Knochen selbst, sondern schafft Prozesse, die die Heilung fördern.

Im Allgemeinen kann die Behandlungsgeschichte in zwei Richtungen unterteilt werden:
  • Behandlung als ein Prozess, der die günstigsten Bedingungen für die Knochenheilung schafft (während des Behandlungsprozesses tragen wir Gips auf, damit sich der Knochen nicht bewegt).
  • Behandlung als Prozess der „Verbesserung“ des Heilungsprozesses (auf biochemischer Ebene verstehen wir, wie der Heilungsprozess abläuft, und verwenden Medikamente, die ihn beschleunigen).


Und hier lautet die Hauptthese tatsächlich „Software“ für die gesamte Disziplin des Berichts: Warum müssen wir verstehen, wie die soziotechnischen Prozesse während eines Unfalls ablaufen?

Wenn wir verstehen, wie der „Behandlungsmechanismus“ (z. B. die Lösung eines Notfalls) funktioniert, können wir zumindest so günstige Bedingungen schaffen, dass der Unfall nur minimalen Schaden verursacht und den Prozess der Unfalllösung maximal beschleunigt. Wir können Fälle nicht verhindern, in denen eine Person einen Knochen bricht, aber wir können den Heilungsprozess verbessern.

Die Kunst, Fehler im Maßstab zu erfassen. Adrian Hornsby


Und jetzt ein technischer Bericht über die Entwicklung der Fehlertoleranz in der AWS-Infrastruktur.
Ohne auf technische Merkmale einzugehen (Sie können sie in der Präsentation sehen ), werden wir die Hauptthese des Berichts betrachten. AWS entwickelt beim Aufbau verschiedener Systeme die Architektur unter Berücksichtigung der Tatsache, dass ein Unfall früher oder später auftreten kann, und dementsprechend sollte die Systemarchitektur so gestaltet sein, dass der "Explosionsradius" im Falle eines Unfalls begrenzt wird. Beispielsweise werden Client-Datenbanken und Speicher in Gruppen von "Zellen" unterteilt, und die von einem Client erstellte Last betrifft nur Benutzer dieser Zelle. Clients in Zellrepliken duplizieren die Hauptzellen nicht, sondern werden miteinander gemischt, wodurch der Aufprallradius auf ein Minimum begrenzt wird.







Durch die Erhöhung der Anzahl solcher Kombinationen verringern wir das Risiko einer Kundenbeteiligung im Falle eines Aufpralls.



Sich unter Wasser wohlfühlen. Ronnie Chen


Ein Bericht eines Twitter-Managers mit Erfahrung im technischen Tiefseetauchen zu Sicherheitsmerkmalen beim Tauchen.

Team Deep Diving ist ein risikoreicher Job. Und wenn die Organisation solcher Tauchgänge nur dann von der Möglichkeit des Tauchens ausgeht, wenn solche Risiken vollständig ausgeglichen sind, wird es überhaupt keine Tiefseetauchgänge geben. Auf die eine oder andere Weise können Probleme auftreten, und das ist normal - der Sprecher als Ganzes vergleicht das bewusste Eingehen von Risiken als Methode zur Entwicklung des menschlichen Potenzials. Wenn wir Risiken mindern, wird dies unser Potenzial einschränken. Die Aufgabe besteht wiederum darin, die einfachste Lösung von Situationen zu organisieren, falls diese Risiken erkannt werden.

Wie können Sie versuchen, mit dem Druck zu leben, der bei riskanten Aktivitäten beim Team liegt?

Ein Beispiel für die Interaktionsregeln eines Tauchteams:
  • Zuverlässige und ständige Kommunikation zwischen den Teilnehmern und maximale psychologische Sicherheit: Jedes Teammitglied muss sich sicher fühlen, jeder Tauchteilnehmer kann jederzeit mit dem Tauchen aufhören (und Gebühren sind verboten).
  • Akzeptanz von Fehlern. Jeder Mensch kann Fehler machen, und Fehler sind bei der Arbeit unvermeidlich. Schuldzuweisungen sind ebenfalls nicht akzeptabel.
  • Das Team kann die Ziele des Projekts neu definieren und den Erfolg des Projekts im Tauchprozess in Abhängigkeit von sich ändernden Bedingungen bestimmen.
  • , .
  • — . , , .
  • ( ) , root cause ( ), , .


The Practice of Practice: Teamwork in Complexity. Matt Davis


Im Falle eines Unfalls sind die Ingenieure weitgehend intuitiv, und die Intuition im Bericht wird mit der musikalischen Improvisation verglichen. Improvisation ist ein Prozess des intuitiven Musikspielens, aber diese Intuition basiert auf Erfahrung - Kenntnis der musikalischen Skalen, Erfahrung früherer Improvisation, Teamarbeit. Darüber hinaus ist dies ein bidirektionaler Prozess: Intuition basiert auf Erfahrung, und Prozesse basieren auf der Analyse intuitiver Handlungen (in Musik - Noten einer komponierten Komposition werden geschrieben, in Technologien - der Prozess der Korrektur eines Unfalls wird beschrieben).

Zwei Arten zu lehren / Intuition zu formen:
- Post-mortem nicht als Mittel, um Probleme in der Zukunft zu beschuldigen oder zu verhindern, sondern als Mittel zur Schulung und zum Austausch von Erfahrungen. Teilen Sie Ihre Erfahrungen bei der Lösung von Unfällen regelmäßig in Form eines Obduktions- / Unfallberichts mit, um Ihre Erfahrungen bei der Lösung von Problemen mit anderen Personen zu teilen.
- Chaos Engineering als Möglichkeit, Erfahrungen in einer kontrollierten Umgebung zu generieren. Indem wir künstlich einen Unfall im System verursachen, der behoben werden muss, bilden wir die Erfahrung der Intuition mit den Ingenieuren, die sich mit seiner Lösung befassen. Gleichzeitig können wir den erforderlichen Stapel bestimmen, in dem wir Kompetenzen entwickeln möchten, indem wir den Radius der Auswirkungen im System begrenzen.

Hier sind die denkwürdigsten Berichte an mich. Es scheint mir, dass dies momentan sehr nützliche Dinge sind, wenn es so aussieht, als ob im Allgemeinen die gesamte Realität zusammengebrochen ist, „trage eine andere“. Vielleicht helfen Ihnen einige Punkte dabei, die Realität und Unfälle aus einem neuen Blickwinkel zu betrachten.

Und ich bin ein bisschen regelmäßiger als der Blog hier, ich behalte meinen Telegrammkanal , abonniere :-)

More articles:


All Articles