DevOps para cliente estrangeiro: plantão e incidente fora do horário

Um incidente de infraestrutura fora do horário comercial pode envolver profissionais em vários países, fornecedores externos e pessoas com permissões diferentes. Para quem presta serviços DevOps a um cliente estrangeiro, a escala de plantão precisa explicar quem acompanha o ambiente, quem recebe o alerta e quem pode autorizar mudanças. Estar em uma escala não significa assumir sozinho toda a operação.

O contrato e o procedimento operacional devem trabalhar juntos. O primeiro define cobertura, responsabilidades e remuneração; o segundo organiza o acionamento real. Quando essas duas partes são vagas, surgem conflitos sobre disponibilidade, demora na resposta, decisões emergenciais e horas cobradas depois do incidente.

Defina a cobertura com fuso e calendário explícitos

Registre o período de plantão, o fuso de referência e o calendário utilizado. Informe como mudanças de horário sazonal, feriados e trocas de escala serão tratadas. Uma indicação como “durante a noite” não esclarece qual noite está coberta quando prestador e cliente estão em países diferentes.

Separe disponibilidade contratada de trabalho efetivamente acionado. Defina também se a cobertura envolve observação contínua, recebimento de alertas ou atendimento a chamados classificados pelo cliente. Cada modelo exige uma organização distinta. A escala deve conter responsável principal, substituto e forma de confirmação, sem depender da suposição de que alguém lerá uma mensagem enviada a um grupo amplo.

Estabeleça o que autoriza o acionamento

Crie critérios de severidade e indique quem pode abrir um incidente. Diferencie indisponibilidade relevante, degradação, alerta preventivo e solicitação comum de mudança. Um pedido para instalar uma nova ferramenta à noite não se transforma automaticamente em incidente crítico porque foi enviado fora do horário habitual.

Associe cada situação ao canal previsto e às informações mínimas: ambiente afetado, impacto observado, horário e identificador do alerta. Se o cliente usar uma classificação provisória, registre como ela será revista. Evite discutir a cobrança enquanto o ambiente está instável; preserve os fatos para uma revisão posterior, conforme as condições previamente acordadas.

Separe resposta, diagnóstico e recuperação

Defina o que conta como confirmação de recebimento e o que caracteriza início do atendimento. Não confunda essas etapas com resolução definitiva. O tempo de recuperação pode depender de acesso, decisão do cliente, fornecedor de nuvem ou condição técnica que o prestador não controla integralmente.

Em um exemplo contratual hipotético, as partes podem estabelecer uma janela de resposta para determinada severidade. Isso não deve ser divulgado como garantia universal de restauração no mesmo prazo. Registre condições, dependências e critérios de medição. A documentação deve permitir verificar o que foi assumido e o que ocorreu, sem transformar uma meta operacional em promessa indefinida sobre qualquer falha possível.

Organize a autoridade durante o incidente

Defina quem coordena o atendimento, quem executa alterações e quem comunica o cliente. O Google SRE apresenta a separação dessas funções e a importância de uma passagem de responsabilidade explícita. Para uma equipe pequena, uma pessoa pode acumular funções, mas elas precisam continuar compreensíveis.

Registre quais ações estão previamente autorizadas e quais exigem confirmação. Reiniciar um serviço, restaurar um backup e alterar uma política de acesso possuem impactos diferentes. Use os procedimentos de segurança acordados e preserve o histórico das decisões. Não adote o compartilhamento de senhas como solução para uma escala incompleta; a cobertura deve ser compatível com acessos individuais e responsabilidades definidas.

Faça a passagem de turno com uma posição utilizável

Ao trocar o responsável, informe o impacto atual, as ações executadas, os resultados e os próximos passos. Inclua referências para registros e painéis, evitando copiar segredos ou dados pessoais em canais inadequados. O novo responsável deve confirmar que assumiu o caso, para que a responsabilidade não fique implícita entre duas agendas.

Considere um incidente iniciado às 22h40, com troca de escala às 23h. O primeiro profissional registra a hipótese investigada e a alteração já realizada; o segundo confirma o recebimento e continua a análise. Se ambos atuarem durante a transição, descreva esse período. A passagem organizada reduz ações repetidas e permite explicar posteriormente a participação de cada pessoa.

Vincule a cobrança ao modelo contratado

O contrato pode prever mensalidade pela disponibilidade, franquia de ativações, cobrança por tempo ou combinação dessas condições. Escolha referências que permitam conferir o cálculo. Registre identificador do incidente, horários, pausas justificadas, participantes e atividades, preservando a diferença entre permanecer disponível e trabalhar em um chamado.

Imagine um contrato com cobertura mensal e duas horas de atendimento incluídas. Em um incidente com três horas de atuação elegível, a revisão deve mostrar as duas horas consumidas e a hora excedente conforme a regra acordada. Não cobre novamente toda a disponibilidade como horas de incidente. O CPC 47 orienta a análise da receita contratual; a invoice e o controle operacional devem apoiar, sem substituir, essa avaliação.

Revise o incidente antes do próximo plantão

Após estabilizar o ambiente, reúna a cronologia, as causas identificadas, as limitações e as ações propostas. Diferencie a atuação do prestador de falhas em serviços externos, sem presumir responsabilidade apenas porque o alerta chegou durante sua escala. Uma revisão útil procura melhorar o processo e esclarecer fatos, não atribuir culpa sem investigação.

A publicação NIST SP 800-61r3, de 2025, trata a resposta a incidentes de segurança no contexto da gestão de riscos. Nem todo chamado DevOps é um incidente de segurança; quando houver essa suspeita, acione o procedimento específico do cliente. Feche a revisão com responsáveis pelas melhorias, ajustes de alertas e eventual atualização do contrato, preservando as condições que valeram no atendimento já realizado.

Perguntas frequentes

Estar de plantão significa monitorar todos os sistemas continuamente?

Depende do serviço contratado. A cobertura pode envolver monitoramento contínuo, recebimento de alertas ou atendimento a acionamentos específicos. Defina ambientes, canais, períodos e responsabilidades. A escala, sozinha, não esclarece quais atividades devem ocorrer enquanto não existe um chamado aberto.

Como cobrar um incidente que atravessa a troca de turno?

Use o identificador do mesmo incidente e registre a participação de cada profissional, incluindo a passagem de responsabilidade. Aplique as regras contratuais de franquia, tempo elegível e eventual atuação simultânea. Evite somar duas vezes o mesmo período sem uma condição que justifique a cobrança.

Se a nuvem do cliente falhar, o DevOps deve garantir a recuperação imediata?

A responsabilidade depende do escopo e das condições contratadas. O prestador pode ter deveres de diagnóstico, comunicação e contingência, mas a restauração pode depender de terceiros. Diferencie resposta e recuperação, registre as dependências e não assuma uma garantia de prazo que não possa ser sustentada.

Fontes oficiais

• Google SRE — organização e coordenação de incidentes
• NIST SP 800-61r3 — resposta a incidentes e gestão de riscos
• CPC 47 — receita de contrato com cliente

Leituras relacionadas

• Como definir plantão por incidente em um contrato mensal de backend
• Guias para exportadores de serviços

Como a Zen pode ajudar

A contabilidade para exportação de serviços da Zen ajuda a organizar documentos, conciliar recebimentos e analisar as regras da sua operação. Peça uma proposta personalizada para conversar sobre o seu caso.