Categoria
Operações e fieldcraft
Todas as ferramentas e artigos desta categoria, reunidos em um só lugar.
Ferramentas
Analisador de mensagens syslog
Cole uma mensagem syslog, ou um quadro TCP que a carrega, e leia cada campo nomeado na ordem em que a RFC os nomeia: o PRI aberto em facility e severidade, o cabeçalho da RFC 5424, os dados estruturados elemento por elemento, a mensagem; ou a forma BSD da RFC 3164, com TIMESTAMP, HOSTNAME, TAG e CONTENT. O que não está em conformidade é dito nas palavras da própria RFC. Nada é enviado a lugar algum.
Calculadora de permissões chmod
Digite um modo de arquivo em octal (4755), como o ls mostra (-rwsr-xr-x) ou como cláusulas do chmod sobre uma base (g+s,o-rwx) e leia-o de todas as outras formas: os bits, quem pode fazer o quê, o que setuid, setgid e o sticky bit significam para um arquivo ou um diretório, os comandos que chegam a ele, o umask que o criaria e um rastro de cada cláusula. Do chmod e do ls do POSIX.1-2024 e do chmod(1) do coreutils 9.11; nada sai do navegador.
Comparador de sistemas operacionais de rede
Quatorze sistemas operacionais de rede — IOS, IOS XE, IOS XR, NX-OS, Junos, Junos Evolved, EOS, TMOS, F5OS, EXOS, VOSS, FortiOS, PAN-OS e Gaia — com linhagem, sobre o que cada um roda, como os componentes compartilham estado, onde os planos se dividem, e quanto custa uma atualização. Escolha um para o perfil completo ou dois para vê-los eixo a eixo. Toda entrada lista fraquezas além de forças.
Comparador de Snapshots de Saúde Antes/Depois
Você declara os estados, a ferramenta condiciona a conclusão: sete seleções produzem um relatório de comparação em camadas - qualidade da baseline, catálogo de dimensões com classes de churn, orientação de interpretação de deltas e o portão continuar / observar / investigar / manter-rollback-armado. Nunca rotula uma mudança como bem-sucedida só por componentes verdes.
Construtor de Hipóteses de Falha
Descreva uma falha em seis campos estruturados; um conjunto fixo de regras classifica hipóteses a testar - com as evidências a coletar, o que sustentaria cada uma e o que a enfraqueceria. Estrutura consultiva, nunca um diagnóstico.
Construtor de Linha do Tempo e RCA de Incidente
RCA é a sigla de root cause analysis, a análise de causa raiz - o caminho disciplinado dos sintomas de um incidente de volta às condições que o permitiram. Insira os eventos de um incidente como uma pequena linha do tempo e marque os domínios de fator contribuinte que você observou; um conjunto fixo de regras ordena a linha do tempo, deriva os intervalos entre marcos e estrutura fatores contribuintes candidatos com a evidência de cada um. Nunca aponta uma causa-raiz - candidatos a investigar, não um veredito.
Construtor de Pacote de Escalação para TAC
Descreva o problema que você está prestes a escalar; um conjunto fixo de regras monta um pacote completo de suporte do fornecedor e uma lista dos artefatos que ainda faltam coletar antes de abrir o chamado, removendo o que você já tem. Estrutura a passagem; não abre um chamado nem contata nenhum fornecedor.
Construtor de Plano de Captura de Pacotes
Construtores de comandos respondem como capturar; este responde onde, por que e o que significaria. Descreva o caminho e o sintoma; um registro original de 35 regras projeta um plano de captura em fases: pontos ranqueados em fronteiras nomeadas, observações esperadas, uma matriz de interpretação com sustenta e enfraquece decididos antes da coleta, e disciplina de sincronização e autorização. Ele planeja capturas - nunca as ingere.
Construtor de Runbook de Janela de Mudança
Descreva uma mudança planejada em seis campos estruturados; um conjunto fixo de regras monta um runbook ordenado em seis fases — com os riscos que o plano carrega e ressalvas de prontidão sobre a entrada. Estrutura consultiva para revisar e adaptar, nunca uma aprovação.
Explicador de terminal, shell, TTY e console
Cole o que o `tty` imprimiu — /dev/pts/3, /dev/tty2, /dev/ttyS0, /dev/tty, /dev/console, ou “not a tty” — e veja qual camada você está realmente olhando, o que segura a outra ponta, e o que isso implica para sinais, controle de jobs e o que acontece quando a janela fecha. Local e offline.
Mapeador de níveis de log
Escolha um nível em um sistema de log (syslog, o kernel Linux, Cisco IOS, Junos, Windows Event Log, .NET, Python, java.util.logging, Log4j 2, OpenTelemetry) e leia o equivalente mais próximo em cada um dos outros, com o número e as palavras de cada sistema, onde a correspondência é exata e onde é só o degrau mais próximo. A ponte é o SeverityNumber do OpenTelemetry, a única escala definida para conter as outras. Nada é enviado a lugar algum.
Mapeador de Raio de Impacto de Mudança
Descreva o que você está mudando e a estrutura dele; um conjunto fixo de regras mapeia o raio de impacto como camadas concêntricas (alvo, co-localizado, a jusante, humano) preenchidas com o que poderia ser afetado, mais riscos classificados por severidade e medidas de contenção. Mapeia o que poderia ser afetado, nunca afirma o que vai quebrar.
Playground de Python
CPython 3.14 de verdade no seu navegador, para a aritmética das redes: sub-redes, máscaras, EUI-64, cabeçalhos DNS em struct, HMAC, estatísticas de latência, tempos de transferência. Um motor de 13,5 MB é baixado uma vez, quando você autorizar; nada do que você digita sai da página.
Raciocinador de Caminho de Fluxo
A habilidade sênior é recusar-se a fazer troubleshooting até o caminho estar entendido. Sete seleções constroem um mapa canônico de saltos com fluxos laterais, segmentos TLS, pontos de reescrita e domínios de falha ranqueados - e os desconhecidos permanecem visivelmente desconhecidos.
Rastreador de transformação digital
Trinta marcos em sete domínios, ordenados por quanto você deve confiar neles: o que já aconteceu, o que já é lei, o que está agendado, o que está agendado mas em movimento, e o que é apenas a previsão de alguém.
Artigos
Do primeiro sintoma a um chamado que não volta
Cinco passos que nunca nomeiam uma causa raiz. A disciplina é manter separado o que você observou do que você concluiu, porque uma escalação que mistura os dois é uma escalação que volta pedindo a diferença.
LerPlanejar uma mudança, e o passo que todo mundo pula
Mapeie o alcance, escreva o runbook com o plano de retorno, depois compare a saúde antes e depois. O terceiro passo é o que se abandona, e é o único capaz de dizer que a mudança fez o que você prometeu.
LerGit: o banco endereçado por conteúdo vestindo terno de controle de versão
O que o Git guarda de verdade (snapshots, não diffs), por que uma branch é só um ponteiro de 41 bytes, como as três áreas explicam quase todo comando confuso, e o que fez de um projeto paralelo de duas semanas o padrão da indústria em quinze anos.
LerGitHub: o pull request era o produto
O Git resolveu copiar; o GitHub resolveu coordenar. Como um app Rails de 2008 transformou o patch por e-mail numa conversa revisável, fez do perfil um currículo, acumulou uma plataforma ao redor do repositório e virou o maior host de código do mundo sem nunca ser dono do protocolo por baixo.
LerO que um engenheiro de sistemas de canal realmente faz
Dentro de um distribuidor existe uma função que quase ninguém de fora do canal sabe descrever: o engenheiro de sistemas que atende revendas, não clientes finais. Montagem de lista de materiais em todo projeto que passa por ali, provas de conceito, apresentações, capacitação, bootcamps, feiras. Algumas das revendas atendidas não têm equipe técnica nenhuma, e é esse fato que explica todo o resto do trabalho.
LerTerminal, shell, TTY, console
Quatro palavras usadas de forma intercambiável por quase todo mundo, inclusive pela documentação. Elas nomeiam quatro coisas diferentes, e a distinção explica por que Ctrl+C mata o seu comando mas não o seu shell.
LerO que é, de fato, um sistema operacional de rede
IOS, Junos, EOS, TMOS, FortiOS, PAN-OS e os demais, comparados nos eixos que importam: sobre o que rodam, como os componentes compartilham estado, onde os planos se dividem, e o que acontece quando uma parte falha.
LerO caminho que um produto percorre, e os trabalhos ao longo dele
Entre a empresa que constrói uma coisa e a pessoa que depende dela, um produto passa por muitas mãos. Cada par pertence a um trabalho com clientes, fornecedores, responsabilidade e medição próprios — e a medição raramente é a mesma coisa que a responsabilidade.
Lercron: cinco campos que rodam as tarefas do mundo
Toda máquina Unix carrega um agendador cuja língua inteira são cinco colunas de números e asteriscos. Como lê-los, a regra do OU que pega quase todo mundo, por que 0 e 7 são o mesmo dia, para que as macros @ expandem, e a realidade de horário local por trás de toda execução projetada.
LerOpen source, e os dois sentidos de free
O inglês sobrecarrega uma palavra pequena, e quarenta anos de história do software pendem dessa ambiguidade. As quatro liberdades, o rebatismo de 1998 que criou o 'open source', copyleft versus permissivas, por que gratuito não é livre — e por que quem fala português nunca teve esse problema.
LerDecidido de antemão: as cinco práticas que as falhas defendem
Duas páginas companheiras reúnem o que quebrou e o que foi dito. Esta é a terceira pergunta: o que precisa ser decidido antes de qualquer coisa acontecer, porque não pode ser decidido durante. Cinco práticas, cada uma emparelhada com o caso que demonstra o custo de não tê-la - uma linha de base, um raio de dano, uma janela de mudança, um backup restaurável, e uma fronteira.
LerComo revisar uma arquitetura de rede de forma independente antes de aprová-la
Um projeto chega com um diagrama, uma lista de materiais e uma data. Aprová-lo é uma decisão com anos de consequência, e o material diante de você foi preparado por quem quer a aprovação. Um método para lê-lo nos seus próprios termos: o que pedir antes de começar, as sete perguntas que encontram a maioria dos problemas, como separar o que o projeto diz do que ele presume, e o que uma revisão por escrito deve conter para que a aprovação sobreviva a quem a deu.
LerComo encontrar as premissas escondidas num diagrama de arquitetura
Um diagrama mostra o que foi decidido e esconde o que foi presumido. As caixas são produtos, as linhas são intenções, e as coisas que de fato vão falhar, a dependência compartilhada, o pico não medido, a função sem dono, o caminho que só funciona num sentido, não estão desenhadas porque ninguém as pensou como decisões. Oito lugares em que as premissas se escondem num diagrama, as perguntas que trazem cada uma à tona, e o registro que transforma uma leitura em algo que a organização consegue usar no terceiro ano.
LerO que deve haver numa revisão técnica pós-incidente
Depois de uma interrupção grave alguém tem de escrever o que aconteceu, e o documento que resulta costuma ser ou uma defesa ou uma acusação. Uma revisão técnica não é nenhuma das duas. É escrita para quem não estava lá, mantém o que foi observado separado do que foi concluído, nomeia as condições que tornaram a falha possível em vez da pessoa que tocou o teclado, e termina em mudanças que podem ser verificadas. O que uma revisão assim contém, quem deve escrevê-la, e os três tipos de revisão que não se podem confundir.
LerComo separar limitações de produto de falhas de arquitetura
Quando algo falha, a primeira explicação na mesa é o produto, porque o produto tem um fabricante e o fabricante tem uma linha de suporte. Muitas vezes o produto fez exatamente o que foi construído para fazer, dentro de um projeto que lhe pediu outra coisa. Distinguir os dois importa, porque a correção para uma limitação de produto é um chamado, uma correção ou uma substituição, e a correção para uma falha de arquitetura é uma mudança no projeto, e comprar um produto novo para corrigir um projeto é a forma mais cara de manter o problema. Um método para fazer a distinção, com evidência.
LerO que executivos devem perguntar antes de aprovar uma transformação de rede
Um programa de transformação chega à mesa executiva como uma visão, um fornecedor, um orçamento e uma data, e o detalhe técnico por baixo dele é exatamente o que as pessoas à mesa foram contratadas para não precisar. Elas não precisam dele. Precisam de doze perguntas cujas respostas dizem se o detalhe foi feito, quem carrega qual risco, o que a organização não vai conseguir desfazer, e quanto os primeiros noventa dias vão custar em atenção. As perguntas, por que cada uma importa, e como soa uma boa resposta.
LerModos de arquivo, lidos como o kernel os lê: octal, simbólico e os três bits que quase todo mundo pula
Um modo de arquivo Unix tem doze bits, e quase todo erro de permissão vem de ler nove deles. De onde vem o 755, por que o ls imprime um s ou um T, o que set-user-ID, set-group-ID e a flag de exclusão restrita fazem num arquivo e num diretório, como uma cláusula do chmod sem classe passa em silêncio pelo umask, por que X não é x, e a regra do GNU que preserva o set-group-ID de um diretório quando você digita chmod 755. Do POSIX.1-2024 e do coreutils 9.11, com a calculadora para experimentar cada caso.
LerComo ler uma mensagem syslog campo a campo: o que o parser verifica e de onde vem cada regra
Uma mensagem RFC 5424 tem sete campos de header, um bloco de dados estruturados e um texto livre no final, e cada parte tem uma regra que um parser consegue testar: a regra do zero à esquerda no PRI, o T e o Z maiúsculos do timestamp, o APP-NAME de até 48 caracteres, os escapes dentro dos dados estruturados, o byte order mark que indica UTF-8, os limites de 480 e 2048 octetos e as duas formas de delimitar uma mensagem no TCP. Tudo lido nas próprias RFCs, com o parser aplicando cada regra enquanto você lê.
LerNíveis de log entre sistemas: uma escala, muitas escadas
O syslog conta para baixo a partir de 0, o Python conta para cima de dez em dez, o Log4j dá a FATAL o menor número e a TRACE o maior, o Windows põe Critical em 1 e o java.util.logging põe SEVERE em 1000. Todo sistema tem uma escada, nenhuma concorda com a outra em direção ou espaçamento, e a mesma palavra cai em lugares diferentes. O SeverityNumber do OpenTelemetry é a única escala escrita para abrigar todas, e este artigo percorre as dez escadas que o mapeador conhece, onde cada degrau cai, e onde o mapeamento é um julgamento e não um fato.
LerAccounting: quem fez o quê, em qual equipamento e quando
O terceiro A do AAA tratado como projeto de engenharia, e não como item de checklist: os quatro fluxos de registro que, juntos, respondem à pergunta feita depois de toda queda e de toda invasão (o RADIUS accounting da RFC 2866, o accounting de comandos do TACACS+ da RFC 8907, o syslog da RFC 5424 e o log de mudanças de configuração do próprio equipamento), mais os backups de configuração, que mostram o que os comandos fizeram; o que cada registro contém, campo a campo; os controles da NIST SP 800-53 que dizem o que um registro precisa comprovar; os relógios, a retenção, as chaves de correlação e a segregação de funções que tornam os registros utilizáveis; e o apontamento mais antigo da área: o equipamento em que ninguém configurou para onde enviar esses registros.
Ler