Estudo comentado: como sistemas complexos falham?
Olá!
Hoje eu gostaria de abordar o assunto sistemas complexos da perspectiva de uma visão acadêmica das causas de suas falhas.
Acredito que tema seja vital na atuação de uma pessoa desenvolvedora e não se aplica somente a líderes, inclusive.
Lei de Gall
Antes de explorar o paper, gostaria de apresentar a Lei de Gall, que diz o seguinte:
Um sistema complexo que funciona é invariavelmente descoberto como tendo evoluído de um sistema simples que funcionava. A proposição inversa também parece ser verdadeira: Um sistema complexo projetado do zero nunca funciona e não pode ser feito para funcionar. É necessário começar de novo, partindo de um sistema simples que funcione.
É possível deduzir que a partir dessa ideia, um sistema complexo terá multiplas partes, que são geradas como uma espécie de “sujeira” a partir da evolução natural do sistema. Tenha isso em mente ao analisar os pontos do artigo, você verá que os pontos descritos tem bastante sinergia com essa lei.
Agora, vamos ao paper em si. O material original é esse, de Richard Cook, da universidade de Chicago, publicado originalmente em 2002. Optei por traduzir os principais tópicos do paper e vou tecer alguns comentários. Os pontos em itálico são do texto original.
Sistemas complexos são intrinsecamente sistemas perigosos.
Todos os sistemas interessantes (por exemplo, transporte, saúde, geração de energia) são inherentemente e inevitavelmente perigosos por sua própria natureza. A frequência da exposição ao perigo às vezes pode ser alterada, mas os processos envolvidos no sistema são intrinsecamente e irredutivelmente perigosos. É a presença desses perigos que impulsiona a criação de defesas contra perigos que caracterizam esses sistemas.
Trazendo para a tecnologia, geralmente, encontramos esse comportamento em sistemas financeiros (como bancos e processadores de pagamentos). Portanto, o grande aprendizado aqui é entender que sistemas de alto volume e importância serão um alvo, invarialmente. Logo, o desenvolvimento desse tipo de sistema não pode ser feito de forma leviana. Você confiaria em um sistema de controle de avião feito no Go Horse? Pois é, eu também não.
Sistemas complexos são pesadamente e com sucesso defendidos contra o fracasso.
As altas consequências do fracasso levam, ao longo do tempo, à construção de múltiplas camadas de defesa contra o fracasso. Essas defesas incluem componentes técnicos óbvios (por exemplo, sistemas de backup, características de ‘segurança’ de equipamentos) e componentes humanos (por exemplo, treinamento, conhecimento), mas também uma variedade de defesas organizacionais, institucionais e regulatórias (por exemplo, políticas e procedimentos, certificação, regras de trabalho, treinamento de equipe). O efeito dessas medidas é fornecer uma série de escudos que normalmente desviam as operações de acidentes.
Trazendo para o ecossistema financeiro que consigo falar sobre com um pouco mais de propriedade, eu observei que ocorre isso mesmo. Um processo que vi acontecer em bancos foi: para acessar a base de produção do sistema de cartões, era necessário abrir um chamado e aguardar aprovação. Após isso, só então ser autorizado a acessar uma área do prédio que continham máquinas que podiam acessar o ambiente de produção. Além disso, ficava um segurança na porta da sala e tinha câmeras filmando o que você fazia, contemplando teclado e tela.
Portanto, toda vez que você se deparar com burocracia similares em empresas que possuem sistemas assim, provavelmente é por causa desse ponto. Não adianta reclamar contra isso. Não será você que irá mudar a burocracia de segurança, o risco para a organização é alto demais. Aceite que será assim ou troque de ramo de atuação (porque só trocar a empresa não vai adiantar).
Catástrofe requer múltiplos fracassos — falhas de ponto único não são suficientes.
A matriz de defesas funciona. As operações do sistema são geralmente bem-sucedidas. O fracasso catastrófico manifesto ocorre quando pequenas falhas aparentemente inócuas se juntam para criar oportunidades para um acidente sistêmico. […] A maioria das trajetórias de falha inicial é bloqueada por componentes de segurança do sistema projetados. As trajetórias que alcançam o nível operacional são na maioria das vezes bloqueadas, geralmente pelos praticantes.
Imagine um sistema complexo, do naipe de um grande marketplace de restaurantes. Para todo aquele ecossistema cair e gerar uma indisponibilidade grave, geralmente requer que aconteçam múltiplas falhas ocorrendo simultaneamente (ex: cair o gateway de pagamento ao mesmo tempo que a AWS está fora e o chaveamento para outro gateway não foi possível). Além disso, a maioria dos problemas que os desenvolvedores podem causar, em teoria, são tratados por processos robustos de engenharia de software (como testes, CI/CD, blue green deployment e similares). Para os problemas que os clientes podem causar, geralmente mecanismos como WAFs, Load Balancers, CDNs e até mesmo sanitização de input são empregados.
Sistemas complexos contêm misturas mutáveis de falhas latentes dentro deles.
A complexidade desses sistemas torna impossível que eles funcionem sem que múltiplas falhas estejam presentes. Como essas são individualmente insuficientes para causar falhas, elas são consideradas fatores menores durante as operações. A erradicação de todas as falhas latentes é limitada principalmente pelo custo econômico, mas também porque é difícil, antes do fato, ver como tais falhas podem contribuir para um acidente. As falhas mudam constantemente devido à tecnologia em mudança, organização do trabalho e esforços para erradicar falhas.
Quem nunca aprendeu a conviver com logs de erros conhecidos em sistemas que nunca serão corrigidos porque não vale o custo, nunca trabalhou a sério com sistemas distribuídos.
Um exemplo de prática que a indústria de software criou para lidar com isso é chaos engineering, que surge para justamente fazer o sistema operar com múltiplas falhas presentes o tempo todo.
Sistemas complexos funcionam em modo degradado.
Um corolário do ponto anterior é que sistemas complexos funcionam como sistemas defeituosos. O sistema continua a funcionar porque contém tantas redundâncias e porque as pessoas podem fazê-lo funcionar, apesar da presença de muitas falhas. Após análises de acidentes, quase sempre se nota que o sistema tem um histórico de ‘proto-acidentes’ anteriores que quase geraram catástrofes. Argumentos de que essas condições degradadas deveriam ter sido reconhecidas antes do acidente manifesto são geralmente baseados em noções ingênuas de desempenho do sistema. As operações do sistema são dinâmicas, com componentes (organizacionais, humanos, técnicos) falhando e sendo substituídos continuamente.
Esse ponto eu achei sensacional. Em um ecossistema complexo, são tantas partes envolvidas que é impossível prever e antecipar todos os problemas. Portanto, outras abordagens são mais efetivas, como sharding, backups, multi-cloud e similares. É melhor ter um plano B do que tentar fazer o plano A funcionar 100% das vezes.
Catástrofe está sempre à espreita. Sistemas complexos possuem potencial para falhas catastróficas.
Os praticantes humanos estão quase sempre em proximidade física e temporal próxima a essas falhas potenciais — o desastre pode ocorrer a qualquer momento e em quase qualquer lugar. O potencial para um resultado catastrófico é uma marca registrada dos sistemas complexos. É impossível eliminar o potencial para tal fracasso catastrófico; o potencial para tal falha está sempre presente pela própria natureza do sistema.
O ecossistema do marketplace de comida do logo vermelho movimenta 0,53% do PIB do Brasil inteiro. São 97 bilhões de reais. O sistema do banco laranja para processamento de pagamentos contemplava 35% de todas as transações bancárias realizadas no Brasil na época que eu trabalhava lá. Faça as contas do que acontece em termos de perdas financeiras, transtornos e demais problemas que iriam acontecer se acontecesse desses sistemas ficarem fora do ar por muito tempo.
O subsistema do jurídico ficar fora do ar não é catástrofe. O sistema de pagamentos ou o core de processamentos de pedidos cair, sim. Eu só gostaria que mais pessoas de negócio soubessem disso antes de sair reclamando que os times de tech não fazem o que eles pedem (geralmente, porque estão focados em outras coisas mais críticas).
A atribuição pós-acidente do acidente a uma ‘causa raiz’ é fundamentalmente errada.
Porque o fracasso manifesto requer múltiplas falhas, não há ‘causa’ isolada de um acidente. Existem múltiplos contribuintes para acidentes. Cada um destes é necessário, mas insuficiente por si só para criar um acidente. Somente juntos essas causas são suficientes para criar um acidente. […] Assim, não é possível isolar a ‘causa raiz’ de um acidente. As avaliações baseadas em tal raciocínio como ‘causa raiz’ não refletem uma compreensão técnica da natureza do fracasso, mas sim a necessidade social, cultural, de culpar forças ou eventos específicos e localizados pelos resultados.
Concordo com o autor quando ele diz que não tem uma “única” causa para falhas catastróficas. Porém, ao realizar um postmortem desse tipo de incidente surgem várias causas raízes. O que nos leva a seguinte abordagem: busque todas as causas ao invés de parar na primeira. Me parece um caminho mais adequado no geral.
O viés retrospectivo enviesa as avaliações pós-acidente do desempenho humano.
O conhecimento do resultado faz com que pareça que os eventos que levam ao resultado deveriam ter aparecido mais salientes para os praticantes na época do que realmente foi o caso. Isso significa que a análise pós-fato do desempenho humano em acidentes é imprecisa. O conhecimento do resultado prejudica a capacidade dos observadores pós-acidente de recriar a visão dos praticantes antes do acidente desses mesmos fatores. Parece que os praticantes “deveriam ter sabido” que os fatores levariam “inevitavelmente” a um acidente. O viés retrospectivo continua a ser o principal obstáculo para a investigação de acidentes, especialmente quando o desempenho humano especializado está envolvido.
Nesse ponto, concordo 100%. O viés de retrospectiva é a explicação científica da expressão “engenheiro de obra pronta”, que é utilizada nas empresas quando alguém olha o passado com informações do presente, que não eram disponíveis no momento que o problema ocorreu.
Isso é tão presente em seres humanos que tem até um termo na História (ciência) que trata disso, que é o anacronismo.
Portanto, a mensagem é essa: seres humanos tem uma tendência a fazer isso. Portanto, a nossa obrigação se torna reduzir nossos viéses se quisermos ser pessoas que estão menos erradas ao longo do tempo.
Os operadores humanos têm papéis duplos: como produtores e como defensores contra o fracasso.
Os praticantes do sistema operam o sistema para produzir seu produto desejado e também trabalham para evitar acidentes. Essa qualidade dinâmica da operação do sistema, o equilíbrio entre as demandas de produção e a possibilidade de falha incipiente, é inevitável. Os estranhos raramente reconhecem a dualidade desse papel. Em tempos sem acidentes, o papel de produção é enfatizado. Após acidentes, o papel de defesa contra falhas é enfatizado. Em qualquer momento, a visão do estranho mal compreende o engajamento constante e simultâneo do operador com ambos os papéis.
Ou seja, quem constrói mantém, ataca dívida técnica e é acionado em caso de incidentes. Essa abordagem se popularizou com a frase abaixo, proferida em 2006 pela então CTO da Amazon.
Ao meu ver, me parece uma prática muito atual e que deve ser mantida por times de alta performance.
Esse texto terá uma segunda parte, com o restante dos tópicos do paper.
Até a próxima!
Você gostou do conteúdo e gostaria de fazer mentoria comigo? Clique aqui e descubra como.
