Chaos Engineering para PHP: como quebrar a aplicação antes que os usuários o façam

Sua aplicação PHP é uma borboleta frágil? Hora de testar isso em batalha

Imagine: sexta-feira à noite. Você acabou de lançar o tão esperado release. Tudo funciona perfeitamente. Você serve um chá, abre o Telegram... E aí o banco de dados cai. Ou o Redis. Ou a API externa. Familiar? Se não — provavelmente você ainda não enfrentou o caos real.

No mundo do desenvolvimento PHP, é comum confiar no "jeitinho". Escrevemos código, cobrimos com testes unitários, às vezes até testes de integração. Mas o que acontece quando tudo sai do planejado? Quando o servidor perde pacotes, o banco de dados responde com 10 segundos de atraso, ou o sistema de arquivos fica cheio?

É aí que entra o Chaos Engineering — uma disciplina que veio do mundo da Netflix e de grandes sistemas distribuídos. Mas não feche o artigo: isso funciona também para aplicações PHP comuns, mesmo que você tenha um monolito em Laravel ou Symfony.

O que é Chaos Engineering e por que um desenvolvedor PHP precisa disso?

Chaos Engineering é a prática de realizar experimentos no sistema para identificar pontos fracos antes que eles se manifestem em uma falha real. Você intencionalmente introduz falhas (desliga serviços, atrasa respostas, mata processos) e observa como sua aplicação se comporta.

Muitos pensam: "Eu tenho uma aplicação PHP simples, por que preciso disso?". Mas sejamos honestos:

\n
• Seu código depende de APIs externas? Sim.
\n
• Você tem cache com Redis ou Memcached? Sim.
\n
• Você usa filas (RabbitMQ, Kafka, SQS)? Provavelmente sim.
\n
• Banco de dados — MySQL/PostgreSQL? Sim.
\n

Cada um desses pontos é um potencial ponto de falha. E a resiliência PHP da aplicação só é testada no momento em que algo quebra. O Chaos Engineering permite que você seja quem quebra, não quem conserta.

Princípios básicos do Chaos Engineering

Antes de escrever código, lembre-se de três regras principais:

\n
• Comece pequeno. Não desligue o banco de dados inteiro de uma vez. Comece com uma conexão.
\n
• Tenha uma hipótese. "Se o Redis cair, a aplicação deve funcionar, mas mais devagar" — isso é uma hipótese. Teste-a.
\n
• Automatize a reversão. Sempre tenha um plano para retornar ao estado normal.
\n

Agora vamos para exemplos reais em PHP.

Exemplo 1: Emulação de atraso no banco de dados

Suponha que você tenha uma consulta típica ao MySQL. Você usa PDO. Como verificar o que aconteceria se o banco de dados de repente começasse a "lagar"?

A maneira mais simples é escrever um middleware ou um wrapper para o PDO que adiciona um atraso aleatório. Aqui está um exemplo:

<?php\nclass ChaoticPDO extends PDO {\n    private float $chaosProbability;\n    private int $maxDelayMs;\n\n    public function __construct(\n        string $dsn, \n        ?string $username = null, \n        ?string $password = null, \n        ?array $options = null,\n        float $chaosProbability = 0.1, // 10% das consultas vão "lagar"\n        int $maxDelayMs = 5000        // máximo de 5 segundos de atraso\n    ) {\n        parent::__construct($dsn, $username, $password, $options);\n        $this->chaosProbability = $chaosProbability;\n        $this->maxDelayMs = $maxDelayMs;\n    }\n\n    public function query(string $query, ?int $fetchMode = null, mixed ...$fetchModeArgs): PDOStatement|false\n    {\n        $this->maybeInjectDelay();\n        return parent::query($query, $fetchMode, ...$fetchModeArgs);\n    }\n\n    private function maybeInjectDelay(): void {\n        if (mt_rand() / mt_getrandmax() < $this->chaosProbability) {\n            $delay = mt_rand(100, $this->maxDelayMs);\n            usleep($delay * 1000);\n            // Log para monitoramento\n            error_log("[CHAOS] Injected delay of {$delay}ms in database query");\n        }\n    }\n}\n\n// Uso\n$pdo = new Ch