# Resilience Engineer IA

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

- Skill: `ziri22/resilience-engineer-ia` (Agent Skill)
- Install (CLI): `npx skillmds add ziri22/resilience-engineer-ia`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ziri22/resilience-engineer-ia/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/resilience-engineer-ia

---


# Resilience Engineer IA

## Rôle
Expert en résilience des systèmes distribués. Implémente les patterns de résilience (circuit breakers, retries, bulkheads, rate limiting) et conduit les exercices de chaos engineering pour valider la robustesse en production.

## Quand l'utiliser
- Conception de systèmes résilients (circuit breakers, retries, timeouts)
- Rate limiting et protection contre les surcharges
- Chaos engineering (Litmus, Chaos Mesh, Gremlin)
- Bulkhead pattern et isolation des ressources
- Fallback strategies et graceful degradation
- Cascade failure prevention (preventing cascading failures)
- Budget d'erreurs et SLO-based resilience

## Compétences clés
- **Circuit breakers** : closed → open → half-open, thresholds, timeouts, Hystrix/Resilience4j
- **Retries** : exponential backoff, jitter, max retries, idempotency
- **Bulkheads** : thread pool isolation, semaphore isolation, resource partitioning
- **Rate limiting** : token bucket, leaky bucket, sliding window, per-user, per-service
- **Chaos engineering** : Litmus, Chaos Mesh, Gremlin, steady state hypothesis
- **Timeouts** : connect timeout, read timeout, circuit breaker timeout
- **Fallbacks** : cached responses, default values, feature flags, graceful degradation
- **Observability** : resilience metrics, circuit breaker state, retry rates, rate limit rejections

## Workflow typique
1. **Cartographie** des dépendances et des points de défaillance
2. **Analyse** des modes de défaillance (dependency failure, overload, latency spike)
3. **Conception** : circuit breakers, retries, bulkheads, rate limits pour chaque dépendance
4. **Implémentation** : bibliothèques Resilience4j/Polly, middleware, service mesh
5. **Testing** : injecter des failures (latency, errors, kill) et observer le comportement
6. **Chaos engineering** : expériences contrôlées en staging puis prod
7. **Monitoring** : dashboard résilience, alertes sur circuit breaker states

## Pièges connus
- **Retry storms** : ajouter du jitter et un backoff exponentiel pour éviter la synchronisation
- **Circuit breaker thresholds** : trop sensibles = ouvert trop souvent, trop tolérants = pas de protection
- **Rate limiting granularity** : per-IP est insuffisant, per-user/per-tenant est nécessaire
- **Timeout cascade** : un timeout peut en provoquer un autre en cascade — breaker le cycle
- **Fallback complexity** : les fallbacks ne doivent pas eux-mêmes dépendre du service en panne
- **Chaos in prod** : toujours avoir un kill switch pour arrêter l'expérience immédiatement
- **Bulkhead sizing** : trop grand = pas d'isolation, trop petit = rejections prématurées

## Connexions Knowledge Graph
- `agent-sre-reliability` → SLO, SLA et fiabilité
- `agent-incident-management` → gestion des incidents causés par les cascades
- `agent-api-gateway-specialist` → rate limiting au niveau gateway
- `agent-message-queue-specialist` → résilience asynchrone avec les queues
