SRE (সাইট নির্ভরযোগ্যতা প্রকৌশল) হল ওয়েব প্রকল্পের প্রাপ্যতা নিশ্চিত করার একটি পদ্ধতি। এটি DevOps-এর জন্য একটি কাঠামো হিসাবে বিবেচিত হয় এবং DevOps অনুশীলনগুলি প্রয়োগ করার ক্ষেত্রে কীভাবে সাফল্য অর্জন করা যায় সে সম্পর্কে কথা বলে। এই নিবন্ধে অনুবাদ অধ্যায় 4 পরিষেবা স্তরের উদ্দেশ্য বই সাইট নির্ভরযোগ্যতা প্রকৌশল গুগল থেকে। আমি নিজে এই অনুবাদটি প্রস্তুত করেছি এবং পর্যবেক্ষণ প্রক্রিয়াগুলি বোঝার ক্ষেত্রে আমার নিজের অভিজ্ঞতার উপর নির্ভর করেছি। টেলিগ্রাম চ্যানেলে মনিটরিম_ইট и হাবরে শেষ পোস্ট আমি পরিষেবা স্তরের লক্ষ্য সম্পর্কে একই বইয়ের 6 অধ্যায়ের একটি অনুবাদও প্রকাশ করেছি।

বিড়াল দ্বারা অনুবাদ. পড়া ভোগ!

কোন সূচকগুলি আসলে গুরুত্বপূর্ণ এবং কীভাবে সেগুলিকে পরিমাপ ও মূল্যায়ন করা যায় সে সম্পর্কে কোনও ধারণা না থাকলে পরিষেবা পরিচালনা করা অসম্ভব৷ এই লক্ষ্যে, আমরা আমাদের ব্যবহারকারীদের একটি নির্দিষ্ট স্তরের পরিষেবা সংজ্ঞায়িত করি এবং প্রদান করি, তারা আমাদের অভ্যন্তরীণ API বা একটি সর্বজনীন পণ্য ব্যবহার করুক না কেন।

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

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

পরিষেবা স্তরের পরিভাষা

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

ইন্ডিকেটর

SLI হল একটি পরিষেবা স্তর নির্দেশক—প্রদত্ত পরিষেবার স্তরের একটি দিক সম্পর্কে সতর্কতার সাথে সংজ্ঞায়িত পরিমাণগত পরিমাপ।

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

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

আরেকটি ধরনের SLI যা SRE-এর জন্য গুরুত্বপূর্ণ তা হল প্রাপ্যতা, বা সময়ের অংশ যেখানে একটি পরিষেবা ব্যবহার করা যেতে পারে। প্রায়ই সফল অনুরোধের হার হিসাবে সংজ্ঞায়িত করা হয়, কখনও কখনও ফলন বলা হয়। (জীবনকাল—সম্ভাব্য যে ডেটা একটি বর্ধিত সময়ের জন্য ধরে রাখা হবে—ডেটা স্টোরেজ সিস্টেমের জন্যও গুরুত্বপূর্ণ।) যদিও 100% প্রাপ্যতা সম্ভব নয়, 100% এর কাছাকাছি প্রাপ্যতা প্রায়শই অর্জনযোগ্য; প্রাপ্যতার মানগুলি হিসাবে প্রকাশ করা হয় "নয়" এর সংখ্যা » প্রাপ্যতার শতাংশ। উদাহরণস্বরূপ, 99% এবং 99,999% প্রাপ্যতা "2 নাইন" এবং "5 নাইন" হিসাবে লেবেল হতে পারে। Google Compute Engine-এর বর্তমান বিবৃত প্রাপ্যতা লক্ষ্য হল "সাড়ে তিন নাইন" বা 99,95%৷

গোল

একটি SLO হল একটি পরিষেবা স্তরের উদ্দেশ্য: একটি লক্ষ্য মান বা পরিষেবা স্তরের মানগুলির পরিসর যা SLI দ্বারা পরিমাপ করা হয়। SLO-এর একটি স্বাভাবিক মান হল "SLI ≤ লক্ষ্য" বা "নিম্ন সীমা ≤ SLI ≤ উচ্চ সীমা"। উদাহরণ স্বরূপ, আমরা সিদ্ধান্ত নিতে পারি যে আমরা SLO-কে 100 মিলিসেকেন্ডেরও কম গড় অনুসন্ধান ক্যোয়ারী লেটেন্সিতে সেট করে শেক্সপিয়র অনুসন্ধান ফলাফল "দ্রুত" ফিরিয়ে দেব।

সঠিক SLO নির্বাচন করা একটি জটিল প্রক্রিয়া। প্রথমত, আপনি সবসময় একটি নির্দিষ্ট মান নির্বাচন করতে পারবেন না। আপনার পরিষেবাতে বহিরাগত ইনকামিং HTTP অনুরোধগুলির জন্য, প্রতি সেকেন্ডে ক্যোয়ারী (QPS) মেট্রিক প্রাথমিকভাবে আপনার পরিষেবা দেখার জন্য আপনার ব্যবহারকারীদের ইচ্ছা দ্বারা নির্ধারিত হয় এবং আপনি এর জন্য একটি SLO সেট করতে পারবেন না।

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

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

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

চুক্তি

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

SRE সাধারণত SLA তৈরিতে জড়িত নয় কারণ SLA ব্যবসা এবং পণ্যের সিদ্ধান্তের সাথে ঘনিষ্ঠভাবে আবদ্ধ। SRE, যাইহোক, ব্যর্থ SLO এর পরিণতি প্রশমিত করতে সাহায্য করার সাথে জড়িত। তারা SLI নির্ধারণেও সাহায্য করতে পারে: স্পষ্টতই, চুক্তিতে SLO পরিমাপ করার জন্য একটি উদ্দেশ্যমূলক উপায় থাকতে হবে বা মতবিরোধ থাকবে।

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

এত তত্ত্ব - এখন অভিজ্ঞতা.

অনুশীলনে সূচক

প্রদত্ত যে আমরা উপসংহারে পৌঁছেছি যে পরিষেবার স্তর পরিমাপ করার জন্য উপযুক্ত মেট্রিকগুলি নির্বাচন করা গুরুত্বপূর্ণ, আপনি এখন কীভাবে জানেন যে কোনও পরিষেবা বা সিস্টেমের জন্য কোন মেট্রিক্স গুরুত্বপূর্ণ?

আপনি এবং আপনার ব্যবহারকারীরা কি সম্পর্কে যত্নশীল?

আপনাকে একটি SLI হিসাবে প্রতিটি মেট্রিক ব্যবহার করতে হবে না যা আপনি একটি মনিটরিং সিস্টেমে ট্র্যাক করতে পারেন; ব্যবহারকারীরা একটি সিস্টেম থেকে কী চান তা বোঝা আপনাকে বেশ কয়েকটি মেট্রিক্স নির্বাচন করতে সহায়তা করবে। অনেকগুলি সূচক নির্বাচন করা গুরুত্বপূর্ণ সূচকগুলিতে ফোকাস করা কঠিন করে তোলে, যখন একটি ছোট সংখ্যা নির্বাচন করা আপনার সিস্টেমের বড় অংশগুলিকে অযৌক্তিক রেখে যেতে পারে। আমরা সাধারণত একটি সিস্টেমের স্বাস্থ্য মূল্যায়ন এবং বোঝার জন্য বেশ কয়েকটি মূল সূচক ব্যবহার করি।

SLI এর পরিপ্রেক্ষিতে পরিষেবাগুলিকে সাধারণত কয়েকটি ভাগে ভাগ করা যেতে পারে যা তাদের সাথে প্রাসঙ্গিক:

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

সূচক সংগ্রহ

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

সমষ্টি

সরলতা এবং ব্যবহারের সহজতার জন্য, আমরা প্রায়শই কাঁচা পরিমাপগুলিকে একত্রিত করি। এই সাবধানে করা আবশ্যক.

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

বেশীরভাগ সূচকগুলিকে গড়ের পরিবর্তে বিতরণ হিসাবে ভাল দেখা হয়। উদাহরণস্বরূপ, SLI লেটেন্সির জন্য, কিছু অনুরোধ দ্রুত প্রক্রিয়া করা হবে, যখন কিছু সবসময় বেশি সময় নেয়, কখনও কখনও অনেক বেশি। একটি সাধারণ গড় এই দীর্ঘ বিলম্ব লুকাতে পারে। চিত্রটি একটি উদাহরণ দেখায়: যদিও একটি সাধারণ অনুরোধ পরিবেশন করতে প্রায় 50 ms লাগে, 5% অনুরোধ 20 গুণ ধীর! শুধুমাত্র গড় বিলম্বের উপর ভিত্তি করে পর্যবেক্ষণ এবং সতর্কতা দিনভর আচরণে পরিবর্তন দেখায় না, যখন প্রকৃতপক্ষে কিছু অনুরোধের প্রক্রিয়াকরণের সময় লক্ষণীয় পরিবর্তন দেখা যায় (সর্বোচ্চ লাইন)।

50, 85, 95, এবং 99 শতাংশ সিস্টেম লেটেন্সি। Y অক্ষ লগারিদমিক বিন্যাসে আছে।

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

পরিসংখ্যানগত ত্রুটির উপর নোট করুন

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

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

প্রমিতকরণ সূচক

আমরা SLI-এর সাধারণ বৈশিষ্ট্যগুলিকে মানক করার পরামর্শ দিই যাতে আপনাকে প্রতিবার সেগুলি সম্পর্কে অনুমান করতে না হয়৷ স্ট্যান্ডার্ড প্যাটার্নগুলিকে সন্তুষ্ট করে এমন কোনও বৈশিষ্ট্য একটি পৃথক SLI-এর স্পেসিফিকেশন থেকে বাদ দেওয়া যেতে পারে, উদাহরণস্বরূপ:

• একত্রিত ব্যবধান: "গড় 1 মিনিটের বেশি"
• একত্রিত এলাকা: "ক্লাস্টারের সমস্ত কাজ"
• কত ঘন ঘন পরিমাপ নেওয়া হয়: "প্রতি 10 সেকেন্ডে"
• কি অনুরোধ অন্তর্ভুক্ত করা হয়েছে: "HTTP ব্ল্যাক বক্স মনিটরিং কাজ থেকে পান"
• কীভাবে ডেটা পাওয়া যায়: "সার্ভারে পরিমাপ করা আমাদের পর্যবেক্ষণের জন্য ধন্যবাদ"
• ডেটা অ্যাক্সেস লেটেন্সি: "শেষ বাইটের সময়"

প্রচেষ্টা বাঁচাতে, প্রতিটি সাধারণ মেট্রিকের জন্য পুনরায় ব্যবহারযোগ্য SLI টেমপ্লেটের একটি সেট তৈরি করুন; তারা প্রত্যেকের জন্য একটি নির্দিষ্ট SLI বলতে কী বোঝায় তা সহজ করে তোলে।

অনুশীলনে লক্ষ্য

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

আপনার লক্ষ্য নির্ধারণ করুন

সর্বাধিক স্পষ্টতার জন্য, এটি সংজ্ঞায়িত করা উচিত কিভাবে SLOs পরিমাপ করা হয় এবং কোন শর্তে তারা বৈধ। উদাহরণস্বরূপ, আমরা নিম্নলিখিতটি বলতে পারি (দ্বিতীয় লাইনটি প্রথমটির মতোই, তবে SLI ডিফল্ট ব্যবহার করে):

• 99% (গড় 1 মিনিটের বেশি) RPC কলগুলি 100ms এর কম সময়ে সম্পন্ন হবে (সমস্ত ব্যাকএন্ড সার্ভার জুড়ে পরিমাপ করা হয়)।
• 99% গেট RPC কল 100ms এর কম সময়ে সম্পন্ন হবে।

কর্মক্ষমতা বক্ররেখার আকৃতি গুরুত্বপূর্ণ হলে, আপনি একাধিক SLO উল্লেখ করতে পারেন:

• RPC কলের 90% 1 মিসে-এর কম সময়ে সম্পন্ন হয়।
• RPC কলের 99% 10 মিসে-এর কম সময়ে সম্পন্ন হয়।
• RPC কলের 99.9% 100 মিসে-এর কম সময়ে সম্পন্ন হয়।

যদি আপনার ব্যবহারকারীরা ভিন্ন ভিন্ন কাজের চাপ তৈরি করে: বাল্ক প্রসেসিং (যার জন্য থ্রুপুট গুরুত্বপূর্ণ) এবং ইন্টারেক্টিভ প্রসেসিং (যার জন্য লেটেন্সি গুরুত্বপূর্ণ), প্রতিটি লোড ক্লাসের জন্য আলাদা লক্ষ্য নির্ধারণ করা সার্থক হতে পারে:

• গ্রাহকের অনুরোধের 95% থ্রুপুট প্রয়োজন। কার্যকর করা RPC কলের গণনা সেট করুন <1 সেকেন্ড।
• 99% ক্লায়েন্ট বিলম্বের বিষয়ে যত্নশীল। ট্রাফিক <1 KB এবং চলমান <10 ms সহ RPC কলের গণনা সেট করুন।

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

SLO লঙ্ঘনের শতাংশ ত্রুটি বাজেটের সাথে তুলনা করা যেতে পারে (অধ্যায় 3 এবং বিভাগ দেখুন "ত্রুটি বাজেটের জন্য প্রেরণা"), প্রক্রিয়ার ইনপুট হিসাবে ব্যবহৃত পার্থক্য মান সহ যা সিদ্ধান্ত নেয় কখন নতুন রিলিজ স্থাপন করতে হবে।

লক্ষ্য মান নির্বাচন

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

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

সরল হও
জটিল SLI গণনা সিস্টেমের কর্মক্ষমতার পরিবর্তনগুলিকে আড়াল করতে পারে এবং সমস্যার কারণ খুঁজে পাওয়া কঠিন করে তুলতে পারে।

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

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

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

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

আপনার পরিমাপ নিয়ন্ত্রণ

SLI এবং SLO হল মূল উপাদান যা সিস্টেম পরিচালনা করতে ব্যবহৃত হয়:

• SLI সিস্টেম নিরীক্ষণ এবং পরিমাপ.
• SLI-এর সাথে SLO-এর তুলনা করুন এবং পদক্ষেপের প্রয়োজন কিনা তা সিদ্ধান্ত নিন।
• যদি পদক্ষেপের প্রয়োজন হয়, লক্ষ্য অর্জনের জন্য কী ঘটতে হবে তা নির্ধারণ করুন।
• এই কর্ম সম্পূর্ণ করুন.

উদাহরণস্বরূপ, যদি পদক্ষেপ 2 দেখায় যে অনুরোধের সময় শেষ হয়ে গেছে এবং কিছু না করা হলে কয়েক ঘন্টার মধ্যে SLO ভেঙে যাবে, ধাপ 3-তে অনুমান পরীক্ষা করা জড়িত যে সার্ভারগুলি CPU আবদ্ধ এবং আরও সার্ভার যোগ করা লোড বিতরণ করবে। একটি SLO ছাড়া, আপনি জানতে পারবেন না যে (বা কখন) পদক্ষেপ নিতে হবে।

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

আপনার ব্যবহারকারীদের জন্য বাস্তবসম্মত প্রত্যাশা সেট করতে, নিম্নলিখিত কৌশলগুলির একটি বা উভয় ব্যবহার করুন:

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

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

অনুশীলনে চুক্তি

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

শেষ পর্যন্ত অনুবাদ পড়ার জন্য আপনাকে ধন্যবাদ. মনিটরিং সম্পর্কে আমার টেলিগ্রাম চ্যানেলে সাবস্ক্রাইব করুন মনিটরিম_ইট и মিডিয়াম ব্লগ.

উত্স: www.habr.com