A filosofia DevOps “Build to Fail” é um risco à segurança?

Quebrando a Lei das Manchetes de Betteridge , a resposta curta é sim. Mas, como acontece com todas as coisas que envolvem tecnologia hoje em dia, a resposta longa é um pouco mais complexa do que isso.

Acredito que o DevOps se tornou bastante difundido em todos os setores. Embora nem todas as organizações adotem todos os aspectos da abordagem ou apliquem a mesma adesão zelosa aos seus princípios como, digamos, a Netflix, é definitivamente uma "coisa" que está acontecendo.

Embora não seja diretamente um ponto de prova, quando perguntamos aos mais de 3.000 entrevistados como a transformação digital estava impactando suas decisões de aplicativos para nosso State of Application Delivery 2018, duas das três principais respostas foram "empregar automação e orquestração em sistemas e processos de TI" e "mudar a forma como desenvolvemos aplicativos (por exemplo, migrando para o ágil)". Para mim, ambas são reações inferidas à adoção de pelo menos partes de uma abordagem DevOps para desenvolver e entregar aplicativos em arquiteturas modernas.

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

Agora, essa frase é um tanto imprecisa, pois ninguém fica sentado projetando sistemas que falham. O que eles fazem, no entanto, é projetar sistemas que sejam resilientes a falhas. Isso significa, por exemplo, que se uma instância (servidor) travar, o sistema deverá ser capaz de lidar automaticamente com a situação removendo a instância inativa e iniciando uma nova para substituí-la.

Pronto! Feito para falhar.

E embora esta seja certamente uma reação desejável – particularmente quando um sistema está sob carga e demanda pesadas – há um risco na abordagem que precisa ser considerado e, espera-se, posteriormente abordado.

Considere a vulnerabilidade do Cloudflare no início de 2017 . A Cloudflare – que tem sido admiravelmente transparente em seus próprios relatos do problema – observa que, basicamente, o problema foi um vazamento de memória (resultando em potencial vazamento de dados) causado por um defeito em uma extensão de um analisador HTTP. Para encurtar a história, o bug causou vazamento de memória, o que fez com que as instâncias travassem. Essas instâncias foram encerradas e reiniciadas porque foram criadas para falhar.    

Só para constar, esta não é uma postagem do tipo "criticando o Cloudflare por um bug". Como desenvolvedor, sou muito solidário com a ideia de que os defeitos de alguém sejam expostos tão publicamente. Sou menos compreensivo em situações em que há pouca consideração em descobrir por que algo está travando, vazando memória ou simplesmente falhando.

Qual é o objetivo do post de hoje. Porque às vezes a filosofia DevOps deixa seus adeptos com uma abordagem laissez-faire para investigação pós-falha.

É perfeitamente razoável reagir a uma falha de serviço/aplicativo encerrando e reiniciando o serviço para garantir a disponibilidade, desde que você investigue a falha para determinar o que a causou. Os aplicativos não travam sem motivo. Se caiu, algo o empurrou. Nove em cada dez vezes, é como um erro não explorável. Não há nada sobre o que escrever um post de blog. Mas a única vez que há uma vulnerabilidade séria esperando para ser explorada faz com que valha a pena o esforço aparentemente desperdiçado nas outras nove. Porque isso é algo sobre o qual escrever um post de blog.

Não é razoável ignorá-lo.

Monitorar e alertar sobre falhas e outros problemas também é um componente essencial de um programa DevOps completo. Esse é o “S” no 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 de DevOps). Também se trata de dados e do estado dos sistemas. Trata-se de garantir que aqueles que podem se beneficiar do conhecimento, saibam. E isso inclui uma falha no sistema.

Uma falha – especialmente uma queda – não deve passar despercebida. Se um sistema no pipeline falhar, alguém deve saber e verificar. Ignorar isso é um risco à segurança. Pior, é um risco evitável porque é seu ambiente, seus sistemas e seu código. Você tem controle total e, portanto, não há desculpas para ignorá-lo.

Então, sim, em poucas palavras, “construir para falhar” pode expor seus aplicativos – e negócios – a riscos de segurança. A boa notícia é que esses riscos são completamente administráveis, se você garantir que a filosofia não fique no papel como "construído para falhar", mas na prática acabe sendo "construído para ignorar uma falha".

Preste atenção às coisas que travam, mesmo que você as reinicie para manter a disponibilidade alta. Você pode evitar que você (e seu negócio) se tornem tendências no Twitter pelos motivos errados.