Catálogo de Serviços e Propriedade (Ownership)

Um catálogo de serviços é a fonte única da verdade para 'o que estamos rodando, e quem é dono disso?' Sem um, todo incidente começa com 20 minutos de threads no Slack perguntando 'alguém sabe quem é dono desse serviço?' Aqui está como eu resolveria essa bagunça de ownership: Primeiro, exija que todo serviço tenha um catalog-info.yaml no seu repositório. Esse arquivo declara o nome do serviço, o time responsável, as dependências e as especificações de API. Se um repositório não tiver um, ele aparece como 'sem dono' no catálogo, o que cria pressão social para corrigir isso. Segundo, automatize a descoberta do catálogo. Não dependa de pessoas registrando serviços manualmente. Faça scan da sua organização no GitHub, puxe metadados do Kubernetes (o que está realmente rodando) e cruze com o seu provedor de nuvem. Se um serviço está rodando em produção, mas não está no catálogo, sinalize isso. Terceiro, torne o catálogo útil, não apenas um registro. Um bom catálogo de serviços mostra: quem é o dono, do que ele depende, sua saúde atual, deploys recentes, escala de plantão (on-call), documentação de API e custo. Se o catálogo é apenas uma lista de nomes, ninguém vai mantê-lo. O modelo de ownership também importa. Use ownership por time, não por indivíduo. Pessoas saem. Times permanecem. E todo serviço deve ter exatamente um time responsável. Ownership compartilhado significa nenhum ownership. Ferramentas como Backstage, Cortex ou OpsLevel fazem isso bem, mas você pode começar com um simples arquivo YAML por repositório e um script que os agrega.