৬.১ পরিষেবা স্তর সূচক, উদ্দেশ্য, এবং ত্রুটি বাজেট
সারসংক্ষেপ এবং প্রেরণা
সাইট নির্ভরযোগ্যতা প্রকৌশল (SRE), গুগলে অগ্রণী ও Site Reliability Engineering বইয়ে নথিভুক্ত শৃঙ্খলা, একটি শব্দভাণ্ডার অবদান রেখেছে যার উপর এই বিষয় সরাসরি নির্মিত: একটি পরিষেবা স্তর সূচক (SLI) হলো একটি পরিষেবার স্বাস্থ্যের সরাসরি পরিমাপিত সংকেত, অনুরোধের বিলম্বতা, ত্রুটির হার, উপলব্ধতা। একটি পরিষেবা স্তর উদ্দেশ্য (SLO) হলো সেই সূচকের লক্ষ্য পরিসর, উদাহরণস্বরূপ ২০০ মিলিসেকেন্ডের মধ্যে ৯৯.৯% অনুরোধ সফল হয়। এবং একটি ত্রুটি বাজেট হলো অনুমোদিত ঘাটতি, ব্যর্থ হতে অনুমোদিত অনুরোধের ০.১%, নির্মূল করার একটি ত্রুটি হিসেবে নয় বরং ইচ্ছাকৃতভাবে ঝুঁকি নিতে ব্যবহার করা যায় এমন একটি ব্যয়যোগ্য সম্পদ হিসেবে বিবেচিত: একটি ঝুঁকিপূর্ণ পরিবর্তন সরবরাহ করা, একটি পরীক্ষা চালানো, বা শুধু স্বীকার করা যে নিখুঁত নির্ভরযোগ্যতা অর্জনযোগ্য নয় এবং একটি নির্দিষ্ট বিন্দুর পরে, এর খরচের যোগ্যও নয়।
এই শেষ ধারণাটি, ত্রুটি বাজেট শূন্যের দিকে কমানোর একটি সংখ্যা হিসেবে নয় বরং একটি ব্যয়যোগ্য সম্পদ হিসেবে, এই বিষয়ের একক সবচেয়ে গুরুত্বপূর্ণ ধারণা এবং যুক্তিসঙ্গতভাবে এই সম্পূর্ণ পর্বেরও। এটি একটি টানাপোড়েন সমাধান করে যা অনেক প্রতিষ্ঠানকে জর্জরিত করে: প্রকৌশল বৈশিষ্ট্য সরবরাহ করতে ও যুক্তিসঙ্গত ঝুঁকি নিতে চায়; কার্যক্রম সর্বোচ্চ স্থিতিশীলতা চায়। একটি ভাগ করা, পরিমাণগত ত্রুটি বাজেট ছাড়া, এটি একটি অন্তহীন, রাজনৈতিকভাবে চার্জযুক্ত আলোচনা হয়ে ওঠে। একটির সাথে, এটি একটি সরল, বস্তুনিষ্ঠ নিয়ম হয়ে ওঠে: বাজেট থাকা অবস্থায় অবাধে ব্যয় করুন, একবার এটি নিঃশেষ হলে স্বয়ংক্রিয়ভাবে ধীর হয়ে স্থিতিশীলতা কাজকে অগ্রাধিকার দিন। এটি একটি দার্শনিক মতবিরোধকে একটি গাণিতিকে পরিণত করে।
বড় দলের জন্য, SLO ও ত্রুটি বাজেট হলো যা নির্ভরযোগ্যতাকে পরিমাপযোগ্য ও আলোচনাযোগ্য করে তোলে একটি অপ্রাপ্য, অব্যক্ত পরমের বদলে যা প্রতিটি দল নীরবে পূরণ করতে ব্যর্থ হয় এটি সম্পর্কে অস্পষ্টভাবে দোষী বোধ করার সময়। এন্টারপ্রাইজ প্রতিষ্ঠান দল ও গ্রাহকদের মধ্যে স্পষ্ট, চুক্তিভুক্ত প্রত্যাশা নির্ধারণ করতে SLO ব্যবহার করে; সমালোচনামূলক সরকারি অবকাঠামো পরিচালনাকারী সরকারি প্রতিষ্ঠান রক্ষণযোগ্য, প্রকাশ্যে ন্যায্যতাযোগ্য নির্ভরযোগ্যতা লক্ষ্য নির্ধারণ করতে এগুলো ব্যবহার করে একটি অসম্ভব নিখুঁততার মানের বদলে যা কোনো প্রকৃত সিস্টেম টেকসই রাখতে পারে না।
মূল নীতিসমূহ
- ১০০% নির্ভরযোগ্যতা প্রায় যে কোনো সিস্টেমের জন্য ভুল লক্ষ্য। এটি সাধারণত অর্জনযোগ্য নয়, এবং একটি নির্দিষ্ট বিন্দুর পরে এটি অনুসরণ করা কোনো অর্থপূর্ণ ব্যবহারকারী সুবিধা ছাড়াই সক্রিয়ভাবে গতি বিনিময় করে।
- একটি SLO ব্যবহারকারীরা প্রকৃতপক্ষে লক্ষ্য করেন ও যত্ন করেন তা প্রতিফলিত করা উচিত, আশ্বস্তকারী শোনায় বলে বেছে নেওয়া একটি স্বেচ্ছাচারী গোল সংখ্যা নয়।
- ত্রুটি বাজেট নির্ভরযোগ্যতাকে একটি ব্যয়যোগ্য সম্পদে পরিণত করে, প্রকৌশল ও কার্যক্রম উভয়কেই কখন দ্রুত সরবরাহ করতে হবে ও কখন ধীর করতে হবে তার একটি ভাগ করা, বস্তুনিষ্ঠ নিয়ম দিয়ে।
- SLI অবশ্যই যেখানেই সম্ভব ব্যবহারকারীর প্রকৃত অভিজ্ঞতা থেকে পরিমাপ করতে হবে, শুধু একটি অভ্যন্তরীণ সিস্টেমের স্ব-প্রতিবেদিত স্বাস্থ্য থেকে নয়।
- ত্রুটি বাজেট নিঃশেষ হওয়া একটি পূর্বনির্ধারিত, সম্মত প্রতিক্রিয়া ট্রিগার করে, প্রতিবার ঘটার সময় একটি এডহক তর্ক নয়।
সুপারিশসমূহ
প্রকৃত ব্যবহারকারী অভিজ্ঞতা প্রতিফলিত করে এমন SLI বেছে নিন
সম্ভব হলে প্রকৃত ব্যবহারকারী অভিজ্ঞতার যতটা কাছাকাছি পরিমাপিত সূচক নির্বাচন করুন: প্রান্ত বা লোড ব্যালেন্সারে পরিমাপিত অনুরোধ সফলতার হার ও বিলম্বতা, শুধু অভ্যন্তরীণ পরিষেবা স্বাস্থ্য পরীক্ষা নয় যা “সুস্থ” প্রতিবেদন করতে পারে যখন ব্যবহারকারীরা প্রকৃত সমস্যা অনুভব করেন। একটি SLI যা এমন কিছু পরিমাপ করে যা ব্যবহারকারী প্রকৃতপক্ষে কখনও লক্ষ্য করেন না, একটি অভ্যন্তরীণ উপাদান প্রযুক্তিগতভাবে চালু থাকা যখন সামগ্রিক অনুরোধ এখনও ব্যর্থ হয়, এটি ইনস্ট্রুমেন্ট করা যতই সহজ হোক না কেন ভুল জিনিস পরিমাপ করছে।
একটি স্বেচ্ছাচারী গোল সংখ্যা নয়, ব্যবহারকারীদের প্রকৃতপক্ষে প্রয়োজনের ভিত্তিতে SLO লক্ষ্য নির্ধারণ করুন
শুধু এটি প্রভাবশালীভাবে কঠোর শোনায় বলে “৯৯.৯৯% আপটাইম”-এর মতো একটি লক্ষ্য নির্ধারণের প্রতিবর্ত প্রতিরোধ করুন। পরিবর্তে, ব্যবহারকারীরা প্রকৃতপক্ষে কোন নির্ভরযোগ্যতা স্তর লক্ষ্য করেন ও যত্ন করেন তা গবেষণা করুন, ঐতিহাসিক ঘটনা উপাত্ত, ব্যবহারকারী গবেষণা, এবং নির্ভরযোগ্যতার প্রতিটি অতিরিক্ত বৃদ্ধি অর্জনের প্রদর্শিত খরচ দ্বারা অবহিত, যেহেতু ৯৯.৯% থেকে ৯৯.৯৯%-এ যাওয়া প্রায়ই ৯৯% থেকে ৯৯.৯%-এ যাওয়ার চেয়ে অনেক বেশি প্রকৌশল প্রচেষ্টা খরচ করে, হ্রাসমান এবং অবশেষে নগণ্য ব্যবহারকারী-অনুভবযোগ্য সুবিধার জন্য।
একটি পূর্বনির্ধারিত নিঃশেষ প্রতিক্রিয়াসহ ত্রুটি বাজেটকে একটি ব্যয়যোগ্য সম্পদ হিসেবে বিবেচনা করুন
সরাসরি SLO থেকে ত্রুটি বাজেট গণনা করুন (৩০ দিনে একটি ৯৯.৯% উপলব্ধতা লক্ষ্য মোটামুটি ৪৩ মিনিট অনুমোদিত ডাউনটাইমের অনুমতি দেয়) এবং ক্রমাগত এর বিরুদ্ধে ব্যয় ট্র্যাক করুন। আগেভাগে ও যে কোনো নির্দিষ্ট ঘটনার আগে, বাজেট নিঃশেষ হলে কী ঘটে তা সম্মত হন: একটি সাধারণ, কার্যকর নীতি হলো বৈশিষ্ট্য কাজ বিরতি নেয় এবং দলের অগ্রাধিকার স্বয়ংক্রিয়ভাবে নির্ভরযোগ্যতা কাজে স্থানান্তরিত হয় বাজেট পুনরুদ্ধার না হওয়া পর্যন্ত। এই পূর্বনির্ধারিত নিয়ম প্রতিটি পৃথক ঘটনার সময় চাপের অধীনে বিনিময় পুনরায় বিতর্ক করার প্রয়োজন অপসারণ করে।
ইচ্ছাকৃত, অবগত ঝুঁকি সিদ্ধান্ত নিতে ত্রুটি বাজেট ব্যবহার করুন
একটি সুস্থ, অব্যয়িত ত্রুটি বাজেট সঞ্চয় করার মতো কিছু নয়; এটি যুক্তিসঙ্গত ঝুঁকি নেওয়ার অনুমতি, বেড়ে যাওয়া কিন্তু গ্রহণযোগ্য ঝুঁকিসহ একটি পরিবর্তন সরবরাহ করা, একটি বিশৃঙ্খলা প্রকৌশল পরীক্ষা চালানো (সহোদর software-engineering-guide বইয়ের বিশৃঙ্খলা প্রকৌশল বিষয় সরাসরি এটি আচ্ছাদন করে), বা একটি ঝুঁকিপূর্ণতর স্থাপত্য পরিবর্তন গ্রহণ করা, কারণ বাজেট নির্দিষ্টভাবে অস্পৃশ্য সংরক্ষণের বদলে ইচ্ছাকৃতভাবে ব্যয় করার জন্য বিদ্যমান। একটি ত্রুটি বাজেট যা কখনও ব্যয় হয় না হয় একটি অতিরিক্ত রক্ষণশীল দল বা প্রকৃত অর্জিত নির্ভরযোগ্যতার সাপেক্ষে খুব শিথিলভাবে নির্ধারিত একটি SLO পরামর্শ দেয়, উভয়ই তদন্তের যোগ্য।
প্রমাণের ভিত্তিতে, জড়তার ভিত্তিতে নয়, পর্যায়ক্রমিকভাবে SLO পর্যালোচনা ও সংশোধন করুন
বছর আগে নির্ধারিত একটি SLO আর বর্তমান ব্যবহারকারী প্রত্যাশা, সিস্টেম স্থাপত্য, বা ব্যবসায়িক অগ্রাধিকার প্রতিফলিত নাও করতে পারে। একটি নিয়মিত ছন্দে SLO পর্যালোচনা করুন, ঐতিহাসিক অর্জিত নির্ভরযোগ্যতা, ব্যবহারকারী প্রতিক্রিয়া পরীক্ষা করে, এবং লক্ষ্যটি এখনও একটি অর্থপূর্ণ বিনিময় বিন্দু প্রতিনিধিত্ব করে কিনা নাকি একটি সহজে-পূরণযোগ্য লক্ষ্য যা অন্য কোথাও আরও গতি সক্ষম করতে কঠোর করা যেত, বা একটি অবাস্তব একটি যা দল কার্যকরভাবে পূরণ করার চেষ্টা ছেড়ে দিয়েছে।
মূল্যবিচার: ভালো ও মন্দ দিক
| পদ্ধতি | ভালো দিক | মন্দ দিক |
|---|---|---|
| কোনো আনুষ্ঠানিক SLO নেই (অন্তর্নিহিত “যতটা সম্ভব নির্ভরযোগ্য”) | সেটআপ করতে কোনো ওভারহেড নেই | গতি ও স্থিতিশীলতার মধ্যে অন্তহীন, ভিত্তিহীন আলোচনা; কোনো ভাগ করা নিয়ম নেই |
| উচ্চাকাঙ্ক্ষী, অত্যন্ত উচ্চ SLO (৯৯.৯৯%+) | নির্ভরযোগ্যতা সম্পর্কে গুরুত্ব সংকেত দেয় | প্রায়ই অপ্রয়োজনীয় খরচ; ব্যবহারকারী প্রকৃতপক্ষে যা লক্ষ্য করেন তার বাইরে হ্রাসমান রিটার্ন |
| প্রমাণ-ভিত্তিক, ব্যবহারকারী-অভিজ্ঞতা-ভিত্তিক SLO | প্রকৃত মূল্য প্রতিফলিত করে; রক্ষণযোগ্য ও অর্জনযোগ্য | সঠিকভাবে নির্ধারণ করতে প্রকৃত উপাত্ত ও বিশ্লেষণ প্রয়োজন |
| পূর্বনির্ধারিত নিঃশেষ প্রতিক্রিয়াসহ ত্রুটি বাজেট | এডহক আলোচনা অপসারণ করে; বস্তুনিষ্ঠ, দ্রুত সিদ্ধান্ত গ্রহণ | পূর্বনির্ধারিত নিয়ম প্রকৃতপক্ষে সম্মান করার প্রাতিষ্ঠানিক সমর্থন ও শৃঙ্খলা প্রয়োজন |
কেন্দ্রীয় টানাপোড়েন হলো আকাঙ্ক্ষা বনাম অর্জনযোগ্যতা। একটি উচ্চ, উচ্চাকাঙ্ক্ষী SLO মনে হয় এটি গুণমান সম্পর্কে গুরুত্ব সংকেত দেয়, কিন্তু ব্যবহারকারীরা প্রকৃতপক্ষে লক্ষ্য করেন তার বাইরে নির্ভরযোগ্যতা অনুসরণ করা কোনো প্রকৃত সুবিধা ছাড়াই প্রকৃত গতি বিনিময় করে, এবং একটি অবাস্তব লক্ষ্য যা দল কখনও প্রকৃতপক্ষে পূরণ করে না সবাইকে SLO-কে মোটেও গুরুত্বের সাথে নেওয়া বন্ধ করতে শেখায়। প্রকৃত প্রমাণে SLO ভিত্তি করে টানাপোড়েন সমাধান করুন, ব্যবহারকারীরা কী লক্ষ্য করেন, সিস্টেম ঐতিহাসিকভাবে কী অর্জন করেছে, প্রতিটি অতিরিক্ত বৃদ্ধির কী খরচ, একটি স্কোরকার্ডে কঠোর দেখানোর আকাঙ্ক্ষা বা ইচ্ছার বদলে।
আপনার দলের সাথে আলোচনার প্রশ্ন
১. আমাদের বর্তমান SLO কি ব্যবহারকারীরা প্রকৃতপক্ষে কী লক্ষ্য করেন সে সম্পর্কে প্রমাণে ভিত্তিপ্রাপ্ত, নাকি এটি উচ্চাকাঙ্ক্ষীভাবে নির্ধারিত হয়েছিল কারণ একটি উচ্চ সংখ্যা যথাযথভাবে গুরুতর মনে হয়েছিল? আপনার বর্তমান লক্ষ্যের উৎস খুঁজুন, যদি পারেন, এবং সততার সাথে মূল্যায়ন করুন এটি প্রকৃত ব্যবহারকারী গবেষণা প্রতিফলিত করে নাকি একা প্রকৌশল স্বজ্ঞা।
২. ত্রুটি-বাজেট নিঃশেষের জন্য আমাদের কি একটি পূর্বনির্ধারিত, সম্মত প্রতিক্রিয়া আছে, নাকি বিনিময়টি প্রতিবার ঘটার সময় পুনরায় বিতর্কিত হয়? যদি সৎ উত্তর দ্বিতীয়টি হয়, পরবর্তী ঘটনা চাপের অধীনে তর্ক বাধ্য করার আগে সেই ফাঁক বন্ধ করার যোগ্য।
৩. আমাদের ত্রুটি বাজেট কি কখনও প্রকৃতপক্ষে ইচ্ছাকৃতভাবে ব্যয় হয়, একটি গণনাকৃত-ঝুঁকি পরিবর্তন বা একটি পরীক্ষায়, নাকি এটি শুধুমাত্র ঘটনার মাধ্যমে দুর্ঘটনাক্রমে খরচ হয়? একটি বাজেট যা কখনও ইচ্ছাকৃতভাবে ব্যয় হয় না একটি অতিরিক্ত সতর্ক দল বাজেট সক্ষম করতে বিদ্যমান এমন বৈধ সুযোগ মিস করা নির্দেশ করতে পারে।
৪. আমাদের SLI কি প্রকৃত ব্যবহারকারী অভিজ্ঞতা থেকে পরিমাপ করা হয়, নাকি অভ্যন্তরীণ সিস্টেম স্বাস্থ্য থেকে যা ব্যবহারকারীরা প্রকৃতপক্ষে যা অনুভব করেন তা প্রতিফলিত নাও করতে পারে? এই নির্দিষ্ট পার্থক্যের বিরুদ্ধে আপনার বর্তমান ইনস্ট্রুমেন্টেশন পরীক্ষা করুন; এটি অন্যথায় পরিপক্ব নির্ভরযোগ্যতা কর্মসূচিতেও একটি সাধারণ ফাঁক।
৫. আমরা সর্বশেষ কখন প্রকৃত প্রমাণের বিরুদ্ধে আমাদের SLO পর্যালোচনা করেছি, এবং কিছু কি পরিবর্তিত হয়েছে, ব্যবহারকারী প্রত্যাশা, সিস্টেম স্থাপত্য, ব্যবসায়িক অগ্রাধিকার, যা এটি সংশোধন ন্যায্যতা দেবে? যদি আপনি একটি সাম্প্রতিক পর্যালোচনা মনে করতে না পারেন, সেই অনুপস্থিতি নিজেই আলোচনার যোগ্য।
৬. আমাদের বর্তমান SLO-কে নির্ভরযোগ্যতার একটি অতিরিক্ত “নয়” দিয়ে বাড়াতে আমাদের কী খরচ হবে, প্রকৌশল প্রচেষ্টায়, এবং সেই খরচ কি কোনো প্রকৃত ব্যবহারকারী সুবিধা দ্বারা ন্যায্যতাপ্রাপ্ত হবে? এই সুনির্দিষ্ট খরচ-সুবিধা গঠন বিমূর্ত পছন্দের বদলে প্রকৃত সংখ্যায় আকাঙ্ক্ষা-বনাম-অর্জনযোগ্যতা টানাপোড়েন ভিত্তি করতে সাহায্য করে।
ক্ষেত্র লেন্স
স্টার্টআপ। আনুষ্ঠানিক SLO প্রায়ই খুব প্রাথমিকভাবে অপ্রয়োজনীয়, যখন দল সরাসরি ও অনানুষ্ঠানিকভাবে নির্ভরযোগ্যতা সমস্যার প্রতিক্রিয়া জানাতে পারে। একবার আপনার আপটাইমের উপর নির্ভরশীল প্রকৃত প্রদানকারী গ্রাহক থাকলে কমপক্ষে একটি মোটামুটি, অনানুষ্ঠানিক SLO গ্রহণ করুন, যেহেতু একটি স্পষ্ট লক্ষ্যের শৃঙ্খলা, এমনকি একটি শিথিলভাবে ট্র্যাক করা একটিও, বেশিরভাগ তরুণ কোম্পানি ভাবার চেয়ে আগে বৈশিষ্ট্য চাপের বিরুদ্ধে নির্ভরযোগ্যতা কাজ অগ্রাধিকার দিতে সাহায্য করে।
ছোট ব্যবসা। বেশিরভাগ আধুনিক হোস্টিং ও পর্যবেক্ষণযোগ্যতা প্ল্যাটফর্ম ন্যূনতম সেটআপসহ মৌলিক আপটাইম ও বিলম্বতা উপাত্ত প্রতিবেদন করে; আপনার সীমিত কার্যক্রম ক্ষমতা সহ বাস্তবসম্মতভাবে ট্র্যাক বা কাজ করতে পারবেন না এমন একটি উচ্চাকাঙ্ক্ষী একটির বদলে একটি সরল, অর্জনযোগ্য SLO নির্ধারণ করতে এটি ব্যবহার করুন।
এন্টারপ্রাইজ। এই মাত্রায় SLO প্রায়ই প্রকৃত আর্থিক পরিণতিসহ চুক্তিভুক্ত পরিষেবা স্তর চুক্তির ভিত্তি প্রদান করে, যা প্রমাণ-ভিত্তিক লক্ষ্য নির্ধারণ ও শৃঙ্খলাবদ্ধ ত্রুটি-বাজেট ব্যবস্থাপনাকে বিশেষভাবে গুরুত্বপূর্ণ করে তোলে। সুবিধাজনক অভ্যন্তরীণ স্বাস্থ্য পরীক্ষার বদলে প্রকৃত ব্যবহারকারী-অভিজ্ঞতা-ভিত্তিক SLI-এ বিনিয়োগ করুন, এবং এটি চাপের অধীনে প্রয়োজন হওয়ার আগে নির্বাহী সমর্থনসহ আনুষ্ঠানিকভাবে পূর্বনির্ধারিত নিঃশেষ-প্রতিক্রিয়া নীতি প্রতিষ্ঠা করুন।
সরকার। সমালোচনামূলক অবকাঠামোর জন্য সরকারি-খাতের নির্ভরযোগ্যতা লক্ষ্য কখনও কখনও আইনি বা নিয়ন্ত্রক ওজন বহন করে, এবং একটি নিরীক্ষা বা একটি জনসাধারণের ঘটনার সময় আবিষ্কৃত একটি অবাস্তব, অপূর্ণ লক্ষ্য প্রাতিষ্ঠানিক বিশ্বাসযোগ্যতার উল্লেখযোগ্যভাবে ক্ষতি করে। প্রকৃত, নথিভুক্ত ব্যবহারকারী ও মিশন প্রয়োজনের ভিত্তিতে লক্ষ্য নির্ধারণ করুন, এবং একটি অপ্রাপ্য নিখুঁততার মান বোঝানোর বদলে একটি ত্রুটি বাজেট যে ইচ্ছাকৃত বিনিময় প্রতিনিধিত্ব করে সে সম্পর্কে প্রকাশ্যে স্বচ্ছ থাকুন।
উদাহরণ
এন্টারপ্রাইজ। একটি ক্লাউড স্টোরেজ কোম্পানি, বছরের পর বছর ধরে, কোনো আনুষ্ঠানিক SLO ছাড়াই “সর্বোচ্চ আপটাইম” লক্ষ্য করেছিল, পণ্য দলের (দ্রুত বৈশিষ্ট্য সরবরাহ করতে চাওয়া) ও অবকাঠামো দলের (সর্বোচ্চ সতর্কতা চাওয়া) মধ্যে একটি দীর্ঘস্থায়ী, অসমাধানকৃত টানাপোড়েনের দিকে নিয়ে যায়, প্রতিটি মুক্তি পরিকল্পনা সভায় নতুনভাবে বিতর্কিত। একটি ৯৯.৯৫% উপলব্ধতা SLO একটি স্পষ্ট ত্রুটি বাজেট ও একটি পূর্বনির্ধারিত নীতিসহ গ্রহণ করা, বাজেট নিঃশেষ হলে বৈশিষ্ট্য কাজ স্বয়ংক্রিয়ভাবে বিরতি নেয়, পুনরাবৃত্ত আলোচনা সম্পূর্ণভাবে সমাধান করেছিল: উভয় দলই একই সংখ্যা দেখতে পারত এবং একই নিয়মে একমত হতে পারত, এবং কোম্পানিটি পরবর্তী বছরে সুস্থ বাজেট সময়কালে সরবরাহকৃত বৈশিষ্ট্যে একটি পরিমাপযোগ্য বৃদ্ধি প্রতিবেদন করেছিল যখন বাজেট প্রকৃতপক্ষে নিঃশেষ হয়েছিল এমন দুটি সময়কালে একটি পরিমাপযোগ্য, ইচ্ছাকৃত ধীরগতির পাশাপাশি, ঠিক নীতি যেমনটি উদ্দেশ্য করেছিল।
সরকার। একটি জাতীয় আবহাওয়া পরিষেবার সরকারি সতর্কীকরণ সিস্টেম বছরের পর বছর ধরে “সবসময় উপলব্ধ”-এর একটি অনানুষ্ঠানিক প্রত্যাশার অধীনে পরিচালিত হয়েছিল, কোনো নথিভুক্ত লক্ষ্য ছাড়া এবং একটি অব্যক্ত, কার্যকরভাবে অসম্ভব মান পূরণ করার চেষ্টা করা অন-কল দলের উপর উল্লেখযোগ্য, অসমাধানকৃত কার্যক্রম চাপসহ। একটি নতুন গৃহীত আনুষ্ঠানিক SLO, একটি স্পষ্টভাবে যোগাযোগকৃত সরকারি ত্রুটি বাজেট ব্যাখ্যাসহ ৯৯.৯% উপলব্ধতা, কার্যক্রম দলকে বাজেটের মধ্যে পরিকল্পিত রক্ষণাবেক্ষণ উইন্ডো নির্ধারণ করার স্পষ্ট, রক্ষণযোগ্য অনুমতি দিয়েছিল, এমন কিছু যা পূর্ববর্তী অব্যক্ত “সবসময় উপলব্ধ” প্রত্যাশা রাজনৈতিকভাবে করা কঠিন করে দিয়েছিল এমনকি যখন দীর্ঘমেয়াদী সিস্টেম স্বাস্থ্যের জন্য প্রকৃতপক্ষে প্রয়োজনীয় ছিল। ত্রুটি বাজেট ধারণা সরাসরি ব্যাখ্যা করা সরকারি যোগাযোগ, এটি লুকানোর বদলে, পরিষেবা গুণমানের প্রতিশ্রুতি দুর্বল করার বদলে সৎ, পরিপক্ব কার্যক্রম অনুশীলনের একটি চিহ্ন হিসেবে অনুকূলভাবে গৃহীত হয়েছিল।
ব্যবসায়িক যুক্তি: প্রেরণা, ROI, এবং TCO
আনুষ্ঠানিকভাবে SLO ও ত্রুটি বাজেট গ্রহণের রিটার্ন হলো একটি একক, ভাগ করা, বস্তুনিষ্ঠ নিয়মসহ গতি ও স্থিতিশীলতার মধ্যে একটি অন্যথায় অন্তহীন, রাজনৈতিকভাবে ব্যয়বহুল আলোচনা সমাধান করা। উপরের ক্লাউড স্টোরেজ উদাহরণ এটি সুনির্দিষ্টভাবে দেখায়: দুটি দলের মধ্যে পুনরাবৃত্ত, অসমাধানকৃত টানাপোড়েনের বছর একটি একক আনুষ্ঠানিক লক্ষ্য ও একটি পূর্বনির্ধারিত নীতি দ্বারা সমাধান হয়েছিল, উল্লেখযোগ্য প্রাতিষ্ঠানিক শক্তি মুক্ত করে যা পূর্বে একই বিনিময় বারবার পুনরায় বিতর্ক করতে গিয়েছিল।
মোট মালিকানা খরচে সঠিকভাবে একটি প্রমাণ-ভিত্তিক লক্ষ্য নির্ধারণের বিশ্লেষণ প্রচেষ্টা এবং যাই হোক একটি বিশেষভাবে কাঙ্ক্ষিত বৈশিষ্ট্য সরবরাহ করার চাপের অধীনেও পূর্বনির্ধারিত নিঃশেষ প্রতিক্রিয়া সম্মান করার শৃঙ্খলা অন্তর্ভুক্ত। সেই শৃঙ্খলা খরচ প্রকৃত, কিন্তু এটি প্রতিটি পরিকল্পনা চক্রে অনির্দিষ্টকালের জন্য প্রাতিষ্ঠানিক শক্তি গ্রাস করে এমন একটি অসমাধানকৃত, দীর্ঘস্থায়ী আলোচনার চলমান খরচের চেয়ে অনেক কম।
বিরোধী প্যাটার্ন এবং ফাঁদ
- এর পেছনে কোনো প্রমাণ ছাড়া একটি উচ্চাকাঙ্ক্ষী SLO নির্ধারণ করা: একটি অবাস্তব লক্ষ্য উৎপাদন করে যা দল গুরুত্বের সাথে নেওয়া বন্ধ করে দেয়, বা একটি অপ্রয়োজনীয়ভাবে ব্যয়বহুল একটি যা ব্যবহারকারীরা লক্ষ্য করেন না এমন সুবিধা তাড়া করে।
- ত্রুটি-বাজেট নিঃশেষের জন্য কোনো পূর্বনির্ধারিত প্রতিক্রিয়া নেই: প্রতিবার ঘটার সময় চাপের অধীনে একই কঠিন বিনিময় তর্ক বাধ্য করে।
- প্রকৃত ব্যবহারকারী অভিজ্ঞতার বদলে অভ্যন্তরীণ সিস্টেম স্বাস্থ্য থেকে SLI পরিমাপ করা: ব্যবহারকারীরা প্রকৃত সমস্যা অনুভব করার সময় “সুস্থ” প্রতিবেদন করতে পারে।
- কখনও প্রকৃতপক্ষে ইচ্ছাকৃতভাবে একটি সুস্থ ত্রুটি বাজেট ব্যয় না করা: অতিরিক্ত সতর্কতা ও মিস করা বৈধ সুযোগ নির্দেশ করতে পারে।
- একবার লক্ষ্য নির্ধারণ করা এবং কখনও পুনরায় না দেখা: ব্যবহারকারী প্রত্যাশা, স্থাপত্য, এবং অগ্রাধিকার পরিবর্তনের সাথে সাথে একটি SLO পুরনো হয়ে উঠতে পারে।
- চাপের অধীনে ত্রুটি বাজেট নীতিকে ঐচ্ছিক হিসেবে বিবেচনা করা: একটি পূর্বনির্ধারিত নিয়ম যা যখনই অসুবিধাজনক তখন ওভাররাইড করা হয় কোনো প্রকৃত সিদ্ধান্ত-গ্রহণ মূল্য প্রদান করে না।
পরিপক্বতা মডেল
- স্তর ১, শুরু: নির্ভরযোগ্যতা লক্ষ্য অন্তর্নিহিত বা উচ্চাকাঙ্ক্ষী, কোনো আনুষ্ঠানিক SLO, SLI, বা ত্রুটি বাজেট সংজ্ঞায়িত না করে।
- স্তর ২, উন্নয়ন: কিছু পরিষেবার একটি অনানুষ্ঠানিক SLO আছে, কিন্তু SLI প্রকৃত ব্যবহারকারী অভিজ্ঞতা প্রতিফলিত নাও করতে পারে এবং কোনো পূর্বনির্ধারিত নিঃশেষ নীতি নেই।
- স্তর ৩, মানসম্মতকরণ: প্রকৃত ব্যবহারকারী-অভিজ্ঞতা SLI ও একটি পূর্বনির্ধারিত ত্রুটি-বাজেট নিঃশেষ নীতিসহ প্রমাণ-ভিত্তিক SLO সমালোচনামূলক পরিষেবা জুড়ে সামঞ্জস্যপূর্ণভাবে প্রতিষ্ঠিত।
- স্তর ৪, ব্যবস্থাপনা: ত্রুটি বাজেট সক্রিয়ভাবে ও ইচ্ছাকৃতভাবে গণনাকৃত ঝুঁকি-গ্রহণে ব্যয় করা হয়, এবং SLO একটি নিয়মিত, প্রমাণ-ভিত্তিক ছন্দে পর্যালোচিত ও সংশোধিত হয়।
- স্তর ৫, সমন্বয়: SLO ও ত্রুটি বাজেট গতি ও স্থিতিশীলতার ভারসাম্যের ভাগ করা, বস্তুনিষ্ঠ প্রক্রিয়া হিসেবে প্রতিষ্ঠান-ব্যাপী একত্রিত, এবং প্রতিষ্ঠান নির্দিষ্ট সিদ্ধান্ত নির্দেশ করতে পারে যা কাঠামো সক্ষম করেছিল যা একটি ভিত্তিহীন আলোচনা এত কার্যকরভাবে সমাধান করত না।
আলোচনার জন্য ধারণা
১. আমাদের বর্তমান SLO কি প্রমাণে, নাকি আকাঙ্ক্ষায় ভিত্তিপ্রাপ্ত? ২. ত্রুটি-বাজেট নিঃশেষের জন্য আমাদের কি একটি পূর্বনির্ধারিত প্রতিক্রিয়া আছে যা আমরা প্রকৃতপক্ষে চাপের অধীনে সম্মান করব? ৩. আমরা সর্বশেষ কখন একটি গণনাকৃত ঝুঁকিতে ইচ্ছাকৃতভাবে একটি সুস্থ ত্রুটি বাজেট ব্যয় করেছি? ৪. আমাদের SLI কি প্রকৃত ব্যবহারকারী অভিজ্ঞতা পরিমাপ করছে নাকি সুবিধাজনক অভ্যন্তরীণ স্বাস্থ্য পরীক্ষা? ৫. আমাদের SLO একটি অতিরিক্ত “নয়” বাড়াতে আমাদের কী খরচ হবে, এবং সেই খরচ কি ন্যায্যতাপ্রাপ্ত হবে?
মূল বিষয়সমূহ
- একটি পরিষেবা স্তর সূচক (SLI) প্রকৃত ব্যবহারকারী অভিজ্ঞতা পরিমাপ করে; একটি পরিষেবা স্তর উদ্দেশ্য (SLO) এর প্রমাণ-ভিত্তিক লক্ষ্য; একটি ত্রুটি বাজেট ইচ্ছাকৃতভাবে ব্যয়যোগ্য অনুমোদিত ঘাটতি।
- ১০০% নির্ভরযোগ্যতা সাধারণত ভুল লক্ষ্য; ব্যবহারকারীরা প্রকৃতপক্ষে কী লক্ষ্য করেন ও প্রতিটি অতিরিক্ত বৃদ্ধির প্রকৃতপক্ষে কী খরচ হয় তাতে আপনার SLO ভিত্তি করুন।
- ত্রুটি বাজেটকে একটি পূর্বনির্ধারিত নিঃশেষ প্রতিক্রিয়াসহ একটি ব্যয়যোগ্য সম্পদ হিসেবে বিবেচনা করুন, প্রতিবার গতি-বনাম-স্থিতিশীলতা চাপের অধীনে পুনরায় বিতর্ক করার প্রয়োজন অপসারণ করে।
- সুবিধাজনক অভ্যন্তরীণ স্বাস্থ্য পরীক্ষা নয়, প্রকৃত ব্যবহারকারী অভিজ্ঞতা থেকে SLI পরিমাপ করুন।
- প্রমাণের ভিত্তিতে পর্যায়ক্রমিকভাবে SLO পর্যালোচনা ও সংশোধন করুন, যেহেতু একটি পুরনো লক্ষ্য সিস্টেম ও এর ব্যবহারকারীরা পরিবর্তিত হওয়ার সাথে সাথে এর উপযোগিতা হারায়।
তথ্যসূত্র এবং অতিরিক্ত পাঠ
- Beyer, Betsy, Chris Jones, Jennifer Petoff, and Niall Richard Murphy, eds. Site Reliability Engineering: How Google Runs Production Systems. O’Reilly Media, 2016.
- Beyer, Betsy, Niall Richard Murphy, David K. Rensin, Kent Kawahara, and Stephen Thorne, eds. The Site Reliability Workbook: Practical Ways to Implement SRE. O’Reilly Media, 2018.
- Hidalgo, Alex. Implementing Service Level Objectives: A Practical Guide to SLIs, SLOs, and Error Budgets. O’Reilly Media, 2020.
- Forsgren, Nicole, Jez Humble, and Gene Kim. Accelerate: The Science of Lean Software and DevOps. IT Revolution Press, 2018.