Capítulo 25 — Ateliê de projeto em equipe
Mapa da aula
Aula 25 publicada. Mapa, exemplo, EX073.
flowchart TD
N0["25.1 A equipe e os seus papéis"]
N1["25.2 Itens de trabalho com critérios de aceitação"]
N2["25.3 A revisão como controle"]
N3["25.4 Ritmo"]
N4["25.5 Revisões sem culpados"]
N5["25.7 Atividade prática: backlog do projeto"]
N6["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX073"]
Desenho lógico
flowchart LR
N0["25.1 A equipe e os seus papéis"]
N1["25.2 Itens de trabalho com critérios de aceitação"]
N2["25.3 A revisão como controle"]
N3["25.4 Ritmo"]
N4["25.5 Revisões sem culpados"]
N5["25.7 Atividade prática: backlog do projeto"]
N6["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX073"]
[25.1 A equipe e os seus papéis]
|
v
[25.2 Itens de trabalho com critérios de aceitação]
|
v
[25.3 A revisão como controle]
|
v
[25.4 Ritmo]
|
v
[25.5 Revisões sem culpados]
|
v
[25.7 Atividade prática: backlog do projeto]
|
v
[Síntese do capítulo]
|
v
[Exemplo resolvido] --> [Exercício EX073]
Objetivos de aprendizagem e conexão
Depois deste capítulo, você deve ser capaz de:
- trabalhar como parte de uma pequena equipe de entrega que constrói e opera um serviço compartilhado;
- dividir o projeto de integração do LANTERN em itens de trabalho com critérios de aceitação e evidências;
- usar a revisão — de código, configuração e documentos — como um controle de segurança;
- conduzir revisões curtas e sem culpados do que deu certo e do que deu errado, e transformá-las em mudanças.
Do Capítulo 26 em diante, o livro passa à entrega, à implantação e ao trabalho de conclusão. Os serviços reais são construídos por equipes, e muitas falhas de segurança são falhas de equipe: uma premissa que ninguém conferiu porque cada um achou que outro tinha conferido, uma mudança incorporada sem revisão porque o revisor estava ocupado. Este capítulo é um ateliê: ele dá uma estrutura para o trabalho em equipe de que o trabalho de conclusão precisa.
25.1 A equipe e os seus papéis
Uma equipe de entrega do LANTERN na FSTS tem quatro ou cinco pessoas: um dono do serviço (prioriza, fala pelos clientes), dois ou três tecnólogos (constroem e operam), um revisor de segurança (pode ser um dos tecnólogos, em rodízio) e um representante do cliente da operação de Água, que participa das revisões e aceita o trabalho que afeta o processo. Os papéis se revezam onde possível, para que o conhecimento seja compartilhado; nenhuma pessoa deve ser a única que entende o relay ou detém as suas chaves (a independência do Capítulo 8).
25.2 Itens de trabalho com critérios de aceitação
Todo item de trabalho declara o que significa "pronto" na forma de critérios de aceitação que produzem evidências. "Acrescentar alertas de silêncio de estação" é um desejo. "A Regra C alerta em até 20 minutos depois que o heartbeat de uma estação para, verificado por três silêncios de teste injetados em duas estações; primeira ação escrita e acordada com a sala de controle da Água; cartão de controle atualizado" é um item de trabalho. As evidências passam a fazer parte do registro do trabalho de conclusão.
A fusão do NTP neste capítulo mostra o custo de um critério fraco: "atualizar os servidores NTP" foi cumprido enquanto todos os relays perdiam a sua segunda fonte de tempo. O critério reescrito, "deslocamento < 1 s em todos os relays por 24 h", teria falhado no primeiro dia.
25.3 A revisão como controle
A revisão por pares de código, de arquivos de estado desejado, de mudanças de firewall e de runbooks pega erros, espalha o conhecimento e torna mais difícil que uma única conta comprometida ou descuidada mude o serviço sozinha. Torne a revisão obrigatória para tudo o que muda o serviço (branches protegidos, Capítulo 22), específica (o revisor confere contra os critérios de aceitação e as propriedades de projeto do Capítulo 8, e não apenas o estilo) e registrada. Faça rodízio dos revisores, para que a revisão não vire um carimbo de um aprovador habitual.
A fusão do NTP foi revisada, mas quanto à sintaxe; o revisor nunca conferiu se o novo servidor existia.
25.4 Ritmo
Um ritmo curto e regular combina com equipes operacionais: uma conversa semanal de planejamento (o que será feito, por quem, com que evidência), uma breve verificação diária (o que está bloqueado) e uma revisão ao fim de cada ciclo (o que foi entregue, mostrado com as suas evidências ao representante do cliente). O trabalho operacional — incidentes, falhas — interrompe o trabalho de projeto; planeje para ele, em vez de fingir que não vai acontecer.
O silêncio da PS-09 e a falha do disco do host de salto são as interrupções para as quais planejar.
Em Fallowmere, foi na verificação diária que o silêncio da PS-09 foi levantado, na manhã seguinte ao disparo da Regra C.
25.5 Revisões sem culpados
Quando algo dá errado — uma mudança que falhou, um alerta perdido, um quase acidente —, faça uma curta revisão sem culpados: o que aconteceu, o que as pessoas sabiam em cada momento, por que as suas ações faziam sentido para elas naquele momento, que condições permitiram o problema e o que vai mudar. O material de SRE do Google descreve o valor dos postmortems sem culpados para aprender com os incidentes sem desencorajar o relato honesto (livro de SRE do Google, cultura de postmortem); o trabalho de Reason sobre o erro humano distingue culpar indivíduos de corrigir as condições do sistema que tornam os erros prováveis (Reason, 2000). O produto são mudanças, cada uma com um responsável — e não uma pessoa a culpar.
25.6 Exemplo resolvido: uma fusão que não deveria ter acontecido (sintético)
Durante o projeto, um tecnólogo incorporou uma mudança de estado desejado que removia 10.30.0.2 dos servidores NTP dos relays, com a intenção de substituí-lo por um novo servidor que ainda não tinha sido construído. A automação a aplicou; os relays ficaram com uma fonte de tempo; quando essa fonte reiniciou para manutenção, dois dias depois, os relays derivaram, e as mensagens das estações começaram a falhar na janela de 120 segundos. A revisão sem culpados descobriu: a mudança foi revisada, mas o revisor conferiu a sintaxe, e não se o novo servidor existia; os critérios de aceitação diziam apenas "atualizar os servidores NTP"; o monitoramento de deriva conferia se as configurações correspondiam ao estado desejado, e correspondiam; e não havia alerta para o deslocamento do relógio. Mudanças: a lista de verificação da revisão inclui "todo sistema referenciado existe e responde?"; os critérios de aceitação para mudanças de hora incluem "deslocamento < 1 s em todos os relays por 24 h"; novo alerta para deslocamento do relógio do relay > 2 s. Ninguém foi culpado; três condições foram corrigidas.
25.7 Atividade prática: backlog do projeto
Escreva o backlog para o trabalho de conclusão (Capítulo 29): pelo menos dez itens de trabalho cobrindo o relay, a validação, a autenticação, o historiador, os logs, as regras de monitoramento, o acesso, o backup e a restauração, a automação, os runbooks e as evidências. Cada um precisa de critérios de aceitação que produzam evidências e de um papel responsável.
Um item completo como modelo: "Alerta de deslocamento do relógio do relay: alertar quando o deslocamento de qualquer relay exceder 2 s; aceitação, um deslocamento injetado num relay de teste gera o alerta em um ciclo de avaliação e a primeira ação está escrita; responsável, monitoramento da FSTS." Ele vem direto da revisão do NTP. Inclua pelo menos um item que exista apenas para fechar uma lacuna encontrada antes, como a mediana de detecção de 1.440 minutos da FIM.
25.8 Erros comuns e limites
- Itens de trabalho sem critérios de aceitação.
- Revisão que confere o estilo, e não a substância; ou um único revisor habitual.
- Um único membro da equipe como a única pessoa que entende um componente.
- Planos que ignoram as interrupções operacionais.
- Revisões de falhas que terminam em "ter mais cuidado".
A revisão do NTP neste capítulo terminou com três condições mudadas, e não com "ter mais cuidado".
A fusão do NTP mostra os dois primeiros: um critério de aceitação vago e uma revisão só da sintaxe. Uma única pessoa entender o armazenamento de chaves é o terceiro, que a passagem do Capítulo 26 expôs quando a equipe que recebia não conseguiu encontrá-lo.
Exercícios — capítulo 25
EX073 — Critérios de aceitação. Objetivo: escrever critérios que produzam evidências. Entradas: itens de trabalho: (a) "proteger o SSH nos relays"; (b) "backups para o historiador"; (c) "processo de acesso de fornecedores". Restrições: cada critério precisa ser verificável por outra pessoa. Etapas: reescreva cada um com pelo menos três critérios. Evidência esperada: lista. Rubrica: 3 = por exemplo, (a) autenticação por senha desligada e listener na interface de gerenciamento em todos os relays (saída da verificação de deriva), conexão a partir da zona corporativa recusada (registro de teste), MFA no host de salto; (b) backup noturno com uma cópia imutável, teste de restauração dentro do RTO registrado; (c) habilitação limitada no tempo testada de ponta a ponta, expiração verificada, ciência da Kell registrada; 2 = critérios parcialmente verificáveis; 1 = desejos reafirmados; 0 = nada.
EX074 — Lista de verificação da revisão. Objetivo: tornar a revisão substantiva. Entradas: o caso do Capítulo 25 ("Exemplo resolvido: uma fusão que não deveria ter acontecido") e as propriedades de projeto do Capítulo 8. Restrições: oito itens. Etapas: escreva uma lista de verificação para revisar uma mudança de estado desejado. Evidência esperada: lista de verificação. Rubrica: 3 = inclui a existência e a alcançabilidade dos sistemas referenciados, a direção da confiança preservada, nenhum novo listener em todas as interfaces, segredos fora da mudança, rollback definido, critérios de aceitação e verificação, clientes afetados informados, implantação escalonada; 2 = seis; 1 = itens só de estilo; 0 = nada.
EX075 — Revisão sem culpados. Objetivo: conduzir uma revisão que produza mudanças. Entradas: incidente: um tecnólogo de plantão silenciou a Regra B por 24 horas durante uma noite ruidosa e esqueceu de reativá-la; um fluxo não declarado real ficou sem alerta por três dias. Restrições: sem culpados; condições, e não pessoas. Etapas: escreva a revisão: linha do tempo, o que fazia sentido no momento, condições, mudanças com responsáveis. Evidência esperada: uma página. Rubrica: 3 = reconhece o ruído por evento da Regra B (Capítulo 19) como uma causa, a falta de expiração automática dos silenciamentos e a falta de visibilidade das regras silenciadas; mudanças como alertas por episódio, silenciamentos que expiram e aparecem no painel, item na lista de verificação de passagem de turno; 2 = mudanças parciais; 1 = culpa o tecnólogo; 0 = nada.
Síntese do capítulo
Os serviços são construídos por equipes. Dê aos papéis responsabilidades claras e faça o rodízio deles, para que o conhecimento e o controle não se concentrem numa só pessoa. Escreva itens de trabalho com critérios de aceitação que produzam evidências. Torne a revisão obrigatória, específica e registrada, para que ela funcione como um controle de segurança. Planeje para as interrupções operacionais e aprenda com as falhas por meio de revisões sem culpados, que mudam condições em vez de culpar pessoas.
Continue estudando — capítulo 25 de 30
← Capítulo 24 · Índice de capítulos do curso · Capítulo 26 →
Siga para a próxima lição escrita.