Elis Regina, minha cantora favorita, é intérprete de uma música intitulada “Aprendendo a jogar”. Desde que fui convidada para escrever este artigo, fiquei pensando sobre o que poderia colocar sobre “desenvolvimento e operações” e, paralelamente, a tal da música não saía da minha cabeça. A letra fala “nem sempre ganhando, nem sempre perdendo, mas aprendendo a jogar”.

Tenho muita experiência na área e trabalho com administração de sistemas Unix há 14 anos. Uma das coisas mais importantes a serem entendidas desde cedo é que, em uma carreira em tecnologia, aprendizado é sempre parte do processo. Durante os últimos dois anos trabalhando com arquitetura de larga escala, assimilei a importância de aprender com os erros cometidos em diversos níveis – individual, em equipe e na organização como um todo.

Eu trabalho para o Facebook, em Menlo Park, na Califórnia, uma empresa com centenas de engenheiros na área de infraestrutura. Como gerente dessa área, eu passo muito tempo em reuniões. Algumas melhores e mais produtivas que outras. Porém, a que para mim é a mais divertida, e também uma grande fonte de aprendizado, é a que chamamos de “Revisão de Gestão de Incidentes”.

Nessa reunião, falamos a respeito de tudo o que deu errado ao longo da última semana. O processo é extremamente simples. Primeiro, um dos membros da equipe escolhe os incidentes que serão revisados. Para todos esses incidentes, as pessoas que trabalharam nele precisam fornecer algumas informações a respeito do que aconteceu, e isso inclui:

• Linha do tempo: informações sobre tudo o que aconteceu, na ordem em que aconteceu. Quais os primeiros sinais percebidos de que algo estava errado, o que foi feito para chegar ao problema central, o que foi feito para remediar e, finalmente, arrumar o problema de acordo com a ordem em que os eventos aconteceram.
• Causa: aqui se fala sobre a causa do incidente (prefiro não exemplificar por aqui). Independentemente do que sejam, todos incidentes precisam ter sua causa devidamente identificada.
• Ações posteriores: todas as ações corretivas relacionadas ao incidente e, principalmente, aquelas que evitarão que ele se repita no futuro.

Pode parecer trivial, eu sei, mas para mim foi um conceito que mudou a minha vida. Em todos meus empregos anteriores, eu jamais tinha vivenciado algo desse tipo e acho que esse processo é de extrema importância para organizações que precisam manter um alto nível de disponibilidade nos sistemas que desenvolvem e mantêm.

Esse tipo de revisão altera toda a percepção do que acontece quando as coisas dão errado.

O time todo deve entender que, quando algo dá errado, independentemente do motivo, o foco de todo mundo é retomar a estabilidade. Se necessário, todo mundo deve parar o que está fazendo para trabalhar em como remediar o problema no curto prazo. Isso pode ser simples ou extremamente complicado e depende muito do que exatamente está acontecendo.

Uma vez identificado o problema, recupera-se a normalidade, e daí começa o processo que, em minha opinião, é o mais legal: tentar fazer com que o mesmo incidente não se repita.

Se o problema foi em uma configuração alterada por engano, precisa-se melhorar o processo de validação da configuração. Isso pode ser unit tests, revisão de diffs ou até mesmo monitoramento. Se o problema foi em um release que saiu quando não deveria, então foca-se em revisar esse processo.

Terminado esse processo, o grupo de pessoas envolvidas se prepara para apresentar o “caso” na reunião semanal. Eles contam a história do que aconteceu e falam sobre o que estão fazendo para evitar reincidência. Daí entra uma parte do processo que eu jamais tinha visto. Essa reunião é frequentada por membros de diversas partes do time de infraestrutura. Então, todas as pessoas que participam dessa reunião perguntam a respeito do incidente, a equipe que está apresentando explica e coleta as sugestões apresentadas.

O intuito aqui não é atribuir culpa, mas fazer com que a equipe que teve o problema receba sugestões de pessoas que estão vendo o processo de um ponto de vista diferente. Geralmente, as pessoas que estão perguntando a respeito dos incidentes não sabem do dia a dia da equipe em questão e não assumem as mesmas coisas que aqueles que têm uma visão “interna” do processo de desenvolvimento e release.

No final das contas, todo mundo sai ganhando: quem está apresentando recebe sugestões do que pode ser melhorado de um ponto de vista de quem não está inserido na rotina da equipe. As pessoas que ouviram a apresentação aprendem mais sobre o que acontece em outras partes da infraestrutura da empresa, e o melhor: todo mundo aprende sobre o que fazer para que o mesmo problema não se repita.

Como canta a saudosa Elis Regina: “vivendo e aprendendo a jogar”.