dívida técnica ITSM auditoria de TI bus factor segurança da informação

Dívida Técnica em TI: Causas Principais e Riscos Ocultos

A dívida técnica em TI é o preço de compromissos passados, que podem levar a riscos e custos adicionais. O artigo explora as causas, os impactos e como a auditoria de TI pode ajudar a mitigar esses problemas, oferecendo um plano de ação para reduzir a dívida técnica.

MundiX News·10 de maio de 2026·12 min de leitura·👁 1 views

8K+ Alcance em 30 dias ALP ITSM 21,42 Classificação 24 Assinantes Assinar alp-itsm 20 minutos atrás Dívida Técnica em TI: Causas Principais e Riscos Ocultos Simples 12 min 228 Blog da empresa ALP ITSM Administração de sistemas * Segurança da informação * Visão geral Do ponto de vista de um engenheiro, a dívida técnica raramente se parece com um grande problema. É mais como um conjunto: um serviço temporário em um Windows Server antigo, que de repente se tornou crítico; suporte em chats de trabalho sem SLAs e priorização normais; bus factor = 1 em um sistema chave, onde tudo depende de uma pessoa; backups que ninguém testou há muito tempo. Enquanto tudo funciona, isso é considerado um compromisso razoável. Até a primeira falha séria. Olá, sou Avdey Martynovich, chefe da unidade de trabalho com SMB na ALP ITSM. Regularmente entramos em infraestruturas que cresceram por anos com base no princípio de "lançar - então vamos descobrir": CMDB nas cabeças, incidentes e solicitações em um chat, serviços "de teste" em produção, legacy‑monolitos que são assustadores de tocar. Nossa tarefa é honestamente decompor essa dívida técnica, calcular suas consequências e ajudar a negociar com as empresas o que e em que ordem mudar. No artigo, analisamos:

como a dívida técnica se parece em três níveis - pessoas (bus factor, documentação), processos (incidentes, solicitações, alterações), tecnologias (pilha antiga, ausência de plano de recuperação, soluções "temporárias");
como separar a avaliação de engenharia e negócios de "consertar/não consertar";
por que tentar "não tocar em nada" costuma ser mais caro do que uma migração planejada;
e o que a equipe recebe de uma auditoria de TI: não apenas uma apresentação para a gerência, mas também uma lista específica de riscos, melhorias arquiteturais e mudanças de processo. O que é dívida técnica A dívida técnica é o preço dos compromissos de TI anteriores, que permitiram que você fizesse algo mais rápido ou mais barato em algum momento, mas agora estão retornando com riscos e custos adicionais. A dívida técnica são as mesmas decisões "para depois", que foram tomadas há um, dois, cinco anos. Você economizou em arquitetura, tolerância a falhas, documentação, pessoas e processos - e hoje está pagando por isso com tempo de inatividade, trabalho de emergência e restrições para as empresas. Se você for um pouco mais prático, a dívida técnica sempre tem dois lados. No nível de engenharia, são horas de trabalho, licenças, novo hardware, migrações, testes, suporte. No nível de negócios - o custo de uma hora de inatividade, SLA com os clientes, multas, interrupção de entregas, perda de receita. Uma conversa normal sobre dívida técnica se parece com uma comparação de dois números: quanto custa consertar agora e quanto custa não consertar até a primeira falha séria. Se o segundo número for significativamente maior, a questão de "é caro consertar" geralmente desaparece. Não há dívida técnica na contabilidade - existem apenas servidores, licenças e linhas de despesas. Por causa disso, o bloco financeiro simplesmente não o vê, embora a dívida técnica consuma lucros, aumente as perdas e, em algum momento, comece a afetar o custo da empresa. Por causa disso, você não recebe receita suficiente, perde clientes, não cumpre obrigações e paga demais por "reparos de emergência". Você precisa pensar na dívida técnica como um empréstimo com juros. Toda vez que você adia uma atualização "desagradável" ou a substituição de um servidor antigo, você está, por assim dizer, estendendo esse empréstimo por mais um mês. Os juros se acumulam na forma de reparos cada vez mais caros, complexidade crescente de suporte e riscos crescentes de tempo de inatividade. A segunda metáfora são dentes não tratados. Enquanto não dói, parece que você pode esperar. Mas a cada mês de adiamento, o tratamento se torna mais caro e doloroso, e alguns dentes não são mais tratados - eles são simplesmente removidos. Tudo é exatamente o mesmo com a infraestrutura e os serviços de TI. Três fontes de dívida técnica: pessoas, processos, tecnologias Vamos olhar não abstratamente para "alguma TI", mas de forma abrangente, através de uma abordagem ITSM madura. Nele, a TI é sempre composta por três blocos: pessoas, processos, tecnologias. E é exatamente nesses três lugares que a dívida técnica se acumula. Não acontece que tudo seja ruim apenas nos servidores, e as pessoas e os processos sejam perfeitos - sempre há uma queda em algum lugar. A maioria das pessoas olha apenas para hardware e software: "servidor antigo, versão antiga, precisa ser atualizado". E os problemas reais começam onde todos os três componentes convergem: não há pessoas suficientes, os processos são montados no joelho e as tecnologias são mantidas em remendos temporários. Se você já está afundando em pelo menos um dos blocos, você está gradualmente criando dívida técnica. Se houver buracos em todos os três, a questão não é "haverá um acidente", mas "quando exatamente e quanto vai custar". Pessoas: quando tudo depende de um herói Uma imagem muito comum: a empresa tem "aquele" especialista em TI que carrega um ou mais serviços críticos. Ele é o único que sabe como tudo funciona, onde os backups estão localizados, quais são os remendos e o que precisa ser "ajustado para que funcione". De fora, parece conveniente: há sua própria pessoa, todos vão até ele, ele conserta tudo, a empresa está satisfeita. Na verdade, esta é uma mina terrestre de pessoal. Tão logo essa pessoa tiver algo do conjunto "adoeceu, queimou, foi embora, foi demitido" - um serviço crítico para os negócios simplesmente para. E junto com ele, as contas, remessas, documentos de fechamento, relatórios e todos que dependiam desse serviço param. Ao mesmo tempo, buracos no mapa de competências da equipe se acumulam paralelamente. A carga de trabalho está crescendo, o cenário de TI está se tornando mais complexo, novos serviços e integrações estão aparecendo, requisitos de segurança, e a equipe ainda está trabalhando no modo "apagando incêndios, o resto de alguma forma depois". Em algum momento, você de repente descobre que as pessoas fisicamente não conseguem lidar com o volume e a complexidade das tarefas. Mas ninguém fez um inventário honesto de competências, riscos e capacidade - todos simplesmente "carregaram heroicamente". Esta é a mesma dívida técnica que um servidor antigo: dívida de pessoas e de gerenciamento da equipe de TI. Processos: suporte "de alguma forma no chat" O segundo tipo de dívida técnica reside no plano dos processos. Na maioria das vezes, tudo começa de forma simples: eles iniciaram um chat, colocaram um engenheiro lá, disseram à empresa "escreva aqui, pessoal vai ajudar". Enquanto a empresa é pequena e os serviços não são críticos, esse esquema ainda funciona de alguma forma. Mas assim que o número de usuários e sistemas aumenta, os sintomas clássicos começam:
as solicitações são perdidas ou ficam "para pensar" por meses;
todo mundo está pegando fogo, mas ninguém entende o que é realmente crítico;
ninguém é realmente responsável pelo tempo de resposta e recuperação. Não há SLAs/OLAs formalizados, tudo depende de acordos pessoais e da boa vontade de indivíduos. Como resultado, qualquer incidente mais ou menos sério se transforma em caos: a empresa espera que "seja levantado em meia hora", a TI está fazendo algo, mas não há regras comuns do jogo. Se você olhar através da lente do ITSM, incidentes, solicitações de serviço e alterações são misturados em um frasco. Não há categorização e priorização normais (P1–P4 condicionais), não há entrada clara no processo de gerenciamento de mudanças, não há ligação "incidente → investigação → problema → mudança". Formalmente, os SLAs podem existir em uma apresentação para a empresa, mas eles não vivem na operação: não há monitoramento do desempenho real, não há conexão com os KPIs da equipe de suporte, não há estatísticas transparentes sobre reações e recuperação. Os processos de incidentes e solicitações de serviço costumam permanecer inacabados, porque em algum momento foram lançados "como uma solução temporária, então vamos aperfeiçoá-la". Então, como de costume, não aconteceu - e a solução temporária se tornou permanente. Toda vez que você diz "ok, agora não é hora do processo, vamos melhorar depois", você cria dívida técnica nos processos de gerenciamento de TI. E você paga por isso quando tudo cai no momento mais inconveniente. Tecnologias: de um serviço de teste a um ponto único de falha A terceira camada, a mais óbvia, são as tecnologias. Aqui, tudo geralmente começa com a história "vamos lançar um serviço de teste, ver se ele vai, e então decidiremos". Para o teste, ele é colocado na infraestrutura mínima: sem tolerância a falhas, sem backups normais, muitas vezes em algum servidor antigo "para que não seja uma pena". Formalmente, é temporário, "nada crítico" nele. Na prática, geralmente se parece com isto: em algum lugar no canto, o mesmo Windows Server "temporário" com CRM autoescrito, um pedaço de 1C ou uma interface web gira, que ninguém quer mais tocar. Integrações, scripts, agendadores de tarefas são criados em cima disso - e tudo isso funciona com base no princípio de "não toque, enquanto funciona". Ao mesmo tempo, não há monitoramento normal de métricas e estados, nem notificações claras de eventos, nem uma verificação regular da recuperação de backups. É bom se em algum momento "para mostrar" eles levantaram um estande de uma cópia de backup e verificaram se ele realmente começa. Um ou dois anos se passam, as equipes se aproximam, os dados se movem, os processos crescem com esse serviço - e de repente fica claro que metade da empresa já vive nessa "peça de teste temporária". Mas a arquitetura, a tolerância a falhas e o backup ainda estão no nível do teste. Isso também inclui os clássicos do gênero: hardware antigo sem suporte e peças de reposição. O servidor tem dez anos, o modelo foi descontinuado, não há suporte oficial, é quase impossível encontrar peças de reposição para ele, mas ele atende um sistema crítico, e todos têm pena de tocá-lo, porque "de repente não vamos levantá-lo". Uma história separada são as versões desatualizadas do SO e do software de aplicação, nas quais "tudo ainda funciona de alguma forma". Eles não recebem mais atualizações de segurança, o fornecedor se esqueceu deles, mas aplicativos críticos para os negócios estão ligados a eles, que são assustadores e caros para reescrever. Qualquer tentativa de atualização se transforma em uma missão com um final imprevisível, então a atualização é adiada por mais um ano. E por mais um ano. Todos esses "vamos deixar assim por enquanto, funciona" se somam a um cofrinho muito específico de dívida técnica tecnológica. Uma dificuldade separada são as integrações em torno do serviço. Enquanto tudo funciona, eles tentam não tocar neles. Mas no momento da queda, acontece que você precisa levantar não um sistema, mas um "zoológico" inteiro de componentes dependentes, uma fila de tarefas, sincronizações e importações. Quando o CRM "temporário" interrompe todo o atacado Vou contar a história de uma das empresas, em seu exemplo é claramente visível o que leva a ignorar o trabalho com dívida tecnológica. Em 2017, era uma pequena empresa atacadista: um armazém de 200 m², alguns carros, cinco pessoas. Os pedidos foram feitos por telefone, as remessas foram coletadas no Excel, os documentos foram emitidos no 1C - inconveniente, mas tolerável. Quando cresceram para várias dezenas de clientes e pequenas redes, eles iniciaram o Bitrix24 "para experimentar" para não perder solicitações e pelo menos ver o funil de alguma forma. Dois anos depois, o CRM se tornou o sistema nervoso da empresa. Através dele, os pedidos recebidos, as tarefas do armazém e dos motoristas, as janelas de entrega, a aprovação de preços e o adiamento, a correspondência com os principais clientes passaram. Na verdade, se o Bitrix não funcionar, a empresa não vê pedidos, obrigações e operações atuais. Mas sob tudo isso, o mesmo fundamento "temporário" permaneceu: um servidor de escritório, "alguns" backups, integrações autoescritas com 1C sem documentação e sem um contorno de teste. A imagem parecia boa em termos de dinheiro. Na temporada, a empresa faturou 1,5–1,9 milhões de rublos por mês, ou seja, 70–90 mil rublos por dia. Nesse contexto, um servidor por 120 mil e "então, de alguma forma, vamos transferir para a nuvem" pareciam uma economia razoável. Até que um dia, na sexta-feira, no final do mês, o servidor parou de inicializar após a atualização. O CRM não subiu, a tentativa de se recuperar do backup falhou - os backups estavam lá, mas não foram verificados. Como resultado, por mais de dois dias, a empresa viveu, na verdade, em um modo de paralisia parcial:
os gerentes não viram solicitações, histórico de clientes e acordos de adiamento;
o armazém não viu as reservas atuais e as datas de validade, não entendeu o que já foi prometido a clientes específicos;
o logístico não viu rotas e janelas de entrega, os carros estavam parados ou dirigindo em listas "de papel";
a contabilidade não conseguiu fechar documentos e emitir faturas a tempo. Durante esses dois dias, parte da entrega nas redes parou, parte dos pedidos foi para os concorrentes, em vários clientes-chave, a empresa recebeu feedback duro e ameaças de "rever a cooperação". Além disso, houve reclamações nas redes sociais e em sites especializados - e então essas capturas de tela apareceram por muito tempo nas negociações. Se você contar o dinheiro, a aritmética é desagradável. Com uma receita diária de 70–90 mil rublos, o tempo de inatividade e as interrupções de pedidos em dias de pico podem facilmente resultar em 200–300 mil rublos de receita não recebida e multas por vários dias. Uma dor separada é a reputação. Um dos clientes questionou abertamente a continuação da cooperação após a interrupção das entregas, vários parceiros começaram a testar fornecedores alternativos "para o caso". Esta é a parte das perdas que não se reflete nos relatórios, mas então inesperadamente aparece na forma de diminuição da lealdade e menos fluxo de pedidos. Agora, vamos olhar para o outro lado da equação - quanto custaria "fazer direito". Transferir o CRM para a nuvem com um SLA normal, backups verificados regulares, documentação para integrações com 1C, um Plano Mínimo de Recuperação de Desastres (Disaster Recovery plan) e um contorno de teste para atualizações custariam na faixa de 150.000–500.000 rublos de uma vez, mais 50.000–100.000 rublos por ano para infraestrutura e suporte. O número específico depende do zoológico de integrações acumuladas, mas a ordem é essa: um projeto "normal" custa o mesmo que um ou dois incidentes sérios. Caso Grow Food e outras histórias públicas com tempo de inatividade de vários dias mostram que o problema não é único: mesmo grandes empresas com equipes de TI e orçamentos que são uma ordem de magnitude maiores às vezes ficam paradas por dois dias ou mais. Para um pequeno atacadista sem um plano de DR, dois dias de inatividade é um cenário bastante suave. Nesse contexto, a dívida técnica deixa de ser uma história de terror para os profissionais de TI e se transforma em uma escolha gerencial muito simples: pagar uma vez pela solução ou pagar regularmente quantias comparáveis pelas consequências. Um serviço, três camadas de dívida técnica Vamos pegar um exemplo real. Não um "serviço" abstrato, mas um sistema interno muito real, através do qual as contas, documentos de fechamento e parte da comunicação com os clientes passam. Em algum momento, ele foi lançado "para conveniência": eles colocaram, para que fosse mais fácil para os caras trabalharem, eles olharam, o que vai - e foi. Camada de pessoas. Na verdade, toda essa história é mantida por uma ou duas pessoas. Eles se lembram do que está onde, quais remendos foram colocados há três anos, qual script deve ser executado para que "ele reviva". A equipe está ligada à sua competência pessoal e ao fato de que eles estão sempre em contato - na verdade, 24 horas por dia, 7 dias por semana. Camada de processos. As solicitações de edições e bugs voam para o chat: alguém escreveu, alguém foi mencionado, alguém prometeu algo. Em algum lugar, isso acaba em um rastreador de tarefas, em algum lugar não - depende da disciplina de pessoas específicas. Os SLAs para corrigir erros e tempo de inatividade do serviço não são formalmente descritos em nenhum lugar, tudo depende de "nós concordamos" e "bem, você entende que isso é importante". Camada de tecnologias. O serviço ainda está rodando no mesmo servidor "temporário", que foi alocado "para teste" em algum momento. Não há tolerância a falhas normal, os backups são feitos como eles são, não há contorno de teste no qual você possa verificar algo com segurança. Separadamente, todas essas decisões pareciam pequenas coisas em algum momento: aqui eles economizaram um dia na aprovação do servidor, aqui eles não se preocuparam com o processo, aqui eles não tiveram tempo de emitir um serviço normal e substituir pessoas. Mas, no total, isso não são mais pequenas coisas, mas um risco de negócios específico. Basta um acidente ou o fato de que a pessoa-chave de repente sai do processo - e você tem uma parte crítica das operações paralisada. Esta é a dívida técnica em toda a sua glória: não uma grande "falha", mas muitos pequenos compromissos que silenciosamente se somaram a um grande problema. Por que a dívida técnica está ficando mais cara a cada mês A dívida técnica não é algo estático que pode ser "congelado" e então voltar a ela com segurança. É um empréstimo: você já o pegou, e os juros estão sendo cobrados todos os dias, mesmo que você finja que nada está acontecendo. O hardware está ficando mais caro, os novos modelos são mais caros do que os antigos, as oscilações cambiais não vão a lugar nenhum. Licenças e assinaturas também não tendem a se tornar mais baratas, e as condições dos fornecedores, via de regra, se tornam mais rígidas com o tempo, e não mais suaves. O trabalho das pessoas também está ficando cada vez mais caro: não há mais bons especialistas em TI no mercado, as infraestruturas estão se tornando mais complexas, e qualquer projeto de migração requer cada vez mais qualificação e tempo. O que poderia ser feito "com pouco sangue" há três anos, hoje se transforma em uma transferência difícil por várias semanas. Um artigo separado de "juros" é a segurança. Versões antigas de estruturas, bibliotecas e sistemas operacionais param de receber patches, e os requisitos para proteção de dados e os resultados de inspeções externas estão se tornando cada vez mais rígidos. Fechar novas vulnerabilidades em uma pilha antiga costuma ser mais caro do que migrar uma vez de forma planejada. Uma situação semelhante com legacy‑monolitos. O sistema, que há três anos ainda poderia ser relativamente indolor para dividir ou pelo menos cercar com testes, durante esse tempo cresce com integrações e lógica de negócios. Cada alteração nele requer cada vez mais esforço, e o preço de qualquer refatoração está crescendo muito mais rápido do que a inflação. Cada novo incidente em um servidor antigo, em torno de um serviço desatualizado ou um funcionário "heroico" - este não é apenas um problema único, mas exatamente os mesmos juros sobre o empréstimo. Você paga por viagens de emergência, horas extras, remendos únicos, mas o corpo da dívida não vai a lugar nenhum - pelo contrário, o risco do próximo, ainda mais caro, acidente só aumenta. Adiar a decisão aqui não economiza dinheiro. Ele apenas transfere o pagamento para o futuro, adicionando a ele um prêmio de risco e uma infraestrutura que se tornou mais complexa durante esse tempo. Por que auditoria e consultoria de TI aqui Para começar a fazer algo com a dívida técnica, você primeiro precisa tirá-la à luz. Não no formato de "temos tudo velho e tudo ruim", mas na forma de uma lista muito prática: onde temos riscos para as pessoas, onde para os processos, onde para as tecnologias e o que exatamente pode explodir lá. Normalmente, isso é feito por meio de uma auditoria de TI. Na verdade, esta é uma inventariação da dívida técnica e uma avaliação honesta do que "não mudar nada" lhe custa. Dividimos a imagem em duas partes: uma avaliação de engenharia - quanto custa consertar, e uma avaliação de negócios - quanto custa não consertar. Então a consultoria funciona: não basta ver o problema, você precisa concordar em que ordem você vai pagar essa dívida. Onde há um risco crítico e você precisa fazer ontem, onde você pode incluir mudanças no plano de trabalho, e onde você geralmente tem melhorias mínimas e não precisa "reescrever tudo do zero". Nossa experiência é muito simples: a maioria dos clientes arrasta a dívida técnica até que sejam "picados por um galo frito". Um servidor desatualizado cai, um serviço antigo finalmente quebra, a única pessoa que sabe tudo vai embora - e a empresa paga muitas vezes mais do que uma solução planejada custaria. A auditoria de TI é necessária para chegar não após o acidente, mas antes dele. Calcule calmamente onde o risco é justificado e onde você está jogando roleta russa, e registre isso na linguagem do dinheiro, e não das emoções. Do ponto de vista da equipe de TI, o resultado de uma auditoria normal não é apenas uma apresentação para os proprietários. Este é um plano de trabalho muito específico:
uma lista de riscos para serviços e sistemas-chave;
"dívidas" arquiteturais e opções para fechá-las;
uma lista de falhas na documentação;
mudanças priorizadas nos processos de suporte e operação. Ao mesmo tempo, a tarefa de auditoria não é "convencer todos a reescrever urgentemente tudo em uma nova pilha por causa da moda". O objetivo é mostrar honestamente onde melhorias e disciplina mínimas são suficientes, e onde, sem refatoração ou migração séria, o risco já é inadequado para os negócios. Em vez de uma conclusão Tecnicamente, a maioria das histórias sobre "o CRM caiu por dois dias" ou "o 1C caiu no final do mês" são organizadas da mesma forma. Por anos, as empresas e a TI fizeram pequenos compromissos - um servidor temporário, uma integração de remendo, ausência de DR - até que uma falha combinou essas decisões em um tempo de inatividade completo com um preço muito específico. A boa notícia é que você pode mudar essa trajetória sem "reescrever o mundo" totalmente. Você pode começar com um inventário da dívida técnica: quais serviços são realmente críticos, em quais deles você ainda vive em hardware de teste, onde não há um processo de mudança normal, e onde os SLAs existem apenas em apresentações. Em seguida, feche as coisas mais tóxicas: ausência de backups verificáveis, bus factor 1 em torno de sistemas-chave, integrações autoescritas sem documentação. Essas são tarefas chatas, mas são elas que determinam se o próximo acidente terminará com uma mudança noturna no console ou com a interrupção dos negócios por dois dias. Compartilhe nos comentários suas histórias e pensamentos sobre o que leva a situações em que a dívida técnica é excluída dos planos de desenvolvimento. Tags: dívida tecnológica dívida técnica gerenciamento de dívida técnica itsm bus factor auditoria de ti alp itsm Hubs: Blog da empresa ALP ITSM Administração de sistemas Segurança da informação 0 0 0 8K+ Alcance em 30 dias ALP ITSM Site 16K+ Alcance em 30 dias 4 Carma @alp-itsm Usuário Assinar O fluxo Top Management está disponível 24 horas por dia, 7 dias por semana, graças ao apoio dos amigos do Habr Habr Cursos para todos PUBLICIDADE Prática, Hexlet, SkyPro, cursos do autor - reunimos todos e pedimos descontos. Resta escolher! Ir Ir para o fluxo Top Management Comentar Melhor do dia Semelhante

como a dívida técnica se parece em três níveis - pessoas (bus factor, documentação), processos (incidentes, solicitações, alterações), tecnologias (pilha antiga, ausência de plano de recuperação, soluções "temporárias");
como separar a avaliação de engenharia e negócios de "consertar/não consertar";
por que tentar "não tocar em nada" costuma ser mais caro do que uma migração planejada;
e o que a equipe recebe de uma auditoria de TI: não apenas uma apresentação para a gerência, mas também uma lista específica de riscos, melhorias arquiteturais e mudanças de processo. O que é dívida técnica A dívida técnica é o preço dos compromissos de TI anteriores, que permitiram que você fizesse algo mais rápido ou mais barato em algum momento, mas agora estão retornando com riscos e custos adicionais. A dívida técnica são as mesmas decisões "para depois", que foram tomadas há um, dois, cinco anos. Você economizou em arquitetura, tolerância a falhas, documentação, pessoas e processos - e hoje está pagando por isso com tempo de inatividade, trabalho de emergência e restrições para as empresas. Se você for um pouco mais prático, a dívida técnica sempre tem dois lados. No nível de engenharia, são horas de trabalho, licenças, novo hardware, migrações, testes, suporte. No nível de negócios - o custo de uma hora de inatividade, SLA com os clientes, multas, interrupção de entregas, perda de receita. Uma conversa normal sobre dívida técnica se parece com uma comparação de dois números: quanto custa consertar agora e quanto custa não consertar até a primeira falha séria. Se o segundo número for significativamente maior, a questão de "é caro consertar" geralmente desaparece. Não há dívida técnica na contabilidade - existem apenas servidores, licenças e linhas de despesas. Por causa disso, o bloco financeiro simplesmente não o vê, embora a dívida técnica consuma lucros, aumente as perdas e, em algum momento, comece a afetar o custo da empresa. Por causa disso, você não recebe receita suficiente, perde clientes, não cumpre obrigações e paga demais por "reparos de emergência". Você precisa pensar na dívida técnica como um empréstimo com juros. Toda vez que você adia uma atualização "desagradável" ou a substituição de um servidor antigo, você está, por assim dizer, estendendo esse empréstimo por mais um mês. Os juros se acumulam na forma de reparos cada vez mais caros, complexidade crescente de suporte e riscos crescentes de tempo de inatividade. A segunda metáfora são dentes não tratados. Enquanto não dói, parece que você pode esperar. Mas a cada mês de adiamento, o tratamento se torna mais caro e doloroso, e alguns dentes não são mais tratados - eles são simplesmente removidos. Tudo é exatamente o mesmo com a infraestrutura e os serviços de TI. Três fontes de dívida técnica: pessoas, processos, tecnologias Vamos olhar não abstratamente para "alguma TI", mas de forma abrangente, através de uma abordagem ITSM madura. Nele, a TI é sempre composta por três blocos: pessoas, processos, tecnologias. E é exatamente nesses três lugares que a dívida técnica se acumula. Não acontece que tudo seja ruim apenas nos servidores, e as pessoas e os processos sejam perfeitos - sempre há uma queda em algum lugar. A maioria das pessoas olha apenas para hardware e software: "servidor antigo, versão antiga, precisa ser atualizado". E os problemas reais começam onde todos os três componentes convergem: não há pessoas suficientes, os processos são montados no joelho e as tecnologias são mantidas em remendos temporários. Se você já está afundando em pelo menos um dos blocos, você está gradualmente criando dívida técnica. Se houver buracos em todos os três, a questão não é "haverá um acidente", mas "quando exatamente e quanto vai custar". Pessoas: quando tudo depende de um herói Uma imagem muito comum: a empresa tem "aquele" especialista em TI que carrega um ou mais serviços críticos. Ele é o único que sabe como tudo funciona, onde os backups estão localizados, quais são os remendos e o que precisa ser "ajustado para que funcione". De fora, parece conveniente: há sua própria pessoa, todos vão até ele, ele conserta tudo, a empresa está satisfeita. Na verdade, esta é uma mina terrestre de pessoal. Tão logo essa pessoa tiver algo do conjunto "adoeceu, queimou, foi embora, foi demitido" - um serviço crítico para os negócios simplesmente para. E junto com ele, as contas, remessas, documentos de fechamento, relatórios e todos que dependiam desse serviço param. Ao mesmo tempo, buracos no mapa de competências da equipe se acumulam paralelamente. A carga de trabalho está crescendo, o cenário de TI está se tornando mais complexo, novos serviços e integrações estão aparecendo, requisitos de segurança, e a equipe ainda está trabalhando no modo "apagando incêndios, o resto de alguma forma depois". Em algum momento, você de repente descobre que as pessoas fisicamente não conseguem lidar com o volume e a complexidade das tarefas. Mas ninguém fez um inventário honesto de competências, riscos e capacidade - todos simplesmente "carregaram heroicamente". Esta é a mesma dívida técnica que um servidor antigo: dívida de pessoas e de gerenciamento da equipe de TI. Processos: suporte "de alguma forma no chat" O segundo tipo de dívida técnica reside no plano dos processos. Na maioria das vezes, tudo começa de forma simples: eles iniciaram um chat, colocaram um engenheiro lá, disseram à empresa "escreva aqui, pessoal vai ajudar". Enquanto a empresa é pequena e os serviços não são críticos, esse esquema ainda funciona de alguma forma. Mas assim que o número de usuários e sistemas aumenta, os sintomas clássicos começam:
as solicitações são perdidas ou ficam "para pensar" por meses;
todo mundo está pegando fogo, mas ninguém entende o que é realmente crítico;
ninguém é realmente responsável pelo tempo de resposta e recuperação. Não há SLAs/OLAs formalizados, tudo depende de acordos pessoais e da boa vontade de indivíduos. Como resultado, qualquer incidente mais ou menos sério se transforma em caos: a empresa espera que "seja levantado em meia hora", a TI está fazendo algo, mas não há regras comuns do jogo. Se você olhar através da lente do ITSM, incidentes, solicitações de serviço e alterações são misturados em um frasco. Não há categorização e priorização normais (P1–P4 condicionais), não há entrada clara no processo de gerenciamento de mudanças, não há ligação "incidente → investigação → problema → mudança". Formalmente, os SLAs podem existir em uma apresentação para a empresa, mas eles não vivem na operação: não há monitoramento do desempenho real, não há conexão com os KPIs da equipe de suporte, não há estatísticas transparentes sobre reações e recuperação. Os processos de incidentes e solicitações de serviço costumam permanecer inacabados, porque em algum momento foram lançados "como uma solução temporária, então vamos aperfeiçoá-la". Então, como de costume, não aconteceu - e a solução temporária se tornou permanente. Toda vez que você diz "ok, agora não é hora do processo, vamos melhorar depois", você cria dívida técnica nos processos de gerenciamento de TI. E você paga por isso quando tudo cai no momento mais inconveniente. Tecnologias: de um serviço de teste a um ponto único de falha A terceira camada, a mais óbvia, são as tecnologias. Aqui, tudo geralmente começa com a história "vamos lançar um serviço de teste, ver se ele vai, e então decidiremos". Para o teste, ele é colocado na infraestrutura mínima: sem tolerância a falhas, sem backups normais, muitas vezes em algum servidor antigo "para que não seja uma pena". Formalmente, é temporário, "nada crítico" nele. Na prática, geralmente se parece com isto: em algum lugar no canto, o mesmo Windows Server "temporário" com CRM autoescrito, um pedaço de 1C ou uma interface web gira, que ninguém quer mais tocar. Integrações, scripts, agendadores de tarefas são criados em cima disso - e tudo isso funciona com base no princípio de "não toque, enquanto funciona". Ao mesmo tempo, não há monitoramento normal de métricas e estados, nem notificações claras de eventos, nem uma verificação regular da recuperação de backups. É bom se em algum momento "para mostrar" eles levantaram um estande de uma cópia de backup e verificaram se ele realmente começa. Um ou dois anos se passam, as equipes se aproximam, os dados se movem, os processos crescem com esse serviço - e de repente fica claro que metade da empresa já vive nessa "peça de teste temporária". Mas a arquitetura, a tolerância a falhas e o backup ainda estão no nível do teste. Isso também inclui os clássicos do gênero: hardware antigo sem suporte e peças de reposição. O servidor tem dez anos, o modelo foi descontinuado, não há suporte oficial, é quase impossível encontrar peças de reposição para ele, mas ele atende um sistema crítico, e todos têm pena de tocá-lo, porque "de repente não vamos levantá-lo". Uma história separada são as versões desatualizadas do SO e do software de aplicação, nas quais "tudo ainda funciona de alguma forma". Eles não recebem mais atualizações de segurança, o fornecedor se esqueceu deles, mas aplicativos críticos para os negócios estão ligados a eles, que são assustadores e caros para reescrever. Qualquer tentativa de atualização se transforma em uma missão com um final imprevisível, então a atualização é adiada por mais um ano. E por mais um ano. Todos esses "vamos deixar assim por enquanto, funciona" se somam a um cofrinho muito específico de dívida técnica tecnológica. Uma dificuldade separada são as integrações em torno do serviço. Enquanto tudo funciona, eles tentam não tocar neles. Mas no momento da queda, acontece que você precisa levantar não um sistema, mas um "zoológico" inteiro de componentes dependentes, uma fila de tarefas, sincronizações e importações. Quando o CRM "temporário" interrompe todo o atacado Vou contar a história de uma das empresas, em seu exemplo é claramente visível o que leva a ignorar o trabalho com dívida tecnológica. Em 2017, era uma pequena empresa atacadista: um armazém de 200 m², alguns carros, cinco pessoas. Os pedidos foram feitos por telefone, as remessas foram coletadas no Excel, os documentos foram emitidos no 1C - inconveniente, mas tolerável. Quando cresceram para várias dezenas de clientes e pequenas redes, eles iniciaram o Bitrix24 "para experimentar" para não perder solicitações e pelo menos ver o funil de alguma forma. Dois anos depois, o CRM se tornou o sistema nervoso da empresa. Através dele, os pedidos recebidos, as tarefas do armazém e dos motoristas, as janelas de entrega, a aprovação de preços e o adiamento, a correspondência com os principais clientes passaram. Na verdade, se o Bitrix não funcionar, a empresa não vê pedidos, obrigações e operações atuais. Mas sob tudo isso, o mesmo fundamento "temporário" permaneceu: um servidor de escritório, "alguns" backups, integrações autoescritas com 1C sem documentação e sem um contorno de teste. A imagem parecia boa em termos de dinheiro. Na temporada, a empresa faturou 1,5–1,9 milhões de rublos por mês, ou seja, 70–90 mil rublos por dia. Nesse contexto, um servidor por 120 mil e "então, de alguma forma, vamos transferir para a nuvem" pareciam uma economia razoável. Até que um dia, na sexta-feira, no final do mês, o servidor parou de inicializar após a atualização. O CRM não subiu, a tentativa de se recuperar do backup falhou - os backups estavam lá, mas não foram verificados. Como resultado, por mais de dois dias, a empresa viveu, na verdade, em um modo de paralisia parcial:
os gerentes não viram solicitações, histórico de clientes e acordos de adiamento;
o armazém não viu as reservas atuais e as datas de validade, não entendeu o que já foi prometido a clientes específicos;
o logístico não viu rotas e janelas de entrega, os carros estavam parados ou dirigindo em listas "de papel";
a contabilidade não conseguiu fechar documentos e emitir faturas a tempo. Durante esses dois dias, parte da entrega nas redes parou, parte dos pedidos foi para os concorrentes, em vários clientes-chave, a empresa recebeu feedback duro e ameaças de "rever a cooperação". Além disso, houve reclamações nas redes sociais e em sites especializados - e então essas capturas de tela apareceram por muito tempo nas negociações. Se você contar o dinheiro, a aritmética é desagradável. Com uma receita diária de 70–90 mil rublos, o tempo de inatividade e as interrupções de pedidos em dias de pico podem facilmente resultar em 200–300 mil rublos de receita não recebida e multas por vários dias. Uma dor separada é a reputação. Um dos clientes questionou abertamente a continuação da cooperação após a interrupção das entregas, vários parceiros começaram a testar fornecedores alternativos "para o caso". Esta é a parte das perdas que não se reflete nos relatórios, mas então inesperadamente aparece na forma de diminuição da lealdade e menos fluxo de pedidos. Agora, vamos olhar para o outro lado da equação - quanto custaria "fazer direito". Transferir o CRM para a nuvem com um SLA normal, backups verificados regulares, documentação para integrações com 1C, um Plano Mínimo de Recuperação de Desastres (Disaster Recovery plan) e um contorno de teste para atualizações custariam na faixa de 150.000–500.000 rublos de uma vez, mais 50.000–100.000 rublos por ano para infraestrutura e suporte. O número específico depende do zoológico de integrações acumuladas, mas a ordem é essa: um projeto "normal" custa o mesmo que um ou dois incidentes sérios. Caso Grow Food e outras histórias públicas com tempo de inatividade de vários dias mostram que o problema não é único: mesmo grandes empresas com equipes de TI e orçamentos que são uma ordem de magnitude maiores às vezes ficam paradas por dois dias ou mais. Para um pequeno atacadista sem um plano de DR, dois dias de inatividade é um cenário bastante suave. Nesse contexto, a dívida técnica deixa de ser uma história de terror para os profissionais de TI e se transforma em uma escolha gerencial muito simples: pagar uma vez pela solução ou pagar regularmente quantias comparáveis pelas consequências. Um serviço, três camadas de dívida técnica Vamos pegar um exemplo real. Não um "serviço" abstrato, mas um sistema interno muito real, através do qual as contas, documentos de fechamento e parte da comunicação com os clientes passam. Em algum momento, ele foi lançado "para conveniência": eles colocaram, para que fosse mais fácil para os caras trabalharem, eles olharam, o que vai - e foi. Camada de pessoas. Na verdade, toda essa história é mantida por uma ou duas pessoas. Eles se lembram do que está onde, quais remendos foram colocados há três anos, qual script deve ser executado para que "ele reviva". A equipe está ligada à sua competência pessoal e ao fato de que eles estão sempre em contato - na verdade, 24 horas por dia, 7 dias por semana. Camada de processos. As solicitações de edições e bugs voam para o chat: alguém escreveu, alguém foi mencionado, alguém prometeu algo. Em algum lugar, isso acaba em um rastreador de tarefas, em algum lugar não - depende da disciplina de pessoas específicas. Os SLAs para corrigir erros e tempo de inatividade do serviço não são formalmente descritos em nenhum lugar, tudo depende de "nós concordamos" e "bem, você entende que isso é importante". Camada de tecnologias. O serviço ainda está rodando no mesmo servidor "temporário", que foi alocado "para teste" em algum momento. Não há tolerância a falhas normal, os backups são feitos como eles são, não há contorno de teste no qual você possa verificar algo com segurança. Separadamente, todas essas decisões pareciam pequenas coisas em algum momento: aqui eles economizaram um dia na aprovação do servidor, aqui eles não se preocuparam com o processo, aqui eles não tiveram tempo de emitir um serviço normal e substituir pessoas. Mas, no total, isso não são mais pequenas coisas, mas um risco de negócios específico. Basta um acidente ou o fato de que a pessoa-chave de repente sai do processo - e você tem uma parte crítica das operações paralisada. Esta é a dívida técnica em toda a sua glória: não uma grande "falha", mas muitos pequenos compromissos que silenciosamente se somaram a um grande problema. Por que a dívida técnica está ficando mais cara a cada mês A dívida técnica não é algo estático que pode ser "congelado" e então voltar a ela com segurança. É um empréstimo: você já o pegou, e os juros estão sendo cobrados todos os dias, mesmo que você finja que nada está acontecendo. O hardware está ficando mais caro, os novos modelos são mais caros do que os antigos, as oscilações cambiais não vão a lugar nenhum. Licenças e assinaturas também não tendem a se tornar mais baratas, e as condições dos fornecedores, via de regra, se tornam mais rígidas com o tempo, e não mais suaves. O trabalho das pessoas também está ficando cada vez mais caro: não há mais bons especialistas em TI no mercado, as infraestruturas estão se tornando mais complexas, e qualquer projeto de migração requer cada vez mais qualificação e tempo. O que poderia ser feito "com pouco sangue" há três anos, hoje se transforma em uma transferência difícil por várias semanas. Um artigo separado de "juros" é a segurança. Versões antigas de estruturas, bibliotecas e sistemas operacionais param de receber patches, e os requisitos para proteção de dados e os resultados de inspeções externas estão se tornando cada vez mais rígidos. Fechar novas vulnerabilidades em uma pilha antiga costuma ser mais caro do que migrar uma vez de forma planejada. Uma situação semelhante com legacy‑monolitos. O sistema, que há três anos ainda poderia ser relativamente indolor para dividir ou pelo menos cercar com testes, durante esse tempo cresce com integrações e lógica de negócios. Cada alteração nele requer cada vez mais esforço, e o preço de qualquer refatoração está crescendo muito mais rápido do que a inflação. Cada novo incidente em um servidor antigo, em torno de um serviço desatualizado ou um funcionário "heroico" - este não é apenas um problema único, mas exatamente os mesmos juros sobre o empréstimo. Você paga por viagens de emergência, horas extras, remendos únicos, mas o corpo da dívida não vai a lugar nenhum - pelo contrário, o risco do próximo, ainda mais caro, acidente só aumenta. Adiar a decisão aqui não economiza dinheiro. Ele apenas transfere o pagamento para o futuro, adicionando a ele um prêmio de risco e uma infraestrutura que se tornou mais complexa durante esse tempo. Por que auditoria e consultoria de TI aqui Para começar a fazer algo com a dívida técnica, você primeiro precisa tirá-la à luz. Não no formato de "temos tudo velho e tudo ruim", mas na forma de uma lista muito prática: onde temos riscos para as pessoas, onde para os processos, onde para as tecnologias e o que exatamente pode explodir lá. Normalmente, isso é feito por meio de uma auditoria de TI. Na verdade, esta é uma inventariação da dívida técnica e uma avaliação honesta do que "não mudar nada" lhe custa. Dividimos a imagem em duas partes: uma avaliação de engenharia - quanto custa consertar, e uma avaliação de negócios - quanto custa não consertar. Então a consultoria funciona: não basta ver o problema, você precisa concordar em que ordem você vai pagar essa dívida. Onde há um risco crítico e você precisa fazer ontem, onde você pode incluir mudanças no plano de trabalho, e onde você geralmente tem melhorias mínimas e não precisa "reescrever tudo do zero". Nossa experiência é muito simples: a maioria dos clientes arrasta a dívida técnica até que sejam "picados por um galo frito". Um servidor desatualizado cai, um serviço antigo finalmente quebra, a única pessoa que sabe tudo vai embora - e a empresa paga muitas vezes mais do que uma solução planejada custaria. A auditoria de TI é necessária para chegar não após o acidente, mas antes dele. Calcule calmamente onde o risco é justificado e onde você está jogando roleta russa, e registre isso na linguagem do dinheiro, e não das emoções. Do ponto de vista da equipe de TI, o resultado de uma auditoria normal não é apenas uma apresentação para os proprietários. Este é um plano de trabalho muito específico:
uma lista de riscos para serviços e sistemas-chave;
"dívidas" arquiteturais e opções para fechá-las;
uma lista de falhas na documentação;
mudanças priorizadas nos processos de suporte e operação. Ao mesmo tempo, a tarefa de auditoria não é "convencer todos a reescrever urgentemente tudo em uma nova pilha por causa da moda". O objetivo é mostrar honestamente onde melhorias e disciplina mínimas são suficientes, e onde, sem refatoração ou migração séria, o risco já é inadequado para os negócios. Em vez de uma conclusão Tecnicamente, a maioria das histórias sobre "o CRM caiu por dois dias" ou "o 1C caiu no final do mês" são organizadas da mesma forma. Por anos, as empresas e a TI fizeram pequenos compromissos - um servidor temporário, uma integração de remendo, ausência de DR - até que uma falha combinou essas decisões em um tempo de inatividade completo com um preço muito específico. A boa notícia é que você pode mudar essa trajetória sem "reescrever o mundo" totalmente. Você pode começar com um inventário da dívida técnica: quais serviços são realmente críticos, em quais deles você ainda vive em hardware de teste, onde não há um processo de mudança normal, e onde os SLAs existem apenas em apresentações. Em seguida, feche as coisas mais tóxicas: ausência de backups verificáveis, bus factor 1 em torno de sistemas-chave, integrações autoescritas sem documentação. Essas são tarefas chatas, mas são elas que determinam se o próximo acidente terminará com uma mudança noturna no console ou com a interrupção dos negócios por dois dias. Compartilhe nos comentários suas histórias e pensamentos sobre o que leva a situações em que a dívida técnica é excluída dos planos de desenvolvimento. Tags: dívida tecnológica dívida técnica gerenciamento de dívida técnica itsm bus factor auditoria de ti alp itsm Hubs: Blog da empresa ALP ITSM Administração de sistemas Segurança da informação 0 0 0 8K+ Alcance em 30 dias ALP ITSM Site 16K+ Alcance em 30 dias 4 Carma @alp-itsm Usuário Assinar O fluxo Top Management está disponível 24 horas por dia, 7 dias por semana, graças ao apoio dos amigos do Habr Habr Cursos para todos PUBLICIDADE Prática, Hexlet, SkyPro, cursos do autor - reunimos todos e pedimos descontos. Resta escolher! Ir Ir para o fluxo Top Management Comentar Melhor do dia Semelhante

📤 Compartilhar & Baixar