Capítulo 1 — Sistemas computacionais | Tecnólogo Segurança de infraestrutura crítica e setores

Ensino gratuito e aberto para quem deseja proteger pessoas e tecnologias. Não é preciso criar uma conta para estudar ou consultar as respostas.

Mapa da aula

Aula 01 publicada. Mapa, exemplo, EX001.

flowchart TD
  N0["1.1 Um host como um conjunto de recursos finitos"]
  N1["1.3 A folga e por que o suficiente não basta"]
  N2["1.4 Prever o esgotamento"]
  N3["1.5 Modos de falha silenciosos"]
  N4["1.7 Atividade prática: folga de capacidade"]
  N5["Síntese do capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX001"]

Desenho lógico

flowchart LR
  N0["1.1 Um host como um conjunto de recursos finitos"]
  N1["1.3 A folga e por que o suficiente não basta"]
  N2["1.4 Prever o esgotamento"]
  N3["1.5 Modos de falha silenciosos"]
  N4["1.7 Atividade prática: folga de capacidade"]
  N5["Síntese do capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX001"]

[1.1 Um host como um conjunto de recursos finitos]
    |
    v
[1.3 A folga e por que o suficiente não basta]
    |
    v
[1.4 Prever o esgotamento]
    |
    v
[1.5 Modos de falha silenciosos]
    |
    v
[1.7 Atividade prática: folga de capacidade]
    |
    v
[Síntese do capítulo]
    |
    v
[Exemplo resolvido] --> [Exercício EX001]

Objetivos de aprendizagem e conexão

Depois deste capítulo, você deve ser capaz de:

descrever um host em termos dos quatro recursos que um operador de fato vê se esgotarem — processamento, memória, armazenamento e E/S — e do recurso que as pessoas esquecem, o tempo;
prever quando um recurso vai se esgotar a partir de uma série curta de medições, e dizer quanto confiar na previsão;
explicar por que um host que sustenta uma função essencial precisa de folga, e não apenas de "o suficiente";
reconhecer as formas comuns pelas quais um host falha em silêncio, e escrever as primeiras verificações que as notariam.

O curso de entrada ensinou como um computador funciona. Este capítulo faz uma pergunta mais estreita, que atravessa o livro inteiro: o que precisa continuar verdadeiro sobre este computador para que o serviço em cima dele continue funcionando, e como você saberia se deixasse de ser verdadeiro? O host de retransmissão do LANTERN, RLY-01, é a primeira máquina que você vai conhecer; no Capítulo 29, ele será um de três.

1.1 Um host como um conjunto de recursos finitos

Todo serviço que você opera fica sobre um host com recursos finitos. O processamento (tempo de CPU) limita quanto trabalho pode ser feito por segundo. A memória limita quanto pode ser mantido de uma vez; quando ela acaba, o sistema operacional ou faz swap para o disco (e tudo fica lento) ou encerra processos. O armazenamento limita o que pode ser guardado; quando um disco enche, as gravações falham, e muitos programas falham mal — um banco de dados pode parar de aceitar gravações, um daemon de logs pode descartar mensagens em silêncio, um relay pode travar. A E/S (vazão de disco e de rede) limita a velocidade com que os dados entram e saem.

O recurso que as pessoas esquecem é o tempo: o relógio do host. Um relógio errado não para um serviço, mas faz os seus registros discordarem dos de todos os outros, quebra a validação de certificados e as verificações de janelas de tempo, e torna as investigações enganosas. Os Capítulos 17 e 20 voltam ao tempo em detalhe.

Para um serviço crítico, a pergunta útil sobre cada recurso não é "quanto está sendo usado?", mas "quanto tempo até este recurso parar o serviço, e com quanta antecedência seremos avisados?"

1.2 Utilização, saturação e erros

Uma forma prática de inspecionar qualquer recurso é perguntar três coisas sobre ele: a sua utilização (quão ocupado está, como fração da capacidade), a sua saturação (quanto trabalho está esperando porque ele está ocupado — uma fila de execução, uma fila de disco, pacotes descartados) e os seus erros (operações que falharam). Uma CPU a 60 % de utilização sem fila está bem; um disco a 40 % de utilização com uma fila longa não está. A utilização, sozinha, esconde o problema que os usuários sentem, que é a espera.

Disso decorrem dois hábitos. Primeiro, meça num percentil, não numa média: a CPU no percentil 95 ao longo de um dia informa sobre os momentos de pico que importam; a média diária os esconde. Segundo, meça por um período longo o bastante para ver o ritmo do serviço. Os relays de telemetria ficam mais ocupados quando os relatórios rodam e quando as estações enviam dados em lote depois de uma queda da rede; os sistemas hospitalares têm pico nas trocas de turno; os sistemas de transporte, na hora do rush.

1.3 A folga e por que "o suficiente" não basta

A folga é a capacidade sobressalente entre a carga normal de pico e o ponto em que o serviço se degrada. Um serviço essencial precisa de folga por três motivos: a demanda sobe de forma inesperada (uma tempestade, um evento com múltiplas vítimas, uma interrupção em outro lugar que envia tráfego para você); a própria recuperação consome recursos (as estações que estavam offline enviam o seu acúmulo quando voltam; uma restauração grava intensamente em disco); e as ferramentas de segurança consomem recursos (uma varredura, uma verificação de integridade ou uma atualização do antivírus pode dobrar o uso de CPU por minutos). Um host dimensionado para "apenas o suficiente" num dia normal está dimensionado para falhar no dia em que mais importa.

1.4 Prever o esgotamento

Para recursos que crescem de forma constante — o disco preenchido por logs e dados é o caso clássico —, uma reta ajustada às medições diárias recentes dá uma previsão utilizável: o crescimento por dia e os dias até um limiar de alarme e até encher. É uma previsão, não uma promessa. Ela pressupõe que o crescimento continue no ritmo recente. Estará errada se a retenção for alterada, se um processo ruidoso começar a registrar logs em nível de depuração ou se uma interrupção for seguida por uma rajada de acúmulo. Use-a para agendar a ação bem antes do limiar, e execute-a de novo depois de qualquer mudança.

Um cálculo complementar útil é o tamanho em regime estacionário: se os dados são mantidos por R dias e chegam a g GB por dia, o volume retido se estabiliza em cerca de g × R. Se esse número exceder o disco, nenhuma "limpeza" vai salvar o host; ou a retenção, ou o volume, ou a capacidade precisa mudar.

1.5 Modos de falha silenciosos

Hosts em serviços de longa duração tendem a falhar de um pequeno número de formas silenciosas: um disco ou partição enche; uma tarefa de rotação de logs para e um arquivo cresce sem limite; um certificado expira; o relógio deriva depois que a sua fonte de tempo fica inalcançável; um processo vaza memória e é reiniciado pelo gerenciador do sistema a cada poucos dias, perdendo os dados em trânsito; uma tarefa agendada (backup, relatório) falha e ninguém lê o seu e-mail. Cada um deles pode ser notado com uma verificação que não custa quase nada — se alguém escrever a verificação e alguém ler o seu resultado. O Capítulo 19 transforma essas verificações em monitoramento.

1.6 Exemplo resolvido: o disco do RLY-01 (sintético)

E. Strand pergunta se o RLY-01, que armazena em buffer a telemetria das estações e mantém os seus próprios logs por 30 dias, precisa de um disco maior antes do inverno. Você coleta 14 dias de uso de disco (disco de 200 GB) e a CPU diária no percentil 95. O disco cresce cerca de 1,9 GB por dia e está em 120,9 GB. O alarme de operações dispara em 85 % (170 GB). Neste ritmo, o alarme dispara em cerca de 26 dias e o disco enche em cerca de 41 dias. Com retenção de 30 dias, o volume de logs em regime estacionário é de cerca de 57 GB — mas o disco já passou bem disso, o que indica que o crescimento não vem apenas de logs dentro da retenção. Algo está mantendo dados por mais de 30 dias. Essa é uma pergunta de configuração, não de capacidade, e deve ser respondida antes de comprar um disco.

A série de CPU mostra um padrão semanal: os dias 6–7 de cada semana rodam a cerca de 62 %, contra cerca de 42 % nos outros dias. Você pergunta à operação de Água e descobre que os relatórios semanais de conformidade rodam nesses dias. Essa é uma carga normal, mas é a carga para a qual você precisa dimensionar.

1.7 Atividade prática: folga de capacidade

Execute o Laboratório 1. Ele ajusta uma reta à série do disco, informa os dias até o alarme e até encher, o volume de logs em regime estacionário com retenção de 30 dias, e compara a CPU nos dias de relatório com a dos outros dias.

Laboratório 1 (salve como lab01.py, execute com python3 lab01.py):

# Lab 1 - capacity headroom for the relay host (offline, standard library only)
# Synthetic: Fallowmere relay host RLY-01. Daily samples over 14 days.
disk_total_gb = 200.0
disk_used_gb = [96.0, 97.9, 99.7, 101.8, 103.6, 105.5, 107.6, 109.4, 111.3, 113.2, 115.1, 117.0, 118.8, 120.9]
cpu_p95 = [41, 43, 40, 44, 42, 61, 63, 42, 41, 44, 43, 40, 62, 64]  # percent, 95th percentile per day
alarm_at = 0.85  # operations alarm when disk reaches 85 % full

n = len(disk_used_gb)
xs = list(range(n))
mx, my = sum(xs) / n, sum(disk_used_gb) / n
slope = sum((x - mx) * (y - my) for x, y in zip(xs, disk_used_gb)) / sum((x - mx) ** 2 for x in xs)
print(f"growth: {slope:.2f} GB/day")
for limit, label in ((alarm_at * disk_total_gb, "85% alarm"), (disk_total_gb, "full")):
    days = (limit - disk_used_gb[-1]) / slope
    print(f"days until {label}: {days:.1f}")
# retention: logs kept 30 days; growth comes from logs (synthetic assumption)
print(f"steady-state log volume at 30-day retention: {slope*30:.1f} GB")
weekly = [cpu_p95[i] for i in range(n) if i % 7 in (5, 6)]
weekday = [cpu_p95[i] for i in range(n) if i % 7 not in (5, 6)]
print(f"cpu p95 mean weekday {sum(weekday)/len(weekday):.1f}% vs days 6-7 of each week {sum(weekly)/len(weekly):.1f}%")

Saída esperada (Python 3.13.5):

growth: 1.91 GB/day
days until 85% alarm: 25.7
days until full: 41.4
steady-state log volume at 30-day retention: 57.3 GB
cpu p95 mean weekday 42.0% vs days 6-7 of each week 62.5%

Registre os quatro números na sua nota de trabalho sob observado, depois escreva uma frase inferida e um item em aberto. Um bom item em aberto nomeia uma pergunta e um responsável: "Por que o RLY-01 retém mais de 30 dias de dados? — E. Strand, até sexta-feira."

1.8 Erros comuns e limites

Relatar a CPU média e concluir que há folga, quando o pico — o momento que importa — está perto da saturação.
Tratar uma previsão linear como garantia; ela pressupõe que o futuro se pareça com as duas últimas semanas.
Resolver uma falha de retenção ou de logs comprando capacidade, o que esconde a falha até o novo disco encher.
Esquecer que a recuperação e as atividades de segurança consomem recursos.
Definir um alarme num limiar que deixa menos tempo de aviso do que o necessário para adquirir, aprovar e instalar mais capacidade.
Ignorar o relógio porque "é só o tempo".

Catorze amostras são uma base pequena para qualquer previsão. O valor do método está em transformar uma impressão ("o disco parece estar enchendo") num número com uma premissa explícita, que alguém pode conferir.

Exercícios — capítulo 1

EX001 — Prazo de reposição versus tempo de aviso. Objetivo: definir um limiar de alarme a partir do prazo operacional de reposição. Entradas: a saída do Laboratório 1; a aquisição e a instalação aprovada de um disco novo levam 21 dias úteis (cerca de 30 dias corridos). Restrições: mantenha a mesma taxa de crescimento. Etapas: (1) calcule o nível de preenchimento em que você precisa abrir a solicitação para que o disco seja instalado antes de encher, com 7 dias de margem; (2) expresse-o como porcentagem do disco; (3) diga se o alarme de 85 % é adequado. Evidência esperada: cálculo e recomendação em duas frases. Rubrica: 3 = limiar correto (37 dias × 1,91 GB ≈ 71 GB de espaço livre necessários, ou seja, abrir a solicitação em cerca de 129 GB ou 65 %, que o RLY-01 atinge em cerca de quatro dias) e um julgamento claro de que 85 % é tarde demais para esse prazo; 2 = método certo, deslize aritmético; 1 = limiar escolhido sem o prazo de reposição; 0 = nada.

EX002 — Explique o crescimento. Objetivo: separar um problema de capacidade de um problema de configuração. Entradas: o exemplo resolvido. Restrições: não toque em nenhum sistema real; raciocine a partir dos números. Etapas: (1) calcule quantos dias de dados, a 1,91 GB/dia, os 120,9 GB atuais representam; (2) dê duas causas de configuração plausíveis; (3) descreva a verificação que distinguiria uma da outra. Evidência esperada: nota curta com os rótulos observado / inferido / em aberto. Rubrica: 3 = cerca de 63 dias calculados, duas causas específicas (por exemplo, rotação que não apaga, buffer para um upstream offline que não está sendo esvaziado, um segundo fluxo de logs fora da política de retenção) e uma verificação para cada uma; 2 = causas genéricas; 1 = recomenda apenas um disco maior; 0 = nada.

EX003 — Lista de verificação de falhas silenciosas. Objetivo: transformar modos de falha silenciosos em verificações. Entradas: Capítulo 1 ("Modos de falha silenciosos"). Restrições: cinco verificações; cada uma deve nomear o que é medido, o limiar e quem lê o resultado. Etapas: escreva uma tabela com as colunas: modo de falha, medição, limiar, leitor, ação. Evidência esperada: tabela. Rubrica: 3 = cinco modos de falha distintos, limiares mensuráveis com tempo de aviso, um leitor nomeado e uma ação para cada um; 2 = uma coluna fraca; 1 = "monitorar o servidor" genérico; 0 = nada.

Síntese do capítulo

Um host é um conjunto de recursos finitos mais um relógio. Para um serviço essencial, a pergunta sobre cada recurso é quanto tempo falta até ele parar o serviço e com quanta antecedência você será avisado. Meça utilização, saturação e erros em percentis ao longo do ritmo natural do serviço; mantenha folga para os dias ruins, para a recuperação e para o trabalho de segurança; preveja o esgotamento com premissas explícitas; e escreva verificações baratas para as falhas silenciosas que de fato derrubam serviços. Quando os números contrariam as expectativas, como o disco do RLY-01, procure uma causa de configuração antes de comprar capacidade.