Chaos Engineering - ইচ্ছে করে ভাঙা, যাতে হঠাৎ না ভাঙে

০০ যে প্রশ্নগুলোর উত্তর খুঁজবো

আগের সেশনগুলোতে আমরা system কে টেকসই বানানোর অনেক কৌশল শিখেছি। Server এর replica রেখেছি, database এর failover সাজিয়েছি, timeout আর circuit breaker বসিয়েছি। কিন্তু একটা প্রশ্ন এখনো বাকি: এগুলো সত্যিই কাজ করে তো?

এই সেশনে আমরা সেই প্রশ্নের উত্তর খোঁজার একটা পদ্ধতি শিখবো। পদ্ধতিটা শুনতে একটু অদ্ভুত: নিজের system নিজেই, ইচ্ছে করে, নিয়ম মেনে ভাঙা। শেষে আপনি বুঝবেন, কেন বড় বড় কোম্পানি এটা নিয়মিত করে, আর একটা নতুন team কীভাবে নিরাপদে শুরু করতে পারে।

০১ “আমাদের সবকিছুর ২ টা replica আছে” বললেই কি failover কাজ করবে?

বৃহস্পতিবার, বিকেল ঠিক তিনটা। Meeting room এ ছয়জন মানুষ, সবার চোখ দেয়ালের বড় screen এ। তাসনিম mouse এ হাত রেখে বললো, “Primary database বন্ধ করছি।” তারপর click করলো। Payment success rate এর সবুজ রেখাটা ঝপ করে নিচে নেমে গেলো। কেউ ঘাবড়ালো না, কারণ সবাই জানে replica এক মিনিটের মধ্যে দায়িত্ব নিয়ে নেবে। এক মিনিট গেলো। তিন মিনিট গেলো। পাঁচ মিনিটের মাথায় ঘরটা একদম চুপ হয়ে গেলো। রেখাটা আবার উপরে উঠলো ঠিক এগারো মিনিট পরে।

তাসনিম একটা bill payment application এর backend team এ কাজ করে। মানুষ এই application দিয়ে বিদ্যুৎ, গ্যাস আর internet এর bill দেয়। Team এর একটা গর্বের কথা ছিলো: “আমাদের সবকিছুর ২ টা করে replica আছে।” Load balancer দুইটা (সেশন ০২), app server ছয়টা, আর database এর একটা primary আর একটা replica (সেশন ০৩)। কাগজে কলমে কোথাও কোনো SPOF নেই। SPOF (single point of failure) মানে এমন একটা অংশ, যেটা একা বন্ধ হলেই পুরো system বন্ধ হয়ে যায় (সেশন ০১)।

এই game day এর তিন সপ্তাহ আগে, এক standup meeting এ, senior engineer অর্ণব একটা ছোট প্রশ্ন করেছিলেন: “Failover শেষ কবে নিজের চোখে দেখেছেন?” কেউ উত্তর দিতে পারেনি। শেষবার test হয়েছিলো আট মাস আগে, তাও staging এ। এর মধ্যে code বদলেছে, configuration বদলেছে, traffic তিন গুণ হয়েছে।

Replica থাকা আর failover কাজ করা এক কথা নয়। Replica মানে শুধু একটা দ্বিতীয় machine, যেটা তৈরি হয়ে বসে আছে। Failover ঠিকমতো হতে হলে তিনটা কাজ পরপর ঠিকঠাক হতে হয়:

1. ধরা পড়া (detection): কেউ একজনকে বুঝতে হবে যে primary আর সাড়া দিচ্ছে না।
2. দায়িত্ব বদল (promotion): Replica কে নতুন primary বানাতে হবে, যাতে সে write নিতে পারে।
3. পথ বদল (rerouting): সব app server কে জানাতে হবে যে এখন থেকে নতুন primary তে যেতে হবে।

এই তিনটার যেকোনো একটা ধীর হলে, বা ভুল হলে, পুরো failover আটকে যায়। আর কোনটা ভুল, সেটা আপনি জানতে পারবেন শুধু তখনই, যখন সত্যিই primary বন্ধ হবে।

০২ Staging এ failover test পাস করলে production নিয়ে নিশ্চিন্ত থাকা যায় না কেন?

Staging হলো production এর একটা ছোট নকল। নতুন code release এর আগে এখানে চালিয়ে দেখা হয়। আট মাস আগে তাসনিমের team staging এ primary বন্ধ করেছিলো, আর failover হয়েছিলো ৪০ সেকেন্ডে। তাহলে production এ এগারো মিনিট লাগলো কেন?

কারণ staging দেখতে production এর মতো, কিন্তু ভেতরে অনেক পার্থক্য:

তালিকার প্রতিটা পার্থক্য দেখতে ছোট। কিন্তু failure ঠিক এই ছোট জায়গাগুলোতেই লুকিয়ে থাকে। যেমন DNS TTL এর লাইনটা দেখুন। DNS নাম থেকে server এর address বের করে দেয় (সেশন ০৬)। আর TTL হলো একটা উত্তর কতক্ষণ মনে রাখা যাবে, তার মেয়াদ (সেশন ০৪)। Staging এ TTL শূন্য, তাই address বদলালেই সবাই সাথে সাথে নতুনটা পায়। Production এ TTL ৩০০ সেকেন্ড, তাই app server গুলো পাঁচ মিনিট ধরে পুরোনো address টাই ব্যবহার করতে থাকে। Staging এর test এই পাঁচ মিনিটের দেখা কখনো পায়নি।

আরেকটা সমস্যার নাম configuration drift। শুরুতে staging আর production এর setting এক থাকে। তারপর production এ কেউ একটা timeout বাড়ায়, কেউ একটা নতুন setting যোগ করে, কিন্তু staging এ সেটা আর করা হয় না। মাসের পর মাস এভাবে দুটো ধীরে ধীরে আলাদা হয়ে যায়।

এছাড়া production এ আসল user থাকে, আসল bank আর SMS provider এর সাথে আসল সংযোগ থাকে। Staging এ এগুলোর বেশিরভাগই নকল (mock) দিয়ে চালানো হয়।

০৩ Chaos engineering কী, আর Chaos Monkey কোথা থেকে এলো?

অফিসের fire drill

অনেক অফিসে বছরে একবার fire drill হয়। কোথাও আগুন লাগেনি, তবু হঠাৎ alarm বাজে। সবাই কাজ ফেলে সিঁড়ি দিয়ে নেমে মাঠে জড়ো হয়। এই মহড়াতেই অনেক কিছু ধরা পড়ে। হয়তো জরুরি সিঁড়ির দরজায় তালা দেওয়া। হয়তো নতুন কর্মীরা জানেনই না কোথায় জড়ো হতে হবে। আগুনের দিনে এগুলো জানলে অনেক দেরি হয়ে যায়।

Software এর fire drill এর নামই chaos engineering। এখানে ইচ্ছে করে, নিয়ন্ত্রিতভাবে system এ একটা failure ঢোকানো হয়। তারপর দেখা হয় system টা কেমন আচরণ করে। উদ্দেশ্য একটাই: আসল failure আসার আগেই দুর্বলতা খুঁজে বের করা।

নামে “chaos” (বিশৃঙ্খলা) থাকলেও কাজটা খুব গোছানো। এটা আসলে একটা বৈজ্ঞানিক experiment, ঠিক school এর বিজ্ঞান ক্লাসের মতো। আগে মাপা, তারপর অনুমান লেখা, তারপর পরীক্ষা, শেষে মিলিয়ে দেখা:

পরের তিনটা section এ এই চক্রের প্রতিটা ধাপ আলাদা করে দেখবো।

Chaos Monkey: শুরুর গল্প

২০০৮ সালে Netflix এর একটা database এ data corrupt হয়ে যায়। তখন Netflix ডাকে DVD পাঠাতো। এই এক ঘটনায় তিন দিন তারা কোনো DVD পাঠাতে পারেনি। এরপর Netflix নিজেদের data center ছেড়ে AWS cloud এ যাওয়া শুরু করে।

Cloud এ একটা নতুন বাস্তবতা ছিলো: যেকোনো server যেকোনো সময় হারিয়ে যেতে পারে। Netflix এর engineer রা ঠিক করলেন, এই failure এর জন্য অপেক্ষা না করে তাঁরা নিজেরাই এটা ঘটাবেন। তাঁরা বানালেন Chaos Monkey, একটা tool যেটা production এর random server বন্ধ করে দেয়। মজার ব্যাপার হলো, এটা চলে শুধু কাজের দিনে, অফিসের সময়ে। কারণ তখন engineer রা জেগে থাকেন, আর কিছু ভাঙলে সাথে সাথে ঠিক করতে পারেন।

ফল হলো চমৎকার। প্রতিদিন server হারাতে হারাতে team গুলো এমন service বানাতে শিখলো, যেটা একটা server চলে গেলে টেরই পায় না।

পরে আরো “বানর” যোগ হয়। Latency Monkey ইচ্ছে করে network এ দেরি ঢোকায়। Chaos Gorilla একটা পুরো availability zone বন্ধ করে দেয় (zone কী, সেটা section ০৫ এ দেখবো)। ২০১২ সালে Netflix Chaos Monkey কে open source করে দেয়। আজ AWS Fault Injection Service, Gremlin বা Chaos Mesh এর মতো tool দিয়ে যেকোনো team এই কাজ করতে পারে।

০৪ একটা experiment এর steady state আর hypothesis কীভাবে লিখবো?

Steady state: স্বাভাবিক দেখতে কেমন

কিছু ভাঙার আগে জানতে হবে, ঠিক থাকা অবস্থায় system দেখতে কেমন। এই স্বাভাবিক অবস্থাকে একটা মাপা যায় এমন সংখ্যায় লিখে ফেলাকে বলে steady state।

এখানে একটা সাধারণ ভুল হয়। অনেকে steady state হিসেবে machine এর সংখ্যা বেছে নেন, যেমন CPU বা memory। কিন্তু user CPU দেখে না। User দেখে তার payment হলো কিনা। তাই steady state হওয়া উচিত এমন একটা সংখ্যা, যেটা user এর অভিজ্ঞতা সরাসরি বলে দেয়:

p99 latency মানে, ১০০ টা request এর মধ্যে ৯৯ টা এই সময়ের মধ্যে শেষ হয় (percentile এর বিস্তারিত সেশন ১৯ এ)। Netflix ও steady state হিসেবে user এর দিক থেকে একটা সংখ্যা দেখে: প্রতি সেকেন্ডে কতজন একটা video চালু করলো।

Hypothesis: পরীক্ষার আগে অনুমান লিখে ফেলা

Hypothesis হলো experiment এর আগে লিখে রাখা একটা অনুমান। এর গঠন সাধারণত এমন: “X ঘটলে steady state Y এর মধ্যে থাকবে।” ভালো hypothesis কে ভুল প্রমাণ করা যায়। “System মোটামুটি ঠিক থাকবে” ভুল প্রমাণ করা যায় না, তাই এটা hypothesis নয়। “৬০ সেকেন্ডের মধ্যে success rate আবার ৯৯% এর উপরে উঠবে” ভুল প্রমাণ করা যায়।

তাসনিমের team game day এর এক সপ্তাহ আগে এই কাগজটা লিখেছিলো:

Experiment #1: Primary DB failover
তারিখ: বৃহস্পতিবার, বিকেল 3:00 থেকে 3:15

Steady state (গত চার বৃহস্পতিবার, একই সময়ে):
  traffic             ~150 request/s
  payment success     99.7%
  p99 latency         350ms

Hypothesis:
  Primary DB বন্ধ করলে 60 সেকেন্ডের মধ্যে replica primary হবে।
  এই 60 সেকেন্ডের পর success rate আবার 99% এর উপরে উঠবে।

Fault:
  Primary DB এর machine টা বন্ধ করা (replica ছোঁয়া হবে না)

Abort condition:
  success rate টানা 2 মিনিট 95% এর নিচে থাকলে experiment থামবে

Abort action:
  পুরোনো primary আবার চালু করা

খেয়াল করুন, steady state এর সংখ্যাগুলো এসেছে গত চার বৃহস্পতিবারের একই সময় থেকে। এই পুরোনো দিনগুলো এখানে তুলনার ভিত্তি। বড় system এ আরো ভালো উপায় আছে। User দের দুই দলে ভাগ করা হয়। Control group এর উপর কিছুই করা হয় না। Experiment group এর উপর fault ঢোকানো হয়। একই সময়ে দুই দলের সংখ্যা পাশাপাশি রাখলে যে পার্থক্য দেখা যায়, সেটা fault এর কারণেই। এই কারণেই একে বলে controlled experiment।

০৫ Fault injection এ কোন কোন failure ঢোকানো যায়?

ইচ্ছে করে system এ একটা নির্দিষ্ট failure ঢোকানোকে বলে fault injection। প্রতিটা fault বাস্তবের কোনো একটা ঘটনাকে নকল করে। সবচেয়ে প্রচলিত পাঁচটা:

• Instance kill: একটা server বন্ধ করে দেওয়া। দেখা হয়, load balancer health check দিয়ে সেটাকে বাদ দেয় কিনা (সেশন ০২), আর বাকি server গুলো তার ভাগের traffic সামলাতে পারে কিনা।
• Latency যোগ: কোনো একটা call কে ইচ্ছে করে ধীর করে দেওয়া, যেমন SMS provider এর প্রতিটা উত্তরে বাড়তি 500ms। দেখা হয়, timeout আর circuit breaker ঠিক সময়ে কাজ করে কিনা (সেশন ২১)।
• Packet drop: Network এ পাঠানো তথ্যের ছোট ছোট টুকরোকে বলে packet। এখানে ১০০ টা packet এর ৫ টা ইচ্ছে করে হারিয়ে ফেলা হয়। দেখা হয়, retry গুলো ঠিকমতো হয় কিনা, আর latency কতটা বাড়ে।
• Disk ভরানো: একটা server এর disk প্রায় ভরে ফেলা। দেখা হয়, disk শেষ হওয়ার আগে alert আসে কিনা, আর application টা ভদ্রভাবে থামে নাকি হঠাৎ crash করে।
• Zone down: Cloud এর একটা region এর ভেতরে কয়েকটা আলাদা data center থাকে, যাদের বিদ্যুৎ আর network আলাদা। এর প্রতিটাকে বলে availability zone। এখানে একটা পুরো zone বন্ধ ধরে নেওয়া হয়।

Zone down এর হিসাবটা দেখুন

তাসনিমের ছয়টা app server তিনটা zone এ ছড়ানো, প্রতি zone এ দুইটা করে। প্রতিটা server সর্বোচ্চ 250 request/s সামলাতে পারে। একটা zone বন্ধ হলে থাকে চারটা server, মানে 4 × 250 = 1,000 request/s। দুপুরের 150 request/s এর জন্য এটা অনেক বেশি। কিন্তু ঈদের আগের রাতে traffic ওঠে 1,200 request/s এ। তখন 1,000 দিয়ে কুলাবে না। কাগজে redundancy আছে, কিন্তু যথেষ্ট capacity নেই। এই হিসাবটা চোখে পড়ে শুধু তখনই, যখন কেউ zone down এর কথা সত্যিই ভাবে।

০৬ Blast radius কী, আর সেটা কীভাবে ছোট রাখবো?

নতুন একটা তরকারিতে লবণ ঠিক হলো কিনা, সেটা দেখতে কেউ পুরো হাঁড়ি খেয়ে ফেলে না। এক চামচ চেখে দেখে। লবণ বেশি হলে নষ্ট হয় শুধু ঐ এক চামচ।

Chaos experiment এও একই নিয়ম। Experiment টা ভুল হলে ক্ষতি কতদূর ছড়াবে, তার পরিধিকে বলে blast radius। কতজন user এর উপর প্রভাব পড়বে, কয়টা service এ, কতক্ষণ ধরে, এই সবকিছু মিলিয়ে blast radius।

Blast radius ছোট রাখার চারটা উপায় আছে:

1. কম জিনিস: ছয়টা server এর মধ্যে মাত্র একটা বন্ধ করুন। পাঁচটা ঠিক থাকলে ক্ষতি সীমিত থাকে।
2. কম user: প্রথমে মাত্র ১% user এর request এ fault ঢোকান। নতুন কিছু প্রথমে অল্প কিছু user এর উপর চালানোর এই কৌশলকে বলে canary।
3. কম সময়: আগে থেকে সর্বোচ্চ সময় ঠিক করুন, যেমন ১০ মিনিট। সময় শেষ হলে experiment নিজে থেকেই থামবে।
4. কম ভিড়ের সময়: দুপুর তিনটায় traffic 150 request/s, ঈদের আগের রাতে 1,200। কম ভিড়ের সময় বেছে নিলে একই ভুলে আট ভাগের এক ভাগ মানুষ ভোগে।

এবার তাসনিমের প্রথম experiment টা আবার দেখুন। Primary database এর উপর সব user, সব payment নির্ভর করে। মানে প্রথম দিনেই তারা সবচেয়ে বাইরের রিং টা বেছে নিয়েছিলো। সময় আর ভিড়ের দিক থেকে তারা সাবধান ছিলো, কিন্তু জিনিস আর user এর দিক থেকে ছিলো না। পেছন ফিরে দেখলে, প্রথম experiment হিসেবে এটা অনেক বড় ছিলো।

০৭ একটা game day কীভাবে চলে?

আগে থেকে ঠিক করা একটা দিন, যেদিন পুরো team একসাথে বসে ইচ্ছে করে একটা failure ঘটায়, দেখে, আর শেখে, তাকে বলে game day। অফিসের fire drill এর দিনটার মতো। সবাই জানে কী হতে যাচ্ছে, সবাই তৈরি থাকে।

চলার সময় চারজন মানুষের চারটা আলাদা দায়িত্ব থাকে:

• Lead: পুরো experiment এর দায়িত্বে। Abort করার সিদ্ধান্ত তাঁর।
• Operator: যিনি নিজের হাতে fault ঢোকান আর বন্ধ করেন। তাসনিম ছিলো এই দায়িত্বে।
• Observer: Dashboard এর দিকে চোখ রাখেন, আর সংখ্যা বদলালেই জোরে বলেন।
• Scribe: প্রতিটা ঘটনা সময় ধরে লিখে রাখেন। পরে এই লেখা থেকেই timeline বানানো হয়।

Game day এর পরে একটা blameless postmortem হয়, মানে এমন একটা আলোচনা যেখানে কাউকে দোষ না দিয়ে শুধু কারণ খোঁজা হয় (বিস্তারিত সেশন ২০ এ)।

তাসনিমের এগারো মিনিট, মিনিট ধরে ধরে

Scribe এর লেখা থেকে বানানো timeline টা এমন:

এগারো মিনিটের পেছনে কোনো একটা বড় ভুল ছিলো না। ছিলো চারটা ছোট ভুল, যেগুলো একটা আরেকটার উপর জমেছে:

1. ধীর detection: Health check প্রতি ৩০ সেকেন্ডে একবার চলতো, আর টানা তিনবার fail না হলে কেউ কিছু করতো না। শুধু ধরা পড়তেই লাগলো ৯০ সেকেন্ড।
2. লম্বা DNS TTL: Replica primary হওয়ার পর DNS record বদলানো হলো। কিন্তু TTL ৩০০ সেকেন্ড হওয়ায় app server গুলো পাঁচ মিনিট ধরে পুরোনো address এই যেতে থাকলো।
3. পুরোনো connection আঁকড়ে থাকা pool: প্রতিবার database এর সাথে নতুন connection খুলতে সময় লাগে। তাই application কিছু connection খুলে রাখে আর বারবার ব্যবহার করে। এই সংগ্রহকে বলে connection pool। DNS ঠিক হওয়ার পরও pool টা পুরোনো, অচল connection গুলো ফেলে দেয়নি। প্রতিটা request ৩০ সেকেন্ড অপেক্ষা করে তারপর fail করছিলো। শেষে server restart করে pool খালি করতে হলো।
4. অচল abort action: এটার গল্প section ০৮ এ।

একই এগারো মিনিট graph এ দেখতে এমন:

এই experiment এর দাম কত পড়লো

তাসনিমের মন খারাপ হয়েছিলো। প্রায় ৮৯,০০০ payment request fail করেছে, অনেক মানুষকে আবার চেষ্টা করতে হয়েছে। কিন্তু অর্ণব তাকে একটা হিসাব দেখালেন:

Game day এর দাম (বৃহস্পতিবার, দুপুর 3 টা):
  traffic              150 request/s
  সময়                  11 মিনিট = 660 সেকেন্ড
  মোট request          150 x 660        = 99,000
  fail হলো (~90%)                       = ~89,000

একই failure ঈদের আগের রাতে, রাত 2 টায় ঘটলে:
  traffic              1,200 request/s
  কেউ জেগে নেই, ধরা পড়তে আরো ~20 মিনিট
  সময়                  11 + 20 = 31 মিনিট = 1,860 সেকেন্ড
  মোট request          1,200 x 1,860    = 22,32,000
  fail হতো (~90%)                       = ~20 লাখ

Error budget (SLO 99.9%, এক মাস):
  মাসে মোট মিনিট       30 x 24 x 60     = 43,200
  0.1% খারাপ সময়        43,200 x 0.001   = 43.2 মিনিট
  game day খরচ করলো    11 / 43.2        = ~25%

Game day এ ক্ষতি হয়েছে ঠিকই, কিন্তু সেটা ছিলো দিনের আলোয়, কম ভিড়ের সময়ে, সবাই চোখ রেখে বসে থাকা অবস্থায়। একই দুর্বলতা ঈদের রাতে নিজে থেকে ধরা পড়লে ক্ষতি হতো প্রায় বাইশ গুণ। Error budget এর হিসাবও আছে। Error budget হলো SLO এর ভেতরে মাসে যতটুকু খারাপ সময় মেনে নেওয়া যায় (সেশন ২০)। এই team এর SLO ৯৯.৯%, তাই মাসে ৪৩ মিনিটের মতো খারাপ সময় চলে। Game day সেই budget এর এক চতুর্থাংশ খরচ করেছে, ইচ্ছে করে, একটা শিক্ষা কিনতে।

Game day এর পরে যা বদলালো

Postmortem থেকে পাঁচটা fix এলো, প্রতিটার একজন owner:

তিন সপ্তাহ পরে team একই experiment আবার চালালো। এবার failover হলো ৪৮ সেকেন্ডে। Hypothesis টিকে গেলো।

০৮ Abort condition কী, আর abort action নিজেই অচল হলে কী হয়?

Abort condition হলো আগে থেকে লেখা একটা সীমা। Experiment চলার সময় সেই সীমা পার হলেই experiment থামবে, কারো মতামতের অপেক্ষা না করে। কয়েকটা উদাহরণ:

• Payment success rate টানা ২ মিনিট ৯৫% এর নিচে।
• p99 latency টানা ১ মিনিট ২ সেকেন্ডের বেশি।
• Customer support এ হঠাৎ অভিযোগ বেড়ে যাওয়া।
• মাসের error budget এর ২০% এর বেশি খরচ হয়ে যাওয়া।

আর সীমা পার হলে যা করা হয়, তাকে বলে abort action: fault বন্ধ করে system কে আগের অবস্থায় ফিরিয়ে আনা। ভালো abort action একটা মাত্র command, যেটা যে কেউ এক সেকেন্ডে চালাতে পারে।

যখন abort action নিজেই অচল

তাসনিমের team এর abort condition ঠিক ছিলো, আর সেটা কাজও করেছিলো। ০০:১০ এ success rate ৯৫% এর নিচে নামলো, ০২:১০ এ দুই মিনিট পূর্ণ হলো। Lead বললেন, “Abort।” তাসনিম abort action এর কাগজটা খুললো: “পুরোনো primary আবার চালু করা।”

ঠিক তখনই অর্ণব থামালেন। দশ সেকেন্ড আগে, ০২:০০ এ, replica নতুন primary হয়ে গেছে। এখন পুরোনো primary চালু করলে একসাথে দুটো primary থাকবে। কিছু app server পুরোনোটায় write করবে, কিছু নতুনটায়। দুই জায়গার data আলাদা হয়ে যাবে, আর কোনটা সঠিক, সেটা বলার উপায় থাকবে না। এই অবস্থার নাম split brain (সেশন ০৩)। Payment এর data নিয়ে এই ঝুঁকি নেওয়া যায় না। তাই team কে সামনের দিকেই এগোতে হলো, আর বাকি নয় মিনিট ভুগতে হলো।

শিক্ষাটা পরিষ্কার। Abort action টা experiment এর শুরুতে কাজ করতো, কিন্তু দুই মিনিট পরে আর করতো না। এখন তাদের abort plan এ দুটো আলাদা action লেখা থাকে। Promotion এর আগে abort করলে পুরোনো primary চালু করা হয়। Promotion এর পরে abort করলে app server গুলোকে জোর করে নতুন primary তে পাঠানো হয়। আর দুটো action ই আগে staging এ চালিয়ে দেখা হয়।

০৯ অভিজ্ঞতা নেই এমন একটা team কোথা থেকে শুরু করবে?

তাসনিমের team প্রথম দিনেই সবচেয়ে বড় experiment টা করেছিলো। আপনার team কে সেটা করতে হবে না। শুরু করার একটা নিরাপদ সিঁড়ি আছে:

1. Tabletop exercise: কোনো system ছোঁয়া হয় না। Team whiteboard এর সামনে বসে আলোচনা করে: “Primary database বন্ধ হলে ঠিক কী কী হবে? কে টের পাবে? কত সেকেন্ডে?” অবাক হওয়ার মতো বিষয় হলো, শুধু এই আলোচনাতেই অনেক দুর্বলতা ধরা পড়ে। তাসনিমের team এটা করলে হয়তো DNS TTL এর কথাটা আগেই কারো মাথায় আসতো।
2. Staging এ ছোট fault: একটা server বন্ধ করে দেখুন। এখানে উদ্দেশ্য hypothesis লেখা, dashboard পড়া আর abort action চালানো অভ্যাস করা।
3. Production এ ছোট fault: কম ভিড়ের সময়ে, পুরো team এর সামনে, ছয়টার মধ্যে একটা app server বন্ধ করুন।
4. বড় experiment: Latency injection, database failover, এরপর একটা zone। প্রতিবার blast radius এক রিং করে বাড়ান।
5. নিয়মিত আর automatic: যে experiment গুলো বারবার পাস করে, সেগুলোকে প্রতি সপ্তাহে নিজে থেকে চলার ব্যবস্থা করুন। তাহলে নতুন code বা configuration কোনো পুরোনো fix নষ্ট করলে সাথে সাথে ধরা পড়বে।

শুরুর আগে যা থাকতেই হবে

• Monitoring: Steady state দেখার মতো dashboard না থাকলে experiment এর ফল কেউ দেখতেই পাবে না (সেশন ২০)।
• Alert আর on-call: কিছু ভাঙলে সাথে সাথে কেউ জানবে, এই ব্যবস্থা থাকতে হবে।
• জানা সমস্যার fix: কোনো দুর্বলতার কথা আগে থেকেই জানা থাকলে, প্রথমে সেটা ঠিক করুন। জানা ভাঙা জিনিস আবার ভেঙে নতুন কিছু শেখা যায় না।

আজ তাসনিমের team এ প্রতি বৃহস্পতিবার দুপুর তিনটায় ১৫ মিনিটের একটা ছোট experiment চলে। কেউ যখন জিজ্ঞেস করে system কতটা নির্ভরযোগ্য, তাসনিম এখন অন্যভাবে উত্তর দেয়: “আমাদের ২ টা replica আছে। আর গত বৃহস্পতিবার নিজের চোখে দেখেছি, failover ৪৮ সেকেন্ডে হয়।”

১০ মগজে প্রেশার দিন

আগে নিজে ভাবুন। তারপর উত্তর খুলে দেখুন: বেশিরভাগ মানুষ কীভাবে ভাবে, সেই চিন্তায় কী বাদ পড়ে, আর আসল কথাটা কোথায়।

১১ যে টার্মগুলো শিখলাম

১২ শর্ট সামারি

১৩ মনে রাখুন

• Test না হওয়া redundancy একটা অনুমান। Failover নিজের চোখে না দেখা পর্যন্ত ধরে নেবেন না যে সেটা কাজ করে।
• Steady state মাপুন user এর সংখ্যায়, machine এর সংখ্যায় নয়। CPU ঠিক থাকলেও payment fail করতে পারে।
• Hypothesis টা experiment এর আগে লিখুন। পরে লিখলে মন ফলাফলের সাথে মিলিয়ে অনুমান বদলে ফেলে।
• সবচেয়ে ছোট blast radius থেকে শুরু করুন। কম জিনিস, কম user, কম সময়, কম ভিড়।
• Abort action টা পুরো experiment জুড়ে কাজ করে কিনা, test করুন। তাসনিমের abort action দুই মিনিট পরেই অচল হয়ে গিয়েছিলো।
• Hypothesis ভুল প্রমাণ হওয়া মানে experiment সফল। আপনি একটা দুর্বলতা পেয়েছেন, আর সেটা পেয়েছেন নিজের বেছে নেওয়া সময়ে।
• Game day শেষ হয় fix দিয়ে, আর fix প্রমাণ হয় পরের game day তে। একই experiment আবার চালিয়ে দেখুন।