ব্যবহারকারী-দৃশ্যমান ফাংশন মনিটর করুন, এটি নির্ণয়ের জন্য যথেষ্ট রিসোর্স ও অ্যাপ্লিকেশন প্রমাণ যোগ করুন, এবং কেবল সময়োপযোগী মানব পদক্ষেপ প্রয়োজন এমন অবস্থার জন্য পেজ করুন। প্রতিটি অ্যালার্টের সাথে একটি মালিক, একটি প্রথম পদক্ষেপ এবং এস্কেলেশন যুক্ত করুন। ইনসিডেন্টের সময় প্রশমন সমন্বয় করুন, প্রমাণ সুরক্ষিত করুন এবং প্রকৃত ব্যবহারকারী যাত্রার মাধ্যমে পুনরুদ্ধার যাচাই করুন।
গুরুত্বপূর্ণ ফাংশন দিয়ে শুরু করুন
একটি সার্ভার পিং-এ সাড়া দিলে এটি প্রমাণ হয় না যে এর অ্যাপ্লিকেশন কাজ করে। একটি প্রতিনিধিত্বমূলক, নিরীহ ব্যবহারকারী যাত্রা বেছে নিন, যেমন একটি পাবলিক পেজ আনা বা একটি নিয়ন্ত্রিত পরীক্ষা এন্ডপয়েন্টে অ্যাক্সেস করা। সফলতা কেমন দেখায় তা নির্ধারণ করুন এবং এমন সিন্থেটিক চেক এড়িয়ে চলুন যা প্রতিটি রানে প্রকৃত অর্ডার তৈরি করে, কন্টেন্ট প্রকাশ করে বা গ্রাহক বিজ্ঞপ্তি পাঠায়।
অ্যাপ্লিকেশনের ভিতরে এবং একটি উপযুক্ত বাইরের দৃষ্টিকোণ থেকেও মনিটর করুন। বাহ্যিক পর্যবেক্ষণ অ্যাক্সেস বা রাউটিং সমস্যা প্রকাশ করতে পারে যা সার্ভার দেখে না। অভ্যন্তরীণ পরিমাপ যাত্রা কেন ব্যর্থ হয়েছে তা ব্যাখ্যা করতে পারে। প্রতিটি মেট্রিক উপলব্ধ বলেই একটি বড় ড্যাশবোর্ড সংগ্রহ না করে উভয় দৃষ্টিভঙ্গিকে ফাংশনের সাথে সংযুক্ত রাখুন।
ডায়াগনস্টিক মূল্য আছে এমন সংকেত বেছে নিন
Google-এর SRE নির্দেশনা ব্যবহারকারী-মুখী সিস্টেমের জন্য লেটেন্সি, ট্রাফিক, ত্রুটি এবং স্যাচুরেশনকে উপকারী সংকেত হিসেবে তুলে ধরে। এগুলি আচরণ বর্ণনা করতে ব্যবহার করুন: প্রতিক্রিয়ার সময়, অনুরোধের পরিমাণ, অসফল অনুরোধ এবং সীমাবদ্ধ রিসোর্সের উপর চাপ। একটি ওয়েবসাইট, একটি ট্রান্সফার সেবা এবং একটি ব্যাকগ্রাউন্ড ওয়ার্কারের জন্য একই মেট্রিক সংজ্ঞা কাজ করে বলে ধরে না নিয়ে অ্যাপ্লিকেশনের উপযুক্ত পরিমাপ বেছে নিন।
যেখানে গুরুত্বপূর্ণ সেখানে সফল ও ব্যর্থ অনুরোধের আচরণ আলাদা করুন, এবং কেবল গড় নয় ধীর-টেইল ফলাফলও পরীক্ষা করুন। সেবা ব্যাখ্যা করলে মেমোরি চাপ, ডিস্ক স্পেস, কিউ ডেপথ বা অ্যাপ্লিকেশন-নির্দিষ্ট সীমা যোগ করুন। উপকারী ব্যাচ কাজের সময় উচ্চ CPU রিডিং স্বাভাবিক হতে পারে; ব্যবহারকারী-দৃশ্যমান প্রভাব নির্ধারণ করে তাৎক্ষণিক পদক্ষেপ প্রয়োজন কি না।
প্রতিটি অ্যালার্টকে একটি পদক্ষেপ এবং একটি মালিক দিন
একটি অ্যালার্টে প্রভাবিত ফাংশন, পর্যবেক্ষিত অবস্থা এবং উপকারী প্রথম চেক উল্লেখ করা উচিত। এটি ডিপ্লয় করার আগে একটি মালিক এবং একটি এস্কেলেশন পথ নির্ধারণ করুন। দ্রুত হস্তক্ষেপ প্রয়োজন এমন অবস্থা এবং নির্ধারিত পর্যালোচনার উপযুক্ত বিষয়গুলির মধ্যে পার্থক্য করুন। বারবার কম-মূল্যের পেজ অপারেটরদের সিস্টেম উপেক্ষা করতে শেখায় এবং গুরুত্বপূর্ণ সংকেত চেনা কঠিন করে তোলে।
অস্পষ্টতা দূর করতে একটি ছোট অ্যালার্ট পর্যালোচনা ব্যবহার করুন। এই উদাহরণমূলক টেবিল সম্ভাব্য মনিটরিং সিদ্ধান্ত বর্ণনা করে, SwissOctet সাপোর্ট কভারেজ বা প্রাপ্যতার প্রতিশ্রুতি নয়। থ্রেশহোল্ড প্রকৃত অ্যাপ্লিকেশনের বেসলাইনের বিপরীতে পরীক্ষা করা প্রয়োজন। একটি পুনরুদ্ধার শর্ত অন্তর্ভুক্ত করুন যাতে অপারেটর জানতে পারে অ্যালার্ট কখন সরে গেছে এবং কী এখনও যাচাই করা প্রয়োজন।
| পর্যবেক্ষিত অবস্থা | উপকারী প্রতিক্রিয়া | অন্তর্ভুক্ত করার প্রসঙ্গ |
|---|---|---|
| প্রতিনিধিত্বমূলক ব্যবহারকারী যাত্রা ব্যর্থ হয় | প্রভাব মূল্যায়ন করুন এবং প্রশমন করুন | প্রভাবিত এন্ডপয়েন্ট, সময়কাল এবং সাম্প্রতিক পরিবর্তন |
| ডিস্ক পরিকল্পিত সীমার দিকে এগোচ্ছে | বৃদ্ধি এবং রিটেনশন পর্যালোচনা করুন | ভলিউম, বৃদ্ধির হার এবং নিরাপদ হেডরুম |
| ব্যাকআপ যাচাই ব্যর্থ হয় | পুনরুদ্ধার পথ সুরক্ষিত করুন | জব, শেষ ব্যবহারযোগ্য বিন্দু এবং ত্রুটি |
| রিলিজের সময় লেটেন্সি বাড়ে | পরিবর্তন পরীক্ষা করুন বা রোলব্যাক করুন | বেসলাইন, রিলিজের সময় এবং প্রভাবিত অনুরোধ |
একটি ছোট ইনসিডেন্ট কাঠামো প্রস্তুত করুন
একটি প্রতিক্রিয়া প্রক্রিয়া চাপের মধ্যে বোধগম্য হওয়া উচিত। একটি সমন্বয়কারী, প্রযুক্তিগত কাজ পরিচালনাকারী একজন এবং ইনসিডেন্ট আলাদা ভূমিকা প্রয়োজনীয় হওয়ার মতো বড় হলে আপডেটের দায়িত্বে থাকা একজনকে নাম দিন। একটি ছোট প্রকল্প ভূমিকা একত্রিত করতে পারে, তবে এটি একটি স্পষ্ট সিদ্ধান্ত বিন্দু থেকে উপকৃত হয়। সেবা ব্যর্থ হওয়ার আগে একটি যোগাযোগ চ্যানেলে সম্মত হন।
Google-এর ইনসিডেন্ট-রেসপন্স উপাদান সমন্বয় এবং প্রশমন-প্রথম পদ্ধতির উপর জোর দেয়। প্রকল্পের সাথে মানানসই স্কেলে তা প্রয়োগ করুন: প্রভাব প্রতিষ্ঠা করুন, নিরাপদ পদক্ষেপ বেছে নিন এবং একাধিক অপারেটর যাতে পরস্পরবিরোধী পরিবর্তন না করে তা এড়ান। একটি টাইমলাইন এবং সিদ্ধান্ত রেকর্ড করুন। নিখুঁত ব্যাখ্যার সন্ধান প্রভাবিত ফাংশন পুনরুদ্ধারকারী একটি নিরাপদ পদক্ষেপ বিলম্বিত করা উচিত নয়।
একটি নির্দিষ্ট অবনতির মধ্য দিয়ে যান
কল্পনা করুন একটি রিলিজের পরে একটি সাইট ধীর হয়ে যাচ্ছে। একটি বাহ্যিক চেক বর্ধিত সম্পন্ন হওয়ার সময় দেখায়, অথচ অভ্যন্তরীণ পরিমাপ অ্যাপ্লিকেশন ত্রুটি এবং বাড়তে থাকা ডেটাবেস কাজ দেখায়। সমন্বয়কারী একটি সীমাবদ্ধ ইনসিডেন্ট ঘোষণা করেন, প্রমাণ সুরক্ষিত করেন এবং একজনকে রিলিজের সাথে বেসলাইন তুলনা করার দায়িত্ব দেন। আরেকজন অসম্পর্কিত অবকাঠামো পরিবর্তন করার বদলে পরীক্ষিত রোলব্যাক পথ প্রস্তুত করেন।
অ্যাপ্লিকেশনের ডেটা অবস্থার জন্য রোলব্যাক নিরাপদ হলে তা ব্যবহার করুন এবং ফলাফল পর্যবেক্ষণ করুন। নিরাপদ না হলে অপারেটিং প্ল্যান দ্বারা সমর্থিত একটি সংকীর্ণ প্রশমন বেছে নিন। কী পরিবর্তিত হয়েছে এবং কখন তা নথিভুক্ত করুন। একটি বড় VPS বা পোর্ট পরে মূল্যায়ন করা মূল্যবান হতে পারে, তবে তাৎক্ষণিক সিদ্ধান্ত অবকাঠামোর আকারই কারণ ধরে না নিয়ে প্রমাণ মোকাবিলা করা উচিত।
প্রমাণ সুরক্ষিত করুন এবং পুনরুদ্ধার যাচাই করুন
পরিচালনগত লগ এবং ইনসিডেন্ট নোটে ঠিকানা, শনাক্তকারী এবং গ্রাহক তথ্য থাকতে পারে। তদন্তের যা প্রয়োজন তা সংগ্রহ করুন, অ্যাক্সেস সীমাবদ্ধ করুন এবং শেয়ার করা রিপোর্টে ক্রেডেনশিয়াল বা ব্যক্তিগত অর্ডার টোকেন রাখা এড়িয়ে চলুন। সন্দেহজনক নিরাপত্তা ইনসিডেন্টের জন্য উপযুক্ত প্রমাণ সংরক্ষণ করুন এবং তাড়াহুড়ো করে পরিষ্কার করার মাধ্যমে তথ্য ধ্বংস না করে প্রকল্পের প্রতিক্রিয়া নীতি অনুসরণ করুন।
NIST-এর ইনসিডেন্ট-রেসপন্স নির্দেশনা প্রতিক্রিয়াকে বিস্তৃত সাইবারসিকিউরিটি ঝুঁকি ব্যবস্থাপনার মধ্যে রাখে। পুনরুদ্ধারে অভিপ্রেত ফাংশন পরীক্ষা করা এবং ইনসিডেন্ট সম্ভব করা অবস্থার সমাধান করা অন্তর্ভুক্ত। প্রতিক্রিয়া বন্ধ করার আগে ব্যবহারকারী যাত্রা পরীক্ষা করুন, রিসোর্স আচরণ পর্যালোচনা করুন এবং ব্যাকগ্রাউন্ড কাজ দেখুন। কেবল একটি সরে যাওয়া অ্যালার্ট বা পুনরারম্ভ করা প্রক্রিয়া উপকারী সেবায় সম্পূর্ণ প্রত্যাবর্তন প্রমাণ করতে পারে না।
ইনসিডেন্টকে একটি পরিমাপযোগ্য উন্নতিতে রূপান্তর করুন
প্রভাব, টাইমলাইন, অবদানকারী অবস্থা এবং গৃহীত পদক্ষেপের একটি সংক্ষিপ্ত পর্যালোচনা লিখুন। যাচাইযোগ্য পরিবর্তনের উপর মনোযোগ দিন: একটি চেক উন্নত করুন, একটি অনুমতি সংশোধন করুন, রোলব্যাক অনুশীলন করুন বা একটি অনুপস্থিত পুনরুদ্ধার নির্ভরতা যোগ করুন। মালিক এবং সমাপ্তির মানদণ্ড নির্ধারণ করুন। অস্পষ্ট অভিপ্রায়ের একটি দীর্ঘ তালিকা এড়িয়ে চলুন যা পরে কেউ বাস্তবায়িত হয়েছে বলে নিশ্চিত করতে পারে না।
SwissOctet-এ ডিপ্লয় করার সময়, নির্বাচিত হার্ডওয়্যার এবং কোনো নিশ্চিত ব্যবস্থাপনা ব্যবস্থা থেকে আলাদা, অ্যাপ্লিকেশনের পরিচালনার অংশ হিসেবে মনিটরিং এবং প্রতিক্রিয়া পরিকল্পনা করুন। ক্যাটালগ একটি কর্মী-সমৃদ্ধ ইনসিডেন্ট টিম বা অবিরাম সাপোর্ট আওয়ার প্রতিষ্ঠা করে না। প্রোডাকশন পরিবেশের উপর নির্ভর করার আগে কে অ্যালার্ট পায়, কে পদক্ষেপ নিতে পারে এবং প্রকৃত সেবা শর্তগুলি কী কভার করে তা নির্ধারণ করুন।
আপনার ব্যবহারিক চেকলিস্ট।
- একটি নিরীহ প্রতিনিধিত্বমূলক ব্যবহারকারী যাত্রা মনিটর করুন।
- অ্যাপ্লিকেশন আচরণ ব্যাখ্যা করে এমন সংকেত বেছে নিন।
- অ্যালার্টকে একটি পদক্ষেপ, মালিক এবং পুনরুদ্ধার শর্ত দিন।
- ইনসিডেন্টের আগে সমন্বয় এবং এস্কেলেশনে সম্মত হন।
- প্রমাণ সুরক্ষিত করুন এবং সম্পূর্ণ পুনরুদ্ধার যাচাই করুন।
- পর্যালোচনার পরে পরীক্ষাযোগ্য উন্নতি নির্ধারণ করুন।
যে বিবরণগুলো গুরুত্বপূর্ণ।
সার্ভার আপটাইম মনিটরিং কি যথেষ্ট?+
না। একটি পৌঁছানোযোগ্য মেশিন একটি ভাঙা অ্যাপ্লিকেশন হোস্ট করতে পারে। ব্যবহারকারীরা যে ফাংশনের উপর নির্ভর করে তা মনিটর করুন এবং ব্যর্থতা নির্ণয়ের জন্য রিসোর্স প্রমাণ যোগ করুন।
প্রতিটি মেট্রিক থ্রেশহোল্ড কি কাউকে অবিলম্বে পেজ করবে?+
না। সময়োপযোগী মনোযোগ প্রয়োজন এমন কার্যকর অবস্থার জন্য জরুরি হস্তক্ষেপ সংরক্ষণ করুন। কম-অগ্রাধিকার কাজ একটি স্পষ্ট মালিকসহ পর্যালোচনা প্রক্রিয়ায় পাঠান।
একটি ইনসিডেন্ট কখন শেষ হয়?+
প্রভাবিত ফাংশন এবং প্রাসঙ্গিক ব্যাকগ্রাউন্ড কাজ যাচাই করার পরে, তাৎক্ষণিক ঝুঁকি মোকাবিলা করার পরে এবং ফলো-আপ পদক্ষেপ রেকর্ড করার পরে। কেবল একটি প্রক্রিয়া পুনরারম্ভ যথেষ্ট নয়।
সূত্রে যান।
এই রেফারেন্সগুলি এই গাইডের প্রযুক্তিগত ধারণাগুলি সমর্থন করে। একটি উৎপাদন সিস্টেম পরিবর্তন করার আগে বর্তমান ডকুমেন্টেশন অনুসরণ করুন।
- Google SRE: বিতরণকৃত সিস্টেম মনিটরিং sre.google
- Google SRE Workbook: ইনসিডেন্ট রেসপন্স sre.google
- NIST SP 800-61 Rev. 3: ইনসিডেন্ট রেসপন্স csrc.nist.gov
SwissOctet দ্বারা সম্পাদকীয় নির্দেশনা। উদাহরণগুলি উদাহরণমূলক। সেবা স্পেসিফিকেশন, উপলব্ধ অপশন এবং চুক্তিভিত্তিক শর্তগুলি আলাদাভাবে যাচাই করতে হবে।