9.1 সাইট নির্ভরযোগ্যতা প্রকৌশল

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

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

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

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

আরও দেখুন: অধ্যায় 9.2 (পর্যবেক্ষণযোগ্যতা ও মনিটরিং), অধ্যায় 9.3 (ঘটনা ব্যবস্থাপনা), এবং অধ্যায় 3.5 (স্কেলযোগ্যতা, কর্মক্ষমতা ও স্থিতিস্থাপকতা)।

মূল নীতিসমূহ

• নির্ভরযোগ্যতা সবচেয়ে গুরুত্বপূর্ণ ফিচার। যে সিস্টেম কাজ করে না তার যত ফিচারই থাকুক মূল্যহীন, কিন্তু নিখুঁত নির্ভরযোগ্যতা অর্জনযোগ্যও নয়, তার খরচের যোগ্যও নয়।
• পরিমাপযোগ্য উদ্দেশ্য দিয়ে নির্ভরযোগ্যতা সংজ্ঞায়িত করুন। সেবা-স্তরের সূচক (SLI), উদ্দেশ্য (SLO) ও চুক্তি (SLA) অস্পষ্ট প্রত্যাশাকে এমন সংখ্যায় পরিণত করে যাতে সবাই একমত হতে পারে।
• ১০০ শতাংশ ভুল লক্ষ্য। ব্যবহারকারীরা খুব নির্ভরযোগ্য ও নিখুঁতভাবে নির্ভরযোগ্য সিস্টেমের পার্থক্য বলতে পারে না, তাই “যথেষ্ট নির্ভরযোগ্য” লক্ষ্য করুন এবং অবশিষ্ট বাজেট গতিতে খরচ করুন।
• ত্রুটি বাজেট প্রণোদনা সারিবদ্ধ করে। SLO ও ১০০ শতাংশের মধ্যকার ফাঁক ডেভেলপার ও অপারেটরদের ভাগ করা ঝুঁকির বাজেট, তর্ককে পাটিগণিত দিয়ে প্রতিস্থাপন করে।
• পরিশ্রম শত্রু। পুনরাবৃত্ত, ম্যানুয়াল, স্বয়ংক্রিয়যোগ্য পরিচালনগত কাজ মাপা, সীমিত করা এবং ব্যবস্থাগতভাবে নির্মূল করা উচিত।
• সুচিন্তিতভাবে স্বয়ংক্রিয় করুন। একটি ছোট দল স্বয়ংক্রিয়তার মাধ্যমেই একটি বড় সিস্টেম চালায়; এতে বিনিয়োগ প্রথম-শ্রেণির প্রকৌশল কার্যকলাপ।
• দোষারোপহীন শিক্ষা। ব্যর্থতা ব্যক্তিকে শাস্তি দেওয়ার নয়, সিস্টেম ও প্রক্রিয়া উন্নত করার সুযোগ গণ্য করা হয়।

সুপারিশ

সুচিন্তিতভাবে SLI, SLO ও SLA সংজ্ঞায়িত করুন

ব্যবহারকারীর দৃষ্টিকোণ থেকে শুরু করুন। একটি সেবা-স্তরের সূচক একটি সেবার আচরণের পরিমাণগত মাপ, যেমন ৩০০ মিলিসেকেন্ডের নিচে সেবা পাওয়া অনুরোধের অনুপাত বা সফল সাড়ার ভগ্নাংশ। ব্যবহারকারীর সুখ সত্যিই প্রতিফলিত করে এমন অল্প কিছু SLI বাছুন: প্রাপ্যতা, বিলম্ব, সঠিকতা ও সতেজতা সাধারণ। একটি সেবা-স্তরের উদ্দেশ্য একটি SLI-র লক্ষ্য মান বা পরিসর, উদাহরণস্বরূপ “একটি চলমান ২৮-দিনের জানালায় ৯৯.৯ শতাংশ অনুরোধ সফল।” একটি সেবা-স্তরের চুক্তি একটি প্রতিশ্রুত স্তরের সঙ্গে যুক্ত পরিণতিসহ (ফেরত, জরিমানা) একটি চুক্তি। আপনার SLO আপনার SLA-র চেয়ে কঠোর রাখুন, যাতে প্রতিশ্রুতি ভাঙার আগে আপনি সতর্কতা পান। আপনার SLO প্রকাশ করুন, ত্রৈমাসিক পর্যালোচনা করুন এবং এগুলোকে জীবন্ত নথি গণ্য করুন যা আপনি শিখলে আঁটো বা শিথিল হয়।

ত্রুটি বাজেট গ্রহণ ও প্রয়োগ করুন

ত্রুটি বাজেট হলো 100% বিয়োগ SLO। আপনার SLO ৯৯.৯ শতাংশ হলে আপনার বাজেট প্রতি জানালায় ০.১ শতাংশ অনির্ভরযোগ্যতা, মাসে মোটামুটি ৪৩ মিনিট। এটি পরিকল্পিত ঝুঁকিতে খরচ করুন: আক্রমণাত্মক রিলিজ, পরীক্ষা এবং নিয়ন্ত্রিত ব্যর্থতা টেস্ট। বাজেট সুস্থ থাকলে দলগুলো দ্রুত পাঠাতে পারে। এটি ফুরিয়ে গেলে নীতি স্বয়ংক্রিয়ভাবে অগ্রাধিকার নির্ভরযোগ্যতা কাজের দিকে সরাবে এবং সিস্টেম সেরে না ওঠা পর্যন্ত ঝুঁকিপূর্ণ পরিবর্তন থামাবে। ত্রুটি বাজেটের শক্তি হলো আপনি আগে থেকে তাতে একমত হন, তাই এটি একটি বিভ্রাটের মুহূর্ত থেকে আবেগ ও রাজনীতি সরায়।

পরিশ্রম মাপুন ও কমান

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

ক্ষমতা পরিকল্পনা ও চাহিদা পূর্বাভাস করুন

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

নির্ভরযোগ্যতাকে প্রকৃত খরচসহ ফিচার গণ্য করুন

প্রাপ্যতার প্রতিটি অতিরিক্ত “নাইন” সাধারণত আগেরটির চেয়ে অনেক বেশি অতিরিক্ততা, টেস্টিং ও পরিচালনগত পরিশীলনে খরচ করে। নাইনের খরচ সুস্পষ্ট করুন, যাতে পণ্য মালিকরা খোলা চোখে লক্ষ্য বাছেন। সুন্দরভাবে অবনমনের নকশা করুন, যাতে আংশিক ব্যর্থতা সম্পূর্ণ বিভ্রাটের বদলে কমিয়ে আনা সেবা দেয়। অতিরিক্ততা ও ফেইলওভারে SLO-র অনুপাতে বিনিয়োগ করুন, প্রতিটি উপাদানে সমভাবে নয়।

একটি SRE সাংগঠনিক মডেল বাছুন

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

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

সিদ্ধান্ত	সুবিধা	অসুবিধা
কঠোর SLO (আরও নাইন)	উচ্চতর ব্যবহারকারী আস্থা, চুক্তি পূরণ	ক্রমবর্ধমান খরচ, ধীরতর ফিচার ডেলিভারি
শিথিল SLO (কম নাইন)	দ্রুততর পাঠানো, কম খরচ	ব্যবহারকারী চার্ন ও SLA জরিমানার ঝুঁকি
কেন্দ্রীভূত SRE	সামঞ্জস্য, ভাগ করা দক্ষতা	বাধা, পণ্য থেকে দূরত্ব
এমবেডেড SRE	ঘনিষ্ঠ সহযোগিতা, প্রসঙ্গ	অসঙ্গতি, কর্মী দেওয়া কঠিন
ভারী স্বয়ংক্রিয়তা বিনিয়োগ	স্কেল করে, পরিশ্রম কমায়	অগ্রিম খরচ, স্বয়ংক্রিয়তা নিজেও ব্যর্থ হতে পারে

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

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

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

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

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

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

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

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

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

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

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

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

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

উদাহরণ

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

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

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

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

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

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

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

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

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

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

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

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

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

স্তর 5, সমন্বয়। নির্ভরযোগ্যতা প্রকৌশল প্রতিষ্ঠান জুড়ে একীভূত ও নিরন্তর উন্নত। ত্রুটি-বাজেট নীতি স্বয়ংক্রিয় ও সর্বত্র সম্মানিত, বেশিরভাগ অপারেশন স্ব-সেবা, ক্ষমতা সক্রিয়ভাবে প্রস্তুত করা হয়, এবং নির্ভরযোগ্যতা ডেটা গতি ও স্থিতিশীলতার মধ্যে অভিযোজিত ট্রেড-অফ চালায়। ব্যবসা ও ঝুঁকি চিত্র সরলে প্রতিষ্ঠান নিয়মিত SLO পুনঃপরিসর করে, পরিশ্রম অবসর দেয় এবং নির্ভরযোগ্যতা বিনিয়োগ পুনঃভারসাম্য করে।

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

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

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

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

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

• Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy, Site Reliability Engineering: How Google Runs Production Systems
• Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara, Stephen Thorne, The Site Reliability Workbook: Practical Ways to Implement SRE
• David N. Blank-Edelman (editor), Seeking SRE: Conversations About Running Production Systems at Scale
• Thomas A. Limoncelli, Strata R. Chalup, Christina J. Hogan, The Practice of Cloud System Administration
• Nicole Forsgren, Jez Humble, Gene Kim, Accelerate: The Science of Lean Software and DevOps