operations

O repositório operations opera o que permite a uma equipe ver como está seu produto: o caminho que leva logs, métricas e traces ao Grafana Cloud, os painéis e as regras de alerta que cada produto recebe a partir da sua entrada no catálogo, o relatório diário de custos, e o catálogo de arquitetura que mapeia cada produto. Nenhuma equipe configura nada disso à mão: tudo sai do catálogo.

Para que serve

Um produto que ninguém consegue observar é um produto que ninguém consegue operar. O operations garante que cada produto comece com a mesma observabilidade, sem que a equipe a construa, e que a própria plataforma seja observada do mesmo jeito.

O que ele contém

roots/telemetry: os gateways de telemetria, um par por edição, produção e não produção, rodando Grafana Alloy, o coletor de telemetria do Grafana, no Cloud Run e indo a zero. As aplicações enviam traces e métricas por OTLP, o protocolo do OpenTelemetry, e seus logs chegam aos gateways por um buffer. Os endpoints são publicados para que a saída Ready de cada produto os carregue.
roots/grafana: o reconciliador do único stack do Grafana Cloud. A partir do catálogo, ele cria as equipes e uma pasta por produto, e na pasta de cada produto um painel do serviço, um painel de confiabilidade e um painel de custos, com regras de alerta básicas que avaliam a produção e avisam o ponto de contato da equipe.
roots/cost: o conjunto de dados que recebe a exportação de faturamento do Google Cloud. Um job diário, cost:report, a transforma nas séries de custo por trás do painel de custos de cada produto, com o orçamento do produto no catálogo como limite: laranja em 80 por cento e vermelho em 100.
roots/eventcatalog e eventcatalog/: o catálogo de arquitetura. Cada repositório publica uma descrição de si mesmo a cada merge; um agregador as junta em um só site, reconstruído depois de cada publicação e a cada hora, em catalog.projectairframe.dev atrás do login único.
jobs/: os relatórios agendados: cobertura de testes, custos e entregas.

Como ele se conecta

Ele lê o catálogo. A cadeia depois de um merge no catálogo roda o pipeline deste repositório em segundo lugar, depois do landing-zone, para que as identidades às quais ele concede permissões já existam.
Ele lê as saídas do landing-zone. A raiz de telemetria dá às identidades de cada produto o que elas precisam para enviar telemetria; a raiz do Grafana posiciona os painéis de cada produto.
Os produtos publicam para ele. A própria raiz infra/grafana de um produto publica seus painéis, e a raiz do Grafana os cria na pasta do produto, então o produto nunca tem uma credencial do Grafana.
Os relatórios de desvio não ficam aqui. O agendamento diário de cada repositório planeja suas raízes e mantém uma issue por raiz com desvio naquele repositório. Veja desvio.

Quem o muda, e como

As mudanças são merge requests aprovados pela equipe de plataforma, com a aprovação do controle obrigatória. Na main, cada raiz planeja, passa pelo pacote de políticas e aplica com sua própria identidade, com os tokens do Grafana lidos do Secret Manager na hora da execução.

Algumas partes do design ainda não foram construídas: os agentes de operações e de auditoria, as skills de agente com seu ambiente de testes, e o servidor MCP do catálogo estão previstos neste repositório e hoje não existem.

Seu custo permanente é de cerca de USD 7 por mês pela instância do agente de plataforma de não produção, um coletor Grafana Alloy das métricas da própria plataforma (um agente só no nome), mais centavos de armazenamento para a exportação de faturamento; os gateways vão a zero.

Onde fica

No repositório operations: