PROSTI: programa de prontidão operacional em suporte de TI

O programa de prontidão operacional em suporte de TI (PROSTI) é uma metodologia que muda como uma equipe responde a incidente — saindo do modelo “reativo por SLA” pra um modelo “preventivo por prontidão”. É uma abordagem que funciona especialmente bem em empresas com infraestrutura crítica, onde cada hora de indisponibilidade custa dinheiro real. Este post explica o que é PROSTI, como ele difere de SLA tradicional, que métricas mudam com PROSTI implantado, quando faz sentido aplicar, e como começar nos primeiros 60 dias.

O que é prontidão operacional em suporte de TI (definição e origem)

Prontidão operacional, em termos técnicos, é o estado em que a equipe e a infraestrutura estão preparadas pra absorver, diagnosticar e tratar incidente com perda mínima de tempo. PROSTI é a estrutura prática que leva uma operação de TI a esse estado — combina classificação de incidente, jogo de simulação, gestão de capacidade, e revisão contínua de causa raiz.

A origem do conceito vem da indústria militar e da aviação, onde “operational readiness” descreve a capacidade de resposta a evento crítico. Trazido pra TI, o conceito se ajusta: em vez de esperar o incidente acontecer pra reagir (modelo de SLA tradicional), a equipe está em postura de antecipação — conhece o ambiente, sabe os pontos de falha mais prováveis, e tem protocolo definido pra cada categoria.

A diferença prática é grande. SLA tradicional mede tempo de resposta depois do problema. PROSTI mede tempo de preparação pra evitar que o problema vire incidente — e quando o incidente acontece, mede tempo de tratamento até resolução, com cadeia clara de decisão.

Como o PROSTI mapeia e classifica incidentes antes de virarem parada

O PROSTI começa com inventário de cenário de falha. A equipe lista, com base no ambiente real, todos os tipos de incidente prováveis: servidor que cai, rede que para, banco que satura, backup que falha, link que oscila, ataque que aparece, atualização que dá errado. Pra cada cenário, define classe (crítico, alto, médio, baixo) e impacto esperado.

Depois vem o protocolo de tratamento por classe. Cada classe tem cadeia de comunicação definida (quem avisa quem), responsável técnico designado, prazo de tratamento esperado, e procedimento operacional padrão (passo a passo do que fazer). Esse protocolo fica vivo — revisado a cada três meses com base nos incidentes do trimestre.

A parte mais valiosa: simulação periódica. A equipe roda exercício de incidente fictício a cada 30-60 dias, com timer, papel atribuído, e cenário inesperado. Cada simulação melhora o protocolo, descobre buracos, e treina o time. Em empresas que adotam PROSTI bem, o tempo médio de resposta cai de horas pra minutos depois de 6 meses.

A ferramentaria ajuda mas não substitui — runbook escrito, painel de status em tempo real, integração com monitoramento, e canal de comunicação dedicado pra incidente.

Métricas que mudam com PROSTI implantado (MTTR, MTBF, tickets recorrentes)

Três métricas mudam significativamente com PROSTI bem implantado.

MTTR (Mean Time To Resolve): tempo médio entre identificação do incidente e sua resolução. Em operações de TI sem PROSTI, MTTR de incidente crítico costuma ficar entre 2 e 8 horas. Com PROSTI maduro, cai pra 30 minutos a 2 horas — porque a cadeia de comunicação é instantânea, o protocolo é claro, e ninguém perde tempo decidindo o que fazer.

MTBF (Mean Time Between Failures): tempo médio entre falhas do mesmo tipo. PROSTI ataca causa raiz com disciplina, então falhas recorrentes praticamente somem. MTBF de incidente do mesmo tipo costuma dobrar ou triplicar nos primeiros 6 meses de PROSTI.

Tickets recorrentes: número de tickets abertos pelo mesmo motivo em um período. PROSTI categoriza incidente e investiga causa raiz, então ticket recorrente vira projeto de melhoria. Empresas que adotam PROSTI bem reduzem tickets recorrentes em 40-70% no primeiro ano.

Além dessas três, melhora também o NPS interno do suporte (usuário avalia melhor porque o atendimento fica mais rápido e previsível), o tempo de comunicação ao stakeholder (diretoria sabe do problema em minutos, não em horas), e o custo total de incidente (perda operacional + custo de hora extra de TI cai significativamente).

Quando faz sentido aplicar PROSTI vs SLA tradicional

PROSTI faz sentido em três cenários. Cenário 1: empresa onde indisponibilidade custa caro por hora. E-commerce, serviço financeiro, operação 24/7 industrial. Cada minuto de indisponibilidade vira perda direta — investir em prontidão paga rápido.

Cenário 2: empresa com volume alto de incidentes ou histórico de problemas recorrentes. Quando o time gasta a maior parte do tempo apagando incêndio, PROSTI reorganiza a operação e devolve capacidade pra projeto.

Cenário 3: empresa em setor regulado, com exigência de tempo de resposta definido e auditável. PROSTI gera evidência sistemática (logs, simulações, revisões) que serve diretamente pra auditoria.

Quando NÃO faz sentido: empresa com infraestrutura simples, baixo volume de incidente, e usuário interno que tolera bem indisponibilidade. SLA tradicional cumpre o necessário com menor custo de implementação.

A regra empírica: se o custo de 1 hora de indisponibilidade do sistema crítico ultrapassa o custo mensal do contrato de suporte, PROSTI tem retorno alto. Abaixo desse ponto, SLA tradicional pode ser suficiente.

Como começar: diagnóstico inicial e os primeiros 60 dias

Implementar PROSTI tem caminho previsível em três etapas.

Semanas 1 a 3 — Diagnóstico: a equipe roda inventário de ambiente, mapeia sistemas críticos, levanta histórico de incidente dos últimos 6-12 meses, e identifica os 5-10 cenários de falha mais prováveis. Entrega dessa fase: relatório de baseline com MTTR atual, MTBF atual, e mapa de pontos de risco.

Semanas 4 a 7 — Estruturação: a equipe define a classificação de incidente, o protocolo por classe (cadeia de comunicação, papel, procedimento), monta runbook escrito pros 10 cenários priorizados, e prepara o ambiente técnico (painel de status, canal dedicado de comunicação, integração com monitoramento). Entrega: protocolo formal e ambiente operacional pronto.

Semanas 8 a 9 — Treinamento e primeira simulação: a equipe inteira passa por treinamento no novo protocolo, e roda primeira simulação completa de incidente fictício. Lições aprendidas viram ajuste na próxima revisão. Entrega: equipe treinada e simulação documentada.

A partir do dia 60, PROSTI vira rotina — com revisão mensal de incidentes reais, simulação a cada 30-60 dias, e ajuste contínuo do protocolo. Em 4-6 meses, os indicadores começam a mostrar mudança clara.

Próximo passo

Se sua empresa tem infraestrutura crítica e quer reduzir o impacto de incidente em TI, vale conhecer o PROSTI de perto. A equipe da OpTec IT roda diagnóstico inicial em 2-3 semanas, mostra como o programa se aplica ao seu ambiente, e propõe roadmap de implementação realista pros próximos 60 dias.