Get best of the week

Engenharia de resiliência: notas da conferência REDeploy



Enquanto as conferências em todo o mundo buscam os melhores formatos on-line, é hora de lembrar como eles (e todos nós) vivemos na era pré-viral. No final do ano passado, participei da conferência REDeploy 2019 dedicada à engenharia de resiliência. Durante muito tempo, tentei entender como traduzir esse termo para o russo, até descobrir que o termo é usado há muito tempo em nichos não escritos - como "engenharia da resiliência". Além disso, seria necessário escrever uma definição de resiliência, mas é difícil fazer isso com uma frase simples. Descobriu-se também que os tópicos levantados há seis meses são muito relevantes em nossa nova realidade.

Antes de tudo, é importante entender que a engenharia da resiliência é um campo interdisciplinar da ciência, que visa à pesquisa, formalização e formação de práticas que aumentam a capacidade de sistemas sócio-técnicos complexos de se prepararem para situações e acidentes incomuns, se adaptarem a eles e melhorarem suas habilidades. para adaptar.

Por muitos anos, a imagem mecânica do mundo prevaleceu no processo de desenvolvimento de software - a crença de que somos capazes de desenvolver software que funcionará sem falhas e, se ocorrer um acidente, terá alguma causa raiz, que poderá ser corrigida. para evitar a recorrência de tais erros no futuro - e, portanto, como o número de erros é claro, no final, corrija todos os erros que levam a acidentes (consulte excelente artigoDev, Ops e Determinism sobre isso).

A mesma abordagem de "engenharia" também é aplicada à maneira como as pessoas interagem durante um acidente: basta criar algumas ferramentas, usando as quais as pessoas podem resolver o problema (evitando erros).

Mas o problema é que o software continua sendo atualizado, torna-se complexo, fragmentado e ramificado, e os acidentes que ocorrem não têm um único motivo (além disso, eles podem até estar localizados fora do sistema), e as pessoas no processo de comunicação para corrigir esse acidente podem cometer erros.

Portanto, a tarefa não é quase impossível de evitar erros e acidentes no sistema, mas de preparar as pessoas e o sistema para que um acidente em potencial tenha o menor impacto no sistema, em seus usuários e criadores.

Por muito tempo, o desenvolvimento de software permaneceu distante de outras disciplinas de engenharia "offline", enquanto a prática de "redução de danos" devido a acidentes foi usada por um longo tempo. E é mais provável que essas práticas estejam relacionadas às pessoas do que serviços públicos e soluções técnicas para evitar acidentes.

As perguntas feitas pela resiliência de engenharia são assim:
  1. Quais características culturais e sociais da interação das pessoas devem ser consideradas para melhor entender o que pode e o que não pode acontecer na comunicação das pessoas em processo de acidente? Como o processo de adaptação e comunicação pode ser aprimorado? E vice-versa, como a situação pode piorar?
  2. Que conhecimento de outras disciplinas podemos aplicar para tornar o sistema mais flexível e estável em caso de acidente?
  3. Como o treinamento e a interação humana devem ser organizados de modo que, em caso de acidente, os danos e o estresse, para quem o elimine, sejam os menores?
  4. Quais soluções técnicas, práticas podem ser aplicadas para isso? Como, através de ações conscientes, podemos aumentar a estabilidade do sistema e sua adaptabilidade a acidentes?


Sobre isso foi a conferência. E abaixo - sobre o que alguns palestrantes falaram.

Algumas observações sobre a maravilhosa resiliência da engenharia de ossos e resiliência. Richard Cook


Antes de tudo, deve-se dizer sobre a pessoa do orador. Richard Cook é médico, cientista e um dos principais "popularizadores" da engenharia de resiliência de TI. Juntamente com David Woods e John Olspau (o homem que realmente lançou o DevOps como referência), ele co-fundou a Adaptive Capacity Labs, uma empresa que implementa engenharia de sustentabilidade em outras organizações.

Note-se que o REDeploy não é uma conferência de TI, e este relatório é um exemplo vívido disso.

A maior parte do relatório é uma análise detalhada de como o osso quebrado se recupera, cuja cura é um arquétipo da resiliência. Os ossos em si não são fundidos corretamente. A medicina estudou como tratar fraturas, entendendo o processo de cicatrização. De fato, a medicina nem trata o próprio osso, cria processos que promovem a cura.

Em geral, a história do tratamento pode ser dividida em duas direções:
  • tratamento como um processo que cria as condições mais favoráveis ​​para a cicatrização óssea (no processo de tratamento, aplicamos gesso para que o osso não se mova).
  • tratamento como um processo de “melhoria” do processo de cicatrização (entendendo - no nível bioquímico - como o processo de cicatrização ocorre, usamos drogas que o aceleram).


E aqui a tese principal é, de fato, “programática” para toda a disciplina do relatório: por que precisamos entender como ocorrem os processos sociotécnicos durante um acidente?

Entendendo como funciona o mecanismo de "tratamento" (por exemplo, resolver uma emergência), podemos pelo menos organizar condições tão favoráveis ​​que o acidente cause danos mínimos e, no máximo, acelere o processo de resolução do acidente. Não podemos evitar casos em que uma pessoa quebra um osso, mas podemos melhorar o processo de cicatrização.

A arte de abraçar o fracasso em escala. Adrian hornsby


E agora, um relatório técnico sobre a evolução da tolerância a falhas na infraestrutura da AWS.
Sem entrar em recursos técnicos (você pode vê-los na apresentação ), consideraremos a tese principal do relatório. A AWS no processo de construção de vários sistemas desenvolve a arquitetura levando em consideração o fato de que um acidente pode ocorrer mais cedo ou mais tarde e, portanto, a arquitetura do sistema deve ser projetada de forma a limitar o "raio de explosão" no caso de um acidente. Por exemplo, bancos de dados do cliente, armazenamentos são divididos em grupos de "células" e a carga criada por um cliente afeta apenas os usuários dessa célula. Os clientes nas réplicas de células não duplicam as células principais, mas são misturados, limitando assim o raio do impacto ao mínimo.







Ao aumentar o número de tais combinações, reduzimos o risco de envolvimento do cliente em caso de impacto.



Ficando Confortável em Estar Subaquático. Ronnie chen


Um relatório de um gerente do Twitter com experiência em mergulho técnico em alto mar sobre recursos de segurança durante o mergulho.

Mergulho em equipe é um trabalho de alto risco. E se a organização de tais mergulhos proceder da possibilidade de mergulhar apenas no caso de um nivelamento completo de tais riscos - não haverá mergulhos em alto mar. De uma maneira ou de outra, problemas podem ocorrer, e isso é normal - o falante como um todo compara a tomada consciente de riscos como um método de desenvolvimento do potencial humano. Se mitigarmos os riscos, isso limitará nosso potencial. A tarefa, novamente, é organizar a resolução mais fácil de situações, caso esses riscos sejam realizados.

Como você pode tentar conviver com a pressão que recai sobre a equipe em caso de atividades arriscadas?

Um exemplo das regras de interação de uma equipe de mergulhadores:
  • Comunicação confiável e constante entre os participantes e segurança psicológica máxima: cada membro da equipe deve se sentir seguro, qualquer participante do mergulho pode parar de mergulhar a qualquer momento (e as cobranças são proibidas).
  • Aceitação de erros. Qualquer pessoa pode cometer erros, e os erros são inevitáveis ​​no processo de trabalho; culpar erros também é inaceitável.
  • A equipe pode redefinir os objetivos do projeto e determinar o sucesso do projeto no processo de mergulho, dependendo das condições de mudança.
  • , .
  • — . , , .
  • ( ) , root cause ( ), , .


The Practice of Practice: Teamwork in Complexity. Matt Davis


No caso de um acidente, os engenheiros são bastante intuitivos, e a intuição no relatório é comparada à improvisação musical. A improvisação é um processo de tocar música intuitivamente, mas essa intuição é baseada na experiência - conhecimento de escalas musicais, experiência de improvisação anterior, trabalho em equipe. Além disso, este é um processo bidirecional: a intuição é construída sobre a experiência e os processos são construídos sobre a análise de ações intuitivas (na música - notas de uma composição composta são escritas, em tecnologias - é descrito o processo de correção de um acidente).

Duas maneiras de ensinar / formar intuição:
- Post-mortem, não como um meio de culpar ou prevenir problemas no futuro, mas um meio de treinamento e uma maneira de compartilhar experiências. Compartilhe regularmente sua experiência na resolução de acidentes na forma de um relatório post mortem / acidente, a fim de compartilhar sua experiência na resolução do problema com outras pessoas.
- Engenharia do Caos como forma de gerar experiência em ambiente controlado. Criando artificialmente um acidente no sistema que precisa ser resolvido, formamos a experiência da intuição com os engenheiros que lidam com sua solução. Ao mesmo tempo, podemos determinar a pilha necessária na qual queremos desenvolver competências limitando o raio do impacto no sistema.

Aqui estão os relatórios mais memoráveis ​​para mim. Parece-me que essas são coisas muito úteis no momento, quando pode parecer que, em geral, toda a realidade se desintegrou, “carrega outra”. Talvez alguns pontos o ajudem a encarar a realidade e os acidentes sob um novo ângulo.

E sou um pouco mais regular do que o blog aqui, mantenho meu canal de telegrama , assino :-)

More articles:


All Articles