<p><strong>Meta Description:</strong> Aprenda Chaos Engineering: princípios, ferramentas (Chaos Monkey, Gremlin), inject faults deliberadamente e garantir resiliência do sistema.</p>

<hr>
<h2>O Que é Chaos Engineering?</h2>

<p>Chaos Engineering é a prática de injectar falhas deliberadamente em sistemas para testar resiliência e descobrir vulnerabilidades antes que elas causem problemas em produção.</p>

<h3>Princípios</h3>
<ol><li><strong>Hipótese primeiro</strong>: Defina o que você quer testar</li>
<li><strong>Comece pequeno</strong>: Aumente gradualmente</li>
<li><strong>Máximo impacto, mínimo dano</strong>: Controle o blast radius</li>
<li><strong>Monitore sempre</strong>: Observe métricas durante experimentos</li>
<li><strong>Automação</strong>: Execute experimentos continuamente</li>
</ol>
<hr>
<h2>Prática de Chaos Engineering</h2>

<h3>Ciclo de Experimentos</h3>

<pre><code>┌─────────────────────────────────────┐
│                                     │
│  1. Define Hipótese                 │
│     "O sistema funciona se DB cair"  │
│                                     │
│  2. Planeja Experimento             │
│     "DB node mata por 60s"          │
│                                     │
│  3. Executa em Prod-like            │
│     "Staging environment"           │
│                                     │
│  4. Observa Métricas                │
│     "Taxa de erro aumenta?"          │
│                                     │
│  5. Analisa Resultados              │
│     "Sistema degradou graciosamente"│
│                                     │
│  6. Melhora Sistema                 │
│     "Adicionar circuit breaker"      │
│                                     │
└─────────────────────────────────────┘
</code></pre>

<h3>Hipóteses de Teste</h3>

<pre><code># Hipóteses de Chaos Engineering

<h2>1. Alta Disponibilidade</h2>
Hipótese: "Se um node da API morrer, o sistema continuará funcionando"
Experimento: Matar 1 instance de API
Métricas: Throughput, error rate, latency
Resultado Esperado: Throughput cai 20{6727d158e4474b0847515bd23a8ee4bebd5f1aac7a18bc968e51d8985dccb442}, mas sem erros 5xx

<h2>2. Database Resilience</h2>
Hipótese: "Se o banco primário ficar indisponível, failover ocurrerrá automaticamente"
Experimento: Matar database primary
Métricas: Time to failover, error rate
Resultado Esperado: Failover em &lt;60s, erros apenas durante transição

<h2>3. Network Partition</h2>
Hipótese: "Se rede entre serviços degrada, retry logic funcionará"
Experimento: Adicionar latência de 500ms
Métricas: Retry count, timeout rate
Resultado Esperado: Retries com backoff, nenhum erro usuário final

<h2>4. Memory Leak</h2>
Hipótese: "Se memory leak ocurrer, sistema reiniciará corretamente"
Experimento: Simular leak por alocar memória
Métricas: Memory usage, restart count
Resultado Esperado: Service restart gracefully
</code></pre>

<hr>
<h2>Ferramentas</h2>

<h3>Chaos Monkey</h3>

<pre><code># Instalação
brew install chaos-monkey
# ou
docker pull chaosmonkey/chaos-monkey

<p># Configuração (chaos-monkey.json)<br>{<br>  "enabled": true,<br>  "runScheme": "fixed",<br>  "startTime": "08:00",<br>  "endTime": "20:00",<br>  "daysOfWeek": ["monday", "tuesday", "wednesday", "thursday", "friday"],<br>  "kind": "exp-random",<br>  "services": [<br>    {<br>      "name": "api-service",<br>      "probability": 30,<br>      "attacks": ["kill-container"]<br>    },<br>    {<br>      "name": "payment-service",<br>      "probability": 50,<br>      "attacks": ["network-latency"]<br>    }<br>  ]<br>}</p>

<p># Executar<br>chaos-monkey run --config chaos-monkey.json<br></code></pre></p>

<h3>Gremlin</h3>

<pre><code># CLI Installation
curl - https://www.gremlin.com/gremlin-cli.tar.gz | tar -xz
sudo mv gremlin /usr/local/bin/

<p># Initialize<br>gremlin init --teamid YOUR_TEAM_ID --secret YOUR_SECRET</p>

<p># Attack Examples</p>

<p># 1. CPU Attack<br>gremlin attack cpu --length 60 --percent 100</p>

<p># 2. Memory Attack<br>gremlin attack memory --length 60 --percent 50</p>

<p># 3. IO Attack<br>gremlin attack io --length 60 --percent 100</p>

<p># 4. Network Attack<br>gremlin attack network --delay 500 --loss 10 --percent 50</p>

<p># 5. Process Kill<br>gremlin attack process --process-name nginx</p>

<p># 6. DNS Attack<br>gremlin attack dns --hostname api.example.com --ip 127.0.0.1<br></code></pre></p>

<h3>LitmusChaos (Kubernetes)</h3>

<pre><code># Pod Delete Experiment
apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: pod-delete-chaos
  namespace: litmus
spec:
  appinfo:
    appns: production
    applabel: "app=api"
  chaosServiceAccount: litmus-admin
  experiments:
    - name: pod-delete
      spec:
        components:
          env:
            - name: TOTAL_CHAOS_DURATION
              value: '30'
            - name: CHAOS_INTERVAL
              value: '10'
            - name: FORCE
              value: 'false'
</code></pre>

<hr>
<h2>Exemplos de Experimentos</h2>

<h3>1. API Latency Injection</h3>

<pre><code># Testando timeout e retry
import requests
import time
import random

<p>def test_api_resilience():<br>    """<br>    Hipótese: API cliente deve ter timeout e retry configurados<br>    """<br>    base_url = "http://api-service:8080"<br>    timeouts = 0<br>    successes = 0<br>    retries = 0</p>

<p>for i in range(100):<br>        try:<br>            response = requests.get(<br>                f"{base_url}/data",<br>                timeout=5,<br>                headers={"X-Client-Id": f"test-{i}"}<br>            )<br>            if response.status_code == 200:<br>                successes += 1<br>        except requests.Timeout:<br>            timeouts += 1<br>        except requests.ConnectionError:<br>            retries += 1</p>

<p># Assertions<br>    assert successes &gt;= 90, f"Only {successes}{6727d158e4474b0847515bd23a8ee4bebd5f1aac7a18bc968e51d8985dccb442} success rate"<br>    assert timeouts &lt;= 5, f&quot;Too many timeouts: {timeouts}&quot;<br></code></pre></p>

<h3>2. Database Failover</h3>

<pre><code># Teste manual de failover
# 1. Identificar primary
psql -h db-cluster -c "SELECT pg_is_in_recovery();"

<p># 2. Simular failure no primary<br># (Em produção, usar orquestrador)</p>

<p># 3. Verificar failover<br>psql -h db-cluster -c "SELECT pg_is_in_recovery();"<br># Deve retornar 't' no novo primary</p>

<p># 4. Verificar aplicação<br>curl http://api-service:8080/health<br># Deve estar healthy após breve degradation<br></code></pre></p>

<h3>3. Network Partition</h3>

<pre><code># iptables para simular latência
# Adicionar latência
iptables -A INPUT -p tcp --dport 5432 -m state --state NEW 
  -m recent --set --name DBPOSTGRES

<p>iptables -A INPUT -p tcp --dport 5432 -m state --state NEW <br>  -m recent --update --seconds 1 --hitcount 10 --name DBPOSTGRES <br>  -j DROP</p>

<p># Adicionar delay de 500ms<br>tc qdisc add dev eth0 root netem delay 500ms</p>

<p># Remover (cleanup)<br>tc qdisc del dev eth0 root<br></code></pre></p>

<h3>4. Container Kill</h3>

<pre><code>#!/bin/bash
# chaos-test.sh

<p>echo "=== Chaos Engineering Test ==="<br>echo "Target: Random API pod"</p>

<p># Get random API pod<br>POD=$(kubectl get pods -n production -l app=api <br>  -o jsonpath='{.items[0].metadata.name}')</p>

<p>echo "Killing pod: $POD"</p>

<p># Get metrics before<br>kubectl top pods $POD -n production<br>ERROR_RATE_BEFORE=$(curl -s http://api-service/metrics | grep error_rate)</p>

<p># Kill pod<br>kubectl delete pod $POD -n production</p>

<p># Monitor recovery<br>echo "Monitoring recovery..."<br>for i in {1..30}; do<br>    RESPONSE=$(curl -s -o /dev/null -w "{6727d158e4474b0847515bd23a8ee4bebd5f1aac7a18bc968e51d8985dccb442}{http_code}" http://api-service/health)<br>    if [ "$RESPONSE" == "200" ]; then<br>        echo "Recovered after ${i} seconds"<br>        break<br>    fi<br>    sleep 1<br>done</p>

<p># Get metrics after<br>kubectl top pods -n production -l app=api<br>ERROR_RATE_AFTER=$(curl -s http://api-service/metrics | grep error_rate)</p>

<p>echo "Error rate before: $ERROR_RATE_BEFORE"<br>echo "Error rate after: $ERROR_RATE_AFTER"</p>

<p># Validate<br>if [ $i -lt 30 ]; then<br>    echo "✅ Recovery successful"<br>else<br>    echo "❌ Recovery failed"<br>    exit 1<br>fi<br></code></pre></p>

<hr>
<h2>SRE错误预算 (Error Budgets)</h2>

<pre><code># Error Budget Calculator
class ErrorBudget:
    def __init__(self, slo_percentage, window_days=30):
        self.slo = slo_percentage / 100
        self.window_hours = window_days <em> 24 </em> 60 * 60

<p>def allowed_downtime(self):<br>        """Tempo máximo de downtime permitido"""<br>        return (1 - self.slo) * self.window_hours</p>

<p>def current_budget(self, actual_uptime):<br>        """Orçamento restante"""<br>        budget_used = (1 - actual_uptime) * self.window_hours<br>        return self.allowed_downtime() - budget_used</p>

<p>def budget_remaining_percentage(self, actual_uptime):<br>        """{6727d158e4474b0847515bd23a8ee4bebd5f1aac7a18bc968e51d8985dccb442} de orçamento restante"""<br>        budget = self.current_budget(actual_uptime)<br>        return (budget / self.allowed_downtime()) * 100</p>

<p># Uso<br>budget = ErrorBudget(slo_percentage=99.9, window_days=30)<br>allowed = budget.allowed_downtime()<br>print(f"Allowed downtime: {allowed/60:.1f} minutes per month")</p>

<p># Verificar se pode fazer chaos<br>actual_uptime = 0.998  # 99.8{6727d158e4474b0847515bd23a8ee4bebd5f1aac7a18bc968e51d8985dccb442}<br>remaining = budget.budget_remaining_percentage(actual_uptime)<br>print(f"Budget remaining: {remaining:.1f}{6727d158e4474b0847515bd23a8ee4bebd5f1aac7a18bc968e51d8985dccb442}")</p>

<p>if remaining &gt; 50:<br>    print("✅ Safe to run chaos experiments")<br>else:<br>    print("⚠️ Budget low, avoid chaos")<br></code></pre></p>

<hr>
<h2>Conclusão</h2>

<p>Chaos Engineeringprevine falhas em produção. As chaves são:<br><ol><li><strong>Comece com hipóteses</strong> - O que você quer provar?</li><br><li><strong>Amplitude controlada</strong> - Limite o blast radius</li><br><li><strong>Monitore</strong> - Observabilidade durante experimentos</li><br><li><strong>Automação</strong> - Execute continuamente</li><br><li><strong>Cultura</strong> - Aprenda com falhas, não puna</li><br></ol><br><hr><br><h3>FAQ</h3></p>

<p><strong>P: Chaos Engineering é seguro?</strong>  <br>R: Sim, quando feito com controle de blast radius e rollback.</p>

<p><strong>P: Quando começar?</strong>  <br>R: Quando você tiver observabilidade básica (métricas, logs, alertas).</p>

<p><strong>P: Qual ambiente usar?</strong>  <br>R: Comece em staging, depois produção controlada.</p>