Exercícios Práticos¶

Esta seção apresenta exercícios práticos, cenários e laboratórios para consolidação dos conceitos apresentados ao longo do Knowledge Area 06. Os exercícios estão organizados por tópico e variam em complexidade desde questões conceituais até simulações de cenários reais.

Instruções Gerais¶

Como Usar Este Capítulo¶

1. Exercícios Individuais: Ideal para auto-estudo e avaliação de compreensão
2. Laboratórios: Requerem ambiente de prática (cloud sandbox, Kubernetes cluster, etc.)
3. Cenários: Podem ser usados em grupos de estudo ou workshops
4. Discussions: Provocam reflexão sobre trade-offs e decisões de design

Ambiente de Prática Recomendado¶

Para os laboratórios práticos, recomenda-se:

• Cloud: AWS Free Tier, GCP Free Tier, ou Azure Free Account
• Local: Minikube ou Kind para Kubernetes
• Ferramentas: Terraform, Docker, kubectl, helm
• Opcional: Conta no GitHub para CI/CD

Parte 1: Fundamentos e Conceitos¶

Exercício 1.1: SLIs, SLOs e Error Budgets¶

Contexto: Você é SRE para um serviço de pagamentos que processa 10 milhões de transações por dia. O serviço é crítico para o negócio.

Questões:

1. Defina 3 SLIs apropriados para este serviço. Justifique cada escolha.

2. Para cada SLI, proponha um SLO realista. Considere:

3. Qual a disponibilidade atual (assuma 99.5%)

4. Qual o custo de melhoria

5. Expectativas dos clientes

6. Calcule o error budget para cada SLO proposto:

7. Em uma janela de 30 dias

8. Em número absoluto de eventos permitidos

9. Se o serviço experimentar um incidente de 30 minutos de downtime:

10. Quanto error budget foi consumido?

11. Que ações você tomaria se isso ocorresse no dia 5 da janela?
12. E se ocorresse no dia 25?

Critérios de Avaliação:

• SLIs relevantes e mensuráveis
• SLOs balanceados (nem conservadores demais, nem agressivos)
• Cálculos matemáticos corretos
• Decisões justificadas

Exercício 1.2: Toil Analysis¶

Instruções:

1. Liste 5 atividades que você realiza regularmente em seu trabalho atual (ou imagine se estiver em transição de carreira)

2. Para cada atividade, avalie:

3. Frequência (diária, semanal, mensal)

4. Tempo gasto médio
5. Automatizabilidade (1-5, onde 5 = totalmente automatizável)
6. Valor estratégico (1-5, onde 5 = alto valor)

7. Toil score = (frequência × tempo × automatizabilidade) / valor

8. Priorize as atividades para automação usando a matriz Impacto vs. Esforço

9. Para a atividade de maior prioridade, esboce uma solução de automação (pode ser com ou sem IA)

Template:

Atividade: [Descrição]
Frequência: [X vezes/periodo]
Tempo médio: [Y minutos]
Automatizabilidade: [1-5]
Valor estratégico: [1-5]
Toil score: [Calculado]

Priorização: [Alta/Média/Baixa]

Solução proposta:
- Ferramentas: [...]
- Passos: [...]
- Expected ROI: [...]

Parte 2: CI/CD e DevOps¶

Laboratório 2.1: Pipeline CI/CD Moderno¶

Objetivo: Construir um pipeline CI/CD completo com práticas modernas.

Setup:

1. Crie um repositório Git com uma aplicação simples (pode ser um "Hello World" web app)

2. Configure um pipeline com as seguintes etapas:

3. Build

4. Testes unitários
5. Análise de segurança (SAST)
6. Build de container
7. Testes de integração
8. Deploy para staging
9. Testes de smoke
10. Deploy para produção (com approval)

Exercício:

1. Implemente o pipeline usando GitHub Actions, GitLab CI, ou ferramenta similar

2. Adicione as seguintes features:

3. Cache de dependências

4. Parallel test execution
5. Artifact storage

6. Rollback automático em caso de falha nos smoke tests

7. Documente o tempo de execução de cada etapa

8. Implemente uma estratégia de deployment (blue-green, canary, ou rolling)

Critérios de Sucesso:

• Pipeline executa de ponta a ponta
• Build time < 10 minutos
• Zero intervenção manual até staging
• Rollback funcional

Exercício 2.2: Métricas DORA¶

Cenário: Sua organização quer melhorar performance de entrega de software.

Tarefas:

1. Para cada métrica DORA, defina:
2. Como coletar a métrica em seu ambiente
3. Qual a classificação atual (Elite/High/Medium/Low)
4. Qual o target realista em 6 meses

1. Proponha 3 iniciativas para melhorar cada métrica de "Low" para "High"

2. Estime o esforço e impacto de cada iniciativa

3. Crie um roadmap de 6 meses priorizando as iniciativas

Parte 3: SRE e Confiabilidade¶

Laboratório 3.1: Implementação de SLOs¶

Objetivo: Implementar SLIs e SLOs para um serviço real ou simulado.

Setup:

1. Escolha um serviço para trabalhar (pode ser um serviço existente ou usar uma aplicação de exemplo)

2. Configure coleta de métricas usando Prometheus ou similar

Exercício:

1. Defina 3 SLIs para o serviço:

2. Disponibilidade

3. Latência

4. Taxa de erro

5. Implemente queries Prometheus para calcular cada SLI

# Exemplo estrutura
# SLI de Disponibilidade
sum(rate(http_requests_total{status=~"2..|3.."}[5m]))
/
sum(rate(http_requests_total[5m]))

1. Configure alertas baseados em SLOs (burn rate alerts)

2. Crie um dashboard Grafana mostrando:

3. SLI atual vs. SLO

4. Error budget consumption

5. Burn rate

6. Simule uma degradação e observe o alerta disparar

Entregáveis:

• Queries Prometheus documentadas
• Dashboard Grafana exportado
• Regras de alerta configuradas
• Documento explicando as escolhas

Cenário 3.2: Gerenciamento de Error Budget¶

Situação:

Seu serviço tem um SLO de 99.9% de disponibilidade (janela de 30 dias). No dia 15 da janela, você tem os seguintes dados:

• Tempo de indisponibilidade acumulado: 25 minutos
• 3 deploys realizados no período
• 2 incidentes, ambos relacionados a deploys
• Product team pressionando para novo feature

Questões:

1. Quanto error budget resta?

2. Calcule o burn rate atual:

3. Se continuar assim, qual a projeção para o final do mês?

4. O que indica sobre a saúde do serviço?

5. Que decisões você tomaria:

6. Sobre novos deploys?

7. Sobre o feature request?

8. Sobre investimento em confiabilidade?

9. Proponha um processo para gerenciar error budget em sua organização

Parte 4: Observabilidade¶

Laboratório 4.1: OpenTelemetry Instrumentação¶

Objetivo: Instrumentar uma aplicação com OpenTelemetry.

Setup:

1. Escolha uma linguagem de programação (Python, Node.js, Java, ou Go)

2. Prepare uma aplicação simples com:

3. API HTTP

4. Chamada a banco de dados
5. Chamada a serviço externo (mock)

Exercício:

1. Adicione instrumentação OpenTelemetry:

2. Traces automáticos

3. Traces manuais para operações críticas
4. Metrics customizadas

5. Logs estruturados correlacionados

6. Configure o OpenTelemetry Collector:

7. Recebedores (receivers)

8. Processadores (processors)

9. Exportadores para:

   • Jaeger (traces)
   • Prometheus (metrics)
   • Loki ou ELK (logs)

10. Implemente um fluxo de negócio e trace através de:

11. Múltiplos serviços (use containers)

12. Banco de dados
13. Cache

14. Fila de mensagens (opcional)

15. Crie um dashboard unificado mostrando:

16. Distributed trace completo

17. Métricas de negócio correlacionadas
18. Logs contextualizados

Entregáveis:

• Código instrumentado
• Configuração do Collector
• Screenshots de traces e dashboards
• Documentação de arquitetura

Exercício 4.2: Design de Dashboards¶

Contexto: Você precisa criar dashboards para um sistema de e-commerce.

Tarefas:

1. Identifique 4 personas que usarão os dashboards:

2. Exemplo: SRE on-call, Product Manager, Executivo, Developer

3. Para cada persona, defina:

4. 3 métricas principais (Golden Signals ou derivadas)

5. 3 métricas de negócio

6. Frequência de consulta esperada

7. Desenhe (papel ou ferramenta) um dashboard para cada persona

8. Justifique suas escolhas:

9. Por que essas métricas?

10. Por que essa organização visual?
11. Como o dashboard ajuda na tomada de decisão?

Critérios de Avaliação:

• Métricas relevantes para cada persona
• Clareza visual
• Ação associada às métricas
• Evitar "dashboard hell"

Parte 5: Infraestrutura como Código¶

Laboratório 5.1: Terraform End-to-End¶

Objetivo: Provisionar infraestrutura completa usando Terraform.

Setup:

Crie uma conta AWS/GCP/Azure (Free Tier) ou use LocalStack para simulação.

Exercício:

1. Crie um módulo Terraform para:

2. VPC com subnets públicas e privadas

3. Security groups
4. Application Load Balancer
5. ECS/EKS ou instâncias EC2
6. RDS (banco de dados)

7. S3 bucket

8. Implemente as seguintes práticas:

9. State remoto com locking

10. Workspaces para ambientes
11. Módulos reutilizáveis
12. Variables e outputs bem documentados

13. Tags consistentes

14. Adicione:

15. Pre-commit hooks (fmt, validate, lint)

16. CI/CD para Terraform (plan em PR, apply no merge)

17. Policy as Code (OPA ou Sentinel)

18. Implemente drift detection

Entregáveis:

• Repositório Git com código Terraform
• Documentação de arquitetura
• CI/CD pipeline
• Vídeo demo (opcional)

Exercício 5.2: Comparação de Ferramentas IaC¶

Tarefa de Pesquisa:

Compare as seguintes ferramentas de IaC:

1. Terraform
2. Pulumi
3. AWS CloudFormation
4. Ansible (para configuração)

Para cada ferramenta, avalie:

Discussão:

Em que cenários você escolheria cada ferramenta? Justifique.

Parte 6: Kubernetes e GitOps¶

Laboratório 6.1: GitOps com ArgoCD¶

Objetivo: Implementar GitOps para deployment contínuo.

Setup:

1. Instale um cluster Kubernetes (Minikube, Kind, ou cloud)

2. Instale ArgoCD

Exercício:

1. Configure:

2. Repositório Git como source of truth

3. Aplicação no ArgoCD
4. Auto-sync habilitado

5. Prune e self-heal ativados

6. Implemente:

7. Multi-environment (dev, staging, prod)

8. ApplicationSets para multi-tenant
9. Resource hooks (pre-sync, post-sync)

10. Notifications (Slack/email)

11. Teste:

12. Fazer push para Git e observar sync automático

13. Simular drift manualmente e verificar self-healing

14. Rollback para versão anterior

15. Adicione:

16. Progressive delivery (canary com Argo Rollouts)

17. Policy enforcement (Kyverno ou OPA)
18. Secrets management (External Secrets Operator)

Entregáveis:

• Manifestos Kubernetes
• Configuração ArgoCD
• Documentação do processo
• Screenshots de sync

Exercício 6.2: Estratégias de Deployment¶

Cenário:

Você precisa escolher uma estratégia de deployment para diferentes serviços:

Serviços:

1. Serviço de Pagamentos: Crítico, downtime é inaceitável
2. Serviço de Recomendações: Pode tolerar alguma instabilidade
3. Serviço de Batch Processing: Não tem usuários diretos
4. Serviço de Notificações: Alto volume, tolera atrasos

Tarefas:

1. Para cada serviço, recomende uma estratégia:

2. Blue-Green

3. Canary
4. Rolling Update

5. Recreate

6. Justifique sua escolha considerando:

7. Risco de rollback

8. Custo de infraestrutura
9. Complexidade de implementação

10. Impacto ao usuário

11. Desenhe a arquitetura para cada estratégia recomendada

12. Defina métricas para decisão de rollback em cada caso

Parte 7: AIOps e IA¶

Laboratório 7.1: Anomaly Detection Básico¶

Objetivo: Implementar detecção de anomalias simples.

Setup:

Use Python com bibliotecas: pandas, numpy, scikit-learn, matplotlib.

Exercício:

1. Colete ou gere dados de métricas:

2. 30 dias de CPU utilization

3. Injete 3-5 anomalias artificiais

4. Implemente 3 métodos de detecção:

5. Threshold estático (baseline)

6. Statistical (z-score, IQR)

7. ML simples (Isolation Forest)

8. Compare os métodos:

9. Precision e recall

10. False positive rate

11. Latência de detecção

12. Visualize:

13. Série temporal com anomalias marcadas

14. Comparação dos métodos

Entregáveis:

• Notebook Python
• Análise comparativa
• Recomendação de método

Exercício 7.2: Design de RCA Assistido por IA¶

Cenário:

Você está projetando um sistema de RCA assistido por LLM.

Tarefas:

1. Defina a arquitetura do sistema:

2. Quais fontes de dados?

3. Como estruturar o contexto?

4. Qual o fluxo de processamento?

5. Desenhe o prompt para o LLM:

6. System prompt

7. User prompt template

8. Expected output format

9. Identifique limitações e mitigações:

10. Context window

11. Hallucination
12. Latência

13. Custo

14. Defina um processo de validação humana

15. Proponha métricas de sucesso

Template de Entrega:

## Arquitetura
[Diagrama e descrição]

## Prompt Design
### System

[Prompt]

### User Template

[Template com variáveis]

## Limitações e Mitigações
| Limitação | Mitigação |
|-----------|-----------|
| [...] | [...] |

## Métricas de Sucesso
- [Métrica 1]: [Target]

Parte 8: FinOps¶

Laboratório 8.1: Análise de Custos Cloud¶

Objetivo: Analisar e otimizar custos de cloud.

Setup:

Use dados de billing export (CSV/JSON) ou simule dados.

Exercício:

1. Análise exploratória:

2. Top 5 serviços por custo

3. Evolução mensal
4. Distribuição por região

5. Crescimento month-over-month

6. Identifique waste:

7. Instâncias subutilizadas (CPU < 20%)

8. Recursos orfãos (volumes não atachados)
9. Storage não acessado

10. IPs elásticos não usados

11. Proponha otimizações:

12. Right-sizing

13. Reserved Instances
14. Spot instances

15. Storage tiering

16. Calcule:

17. Custo total atual

18. Custo projetado com otimizações
19. ROI do esforço

Entregáveis:

• Notebook de análise
• Relatório de recomendações
• Projeção de economia

Exercício 8.2: Estratégia de Tagging¶

Tarefa:

1. Desenhe um schema de tagging para uma organização com:

2. 3 ambientes (prod, staging, dev)

3. 5 times de produto
4. 3 regiões AWS

5. 2 business units

6. Defina:

7. Tags obrigatórias

8. Tags opcionais
9. Valores permitidos

10. Validações

11. Implemente (pseudo-código):

12. Política de tagging

13. Auto-tagging para novos recursos
14. Compliance check

15. Remediação automática

16. Projete um dashboard de alocação de custos

Parte 9: Gerenciamento de Incidentes¶

Cenário 9.1: Simulação de Incidente¶

Contexto:

Você é o Incident Commander para o seguinte incidente:

Hora: 14:32 UTC
Alerta: Error rate 50% no serviço de checkout
Impacto: Usuários não conseguem finalizar compras
Escopo: Produção, todas as regiões

Tarefas:

1. Escreva as primeiras comunicações:

2. Notificação inicial ao time

3. Status page update

4. Comunicação executiva

5. Desenhe a estrutura de comando:

6. Quem são os papéis?

7. Quem você escalonaria?

8. Defina as primeiras ações:

9. O que investigar primeiro?

10. Qual a mitigação imediata?

11. Crie uma timeline template para o incidente

12. Escreva o postmortem (fictício, mas realista)

Entregáveis:

• Comunicações escritas
• Diagrama de comando
• Timeline preenchida
• Postmortem completo

Exercício 9.2: Design de Runbook¶

Tarefa:

Escreva um runbook para o seguinte cenário:

"Database Connection Pool Exhaustion"

O runbook deve incluir:

1. Diagnóstico:

2. Como identificar o problema

3. Queries/comandos para confirmar

4. Dados a coletar

5. Mitigação Imediata:

6. Passos para reduzir impacto

7. Decisões de trade-off

8. Resolução:

9. Fix definitivo

10. Rollback plan

11. Prevenção:

12. Como evitar recorrência

13. Métricas a monitorar

14. Escalonamento:

15. Quando chamar ajuda

16. Quem contatar

Formato: Use markdown com checkboxes para execução.

Parte 10: Cenários Integrados¶

Cenário Final: Transformação Completa¶

Contexto:

Você foi contratado como VP of Platform Engineering para uma empresa de SaaS com 200 engenheiros:

Situação Atual:

• Deploys manuais, 2x por mês
• Operações heroicas, burnout comum
• Zero observabilidade unificada
• Custo de cloud crescendo 30% ao ano
• MTTR de 4+ horas
• Infraestrutura snowflake

Objetivo: Transformar operações em 18 meses.

Tarefas:

1. Assessment:

2. Avalie a maturidade atual usando o modelo SOM

3. Identifique os 3 maiores gargalos

4. Estabeleça baseline de métricas

5. Roadmap:

6. Crie roadmap de 18 meses

7. Defina milestones trimestrais

8. Aloque recursos necessários

9. Priorização:

10. Use framework RICE para priorizar

11. Justifique a sequência

12. Identifique quick wins

13. Gestão de Mudança:

14. Plano de comunicação

15. Estratégia de treinamento

16. Como lidar com resistência

17. Métricas de Sucesso:

18. KPIs para cada fase

19. Como comunicar progresso

20. Definição de sucesso

21. Riscos:

22. Top 5 riscos

23. Mitigações
24. Planos de contingência

Entregável:

Apresentação executiva (10-15 slides) cobrindo:

• Situação atual
• Visão futura
• Roadmap
• Investment ask
• Expected ROI

Gabaritos e Discussões¶

Discussões Importantes¶

Questões para Reflexão em Grupo:

1. Trade-offs de Automação: Até que ponto devemos automatizar? Quando um humano deve estar no loop?

2. Cultura vs. Ferramentas: Qual o mais importante para transformação de operações: mudar ferramentas ou mudar cultura?

3. IA na Operação: Você confiaria em um sistema autônomo para fazer deploy em produção? Sob quais condições?

4. SLOs Realistas: Como balancear ambição e realismo na definição de SLOs? O que acontece quando SLOs são muito agressivos? E muito conservadores?

5. FinOps vs. Agilidade: Como balancear otimização de custos com velocidade de desenvolvimento?

Recursos Adicionais¶

Projetos de Prática Recomendados¶

1. Homelab Kubernetes:

2. Monte um cluster em casa (Raspberry Pi ou VMs)

3. Implemente stack completo de observabilidade

4. Pratique GitOps e CI/CD

5. Cloud Challenge:

6. Complete AWS/GCP/Azure Well-Architected Labs

7. Implemente infraestrutura multi-region

8. Otimizações de custo e performance

9. Open Source Contribution:

10. Contribua para projetos de observabilidade

11. Documentação, bug fixes, features

Certificações Relevantes¶

• Cloud: AWS Solutions Architect, GCP Professional Cloud Architect
• Kubernetes: CKA, CKAD, CKS
• SRE: SRE Foundation (DevOps Institute)
• Security: AWS Security Specialty
• FinOps: FinOps Certified Practitioner

Conclusão¶

Estes exercícios cobrem o espectro de competências necessárias para operações de software modernas. A prática deliberada, combinada com estudo teórico, acelera o desenvolvimento de expertise.

Lembre-se: não é necessário completar todos os exercícios. Foque nos que endereçam lacunas em seu conhecimento ou são mais relevantes para sua situação atual.

Boa prática!