9.8 অন-কল ও পরিচালনগত প্রস্তুতি

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

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

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

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

মূল নীতিসমূহ

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

সুপারিশ

একটি মানবিক, টেকসই ঘূর্ণন নকশা করুন

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

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

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

পেজিং নীতিকে কাজযোগ্য, জরুরি, প্রকৃত সমস্যা সম্পর্কে করুন

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

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

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

কারণে নয়, উপসর্গ ও SLO-তে সতর্ক করুন

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

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

লঞ্চের আগে পরিচালনগত প্রস্তুতি দাবি করুন

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

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

প্রকৃতপক্ষে ব্যবহৃত রানবুক ও প্লেবুক লিখুন

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

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

আপনার গড়া জিনিসের মালিক হোন, মানবিক সীমার ভেতরে

DevOps আন্দোলন জনপ্রিয় করেছে “আপনি গড়েন, আপনি চালান”: যে দল একটি সেবা লেখে সে তার পেজারও বহন করে। সুবিধা প্রকৃত এবং রক্ষা করার যোগ্য। নির্মাতারা যখন নিজেদের পেজ অনুভব করে, তারা নির্ভরযোগ্যতায় বিনিয়োগ করে, কোলাহলপূর্ণ সতর্কতা সারায়, এবং পরিচালনযোগ্যতার জন্য নকশা করে, কারণ প্রতিক্রিয়া চক্র মূল কারণ সারাতে না পারা একটি আলাদা অপস দলে নামার বদলে ব্যক্তিগতভাবে তাদের কাছে পৌঁছায়।

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

সুচিন্তিতভাবে অন-কল ইঞ্জিনিয়ার অনবোর্ড করুন এবং গেম ডে চালান

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

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

পরিষ্কার হস্তান্তর চালান এবং অন-কল স্বাস্থ্য মাপুন

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

উদাহরণ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy (eds.), Site Reliability Engineering: How Google Runs Production Systems
• Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara, and Stephen Thorne (eds.), The Site Reliability Workbook: Practical Ways to Implement SRE
• Rob Ewaschuk, “My Philosophy on Alerting,” in Site Reliability Engineering appendix
• John Allspaw and Jesse Robbins (eds.), Web Operations: Keeping the Data on Time
• Nicole Forsgren, Jez Humble, and Gene Kim, Accelerate: The Science of Lean Software and DevOps
• Gene Kim, Jez Humble, Patrick Debois, and John Willis, The DevOps Handbook
• Michael T. Nygard, Release It! Design and Deploy Production-Ready Software
• World Health Organisation, ICD-11, entry on burn-out as an occupational phenomenon