Observabilidade em escala na maior rede de cosméticos do mundo, o Grupo Boticário.

Como reduzimos o tempo de resposta e o impacto em nossas clientes dentro de um ambiente distribuído com mais de 2000 apps e mais de 1.000 pessoas de desenvolvimento ? O ambiente digital do Grupo Boticário é muito extenso e está em constante movimento.

Escala do desafio Grupo Boticário.

O primeiro passo para abordar observabilidade em escala foi estabelecer baselines de observabilidade e alertas. O ponto de partida inicial padronizado para todas as aplicações e infraestrutura. Garantir a mesma experiência em termos de observabilidade para todas as pessoas de tech e todas as stacks disponíveis dentro de GB.Tech.

Porque baselines de observabilidade e alertas ?

• Baselines definem o ponto de partida para observabilidade e alertas cloud para todas as aplicações e infra.
• Padronização e templates reaproveitáveis.
• Facilita a movimentação lateral de pessoas de tech dentro do Grupo Boticário.
• Habilita o trabalho em escala dentro de plataformas de monitoramento.
• Documentação extensa para apoio dos times.
• Aumentar o MTBF ( mean time between failure ).
• Reduzir o MTTA ( mean time to acknowledge ) e MTTR (mean time to recover)
• Facilita a adoção do modelo : You build you run it !
• Cobertura das principais métricas de performance de
  aplicações e infra-cloud.

Operational metrics.

Dada a escala do Grupo Boticário uma série de desafios foram levantados.

Principais desafios quanto a observabilidade em escala.

Uma das primeiras premissas era a horizontalidade de ambos baselines. Era necessário ser objetivo e simples o suficiente para funcionar em qualquer provedor cloud ou OnPrem.
Outra premissa era uma interface de configuração as code, simples, passiva de over rides de configuração e igual para qualquer ambiente de destino.

Multiple cloud providers, OnPrem and private cloud environments.

Outro ponto de atenção era a integração com nossa plataforma de desenvolvimento interna "Alquimia". Era necessário uma integração simples com a mesma que funciona em cima de uma stack open source: Backstage, ArgoCD, Crossplane e também do Github Actions.

Engine de automação para ambos os baselines construída em Typescript e executada via Github Actions. 100% integrada a plataforma interna de desenvolvimento e disponível também via MonoRepo de SRE que permite uma flexibilidade ainda maior.

Possibilidade de integração em 100% de nossos ambientes.

O fluxo de automação a partir de nossa plataforma interna de desenvolvimento ficou simplificado e foi possível integrar abrindo um simples PR na action já existente da plataforma adicionando uma requisição a nova action de configuração desenvolvida pelo time de SRE.

Uma visão macro dos steps envolvidos durante a configuração automática de ambos baselines :

1: trigger via push main or schedule
Todo o fluxo é iniciado a partir de um push na main branch do monorepo de SRE ou repos de aplicações provisionados via nossa plataforma interna.

2: parse infra.yaml
A partir do arquivo infra.yaml (provisionado com toda aplicação configurada usando nossa plataforma interna) nossa automação identifica qual a infra dedicada à aquela aplicação e configura as métricas e alertas de acordo garantindo sempre o mesmo padrão entre apps e infraestrutura. Por exemplo: Uma api de backend com RDS + Elasticache seria identificada como tal e todas as métricas de baselines para cada recurso de infra e o seu ambiente de execução ( K8s / Serverless ) seriam automaticamente configurados. Ao adicionar um componente ( ex : uma fila ) ou remover um componente ( ex: cache ) automaticamente é atualizado em seu destino de monitoramento e alertas para refletir o estado declaro.

Exemplo prático de um arquivo infra.yaml provisionado via nossa plataforma interna definindo um DynamoDB, Redis e SNS dedicados ao serviço em questão. Na prática isso significa que o conjunto de métricas de observabilidade e acionáveis ( alertas ) serão automaticamente configurados. Uma atualização nesse arquivo reflete na configuração dos baselines.

3: load vars
Nossa automação consulta nossa api de domínios interna em busca dos valores de variáveis de ambiente de acordo com sua VS e ambiente.

4: load templates
A partir de uma requisição à api de SRE os templates de configuração são entregues de volta a nossa automação.

5: render templates
Os Templates de configuração são renderizados durante o runtime da automação e uma requisição POST de configuração é efetuada a api da stack de observabilidade desejada.

Já a partir do monorepo de SRE é possível criar novos baselines ou templates 100% personalizados para monitoramento e alertas. Sempre utilizando a mesma interface yaml de configuração e todo funcionamento automatizado seguindo o modelo de GitOps.

Garantimos assim a simplicidade com 1 click a partir de nossa plataforma interna ou 100% de flexibilidade as code dentro do monorepo de SRE e assim é possível atender a todas as demandas de observabilidade.

Golden Signals + Logs K8s App

Transaction Details K8s app

Relational Database Observability Baseline

K8s metrics

Os resultados até agora são expressivos :

• 2.000+ Dashboards provisionados , facilitando a adoção em massa de uma observabilidade padronizada.
• 100% das aplicações provisionadas via plataforma interna automaticamente integradas a ambos os baselines, toda aplicação é configurada com suas métricas e alertas.
• Engine de automação para ambos baselines interna e disponível para uso em 100% de nosso ambiente digital, é possível usufluir de maneira abstrata, simples e ágil via nossa plataforma interna ou customizar conforme necessário utilizando o monorepo de SRE.
• Dissiminação da cultura de monitoramento, alertas e respostas a incidentes.
• Construção de OKR focados em melhoria operacional. Ex: redução do nosso tempo médio de MTTA.
• Visibilidade e alertas padronizados com documentação de apoio aos times disponível.