০৭ সেপ, ২০২৫·7 মিনিট পড়তে

সেল্ফ-হোস্টিং-এর জন্য Production-ready অ্যাপ হ্যান্ডঅফ চেকলিস্ট

এই production-ready হ্যান্ডঅফ চেকলিস্টটি env, সিক্রেট, মনিটরিং, ব্যাকআপ ও রানবুক প্যাকেজ করে ops-কে অ্যাপ ডিপ্লয় ও পরিচালনার জন্য প্রস্তুত করে।

Production-ready হ্যান্ডঅফ বাস্তবে কী বোঝায়

Production-ready হ্যান্ডঅফ মানে ops-রা অনুমান না করে অ্যাপটি চালাতে পারবে। তারা একটি নির্দিষ্ট ভার্সন ডিপ্লয় করতে পারবে, স্বাস্থ্যের নিশ্চয়তা দিতে পারবে, অ্যালার্টগুলোর জবাব দিতে পারবে এবং খারাপ রিলিজ বা আউটেজ থেকে পুনরুদ্ধার করতে পারবে। যদি এসবের কোনটিই কোনো ডেভেলপার-এর স্মৃতির উপর নির্ভর করে, তাহলে হ্যান্ডঅফ সম্পন্ন হয়নি।

হ্যান্ডঅফকে এমন এক প্যাকেজ হিসেবে ভাবুন যা একটি প্রশ্নের উত্তর দেয়: মূল নির্মাতারা এক সপ্তাহের জন্য অনুপস্থিত হলে কি ops এখনও সিস্টেমকে নিরাপদ ও উপলব্ধ রাখতে পারবে?

একটি ভালো প্যাকেজ সাধারণত কভার করে: অ্যাপটি কি করে, "স্বাস্থ্যবান" বলতে কী বোঝায়, রিলিজ কীভাবে কাজ করে (ডিপ্লয়, যাচাই, রোলব্যাক), কনফিগ কখন কোথায় থাকে, সিক্রেটস কিভাবে হ্যান্ডল করা হয়, এবং মনিটরিং, ব্যাকআপ ও ইনসিডেন্টে কিভাবে প্রতিক্রিয়া করা হয়।

এতটাই গুরুত্বপূর্ণ যে হ্যান্ডঅফ কী কভার করে না। হ্যান্ডঅফ কোনো ফিচার অ্যাড করা, রিফ্যাক্টর করা, স্ক্রীন ডিজাইন বদলানো বা "পরে পরিষ্কার করা হবে"—এইসবের প্রতিশ্রুতি নয়। সেগুলো আলাদা প্রজেক্ট যার আলাদা স্কোপ আছে।

সম্পন্ন বলে ঘোষণার আগে দায়িত্ব ও রেসপন্স টাইমগুলিতে সম্মত হন। উদাহরণস্বরূপ: ops-ই uptime-এর দায় নেয় এবং ডিপ্লয় করে; প্রোডাক্ট টিম রোডম্যাপ পরিবর্তনের দায়ে; ডেভ টিম হ্যান্ডঅফের পরে কিছু নির্দিষ্ট সময়ের জন্য ফিক্স ও প্রশ্নের সমর্থন দেয়।

একটি সরল সিস্টেম ইনভেন্টরি তৈরি করুন (কি কোথায় চলছে)

Ops মাত্র দেখা যে জিনিসটুকুই পরিচালনা করতে পারে। একটি এক-পৃষ্ঠার ইনভেন্টরি ডিপ্লয়, ইনসিডেন্ট ও অডিটের সময় অনুমানকে রোধ করে। এটা সরল ইংরেজি (বা স্থানীয় ভাষা) এবং স্পষ্ট রাখুন।

সিস্টেমের প্রতিটি চলমান অংশ এবং সে কোথায় আছে তা তালিকাভুক্ত করুন: ব্যাকএন্ড API, ওয়েব অ্যাপ, ব্যাকগ্রাউন্ড ওয়ার্কার, নির্ধারিত জব, এবং মোবাইল অ্যাপ কিভাবে সংযুক্ত হয়। যদিও iOS/Android স্টোর দিয়ে বিতরণ হয়, তবুও তারা একই ব্যাকএন্ডের উপর নির্ভর করে।

অ্যাপ যে বাইরের সার্ভিসগুলো ছাড়া চলবে না সেগুলোও অন্তর্ভুক্ত করুন। আপনি যদি ব্যবহার করেন PostgreSQL, কিউ, অবজেক্ট স্টোরেজ বা তৃতীয় পক্ষের API (যেমন payments like Stripe, messaging, email/SMS, Telegram), সঠিক সার্ভিস নাম এবং এর ব্যাবহার কী সেটি লিখে রাখুন।

হোস্টিং ট্রায়াল-এন্ড-এরর না হয়ে উঠুক এজন্য নেটওয়ার্ক চাহিদাগুলো ধরুন: প্রয়োজনীয় ডোমেইন (app, api, admin), পোর্ট ও প্রোটোকল, TLS সার্টিফিকেট কে রিনিউ করে, DNS কোথায় ম্যানেজ হয়, এবং কোনো ইনবাউন্ড/আউটবাউন্ড allowlists আছে কিনা।

শেষে আনুমানিক লোড সংখ্যায় লিখে রাখুন: একেবারে পিক রিকোয়েস্ট মিনিট প্রতি, সক্রিয় ইউজার, সাধারণ পে-লোড সাইজ, বর্তমান ডেটাবেস সাইজ, ও প্রত্যাশিত বৃদ্ধির হার। এমনকি রাফ রেঞ্জও ops-কে লিমিট ও অ্যালার্ট সেট করতে সাহায্য করে।

আপনি যদি AppMaster দিয়ে বানিয়ে থাকেন, তবে জেনারেট করা ব্যাকএন্ড, ওয়েব অ্যাপ এবং ইন্টিগ্রেশনগুলো inventory-তে রাখুন যাতে ops জানে কোনগুলো একসাথে ডিপ্লয় করতে হবে।

পরিবেশ কনফিগারেশন প্যাকেজ করুন (সিক্রেট উন্মোচন না করে)

প্রোডাকশন সেটআপ সাধারণত সেই বিরক্তিকর অংশে ব্যর্থ হয়: কনফিগ যা কেবল কারো মাথায় আছে। কনফিগারেশনকে একটি ডেলিভারেবল হিসেবে বিবেচনা করুন। ops-কে দেখতে হবে কী সেটিংস আছে, পরিবেশ অনুসারে কী আলাদা, এবং কিভাবে এগুলো নিরাপদে পরিবর্তন করতে হয়।

প্রতিটি বিদ্যমান পরিবেশের নাম দিয়ে শুরু করুন, এমনকি যদি তা অস্থায়ী মনে হয়। বেশিরভাগ টিমে dev, staging এবং production থাকে, সাথে কখনো কখনো "production-eu" বা "staging-us"-এর মতো কপি থাকে। নোট করুন কোন পরিবেশ রিলিজ টেস্টিং, ডেটা মাইগ্রেশন ও ইনসিডেন্ট ড্রিলের জন্য ব্যবহৃত হয়।

একটি একক কনফিগ রেফারেন্স দিন যা ভ্যারিয়েবল নামগুলো এবং নিরাপদ উদাহরণ মান (কখোনো প্রকৃত ক্রেডেনশিয়াল নয়) তালিকাভুক্ত করবে। প্লেসহোল্ডারগুলো স্পষ্ট রাখুন।

আপনার হ্যান্ডঅফ প্যাকেজে থাকা উচিত:

পরিবেশগুলোর তালিকা এবং প্রতিটির উদ্দেশ্য
কনফিগ কী-এর রেফারেন্স (env vars বা কনফিগ ফাইল কী), প্রত্যাশিত টাইপ, এবং একটি নন-সিক্রেট উদাহরণ মান
পরিবেশগুলোর মধ্যে জানাজানি পার্থক্য (ফিচার ফ্ল্যাগ, রেট লিমিট, ক্যাশ সাইজ, ইমেইল মোড, লগিং লেভেল)
ডিফল্ট মান এবং কোনো কী অনুপস্থিত হলে কী হয়
কনফিগ কোথায় সংরক্ষিত এবং ডিপ্লয়ে কীভাবে প্রয়োগ হয়

সরল একটি পরিবর্তন প্রক্রিয়া যোগ করুন। উদাহরণ: টিকেটে রিকোয়েস্ট, সার্ভিস ওনার দ্বারা রিভিউ, আগে স্টেজিং-এ প্রয়োগ, তারপর নির্ধারিত উইন্ডোতে প্রোডাকশনে প্রোমোট এবং ইরর রেট বাড়লে রোলব্যাক প্ল্যান।

আপনি যদি AppMaster থেকে export করে self-host করছেন, একই নিয়ম পালন করুন: জেনারেট করা সোর্সের পাশে পরিষ্কার, ডকুমেন্টেড কনফিগ কী-এর সেট শিপ করুন যাতে ops বিভিন্ন পরিবেশে ধারাবাহিকভাবে চালাতে পারে।

সিক্রেটস ও ক্রেডেনশিয়াল: স্টোরেজ, রোটেশন, এবং অ্যাক্সেস

সিক্রেটসই সবচেয়ে দ্রুত একটি পরিষ্কার হ্যান্ডঅফকে সিকিউরিটি ইনসিডেন্টে পরিণত করে। লক্ষ্য সরল: ops-কে জানতে হবে অ্যাপ কোন সিক্রেটগুলো চায়, সেগুলো কোথায় রাখা, কে পড়ে পারে, এবং কিভাবে তা ডাউনটাইম ছাড়াই বদলানো যায়।

এক মিনিটে স্ক্যান করা যাবে এমন একটি শর্ট সিক্রেটস লিস্ট দিয়ে শুরু করুন। প্রতিটি আইটেমের জন্য লেখুন এটি কী আনলক করে (ডেটাবেস, SMTP, Stripe, JWT signing key), কোথায় আছে (vault, cloud secret store, Kubernetes Secret, encrypted file), এবং রোটেশনের মালিক কে।

রোটেশন স্টেপগুলো নীতিমালার মতো না করে রেসিপির মতো লিখুন। সঠিক অর্ডার, কতক্ষণ পুরানো সিক্রেট বৈধ থাকতে হবে, এবং যে একটিই চেক সেটি কার্যকরতা প্রমাণ করে—এইগুলো দিন।

রোটেশন চেকলিস্ট (উদাহরণ)

প্রতিটি সিক্রেটের জন্য এই প্যাটার্ন ব্যবহার করুন:

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

এনক্রিপশন প্রত্যাশা সম্পর্কে স্পষ্ট থাকুন। সিক্রেটগুলো স্টোরে রেস্টে এনক্রিপ্টেড থাকা উচিত এবং অ্যাপ ও তার ডিপেন্ডেন্সির মধ্যে ট্রান্সিটের সময় TLS-এ সুরক্ষিত থাকা উচিত। সিক্রেট কখনো সোর্স কন্ট্রোলে, বিল্ড আর্টিফ্যাক্টে বা শেয়ারড ডকসে রাখবেন না।

ব্রেক-গ্লাস অ্যাক্সেস সংজ্ঞায়িত করুন। যদি আউটেজ স্বাভাবিক অ্যাক্সেস বন্ধ করে দেয়, তাহলে নির্দিষ্ট করুন কে জরুরি অ্যাক্সেস অনুমোদন করতে পারে, তা কতক্ষণ চালু থাকবে, এবং পরে কি অডিট করা লাগবে।

ডিপ্লয়মেন্ট প্যাকেজ: আর্টিফ্যাক্ট, ভার্সন, এবং রোলব্যাক

আপনার ডিপ্লয়েবল সোর্স নিজের করুন

বাস্তব সূত্রকোড জেনারেট করুন যা আপনার টিম রান, রিভিউ ও সেল্ফ-হোস্ট করতে পারে।

কোড জেনারেট করুন

Ops কেবল সেইটাই পরিচালনা করতে পারে যা তারা পুনরুত্পাদন করতে পারে। একটি ভালো ডিপ্লয়মেন্ট প্যাকেজ তিনটি প্রশ্নের উত্তর সহজ করে: আমরা ঠিক কি চালাচ্ছি, কিভাবে আবার ডিপ্লয় করব, এবং কিছু ভেঙে গেলে দ্রুত কিভাবে ফিরে যাব?

বিল্ডের একটি স্পষ্ট “বিল অফ ম্যাটেরিয়াল” দিন। আর্টিফ্যাক্ট টাইপ ও কিভাবে যাচাই করবেন তা নাম দিন, কেবল কোথায় আছে সেটাই নয়:

আর্টিফ্যাক্ট বিবরণ: কনটেইনার ইমেজ নাম/ট্যাগ (বা বাইনারি/প্যাকেজ নাম), অ্যাপ ভার্সন, বিল্ড তারিখ, চেকসাম
সোর্স রেফারেন্স: রিলিজ ট্যাগ বা কমিট হ্যাশ যা বিল্ডে ব্যবহার হয়েছে, ও কোন বিল্ড ফ্ল্যাগগুলি গুরুত্বপূর্ণ
সাপোর্টেড টার্গেট: VM, কনটেইনার (Docker) বা Kubernetes, এবং কোনটি সুপারিশকৃত ডিফল্ট
ডিপ্লয় স্টেপস: প্রিরিকুইজিটস (রানটাইম, ডেটাবেস, স্টোরেজ), সঠিক অর্ডার, এবং সাধারণ ডিপ্লয় সময়
ডেটাবেস মাইগ্রেশন: কিভাবে চালানো হয় (স্টার্টআপে অটো বা ম্যানুয়াল), লগ কোথায় আছে, ও সফলতা কীভাবে নিশ্চিত করা হয়

একটি ছোট, কনক্রিট উদাহরণ যোগ করুন। উদাহরণ: “Deploy v1.8.2 করতে ইমেজ ট্যাগ আপডেট করুন, মাইগ্রেশন চালান, তারপর ওয়েব ওয়ার্কার্স রিস্টার্ট করুন। যদি 10 মিনিটের মধ্যে হেলথ চেক ফেল করে, v1.8.1-এ রিভার্ট করুন এবং মাইগ্রেশন কাজ বন্ধ করুন।”

জটিলতা ছাড়া রোলব্যাক

একটি রোলব্যাক প্ল্যান এমনভাবে লিখুন যেন রাত ২টায় অনুসরণ করা যায়। এতে থাকা উচিত:

রোলব্যাক ট্রিগার করার সিগন্যাল (এরর রেট, হেলথ চেক ফেল, লগইন ভাঙা)
শেষ known-good ভার্সন এবং তা কোথায় রাখা আছে
ডেটাবেস পরিবর্তনগুলো কি উল্টানো যায় এবং যদি না যায় কি করণীয়

আপনি যদি অ্যাপটি AppMaster দিয়ে বানিয়ে export করে self-host করছেন, তাহলে জেনারেটেড কোড ভার্সন, বিল্ড নির্দেশনা এবং রানটাইম প্রত্যাশাগুলো অন্তর্ভুক্ত করুন যাতে ops একই রিলিজ পরবর্তীতে পুনর্নির্মাণ করতে পারে।

মনিটরিং ও অ্যালার্টিং: কি মাপবেন এবং কখন পেজ করবেন

হ্যান্ডঅফ তখনই পূর্ণ হবে যখন ops দেখতে পারবে অ্যাপ কী করছে এবং ব্যবহারকারীরা ফাঁসফোস করার আগে তারা সাবধান করে দেওয়া হবে।

কোন লগগুলি থাকতে হবে এবং কোথায় যাবে (ফাইল, syslog, লগ প্ল্যাটফর্ম) এ বিষয়ে সম্মত হন। নিশ্চিত করুন লগগুলোর টাইম সিঙ্ক আছে এবং একটি রিকোয়েস্ট বা করিলেশন ID আছে যাতে ইনসিডেন্ট ট্রেস করা যায় শেষ পর্যন্ত।

সাধারণত চাই এমন লগ: অ্যাপ্লিকেশন লগ (কী ইভেন্ট ও ফেইলিউর), এরর লগ (স্ট্যাক ট্রেস ও ফেইল করা জব), অ্যাক্সেস লগ (রিকোয়েস্ট ও স্ট্যাটাস কোড), অডিট লগ (অ্যাডমিন অ্যাকশন ও এক্সপোর্ট), এবং ইন্ফ্রাস্ট্রাকচার লগ (রিস্টার্ট, নোড প্রেসার, ডিস্ক ইস্যু)।

পরবর্তী ধাপে এমন Metrics কয়েকটি নির্ধারণ করুন যা ব্যবহারকারী-প্রভাব ও সিস্টেম স্বাস্থ্য প্রতিফলিত করে। যদি শুধু পাঁচটি বেছে নিতে হয়: latency (p95/p99), error rate, saturation (CPU/memory/disk), queue depth, এবং নেটওয়ার্কের বাইরে থেকে availability checks।

অ্যালার্ট রুলগুলো অস্পষ্ট নয়: কি ট্রিগার করে, সেভারিটি (পেজ বনাম টিকিট), কে অন-কল, এবং কখন এস্কেলেট করতে হবে। একটি "ভাল" ড্যাশবোর্ড স্ন্যাপশট এবং স্বাভাবিক কী তার সংক্ষিপ্ত নোট যুক্ত করুন (স্বাভাবিক latency রেঞ্জ, প্রত্যাশিত error rate, সাধারণ queue depth)। এই প্রসঙ্গ শব্দবহুল অ্যালার্ট কমায় ও নতুন রেসপন্ডারকে দ্রুত কাজ করতে সাহায্য করে।

ব্যাকআপ ও রিকভারি: রিস্টোরগুলো বারবার করা যায় এমন করে বানান

আপনার ব্যাকএন্ড স্পষ্টভাবে ডিজাইন করুন

PostgreSQL ডেটা এবং API ভিজুয়ালি মডেল করুন, তারপর বাস্তব ব্যাকএন্ড হিসেবে ডিপ্লয় করুন।

ব্যাকএন্ড তৈরি করুন

ব্যাকআপ কেবল "আছে" এমন কিছু নয় — এগুলো এমন কিছু যা আপনি ডিমান্ডে রিস্টোর করতে পারেন।

নির্দিষ্টভাবে লিখে রাখুন ব্যাকআপের স্কোপ: ডেটাবেস, ফাইল স্টোরেজ (আপলোড, রিপোর্ট, ইনভয়েস), এবং সাধারণত ভুলে যাওয়া কনফিগ যা কোডে নেই এবং এনক্রিপশন কী যা রক্ষা করা ডেটা পড়তে লাগে।

টার্গেটগুলো সাধারণ ভাষায় রাখুন। RPO হল আপনি কত ডাটা হারাতে পারবেন (উদাহরণ: 15 মিনিট)। RTO হল আপনি কতক্ষণ ডাউন থাকতে পারবেন (উদাহরণ: 1 ঘন্টা)। ব্যবসা যা মেনে নেয় এমন সংখ্যা নিন, কারণ এগুলোই খরচ ও প্রচেষ্টা নির্ধারণ করে।

অন্তর্ভুক্ত করুন:

কি ব্যাকআপ করা হয়, কোথায় থাকে, এবং রিটেনশন
কে ব্যাকআপ ও রিস্টোর চালাতে পারে, এবং অ্যাক্সেস কীভাবে অনুমোদিত হয়
ধাপে ধাপে রিস্টোর প্রক্রিয়া ও যাচাইকরণ চেক
রিস্টোর লগ কোথায় থাকে, এবং ‘সফলতা’ কীভাবে দেখা হয়
সাধারণ ব্যর্থতার কারণ (ভুল কী, মিসিং বালতি, স্কিমা মিসম্যাচ) এবং সমাধান

আপনি যদি AppMaster থেকে export করে self-host করছেন, PostgreSQL রিস্টোর স্টেপস ও কোনো এক্সটার্নাল স্টোরেজ বালতি এবং এনক্রিপ্টেড ফিল্ডের কী অন্তর্ভুক্ত করুন।

একটি রিস্টোর ড্রিল শিডিউল করুন। সময়, কি ভাঙল, এবং আপনি কি পরিবর্তন করলেন তা রেকর্ড করুন যাতে পরেরবার রিস্টোর দ্রুত ও কম স্ট্রেসফুল হয়।

রানবুক এবং অন-কল: ops বাস্তবে ইনসিডেন্ট কিভাবে হ্যান্ডেল করে

হ্যান্ডঅফ তখনই বাস্তব যখন কেউ রাত ২টায় পেজ পেয়ে সমস্যা ঠিক করতে পারে অনুমান না করে। রানবুক উপজাতি জ্ঞানকে এমন ধাপে ভাঙ্গে যা অন-কল ব্যক্তি অনুসরণ করতে পারে।

প্রথমে সেই ইনসিডেন্টগুলো নিয়ে শুরু করুন যা প্রথমে ঘটার সম্ভাবনা বেশি: মোট আউটেজ, ধীর অনুরোধ, এবং একটি ডিপ্লয় যা কিছু ভেঙে দেয়। প্রতিটি রানবুক ছোট রাখুন। দ্রুততম চেকগুলো উপরে রাখুন যাতে রেসপন্ডার মিনিটের মধ্যে সিগন্যাল পায়।

একটি ভালো রানবুক কি রাখে

গঠন সঙ্গত রাখুন যাতে চাপের মধ্যে স্ক্যান করা যায়:

ব্যবহারকারী কি দেখে এবং তা কিভাবে যাচাই করবেন (উদাহরণ: এরর রেট X% এর উপরে, চেকআউট ব্যর্থ)
প্রথম চেকগুলো (সার্ভিস স্ট্যাটাস, সাম্প্রতিক ডিপ্লয়, ডিপেনডেন্সি হেলথ, ডিস্ক/CPU, ডেটাবেস কানেকশন)
পরবর্তী চেকগুলো (কোন লগগুলো খোলা লাগে, কী ড্যাশবোর্ড, সাম্প্রতিক কনফিগ পরিবর্তন, কিউ গভীরতা)
ডিসিশন পয়েন্ট (কখন রোলব্যাক, কখন স্কেল, কখন কোনো ফিচার নিষ্ক্রিয় করা)
এসকালেশন (কে অ্যাপ-এর মালিক, কে ইনফ্রার মালিক, এবং কবে কারে পেজ করা)

আপনি যদি AppMaster থেকে export করে self-host করেন, তা হলে জেনারেট করা সার্ভিসগুলো কোথায় চলে, কিভাবে নিরাপদে রিস্টার্ট করতে হয়, এবং প্রতিটি পরিবেশে কোন কনফিগ ভ্যালু প্রত্যাশিত—এসব অন্তর্ভুক্ত করুন।

ইনসিডেন্টের পরে: সঠিক তথ্য ধরুন

একটি সংক্ষিপ্ত পোস্ট-ইনসিডেন্ট চেকলিস্ট রাখুন। টাইমলাইন রেকর্ড করুন, শেষ কোন পরিবর্তন হয়, সঠিক এরর মেসেজগুলো কি, কোন ইউজাররা প্রভাবিত, এবং কোন অ্যাকশনটা ঠিক করলো। তারপর রানবুক আপডেট করুন যখন তথ্য ঘরোয়া থাক।

অ্যাক্সেস কন্ট্রোল ও পারমিশন: কে কী করতে পারে

আপনার হোস্টিং পথ বেছে নিন

AppMaster Cloud বা আপনার AWS, Azure, or Google Cloud সেটআপে ডিপ্লয় করুন।

এখন ডিপ্লয় করুন

Ops কেবল সেই সিস্টেমটি মালিকানা নিতে পারে যদি স্পষ্ট থাকে কে কী করতে পারে এবং কিভাবে অ্যাক্সেস ট্র্যাক করা হয়।

আপনি যে রোলে বাস্তবে ব্যবহার করেন সেগুলো লিখে রাখুন। অনেক টিমের জন্য এগুলো যথেষ্ট:

Deployer: অনুমোদিত ভার্সন ডিপ্লয় ও রোলব্যাক ট্রিগার করে
DB admin: স্কিমা পরিবর্তন ও ব্যাকআপ রিস্টোর চালায়
Read-only: ড্যাশবোর্ড, লগ ও কনফিগ দেখার অনুমতি কিন্তু সম্পাদনার নয়
Incident commander: আউটেজের সময় জরুরি সিদ্ধান্ত ও অ্যাকশন অনুমোদন করে

"ডোর পলিসি" সরল ধাপে ডকুমেন্ট করুন: কে অ্যাক্সেস দেয়, কোথায় (SSO, ক্লাউড IAM, ডেটাবেস ইউজার, CI/CD, অ্যাডমিন প্যানেল), কে বাতিল করে, এবং অফবোর্ডিংয়ে তা কিভাবে বাদ পড়েছে কি নিশ্চিত করা হয়।

নন-হিউম্যান অ্যাক্সেস ভুলে যাবেন না। প্রতিটি সার্ভিস অ্যাকাউন্ট ও টোকেন তালিকাভুক্ত করুন যেগুলো জব, ইন্টিগ্রেশন ও মনিটরিং ব্যবহার করে, সাথে প্রতিটির জন্য least-privilege নোট (উদাহরণ: "শুধু বালতি X থেকে পড়তে পারে")। যদি আপনি AppMaster সোর্স কোড এক্সপোর্ট করেন self-hosting-এর জন্য, উল্লেখ করুন কোন env vars বা কনফিগ ফাইল এই পরিচয় নির্ধারণ করে, কিন্তু কখনো সিক্রেট মান হ্যান্ডঅফ ডকুমেন্টে পেস্ট করবেন না।

অডিট লগ প্রত্যাশাও সেট করুন: কি লগ করা উচিত (লগইন, ডিপ্লয়, কনফিগ পরিবর্তন, DB admin অ্যাকশন), কে লগ পড়তে পারে, রিটেনশন, কোথায় লগ সংরক্ষিত, এবং ইনসিডেন্ট বা রিভিউয়ে লগ কিভাবে অনুরোধ করবেন।

সিকিউরিটি ও কমপ্লায়েন্স বেসিক (সরল ভাষায়)

সিকিউরিটি নোটগুলো না-টেকনিক্যাল লোক পড়লেই বুঝতে পারে এমনভাবে লিখুন, কিন্তু অপারেশনসের জন্য যথেষ্ট নির্দিষ্ট। এক পৃষ্ঠার সারাংশ দিন যা উত্তর দেয়: আমরা কি ডেটা রাখি, সেটা কোথায় থাকে, এবং কে অ্যাক্সেস পায়?

ডেটার ধরণ দিয়ে শুরু করুন: কাস্টমার প্রোফাইল, সাপোর্ট টিকিট, পেমেন্ট মেটাডাটা, ফাইল। সংবেদনশীল ক্যাটাগরি যেমন PII (নাম, ইমেইল, ফোন নম্বর), ক্রেডেনশিয়াল এবং কোন নিয়মিত-নিয়ন্ত্রিত ডেটা থাকলে সেটাও উল্লেখ করুন। যদি আপনি সেল্ফ-হোস্টিং-এর জন্য সোর্স কোড এক্সপোর্ট করে থাকেন (AppMaster-সহ), লিখুন ঐ ডেটা কোথায় ডেটাবেসে পড়ে এবং কোন সার্ভিসগুলো তা পড়তে পারে।

এরপর রিটেনশন ও ডিলিশন নিয়মগুলো ব্যবহারিকভাবে লিখুন। বলুন কি রাখবেন, কতক্ষণ, এবং ডিলিশন কিভাবে কাজ করে (soft delete বনাম hard delete, ডিলে-পার্জ, ব্যাকআপ)। যদি লিগ্যাল হোল্ড বা অডিট প্রয়োজন থাকে, ব্যতিক্রম কে অনুমোদন করে তা লিখে দিন।

লগগুলি প্রায়ই ডেটাবেসের চেয়েও বেশি লিক করে। পরিষ্কার করে বলুন কোথায় PII দেখতে পাওয়া যেতে পারে (অ্যাক্সেস লগ, এরর লগ, অ্যানালিটিক্স ইভেন্ট) এবং কিভাবে আপনি এটাকে কম বা মাস্ক করবেন। যদি কোন ফিল্ড কখনো লগ করা যাবে না, সেটি স্পষ্টভাবে উল্লেখ করুন।

অনুমোদনগুলো নির্দিষ্ট করুন:

Authentication পরিবর্তনের জন্য নামযুক্ত অনুমোদক লাগবে।
Payment-সংক্রান্ত পরিবর্তন (Stripe keys, webhook endpoints, রিফান্ড লজিক) নামযুক্ত অনুমোদক লাগবে।
রোল ও পারমিশন মডেল পরিবর্তনের জন্য নামযুক্ত অনুমোদক লাগবে।
সিকিউরিটি প্যাচিং উইন্ডো ও জরুরি পরিবর্তনের নিয়ম ডকুমেন্ট করা থাকবে।

একটি অতিরিক্ত জিনিস যোগ করতে পারেন যদি কিছু করে থাকেন: একটি এভিডেন্স নোট কোথায় অডিট লগ রাখা হয় এবং কাউকে প্রমাণ চাইলে কীভাবে এক্সপোর্ট করবেন।

উদাহরণ হ্যান্ডঅফ সিনারিও: ops এক সপ্তাহে মালিকানাসম্পন্ন হয়

পেমেন্ট দায়িত্বশীলভাবে প্ল্যান করুন

শুরুতেই Stripe ইন্টিগ্রেট করুন যাতে ops জানে কি মনিটর ও রোটেট করতে হবে।

পেমেন্ট যোগ করুন

Ops একটি কাস্টমার পোর্টাল নিয়ে নেয় যা ছোট প্রোডাক্ট টিম তৈরি করেছে এবং নতুন সেল্ফ-হোস্টেড ইনফ্রাস্ট্রাকচারে মুভ করছে। লক্ষ্য শুধু "চলছে" নয়, বরং "ops এটিকে নির্মাতাদের কল ছাড়া চালাতে পারবে"।

সপ্তাহটি কেমন লাগবে

Day 1: Ops একটি নতুন পরিবেশে হ্যান্ডঅফ প্যাকেজ দিয়ে প্রথম ক্লিন ডিপ্লয় করে। অ্যাপটি উঠলেও লগইন ব্যর্থ হয় কারণ ইমেইল প্রোভাইডারের জন্য একটি এনভায়রনমেন্ট ভ্যারিয়েবল অনুপস্থিত। সেটি env টেমপ্লেটে যোগ করা হয়, এবং ডিপ্লয় আবার করা হয় যতক্ষণ না শূন্য থেকে কাজ করে।

Day 2: ইচ্ছাকৃতভাবে প্রথম অ্যালার্ট ট্রিগার করে। Ops একটি কন্ট্রোলড ফেলিয়ার (এক সার্ভিস বন্ধ করা বা আউটবাউন্ড ইমেইল ব্লক করা) ট্রিগার করে এবং নিশ্চিত করে: মেট্রিক্স ইস্যুটি দেখায়, অ্যালার্ট সঠিক চ্যানেলে পৌঁছায়, এবং বার্তায় পরবর্তী করণীয় বলা আছে।

Day 3: পেমেন্ট স্যান্ডবক্সে একটি টোকেন মেয়াদোত্তীর্ণ হয়। ক্রেডেনশিয়াল লোকেশন ও রোটেশন স্টেপ ডকুমেন্টেড থাকায় ops এটি বদলে নেয় অনুমান না করে বা সিক্রেট উন্মোচিত করে না।

Day 4: DNS কাটওভার। ভুল রেকর্ড পুরানো IP-তে নির্দেশ করায় কিছু ব্যবহারকারীর জন্য পোর্টাল ডাউন মনে হয়। Ops রানবুক মেনে DNS, TLS, এবং হেলথ চেক সঠিক ক্রমে যাচাই করে।

Day 5: প্রথম ব্যাকআপ-রিস্টোর টেস্ট। Ops একটি ফ্রেশ ডাটাবেসে রিস্টোর করে প্রমাণ করে পোর্টাল সঠিকভাবে বাস্তব ডেটা লোড করতে পারে।

1 সপ্তাহ পরে “সম্পন্ন” কেমন লাগবে

অ্যাপটি ৭ দিন ধরে অজানা ফিক্স ছাড়াই চলেছে, একটি সফল রিস্টোর হয়েছে, স্পষ্ট অ্যালার্ট আছে, এবং একটি পুনরাবৃত্তযোগ্য ডিপ্লয় আছে যেটি ops একা করতে পারে।

সাধারণ হ্যান্ডঅফ ভুল যা রাতের ২টায় সমস্যা তৈরি করে

একটি শান্ত হ্যান্ডঅফকে রাত ২টার আগুনে পরিণত করার দ্রুততম উপায় হল ধরে নেওয়া যে "আমরা ops-কে সব কিছু বলেছি" মানেই "ops আমাদের ছাড়া চালাতে পারে"।

সেল্ফ-হোস্টিং হ্যান্ডঅফের পর সাধারণ ব্যর্থতার ধরণগুলো:

স্প্রেডশিট বা চ্যাটে শেয়ার করা সিক্রেটস
রোলব্যাক যা কোনো ডেভেলপারের উপর নির্ভর করে
ব্যাকআপ আছে কিন্তু রিস্টোর টেস্ট হয়নি
অ্যালার্ট সারাক্ষণ বেজে কারণ থ্রেশহোল্ড ঠিক করা হয়নি
পরিবেশের বিবরণ কেবল কারো মাথায় (পোর্ট, DNS নাম, ক্রন শিডিউল, ক্লাউড পারমিশন)

উদাহরণ: আপনি AppMaster থেকে সোর্স কোড এক্সপোর্ট করে self-host করছেন এবং প্রথম ডিপ্লয় কাজ করে। দুই সপ্তাহ পরে একটি কনফিগ পরিবর্তন লগইন ভেঙে দেয়। যদি সিক্রেটস চ্যাটে ছিল এবং রোলব্যাকের জন্য মূল নির্মাতার প্রয়োজন হয়, ops ঘণ্টা কাটে শুধু ফিরে নিয়ে আসতে "গতকালের কাজ"-এ।

“হ্যান্ডঅফ সম্পন্ন” বলার আগে দ্রুত চেকগুলো

প্রক্রিয়াগুলো কম ম্যানুয়াল করুন

রানবুক ধাপগুলোকে ড্র্যাগ-অ্যান্ড-ড্রপ প্রসেসে রূপান্তর করে পুনরাবৃত্তিমূলক করুন।

ওয়ার্কফ্লো তৈরি করুন

টিকিট ক্লোজ করার আগে একটি সংক্ষিপ্ত fresh-start ড্রিল চালান। হ্যান্ডঅফ প্যাকেজটি একটি ops ইঞ্জিনিয়ারকে দিন এবং একটি ক্লিন পরিবেশ (নতুন VM, নতুন Kubernetes namespace, বা একটি খালি ক্লাউড প্রজেক্ট)। যদি তারা প্যাকেজ ব্যবহার করে নির্দিষ্ট সময়ের মধ্যে (উদাহরণ: 2 ঘন্টা) ডিপ্লয়, পর্যবেক্ষণ ও রিকভারি করতে পারে, আপনি প্রায় শেষ।

এই চেকগুলো ব্যবহার করুন:

কেবল প্যাকেজ করা আর্টিফ্যাক্ট, কনফিগ ডকস ও রানবুক ব্যবহার করে শূন্য থেকে পুনর্নির্মাণ ও ডিপ্লয় করুন (রোলব্যাকসহ)।
নিশ্চিত করুন প্রতিটি সিক্রেট ইচ্ছে অনুযায়ী জায়গায় আছে এবং রোটেশন স্টেপ লেখা ও টেস্ট করা আছে।
ড্যাশবোর্ড খুলে নিশ্চিত করুন তারা মৌলিক প্রশ্নের উত্তর দেয়: এটা আপ আছে, ধীর হচ্ছে, এরর হচ্ছে, বা রিসোর্স শেষ হয়ে যাচ্ছে?
একটি নিরাপদ টেস্ট অ্যালার্ট ট্রিগার করে দেখুন পেজিং রুট, ওনার ও Quiet hours সঠিক আচরণ করে কি না।
একটি আলাদা পরিবেশে বাস্তব রিস্টোর টেস্ট চালান, তারপর সঠিক ধাপ ও প্রত্যাশিত ফল নথিভুক্ত করুন।

আপনি যদি জেনারেটেড সোর্স কোড এক্সপোর্ট করে সেল্ফ-হোস্ট করছেন, নিশ্চিত করুন ops জানে কোথায় বিল্ড ইনপুট, ভার্সন ও রিলিজ ট্যাগ রেকর্ড করা হয় যাতে ভবিষ্যৎ রিলিজগুলো পুনরাবৃত্তিযোগ্য থাকে।

পরবর্তী ধাপ: মালিকানা চূড়ান্ত করুন এবং প্যাকেজ আপ টু ডেট রাখুন

পেজ বহনকারীদের সঙ্গে একটি চূড়ান্ত ওয়াকথ্রু চালান। এটাকে রিহার্সেল হিসেবে বিবেচনা করুন। ডিপ্লয়, রোলব্যাক, রিস্টোর এবং অ্যালার্টিং সব একই প্যাকেজ দিয়ে কাজ করছে কিনা প্রমাণ করুন।

একটি চূড়ান্ত ওয়াকথ্রু সাধারণত কভার করে: একটি টেস্ট পরিবেশে তারপর প্রোডাকশনে একই ধাপগুলো ডিপ্লয় করা; পূর্ববর্তী ভার্সনে রোলব্যাক করা এবং অ্যাপের কাজ করা যাচাই করা; একটি ক্লিন পরিবেশে ব্যাকআপ থেকে রিস্টোর করে সরল যাচাই (লগইন, রেকর্ড তৈরি, মেসেজ পাঠানো) করা; একটি নিরাপদ টেস্ট অ্যালার্ট ট্রিগার করা; এবং ইনসিডেন্টে লগ ও ড্যাশবোর্ড কোথায় পাওয়া যায় তা নিশ্চিত করা।

মালিকানা স্পষ্ট করুন। প্রতিটি রানবুক (ডিপ্লয়, ইনসিডেন্ট, রিস্টোর) এবং প্রতিটি অ্যালার্ট রুটের জন্য (প্রাইমারি অন-কল, ব্যাকআপ, অফ-ঘন্টার আচরণ) একটি নামযুক্ত ওনার নির্ধারণ করুন। যদি কোনো অ্যালার্টের মালিক না থাকে, এটি অবহেলা করা হবে বা ভুল মানুষকে জাগাবে।

একটি সংক্ষিপ্ত Day 2 প্ল্যান লিখে দিন যাতে ops জানে প্রথম সপ্তাহের পরে কী উন্নতি করতে হবে: থ্রেশহোল্ড টিউনিং, খরচ চেক, পুরানো আর্টিফ্যাক্ট ক্লিনআপ, এবং অ্যাক্সেস রিভিউ। এটাকে ছোট ও টাইমবক্সড রাখুন।

আপনি যদি AppMaster (appmaster.io) ব্যবহার করে বানিয়েছেন, এক্সপোর্ট করা সোর্স কোড বা নির্দিষ্ট ডিপ্লয়মেন্ট টার্গেটের বিবরণ (ক্লাউড, রিজিয়ন, বিল্ড সেটিংস, প্রয়োজনীয় সার্ভিস) অন্তর্ভুক্ত করুন যাতে ops মূল প্রজেক্ট ওয়ার্কস্পেসের উপর নির্ভর না করে অ্যাপ পুনরুত্পাদন করতে পারে। পরিবর্তনের সাথে প্যাকেজ আপডেট করার জন্য একটি সহজ কেডেন্স নির্ধারণ করুন যাতে রানবুক বাস্তবতা থেকে বিচ্ছিন্ন না হয়।

প্রশ্নোত্তর

A production-ready handoff means ops can deploy a known version, confirm it’s healthy, respond to alerts, and recover from failures without relying on a specific developer’s memory. If a week without the builders would put uptime at risk, the handoff isn’t finished.

Start with a one-page system inventory that lists every running component and where it lives: API, web app, workers, scheduled jobs, database, storage, and required third-party services. Add the domains, ports, DNS/TLS ownership, and rough expected load so ops can operate without guessing.

Provide a single config reference that lists every config key, its type, and a safe example value, plus what differs between dev/staging/prod. Keep real credentials out of it, and document where config is stored and how it’s applied during deploys so changes are repeatable.

Create a short secrets list that states what each secret is for, where it is stored, who can read it, and who owns rotation. Write rotation steps like a checklist with one clear verification step, and include a break-glass process for emergencies with audit expectations.

Ops needs to know exactly what is running and how to reproduce it: artifact name/tag, version, build date, checksum, and the source reference used to build it. Include the recommended deployment target, the deploy order, expected deploy time, and how database migrations run and are verified.

Define the trigger signals (like failing health checks or elevated error rate), the last known good version, and the exact steps to revert quickly. Call out whether database changes are reversible, and what the safe fallback is if they aren’t, so rollback doesn’t turn into improvisation.

Pick a small set of metrics that reflect user impact: latency, error rate, resource saturation, queue depth, and an external uptime check. Make alerts explicit about severity, who gets paged, and what “normal” looks like, and ensure logs are time-synced and traceable with a correlation ID.

Document what is backed up, where it’s stored, retention, and who can run restores. Include a step-by-step restore procedure with a verification check, and schedule a restore drill; backups only matter if a restore can be performed on demand in a clean environment.

Keep runbooks short and consistent: symptoms, first checks, next checks, decision points, and escalation. Focus on the likely first incidents (outage, slowness, bad deploy), and update the runbook right after incidents while details are fresh so knowledge doesn’t drift.

Write down the roles you actually use (deployer, DB admin, read-only, incident commander), how access is granted and revoked, and what must be logged for auditing. Don’t forget service accounts and tokens; list what they can access and where their identities are configured without including secret values.