Lab 57 — Chaos: derrubar uma AZ de propósito

// O alarme composto do L52 muda de estado durante a janela. Se isto acontecer
// enquanto o experimento roda, e a stop condition, nao um efeito colateral.
{
  "source": "aws.cloudwatch",
  "detail-type": "CloudWatch Alarm State Change",
  "resources": ["arn:aws:cloudwatch:us-east-1:111122223333:alarm:ffv-lab-slo-disponibilidade-queima-rapida-confirmada"],
  "detail": {
    "alarmName": "ffv-lab-slo-disponibilidade-queima-rapida-confirmada",
    "state": {
      "value": "ALARM",
      // Se as DUAS janelas confirmarem durante o experimento, o FIS aborta
      // sozinho — e a hipotese caiu. Registrar isso e o resultado, nao um erro.
      "reason": "arn:...:burn-5m transitioned to ALARM, arn:...:burn-1h transitioned to ALARM"
    },
    "previousState": { "value": "OK" }
  }
}

# fis_iam.tf — o papel que o FIS assume, e só as tres permissoes que ele precisa

data "aws_caller_identity" "atual" {}

data "aws_iam_policy_document" "fis_confia" {
  statement {
    effect  = "Allow"
    actions = ["sts:AssumeRole"]
    principals {
      type        = "Service"
      identifiers = ["fis.amazonaws.com"]
    }
    # Trava por conta: sem isto, um ARN deste papel que vazasse poderia, em
    # teoria, ser assumido por um experimento de OUTRA conta. O raio de
    # explosão do PAPEL tem de ser tao pequeno quanto o do experimento.
    condition {
      test     = "StringEquals"
      variable = "aws:SourceAccount"
      values   = [data.aws_caller_identity.atual.account_id]
    }
  }
}

resource "aws_iam_role" "fis_experimento" {
  name               = "${var.projeto}-fis-derrubar-az"
  assume_role_policy = data.aws_iam_policy_document.fis_confia.json
}

# As tres politicas GERENCIADAS da AWS cobrem exatamente as tres acoes deste
# experimento — rede, RDS e ECS — e nada alem disso. Usamos `data` em vez de
# hardcodar o ARN porque o caminho exato (com ou sem prefixo `service-role/`)
# varia por politica; resolver pelo NOME e o jeito que nao quebra se mudar.
data "aws_iam_policy" "fis_rede" {
  name = "AWSFaultInjectionSimulatorNetworkAccess"
}
data "aws_iam_policy" "fis_rds" {
  name = "AWSFaultInjectionSimulatorRDSAccess"
}
data "aws_iam_policy" "fis_ecs" {
  name = "AWSFaultInjectionSimulatorECSAccess"
}

resource "aws_iam_role_policy_attachment" "fis_rede" {
  role       = aws_iam_role.fis_experimento.name
  policy_arn = data.aws_iam_policy.fis_rede.arn
}
resource "aws_iam_role_policy_attachment" "fis_rds" {
  role       = aws_iam_role.fis_experimento.name
  policy_arn = data.aws_iam_policy.fis_rds.arn
}
resource "aws_iam_role_policy_attachment" "fis_ecs" {
  role       = aws_iam_role.fis_experimento.name
  policy_arn = data.aws_iam_policy.fis_ecs.arn
}

output "papel_fis_arn" {
  value       = aws_iam_role.fis_experimento.arn
  description = "ARN do papel que o experimento assume — referenciado pelo template abaixo"
}

# fis_experimento.tf — as tres acoes, na ordem, com o alarme do L52 como freio

variable "arn_alarme_queima_rapida_slo" {
  description = "ARN do alarme composto do L52 (queima-rapida-confirmada) — a stop condition"
  type        = string
}
variable "subnet_zona_a_arn" {
  description = "ARN da sub-rede privada da Zona A (a que hospeda o gravador do RDS agora)"
  type        = string
}
variable "rds_instance_arn" {
  description = "ARN da instancia RDS (Multi-AZ DB instance deployment, um standby)"
  type        = string
}

resource "aws_fis_experiment_template" "derrubar_zona_a" {
  description = "Interrompe rede, banco e computo da Zona A, com hipotese e freio"
  role_arn    = aws_iam_role.fis_experimento.arn

  # A stop condition E o SLO do L52 — nao um alarme novo criado so para este
  # teste. Reaproveitar o criterio que a empresa ja decidiu que significa
  # "grave" evita que o experimento tenha um padrao de sucesso diferente do
  # que o negocio usa todo santo dia.
  stop_condition {
    source = "aws:cloudwatch:alarm"
    value  = var.arn_alarme_queima_rapida_slo
  }

  target {
    name           = "SubnetZonaA"
    resource_type  = "aws:ec2:subnet"
    selection_mode = "ALL"
    resource_arns  = [var.subnet_zona_a_arn]
  }

  target {
    name           = "RdsGravador"
    resource_type  = "aws:rds:db"
    selection_mode = "ALL"
    resource_arns  = [var.rds_instance_arn]
  }

  # Vazio DE PROPOSITO. O ARN de uma task Fargate muda a cada deploy e a cada
  # substituicao — nao existe valor fixo para escrever aqui. O script
  # resolver-alvos.sh preenche isto com `update-experiment-template` minutos
  # antes de cada rodada.
  target {
    name           = "TasksZonaA"
    resource_type  = "aws:ecs:task"
    selection_mode = "ALL"
    resource_arns  = []
  }

  action {
    name        = "interromper-rede-zona-a"
    action_id   = "aws:network:disrupt-connectivity"
    description = "Bloqueia trafego de/para a sub-rede da Zona A"

    # 2 minutos: o mesmo valor que o proprio cenario pronto da AWS usa para a
    # acao de rede — o bastante para forcar timeout e reconexao sem prolongar
    # o experimento alem do necessario.
    parameter { key = "duration", value = "PT2M" }
    # "availability-zone" nega trafego intra-VPC entre zonas; "all" negaria
    # tambem o trafego DENTRO da propria sub-rede, o que testaria mais do que
    # a hipotese pede.
    parameter { key = "scope", value = "availability-zone" }

    target { key = "Subnets", value = "SubnetZonaA" }
  }

  action {
    name        = "falhar-rds"
    action_id   = "aws:rds:reboot-db-instances"
    description = "Forca o failover do gravador para o standby"

    # Sem este parametro, reboot-db-instances so reinicia a MESMA instancia
    # no lugar — nao troca de zona. E ele quem transforma um reboot comum na
    # mesma API que um failover real dispara.
    parameter { key = "forceFailover", value = "true" }

    target { key = "DBInstances", value = "RdsGravador" }

    # Comeca so depois de a rede cair — espelha a ordem de uma interrupcao de
    # zona real, em que a rede falha primeiro e o failover e' a CONSEQUENCIA.
    start_after = ["interromper-rede-zona-a"]
  }

  action {
    name        = "parar-tasks-zona-a"
    action_id   = "aws:ecs:stop-task"
    description = "Para as tasks Fargate resolvidas como pertencentes a Zona A"

    target { key = "Tasks", value = "TasksZonaA" }

    start_after = ["interromper-rede-zona-a"]
  }

  # O ponto que este modulo cobra explicitamente: "fail", nao "skip" (o
  # padrao do cenario pronto da AWS). Se o script de resolucao de alvos
  # falhar e a lista de tasks ficar vazia, o experimento INTEIRO falha em vez
  # de terminar "com sucesso" sem ter testado o computo — que e' exatamente a
  # armadilha que o nucleo deste laboratorio existe para expor.
  #
  # Confira o nome exato deste bloco na versao do provider AWS que voce usa;
  # a API por baixo (experimentOptions.emptyTargetResolutionMode) e a mesma
  # que o cenario pronto da AWS expoe.
  experiment_options {
    account_targeting            = "single-account"
    empty_target_resolution_mode = "fail"
  }

  tags = {
    Projeto      = var.projeto
    Hipotese     = "slo-99-9-sobrevive-queda-zona-a"
    RaioExplosao = "homologacao-primeiro"
  }
}

output "template_id" {
  value = aws_fis_experiment_template.derrubar_zona_a.id
}

#!/usr/bin/env bash
# rodar-experimento.sh — resolve alvos efemeros, confere o freio, so entao comeca
set -euo pipefail

PROJETO="${PROJETO:?defina PROJETO}"
ZONA_ALVO="${ZONA_ALVO:?defina a AZ que hospeda o gravador do RDS agora, ex: us-east-1a}"
TEMPLATE_ID="${TEMPLATE_ID:?defina o id do experiment template}"

# 1. Pre-checagem: o freio precisa estar destravado ANTES de comecar. Alarme
#    ja em ALARM significa que o orcamento do mes ja esta comprometido por
#    outro motivo — rodar o experimento em cima disso mistura duas causas e
#    o resultado nao ensina nada sobre a hipotese.
estado_alarme=$(aws cloudwatch describe-alarms \
  --alarm-names "${PROJETO}-slo-disponibilidade-queima-rapida-confirmada" \
  --query "MetricAlarms[0].StateValue" --output text)
if [[ "$estado_alarme" != "OK" ]]; then
  echo "alarme do L52 nao esta OK ($estado_alarme) — nao inicie o experimento agora" >&2
  exit 1
fi

# 2. Resolucao dos alvos efemeros. O ARN de uma task Fargate nao existe ate
#    ela subir, e muda a cada substituicao — por isso isto roda a CADA
#    execucao, nunca uma vez so no Terraform.
tasks_zona_a=$(for arn in $(aws ecs list-tasks --cluster "$PROJETO" --query "taskArns" --output text); do
  aws ecs describe-tasks --cluster "$PROJETO" --tasks "$arn" \
    --query "tasks[?availabilityZone=='${ZONA_ALVO}'].taskArn" --output text
done)

if [[ -z "$tasks_zona_a" ]]; then
  echo "nenhuma task encontrada na zona ${ZONA_ALVO} — servico desbalanceado," \
       "ou nome de AZ errado. Corrija antes de continuar." >&2
  exit 1
fi
echo "tasks na zona alvo: $tasks_zona_a"

# 3. Atualiza o alvo TasksZonaA do template com os ARNs resolvidos AGORA. Com
#    empty_target_resolution_mode=fail no template, se este passo falhar e a
#    lista ficar vazia, o experimento INTEIRO falha — em vez de "passar" sem
#    ter testado o computo.
arns_json=$(echo "$tasks_zona_a" | tr '\t' '\n' | jq -R . | jq -s .)
aws fis update-experiment-template --id "$TEMPLATE_ID" \
  --targets "{\"TasksZonaA\":{\"resourceType\":\"aws:ecs:task\",\"resourceArns\":${arns_json},\"selectionMode\":\"ALL\"}}"

# 4. So agora comeca. A partir daqui, o relogio do experimento e o do L52
#    correm juntos — e e o do L52 que decide se o teste continua.
experimento_id=$(aws fis start-experiment --experiment-template-id "$TEMPLATE_ID" \
  --query "experiment.id" --output text)
echo "experimento iniciado: $experimento_id — hipotese registrada em hipotese.md"

aws fis get-experiment --id "$experimento_id" --query "experiment.state"

// Program.cs (trecho) — a aplicacao revela a propria zona

var builder = WebApplication.CreateBuilder(args);

// O Fargate injeta esta variavel em toda task, apontando para o endpoint de
// metadados DA PROPRIA task (Task Metadata Endpoint v4). Nao exige IAM nem
// chamada externa — e local, dentro da rede da propria task. O campo
// AvailabilityZone so existe a partir da plataforma Fargate 1.4 (Linux).
var metadataUri = Environment.GetEnvironmentVariable("ECS_CONTAINER_METADATA_URI_V4");
var zonaDaTask = "desconhecida";

if (metadataUri is not null)
{
    using var http = new HttpClient { Timeout = TimeSpan.FromSeconds(2) };
    try
    {
        // "/task" (nao a raiz, que descreve so o CONTEINER) traz o campo no
        // nivel da TASK inteira — e a task, nao o conteiner, que tem zona.
        var resposta = await http.GetFromJsonAsync<JsonElement>($"{metadataUri}/task");
        zonaDaTask = resposta.GetProperty("AvailabilityZone").GetString() ?? "desconhecida";
    }
    catch (Exception ex)
    {
        // Falhar aqui NAO pode derrubar a partida da aplicacao — e so
        // observabilidade extra. Sem a zona, o experimento ainda funciona;
        // so fica mais dificil provar QUAL task foi atingida depois.
        Console.Error.WriteLine($"nao foi possivel ler a zona da task: {ex.Message}");
    }
}

// Rotula toda metrica e todo log estruturado com a zona — e o que permite,
// depois do experimento, filtrar so os eventos da Zona A e comparar contra a
// Zona B no mesmo grafico.
builder.Services.AddSingleton(new ZonaDaTask(zonaDaTask));
builder.Logging.AddOpenTelemetry(o => o.SetResourceBuilder(
    ResourceBuilder.CreateDefault().AddAttributes(new Dictionary<string, object>
    {
        ["cloud.availability_zone"] = zonaDaTask,
    })));

var app = builder.Build();

app.MapGet("/api/diagnostico/zona", (ZonaDaTask z) => Results.Ok(new { zona = z.Valor }));

app.Run();

record ZonaDaTask(string Valor);

#!/usr/bin/env bash
# provas.sh — cinco medicoes; nenhuma aceita "o experimento nao deu erro" como resultado
set -euo pipefail
PROJETO="${PROJETO:?defina PROJETO}"
EXPERIMENTO_ID="${EXPERIMENTO_ID:?defina o id do experimento ja iniciado}"

# ── Prova 1: a rede realmente foi bloqueada, e o bloqueio realmente saiu ─────
aws ec2 describe-network-acls \
  --filters "Name=tag:managedByFIS,Values=true" \
  --query "NetworkAcls[].{id:NetworkAclId,subnet:Associations[0].SubnetId}" --output table
# Esperado DURANTE a janela: uma linha. Esperado 3 min depois de terminar: nenhuma.
# Se a linha persistir depois do fim, a sub-rede ficou bloqueada — veja o
# troubleshooting sobre NACL residual antes de qualquer outra coisa.

# ── Prova 2: as tasks da Zona A realmente pararam, nao so ficaram sem rede ──
aws ecs describe-tasks --cluster "$PROJETO" \
  --tasks $(aws ecs list-tasks --cluster "$PROJETO" --desired-status STOPPED \
              --query "taskArns" --output text) \
  --query "tasks[].{parada:stoppedReason,quando:stoppedAt}" --output table
# Esperado: stoppedReason mencionando a chamada StopTask do FIS, com
# stoppedAt dentro da janela do experimento.

# ── Prova 3: o RDS falhou de verdade, e o tempo da troca fica registrado ────
aws rds describe-events --source-type db-instance --duration 30 \
  --query "Events[?contains(Message, 'failover')].{quando:Date,msg:Message}" --output table
# Procure "Multi-AZ instance failover started" e "...completed" — a diferenca
# entre os dois timestamps E o numero que a documentacao nao compromete.
# Medido neste ambiente: cerca de 51 s. NAO copie este valor — meca o seu.

# ── Prova 4: o orcamento de erro do L52, medido durante a janela ────────────
aws cloudwatch describe-alarms \
  --alarm-names "${PROJETO}-slo-disponibilidade-burn-5m" "${PROJETO}-slo-disponibilidade-burn-1h" \
               "${PROJETO}-slo-disponibilidade-queima-rapida-confirmada" \
  --query "MetricAlarms[].{nome:AlarmName,estado:StateValue,motivo:StateReason}" --output table
# Esperado, se a hipotese se confirma: a janela de 5 min PODE ter cruzado o
# limiar (o failover e curto e real); a de 1 h nao confirma; o COMPOSTO
# continua OK. Se o composto disparou, a hipotese caiu — registre isso.

# ── Prova 5: o relatorio do FIS confirma que NENHUMA acao foi pulada ────────
aws fis get-experiment --id "$EXPERIMENTO_ID" \
  --query "experiment.actions.*.{acao:actionId,estado:state.status,motivo:state.reason}" --output table
# Esperado: as tres acoes com status "completed". Se "parar-tasks-zona-a"
# aparecer como "skipped" ou "failed", o computo nao foi testado — e com
# empty_target_resolution_mode=fail o experimento inteiro deveria ter falhado
# antes de chegar aqui. Ver esta prova passar SEM as outras falharem e o
# resultado que importa: prova que o freio contra o "sucesso silencioso" funcionou.

#!/usr/bin/env bash
# limpar.sh — o que o destroy nao leva, e o residuo que so este experimento pode deixar
set -euo pipefail

# 1. Derrube o que o Terraform administra (template, papel, policies).
terraform destroy -auto-approve

# 2. NACL RESIDUAL: se o experimento foi interrompido de forma anormal (conta
#    perdeu permissao no meio, por exemplo), o FIS pode nao ter restaurado a
#    associacao original da sub-rede. Isto NAO aparece no estado do Terraform
#    porque o FIS criou e destruiu esse recurso por fora dele.
aws ec2 describe-network-acls --filters "Name=tag:managedByFIS,Values=true" \
  --query "NetworkAcls[].NetworkAclId" --output table
# Esperado: vazio. Se houver linha, reassocie a sub-rede a lista de controle
# de acesso ORIGINAL antes de seguir — enquanto isso nao acontece, a Zona A
# continua bloqueada de verdade, fora do experimento.

# 3. TASKS SUBSTITUTAS: o servico ECS recria o que o FIS parou. Confirme que
#    a contagem desejada voltou ao normal e que nenhuma task ficou presa
#    tentando nascer na sub-rede que acabou de ser desbloqueada.
aws ecs describe-services --cluster "$PROJETO" --services "${PROJETO}-api" \
  --query "services[0].{desejado:desiredCount,rodando:runningCount}" --output table

# 4. HISTORICO DO EXPERIMENTO: os logs do FIS (se voce configurou
#    log_configuration) tem retencao propria e sobrevivem ao destroy do
#    template — e' o registro que compara hipotese com resultado.
aws logs describe-log-groups --log-group-name-prefix "/aws/fis/${PROJETO}" \
  --query "logGroups[].{grupo:logGroupName,retencao:retentionInDays}" --output table