Conceitos
Canary, blue/green e rollback
Intuição
Antes de servir um prato novo a todas as mesas do restaurante, o cozinheiro manda uma porção só para algumas mesas e observa se alguém passa mal. Se der problema, só poucos clientes foram afetados e o prato volta para a cozinha; se der certo, ele passa a servir todo mundo. Lançar uma nova versão de um software funciona do mesmo jeito: testar com uma parte pequena dos usuários limita o estrago de um defeito escondido.
Como funciona
O capítulo parte da observação de que, na experiência do Google, a maioria dos incidentes vem de pushes de binário ou de configuração, e de que testes não cobrem tudo, então alguns defeitos só aparecem com tráfego real de produção. Canarying é um deploy parcial e limitado no tempo de uma mudança, junto com sua avaliação: a parte que recebe a mudança é o canary, o restante é o controle, e comparar os dois lembra um teste A/B. O impacto no error budget é proporcional ao tráfego exposto ao defeito, supondo que detecção e rollback levem tempo parecido com e sem canary; no exemplo do capítulo, uma falha em 20% das requisições vira cerca de 1% de erro geral com um canary de 5% (modelo simples, que assume carga uniforme e falha de 100% no pior caso). Tamanho e duração do canary precisam ser suficientes para representar o deploy como um todo: depende da homogeneidade e do volume de tráfego, do horário (defeitos de desempenho costumam aparecer só sob carga alta) e da cadência de releases, e o capítulo recomenda um canary por vez. As métricas devem refletir problemas percebidos pelo usuário, partindo dos SLIs, ser poucas (talvez no máximo uma dúzia) e atribuíveis à mudança; um critério rígido demais gera falsos positivos e um frouxo demais aumenta a chance de um canary ruim passar sem detecção; métricas sem essas propriedades ainda podem ser úteis num canary gradual em estágios, com um primeiro estágio pequeno avaliado pelas métricas mais claras, como crashes e falhas de requisição, e estágios seguintes maiores. A avaliação precisa estar ligada ao processo de release: se a taxa de erro do canary se afastar demais da do controle, o rollout pausa e reverte ou chama uma pessoa; se forem parecidas, segue. Isso exige monitoramento separado por versão, pois o erro de 1% no agregado pode se confundir com outras fontes, e janelas de métrica iguais ou menores que a duração do canary; e, como canary e controle podem compartilhar backends, um resultado ruim não culpa necessariamente o canary, e um canary ruim pode afetar o controle, por isso convém usar também medidas absolutas, como os SLOs. O capítulo descreve ainda o blue/green como duas instâncias em que o rollback é reverter a mudança no roteador, ao custo de o dobro de recursos, equivalente a um canary antes/depois e próximo de um canary A/B se o tráfego for dividido entre as duas.
Na prática
Na prática, o canary vira uma etapa integrada ao pipeline de release: um subconjunto pequeno recebe a nova versão, a comparação com o controle decide entre seguir o rollout e pausar e reverter ou chamar uma pessoa, e um canary gradual em estágios (um primeiro pequeno, com as métricas mais claras, como crashes e falhas de requisição, e depois maiores) permite usar também métricas menos ideais. O capítulo trata o blue/green como um conceito próximo: o rollback é só reverter a mudança no roteador, ao custo de manter o dobro de recursos, e, com o tráfego dividido entre as duas instâncias, ele se aproxima de um canary A/B. No canary, como canary e controle podem compartilhar backends, convém conferir também medidas absolutas, como os SLOs.
Use em um desenho
Pratique na escola de System Design os casos que dependem deste conceito.