Gastar agora, pagar depois? Como ajustar a conta da dívida técnica

Quando um cliente de serviços web muda uma configuração, e setores imensos da internet ficam inacessíveis como resultado, você sabe que chegou a hora de abordar erros de configuração e dívida técnica. A parada da Fastly, que fez com que diversos serviços de notícias mundiais, áreas do site .gov do Reino Unido e alguns sites da Amazon ficassem desativados por mais de uma hora, colocou subitamente as configurações de software e a administração de infraestrutura debaixo dos holofotes – exatamente onde deveriam estar, em minha opinião.

Dívida técnica é um conceito complexo, que já tem décadas, e erros de configuração relativamente simples como os da Fastly são apenas um exemplo bastante visível de um problema muito mais abrangente. Mas o que significa, o que abrange e o que os líderes de TI e segurança deveriam fazer?

Desenvolver agora, pagar depois?

A questão da dívida técnica é discutida há muito tempo na comunidade de desenvolvimento de software, mas atualmente todas as empresas e departamentos operam em um mundo digitalmente transformado e interconectado, e aparentemente a hora de pagar está chegando. Essencialmente, dívida técnica é a diferença entre o “preço” (tempo, recursos humanos, investimento em tecnologia) que um projeto técnico deveria custar para ser perfeito e à prova de futuro, e o “preço” que uma organização está disposta a pagar na ocasião.

No entanto, não vivemos em um mundo perfeito e um projeto após o outro vão acumulando pequenos valores de dívida técnica – o que deve ser abordado em algum momento antes que um projeto desenvolva falhas, não possa ser atualizado ou deixe totalmente de funcionar. Como nós trabalhamos em organizações com vários produtos e que mudam constantemente, é muito fácil que montantes significativos de dívida técnica se acumulem, item a item, e resultem em um incidente em grande escala que pode causar uma violação, um ataque digital ou um incidente de continuidade de negócios.

Na minha opinião, existem três grandes áreas em que a dívida técnica se acumula, e que empresas e líderes de TI devem monitorar como parte de seus programas contínuos de avaliação de riscos.

1. Investimento redirecionado

Toda empresa evolui, optando por redirecionar orçamento e recursos para tecnologias ou produtos novos ou diferentes, enquanto os produtos mais antigos permanecem “embarcados” mas não têm o mesmo nível de suporte que tinham antes. Tudo bem, é normal. No entanto, se não forem implementados planos de fim de vida útil, as empresas correm o risco de ficar com produtos que foram criados com códigos desatualizados e não podem ser atualizados para as versões mais recentes dos sistemas operacionais, resultando em falhas de segurança significativas.

Quando o investimento em determinados produtos termina, o ambiente de códigos também não é atualizado. Isso pode causar problemas de manutenção e administração, erros de configuração e vulnerabilidades.

As mudanças nos investimentos não impactam apenas produtos mais antigos a caminho da aposentadoria. Também observamos dívida técnica em produtos ativos, quando um cenário de desenvolvimento ideal resulta em tempo e investimento significativos, mas um produto viável pode ser criado em um cronograma mais curto, mesmo que não seja perfeito. Encontrar esse equilíbrio entre perfeição, funcionalidade apropriada e viabilidade mínima é um desafio, e algumas pessoas podem se ver em uma situação em que são prometidas melhorias para quando o projeto estiver concluído, mas depois as prioridades de negócios mudam e os planos não são implementados.

É claro que administrar a dívida técnica nesses cenários é um desafio muito real para as equipes de liderança. Na minha opinião, pode-se encontrar um ponto ideal com administração cuidadosa, mas os líderes de TI e negócios precisam trabalhar de perto com as equipes de desenvolvimento, definindo objetivos claros e ajudando a criar um produto que seja satisfatório para o desenvolvedor de software, seguro e de baixo risco, e aceitável para o líder que quer entregar um produto em um prazo limitado.

2. Tecnologia física

De forma semelhante, os data centers físicos cheios de roteadores, firewalls e servidores precisam ser mantidos. Eu já vi muitos exemplos de data centers em que houve investimento e depois abandono, sem administração adicional, por até quatro anos.

Este desenho é um bom resumo: operar em sistemas complexos, em que novos serviços foram adicionados ou anexados a sistemas legados, pode deixar uma empresa em situação precária.

Dependency: https://xkcd.com/2347/

Infelizmente, com frequência são alguns de nossos serviços mais críticos que sofrem com desafios de integração com sistemas legados, embora isso esteja sendo abordado lentamente. Serviços financeiros e cuidados de saúde sofreram paradas, violações e ataques que podem paralisar serviços críticos subitamente. A infraestrutura crítica com frequência é construída com TO (tecnologia operacional) proprietária, o que, quando conectada a serviços digitais modernos, pode deixar as organizações abertas ao risco. Se considerarmos também o número imenso de pequenas empresas que compõem a cadeia de suprimentos para as grandes corporações, governos ou infraestruturas críticas, existe uma tempestade perfeita de tecnologias legadas e sem suporte.

3. Pessoas

Talvez a parte mais importante da dívida técnica sejam as pessoas. Com frequência, os sistemas de software foram desenvolvidos ao longo de décadas e são mantidos por equipes de trabalhadores com experiência significativa, conjuntos de habilidades de codificação mais abrangente (por exemplo, PERL x Python) e anos de conhecimentos institucionais. Essas pessoas consertam, fazem manutenção e administram as tecnologias e os serviços mais antigos, híbridos ou subfinanciados.

No entanto, à medida que as empresas evoluem ao longo do tempo, e os líderes adaptam estratégias e redirecionam recursos para novos produtos e serviços, os sistemas desenvolvidos com códigos mais antigos podem ser negligenciados. A mudança organizacional pode deixar as pessoas se sentindo desautorizadas, o que aumenta o risco de ameaças internas – e isso é especialmente relevante se essas pessoas administram infraestruturas críticas de TI.

O planejamento de sucessão é imperativo, porque todos os trabalhadores acabarão saindo da empresa ou se aposentando e, sem compartilhamento abrangente de conhecimentos, você se arrisca a ter uma situação em que os sistemas antigos precisem ser mantidos por novos funcionários com conjuntos de habilidades de programação muito diferentes. A higiene de segurança diária deve ser mantida em sistemas mais antigos, com aplicação de patches e atualizações, e administração apropriada de configurações.

Como os líderes de TI devem avaliar os riscos e administrar a dívida técnica?

Os líderes de tecnologia devem garantir que os desenvolvedores integrem processos de fim de vida útil em todos os produtos ou projetos de infraestrutura, desde o início. Quando ocorre mudança organizacional, também deve haver mudanças nas avaliações de riscos, na documentação do impacto potencial sobre software e hardware, e na implementação de planos de contingência.

Mesmo em tecnologias que estão no caminho para o fim da vida útil, deve ser feito algum investimento em infraestrutura e recursos humanos. Ao desenvolver softwares novos, adote medidas para investir em um estado futuro e planejar para mudanças – em outras palavras, desenvolva não apenas para escalabilidade, mas também para caminhos de atualização futuros.

Precisamos ter planejamento de sucessão para software, ou corremos o risco de erros de configuração contínuos ou ainda paradas, violações ou ciberataques impulsionados por vulnerabilidades.

Apêndice

Recursos/exemplos adicionais:

• https://www.businesswire.com/news/home/20210615005115/en/4994345/Study-Reveals-Majority-of-IT-Leaders-Consider-Technical-Debt-One-of-the-Biggest-Threats-to-Innovation-as-They-Build-Back
• Erro de configuração no banco de dados da nuvem da CVS Health expõe mais de um bilhão de registros
• https://www.theregister.com/2021/06/18/bofh_2021_episode_8/