Como este tema funciona na sua empresa
Documentação mínima pré-transição; frequentemente está na cabeça de 1-2 pessoas. Recomendação: criar documentação básica crítica durante transição. Runbook simplificado (10-20 páginas) é suficiente: arquitetura (diagrama), procedimentos operacionais (backup, restart), troubleshooting, contatos. Custo: tempo apenas.
Documentação parcial; muitas coisas não estão documentadas mas há alguma base. Recomendação: completar documentação durante projeto de transição. Runbook detalhado (50-100 páginas) para operações críticas. Arquitetura, procedimentos, troubleshooting, recovery. Responsável designado para atualização pós-transição. Custo: R$ 20-50k em consultoria + tempo interno.
Documentação extensa; desafio é manter atualizada. Recomendação: documentação abrangente (500+ páginas) com controle de versão, wiki/intranet. Runbooks para todas as operações. Procedimentos de escalonamento, centro de excelência para coordenar. Custo: R$ 100-300k + sistema de gestão de conhecimento.
Runbook e documentação de transição são procedimentos passo-a-passo e materiais de referência que descrevem como executar operação rotineira, troubleshoot problemas, e recuperar de desastre. Runbook = procedimento específico (como fazer X). Documentação = referência ampla (arquitetura, conceitos, integrações). Ambos são críticos para que novo fornecedor/equipe execute operação de forma autossuficiente[1].
Tipos de documentação crítica em transição
Documentação de arquitetura: diagrama da operação, fluxos de dados, sistemas interdependentes, decisões de design, alternativas consideradas. Procedimentos operacionais: operações rotineiras (backup, patch, monitoramento), frequência, SLA, responsável, validação. Procedimentos de desastre/recuperação: cenários críticos (perda de dados, falha de sistema), RTO/RPO, passos de recuperação, testes. Documentação de troubleshooting: problemas conhecidos, sintomas, causa raiz, resolução, contatos de escalação. Runbooks: procedimentos passo-a-passo, específicos para ação operacional, com pré-requisitos, passos, validação, rollback.
Estrutura de runbook padrão
Cabeçalho: objetivo, escopo, audiência, data de criação, responsável de manutenção. Pré-requisitos: acessos necessários, ferramentas, documentação relacionada. Passos numerados: (1) Passo, (2) Passo, etc. Muito específico (ex: "clique em menu X", não "abra aplicação"). Validação: como confirmar que procedimento funcionou (ex: "backup iniciado com sucesso", "sistema respondeu em <2s"). Rollback: se algo deu errado, como desfazer (ex: "restaurar de backup anterior"). Escalação: quem contatar se procedimento falhar. Referências: links para documentação relacionada, contatos, sistemas. Exemplo de runbook bem feito = novo técnico consegue executar sozinho sem fazer perguntas.
Documentação inline: (1) Diagrama simples (esboço no papel). (2) 3-5 runbooks essenciais (backup, restart, reset password, contatos). (3) Contatos críticos (quem ligar se problema). (4) Checklist de startup (passos para "ligar" sistema). Formato: Google Doc ou Word, 10-20 páginas total. Manutenção: quando algo muda, atualizar no documento. Arquivo em Google Drive compartilhado ou OneDrive.
Documentação estruturada: (1) Arquivo central (intranet, wiki, SharePoint). (2) Índice por função (infraestrutura, suporte, aplicações). (3) 15-25 runbooks (backup, patch, monitoramento, recovery, troubleshooting). (4) Diagrama de arquitetura (Visio, Draw.io). (5) Matriz de RACI (quem faz o quê). (6) Versionamento (v1.0, v1.1, etc.). (7) Responsável pela atualização (designado). Formato: 50-100 páginas. Custo: R$ 20-50k de consultoria para primeira versão.
Sistema de gestão de conhecimento (wiki, Confluence, SharePoint avançado). Documentação abrangente: (1) Arquitetura completa (múltiplos diagramas). (2) Todos os runbooks (30-50+). (3) Procedimentos de escalonamento. (4) Casos de uso e cenários. (5) SOP (Standard Operating Procedures). (6) Versionamento e change control. (7) Auditoria de documentação (quem revisou, quando). Manutenção contínua (quarterly review). Centro de excelência coordena. Custo: R$ 100-300k + sistema e pessoas.
Timing: quando documentação deve estar pronta
Fase 1 (Pré-transição): documentação existe do fornecedor antigo (coleta, organização). Fase 2 (Durante transição): documentação é criada/melhorada (runbooks, troubleshooting). Fase 3 (Pós-transição): documentação é atualizada conforme aprendizado (gaps identificados, correções). Recomendação: não esperar fim de transição para documentar. Fazer em paralelo. Runbooks devem ser TESTADOS durante transição (se não funciona no procedimento, não funciona depois). Documentação nunca está 100% pronta; é processo contínuo.
Manutenção pós-transição
Risco crítico: documentação desatualizada é pior que nenhuma (falhas causadas por doc desatualizada criam desconfiança). Proteção: (1) Responsável designado (quem atualiza). (2) Frequência definida (trimestral review, atualização conforme mudanças). (3) Processo de controle de mudança (mudança no sistema ? atualizar documentação). (4) Comunicação (equipe avisa quando documentação está desatualizada). (5) Versionamento (histórico de mudanças). Sem essas proteções, documentação degrada rápido.
Sinais de que documentação será problema em transição
Se você reconhece dois ou mais, prepare mitigação agressiva.
- Fornecedor antigo não tem documentação organizada ou atualizada
- Conhecimento crítico está na cabeça de 1-2 pessoas (não documentado)
- Você não sabe exatamente como sistema é arquitetado (caixa preta)
- Integrações com outros sistemas são complexas e não estão claras
- Procedimentos de recovery de desastre não foram testados
- Documentação existente é desatualizada (versão de 3 anos atrás)
- Fornecedor é resistente a passar documentação (indica baixa qualidade ou lock-in)
Caminhos para documentação bem-sucedida em transição
Sua equipe cria documentação enquanto aprende.
- Perfil necessário: técnico experiente + "tirador de atas" que documenta
- Tempo estimado: 20-30% do tempo de transição dedicado a documentação
- Faz sentido quando: você tem pessoas com tempo, transição é modular
- Risco principal: documentação incompleta (aprendizado não fica registrado)
Consultores técnico-escritores criam documentação durante transição.
- Tipo de fornecedor: consultores de documentação técnica, especialistas em gestão de conhecimento
- Vantagem: documentação profissional, completa, viável de manter pós-transição
- Faz sentido quando: operação é complexa, documentação é crítica para sucesso
- Resultado típico: documentação completa, time consegue ser autossuficiente em 2-3 semanas pós-transição
Precisa estruturar documentação e runbooks para transição?
O oHub conecta você gratuitamente a consultores de documentação técnica e especialistas em gestão de conhecimento. Descreva sua necessidade (complexidade da operação, tamanho da documentação necessária) em menos de 3 minutos, receba propostas sem compromisso.
Encontrar fornecedores de TI no oHub
Sem custo, sem compromisso. Documentação bem feita economiza semanas de transição e reduz erros operacionais.
Perguntas frequentes
Qual é a diferença entre runbook e documentação?
Runbook = procedimento específico passo-a-passo ("como fazer backup"). Documentação = referência ampla ("como sistema funciona"). Ambos são necessários. Runbook é para fazer; documentação é para aprender.
Documentação em texto é melhor que vídeo?
Depende. Texto é buscável, rápido de atualizar. Vídeo é melhor para procedimentos visuais/complexos. Ideal: combinar (texto + vídeo para procedimentos críticos). Vídeos devem ter legenda (acessibilidade) e ser curtos (<10 min cada).
Quem é responsável por manter documentação atualizada pós-transição?
Deve estar designado contratualmente: fornecedor novo? sua equipe? compartilhado? Sem responsável claro, documentação degrada. Recomendação: um "guardião da documentação" (5-10% do tempo dedicado).
Runbooks precisam ser testados?
SIM. Se runbook não foi testado, não funciona. Testar em environment de teste: simular procedimento, validar que passos são executáveis, timing está realista. Se teste revela problemas, corrigir antes de usar em produção.
Como garantir que documentação não fica obsoleta?
Processo de controle de mudança: mudança no sistema ? atualizar documentação. Responsável designado. Revisão trimestral (validar que ainda é correto). Comunicação: técnicos que descobrem erro reportam. Versionamento: rastrear mudanças.
Qual é o volume típico de documentação para operação de TI?
Pequena: 10-20 páginas. Média: 50-100 páginas. Grande: 500+ páginas. Não há limite. Regra: documentação suficiente para novo técnico ser autossuficiente em 2-4 semanas.
Fontes e referências
- ITIL v3 Service Transition — Documentação e Conhecimento. AXELOS Ltd.
- ISO/IEC 27001 — Documentação de Operações de Segurança. International Organization for Standardization.
- CETIC.br — Pesquisa sobre documentação em TI brasileiro. Centro Regional de Estudos para o Desenvolvimento da Sociedade da Informação.