আপনার পরিকাঠামো কি ভবিষ্যতের জন্য প্রস্তুত? এই 3 স্পেস চেক করুন

একটি সিস্টেম আজ ভালভাবে কাজ করতে পারে এবং এখনও যখন ট্রাফিক বৃদ্ধি পায়, একটি পরিষেবা ব্যর্থ হয়, বা দলকে দ্রুত গতিতে পরিবর্তনগুলি প্রকাশ করতে হয় তখনও সংগ্রাম করতে পারে। আমি দেখেছি অবকাঠামো পর্যালোচনাগুলি সার্ভারের আকারের উপর ফোকাস করে যখন সবচেয়ে বড় ঝুঁকি তৈরি করে এমন ক্ষেত্রগুলি মিস করে: সীমিত ক্ষমতা, দুর্বল পুনরুদ্ধারের পরিকল্পনা এবং সিস্টেম আচরণে দুর্বল দৃশ্যমানতা। একটি ভবিষ্যত-প্রস্তুত সেটআপ প্রতিটি নতুন প্রযুক্তি ব্যবহার করার প্রয়োজন নেই। এটা কম ব্যাঘাত সঙ্গে পরিবর্তন পরিচালনা করা প্রয়োজন. এই তিনটি স্পেসিফিকেশন আমাকে একটি ব্যবহারিক সূচনা পয়েন্ট দেয়। 1। সম্পূর্ণ পুনর্নির্মাণ ছাড়াই বাড়তে পারে এমন ক্ষমতা চাহিদা বাড়লে পরিকাঠামো কীভাবে সাড়া দেয় তা আমি পরীক্ষা করি। একটি দরকারী পর্যালোচনার মধ্যে রয়েছে: - CPU এবং মেমরি হেডরুম - স্টোরেজ বৃদ্ধি এবং ব্যাকআপ ক্ষমতা - নেটওয়ার্ক ব্যান্ডউইথ - ডেটাবেস সংযোগের সীমা - অটো-স্কেলিং নিয়ম - লোড ব্যালেন্সার ক্ষমতা - উচ্চ ব্যবহারের স্তরে খরচ পরিবর্তন একটি সিস্টেম যা স্বাভাবিক ব্যবসায়িক সময়ে 85% CPU তে চলে ট্রাফিক স্পাইকের জন্য সামান্য জায়গা ছেড়ে দিতে পারে। একটি আকস্মিক প্রচারাভিযান, পণ্য লঞ্চ, বা মৌসুমী চাহিদা পরিষেবাটিকে ধীর প্রতিক্রিয়া বা ব্যর্থ অনুরোধে ঠেলে দিতে পারে। আমি স্কেলিং মডেল তাকান. উল্লম্ব স্কেলিং মানে একটি মেশিনে আরও শক্তি যোগ করা। অনুভূমিক স্কেলিং মানে আরও মেশিন বা পরিষেবা দৃষ্টান্ত যোগ করা। অনুভূমিক স্কেলিং আরও নমনীয়ভাবে বৃদ্ধিকে সমর্থন করতে পারে, তবে শুধুমাত্র যখন অ্যাপ্লিকেশন, ডাটাবেস, সেশন পরিচালনা এবং স্থাপনা প্রক্রিয়া এটিকে সমর্থন করে। একটি সাধারণ ক্ষমতা পরীক্ষা ফাঁকগুলি প্রকাশ করতে পারে: 1. স্বাভাবিক ট্র্যাফিক এবং সর্বোচ্চ ট্র্যাফিক রেকর্ড করুন। 2. ছোট ধাপে পরীক্ষার লোড বাড়ান। 3. ট্র্যাক প্রতিক্রিয়া সময়, ত্রুটি হার, CPU, মেমরি, এবং ডাটাবেস ব্যবহার. 4. নতুন দৃষ্টান্ত প্রত্যাশিত হিসাবে শুরু হয় কিনা তা পরীক্ষা করুন৷ 5. প্রতিটি লোড স্তরে খরচ পর্যালোচনা করুন। 6. ম্যানুয়াল পর্যালোচনার জন্য একটি পরিষ্কার পয়েন্ট সেট করুন। উদাহরণস্বরূপ, একটি অনলাইন স্টোর একটি সাধারণ সময়কালে প্রতি মিনিটে 500টি এবং প্রচারের সময় 2,000টি অনুরোধ পরিচালনা করতে পারে৷ যদি সিস্টেমটি প্রতি মিনিটে 600টি অনুরোধে পরীক্ষা করা হয় তবে দলটি সীমিত প্রমাণের সাথে সিদ্ধান্ত নিচ্ছে। একটি নিয়ন্ত্রিত লোড পরীক্ষা দেখাতে পারে যে সমস্যাটি অ্যাপ্লিকেশন সার্ভার, ডাটাবেস কোয়েরি, নেটওয়ার্ক সীমা বা একটি বহিরাগত পরিষেবা থেকে এসেছে কিনা। ক্ষমতা পরিকল্পনা এছাড়াও তথ্য অন্তর্ভুক্ত করা উচিত. সঞ্চয়স্থান প্রায়শই নিঃশব্দে বৃদ্ধি পায় যতক্ষণ না ব্যাকআপ উইন্ডোগুলি খুব দীর্ঘ হয়ে যায় বা ডাটাবেসের কার্যকারিতা কমতে শুরু করে। আমি মাসিক বৃদ্ধি ট্র্যাক করতে এবং পরবর্তী 12 থেকে 24 মাস অনুমান করতে পছন্দ করি। অনুমান সঠিক হবে না, তবে এটি দলকে পরিকল্পনা করার সময় দেয়। 2। ব্যবসার সাথে মেলে পুনরুদ্ধারের লক্ষ্য একটি ব্যাকআপ একটি পুনরুদ্ধার পরিকল্পনার সমান নয়। আমি দুটি স্পেসিফিকেশন পরীক্ষা করি: - রিকভারি টাইম অবজেক্টিভ (RTO): কতক্ষণ পরিষেবাটি অনুপলব্ধ থাকতে পারে - রিকভারি পয়েন্ট অবজেক্টিভ (RPO): ব্যবসা কতটা সাম্প্রতিক ডেটা হারাতে পারে তা একটি ছোট অভ্যন্তরীণ টুল কয়েক ঘণ্টার RTO গ্রহণ করতে পারে৷ একটি অর্থপ্রদান বা অর্ডার সিস্টেম একটি ছোট পুনরুদ্ধার উইন্ডো প্রয়োজন হতে পারে. সঠিক লক্ষ্য ব্যবসায়িক প্রভাব, গ্রাহকের চাহিদা, অপারেশনাল খরচ এবং প্রযুক্তিগত সীমার উপর নির্ভর করে। পুনরুদ্ধার পরিকল্পনাটি ব্যবহারিক প্রশ্নের উত্তর দিতে হবে: - ব্যাকআপগুলি কোথায় সংরক্ষণ করা হয়? - কত ঘন ঘন ব্যাকআপ তৈরি করা হয়? - ব্যাকআপ কি মূল পরিবেশ থেকে আলাদা? - কে সিস্টেম পুনরুদ্ধার করতে পারেন? - পুনরুদ্ধার কতক্ষণ লাগে? - পুনরুদ্ধারের পরে কীভাবে ডেটা পরিবর্তনগুলি পরীক্ষা করা হয়? - প্রাথমিক অঞ্চল বা ডেটা সেন্টার অনুপলব্ধ হলে কি হবে? - শেষ পুনরুদ্ধারের পরীক্ষা কখন হয়েছিল? একটি দল প্রতিদিনের ব্যাকআপের রিপোর্ট করতে পারে, তবে সাম্প্রতিক ব্যাকআপ পুনরুদ্ধার করা না গেলে ব্যবসাটি এখনও লেনদেনের একটি দিন হারাতে পারে। আমি পুনরুদ্ধার পরীক্ষাকে নির্দিষ্টকরণের অংশ হিসাবে বিবেচনা করি, একটি ঐচ্ছিক অনুশীলন হিসাবে নয়। একটি দরকারী পুনরুদ্ধার পরীক্ষা এই প্যাটার্ন অনুসরণ করতে পারে: 1. একটি কম ঝুঁকিপূর্ণ পরীক্ষার পরিবেশ নির্বাচন করুন। 2. একটি সাম্প্রতিক ব্যাকআপ পুনরুদ্ধার করুন৷ 3. প্রয়োজনীয় সময় পরিমাপ করুন। 4. অ্যাপ্লিকেশন ফাংশন এবং ডেটা সামঞ্জস্য পরীক্ষা করুন। 5. রেকর্ড ব্যর্থতা এবং অস্পষ্ট পদক্ষেপ. 6. রানবুক আপডেট করুন। 7. পরিকল্পিত বিরতিতে পরীক্ষাটি পুনরাবৃত্তি করুন। পাবলিক ক্লাউড বিভ্রাট দেখিয়েছে কেন একটি একক অবস্থান অপারেশনাল ঝুঁকি তৈরি করতে পারে। একটি মাল্টি-রিজিওন ডিজাইন সেই ঝুঁকি কমাতে পারে, তবে এটি উচ্চ খরচ এবং আরও জটিল ডেটা হ্যান্ডলিং নিয়ে আসে। পছন্দটি আরও অঞ্চলের জন্য সাধারণ পছন্দের পরিবর্তে পরিষেবার প্রয়োজনীয়তাকে প্রতিফলিত করা উচিত। আমিও জিজ্ঞাসা করি যে মূল সিস্টেমটি তৈরি করা ব্যক্তিকে ছাড়া দলটি পুনরুদ্ধার করতে পারে কিনা। উত্তর না হলে, ডকুমেন্টেশন কাজ প্রয়োজন. 3. নিরীক্ষণ যা ব্যবহারকারীদের কী অভিজ্ঞতা দেয় তা ব্যাখ্যা করে গ্রাহকদের ধীরগতির পৃষ্ঠা বা ব্যর্থ লেনদেনের মুখোমুখি হওয়ার সময় পরিকাঠামো সুস্থ দেখাতে পারে। CPU এবং মেমরি মেট্রিক্স দরকারী, কিন্তু তারা সম্পূর্ণ গল্প বলতে না. আমি দেখতে চাই: - p95 বা p99 মান সহ অনুরোধের বিলম্বিতা - ত্রুটির হার - উপলব্ধতা - সারির গভীরতা - ডেটাবেস ক্যোয়ারী সময় - ক্যাশে কর্মক্ষমতা - ব্যর্থ স্থাপনা - স্যাচুরেটেড সংযোগ - ব্যবহারকারীর লেনদেনের সাফল্যের হার গড় সমস্যাগুলি লুকাতে পারে৷ যদি বেশিরভাগ অনুরোধ 100 মিলিসেকেন্ড সময় নেয় এবং একটি ছোট গ্রুপ 8 সেকেন্ড সময় নেয়, তাহলে গড় এখনও গ্রহণযোগ্য মনে হতে পারে। পারসেন্টাইল ডেটা ধীরগতির অনুরোধগুলির একটি ভাল দৃশ্য দেয়। লগগুলি দলকে তিনটি প্রশ্নের উত্তর দিতে সাহায্য করবে: 1. কী ঘটেছে? 2. কোন সেবা এটি ঘটিয়েছে? 3. কোন ব্যবহারকারী বা লেনদেন প্রভাবিত হয়েছিল? একটি অনুরোধ আইডি যা পরিষেবা জুড়ে একটি লেনদেন অনুসরণ করে তদন্তের সময় কমাতে পারে। সতর্কতা একটি সম্ভাব্য কর্ম নির্দেশ করা উচিত. "CPU উচ্চ" বলে একটি সতর্কতা সীমিত নির্দেশনা দেয়৷ একটি সতর্কতা যা ক্রমবর্ধমান চেকআউট ত্রুটি এবং সাম্প্রতিক স্থাপনার সাথে উচ্চ CPU-কে লিঙ্ক করে দলটিকে আরও দরকারী প্রসঙ্গ দেয়৷ আমি ঘটনার পরে সতর্কতার গুণমান পর্যালোচনা করার পরামর্শ দিই। যদি দলটি অনেক সতর্কতা পায় কিন্তু গ্রাহকের প্রভাব মিস করে, তাহলে পর্যবেক্ষণ সেটআপের সামঞ্জস্য প্রয়োজন। যদি একটি পরিচিত ব্যর্থতার সময় কোন সতর্কতা উপস্থিত না হয়, তবে ফাঁকটি নথিভুক্ত এবং পরীক্ষা করা উচিত। নিরাপত্তাও এই পর্যালোচনার অন্তর্গত। আমি অ্যাক্সেসের অনুমতি, গোপন স্টোরেজ, প্যাচ রুটিন, নেটওয়ার্ক নিয়ন্ত্রণ এবং অডিট লগগুলি পরীক্ষা করি। এই চেকগুলি একটি সম্পূর্ণ নিরাপত্তা মূল্যায়ন প্রতিস্থাপন করে না, তবে তারা দৈনন্দিন ক্রিয়াকলাপের মৌলিক দুর্বলতাগুলিকে প্রকাশ করতে পারে। একটি ব্যবহারিক পর্যালোচনা 1 থেকে 5 পর্যন্ত প্রতিটি স্পেসিফিকেশন স্কোর করতে পারে: - 1: কোন স্পষ্ট পরিকল্পনা বা নির্ভরযোগ্য পরিমাপ নেই - 2: কিছু সরঞ্জাম বিদ্যমান, তবে পরীক্ষা সীমিত - 3: প্রক্রিয়াটি স্বাভাবিক অবস্থায় কাজ করে - 4: প্রক্রিয়াটি চাপের মধ্যে পরীক্ষা করা হয়েছে - 5: প্রক্রিয়াটি পরীক্ষা করা হয়েছে, নথিভুক্ত করা হয়েছে, এবং সিস্টেমের চেয়ে কম প্রমাণ হিসেবে পর্যালোচনা করা হয়েছে। একটি দল ক্ষমতা পরীক্ষার ফলাফল দেখাতে, রেকর্ড পুনরুদ্ধার করতে, ড্যাশবোর্ডগুলি পর্যবেক্ষণ করতে এবং আপডেট করা রানবুকগুলি দেখাতে সক্ষম হওয়া উচিত। যখন আমি পরিকাঠামো মূল্যায়ন করি, তখন আমি জিজ্ঞাসা করি না যে এটি নতুন প্ল্যাটফর্ম ব্যবহার করে কিনা। আমি জিজ্ঞাসা করি যে এটি প্রত্যাশিত বৃদ্ধিকে সমর্থন করতে পারে, একটি সম্মত উইন্ডোর মধ্যে পুনরুদ্ধার করতে পারে এবং ব্যবহারকারীরা কী অনুভব করছে তা দলকে দেখাতে পারে। উত্তরটি অস্পষ্ট হলে, পরবর্তী ধাপটি সম্পূর্ণ পুনর্নির্মাণ নয়। পরিমাপ দিয়ে শুরু করুন, দুর্বল এলাকাগুলি পরীক্ষা করুন এবং সবচেয়ে বড় ব্যবসার ঝুঁকি বহন করে এমন অংশটি উন্নত করুন।

অনেক অবকাঠামো দল একটি পণ্য লঞ্চ, একটি ট্রাফিক স্পাইক, বা একটি নিরাপত্তা ইভেন্টের সময় তাদের সিস্টেমের সীমা আবিষ্কার করে। সমস্যাটি খুব কমই একটি একক সার্ভার। এটি প্রায়শই ধীর স্কেলিং, দুর্বল পুনরুদ্ধারের পরিকল্পনা এবং সিস্টেমের স্বাস্থ্যের মধ্যে সীমিত দৃশ্যমানতার মিশ্রণ। আমি তিনটি ব্যবহারিক বৈশিষ্ট্য দ্বারা পরিকাঠামোকে বিচার করি: এটি কতটা ভালভাবে স্কেল করে, কত দ্রুত এটি পুনরুদ্ধার করে এবং দলটি কী ঘটছে তা কতটা স্পষ্টভাবে দেখতে পারে। এই ব্যবস্থাগুলি আমাকে এমন একটি সিস্টেমকে আলাদা করতে সাহায্য করে যা শুধুমাত্র আজকে কাজ করে এমন একটি সিস্টেম থেকে যা পরিবর্তনশীল ব্যবসায়িক চাহিদাগুলিকে সমর্থন করতে পারে। 1। স্থিতিস্থাপক ক্ষমতা যা চাহিদার সাথে মেলে একটি ভবিষ্যত-প্রস্তুত পরিকাঠামো চাহিদার পরিবর্তনের সাথে সাথে সংস্থান যোগ করতে বা ছেড়ে দিতে পারে। এতে কম্পিউট ইনস্ট্যান্স, কন্টেইনার, ডাটাবেসের ক্ষমতা, স্টোরেজ বা নেটওয়ার্ক ব্যান্ডউইথ অন্তর্ভুক্ত থাকতে পারে। আমি একটি সাধারণ "ক্লাউড-ভিত্তিক" লেবেলের বাইরে তাকাই। দরকারী প্রশ্নগুলি আরও সুনির্দিষ্ট: - সিস্টেম কি ট্র্যাফিকের আকস্মিক বৃদ্ধি পরিচালনা করতে পারে? - স্কেলিং কতক্ষণ লাগে? - চাহিদা কমে গেলে তা কি কমতে পারে? - অ্যাপ্লিকেশন স্তর সঙ্গে ডাটাবেস স্কেল? - স্কেলিং নিয়ম কি দরকারী সংকেতের উপর ভিত্তি করে, যেমন প্রতি সেকেন্ডে অনুরোধ বা সারির দৈর্ঘ্য? একটি খুচরা কোম্পানি বছরের বেশিরভাগ সময় স্থির ট্রাফিক পেতে পারে, তারপর একটি মৌসুমী প্রচারণার সময় একটি তীক্ষ্ণ বৃদ্ধি দেখতে পারে। যদি ওয়েব সার্ভার স্কেল কিন্তু ডাটাবেস স্থির থাকে, ব্যবহারকারীরা এখনও ধীর পৃষ্ঠা বা ব্যর্থ আদেশ সম্মুখীন হতে পারে. আরো অ্যাপ্লিকেশন সার্ভার যোগ করা একটি ডাটাবেস বাধা সমাধান করবে না. আমি ধারণক্ষমতা পরীক্ষা পছন্দ করি যা স্বাভাবিক ব্যবসার ধরণ প্রতিফলিত করে। একটি দল নিয়মিত ট্র্যাফিক, সর্বোচ্চ ট্র্যাফিক এবং হঠাৎ ট্র্যাফিক জাম্প পরীক্ষা করতে পারে। পরীক্ষার প্রতিক্রিয়া সময়, ত্রুটির হার, সম্পদ ব্যবহার এবং খরচ ট্র্যাক করা উচিত। একটি দরকারী লক্ষ্য হতে পারে: - 95% অনুরোধগুলি স্বাভাবিক লোডের অধীনে 300 মিলিসেকেন্ডের মধ্যে সাড়া দেয় - পিক লোডের সময় ত্রুটির হার একটি সম্মত ব্যবসায়িক সীমার নিচে থাকে - নতুন অ্যাপ্লিকেশন ক্ষমতা একটি নির্দিষ্ট সময়ের মধ্যে উপলব্ধ হয় - ডেটাবেস সংযোগগুলি একটি নিরাপদ অপারেটিং সীমার মধ্যে থাকে সঠিক সংখ্যাগুলি পরিষেবার উপর নির্ভর করে৷ কি গুরুত্বপূর্ণ যে দল তাদের সংজ্ঞায়িত করে একটি সমস্যা হওয়ার আগে। 2। পুনরুদ্ধার যা পরীক্ষা করা হয়, শুধুমাত্র নথিভুক্ত নয় একটি ব্যাকআপ পরিকল্পনার মূল্য তখনই থাকে যখন দলটি পরিষেবা পুনরুদ্ধার করতে পারে। আমি দুটি পরিমাপ দেখি: - পুনরুদ্ধারের সময় উদ্দেশ্য: কতক্ষণ পরিষেবাটি অনুপলব্ধ থাকতে পারে - পুনরুদ্ধার পয়েন্ট উদ্দেশ্য: ব্যবসা কত সাম্প্রতিক ডেটা হারাতে পারে একটি পেমেন্ট প্ল্যাটফর্মের মিনিটে পরিমাপ করা একটি পুনরুদ্ধার পয়েন্টের প্রয়োজন হতে পারে৷ একটি অভ্যন্তরীণ রিপোর্টিং টুল একটি দীর্ঘ উইন্ডো গ্রহণ করতে পারে. সঠিক লক্ষ্য ব্যবসায়িক প্রভাব থেকে আসে, একটি টেমপ্লেট থেকে নয়। একটি ব্যবহারিক পুনরুদ্ধারের নকশার মধ্যে অন্তর্ভুক্ত থাকতে পারে: - স্বয়ংক্রিয় ব্যাকআপ - একটি পৃথক অবস্থানে সংরক্ষিত অনুলিপি - উপলব্ধ অঞ্চল বা অঞ্চল জুড়ে প্রতিলিপি ডেটা - নথিভুক্ত পুনরুদ্ধারের পদক্ষেপ - ব্যাকআপ সিস্টেমের জন্য অ্যাক্সেস নিয়ন্ত্রণ - নিয়মিত পুনরুদ্ধার পরীক্ষা একটি মাঝারি আকারের অনলাইন খুচরা বিক্রেতা একবার একটি পুনরুদ্ধারের অনুশীলনের সময় পাওয়া গিয়েছিল যে তার ব্যাকআপগুলি সম্পূর্ণরূপে বিশ্রামের প্রক্রিয়ার উপর নির্ভরশীল ছিল, তবে এটি সম্পূর্ণরূপে নির্ভর করে। ফাইল বিদ্যমান ছিল. পরিষেবা এখনও নির্ধারিত সময়ে ফিরতে পারেনি। অনুশীলনের পরে, দলটি স্পষ্ট মালিকদের বরাদ্দ করে, ব্যাকআপ সিস্টেমের সাথে পুনরুদ্ধারের নির্দেশাবলী সংরক্ষণ করে এবং প্রতি ত্রৈমাসিকে পুনরুদ্ধারের পরীক্ষা করে। এই ধরনের পরীক্ষা ফাঁকগুলি প্রকাশ করে যা নথিগুলি প্রায়শই মিস করে। একটি ব্যর্থ পুনরুদ্ধার অস্বস্তিকর, তবুও এটি দলকে প্রক্রিয়াটি ঠিক করার জন্য একটি নিরাপদ জায়গা দেয়। আমি সার্ভারের চেয়ে পুনরুদ্ধার বেশি কভার করে কিনা তাও পরীক্ষা করি। অ্যাপ্লিকেশনগুলি ডিএনএস, পরিচয় পরিষেবা, শংসাপত্র, বার্তা সারি, তৃতীয় পক্ষের API এবং ডেটাবেস শংসাপত্রের উপর নির্ভর করতে পারে। একটি পুনরুদ্ধার পরিকল্পনা দেখানো উচিত কিভাবে এই অংশগুলি একসাথে কাজ করে। 3. পর্যবেক্ষণযোগ্যতা যা সংকেতকে কর্মের সাথে সংযুক্ত করে পরিকাঠামো প্রচুর পরিমাণে ডেটা তৈরি করে। দরকারী পর্যবেক্ষণযোগ্যতা লোকেদের সেই ডেটা বুঝতে এবং পরিষেবা সমস্যাগুলির প্রতিক্রিয়া জানাতে সহায়তা করে। আমি তিন ধরণের সংকেত আশা করি: - মেট্রিক্স: বিলম্ব, ট্র্যাফিক, ত্রুটির হার, CPU ব্যবহার, মেমরি ব্যবহার, সারির গভীরতা - লগ: অ্যাপ্লিকেশন ইভেন্ট, অ্যাক্সেস রেকর্ড, নিরাপত্তা সতর্কতা, সিস্টেম বার্তা - ট্রেস: পরিষেবা জুড়ে অনুরোধের পথ চার্টে পূর্ণ একটি ড্যাশবোর্ড স্বয়ংক্রিয়ভাবে ক্রিয়াকলাপ উন্নত করে না। দলের স্পষ্ট পরিষেবা সূচক এবং দরকারী সতর্কতা প্রয়োজন। উদাহরণস্বরূপ, উচ্চ CPU ব্যবহার সম্পর্কে একটি সতর্কতা অবিলম্বে পদক্ষেপের প্রয়োজন নাও হতে পারে যদি প্রতিক্রিয়া সময় স্থিতিশীল থাকে। সার্ভার ক্ষমতা স্বাভাবিক দেখালেও ব্যর্থ অর্থপ্রদানের বৃদ্ধি মনোযোগের দাবি রাখে। আমি যখনই সম্ভব গ্রাহকের প্রভাবের সাথে সতর্কতা সংযুক্ত করি। একটি শক্তিশালী মনিটরিং সেটআপ প্রশ্নের উত্তর দেয় যেমন: - কোন পরিষেবা প্রভাবিত হয়? - সমস্যা কবে থেকে শুরু হলো? - কোন ব্যবহারকারী বা অঞ্চল সমস্যাটি দেখছেন? - সমস্যা উপস্থিত হওয়ার আগে কি পরিবর্তন হয়েছে? - পরবর্তী কর্মের মালিক কে? - সমস্যা বাড়ছে নাকি পুনরুদ্ধার হচ্ছে? একটি সফ্টওয়্যার কোম্পানী একটি অনুরোধ ট্রেস ব্যবহার করতে পারে যে একটি ধীর চেকআউট পৃষ্ঠা ওয়েব সার্ভার দ্বারা সৃষ্ট নয়। বিলম্ব একটি পণ্য সুপারিশ পরিষেবা বা একটি বহিরাগত অর্থ প্রদান প্রদানকারী থেকে আসতে পারে. এই স্তরের বিশদ অনুমানকে হ্রাস করে এবং দলকে সঠিক উপাদানের উপর ফোকাস করতে সহায়তা করে। পর্যবেক্ষণযোগ্যতা খরচ এবং নিরাপত্তা সংকেত অন্তর্ভুক্ত করা উচিত. অপ্রত্যাশিত সঞ্চয়স্থান বৃদ্ধি, অস্বাভাবিক লগইন কার্যকলাপ, এবং ডেটা স্থানান্তরের একটি তীক্ষ্ণ বৃদ্ধি অপারেশনাল বা নিরাপত্তা উদ্বেগ নির্দেশ করতে পারে। আমি একটি ব্যবহারিক পর্যালোচনা চেকলিস্ট হিসাবে এই তিনটি চশমা ব্যবহার করি: 1. স্বাভাবিকের অধীনে পরীক্ষা ক্ষমতা, সর্বোচ্চ এবং আকস্মিক চাহিদা। 2. প্রতিটি পরিষেবার জন্য পুনরুদ্ধারের সময় এবং ডেটা হারানোর সীমা নির্ধারণ করুন। 3. পুনরুদ্ধার অনুশীলন চালান এবং ফলাফল রেকর্ড করুন। 4. ব্যবহারকারী-মুখী পরিষেবা সূচকগুলি ট্র্যাক করুন। 5. মালিকদের এবং প্রতিক্রিয়া পদক্ষেপগুলি লিঙ্ক সতর্কতা. 6. পরিকাঠামো খরচ, অ্যাক্সেস, এবং নির্ভরতা পরিবর্তন পর্যালোচনা করুন। ভবিষ্যতের বৃদ্ধিকে সমর্থন করার জন্য একটি সিস্টেমের প্রতিটি নতুন হাতিয়ারের প্রয়োজন হয় না। এটি প্রত্যাশিত চাহিদার জন্য যথেষ্ট ক্ষমতার প্রয়োজন, একটি পুনরুদ্ধার প্রক্রিয়া যা লোকেরা সম্পাদন করতে পারে এবং পরিস্থিতি পরিবর্তিত হলে তথ্য পরিষ্কার করতে হবে। যখন আমি পরিকাঠামো পর্যালোচনা করি, তখন আমি একটি সরাসরি প্রশ্ন করি: দল কি ব্যাখ্যা করতে পারে যখন চাহিদা বেড়ে যায়, নির্ভরতা ব্যর্থ হয় বা ডেটা পুনরুদ্ধার করতে হবে তখন কী ঘটবে? উত্তর যদি অনুমানের উপর নির্ভর করে, তাহলে পরবর্তী বড় ব্যবসায়িক পরিবর্তনের আগে সিস্টেমের আরও প্রস্তুতির প্রয়োজন হতে পারে।

অনেক অবকাঠামো পরিকল্পনা কাগজে স্বাস্থ্যকর দেখায় এবং এক বছর পরেও সমস্যা তৈরি করে। সঞ্চয়স্থান প্রত্যাশার চেয়ে দ্রুত পূর্ণ হয়। একটি নতুন অ্যাপ্লিকেশন একটি ভিন্ন ইন্টারফেস প্রয়োজন. নিরাপত্তা সরঞ্জামগুলি পুরানো সিস্টেমে অতিরিক্ত লোড যোগ করে। দলগুলি তখন ব্যবসার উন্নতির চেয়ে সীমা নির্ধারণে বেশি সময় ব্যয় করে। একটি সার্ভার, ক্লাউড এনভায়রনমেন্ট, নেটওয়ার্ক আপগ্রেড, বা স্টোরেজ প্ল্যাটফর্ম অনুমোদন করার আগে আমি তিনটি স্পেসিফিকেশন পর্যালোচনা করি: - ক্ষমতা এবং কর্মক্ষমতা - সামঞ্জস্য এবং একীকরণ - নিরাপত্তা এবং অপারেশনাল নিয়ন্ত্রণ এই ক্ষেত্রগুলি আমাকে বিচার করতে সাহায্য করে যে কোনও পরিকাঠামোগত সিদ্ধান্ত ব্যবসায় ব্যবহার করবে না এমন বৈশিষ্ট্যগুলির জন্য অর্থ প্রদান না করে ভবিষ্যতের প্রয়োজনগুলিকে সমর্থন করতে পারে কিনা। ## 1. ক্যাপাসিটি এবং পারফরম্যান্স আমি স্বাভাবিক ব্যবহারে এবং চাপের মধ্যে সিস্টেমটি কীভাবে পারফর্ম করে তা পরীক্ষা করে শুরু করি। একটি স্পেসিফিকেশন শীট প্রসেসরের গতি, মেমরি, স্টোরেজ সাইজ, নেটওয়ার্ক ব্যান্ডউইথ বা ক্লাউড ইনস্ট্যান্স সীমা তালিকাভুক্ত করতে পারে। এই সংখ্যাগুলি গুরুত্বপূর্ণ, তবে তারা পুরো গল্পটি বলে না। আমি আরও দেখি: - বর্তমান ব্যবহারের মাত্রা - সর্বোচ্চ চাহিদা - প্রত্যাশিত ব্যবহারকারী বৃদ্ধি - ডেটা বৃদ্ধি - ব্যাকআপ প্রয়োজনীয়তা - কাজের চাপ পরিবর্তন - রক্ষণাবেক্ষণ বা ব্যর্থতার সময় কর্মক্ষমতা 80 জন কর্মচারী সহ একটি কোম্পানি তার বর্তমান ফাইল সার্ভারে ভালভাবে চলতে পারে৷ এর অর্থ এই নয় যে একই সার্ভার একটি নতুন গ্রাহক পোর্টাল, বৃহত্তর ডিজাইন ফাইল এবং প্রতিদিনের বিশ্লেষণের কাজগুলিকে সমর্থন করবে৷ আমি তিনটি পরিসংখ্যান রেকর্ড করতে পছন্দ করি: 1. বর্তমান গড় ব্যবহার 2. ব্যস্ত সময়ের মধ্যে সর্বোচ্চ ব্যবহার 3. পরবর্তী পরিকল্পনা চক্রে প্রত্যাশিত ব্যবহার উদাহরণস্বরূপ, একটি ছোট অনলাইন খুচরা বিক্রেতা একটি সাধারণ দিনে তার ডাটাবেস ক্ষমতার 55% ব্যবহার করতে পারে এবং মাসিক প্রচারের সময় 85% এ পৌঁছাতে পারে৷ যদি একটি নতুন বিক্রয় চ্যানেল যোগ করা হয়, তবে সিস্টেমটি দলের প্রত্যাশার চেয়ে তাড়াতাড়ি তার সীমাতে পৌঁছাতে পারে। শুধুমাত্র গড় পরিসংখ্যান পর্যালোচনা করলে চাপের বিন্দু লুকিয়ে থাকবে। আমি প্ল্যাটফর্ম স্কেল কিভাবে পরীক্ষা. আমি কি মেমরি যোগ করতে পারি? স্টোরেজ একটি দীর্ঘ আউটেজ ছাড়া প্রসারিত করা যাবে? ক্লাউড পরিষেবা কি একটি পরিষ্কার প্রক্রিয়ার মাধ্যমে গণনার ক্ষমতা বাড়াতে পারে? নেটওয়ার্ক কি আরও ডিভাইস এবং উচ্চ ট্রাফিক সমর্থন করে? খরচ দৃশ্যমান রাখার সময় একটি দরকারী নকশা বৃদ্ধির জন্য জায়গা ছেড়ে দেয়। ব্যবসা ব্যবহার করতে পারে তার চেয়ে অনেক বেশি ক্ষমতা কেনা উচ্চ লাইসেন্সিং, শক্তি, সহায়তা এবং ব্যবস্থাপনা খরচের মাধ্যমে নিজের সমস্যা তৈরি করতে পারে। ## 2. সামঞ্জস্য এবং একীকরণ পরিকাঠামো খুব কমই একা কাজ করে। এটি অ্যাপ্লিকেশন, আইডেন্টিটি সিস্টেম, মনিটরিং টুল, ব্যাকআপ প্ল্যাটফর্ম, পেমেন্ট পরিষেবা এবং কর্মচারী ডিভাইসগুলির সাথে সংযোগ করে। আমি অতিরিক্ত বৈশিষ্ট্য দেখার আগে সামঞ্জস্য পর্যালোচনা. একটি পণ্যের শক্তিশালী স্পেসিফিকেশন থাকতে পারে এবং এটি ইতিমধ্যেই থাকা সিস্টেমগুলির সাথে সংযোগ করতে না পারলেও বিলম্ব তৈরি করতে পারে। আমার চেকলিস্টের মধ্যে রয়েছে: - অপারেটিং সিস্টেম সমর্থন - অ্যাপ্লিকেশন প্রয়োজনীয়তা - API এবং প্রোটোকল সমর্থন - পরিচয় এবং অ্যাক্সেস বিকল্পগুলি - নেটওয়ার্ক মান - ব্যাকআপ সামঞ্জস্য - পর্যবেক্ষণ এবং সতর্কতা সমর্থন - ডেটা রপ্তানির বিকল্পগুলি - বিক্রেতা সমর্থন সময়কাল ডেটা রপ্তানি গভীর মনোযোগের দাবি রাখে৷ যদি কোনও পরিষেবা ব্যবসার ডেটা পুনরুদ্ধার করা কঠিন করে তোলে, তবে কোম্পানিটি মাইগ্রেশন বা চুক্তি পরিবর্তনের সময় সমস্যার সম্মুখীন হতে পারে। আমি জিজ্ঞাসা করি যে ডেটা কোন ফর্ম্যাট ব্যবহার করে, রপ্তানি কতক্ষণ লাগে এবং এক্সপোর্টে সেটিংস, লগ এবং অ্যাক্সেস রেকর্ড অন্তর্ভুক্ত রয়েছে কিনা। একটি বাস্তবসম্মত উদাহরণ হল একটি কোম্পানি স্থানীয় ফাইল স্টোরেজ থেকে ক্লাউড স্টোরেজে চলে যাচ্ছে। স্টোরেজ পরিষেবা অফিস নথিগুলির জন্য ভাল কাজ করতে পারে, তবে ডিজাইন টিম বড় ফাইল, বিশেষ অনুমতি বা সফ্টওয়্যারের উপর নির্ভর করতে পারে যা স্থানীয় নেটওয়ার্ক পাথের প্রত্যাশা করে। যদি এই বিবরণগুলি মিস করা হয়, কর্মচারীদের ধীর অ্যাক্সেস বা ভাঙা কর্মপ্রবাহ অনুভব করতে পারে। আমি একটি বৃহত্তর পরিবর্তন করার আগে একটি ছোট গ্রুপের সাথে সংযোগ পরীক্ষা করি। পরীক্ষায় একজন সাধারণ ব্যবহারকারী, একজন প্রশাসক, একজন দূরবর্তী কর্মী এবং একটি সিস্টেম অন্তর্ভুক্ত করা উচিত যা প্ল্যাটফর্মের সাথে ডেটা বিনিময় করে। তাদের প্রতিক্রিয়া প্রায়ই এমন সমস্যাগুলি প্রকাশ করে যা একটি প্রযুক্তিগত স্পেসিফিকেশন দেখায় না। সামঞ্জস্যতা এছাড়াও মানুষ অন্তর্ভুক্ত. একটি সিস্টেম যার জন্য জটিল ম্যানুয়াল পদক্ষেপের প্রয়োজন হয় সমর্থন অনুরোধ বাড়াতে পারে এবং অসামঞ্জস্যপূর্ণ ফলাফল তৈরি করতে পারে। ইন্সটলেশন টিম চলে যাওয়ার পর পরিকাঠামোকে কাজে লাগাতে সাহায্য করে পরিষ্কার কর্মপ্রবাহ। ## 3. নিরাপত্তা এবং কর্মক্ষম নিয়ন্ত্রণ নিরাপত্তা স্পেসিফিকেশন পর্যালোচনার অংশ হওয়া উচিত, ক্রয়ের পরে যোগ করা কোনো আইটেম নয়। আমি চেক করি কিভাবে সিস্টেমটি পরিচয়, অনুমতি, এনক্রিপশন, আপডেট, লগ, ব্যাকআপ এবং পুনরুদ্ধার পরিচালনা করে। কে সেটিংস পরিবর্তন করতে পারে এবং কীভাবে সেই পরিবর্তনগুলি রেকর্ড করা হয় তাও আমি জিজ্ঞাসা করি৷ মূল প্রশ্নগুলির মধ্যে রয়েছে: - প্ল্যাটফর্মটি কি মাল্টি-ফ্যাক্টর প্রমাণীকরণ সমর্থন করে? - ভূমিকা দ্বারা অ্যাক্সেস বরাদ্দ করা যেতে পারে? - অব্যবহৃত অ্যাকাউন্ট নিষ্ক্রিয় করা সহজ? - অ্যাডমিনিস্ট্রেটর অ্যাকশন লগ করা আছে? - বিদ্যমান পর্যবেক্ষণ সিস্টেমে লগ পাঠানো যাবে? - নিরাপত্তা আপডেট কিভাবে বিতরণ করা হয়? - ব্যাকআপ কি উৎপাদন ব্যবস্থা থেকে আলাদা করা যায়? - ব্যর্থতার পরে পুনরুদ্ধারের কতক্ষণ সময় লাগে? - লাইভ পরিষেবাগুলিকে প্রভাবিত না করে দল কি পুনরুদ্ধারের পরীক্ষা করতে পারে? একটি ব্যাকআপ তখনই কার্যকর যখন ব্যবসা একটি গ্রহণযোগ্য সময়ের মধ্যে প্রয়োজনীয় ডেটা পুনরুদ্ধার করতে পারে। ব্যাকআপ সম্পূর্ণ হয়েছে বলে স্ট্যাটাস মেসেজের উপর নির্ভর না করে আমি দলকে নমুনা পুনরুদ্ধার পরীক্ষা করতে বলি। একটি ছোট চিকিৎসা অনুশীলন, উদাহরণস্বরূপ, প্রতিদিনের ব্যাকআপ থাকতে পারে কিন্তু কোনো পরীক্ষিত পুনরুদ্ধারের প্রক্রিয়া নেই। প্রধান সার্ভার ব্যর্থ হলে, কর্মীরা আবিষ্কার করতে পারে যে ব্যাকআপ অ্যাকাউন্ট আর কাজ করে না বা একটি মূল অ্যাপ্লিকেশন অন্তর্ভুক্ত করা হয়নি। একটি পুনরুদ্ধারের অনুশীলন এই ফাঁকগুলি প্রকাশ করতে পারে যখন স্বাভাবিক পরিষেবাগুলি এখনও উপলব্ধ থাকে। অপারেশনাল নিয়ন্ত্রণ ডকুমেন্টেশন উপর নির্ভর করে. আমি একটি সিস্টেম ডায়াগ্রাম, মালিকানা তালিকা, আপডেট প্রক্রিয়া, বৃদ্ধির পথ এবং পুনরুদ্ধারের নির্দেশিকা দেখতে চাই। এই নথি দীর্ঘ হতে হবে না. তাদের অন্য প্রশিক্ষিত কর্মচারীকে বুঝতে সাহায্য করতে হবে যে কোন পরিষেবাটি কাজ করা বন্ধ করে দিলে কী বিদ্যমান এবং কী করতে হবে। ## একটি ব্যবহারিক পর্যালোচনা প্রক্রিয়া আমি প্রতিটি অবকাঠামো প্রস্তাবের জন্য একটি সাধারণ পর্যালোচনা টেবিল ব্যবহার করি: | এলাকা | রেকর্ড করার জন্য প্রশ্ন | |---|---| | ক্ষমতা | বর্তমান লোড, সর্বোচ্চ লোড এবং প্রত্যাশিত বৃদ্ধি কি? | | কর্মক্ষমতা | ব্যস্ত সময়, রক্ষণাবেক্ষণ বা আংশিক ব্যর্থতার সময় কী ঘটে? | | সামঞ্জস্য | কোন বিদ্যমান সিস্টেম, অ্যাপ্লিকেশন, এবং ডিভাইস সংযুক্ত করা আবশ্যক? | | নিরাপত্তা | কীভাবে অ্যাক্সেস, আপডেট, লগ, ব্যাকআপ এবং পুনরুদ্ধার পরিচালনা করা হয়? | | অপারেশন | কে সিস্টেমের মালিক, এবং কিভাবে পরিবর্তন পরিচালিত হবে? | | খরচ | ক্রয়, লাইসেন্স, সমর্থন, প্রশিক্ষণ এবং প্রস্থান খরচ কি? | আমি সরবরাহকারীকে শুধুমাত্র সাধারণ পণ্যের তথ্য পাঠানোর পরিবর্তে নির্দিষ্ট ব্যবহারের ক্ষেত্রে প্রতিক্রিয়া জানাতে বলি। "এটি কি আমাদের ব্যবসাকে সমর্থন করতে পারে?" খুব বিস্তৃত। "রাত্রিকালীন ব্যাকআপ চলাকালীন কি 40 জন দূরবর্তী ব্যবহারকারী ডকুমেন্ট সিস্টেম অ্যাক্সেস করতে পারে?" একটি আরো দরকারী উত্তর উত্পাদন করে। আমার দৃষ্টিভঙ্গি সহজ: একটি অবকাঠামোগত সিদ্ধান্তের বিচার করা উচিত যে এটি দৈনন্দিন কাজ, ভবিষ্যতের চাহিদা এবং ব্যাঘাত থেকে পুনরুদ্ধারকে কতটা সমর্থন করে। একটি উচ্চ স্পেসিফিকেশন স্বয়ংক্রিয়ভাবে একটি ভাল নকশা তৈরি করে না। সঠিক পছন্দ ক্ষমতা, সামঞ্জস্য, নিরাপত্তা এবং ব্যবহারিক ক্রিয়াকলাপকে সংযুক্ত করে। অনুমোদনের আগে এই তিনটি স্পেসিফিকেশন পর্যালোচনা করা দলটিকে সিস্টেমটি কী সমর্থন করতে পারে, এর সীমা কোথায় এবং কোন প্রশ্নের উত্তর প্রয়োজন তার একটি পরিষ্কার চিত্র দেয়। শিল্প প্রবণতা এবং সমাধান সম্পর্কে আরও জানতে আগ্রহী? Zhan এর সাথে যোগাযোগ করুন: 458602957@qq.com/WhatsApp +8618555395111।

তথ্যসূত্র Google, 2016, সাইট নির্ভরযোগ্যতা প্রকৌশল: Google কিভাবে প্রোডাকশন সিস্টেম ন্যাশনাল ইনস্টিটিউট অফ স্ট্যান্ডার্ডস অ্যান্ড টেকনোলজি চালায়, মে 2010, ফেডারেল ইনফরমেশন সিস্টেম অ্যামাজন ওয়েব পরিষেবার জন্য কন্টিনজেন্সি প্ল্যানিং গাইড, অক্টোবর 2023, AWS ভাল-আর্কিটেক্টেড ফ্রেমওয়ার্ক মাইক্রোসফ্ট, 2024, Azure2, দ্য লিনাক্স 2024 ফাউন্ডেশন, দ্য লিনাক্স ওয়েল-আর্কিটেক্টেড ফ্রেমওয়ার্ক ক্লাউড নেটিভ অবজারভেবিলিটি মার্টিন ক্লেপম্যান, 2017, ডেটা-ইনটেনসিভ অ্যাপ্লিকেশন ডিজাইন করা