A filosofia de DevOps de “construir para falhar” representa um risco à segurança?

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

Contrariando a Lei das Manchetes de Betteridge, a resposta curta é sim. Mas, como tudo o que envolve tecnologia hoje em dia, a resposta longa é um pouco mais complexa do que isso.

Acredito que o DevOps tenha se tornado bastante difundido em todos os setores. Embora nem todas as organizações adotem todos os aspectos dessa abordagem ou sigam seus princípios com o mesmo fervor que, por exemplo, a Netflix, é definitivamente uma tendência em curso.

Embora isso não seja uma evidência direta, quando perguntamos aos mais de 3.000 participantes da nossa pesquisa State of Application Delivery 2018 como a transformação digital estava afetando suas decisões relacionadas a aplicações, duas das três respostas mais citadas foram “empregar automação e orquestração em sistemas e processos de TI” e “mudar a forma como desenvolvemos aplicações (por exemplo, adotando metodologias ágeis)”. Para mim, ambas são reações que indicam a adoção de pelo menos alguns aspectos de uma abordagem DevOps para desenvolver e disponibilizar aplicações em arquiteturas modernas.

Então, se as organizações estão adotando algumas das ferramentas e técnicas relacionadas a DevOps, pode-se presumir que também estejam adotando outras. Uma delas pode até ser (entra a música dramática): desenvolver para falhar.

Essa expressão, porém, é um tanto imprecisa, pois ninguém se dedica a projetar sistemas para que falhem. O que se faz, na verdade, é projetar sistemas que sejam resilientes a falhas. Isso significa, por exemplo, que, se uma instância (servidor) parar de funcionar, o sistema deverá ser capaz de lidar automaticamente com a situação, removendo a instância inativa e iniciando uma nova para substituí-la.

Voilà! Projetado para falhar.

E embora essa seja certamente uma reação desejável — especialmente quando um sistema está sob carga e demanda elevadas —, há um risco nessa abordagem que precisa ser considerado e, espera-se, posteriormente solucionado.

Considere a vulnerabilidade da Cloudflare no início de 2017. A Cloudflare — que foi admiravelmente transparente ao relatar o problema — observa que, basicamente, o problema era um vazamento de memória (que poderia resultar em vazamento de dados) causado por um defeito em uma extensão de um analisador HTTP. Resumindo: o bug causou um vazamento de memória, que fez com que as instâncias falhassem. Essas instâncias foram encerradas e reiniciadas porque foram projetadas para falhar.

Só para deixar claro, este não é um post para “detonar a Cloudflare por causa de um bug”. Como desenvolvedor, solidarizo-me profundamente com quem tem seus erros expostos de forma tão pública. Tenho menos compreensão em situações nas quais há pouco interesse em descobrir por que algo está travando, causando vazamento de memória ou simplesmente falhando por completo.

E esse é o ponto do post de hoje. Porque, às vezes, a filosofia DevOps leva seus adeptos a adotar uma postura de laissez-faire em relação à investigação após uma falha.

É perfeitamente razoável reagir a uma falha de serviço/aplicativo encerrando e reiniciando o serviço para garantir a disponibilidade — desde que, em seguida, você investigue a falha para determinar o que a causou. Aplicativos não travam sem motivo. Se ele caiu, alguma coisa o derrubou. Em nove de cada dez casos, trata-se de um erro que não pode ser explorado. Nada que renda um post no blog. Mas aquela única vez em que se trata de uma vulnerabilidade grave à espera de ser explorada faz valer a pena o esforço aparentemente desperdiçado nos outros nove casos. Porque isso, sim, rende um post no blog.

Não é razoável ignorar isso.

O monitoramento e a emissão de alertas sobre falhas e outros problemas também são componentes essenciais de um programa de DevOps completo. Esse é o “S” do CAMS, que compõe uma abordagem holística de DevOps: Cultura, Automação, Medição e Compartilhamento. Damon e John (que cunharam a sigla em 2010) não estavam falando apenas de pizza e cerveja (embora essa seja uma boa maneira de incentivar o “C” de Cultura do DevOps). Trata-se também dos dados e do estado dos sistemas. Trata-se de garantir que aqueles que podem se beneficiar dessas informações tenham acesso a elas. E isso inclui uma falha no sistema.

Uma falha — especialmente uma pane — não deve passar despercebida. Se um sistema no pipeline parar de funcionar, alguém deve ser informado e investigar o ocorrido. Ignorar isso representa um risco à segurança. Pior ainda, é um risco evitável, pois trata-se do seu ambiente, dos seus sistemas e do seu código. Você tem controle total e, portanto, não há desculpa para ignorá-lo.

Então, sim, em resumo, a abordagem de “projetar para falhar” pode expor seus aplicativos — e sua empresa — a riscos de segurança. A boa notícia é que esses riscos são totalmente gerenciáveis, desde que você garanta que essa filosofia não seja apenas “projetado para falhar” no papel, mas que, na prática, acabe se tornando “projetado para ignorar uma falha”.

Preste atenção ao que falha — mesmo que você reinicie os sistemas para manter a alta disponibilidade. Isso pode evitar que você (e sua empresa) vire assunto no Twitter pelos piores motivos.

Sobre o autor

Lori Mac VittieEngenheiro Emérito e Evangelista-Chefe | F5

Lori MacVittie é engenheira distinta e evangelista-chefe no Escritório do CTO da F5, com ampla experiência em entrega de aplicações, estratégia de automação e infraestrutura. Ela é conhecida por transformar complexidade em clareza, seja definindo diretrizes para agentes de IA, analisando arquiteturas multinuvem frágeis ou investigando os limites de sistemas escaláveis. Ela acumula mais de trinta anos de experiência no setor, abrangendo desenvolvimento de aplicações, arquitetura de TI e operações de redes e sistemas. Antes de ingressar na F5, atuou como editora de tecnologia e recebeu diversos prêmios. MacVittie tem mestrado em Ciência da Computação e é uma autora prolífica, com publicações que abrangem segurança, nuvem e arquitetura empresarial. Ela também é uma entusiasta de jogos de tabuleiro e videogames, além de ter opiniões assumidamente fortes sobre queijos.

Mais publicações de Lori Mac Vittie