Como definir RACI e runbooks ao contratar gestão de infraestrutura em nuvem
Use uma matriz RACI bem definida e runbooks testados para saber quem decide, quem executa e como responder a incidentes em produção.
Solicitar uma avaliação operacional
Neste artigo9 seções
- Por que RACI e runbooks devem estar no contrato de gestão de nuvem
- Como montar a matriz RACI para infraestrutura em nuvem
- Checklist de responsabilidades que a RACI deve conter
- O que um runbook de infraestrutura em nuvem precisa explicar
- Como validar runbooks durante uma prova de conceito
- Quatro runbooks essenciais para e-commerce e SaaS de média escala
- Como garantir atualização e treinamento dos runbooks no SLA
- Sinais de que o fornecedor está pronto para operar com você
- Checklist final para contratar gestão de infraestrutura em nuvem
Por que RACI e runbooks devem estar no contrato de gestão de nuvem
A gestão de infraestrutura em nuvem para PMEs não termina quando servidores, redes e serviços são configurados. Para operar com segurança, sua equipe precisa saber quem responde por cada atividade e ter instruções claras para agir quando ocorre um incidente, uma alteração ou uma falha de automação.
É exatamente essa função que RACI e runbooks cumprem. A matriz RACI distribui responsabilidades entre a empresa contratante e o fornecedor. O runbook descreve, em uma sequência executável, como realizar uma tarefa operacional ou restaurar um serviço.
Sem esses dois artefatos, situações simples podem gerar atrasos: um deploy falha fora do horário comercial, o DNS não propaga como esperado, uma instância fica sem capacidade ou um alerta chega a uma pessoa sem autorização para intervir. O problema raramente é apenas técnico. Ele também envolve comunicação, acesso, decisão e escalonamento.
Antes de contratar, use o roteiro técnico de pré-contratação com provas de conceito e entregáveis para verificar se o fornecedor demonstra sua forma de trabalhar, em vez de apresentar apenas uma proposta genérica.
Este guia mostra o que deve constar na matriz RACI, qual nível de detalhe um runbook precisa ter, como validar os documentos durante uma prova de conceito e quais cláusulas ajudam a mantê-los atualizados ao longo do contrato.
Como montar a matriz RACI para infraestrutura em nuvem
RACI é a sigla para responsável pela execução, aprovador ou responsável final, consultado e informado. Uma atividade pode ter mais de uma pessoa responsável pela execução, mas deve ter apenas um aprovador final. Essa regra reduz disputas e evita que uma tarefa fique sem dono.
Em uma operação de e-commerce de média escala, por exemplo, a matriz pode envolver liderança de TI, desenvolvimento, produto, financeiro, atendimento e o fornecedor de nuvem gerenciada. Em uma empresa SaaS, também é comum incluir o responsável pelo banco de dados, segurança, suporte ao cliente e gestor do produto.
Não crie uma RACI baseada somente em cargos abstratos. Registre o papel operacional e o grupo ou pessoa que o representa, além de um canal de contato e um substituto para períodos de férias, plantão ou indisponibilidade.
A matriz deve cobrir atividades recorrentes e eventos críticos, como criação de ambientes, concessão de acessos, aplicação de patches, gestão de certificados, deploy, rollback, backup, restauração, alteração de DNS, resposta a incidentes, análise de custos e revisão de capacidade.
Uma boa referência para organizar operações e melhoria contínua é o pilar de excelência operacional da AWS. Ele reforça práticas como preparação, operação, evolução e aprendizado a partir de eventos, princípios que podem ser traduzidos para a realidade de uma PME.
Ao avaliar um fornecedor, peça uma amostra da matriz com pelo menos cinco atividades do seu ambiente. Se a resposta vier com um modelo idêntico para todos os clientes, sem considerar sistemas, horários, níveis de acesso e dependências internas, a documentação provavelmente não será útil na prática.
Checklist de responsabilidades que a RACI deve conter
- ✓Inventário e classificação dos recursos: quem mantém a lista de contas, máquinas virtuais, bancos, redes, domínios, certificados e serviços críticos.
- ✓Acessos e credenciais: quem solicita, aprova, concede, revisa e revoga permissões. A RACI deve apontar o processo de cofre de segredos e o responsável por acessos emergenciais.
- ✓Mudanças em produção: quem abre a solicitação, avalia o risco, aprova a janela, executa, valida o resultado e comunica as áreas afetadas.
- ✓Deploy e rollback: quem responde pela aplicação, quem pode autorizar a reversão e quem confirma que a versão anterior está saudável.
- ✓Monitoramento e alertas: quem acompanha indicadores, quem analisa o primeiro diagnóstico, quem assume o incidente e quem recebe a comunicação executiva.
- ✓Backup e recuperação: quem verifica os resultados dos backups, quem testa restaurações, quem define a prioridade dos dados e quem autoriza uma recuperação de desastre.
- ✓DNS, domínios e certificados: quem controla registradores, zonas DNS, validade, renovação e mudanças que podem afetar vendas ou acesso ao produto.
- ✓Capacidade e custos: quem acompanha consumo, aprova expansão de recursos e avalia oportunidades de otimização sem comprometer desempenho.
- ✓Incidentes e escalonamento: quais são os níveis de severidade, os tempos de resposta, os contatos de plantão e o ponto em que a liderança deve ser envolvida.
- ✓Conhecimento e documentação: quem atualiza os runbooks depois de uma mudança, quem aprova a versão e quem treina os envolvidos.
O que um runbook de infraestrutura em nuvem precisa explicar
Um runbook não é um texto longo sobre arquitetura. Ele é um roteiro operacional para uma pessoa autorizada executar uma tarefa com segurança, inclusive sob pressão. O documento deve ser específico o suficiente para orientar a ação, mas simples o bastante para ser consultado durante um incidente.
Comece pelo objetivo e pelo critério de uso. Um runbook de rollback deve dizer quando a reversão é indicada, quais sinais confirmam o problema e quem tem autoridade para iniciá-la. Também precisa informar quando não executar o procedimento e qual alternativa deve ser acionada.
Inclua pré-requisitos verificáveis: acessos necessários, ferramentas, variáveis, janela de mudança, backup disponível, dependências e contatos. Nunca coloque senhas ou chaves diretamente no documento. Para esse controle, consulte o guia prático de gestão de segredos e credenciais para automações em PMEs.
A sequência principal deve usar passos numerados, comandos ou caminhos de tela quando necessário e pontos de validação após cada etapa relevante. Um bom teste não diz apenas “verifique se funcionou”. Ele aponta o painel, métrica, registro ou resposta esperada que confirma o resultado.
O final do runbook deve apresentar critérios de sucesso, sinais de falha, ações de contenção, procedimento de retorno, evidências a registrar e regras de escalonamento. Se a equipe precisa interpretar o documento para decidir o próximo passo, há uma lacuna de operação assistida.
Como referência de maturidade, o livro de engenharia de confiabilidade do Google aborda práticas como resposta a incidentes, monitoramento e redução de trabalho operacional repetitivo. A PME não precisa copiar o modelo de uma grande empresa, mas pode adotar o princípio de transformar conhecimento tácito em procedimentos testáveis.
Como validar runbooks durante uma prova de conceito
- 1
Escolha quatro cenários que realmente afetam o negócio
Para e-commerce, selecione falha de deploy, rollback, problema de DNS e escalonamento de servidor. Para SaaS, inclua também indisponibilidade de banco ou degradação de uma integração crítica.
- 2
Peça a versão inicial antes da demonstração
O documento deve conter objetivo, pré-requisitos, passos, validações e escalonamento. Evite aceitar uma apresentação improvisada como substituto de um runbook que sua equipe possa revisar.
- 3
Execute o procedimento em ambiente controlado
Simule o incidente sem colocar a produção em risco. Registre o tempo para localizar o documento, identificar o responsável, executar a ação e confirmar a recuperação.
- 4
Faça uma pessoa interna repetir a tarefa
O fornecedor pode conhecer sua própria arquitetura, mas o teste precisa mostrar se um profissional autorizado da PME consegue seguir as instruções. Anote dúvidas, passos implícitos e permissões ausentes.
- 5
Avalie evidências e critérios de parada
Confirme se o runbook explica quais métricas, logs ou telas devem ser verificadas. Também confira se há um ponto claro para interromper a execução e escalar o caso.
- 6
Transforme os achados em requisito contratual
Liste os ajustes necessários, o prazo de entrega, o responsável pela aprovação e a periodicidade de revisão. Um runbook aprovado na prova de conceito deve entrar no inventário oficial de documentos.
Quatro runbooks essenciais para e-commerce e SaaS de média escala
No incidente de deploy, o documento deve orientar a identificação da versão implantada, a consulta aos indicadores de erro, a pausa de novas mudanças e a escolha entre correção rápida e rollback. A validação pode incluir código de resposta, taxa de erro, latência, filas pendentes e uma transação controlada no sistema.
No rollback, registre como localizar a última versão estável, quais migrações de banco são compatíveis e quem aprova a reversão. Reverter a aplicação sem avaliar alterações irreversíveis no banco pode transformar uma falha de versão em perda de dados ou inconsistência funcional.
Para problemas de DNS, o roteiro precisa identificar o provedor autoritativo, a zona afetada, o valor esperado do registro e o tempo de vida definido. A pessoa executora deve verificar a mudança em mais de um resolvedor, confirmar certificados e acompanhar o impacto sobre site, APIs, e-mail ou integrações.
O runbook de escalonamento de servidores deve estabelecer os sinais que justificam aumento de capacidade, como saturação persistente de CPU, memória, armazenamento ou conexões. Também precisa diferenciar uma expansão temporária de uma correção estrutural, como consulta lenta, vazamento de memória ou processamento fora do horário adequado.
Em projetos de automação, esses roteiros podem ser conectados a ferramentas de nuvem, painéis administrativos como cPanel ou DirectAdmin e soluções de análise como Metabase. A automação pode preparar informações, abrir tarefas e executar ações autorizadas, enquanto a decisão crítica permanece com a pessoa definida na RACI.
A Trait aplica esse raciocínio em diagnósticos e entregas ponta a ponta: primeiro identifica dependências e riscos, depois documenta o procedimento e, por fim, integra o runbook à operação assistida. O objetivo é devolver tempo à equipe sem transformar automações em uma caixa-preta.
Como garantir atualização e treinamento dos runbooks no SLA
Um contrato de gestão de infraestrutura em nuvem deve tratar RACI e runbooks como entregáveis operacionais, não como anexos opcionais. Defina quais documentos serão produzidos, em qual formato, onde ficarão armazenados, quem terá acesso e qual processo será usado para aprovar uma nova versão.
Inclua a obrigação de revisar o runbook sempre que houver mudança relevante na arquitetura, ferramenta, fluxo de deploy, política de acesso ou contato de escalonamento. Também estabeleça uma revisão periódica, por exemplo a cada trimestre, mesmo que não tenha ocorrido uma alteração visível.
O SLA deve separar tempo de resposta, tempo de atualização documental e tempo de treinamento. Uma empresa pode responder rapidamente a um incidente e ainda deixar o conhecimento desatualizado, criando risco para a próxima ocorrência.
Peça evidências de teste. Elas podem ser um registro de simulação, ata de exercício, histórico de versões, lista de participantes e ações corretivas. Para complementar a definição de indicadores, use o guia sobre SLIs, SLOs e SLAs práticos para PMEs.
O treinamento pode ser curto, desde que seja aplicado ao contexto real. Uma sessão de 60 a 90 minutos com gravação, exercício controlado e espaço para perguntas costuma gerar mais valor do que um manual extenso nunca consultado.
Também defina o que acontece na saída do fornecedor. A transferência deve incluir RACI atualizada, runbooks aprovados, inventário, histórico de incidentes, acessos sob controle da empresa e uma sessão de passagem de conhecimento. Esse requisito reduz o risco de dependência operacional.
Sinais de que o fornecedor está pronto para operar com você
- ✓Faz perguntas sobre criticidade, horários de pico, dependências, responsáveis internos e impacto financeiro antes de propor procedimentos.
- ✓Apresenta uma RACI adaptável ao seu ambiente, com um único aprovador por atividade e contatos de substituição.
- ✓Demonstra runbooks com pré-requisitos, passos, validações, critérios de parada, evidências e escalonamento.
- ✓Aceita testar os documentos com alguém da sua equipe, sem depender de conhecimento exclusivo do consultor.
- ✓Explica como monitora servidores, incidentes, alterações, capacidade e custos, conectando alertas a responsáveis definidos.
- ✓Mantém histórico de versões e associa mudanças de infraestrutura aos documentos afetados.
- ✓Prevê treinamento, exercícios de recuperação e revisão após incidentes, não apenas a entrega inicial.
- ✓Consegue integrar procedimentos a AWS ou Azure e, quando aplicável, a painéis como cPanel, DirectAdmin e Metabase sem expor credenciais.
- ✓Define limites claros para automação: o que pode ser executado automaticamente, o que exige aprovação e o que deve ser escalado.
- ✓Mede o resultado com indicadores como tempo para reconhecer incidentes, tempo para restaurar serviços, percentual de procedimentos testados e quantidade de intervenções manuais.
Checklist final para contratar gestão de infraestrutura em nuvem
Antes de assinar, descreva os serviços críticos e o impacto de uma indisponibilidade. Relacione horários de maior movimento, metas de recuperação, requisitos de segurança, sistemas integrados e pessoas que podem aprovar mudanças.
Em seguida, solicite uma amostra preenchida de RACI e dois ou quatro runbooks relacionados ao seu ambiente. Não avalie apenas a aparência do documento. Peça uma execução controlada e observe se a equipe consegue localizar informações, agir sem ambiguidades e produzir evidências.
Confira se a proposta contempla diagnóstico, implantação, monitoramento, suporte pós-implantação e operação contínua. O guia de monitoramento de infraestrutura para PMEs ajuda a estruturar a conversa sobre indicadores, alertas e acompanhamento de servidores.
Use também o checklist operacional de deploy com 15 verificações para produção para transformar o processo de publicação em um caso concreto de validação. Deploy é uma boa prova porque reúne autorização, comunicação, observabilidade, plano de retorno e responsabilidade compartilhada.
Por fim, compare a documentação prometida com o que será medido no contrato. Se “runbook atualizado” não tiver definição de versão, prazo, responsável, teste e aprovação, a obrigação fica difícil de cobrar.
A Trait pode conduzir esse diagnóstico de forma remota, mapear papéis, estruturar a RACI, criar runbooks orientados à execução e conectar os procedimentos às ferramentas já usadas pela equipe. Assim, a contratação começa com clareza operacional e evolui para uma operação mais estável, automatizada e sustentável.
Perguntas Frequentes
Quais papéis internos e do fornecedor devem constar na matriz RACI de nuvem?▼
A matriz deve incluir, no mínimo, liderança de TI, desenvolvimento ou produto, segurança quando aplicável, área de negócio responsável pelo sistema e equipe do fornecedor. Os papéis precisam estar associados a atividades concretas, como deploy, backup, acessos, incidentes, DNS, capacidade e custos. Registre também substitutos, canais de contato e o aprovador final de cada tarefa. Evite listar apenas nomes de departamentos sem explicar a responsabilidade operacional.
Qual é o nível de detalhe ideal para um runbook de infraestrutura?▼
O runbook deve permitir que uma pessoa autorizada, mas que não participou da criação do ambiente, execute o procedimento com segurança. Para isso, inclua objetivo, quando usar, pré-requisitos, acessos, passos numerados, validações, critérios de parada, plano de retorno e escalonamento. Comandos e caminhos devem ser específicos, mas senhas e chaves nunca devem ser armazenados no documento. O teste com alguém da equipe interna é a melhor forma de medir se o nível de detalhe é suficiente.
Como validar runbooks antes de contratar um fornecedor de nuvem?▼
Peça documentos relacionados a cenários reais da sua operação, como falha de deploy, rollback, DNS ou aumento de capacidade. Depois, execute uma prova de conceito em ambiente controlado e observe se o procedimento contém decisões, evidências e pontos de escalonamento claros. Solicite que uma pessoa interna repita a tarefa sem receber explicações paralelas do fornecedor. As dúvidas e etapas implícitas encontradas devem virar requisitos de melhoria e itens do contrato.
O runbook deve ser entregue em qual formato?▼
O formato importa menos do que a facilidade de acesso, pesquisa, controle de versão e atualização. A documentação deve ficar em um repositório sob controle da empresa ou em uma ferramenta com exportação e histórico acessíveis. Cada página precisa indicar proprietário, data da última revisão, versão, sistemas afetados e data prevista para o próximo teste. Evite documentos isolados no computador de um consultor ou arquivos sem histórico de alterações.
O que incluir no SLA para manter RACI e runbooks atualizados?▼
Defina os entregáveis, responsáveis, prazos, critérios de aceite e periodicidade de revisão. Inclua atualização obrigatória após mudanças relevantes e incidentes, além de exercícios periódicos para validar os procedimentos. O SLA também deve separar tempo de resposta ao incidente, prazo de correção documental e prazo de treinamento. Na rescisão, preveja a entrega da documentação, do inventário, do histórico e da transferência de conhecimento.
Runbooks podem reduzir intervenções manuais sem eliminar a aprovação humana?▼
Sim. Um runbook pode ser conectado a automações que coletam diagnósticos, abrem chamados, validam pré-requisitos ou executam ações previamente autorizadas. Atividades de maior risco, como exclusão de recursos, alteração de banco ou rollback amplo, podem exigir aprovação definida na RACI. Essa combinação reduz tarefas repetitivas sem transformar uma ação crítica em processo automático e sem supervisão.
Quantos runbooks uma PME deve criar primeiro?▼
Comece pelos procedimentos de maior impacto, frequência ou risco, em vez de tentar documentar toda a infraestrutura de uma vez. Para muitas operações, quatro a seis roteiros iniciais cobrem deploy, rollback, incidente de disponibilidade, DNS, capacidade e restauração de backup. A prioridade deve considerar criticidade do serviço, tempo de recuperação e dependência de uma única pessoa. Depois, use incidentes e mudanças reais para ampliar o acervo.
Transforme responsabilidades e procedimentos em uma operação de nuvem mais previsível
Falar com a Trait sobre meu ambienteSobre o Autor
Fundador da Trait. Empreendedor e especialista em soluções digitais.