De madrugada, um alerta dispara e ninguém sabe quem deve responder: quem escreveu o código ou quem mantém o servidor. Na leitura de Rolando Bonaccorsi, especialista em gestão de operações de TI e excelência em serviços, a divisão rígida entre quem constrói e quem sustenta um sistema costuma ser a origem de falhas demoradas, e o DevOps nasceu para enfrentar justamente esse impasse.
O que é DevOps e por que ele existe?
DevOps é um conjunto de práticas e de uma cultura de trabalho que reúne as pessoas que desenvolvem um sistema e as que o colocam e o mantêm em funcionamento. O nome junta as duas pontas, desenvolvimento e operação. A ideia central é que a responsabilidade pelo software não termina quando o código fica pronto, mas só quando ele roda de forma estável para quem o usa.
Antes dessa abordagem, em muitas empresas as áreas trabalhavam como departamentos separados, cada qual com metas próprias. Desenvolvimento era cobrado por entregar novidades, e operação era cobrada por manter tudo estável. Os dois objetivos entram em choque com facilidade, porque toda novidade traz algum risco. O resultado era uma fila de pedidos, entregas atrasadas e discussões sobre quem tinha causado cada problema, como num condomínio em que o síndico e os moradores só conversam por bilhetes colados no elevador.
Quais problemas o DevOps tenta resolver na prática?
O primeiro problema é a lentidão entre a ideia e o uso. Sem integração, uma alteração simples pode esperar semanas para ser aprovada, testada e publicada. O segundo é a instabilidade: quando a publicação acontece em grandes blocos, raros e trabalhosos, qualquer erro afeta muita coisa ao mesmo tempo e fica difícil descobrir o que o causou.
O terceiro é a falta de visão compartilhada. Quem desenvolve raramente enxerga como o sistema se comporta sob uso real, e quem opera nem sempre entende as decisões de projeto que explicam certo comportamento. Sob a perspectiva de Rolando Bonaccorsi, o ganho mais duradouro do DevOps está em fazer essas duas leituras se encontrarem, porque um sistema só é bem sustentado quando quem o criou também acompanha o que acontece depois da entrega.
Como funciona a rotina de uma equipe que adota DevOps?
Em equipes que adotam a abordagem, o trabalho segue um ciclo contínuo. Mudanças pequenas são integradas com frequência, testadas de forma automática e publicadas em etapas curtas. A integração e entrega contínuas, prática que une a junção constante do código novo ao existente e a publicação automatizada em etapas, reduzem o tamanho de cada mudança e, com isso, o risco de cada publicação. Se algo der errado, o problema é menor e a volta ao estado anterior é mais simples.
Outro elemento é o monitoramento, isto é, o acompanhamento constante do comportamento do sistema por meio de indicadores e alertas. Em operações de tecnologia, os dados coletados depois da publicação voltam para quem desenvolve, e isso orienta as próximas decisões. Também entra a automação de tarefas repetitivas, como preparar ambientes e rodar testes, que libera as pessoas para o trabalho que exige julgamento e diminui os erros de digitação e de esquecimento.
DevOps é só uma questão de ferramentas?
Não é. Comprar plataformas de automação sem mudar a forma de colaborar costuma gerar pouco resultado, e muitas iniciativas fracassam justamente por esse motivo. Como reforça Rolando Bonaccorsi, a ferramenta ajuda, mas a mudança de fato está em como as equipes dividem responsabilidades, compartilham informação e tratam os erros, sem procurar culpados e com foco em aprender com cada ocorrência.
A aproximação exige apoio da liderança. Em organizações em que as áreas têm metas conflitantes, ela não se sustenta, porque cada lado continua sendo cobrado por coisas opostas. Metas comuns, como a estabilidade e a velocidade de entrega medidas em conjunto, ajudam a alinhar os interesses. Também é necessário investir em treinamento, pois quem sempre trabalhou numa só frente precisa aprender o vocabulário e as preocupações da outra.
Por onde uma empresa pode começar?
O caminho mais seguro é escolher um sistema de importância moderada e começar por ele, em vez de tentar transformar tudo de uma vez. A equipe mapeia as etapas entre o código pronto e o uso real, identifica onde há espera ou retrabalho e ataca os gargalos um a um. Automatizar primeiro os testes e a publicação costuma render ganhos visíveis e ajuda a convencer quem ainda está cético.
No entendimento de Rolando Bonaccorsi, vale acompanhar poucos indicadores desde o início, como o tempo entre a alteração do código e a sua publicação, a frequência das publicações e o tempo para restabelecer o serviço após uma falha. Com esses números à vista, a conversa sobre melhoria deixa de depender de opinião e passa a se apoiar em evidências. O DevOps, nesse sentido, é uma prática de melhoria contínua, que se ajusta ao tamanho e à maturidade de cada organização.