Software production-এ গেলেই maintenance-free হয় না।

Browser বদলায়। Dependency fix প্রকাশ করে। Provider API deprecate করে। Certificate expire হয়। Content inaccurate হয়। Traffic pattern বদলায়। দশ customer-এর জন্য সহজ workflow এক হাজার customer-এর জন্য painful হতে পারে।

“ভাঙলে fix করব” maintenance plan নয়। এটি unpriced incident strategy।

Useful plan client এবং technical team-কে জানায়—কী দেখা হবে, response কার ownership-এ, কোন routine work included এবং নতুন product work কীভাবে system-এ আসবে।

Service inventory দিয়ে শুরু

যা record-ই করা হয়নি, তা reliably maintain করা যায় না।

Inventory-তে থাকা উচিত:

• production application ও domain;
• hosting ও deployment service;
• database ও object storage;
• email, payment, authentication, analytics এবং অন্য provider;
• scheduled job ও queue;
• source ও artifact ownership;
• DNS, certificate এবং renewal behavior;
• environment variable ও secret owner;
• monitoring ও alert destination;
• backup location ও retention।

Inventory-তে secret value রাখবেন না। কোথায় manage হয় এবং কে rotate করতে পারেন তা লিখুন।

Incident-এর সময় “কোন account এটি control করে?”—এই প্রশ্নের delay সরানোই লক্ষ্য।

“Healthy” বলতে কী বোঝায়

শুধু uptime number অসম্পূর্ণ।

Server successful response দিতে পারে, কিন্তু checkout, signup, email বা data processing broken থাকতে পারে।

Health-এ product-এর important path reflect করা দরকার। System অনুযায়ী থাকতে পারে:

• application availability;
• error rate ও latency;
• successful authentication;
• payment বা order completion;
• queue age ও failed job;
• webhook delivery;
• database capacity;
• certificate expiry;
• backup completion;
• critical journey-এর synthetic check।

প্রতিটি signal-এর threshold, destination এবং owner দরকার। কেউ receive করে না এমন alert শুধু log।

Incident-এর আগেই incident path

Plan-এ উত্তর থাকা দরকার:

1. প্রথম alert কে পাবেন?
2. Severity কীভাবে ঠিক হবে?
3. Production কে change করতে পারবেন?
4. কখন rollback prefer করা হবে?
5. Stakeholder-এর সঙ্গে কে communicate করবেন?
6. Incident timeline কোথায় record হবে?
7. কখন follow-up review লাগবে?

Small product-এ একজন একাধিক role নিতে পারেন। Role তবু explicit হওয়া দরকার।

Useful incident update জানায় কী affected, কখন শুরু, user কী করবেন, team কী করছে এবং next update কখন। Speculation-কে fact হিসেবে দেওয়া উচিত নয়।

Backup-কে testable করুন

“Backup enabled” এবং recoverability এক নয়।

Maintenance plan define করবে:

• কোন data backup হয়;
• কত ঘনঘন;
• কতদিন রাখা হয়;
• encrypted কি না;
• কার access আছে;
• expected recovery time;
• acceptable data-loss window;
• restore test কীভাবে;
• last successful restore test কবে।

Restore process document করা দরকার। কখনও restore না করা backup একটি assumption।

Dependency ও platform update plan

Update-এর prioritization দরকার—blind automation বা indefinite delay নয়।

আমি সাধারণত ভাগ করি:

• urgent security fix;
• provider বা platform deprecation;
• runtime ও framework compatibility;
• routine patch update;
• planned product work দরকার এমন major upgrade।

Update-এর আগে release note, compatibility, test, migration, rollback এবং production risk দেখুন।

Major framework upgrade ছোট bug-fix ticket-এর মধ্যে quietly ঢোকা উচিত নয়।

Security operation অন্তর্ভুক্ত করুন

Launch review-এ security শেষ হয় না।

Ongoing work হতে পারে:

• dependency ও platform advisory;
• access review;
• credential ও key rotation;
• log review ও alert tuning;
• suspicious request investigation;
• domain ও certificate monitoring;
• data retention ও deletion;
• provider permission review;
• vulnerability intake ও response।

Emergency change কে authorize করতে পারেন এবং private data expose না করে evidence কীভাবে রাখা হবে, তাও plan-এ থাকা দরকার।

Maintenance এবং product development আলাদা

এই distinction recurring conflict কমায়।

Maintenance হতে পারে:

• regression fix;
• failed service restore;
• supported security patch;
• routine monitoring review;
• small compatibility work;
• backup verification।

Product work হতে পারে:

• new workflow;
• new integration;
• changed business rule;
• redesign;
• major data migration;
• new reporting capability।

Contract-এ boundary, response expectation এবং out-of-scope estimate process স্পষ্ট থাকা উচিত। নইলে প্রতিটি request “support” শব্দ নিয়ে argument হয়।

Controlled change process রাখুন

Small system-ও lightweight release record থেকে benefit পায়:

• request বা reason;
• owner ও approver;
• affected area;
• risk level;
• test evidence;
• data বা configuration change;
• deployment time;
• rollback path;
• verification result।

Original developer unavailable হলেও এতে continuity থাকে এবং repeated failure diagnose সহজ হয়।

Release-এর technical question-এর জন্য আমার production code-review checklist দেখুন।

Performance ও cost review

Gradual degradation ধরারও সঠিক সময় maintenance।

Review করুন:

• Core Web Vitals ও important route performance;
• server response time;
• database query pattern;
• queue throughput;
• storage growth;
• provider usage;
• hosting cost;
• unused resource;
• cache behavior;
• traffic ও error trend।

একটি isolated score থেকে optimize করবেন না। Representative route, available real-user evidence এবং defined performance budget ব্যবহার করুন।

Content ও SEO hygiene schedule

Public website-এর technical maintenance-এ থাকা উচিত:

• broken internal link;
• incorrect redirect;
• sitemap generation;
• canonical ও language alternate;
• indexation change;
• outdated claim ও biography;
• structured-data validity;
• missing বা duplicate metadata;
• intent আর satisfy করে না এমন page।

আরও page publish সবসময় answer নয়। Unhelpful content update, consolidate বা remove করা ভালো decision হতে পারে।

Practical cadence

Risk, traffic ও contract অনুযায়ী cadence বদলাবে। একটি plan-এ থাকতে পারে:

• critical failure-এর continuous alert;
• error, failed job ও provider notice-এর weekly review;
• access, backup, cost ও performance-এর monthly check;
• quarterly restore test ও roadmap review;
• provider বা framework support deadline-এর আগে scheduled review।

প্রতিটি item-এর owner এবং completion evidence দরকার।

Handover question

Handover-এর সময় আমি জিজ্ঞেস করি:

অন্য authorized person কি system বুঝতে, serious failure চিনতে, সঠিক account-এ পৌঁছাতে এবং প্রথম safe recovery step নিতে পারবেন?

না পারলে project এখনো undocumented memory-এর ওপর নির্ভর করছে।

Maintenance plan সেই memory-কে software-এর operating system-এ রূপ দেয়।

Existing application-এর maintenance plan দরকার হলে main service, critical user path এবং current support arrangement পাঠান।