# Runbooks Críticos Guia rápido e prático para situações que **não podem dar errado**.\ Em qualquer dúvida: priorize **proteger o cliente, a liquidez e a reputação da Rise**. *** ### 1. Incidente técnico grave / Queda da plataforma #### Quando acionar * Clientes não conseguem: * acessar a conta, * visualizar saldo/extratos, * investir ou resgatar. * Erros generalizados em fluxo crítico (onboarding, funding, ordens). #### Objetivo Restaurar o serviço o mais rápido possível e comunicar com transparência. #### Time envolvido * **Incident Owner:** Tech Lead * **Apoio:** CEO/CTO, Dev interno + Hous3, Head de Operações, Community Manager, Head de Marketing #### Passo a passo (V1) 1. **Assumir o incidente** * Tech Lead declara: *“Incidente aberto – plataforma com problema em X”*. * Cria-se um canal específico no Lark para o incidente (ex.: `#incidente-plataforma-data`). 2. **Classificar severidade** * **Sev0:** total/parcial de operação crítica (investir, sacar, acessar conta). * **Sev1:** impacto alto, mas com contorno. * **Sev2:** impacto moderado. 3. **Mitigar rápido** * Verificar últimos deploys, logs e status de serviços. * Se necessário: **rollback**, desligar feature flag ou módulo específico. * Objetivo: voltar ao estado estável anterior, mesmo que com menos funcionalidades. 4. **Comunicar status** * Head de Operações + Community Manager: * Atualizam **status page** (quando aplicável). * Preparam mensagem padrão para suporte e comunidade: * “Estamos com instabilidade em X. Nosso time já está atuando. Avisaremos assim que normalizar.” 5. **Normalizar e encerrar** * Tech Lead confirma estabilização. * Comunicar fim do incidente (status page, canais internos). 6. **Registrar e aprender** * Em até 48h, fazer um debrief curto: * O que aconteceu * Causa raiz provável * O que foi feito * Melhorias para evitar repetição * Documentar no GitBook na seção de incidentes. *** ### 2. Problema grave em liquidação / conciliação D+1 (Avenia) #### Quando acionar * Divergência relevante entre: * valores recebidos via Avenia * registros da plataforma / saldos de clientes * Ex.: aporte não refletido, resgate sem liquidação, valores errados para vários clientes. #### Objetivo Proteger o cliente e corrigir divergências financeiras com rastreabilidade. #### Time envolvido * **Incident Owner:** Head de Operações * **Apoio:** CFO, CEO/CTO, Avenia, Tech Lead, Community Manager (se afetar muitos clientes) #### Passo a passo (V1) 1. **Detectar e delimitar impacto** * Operações identifica a divergência em conciliação D+1. * Listar: * Quantos clientes * Qual o valor envolvido * De qual período. 2. **Escalar para CFO e CEO/CTO** * Head de Operações abre incidente no Lark com resumo objetivo. * CFO avalia risco financeiro imediato. 3. **Congelar ações de risco** * Se necessário, pausar temporariamente: * novos aportes em oferta específica * resgates em fluxo afetado * Sempre informando claramente o motivo. 4. **Alinhar com Avenia** * Operações + CFO entram em contato com Avenia para entender: * se houve falha de arquivo, atraso, duplicidade etc. 5. **Definir plano de correção** * Ajuste manual pontual ou correção sistêmica com Tech Lead. * Sempre preservar trilha: o que mudou, quando e por quem. 6. **Comunicar clientes afetados (se necessário)** * Mensagem clara, sem jargão técnico, explicando: * problema * impacto * prazo de correção * Comunicação feita por canais oficiais (e-mail/app), nunca só via WhatsApp. 7. **Registrar e documentar** * Guardar relatório simples: causa, impacto, correções e melhorias. * Ajustar processos, se preciso (ex.: checagens extras em D+1). *** ### 3. Incidente de segurança da informação #### Quando acionar * Suspeita de vazamento de dados. * Dispositivo corporativo perdido/roubado com acessos ativos. * Acesso indevido a sistemas da Rise ou parceiros. * Campanha de phishing bem-sucedida em alguém do time. #### Objetivo Conter o incidente, proteger dados de clientes e da Rise e cumprir obrigações legais. #### Time envolvido * **Incident Owner:** CEO/CTO * **Apoio:** Tech Lead, Head de Operações, CBA, CFO #### Passo a passo (V1) 1. **Identificar e conter** * Revogar acessos suspeitos (e-mail, Lark, repositórios, Cockpit). * Forçar **reset de senhas** e revisar sessões ativas. * Se for dispositivo perdido: acionar recursos de bloqueio remoto. 2. **Mapear o que pode ter sido exposto** * Tipo de dados: pessoais, financeiros, credenciais, internos. * Volume aproximado de impacto. 3. **Acionar CBA (Jurídico & Compliance)** * Entender necessidade de comunicação formal a autoridades ou titulares (LGPD). * Definir estratégia de notificação (se aplicável). 4. **Definir comunicação interna** * Mensagem clara para o time: * O que aconteceu (sem pânico) * O que já foi feito * O que cada um deve fazer (troca de senha, atenção a e-mails etc.) 5. **Analisar causa raiz** * Ex.: credencial vazou, phishing, falha de configuração. * Definir correções técnicas e processuais. 6. **Documentar incidente** * Registro interno com: * Linha do tempo * Impacto * Medidas tomadas * Plano de prevenção para o futuro. *** ### 4. Crise de comunicação / Erro público em oferta ou material #### Quando acionar * Post, campanha, e-mail ou material público: * com informação errada sobre produto/oferta, * com interpretação equivocada de risco/retorno, * que gera repercussão negativa relevante. #### Objetivo Corrigir a informação rapidamente, minimizar dano reputacional e ficar em conformidade regulatória. #### Time envolvido * **Incident Owner:** CBDO/CMO * **Apoio:** Head de Marketing, Community Manager, CBA, CEO/CTO, CRO #### Passo a passo (V1) 1. **Pausar o material problemático** * Tirar do ar o post, página, campanha ou peça em questão (quando possível). * Parar impulsionamento/anúncios relacionados. 2. **Informar CBA e CEO/CTO** * Enviar o material e explicar o contexto de forma objetiva. * Verificar se há potencial infração regulatória. 3. **Definir mensagem de correção** * Junto com CBA: * Redigir esclarecimento ou correção. * Decidir se será público (post, e-mail, nota) ou direcionado (apenas para quem recebeu). 4. **Responder à comunidade** * Community Manager: * Responde dúvidas e comentários com texto alinhado à comunicação oficial. * Evitar discussões técnicas em excesso; direcionar para canais oficiais quando necessário. 5. **Rever processo interno** * Entender por que o material foi ao ar sem a revisão adequada (ou com falha). * Ajustar fluxo de aprovação (ex.: mais checagem com CBA para certos tipos de peça). 6. **Documentar o caso** * Registrar o que houve, como foi tratado e quais mudanças de processo foram feitas. *** ### 5. Prioridade prática: o que fazer primeiro? Quando algo grave acontecer e você tiver dúvida **qual runbook aplicar**, siga esta ordem de pensamento: 1. **Há risco imediato para dinheiro ou dados do cliente?** * Sim → acione **Incidente de Segurança** ou **Liquidação/Conciliação**. 2. **Clientes estão impossibilitados de usar a plataforma?** * Sim → acione **Incidente Técnico / Queda da Plataforma**. 3. **Há informação errada ou confusa circulando publicamente?** * Sim → acione **Crise de Comunicação / Material Público**. > Em qualquer um dos casos, se você não for o responsável direto,\ > **avise imediatamente seu líder de área e o CEO/CTO no Lark** com um resumo em 3 linhas:\ > \&#xNAN;*o que aconteceu, desde quando e quem está sendo afetado*. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://rise-finance-2.gitbook.io/internal/playbook/runbooks-criticos.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.