বিষয় 3.6 — DevOps ও প্রকৌশল উৎকর্ষ

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

স্বাস্থ্য ও পরিচর্যায় কেন এটি গুরুত্বপূর্ণ#

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

নিয়ন্ত্রিত ক্ষেত্রে একটি স্থায়ী ও বিপজ্জনক কল্পকথা আছে যে পরিবর্তনই ঝুঁকি, তাই সবচেয়ে নিরাপদ সিস্টেম হলো যাকে আপনি সবচেয়ে কম স্পর্শ করেন। প্রমাণ উল্টো দিকে ইঙ্গিত করে। যে সিস্টেম কদাচিৎ বদলানো হয় তা অপ্যাচড দুর্বলতা, ভঙ্গুর ম্যানুয়াল মোতায়েন ধাপ এবং নথিহীন গোষ্ঠী-জ্ঞান জমায়; যখন পরিবর্তন শেষ পর্যন্ত অনিবার্য হয়, একটি নিরাপত্তা প্যাচ, একটি নিয়ন্ত্রক সময়সীমা, একজন সরবরাহকারীর প্রত্যাহার, তা একটি বড়, ঝুঁকিপূর্ণ, খারাপভাবে বোঝা "বিগ ব্যাং" হিসেবে আসে। যে প্রতিষ্ঠানগুলো স্বয়ংক্রিয়তা ও দ্রুত ফেরানোসহ ঘন ঘন ছোট পরিবর্তন মোতায়েন করে তারা কম ব্যর্থতা অনুভব করে এবং দ্রুততর পুনরুদ্ধার করে। স্বাস্থ্য ও পরিচর্যায় সেই পার্থক্য রোগীর নিরাপত্তায় মাপা হয়।

প্রকৌশল উৎকর্ষ একটি ন্যায্যতা ও জনগণের-আস্থার বিষয়ও। যে সফটওয়্যার পর্যবেক্ষণযোগ্য নয় তা লুকিয়ে রাখে যে একটি সেবা পুরোনো ডিভাইসের বা দুর্বল সংযোগের এলাকার ব্যবহারকারীদের জন্য খারাপ কাজ করে। একটি অনিরাপদ সফটওয়্যার সরবরাহ শৃঙ্খল গোপনীয় রোগীর তথ্যকে ঝুঁকিতে ফেলে (বিষয় 1.7 — তথ্য গভর্ন্যান্স, ডেটা সুরক্ষা ও সাইবার নিরাপত্তা দেখুন)। আর যেহেতু এটি জনগণের অর্থ ও জনগণের ডেটা, খাতটি ক্রমেই প্রত্যাশা করে কোড উন্মুক্ত, পরিদর্শনযোগ্য মানে গড়া হবে, কখনো আক্ষরিকভাবে প্রকাশ্যে। তাই আপনি কীভাবে কাজ করেন তা একটি ব্যক্তিগত প্রকৌশল বিষয় নয়; তা রোগী, চিকিৎসক ও জনগণের কাছে জবাবদিহিকারী।

মূল ধারণা#

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

অবিরাম একীকরণ ও অবিরাম সরবরাহ (CI/CD)। অবিরাম একীকরণ (CI) মানে প্রতিটি ডেভেলপার ঘন ঘন একটি ভাগ করা মূল ব্রাঞ্চে ছোট পরিবর্তন মার্জ করেন, প্রতিটি একটি স্বয়ংক্রিয় নির্মাণ ও পরীক্ষা চালায় যাতে সমস্যা মিনিটের মধ্যে ভেসে ওঠে। অবিরাম সরবরাহ (CD) এটি প্রসারিত করে যাতে সফটওয়্যার সর্বদা রিলিজযোগ্য অবস্থায় থাকে এবং একটি স্বয়ংক্রিয়, পুনরাবৃত্তিযোগ্য পাইপলাইনের মাধ্যমে প্রোডাকশনে মোতায়েন করা যায়। অবিরাম মোতায়েন এক ধাপ এগিয়ে পাইপলাইন পাস করা প্রতিটি পরিবর্তন স্বয়ংক্রিয়ভাবে রিলিজ করে। পরীক্ষা হলো পাইপলাইনের গেটের সারবস্তু, যা বিষয় 3.7 — পরীক্ষা ও গুণমান নিশ্চয়তায় গভীরভাবে আলোচিত।

ট্রাঙ্ক-ভিত্তিক ডেভেলপমেন্ট এবং ছোট, ফেরানো-যায় রিলিজ। ট্রাঙ্ক-ভিত্তিক ডেভেলপমেন্ট সবাইকে সংস্করণ নিয়ন্ত্রণ-এ একটি একক মূল রেখার কাছাকাছি কাজ করতে রাখে, বিচ্যুত হয়ে যন্ত্রণাদায়কভাবে মার্জ হওয়া দীর্ঘস্থায়ী ব্রাঞ্চ লালন না করে দিনে বহুবার একীকরণ করে। জোড়া শৃঙ্খলা হলো ছোট, ঘন ঘন, স্বাধীনভাবে ফেরানো-যায় পরিবর্তন পাঠানো। একটি ছোট পরিবর্তন পর্যালোচনা করা সহজ, পরীক্ষা করা সহজ, এবং, নির্ণায়কভাবে একটি ক্লিনিক্যাল সিস্টেমে, কিছু ভুল হলে পরিষ্কারভাবে ফেরানো সহজ।

অবকাঠামো-কোড হিসেবে (IaC)। হাতে সার্ভার কনফিগার করার বদলে, আপনি সংস্করণ নিয়ন্ত্রণে রাখা মেশিন-পাঠযোগ্য ফাইলে অবকাঠামো সংজ্ঞায়িত করেন। পরিবেশ পুনরুৎপাদনযোগ্য, পর্যালোচনাযোগ্য ও নিরীক্ষাযোগ্য হয়: আপনি অভিন্নভাবে তা পুনর্নির্মাণ করতে পারেন, কে কী ও কেন বদলেছেন দেখতে পারেন, এবং প্রমাণ করতে পারেন পরীক্ষা ও প্রোডাকশন মেলে। এটি নির্ভরযোগ্য পরিবেশের ভিত্তি (বিষয় 4.0 — প্রযুক্তিগত আর্কিটেকচার, ক্লাউড ও লিগ্যাসি দেখুন)।

প্ল্যাটফর্ম প্রকৌশল ও ডেভেলপার অভিজ্ঞতা। প্ল্যাটফর্ম প্রকৌশল সেই অভ্যন্তরীণ হাতিয়ার, পাইপলাইন ও পরিবেশ যার ওপর ডেলিভারি দলগুলো নির্ভর করে তাদের একটি প্রোডাক্ট হিসেবে দেখে, দলগুলো তার ব্যবহারকারী। একটি ভালোভাবে গড়া অভ্যন্তরীণ প্ল্যাটফর্ম দলগুলোকে একটি "পাকা রাস্তা" দেয়, নিরাপদ ডিফল্ট, পূর্ব-অনুমোদিত ধরন, এক-ক্লিক মোতায়েন, যাতে তারা প্রত্যেকে সম্মতি নতুন করে উদ্ভাবন না করে দ্রুত এবং নিরাপদে চলতে পারে। ভালো ডেভেলপার অভিজ্ঞতা বিলাসিতা নয়; এটি নিরাপদ পথকে সহজ পথ করার উপায়।

DORA মেট্রিক। DevOps Research and Assessment (DORA) চারটি পরিমাপ চিহ্নিত করেছে যা উচ্চ-কর্মক্ষম দলগুলোকে আলাদা করে: মোতায়েন ঘনত্ব (কত ঘন ঘন আপনি রিলিজ করেন), পরিবর্তনের লিড টাইম (কমিট থেকে প্রোডাকশন পর্যন্ত কত সময়), পরিবর্তন-ব্যর্থতার হার (পরিবর্তনের কত অংশ সমস্যা ঘটায়), এবং সেবা পুনরুদ্ধারের সময় (আপনি কত দ্রুত সেরে ওঠেন)। একত্রে তারা প্রকাশ করে গতি ও স্থিতিশীলতা একসঙ্গে বাড়ে: যে দলগুলো সবচেয়ে ঘন ঘন মোতায়েন করে তারা সবচেয়ে কম ব্যর্থ হয় এবং সবচেয়ে দ্রুত সেরে ওঠে।

"আপনি গড়লে আপনিই চালান," SRE ও পর্যবেক্ষণযোগ্যতা। Amazon-এ জনপ্রিয় হওয়া "আপনি গড়লে আপনিই চালান" মানে যে দল একটি সেবা লেখে সে তা পরিচালনাও করে, পেজার বহন করে, এবং তার ব্যর্থতা অনুভব করে, প্রকৌশল পছন্দ ও পরিচালনগত বাস্তবতার মধ্যে ফিডব্যাক লুপ বন্ধ করে (বিষয় 3.8 — সেবা ব্যবস্থাপনা ও লাইভ অপারেশন্স দেখুন)। সাইট নির্ভরযোগ্যতা প্রকৌশল (SRE) একটি নির্দিষ্ট বাস্তবায়ন যা পরিচালনায় প্রকৌশল প্রয়োগ করে, স্পষ্ট নির্ভরযোগ্যতা লক্ষ্য ও ত্রুটি বাজেটসহ। পর্যবেক্ষণযোগ্যতা, একটি সিস্টেমের আউটপুট (মেট্রিক, লগ, ট্রেস) থেকে তার অভ্যন্তরীণ অবস্থা বোঝার সামর্থ্য, হলো সেই জিনিস যা আপনাকে রোগী ও চিকিৎসকদের আগেই সমস্যা শনাক্ত ও নির্ণয় করতে দেয়।

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

প্রকাশ্যে কোডিং এবং ওপেন-সোর্স সফটওয়্যার। যুক্তরাজ্য সরকারের নীতি, GDS Service Standard ও NHS Service Standard-এ প্রকাশিত, দলগুলোকে নতুন সোর্স কোড ডিফল্টে উন্মুক্ত করতে এবং উন্মুক্ত মান ব্যবহার করতে বলে। জনগণের অর্থায়িত স্বাস্থ্য সফটওয়্যারের জন্য এটি যাচাই, পুনর্ব্যবহার ও আস্থা উন্নত করে, যদি রোগীর ডেটা ও প্রকৃত গোপন বিষয় কঠোরভাবে প্রকাশ্য রিপোজিটরির বাইরে রাখা হয়।

শ্রেষ্ঠ চর্চা#

1. সেবা গড়ার আগে একটি CI/CD পাইপলাইন গড়ুন। প্রথম সপ্তাহ থেকে স্বয়ংক্রিয় নির্মাণ, পরীক্ষা ও মোতায়েন স্থাপন করুন, যাতে প্রতিটি পরিবর্তন প্রোডাকশনে একই পুনরাবৃত্তিযোগ্য, নিরীক্ষাযোগ্য পথ দিয়ে প্রবাহিত হয়। পাইপলাইন হলো সেই জায়গা যেখানে আপনার ক্লিনিক্যাল-নিরাপত্তা, নিরাপত্তা ও অ্যাক্সেসিবিলিটি গেট স্বয়ংক্রিয় যাচাই হিসেবে বাস করে, ঠিক কী কখন মোতায়েন হয়েছিল তার একটি নথিবদ্ধ, ছেঁড়াছিঁড়ি-প্রমাণ রেকর্ড দিয়ে। একটি নিয়ন্ত্রিত সিস্টেমে এই নিরীক্ষা-পথ ওভারহেড নয়: এটি আপনার ক্লিনিক্যাল নিরাপত্তা কেসের প্রমাণ (বিষয় 1.6 — ক্লিনিক্যাল নিরাপত্তা ও ঝুঁকি ব্যবস্থাপনা দেখুন)।

2. ছোট, ঘন ঘন, ফেরানো-যায় পরিবর্তন মোতায়েন করুন। মাঝে মাঝে বড় রিলিজের চেয়ে অনেক ছোট রিলিজ পছন্দ করুন, এবং প্রতিটি পরিবর্তন এমনভাবে নকশা করুন যাতে তা দ্রুত ফেরানো বা নিষ্ক্রিয় করা যায়। একটি ব্যর্থ ক্ষুদ্র পরিবর্তন বোঝা ও ফেরানো সহজ; একটি ব্যর্থ ত্রৈমাসিক মেগা-রিলিজ একশো সন্দেহভাজনসহ একটি ক্লিনিক্যাল ঘটনা। ফিচার ফ্ল্যাগ, ক্যানারি রিলিজ ও ব্লু-গ্রিন মোতায়েনের মতো কৌশল আপনাকে পরিবর্তন ধীরে ধীরে উন্মুক্ত করতে এবং তৎক্ষণাৎ টেনে নিতে দেয়, মোতায়েনকে একটি ভয়ের ঘটনা থেকে একটি রুটিন, কম-নাটকীয় কাজে পরিণত করে।

3. দ্রুত, পরিষ্কার ফেরানোকে প্রথম শ্রেণির নিরাপত্তা নিয়ন্ত্রণ করুন। ফেরানো এমনভাবে মহড়া দিন যেমন আপনি অগ্নি-মহড়া দেন, এবং তা আসলে কত সময় নেয় পরিমাপ করুন। একটি ক্লিনিক্যাল সিস্টেমে একক সবচেয়ে মূল্যবান পরিচালনগত সামর্থ্য হলো একটি পরিবর্তন ক্ষতি করলে মিনিটের মধ্যে একটি জানা-ভালো অবস্থায় ফিরে যেতে পারা। কখনো পরীক্ষা না করা ফেরানো একটি আশা, নিয়ন্ত্রণ নয়; তা কাজ করে প্রমাণ করুন এবং প্রমাণ করে যান।

4. অবকাঠামো ও কনফিগারেশনকে কোড হিসেবে দেখুন। পরিবেশ, নেটওয়ার্কিং ও কনফিগারেশন ঘোষণামূলকভাবে, সংস্করণ নিয়ন্ত্রণের অধীনে সংজ্ঞায়িত করুন এবং স্বয়ংক্রিয়ভাবে প্রোভিশন করুন। এটি আপনাকে পুনরুৎপাদনযোগ্য পরিবেশ, সহকর্মী-পর্যালোচিত পরিবর্তন, এবং ব্যর্থতা বা দুর্যোগের পরে পুনর্নির্মাণের সামর্থ্য দেয় (বিষয় 3.9 — ব্যবসায়িক ধারাবাহিকতা ও দুর্যোগ পুনরুদ্ধার দেখুন)। ম্যানুয়াল, হাতে-সুরে-বাঁধা "স্নোফ্লেক" সার্ভার অপুনরাবৃত্তিযোগ্য, নথিহীন, এবং "পরীক্ষায় কাজ করেছিল কিন্তু প্রোডাকশনে নয়"-র সাধারণ কারণ।

5. ব্যক্তিদের র‍্যাঙ্ক করতে নয়, সৎ আলাপের জন্য DORA মেট্রিক ব্যবহার করুন। মোতায়েন ঘনত্ব, লিড টাইম, পরিবর্তন-ব্যর্থতার হার ও পুনরুদ্ধারের সময় একটি সিস্টেম-স্তরের স্বাস্থ্য সংকেত হিসেবে ট্র্যাক করুন, এবং দ্রুততর-ও-নিরাপদতরের দিকে একসঙ্গে নড়তে দেখুন। এগুলোকে ব্যক্তিগত বা দলগত ক্রম-তালিকায় পরিণত করা প্রতিরোধ করুন: DORA-র নিজস্ব লেখকরা এর বিরুদ্ধে সতর্ক করেন, কারণ এটি কারসাজি ও লুকানো ঝুঁকি চালায়। সঠিক ব্যবহার নির্ণয়মূলক: একটি ক্রমবর্ধমান পরিবর্তন-ব্যর্থতার হার আপনাকে পরীক্ষা কভারেজ বা ব্যাচ আকার সম্পর্কে এমন কিছু বলছে যা একটি বোর্ডের শুনতে চাওয়া উচিত।

6. পর্যবেক্ষণযোগ্যতা-সমর্থিত "আপনি গড়লে আপনিই চালান" গ্রহণ করুন। ডেলিভারি দলগুলোকে প্রোডাকশনে তাদের সেবার প্রকৃত মালিকানা দিন, অন-কল দায়িত্বসহ, যাতে নকশা পছন্দ করা মানুষরা পরিচালনগত পরিণামের সঙ্গে বাস করেন। এটিকে পর্যবেক্ষণযোগ্যতা, মেট্রিক, কাঠামোবদ্ধ লগ ও ট্রেস, এবং ব্যবহারকারীর প্রভাবের সঙ্গে যুক্ত অর্থবহ সতর্কতা দিয়ে ভিত্তি দিন, যাতে দলগুলো চিকিৎসকরা রিপোর্ট করার আগে সমস্যা খুঁজে পায়। এটি সেই ফিডব্যাক লুপ বন্ধ করে যা সময়ের সঙ্গে প্রকৌশল পছন্দ ভালো করে এবং সরাসরি সেবা ব্যবস্থাপনার সঙ্গে যুক্ত (বিষয় 3.8)।

7. সফটওয়্যার সরবরাহ শৃঙ্খল অবিরাম সুরক্ষিত করুন। নির্ভরতার একটি তালিকা রাখুন, পরিচিত দুর্বলতার জন্য স্বয়ংক্রিয়ভাবে স্ক্যান করুন, সংস্করণ পিন ও যাচাই করুন, এবং একটি সফটওয়্যার বিল অব ম্যাটেরিয়ালস রাখুন যাতে পরবর্তী ব্যাপকভাবে প্রচারিত ত্রুটির কয়েক ঘণ্টার মধ্যে আপনি "আমরা কি প্রভাবিত?" উত্তর দিতে পারেন। কে এবং কী প্রোডাকশনে পাঠাতে পারে তা সীমিত করুন, এবং গোপন বিষয় ও ক্রেডেনশিয়াল কঠোরভাবে রক্ষা করুন (বিষয় 4.2 — পরিচয় ও প্রবেশাধিকার ব্যবস্থাপনা দেখুন)। স্বাস্থ্য ও পরিচর্যায় একটি আপসকৃত নির্ভরতা গোপনীয় রোগীর ডেটার পথ, তাই সরবরাহ-শৃঙ্খল স্বাস্থ্যবিধি রোগী-নিরাপত্তা ও তথ্য-গভর্ন্যান্সের কাজ।

8. প্রকৌশল মান নির্ধারণ ও প্রয়োগ করুন, এবং টেকনিক্যাল ঋণ সুচিন্তিতভাবে পরিচালনা করুন। কোডিং মান, স্বয়ংক্রিয় লিন্টিং, কোড পর্যালোচনা এবং একটি স্পষ্ট "সম্পন্নের সংজ্ঞা"-য় সম্মত হন, যাতে গুণমান পরে পরিদর্শন করে আনার বদলে ভেতরে গড়া হয়। টেকনিক্যাল ঋণ স্পষ্টভাবে ট্র্যাক করুন এবং পরিকল্পিত কাজ হিসেবে শোধ করুন, কারণ একটি ক্লিনিক্যাল সিস্টেমে অপরিচালিত ঋণ নীরবে প্রতিটি ভবিষ্যৎ পরিবর্তনের খরচ ও ঝুঁকি বাড়ায়। মান কোডকে পরবর্তী প্রকৌশলীর কাছে পাঠযোগ্য করে, এবং নিরীক্ষক, নিরাপত্তা অফিসার ও ওপেন-সোর্স পর্যালোচকদের কাছেও যাঁদের তা পড়তে হতে পারে।

9. যেখানে নিরাপদে পারেন সেখানে প্রকাশ্যে কোড করুন। নতুন সোর্স কোড ডিফল্টে উন্মুক্ত করা এবং উন্মুক্ত মান পুনর্ব্যবহার করার GDS ও NHS প্রত্যাশা অনুসরণ করুন, শৃঙ্খলাবদ্ধ গোপন বিষয় ব্যবস্থাপনার মাধ্যমে রোগীর ডেটা ও গোপন বিষয় কঠোরভাবে সর্বজনীন রিপোজিটরির বাইরে রেখে। উন্মুক্ত কোড এমন যাচাই আমন্ত্রণ জানায় যা গুণমান ও নিরাপত্তা উন্নত করে, নগদ-টানাটানির ব্যবস্থা জুড়ে পুনর্ব্যবহার সক্ষম করে, এবং জনগণের অর্থ ব্যয় করা সফটওয়্যার যা দাবি করে তা করছে এই বিষয়ে জনগণের আস্থা গড়ে। যেখানে কোড সত্যিই উন্মুক্ত করা যায় না (যেমন কিছু নিরাপত্তা-সংবেদনশীল উপাদান), অভ্যাসবশত বন্ধ ডিফল্ট না করে কারণ নথিবদ্ধ করুন।

দলের সঙ্গে আলোচনার প্রশ্ন#

1. আমরা কি আসলে বিশ্বাস করি আমাদের ক্লিনিক্যাল সিস্টেম আরও ঘন ঘন বদলালে তা নিরাপদতর হয়, এবং আমাদের আচরণ কি সেই বিশ্বাসের সঙ্গে মেলে? এই প্রশ্ন একটি দলকে প্রমাণ ও সহজাত বোধের ফাঁকের মুখোমুখি হতে বাধ্য করে। DORA গবেষণা স্পষ্ট যে যে দলগুলো ঘন ঘন ছোট পরিবর্তন মোতায়েন করে তাদের ব্যর্থতার হার কম এবং তারা দ্রুততর পুনরুদ্ধার করে, তবু অনেক স্বাস্থ্য প্রতিষ্ঠান এখনো নিরাপত্তার নামে পরিবর্তন বিরল, ভারীভাবে গেটযুক্ত রিলিজে ব্যাচ করে, অনিচ্ছাকৃতভাবে প্রতিটিকে বড় ও ঝুঁকিপূর্ণ করে। বিতর্ক করুন আপনার পরিবর্তন-উপদেষ্টা প্রক্রিয়া কোথায় সত্যিই ঝুঁকি কমায় আর কোথায় কেবল বিলম্ব যোগ করে যা দলগুলোকে বিগ-ব্যাং রিলিজের দিকে ঠেলে। আপনার শেষ কয়েকটি ঘটনা সৎভাবে দেখুন: সেগুলো কি ঘন ঘন ছোট পরিবর্তন থেকে ঘটেছিল, নাকি বিরল বড় পরিবর্তন ও অপ্যাচড অবহেলা থেকে? বিবেচনা করুন আপনার ফেরানোর সামর্থ্য বাস্তব ও মহড়া-দেওয়া কি না, কারণ ঘন ঘন পরিবর্তনের যুক্তি সম্পূর্ণ তা দ্রুত ফেরাতে পারার ওপর দাঁড়িয়ে। ভালো উত্তর মতাদর্শিক নয়; এটি নির্দিষ্ট নিয়ন্ত্রণের, স্বয়ংক্রিয় পরীক্ষা, ক্যানারি রিলিজ, পরীক্ষিত ফেরানো, নাম বলে যা আপনাকে পরিবর্তনের ঘনত্ব বাড়াতে এবং একই সঙ্গে আপনার ক্লিনিক্যাল-নিরাপত্তা ও আশ্বাস বাধ্যবাধকতা পূরণ করতে দেবে।

2. রাত ২টায় প্রোডাকশনে আমাদের সেবা কে চালায়, এবং তা আমাদের প্রকৌশল পছন্দ সম্পর্কে কী বলে? "আপনি গড়লে আপনিই চালান" সমর্থন করা সহজ এবং বাস করা কঠিন। এই প্রশ্ন প্রকাশ করে যাঁরা স্থাপত্য ও ডেলিভারি সিদ্ধান্ত নেন তাঁরা আসলেই পরিচালনগত পরিণাম অনুভব করেন, নাকি যন্ত্রণা একটি আলাদা পরিচালনা বা সেবা-ডেস্ক দলের ওপর চাপানো হয় যারা মূল কারণ ঠিক করতে পারে না। আপনার পর্যবেক্ষণযোগ্যতার অবস্থা অনুসন্ধান করুন: একটি শেয়ার্ড কেয়ার রেকর্ড ধীর হলে, আপনি কি তা ড্যাশবোর্ড ও সতর্কতা থেকে জানেন, নাকি একজন রুষ্ট চিকিৎসকের কাছ থেকে? মানবিক খরচও আলোচনা করুন: অন-কল মানবিক, অর্থায়িত ও ভাগ করা হতে হবে, নয়তো তা একটি বার্নআউট ও ধারণক্ষমতার সমস্যা হয়, যা কর্মীবাহিনী-সীমিত NHS-এ একটি গুরুতর ঝুঁকি (বিষয় 7.2 — কর্মীবাহিনী পরিকল্পনা দেখুন)। পূর্ণ দলীয় মালিকানা এবং এই বাস্তবতার মধ্যে একটি প্রকৃত ট্রেড-অফ আছে যে কিছু ছোট প্রতিষ্ঠান ও সরবরাহকারীর নির্ভরযোগ্যভাবে জিনিস চালাতে সত্যিই একটি ভাগ করা প্ল্যাটফর্ম বা ম্যানেজড সেবা দরকার। শক্তিশালী উত্তর পরিচালনগত দায়িত্বকে নকশার সঙ্গে ফিরে যুক্ত করে: এটি চিহ্নিত করে গড়া ও চালানোর মধ্যকার ফিডব্যাক লুপ কোথায় ভাঙা, এবং আপনি কী বদলাবেন যাতে প্রকৌশল পছন্দ লাইভ পরিচালনার বাস্তবতা দ্বারা জানা হয়।

3. আমাদের কোড এবং প্রকৌশল চর্চার কতটা প্রকাশ্য করা সহ্য করতে পারত, এবং উত্তরটি কী প্রকাশ করে? সরকার ও NHS নীতি দলগুলোকে ডিফল্টে প্রকাশ্যে কোড করতে বলে, এবং এই প্রশ্ন সেই লেন্সকে নির্ণয়মূলক হিসেবে ব্যবহার করে এমনকি যেখানে পূর্ণ উন্মুক্ততা এখনো সম্ভব নয়। আপনার রিপোজিটরি প্রকাশের সম্ভাবনা উদ্বেগ জাগালে, জিজ্ঞাসা করুন ঠিক কেন: তা কি হার্ড-কোড করা গোপন বিষয়, এম্বেড করা রোগীর ডেটা, অনুপস্থিত পরীক্ষা, নথিহীন সিদ্ধান্ত, নাকি কেবল অপরিচিতি? এর প্রতিটি একটি প্রকৃত প্রকৌশল-মান বা তথ্য-গভর্ন্যান্স সমস্যা যা বন্ধ থাকা কেবল লুকায়, সমাধান করে না। প্রকৃত সীমাবদ্ধতাগুলো নিয়ে বিতর্ক করুন, কিছু নিরাপত্তা-সংবেদনশীল কোড বন্ধ থাকা উচিত, এবং গোপন বিষয় ব্যবস্থাপনা ঠিক করা একটি পূর্বশর্ত, যাচাইয়ের সুবিধা, নগদ-টানাটানির ব্যবস্থা জুড়ে পুনর্ব্যবহার, এবং স্বাস্থ্য সফটওয়্যার ব্যয় কীভাবে ব্যবহৃত হয় সে বিষয়ে জনগণের আস্থার বিপরীতে। একজন আক্রমণকারীর আগে বাইরের চোখের একটি ত্রুটি খুঁজে পাওয়ার সুনাম ও নিরাপত্তা মূল্য বিবেচনা করুন। ভালো, সৎ উত্তর যে কোড একটি রক্ষণযোগ্য, নথিবদ্ধ কারণে বন্ধ তাকে যা অভ্যাস বা বিব্রতবোধে বন্ধ তা থেকে আলাদা করে, এবং যেভাবেই হোক অন্তর্নিহিত গুণমান ও স্বাস্থ্যবিধি সমস্যা ঠিক করতে প্রতিশ্রুতিবদ্ধ হয়।

4. কাল সকালে একটি সাধারণ নির্ভরতায় একটি ব্যাপকভাবে প্রচারিত দুর্বলতা ঘোষিত হলে, "আমরা কি প্রভাবিত, এবং কোথায়?" উত্তর দিতে আমাদের কত সময় লাগত? এই প্রশ্ন পরীক্ষা করে সরবরাহ-শৃঙ্খল স্বাস্থ্যবিধি একটি প্রকৃত সামর্থ্য নাকি আকাঙ্ক্ষা, এমন খাত-ব্যাপী ঘটনার ধরন ব্যবহার করে, Log4j-ধাঁচের একটি ত্রুটি, যা একটি বিমূর্ত ঝুঁকিকে একই-দিনের জরুরি অবস্থায় পরিণত করে। সৎ উত্তর নির্ভর করে আপনি নির্ভরতার একটি নির্ভুল তালিকা ও একটি সফটওয়্যার বিল অব ম্যাটেরিয়ালস রাখেন কি না, নাকি রিপোজিটরির মধ্যে খুঁজতে এবং এমন সরবরাহকারীদের জিজ্ঞাসা করতে দিন কাটাতেন যারা নিজেরাও হয়তো জানে না। অনুসন্ধান করুন আপনার সফটওয়্যারের কতটা তৃতীয়-পক্ষ ও ওপেন-সোর্স উপাদান থেকে জোড়া, এবং সেই পৃষ্ঠতলের কতটা আপনি আসলে স্বয়ংক্রিয় স্ক্যানিং দিয়ে বনাম মাঝে মাঝে ম্যানুয়াল যাচাইয়ে পর্যবেক্ষণ করেন। তৃতীয়-পক্ষ ও সরবরাহকারীর মাত্রাও আলোচনা করুন, কারণ স্বাস্থ্য ও পরিচর্যায় ভুবনের বেশির ভাগ কেনা, গড়া নয়, এবং একজন সরবরাহকারীর পণ্যে একটি আপসকৃত নির্ভরতা এমন গোপনীয় রোগীর ডেটার পথ যা আপনি সরাসরি নিয়ন্ত্রণ করেন না (বিষয় 1.7 — তথ্য গভর্ন্যান্স, ডেটা সুরক্ষা ও সাইবার নিরাপত্তা দেখুন)। বিবেচনা করুন আপনার পাইপলাইন ও প্রোডাকশন-পুশ অনুমতি যথেষ্ট আঁটসাঁট কি না যাতে একটি বিষাক্ত উপাদান নীরবে পাঠানো যেত না। শক্তিশালী উত্তর ঘণ্টায় মাপা একটি বাস্তবসম্মত উত্তর-দেওয়ার-সময়ের নাম বলে, তা সম্ভব করা নির্দিষ্ট হাতিয়ার ও তালিকার দিকে নির্দেশ করে, এবং ভুবনের যে অংশে, বিশেষত সরবরাহকারী-প্রদত্ত, দৃশ্যমানতা বর্তমানে দুর্বল সে বিষয়ে খোলামেলা।

5. আমাদের প্রকৌশল মেট্রিক কি আমাদের সত্য বলে, নাকি তা নীরবে একটি কর্মক্ষমতা লক্ষ্যে পরিণত হয়েছে যা মানুষ ওপরে সামলায়? DORA মেট্রিক কেবল একটি সৎ সিস্টেম-স্তরের সংকেত হিসেবে উপযোগী, এবং এই প্রশ্ন খুঁজে দেখে আপনার মেট্রিক সাংগঠনিক প্রণোদনার সংস্পর্শে টিকেছে কি না। গুডহার্টের নিয়ম ক্ষমাহীন: যে মুহূর্তে মোতায়েন ঘনত্ব বা পরিবর্তন-ব্যর্থতার হার একটি সংখ্যা হয় যার ভিত্তিতে দল বিচারিত হয়, মানুষ অন্তর্নিহিত বাস্তবতার বদলে সংখ্যাটি অপ্টিমাইজ করে, ঘনত্ব ফোলাতে মোতায়েন ভাগ করে, বা নীরবে ঘটনা পুনঃশ্রেণিবদ্ধ করে যাতে তা ব্যর্থতা হিসেবে গণ্য না হয়। বিতর্ক করুন কারা এই মেট্রিক দেখে এবং কেন, এবং সেগুলো পরীক্ষা কভারেজ বা ব্যাচ আকারে বিনিয়োগ প্ররোচিত করতে নির্ণয়মূলকভাবে ব্যবহৃত হচ্ছে, নাকি কারসাজি ও লুকানো ঝুঁকি চালানো একটি ক্রম-তালিকা হিসেবে। উল্টো দিকও বিবেচনা করুন: যে দলগুলো কিছুই মাপে না এবং কাহিনির ওপর নির্ভর করে, তাই একটি ক্রমবর্ধমান ব্যর্থতার হার একটি ক্লিনিক্যাল ঘটনা না হওয়া পর্যন্ত অদৃশ্য। আশ্বাসের জন্য বোর্ডের বৈধ প্রয়োজন এবং সবচেয়ে উপযোগী মেট্রিক হলো সেগুলো যা দলগুলো সততার সঙ্গে প্রতিবেদন করতে নিরাপদ বোধ করে এই ঘটনার মধ্যে একটি প্রকৃত টানাপোড়েন আছে। ভালো উত্তর বর্ণনা করে পরিমাপ কীভাবে সাজানো ও শাসিত যাতে তা অস্বস্তিকর সত্য আগে প্রকাশ করে, মানুষকে তা লুকানোর জন্য পুরস্কৃত না করে।

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

বাস্তবে: স্বাস্থ্য ও পরিচর্যার একটি উদাহরণ#

একটি সমন্বিত পরিচর্যা ব্যবস্থা (ICS) একটি ভাগ করা "একক প্রবেশ বিন্দু" সেবা চালায় যা জরুরি কমিউনিটি-পরিচর্যা রেফারাল সঠিক দলে রাউট করে। প্রথম দুই বছরে সেবাটি আনুমানিক ত্রৈমাসিকে একবার হাতে মোতায়েন করা হতো: একজন ডেভেলপার শুক্রবার শেষ বেলায় ম্যানুয়াল ধাপের একটি উইকি পাতা অনুসরণ করতেন, এবং প্রতিটি রিলিজ ছিল একটি উত্তেজনাপূর্ণ, সবার-উপস্থিতির ঘটনা। যখন একটি রেফারাল-রাউটিং বাগ ভেসে ওঠে, মাঝে মাঝে জটিল-প্রয়োজনের রেফারাল ভুল দলে পাঠায়, সংশোধন পরবর্তী রিলিজ জানালার জন্য ছয় সপ্তাহ সারিতে বসে ছিল, এবং চিকিৎসকরা ম্যানুয়াল ঘুরপথে ঝুঁকি সামলাচ্ছিলেন।

নতুন প্রকৌশল লিড এটিকে কেবল দক্ষতার নয়, ক্লিনিক্যাল-নিরাপত্তার সমস্যা হিসেবে নতুন করে সাজান। দল একটি CI/CD পাইপলাইন চালু করে: প্রতিটি পরিবর্তন ছোট, সহকর্মী-পর্যালোচিত, এবং স্বয়ংক্রিয়ভাবে নির্মিত ও পরীক্ষিত, অ্যাক্সেসিবিলিটি ও নিরাপত্তা যাচাই এবং বিপদ-লগের জন্য একটি নিরীক্ষাযোগ্য রেকর্ড তৈরি করা পাইপলাইন গেট হিসেবে এনকোড করা একটি ক্লিনিক্যাল-নিরাপত্তা অনুমোদন ধাপসহ। অবকাঠামো কোডে সরানো হয়, তাই পরীক্ষা ও প্রোডাকশন পরিবেশ অবশেষে মেলে। মোতায়েন ত্রৈমাসিক থেকে সপ্তাহে কয়েকবারে যায়, প্রথমে একটি একক এলাকায় ক্যানারি হিসেবে রিলিজ হয়, পাঁচ মিনিটের কমে শেষ জানা-ভালো অবস্থায় ফিরে আসা একটি পরীক্ষিত ফেরানোসহ।

ছয় মাস পরে, DORA মেট্রিক বোর্ডকে সরল ভাষায় গল্পটি বলে: একটি সংশোধনের লিড টাইম ছয় সপ্তাহ থেকে একদিনের নিচে নেমেছে, মোতায়েন ঘনত্ব দশগুণ বেড়েছে, এবং পরিবর্তন-ব্যর্থতার হার কমেছে কারণ পরিবর্তন এখন ছোট ও পর্যবেক্ষণযোগ্য। যখন একটি সূক্ষ্ম রাউটিং ত্রুটি পুনরাবৃত্ত হয়, পর্যবেক্ষণযোগ্যতা ড্যাশবোর্ড মিনিটের মধ্যে অসংগতি চিহ্নিত করে, দল কোনো রেফারাল ভুল রাউট হওয়ার আগে ফেরায়, পরদিন সকালে একটি সংশোধন পাঠায়, এবং একটি দোষারোপহীন ঘটনা-পরবর্তী পর্যালোচনা লিপিবদ্ধ করে। দল NHS Service Standard-এর অধীনে অ-সংবেদনশীল রাউটিং-নিয়ম ইঞ্জিনটিকে ওপেন সোর্স হিসেবে প্রকাশও করে, এবং একটি প্রতিবেশী ICS তা পুনর্ব্যবহার করে। সিস্টেম আরও ঘন ঘন বদলানো তাকে প্রদর্শনযোগ্যভাবে নিরাপদতর করেছে।

খাতভিত্তিক দৃষ্টিকোণ#

স্টার্ট-আপ#

একটি ডিজিটাল-স্বাস্থ্য স্টার্ট-আপ প্রথম দিন থেকে আধুনিক প্রকৌশল চর্চা গ্রহণ করতে পারে, দরকষাকষির জন্য কোনো লিগ্যাসি পরিচালনা দল ছাড়াই: ট্রাঙ্ক-ভিত্তিক ডেভেলপমেন্ট, CI/CD ও অবকাঠামো-কোড হিসেবে একটি ছোট, গ্রিনফিল্ড দলে মূলত বিনামূল্যের ডিফল্ট, এবং এটি একটি প্রকৃত সুবিধা। ঝুঁকি হলো "দ্রুত চলুন" নীরবে স্বাস্থ্য যে শৃঙ্খলা দাবি করে তা বাদ দেয়: স্বয়ংক্রিয় পরীক্ষা, পরীক্ষিত ফেরানো, গোপন বিষয় ব্যবস্থাপনা ও নির্ভরতা স্ক্যানিং ঘর্ষণ মনে হয় যখন কোনো নিয়ন্ত্রক এখনো নজর রাখছে না। প্রতিষ্ঠাতাদের চিনতে হবে ক্লিনিক্যাল-নিরাপত্তা ও সরবরাহ-শৃঙ্খল বাধ্যবাধকতা কোম্পানির আকার নির্বিশেষে বর্তায়, এবং একটি ফাঁস হওয়া রোগী ডেটাসেট বা অপরিচালিত নির্ভরতা কোম্পানি শেষ করতে পারে। বাস্তবসম্মত পথ হলো ম্যানেজড ক্লাউড প্ল্যাটফর্ম ও একটি ছোট, মতামতপূর্ণ "পাকা রাস্তা"-র ওপর ভর দেওয়া, যাতে একটি ক্ষুদ্র দল এখনো সামর্থ্যে নেই এমন একটি প্ল্যাটফর্ম গোষ্ঠী না গড়ে ডিফল্টে নিরাপত্তা পায়।

ক্ষুদ্র ব্যবসা#

একটি প্রতিষ্ঠিত ছোট প্রদানকারী বা সরবরাহকারী, যেমন একটি জিপি প্র্যাকটিস, কমিউনিটি ফার্মেসি, কেয়ার হোম, একক-স্থানের ক্লিনিক, বা রাজস্ব-পূর্ব পর্যায় পেরোনো একটি ছোট স্বাস্থ্য-প্রযুক্তি বিক্রেতা, সাধারণত প্রকৃত রোগী ও প্রকৃত পরিচালনা রাখে কিন্তু পাইপলাইন, পর্যবেক্ষণযোগ্যতা বা অন-কল চালানোর কোনো নিবেদিত প্রকৌশল বা IT কার্য নেই। এমন বেশির ভাগ প্রতিষ্ঠানের জন্য প্রকৌশল উৎকর্ষের ব্যবহারিক রূপ হলো গড়ার বদলে ভালোভাবে কেনা: এমন সরবরাহকারী ও ম্যানেজড প্ল্যাটফর্ম বেছে নিন যাদের নিজস্ব DevOps শৃঙ্খলা আপনি পরিদর্শন করতে পারেন, এবং স্বয়ংক্রিয় হালনাগাদ, পরীক্ষিত ব্যাকআপ ও নির্ভরতা প্যাচিংকে আশার বদলে চুক্তিগত প্রত্যাশা করুন। যেখানে একজন ছোট বিক্রেতা সফটওয়্যার লেখে, একটি ম্যানেজড ক্লাউড প্ল্যাটফর্মে একটি ভালোভাবে কনফিগার করা CI/CD পাইপলাইন, স্বয়ংক্রিয় নির্ভরতা স্ক্যানিং ও রিপোজিটরির বাইরে রাখা গোপন বিষয়সহ, একটি রোগা দল বহন করতে পারে এমন খরচে বেশির ভাগ নিরাপত্তা সুবিধা দেয়। ফাঁদ হলো ধরে নেওয়া যে ছোট আকার ক্লিনিক্যাল-নিরাপত্তা, নিরাপত্তা ও তথ্য-গভর্ন্যান্সের মান কমায়, তা কমায় না, এবং একটি অপ্যাচড নির্ভরতা বা হাতে মোতায়েন হওয়া ভুল পরিবর্তন দুই-চিকিৎসকের প্র্যাকটিসে একটি জাতীয় সংস্থার মতোই নিশ্চিতভাবে রোগীদের ক্ষতি করে। বাস্তবসম্মত লক্ষ্য হলো ভালো প্ল্যাটফর্ম ও ভালো সরবরাহকারী থেকে উত্তরাধিকারে-পাওয়া ডিফল্টে-নিরাপত্তা, প্র্যাকটিসের সীমিত মনোযোগ সেই ডিফল্ট আসলে চালু আছে কি না যাচাই করতে ব্যয় করে।

বৃহৎ প্রতিষ্ঠান#

একটি বড় NHS ট্রাস্ট বা প্রধান স্বাস্থ্য-প্রযুক্তি সরবরাহকারীর প্ল্যাটফর্ম প্রকৌশল, পর্যবেক্ষণযোগ্যতা ও "আপনি গড়লে আপনিই চালান" যথাযথভাবে করার সম্পদ আছে, কিন্তু লিগ্যাসি সিস্টেম, সাইলোকৃত ডেভেলপমেন্ট-ও-পরিচালনা দল এবং ধীরতর যুগের জন্য গড়া পরিবর্তন-উপদেষ্টা প্রক্রিয়া তাকে পিছিয়ে রাখে। চরিত্রগত ব্যর্থতা হলো একটি ভারী পরিবর্তন বোর্ড যা ঝুঁকি নিয়ন্ত্রণ করতে চেষ্টা করে বড় ব্যাচ-করা রিলিজ বাধ্য করে যা সে যে ঘন ঘন ছোটগুলোকে ভয় পায় তার চেয়ে বেশি বিপজ্জনক। সুযোগ হলো একটি অভ্যন্তরীণ ডেভেলপার প্ল্যাটফর্মে বিনিয়োগ করা যা সম্মতি, নিরাপত্তা ও ক্লিনিক্যাল-নিরাপত্তা গেট একটি পাকা রাস্তায় বেক করে, যাতে ডজন ডজন দল প্রত্যেকে দরকষাকষি না করে ভালো চর্চা উত্তরাধিকারে পায়। এখানে মাপ দ্বিধারী তলোয়ার: একটি খারাপ মোতায়েনের বিস্ফোরণ-ব্যাসার্ধ বিশাল, ঠিক সেই কারণেই স্বয়ংক্রিয়তা, ক্যানারি রিলিজ ও পরীক্ষিত ফেরানো ঐচ্ছিক নয়, অপরিহার্য।

সরকার#

NHS England বা একটি স্বায়ত্তশাসিত স্বাস্থ্য বিভাগের মতো একটি জাতীয় সংস্থা অন্যরা যে মান অনুসরণ করে তা নির্ধারণ করে, NHS ও GDS Service Standard, ব্যয়-নিয়ন্ত্রণ, প্রকাশ্যে কোড করার প্রত্যাশা, এবং সফটওয়্যার কীভাবে গড়া ও চালানো হয় সে বিষয়ে পার্লামেন্ট ও জনগণের কাছে জবাবদিহিকারী। তার প্রকৌশল পছন্দ ব্যবস্থা জুড়ে ঢেউ তোলে: একটি ভালোভাবে চালানো জাতীয় প্ল্যাটফর্ম, প্রকাশিত ওপেন-সোর্স উপাদান এবং স্পষ্ট সরবরাহ-শৃঙ্খল নির্দেশিকা প্রতিটি ট্রাস্ট ও সরবরাহকারীর জন্য ভিত্তিমূল উঁচু করে। সীমাবদ্ধতা বাস্তব: বহু-বছরের অর্থায়ন, ক্রয় নিয়ম এবং জাতীয় ডেটার নিছক মাপ ও সংবেদনশীলতার অর্থ মোতায়েনের ছন্দ একটি স্টার্ট-আপের চেয়ে বেশি পরিমিত। সরকারি দৃষ্টিকোণকে অনুকরণীয় স্বচ্ছতা ও পুনর্ব্যবহার এবং জাতীয়ভাবে সংকটপূর্ণ সিস্টেমের নিরাপত্তার ভারসাম্য রাখতে হবে, সুচিন্তিতভাবে ঠিক করে কী উন্মুক্ত আর কী সুরক্ষিত, এবং যেভাবেই হোক যুক্তি নথিবদ্ধ করে।

ব্যর্থতার সাধারণ ধরন#

• "পরিবর্তনই ঝুঁকি" পক্ষাঘাত। নিরাপদ বোধ করতে কদাচিৎ মোতায়েন করা, যা বড়, বিপজ্জনক, খারাপভাবে বোঝা রিলিজ ও অপ্যাচড অবহেলা তৈরি করে। প্রতিষেধক: পরীক্ষিত ফেরানোসহ ছোট, ঘন ঘন, ফেরানো-যায় পরিবর্তন।
• dev ও ops-এর মধ্যে প্রাচীর। ডেভেলপাররা মূল কারণ ঠিক করতে না পারা একটি আলাদা পরিচালনা দলের কাছে "প্রাচীরের ওপর দিয়ে কোড ছুড়ে দেয়"; কেউ পুরো লুপের মালিক নয়। প্রতিষেধক: ভাগ করা মালিকানা ও মানবিকভাবে সমর্থিত "আপনি গড়লে আপনিই চালান"।
• ম্যানুয়াল, স্নোফ্লেক মোতায়েন। রিলিজ একজন মানুষ ও একটি উইকি পাতার ওপর নির্ভর করে; পরিবেশ সরে যায় এবং "পরীক্ষায় কাজ করে, প্রোডাকশনে ভাঙে" নিয়মিত। প্রতিষেধক: CI/CD সঙ্গে অবকাঠামো-কোড হিসেবে।
• লাঠি হিসেবে মেট্রিক। দলগুলোকে র‍্যাঙ্ক করতে ব্যবহৃত DORA সংখ্যা, কারসাজি ও লুকানো ঝুঁকি চালায়। প্রতিষেধক: DORA-র নিজস্ব নির্দেশিকা অনুযায়ী একটি সিস্টেম-স্তরের নির্ণয়মূলক হিসেবে ব্যবহার করুন।
• সতর্কতা-অন্ধ পরিচালনা। পর্যবেক্ষণযোগ্যতা নেই, তাই রোগী ও চিকিৎসকরা প্রথমে ব্যর্থতা আবিষ্কার করেন। প্রতিষেধক: মেট্রিক, লগ, ট্রেস এবং ব্যবহারকারীর-প্রভাব সতর্কতা।
• অবহেলিত সরবরাহ শৃঙ্খল। অপ্যাচড নির্ভরতা ও অস্ক্যান উপাদান লঙ্ঘন হয়ে ওঠে। প্রতিষেধক: অবিরাম স্ক্যানিং, একটি সফটওয়্যার বিল অব ম্যাটেরিয়ালস এবং সুরক্ষিত পাইপলাইন।
• দুর্ঘটনাজনিত উন্মুক্ততা। অসতর্কভাবে করা প্রকাশ্যে কোডিং, গোপন বিষয় বা রোগীর ডেটা ফাঁস করে। প্রতিষেধক: ডিফল্টে-বন্ধে পশ্চাদপসরণ নয়, কঠোর গোপন বিষয় ব্যবস্থাপনা ও প্রকাশ-পূর্ব স্ক্যানিং।

পরিপক্বতা মডেল#

চেকলিস্ট#

• একটি CI/CD পাইপলাইন প্রতিটি পরিবর্তন এনকোড করা নিরাপত্তা/সুরক্ষা/অ্যাক্সেসিবিলিটি গেটসহ একটি নিরীক্ষাযোগ্য পথে নির্মাণ, পরীক্ষা ও মোতায়েন করে।
• পরিবর্তন ছোট, ঘন ঘন এবং স্বাধীনভাবে ফেরানো-যায় (ফিচার ফ্ল্যাগ, ক্যানারি বা ব্লু-গ্রিন রিলিজ)।
• একটি জানা-ভালো অবস্থায় ফেরানো নিয়মিত পরীক্ষিত এবং একটি নথিবদ্ধ, সংক্ষিপ্ত সময়ের মধ্যে সম্পন্ন হয়।
• অবকাঠামো ও কনফিগারেশন সংস্করণ-নিয়ন্ত্রিত কোড হিসেবে সংজ্ঞায়িত; পরীক্ষা ও প্রোডাকশন পরিবেশ মেলে।
• চারটি DORA মেট্রিক একটি সিস্টেম-স্তরের সংকেত হিসেবে ট্র্যাক করা হয়, ব্যক্তি বা দল র‍্যাঙ্ক করতে ব্যবহৃত হয় না।
• ডেলিভারি দলগুলো প্রোডাকশনে তাদের সেবার মালিক, মানবিক, অর্থায়িত অন-কল ও অর্থবহ পর্যবেক্ষণযোগ্যতাসহ (মেট্রিক, লগ, ট্রেস, সতর্কতা)।
• নির্ভরতা তালিকাভুক্ত ও স্বয়ংক্রিয়ভাবে স্ক্যান করা হয়; একটি সফটওয়্যার বিল অব ম্যাটেরিয়ালস আছে এবং গোপন বিষয় সুরক্ষিত।
• প্রকৌশল মান, কোড পর্যালোচনা ও একটি সম্পন্নের সংজ্ঞা সম্মত; টেকনিক্যাল ঋণ ট্র্যাক ও পরিকল্পিত কাজ হিসেবে শোধ করা হয়।
• নতুন সোর্স কোড যেখানে নিরাপদ সেখানে ডিফল্টে উন্মুক্ত, কোনো রোগীর ডেটা বা গোপন বিষয় উন্মুক্ত হয় না তার কঠোর যাচাইসহ।
• প্রকৌশল চর্চা নথিবদ্ধ যাতে একজন নতুন প্রকৌশলী, নিরীক্ষক বা নিরাপত্তা অফিসার বুঝতে পারেন কী চলে এবং কেন (বিষয় 10.3 দেখুন)।

মূল উৎস#

• Nicole Forsgren, Jez Humble ও Gene Kim, Accelerate: The Science of Lean Software and Development and DevOps — DORA গবেষণা ও চারটি মূল মেট্রিক।
• DORA (DevOps Research and Assessment) — বার্ষিক State of DevOps রিপোর্ট ও সামর্থ্য ক্যাটালগ — dora.dev।
• Jez Humble ও David Farley, Continuous Delivery — মোতায়েন পাইপলাইন ও রিলিজ স্বয়ংক্রিয়তা।
• Betsy Beyer et al. (সম্পা.), Site Reliability Engineering — প্রোডাকশন সিস্টেম চালানো নিয়ে Google-এর SRE বই।
• NHS England — NHS Service Standard ও NHS Digital Service Manual (প্রকাশ্যে কোডিং ও উন্মুক্ত মানসহ)।
• GOV.UK Service Manual / Government Service Standard (GDS) — "নতুন সোর্স কোড উন্মুক্ত করুন", অবিরাম সরবরাহ ও একটি সেবা পরিচালনা।
• National Cyber Security Centre (NCSC) — নিরাপদ সফটওয়্যার ডেভেলপমেন্ট ও সরবরাহ শৃঙ্খল নিরাপত্তা নির্দেশিকা।
• NHS England — ক্লিনিক্যাল ঝুঁকি ব্যবস্থাপনা মান DCB0129 ও DCB0160 (ক্লিনিক্যাল নিরাপত্তা কেসের অংশ হিসেবে প্রকৌশল পরিবর্তন)।

তথ্যসূত্র#

1. DevOps — Wikipedia — https://en.wikipedia.org/wiki/DevOps
2. CI/CD — Wikipedia — https://en.wikipedia.org/wiki/CI/CD
3. Continuous integration — Wikipedia — https://en.wikipedia.org/wiki/Continuous_integration
4. Continuous delivery — Wikipedia — https://en.wikipedia.org/wiki/Continuous_delivery
5. Version control — Wikipedia — https://en.wikipedia.org/wiki/Version_control
6. Infrastructure as code — Wikipedia — https://en.wikipedia.org/wiki/Infrastructure_as_code
7. Platform engineering — Wikipedia — https://en.wikipedia.org/wiki/Platform_engineering
8. DevOps Research and Assessment (DORA) — Wikipedia — https://en.wikipedia.org/wiki/DevOps_Research_and_Assessment
9. Site reliability engineering — Wikipedia — https://en.wikipedia.org/wiki/Site_reliability_engineering
10. Observability (software) — Wikipedia — https://en.wikipedia.org/wiki/Observability_(software)
11. Supply chain attack — Wikipedia — https://en.wikipedia.org/wiki/Supply_chain_attack
12. Open-source software — Wikipedia — https://en.wikipedia.org/wiki/Open-source_software
13. Accelerate: The Science of Lean Software and DevOps — Nicole Forsgren, Jez Humble & Gene Kim (IT Revolution) — https://itrevolution.com/product/accelerate/
14. DORA — DevOps Research and Assessment — Google Cloud / DORA — https://dora.dev/
15. Continuous Delivery — Jez Humble & David Farley — https://continuousdelivery.com/
16. Site Reliability Engineering — Google (O'Reilly) — https://sre.google/books/
17. NHS Service Standard — NHS England — https://service-manual.nhs.uk/standards-and-technology/service-standard-points
18. Making source code open and reusable — Government Digital Service, GOV.UK Service Manual — https://www.gov.uk/service-manual/technology/making-source-code-open-and-reusable
19. Secure software development and supply chain security — National Cyber Security Centre (NCSC) — https://www.ncsc.gov.uk/collection/developers-collection
20. Clinical risk management standards DCB0129 and DCB0160 — NHS England — https://digital.nhs.uk/services/clinical-safety