Chaos Engineering pour C# : casser les applications pour sauver l'entreprise

Introduction : Pourquoi votre service C# n'est pas un mécanisme parfait

Imaginez : vous avez écrit un microservice élégant en C#. Le code a passé une code review, les tests unitaires couvrent 95 %, les tests d'intégration sont verts. Vous le déployez en production, et… 3 heures plus tard, le système s'effondre. La cause ? Un pic de trafic inattendu qui a surchargé le pool de threads, ou une panne soudaine de la base de données que vous n'aviez pas prévue.

Bienvenue dans le monde réel, où le Chaos Engineering (ingénierie du chaos) devient non pas un luxe, mais une nécessité. Il ne s'agit pas de « tout casser pour le plaisir ». C'est une discipline qui aide à identifier les points faibles des systèmes distribués avant que vos utilisateurs ne les découvrent.

Dans cet article, nous allons voir comment appliquer le Chaos Engineering pour les applications C# : de la théorie aux exemples de code concrets utilisant les bibliothèques Polly et Simmy. Vous apprendrez à introduire délibérément du chaos dans les services .NET pour améliorer leur résilience et leur prévisibilité.

Qu'est-ce que le Chaos Engineering et pourquoi est-ce important pour .NET ?

Chaos Engineering est la pratique qui consiste à mener des expériences sur un système distribué pour vérifier sa capacité à résister à des pannes inattendues. Netflix, Amazon, Microsoft – tous les géants l'utilisent. Pour les développeurs C#, c'est particulièrement pertinent car .NET Core/5+ est de plus en plus utilisé pour construire des services cloud à forte charge sur Microsoft Azure.

Principes fondamentaux de l'ingénierie du chaos :

\n
• Définir l'« état stable » (steady state) – comment votre système se comporte normalement (latence, débit, taux d'erreur).
\n
• Formuler une hypothèse – « Si la base de données OrderDB tombe, le service de commandes continuera de répondre avec des données mises en cache pendant 5 minutes. »
\n
• Introduire le chaos – vous déconnectez réellement OrderDB pendant 30 secondes.
\n
• Vérifier l'hypothèse – on observe les métriques. Si l'hypothèse n'est pas confirmée, vous avez un bug dans l'architecture.
\n

Le mot-clé ici est « expérience ». Vous n'espérez pas simplement que tout va bien se passer, vous prouvez que votre système survivra.

Boîte à outils pour le Chaos Engineering en C#

Dans le monde .NET, il existe deux outils puissants qui fonctionnent ensemble :

\n
• Polly – une bibliothèque pour implémenter des modèles de résilience (Retry, Circuit Breaker, Timeout, Bulkhead Isolation).
\n
• Simmy (Microsoft.Extensions.Resilience) – une bibliothèque pour le Chaos Engineering, qui étend Polly. Elle permet d'« injecter » des pannes dans vos politiques.
\n

Simmy est le « méchant frère » de Polly. Si Polly apprend à votre application à survivre, Simmy vérifie à quel point elle le fait bien, en cassant délibérément les appels.

Pratique : Configuration d'une expérience de chaos en C#

Passons au code. Supposons que nous ayons un service de réservation qui appelle une API de paiement externe. Nous voulons vérifier comment BookingService se comportera si l'API de paiement commence à répondre avec des retards ou des erreurs.

Étape 1 : Installation des packages

dotnet add package Microsoft.Extensions.Http.Polly\ndotnet add package Microsoft.Extensions.Resilience\n

Étape 2 : Configuration de HttpClient avec des politiques

D'abord, nous configurons une politique standard Circuit Breaker et Retry avec Polly. Ensuite, nous l'« enveloppons » dans une politique de chaos provenant de Simmy.

using Microsoft.Extensions.DependencyInjection;\nusing Microsoft.Extensions.Http.Resilience;\nusing Polly;\nusing Polly.Extensions.Http;\n\npublic static class ServiceCollectionExtensions\n{\n    public static IServiceCollection AddPaymentClient(this IServiceCollection services)\n    {\n        services.AddHttpClient<IPaymentService, PaymentService>(client =&g