A maioria dos erros de software não é por falta de conhecimento

Quando eu era mais jovem, participei de várias expedições de escalada e montanhismo. Fui exposto a alguns instrutores e praticantes que levavam muito a sério a segurança nas montanhas. Um deles carregava um livro do The American Alpine Club sobre acidentes de escalada. Os acidentes nunca foram a causa de uma única má escolha. Eles foram causados por uma série de decisões, tomadas ao longo do tempo, que se combinaram para criar as condições para o acidente.

O que ficou na minha memória, sentado ao lado de rochas que poderiam muito bem ser o cenário de uma das histórias, foi que em certos casos poderíamos fazer uma das mesmas escolhas. Dada uma hora do dia diferente, clima diferente ou parceiros de escalada diferentes, a mesma escolha pode ter diferentes níveis de risco. Ler e discutir essas histórias me tornou um aventureiro mais consciente e um alpinista mais seguro.

A análise e discussão pública da cadeia de decisões e eventos que levaram a acidentes ajuda os iniciantes a adquirir experiência, os especialistas a desenvolver sabedoria e a promover uma cultura de segurança. Outras indústrias e subculturas têm suas próprias maneiras de aprender com os acidentes. Por exemplo: as forças armadas dos EUA têm análises pós-ação, a medicina tem conselhos de revisão de acidentes e a aviação tem revisões de acidentes do NTSB.

Eu li relatórios de análise de causa raiz de interrupções em provedores de hospedagem em nuvem hiperescalar. Freqüentemente, eles parecem as pegadas de gesso de um animal morto há muito tempo, os departamentos jurídico e de marketing higienizando e esfregando qualquer elemento da vida ou aprendendo com eles. Eles são a carga cultual da investigação e do relatório de acidentes. Todos os movimentos e afetações sem nenhuma substância.

A cultura predominante em software para erros parece ser "se você apenas". Onde os erros são atribuídos à falta de conhecimento. Se o operador "apenas" conhecesse o impacto da alteração de configuração, se o desenvolvedor "apenas" entendesse a interação de sua alteração de código. É uma cultura de conhecimento especializado. Baseia-se na crença não examinada de que os bugs só existem por falta de conhecimento ou falta de cuidado. Ou levados aos seus extremos ofensivos: estupidez e preguiça.

Na indústria de software, bugs ou interrupções na maioria das vezes não resultam em ferimentos ou morte. No entanto, à medida que a sociedade se torna mais dependente dos sistemas de software que estamos construindo, a gravidade e o impacto dos problemas só aumentam. À medida que nossos sistemas de software continuam a crescer em complexidade e o alcance dos problemas para os quais escrevemos software para resolver, nós, como sociedade, devemos lutar para mudar essa cultura.

Como um passo neste caminho de mudança desta cultura, estou falando sobre falhas que vi ou participei. Meu objetivo é tornar mais fácil para outras pessoas compartilharem onde falharam. Isso criará um ciclo de feedback que nos permitirá aprender mais rápido.

Junte-se a mim para compartilhar histórias de fracasso. Aqui está uma palestra sobre o fracasso e algumas postagens relacionadas minhas e da equipe da Cyclic:

1. Como falhar no Serverless: Serverless é Stateless (postagem do blog)
2. Está sempre ensolarado em us-east-1: A gangue faz a continuidade dos negócios (postagem no blog)
3. AWS S3: Por que às vezes você deve pressionar o botão $ 100k (postagem no blog)

Adoraríamos ouvir suas histórias.

Escreva algo.

Publique-o publicamente .

Nos informe.

Nós protegemos você :)

Publicado também aqui . Imagem em destaque acima gerada por HackerNoon Stable Diffusion.