Engenheiro(a) de Plataforma

Self-Service Infrastructure

Por quê: Permite desenhar o self-service com proteções de custo, segurança e responsabilidade, para as equipes criarem ambientes à vontade sem que um banco esquecido e desprotegido apareça na fatura.

Developer Portal (Backstage)

Por quê: Permite operar um catálogo de serviços no Backstage com responsáveis, docs e links, para que num incidente qualquer pessoa descubra em segundos quem é dono do serviço que falha.

Kubernetes Operations

Por quê: Permite definir cadência de atualização, modelo de multitenancy e políticas para os clusters de várias equipes e planejar a troca de versões para que uma API removida não quebre aplicações que não são suas.

Helm Chart Design

Por quê: Permite versionar um chart compartilhado e gerir suas dependências e atualizações, para que mudar um default não altere em silêncio o deploy de dezenas de serviços.

Terraform Modules & State

Por quê: Permite governar versões de módulos e layout de estado entre contas, para que uma mudança num módulo de rede compartilhado seja implantada de forma deliberada e não quebre todos os consumidores no próximo apply.

GitOps (ArgoCD/Flux)

Por quê: Permite estruturar repositórios e promoção de GitOps para muitas equipes, decidindo quem pode alterar o quê, para que desvios e disputas de responsabilidade não se acumulem à medida que você escala.

Build Optimization & Caching

Por quê: Permite dimensionar a infraestrutura de build e os caches remotos da empresa e mostrar as horas de engenharia economizadas, que é como você justifica o orçamento disso.

Artifact Management

Por quê: Permite promover uma mesma imagem assinada entre ambientes a partir de um registry controlado, para que o que rodou no staging seja o que chega à produção e uma dependência comprometida possa ser rastreada.

Centralized Logging

Por quê: Permite decidir retenção, indexação e custo da plataforma de logs para a empresa toda, para que a busca em incidentes continue rápida sem a conta de logs crescer mais que o tráfego.

Metrics & Dashboarding (Prometheus/Grafana)

Por quê: Permite definir um padrão de nomes e cardinalidade de métricas, para que uma equipe que adiciona um label de alta cardinalidade não sobrecarregue o Prometheus e os dashboards sigam comparáveis entre serviços.

Platform Team Topologies

Por quê: Permite explicar por que a equipe de plataforma oferece serviços em vez de atender tickets e definir sua interação com as equipes de fluxo para que ela não vire gargalo.

API-First Platform Design

Por quê: Permite expor capacidades da plataforma por APIs versionadas, para que outras equipes automatizem em cima delas e você mude o interno sem quebrar os scripts delas.

Internal Developer Platforms

Por quê: Permite conectar pipelines, infraestrutura e documentação numa plataforma interna única, para o desenvolvedor ir da ideia a um serviço rodando por um caminho só em vez de cinco ferramentas.

Developer Experience Metrics

Por quê: Permite combinar números DORA com pesquisas com desenvolvedores para mostrar se a plataforma ajuda e escolher o próximo investimento por evidência e não pelo pedido mais barulhento.