Quando a diretoria ignorou os alertas do TI, a equipe técnica partiu para uma resposta contundente
(theregister.com)A resposta instrutiva da equipe de TI
- História de "Bruce", que trabalhava na equipe de infraestrutura de internet de um banco australiano.
- Nos primeiros tempos do internet banking, a equipe cresceu rapidamente e a carga de trabalho também aumentou.
- Antes que o uso dos links ISDN passasse da metade, a equipe percebeu a necessidade de comprar links adicionais e enviou uma proposta ao CIO.
A recusa da diretoria e a reação da equipe de TI
- O CIO repassou à diretoria o pedido de compra de links ISDN adicionais, mas ele foi recusado porque o uso atual dos links ainda não tinha chegado à metade.
- Quando o uso dos links passou de 50%, a equipe de TI fez um novo pedido, mas recebeu a orientação de esperar até que chegasse perto de 100%.
A ação estratégica da equipe de TI
- A equipe de TI decidiu ajustar a conexão de rede da diretoria para fazer com que o problema fosse percebido por ela.
- Na primeira semana, reduziu 10%, e depois cortou mais 10% a cada semana.
- Um mês depois, a instalação de links ISDN adicionais foi aprovada, e a diretoria comemorou como se tivesse resolvido o "problema da internet".
Opinião do GN⁺
O ponto mais importante deste artigo é a resposta estratégica da equipe de TI ao desafiar a decisão da diretoria e convencer sobre a necessidade de investir em infraestrutura por meio da experiência real dos usuários. Isso mostra uma abordagem criativa e eficaz para reduzir a distância entre problemas técnicos e decisões de negócio. A história não é apenas interessante para profissionais de TI, mas também traz uma lição que pode ajudar tomadores de decisão não técnicos a entender a importância da infraestrutura tecnológica.
1 comentários
Comentários do Hacker News
Já usei um software de terceiros horrível que causava grandes problemas para clientes
Estávamos criando uma solução interna para substituí-lo, mas algumas pessoas queriam renovar o contrato e continuar usando o mesmo software cheio de bugs
Fizemos com que todos os tickets abertos pelos clientes fossem encaminhados ao grupo que defendia manter a solução antiga, e no fim, depois que migramos para o nosso sistema, os problemas praticamente desapareceram
Muitas vezes, quem está na linha de frente heroicamente impede que essa dor chegue aos níveis superiores, e a organização, em vez de eliminar o problema, passa a colocar pessoas como se fossem analgésicos e acaba viciada nesse estado
O sistema legado não conseguia fazer nada além do que já fazia sem uma grande reestruturação, e a equipe responsável acreditava que, se não compartilhasse conhecimento, teria emprego garantido para sempre
O novo sistema sofria com lentidão no banco de dados porque o pessoal achava que bastava adicionar mais CPU em vez de corrigir as queries
As duas equipes sentavam uma ao lado da outra, mas não se falavam, e a equipe do sistema legado chegou ao ponto de denunciar como bomba um pacote embaixo da mesa do diretor de TI
A equipe do novo sistema acabou chamando a Oracle, e a Oracle reescreveu as queries
A capacidade de explicar claramente os riscos e mostrar como consequências técnicas afetam o negócio é uma competência essencial para quem trabalha com TI
Talvez a diretoria desse banco fosse realmente absurda de tão lerda, mas também pode ser que a equipe técnica não tenha explicado direito
Talvez por eu estar dentro da área, sinto que nos comunicamos bastante bem, e com precisão
O problema real é que a política da gerência intermediária distorce tudo
Para o time, você pode dizer “eu estraguei isso e preciso consertar”, mas mais acima há gente que inventa todo tipo de desculpa para não voltar atrás nem em decisões pouco importantes
Talvez alguém já tenha vendido ao chefe a ideia de que aquele equipamento ainda daria para usar por mais 10 anos
Trabalhando com colegas, vejo que eles se esforçam bastante para explicar em vários níveis de profundidade, de acordo com quem vai receber a explicação
O que acontece com mais frequência é que a alta direção e os gestores logo abaixo simplesmente não se importam
Eles já têm na cabeça um “grande plano”, e não importa quantas vezes os desenvolvedores digam que aquela fantasia não pode virar realidade
Na maioria das vezes, eles entendem perfeitamente o que estamos dizendo
Não é que estejamos jogando jargão obscuro que só nerds de elite entenderiam, é só que eles não ligam
Queria que houvesse menos empresas comandadas por gente de mentalidade MBA, sem cabeça nem coração, e mais organizações em que engenheiros assumem responsabilidade, mas a vida é assim
A TI corporativa nasceu como área de apoio ao trabalho administrativo, e no começo era tratada como um departamento sem importância, porque não era preciso planejamento estratégico para garantir que um fax ou um PC funcionasse
É fácil achar que o problema são pessoas de terno sendo mesquinhas, burras ou incapazes de entender tecnologia, mas na prática muitas vezes também é falta de habilidade de comunicação
No meu primeiro emprego, o CFO continuava recusando o pedido de um sistema de backup decente para o AS/400
Naquele AS/400 estavam o ERP, o CRM, a contabilidade e basicamente toda a operação da empresa, e fazer backup do trabalho de 300 pessoas em disquetes de 8 polegadas simplesmente nunca foi viável
Um dia houve uma grande falha de disco, e a empresa inteira parou por semanas; processamento de pedidos, chamados de suporte, propostas de vendas e até consulta a números e endereços de clientes ficaram bloqueados
Se bem me lembro, alguns discos foram enviados para a Kroll Ontrack
Só depois desse desastre compraram equipamento de backup de verdade
Alguns meses depois, um desenvolvedor estagiário executou em produção uma query de delete com a cláusula
wherecomentada, e uma tabela inteira foi apagadaHavia backup, mas uma tarefa em segundo plano detectou isso e recriou 4 anos de faturas, enviando e-mails para cobrar novamente todos os clientes antigos
O ambiente de testes apareceu pouco depois
Há pouco tempo trabalhei em uma faculdade comunitária isolada, onde todos os dados estavam em um velho AS/400 que caía por um ou dois dias a cada poucas semanas
Não havia backups, o tape drive estava quebrado, e peças como uma NIC de 10Mbps, já ultrapassada até para a época, nem tinham substitutas disponíveis
Eu insistia que precisávamos substituí-lo ou migrar para um servidor na nuvem, mas a resposta era sempre “não está no orçamento” ou “é caro demais”
Pelo uso real, o custo seria de apenas algumas centenas de dólares por mês, o que não fazia sentido diante do risco de a faculdade inteira colapsar e até fechar permanentemente se o sistema morresse
No fim, a falha aconteceu, e durante alguns dias o terminal principal funcionava, mas o sistema não se comunicava de forma alguma com a rede
As pessoas começaram a entrar em pânico, e surgiu até a ideia de chamar um especialista em reparo de AS/400 que cobrava mais de 100 dólares por hora
Como última tentativa, consertei a NIC e, ao avisar que o sistema tinha voltado, também deixei claro que aquela podia ser a última inicialização, então precisávamos fazer backup em algum lugar antes disso
Seis semanas depois, tínhamos um AS/400 novinho baseado em nuvem, e fizemos o funeral daquele velho monstro pesado ao desligá-lo pela última vez
O total de horas de funcionamento tinha sido de quase 25 anos
Dá para dizer que essa história é improvável ou totalmente inventada, mas eu não acho isso
Para conseguir fazer algo acontecer em uma organização grande, a liderança precisa sentir a minha dor
Não é cinismo; é assim que o mundo funciona
Quem espera que a outra pessoa percorra sozinha todos os passos mentais necessários para entender a situação vai ter uma surpresa bem desagradável
Mesmo no começo dos anos 90, ISDN provavelmente não era comum fora de escritórios de filiais
E, quando entra a conversa sobre traffic shaping/QoS, fica ainda mais difícil acreditar
Pelo que eu sei, os roteadores Cisco 2500/2600, que quase todo mundo usava na época, só passaram a oferecer esse tipo de recurso bem mais tarde
Talvez quisessem dizer T1, e a história passa bem uma sensação de r/thathappened
Por definição, gestores fazem um trabalho diferente do pessoal operacional
Por exemplo, como fazer um gestor sentir a dor de uma base de código caótica?
No trabalho, tentamos economizar configurando um roteador Cisco 1604 ISDN para não ficar sempre conectado e usar discagem automática
Aí descobrimos que um IBM AIX com um pacote de navegador web instalado fazia, a cada hora, uma chamada de telemetria periódica para a Big Blue, impedindo a rede do laboratório de cair para o estado ocioso
Adicionamos uma regra de firewall no roteador para bloquear essa esperteza discreta
Mesmo no fim dos anos 90, Microsoft, Sun e Novell não eram tão descaradas com telemetria quanto a IBM
O verdadeiro problema revelado aqui é que o pessoal de TI precisa de autonomia para executar, até certo ponto de forma independente do lado de negócios, aquilo que sabe ser o correto
No fim, o quanto de supervisão uma organização acha necessário depende de confiança
Onde eu trabalho, se algo não afeta o cliente, não preciso pedir permissão
Se uma máquina parece sobrecarregada ou um plano SaaS está chegando perto do limite, eu simplesmente faço o upgrade
Às vezes alguém pergunta sobre uma nova cobrança ou aumento de custo, mas não preciso passar por vários interrogatórios só para tocar o trabalho
As pessoas de terno deveriam pensar nas desvantagens de um ambiente em que é preciso implorar autorização até para tarefas técnicas triviais
Quantas inovações não estão indo direto para a lata de lixo em chamas por causa de políticas complexas de mudança criadas em torre de marfim há mais de uma década?
Não daria para repensar a organização modelando o negócio como cliente da equipe de TI?
Se a empresa fracassa, a organização de TI também perde sua razão de existir, então isso parece uma forma de pensar muito mais simples
Portanto, a relação custo-benefício muda e a comunicação é necessária
Quando vejo reações no estilo “seu trabalho é respeitar as decisões da hierarquia”, lembro o quanto as organizações corporativas ainda permanecem presas a uma mentalidade militar
No antigo exército prussiano, as missões eram passadas com foco no objetivo
Algo como “eu estou tentando alcançar X, você fica responsável por Y, e outras unidades fazem Z”, enquanto a execução ficava a cargo do oficial local, que via a situação real e também tinha o conhecimento necessário
Além disso, se um oficial ou suboficial discordasse de uma ordem do comandante direto, podia apelar para níveis superiores
Somando isso ao sistema de oficiais de estado-maior, em que esses oficiais também precisavam ter experiência de comando durante a formação e podiam até neutralizar ordens de comandantes, o resultado era uma estrutura forte e flexível, capaz de se adaptar a situações em mudança
Os oficiais não hesitavam em discutir com superiores, escalar a questão para cima ou, se realmente considerassem necessário, recusar ordens
Porque isso gera concordância e participação das patentes mais baixas
A ideia era tomar decisões no nível mais baixo possível
Isso perdeu um pouco de força na era moderna, mas, até onde eu sei, nenhum exército funciona puramente na lógica de “seu trabalho é obedecer às decisões hierárquicas”
Um exemplo é o livro Extreme Ownership
Talvez eu esteja sendo maldoso demais, mas com uma liderança dessas eu simplesmente procuraria outro emprego e deixaria o navio afundar
Simplificando do ponto de vista da liderança, imagine que todo ano chegam 100 propostas parecidas, e cada uma custa 1 milhão de dólares
Mesmo sem considerar depreciação ou manobras tributárias, isso já representa 100 milhões de dólares em custo puro por ano
Mesmo para um banco, é muito dinheiro, e precisa ser usado estrategicamente, não desperdiçado
Nesse cenário, fazer a liderança sentir a dor e entender instintivamente por que este 1 milhão específico é bem empregado é, de certa forma, uma estratégia saudável para a liderança, para a TI e para o negócio
Também existe o fato de que executivos são as pessoas encarregadas de administrar o tempo, os funcionários, os custos e outros recursos finitos da empresa
Claro, em geral eles não fazem isso particularmente bem, e pode-se argumentar que a escolha puramente racional do ponto de vista da empresa seria dar a eles uma remuneração menos luxuosa, mais próxima da dos demais funcionários
Mas quem decide não é “a empresa” como entidade abstrata, e sim pessoas, e aí entram jogo político, incentivos e interesse próprio
Os executivos controlam o fluxo de informação, decisões, recursos e dinheiro e, por isso, agem como parasitas sugando uma parcela excessiva da empresa hospedeira
A solução para esse problema fica como exercício para o leitor
Se tudo o que ouviram foi “prevemos que por volta de X dia o circuito estará 50% saturado”, então a TI realmente explicou muito mal
Nós sabemos que, nessa tecnologia, 50% de saturação já significa latência para o cliente ou erro de conexão
Nesse caso, seria preciso dizer “esperamos que por volta de X dia os clientes comecem a ter problemas de conexão”
Se você sabe que o limite de 100% é um valor teórico alcançável apenas em condições ideais, então precisa falar com base no limite realmente utilizável
Para que as pessoas tomem decisões com base em informação, é preciso dar a informação correta, e se quem recebe para entender a tecnologia é a TI, então também faz parte do trabalho da TI comunicar essas características de um jeito que as pessoas de terno consigam entender
Claro, eles podem até ter feito o melhor possível, mas, olhando só o texto, parece que mandaram apenas um memorando sem esse contexto
Não entendo muito bem usar a expressão “50% de utilização” como se fosse abrir a torneira só até a metade
Se a carga se concentrar em picos em um único link, de qualquer forma não vai haver degradação intermitente de desempenho?
A proporção de tempo em que se tem uma “experiência ruim” parece aumentar rapidamente dependendo da distribuição, então mesmo com 60% já pareceria difícil de aguentar
Fazendo uma comparação, é como um bar decidir colocar só 1 atendente olhando apenas para a demanda média, e então chegar a noite de sexta-feira
É exatamente isso que a fórmula de Kingman diz
“Quando a utilização passou de 50%, a equipe de TI propôs pedir ISDN novamente. E foi rejeitada de novo. Junto com a instrução de não perguntar outra vez até que a utilização chegasse perto de 100%.”
Isso se parece muito com a percepção das autoridades sobre a covid
Parece que os responsáveis olham para a tendência existente e não conseguem fazer nenhum tipo de previsão, reagindo só quando o desastre já está diante dos olhos