Design de Site de Runbook de Serviço

Design do Runbook do Auth-Service

Este exemplo oficial de site do OpenDesign apresenta o runbook de um serviço de identidade da Northwind como uma única referência operacional. O título autoral é “auth-service”, seguido de responsável, versão, data de revisão e do status “TIER 0 · PRODUCTION-CRITICAL”. Essa abertura estabelece a responsabilidade do serviço antes de o leitor chegar aos alertas ou comandos.

O resumo do serviço cita a emissão, a validação e a revogação de tokens de sessão na web, no mobile e na API pública. Também identifica o armazenamento de senhas, os cadastros de TOTP/WebAuthn e o gravador do log de auditoria. Isso torna a página útil para orientação: quem responde vê quais responsabilidades voltadas ao cliente e à segurança pertencem ao serviço antes de escolher um procedimento.

Tarefas Operacionais Atendidas

O design atende a várias tarefas relacionadas sem dividi-las em páginas separadas. A ordem vai do escopo do serviço às dependências, depois alertas, procedimentos, cobertura de plantão e resposta a incidentes. Essa sequência reduz a necessidade de interpretar um alerta isoladamente: o leitor primeiro entende o que o serviço possui e, depois, como responder quando uma parte está comprometida.

A lista de dependências repete um padrão de nome e estado para Postgres, Redis, KMS, SES e Pager. Quatro entradas estão marcadas como saudáveis, enquanto SES · transactional está marcado como degradado. Os estados alinhados à direita facilitam a leitura rápida, mas são um retrato do design de exemplo, não verificações de saúde ao vivo demonstradas.

Do Alerta ao Procedimento

A seção de alertas foi pensada como uma superfície de decisão de quatro colunas: alerta, severidade, o que significa e primeira resposta. Por exemplo, “auth.login_5xx_rate greater than 1%” é associado a “SEV-1”, a uma explicação de bloqueio de clientes e à orientação de inspecionar os dashboards de Postgres e Redis. O limite explícito dá a quem responde um gatilho, enquanto o texto fornece a interpretação; em contrapartida, os valores de exemplo ainda precisariam de uma fonte de monitoramento verificada em um runbook real.

A seção de procedimentos muda o ritmo, de linhas compactas para blocos grandes com título, nota de uso, frase explicativa e painel de comandos. “Deploy a new version” indica que o fluxo é blue/green e aguarda dois healthchecks consecutivos antes da promoção. A sequência visível de tráfego, “10% / 50% / 100%”, comunica um rollout em etapas, e o bloco maior consome mais espaço vertical em troca de uma leitura mais segura no nível dos comandos.

Comandos e Restrições

Os blocos de procedimento mantêm ação e cautela lado a lado. O rollback é indicado para quando a taxa de erro pós-deploy excede 1%, enquanto a rotação da chave de assinatura diz “Schedule with security; never solo”. O procedimento do log de auditoria está explicitamente ligado ao alerta de backlog. Esses pares mostram uma boa escolha de design da informação: o comando não é apresentado como suficiente por si só, e a condição ao redor define quando ele pertence ao fluxo.

Sequência do Incidente e Limite de Capacidade

A seção final de resposta a incidentes converte os primeiros trinta minutos em cinco cartões numerados. A sequência começa com o reconhecimento em até cinco minutos, abre um canal de incidente dedicado, exige um resumo de status a cada dez minutos, prioriza a mitigação e termina com a passagem de bastão ou o encerramento. A numeração deixa a ordem pretendida visível; o arranjo em duas colunas mantém as quatro primeiras ações compactas, enquanto o quinto cartão ocupa apenas o próprio conteúdo.

Este é um exemplo de site apenas de design. A página capturada apresenta visualmente comandos, status, nomes e resultados de exemplo, como “rolled back to v4.7.2 in 38 s”, mas isso não comprova que os comandos sejam executados, que os serviços estejam conectados ou que os resultados operacionais exibidos tenham sido medidos. As adaptações devem preservar a distinção entre orientação documentada e dados de execução verificados.

1. Reconheça o Acionamento

   O design começa com /ack e uma janela de resposta de cinco minutos, estabelecendo a primeira obrigação de coordenação.

2. Abra o Canal do Incidente

   O segundo cartão indica o nome do serviço e o padrão de título curto usado para criar um espaço de resposta dedicado.

3. Publique um Resumo de Status

   O terceiro cartão condensa impacto ao cliente, conhecimento atual e próximas verificações em uma atualização repetível.

4. Mitigue e Passe o Bastão

   Os dois últimos cartões priorizam rollback ou escalonamento de segurança e, depois, definem a passagem de bastão e o encerramento.