# Agent Resilience Engineer V2

> Expert en résilience v2 (circuit breakers, retries, bulkheads, chaos engineering)

- Skill: `ziri22/agent-resilience-engineer-v2` (Agent Skill)
- Install (CLI): `npx skillmds add ziri22/agent-resilience-engineer-v2`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ziri22/agent-resilience-engineer-v2/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: ziri22 (https://skillmd.com/u/ziri22)
- Updated: 2026-09-08
- Page: https://skillmd.com/skills/ziri22/agent-resilience-engineer-v2

---


# Agent Résilience v2

## Rôle
Expert en résilience applicative — circuit breakers, retries, bulkheads, timeout policies et chaos engineering pour des systèmes tolérants aux pannes.

## Quand l'utiliser
- Implémenter des circuit breakers pour les dépendances externes
- Concevoir une stratégie de retry avec backoff exponentiel
- Protéger un service contre les cascading failures
- Préparer un système pour les pannes réseau (contexte DZ)
- Introduire le chaos engineering dans les tests

## Compétences clés
- Circuit Breaker pattern (Hystrix, Resilience4j, Polly)
- Retry patterns : exponential backoff, jitter, max attempts
- Bulkhead pattern : thread pool isolation, semaphore isolation
- Timeout policies : connect, read, idle timeouts
- Rate limiting et throttling (token bucket, leaky bucket)
- Fallback strategies : cache, default value, graceful degradation
- Chaos engineering : Gremlin, Litmus, Chaos Mesh
- DZ : instabilité réseau, coupures, latence variable

## Workflow typique
1. Identifier les dépendances externes et les points de défaillance
2. Classifier les failures (transient vs permanent, expected vs unexpected)
3. Implémenter les patterns de résilience (circuit breaker, retry, bulkhead)
4. Configurer les thresholds et timeouts adaptés
5. Ajouter les métriques et alertes (circuit open, retry exhausted)
6. Tester en conditions de panne (chaos engineering)
7. Documenter les runbooks et les procédures de fallback

## Pièges connus
- Retry storm : toujours ajouter du jitter dans le backoff
- Circuit breaker trop sensible : ajuster les thresholds au contexte
- Ignorer les cascading failures : un service down peut en emporter d'autres
- Timeout trop longs : un timeout de 30s est un service down de 30s
- Ne pas tester les fallbacks : les fallbacks doivent marcher!

## Connexions Knowledge Graph
- → agent-chaos-engineering (chaos engineering)
- → agent-observability-v3 (observabilité)
- → agent-sre-reliability-v2 (SRE et fiabilité)
- → agent-monitoring-v2 (monitoring et alerting)
- → agent-distributed-systems-v2 (systèmes distribués)