Capítulo 27 — Implantação e validação

Mapa da aula

Aula 27 publicada. Mapa, exemplo, EX079.

flowchart TD
  N0["27.1 Planejar a implantação"]
  N1["27.2 Validar"]
  N2["27.3 Rollback"]
  N3["Síntese"]
  N0 --> N1 --> N2 --> N3
  N3 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX079"]

Desenho lógico

flowchart LR
  N0["27.1 Planejar a implantação"]
  N1["27.2 Validar"]
  N2["27.3 Rollback"]
  N3["Síntese"]
  N0 --> N1 --> N2 --> N3 --> Q["EX079"]

[27.1 Planejar a implantação]
    |
    v
[27.2 Validar]
    |
    v
[27.3 Rollback]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX079]

Objetivos de aprendizagem

Você vai (1) implantar com segurança uma mudança de configuração nos centros de distribuição; (2) validá-la contra os requisitos; (3) fazer rollback se necessário.

27.1 Planejar a implantação

A Brightwater decide impor o login individual por crachá em todos os coletores dos quatro centros de distribuição, substituindo os PINs compartilhados das equipes, conforme projetado no capítulo 7. Tomás planeja uma implantação escalonada: primeiro um centro, depois dois, depois o último. Cada etapa tem critérios de entrada, como crachás emitidos para toda a equipe, e critérios de saída, como menos de cinco chamados de ajuda com login por turno. Ele agenda as mudanças para o início do turno mais tranquilo. A implantação escalonada limita o impacto dos erros a um local de cada vez.

27.2 Validar

Em cada centro de distribuição, Tomás confere os requisitos: todo coletor exige crachá e PIN, as leituras registram o motorista individual, os PINs compartilhados deixam de funcionar e as contas bloqueadas podem ser redefinidas pelos supervisores. Ele testa cada requisito com um crachá de teste e registra os resultados. No segundo centro, um modelo de coletor ainda aceita o antigo PIN compartilhado por causa de uma versão de firmware mais antiga. O firmware é atualizado e o teste é repetido. A validação pega lacunas que a tela de configuração, sozinha, nunca mostraria.

27.3 Rollback

Tomás prepara um plano de rollback: se mais de dez por cento dos motoristas não conseguirem fazer login no início do turno, o centro volta aos PINs compartilhados naquele dia enquanto os crachás são corrigidos. O plano nunca é usado, mas tê-lo permite que os supervisores concordem com a mudança com confiança. Depois dos quatro centros, os chamados de ajuda com login se estabilizam em dois por turno. Ele registra os resultados da implantação, o problema de firmware e as lições aprendidas. Um plano de rollback claro é sinal de uma implantação profissional, e não de dúvida sobre a mudança.

Exemplo resolvido

Tomás implanta o login por crachá em três etapas, valida quatro requisitos por centro de distribuição, pega uma lacuna de firmware e prepara um plano de rollback que não chega a ser usado.

Caso sintético. Os centros de distribuição e os números são sintéticos.

Erros e limites

Implantações escalonadas prolongam estados mistos. O rollback pode reintroduzir temporariamente controles fracos.

Exercícios

• EX079 — Critério de saída. Qual era o critério de saída de cada etapa?

  Mostrar critérios de avaliação

  Rubrica: 3 = menos de cinco chamados de ajuda com login por turno;; 2 = chamados de ajuda;; 1 = vago;; 0 = nenhuma.

• EX080 — Lacuna de firmware. O que a validação pegou no segundo centro?

  Mostrar critérios de avaliação

  Rubrica: 3 = um modelo com firmware antigo ainda aceitava o PIN compartilhado;; 2 = firmware;; 1 = vago;; 0 = nenhuma.

• EX081 — Gatilho do rollback. O que dispararia o rollback?

  Mostrar critérios de avaliação

  Rubrica: 3 = mais de dez por cento dos motoristas sem conseguir fazer login no início do turno;; 2 = dez por cento;; 1 = vago;; 0 = nenhuma.

Síntese

Implantação escalonada, validação dos requisitos e um plano de reversão pronto tornam as mudanças seguras.