Janelas de serviço

1) O que é uma «janela de serviço» e o que é necessário

A janela de manutenção é um intervalo de tempo pré-acordado para trabalhos que potencialmente afetam a disponibilidade/desempenho. O objetivo é uma mudança controlada, com risco previsível, comunicação transparente e relatórios de provas.

• Planned (programado): lançamentos, migração, rotação de certificados/chaves, upgrades de BD/corretores.
• Emergency (emergência): gravações de segurança/reversões de emergência.
• Silent/Zero-impacto: sem influência personalizada (canários ocultos, réplicas, entrada paralela).
• Provider-led: janelas de provedores externos (PSP/KYC/CDN/Cloud).

2) Princípios

SLO-first: A decisão sobre o tempo/formato da janela é tomada pelo impacto no SLI e nos orçamentos de erro.
Raio mínimo de explosão, canário → passo → total.
Reversível: Cada operação tem um plano backout e uma reversão verificada.
Uma única fonte de verdade: calendário de janelas + tíquete/RFC com pacote completo de dados.
Prova: coleta de evidence (logs, gráficos, screenshots, hashs artefactos).
Comunicações SLA: adiantado, durante o trabalho, após a conclusão.

3) Planejamento: escolha do tempo e do alcance

A escolha da janela é baixo tráfego, o mínimo de impactos para os cômodos-chave (regiões/VIP/parceiros).
Fuso horário: fixe em UTC + horário local (por exemplo, Europe/Kyiv).
Período de Blacklout: proibição de trabalhos em estações de pico/eventos (jogos, vendas, janelas da morte).
Blast radius: definir claramente quem será afetado (serviços, regiões, provedores).

4) Processo de negociação (RFC/FAB lite)

1. O iniciador cria um tíquete/RFC com análise de risco e plano (consulte o modelo abaixo).
2. Avaliação de risco (Low/Ted/High) e aprovação pelo proprietário do serviço + SRE/segurança.
3. Calendário: reserva slot; verificação de conflitos (outras janelas/provedores).
4. Plano comm: notificações pré-acordadas e página de status.
5. Reunião Go/No-Go (24-48 h) para alterações High-risk.

5) Preparação: gates de segurança

Testes pré-lançamento: testes de stage bem sucedidos, artefatos assinados, riscos totais ≤ aceitáveis.
Canário: 1%→5%→25% em linha/região; Guarda SLO automático e auto-recall.
As bandeiras da degradação e os limites estão prontos.
O plano Rollback/backout foi testado na caixa de areia; os comandos de reversão estão documentados.
Supressão de alertas: Apenas para o ruído esperado, os sinais SLO não são silenciosos.
Disponíveis: JIT/JEA aulas de operações, auditoria de mandatos.

6) Comunicações (timing e conteúdo)

T-14/7/2 dias (programados): heads-up para clientes/comandos internos (que/quando/influência/contatos).
T-60/30/15 minutos: lembretes dentro e na página de status.
Durante o trabalho: update a cada 15 a 30 minutos (V-dependente) no modelo: Impacto → Etapa → Próxima atualização.
Depois: final «Completed/Partially completed/Rolled back», lista de alterações, verificação SLO.

7) Realização de obras (cenário de cenário)

1. Freeze lançamentos não relacionados.
2. A mudança para canary (cômodo limitado) observa → SLI/métricas p95/p99.
3. Aumento passo a passo da participação nas gardrelas verdes.
4. Verificação de SLI de negócios (conversão, sucesso de pagamentos/registros).
5. Verificação de função por folha de cheque (happy path + cenários críticos).
6. Release/No-release solução (IC/SRE/proprietário do serviço).
7. Retirada da supressão, restituição de políticas alert.

8) Após a janela: verificação e relatórios

Observation window (por exemplo, 1-24 h): rastreamento de SLO e erros.
Relatório da janela, o que faziam, métricas, desvios, evidências, resultados.
Se houve problemas, AAR→RCA→CAPA (fixe de regras, testes, documentação).
Tíquete, artefactos, assinaturas, somas de controlo.

9) Coordenação com provedores externos

Slots confirmados e contatos do provedor; uma janela no seu sistema de status.
Folback/roteamento para provedor alternativo durante o período de trabalho.
Um único war-room com um provedor (chat/bridge) e um SLA update.

10) Métricas de maturidade do processo

On-time rate:% das janelas iniciadas/concluídas dentro do prazo.
Mudar failure rate:% das janelas com reversão/influência no SLO.
Invident-during-MW: Incidentes ocorridos durante a janela.
Comunicação SLA: proporção de updates pontuais.
Evidence completeness:% das janelas com pacote completo de provas.
Customer impact: queixas/tíquetes para 1 janela, tendência.
Após 7/30 dias, estabilidade do SLO e ausência de reincidência.

11) Folhas de cheque

Antes da janela

• RFC/tíquete está cheio; A avaliação de risco foi cumprida; O dono está nomeado.
• O plano canário e backout foram testados; os comandos de reversão foram testados.
• Os JIT disponíveis foram emitidos; os alerts estão configurados (o SLO não está calado).
• O calendário/status da página e as notificações estão prontas.
• Lançamentos/janelas concorrentes - congelados/movidos.
• Provedores confirmados; contatos e SLA gravados.

Durante

• Os Updates de acordo com o cronograma; war-room está ativo.
• Gardrelas SLO/pico de erros são respeitados; em caso de violação, reversão automática.
• Evidence está sendo recolhido (capturas de tela, gráficos antes/depois, logs de ação).

Depois

• SLO na área verde durante a observação window.
• Relatório final com evidência; o status da página foi atualizado.
• CAPA foram formalizados (se houve desvios); documentação atualizada.

12) Modelos

Modelo de RFC para janela de serviço

RFC: MW-2025-11-05-DB-Upgrade
Window: 2025-11-05 00: 00-02: 00 UTC (Europe/Kyiv 02: 00-04: 00)
Service/component: payments-db (PostgreSQL cluster A)
Type: Planned (High)
Target: Upgrade to 15. x for security/bugs
Blast radius: EU region, tenant EU, all write operations
Impact: up to 2 × p99 growth to 400 ms; short-term read-only (≤5 min)
Gardrails: error-rate <0. 5%, p99 <400 ms, SLO not impaired
План: expand→migrate→contract; canary 1 %/5 %/25%; 1..N steps (with commands)
Backout: rolling back replica/slots; TTL DNS does not change; rollback time ≤ 10 min
Suppression: noise of database/replica alerts; SLO alerts are active
Communications: T-7/T-2 days and T-60/15 minutes; war-room #mw-db-a
Owners: @ db-tl, @ sre-ic, @ payments-pm
Evidence: before/after p95/p99 graphs, migration logs, checksums
Risk: High (data) - confirmed by CAB

Modelo de notificação do cliente (resumido)

Topic: Planned work 05. 11. 2025 02:00–04:00 (Europe/Kyiv)
We will update the payment database. Short delays and read-only mode (up to 5 minutes) are possible.
On-call contacts: status. example. com      support@example. com

Regras de supressão (ideia)

yaml suppress:
- name: db-maintenance when: window("2025-11-05T00:00Z","2025-11-05T02:00Z")
match: [ "db. replica. lag", "db. connection. reset", "migration. progress" ]
keep: [ "slo. payment. success", "api. availability" ]

13) Características para domínios regulados

A auditoria é imutável, quem aprovou, quem executou, quais comandos, os artefactos.
PII/finanças: camuflagem em evidence, acesso limitado a relatórios.
Os prazos de notificação para clientes e parceiros são de acordo com os contratos.
Janelas de provimento - Documentado com SLA e contatos externos.

14) Anti-pattern

Janela sem plano backout e reversão verificada.
Silenciamento de sinais SLO por precaução.
Janelas concorrentes no mesmo domínio/região.
Não há updates «antes/durante/depois».
Edição manual de venda sem auditoria ou script.
Janelas «infinitas» devido a critérios de sucesso incertos.
Falta de evidência - não há como confirmar a qualidade.

15) Mapa de trânsito de implementação (4-6 semanas)

1. Ned. 1: digite um calendário único e um modelo RFC; determinar os períodos de blacklout.
2. Ned. 2: normalizar gates (canário, guardrelas SLO, backout).
3. Ned. 3: automatizar supressão/anotação de lançamentos e status-página.
4. Ned. 4: relatórios e métricas de maturidade; MW-review semanal.
5. Ned. 5-6: integração com os provedores e arquivos de auditoria; simulação da janela High-risk.

16) Resultado

As janelas de serviço corretamente organizadas são mudanças controladas, reversíveis e comprovadamente seguras. Com gardrelas SLO, canários, comunicações rigorosas e um conjunto completo de evidence, a janela passa de «tempo de interrupção terrível» para um mecanismo rotineiro de melhorias sem surpresas para usuários e parceiros.