Player Unknown’s Bug: registrar problemas de causa desconhecida pode nos fazer evoluir?
(engineering.ab180.co)Compartilho a história de como, por meio de uma página de issues criada por acaso, aumentamos a segurança psicológica da equipe e ampliamos o compartilhamento de informações para construir uma organização e um serviço mais robustos.
Ao desenvolver, às vezes nos deparamos com problemas de causa desconhecida.
Especialmente no front-end web, além do estado do servidor e afins, há influência de inúmeros fatores externos, como tipo e versão do navegador, extensões do Chrome etc.
Se não soubermos a causa do problema, ou se a causa não estiver do nosso lado, de repente passei a me perguntar se seria possível construir uma estrutura realmente sólida apenas com postmortems (será que isso não é insuficiente?).
Motivação
Houve uma vez em que levamos 9 horas para receber o reporte de um issue de causa desconhecida e encerrá-lo.
Só depois de dedicar 4 horas ao debugging do issue descobrimos que a causa do problema não estava no código interno nem na infraestrutura, mas em um bug de uma extensão do Chrome do usuário.
Já era difícil identificar onde estava a causa do problema, mas fiquei especialmente irritado comigo mesmo por ter levado nada menos que 4 a 5 horas para perceber que a origem era externa.
Criei no Notion uma página chamada Player Unknown’s Bug(PUB) e, junto com a frustração, organizei o que tentamos durante a resposta ao issue, o que deixou a desejar e o que seria bom melhorar.
Consolidação como cultura, e evolução
Ao fazer a retrospectiva, conversamos sobre a causa do issue, o que aprendemos adicionalmente ao investigar e os pontos em que fizemos julgamentos equivocados. Os membros da equipe apontaram dúvidas e pontos que valia a pena melhorar, e reunimos isso para estabelecer um processo de resposta a incidentes.
O que foi bom nesse processo é que a equipe se identificou com as dificuldades sentidas durante a resposta ao issue, e também houve a diversão de compartilhar coisas novas que aprendemos. Além disso, criamos um checklist para que, em situações parecidas, fosse possível identificar o problema mais rapidamente. Depois de conversar com o time, isso foi adotado como uma cultura oficial.
A organização de desenvolvimento da AB180 já realiza postmortem por padrão. Se o postmortem interno é centrado em Resolution e Action Items, o PUB tem como objetivo registrar Lesson Learn, formar segurança psicológica em relação à resposta a issues e organizar os fatores que devem ser verificados primeiro em problemas desconhecidos.
Uma cultura de compartilhamento voluntário de informações
À medida que isso se consolidou no time, os issues tratados por outros membros também começaram a se acumular, um a um.
Durante as retrospectivas, o tempo para falar sobre pontos que não conhecíamos e investigar mais a fundo começou a funcionar, ainda que de forma modesta, como uma sessão voluntária de compartilhamento de conhecimento.
Para expandir um pouco mais essa cultura, estamos operando um canal no Slack para compartilhar com frequência o que aprendemos e o que descobrimos. Até agora, tem funcionado bem.
Lesson Learn
- É preciso aumentar a segurança psicológica de toda a equipe que respondeu ao incidente e, para isso, precisamos conversar mais.
- Quando isso não acontece, os problemas se repetem e se enraíza na organização a ideia de que “problema = algo sobre o qual não se deve falar”.
- Por meio do compartilhamento de informações, é possível criar e até elevar a segurança psicológica da organização.
- E essa cultura de compartilhamento de informações talvez possa começar com algo menos importante do que imaginamos.
5 comentários
Eu fui pelo caminho oposto: hoje saí do trabalho depois de passar o dia inteiro sofrendo com um incidente que, por causa de um determinado fator externo, parecia ter uma causa muito clara, mas que por questões internas eu achava que não dava para resolver facilmente e só podia ficar ali aflito; no fim, era um caso que podia ser resolvido simplesmente alterando uma única linha no arquivo de configuração. Vendo este texto, sinto que ele realmente ajuda bastante.
Você trabalhou muito hoje também. Ainda bem que conseguiu resolver o problema. Às vezes eu ainda me lembro dos problemas que mencionei no texto acima. Naquela época foi difícil, mas acho que agora consigo encará-los com leveza.
Será que, com o passar do tempo, a dificuldade que o kunggom enfrentou hoje também não vai virar uma lembrança agradável? haha
Obrigado por ler meu texto modesto.
Na verdade, tanto antes quanto agora, nunca achei divertido lidar com incidentes.
Por exemplo, o incidente que resolvemos hoje aconteceu justamente em um produto no qual, para a nossa equipe, o acesso direto ao servidor de produção estava bloqueado, então, tirando a fase inicial em que detectamos o incidente e fomos entendendo o que estava acontecendo, e a fase final depois de finalmente conseguirmos permissão de acesso ao servidor, não teve como não nos sentirmos relativamente impotentes. Quando nossa equipe pedia que fossem tomadas determinadas medidas, a equipe de operações dos servidores recusava por questões do lado deles. Não dá para encarar esse tipo de impotência com alegria.
Por isso, o que senti ao escrever o documento de post-mortem antes de ir embora foi algo mais próximo de: ‘de raiva, pelo menos da próxima vez eu não cometo esse erro de novo!’.
Ao ouvir o que você contou, dá para imaginar o quanto isso deve ter sido difícil para você. Como você disse, ao evitar repetir os mesmos erros, não tem como não ir melhorando aos poucos... snif
Na verdade, esse produto é um sistema legado bem antigo, eu o recebi na passagem de responsabilidade há pouco tempo e, assim que o assumi, já chegou uma demanda de alteração de funcionalidade. Por isso, recentemente cheguei a modificar o código, mas era uma parte que não tinha absolutamente nenhuma relação com a falha ocorrida hoje. Então, a parte que de fato causou o problema não foi algo escrito diretamente por mim, mas, se eu conhecesse esse produto mais a fundo, provavelmente teria conseguido resolver o problema muito mais rápido. É isso que mais me deixa frustrado.
E, para completar, a hipótese sobre a causa na qual eu mais confiei logo no início, depois de identificar a situação de indisponibilidade total, na verdade estava apenas meio certa. Acho que foi justamente essa confiança na hipótese que acabou sendo o verdadeiro erro de hoje.