Como construir um aplicativo web para gerenciar runbooks operacionais

Esclareça objetivos e para quem o app é destinado

Antes de escolher recursos ou stack, alinhe o que “runbook” significa na sua organização. Algumas equipes usam runbooks como playbooks de resposta a incidentes (alta pressão, sensível ao tempo). Outras entendem como procedimentos operacionais padrão (tarefas repetíveis), manutenção agendada ou fluxos de suporte ao cliente. Se você não definir o escopo desde o início, o app vai tentar servir todo tipo de documento — e não servirá bem nenhum.

Defina os tipos de runbook (e o que é “bom”)

Anote as categorias que espera armazenar, com um exemplo rápido para cada:

• Playbooks de incidente: passos para “pico de latência da API”, caminhos de escalonamento, instruções de rollback
• SOPs: “Provisionar um novo cliente”, “Rotacionar credenciais”, “Verificação semanal de capacidade”
• Tarefas de manutenção: “Patch de banco de dados”, “Renovação de certificado”

Defina também padrões mínimos: campos obrigatórios (proprietário, serviços afetados, data da última revisão), o que significa “concluído” (todo passo marcado, anotações capturadas) e o que evitar (texto longo que é difícil de escanear).

Identifique usuários-alvo e suas restrições

Liste os usuários principais e o que eles precisam no momento:

• Engenheiros on-call: velocidade, clareza, pouco atrito enquanto multitarefam
• Operações/suporte: processos consistentes, menos handoffs, definições claras
• Gerentes/líderes: visibilidade de cobertura, cadência de revisão e responsabilidade

Usuários diferentes priorizam coisas distintas. Projetar para o caso on-call geralmente força a interface a ser simples e previsível.

Defina resultados e métricas de sucesso mensuráveis

Escolha 2–4 resultados centrais, como resposta mais rápida, execução consistente e revisões mais simples. Depois atribua métricas que você possa acompanhar:

• Tempo para encontrar o runbook certo (search-to-open)
• Taxa de conclusão para tarefas recorrentes
• Tempo até mitigação de incidentes quando existe um playbook vs. quando não existe
• Cadência de revisão: % de runbooks revisados nos últimos 90 dias

Essas decisões devem guiar escolhas posteriores, da navegação às permissões.

Capture requisitos a partir de fluxos operacionais reais

Antes de escolher stack ou rascunhar telas, observe como as operações realmente funcionam quando algo quebra. Um app de runbooks tem sucesso quando se encaixa em hábitos reais: onde as pessoas procuram respostas, o que é “bom o suficiente” durante um incidente e o que é ignorado quando todos estão sobrecarregados.

Comece pela dor que você está resolvendo

Entrevise engenheiros on-call, SREs, suporte e donos de serviço. Peça exemplos específicos recentes, não opiniões gerais. Dores comuns incluem docs espalhados por várias ferramentas, passos desatualizados que não refletem produção e propriedade incerta (ninguém sabe quem deve atualizar um runbook após uma mudança).

Registre cada ponto de dor como uma pequena história: o que aconteceu, o que a equipe tentou, o que deu errado e o que teria ajudado. Essas histórias viram critérios de aceitação mais tarde.

Faça inventário das fontes existentes e necessidades de importação

Liste onde os runbooks e SOPs vivem hoje: wikis, Google Docs, repositórios Markdown, PDFs, comentários de tickets e postmortems de incidentes. Para cada fonte, anote:

• Formato e estrutura (tabelas, checklists, screenshots, links)
• Volume e histórico que “precisa ser mantido”
• Metadados necessários (serviço, ambiente, severidade, proprietário)

Isso indica se você precisa de um importador em massa, uma migração por copy/paste ou ambos.

Mapeie o fluxo end-to-end do runbook

Escreva o ciclo típico: criar → revisar → usar → atualizar. Preste atenção em quem participa em cada etapa, onde ocorrem aprovações e o que aciona atualizações (mudanças de serviço, aprendizados de incidentes, revisões trimestrais).

Identifique expectativas de conformidade e auditoria

Mesmo sem regulação, times frequentemente precisam responder “quem mudou o quê, quando e por quê”. Defina requisitos mínimos de trilha de auditoria cedo: resumos de mudança, identidade do aprovador, carimbos de tempo e a capacidade de comparar versões durante a execução de um playbook de incidente.

Projete o modelo de dados para runbooks e versões

Um app de runbooks dá certo ou não dependendo se seu modelo de dados coincide com como times de operações realmente trabalham: muitos runbooks, blocos reutilizáveis, edições frequentes e alta confiança no “o que era verdade na época”. Comece definindo os objetos centrais e suas relações.

Objetos centrais

No mínimo, modele:

• Runbook: título, resumo, status (draft/published/archived), flags de severidade/caso de uso, last_reviewed_at.
• Step: itens ordenados dentro de um runbook (com ramificações de decisão opcionais).
• Tag: rotulação leve para busca e filtro.
• Service: o que o runbook cobre (pagamentos, API, pipeline de dados).
• Owner: pessoa/equipe responsável pela precisão.
• Version: snapshot imutável do runbook em um momento.
• Execution: uma “execução” registrada do runbook durante um incidente ou tarefa rotineira.

Relações que refletem operações

Runbooks raramente vivem isolados. Planeje links para que o app consiga mostrar o documento certo sob pressão:

• Runbook ↔ Service (many-to-many): um serviço pode ter vários runbooks; um runbook pode cobrir vários serviços.
• Runbook ↔ Incident type / alert rule: armazene referências a identificadores de alerta ou categorias de incidente para que integrações sugiram o playbook adequado.
• Runbook ↔ Tags: para preocupações transversais (banco de dados, impacto ao cliente, rollback).

Versionamento: draft vs. publicado

Trate versões como registros append-only. Um Runbook aponta para um current_draft_version_id e um current_published_version_id.

• A edição cria novas versões draft.
• Publicar “promove” um draft para published (criando uma nova versão publicada imutável).
• Mantenha versões antigas para auditoria e postmortems; considere políticas de retenção apenas para drafts, não para versões publicadas.

Armazenando conteúdo rico e anexos

Para passos, armazene conteúdo como Markdown (simples) ou blocos JSON estruturados (melhor para checklists, callouts e templates). Mantenha anexos fora do banco: guarde metadados (nome do arquivo, tamanho, content_type, storage_key) e coloque arquivos em storage de objetos.

Essa estrutura prepara você para trilhas de auditoria confiáveis e uma experiência de execução suave depois.

Planeje o conjunto de recursos e as jornadas de usuário

Um app de runbooks funciona quando é previsível sob pressão. Comece definindo um MVP que suporte o loop central: escrever um runbook, publicá-lo e usá-lo com confiabilidade no trabalho.

MVP: o mínimo necessário para ser útil

Mantenha o primeiro release enxuto:

• Biblioteca/lista: navegar por runbooks por serviço, equipe e tag.
• Visualização: página limpa em modo somente leitura que carrega rápido e imprime bem.
• Criar: começar do zero com título, resumo e passos ordenados.
• Editar: mudanças em draft sem afetar a versão publicada.
• Publicar: ação clara que torna uma versão “oficial”.
• Busca: busca full-text em títulos, resumos e texto dos passos.

Se não conseguir fazer essas seis coisas rapidamente, recursos extras não farão diferença.

“Gostosuras” para depois (não bloqueiam o primeiro release)

Quando o básico estiver estável, adicione capacidades que tragam controle e visibilidade:

• Templates para tipos comuns de incidente e manutenção recorrente.
• Aprovações e revisores para sistemas de alto risco.
• Execuções (checklists) para registrar o que foi feito e quando.
• Análises como runbooks mais usados, conteúdo obsoleto e buscas sem resultados.

Layout: três áreas de trabalho principais

Faça o mapa da UI refletir como operadores pensam:

1. Biblioteca de Runbooks: encontrar e filtrar rapidamente.
2. Editor: draft, revisar e pré-visualizar a visão publicada.
3. Modo de Execução: modo focado “faça os passos” com rastreamento de progresso.

Mapa de páginas simples (navegação previsível)

• /runbooks (biblioteca)
• /runbooks/new
• /runbooks/:id (visualização publicada)
• /runbooks/:id/edit (editor de draft)
• /runbooks/:id/versions
• /runbooks/:id/execute (modo de execução)
• /search

Projete jornadas de usuário por função: um autor criando e publicando, um respondedore buscando e executando, e um gerente revisando o que está atual e o que está obsoleto.

Construa um editor que mantenha passos claros e repetíveis

Um editor deve tornar a forma “correta” de escrever procedimentos a mais fácil de usar. Se as pessoas conseguem criar passos limpos e consistentes com rapidez, seus runbooks permanecem úteis sob estresse e pouco tempo.

Escolha um estilo de editor que combine com seus usuários

Existem três abordagens comuns:

• Editor Markdown: rápido para operadores experientes, ótimo para fluxo por teclado, mas facilita a perda de consistência.
• Editor por blocos: conteúdo estruturado (passos, callouts, links) com boa legibilidade; geralmente o melhor equilíbrio para equipes mistas.
• Etapas em formulário: cada passo é um formulário com campos específicos (ação, resultado esperado, responsável, links). Produz a saída mais consistente e é ideal quando é necessária repetibilidade estrita.

Muitas equipes começam com um editor por blocos e adicionam restrições estilo formulário para tipos de passo críticos.

Modele passos como objetos de primeira classe

Em vez de um documento longo, armazene um runbook como uma lista ordenada de passos com tipos como:

• Text (contexto)
• Command (com botão copiar e “output esperado” opcional)
• Link (dashboards, tickets, docs)
• Decision (ramificações if/then)
• Checklist (subitens múltiplos)
• Caution note (avisos de alta visibilidade)

Passos tipados permitem renderização consistente, busca melhor, reutilização segura e uma UX de execução superior.

Adicione guardrails que previnam “passos misteriosos”

Guardrails mantêm o conteúdo legível e executável:

• Campos obrigatórios (ex.: todo step do tipo command precisa ter comando e ambiente)
• Validação (links quebrados, placeholders vazios, pré-requisitos faltando)
• Pré-visualização que corresponda ao modo de execução para que autores vejam o que os respondedores verão
• Regras de formatação (limitar headings, padronizar nomes como “Verificar…”, “Rollback…”, “Escalar…")

Facilite a reutilização

Suporte templates para padrões comuns (triagem, rollback, checagens pós-incidente) e uma ação de Duplicar runbook que copia a estrutura e solicita atualização de campos-chave (nome do serviço, canal on-call, dashboards). Reutilizar reduz variância — e variância é onde erros se escondem.

Adicione aprovações, propriedade e lembretes de revisão

Runbooks só são úteis quando as pessoas confiam neles. Uma camada de governança leve — proprietários claros, caminho de aprovação previsível e revisões recorrentes — mantém o conteúdo preciso sem transformar cada mudança em gargalo.

Projete um fluxo de revisão simples

Comece com um pequeno conjunto de status que reflita como as equipes trabalham:

• Draft: sendo escrito ou atualizado
• In review: aguardando feedback de revisores específicos
• Approved: pronto, mas ainda não visível para todos (buffer opcional)
• Published: versão usada durante incidentes e trabalho rotineiro

Torne as transições explícitas na UI (ex.: “Request review”, “Aprovar & publicar”) e registre quem executou cada ação e quando.

Adicione propriedade e datas de revisão

Todo runbook deve ter pelo menos:

• Proprietário primário: responsável pela correção
• Proprietário de backup: cobertura para férias e rotações
• Data de revisão (ou “revisar a cada X dias”): para evitar apodrecimento silencioso

Trate propriedade como um conceito operacional de plantão: proprietários mudam conforme as equipes mudam, e essas mudanças devem ficar visíveis.

Exija resumos de mudança nas edições

Quando alguém atualiza um runbook publicado, peça um breve resumo da mudança e (quando relevante) um comentário obrigatório como “Por que estamos alterando este passo?” Isso cria contexto compartilhado para revisores e reduz trocas durante aprovação.

Planeje notificações sem se amarrar a um provedor

Revisões funcionam só se as pessoas recebê-las. Envie lembretes de “review requested” e “review due soon”, mas evite hard-code de email ou Slack. Defina uma interface simples de notificações (eventos + destinatários) e depois conecte provedores — Slack hoje, Teams amanhã — sem reescrever a lógica central.

Trate autenticação e permissões com segurança

Runbooks frequentemente contêm exatamente o tipo de informação que você NÃO quer compartilhar amplamente: URLs internas, contatos de escalonamento, comandos de recuperação e, às vezes, detalhes de configuração sensíveis. Trate autenticação e autorização como recurso central, não como endurecimento posterior.

Comece com RBAC simples

No mínimo, implemente controle de acesso baseado em funções com três papéis:

• Viewer: pode ler runbooks e usar o modo de execução.
• Editor: pode criar e atualizar runbooks que tem permissão para acessar.
• Admin: pode gerenciar permissões, equipes/services e configurações globais.

Mantenha esses papéis consistentes na UI (botões, acesso ao editor, aprovações) para que usuários não tenham que adivinhar o que podem fazer.

Escopo de acesso por equipe ou serviço (e opcionalmente por runbook)

A maioria das organizações organiza operações por equipe ou serviço, e permissões devem seguir essa estrutura. Um modelo prático é:

• Usuários pertencem a uma ou mais equipes.
• Runbooks são taggeados para um serviço (pertencente a uma equipe).
• Permissões são concedidas no nível de equipe/serviço.

Para conteúdo de alto risco, adicione um override opcional no nível do runbook (ex.: “apenas Database SREs podem editar este runbook”). Isso mantém o sistema gerenciável e suporta exceções.

Proteja passos sensíveis

Alguns passos devem ser visíveis apenas a um grupo reduzido. Suporte seções restritas como “Detalhes sensíveis” que exigem permissão elevada para visualizar. Prefira redação/ocultação (“oculto para viewers”) ao invés de exclusão para que o runbook ainda faça sentido sob pressão.

Mantenha autenticação flexível

Mesmo que comece com email/senha, projete a camada de autenticação para adicionar SSO depois (OAuth, SAML). Use uma abordagem plugável para provedores de identidade e armazene identificadores estáveis para que trocar para SSO não quebre propriedade, aprovações ou trilhas de auditoria.

Facilite a localização dos runbooks sob pressão

Quando algo está quebrado, ninguém quer vasculhar documentação. Querem o runbook certo em segundos, mesmo que lembrem apenas de um termo vago do alerta ou da mensagem de um colega. Encontrabilidade é recurso de produto, não enfeite.

Construa busca que se comporte como a mente on-call

Implemente uma caixa de busca que vasculhe mais que títulos. Indexe títulos, tags, serviço dono e conteúdo dos passos (incluindo comandos, URLs e trechos de erro). Pessoas costumam colar um trecho de log ou texto de alerta — a busca ao nível de passo é o que transforma isso em match.

Suporte correspondência tolerante: partes de palavra, erros de digitação e prefixos. Retorne resultados com trechos destacados para que usuários confirmem que acharam o procedimento certo sem abrir várias abas.

Adicione filtros que cortem o ruído instantaneamente

A busca é mais rápida quando usuários podem delimitar contexto. Forneça filtros que reflitam como times de ops pensam:

• Service (ou componente)
• Severidade (níveis SEV, prioridade)
• Ambiente (prod/stage/dev, região)
• Time/proprietário
• Última revisão (ou “revisão atrasada”)

Deixe filtros persistentes entre sessões para usuários on-call e mostre filtros ativos de forma proeminente para explicar por que resultados podem estar faltando.

Ensine o sistema sinônimos e a linguagem real de incidentes

Times não usam um único vocabulário. “DB”, “database”, “postgres”, “RDS” e um apelido interno podem significar o mesmo. Adicione um dicionário leve de sinônimos que possa ser atualizado sem redeploy (UI admin ou config). Use-o em tempo de consulta (expandir termos) e opcionalmente em indexação.

Capture também termos comuns de títulos de incidentes e labels de alertas para manter os sinônimos alinhados com a realidade.

Projete a visualização do runbook para escaneamento, não leitura

A página do runbook deve ser densa em informação e fácil de escanear: resumo claro, pré-requisitos e um sumário de passos. Mostre metadados importantes no topo (serviço, aplicabilidade de ambiente, última revisão, proprietário) e mantenha passos curtos, numerados e colapsáveis.

Inclua um recurso de “copiar” para comandos e URLs, e uma área compacta de “runbooks relacionados” para saltar para seguimentos comuns (ex.: rollback, verificação, escalonamento).

Implemente modo de execução para incidentes e tarefas rotineiras

Modo de execução é onde runbooks deixam de ser “documentação” e viram ferramenta que as pessoas podem confiar sob pressão. Trate-o como uma visão focada, sem distrações, que guia alguém do primeiro ao último passo enquanto captura o que realmente aconteceu.

UI focada: passos, status e tempo

Cada passo deve ter um status claro e superfície de controle simples:

• Uma checkbox ou botão Mark complete (mais Skip quando apropriado)
• Estados de passo como Not started / In progress / Blocked / Done
• Timers opcionais: um timer do run (desde o início da execução) e timers de passo (tempo gasto)

Pequenos detalhes ajudam: fixar o passo atual, mostrar “próximo”, e manter passos longos legíveis com detalhes colapsáveis.

Notas, links e evidências — capturadas no momento

Durante a execução, operadores precisam anexar contexto sem sair da página. Permita por-passos adições como:

• Notas livres (o que você viu, o que tentou, por que escolheu um caminho)
• Links para dashboards, tickets ou threads de chat
• Anexos de evidência (screenshots, logs, saída de comando)

Faça essas adições com timestamp automático e preserve-as mesmo se a execução for pausada e retomada.

Ramificações e caminhos de escalonamento

Procedimentos reais não são lineares. Suporte passos de ramificação “if/then” para que um runbook se adapte a condições (ex.: “Se a taxa de erro > 5%, então…”). Inclua também ações explícitas de Stop and escalate que:

• Marquem a execução como escalada/blockada
• Peçam quem foi contactado e por quê
• Opcionalmente gerem um resumo de handoff para o próximo respondedore

Armazene histórico de execuções para aprendizado

Cada execução deve criar um registro imutável: versão do runbook usada, timestamps dos passos, notas, evidências e resultado final. Isso vira a fonte de verdade para revisão pós-incidente e para aprimorar o runbook sem depender da memória.

Adicione trilhas de auditoria e histórico de mudanças confiáveis

Quando um runbook muda, a pergunta durante um incidente não é “qual a versão mais recente?” — é “podemos confiar nela e como ela chegou aqui?” Uma trilha de auditoria clara transforma runbooks em registros operacionais confiáveis, em vez de notas editáveis.

O que registrar (e por que importa)

No mínimo, registre toda mudança significativa com quem, o quê e quando. Vá além e armazene snapshots antes/depois do conteúdo (ou um diff estruturado) para que revisores vejam exatamente o que mudou sem adivinhar.

Capture eventos além de edição, também:

• Publicações: draft → published, published → archived, rollbacks
• Decisões de aprovação: quem aprovou/rejeitou, timestamp, comentário opcional
• Mudanças de propriedade: reassignment do proprietário ou time

Isso cria uma linha do tempo confiável para postmortems e verificações de conformidade.

Visões de auditoria que funcionem sob pressão

Dê aos usuários uma aba Audit por runbook mostrando um fluxo cronológico de mudanças com filtros (editor, intervalo de datas, tipo de evento). Inclua ações “ver esta versão” e “comparar com a atual” para que respondedores confirmem rapidamente que estão seguindo o procedimento pretendido.

Se for preciso, adicione opções de exportação como CSV/JSON para auditorias. Mantenha exportações permissionadas e com escopo (runbook único ou janela temporal), e considere linkar para uma página de admin interna como /settings/audit-exports.

Regras de retenção e resistência à adulteração

Defina regras de retenção compatíveis com seus requisitos: por exemplo, mantenha snapshots completos por 90 dias e depois retenha diffs e metadados por 1–7 anos. Armazene registros de auditoria append-only, restrinja exclusão e registre qualquer override administrativo como evento auditável.

Conecte o app a alertas, incidentes e ferramentas de chat

Seus runbooks ficam muito mais úteis quando estão a um clique do alerta que gerou o trabalho. Integrações reduzem troca de contexto durante incidentes, quando as pessoas estão estressadas e o tempo é curto.

Comece com um contrato simples de integração (webhooks + APIs)

A maioria dos times cobre 80% das necessidades com dois padrões:

• Webhooks de entrada das ferramentas de alerta/incidente para seu app (criar ou atualizar um “contexto de incidente”, sugerir runbooks).
• Webhooks de saída ou chamadas de API do seu app de volta para essas ferramentas (postar link do runbook escolhido, atualizações de status e decisões chave).

Um payload de entrada mínimo pode ser tão simples quanto:

{
  "service": "payments-api",
  "event_type": "5xx_rate_high",
  "severity": "critical",
  "incident_id": "INC-1842",
  "source_url": "https://…"
}

Deep links: leve respondedores ao runbook certo instantaneamente

Projete sua scheme de URLs para que um alerta aponte diretamente para o melhor match, geralmente por service + event type (ou tags como database, latency, deploy). Por exemplo:

• Link para um runbook específico: /runbooks/123
• Link para a visualização em modo de execução com contexto: /runbooks/123/execute?incident=INC-1842
• Link para um preset de busca: /runbooks?service=payments-api&event=5xx_rate_high

Isso facilita incluir a URL nas notificações dos sistemas de alerta e para humanos caírem na checklist correta sem buscas extras.

Notificações em chat e compartilhamento durante um incidente

Integre com Slack ou Microsoft Teams para que respondedores possam:

• Postar o link do runbook selecionado no canal do incidente
• Compartilhar um resumo curto (“O que estamos seguindo, quem é o dono, passo atual”)
• Manter o runbook visível enquanto decisões são tomadas

Se já tiver documentação de integrações, vincule-a na UI (por exemplo, /docs/integrations) e exponha a configuração onde times de ops esperam (uma página de settings + botão de teste rápido).

Faça deploy, proteja e itere sem desacelerar as operações

Um sistema de runbooks é parte da sua rede de segurança operacional. Trate-o como qualquer serviço de produção: faça deploy previsível, proteja contra falhas comuns e melhore em passos pequenos e de baixo risco.

Hosting, backups e recuperação de desastre

Comece com um modelo de hospedagem que seu time de ops suporte (plataforma gerenciada, Kubernetes ou um VM simples). Seja qual for a escolha, documente-a no próprio runbook do app.

Backups devem ser automáticos e testados. Não basta “tirar snapshots” — você precisa ter confiança na restauração:

• Backups do banco de dados em cronograma (e antes de upgrades maiores)
• Backups criptografados com acesso restrito
• Teste de restauração rotineiro (ex.: mensal) em um ambiente separado

Para DR, decida metas antecipadamente: quanto dado pode perder (RPO) e quão rápido precisa recuperar o app (RTO). Mantenha um checklist DR enxuto que inclua DNS, secrets e um procedimento verificado de restore.

Noções básicas de performance que evitam atrito

Runbooks são mais valiosos sob pressão, então mire em carregamentos rápidos e comportamento previsível:

• Cache para endpoints de leitura (listas de runbooks, templates)
• Paginação e filtros para resultados de busca e vistas de auditoria
• Rate limiting em autenticação e ações de escrita para reduzir abuso e sobrecarga acidental

Também registre queries lentas cedo; é mais fácil do que adivinhar depois.

Estratégia de testes que protege a confiança

Foque testes nas funcionalidades que, se quebradas, geram comportamento arriscado:

• Checagens de permissão (RBAC, propriedade, aprovações)
• Comportamento do editor (ordenação de passos, templates, validações)
• Versionamento (diffs, fluxo de publicação, rollback)

Adicione um pequeno conjunto de testes end-to-end para “publicar um runbook” e “executar um runbook” para captar problemas de integração.

Entregue iterativamente, não tudo de uma vez

Pilote com um time primeiro — idealmente o grupo com trabalho de on-call frequente. Colete feedback na ferramenta (comentários rápidos) e em revisões semanais curtas. Expanda gradualmente: adicione o próximo time, migre o próximo conjunto de SOPs e refine templates com base em uso real em vez de suposições.

Acelere a entrega com Koder.ai (sem mudar seu modelo de propriedade)

Se quiser ir do conceito a uma ferramenta interna funcional rapidamente, uma plataforma vibe-coding como Koder.ai pode ajudar a prototipar o app de gerenciamento de runbooks end-to-end a partir de uma especificação orientada por chat. Você pode iterar nos fluxos centrais (biblioteca → editor → modo de execução) e depois exportar o código-fonte quando estiver pronto para revisar, endurecer e rodar dentro do seu processo padrão de engenharia.

Koder.ai é prático para esse tipo de produto porque se alinha a escolhas comuns de implementação (React para UI web; Go + PostgreSQL no backend) e suporta modo de planejamento, snapshots e rollback — útil quando você está iterando em funcionalidades operacionais críticas como versionamento, RBAC e trilhas de auditoria.