Guia

Impor proteções preventivas em toda uma organização, como restringir localizações de recursos ou desabilitar a criação de chaves de conta de serviço.

→Aplicar restrições da Política da Organização (Organization Policy constraints) (ex: `constraints/gcp.resourceLocations`, `constraints/iam.disableServiceAccountKeyCreation`) no nível da organização ou da pasta.

Por quê: As Políticas da Organização são herdadas e aplicadas no nível da API, prevenindo ações não-compatíveis antes que ocorram. Isso é mais eficaz do que a detecção e remediação reativas.

Referência↗

Estruturar uma organização multi-departamental e multi-ambiente para gerenciar políticas e controle de acesso de forma eficaz.

→Projetar uma hierarquia de pastas, tipicamente: Organização > Unidade de Negócios (Pasta) > Ambiente (ex: prod, staging) (Subpasta) > Projetos.

Por quê: Esta estrutura permite a herança granular de políticas. Políticas comuns são definidas no nível da Unidade de Negócios (BU), enquanto políticas específicas do ambiente (ex: mais restritivas para `prod`) são definidas no nível do ambiente.

Agregar logs de todos os projetos para conformidade, análise de segurança e solução de problemas operacionais com otimização de custos.

→Criar um coletor de logs agregado (aggregated log sink) em nível de organização. Direcionar logs para múltiplos destinos com base na necessidade: BigQuery para análise, Cloud Storage (Coldline/Archive) para arquivamento de longo prazo/baixo custo, e Pub/Sub para streaming em tempo real para um SIEM.

Por quê: Esta abordagem em camadas otimiza tanto o custo quanto a capacidade. O BigQuery oferece consultas poderosas, enquanto o Cloud Storage oferece arquivamento barato. Usar um único destino é muito caro ou não tem desempenho suficiente para todos os casos de uso.

Referência↗

Prevenir a exfiltração de dados de serviços gerenciados como BigQuery e Cloud Storage, permitindo acesso apenas de redes ou identidades autorizadas.

→Criar um perímetro de VPC Service Controls em torno de projetos que contêm dados sensíveis. Definir níveis de acesso para permitir acesso de faixas de IP específicas (rede corporativa) ou dispositivos.

Por quê: VPC Service Controls cria um perímetro virtual em torno de serviços baseados em API, mitigando riscos de credenciais roubadas ou políticas IAM mal configuradas ao bloquear o acesso de fora do perímetro.

Estabelecer proteções de segurança que não podem ser sobrescritas pelos proprietários do projeto, como impedir que uma função específica seja concedida.

→Implementar políticas IAM Deny no nível da organização ou da pasta. Essas políticas negam permissões explicitamente e sempre substituem quaisquer políticas de `allow`.

Por quê: As políticas Deny fornecem uma maneira poderosa de aplicar controles de segurança em toda a organização que não podem ser ignorados em níveis inferiores da hierarquia de recursos, garantindo uma postura de segurança consistente.

Garantir que todos os novos projetos sejam provisionados com uma configuração de linha de base padrão (rede, IAM, logging, etc.).

→Usar Infrastructure as Code (ex: Terraform com Cloud Build) para criar uma "landing zone". Automatizar a criação e configuração de projetos via pipeline.

Por quê: A automação garante consistência, reduz erros manuais e acelera o provisionamento de projetos. Ela codifica as melhores práticas, tornando a governança auditável e repetível.

Permitir que sistemas externos (como GitHub Actions ou CI/CD on-prem) acessem recursos do GCP sem usar chaves de conta de serviço de longa duração.

→Configurar Workload Identity Federation. Criar um provedor que confia no IdP externo (ex: GitHub OIDC) e mapear identidades externas para uma conta de serviço do GCP. Usar condições de atributo para restringir o acesso a repositórios/branches específicos.

Por quê: Isso elimina a necessidade de gerenciar e rotacionar chaves de conta de serviço, o que é um grande risco de segurança. Ele fornece credenciais de curta duração baseadas em identidade.

Centralizar a administração de rede (VPCs, subnets, firewalls) enquanto permite que equipes separadas gerenciem seus próprios recursos de projeto.

→Implementar Shared VPC. Criar um "projeto host" para recursos de rede e "projetos de serviço" para cargas de trabalho de aplicação. Conceder `roles/compute.networkUser` às identidades do projeto de serviço.

Por quê: Shared VPC desacopla a administração de rede da administração de projetos, fornecendo controle centralizado e segurança enquanto dá autonomia às equipes. Ele escala melhor e é mais seguro do que VPC Peering para este caso de uso.

Gerenciar configurações de cluster GKE e aplicações declarativamente a partir de um repositório Git.

→Usar um repositório Git como a única fonte de verdade para manifestos. Instalar o Config Sync nos clusters GKE para reconciliar continuamente o estado do cluster com a configuração no repositório.

Por quê: GitOps fornece uma maneira auditável, versionada e automatizada de gerenciar Kubernetes. Ele separa o CI (construção de artefatos) do CD (sincronização de estado).

Impedir que imagens de container com vulnerabilidades críticas sejam implantadas.

→Habilitar a varredura automática de vulnerabilidades no Artifact Registry. No pipeline do Cloud Build, adicionar uma etapa que usa a API Container Analysis para verificar vulnerabilidades e falhar a build se problemas críticos forem encontrados.

Por quê: Isso cria um portão de qualidade automatizado no pipeline de CI, impedindo que artefatos vulneráveis cheguem a um estado implantável. Ele move a segurança para a esquerda (shifts security left).

Impor em tempo de execução que apenas imagens de container confiáveis e assinadas podem ser implantadas no GKE ou Cloud Run.

→Implementar Binary Authorization. Criar atestadores (ex: para passar em varreduras de vulnerabilidade, aprovação de QA). Configurar o pipeline de CI para criar atestações. Aplicar uma política no GKE/Cloud Run que exige atestações específicas para implantação.

Por quê: Binary Authorization oferece uma aplicação forte e baseada em políticas no momento da implantação. Ele protege contra a implantação de imagens comprometidas ou não verificadas, mesmo que cheguem ao registro.

Referência↗

Acessar informações sensíveis como chaves de API ou senhas durante uma execução do Cloud Build sem expô-las em logs ou código-fonte.

→Armazenar segredos no Secret Manager. No `cloudbuild.yaml`, usar o campo `availableSecrets` para montar o segredo como uma variável de ambiente ou arquivo.

Por quê: Esta é a integração nativa e segura. O Cloud Build lida com a autenticação e automaticamente redige os valores do segredo dos logs, prevenindo exposição acidental.

Estabelecer uma cadeia de custódia verificável para artefatos de software para garantir que foram construídos por um sistema confiável a partir de código-fonte confiável.

→Usar o Cloud Build para gerar atestações de proveniência compatíveis com SLSA. Armazenar essas atestações no Artifact Registry junto com as imagens. Usar Binary Authorization para verificar a proveniência antes da implantação.

Por quê: SLSA fornece uma estrutura para fortalecer a cadeia de suprimentos de software. Esta combinação de ferramentas fornece uma cadeia de confiança ponta a ponta e verificável, do código-fonte à produção.

Executar jobs de CI/CD que precisam acessar recursos em uma VPC privada, como um Artifact Registry privado ou um banco de dados Cloud SQL.

→Criar um pool privado do Cloud Build e configurar o VPC peering entre a rede do pool e sua VPC de destino. Configurar builds para rodar neste pool.

Por quê: Pools privados fornecem isolamento de rede e permitem que as builds acessem recursos com segurança em uma rede privada sem expô-los à internet.

Excluir automaticamente imagens de container antigas ou não utilizadas para gerenciar custos de armazenamento enquanto retém imagens importantes.

→Configurar políticas de limpeza do Artifact Registry. Usar uma política de `keep` para tags como `production` e `latest`. Usar políticas de `delete` baseadas em idade, padrões de tag e contagem de versões para outras imagens.

Por quê: As políticas de limpeza fornecem uma maneira declarativa e automatizada de gerenciar o ciclo de vida da imagem, equilibrando a economia de custos com a necessidade de reter artefatos de produção e desenvolvimento recentes.

Automatizar uma implantação multi-estágio de dev para staging para produção com aprovações e diferentes estratégias por ambiente.

→Definir um pipeline de entrega único do Cloud Deploy com uma progressão de destinos (dev, staging, prod). Configurar `requireApproval: true` para o destino de produção e especificar diferentes estratégias de implantação (ex: canary) para cada destino.

Por quê: Cloud Deploy fornece um serviço de entrega contínua gerenciado e auditável. Ele simplifica padrões de entrega progressiva como implantações canary e blue-green com aprovações e rollbacks integrados.

Definir métricas para medir a confiabilidade de um serviço da perspectiva do usuário.

→Definir Indicadores de Nível de Serviço (SLIs) baseados em preocupações voltadas para o usuário: disponibilidade (percentual de requisições bem-sucedidas), latência (percentual de requisições mais rápidas que um limite) e correção/atualização (percentual de dados processados corretamente ou que estão atualizados).

Por quê: SLIs devem medir a satisfação do usuário, não a saúde interna do servidor. Métricas como utilização da CPU são causas, enquanto alta latência é um sintoma. SRE foca em monitorar e gerenciar sintomas.

Ser notificado de violações de SLO cedo o suficiente para reagir, sem ser inundado por alertas para problemas menores e transitórios.

→Configurar alertas baseados na taxa de consumo do orçamento de erro (burn rate) (a velocidade com que o orçamento de erro está sendo consumido). Usar alertas de múltiplas janelas: uma alta taxa de consumo em uma janela curta para páginas críticas, e uma taxa de consumo mais baixa em uma janela longa para tickets não urgentes.

Por quê: O alerta de taxa de consumo é preditivo. Ele alerta sobre a *taxa* de falha, o que indica um problema real, em vez de uma única requisição falha, reduzindo a fadiga de alerta e focando no que importa.

Referência↗

Diagnosticar problemas de latência em uma arquitetura de microsserviços, compreendendo o ciclo de vida completo de uma requisição.

→Instrumentar serviços com SDKs do OpenTelemetry e exportar traces para o Cloud Trace. Garantir que o contexto do trace seja propagado entre as chamadas de serviço (incluindo através de filas de mensagens como Pub/Sub).

Por quê: OpenTelemetry fornece um padrão agnóstico de fornecedor para instrumentação. O Cloud Trace visualiza o fluxo de requisição ponta a ponta, tornando fácil identificar qual serviço ou operação é o gargalo.

Garantir que os logs de aplicação no GKE sejam corretamente analisados, pesquisáveis e tenham o nível de severidade adequado no Cloud Logging.

→Configurar aplicações para escrever logs para `stdout`/`stderr` em formato JSON. Incluir um campo `severity` que corresponda aos valores esperados do Google Cloud (ex: "INFO", "ERROR").

Por quê: O agente de logging padrão do GKE coleta e analisa automaticamente logs JSON do stdout, tornando-os estruturados e pesquisáveis no Cloud Logging sem a necessidade de um sidecar ou agente customizado.

Monitorar, visualizar e alertar sobre a conformidade de SLO e o consumo do orçamento de erro para um serviço.

→Usar o recurso de Monitoramento de Serviço (Service Monitoring) do Cloud Monitoring. Definir um serviço, criar SLIs (ex: disponibilidade de um balanceador de carga), definir metas de SLO e configurar políticas de alerta de taxa de consumo (burn rate).

Por quê: Este recurso nativo automatiza os cálculos complexos de conformidade de SLO e orçamentos de erro, fornece dashboards prontos para uso e integra-se ao sistema de alertas.

Encontrar rapidamente a causa raiz de um problema, correlacionando métricas, traces e logs.

→Garantir que os IDs de trace sejam incluídos em logs estruturados. Usar recursos do Cloud Monitoring como exemplares de trace em gráficos de métricas para pular para um trace específico durante uma anomalia de métrica e, a partir desse trace, pular para os logs correlacionados.

Por quê: A capacidade de alternar perfeitamente entre os três pilares da observabilidade (métricas, logs, traces) é fundamental para reduzir o Mean Time to Resolution (MTTR).

Criar métricas e alertas personalizados para eventos específicos de aplicação que estão disponíveis apenas em dados de log, como cadastros de usuários ou falhas de pagamento.

→No Cloud Logging, criar uma métrica baseada em log. Definir um filtro para corresponder às entradas de log relevantes e configurar o tipo de métrica (contador ou distribuição). Usar esta métrica personalizada em dashboards e políticas de alerta.

Por quê: Métricas baseadas em log permitem transformar dados de log não estruturados ou semi-estruturados em dados de série temporal estruturados, facilitando o monitoramento e o alerta sobre KPIs de nível de negócio sem alterar o código da aplicação.

Diagnosticar problemas de desempenho de banco de dados, como consultas lentas, sem adicionar carga ao banco de dados.

→Habilitar Cloud SQL Insights e Query Insights na instância do Cloud SQL. Usar o dashboard para identificar consultas de alta carga, analisar planos de execução e ver tendências de desempenho.

Por quê: Query Insights fornece monitoramento de desempenho de consulta leve e sem agente. Ele ajuda DBAs e desenvolvedores a identificar consultas ineficientes sem a sobrecarga de ferramentas de profiling tradicionais.

Monitorar proativamente jornadas críticas de usuário ou disponibilidade de API de uma perspectiva externa.

→Usar verificações de tempo de atividade (uptime checks) do Cloud Monitoring para verificações simples de HTTP/TCP. Para fluxos de usuário multi-etapas (ex: login, adicionar ao carrinho, checkout), usar Synthetic Monitors, que executam scripts personalizados (ex: Puppeteer) em um ambiente gerenciado.

Por quê: O monitoramento sintético simula interações reais do usuário, permitindo detectar problemas antes que os usuários o façam. Ele testa toda a pilha de fora para dentro.

Equilibrar a necessidade de confiabilidade do serviço com a necessidade de lançar novas funcionalidades.

→Definir um Objetivo de Nível de Serviço (SLO) (ex: 99,9% de disponibilidade). Os 0,1% restantes são o orçamento de erro. Se o orçamento estiver em grande parte intacto, lançar funcionalidades. Se o orçamento estiver esgotado, interromper os lançamentos de funcionalidades e focar em melhorias de confiabilidade.

Por quê: O orçamento de erro fornece uma estrutura baseada em dados para tomar decisões de risco, alinhando equipes de engenharia, produto e negócios em um objetivo comum.

Aprender com incidentes para evitar que eles recorram, ao mesmo tempo em que se fomenta uma cultura de segurança psicológica.

→Conduzir post-mortems sem culpa (blameless postmortems) após incidentes. Focar a investigação em fatores sistêmicos, lacunas de processo e falhas de ferramentas, e não em atribuir culpa a indivíduos. O resultado deve ser uma lista de itens de melhoria acionáveis.

Por quê: Uma cultura sem culpa incentiva a comunicação honesta e aberta, levando a uma compreensão mais precisa das causas-raiz de um incidente e a ações preventivas mais eficazes.

Coordenar a resposta a um incidente grave de forma eficaz, evitando confusão e esforço duplicado.

→Implementar um Sistema de Comando de Incidentes (ICS) com funções claramente definidas: Comandante do Incidente (coordenação geral), Líder de Operações (investigação técnica/correção) e Líder de Comunicações (atualizações para stakeholders).

Por quê: O ICS fornece uma estrutura padronizada e escalável para resposta a incidentes, garantindo linhas claras de autoridade e comunicação, o que é crucial para resolver problemas complexos rapidamente.

Medir o desempenho de uma organização de entrega de software.

→Acompanhar as quatro principais métricas DORA: Frequência de Implantação (com que frequência), Tempo de Lead para Alterações (quão rápido do commit à implantação), Taxa de Falha de Alteração (qual percentual das implantações causa falha) e Tempo para Restaurar o Serviço (MTTR).

Por quê: Essas quatro métricas fornecem uma visão equilibrada tanto da velocidade de desenvolvimento quanto da estabilidade operacional, e provaram correlacionar-se com organizações de alto desempenho.

Uma equipe SRE está gastando muito tempo em tarefas operacionais manuais e repetitivas (toil), não deixando tempo para projetos de engenharia.

→Identificar e quantificar o "toil" mais demorado. Priorizar e automatizar essas tarefas (ex: implementar autoscaling em vez de escalonamento manual, auto-remediação para alertas comuns). Limitar o "toil" a < 50% do tempo do engenheiro.

Por quê: "Toil" é um fardo para a produtividade e o moral. Reduzir sistematicamente através da automação libera os engenheiros para trabalhar em melhorias de confiabilidade de longo prazo.

Atribuir custos de nuvem com precisão a diferentes equipes, serviços ou ambientes em uma infraestrutura compartilhada.

→Implementar uma estratégia consistente de rotulagem/tagging. Usar esses rótulos para filtrar em relatórios do Cloud Billing. Para GKE, habilitar a alocação de custos do GKE para detalhar os custos por namespace ou carga de trabalho.

Por quê: A alocação de custos precisa proporciona visibilidade, o que impulsiona a responsabilização. Equipes que podem ver seus gastos são capacitadas a otimizá-los.

Otimizar custos de computação para um conjunto diversificado de cargas de trabalho (estáveis, interrompíveis, dev/test).

→Correlacionar a carga de trabalho com o modelo de precificação. Usar Committed Use Discounts (CUDs) para cargas de trabalho estáveis, 24/7. Usar Spot VMs para jobs tolerantes a falhas e interrompíveis (ex: processamento em lote). Agendar ambientes de dev/test para desligar fora do horário comercial.

Por quê: Uma abordagem de precificação de computação "tamanho único" é ineficiente. Usar a ferramenta certa para o trabalho pode levar a economias significativas (>70%) sem impactar o desempenho.

Otimizar custos e desempenho do GKE garantindo que os pods estejam solicitando quantidades apropriadas de CPU e memória.

→Implantar o Vertical Pod Autoscaler (VPA) no modo `recommendation`. Analisar suas sugestões para ajustar os `requests` de recursos dos pods. Uma vez confiante, mudar para o modo `auto` para dimensionamento contínuo.

Por quê: O provisionamento excessivo de pods desperdiça dinheiro, enquanto o provisionamento insuficiente causa problemas de desempenho (throttling, OOMKilled). O VPA usa dados de uso reais para fazer recomendações precisas de dimensionamento, melhorando tanto a eficiência quanto a estabilidade.

Reduzir a latência causada por "cold starts" para um serviço do Cloud Run.

→Configurar um valor `min-instances` para manter um número de instâncias "quentes". Além disso, otimizar a imagem do container (imagem base menor, menos camadas) e o código de inicialização da aplicação (inicialização preguiçosa).

Por quê: `min-instances` é a forma mais direta de reduzir "cold starts", mas tem um custo. Combiná-lo com a otimização de container e código oferece uma abordagem equilibrada para desempenho e custo.

Otimizar custos para uma carga de trabalho de análise BigQuery em grande escala com padrões de consulta variáveis.

→Mudar do preço sob demanda para BigQuery Editions (slots). Comprar um compromisso de slot de linha de base para carga previsível e habilitar autoscaling para picos. Além disso, otimizar consultas usando tabelas particionadas/clusterizadas e evitando `SELECT *`.

Por quê: Para cargas de trabalho consistentes, o preço baseado em slots é mais econômico do que o sob demanda. O autoscaling oferece flexibilidade para picos enquanto controla os custos. A otimização de consultas e tabelas reduz a quantidade de dados processados, diminuindo diretamente os custos.

Reduzir altos custos de saída de rede (network egress) para uma aplicação distribuída globalmente.

→Usar Cloud CDN para armazenar em cache conteúdo estático na borda, mais próximo dos usuários. Para tráfego dinâmico, escolher o Nível de Serviço de Rede apropriado (Premium para desempenho, Standard para economia de custos). Processar dados regionalmente para minimizar o tráfego entre regiões.

Por quê: A saída de rede (Egress) é um grande fator de custo. O CDN descarrega o tráfego da origem, reduzindo diretamente a saída. O uso cuidadoso dos níveis de rede e o processamento de dados regional podem reduzir significativamente os custos.