A Prática
Como o trabalho é de fato feito.
Redes e segurança por dentro: triagem, escalonamento, evidências, passagem de bastão, escala de sobreaviso. Não é sobre como a tecnologia funciona, assunto de outras partes deste site, e sim sobre como o trabalho é feito por quem o faz.
Experimente
Siga o ciclo de vida →
64 artigos na ordem em que o trabalho acontece: antes da venda, quando quebra, o que rende, o que vem depois, a vida e o ofício.
Tenho um problema agora →
Digite o que está na sua frente; a busca olha só dentro deste acervo e lista os textos que tratam disso.
O lado humano →
As duas partes sobre a pessoa que faz o trabalho: A Vida e O Ofício, onde o ciclo de vida deixa de ser um procedimento.
Duas formas de ler isto
As partes abaixo estão em ordem, e a ordem é a vida de um sistema: antes de quebrar, quando quebra, quando não cede, depois que passa, a vida em volta e o ofício por baixo de tudo. Leia de cima a baixo e você terá percorrido o ciclo inteiro.
Ou chegue com uma pergunta só, leia um artigo e vá embora. Cada entrada mostra o que o artigo defende, e não o que ele cobre, porque quem procura o texto sobre escalonamento quer achar o argumento que responde à sua pergunta.
As posições a que este trabalho pertence
Cada artigo aqui descreve um trabalho que alguém é contratado para fazer. A seção Os Papéis cobre 43 dessas posições: pelo que cada uma responde, de quem recebe, a quem serve e como é medida.
A escada de carreira por trás deste trabalho está no livreto gratuito da Red Education, Understanding Cyber Security Career Paths, que descreve as funções, as tarefas e as habilidades de catorze papéis de segurança. Veja onde ele se cruza com este site.
De onde isto vem
Trinta anos são tempo suficiente para ter feito muita coisa, e nem de longe para ter feito tudo. O que está aqui é a parte que eu vivi.
Eu executei e eu planejei. Auditei ambientes de terceiros e supervisionei trabalhos que eu mesmo não fiz. Pus a mão no teclado e fui o nome na escala quando aquilo falhou de madrugada. Treinei equipes de operação: uma pessoa por vez diante de um console, e salas cheias de gente de uma só vez. Parte disso fiz para fabricantes, parte para integradores, e a maior parte para o cliente final, que precisava conviver com o resultado na segunda-feira.
Nada disso é teoria que eu li: é o que a minha carreira me ensinou.
I. Antes de quebrar
O trabalho que decide o quão ruins serão os próximos dois anos, feito enquanto nada está errado e ninguém está olhando.
Ler um projeto que não foi você quem fez
Herdar um sistema projetado por outra pessoa é uma das situações mais comuns deste trabalho, e o primeiro ato não é julgar o projeto: é recuperar as restrições a que ele respondia. Quase tudo que parece errado é uma decisão cuja razão já saiu do prédio, e as partes genuinamente erradas são indistinguíveis das que não são até você saber qual é qual.
Para que serve, de fato, o teste de aceitação
Teste de aceitação não é uma demonstração de que o sistema funciona. A função real dele é registrar o que ficou acordado como "funcionando", enquanto as duas partes ainda querem concordar — para que a discussão que chega dezoito meses depois tenha um documento em vez de duas memórias.
O runbook que ninguém consegue seguir, e por quê
Runbooks falham quando são escritos pela pessoa que menos precisa deles, no momento em que ela mais entende o sistema, para um leitor que ela imagina ser ela mesma. A correção não é mais detalhe — é escrever para um leitor específico em um estado específico, e então deixar esse leitor quebrar o documento antes de você precisar dele.
Passagem: o momento em que um projeto vira operação
A passagem é tratada como transferência de documentos e é, na verdade, transferência de julgamento — e julgamento é a única coisa que não se transfere numa reunião. O que dá para transferir é o raciocínio por trás das decisões, a lista do que ficou por fazer, e o nome de alguém que vai atender o telefone.
Linha de base: saber como é o normal antes de precisar
Uma linha de base não é monitoração nem documentação. É a resposta à única pergunta que importa nos primeiros dez minutos de um incidente — isso sempre foi assim? — e é o único artefato que só pode ser feito quando nada está errado.
O que uma linha de base não consegue dizer
Uma linha de base registra o que aconteceu durante o período em que foi tirada e promove, em silêncio, as condições daquele período ao status de normal. Ela responde se algo mudou, o que já vale muito — mas não consegue dizer se aquilo que registrou algum dia esteve certo, e a diferença entre essas duas perguntas é de onde saem as respostas erradas ditas com confiança.
Janelas de mudança, e a aritmética do rollback
Uma janela de mudança não é o tempo que a mudança leva. É o tempo da mudança mais o tempo para descobrir que deu errado mais o tempo para desfazer — e o terceiro número é o que ninguém mede, razão pela qual janelas estouram e rollbacks são abandonados pela metade.
Nomenclatura, endereçamento e o custo de errar cedo
Nomenclatura e endereçamento são decididos numa tarde por quem estiver livre, e sobrevivem a todas as outras decisões do parque — não porque sejam tecnicamente difíceis de mudar, mas porque todo o resto passa, em silêncio, a depender deles. A conta é paga anos depois, por outra pessoa, numa moeda que ninguém orçou.
Documentar uma rede que outra pessoa vai herdar
Documentação falha porque descreve o sistema, e o sistema já se descreve melhor do que você conseguiria. O que quem herda não consegue recuperar olhando é o raciocínio — as restrições, o que foi deliberadamente não feito, e o comportamento que parece errado e é esperado. Escreva a parte que o parque não consegue dizer sobre si mesmo.
Projetar um sistema que alguém vai interrogar às três da manhã
Todo projeto decide, sem que ninguém tenha essa intenção, o quanto o sistema será cognoscível quando se comportar mal. Ser cognoscível não é um recurso acrescentado depois — é resíduo de escolhas feitas por outros motivos, por pessoas que não estarão na sala quando a resposta for necessária.
As premissas que um projeto carrega e nunca declara
Todo projeto é um conjunto de apostas sobre o ambiente em que vai viver, e o artefato registra apenas as decisões. A aposta fica invisível, o que significa que nada avisa quando ela deixa de pagar — e um projeto sobrevive às próprias premissas por anos, continuando a parecer correto.
II. Quando quebra
A trajetória de um único incidente, do momento em que alguém percebe até o momento em que o serviço volta.
Abertura de chamado: o que um bom relato de problema contém
A maior parte do tempo perdido num incidente é perdida antes de alguém começar a trabalhar nele, no intervalo entre o que quem relatou disse e o que de fato está errado.
Triagem, e por que severidade é uma pergunta de negócio
Engenheiros classificam falhas pelo que está quebrado. O negócio classifica pelo que parou. Esses dois ordenamentos raramente coincidem, e a discussão sobre qual deles vence é a triagem inteira.
Reproduzir uma falha que não se reproduz
Não reproduz é uma afirmação sobre o seu ambiente, não sobre a falha. Ela reproduz muito bem para quem a reportou, o que significa que as condições diferem e você não achou a que importa.
Bissecção: dividir o espaço do problema ao meio
Verificar as coisas em ordem encontra a falha na metade da lista, em média. Cortar a lista ao meio a cada passo encontra no logaritmo da lista, e a diferença entre as duas é a diferença entre uma tarde e uma semana.
Camada a camada: percorrer a pilha sem pular
O modelo em camadas é uma ordem de busca, não uma descrição da realidade. Seu valor é ser compartilhado e ordenado, e a primeira pergunta em qualquer falha real não é qual camada, e sim qual pilha, porque encapsulamento significa que quase sempre há mais de uma.
A diferença entre sintoma e causa
Causa raiz não é descoberta, é escolhida. Toda cadeia causal continua indefinidamente nas duas direções, e o julgamento profissional está em onde parar, que deve ser o ponto onde você de fato tem alavancagem.
Conter antes de curar
Restaurar o serviço e entender a falha são trabalhos diferentes disputando o mesmo sistema, porque quase toda ação de contain destrói a evidência com a qual você teria diagnosticado. A sequência que resolve isso é capturar, conter, e então diagnosticar a partir do que foi capturado.
O contorno e a correção
Contornar uma falha ou corrigi-la é perguntado como questão técnica e quase nunca é uma. É uma questão sobre quem carrega o custo e por quanto tempo, e a resposta só se sustenta quando alguém decidiu, em vez de ter escorregado para ela.
Verificar sem confiar
Verificar é a disciplina de tentar provar que você está errado, e toda força que age sobre o momento seguinte a uma correção empurra para o outro lado. Quem fez a mudança é o pior verificador disponível, porque vai confirmar o modelo que a produziu.
Saber quando o problema não é seu
A pergunta útil durante um incidente não é se você consegue resolver, mas se você é o caminho mais rápido até a solução. São perguntas diferentes, e a primeira o bajula a ficar tempo demais.
III. Quando não cede
O que acontece quando o caminho normal falha: o escalonamento, o fabricante, a sala de crise e as decisões tomadas sem informação suficiente.
A premissa que você não consegue ver
Um problema que não cede raramente é um problema difícil. Em geral é um problema em que algo de que você tem certeza é falso, e certeza é invisível por dentro — por isso a saída é um procedimento para trazer crenças à superfície, e não mais esforço aplicado às mesmas.
Quando a evidência discorda de si mesma
Duas medições que não podem estar ambas certas não são um problema de dados a ser resolvido escolhendo uma. São uma localização: a falha está entre elas, e a contradição é a coisa mais precisa que você tem.
Quando o fabricante diz que não é bug
"Funciona como projetado" costuma ser verdade e quase nunca é uma resposta. O projeto é um conjunto de decisões que alguém tomou, e a pergunta útil não é se o comportamento foi intencional, mas se a intenção sobrevive ao contato com a sua configuração — uma pergunta que o fabricante não pode encerrar por você.
Quando para antes de você encontrar
Uma falha que cessa sozinha não foi corrigida, ficou inobservável. Enquanto você não conseguir enunciar um mecanismo que explique tanto por que começou quanto por que parou, chamar de resolvido é uma decisão de agenda vestida de palavra técnica.
Quando você não pode mexer
O ciclo de hipótese e teste pressupõe que você tem permissão para mudar alguma coisa. Quando não tem, o ciclo não quebra — ele se inverte: você deixa de fabricar evidência e passa a colher a evidência nas diferenças que o sistema já contém, e a habilidade está em reconhecer qual dessas diferenças é um experimento que alguém já rodou para você.
Quando os instrumentos concordam
Concordância entre medições só é evidência se as medições forem independentes, e quase nunca são — elas compartilham um coletor, um relógio, uma janela de média ou uma definição. Uma falha na camada compartilhada produz respostas unânimes, confiantes e erradas, de modo que a certeza da investigação sobe exatamente no momento em que deveria cair.
Quando são dois problemas
Quase toda técnica do repertório pressupõe uma causa única, e nenhuma delas avisa quando essa premissa deixa de valer. Duas falhas simultâneas não produzem resultados aleatórios — produzem resultados parciais, e ler resposta parcial como assinatura, e não como ruído, é a maior parte da habilidade.
Escalar é competência, não confissão
Profissionais escalam tarde demais porque escalar é vivido como confissão de incapacidade, e não como decisão de roteamento. O custo de escalar tarde é pago pelo cliente; o custo de escalar cedo é pago pela autoimagem de quem escala — e é por isso que o incentivo aponta para o lado errado, e por isso o gatilho precisa ser decidido antes do incidente, não durante.
Abrir um chamado com o fabricante que seja de fato trabalhado
O desfecho de um chamado é decidido em grande parte pela primeira mensagem, porque é ela que define em qual fila aquilo cai, com que prioridade, e se o primeiro engenheiro consegue agir ou precisa perguntar. A maior parte do tempo decorrido no suporte do fabricante não é análise — são idas e vindas por informação que você poderia ter fornecido no começo.
O que o suporte do fabricante pode e não pode fazer por você
Quase toda frustração com suporte de fabricante vem de pedir coisas estruturalmente impossíveis, e quase toda alavanca desperdiçada vem de nunca pedir as fáceis. O conhecimento útil não é como ser firme — é o formato das restrições dentro das quais a pessoa do outro lado trabalha.
RMA, e a logística de um equipamento morto
Um RMA é um processo logístico vestido de processo técnico. Provar que o hardware falhou é a metade curta; a metade longa é elegibilidade, alfândega, números de série e o fato de que o equipamento de reposição nunca é bem o mesmo — e quase todo o tempo recuperável se perde antes de alguém falar com uma transportadora.
Conduzir uma sala de crise
O trabalho de uma sala de crise não é resolver o problema mais rápido — uma sala cheia de gente quase nunca resolve. O trabalho dela é sustentar a autoridade de que a investigação precisa, remover impedimentos e absorver a demanda da organização por atualizações. A maioria das salas de crise falha invertendo isso: interrompe a investigação para manter a sala informada.
Decidir com informação incompleta
Você nunca vai ter o suficiente, e esperar por mais é, em si, uma decisão cujo custo corre enquanto ninguém o contabiliza. A habilidade não é intuição — é saber quais decisões são reversíveis, quão assimétrico é o custo de errar em cada direção, e se alguma observação disponível nos próximos vinte minutos mudaria de fato a resposta.
Comunicar para cima com o incidente em curso
Quem está acima de você não está pedindo detalhe técnico; está perguntando se precisa agir. Uma atualização que responde à pergunta técnica e não a essa será refeita em dez minutos — e a interrupção que você acha ruim é consequência previsível da atualização que você mandou.
Quando o fabricante está errado, e como provar
Estar certo não é a parte difícil; tornar o caso inatacável é. Um fabricante fecha o que não consegue reproduzir e defende o que não consegue enxergar, então o trabalho é construir evidência que sobreviva à leitura de um engenheiro cético que não estava lá — o que significa tirar a sua rede da discussão.
IV. Depois que passa
A metade do trabalho que costuma ser pulada, e a razão pela qual a mesma indisponibilidade volta.
O relato: o que registrar enquanto você ainda lembra
Os fatos de um incidente sobrevivem; o raciocínio não. Em um dia somem os becos sem saída, o que foi descartado e o motivo de você ter olhado onde olhou — e essas são as únicas partes de que a próxima pessoa precisa, porque a resposta é a única coisa que ela já consegue ler no chamado.
Causa raiz é uma escolha, não uma descoberta
Causas não terminam. Cada uma tem outra atrás, então o ponto em que a investigação para é decidido — por orçamento, por cansaço, pelo que a organização está disposta a ouvir — e a expressão "causa raiz" esconde que houve decisão.
Análise de causa sem bode expiatório
Culpa não é um defeito moral na sala de revisão; é a explicação mais rápida disponível. Enquanto o mecanismo não é compreendido, uma pessoa é a única coisa concreta na sala — então a culpa aparece por padrão, e é deslocada tornando o mecanismo concreto, não pedindo que as pessoas sejam mais gentis.
Linhas do tempo: reconstruir o que aconteceu, e quando
Uma linha do tempo não é uma lista de eventos; é uma afirmação sobre ordem, e é na ordem que a causa é lida. Cada fonte que a alimenta mente sobre o tempo do seu próprio jeito — relógios discordam, logs registram a escrita e não o evento, a memória reordena sob estresse — então uma sequência confiante é o artefato mais perigoso que um incidente produz.
A retrospectiva faz tudo parecer inevitável
Uma linha do tempo pronta se lê como uma sequência de passos óbvios, porque agora você sabe qual dos cem sinais importava. Quem respondeu estava olhando os cem, e nada distinguia o que importava. Julgar decisões contra um conhecimento que só existe depois do incidente é a forma mais confiável de uma revisão produzir a lição errada.
Prevenção que sobrevive ao encontro com o orçamento
A maior parte da prevenção não falha por mérito; falha porque foi proposta como projeto. Os remédios que de fato acontecem são os pequenos o bastante para caber na janela em que todo mundo ainda se importa, ou os que pegam carona em trabalho já financiado — e o estrutural só sobrevive se alguém o registrar como recusado, em vez de deixá-lo evaporar.
Devolver a correção ao projeto
Uma correção aplicada à instância deixa intocado aquilo que produziu a instância. Enquanto ela não chegar ao gerador — o template, o build padrão, o valor de fábrica, o procedimento — a próxima é fabricada pelo mesmo processo, e a correção comprou exatamente um equipamento de segurança.
A correção que você não consegue provar que funcionou
Uma correção normalmente é dada como verificada porque o sintoma parou. Isso não é evidência — é ausência de evidência, e é indistinguível do gatilho ter ido embora sozinho. Enquanto você não souber dizer por que a mudança endereça o mecanismo, "não voltou a acontecer" é uma afirmação sobre a sua janela de observação.
Registro de conhecimento que alguém vai realmente achar
Registrar conhecimento falha na recuperação, não na captura. As organizações guardam volumes enormes de conhecimento escrito sobre incidentes, indexado pela causa e por quem escreveu — enquanto quem precisa chega segurando apenas um sintoma, que é justamente a única coisa com que ninguém titulou nada.
A repetição: reconhecer uma falha antiga com roupa nova
Repetições quase nunca são reconhecidas, porque a segunda ocorrência se apresenta diferente — outro site, outro sintoma, outro time — e a única coisa em comum é o mecanismo, que é justamente o que o primeiro relato não registrou. Assim a organização resolve a mesma falha várias vezes e vive aquilo como azar.
V. A vida
A escala, a fila, o pager, as pessoas. A parte que nenhum runbook cobre e que todo profissional reconhece.
A fila como objeto psicológico
A fila nunca está vazia, e isso é um fato estrutural, não uma falha pessoal — mas é vivido como falha pessoal, continuamente, por gente trabalhando tão rápido quanto qualquer um trabalharia. O que ela faz com a atenção e com o julgamento custa mais do que o tamanho dela jamais custou.
O turno, a escala, e passar o bastão no meio do problema
Passar adiante uma investigação inacabada é o ato rotineiro mais difícil da operação, porque o que precisa ser transferido não são os fatos, e sim o modelo que está na sua cabeça — e, se você não passar a sua incerteza com o mesmo cuidado com que passa os achados, quem recebe reconstrói errado ou recomeça do zero.
Sobreaviso, com honestidade
O custo do sobreaviso não são as noites em que você é chamado. São as noites em que você pode ser — que são todas — e quase nenhum modelo de remuneração precifica isso, porque todos contam acionamentos. A restrição é o produto; as chamadas são um detalhe ocasional dela.
Julgamento na hora onze
O cansaço não deixa você principalmente mais lento. Ele muda aquilo em que você acredita — estreita o conjunto de explicações que você consegue sustentar, endurece a que você já está seguindo, e degrada justamente a faculdade que teria avisado que tudo isso estava acontecendo. As contramedidas não podem depender de autoavaliação, porque a autoavaliação foi a primeira coisa a quebrar.
O cliente que está furioso e tem razão
O cliente difícil não é o que está errado. É aquele cuja raiva é proporcional e cujos fatos estão certos — porque toda técnica de lidar com pessoas difíceis foi construída para acalmar quem entendeu errado, e nenhuma delas funciona com quem entendeu perfeitamente.
Trabalhar com gente com medo
Medo num incidente quase nunca é do sistema; é do que admitir alguma coisa vai custar à pessoa. E ele se prende com regularidade a quem está segurando justamente o fato de que você mais precisa — o que faz da segurança psicológica um insumo operacional, não uma gentileza de cultura.
Campo: como é de verdade viajar para consertar coisas
Trabalho de campo não é o mesmo trabalho feito em outro lugar. O que domina o dia é logístico e social — entrar no prédio, o que você trouxe ou deixou de trazer, e quem está atrás de você — e a parte técnica costuma ser a menor e mais fácil do dia.
Carreiras para dentro do suporte, e para fora dele
A indústria trata operação como uma etapa pela qual se passa, e isso é errado nas duas direções: não dá a quem fica nada em que crescer além de gestão, e deixa quem sai sem um relato exato do que aprendeu. As competências são reais, transferíveis, e mal nomeadas.
Esgotamento em operação, sem o cartaz de bem-estar
Esgotamento não é causado por trabalhar duro, e não é falta de resiliência. Em operação ele tem causas estruturais específicas — trabalho que nunca conclui, responsabilidade sem autoridade, sucesso invisível e esforço que não acumula — e nomear o mecanismo importa, porque o mecanismo é o que pode ser mudado.
VI. O ofício
Evidências, captura, ferramental e os limites honestos da automação.
Capturar antes de mudar: a primeira disciplina
Toda mudança destrói a evidência do que havia antes, e destrói em silêncio. O estado anterior à mudança é uma observação única e não renovável: dez segundos de captura compram a capacidade de responder perguntas que você ainda nem sabe que vão te fazer, e pular isso as inviabiliza para sempre.
Montar um pacote de evidências
Um pacote de evidências não é tudo que você tem; é uma seleção feita para um leitor com uma decisão a tomar. Mandar tudo falha do mesmo jeito que mandar nada — transfere o trabalho de achar o sinal para quem você está pedindo ajuda, e essa pessoa vai fazer pior que você, porque não enxerga o seu parque.
Disciplina de captura de pacotes: quando, onde e quanto
Uma captura é a evidência de maior resolução disponível e a mais fácil de tornar inútil. A maioria das capturas falha antes de começar — feita em um ponto em vez de dois, filtrada até excluir a resposta, ou tão grande que ninguém jamais a abre.
O que capturar antes de saber o que aconteceu
Decisões de captura são tomadas no momento de máxima incerteza e mínima informação: é preciso decidir o que vai importar antes de saber o que aconteceu. Isso não é um problema de conhecimento que se resolve sabendo mais — é estrutural, e a resposta é capturar por taxa de decaimento, não por hipótese.
Disciplina de log, e os logs que não existem
A maior parte dos problemas com log não é volume nem retenção; é ausência. A linha de que você precisa nunca foi escrita, ou foi escrita num nível que ninguém liga, ou girou embora antes de alguém olhar — e cada uma dessas é uma decisão que alguém tomou anos atrás sem saber que estava tomando.
Evidência que ainda convence no trimestre que vem
Evidência é montada por quem tem todo o contexto, para um leitor que não tem nenhum e não pode fazer uma pergunta. A distância não é de detalhe — é que quem escreve não enxerga qual parte do contexto saiu da própria cabeça, então tudo que era óbvio na hora fica invisível no documento.
Comparação de configuração e controle de versão em parques de rede
"O que mudou?" é a pergunta de maior rendimento em diagnóstico, e a maioria dos parques não consegue responder, porque guarda backups e não histórico. Um backup permite restaurar; só uma série permite comparar — e o trabalho que torna a comparação utilizável não é o armazenamento, é a normalização.
Os scripts que vale guardar
A maior parte dos scripts de operação é escrita uma vez, usada uma vez, e guardada para sempre. Os que valem ser guardados não se distinguem por qualidade, e sim por outra pessoa conseguir rodá-los com segurança — e um script que mais ninguém se atreve a rodar é um passivo fantasiado de ativo.
O que automatizar, e o que nunca
A pergunta nunca é se algo pode ser automatizado — quase tudo pode. É como a falha vai se parecer depois. Automação não reduz erro, ela muda o formato dele: menos enganos, cada um aplicado em todo lugar ao mesmo tempo, por algo que não vai perceber.