Capítulo 27 — Implantação e validação
Mapa da aula
Aula 27 publicada. Mapa, exemplo, EX079.
flowchart TD
N0["27.1 Pré-verificações"]
N1["27.2 Canários e critérios de promoção"]
N2["27.3 Validação depois da implantação"]
N3["27.4 O que a janela não consegue mostrar"]
N4["27.6 Atividade prática: decisão do canário"]
N5["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX079"]
Desenho lógico
flowchart LR
N0["27.1 Pré-verificações"]
N1["27.2 Canários e critérios de promoção"]
N2["27.3 Validação depois da implantação"]
N3["27.4 O que a janela não consegue mostrar"]
N4["27.6 Atividade prática: decisão do canário"]
N5["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX079"]
[27.1 Pré-verificações]
|
v
[27.2 Canários e critérios de promoção]
|
v
[27.3 Validação depois da implantação]
|
v
[27.4 O que a janela não consegue mostrar]
|
v
[27.6 Atividade prática: decisão do canário]
|
v
[Síntese do capítulo]
|
v
[Exemplo resolvido] --> [Exercício EX079]
Objetivos de aprendizagem e conexão
Depois deste capítulo, você deve ser capaz de:
- preparar uma implantação com pré-verificações, incluindo a verificação do que está sendo implantado;
- implantar em etapas, com um canário e critérios explícitos de promoção e de rollback;
- validar depois da implantação contra as propriedades funcionais e de segurança do serviço;
- declarar o que uma janela de validação pode e não pode mostrar.
O Capítulo 14 planejou mudanças; o Capítulo 22 automatizou a configuração. Este capítulo trata de implantações de software — uma nova versão do relay, uma atualização do historiador —, em que a mudança é maior e mais difícil de prever. Em serviços críticos, o objetivo é encontrar um problema num único host, num horário tranquilo, com um rollback pronto, e não em todos os hosts no pico da manhã.
27.1 Pré-verificações
Antes de implantar: a mudança está aprovada; a operação conhece a janela; um backup da configuração foi feito e o pacote de rollback está preparado; e o próprio pacote está verificado — a sua assinatura ou o digest publicado conferido contra o do fornecedor, para que o que você instala seja o que o fornecedor liberou. As orientações de desenvolvimento seguro pedem aos produtores que protejam a integridade do software liberado, por exemplo com assinaturas (NIST SP 800-218); como implementador, a sua parte nisso é conferi-las, e tratar um pacote não verificável como um achado.
27.2 Canários e critérios de promoção
Uma implantação canário instala a nova versão primeiro num único host e a compara com os hosts ainda na versão antiga, no mesmo período e sob a mesma carga. O workbook de SRE do Google descreve o canário como uma implantação parcial e limitada no tempo, avaliada contra uma população de controle antes da implantação mais ampla (workbook de SRE do Google, Canarying releases). Escreva os critérios de promoção antes de implantar: para o LANTERN, razão de aceitação no máximo 0,2 ponto percentual abaixo do controle; latência p95 no máximo 25 % acima do controle; nenhuma reinicialização; rejeições por MAC inalteradas. Se algum critério falhar, faça o rollback do canário e abra um registro de problema. Se todos passarem, promova um host por vez.
27.3 Validação depois da implantação
Depois de atualizar cada host, valide: as propriedades funcionais (todas as estações aceitas, latência normal, historiador recebendo); as propriedades de segurança (verificações de MAC ainda aplicadas — injete uma mensagem de teste com um MAC errado; listeners inalterados — execute a verificação de deriva; logs ainda encaminhados e interpretados — confira as contagens do normalizador); e as propriedades operacionais (alertas ainda avaliados; relatório de saúde verde). As regressões de segurança são fáceis de perder, porque um serviço pode funcionar perfeitamente enquanto uma verificação foi desativada em silêncio.
No RLY-03, a verificação de deriva depois do 2.4.1 ainda mostrava o listener de depuração: a função passou, uma propriedade de segurança não.
27.4 O que a janela não consegue mostrar
Um canário de uma hora, à noite, mostra o comportamento sob a carga noturna durante uma hora. Ele não diz nada sobre o pico de demanda da manhã, as execuções semanais de relatórios (Capítulo 1), os relatórios de fim de mês ou os tipos raros de mensagem. Estenda a janela pelos períodos que importam ou declare a lacuna e observe esses períodos de perto depois da promoção.
O canário do relayd 2.4.1 rodou durante uma hora noturna, por isso a sua queda de 0,0010 na razão de aceitação foi registrada como item em aberto para o pico da manhã.
As execuções semanais de relatórios nos dias 6 e 7, com cerca de 62 % de CPU, são outro período que uma hora à noite não consegue mostrar.
27.5 Exemplo resolvido: relayd 2.4.1 (sintético)
As pré-verificações passam: mudança aprovada, sala de controle informada, configuração com backup, pacote de rollback preparado, assinatura do pacote verificada. O canário RLY-03 roda o 2.4.1 durante uma hora, contra o RLY-01 no 2.4.0. Razão de aceitação de 0,9985 contra 0,9994 (uma queda de 0,0010, dentro de 0,002); latência p95 de 41 ms contra 37 ms (dentro de 25 %); nenhuma reinicialização; rejeições por MAC inalteradas. Decisão: promover para o RLY-02, depois para o RLY-01. A validação pós-implantação no RLY-03 injeta uma mensagem de teste com MAC errado (rejeitada, como esperado) e executa a verificação de deriva — que ainda mostra o listener de depuração do Capítulo 22, um lembrete de que a implantação não corrigiu a deriva de configuração e não deve ser relatada como se tivesse corrigido. A queda na razão de aceitação, embora dentro dos critérios, é registrada como item em aberto a conferir no pico da manhã.
27.6 Atividade prática: decisão do canário
Laboratório 27 (salve como lab27.py, execute com python3 lab27.py):
# Lab 27 - pre- and post-deployment validation with a canary and a rollback rule (offline, standard library only)
# Synthetic: relayd 2.4.1 rolled to rly-03 first (canary), compared with rly-01 still on 2.4.0 for one hour.
checks_pre = {"backup of config taken": True, "rollback package staged": True, "change ticket approved": True,
"operations told (control room)": True, "maintenance window open": True, "signature of package verified": True}
canary = {"msgs_in": 7200, "msgs_accepted": 7189, "mac_rejects": 0, "p95_latency_ms": 41, "cpu_p95": 38, "restarts": 0}
control = {"msgs_in": 7200, "msgs_accepted": 7196, "mac_rejects": 0, "p95_latency_ms": 37, "cpu_p95": 36, "restarts": 0}
limits = {"accept_ratio_drop": 0.002, "latency_ratio": 1.25, "restarts": 0}
print("pre-checks:", "PASS" if all(checks_pre.values()) else "FAIL " + str([k for k, v in checks_pre.items() if not v]))
ra, rc = canary["msgs_accepted"] / canary["msgs_in"], control["msgs_accepted"] / control["msgs_in"]
results = {
"acceptance ratio": (rc - ra <= limits["accept_ratio_drop"], f"{ra:.4f} vs {rc:.4f} (drop {rc-ra:.4f})"),
"p95 latency": (canary["p95_latency_ms"] <= control["p95_latency_ms"] * limits["latency_ratio"], f"{canary['p95_latency_ms']} vs {control['p95_latency_ms']} ms"),
"restarts": (canary["restarts"] <= limits["restarts"], str(canary["restarts"])),
"MAC rejects unchanged": (canary["mac_rejects"] == control["mac_rejects"], str(canary["mac_rejects"])),
}
for k, (ok, detail) in results.items(): print(f" {k:<22} {'pass' if ok else 'FAIL'} {detail}")
print("decision:", "promote to rly-02, then rly-01" if all(ok for ok, _ in results.values()) else "ROLL BACK canary and open problem record")
# What the canary cannot show: a 1-hour window at night says nothing about the morning demand peak or month-end reports.
Saída esperada (Python 3.13.5):
pre-checks: PASS
acceptance ratio pass 0.9985 vs 0.9994 (drop 0.0010)
p95 latency pass 41 vs 37 ms
restarts pass 0
MAC rejects unchanged pass 0
decision: promote to rly-02, then rly-01
Confira cada linha contra os critérios fixados antes da janela: razão de aceitação de 0,9985 contra 0,9994, uma queda de 0,0010, dentro dos 0,002 permitidos; latência p95 de 41 ms contra 37 ms, dentro de 25 %; nenhuma reinicialização; rejeições por MAC inalteradas. Tudo passa, então a decisão é promover para o RLY-02, depois para o RLY-01, um host por vez. A queda, embora dentro dos critérios, fica na lista de itens em aberto para o pico da manhã.
Se a queda tivesse sido de 0,0025, a regra fixada de antemão teria exigido o rollback, por menor que a diferença parecesse.
27.7 Erros comuns e limites
- Instalar pacotes sem verificar a sua origem.
- Critérios de promoção decididos depois de ver os resultados do canário.
- Validar a função, mas não as propriedades de segurança.
- Uma janela de canário que perde os períodos de carga real.
- Promover todos os hosts restantes de uma vez depois do canário.
- Rollback nunca testado.
A implantação do relayd 2.4.1 evitou cada um: assinatura verificada, critérios fixados antes do canário, uma mensagem com MAC errado injetada depois e promoção de um host por vez.
O item em aberto para o pico da manhã é a forma de tratar o quarto quando a janela não pode ser mais longa.
Exercícios — capítulo 27
EX079 — Reprove o canário. Objetivo: aplicar a regra de rollback. Entradas: Laboratório 27. Restrições: mude apenas os números do canário. Etapas: (1) defina a contagem de aceitas do canário como 7170; (2) execute; (3) declare a decisão e as três primeiras ações. Evidência esperada: saída e ações. Rubrica: 3 = queda de aceitação ≈ 0,0036 reprova no critério de 0,002, decisão de rollback; ações: rollback do canário sob a mudança, preservar os logs do canário e os motivos de rejeição, abrir registro de problema e informar a sala de controle; 2 = decisão certa, ações rasas; 1 = não executado; 0 = nada.
EX080 — Conjunto de validação de segurança. Objetivo: especificar as verificações de segurança pós-implantação. Entradas: Capítulo 27 ("Validação depois da implantação"). Restrições: cinco verificações, cada uma com o resultado esperado. Etapas: liste-as. Evidência esperada: tabela. Rubrica: 3 = teste com MAC errado rejeitado, teste de replay rejeitado, verificação de deriva sem novos listeners, contagem de não interpretados do normalizador inalterada, serviço rodando com conta sem privilégios, teste de alerta ainda dispara; 2 = quatro; 1 = só função; 0 = nada.
EX081 — Estenda a janela. Objetivo: projetar uma janela de canário que cubra a carga real. Entradas: execuções semanais de relatórios nos dias 6–7 (Capítulo 1), pico da manhã das 06:00 às 09:00. Restrições: a mudança precisa terminar em dez dias. Etapas: proponha a(s) janela(s), os pontos de promoção e os critérios conferidos em cada um. Evidência esperada: cronograma. Rubrica: 3 = canário cobrindo pelo menos um pico da manhã e uma execução de relatórios antes da promoção, com os critérios avaliados em cada um, depois promoção escalonada dentro dos dez dias; registra a prontidão para rollback durante todo o tempo; 2 = cobre um; 1 = mantém a janela de uma hora; 0 = nada.
Síntese do capítulo
Implante em etapas. Faça as pré-verificações de aprovações, operação, backups, rollback e da origem do pacote. Use um canário num host contra um controle, com critérios de promoção fixados de antemão; faça o rollback a qualquer falha e promova um host por vez em caso de sucesso. Valide as propriedades funcionais, de segurança e operacionais depois de cada host, e declare com honestidade o que a janela de validação não conseguiu mostrar.
Continue estudando — capítulo 27 de 30
← Capítulo 26 · Índice de capítulos do curso · Capítulo 28 →
Siga para a próxima lição escrita.