Chaos Engineering
- ●Chaos Engineering মানে নিয়ন্ত্রিতভাবে নিজেই সিস্টেম ভাঙা, যাতে দুর্বলতা গ্রাহকের আগে তুমি খুঁজে পাও।
- ●প্রতিটা experiment একটা hypothesis দিয়ে শুরু হয় এবং ছোট blast radius রেখে চালানো হয়।
- ●Netflix-এর Chaos Monkey randomly server বন্ধ করে; Game Day-তে টিম মিলে পরিকল্পিত failure মহড়া দেয়।
সমস্যাটা কী?
তুমি অনেক যত্নে redundancy বানিয়েছ — ৩টা replica, auto-failover, load balancer। কাগজে সব ঠিক। কিন্তু সত্যিই কি failover কাজ করবে? নাকি ঠিক সেই রাতে, যখন একটা region down হবে, তখন আবিষ্কার করবে যে failover config-এ একটা ভুল আছে আর কিছুই switch হচ্ছে না?
বেশিরভাগ বড় outage ঘটে এমন কিছু থেকে যা "কখনো ঘটবে না বলে ভাবা হয়েছিল"। সমস্যা হলো — distributed system এত জটিল যে কোন combination-এ কী ভাঙবে তা আগে থেকে অনুমান করা অসম্ভব। তাহলে উপায়? নিজের সিস্টেম নিজেই ইচ্ছাকৃতভাবে, নিয়ন্ত্রিতভাবে ভাঙো — গ্রাহকের আগে দুর্বলতা খুঁজে বের করো। এটাই Chaos Engineering।
মূল ধারণা
Chaos Engineering হলো production (বা production-সদৃশ) সিস্টেমে নিয়ন্ত্রিত experiment চালানোর শৃঙ্খলা, যেখানে ইচ্ছাকৃতভাবে failure ঢুকিয়ে দেখা হয় সিস্টেম তা সহ্য করতে পারে কিনা — আস্থা তৈরির জন্য।
মূল শব্দটা হলো নিয়ন্ত্রিত। এটা এলোমেলো ভাঙচুর নয়; এটা বৈজ্ঞানিক পরীক্ষা। তুমি একটা অনুমান করো, ছোট পরিসরে পরীক্ষা করো, ফলাফল মাপো, শেখো, তারপর ঠিক করো।
ভিত্তি হলো Steady State — সিস্টেমের স্বাভাবিক, সুস্থ আচরণ (যেমন: "প্রতি সেকেন্ডে ৫০০ order, ৯৯.৯% সফল")। experiment-এর পুরো সময় তুমি দেখো steady state বজায় থাকছে কিনা।
কীভাবে কাজ করে
Hypothesis-driven experiment
প্রতিটা chaos experiment ৪ ধাপে চলে:
| ধাপ | কাজ |
|---|---|
| ১. Steady state নির্ধারণ | স্বাভাবিক metric ঠিক করো (order rate, latency) |
| ২. Hypothesis তৈরি | "যদি payment-service-এর একটা instance বন্ধ হয়, তবুও success rate ৯৯%+ থাকবে" |
| ৩. Failure ঢোকানো | একটা instance kill করো (ছোট blast radius-এ) |
| ৪. মাপো ও তুলনা | hypothesis কি টিকল? steady state অটুট থাকল কিনা দেখো |
যদি hypothesis ভেঙে যায় (success rate পড়ে গেল), তুমি একটা লুকানো দুর্বলতা পেলে — আর এটা পেলে নিয়ন্ত্রিত পরিবেশে, রাত ৩টার outage-এ নয়।
Blast Radius নিয়ন্ত্রণ
Blast Radius হলো experiment ভুল হলে কতদূর ক্ষতি ছড়াতে পারে। নিরাপদ chaos-এর মূল নীতি — ছোট থেকে শুরু করো:
- প্রথমে staging-এ পরীক্ষা করো।
- production-এ গেলে শুরু করো ১% traffic বা একটা instance দিয়ে।
- আস্থা বাড়লে ধীরে ধীরে scope বাড়াও।
- সবসময় একটা abort button / kill switch রাখো — খারাপ দেখলেই থামাও।
Failure-এর ধরন
- Instance failure → server/pod হঠাৎ kill
- Network failure → latency যোগ, packet drop, partition
- Resource হ্রাস → CPU/memory চাপ, disk full
- Dependency failure → external API/DB ধীর বা down বানানো
- Region failure → পুরো availability zone বন্ধ
Chaos Engineering হলো অগ্নিনির্বাপণ মহড়ার (fire drill) মতো। একটা অফিস building-এ fire alarm, sprinkler, emergency exit সব আছে — কাগজে নিরাপদ। কিন্তু কেউ কি জানে আগুন লাগলে কোন পথে বের হবে? তাই মাঝে মাঝে পরিকল্পিতভাবে alarm বাজিয়ে মহড়া দেওয়া হয় (নিয়ন্ত্রিত failure)। তখন দেখা যায় — একটা exit-এর তালা আটকে গেছে, বা lift বন্ধ হয়নি। এই দুর্বলতা মহড়ায় ধরা পড়ে, আসল আগুনে নয়। তুমি ইচ্ছাকৃতভাবে ছোট সমস্যা তৈরি করছ যাতে বড় বিপদে প্রস্তুত থাকো।
প্রকারভেদ — টুল ও পদ্ধতি
Netflix Chaos Monkey ও Simian Army
Netflix এই ক্ষেত্রের পথিকৃৎ। তাদের Chaos Monkey production-এ randomly instance বন্ধ করে দেয় — অফিস টাইমে, যখন engineer-রা জেগে আছেন। এর ফলে প্রতিটা service বাধ্য হয় একক instance হারানো সহ্য করতে। তাদের "Simian Army"-তে আরও আছে — Latency Monkey (নেটওয়ার্ক দেরি), Chaos Gorilla (পুরো zone বন্ধ), Chaos Kong (পুরো region বন্ধ)।
অন্য জনপ্রিয় টুল: Gremlin (commercial), LitmusChaos ও Chaos Mesh (Kubernetes-এর জন্য)।
Game Day
Game Day হলো পরিকল্পিত একটা সেশন যেখানে পুরো টিম জড়ো হয়ে ইচ্ছাকৃত failure ঘটায় এবং তাদের incident-response মহড়া দেয়। এতে শুধু সিস্টেম নয়, মানুষ ও process-ও পরীক্ষিত হয় — alert বাজল কি, runbook কাজ করল কি, ঠিক লোকজন জানল কি।
কখন ব্যবহার করবে / করবে না
- যখন তোমার সিস্টেম যথেষ্ট পরিণত — monitoring, alerting, redundancy আগে থেকে আছে।
- যখন একটা failure-এর প্রকৃত প্রভাব জানতে চাও, অনুমান নয়।
- নতুন, অস্থির সিস্টেমে chaos ঢোকানো অর্থহীন — সেখানে তো এমনিতেই সব ভাঙছে।
Production-এ chaos চালানোর আগে নিশ্চিত হও যে (১) তোমার ভালো observability আছে — নইলে কী ভাঙল তা-ই দেখবে না, (২) একটা তাৎক্ষণিক kill switch আছে, আর (৩) ব্যবসায়িক অনুমোদন আছে। কখনো কখনো একটা experiment আসল outage হয়ে যায় — তাই off-peak সময়ে, ছোট blast radius-এ, এবং on-call টিম প্রস্তুত রেখে শুরু করো। অনুমতি ও পরিকল্পনা ছাড়া "চলো production-এ একটা server kill করি" — এটা chaos engineering নয়, এটা দায়িত্বজ্ঞানহীনতা।
বাস্তব উদাহরণ
একটা বড় e-commerce platform (ঈদের sale-এর আগে) chaos experiment চালাল। Hypothesis: "যদি product-recommendation service down হয়, পুরো checkout flow তবুও কাজ করবে (শুধু recommendation না দেখিয়ে)।"
তারা staging-এ recommendation-service kill করল। কিন্তু hypothesis ভেঙে গেল — homepage সম্পূর্ণ load হওয়া বন্ধ হয়ে গেল, কারণ frontend recommendation-এর response-এর জন্য অপেক্ষা করছিল কোনো timeout/fallback ছাড়াই। এটা একটা লুকানো hard dependency ছিল যা কেউ জানত না।
তারা ঠিক করল — recommendation call-এ ৫০০ms timeout আর fallback (খালি section) যোগ করল। ফলে ঈদের sale-এর সময় যখন সত্যিই recommendation-service চাপে পড়ল, homepage অটুট রইল। গ্রাহকের আগে তারা সমস্যাটা ধরেছিল।
Interview-এ chaos engineering-কে "randomly ভাঙা" বলে উপস্থাপন করো না — এটা hypothesis-driven, controlled experiment। মূল চারটা শব্দ বলো: steady state, hypothesis, blast radius, kill switch। Netflix Chaos Monkey-র উদাহরণ আর Game Day-র কথা যোগ করলে depth বোঝা যায়। শেষে বলো — লক্ষ্য সিস্টেম ভাঙা নয়, বরং resilience-এ আস্থা তৈরি করা।
মূল শব্দ (Key Terms)
মিনি কুইজ
1. Chaos experiment-এ 'blast radius' ছোট রাখা কেন জরুরি?
2. Netflix-এর Chaos Monkey মূলত কী করে?
3. একটা সঠিক chaos experiment কীভাবে শুরু হয়?