একজন কাস্টমারের ফলাফলের চারপাশে প্রস্তুতি সংজ্ঞায়িত করুন
প্রাথমিকভাবে আউটকাম দিয়ে শুরু করুন, অবকাঠামো লেবেল দিয়ে নয়। একটি পৌঁছনীয় হোমপেজ যথেষ্ট নয় যদি ভিজিটর সেই কাজটি সম্পন্ন করতে না পারে যা গুরুত্বপূর্ণ। প্রতিটি গুরুত্বপূর্ণ যাত্রার জন্য বলুন কে কি করার চেষ্টা করছে, সফলতা কী বোঝায়, এবং কোন ফলাফল গ্রহণযোগ্য নয়। কয়েকটি যাত্রা দিয়ে শুরু করুন যাতে টিম বাস্তব সিদ্ধান্ত নিতে পারে।
প্রতি ধাপকে এসেনশিয়াল (অবশ্যক), ইম্পরটেন্ট (গুরুত্বপূর্ণ), বা ডিফারেবল (পরিহারযোগ্য) হিসেবে শ্রেণিবদ্ধ করুন। এসেনশিয়াল মানে ওই ধাপ ছাড়া যাত্রা শেষ হয় না; ইম্পরটেন্ট একটি সময়সীমাবদ্ধ ওয়ার্কঅ্যারাউন্ডকে অনুমতি দিতে পারে; ডিফারেবল বাদ, বিলম্ব বা সরলীকৃত করা যায়। এটি একটি প্রোডাক্ট সিদ্ধান্ত যা ইঞ্জিনিয়ারিং দ্বারা জানায়, সার্বজনীন প্রযুক্তিগত র্যাঙ্কিং নয়।
শুধু একটি পেজ-রেসপন্স টার্গেট না রেখে ব্যবহারযোগ্য ফলাফল নথিভুক্ত করুন—উদাহরণ: একটি অর্ডার গ্রহণ করা হয়েছে এবং কনফার্মেশন সংরক্ষিত হয়েছে।
নির্ভরশীলতাগুলো ম্যাপ করুন এবং কী degrade (ক্ষয়) করা যায় সিদ্ধান্ত নিন
প্রতি গুরুত্বপূর্ন পথের জন্য হোস্টিং বা ডেলিভারি, DNS, অ্যাপ্লিকেশন সার্ভিস, ডাটাবেস, অথেনটিকেশন, ইমেইল, পেমেন্ট, সার্চ, ট্যাগ, সম্মতি টুলিং, এবং বাহ্যিক API গুলো ম্যাপ করুন। প্রতিটির জন্য মালিক, সাপোর্ট রুট, প্রাসঙ্গিক সীমা, এবং যদি অবঅ্যাভেইলেবল হয় তবে ব্যবহারকারীর উপর প্রভাব রেকর্ড করুন। OWASP সফ্টওয়্যার নির্ভরশীলতা সম্পর্কে অন্তর্দৃষ্টি সুপারিশ করে; একই মালিকানার শৃঙ্খল অপারেশনাল নির্ভরশীলতার ক্ষেত্রেও সাহায্য করে।
একটি হার্ড নির্ভরশীলতা সেই টাস্কটিকে বন্ধ করে দেয় যখন তা ব্যর্থ হয়। একটি সফট নির্ভরশীলতা অনুপস্থিত বা স্টেল থাকলেও কোর টাস্ক কাজ করতে পারে। AWS গ্রেসফুল ডিগ্রেডেশনকে বর্ণনা করে—অর্থাৎ নির্ভরশীলতাগুলো অনহেলথি হলে কোর ফাংশনটি রাখা। একটি প্রোডাক্ট-নির্দিষ্ট পছন্দ নির্ধারণ করুন: একটি অনাবশ্যক উইজেট লুকিয়ে রাখা, একটি রিপোর্ট স্থগিত করা, বা সৎ ফ্যালব্যাক দেখানো। ইনভেন্টরি, মূল্য, অর্ডার-স্টেট বা পেমেন্ট ফলাফল আবিষ্কার করবেন না।
প্রতিটি আইটেমের উদ্দেশ্য, মালিক, পরিচিত সীমা, ফ্যালব্যাক, পরিবর্তন কন্টাক্ট, এবং শেষ টেস্ট তারিখ ধরা রাখুন।
একটি ট্র্যাফিক পূর্বাভাসকে ক্ষমতা পরীক্ষা (capacity experiment) তে পরিণত করুন
একটি সংখ্যার উপর নয়, একটি সিনারিও ব্যবহার করুন। ইভেন্টটি কি, আগমনের প্যাটার্ন, রিকোয়েস্ট মিক্স, সাইন-ইন শেয়ার, ভূগোল, সঙ্গবদ্ধ চেকআউট বা রাইট অ্যাক্টিভিটি, এবং শীর্ষ সময়কাল সম্পর্কে স্পষ্টভাবে জানুন। একটি হাই কেস এবং অনুমানগুলো অন্তর্ভুক্ত করুন। Google উল্লেখ করে যে রিকোয়েস্টগুলো খুব ভিন্ন রিসোর্স খরচ করতে পারে, তাই প্রতি সেকেন্ড রিকোয়েস্ট কেবলমাত্র ক্ষমতার একটি খারাপ মডেল হতে পারে।
প্রোডাকশনের কাছাকাছি কনফিগারেশনে অনুমোদন ও রক্ষা ব্যবস্থা সহ টেকসই, প্রতিনিধিত্বমূলক, এন্ড-টু-এন্ড ট্র্যাফিক টেস্ট করুন। AWS কেবল কনপোনেন্ট টেস্ট করা, অপ্রতিনিধিত্বমূলক রিকোয়েস্ট সাবসেটে নির্ভর করা, বা প্রত্যাশিত লোডের সামান্য মার্জিনের উপরে থামার ব্যাপারে সতর্ক করে। প্রথম সীমা বা ধীরগতির ডকুমেন্ট রাখুন। লাইভ-প্রোডাকশন টেস্ট গ্রাহকদের প্রভাবিত করতে পারে; পরিকল্পিত, স্টাফ করা অনুশীলন না হলে নিয়ন্ত্রিত পরিবেশ ব্যবহার করুন।
সিনারিো, কনফিগারেশন, রিকোয়েস্ট মিক্স, সময়কাল, দৃশ্যমান সীমা, ক্ষমতা পরিবর্তন, এবং ফলো-আপ মালিক সংরক্ষণ করুন।
পরিবর্তন, রোলব্যাক এবং পুনরুদ্ধারের বিকল্পগুলো প্রস্তুত করুন
একটি উচ্চ-স্টেকস পরিবর্তনের আগে পুনরুদ্ধারের আর্টিফ্যাক্ট বা কনফিগারেশন কী পুনরায় সেট করা হবে, কী অনুমোদন প্রয়োজন, কে অনুমোদিত ব্যক্তি, এবং যাচাই পদ্ধতি নির্ধারণ করুন। একটি সংক্ষিপ্ত রানবুক রাখুন—রিলিজ থামানো, ডিপ্লয়মেন্ট রিভার্ট করা, ফিচার ফ্ল্যাগ নিস্ক্রিয় করা, অগুরুত্বপূর্ণ ইন্টিগ্রেশন কমিয়ে দেওয়া, বা অনুমোদিত পদ্ধতি ব্যবহার করে ডেটা পুনরুদ্ধার করা ইত্যাদি। ইভেন্টের আগে মেকানিকগুলো টেস্ট করুন; একটি অনএক্সারসাইজড ব্যাকআপ বা রোলব্যাক প্ল্যান একটি অনুমান।
বিজনেস প্রভাব থেকে পুনরুদ্ধার লক্ষ্য নির্ধারণ করুন। Recovery Time Objective (RTO) হল সর্বোচ্চ গ্রহণযোগ্য বিলম্ব যতক্ষণ সেবা পুনরুদ্ধার না হয়। Recovery Point Objective (RPO) হল সর্বোচ্চ গ্রহণযোগ্য ডেটা ক্ষতি—সর্বশেষ পুনরুদ্ধার পয়েন্ট থেকে পরিমাপ করা। AWS স্বতন্ত্র বা অবাস্তব লক্ষ্যগুলোর বিরুদ্ধে সতর্ক করে এবং বলে যে নির্ভরশীলতা লক্ষ্যগুলো কী অর্জনযোগ্য তা প্রভাবিত করে। লক্ষ্যগুলোকে গ্রাহক প্রতিশ্রুতি নয়, পরিকল্পনার লক্ষ্য হিসেবে বিবেচনা করুন।
একটি সীমিত, নিরাপদ রোলব্যাক বা রিস্টোর যাচাই করুন এবং কি পরীক্ষা করা হয়েছে, কার দ্বারা, এবং কোনো ফাঁক থাকলে তা নথিভুক্ত করুন।
জরুরি সিদ্ধান্তগুলো আগে থেকেই মালিক নির্ধারণ করুন
শুধু কন্টাক্ট লিস্ট মালিকানা নয়। প্রতিটি গুরুত্বপূর্ণ পথে একটি ব্যবসায়িক মালিক নির্ধারণ করুন যারা গ্রহণযোগ্য আউটকামের জন্য দায়ী, একটি প্রযুক্তিগত মালিক যারা বাস্তবায়নের জন্য দায়ী, এবং একটি সিদ্ধান্ত মালিক যিনি সুরক্ষামূলক পরিবর্তন করার অনুমোদিত ক্ষমতা রাখেন। ব্যাকআপ নাম দিন এবং পরিষ্কার করুন কখন পেপার, এজেন্সি, পেমেন্ট প্রসেসর, বা অভ্যন্তরীণ টিম পরবর্তী পদক্ষেপের মালিক হবে।
ট্র্যাফিক আসার আগে একটি সংক্ষিপ্ত প্রস্তুতি পর্যালোচনা চালান। একটি নির্ভরশীলতা ব্যর্থতার মাধ্যমে হাঁটার মত: কি কিছুই থাকে, কোন লিভারটি নিরাপদ, কে অনুমোদন করে, এবং কীভাবে সফলতা চেক করা হবে। এটি প্রোঅ্যাকটিভ রিহার্সাল, লাইভ-স্ট্যাটাস রিপোর্ট নয়। তারিখযুক্ত পদক্ষেপ, মালিক এবং শেষ করার তারিখ রেকর্ড করুন।
যেখানে উপযুক্ত সেখানে সঙ্কীর্ণ নিরাপদ কর্মগুলো পূর্ব-অনুমোদিত করুন যাতে সুরক্ষা অনিশ্চিত অনুমোদন শৃঙ্খলের অপেক্ষায় না থাকে।
পেমেন্ট এবং সিকিউরিটি-সংবেদনশীল পথে অতিরিক্ত যত্ন নিন
চেকআউট প্রস্তুতি কেবল উপলব্ধি নয়—সঠিকতাও সংরক্ষণ করতে হবে। অথরাইজেশন বাইপাস করবেন না, অ্যাক্সেস কন্ট্রোল দূর্বল করবেন না, অরক্ষণীয়ভাবে ক্রেডেনশিয়াল প্রকাশ করবেন না, বা পেমেন্ট-পেজ স্ক্রিপ্ট সহজভাবে পরিবর্তন করবেন না। PCI SSC নির্দেশনা পেমেন্ট-পেজ স্ক্রিপ্ট এবং সিকিউরিটি-ইমপ্যাক্টিং HTTP হেডারের জন্য অথরাইজেশন, অখণ্ডতা, এবং ট্যাম্পার ডিটেকশনের বিষয়ে নির্দেশ দেয়। সাইট কার্ড গ্রহণ করে বা এমবেডেড পেমেন্ট ফ্রেম ব্যবহার করে থাকলে, মেরচ্যান্ট, প্রসেসর, অ্যাকুইরার, এবং যোগ্য সিকিউরিটি বা সম্মতি পরামর্শদাতাদের মাধ্যমে যে কোনো গুরুত্বপূর্ণ পরিবর্তন পর্যালোচনা করান।
প্রোডাকশনে ব্যবহৃত স্ক্রিপ্ট, ইন্টিগ্রেশন, ভার্সন, এবং অ্যাকাউন্ট মালিকানার ইনভেন্টরি রাখুন এবং যারা এগুলো পরিবর্তন করতে পারে তাদের সীমাবদ্ধ করুন। OWASP নির্দেশ করে যে নির্ভরশীলতার ইনভেন্টরি এবং ভার্সন পিনিং বিল্ডে কী প্রবেশ করছে সে সম্পর্কে অনিশ্চয়তা কমাতে পারে, যেখানে স্বয়ংক্রিয় ফলাফলগুলিকে তখনও ম্যানুয়াল যাচাই প্রয়োজন। এই অনুশীলনগুলো প্রস্তুতিতে সহায়ক, তবে তা PCI সম্মতি প্রতিষ্ঠা করে না বা সিকিউরিটি মূল্যায়নের বিকল্প নয়।
শুধুমাত্র প্রসেসর-অনুমোদিত, পর্যালোচিত বিকল্প ফ্লো ব্যবহার করুন; কখনও অনানুষ্ঠানিক চ্যানেল দিয়ে কার্ড ডেটা সংগ্রহ করবেন না।