Chaos Engineering: সীমিত পরিসরে failure পরীক্ষা

এই পাঠে যা শিখবেন

• Hypothesis-driven failure experiment লেখা
• Blast radius এবং abort condition সীমিত করা
• Steady state ও recovery evidence সংগ্রহ

সমস্যা দিয়ে শুরু

Architecture review বলছে Redis বন্ধ হলেও catalog database থেকে চলবে। বাস্তবে cache client timeout দীর্ঘ হওয়ায় সব PHP worker আটকে যায়। এই assumption incident-এর আগে নিয়ন্ত্রিতভাবে যাচাই করা যেত। Chaos engineering random server ভাঙা নয়; একটি নির্দিষ্ট resilience hypothesis evidence দিয়ে পরীক্ষা করা। Experiment-এর ক্ষতি নিয়ন্ত্রণ করার ক্ষমতা না থাকলে production-এ শুরু করা উচিত নয়।

সহজ করে বুঝি

Steady state হলো user-visible normal behavior-এর measurable definition। Hypothesis বলে কোন failure injection-এর মধ্যেও কোন behavior থাকবে। ছোট scope-এ delay, packet loss বা process failure দিন, তারপর observed result compare করুন। Abort threshold, owner, time limit ও rollback আগে লিখুন। Staging নিরাপদ শুরু, কিন্তু real production dependency ভিন্ন হতে পারে; সেই সীমা স্পষ্ট লিখুন।

পরিচিত একটি উপমা

অগ্নিনির্বাপণ মহড়ায় ইচ্ছা করে পুরো ভবন পোড়ানো হয় না। Alarm, exit route ও মানুষের response পরীক্ষা হয়, observer ও stop rule থাকে। একইভাবে failure drill-এর উদ্দেশ্য system এবং দলের recovery ক্ষমতা জানা।

নকশাটি দেখুন

flowchart LR
 H[Write resilience hypothesis] --> B[Baseline user signals]
 B --> I[Inject scoped fault]
 I --> O[Observe impact]
 O --> A{Abort threshold reached}
 A -->|Yes| S[Stop and recover]
 A -->|No| V[Verify hypothesis]
 S --> L[Record learning]
 V --> L

প্রথমে expected behavior ও baseline লিখুন। Scoped fault এক dependency বা ছোট cohort-এ দিন। User signals continuous দেখুন; threshold পার হলে experiment থামান। Recovery হয়েছে কি না confirm করে result লিখুন। Hypothesis wrong হলে experiment failed নয়—নকশার unknown boundary evidence দিয়ে বেরিয়েছে। Improvement-এর owner এবং followup test দরকার।

PHP ও Laravel-এ প্রয়োগ

Pest feature test-এ Laravel HTTP client fake দিয়ে payment dependency failure simulate করা হয়েছে। Checkout route, user factory এবং expected 503 response application-এ আগে implement করতে হবে। এটি network chaos নয়; application error handling-এর deterministic test। Real provider-এ test charge পাঠাবেন না।

use App\Models\User;
use Illuminate\Support\Facades\Http;
test('checkout reports provider outage safely', function () {
    Http::fake(['payments.example.test/*' => Http::response([], 503)]);
    $user = User::factory()->create();
    $this->actingAs($user)->postJson('/checkout', [
        'cart_id' => 1,
    ])->assertStatus(503);
});

সুবিধা, সীমাবদ্ধতা ও trade-off

Failure drill assumptions প্রকাশ করে এবং runbook অনুশীলন করায়। বিনিময়ে controlled user impact, tooling cost ও coordination লাগে। ছোট fault থেকেও cascade হতে পারে; monitoring broken হলে experiment থামান। Unit-level fake দ্রুত ও repeatable, কিন্তু DNS, connection pool, kernel ও failover behavior প্রমাণ করে না। স্তর অনুযায়ী test boundary লিখুন।

সাধারণ ভুল

• Hypothesis ছাড়া random instance terminate করা।
• Monitoring বা abort control কাজ না করলেও drill চালানো।
• Staging fake test-কে production resilience proof বলা।

আরও একটু গভীরে

একটি experiment-এ একটি প্রধান variable বদলান, নইলে causality বোঝা কঠিন। Critical external dependency-তে provider permission ও safe sandbox ব্যবহার করুন। Experiment traffic user data mix করলে privacy ও side effect risk বিবেচনা করুন। Recovery-র পরে queue backlog, duplicate side effects এবং stale cache দেখুন। Immediate latency স্বাভাবিক হলেও delayed consequence থাকতে পারে।

মনে রাখুন

নিয়ন্ত্রিত failure experiment measurable hypothesis যাচাই করে; scope, observability ও abort mechanism আগে প্রস্তুত থাকতে হয়।

নিজে চেষ্টা করুন

Cache outage-এর hypothesis লিখুন: catalog usable থাকবে কিন্তু latency বাড়বে। কোন cohort, কত সময়, কী timeout, কোন stop signal এবং কী recovery check থাকবে নির্ধারণ করুন। Fake test ও real network drill কী আলাদা শেখাবে লিখুন।

নিজের বোঝা যাচাই করুন

1. Chaos মানে random failure?

না। Specific hypothesis, measurable steady state এবং controlled experiment থাকা দরকার। Random disruption evidence দুর্বল করে।

2. Abort condition কখন?

Experiment-এর আগে। Operator যেন threshold দেখেই দ্রুত stop করতে পারেন, সেই control পরীক্ষা করুন।

3. HTTP fake যথেষ্ট?

Application branch test করে; বাস্তব network latency, connection exhaustion বা provider behavior পুরোটা নয়।

4. Hypothesis ভুল হলে লাভ?

Unknown weakness প্রকাশ পায়। Root cause, owner এবং corrective verification নথিবদ্ধ করলে learning হয়।

5. Recovery শেষে কী দেখব?

User success ছাড়াও backlog, duplicates, stale state ও delayed effects দেখুন। Fault সরলেই সব business consequence শেষ হয় না।

আরও পড়ুন

• Principles of Chaos Engineering
• Laravel HTTP client testing