ব্রেন্ডান গ্রেগের ব্যবহারিক পদ্ধতি (USE, RED, ফ্লেম গ্রাফ) শিখুন—ল্যাটেন্সি ও প্রোডাকশন বটলনেক তথ্যভিত্তিকভাবে তদন্ত করার জন্য, অনুমানের নয়।

ব্রেন্ডান গ্রেগ সিস্টেম পারফরম্যান্সে—বিশেষ করে লিনাক্স জগতেই—একজন অত্যন্ত প্রভাবশালী কণ্ঠ। তিনি বহুল ব্যবহৃত বই লিখেছেন, ব্যবহারিক টুল তৈরি করেছেন এবং—সবচেয়ে জরুরি—বাস্তব প্রোডাকশন সমস্যাগুলো অনুসন্ধানের পরিষ্কার পদ্ধতি শেয়ার করেছেন। টিমগুলো তার পদ্ধতি গ্রহণ করে কারণ এটি চাপের মধ্যে কাজ করে: যখন ল্যাটেন্সি বাড়ে এবং সবাই উত্তর চায়, তখন আপনাকে "হয়তো এটা X" থেকে "এটা নিশ্চিতভাবে Y"-তে ন্যূনতম নাটক নিয়ে চলে যেতে হবে।
একটি পারফরম্যান্স পদ্ধতি কোনো একক টুল বা চতুর কমান্ড নয়। এটি অনুসন্ধানের জন্য একটি পুনরাবৃত্ত নিয়ম: প্রথমে কি দেখা উচিত, আপনি যা দেখছেন তা কীভাবে ব্যাখ্যা করবেন, এবং পরবর্তী কী করবেন তা সিদ্ধান্ত নেওয়ার জন্য একটি চেকলিস্ট।
এই পুনরাবৃত্ততা অনুমান কমায়। সবচেয়ে বেশি অনুভবক্ষম বা সবচেয়ে জোরে বলা ব্যক্তির উপর নির্ভর করার পরিবর্তে, আপনি একটি সঙ্গতিপূর্ণ প্রক্রিয়া অনুসরণ করেন যা:
অনেক ল্যাটেন্সি তদন্ত প্রথম পাঁচ মিনিটেই ভুল হয়ে যায়। মানুষ সরাসরি সমাধানে ঝাঁপিয়ে পড়ে: “CPU বাড়ান,” “সার্ভিস রিস্টার্ট করুন,” “ক্যাশ বাড়ান,” “GC টিউন করুন,” “অবশ্যই নেটওয়ার্ক।” কখনও কখনও এসব সহায়ক হয়—কিন্তু প্রায়ই তারা সিগনাল লুকিয়ে দেয়, সময় নষ্ট করে বা নতুন ঝুঁকি তৈরি করে।
গ্রেগের পদ্ধতিগুলো আপনাকে “সমাধান” বিলম্বিত করতে বাধ্য করে যতক্ষণ না আপনি সহজ প্রশ্নগুলোর উত্তর দিতে পারেন: কী স্যাচুরেটেড? কী ত্রুটি দিচ্ছে? কী ধীরে হয়েছে—থ্রুপুট, কিউইং, না ব্যক্তিগত অপারেশন?
এই গাইডটি আপনাকে সুযোগ সংকুচিত করতে, সঠিক সিগনালগুলো মাপতে এবং অপটিমাইজ করার আগে বটলনেক নিশ্চিত করতে সাহায্য করবে। লক্ষ্য হলো প্রোডাকশনে ল্যাটেন্সি ও প্রোফাইলিং বিষয়ক তদন্তের জন্য একটি কাঠামোবদ্ধ ওয়ার্কফ্লো, যাতে ফলাফল সৌভাগ্যের উপর নির্ভর না করে।
লেটেন্সি একটি লক্ষণ: ব্যবহারকারীরা কাজ শেষ হওয়ার জন্য অপেক্ষা করে বেশি সময় নেন। কারণ সাধারণত অন্য কোথাও থাকে—CPU প্রতিযোগিতা, ডিস্ক বা নেটওয়ার্ক ওয়েট, লক কনটেনশন, গারবেজ কালেকশন, কিউইং, বা রিমোট ডিপেন্ডেন্সি ডিলে। কেবল ল্যাটেন্সি মাপা বলে ব্যথা আছে, তা বলে না কোথা থেকে শুরু হচ্ছে।
এই তিনটি সিগনাল সংযুক্ত:
টিউন করার আগে একই টাইম উইন্ডোর জন্য এই তিনটি ধরে রাখুন। অন্যথায় আপনি কাজ বাদ দিয়ে বা দ্রুত ব্যর্থ করে ল্যাটেন্সি “ফিক্স” করতে পারেন।
গড় ল্যাটেন্সি স্পাইকগুলো লুকায় যা ব্যবহারকারীরা মনে রাখে। ৫০ মি.সে. গড় থাকা সত্ত্বেও সার্ভিসে বারবার ২ সেকেন্ড স্টল থাকতে পারে।
পার্সেন্টাইল ট্র্যাক করুন:
ল্যাটেন্সির আকৃতিও দেখুন: p50 স্থিতিশীল কিন্তু p99 বাড়লে তা অন্তরায়যুক্ত স্টল (যেমন লক কনটেনশন, I/O হিকআপ, স্টপ-দ্য-ওয়ার্ল্ড পজ) নির্দেশ করে, সাধারণ ধীরগতির নয়।
ল্যাটেন্সি বাজেট একটি সহজ হিসাব: “যদি রিকোয়েস্ট 300 ms-এ শেষ করতে হয়, সময় কোথায় ব্যয় করা যাবে?” এটিকে ভাঙুন:
এই বাজেট প্রথম পরিমাপ কাজটিকে ফ্রেম করে: স্পাইকের সময় কোন বালতি (bucket) বেড়েছে তা চিহ্নিত করুন, তারপর সেই অংশটাই তদন্ত করুন, অন্ধভাবে টিউন না করে।
যখন কোনো সমস্যা বর্ণনা করা হয় "সিস্টেম ধীর"—তখন ল্যাটেন্সি কাজ ভেঙে যায়। গ্রেগের পদ্ধতি আগেই শুরু করে: সমস্যাকে একটি নির্দিষ্ট, পরীক্ষাযোগ্য প্রশ্নে প্ররোচিত করে।
কোনো টুল স্পর্শ করার আগে দুইটি বাক্য লিখুন:
এটি আপনাকে ভুল লেয়ার অপ্টিমাইজ করা থেকে রোধ করে—যেমন যদি ব্যথা একটি নির্দিষ্ট এন্ডপয়েন্ট বা ডাউনস্ট্রীম ডিপেনডেন্সি-তে সীমাবদ্ধ থাকে তবুও হোস্ট CPU-কে টিউন করলে ভুল হবে।
অভিযোগের সাথে মানায় এমন একটি উইন্ডো নিন এবং সম্ভব হলে একটি “ভালো” তুলনা সময়ও রাখুন।
স্পষ্টভাবে স্কোপ করুন:
এখানে সঠিক হতে হলে পরবর্তী ধাপগুলি (USE, RED, প্রোফাইলিং) দ্রুত হবে কারণ আপনি জানবেন কোন ডেটা পরিবর্তিত হওয়া উচিত যদি আপনার হাইপোথিসিস সঠিক হয়।
ডিপ্লয়, কনফিগ চেঞ্জ, ট্রাফিক শিফট, ইনফ্রা ইভেন্টগুলো লিপিবদ্ধ করুন—কিন্তু কারণটি ধরে নেবেন না। এগুলোকে লিখুন “যদি X হয়, তবে আমরা Y প্রত্যাশা করব,” যাতে আপনি দ্রুত নিশ্চিত বা বাতিল করতে পারেন।
একটি ছোট লগ সহকর্মীদের মধ্যে পুনরাবৃত্ত কাজ প্রতিরোধ করে এবং হ্যান্ডঅফ সহজ করে।
Time | Question | Scope | Data checked | Result | Next step
এমন পাঁচটি লাইনও একটি চাপগ্রস্ত ঘটনা পুনরাবৃত্ত প্রক্রিয়ায় রূপান্তর করতে পারে।
USE পদ্ধতি (Utilization, Saturation, Errors) গ্রেগের দ্রুত চেকলিস্ট—CPU, মেমরি, ডিস্ক (স্টোরেজ), এবং নেটওয়ার্ক—স্ক্যান করে যাতে আপনি অনুমান বন্ধ করে সংকোচন শুরু করতে পারেন।
ডজন টাকার ড্যাশবোর্ডের দিকে তাকানোর বদলে, প্রতিটি রিসোর্স জন্য একই তিনটি প্রশ্ন করুন:
নিয়মিত প্রয়োগ করলে এটি দ্রুতই বোঝায় কোথায় চাপ আছে।
CPU-র ক্ষেত্রে, utilization হল CPU ব্যস্ততার %, saturation দেখায় রান-কিউ চাপ বা থ্রেডগুলো চলার জন্য অপেক্ষা করছে, এবং errors-এ থাকতে পারে কন্টেইনার থ্রোটলিং বা খারাপ ইন্টারাপ্ট যে আচরণ করছে।
মেমরি-তে utilization হল ব্যবহৃত মেমরি, saturation হিসেবে পেইজিং বা ঘন ঘন গারবেজ কালেকশন দেখা যায়, এবং errors-এ অ্যালোকেশন ফেইল বা OOM ইভেন্ট অন্তর্ভুক্ত।
ডিস্ক-ে utilization হল ডিভাইস ব্যস্ত সময়, saturation হল কিউ গভীরতা ও রিড/রাইট ওয়েট টাইম, এবং errors-এ I/O ত্রুটি বা টাইমআউট থাকে।
নেটওয়ার্ক-এ utilization হল থ্রুপুট, saturation হল ড্রপ/কিউ/ল্যাটেন্সি, এবং errors-এ রিট্রান্সমিট, রিসেট বা প্যাকেট লস থাকে।
ইউজাররা ধীরে অনুভব করলে স্যাচুরেশন সিগন্যাল প্রায়ই সবচেয়ে বেশি প্রকাশ্যে আসে: কিউ, অপেক্ষার সময়, ও কনটেনশন সাধারণত ল্যাটেন্সির সাথে সরাসরি সম্পর্কিত।
সার্ভিস-লেভেল মেট্রিক্স (রিকোয়েস্ট ল্যাটেন্সি ও ত্রুটি হার মত) আপনাকে ইমপ্যাক্ট বলে। USE বলে কোথায় দেখতে হবে—কোন রিসোর্সে চাপ আছে।
একটি ব্যবহারিক লুপ:
RED পদ্ধতি আপনাকে হোস্ট গ্রাফে ডুব দেওয়ার আগে ব্যবহারকারীর অভিজ্ঞতার ওপর ধরে রাখে।
RED আপনাকে “ইন্টারেস্টিং” সিস্টেম মেট্রিক অনুসরণ করা থেকে রোধ করে যা ব্যবহারকারীদের প্রভাবিত করে না। এটি একটি সঙ্কীর্ণ লুপ আরোপ করে: কোন এন্ডপয়েন্ট ধীর, কোন ব্যবহারকারীদের জন্য, এবং কবে থেকে? যদি Duration কেবল এক রুটে স্পাইক করে আর মোট CPU ফ্ল্যাট থাকে, আপনি ইতিমধ্যেই একটি তীক্ষ্ণ সূচনা পেয়েছেন।
একটি উপকারী অভ্যাস: RED সার্ভিস ও শীর্ষ এন্ডপয়েন্ট দ্বারা ভাঙুন (বা প্রধান RPC মেথড)। এতে একটি বিস্তৃত অবনতি ও লোকালাইজড রিগ্রেশন আলাদা করা সহজ হয়।
RED আপনাকে কোথায় ব্যথা হচ্ছে বলে। USE আপনাকে পরীক্ষা করতে সাহায্য করে কোন রিসোর্স দায়ী।
উদাহরণ:
লেআউটকে ফোকাসযুক্ত রাখুন:
একটি ধারাবাহিক ইনসিডেন্ট ওয়ার্কফ্লো চাইলে এই অংশটিকে USE ইনভেন্টরির সাথে জোড়া দিন (/blog/use-method-overview) যাতে আপনি "ইউজাররা অনুভব করছে" থেকে "এই রিসোর্সই কনস্ট্রেন্ট"-এ কম থ্র্যাশ দিয়ে যেতে পারেন।
একটি পারফরম্যান্স তদন্ত কয়েক মিনিটে ডজনগুলো চার্ট ও হাইপোথিসিসে বিস্তৃত হতে পারে। গ্রেগের মানসিকতা হল এটিকে সংকীর্ণ রাখা: আপনার কাজ "আরো ডেটা সংগ্রহ করা" নয়, বরং পরের সেই প্রশ্ন জিজ্ঞেস করা যা সবচেয়ে দ্রুত অনিশ্চয়তা দূর করবে।
অধিকাংশ ল্যাটেন্সি সমস্যাই একক খরচ (বা অল্প কিছু) দ্বারা আধিপত্য করে: একটি হট লক, একটি ধীর ডিপেন্ডেন্সি, একটি ওভারলোডেড ডিস্ক, একটি GC প্যাটার্ন। অগ্রাধিকরণ মানে প্রথমে সেই ডোমিন্যান্ট খরচ খোঁজা, কারণ পাঁচটি জায়গায় 5% করে কমানো সাধারণত ব্যবহারকারীর দৃশ্যমান ল্যাটেন্সি সরাবে না।
একটি ব্যবহারিক পরীক্ষা: “আমাদের দেখা ল্যাটেন্সি পরিবর্তনের বেশিরভাগ কে ব্যাখ্যা করতে পারবে কী?” যদি একটি হাইপোথিসিস কেবল একটি ছোট অংশ ব্যাখ্যা করে, তা নিম্ন-অগ্রাধিকার।
টপ-ডাউন ব্যবহার করুন যখন আপনি উত্তর দিচ্ছেন “ব্যবহারকারীরা ক্ষতিগ্রস্ত কিনা?” এন্ডপয়েন্ট থেকে শুরু করুন (RED-স্টাইল): ল্যাটেন্সি, থ্রুপুট, ত্রুটি। এই পদ্ধতি আপনাকে এমন কিছু অপ্টিমাইজ করা থেকে রোধ করে যা কৃতিক্যাল পাথে নেই।
বটম-আপ ব্যবহার করুন যখন হোস্ট স্পষ্টভাবে খারাপ অবস্থা (USE-স্টাইল লক্ষণ): CPU স্যাচুরেশন, রানঅ্যাওয়ে মেমরি প্রেসার, I/O ওয়েট। যদি একটি নোড পেগড থাকে, আপনি এন্ডপয়েন্ট পার্সেন্টাইল দেখে সময় নষ্ট করবেন কারণ_constraint বোঝা যাবে না।
যখন এলার্ট আসে, একটি শাখা বেছে নিন এবং সেটাতেই থাকুন যতক্ষণ না আপনি নিশ্চিত বা বাতিল করেন:
আপনি নিজেকে ছোট একটি সিগন্যাল সেট পর্যন্ত সীমাবদ্ধ রাখুন, তারপর কেবল যখন কিছু চলে তখনই ড্রিল ডাউন করুন। যদি আপনাকে একটি চেকলিস্ট দরকার, আপনার ধাপগুলো একটি রানবুকের সাথে লিঙ্ক করুন (/blog/performance-incident-workflow) যাতে প্রতিটি নতুন মেট্রিকের একটি উদ্দেশ্য থাকে: একটি নির্দিষ্ট প্রশ্নের উত্তর দেওয়া।
প্রোডাকশনে প্রোফাইলিং ঝুঁকিপূর্ণ মনে হতে পারে কারণ এটি লাইভ সিস্টেম স্পর্শ করে—তবুও এটি প্রায়শই বিতর্ককে প্রমাণে সেরা পথ। লগ ও ড্যাশবোর্ড বলে থাকে কী ধীর হচ্ছে; প্রোফাইলিং বলে কোথায় সময় যাচ্ছে: কোন ফাংশন হট, কোন থ্রেড অপেক্ষায়, কোন কোড পাথ ডমিনেট করছে।
প্রোফাইলিং একটি "সময় বাজেট" টুল। তত্ত্ববাদের বদলে ("এটা DB" বনাম "এটা GC"), আপনি প্রমাণ পান: "CPU স্যাম্পলগুলোর 45% JSON পারসিং-এ ছিল" বা "অধিকাংশ রিকোয়েস্ট একটি মিউটেক্সে ব্লক ছিল।" এটি পরবর্তী ধাপকে এক বা দুই কংক্রিট ফিক্সে সংকীর্ণ করে।
প্রতিটিটি একটি আলাদা প্রশ্নের উত্তর দেয়। ল্যাটেন্সি বেশি কিন্তু CPU কম থাকলে সাধারণত off-CPU বা লক টাইম নির্দেশ করে অন-CPU হটস্পট নয়।
অনেক দল অন-ডিম্যান্ড দিয়ে শুরু করে, তারপর নিরাপত্তা বিশ্বাস করা ও পুনরাবৃত্ত সমস্যা দেখা দিলে অলওয়েজ-অন-এ গ্র্যাজুয়েট করে।
প্রোডাকশন-সেইফ প্রোফাইলিং ওয়েট কন্ট্রোল করা। সর্বদা স্যাম্পলিং পছন্দ করুন (প্রতিটি ইভেন্ট ট্রেস না করে), ক্যাপচার উইন্ডো ছোট রাখুন (উদাহরণস্বরূপ 10–30 সেকেন্ড), এবং ক্যানারি-তে আগে ওভারহেড মাপুন। সন্দেহ হলে, কম-ফ্রিকোয়েন্সি স্যাম্পলিং দিয়ে শুরু করুন এবং সিগন্যাল যদি শব্দজনিত হয় তবেই বাড়ান।
ফ্লেম গ্রাফগুলি প্রোফাইলিং উইন্ডোর সময় কোন স্থানে স্যাম্পল সময় কেটে গেছে তা ভিজ্যুয়ালাইজ করে। প্রতিটি "বক্স" একটি ফাংশন (বা স্ট্যাক ফ্রেম), এবং প্রতিটি স্ট্যাক দেখায় কিভাবে সম্পাদন ওই ফাংশনে পৌঁছেছে। এগুলো দ্রুত প্যাটার্ন ধরতে চমৎকার—কিন্তু তারা অটোম্যাটিকভাবে বলে না “বাগ এখানেই।”
ফ্লেম গ্রাফ সাধারণত on-CPU স্যাম্পল প্রতিনিধিত্ব করে: প্রোগ্রাম যখন সত্যিই CPU কোরে চালছিল তখন সময়। এটি CPU-ভিত্তিক কোডপাথ, অপ্রয়োজনীয় পার্সিং, অতিরিক্ত সিরিয়ালাইজেশন বা সূক্ষ্ম হটস্পট হাইলাইট করতে পারে।
এটি সরাসরি ডিস্ক/নেটওয়ার্ক ওয়েট, শিডিউলার ডিলে, বা মিউটেক্সে ব্লকিং দেখায় না (এগুলো off-CPU সময় এবং আলাদা প্রোফাইলিং দরকার)। এটি ব্যবহারকারীর দৃশ্যমান ল্যাটেন্সির কারণ প্রমাণ করে না যতক্ষণ না আপনি এটিকে একটি সুনির্দিষ্ট লক্ষ্যের সঙ্গে জুড়েন।
বিস্তৃত বক্সকে দোষারোপ করা কৌতূহল তৈরি করে, কিন্তু প্রশ্ন করুন: এটি কি আপনি বদলাতে পারবেন এমন একটি হটস্পট, না upstream-এর কারণে malloc, GC, বা লগিং-এ সময় কাটছে? এছাড়াও JIT, ইনলাইনিং, সিম্বল অনুপস্থিতি প্রেক্ষাপটে কনটেক্সট মিসিং থাকতে পারে, ফলে একটি বক্স অপরাধী হিসেবে উঠে আসে যখন তা কেবল ম্যাসেঞ্জার।
ফ্লেম গ্রাফকে একটি সীমাবদ্ধ প্রশ্নের উত্তর হিসেবে বিবেচনা করুন: কোন এন্ডপয়েন্ট, কোন টাইম উইন্ডো, কোন হোস্ট, এবং কি বদলেছে। "বিফোর বনাম আফটার" (বা "হেলদি বনাম ডিগ্রেডেড") ফ্লেম গ্রাফ তুলনা করুন একই রিকোয়েস্ট পাথে যাতে প্রোফাইলিং শব্দ এড়ানো যায়।
ল্যাটেন্সি স্পাইক হলে অনেক টিম প্রথমে CPU% দেখে। এটা বোধগম্য—তবুও প্রায়ই ভুল দিকে নির্দেশ করে। একটি সার্ভিস মাত্র 20% CPU-তে থেকেও আর্তনাদজনকভাবে ধীর হতে পারে যদি থ্রেডগুলো তাদের বেশিরভাগ সময় চলমান না করে কাটায়।
CPU% প্রশ্নের উত্তর দেয় "প্রসেসর কত ব্যস্ত?" এটি উত্তর দেয় না "আমার রিকোয়েস্ট সময় কোথায় গেল?" রিকোয়েস্ট থ্রেড ঘুমাচ্ছে, ব্লক করা, বা পার্কড থাকলে ওয়াল-ক্লক সময় আবারও বাড়ে।
একটি মূল ধারণা: একটি রিকোয়েস্টের ওয়াল-ক্লক সময়ে আছে on-CPU কাজ এবং off-CPU অপেক্ষা উভয়ই।
Off-CPU সময় সাধারণত ডিপেন্ডেন্সি ও কনটেনশনের পিছনে লুকানো থাকে:
কিছু সিগনাল প্রায়ই off-CPU বটলনেকের সাথে সম্পর্কিত:
এই লক্ষণগুলো বলে “আমরা অপেক্ষা করছি,” কিন্তু কী জন্য অপেক্ষা করছি তা বলে না।
Off-CPU প্রোফাইলিং সময়কে সেই কারণে অ্যাট্রিবিউট করে যার জন্য আপনি চলছে না: সিস্টেম কলেই ব্লক, লকের ওপর অপেক্ষা, স্লিপ, বা ডিসকাশেড হওয়া। এটি ল্যাটেন্সি কাজের জন্য শক্তিশালী কারণ এটি অস্পষ্ট ধীরগতি কার্যকর বিভাগে রূপান্তর করে: “মিউটেক্স X-এ ব্লক,” “disk থেকে read()-এ অপেক্ষা,” বা “upstream-এ connect()-এ আটকে।” একবার আপনি অপেক্ষার নাম বলতে পারেন, আপনি এটি মাপতে, নিশ্চিত করতে এবং ঠিক করতে পারবেন।
পারফরম্যান্স কাজ প্রায়ই একই মুহূর্তে ফেইল করে: কেউ একটি সন্দেহজনক মেট্রিক দেখে সেটাকে “সমস্যা” বলে ঘোষণা করে এবং টিউন শুরু করে। গ্রেগের পদ্ধতি আপনাকে ধীর হতে এবং সীমা নির্ধারণ করা পর্যন্ত প্রমাণ করতে বাধ্য করে।
একটি বটলনেক হল সেই রিসোর্স/কম্পোনেন্ট যা বর্তমানে থ্রুপুটকে ক্যাপ কিংবা ল্যাটেন্সি চালায়। যদি আপনি এটিকে লাঘব করেন, ব্যবহারকারীরা উন্নতি দেখবে।
একটি হটস্পট হল যেখানে সময় কাটে (উদাহরণস্বরূপ, প্রোফাইলে একটি ফাংশন ঘনঘন দেখা যায়)। হটস্পট বটলনেক হতে পারে—বা কেবল ব্যস্ত কাজ যা স্লো পাথকে প্রভাবিত করে না।
নয়েজ হল এমন সবকিছু যা অর্থপূর্ণ দেখায় কিন্তু তা নয়: ব্যাকগ্রাউন্ড জব, এককালীন স্পাইক, স্যাম্পলিং আর্টিফ্যাক্ট, ক্যাশিং প্রভাব, বা "টপ টকার" যা ব্যবহারকারীর দৃশ্যমান সমস্যার সাথে সম্পর্কহীন।
শুরু করুন একটি পরিষ্কার before স্ন্যাপশট ক্যাপচার করে: ইউজার-ফেসিং সিম্পটম (ল্যাটেন্সি বা ত্রুটি হার) এবং প্রধান সন্দেহজনক সিগন্যাল (CPU স্যাচুরেশন, কিউ গভীরতা, ডিস্ক I/O, লক কনটেনশন ইত্যাদি)। তারপর একটি নিয়ন্ত্রিত পরিবর্তন করুন যা কেবল আপনার সন্দেহভাজন কারণটাকেই প্রভাবিত করা উচিত।
কার্যকারিতা পরীক্ষা:
করিলেশন একটি ইঙ্গিত; একে ফাইনাল রায় ভাববেন না। যদি “CPU বাড়লে ল্যাটেন্সি বাড়ে” দেখেন, CPU উপলব্ধতা পরিবর্তন বা CPU কাজ কমিয়ে যাচাই করুন যে ল্যাটেন্সি অনুসরণ করে কি না।
লিখে রাখুন: কী মাপা হয়েছিল, ঠিক কোন পরিবর্তন করা হয়েছিল, before/after ফলাফল, ও দেখা উন্নতি। এটি এককালীন জয়ের বদলে একটি পুনর্ব্যবহারযোগ্য প্লেবুক তৈরি করে এবং ভবিষ্যতে “ইন্টুইশন” ইতিহাস বদলে দেয়া থেকে রোধ করে।
পারফরমেন্স ইনসিডেন্টগুলো জরুরি মনে হয়—এটিই সেই সময় যখন অনুমান প্রবেশ করে। একটি হালকা, পুনরাবৃত্ত ওয়ার্কফ্লো আপনাকে “কিছু ধীর” থেকে “আমরা জানি কি বদলেছে” তে দ্রুত নিয়ে আসে, থ্র্যাশ ছাড়াই।
সনাক্ত: ইউজার-ফেসিং ল্যাটেন্সি ও ত্রুটি হারে এলার্ট দিন, কেবল CPU নয়। যখন p95/p99 ল্যাটেন্সি একটি স্থায়ী উইন্ডো পার করে তখন পেজিং করুন।
ট্রায়াজ: দ্রুত তিনটি প্রশ্নের উত্তর দিন: কি ধীরে, কখন শুরু, এবং কারা প্রভাবিত? যদি আপনি স্কোপ (সার্ভিস, এন্ডপয়েন্ট, রিজিওন, কোহর্ট) বলতে না পারেন, আপনি অপ্টিমাইজ করার জন্য প্রস্তুত নন।
পরিমাপ: এমন প্রমাণ সংগ্রহ করুন যা বটলনেক সংকীর্ণ করে। সময়সীমাবদ্ধ ক্যাপচার (উদাহরণ: 60–180 সেকেন্ড) পছন্দ করুন যাতে আপনি “খারাপ” বনাম “ভালো” তুলনা করতে পারেন।
ফিক্স: একবারে এক জিনিস বদলান, তারপর একই সিগন্যালগুলো পুনরায় মাপুন উন্নতি নিশ্চিত করতে এবং প্ল্যাসিবো বাদ দিতে।
একটি শেয়ারড ড্যাশবোর্ড রাখুন যাতে সবাই ইনসিডেন্টে ব্যবহার করে। এটিকে বোরিং ও কনসিস্টেন্ট রাখুন:
লক্ষ্য সবকিছু গ্রাফ করা নয়; এটি প্রথম-তথ্য-উদ্ধারির সময় ছোট করা।
যে এন্ডপয়েন্টগুলো সবচেয়ে গুরুত্বপূর্ণ (চেকআউট, লগইন, সার্চ) সেগুলোতে ইনস্ট্রুমেন্ট করুন, সব এন্ডপয়েন্ট নয়। প্রত্যেকটির জন্য সম্মত হোন: প্রত্যাশিত p95, সর্বোচ্চ ত্রুটি হার, এবং মূল ডিপেনডেন্সি (DB, ক্যাশ, থার্ড-পার্টি)।
পরবর্তী আউটেজের আগে, একটি ক্যাপচার কিটে সম্মত হোন:
এটি /runbooks/latency-তে সংক্ষিপ্ত রানবুক হিসেবে ডকুমেন্ট করুন, কে ক্যাপচার চালাতে পারে এবং আর্টিফ্যাক্ট কোথায় সংরক্ষণ হবে তা উল্লেখ করে।
গ্রেগের মেথডোলজি মুলত নিয়ন্ত্রিত পরিবর্তন ও দ্রুত যাচাই-র ওপর ভিত্তি করে। যদি আপনার টিম Koder.ai (একটি চ্যাট-ড্রিভেন প্ল্যাটফর্ম ওয়েব, ব্যাকএন্ড, ও মোবাইল অ্যাপ তৈরি ও ইটারেট করার জন্য) ব্যবহার করে সার্ভিস তৈরি করে, দুইটি ফিচার এই মানসিকতার সাথে সাদৃশ্যপূর্ণ:
আপনি যদি ইনসিডেন্টে নতুন কোড তৈরি না করলেও, ছোট ডিফ, পরিমাপযোগ্য ফলাফল, ও দ্রুত উল্টানোর অভ্যাসগুলোই গ্রেগ প্রচার করে।
10:15am—আপনার ড্যাশবোর্ড দেখাচ্ছে API-এর p99 ল্যাটেন্সি ~120ms থেকে ~900ms-এ লাফিয়েছে পিক ট্রাফিকে। ত্রুটি হার স্থিতিশীল, কিন্তু কাস্টমাররা ধীর রিকোয়েস্ট রিপোর্ট করছে।
সার্ভিস-ফার্স্ট: Rate, Errors, Duration।
আপনি Duration এন্ডপয়েন্ট অনুযায়ী স্লাইস করলে দেখতে পাবেন একটি রুট p99-এ ডমিনেট করছে: POST /checkout। Rate 2× বাড়েছে, ত্রুটি স্বাভাবিক, কিন্তু কনকারেন্সি বাড়লে Duration স্পাইক করে—এটা কিউইং বা কনটেনশন ইঙ্গিত করে, সরাসরি ফেইল নয়।
পরবর্তী ধাপে পরীক্ষা করুন latency compute টাইম নাকি waiting time: অ্যাপ্লিকেশন “হ্যান্ডলার টাইম” বনাম মোট রিকোয়েস্ট টাইম তুলনা করুন (ট্রেসিং থাকলে upstream/span)। হ্যান্ডলার টাইম কম, মোট টাইম বেশি—রিকয়েস্টগুলো অপেক্ষায় আছে।
ইনভেন্টরি করে দেখুন: Utilization, Saturation, Errors—CPU, মেমরি, ডিস্ক, নেটওয়ার্ক।
CPU utilization মাত্র ~35%, কিন্তু CPU run queue ও কনটেক্সট স্যুইচ বাড়ছে। ডিস্ক ও নেটওয়ার্ক steady। ওই মিল (কম CPU% কিন্তু বেশি অপেক্ষা) একটি ক্লাসিক সংকেত: থ্রেডগুলো CPU বার্ণ করছে না—তারা ব্লক হচ্ছে।
আপনি স্পাইকের সময় একটি off-CPU প্রোফাইল ক্যাপচার করলে একটি শেয়ার করা “promotion validation” ক্যাশের চারপাশে মিউটেক্সে প্রচুর সময় ব্লক করা দেখা যায়।
আপনি গ্লোবাল লক বদলে পার-কী লক (বা লক-ফ্রি রিড পাথ) প্রয়োগ করে ডিপ্লয় করেন, এবং দেখেন p99 বেসলাইনে ফিরে আসে যখন Rate উপরে থাকে।
পোস্ট-ইনসিডেন্ট চেকলিস্ট: