A automação muitas vezes está envolvida de maneiras contra-intuitivas em incidentes de software (por exemplo, impedindo a resolução ou complicando a resposta humana).
Separar tasks inteiramente por aquelas que a automação lida e aquelas que os humanos lidam influencia o design dos sistemas de maneiras que dificultam a resolução de incidentes.
A automação pode degradar o conhecimento humano e a aquisição/manutenção de habilidades de maneiras não antecipadas devido ao fato de os humanos terem menos experiência com os sistemas destinados a serem executados pela automação.
A ciência cognitiva pode informar um melhor design de sistemas e ferramentas que incorporam ou dependem da automação usando princípios de Sistemas Cognitivos Conjuntos.
Idealmente, os designers de sistemas de software complexos implementariam a automação como uma forma de aumentar e melhorar o trabalho humano, em vez de tentar substituí-lo.
Em 1º de agosto de 2012, a Knight Capital Group, uma empresa de serviços financeiros, lançou uma atualização que acabou fazendo a empresa perder 460 milhões de dólares em vinte minutos, impactando severamente as avaliações de inúmeras outras empresas. No dia seguinte, o valor da Knight Capital despencou em setenta e cinco por cento, levando à sua aquisição a uma fração de seu valor original e à eventual dissolução da empresa. Mais de uma década se passou desde que um processo automatizado contribuiu para a queda de uma grande empresa financeira em minutos. E ainda assim, nossa compreensão e crenças sobre automação não evoluíram enquanto avançamos para uma indústria dominada por IA. Essa crença é parcialmente impulsionada pela noção de que a IA pode abordar as limitações da automação tradicional.
Nossa pesquisa lançou luz sobre essas suposições e limitações, e como elas continuam a causar estragos em sistemas de software que são cada vez mais dependentes da automação (e, cada vez mais, da IA). Abaixo, apresento algumas das suposições e equívocos comuns sobre automação e seu papel em software (e incidentes de software), o que nossa pesquisa descobriu sobre como a automação aparece em incidentes de software, e algumas ideias sobre como as pessoas podem projetar melhor ferramentas automatizadas para ajudar as pessoas a lidar melhor com incidentes de software.
Mitos e Equívocos Sobre a Automação
Embora a automação esteja envolvida em quase todo software neste ponto, fiquei curioso sobre como ferramentas/sistemas projetados para operar de forma independente dos humanos podem, de fato, contribuir, ajudar ou estar de alguma forma envolvidos em incidentes quando o software não funciona como projetado ou esperado – coisas como pipelines de implantação CI/CD, ou autoescalonamento de pod Kubernetes. Meu interesse em pesquisar o papel da automação em incidentes de software surgiu tanto de inúmeras histórias e anedotas que conheço de pessoas nos domínios de SRE e resposta a incidentes, quanto de observar a forma como a IA continua a dominar conversas técnicas, ferramentas e produtos.
A pesquisa de outros domínios, como a aviação, demonstrou uma série de mitos e equívocos sobre como a automação contribui para acidentes nesses domínios, e eu me propus a ver se isso se aplicava a incidentes de software. O principal equívoco ao estudar cockpits automatizados e pilotos é a suposição de que a automação deve substituir o trabalho que os humanos fazem.
Esse equívoco foi descrito na pesquisa de fatores humanos como “alocação funcional por substituição” ou o “mito da substituição”, promovendo a ideia de que tudo o que precisamos fazer é dar tarefas separadas a computadores e pessoas de acordo com suas forças. O mito da substituição refere-se à suposição equivocada de que a automação pode simplesmente substituir funções humanas em um sistema sem alterar fundamentalmente como o sistema ou o trabalho humano opera.
Esse equívoco é construído sobre suposições como HABA-MABA (“Humanos São Melhores em / Máquinas São Melhores em”), que assumem que as forças humanas e das máquinas são fixas, e o design do sistema é simplesmente uma questão de alocar tarefas de acordo.
Pesquisadores argumentam que essa abordagem baseada em substituição falha porque:
A automação não apenas substitui tarefas existentes, mas transforma o trabalho humano, criando novas tarefas, papéis e desafios.
Essas mudanças são muitas vezes qualitativas e imprevisíveis, não apenas quantitativas.
A crença na simples substituição leva a suposições de design ruins, negligencia necessidades de coordenação e ignora como o trabalho humano real é adaptado na prática.
Essas pesquisas revelaram que a automação, ao contrário dessas crenças predominantes, muitas vezes contribui para incidentes e acidentes de maneiras imprevistas, impondo encargos inesperados aos humanos responsáveis por supervisioná-la ou interagir com ela.
As Consequências Não Intencionais da Automação
O que vimos nos relatórios de incidentes de software do VOID reflete o que os pesquisadores articulavam. Descobrimos que a automação contribui para incidentes de várias maneiras, frequentemente de múltiplas maneiras em um único incidente! A automação pode ser um fator contribuinte para um incidente acontecer, pode alertar as pessoas sobre um incidente, pode (muito raramente) resolver o incidente sozinha e, infelizmente, pode também dificultar ainda mais para as pessoas resolverem o incidente do que se a automação não estivesse presente em primeiro lugar.
Talvez o exemplo mais público disso foi quando os funcionários do Facebook não conseguiram acessar seus próprios datacenters durante uma grande interrupção em 2021. Um comando se propagou automaticamente por seu sistema, que desconectou inadvertidamente todas as conexões em sua rede principal, efetivamente desconectando os datacenters do Facebook globalmente. Isso cascadiou em um problema de DNS que tornou impossível para o resto da internet encontrar seus servidores, ao mesmo tempo que levava mais tempo ativar os protocolos de acesso seguro necessários para que os funcionários do Facebook chegassem ao local e pudessem trabalhar nos servidores.
Em particular, minha pesquisa encontrou muitos dos mesmos padrões que pesquisadores identificaram em sua pesquisa fundamental sobre as ironias da automação. Alguns dos padrões incluem:
Projetar apenas para resultados desejáveis
Os designers de automação tendem a imaginar os resultados desejados da automação (por exemplo, carga de trabalho reduzida, maior precisão) e que apenas esses resultados desejados ocorrerão. Como exemplo, temos toda a área de “erros de configuração”: um pipeline CI/CD é ótimo até que ele empurre uma alteração que derrube todo o sistema, sem sinais de que algo poderia dar errado.
Consequências negativas não antecipadas
A automação não tem acesso a todos os parâmetros do mundo real para uma resolução precisa de problemas em todos os contextos, e pode, de fato, dificultar o impacto direto dos humanos no sistema das maneiras que desejam quando há consequências negativas não antecipadas da automação. As tempestades de repetição são um ótimo exemplo disso em ação, quando a automação está fazendo o que foi supostamente projetada para fazer, mas em circunstâncias extremas, pode agravar muito o problema. Interromper esse processo raramente é trivial.
Desqualificação emparelhada com monitoramento passivo
Os humanos ainda precisam monitorar se a automação está funcionando corretamente, mas frequentemente carecem de conhecimento ou contexto sobre como a automação deve funcionar para saber se está, de fato, funcionando corretamente ou não. Isso se deve ao fato de que o conhecimento adequado do sistema e de como a automação funciona dentro dele requer uso e exposição frequente a ele operando em uma variedade de cenários. Esse tipo de conhecimento só se desenvolve por meio de feedback prático e mãos na massa com o sistema em questão, como ele é eficaz e onde e quando ocorrem casos extremos ou resultados inesperados. Se você já olhou para um painel de alertas sem saber o que exatamente está acontecendo com um sistema que você não conhece, provavelmente já passou por isso pessoalmente.
Novas formas de trabalho humano, não antecipadas
Quando um sistema automatizado falha, a quantidade de conhecimento necessária para corrigir as coisas provavelmente é maior do que a necessária durante operações normais. Isso cria itens de trabalho novos, imediatos e numerosos. Como os designers de automação não conseguem automatizar completamente as partes humanas, o humano é deixado para lidar com o que resta depois que as partes automatizadas não funcionam como esperado, deixando mais complexidade em seu caminho.
Falta de visibilidade na atividade do sistema automatizado
A automação cria sistemas que exigem que as pessoas forneçam inteligência fora ou além das instruções conhecidas. Para depurar um sistema com automação, é necessário entender tanto o sistema geral quanto a automação e o que deveria estar fazendo e como está fazendo errado. Esta é uma tarefa fundamentalmente mais complexa do que sem a automação envolvida! Isso muitas vezes se manifesta em bolsões ou silos de experiência, de modo que quando Amy, a especialista em Kafka, sai de férias, ninguém mais conhece as intricacias dos problemas de reequilíbrio de consumidores como ela.
Como Sistemas Cognitivos Conjuntos Apoiam Melhor os Humanas Trabalhando com Automação
Um Sistema Cognitivo Conjunto (JCS) é aquele em que humanos e máquinas trabalham juntos com base em princípios de esforços cognitivos compartilhados, e não simplesmente dividindo o trabalho a ser feito entre humanos e máquinas separadamente. Em vez de substituir o trabalho humano, o JCS defende tornar os componentes automatizados em “jogadores de equipe” eficazes que podem aumentar e apoiar o trabalho humano.
Em pesquisa feita por Gary Klein e colegas, eles descrevem 10 aspectos chave dessa atividade conjunta coletivamente como:
“… um acordo (frequentemente tácito) para facilitar a coordenação, trabalhar em direção a objetivos compartilhados e prevenir quebras na coordenação da equipe. Isso … envolve um compromisso com algum grau de alinhamento de objetivos. Normalmente, isso implica que um ou mais participantes relaxam seus próprios objetivos de curto prazo a fim de permitir que objetivos mais globais e de longo prazo da equipe sejam abordados”.
É muita coisa para passar por todos os dez elementos chave aqui, mas vale a pena notar que para que haja esse alinhamento de objetivos (e ajuste ao longo do tempo), aqueles que trabalham juntos devem:
Ser mutuamente previsíveis em suas ações
Em tarefas altamente interdependentes, como operações de software, só podemos planejar nossas ações efetivamente quando podemos antecipar com precisão as ações dos outros. Equipes habilidosas alcançam essa previsibilidade por meio de conhecimento compartilhado e seus próprios mecanismos de coordenação que são desenvolvidos ao longo do tempo por meio de extensa colaboração. Apesar da frase comum de “erro humano” em incidentes, em geral, os humanos são bastante previsíveis em seu trabalho, e temos meios estabelecidos para verificar se algo parece imprevisível (chamar, conversar, enviar um e-mail, etc.). Então, no final, esse objetivo é realmente mais sobre a automação ser mais previsível (e para os humanos terem melhores maneiras de “ver” o que está acontecendo com ela).
Ser mutuamente dirigíveis
Ser dirigível é a capacidade de avaliar e modificar deliberadamente as ações de outras partes em um ambiente colaborativo à medida que a situação e as prioridades mudam (uma realidade muito comum para equipes de software). A coordenação eficaz requer que a resposta de uma equipe às ações umas das outras seja adequada à medida que o trabalho avança.
Manter um terreno comum
Este é o atributo realmente chave de um JCS bem afiado. O terreno comum reflete o conhecimento, as crenças e as suposições pertinentes que todas as partes envolvidas compartilham, permitindo que cada parte compreenda a comunicação que ajuda a coordenar ações conjuntas. A erosão do terreno comum pode, às vezes, levar a uma quebra potencialmente desastrosa do funcionamento da equipe.
Agora, se você está pensando: “Bem, eu não conheço sistemas automatizados que façam isso!” então você não está sozinho, porque eu também não conheço. Não ainda. Estou bastante curioso sobre alguns trabalhos recentes nessa área da Honeycomb. Eles parecem entender muitos dos princípios que descrevo acima e podem articular o porquê (e o porquê não) de usar LLMs e IA:
“À medida que escrever código se torna cada vez mais fácil, entender código se torna cada vez mais difícil. Escrever código nunca foi a parte mais difícil do desenvolvimento de software; sempre foi operar, manter e iterar sobre ele. Para realmente aumentar a produtividade, a IA terá que se tornar melhor em nos ajudar com essas coisas”.
Eu certamente espero que mais designers de ferramentas e sistemas automatizados (e baseados em IA) considerem esses tipos de princípios em seus designs para tornar a automação uma melhor jogadora de equipe e nos ajudar a fazer melhor nosso trabalho. Muitas vezes me perguntam se “uma IA melhor” resolverá esse problema para nós, e minha resposta é sempre a mesma: Se as pessoas que projetam ferramentas de IA não estão considerando esses fatores cognitivos conjuntos, então não, isso não irá. Apenas exacerbará a escala e a taxa em que os humanos terão que enfrentar esses mesmos problemas repetidamente.
Se as pessoas estão interessadas em aprender mais, ajudei a lançar a Fundação Resiliência em Software, uma comunidade diversa e interdisciplinar focada em enfrentar esses tipos de questões em nossa indústria.
Tanto a minha pesquisa (quanto a de outras pessoas) destaca o quão subestimado e mal compreendido é o papel que a experiência humana desempenha no software. Sempre fui fascinado pela experiência humana: como adquirimos, como isso parece (e se sente) em ação, e quão efêmera pode parecer às vezes. É fácil tomar como certo uma vez que ela é estabelecida, e não pode simplesmente ser clonada e escalonada sistematicamente.