Engenheiro de DevOps / plataforma / SRE

Infraestrutura como código, definições de condutas, manifestos: o grande volume de texto estruturado que descreve o que deve existir.

Decidir às três da manhã, com pressa e com informação parcial, o que se reverte, o que se degrada e o que se diz às pessoas enquanto ainda está partido.

Explicar uma fatura de nuvem, encontrar o que a triplicou e decidir que ineficiência merece a semana de um engenheiro.

Escolher a arquitetura, os modos de falha que estás disposto a ter, e aquilo que a equipa ainda vai conseguir operar daqui a dois anos.

Um inquérito a profissionais, pelo que esses 90% são uso declarado por quem responde e não uso medido, e o «80% acredita que aumentou a sua produtividade» que o acompanha é uma crença e tem de ser lido como tal: este sítio tem um ensaio aleatorizado em que programadores experientes ficaram 19% mais lentos enquanto acreditavam estar 20% mais rápidos, pelo que aquilo que alguém acredita sobre a própria velocidade não é prova sobre a sua velocidade. O que não é declaração sobre o próprio desempenho é a correlação que os investigadores calculam entre quem responde, e é essa a parte útil: a adoção relaciona-se positivamente com o débito do processo e com o desempenho do produto, e negativamente com a estabilidade da entrega. O mecanismo que os autores dão é concreto: sem testes automatizados sólidos, controlo de versões maduro e ciclos de retorno rápidos, um maior volume de alterações produz instabilidade, e as equipas com arquiteturas pouco acopladas veem ganhos enquanto as muito acopladas veem poucos ou nenhuns. Quem publica isto é a Google Cloud, que vende as ferramentas por que pergunta.

Uma ferramenta é usada em grande escala em trabalho real e isso está medido, e quem decidiu usá-la foi a pessoa que trabalha, não quem emprega. É mais do que um registo de capacidade — o trabalho é real, não uma demonstração — e menos do que um de implementação, porque nenhum empregador a pôs em produção, nem a exigiu, nem construiu um processo à sua volta. Ponderada como `cautious`: `automating` significa que a máquina consegue fazer a tarefa E que há sinais de adoção, e isto é um sinal de adoção; mas o uso pode ser experimental, e boa parte da medição vem de uma parte com interesses, por isso um registo nunca chega e dois independentes chegam. Repara também em quem está a contar. A telemetria de um fornecedor vê isto diretamente e ao mesmo tempo vende a ferramenta, por isso um registo deste tipo declara esse interesse no seu âmbito; uma agência estatística que pergunta às empresas se os seus trabalhadores usam IA em tarefas vê o mesmo canal sem interesse nenhum, e onde exista é a melhor fonte.

Um estudo setorial encomendado, não uma medição, e fica registado aqui porque aponta na direção contrária a quase todo o resto desta base. O mesmo documento que espera que o suporte autónomo encolha espera que o trabalho aterre neste posto: diz que a função de DevOps passará a supervisionar os acordos de nível de serviço e a desenvolver novos sistemas, que desenvolvimento e operações se juntam para dar um suporte mais integral, e enumera os engenheiros de automatização e orquestração entre os postos com procura crescente. Nomeia também o engenheiro de DevOps como o destino que considera um salto fácil ou moderado para os engenheiros de suporte cujo deslocamento espera. Nada disso é prova de que alguém tenha sido contratado, de que os efetivos tenham subido ou de que a transição tenha acontecido: é a expectativa de uma agência, publicada antes de a IA generativa chegar ao público, referida apenas a Singapura e construída a partir de entrevistas a partes interessadas e não de dados de emprego. O que estabelece é que o achado de deslocamento noutra parte do mesmo relatório não afirma que o trabalho desaparece.

Uma pessoa com nome e com posição reconhecida previu algo publicamente, numa data, numa declaração atribuível. É registado para que fique verificável quem disse o quê e quando, e nunca move a avaliação de uma tarefa, porque uma previsão não é uma observação. O seu valor chega depois: o registo fica na mesma página que a prova sobre essa profissão, portanto quem lê a previsão lê ao lado o registo do que aconteceu a seguir. É essa a prestação de contas; este sítio não publica veredicto nenhum sobre se uma previsão se cumpriu.

O degrau que antes contratava gente júnior, escrever e ligar configuração, é o que tem apontado o mecanismo mais claro, porque é código com um resultado verificável por máquina. O que isso deixa a quem começa é a prevenção, que é a parte mais dura e a que era suposto ganhar-se. Insiste em estar nas revisões de incidentes muito antes de entrares na escala.

A tua alavanca é a decisão de desenho e a chamada de incidente, e ambas são fatias pequenas da semana. O risco não é serem automatizadas, é as horas à volta delas serem adelgaçadas até um engenheiro cobrir serviços que nenhuma pessoa consegue ter na cabeça. Vigia os serviços por engenheiro como um empregado de mesa vigia os talheres por empregado.

Ficar e reforçar-te

Move-te para o desenho e afasta-te das ligações

A decisão de desenho não tem árbitro automático, que é exatamente por que nenhuma ferramenta consegue fechar o ciclo sobre ela, e é a parte do posto que se acumula.

Refazer o posto

Fica com a operabilidade daquilo que os outros constroem

Ser gerada mais configuração significa mais sistemas por que ninguém responde, e alguém tem de segurar o padrão do que pode correr em produção.

A metade da configuração está a mexer-se e depressa, porque o código de infraestrutura ou se aplica limpo ou dá erro, e um resultado verificável por máquina é o que permite a um modelo tentar de novo sem supervisão. A prevenção não, porque um incidente é por definição a falha que ninguém antecipou e a chamada é sobre dano aceitável e não sobre uma resposta certa. A forma provável não é a remoção mas o adelgaçamento: menos engenheiros a cobrir mais serviços, o que mantém todas as tarefas e piora a escala.

Nenhuma data. Dois números que consegues produzir sozinho dizem mais do que qualquer previsão: que parte da tua semana vai para trabalho em que aplicá-lo ou corre bem ou dá erro, e por quantos serviços responde agora cada engenheiro da tua escala. O primeiro é a tua exposição por tarefa; o segundo é a mudança que chega mesmo às pessoas neste posto, e mexe-se em silêncio um par de trimestres depois de aterrar qualquer ferramenta.

Em geral não, e este é o caso mais claro do sítio de uma ferramenta que parece uma poupança e se comporta como uma dívida. Cada recurso criado é um recurso que alguém tem de manter, proteger e por fim apagar, por isso configurar mais depressa produz mais configuração em vez de menos trabalho: as horas passam de escrever para desemaranhar. Desemaranhar é invisível num plano, que é exatamente por que é orçamentado como uma poupança.

É a tarefa mais segura da ocupação e também a mais pequena. Se um desenho estava certo descobre-se dezoito meses depois, o que significa que não há árbitro automático e portanto não há ciclo que uma ferramenta possa fechar; mas na maioria das equipas as decisões de desenho são uns dias por trimestre. Um posto pode estar seguro na sua tarefa mais sénior e ainda assim perder a maior parte das suas horas, e é essa distância que há a planear.