What is Chaos Monkey?

ক্লাউডে গেলে ব্যর্থতা এড়ানো যায় না, এটা মেনে নিয়েই দীর্ঘমেয়াদে টেকসই সিস্টেম গড়তে হয়। Netflix এই সত্যটা অনেক আগেই বুঝেছিল, আর তাই তারা “fail constantly” নীতিতে Chaos Monkey বানিয়েছিল। এই টুল ইচ্ছাকৃতভাবে instance বা service কে “Kill” করতে পারে, যেন ইঞ্জিনিয়ারিং টিম আসল সমস্যার মতো করেই শিখতে পারে।

আজকের লেখায় Chaos Monkey এর ধারণা, কাজের ধাপ, প্রয়োজনীয় dependency, আর ব্যবহার করা উচিত কি না সবই সহজ ভাষায় গুছিয়ে বলার চেস্টা করবো। সফটওয়্যার লিড, SRE, DevOps কিংবা ব্যাকএন্ড ইঞ্জিনিয়ার যে কেউ এ থেকে বাস্তব কাজের দিকনির্দেশনা পাবেন।

Netflix এর শিক্ষা: Fail constantly মানে কী

Netflix ক্লাউডে মাইগ্রেট করার পথে একটি বড় শিক্ষা পেয়েছিল “ব্যর্থতা এড়ানোর সেরা উপায় হলো পরিকল্পিতভাবে ব্যর্থ হওয়া।” এর মানে এলোমেলো ঝুঁকি নয় বরং ছোট, নিয়ন্ত্রিত ব্যর্থতা তৈরি করে সিস্টেমকে সহনশীল করা। এতে unknown weaknesses চোখে পড়ে, recovery প্র্যাকটিস বারবার টেস্ট হয়, আর টিমের reflex শক্ত হয়।

এই দর্শনের ফলেই Chaos Monkey র‍্যান্ডম টারমিনেশন দিয়ে real-world outage এর মতো ফিলিংস তৈরি করে। তবে লক্ষ্যটা destruction নয় learning, hardening, আর faster recovery। তাই ডিজাইন, মনিটরিং, ওনারশিপ সব জায়গায় শৃঙ্খলা গড়ে ওঠে।

সংক্ষেপে: ভুল হবে তাই আগে থেকেই এমনভাবে অনুশীলন করুন যেন ভুল থেকে দ্রুত, নিরাপদে ফিরে আসতে পারেন।

Chaos Monkey ও Simian Army সংক্ষিপ্ত ইতিহাস

Netflix-এ এক সেট “Monkey” টুল ছিল যারা Simian Army নামে পরিচিত ছিল। Chaos Monkey ছিল এই “Simian Army”-র একজন সদস্য।এদের মধ্যে কারও কাজ ছিল বড়সড় বিপর্যয় অনুশীলন (Chaos Kong), কারও কাজ ছিল অপ্রয়োজনীয় জিনিস ক্লিন করা (Janitor Monkey)। সময়ের সঙ্গে নতুন ও ভালো টুল আসায় এই পুরো Army-র ব্যাচ ২০১৮ সালে অবসর নেয় (বন্ধ করে দেওয়া হয়)।

তবে Chaos Monkey আলাদা রিপোতে এখনো ওপেন সোর্স হিসেবে আছে। আজ আর এতে বড় বা নতুন কোন ফিচার আসছে না। মাঝে-সাঝে প্রয়োজনমাফিক হালকা মেইনটেনেন্স হয়। মানে, চাইলে ব্যবহার করতে পারেন, কিন্তু active community সাপোর্টের ওপর ভরসা করা যাবে না। এই প্রেক্ষাপট বোঝা জরুরি, কারণ টুল বাছাইয়ে কমিউনিটি কতটা এক্টিভ আছে তা লং-টার্মে খুব গুরুত্বপূর্ণ।

Chaos Monkey কীভাবে কাজ করে (Big Picture)

Chaos Monkey এমন এক “রোবট টাইমার” (cron) যেটা দিনে একবার ঘড়ির মতো চলে। আপনি Spinnaker-এ যেসব অ্যাপকে “Chaos Monkey enabled” করেন, সেগুলোকে এটি প্রতিদিন watch করে। তারপর লটারির মতো টার্গেট বেছে নেয়, কিন্তু সম্পূর্ণ অগোছালোভাবে নয়।

প্রতিটি attack আলাদা cron task হিসেবে শিডিউল হয় এবং MySQL-এ লগ/ট্র্যাকিং রাখা হয়। কখন কাকে মারা হলো, কাউকে বারবার টার্গেট করা হচ্ছে কি ন, এসব নিয়ন্ত্রণে রাখতেই এই tracking। In the background, MySQL এ লগ/ট্র্যাকিং রাখে যেন কেউ বাদ না পড়ে

আবার কাউকে যাতে অতিরিক্ত না মারা হয়। ঠিক সময়ে এটি Spinnaker কে বলে দেয় “এই instance/service এখন টার্মিনেট করো” আর সাথে সাথেই এক্সিকিউশন হয়ে যায়। এই পুরো ফ্লোতে “randomness এর ভেতরে disceipline রাখা হয়, যাতে কোনো সার্ভিস একেবারে এড়িয়ে যাওয়া বা অতিরিক্ত আঘাত দুই-ই না ঘটে।

• Daily Scan: দিনে একবার cron ট্রিগার হয়। Spinnaker-এ “Chaos Monkey enabled” অ্যাপগুলোর তালিকা নেয়।
• Target + time বাছাই: এলোমেলোভাবে কোন অ্যাপ/ইনস্ট্যান্সকে কখন মারা হবে তা ঠিক করে। পুরো random নয়, পাশাপাশি fairness মাথায় রাখে।
• Attack শিডিউল করাঃ প্রতিটি Attack আলাদা cron task হিসেবে শিডিউল হয়, মানে নির্দিষ্ট মিনিট/ঘণ্টায় রান করবে এমন টাইমার সেট হয়।
• MySQL-এ Log: কে টার্গেট হলো, কতবার হলো, কখন রান হবে, সব MySQL-এ লেখা থাকে। এতে কোন সার্ভিস/ইন্সট্যান্স বাদ পড়ে না বা অতিরিক্ত আঘাত যাতে না হয়।
• Spinnaker–এ কলঃ পূর্ব-নির্ধারিত schedule এলেই cron Spinnaker-কে ট্রিগার করে, আর Spinnaker সেই instance/service টার্মিনেট করে দেয়।

MySQL ও Spinnaker কে কী করে

এই টুলের দুইটি core dependencies আছে MySQL ও Spinnaker। MySQL-এ সব termination শিডিউল ও এক্সিকিউশনের রেকর্ড থাকে। ফলে সত্যিকারের “random” এ না গিয়ে “controlled randomness” বজায় থাকে। অর্থাৎ কে বাদ পড়ছে, আর কাকে বেশি মারা হচ্ছে সব রেকর্ড থাকে।

Spinnaker হলো ওপেন সোর্স Continuous Delivery প্ল্যাটফর্ম Netflix এটাতেই সার্ভিস deploy/provision করে এবং Chaos Monkey এটাকেই ব্যবহার করে destroy করতে। Spinnaker AWS, Azure, GCP, এমনকি Oracle Cloud-এর সঙ্গেও কাজ করতে পারে। আপনি যেটা Spinnaker দিয়ে manage করতে পারেন, সাধারণত সেটাই Chaos Monkey দিয়ে terminate করা যায়।

Bottom line: Spinnaker আপনার deploy + infra control plane। Chaos Monkey সেই plane-এ failure injection এর orchestration যোগ করে।

• MySQL: Behind the scenes সব schedule ও run log ধরে রাখে, তাই randomness থাকলেও fairness ও control বজায় থাকে।
• Spinnaker: Multi-cloud deploy/provision/destroy চালায়। Chaos Monkey-র execution engine হিসেবে নির্ধারিত সময়ে action এক্সিকিউট করে।

Spinnaker এর সাথে ইন্টিগ্রেশন

Chaos Monkey ব্যবহার করতে হলে Spinnaker এ আপনার অ্যাপ্লিকেশন “Chaos Monkey enabled” হিসেবে mark করতে হবে। এরপর দৈনিক cron জব চলবে, target খুজবে, আর নির্ধারিত সময়ে Spinnaker task ট্রিগার করবে।

এটা শোনায় সরল, কিন্তু Spinnaker সেটআপ নিজেই একটা সিরিয়াস ইনিশিয়েটিভ role, pipeline, permission, environment parity সব মিলিয়ে। শুধু Chaos Monkey চালানোর জন্য CI/CD স্ট্যাক Spinnaker এ মাইগ্রেট করা বাস্তবসম্মত নয়।

তাই আগেই ভাবুন যে আপনার টিম Spinnaker ইতিমধ্যে ব্যাবহার করেছে কি না, বা চালাতে চায় কি না। নাহলে বিকল্প chaos tooling বিবেচনা করা যুক্তিযুক্ত।

Should you use it? ৩টি ফিল্টার দিয়ে ভাবুন

Chaos Monkey-র আইডিয়া শক্তিশালী, কিন্তু আপনার কনটেক্সটে সেটি সঠিক টুল কি না এটা আলাদা প্রশ্ন। নিচের ৩টি ফিল্টার দিয়ে সিদ্ধান্ত নিন।

• Spinnaker prerequisite: Spinnaker ছাড়া Chaos Monkey চলবে না। শুধু এটার জন্য পুরো CI/CD পাল্টানো যুক্তিযুক্ত নয়।
• কমিউনিটি ও রক্ষণাবেক্ষণ: এ্যাক্টিভ বা বড় কমিউনিটি না থাকলে অপারেশনাল সাপোর্ট পুরোটা আপনার কাঁধে।
• শেখা বনাম ভয়: এলোমেলো destruction থেকে শেখা হবে। কিন্তু টিমের উপর অযথা চাপ পড়ে কি না, “incident–এর ভয়” দিয়ে কাজ করানো হচ্ছে কি না—সেটা ভেবে দেখুন।

আরো বাস্তবসম্মতভাবে দেখলে, ভালো chaos practice মানে hypothesis–driven experiment। অর্থাৎ “এই সার্ভিস kill করলে fallback X-এ যাবে, SLO-তে প্রভাব ≤Y” এমন ক্লিয়ার হাইপোথিসিস রেখে blast radius সীমিত করে চালান। এতে শেখা গভীর হয়, blame কমে, আর culture নিরাপদ থাকে।

• Experiment: Metric, log, trace এই তিনটি ছাড়া কিছুই বোঝা যাবে না। আগে নিশ্চিত করুন ড্যাশবোর্ড/alert আছে, যাতে এক্সপেরিমেন্টে কী হল তা মাপতে পারেন।
• Blast radius / abort condition: সর্বোচ্চ প্রভাব কতটুকু হতে দিচ্ছেন (blast radius) আর কোন সিগন্যাল দেখলেই সাথে সাথে থামাবেন (abort) এই দুটো আগে লিখে নিন, সবাইকে জানিয়ে দিন।
• Rollback/Auto–recover: ভুল হলে কীভাবে দ্রুত আগের অবস্থায় ফিরব। এই রুটিনটা rehearsal করা চাই। Manual rollback ধীর হলে, সম্ভব হলে auto-recover পথও যাচাই করুন।
• Postmortem: Incident/experiment শেষে blameless postmortem লিখুন, শেখাগুলো action items এ নামান, আর টিম/org-এ শেয়ার করুন তবেই শেখা টিকে থাকবে।

বিকল্প টুল নেবেন কিভাবে? focus রাখুন learning-এ

Chaos engineering-এর বেশিরভাগ টুলের কাজ একটাই, ইচ্ছাকৃতভাবে “ব্রেক করা”। পার্থক্যটা হয় শেখায়, কোন টুল আপনার প্রক্রিয়াকে কতটা hypothesis-driven করে, কতটা evidence দেখায়, আর টিমকে কতটা safe ফিল করায়।

টুল বাছাইয়ের সময় “কত বড় Attack করতে পারে” এর চেয়ে “কতটা শেখাতে পারে” তার দিকে নজর দিন। ভালো টুলের লক্ষণগুলো সাধারণত এগুলো:

• Small, planned experiment: ছোট পরিসরে, আগে থেকে পরিকল্পিত টেস্ট।
• Repeatable run: একই টেস্ট বারবার চালালে একই রকম ফল মেলে।
• Clear outcome: কী প্রভাব পড়লো, স্পষ্টভাবে দেখা যায়।
• Good reporting: রিপোর্ট/ড্যাশবোর্ডে evidence পরিষ্কার।

শেষ কথা: লক্ষ্য destruction নয়, লক্ষ্য resilience। যে টুল আর প্র্যাকটিস আপনাকে দ্রুত, তথ্যভিত্তিকভাবে শেখায় এবং গ্রোথ-এ সাহায্য করে সেটাই আপনার টিমের জন্য সঠিক পছন্দ।