9.6 কেওস প্রকৌশল ও স্থিতিস্থাপকতা টেস্টিং

পরিচিতি ও প্রেরণা

কেওস প্রকৌশল হলো প্রোডাকশনে অশান্ত অবস্থা সহ্য করার একটি সিস্টেমের সামর্থ্যে আস্থা গড়তে তার ওপর পরীক্ষা চালানোর শৃঙ্খলাবদ্ধ চর্চা। নামটি বেপরোয়া শোনায়, এবং সেটিই প্রথম যা ভুলতে হবে। কেওস প্রকৌশল এলোমেলোভাবে জিনিস ভেঙে কিছু শেখার আশা করা নয়। এটি উল্টো: বাস্তবসম্মত ব্যর্থতা ঢোকানোর একটি নিয়ন্ত্রিত, অনুমান-চালিত পদ্ধতি যাতে আপনার ব্যবহারকারীদের আগে আপনি দুর্বলতা আবিষ্কার করেন। আপনি ইতিমধ্যে জানেন আপনার সিস্টেম ব্যর্থতার মুখোমুখি হবে, কারণ প্রতিটি প্রকৃত সিস্টেম হয়। একমাত্র প্রশ্ন হলো আপনি সেই ব্যর্থতার মুখোমুখি হবেন একটি মঙ্গলবার বিকেলে রোলব্যাক প্রস্তুত রেখে, নাকি রাত ৩টায় আপনার সবচেয়ে ব্যস্ত ঘণ্টায় কী ঘটছে তার কোনো ধারণা ছাড়াই।

বড় দলের জন্য এটি গুরুত্বপূর্ণ কারণ জটিলতা পরিদর্শনে যুক্তি করার যে কারও সামর্থ্য ছাড়িয়ে গেছে। একটি আধুনিক সেবা ডজন ডজন বা শত শত উপাদানের জাল, প্রতিটির নিজস্ব টাইমআউট, পুনঃচেষ্টা, ক্যাশ ও ব্যর্থতার ধরন, এবং তাদের মধ্যকার ক্রিয়া এমন উদ্ভূত আচরণ তৈরি করে যা কোনো স্থাপত্য ডায়াগ্রাম পূর্বাভাস দেয় না। আপনি কোড পর্যালোচনা করতে, বাক্স আঁকতে পারেন এবং তবু অন্ধ হয়ে যেতে পারেন যখন একটি ধীর নির্ভরতা একটি পুনঃচেষ্টা ঝড় ট্রিগার করে যা তিন হপ দূরের একটি সেবা নামিয়ে দেয়। কেওস প্রকৌশল হলো আপনি সেই ক্রিয়া অভিজ্ঞতাভিত্তিকভাবে কীভাবে খোঁজেন, যাতে আপনার স্থিতিস্থাপকতা আপনি ধরে নেওয়া কিছুর বদলে যাচাই করা কিছু হয়।

এন্টারপ্রাইজ ও সরকারি প্রেক্ষাপট ঝুঁকি, এবং ক্রমশ আদেশ, বাড়ায়। আর্থিক নিয়ন্ত্রকরা এখন প্রত্যাশা করেন প্রতিষ্ঠান কঠোর-কিন্তু-সম্ভাব্য দৃশ্যকল্পের বিপরীতে পরিচালনগত স্থিতিস্থাপকতা পরীক্ষা করবে এবং প্রমাণ করবে তারা বিঘ্নের মধ্য দিয়ে জটিল সেবা চালু রাখতে পারে। সরকারি সংস্থা কার্যক্রম-ধারাবাহিকতা অনুশীলন চালায় যাতে অপরিহার্য জনসেবা বিভ্রাট, দুর্যোগ ও সাইবার আক্রমণ টিকে থাকে। দুই জগতেই “আমরা মনে করি এটি টিকবে” একজন নিরীক্ষক বা নাগরিকের কাছে গ্রহণযোগ্য উত্তর নয়। কেওস প্রকৌশল আপনাকে প্রমাণ দেয়। এই অধ্যায় সাইট নির্ভরযোগ্যতা প্রকৌশল (অধ্যায় 9.1) এবং অধ্যায় 3.5-এর স্থিতিস্থাপকতা প্যাটার্নের ওপর গড়ে, এবং ঘটনা ব্যবস্থাপনা (অধ্যায় 9.3) ও দুর্যোগ পুনরুদ্ধার (অধ্যায় 9.5)-র সঙ্গে আঁটোভাবে যুক্ত।

মূল নীতিসমূহ

• আস্থা গড়ুন, বিশৃঙ্খলা তৈরি করবেন না। লক্ষ্য যাচাইকৃত স্থিতিস্থাপকতা, দৃশ্য নয়। প্রতিটি পরীক্ষা চাপের মধ্যে সিস্টেম কীভাবে আচরণ করে সে সম্পর্কে একটি নির্দিষ্ট প্রশ্নের উত্তর দেয়।
• আগে স্থির অবস্থা সংজ্ঞায়িত করুন। “সুস্থ” দেখতে কেমন তার একটি স্পষ্ট, পরিমাপযোগ্য সংজ্ঞা ছাড়া আপনি সমস্যা শনাক্ত করতে পারেন না।
• একটি অনুমান গঠন করুন। ত্রুটি ঢোকানোর আগে আপনি কী ঘটবে আশা করেন তা বলুন। একটি বিস্ময় একটি আবিষ্কার; এর অনুপস্থিতিও একটি আবিষ্কার।
• ক্ষতির পরিসর ন্যূনতম ও সীমিত করুন। ছোট থেকে শুরু করুন, প্রকৃত ব্যবহারকারীদের রক্ষা করুন, এবং আস্থা বাড়লেই কেবল পরিসর প্রসারিত করুন।
• সাবধানে প্রোডাকশন পছন্দ করুন। প্রকৃত ট্রাফিক, প্রকৃত ডেটা ও প্রকৃত পরিসরে ব্যর্থতা ভিন্নভাবে আচরণ করে। সেখানে পরীক্ষার অধিকার অর্জন করুন।
• নিরন্তর যাচাইয়ের দিকে স্বয়ংক্রিয় করুন। একবার সারানো দুর্বলতা রিগ্রেস করতে পারে। নিরন্তর পরীক্ষিত স্থিতিস্থাপকতা সত্য থাকে।
• ব্যর্থতা শিক্ষক, রায় নয়। আবিষ্কার সিস্টেম উন্নত করে; পরীক্ষা চালানো ব্যক্তিকে দোষ দেওয়ার কারণ কখনো নয়।

সুপারিশ

একটি ত্রুটিও ঢোকানোর আগে পূর্বশর্ত স্থাপন করুন

কেওস প্রকৌশল একটি পরিণত সিস্টেমের জন্য শক্তি গুণক এবং একটি অপরিণতের জন্য দায়। শুরুর আগে আপনার তিনটি জিনিস জায়গায় দরকার। প্রথমত, পর্যবেক্ষণযোগ্যতা, মানে মেট্রিক, লগ ও ট্রেস যা আপনাকে বাইরে থেকে দেখতে দেয় সিস্টেম কী করছে, কারণ আপনি পর্যবেক্ষণ করতে পারেন না এমন একটি পরীক্ষা আপনাকে কিছুই শেখায় না। দ্বিতীয়ত, সেবা-স্তরের উদ্দেশ্য বা স্থির-অবস্থা স্বাস্থ্যের সমতুল্য সংজ্ঞা (অধ্যায় 9.1), যাতে আপনি রিয়েল-টাইমে একটি সফল পরীক্ষা ও ক্ষতিকর একটির পার্থক্য বলতে পারেন। তৃতীয়ত, একটি দ্রুত ও বিশ্বস্ত রোলব্যাক বা বাতিল পথ, যাতে একটি পরীক্ষা প্রকৃত ব্যবহারকারীদের হুমকি দিলে আপনি তা থামাতে এবং সেকেন্ডে স্বাভাবিক সেবা ফিরিয়ে আনতে পারেন। আপনি যদি আপনার সিস্টেম মাপতে, তার সুস্থ অবস্থা সংজ্ঞায়িত করতে এবং তাকে কিনারা থেকে ফিরিয়ে আনতে না পারেন, এখনো কেওস পরীক্ষা চালাবেন না। আগে সেই সামর্থ্য গড়ুন। সেগুলো যাই হোক নিজেদের খরচ তোলে।

স্থির অবস্থা সংজ্ঞায়িত করুন এবং একটি প্রকৃত অনুমান গঠন করুন

প্রতিটি পরীক্ষা শুরু হয় স্বাভাবিক দেখতে কেমন তা পরিমাপযোগ্য ভাষায় লিখে রাখা দিয়ে: অনুরোধ সাফল্য হার ৯৯.৯ শতাংশের ওপরে, চেকআউট বিলম্ব ৯৫তম পার্সেন্টাইলে ৪০০ মিলিসেকেন্ডের নিচে, সারি গভীরতা একটি সীমার নিচে। এটি আপনার স্থির-অবস্থা সংজ্ঞা, এবং এটি অভ্যন্তরীণ নলকূপ নয়, ব্যবহারকারী-দৃশ্যমান স্বাস্থ্য প্রতিফলিত করা উচিত। তারপর সহজ ভাষায় একটি অনুমান বলুন: “আমরা সুপারিশ সেবায় ৩০০ মিলিসেকেন্ড বিলম্ব যোগ করলে পণ্য পেজ তার বিলম্ব বাজেটের মধ্যে রেন্ডার হবে কারণ পেজ সুপারিশকে ঐচ্ছিক গণ্য করে এবং ২০০ মিলিসেকেন্ডের পর টাইমআউট করে।” এখন আপনার একটি মিথ্যাপ্রমাণযোগ্য দাবি আছে। আপনি পরীক্ষা চালালে দুটি ভালো জিনিসের একটি ঘটে। হয় সিস্টেম পূর্বাভাস অনুযায়ী আচরণ করে এবং আপনার আস্থা অর্জিত হয়, নয়তো তা করে না এবং আপনি আপনার নিজস্ব শর্তে, ইঞ্জিনিয়াররা দেখছে অবস্থায়, সস্তায় একটি প্রকৃত দুর্বলতা খুঁজে পান।

বাস্তবসম্মত ত্রুটি ঢোকান, নির্বিচার নয়

আপনি যে ত্রুটি ঢোকান তা আপনার সিস্টেম আসলে যে ব্যর্থতার মুখোমুখি হয় তা অনুকরণ করা উচিত। ত্রুটি ইনজেকশন, একটি সিস্টেম কীভাবে সাড়া দেয় পরীক্ষা করতে ইচ্ছাকৃতভাবে ত্রুটি ঢোকানো, আপনাকে প্রকৃত প্রোডাকশন ঘটনা থেকে আঁকা একটি মেনু দেয়। একটি ধীর নির্ভরতা বা সম্পৃক্ত নেটওয়ার্ক লিংক অনুকরণ করতে বিলম্ব ঢোকান। একটি ব্যর্থ নিম্নধারা সেবা অনুকরণ করতে HTTP 500 বা সংযোগ প্রত্যাখ্যান ফেরত দিয়ে ত্রুটি ঢোকান। চাপের অধীনে সিস্টেম কীভাবে অবনমিত হয় দেখতে CPU, মেমরি, ডিস্ক বা ফাইল বর্ণনাকারী খরচ করে রিসোর্স নিঃশেষ ঢোকান। একটি পুরো ডেটাবেস, ক্যাশ, সারি বা তৃতীয়-পক্ষ API নাগালের বাইরে করে নির্ভরতা ব্যর্থতা ঢোকান। একটি বিতরিত সিস্টেমে, যেখানে উপাদান আলাদা মেশিনে চলে এবং একটি অনির্ভরযোগ্য নেটওয়ার্কের ওপর যোগাযোগ করে, এই ব্যর্থতাই প্রকৃত বিভ্রাটে প্রাধান্য পায়। পরিষ্কার ক্র্যাশ নয়, বিলম্ব ও আংশিক ব্যর্থতাই বাস্তবে জিনিস ভাঙে, তাই আপনার পরীক্ষা অগোছালো মাঝামাঝির দিকে ভারী করুন।

যাচাই করুন যে আপনার স্থিতিস্থাপকতা যন্ত্র আসলে কাজ করে

এখানেই কেওস প্রকৌশল তার জীবিকা অর্জন করে। আপনার সিস্টেম এমন যন্ত্রে ভরা যেগুলো আপনাকে রক্ষা করার কথা: একজন কলারকে চিরকাল অপেক্ষা করা থেকে ঠেকানো টাইমআউট, ক্ষণস্থায়ী ঝলক ঢাকা পুনঃচেষ্টা, একটি ব্যর্থ নির্ভরতাকে পেটানো বন্ধ করা সার্কিট ব্রেকার, এবং প্রাথমিক মরলে একটি স্ট্যান্ডবাইয়ে স্যুইচ করা ফেইলওভার। অধ্যায় 3.5-এ ঢাকা এই প্যাটার্ন একটি সীমিত সমস্যা ও একটি ধাপে ধাপে বিভ্রাটের পার্থক্য। সমস্যা হলো এগুলো কদাচিৎ সেই অবস্থায় পরীক্ষিত যার জন্য তারা আছে। কলারের নিজস্ব সময়সীমা ২ সেকেন্ড হলে ৩০ সেকেন্ডে ঠিক করা টাইমআউট কিছুই করে না। ব্যাকঅফ ছাড়া পুনঃচেষ্টা একটি সংগ্রামরত সেবাকে একটি থান্ডারিং হার্ডে পরিণত করে। কখনো প্রয়োগ না করা একটি সার্কিট ব্রেকার ভুল কনফিগার হয়ে কখনো ট্রিপ না করতে বা ক্রমাগত ট্রিপ করতে পারে। কেওস পরীক্ষা হলো আপনি নিশ্চিত করেন যে এগুলোর প্রতিটি, যে ত্রুটি থেকে রক্ষা করে সেটি আসলে এলে, নকশা অনুযায়ী আচরণ করে। একটি পরীক্ষা প্রমাণ না করা পর্যন্ত প্রতিটি অপরীক্ষিত নিরাপত্তা যন্ত্রকে ভাঙা ধরে নিন।

স্বয়ংক্রিয় করার আগে গেম ডে দিয়ে শুরু করুন

নিরন্তর ত্রুটি ঢোকানো একটি স্বয়ংক্রিয় প্ল্যাটফর্ম দিয়ে শুরু করবেন না। একটি গেম ডে দিয়ে শুরু করুন: একটি নির্ধারিত, হাতে-কলমে অনুশীলন যেখানে একটি দল জড়ো হয়, একটি দৃশ্যকল্প বাছে, একটি নিয়ন্ত্রিত পরিবেশে একটি ত্রুটি ঢোকায়, এবং একসঙ্গে দেখে। তার আগেও, একটি টেবিলটপ অনুশীলন, যেখানে আপনি সিস্টেম না ছুঁয়ে হোয়াইটবোর্ডে একটি দৃশ্যকল্প নিয়ে কথা বলেন, প্রায় কোনো ঝুঁকি ছাড়াই রানবুক, সতর্কতা ও মালিকানার ফাঁক উন্মোচন করে। গেম ডে আপনার অন-র‍্যাম্প। তারা অনুমান গঠন, ক্ষতির পরিসর সীমিত করা এবং চাপের অধীনে সিস্টেম পড়ার পেশি গড়ে, এবং তারা নেতৃত্ব ও প্রতিবেশী দলের আস্থা গড়ে যা প্রোডাকশনে কেউ আপনাকে পরীক্ষা চালাতে দেওয়ার আগে লাগবে। তারা সরাসরি ঘটনা সাড়াও শক্তিশালী করে, কারণ দক্ষতা একই যা আপনার অন-কল ইঞ্জিনিয়াররা একটি প্রকৃত ঘটনার সময় ব্যবহার করেন (অধ্যায় 9.3)। আপনার প্রথম গেম ডে স্টেজিংয়ে চালান, তারপর শান্ত ঘণ্টায় একটি ছোট ক্ষতির পরিসরসহ প্রোডাকশনে, তারপর প্রসারিত করুন।

সুচিন্তিতভাবে ক্ষতির পরিসর সীমিত করুন

একক সবচেয়ে গুরুত্বপূর্ণ নিরাপত্তা চর্চা হলো প্রতিটি পরীক্ষার সম্ভাব্য ক্ষতি সীমিত করা। কিছু শেখাতে পারে এমন ক্ষুদ্রতম পরিসর দিয়ে শুরু করুন: একটি ইনস্ট্যান্স, ট্রাফিকের এক শতাংশ, একটি অ-জটিল নির্ভরতা, একটি প্রাপ্যতা অঞ্চল। শুরুর আগে বাতিলের শর্ত সংজ্ঞায়িত করুন, সেগুলো আপনার স্থির-অবস্থা মেট্রিকে জুড়ুন, এবং পরীক্ষা থামানোকে এমন একটি একক কর্ম করুন যা দেখা যে কেউ ট্রিগার করতে পারে। দল সজাগ ও কর্মী থাকা কর্মঘণ্টায় চালানো পছন্দ করুন, রাতারাতি নয় যখন কেউ না দেখলে একটি বিস্ময় ঘটনা হয়। ছোট পরীক্ষা পরিষ্কারভাবে চলার পর এবং আপনার আস্থা সত্যিই বাড়লে কেবল ক্ষতির পরিসর প্রসারিত করুন। সীমাবদ্ধকরণের শৃঙ্খলাই কেওস প্রকৌশল ও আপনার নিজের ঘটানো বিভ্রাটকে আলাদা করে।

নিরন্তর, স্বয়ংক্রিয় স্থিতিস্থাপকতা যাচাইয়ের দিকে বাড়ুন

মাঝে মাঝের গেম ডে দুর্বলতা খুঁজে পায়, কিন্তু সিস্টেম প্রতিদিন বদলায়, এবং গত ত্রৈমাসিকের একটি সংশোধন নীরবে রিগ্রেস করতে পারে। পরিণত শেষ অবস্থা হলো নিরন্তর যাচাই: বাছাই করা স্থিতিস্থাপকতা পরীক্ষার একটি সেট যা একটি পাইপলাইনে বা সূচিতে স্বয়ংক্রিয়ভাবে চলে, যাতে একটি টাইমআউট, পুনঃচেষ্টা নীতি বা ফেইলওভার পথের রিগ্রেশন পরবর্তী প্রকৃত বিভ্রাটের সময় নয়, দিনের মধ্যে ধরা পড়ে। এখানেই Netflix-এর Chaos Monkey-র মতো টুল, যা ইঞ্জিনিয়ারদের ইনস্ট্যান্স হারানো সহ্য করা সেবা গড়তে বাধ্য করতে প্রোডাকশনে এলোমেলোভাবে ইনস্ট্যান্স বন্ধ করে, তাদের সুনাম অর্জন করেছে। কেবল সেই পরীক্ষা স্বয়ংক্রিয় করুন যা আপনি ম্যানুয়াল চালনা থেকে ইতিমধ্যে বোঝেন ও বিশ্বাস করেন। অপরিণত সিস্টেমের ওপর নিরন্তর কেওস আস্থা নয়, ঘটনা তৈরির উপায়।

পরীক্ষাকে দুর্যোগ পুনরুদ্ধার ও ঘটনা শিক্ষার সঙ্গে জুড়ুন

কেওস প্রকৌশল একা বাস করে না। বড়, বিরল দৃশ্যকল্প, একটি পুরো অঞ্চল হারানো, একটি ডেটাবেস ফেইলওভার, ব্যাকআপ থেকে পুনরুদ্ধার, দুর্যোগ-পুনরুদ্ধার টেস্টিং (অধ্যায় 9.5)-এর অন্তর্ভুক্ত, এবং একটি গেম ডে প্রায়ই সেই পরিকল্পনা অনুশীলনের সেরা বাহন, সেগুলোকে অপরীক্ষিত নথি হিসেবে পচতে দেওয়ার বদলে। অন্য দিকে একটি দুর্বলতা তুলে ধরা প্রতিটি পরীক্ষা একটি প্রকৃত ঘটনার একই শেখার চক্রে জোগান দেওয়া উচিত (অধ্যায় 9.3): একটি দোষারোপহীন লেখা, একটি অনুসরণ করা সংশোধন, এবং সংশোধন টেকে তা নিশ্চিত করার একটি অনুসরণ পরীক্ষা। কেওস আবিষ্কার, দুর্যোগ-পুনরুদ্ধার মহড়া ও ঘটনা পর্যালোচনা যখন সবই স্থিতিস্থাপকতা কাজের একটি ব্যাকলগে প্রবাহিত হয়, আপনি ছড়ানো এককালীন অনুশীলনের বদলে চক্রবৃদ্ধি প্রতিদান পান।

ট্রেড-অফ: সুবিধা ও অসুবিধা

সিদ্ধান্ত	সুবিধা	অসুবিধা
প্রোডাকশনে টেস্টিং	প্রকৃত ট্রাফিক, ডেটা ও পরিসর; আবিষ্কার সত্য	ধারণ ব্যর্থ হলে ব্যবহারকারীদের ঝুঁকি; পরিপক্বতা লাগে
কেবল স্টেজিংয়ে টেস্টিং	নিরাপদ, কম ঝুঁকি, শুরু সহজ	প্রকৃত-জগতের আচরণ মিস করে; মিথ্যা আস্থা
ম্যানুয়াল গেম ডে	দক্ষতা ও আস্থা গড়ে; কম টুলিং খরচ	বিরল; আবিষ্কার অলক্ষিতে রিগ্রেস করতে পারে
নিরন্তর স্বয়ংক্রিয় কেওস	রিগ্রেশন দ্রুত ধরে; স্কেল করে	আগে পরিণত টুলিং ও পর্যবেক্ষণযোগ্যতা লাগে
প্রশস্ত ক্ষতির পরিসর	বড় ব্যবস্থাগত দুর্বলতা প্রকাশ করে	উচ্চ ঝুঁকি; একটি ভুল ঘটনা হয়
সংকীর্ণ ক্ষতির পরিসর	নিরাপদ ও নিয়ন্ত্রণযোগ্য	উদ্ভূত আন্তঃ-সেবা ব্যর্থতা মিস করতে পারে

কেন্দ্রীয় টানাপোড়েন বাস্তবতা ও নিরাপত্তার মধ্যে। আপনি যে আবিষ্কার সবচেয়ে চান তা প্রোডাকশন থেকে আসে, কারণ কেবল সেখানেই আপনার সিস্টেম প্রকৃত ট্রাফিক, প্রকৃত ডেটা ও প্রকৃত পরিসরের মুখোমুখি, তবু প্রোডাকশনই ঠিক সেখানে যেখানে একটি ভুল হওয়া পরীক্ষা ব্যবহারকারীদের ক্ষতি করে। সমাধান এক পক্ষ বাছা নয়। এটি ধীরে ধীরে প্রোডাকশনের দিকে আপনার পথ অর্জন করা: আপনার পূর্বশর্ত প্রমাণ করুন, স্টেজিংয়ে মহড়া দিন, তারপর জীবন্ত মেট্রিকে জুড়ে দেওয়া বাতিলের শর্তসহ প্রোডাকশনে ছোট, ভালো-সীমিত পরীক্ষা চালান, এবং প্রমাণ জমলেই কেবল পরিসর প্রসারিত করুন। অন্য পুনরাবৃত্ত টানাপোড়েন, ম্যানুয়াল বনাম স্বয়ংক্রিয়, সময়ের সঙ্গে একইভাবে সমাধান হয়। বোঝা ও আস্থা গড়তে ম্যানুয়াল দিয়ে শুরু করুন, তারপর আপনি নির্ভর করতে শেখা পরীক্ষা স্বয়ংক্রিয় করুন, যাতে একবার যাচাই করা স্থিতিস্থাপকতা যাচাইকৃত থাকে।

আপনার দলের সঙ্গে আলোচনার প্রশ্ন

1. আমরা কি আসলে কেওস পরীক্ষা চালাতে প্রস্তুত, এবং আমরা তা কীভাবে জানব? ত্রুটি ঢোকানো শুরু করার প্রলোভন আছে কারণ এটি পরিশীলিত শোনায়, কিন্তু অপর্যবেক্ষণযোগ্য, কোনো স্পষ্ট স্বাস্থ্য সংজ্ঞা নেই এবং কোনো দ্রুত রোলব্যাক নেই এমন সিস্টেমে কেওস প্রকৌশল কেবল নিজের ঘটানো ডাউনটাইম। এই আলোচনায় সৎ প্রমাণ আনুন: আপনি কি রিয়েল-টাইমে অনুরোধ সাফল্য হার ও বিলম্ব দেখতে পান, আপনার কি স্থির অবস্থার একটি সম্মত সংজ্ঞা আছে, এবং আপনি কি সেকেন্ডে একটি পরীক্ষা বাতিল ও পুনরুদ্ধার করতে পারেন? একটি বড় দলের জন্য উত্তর প্রায়ই সেবা-ধরে ভিন্ন, তাই দরকারি ফল হলো একটি প্রস্তুতি মান যা একটি সেবাকে পরীক্ষার যোগ্য হতে পেরোতে হয়। নিয়ন্ত্রিত পরিবেশে সেই প্রস্তুতি মান এমন একটি নিয়ন্ত্রণও যা আপনি একজন নিরীক্ষককে দেখাতে পারেন। সৎ উত্তর যদি হয় আপনি প্রস্তুত নন, এই ত্রৈমাসিকে আপনি করতে পারেন সবচেয়ে মূল্যবান কেওস কাজ হলো সেই পর্যবেক্ষণযোগ্যতা ও রোলব্যাক সামর্থ্য গড়া যা আপনাকে প্রস্তুত করে।

2. আমাদের ক্ষতির পরিসর নীতি কী, এবং একটি পরীক্ষা থামানোর কর্তৃত্ব কার? প্রতিটি কেওস পরীক্ষা প্রকৃত ব্যবহারকারীদের কিছু ঝুঁকি বহন করে, এবং একটি মূল্যবান আবিষ্কার ও আপনার ঘটানো ঘটনার পার্থক্য আপনি তা কত আঁটোভাবে সীমিত করেছিলেন। সুনির্দিষ্ট সীমা নিয়ে কথা বলুন: ট্রাফিকের কোন ভগ্নাংশ, কতগুলো ইনস্ট্যান্স, কোন পরিবেশ, দিনের কোন সময়, এবং কোন মেট্রিক সীমা স্বয়ংক্রিয়ভাবে চালনা বাতিল করে। আগে থেকে ঠিক করুন প্রতিটি পরীক্ষা কে দেখছে এবং একক-কর্ম কিল সুইচ কার হাতে, কারণ কেউ দ্রুত থামাতে পারে না এমন পরীক্ষা সীমিত নয়। একটি বড় প্রতিষ্ঠানের জন্য এই নীতিই অনেক দলকে তাদের কোনো একটির দুর্ঘটনাক্রমে ভাগ করা নির্ভরতা না নামিয়ে পরীক্ষা করতে দেয়। উত্তর লিখে রাখা, আপনি যে সেবা প্রভাবিত করতে পারেন সেই দলগুলোর সঙ্গে সম্মত, এবং প্রোডাকশনে কিছু চালানোর পূর্বশর্ত গণ্য করা উচিত।

3. কোন স্থিতিস্থাপকতা যন্ত্র আমরা বিশ্বাস করি আমাদের রক্ষা করে, এবং আমরা কি কখনো সেগুলো আসলে পরীক্ষা করেছি? বেশিরভাগ সিস্টেম টাইমআউট, পুনঃচেষ্টা, সার্কিট ব্রেকার, ক্যাশ ও ফেইলওভার পথে ভরা যা একবার কনফিগার করা হয়েছিল এবং যে ব্যর্থতার জন্য তারা আছে তার অধীনে কখনো প্রয়োগ করা হয়নি। আপনি যার ওপর ভরসা করছেন সেই যন্ত্রের একটি তালিকা বানান, তারপর প্রতিটির জন্য জিজ্ঞেস করুন শেষবার কখন একটি প্রকৃত ঢোকানো ত্রুটির অধীনে কাজ করা যাচাই হয়েছিল। প্রতিদ্বন্দ্বী বিবেচনা সময়: প্রতিটি যন্ত্র যাচাই করা প্রকৌশল প্রচেষ্টা খরচ করে, এবং সবসময় একটি ফিচার সময়সীমা থাকে। সেই আপত্তির পাল্টা প্রমাণ আনুন, মানে একটি অতীত বিভ্রাটের খরচ যা একটি কার্যকর সার্কিট ব্রেকার বা সঠিক টাইমআউট সীমিত করত। উত্তর ধরে-নেওয়া সুরক্ষার একটি আরামদায়ক তালিকাকে পরীক্ষার একটি অগ্রাধিকার ব্যাকলগে পরিণত করা উচিত, যে যন্ত্রের ব্যর্থতা সবচেয়ে বেশি ক্ষতি করবে তা দিয়ে শুরু করে।

4. স্টেজিংয়ের বদলে প্রোডাকশনে একটি পরীক্ষা চালানোর আগে কী সত্য হতে হবে, এবং কোন সেবা আজ সেই অধিকার অর্জন করেছে? আপনি যে আবিষ্কার সবচেয়ে চান তা প্রোডাকশন থেকে আসে, কারণ কেবল সেখানেই আপনার সিস্টেম প্রকৃত ট্রাফিক, প্রকৃত ডেটা ও প্রকৃত পরিসরের মুখোমুখি, তবু প্রোডাকশন সেই একটি জায়গা যেখানে একটি ভুল হওয়া পরীক্ষা প্রকৃত ব্যবহারকারীদের ক্ষতি করে। একটি বড় দলের জন্য সৎ বাস্তবতা হলো ভিন্ন সেবা ভিন্ন প্রস্তুতি স্তরে, তাই একটি ব্লাঙ্কেট “প্রোডাকশন কেওস নয়” নিয়ম আপনার সেরা শিক্ষা অপচয় করে যখন একটি ব্লাঙ্কেট “হ্যাঁ” ঘটানো বিভ্রাট আমন্ত্রণ জানায়। সেবা-ধরে প্রমাণ আনুন: এর পর্যবেক্ষণযোগ্যতার মান, স্থির অবস্থা সংজ্ঞায়িত ও সতর্কযোগ্য কি না, রোলব্যাক কত দ্রুত, এবং এটিকে উন্নীত করা যথার্থ করবে এমন পরিষ্কার স্টেজিং পরীক্ষার ট্র্যাক রেকর্ড। এন্টারপ্রাইজ ও সরকারি পরিবেশে প্রোডাকশন গেটকে একটি নথিবদ্ধ নিয়ন্ত্রণে বাঁধুন যা নাম দেয় কে উন্নয়ন অনুমোদন করে এবং কোন বাতিলের শর্ত জীবন্ত মেট্রিকে জোড়া, যাতে নিরীক্ষক প্রকৃত ব্যবহারকারী নিয়ে একটি দল উদ্ভাবনের বদলে একটি সুচিন্তিত, প্রমাণিত সিদ্ধান্ত দেখেন।

5. একটি কেওস পরীক্ষা একটি দুর্বলতা তুলে ধরলে সেই আবিষ্কার কোথায় যায়, এবং আমরা কীভাবে তা অস্পৃষ্ট পচা থেকে ঠেকাই? যে কর্মসূচি দুর্বলতা আবিষ্কার করে কিন্তু কখনো সারায় না তা কোনো কর্মসূচি না থাকার চেয়ে খারাপ, কারণ এটি প্রচেষ্টা পোড়ায়, আস্থা ক্ষয় করে এবং মানুষকে শেখায় যে পরীক্ষা নাট্য। প্রতিদ্বন্দ্বী চাপ সবসময় ফিচার রোডম্যাপ: একটি স্থিতিস্থাপকতা সংশোধন কদাচিৎ পরবর্তী রিলিজের মতো জরুরি মনে হয় যতক্ষণ না যে বিভ্রাট এটি ঠেকাত তা সত্যিই আসে। আলোচনায় আপনার স্থিতিস্থাপকতা ব্যাকলগের বর্তমান অবস্থা আনুন: কতগুলো কেওস আবিষ্কার খোলা, সবচেয়ে পুরনোটি কত পুরনো, এবং পরীক্ষা, দুর্যোগ-পুনরুদ্ধার মহড়া ও ঘটনা পর্যালোচনার আবিষ্কার একটি ভাগ করা সারিতে প্রবাহিত হয় নাকি দল জুড়ে ছড়ায়। প্রতিটি সংশোধনের মালিক এবং সেটি টেকে তা নিশ্চিত করা অনুসরণ পরীক্ষা কে চালায় তা সম্মত হোন। একটি বড় বা নিয়ন্ত্রিত প্রতিষ্ঠানের জন্য নাম দিন কোন ফোরাম একটি নির্দিষ্ট ছন্দে ব্যাকলগ পর্যালোচনা করে এবং একটি ফিচারের ওপর একটি স্থিতিস্থাপকতা সংশোধনকে অগ্রাধিকার দেওয়ার কর্তৃত্ব ধরে, কারণ কেউ বন্ধ করার জন্য জবাবদিহিযোগ্য নয় এমন একটি আবিষ্কার এমন ঝুঁকি যা আপনি কেবল নথিবদ্ধ করেছেন, সরাননি।

6. আমরা কি আমাদের কোনো পরীক্ষা নিরন্তর যাচাইয়ে স্বয়ংক্রিয় করতে প্রস্তুত, এবং নির্দিষ্টভাবে কোনগুলো? মাঝে মাঝের গেম ডে দুর্বলতা খুঁজে পায়, কিন্তু সিস্টেম প্রতিদিন বদলায় এবং গত ত্রৈমাসিকের সংশোধন নীরবে রিগ্রেস করতে পারে, তাই পরিণত শেষ অবস্থা হলো স্বয়ংক্রিয়ভাবে চলা এবং দিনের মধ্যে রিগ্রেশন ধরা পরীক্ষার একটি বাছাই করা সেট। বিপদ হলো খুব আগে স্বয়ংক্রিয় করা: দুর্বল পর্যবেক্ষণযোগ্যতাসহ অপরিণত সিস্টেমের ওপর স্তরযুক্ত নিরন্তর কেওস অন্তর্দৃষ্টির চেয়ে দ্রুত ঘটনা তৈরি করে। আপনি যে পরীক্ষা সম্পূর্ণ বিশ্বাস করার মতো যথেষ্ট বার ম্যানুয়ালি চালিয়েছেন তার তালিকা, অনুপস্থিত অবস্থায় তাদের শাসন করবে এমন ক্ষতির পরিসর নিয়ন্ত্রণ ও বাতিলের শর্ত, এবং কেউ না দেখলে রাত ৩টায় একটি স্বয়ংক্রিয় চালনা ভুল যাচ্ছে ধরবে এমন মনিটরিং আনুন। একটি বড় এন্টারপ্রাইজ বা সরকারি সংস্থার জন্য অনির্ধারিত ত্রুটি ইনজেকশন যে অতিরিক্ত যাচাই আমন্ত্রণ জানায় তা ওজন করুন: পরিবর্তন-ব্যবস্থাপনা অনুমোদন, প্রতিটি স্বয়ংক্রিয় চালনা যে নিরীক্ষা পথ রাখতে হবে, এবং একটি প্রকৃত ঘটনার সঙ্গে মেলা নির্ধারিত পরীক্ষার জন্য স্পষ্ট জবাবদিহি। কেবল সেই পরীক্ষা স্বয়ংক্রিয় করুন যা আপনি ইতিমধ্যে বোঝেন, এবং বাকিগুলো একই আস্থা অর্জন না করা পর্যন্ত ম্যানুয়াল রাখুন।

খাতভেদে দৃষ্টিভঙ্গি

স্টার্টআপ। গতি ও টিকে থাকা প্রাধান্য পায়, তাই কেওস প্ল্যাটফর্মে কিছু খরচ করবেন না। যে নির্ভরতার ব্যর্থতা আসলে আপনাকে মারবে, সাধারণত পেমেন্ট, প্রমাণীকরণ বা আপনার প্রাথমিক ডেটাস্টোর, তার বিরুদ্ধে স্টেজিংয়ে একটি নব্বই-মিনিটের গেম ডে চালান। একটি স্থূল প্রক্সি বা মারা প্রক্রিয়া দিয়ে ব্যর্থতা ঢোকান, কী ভাঙে দেখুন, অনুপস্থিত টাইমআউট বা ফলব্যাক সারান, এবং এগিয়ে যান। পুরো বিন্দু হলো গ্রাহকের আগে স্পষ্ট নিজের ঘটানো বিভ্রাট সস্তায় ধরা, আপনি কর্মী দিতে পারেন না এমন শৃঙ্খলা গড়া নয়।

ছোট ব্যবসা। কোনো নির্ভরযোগ্যতা বিশেষজ্ঞ নেই আর বাজেট কম, তাই স্থিতিস্থাপকতা টেস্টিংকে আপনি কর্মী দেওয়া কর্মসূচির বদলে পর্যায়ক্রমিক, সুচিন্তিত অনুশীলন গণ্য করুন। একটি নিবেদিত প্ল্যাটফর্ম কেনার বদলে আপনার ক্লাউড প্রদানকারী বা ম্যানেজড টুলিং ইতিমধ্যে যে ত্রুটি-ইনজেকশন ফিচার রাখে তার ওপর ঝুঁকুন, এবং একজন গ্রাহক লক্ষ করবেন এমন মুষ্টিমেয় নির্ভরতায় পরীক্ষা কেন্দ্রীভূত করুন। এটিকে বীমা হিসেবে ফ্রেম করুন: আপনার ব্যাকআপ পুনরুদ্ধার হয় এবং আপনার চেকআউট সুন্দরভাবে অবনমিত হয় নিশ্চিত করা একটি বিকেল সেগুলো যে হয় না তা প্রমাণ করা বিভ্রাটের চেয়ে অনেক সস্তা।

এন্টারপ্রাইজ। সমস্যা পরিসরে ভাগ করা নির্ভরতার বিপরীতে অনেক দল সমন্বয়, তাই প্রস্তুতি মান, ক্ষতির পরিসর নীতি এবং প্রতিটি দলকে প্রোডাকশনে চালানোর আগে পেরোতে হওয়া বাতিলের শর্ত তারে প্রমিত করুন। কেওস আবিষ্কার, দুর্যোগ-পুনরুদ্ধার মহড়া ও ঘটনা পর্যালোচনা স্পষ্ট মালিকানাসহ একটি স্থিতিস্থাপকতা ব্যাকলগে রুট করুন, এবং প্রমাণসহ পরিচালনগত-স্থিতিস্থাপকতা প্রত্যাশা পূরণে ত্রৈমাসিক গেম ডে ও স্বয়ংক্রিয় পরীক্ষার একটি বাছাই করা সেট ব্যবহার করুন। একটি ভাগ করা সেবা কে প্রভাবিত করতে পারে তা শাসন করুন যাতে কোনো একক দলের পরীক্ষা অন্যদের নির্ভর করা অবকাঠামো না নামায়।

সরকার। ক্রয় নিয়ম, স্বচ্ছতা ও জনগণের কাছে জবাবদিহি কাজ আকার দেয়। কার্যক্রম-ধারাবাহিকতা আদেশ প্রায়ই নিয়মিত অনুশীলন দাবি করে, তাই সেগুলো কেউ না খোলা বাইন্ডারের বদলে প্রকৃত আবিষ্কার তৈরি করা জীবন্ত গেম ডে হিসেবে চালান, এবং প্রতিটি পরীক্ষা, তার ক্ষতির পরিসর ও ফলের একটি নিরীক্ষা পথ রাখুন। যেখানে ত্রুটি-ইনজেকশন টুলিং ক্রয় করা হয় সেখানে দাবি করুন তা নিরাপত্তা ও ডেটা-পরিচালনা নিয়মের মধ্যে মানায়, এবং নাগরিক-মুখী সেবায় প্রোডাকশন পরীক্ষা আঁটোভাবে সীমিত, অনুমোদিত জানালার জন্য সংরক্ষণ করুন। একটি কেওস কর্মসূচির তৈরি প্রমাণ ঠিক তাই যা একটি তদারকি সংস্থা বা নিরীক্ষক দেখতে প্রত্যাশা করেন।

উদাহরণ

স্টার্টআপ। পনেরো জনের একটি স্টার্টআপ মুষ্টিমেয় সেবায় একটি ওয়েব অ্যাপ চালায় এবং একটি তৃতীয়-পক্ষ পেমেন্ট API-র ওপর নির্ভর করে। কারও কেওস প্ল্যাটফর্মের সময় নেই, তাই দল স্টেজিংয়ে একটি নব্বই-মিনিটের গেম ডে চালায়। তারা একটি অনুমান গঠন করে: পেমেন্ট API ত্রুটি ফেরত দিতে শুরু করলে চেকআউটে একটি স্পষ্ট পুনঃচেষ্টা বার্তা দেখানো এবং ক্র্যাশের বদলে অর্ডার সারিবদ্ধ করা উচিত। তারা একটি সরল প্রক্সি দিয়ে 500 সাড়া ঢোকায়, এবং আবিষ্কার করে ক্লায়েন্ট কলে কোনো টাইমআউট না থাকায় ফ্রন্টএন্ড অনির্দিষ্টকাল ঝুলে থাকে। তারা একটি টাইমআউট ও একটি বন্ধুত্বপূর্ণ ফলব্যাক যোগ করে, সংশোধন নিশ্চিত করতে পরীক্ষা পুনরায় চালায়, এবং একটি ভাগ করা নথিতে দুই অনুচ্ছেদের নোট লেখে। মোট খরচ: একটি বিকেল এবং একজন গ্রাহক আঘাত করার আগে ধরা একটি অত্যন্ত প্রকৃত বাগ।

এন্টারপ্রাইজ। একটি বৈশ্বিক ব্যাংককে নিয়ন্ত্রকদের কাছে কঠোর-কিন্তু-সম্ভাব্য দৃশ্যকল্পের বিপরীতে পরিচালনগত স্থিতিস্থাপকতা প্রদর্শন করতে হয়। এর নির্ভরযোগ্যতা দল ত্রৈমাসিক গেম ডে এবং প্রোডাকশনে স্বয়ংক্রিয় পরীক্ষার একটি সেটের একটি কর্মসূচি চালায়। একটি দৃশ্যকল্প একটি কম-ট্রাফিক জানালায় প্রাথমিক লেনদেন ডেটাবেসকে তার স্ট্যান্ডবাইয়ে ফেইলওভার করে, একটি আঁটো সীমিত ক্ষতির পরিসর এবং লেনদেন সাফল্য হারে বাঁধা বাতিলের শর্তসহ। প্রথম চালনা প্রকাশ করে একটি নিম্নধারা মেলানো সেবার ব্যাকঅফহীন পুনঃচেষ্টা নীতি আছে, যা দুর্যোগ-পুনরুদ্ধার পরিকল্পনা (অধ্যায় 9.5)-র পুনরুদ্ধার-সময় উদ্দেশ্য ছাড়িয়ে পুনরুদ্ধারকে বিলম্বিত করা লোড স্পাইক তৈরি করে। আবিষ্কার ঘটনা পর্যালোচনার একই ব্যাকলগে যায়, পুনঃচেষ্টা নীতি সূচকীয় ব্যাকঅফে সারানো হয়, এবং একটি অনুসরণ পরীক্ষা নিশ্চিত করে ফেইলওভার এখন লক্ষ্যের মধ্যে সম্পূর্ণ হয়। পুরো অনুশীলন নিয়ন্ত্রকের কাছে প্রমাণ হয়।

সরকার। একটি নাগরিক-মুখী সুবিধা পোর্টাল চালানো একটি জাতীয় সংস্থাকে বিঘ্নের মধ্য দিয়ে কার্যক্রম ধারাবাহিকতা বজায় রাখতে হয়। তার ধারাবাহিকতা পরিকল্পনাকে কেউ না খোলা বাইন্ডার গণ্য করার বদলে সংস্থা বার্ষিক ধারাবাহিকতা অনুশীলন একটি জীবন্ত গেম ডে হিসেবে চালায়। দল একটি প্রাথমিক ডেটা সেন্টার হারানো অনুকরণ করে এবং একটি মাধ্যমিক সাইটে ফেইলওভার হাঁটে, যখন আলাদাভাবে একটি পরিচয়-যাচাই নির্ভরতায় বিলম্ব ঢোকায় পোর্টাল সুন্দরভাবে অবনমিত হয় কি না দেখতে। তারা জানে একটি অপরীক্ষিত মনিটরিং ফাঁক অন-কল দলকে পরিচয় সেবা ধীর হওয়ায় অন্ধ রেখেছিল, তাই সতর্কতা দেরিতে ফায়ার করেছে। সংস্থা পর্যবেক্ষণযোগ্যতা ফাঁক বন্ধ করে, রানবুক হালনাগাদ করে, এবং পরের বছরের জন্য একই অনুশীলন নির্ধারণ করে, একটি জটিল জনসেবার জন্য একটি সম্মতি প্রয়োজনকে প্রকৃত, পরীক্ষিত স্থিতিস্থাপকতায় পরিণত করে।

ব্যবসায়িক যুক্তি: প্রেরণা, ROI ও TCO

কেওস প্রকৌশলের প্রতিদান আসে যে বিভ্রাট কখনো ঘটে না তা থেকে। একটি বড় সেবার একটি একক বড় বিভ্রাট হারানো রাজস্ব, নিয়ন্ত্রক জরিমানা, প্রতিকার শ্রম এবং সেবা পুনরুদ্ধারের অনেক পরেও টেকা সুনামের ক্ষতিতে দশ হাজার থেকে মিলিয়ন পর্যন্ত খরচ করতে পারে। কেওস পরীক্ষা সেই অপূর্বাভাসযোগ্য, ব্যয়বহুল বিস্ময়কে ইঞ্জিনিয়াররা দেখছে ও রোলব্যাক প্রস্তুত থাকা অবস্থায় আপনার নিজস্ব সময়সূচিতে সারানো সস্তা, নির্ধারিত আবিষ্কারে রূপান্তর করে। একটি নিয়ন্ত্রিত গেম ডের সময় একটি ভাঙা টাইমআউট খুঁজে পাওয়া একটি বিকেল খরচ করে। একটি প্রকৃত ঘটনার সময় তা খুঁজে পাওয়া একটি বিভ্রাট, একটি সর্বহাত হুড়োহুড়ি এবং আপনার ব্যবহারকারীদের আস্থা খরচ করে। পাটিগণিত বিস্তৃত ব্যবধানে গেম ডের পক্ষে।

পূর্বশর্ত থাকলে মালিকানার মোট খরচ সামান্য, কারণ কেওস প্রকৌশল পর্যবেক্ষণযোগ্যতা, সতর্কতা ও রোলব্যাক বিনিয়োগ পুনর্ব্যবহার করে যা আপনার তবু দরকার। সৎ খরচ হলো পরীক্ষা চালানোর প্রকৌশল সময়, ত্রুটি ঢোকাতে ও ক্ষতির পরিসর সীমিত করতে কিছু টুলিং, এবং নেতৃত্বকে ইচ্ছাকৃতভাবে ব্যর্থতা ঢোকানোর সঙ্গে স্বচ্ছন্দ করার সাংস্কৃতিক কাজ। সেই শেষটিই প্রকৃত বাধা, এবং এর মধ্য দিয়ে পথ হলো স্টেজিংয়ে শুরু করা, অর্থ বা ঝুঁকিতে মেলে এমন আবিষ্কার দেখানো, এবং কয়েকটি নিয়ন্ত্রিত প্রোডাকশন পরীক্ষাকে আস্থা গড়তে দেওয়া। নেতৃত্বের কাছে যুক্তি দিতে কেওস প্রকৌশলকে এমন বীমা হিসেবে ফ্রেম করুন যা আপনি মাপতে পারেন: সাম্প্রতিক ঘটনার খরচ উপস্থাপন করুন, দেখান কোনগুলো একটি স্থিতিস্থাপকতা পরীক্ষা ধরত, এবং ছোট শুরু করে কেবল নিজেকে প্রমাণ করলে প্রসারিত হওয়া একটি কর্মসূচি প্রস্তাব করুন। নিয়ন্ত্রিত ও সরকারি খাত পরিবেশে সম্মতি কোণ যোগ করুন, কারণ পরিচালনগত-স্থিতিস্থাপকতা টেস্টিং ও ধারাবাহিকতা অনুশীলন ক্রমশ প্রত্যাশিত, এবং একটি কেওস কর্মসূচিই আপনি কাগজপত্রের বদলে প্রমাণ দিয়ে সেই প্রত্যাশা পূরণ করার উপায়।

অ্যান্টি-প্যাটার্ন ও ফাঁদ

• পর্যবেক্ষণযোগ্যতা ছাড়া কেওস। আপনি দেখতে পারেন না এমন সিস্টেমে ত্রুটি ঢোকানো অতিরিক্ত ধাপসহ অনুমান; আপনি ক্ষতি করবেন ও কিছুই শিখবেন না।
• স্থির-অবস্থা সংজ্ঞা নেই। স্বাস্থ্যের একটি সম্মত মাপ ছাড়া আপনি বলতে পারেন না একটি পরীক্ষা সমস্যা প্রকাশ করেছে নাকি ঘটিয়েছে।
• অনুমান নেই। এলোমেলোভাবে জিনিস ভাঙা কেওস প্রকৌশল নয়; এটি একটি জমকালো নাম ও কোনো আবিষ্কার ছাড়া ভাঙচুর।
• অসীমিত ক্ষতির পরিসর। ছোট, নিরাপদ পরীক্ষা বাদ দিয়ে সরাসরি প্রোডাকশন-ব্যাপী ব্যর্থতায় যাওয়া একটি পরীক্ষাকে নিজের ঘটানো বিভ্রাটে পরিণত করে।
• বাতিলের পথ নেই। আপনি তৎক্ষণাৎ থামাতে পারেন না এমন পরীক্ষা পরীক্ষা নয়; এটি একটি ট্রিগারের অপেক্ষায় থাকা ঘটনা।
• খুব আগে স্বয়ংক্রিয় করা। অপরিণত সিস্টেমের ওপর নিরন্তর কেওস অন্তর্দৃষ্টির চেয়ে দ্রুত ঘটনা তৈরি করে।
• কোথাও না যাওয়া আবিষ্কার। একটি দুর্বলতা আবিষ্কার করে কখনো না সারানো অনুশীলন অপচয় করে এবং পুরো কর্মসূচিতে আস্থা ক্ষয় করে।
• একটি খারাপ পরীক্ষার পর দোষারোপ। একটি প্রকৃত ত্রুটি তুলে ধরা পরীক্ষা চালানো ইঞ্জিনিয়ারকে শাস্তি দেওয়া নিশ্চিত করে কেউ পরেরটি চালাবে না।

পরিপক্বতা মডেল

• স্তর 1, সূচনা: স্থিতিস্থাপকতা ধরে নেওয়া, পরীক্ষা করা নয়। ব্যর্থতা প্রোডাকশনে প্রকৃত ঘটনার সময় আবিষ্কৃত হয়। কোনো গেম ডে নেই, কোনো ত্রুটি ইনজেকশন নেই, এবং প্রায়ই সুস্থ দেখতে কেমন তার কোনো স্পষ্ট সংজ্ঞা নেই। দল তার দুর্বলতা কঠিন উপায়ে শেখে, এক এক বিভ্রাটে।
• স্তর 2, বিকাশ: দল মাঝে মাঝে গেম ডে চালায়, সাধারণত স্টেজিংয়ে, একটি সংজ্ঞায়িত দৃশ্যকল্প ও অনুমানসহ। কয়েকটি মূল সেবার জন্য স্থির অবস্থা সংজ্ঞায়িত এবং মৌলিক পর্যবেক্ষণযোগ্যতা আছে। আবিষ্কার ধরা হয় এবং কিছু সারানো হয়, কিন্তু চর্চা দল জুড়ে অসঙ্গত এবং একটি প্রতিষ্ঠিত পদ্ধতির বদলে স্বতন্ত্র চ্যাম্পিয়নের ওপর নির্ভর করে।
• স্তর 3, মানসম্মতকরণ: কেওস পরীক্ষা একটি নথিবদ্ধ, প্রতিষ্ঠান-ব্যাপী চর্চা, প্রয়োগ করা ক্ষতির পরিসর নীতি, বাতিলের শর্ত এবং প্রোডাকশনে পরীক্ষার আগে একটি সেবাকে পেরোতে হওয়া প্রস্তুতি মানদণ্ডসহ। পরীক্ষা নিয়ন্ত্রিত অবস্থায় প্রোডাকশনে চলে, আবিষ্কার ঘটনা পর্যালোচনা ও দুর্যোগ-পুনরুদ্ধার মহড়ার পাশাপাশি একটি ভাগ করা স্থিতিস্থাপকতা ব্যাকলগে প্রবাহিত হয়, এবং স্থিতিস্থাপকতা যন্ত্র ধরে নেওয়ার বদলে যাচাই করা হয়। প্রতিটি দল একই প্লেবুক অনুসরণ করে।
• স্তর 4, ব্যবস্থাপনা: কর্মসূচি ভিত্তিরেখার বিপরীতে ডেটা দিয়ে মাপা ও নিয়ন্ত্রিত। আপনি স্থিতিস্থাপকতা কভারেজ (কোন জটিল সেবা ও কোন যন্ত্র, যেমন টাইমআউট, পুনঃচেষ্টা, সার্কিট ব্রেকার ও ফেইলওভার, একটি প্রকৃত ঢোকানো ত্রুটির অধীনে কত সম্প্রতি যাচাই হয়েছে), পরীক্ষা যে হারে আবিষ্কার তুলে ধরে, একটি স্থিতিস্থাপকতা আবিষ্কার বন্ধের গড় সময়, এবং আগে যাচাই করা একটি যন্ত্র কত ঘন ঘন রিগ্রেস করে অনুসরণ করেন। এই মেট্রিক একটি নির্দিষ্ট ছন্দে পর্যালোচিত হয়, প্রোডাকশন উন্নয়ন মতামতের বদলে প্রমাণে গেট করা, এবং পরীক্ষা এখনো অযাচাইকৃত যন্ত্রের মাপা ঝুঁকি অনুযায়ী অগ্রাধিকার পায়।
• স্তর 5, সমন্বয়: পরীক্ষার একটি বাছাই করা সেট নিরন্তর ও স্বয়ংক্রিয়ভাবে চলে, দিনের মধ্যে রিগ্রেশন ধরে, এবং সিস্টেম ও তার ঝুঁকি চিত্র বদলালে কর্মসূচি খাপ খায়। কেওস প্রকৌশল ডেলিভারি পাইপলাইন, ঘটনা শিক্ষা ও দুর্যোগ-পুনরুদ্ধার টেস্টিংয়ের সঙ্গে প্রতিষ্ঠান জুড়ে একীভূত, যাতে নতুন সেবা ডিফল্টে স্থিতিস্থাপকতা যাচাই উত্তরাধিকার পায়। স্থিতিস্থাপকতা সিস্টেমের একটি নিরন্তর যাচাই করা বৈশিষ্ট্য, এবং নেতৃত্ব কর্মসূচিকে একটি বিশেষ উদ্যোগের বদলে প্রমাণে পরিমার্জিত মানক ঝুঁকি ব্যবস্থাপনা গণ্য করে।

আলোচনার ভাবনা

1. আপনার প্রতিষ্ঠানের কোন সেবা প্রথমে প্রোডাকশনে কেওস পরীক্ষা চালানোর অধিকার অর্জন করে তা আপনি কীভাবে ঠিক করেন, এবং তার আগে কী সত্য হতে হবে?
2. একটি কেওস পরীক্ষা একটি গুরুতর দুর্বলতা তুলে ধরলে সংশোধনের মালিক কে, এবং আপনি কীভাবে সেই আবিষ্কারকে একটি ব্যাকলগে অস্পৃষ্ট পড়ে থাকা থেকে ঠেকান?
3. আপনার প্রেক্ষাপটে একটি কেওস পরীক্ষা, একটি দুর্যোগ-পুনরুদ্ধার মহড়া এবং একটি গেম ডের মধ্যে রেখা কোথায়, এবং পার্থক্য কি আপনি কীভাবে তাদের পরিকল্পনা করেন তাতে আদৌ গুরুত্বপূর্ণ?
4. প্রকৃত বিভ্রাটের অপেক্ষার স্থিতাবস্থার চেয়ে প্রোডাকশনে ইচ্ছাকৃতভাবে ব্যর্থতা ঢোকানো নিরাপদ, একজন সন্দিহান নির্বাহীকে আপনি কীভাবে বোঝাবেন?
5. আপনার দল আগামী মাসে সবচেয়ে ছোট, সবচেয়ে মূল্যবান প্রথম কোন পরীক্ষা চালাতে পারে, এবং তা চালাতে আপনাকে কী থামাবে?
6. একটি ধারাবাহিকতা আদেশসহ নাগরিক-মুখী জনসেবা এবং একটি ছোট ব্যবহারকারী ভিত্তিসহ অভ্যন্তরীণ এন্টারপ্রাইজ টুলের মধ্যে স্থিতিস্থাপকতা টেস্টিং কীভাবে ভিন্ন হওয়া উচিত?

প্রধান শিক্ষা

• কেওস প্রকৌশল স্থিতিস্থাপকতায় আস্থা গড়ার শৃঙ্খলাবদ্ধ, অনুমান-চালিত পরীক্ষা, এলোমেলো ভাঙচুর নয়।
• একটি ত্রুটি ঢোকানোর আগে পর্যবেক্ষণযোগ্যতা, একটি স্থির-অবস্থা সংজ্ঞা এবং একটি দ্রুত রোলব্যাক স্থাপন করুন।
• বাস্তবসম্মত ত্রুটি (বিলম্ব, ত্রুটি, রিসোর্স নিঃশেষ, নির্ভরতা ব্যর্থতা) ঢোকান এবং টাইমআউট, পুনঃচেষ্টা, সার্কিট ব্রেকার ও ফেইলওভার আসলে কাজ করে তা যাচাই করতে ব্যবহার করুন।
• টেবিলটপ অনুশীলন ও গেম ডে দিয়ে শুরু করুন, সুচিন্তিতভাবে ক্ষতির পরিসর সীমিত করুন, এবং প্রোডাকশন ও স্বয়ংক্রিয়তার দিকে আপনার পথ অর্জন করুন।
• আবিষ্কার একটি একক স্থিতিস্থাপকতা ব্যাকলগে চক্রবৃদ্ধি হতে পরীক্ষাকে দুর্যোগ-পুনরুদ্ধার টেস্টিং (অধ্যায় 9.5) ও ঘটনা শিক্ষা (অধ্যায় 9.3)-র সঙ্গে জুড়ুন।
• আবিষ্কার দোষারোপহীনভাবে সামলান এবং সারান; যে পরীক্ষার শিক্ষা অমীমাংসিত যায় তা কোনো পরীক্ষা না থাকার চেয়ে খারাপ।

তথ্যসূত্র ও আরও পড়ার জন্য

• Casey Rosenthal, Nora Jones, Chaos Engineering: System Resiliency in Practice
• Russ Miles, Learning Chaos Engineering: Discovering and Overcoming System Weaknesses Through Experimentation
• Mikolaj Pawlikowski, Chaos Engineering: Crash Test Your Applications
• Ali Basiri et al., Chaos Engineering (IEEE Software, 2016)
• Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy, Site Reliability Engineering: How Google Runs Production Systems
• Michael T. Nygard, Release It! Design and Deploy Production-Ready Software
• Principles of Chaos Engineering, principlesofchaos.org