Capítulo 13 — Fatores humanos e política cibernética: solução de problemas

Mapa da aula

Aula 13 publicada. Mapa, exemplo, EX049.

flowchart TD
  N0["13.1 O problema"]
  N1["13.2 Separação das causas"]
  N2["13.3 Correções e prevenção"]
  N3["Síntese"]
  N0 --> N1 --> N2 --> N3
  N3 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX049"]

Desenho lógico

flowchart LR
  N0["13.1 O problema"]
  N1["13.2 Separação das causas"]
  N2["13.3 Correções e prevenção"]
  N3["Síntese"]
  N0 --> N1 --> N2 --> N3 --> Q["EX049"]

[13.1 O problema]
    |
    v
[13.2 Separação das causas]
    |
    v
[13.3 Correções e prevenção]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX049]

Objetivos de aprendizagem

Você vai (1) diagnosticar problemas no serviço de reporte; (2) separar causas técnicas de causas humanas; (3) corrigir as causas e evitar a recorrência.

13.1 O problema

Dois meses depois do lançamento, os reportes dos terminais do centro South param. Priya investiga. O formulário do terminal ainda existe, mas os envios falham em silêncio porque uma mudança de rede bloqueou o servidor do formulário. Os trabalhadores que tentaram reportar não viram nenhum erro e supuseram que tinha funcionado, de modo que ninguém levantou o problema. Enquanto isso, o líder de TI tinha notado a queda, mas supôs que o South simplesmente recebia menos mensagens suspeitas. Priya confere os logs do filtro de e-mail e confirma que o South recebeu um número normal de mensagens maliciosas no período.

13.2 Separação das causas

Priya separa as causas. A causa técnica foi a mudança de rede, feita sem testar os serviços dependentes. A causa de design foi o formulário não mostrar confirmação, o que deixou as falhas invisíveis para os usuários. A causa humana foi interpretar a queda nos reportes como boa notícia sem conferir. Cada causa precisa de sua própria correção. Tratar só a causa técnica deixaria o serviço vulnerável à próxima falha silenciosa, qualquer que fosse a origem, e perderia a lição sobre a interpretação dos dados.

13.3 Correções e prevenção

Priya e o líder de TI corrigem as três causas. A mudança de rede é corrigida e acrescentada a um checklist de serviços a testar depois de mudanças. O formulário agora mostra um número de confirmação quando o reporte é recebido e uma mensagem de erro se ele falha. Uma verificação semanal compara os reportes com as mensagens maliciosas entregues em cada centro e sinaliza qualquer centro em que os reportes caiam muito. Ela registra o incidente no log de solução de problemas. A verificação semanal teria detectado o problema do South em poucos dias.

Exemplo resolvido

Priya atribui uma queda nos reportes do centro South a uma mudança de rede, à falta de confirmação e a uma métrica mal interpretada, e corrige as três.

Caso sintético. O incidente é sintético.

Erros e limites

As verificações semanais exigem atenção. Os checklists podem ser pulados.

Exercícios

• EX049 — Falha silenciosa. Por que os trabalhadores não perceberam a falha?

  Mostrar critérios de avaliação

  Rubrica: 3 = o formulário não mostrava erro nem confirmação;; 2 = silenciosa;; 1 = vago;; 0 = nenhuma.

• EX050 — Queda mal interpretada. Como o líder de TI interpretou mal a queda?

  Mostrar critérios de avaliação

  Rubrica: 3 = como menos mensagens suspeitas;; 2 = boa notícia;; 1 = vago;; 0 = nenhuma.

• EX051 — Correção do formulário. O que o formulário mostra agora?

  Mostrar critérios de avaliação

  Rubrica: 3 = um número de confirmação ou um erro;; 2 = retorno;; 1 = vago;; 0 = nenhuma.

• EX052 — Verificação semanal. O que a verificação semanal compara?

  Mostrar critérios de avaliação

  Rubrica: 3 = os reportes com as mensagens maliciosas entregues por centro;; 2 = razão;; 1 = vago;; 0 = nenhuma.

Síntese

A resolução de problemas encontra causas técnicas, de desenho e humanas, e a prevenção exige corrigir as três.