Get best of the week

Ingeniería de resiliencia: notas de la conferencia REDeploy



Si bien las conferencias en todo el mundo buscan formatos óptimos en línea, es hora de recordar cómo vivían ellos (y todos nosotros) en la era pre-viral. A fines del año pasado, asistí a la conferencia REDeploy 2019 dedicada a la ingeniería de resiliencia. Durante mucho tiempo intenté entender cómo traducir este término al ruso, hasta que descubrí que el término se ha utilizado durante mucho tiempo en nichos no escritos, como "ingeniería de resiliencia". Además, sería necesario escribir una definición de resiliencia, pero es difícil hacerlo con una oración simple. También resultó que los temas planteados hace seis meses son muy relevantes en nuestra nueva realidad.

En primer lugar, es importante comprender que la ingeniería de resiliencia es un campo de la ciencia multidisciplinario, que tiene como objetivo la investigación, la formalización y la formación de prácticas que aumenten la capacidad de los sistemas socio-técnicos complejos para estar preparados para situaciones inusuales y accidentes, adaptarse a ellos y mejorar sus habilidades. adaptar.

Durante muchos años, la imagen mecánica del mundo prevaleció en el proceso de desarrollo de software: la creencia de que podemos desarrollar software que funcionará sin fallas, y si ocurre un accidente, tendrá alguna causa raíz, que puede corregirse para evitar la repetición de tales errores en el futuro y, por lo tanto, dado que la cantidad de errores es, por supuesto, al final, corrija todos los errores que conducen a accidentes (consulte el excelente artículoDev, Ops y determinismo al respecto).

El mismo enfoque de "ingeniería" también se aplica a la forma en que las personas interactúan durante un accidente: es suficiente para crear algunas herramientas, con las cuales las personas pueden solucionar el problema (sin cometer errores).

Pero el problema es que el software continúa actualizándose, se vuelve complejo, fragmentado y ramificado, y los accidentes que ocurren no tienen una sola razón (además, incluso pueden ubicarse fuera del sistema), y las personas en el proceso de comunicación para corregir este accidente pueden cometer errores

Por lo tanto, la tarea no es prácticamente imposible para evitar errores y accidentes en el sistema, sino para preparar a las personas y al sistema para que un posible accidente tenga el menor impacto en el sistema, sus usuarios y creadores.

El desarrollo de software durante mucho tiempo se mantuvo alejado de otras disciplinas de ingeniería "fuera de línea", mientras que la práctica de "reducción de daños" por accidentes se ha utilizado allí durante mucho tiempo. Y es más probable que estas prácticas se relacionen con las personas que los servicios públicos y las soluciones técnicas para prevenir accidentes.

Las preguntas formuladas por la resiliencia de ingeniería son las siguientes:
  1. ¿Qué características culturales y sociales de la interacción de las personas deben considerarse para comprender mejor lo que puede y no puede suceder en la comunicación de las personas en el proceso de un accidente? ¿Cómo se puede mejorar el proceso de adaptación y comunicación? Y viceversa, ¿cómo puede empeorar la situación?
  2. ¿Qué conocimiento de otras disciplinas podemos aplicar para que el sistema sea más flexible y estable en caso de accidente?
  3. ¿Cómo deben organizarse la capacitación y la interacción humana para que, en caso de accidente, el daño y el estrés para quienes lo eliminen sean lo mínimo?
  4. ¿Qué soluciones técnicas, prácticas se pueden aplicar para esto? ¿Cómo, a través de acciones conscientes, podemos aumentar la estabilidad del sistema y su adaptabilidad a los accidentes?


Sobre esto fue la conferencia. Y a continuación, de lo que hablaron algunos oradores.

Algunas observaciones sobre la maravillosa capacidad de recuperación de la ingeniería ósea y de resistencia. Richard Cook


En primer lugar, debe decirse sobre la persona del hablante. Richard Cook es médico, científico y uno de los principales "divulgadores" de la ingeniería de resiliencia de TI. Junto con David Woods y John Olspau (el hombre que realmente lanzó DevOps como referencia), cofundó Adaptive Capacity Labs, una compañía que implementa ingeniería de sostenibilidad en otras organizaciones.

Cabe señalar que REDeploy no es una conferencia de TI, y este informe es un claro ejemplo de esto.

La mayor parte del informe es un análisis detallado de cómo se cura el hueso roto, cuya curación es un arquetipo de resistencia. Los huesos en sí no están fusionados correctamente. La medicina estudió cómo tratar fracturas, entendiendo el proceso de curación. De hecho, la medicina ni siquiera trata el hueso en sí, crea procesos que promueven la curación.

En general, la historia del tratamiento se puede dividir en dos direcciones:
  • tratamiento como un proceso que crea las condiciones más favorables para la curación ósea (en el proceso de tratamiento aplicamos yeso para que el hueso no se mueva).
  • tratamiento como un proceso de "mejora" del proceso de curación (entendiendo, a nivel bioquímico, cómo va el proceso de curación, usamos medicamentos que lo aceleran).


Y aquí la tesis principal es, de hecho, "programática" para toda la disciplina del informe: ¿por qué necesitamos entender cómo ocurren los procesos sociotécnicos durante un accidente?

Al comprender cómo funciona el mecanismo de "tratamiento" (por ejemplo, resolver una emergencia), al menos podemos organizar condiciones tan favorables que el accidente cause un daño mínimo y, como máximo, acelere el proceso de resolución del accidente. No podemos prevenir los casos en que una persona se rompe un hueso, pero podemos mejorar el proceso de curación.

El arte de aceptar el fracaso a escala. Adrian hornsby


Y ahora, un informe técnico sobre la evolución de la tolerancia a fallas en la infraestructura de AWS.
Sin entrar en las características técnicas (puede verlas en la presentación ), consideraremos la tesis principal del informe. AWS, en el proceso de construcción de varios sistemas, desarrolla la arquitectura teniendo en cuenta el hecho de que un accidente puede ocurrir tarde o temprano y, en consecuencia, la arquitectura del sistema debe diseñarse de tal manera que limite el "radio de explosión" en caso de accidente. Por ejemplo, las bases de datos de clientes, los almacenamientos se dividen en grupos de "celdas", y la carga creada por un cliente afecta solo a los usuarios de esta celda. Los clientes en las réplicas de celdas no duplican las celdas principales, sino que se mezclan entre sí, lo que limita el radio de impacto al mínimo.







Al aumentar el número de tales combinaciones, reducimos el riesgo de participación del cliente en caso de impacto.



Cómo sentirse cómodo con estar bajo el agua. Ronnie chen


Un informe de un administrador de Twitter con experiencia en buceo técnico en alta mar sobre características de seguridad durante el buceo.

El buceo profundo en equipo es un trabajo de alto riesgo. Y si la organización de tales inmersiones parte de la posibilidad de bucear solo en el caso de una nivelación completa de tales riesgos, no habrá inmersiones en aguas profundas. De una forma u otra, pueden ocurrir problemas, y esto es normal: el hablante en su conjunto compara la toma consciente de riesgos como un método para desarrollar el potencial humano. Si mitigamos los riesgos, esto limitará nuestro potencial. La tarea, nuevamente, es organizar la resolución más fácil de situaciones en caso de que estos riesgos se realicen.

¿Cómo puede tratar de vivir con la presión que recae sobre el equipo en caso de actividades riesgosas?

Un ejemplo de las reglas de interacción de un equipo de buzos:
  • Comunicación confiable y constante entre los participantes y la máxima seguridad psicológica: cada miembro del equipo debe sentirse seguro, cualquier participante de buceo puede dejar de bucear en cualquier momento (y los cargos están prohibidos).
  • Aceptación de errores. Cualquier persona puede cometer errores, y los errores son inevitables en el proceso de trabajo; culpar a los errores también es inaceptable.
  • El equipo puede redefinir los objetivos del proyecto y determinar el éxito del proyecto en el proceso de inmersión según las condiciones cambiantes.
  • , .
  • — . , , .
  • ( ) , root cause ( ), , .


The Practice of Practice: Teamwork in Complexity. Matt Davis


En caso de accidente, los ingenieros son en gran medida intuitivos, y la intuición en el informe se compara con la improvisación musical. La improvisación es un proceso de reproducción de música intuitiva, pero esta intuición se basa en la experiencia: conocimiento de escalas musicales, la experiencia de improvisación previa, trabajo en equipo. Además, este es un proceso bidireccional: la intuición se basa en la experiencia, y los procesos se basan en el análisis de acciones intuitivas (en la música, se escriben notas de una composición compuesta, en las tecnologías, se describe el proceso de corregir un accidente).

Dos formas de enseñar / formar la intuición:
- Post-mortem no como un medio para culpar o prevenir problemas en el futuro, sino como un medio de capacitación y una forma de compartir experiencias. Comparta regularmente su experiencia en la resolución de accidentes en forma de informe post mortem / accidente para compartir su experiencia de resolver el problema con otras personas.
- Ingeniería del caos como una forma de generar experiencia en un entorno controlado. Al crear artificialmente un accidente en el sistema que necesita ser resuelto, formamos la experiencia de la intuición con aquellos ingenieros que se encargarán de su solución. Al mismo tiempo, podemos determinar la pila necesaria en la que queremos desarrollar competencias limitando el radio del impacto en el sistema.

Aquí están los informes más memorables para mí. Me parece que estas son cosas muy útiles en este momento, cuando puede parecer que, en general, toda la realidad se ha roto, "llevar a otro". Quizás algunos puntos lo ayuden a ver la realidad y los accidentes desde un nuevo ángulo.

Y soy un poco más regular que el blog aquí, mantengo mi canal de telegramas y suscribo :-)

More articles:


All Articles