O ciclo do jogo

Toda noite é feita dos mesmos quatro movimentos repetidos até o amanhecer. Aprender o jogo é aprender a executá-los mais rápido, não aprender mais deles.

Observar

Os logs rolam e os medidores se movem. A maior parte do que você vê é normal: uma frota sob carga produz linhas de tráfego, tarefas cron começam e terminam, a latência oscila. A habilidade treinada aqui é notar a linha que não se encaixa — uma taxa de requisições que nenhum cliente produz, um conjunto residente que só cresce, uma temperatura que parou de baixar.

Diagnosticar

O sintoma raramente é a causa, e o jogo é construído em torno dessa distância. Uma CPU saturada pode ser uma inundação vinda de fora, um processo que saiu do controle localmente ou uma máquina com throttling porque está quente demais.

Os comandos de diagnóstico são gratuitos e instantâneos — não custa nada ter certeza. status dá a frota de relance, top nomeia processos, netstat mostra quem está se conectando, df mostra discos, db_stat mostra locks.

Agir

A correção é um comando. A sintaxe é um Unix gamificado: nomes de comandos reais, flags comuns aceitas, e os nomes ficam em inglês em todos os idiomas porque um terminal é em inglês. Se você digitar algo que não existe, recebe bash: xyz: command not found, e se o jogo conseguir adivinhar o que você quis dizer, ele avisa — did you mean: block_ip?

Confirmar

As métricas se recuperam, a máquina volta a OK e uma linha de resolução aparece no log. Essa confirmação importa: um incidente está resolvido quando o mundo diz que está, não quando você digitou algo plausível. Alguns incidentes aceitam mais de uma resolução, e uma correção parcial pode fechá-los a um custo pior.

O ciclo maior

Em volta desse ciclo de trinta a noventa segundos fica o próprio turno: os incidentes são injetados em um tempo que acelera conforme a noite avança, vários podem se sobrepor e a pressão se acumula. Veja incidentes de relance para entender como esse agendamento funciona.