O caso
A correção de quarta-feira que ninguém viu. O erro começou no deploy, e só apareceu na sexta.
A loja do Isaac publicou uma nova versão do checkout numa quarta à tarde, feita à mão, sem teste automático. Nos dias seguintes, uma em cada vinte compras falhava no pagamento. Ninguém percebeu, porque nenhum alerta existia. Só na sexta, com as reclamações chegando pelo WhatsApp, a equipe descobriu o problema.
Este post parte de Google Cloud: o ponto de partida, que apresenta os serviços do Google Cloud. Também depende de Kubernetes e GKE e de Serverless e Cloud Run, porque é onde o software roda depois de entregue.
O problema
Entregar à mão é entregar no escuro
Quando cada deploy depende de um passo manual, a equipe erra de forma diferente a cada vez. E quando ninguém mede o sistema em produção, o primeiro a saber do problema é o cliente.
Entrega automatizada
Do código à produção, sem passo manual
A entrega automatizada (CI/CD) segue um caminho fixo: o código é testado, empacotado e levado para o ambiente de produção pelo mesmo processo, toda vez.
Build (Cloud Build)
Roda os testes e gera o artefato, como uma imagem de contêiner, a partir do código.
Armazenamento de artefatos (Artifact Registry)
Guarda as imagens e os pacotes gerados, com controle de versão, para que o mesmo artefato chegue a todos os ambientes.
Entrega contínua (Cloud Deploy)
Leva a mesma versão do ambiente de teste para o de produção, com aprovação quando a loja precisa dela.
No caso do Isaac, um pipeline teria rodado os testes de pagamento antes do deploy, e a versão só chegaria à produção depois deles.
Observabilidade
Saber o que acontece, antes do cliente reclamar
Observabilidade é a capacidade de entender o estado do sistema pelos dados que ele emite. No Google Cloud, a base é o Cloud Monitoring (métricas, painéis e alertas), o Cloud Logging (registros) e o Cloud Trace (o caminho de cada requisição entre serviços).
SRE
Confiabilidade medida, não prometida
A prática de SRE (Site Reliability Engineering) trata a confiabilidade como uma meta medida. A equipe define um SLO (service level objective), um objetivo mensurável, como "99,9% das compras concluídas sem erro no mês". Quanto o sistema pode falhar sem romper esse objetivo é o orçamento de erro (error budget).
Enquanto sobra orçamento, a equipe pode lançar novidades. Quando ele acaba, o foco volta para a estabilidade. Assim, a decisão de lançar ou de frear sai de um número, e não de uma discussão.
APIs
Expor serviços com controle
Uma API é a forma como um sistema oferece serviços a outros sistemas. Um gateway fica na entrada, e recebe as chamadas antes de elas chegarem ao serviço: ele verifica quem chama, limita o volume e registra cada uso.
| Serviço | Para quê | Quando faz sentido |
|---|---|---|
| API Gateway | Gateway gerenciado para serviços sem servidor | Uma API simples, em cima de funções ou do Cloud Run |
| Apigee | Gerenciamento completo de APIs | Muitas APIs, com planos de uso, portal para desenvolvedores e análise |
Na loja, a API que consulta o estoque pode ser exposta para os parceiros de entrega. O gateway limita cada parceiro a um número de chamadas por minuto, e o registro mostra quem usou o quê.
Termos-chave
Cinco termos para fixar
Toque no cartão para ver a definição.
Teste rápido
Três perguntas, estilo prova
01
O pipeline da loja gera uma imagem de contêiner a cada versão. Qual serviço guarda essas imagens para que cheguem iguais a todos os ambientes?
02
A equipe quer ser avisada quando a taxa de compras com erro passar de 1% por cinco minutos. Qual serviço faz isso?
03
No fim do mês, o orçamento de erro do checkout já foi consumido. Qual prática de SRE a equipe deve seguir?
Em qualquer prova de nuvem, a pergunta sobre operação costuma ser a mesma: como o software chega ao cliente, e como a equipe sabe que ele está funcionando. No Google Cloud, a resposta passa pela entrega automatizada, pelo monitoramento e pelas metas de SRE.