Capítulo 26 — Privacidade e proteção de dados: transição para a operação
Mapa da aula
Aula 26 publicada. Mapa, exemplo, EX076.
flowchart TD
N0["26.1 Runbooks"]
N1["26.2 Responsáveis"]
N2["26.3 Treinamento"]
N3["26.4 Confirmação"]
N0 --> N1 --> N2 --> N3
N3 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX076"]
Desenho lógico
flowchart LR
N0["26.1 Runbooks"]
N1["26.2 Responsáveis"]
N2["26.3 Treinamento"]
N3["26.4 Confirmação"]
N0 --> N1 --> N2 --> N3 --> Q["EX076"]
[26.1 Runbooks]
|
v
[26.2 Responsáveis]
|
v
[26.3 Treinamento]
|
v
[26.4 Confirmação]
|
v
[Exemplo resolvido] --> [Exercício EX076]
Objetivos de aprendizagem
Você vai (1) entregar os controles à equipe de operações; (2) escrever runbooks; (3) confirmar os responsáveis.
26.1 Runbooks
Aisha escreve runbooks para as verificações do CFTV, as revisões de SDKs, os pedidos de acesso e as exclusões. Cada runbook descreve a finalidade da tarefa, quando executá-la, os passos, os resultados esperados, o que fazer se os resultados forem inesperados e quem procurar. Ela os escreve para a equipe de operações, e não para especialistas, então evita jargão e usa capturas de tela do ambiente de teste sintético, e não dos sistemas reais. O runbook do CFTV, por exemplo, traz o caminho no menu do gravador, a idade esperada do vídeo mais antigo e o telefone a ligar quando ela passar de trinta e cinco dias.
26.2 Responsáveis
Cada runbook nomeia um responsável em operações: o do CFTV pertence ao gerente de operações; a revisão de SDKs, ao líder do aplicativo; os pedidos de acesso, à líder do atendimento; a exclusão de contas, ao gerente de serviços de TI. Cada responsável tem um substituto nomeado para as férias. Sempre que possível, a responsabilidade é escrita na descrição do cargo, para sobreviver às mudanças de função. Sem responsáveis nomeados, a verificação da exclusão do CFTV dependeria de quem se lembrasse dela, que foi exatamente como a falha do firmware passou despercebida por seis semanas.
26.3 Treinamento
Aisha treina os responsáveis e os observa executando cada tarefa. Enquanto o responsável executa o runbook, ela anota onde ele hesita ou lê um passo errado. A líder do atendimento tem dificuldade com a busca das transcrições do chat no fornecedor, então Aisha acrescenta passos mais claros e o nome de um contato no fornecedor. No runbook de exclusão, o gerente de serviços de TI entende mal qual confirmação do fornecedor esperar, e o passo passa a mostrar um exemplo da mensagem de confirmação. A observação revela lacunas que a simples revisão do documento deixaria passar.
26.4 Confirmação
Os responsáveis assinam a aceitação, o que significa que concordam que o runbook está correto e que conseguem executá-lo. O encarregado guarda as aceitações assinadas. Aisha marca um acompanhamento três meses depois para conferir se as tarefas estão rodando e deixa seus contatos para dúvidas. A transição só termina quando as tarefas rodam sem a ajuda dela. Três meses depois, as quatro tarefas rodaram no prazo sem a participação de Aisha, e seu papel se encerra. O Sr. Reilly observa que a transição para a operação é o que mantém os controles vivos depois do fim de um projeto.
Exemplo resolvido
Aisha escreve quatro runbooks, nomeia os responsáveis, treina-os e obtém sua aceitação.
Caso sintético. Os runbooks são sintéticos.
Erros e limites
Runbooks envelhecem; revise-os todo ano.
Exercícios
- EX076 — Runbooks. Cite dois runbooks. Rubrica: 3 = verificações do CFTV, revisões de SDKs, pedidos de acesso, exclusões;; 2 = dois;; 1 = um;; 0 = nenhuma.
- EX077 — Treinamento. Como Aisha confirmou que os responsáveis conseguiam executar as tarefas? Rubrica: 3 = observou-os executando cada tarefa;; 2 = parcialmente correta;; 1 = vago;; 0 = nenhuma.
- EX078 — Finalidade. Por que fazer a transição? Rubrica: 3 = mantém os controles vivos depois do projeto;; 2 = parcialmente correta;; 1 = vago;; 0 = nenhuma.
Continue estudando — aula 26 (capítulo 26 de 30)
← Capítulo 25 · Índice das aulas · Capítulo 27 →
Continue para a próxima aula já escrita.