À medida que as empresas embarcam na corrida pela digitalização, as organizações de tecnologia precisam fornecer serviços inovadores em alta velocidade, mas mantendo um nível elevado de estabilidade operacional. Entretanto, as pressões para agir com rapidez e agilidade costumam ter um forte impacto negativo sobre a resiliência dos serviços.
Embora as empresas de software de ponta tenham assumido a liderança em questões de resiliência, muitas empresas tradicionais (como as dos setores de varejo, seguros e serviços financeiros, por exemplo) ficaram para trás. Quedas, paralisações e “apagões” de sistemas e também a disrupção dos serviços têm aumentado nos últimos anos, à medida que as empresas vão adotando novas tecnologias, acelerando o desenvolvimento de aplicativos de TI e empreendendo iniciativas promissoras para atingir a escala ideal rapidamente. E essas interrupções e disrupções continuam acontecendo apesar de as empresas não tecnológicas terem investido maciçamente na criação de redundância nos serviços – como dispositivos em hot standby [em que os sistemas primário e secundário operam simultaneamente], serviços de backup e restauração em tempo real, melhor planejamento da recuperação de desastres e funcionalidades de autocorreção do sistema.
A crise da COVID-19 acrescentou uma nova dinâmica, em que o trabalho remoto, os picos de utilização de redes e a necessidade de se adaptar rapidamente às preferências digitais dos clientes criaram novas tensões.
Há muito mais em jogo do que os líderes costumam imaginar. Certo varejista de grande porte perdeu $ 5 milhões em vendas quando seus sistemas caíram por várias horas em um dia de compras movimentado. Certa empresa de software viu suas receitas despencarem 8% depois que uma falha no sistema interrompeu os serviços. Certo banco perdeu $ 10 milhões em receitas, além das multas decorrentes, quando a paralisação do sistema se estendeu por vários dias. O Ponemon Institute estimou que o custo médio de uma paralisação não planejada chega a quase $ 9.000 por minuto, ou $ 540.000 por hora1. Isoladamente, cada um desses custos pode não parecer grande coisa. Mas a realidade é que as empresas frequentemente têm de lidar com centenas, até milhares, de incidentes de resiliência por ano, e os custos aumentam rapidamente, muitas vezes sem que TI consiga compreender a verdadeira dimensão do problema. Além do impacto financeiro, há um custo em termos da satisfação dos clientes e da produtividade dos funcionários.
Infelizmente, o modo como muitas organizações de TI dos setores mais tradicionais lidam com problemas de resiliência lembra aquela história de “enxugar gelo”. Quando os sistemas falham, a primeira prioridade de uma organização é restaurar os serviços. Para fazer isso rapidamente, a maioria das equipes de tecnologia compreensivelmente busca soluções capazes de resolver o problema o quanto antes. No entanto, correções táticas que funcionam bem em uma crise nem sempre funcionarão na seguinte, pois os tipos de problema variam enormemente. Como resultado, muitas organizações enfrentam ciclos de triagens ininterruptas, corrigindo um problema aqui só para descobrir outro surgindo ali.
Para romper o ciclo, as empresas precisam abandonar essa postura reativa a emergências. Em nossa experiência, existem quatro práticas que as empresas tradicionais podem adotar para melhorar sua resiliência tecnológica, reduzir o risco de incidentes e mitigar o impacto desses incidentes nos negócios e nos clientes.
1. Vá além dos gatilhos imediatos da crise e busque as causas-raiz e os padrões subjacentes
Eventos de surto, como um pico repentino de tráfego, costumam ser sintoma de um problema maior – como planejamento malfeito da capacidade, testes de desempenho ou de carga inadequados, ou arquiteturas rígidas que quebram com facilidade.
Empresas que possuem resiliência tecnológica estão sempre atentas a esses gatilhos e buscam descobrir os padrões que existem por trás deles. Alguns desses padrões podem ser identificados mapeando-se a quantidade e o tipo de incidentes por área (veja Quadro). Uma vez identificado o padrão – seja no desenvolvimento, na configuração, na gestão de modificações ou em outra área –, as empresas devem seguir as pistas e ir mais a fundo na área problemática a fim de determinarem o que está causando as falhas persistentes.
Por exemplo, certa empresa descobriu que falhas humanas e testes emergenciais eram fatores presentes em 60% das quedas do sistema nos três anos anteriores. Em conversas com os desenvolvedores, constatou que havia algumas questões culturais envolvidas. Pressionadas para atingirem metas agressivas de lançamento, as equipes confiavam demais que os casos de uso seguiriam uma “trajetória perfeita” (isto é, tudo funcionaria conforme planejado) e dedicavam atenção insuficiente às exceções. Embora limitar o desenvolvimento de casos de uso a essas trajetórias perfeitas permitisse que os códigos programados entrassem em produção mais rapidamente, o produto resultante era menos estável. Quando entendeu claramente a causa-raiz, a empresa foi capaz de realizar melhorias sistêmicas, como redesenhar os incentivos de desempenho para recompensar a qualidade, além de agilizar e fortalecer seus sistemas de monitoramento, reduzindo o número de incidentes subsequentes em até 30%.
2. Integre e automatize para prevenir problemas e detectá-los mais cedo
Não é incomum que uma empresa tenha ambientes separados de desenvolvimento, teste e produção. Do mesmo modo, os processos de monitoramento também podem ser fragmentados e manuais. Existem ferramentas capazes de monitorar partes da jornada de desenvolvimento, mas não toda ela; por isso, as equipes de incidentes podem não receber alertas em tempo hábil.
Para resolver esse problema, recomendamos que as equipes identifiquem as jornadas do cliente mais críticas e modernizem e automatizem os processos subjacentes de ponta a ponta. Por exemplo, os testes de desempenho e de carga para os canais do cliente podem ser mais rigorosos a fim de permitir o melhor gerenciamento dos picos de log-in de clientes. Certa grande instituição financeira resolveu esse problema criando um único console de gerenciamento para monitorar e agregar os alertas de todas as jornadas relacionadas a seu aplicativo móvel. Esses alertas foram integrados ao seu sistema de tíquetes de tal modo que, agora, um tíquete de incidente é aberto automaticamente quando qualquer anomalia relevante é detectada. Isso permitiu a detecção precoce de anomalias e reduziu a quantidade de incidentes em cerca de 8% seis semanas após a implementação. Além disso, muitas empresas estão investindo em sistemas autocorretivos em que scripts automatizados são executados quando ocorre uma anomalia. Esses scripts podem executar uma ampla gama de tarefas, como atualizar os servidores, provisionar armazenamento extra ou até mesmo aplicar os patches mais recentes.
A maioria das organizações também precisa melhorar a forma como lida com pedidos de modificação. Com demasiada frequência, os pedidos emergenciais de modificação são agrupados com os demais pedidos de rotina, fazendo com que as equipes sejam obrigadas a triar e priorizar o risco relativo e a urgência de cada pedido por conta própria. Sobrecarregadas, algumas equipes de gestão de modificações e de desenvolvimento de aplicativos recorrem a soluções apressadas, contribuindo para que um número elevado de modificações acabe dando errado.
Para eliminar essa prática, recomendamos não apenas aprimorar a categorização dos riscos, mas também resolver os problemas na origem criando um sistema de pontuação que classifique as equipes de desenvolvimento segundo a quantidade de modificações e a qualidade dos aplicativos. Com tal sistema, por exemplo, equipes com pontuação baixa não seriam autorizadas a efetuar mudanças na produção além de certo limiar.
Certa instituição financeira que implementou essa abordagem notou uma extraordinária melhoria. Obter uma pontuação elevada tornou-se motivo de orgulho para os desenvolvedores, que passaram a ser recompensados com incentivos de desempenho. Motivadas a criarem produtos de melhor qualidade, as equipes elevaram entre 25% e 40% a sua pontuação média de risco ao longo de um período de seis meses. Para o longo prazo, as empresas podem investir em sistemas de gestão de modificações que automatizem um grande número desses processos.
3. Desenvolva ferramentas e redes de especialistas para acelerar a resposta a incidentes
Não importa quão robusta seja organização de tecnologia, sempre ocorrerão incidentes. A meta deve ser reduzir a frequência e gravidade dos incidentes e minimizar seu impacto. As empresas podem fazer isso facilitando o acesso das equipes aos conhecimentos necessários e também comunicando-se de modo claro e constante com os clientes e stakeholders.
Soluções inteligentes podem incluir a atualização dos repositórios de conhecimento com ferramentas fáceis de usar que ajudem as equipes a resolverem problemas mais depressa. Por exemplo, painéis de controle e tablets inteligentes podem permitir que os analistas acionem um breve perfil das paralisações. Funcionalidades analíticas incorporadas ao dispositivo examinam então a base de dados de incidentes da empresa, solicitam ao analista que insira detalhes adicionais para filtrar os resultados, e oferecem recomendações, informações de contato e casos de referência para os provedores de soluções contratados. Isso pode ajudar a diminuir o “tempo médio de reparo” (MTTR na sigla em inglês), reduzindo assim o impacto da paralisação.
Facilitar a colaboração e o acesso a especialistas relevantes é igualmente importante. Catalogar os especialistas relevantes – seja em questões de TI como em outros assuntos – e reunir periodicamente os grupos para discussões informais e exercícios simulados têm ajudado os líderes a criar redes mais robustas de especialistas, levando a uma resposta mais rápida e eficaz aos problemas de resiliência.
As empresas precisam dedicar igual atenção a manter os principais stakeholders devidamente informados. A maioria das organizações tem planos de comunicação em caso de crise, mas estes precisam ser revisados periodicamente para garantir que a cadeia de comando responsável por divulgar mensagens sobre os serviços esteja atualizada. Os clientes entendem que paralisações acontecem, mas têm bem menos paciência com longos tempos de espera, relatórios de status desatualizados e interfaces obsoletas ou difíceis de usar. Criar um plano abrangente de resposta a incidentes que anteveja as dúvidas dos clientes, investidores e outros stakeholders pode ajudar muito as empresas a preservarem relacionamentos sólidos.
4. Garanta que as equipes de gestão de problemas tenham estrutura e poder para agir
Para reduzir o risco de haver incidentes repetidos, as equipes de gestão de problemas devem realizar análises postmortem e oferecer recomendações. Todavia, muitas vezes suas sugestões são ignoradas e, caso cheguem a ser implementadas, isso pode levar muito tempo, aumentando a probabilidade de que incidentes semelhantes ocorram antes de serem resolvidos.
Em certa instituição financeira, por exemplo, os gerentes de problemas costumavam demorar até quatro semanas para conduzir uma análise postmortem após um incidente. E levava outras seis semanas até que suas recomendações fossem implementadas. Isso geralmente decorre de acordos de nível de serviço (SLAs) mal definidos ou de equipes de resolução de problemas que simplesmente não os cumprem. Para promover a responsabilização, um SLA deve definir claramente as ações acordadas e as obrigações de cada um para que a gerência saiba quem é responsável por efetuar as modificações necessárias.
O patrocínio da liderança executiva também é importante. Por si mesmas, as equipes de gestão de problemas geralmente não têm influência institucional suficiente para fazer com que suas recomendações sejam implementadas. Mas o envolvimento ativo do CIO pode contribuir para que isso aconteça. Em certa empresa, por exemplo, o CIO incorporou uma revisão do status dos problemas em sua reunião semanal com os responsáveis pela resolução de incidentes. Esse simples passo foi a pressão que faltava para assegurar que recomendações fossem criadas e implementadas em tempo hábil. Passados dois meses, a organização havia reduzido o tempo médio para implementar recomendações de 25 para oito dias.
Os líderes que adotarem as recomendações aqui descritas contribuirão para que suas organizações enfrentem melhor as demandas da crise e do pós-crise. E refletir sobre as seguintes questões ajudará os líderes de tecnologia a iniciar essa jornada:
- Como a adoção digital e a crescente rapidez das mudanças impactaram a resiliência de TI nos últimos anos? E sobre qual área a crise da COVID-19 gerou mais pressão?
- Como a resposta da minha empresa aos incidentes se compara à de empresas similares e à de outros setores em termos do número e da gravidade dos incidentes e dos custos associados?
- Examinando a empresa como um todo, quais problemas geram o maior volume de incidentes? E quais são as jornadas do usuário e do cliente mais afetadas?
- Dentre todos os problemas de desenvolvimento de aplicativos de TI, qual porcentagem só é detectada na produção? E quantas horas de trabalho foram necessárias para localizá-los e resolvê-los? Um processo automatizado seria mais econômico e mais eficaz?
Os CIOs têm de agir rapidamente. À medida que as empresas aceleram o ritmo de desenvolvimento e adoção de ferramentas, canais e modelos de negócio, a resiliência dos serviços de tecnologia terá papel cada vez maior na resiliência geral dos negócios.