ronutz

Os Papéis · Quem faz

Engenheiro de software de redes

Escrito a partir de fontes publicadas

O engenheiro que escreve o sistema operacional sobre o qual uma rede roda. É engenharia de software moldada por restrições incomuns: o código roda sem ninguém por perto, em equipamento que não pode reiniciar, e uma falha aparece como um serviço fora do ar em outro continente.

Como é o dia

  • Escrever e revisar código contra uma especificação de protocolo que outras implementações também leem — e leem diferente.
  • Trabalhar dentro da arquitetura da plataforma, que dita as regras: um address space compartilhado faz de um defeito a indisponibilidade de todo mundo, e um state store torna um processo reiniciável.
  • Testar contra hardware, contra escala, e contra os casos de interoperabilidade que só aparecem quando há outro fabricante na outra ponta.
  • Pegar um defeito reproduzido pelo terceiro nível de suporte e achar o que no código o produziu.
  • Decidir qual release carrega uma correção, que é uma conversa sobre risco, não sobre código.

Pelo que responde

  • Código que se comporte corretamente em escala e sob as condições de falha que a plataforma promete sobreviver.
  • Interoperabilidade com implementações escritas por outras pessoas a partir da mesma especificação.
  • A correção chegar numa release, no calendário que o suporte e os clientes ouviram.

Como é medido

  • Taxa de escape de defeitos, que é o que o cliente vive como qualidade.
  • Entrega contra o release train, que anda pelo portfólio inteiro, e não por uma feature.
  • Cobertura de testes e os resultados da suíte de regressão.

De quem recebe

O suporte de produto de terceiro nível
Defeitos reproduzidos com a evidência anexada — a diferença entre uma correção e uma investigação.
A gestão de produto
Requisitos, prioridades, e os clientes por trás deles.
Órgãos de padronização e especificações
O comportamento com que o código tem de concordar.

A quem serve

Todo engenheiro rodando a release
Software que se comporta como documentado, inclusive quando algo falha.
O suporte, em todos os níveis
Correções, contornos (workarounds) e a explicação no nível do código por trás deles.
A própria arquitetura da plataforma
Mudanças que respeitam as restrições que o desenho existe para dar.

Quem mais tem interesse

  • Os clientes cujas redes carregam a release, e a maioria nunca vai reportar nada.
  • As organizações de suporte mundo afora, cujo volume de casos corre a jusante deste código.
  • Os outros fabricantes, cujas implementações têm de interoperar com esta.

O que exige

  • Programação de sistemas, e a disciplina que vem de código rodando onde ninguém consegue plugar um debugger.
  • Ler especificações de perto, já que interoperabilidade é acordo sobre ambiguidade.
  • Estar à vontade com uma cadência de release medida em meses e uma vida de suporte medida em anos.
  • O discernimento de pesar uma correção contra o risco de entregá-la, que é uma decisão sobre a rede dos outros.

Do que o trabalho depende

A arquitetura decide o preço de um erro, e a arquitetura foi escolhida muito antes de o engenheiro atual chegar. Numa plataforma em que todos os processos dividem um único address space, um defeito numa feature alcança tudo — então a cautela é o único mecanismo de segurança disponível. Numa plataforma em que um processo pode ser reiniciado a partir de um state store, o mesmo defeito fica contido, e o esforço de engenharia migra de evitar falhas para se recuperar delas. Entender para qual plataforma você está escrevendo é, portanto, a primeira coisa a aprender sobre o trabalho.

As fontes publicadas

Para onde leva

Papéis que levam até aqui

O trabalho em si

A Prática cobre como este trabalho é feito — triagem, escalação, evidência, passagem de bastão — em todo o corpus.

Ler A Prática