হাই-ভলিউম সিস্টেমের নিরাপত্তা ও শিপিং: শক্ত এজ আর জিরো-ডাউনটাইম deploy

চতুর্থ পর্বের checkout অভিযোগের সতেরো মিনিট আগে, একই release-এর সকাল ৯:৪৪-এ, টিকিট-বিক্রির সাইটের অন-কল ইঞ্জিনিয়ারের সামনে অন্য একটা সমস্যা। বিক্রি শুরু ১০:০০টায়, আর প্রায় ১,০০০ ক্রেতা একই মিনিটে কাজ করবেন। একজন developer order email-এর একটা বানান ভুল শুধরে এক লাইনের ফিক্স পাঠাতে চান। ৯:৫২-তে dashboard-এ দেখা যায়, হাতে-গোনা কয়েকটা ঠিকানা থেকে মিনিটে ৪,০০০ login চেষ্টা: কোনো স্ক্যালপার স্ক্রিপ্ট গরম হচ্ছে। (এটা কাল্পনিক দৃশ্য, সত্যিকারের ঘটনা নয়।)

সেদিন সকালটা কেমন কাটবে, তা ঠিক হয় কয়েক সপ্তাহ আগের দুটো সিদ্ধান্তে: ইন্টারনেট system-এর কতটা ছুঁতে পারে, আর deploy করতে সাইট বন্ধ করা লাগে কি না। উত্তর যদি "সবটুকু" আর "হ্যাঁ" হয়, ইঞ্জিনিয়ারকে ফিক্সটা ফিরিয়ে দিয়ে স্ক্রিপ্টটা নিজে থেকে থামার আশায় বসে থাকতে হয়।

এই শেষ লেখায় দুটোই দেখব: ইন্টারনেট থেকে data পর্যন্ত শক্ত করে বাঁধা পথ, আর এমন ডেলিভারি পাইপলাইন যা সাইট কখনো বন্ধ করে না। ভিত্তি আমার নিজের ফিল্ড নোট, যেখানে ফ্ল্যাশ সেল, টিকিট release বা পরীক্ষা শুরুর মতো নির্ধারিত স্পাইকের জন্য platform তৈরি করেছি। এগুলো একটা নির্দিষ্ট সেটআপের অভিজ্ঞতা, সবার জন্য বাঁধা রেসিপি নয়।

এটি "হাই-ভলিউম system-এর ইঞ্জিনিয়ারিং" সিরিজের ৫ম এবং শেষ পর্ব। আগের পর্বগুলো: পর্ব ১, ওয়েব টিয়ার ও autoscaling; পর্ব ২, queue ও worker; পর্ব ৩, data টিয়ার; পর্ব ৪, অবজার্ভেবিলিটি।

নিরাপত্তা মানে ছোট ছোট দেয়ালের সারি

কোনো একটা product একা system নিরাপদ করতে পারে না। firewall ফাঁস হওয়া password ঠেকায় না, আবার শক্ত password-ও কাজে আসে না যদি database ইন্টারনেটের জন্য খোলা থাকে। বাস্তব পথ হলো স্তরে স্তরে নিরাপত্তা: প্রতিটি স্তর ধরে নেয় তার সামনের স্তর কখনো কখনো ব্যর্থ হবে।

এখানে OWASP Top 10 একটা ভালো বাস্তবতা-যাচাই। বর্তমান সংস্করণ OWASP Top 10:2025-এ প্রথম স্থানে Broken Access Control, দ্বিতীয় স্থানে Security Misconfiguration। দুটোই মূলত system কীভাবে জোড়া লাগানো, তা নিয়ে; কোনো অদ্ভুত এক্সপ্লয়েট নিয়ে নয়। আমার অভিজ্ঞতাও তা-ই বলে: বেশিরভাগ ঘটনার পেছনে থাকে খোলা পড়ে থাকা একটা পোর্ট, না-বদলানো ডিফল্ট, কিংবা প্রয়োজনের চেয়ে বড় একটা permission।

এজ: CDN, WAF, বট আর rate limit

পাবলিক যা কিছু আছে, তার সামনে ওয়েব অ্যাপ্লিকেশন firewall (WAF) সহ একটা CDN বসান। এটা বিশাল ফ্লাড শুষে নেয়, ক্যাশ করা পেজ আপনার server-এ না ছুঁয়েই পৌঁছে দেয়, আর বহুল প্রচলিত আক্রমণের ধরন আপনার কোডে পৌঁছানোর আগেই আটকে দেয়। স্পাইকের সময় এটা আপনার ক্ষমতাও বাঁচায়: এজ যে request-এর জবাব দেয়, তা আপনার ওয়েব নোড কখনো দেখেই না।

তিনটি সেটিং বাকিগুলোর চেয়ে বেশি গুরুত্বপূর্ণ:

• বট ম্যানেজমেন্ট। ফ্ল্যাশ সেলে স্ক্যালপার আর স্ক্রিপ্ট আসেই। সন্দেহজনক ক্লায়েন্টকে চ্যালেঞ্জ করুন checkout আর login পাথে, পুরো সাইটে নয়; তাহলে আসল ক্রেতারা ধীর হবেন না।
• এজে rate limit। login, password রিসেট, সার্চ আর checkout-এ প্রতি ক্লায়েন্টের সীমা দিন। সীমাটা ঠিক করুন বাস্তব ট্র্যাফিক দেখে: লোড test-এ আগের কোনো পিকের request মিক্স রিপ্লে করে প্রতি ক্লায়েন্টের সর্বোচ্চ বৈধ রেট দেখে নিন।
• অ্যাপ্লিকেশনেও rate limit। কেউ origin-এর ঠিকানা পেয়ে গেলে এজ এড়িয়ে যেতে পারে। তাই app-এ দ্বিতীয় একটা সীমা রাখুন, প্রতি account আর প্রতি অ্যাকশনে, যাতে একজন user ব্যয়বহুল কোনো endpoint-কে ঠুকে ঠুকে ক্লান্ত করতে না পারে।

Origin-কে এমনভাবে তালাবদ্ধ করুন, যেন সে শুধু এজ network-এর ট্র্যাফিক নেয়। server যদি ইন্টারনেটের যে কাউকে সরাসরি জবাব দেয়, তাহলে WAF একটা পরামর্শ মাত্র, নিয়ন্ত্রণ নয়।

TLS, আর সেটা কোথায় শেষ হয়

ট্রানজিটে সবকিছু এনক্রিপ্ট করুন। ক্লায়েন্ট সাপোর্ট করলে TLS 1.3 ব্যবহার করুন, আর TLS 1.2-কে রাখুন ন্যূনতম সীমা হিসেবে। PCI DSS 4.0 পাবলিক network-এ কার্ডহোল্ডার data-র জন্য শক্তিশালী ক্রিপ্টোগ্রাফি চায় এবং SSL ও পুরনো TLS সংস্করণ বাদ দেয়। তাই কার্ডে payment নিলে TLS 1.0 ও 1.1 বন্ধ করে দিন।

ডিজাইনের আসল প্রশ্ন হলো TLS কোথায় শেষ হচ্ছে। অনেক সেটআপে CDN-এ একবার, হোস্টের reverse proxy-তে আবার, তারপর container-এ সাদামাটা HTTP যায়। শেষ ধাপটা প্রাইভেট হোস্ট network-এ চলতে পারে, তবে শুধু তখনই যখন আপনি নিশ্চিত যে সেটা সত্যিই প্রাইভেট। ট্র্যাফিক যদি আপনার নিয়ন্ত্রণের বাইরের কোনো network পার হয়, সেই ধাপও এনক্রিপ্ট করুন।

আরেকটা ফাঁদ হলো মিলহীন লিমিট। আমার চালানো একটা platform-এ পরপর দুটো nginx স্তর ছিল: একটা হোস্ট প্রক্সি যেখানে TLS শেষ হয়, আরেকটা container-এর প্রক্সি, PHP-FPM-এর সামনে। হোস্টের ডিফল্ট বডি লিমিট ছিল ১ MB, তাই সব স্তর একমত না হওয়া পর্যন্ত আপলোড নিঃশব্দে ফেল করত: দুই প্রক্সিতেই client_max_body_size, আর PHP-তে post_max_size ও upload_max_filesize। এটা নির্ভরযোগ্যতার বাগ, কিন্তু এর ফলে অনেকে না ভেবেই লিমিট বাড়িয়ে দেয়। সর্বোচ্চ সীমা একবার ঠিক করুন, প্রতিটি স্তরে বসান, আর লিখে রাখুন।

প্রাইভেট network: পাবলিক শুধু এজ

সবচেয়ে দামি নিয়মটা একই সঙ্গে সবচেয়ে নিরামিষ: এজ আর load balancer ছাড়া কিছুই পাবলিক নয়। ওয়েব নোড, worker, database, ক্যাশ আর সার্চ নোড থাকবে প্রাইভেট network-এ। ম্যানেজড database ও ক্যাশ শুধু ওই network থেকে connection নেবে, ফলে শুধু একটা ফাঁস হওয়া password দিয়ে আক্রমণকারী ভেতরে ঢুকতে পারবে না।

এর ওপর firewall রুল বসান, যা বলে দেয় কে কার সঙ্গে কথা বলতে পারবে, যেমন:

কম্পোনেন্ট	কে কানেক্ট করতে পারে	পাবলিক?
CDN / WAF	ইন্টারনেট	হ্যাঁ
Load balancer	শুধু এজ network-এর রেঞ্জ	হ্যাঁ, সীমিত
ওয়েব ও SSR নোড	শুধু load balancer	না
worker ও scheduler	বাইরে থেকে কেউ নয়	না
database ও ক্যাশ	ওয়েব নোড ও worker, প্রাইভেট ঠিকানায়	না
SSH ও admin অ্যাক্সেস	jump host বা VPN, শুধু কী দিয়ে	না

টপোলজি বদলালেই এই টেবিল আবার দেখুন। "এক মাস ধরে আমরা খোলা ছিলাম" ধরনের গল্পের বেশিরভাগই শুরু হয় এমন এক তাড়াহুড়োর বদল দিয়ে, যা কেউ লিখে রাখেনি।

শেয়ার্ড alias-এর ঘটনা: হোস্টের ভেতরের আইসোলেশন

network আইসোলেশন শুধু ইন্টারনেটের কথা নয়। একটা হোস্টে দেখেছিলাম পাশাপাশি কয়েকটা প্রজেক্ট একই Docker network ব্যবহার করছে, আর প্রতিটি প্রজেক্ট তার PHP সার্ভিসের নাম দিয়েছে app। প্রক্সি request পাঠাচ্ছিল পোর্ট 9000-এর app-এ, আর নামটা একাধিক container-এ রিজলভ হচ্ছিল। অর্ধেক request পৌঁছে যাচ্ছিল অন্য প্রজেক্টের PHP-FPM-এ।

কিছু ক্র্যাশ করেনি। পেজগুলো শুধু ভুল কোড থেকে আসছিল, ভুল কনফিগারেশনে, কখনো ভুল database-এ। এটা একই সঙ্গে নির্ভরযোগ্যতার সমস্যা আর data ফাঁসের সমস্যা।

সমাধান সহজ। প্রতিটি প্রজেক্টকে আলাদা network দিন, সার্ভিসের নাম রাখুন অনন্য, আর যে সার্ভিসের শুধু অন্য কিছুর কাছে পৌঁছানো দরকার, তাকে কোনো network-এ খুলে দেবেন না। কোনো ডিপ্লয়মেন্ট রিভিউ করার সময় সরাসরি জিজ্ঞেস করুন: এই container কি এমন কিছুতে পৌঁছাতে পারে, যেখানে পৌঁছানোর কোনো কারণ তার নেই?

সিক্রেট, account আর প্যাচিং

তিনটি অভ্যাস ক্ষতির বড় একটা অংশ ঠেকিয়ে দেয়।

• সিক্রেট ইমেজের বাইরে থাকুক। ইমেজ কপি হয়ে যায় রেজিস্ট্রিতে, ল্যাপটপে, বিল্ড ক্যাশে। সিক্রেট দিন রানটাইমে, এনভায়রনমেন্ট বা সিক্রেট স্টোর থেকে, আর কেউ চলে গেলে সেগুলো রোটেট করুন।
• প্রতিটি account-এ least privilege। অ্যাপ্লিকেশনের database user যেন টেবিল ড্রপ করতে বা user বানাতে না পারে। worker, রিপোর্টিং আর মাইগ্রেশন আলাদা account-এ, আলাদা অধিকারে চলতে পারে। স্টাফ পাবে রোল, শেয়ার করা admin login নয়, আর admin অ্যাক্সেসে থাকবে সেকেন্ড ফ্যাক্টর।
• নিয়ম করে প্যাচ করুন। OWASP ২০২৫ তালিকায় Software Supply Chain Failures যোগ করেছে কারণ ছাড়া নয়: আপনি যার ওপর নির্ভর করেন, সেটাও আপনার আক্রমণের পরিধির অংশ। নিয়মিত ইমেজ রিবিল্ড করুন, জানা দুর্বলতার জন্য স্ক্যান করুন, আর সত্যিই যা ব্যবহার করেন সেই ডিপেন্ডেন্সির তালিকা ছোট রাখুন। server ও container-এর সেটিং মিলিয়ে দেখতে পারেন Docker এবং জনপ্রিয় Linux ডিস্ট্রিবিউশনের CIS Benchmarks-এর সঙ্গে।

শেষে ধরে নিন, কিছু একটা ভুল হবেই। এমন backup রাখুন যা একই ক্রেডেনশিয়ালে আক্রমণকারী ছুঁতে পারে না, আর restore অনুশীলন করুন। বিষয়টা আলাদা করে লিখেছি ব্যবসায়িক system-এর জন্য র‍্যানসমওয়্যার-প্রস্তুত backup লেখায়; এখানে শুধু এটুকু যোগ করছি: যে restore কখনো চেষ্টা করেননি, সেটা পরিকল্পনা নয়, ভরসা।

ডাউনটাইম ছাড়া শিপ করা: একবার বিল্ড, একই আর্টিফ্যাক্ট

ভয়ের deploy মানুষকে প্যাচ আর পরিবর্তন এড়াতে শেখায়, তাই লক্ষ্য হওয়া উচিত একঘেয়ে deploy। প্রথম নিয়ম: একবার বিল্ড করুন, আর হুবহু একই আর্টিফ্যাক্ট পাঠান। একটা মেশিনে ইমেজ বানান, পুশ করুন, আর প্রতিটি নোড টানুক ঠিক সেই ইমেজ। ট্র্যাফিক সুইচ করার আগে সব নোডের image ID মিলিয়ে দেখুন। যে নোড ট্র্যাফিক সামলাচ্ছে, সেখানে কখনো সোর্স আপডেট আর বিল্ড চালাবেন না: এক ঘণ্টা ব্যবধানে বানানো দুটো নোড চুপচাপ আলাদা হয়ে যেতে পারে, আর মাঝপথে ফেল করা বিল্ড লাইভ server ভেঙে দিতে পারে।

কনফিগারেশন ইমেজ থেকে আলাদা পথে যায়, ফলে একই আর্টিফ্যাক্ট স্টেজিং থেকে প্রোডাকশনে অপরিবর্তিত পৌঁছায়। এর জন্যই বলা যায়: যেটা test করেছেন, সেটাই release হয়েছে।

সাইট চালু রেখে মাইগ্রেশন: expand and contract

"জিরো ডাউনটাইম" সাধারণত ভাঙে database পরিবর্তনে। rolling deploy-এর সময় পুরনো আর নতুন কোড একই স্কিমার ওপর একসঙ্গে চলে, তাই মাইগ্রেশনকে দুই পক্ষের জন্যই কাজ করতে হবে।

প্রচলিত উত্তর হলো expand and contract প্যাটার্ন, যার আরেক নাম parallel change:

1. Expand। নতুন কলাম বা টেবিল এমনভাবে যোগ করুন যাতে পুরনো কোড তা উপেক্ষা করে, যেমন একটা nullable কলাম।
2. Migrate। এমন কোড deploy করুন যা পুরনো ও নতুন দুই কাঠামোতেই লেখে, আর বিদ্যমান সারিগুলো ব্যাকগ্রাউন্ডে ছোট batch-এ backfill করুন।
3. Switch। রিড নতুন কাঠামোয় সরান আর এরর নজরে রাখুন।
4. Contract। চালু কোনো কোডই যখন পুরনো কাঠামো ব্যবহার করছে না, তখন পরের কোনো release-এ সেটা সরিয়ে ফেলুন।

একটা হিসাব-সহ উদাহরণ (সংখ্যাগুলো কাল্পনিক)। ২৪ লক্ষ সারির customers টেবিলে phone কলামের নাম বদলে contact_phone করতে চান। Expand: nullable কলাম contact_phone যোগ করুন। Migrate: নতুন কোড প্রতিবার সেভে দুটো কলামেই লিখবে, আর একটা ব্যাকগ্রাউন্ড জব ৫,০০০ সারির batch-এ কপি করবে। মানে ৪৮০টা batch, প্রতিটায় প্রায় দুই সেকেন্ড ধরলে মোট প্রায় ১৬ মিনিট, আর একজন user-এর জন্যও টেবিল লক হয় না। রিড সরানোর আগে যাচাই করুন, phone আছে কিন্তু contact_phone ফাঁকা, এমন সারির সংখ্যা শূন্য কি না। তারপরই contract।

ড্রপ হলো একমাত্র অপরিবর্তনীয় ধাপ, তাই সে অপেক্ষা করে। সাইট সার্ভ করা অবস্থায় মাইগ্রেশন চালান, আর ফল যাচাই করুন: আগে-পরে সারির সংখ্যা, আর অর্ধেক-রূপান্তরিত কিছু পড়ে নেই কি না তার পরীক্ষা। উইন্ডোর আগে একটা তাজা database ডাম্প নিন, আর কোডের জন্যও রোলব্যাক রেফারেন্স রাখুন।

Rolling backend, blue/green frontend, worker আর scheduler

ভিন্ন টিয়ারে ভিন্ন কৌশল লাগে। stateless PHP backend-এর জন্য আমি rolling deploy ব্যবহার করি, একবারে একটা নোড:

1. Load balancer-এ একটা নোড ড্রেন করুন, যাতে সে চলমান request শেষ করে কিন্তু নতুন কিছু না পায়।
2. ওই নোডে নতুন ইমেজ deploy করুন এবং PHP worker রিস্টার্ট করুন, যাতে OPcache নতুন কোড তুলে নেয়।
3. নোডের বিরুদ্ধে সরাসরি smoke test চালান: login, একটা product খোলা, কার্টে যোগ করা।
4. নোডটিকে load balancer-এ ফিরিয়ে দিন এবং কয়েক মিনিট soak করতে দিন, এই সময়ে এরর আর latency দেখুন।
5. পরের নোডে একই কাজ করুন।

দুটো নোড থাকলে সাইটের হাতে সবসময় একটা সুস্থ server থাকে। idempotent request-এর জন্য প্রক্সিতে retry রুল সাময়িক ব্যর্থতা user-এর চোখ থেকে আড়াল করতে পারে, কিন্তু কার্ডে চার্জ করা request-এ এটা চালু করবেন না।

server-রেন্ডারড frontend-এর জন্য আমার পছন্দ blue/green। নতুন ভার্সন পুরনোটার পাশে চালু করুন, আলাদাভাবে test করুন, তারপর প্রক্সির একটা ফাইল বদলে graceful reload দিয়ে সুইচ করুন। rollback হলো একই কাজ উল্টো দিকে, প্রায় এক সেকেন্ড। StoreConsole-ও নিজের প্রোডাকশন এভাবেই চালায়।

worker আর scheduler-এর নিজস্ব যত্ন লাগে। worker সুইচ করার আগে queue ড্রেন করুন: নতুন জব নেওয়া বন্ধ করুন, চলমান জবকে শেষ করার জন্য উদার grace period দিন, তারপর নতুন ভার্সন চালু করুন। Scheduler চালু করুন সবার শেষে, ঠিক একটা নোডে, যাতে অর্ধেক-deploy হওয়া system কোনো পুনরাবৃত্ত টাস্ক দুবার বা ভুল কোডে চালিয়ে না ফেলে।

যাচাই, soak আর go-live চেকলিস্ট

কমান্ড ফিরে এলেই deploy শেষ হয় না, প্রমাণ করার পর শেষ হয়। এমন end-to-end পরীক্ষা চালান যাতে একটা সত্যিকারের কেনাকাটা বা সাবমিশন থাকে, queue চলছে কি না দেখুন, তারপর soak করুন: কাজ শেষ বলার আগে নির্দিষ্ট সময় ধরে এরর রেট, p95 latency আর queue-য়ের বয়স দেখতে থাকুন। এই সিরিজের ৪র্থ পর্বের dashboard ব্যবহার করুন, আর ভয়ধরানো কোনো alert-এ ব্যবস্থা নেওয়ার আগে আসল প্রসেসের সঙ্গে মিলিয়ে নিন।

হাই-ভলিউম event-এর আগে আমি এই চেকলিস্ট মেনে চলি:

1. লক্ষ্য রেটে abort threshold সহ লোড test চালান, আর ফল সংরক্ষণ করুন।
2. event-এর আগেই ওয়েব ও frontend-এর ক্ষমতা pre-scale করুন; reactive scaling-য়ের অপেক্ষায় থাকবেন না।
3. নিশ্চিত করুন origin শুধু এজ থেকে ট্র্যাফিক নেয়, আর login ও checkout-এ WAF, বট ও rate-limit রুল চালু আছে।
4. নিশ্চিত করুন database, ক্যাশ ও সার্চ নোডের কোনো পাবলিক ঠিকানা নেই।
5. TLS সেটিং ও সার্টিফিকেটের মেয়াদ দেখুন, আর প্রতিটি স্তরে আপলোড লিমিট মিলছে কি না যাচাই করুন।
6. তাজা database ডাম্প নিন, restore করে দেখুন, আর রোলব্যাক রেফারেন্স টুকে রাখুন।
7. জরুরি ফিক্স ছাড়া সব পরিবর্তন ফ্রিজ করুন, আর কে অনুমোদন দিতে পারবে তা ঠিক করে রাখুন।
8. alert এমন একজনের কাছে পৌঁছায় কি না নিশ্চিত করুন যিনি জেগে আছেন, সঙ্গে লিখিত এসকেলেশন পথ।
9. রোলব্যাকের ড্রাই রান করুন, এক-রিলোডের frontend সুইচসহ।
10. দেখুন scheduler ঠিক একটা নোডে চলছে আর queue থেকে পুরনো জব সরানো হয়েছে।

আবার ৯:৪৪-এ ফিরি। এই ব্যবস্থা থাকলে ইঞ্জিনিয়ার বানান-ফিক্সে হ্যাঁ বলতে পারেন। ইমেজ এক ঘণ্টা আগেই বানানো আর test করা, নোডগুলো একটা একটা করে রোল হয়, আর মিনিটে ৪,০০০ login চেষ্টা আটকায় শুধু login পাথের চ্যালেঞ্জে; ক্রেতারা নির্বিঘ্নে ব্রাউজ করেন। database-এর কোনো পাবলিক ঠিকানা নেই, তাই এজের পেছনে স্ক্রিপ্টের খুঁজে পাওয়ার মতো কিছুই নেই। ফিক্স লাইভ হয় আর soak শেষ হয় ৯:৫৫-র মধ্যে, বিক্রি শুরুর পাঁচ মিনিট আগে।

নিচের টেবিলে দেখুন প্রতিটি স্তর কীভাবে ভাঙে আর কীভাবে দ্রুত যাচাই করবেন।

স্তর	সাধারণ ব্যর্থতা	দ্রুত যাচাই
এজ	Origin সরাসরি পাওয়া যায়	এজ network-এর বাইরে থেকে origin-এর ঠিকানায় request পাঠান
network	database ইন্টারনেটে খোলা	বাইরের একটা হোস্ট থেকে পোর্ট স্ক্যান
হোস্ট	শেয়ার্ড সার্ভিস alias	প্রতিটি নাম কোন কোন container-এ রিজলভ হয়, তার তালিকা
সিক্রেট	ইমেজে ঢুকে যাওয়া ক্রেডেনশিয়াল	ইমেজের লেয়ার আর রিপোজিটরির হিস্ট্রিতে খুঁজুন
Deploy	নোডে নোডে আলাদা বিল্ড	প্রতিটি নোডের image ID মেলান
database	লোডের মধ্যে ধ্বংসাত্মক মাইগ্রেশন	expand and contract দেখে রিভিউ; কপির ওপর রিহার্সাল

মূল শিক্ষা

• প্রতিরক্ষা স্তরে স্তরে সাজান: CDN ও WAF, তালাবদ্ধ origin, প্রাইভেট network, least-privilege account আর ইমেজের বাইরে সিক্রেট।
• পাবলিক রাখুন শুধু এজ আর load balancer, আর টপোলজি বদলালেই অনুমোদিত পথগুলো আবার দেখুন।
• একই হোস্টের প্রজেক্টগুলোকে আলাদা network ও অনন্য সার্ভিসের নামে আইসোলেট করুন, যাতে শেয়ার্ড alias কখনো ট্র্যাফিক ভুল কোডে না পাঠায়।
• একবার বিল্ড করুন, হুবহু একই আর্টিফ্যাক্ট পাঠান আর image ID মেলান; সার্ভিং নোডে কখনো বিল্ড করবেন না।
• database বদলান ছোট ছোট ধাপে, expand and contract দিয়ে, যাতে deploy-এর পুরো সময় পুরনো ও নতুন কোড দুটোই চলে।
• backend একবারে একটা নোড করে রোল করুন, frontend blue/green-এ সুইচ করুন, worker ড্রেন করুন, scheduler চালান সবশেষে, আর শেষ করুন soak ও রিহার্সাল-করা rollback দিয়ে।

আনিছুর রহমান একজন সফটওয়্যার আর্কিটেক্ট এবং StoreConsole-এর নির্মাতা। বাড়তে থাকা ব্যবসার জন্য তিনি কমার্স ও ERP সিস্টেম ডিজাইন করেন — বিশেষ মনোযোগ event-driven আর্কিটেকচার, ডেটার নির্ভুলতা আর নিজের সার্ভারে চালানো সিস্টেমের ওপর।