বিষয় 3.8 — সেবা ব্যবস্থাপনা ও লাইভ পরিচালনা

এক বাক্যে: স্বাস্থ্য ও পরিচর্যায় একটি সেবার জীবন, খরচ ও ক্লিনিক্যাল ঝুঁকির বেশির ভাগই গো-লাইভের পরে থাকে, তাই একটি লাইভ সেবা কীভাবে চালানো, পর্যবেক্ষণ ও সহায়তা করা হয় তা একটি রোগী-নিরাপত্তার সিদ্ধান্ত, ব্যাক-অফিসের পরে-ভাবা বিষয় নয়।

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

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

স্বাস্থ্য ও পরিচর্যা দিনে ২৪ ঘণ্টা, সপ্তাহে সাত দিন চলে এবং থামতে পারে না। একটি সুপারমার্কেটের চেকআউট সিস্টেম ব্যর্থ হলে গ্রাহকরা অপেক্ষা করেন; একটি হাসপাতালের রোগী প্রশাসন সিস্টেম ব্যর্থ হলে অ্যাম্বুলেন্স অন্যত্র পাঠাতে হতে পারে এবং ঐচ্ছিক তালিকা স্থগিত হয়। এটি লাইভ পরিচালনাকে একটি স্বতন্ত্র ওজন দেয়: ডাউনটাইম একটি ক্লিনিক্যাল-নিরাপত্তা ঘটনা, এবং আপনি কীভাবে তা শনাক্ত, ঊর্ধ্বতনে জানান, যোগাযোগ ও পুনরুদ্ধার করবেন তার পরিকল্পনা আপনার পরিচর্যা-দায়িত্বের অংশ। ২০১৭ সালের WannaCry র‍্যানসমওয়্যার আক্রমণ, যা হাজার হাজার NHS অ্যাপয়েন্টমেন্ট ও অস্ত্রোপচার বাতিল করতে বাধ্য করেছিল, একটি পরিচালনগত ব্যর্থতা কীভাবে রোগী-নিরাপত্তা ও জনআস্থার সংকটে পরিণত হয় তার প্রসঙ্গ-ঘটনা (বিষয় 1.7 — তথ্য গভর্ন্যান্স, ডেটা সুরক্ষা ও সাইবার নিরাপত্তা দেখুন)।

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

মূল ধারণা#

সেবা ব্যবস্থাপনা ও "লাইভ" পর্যায়। IT সেবা ব্যবস্থাপনা (ITSM) হলো IT সেবাকে তার সম্পূর্ণ জীবনজুড়ে নকশা, পরিচালনা, সহায়তা ও উন্নত করার চর্চার সমষ্টি। GOV.UK ও NHS পর্যায় মডেলে লাইভ হলো সেই পর্যায় যেখানে একটি সেবা অবিরাম পরিচালনায় চলে, তখনো পুনরাবৃত্ত হচ্ছে, তখনো অর্থায়িত, তখনো মালিকানাধীন, যতক্ষণ না তা অবসরে যায় (বিষয় 3.5 — ডেলিভারি জীবনচক্র দেখুন)। লাইভ কোনো বিশ্রামের অবস্থা নয়; এটি জীবনচক্রের দীর্ঘতম ও সবচেয়ে ব্যয়বহুল অংশ।

ITIL 4। ITIL সবচেয়ে বহুল ব্যবহৃত ITSM কাঠামো। এর বর্তমান সংস্করণ ITIL 4 পুরোনো প্রক্রিয়া-ভারী সংস্করণগুলোকে একটি "সেবা মূল্য ব্যবস্থা" ও নমনীয় চর্চার চারপাশে নতুন করে সাজিয়েছে, এবং Agile, DevOps ও Lean-এর সঙ্গে প্রতিযোগিতা না করে পাশাপাশি বসার জন্য নকশাকৃত। ITIL-কে একটি শব্দভান্ডার ও আনুপাতিকভাবে গ্রহণযোগ্য চর্চার চেকলিস্ট হিসেবে দেখুন, সম্পূর্ণ আমদানি করার একটি আমলাতন্ত্র হিসেবে নয়।

ঘটনা, সমস্যা ও পরিবর্তন ব্যবস্থাপনা। ঘটনা ব্যবস্থাপনা একটি অপরিকল্পিত ব্যাঘাতের পরে যত দ্রুত সম্ভব স্বাভাবিক সেবা পুনরুদ্ধার করে, অগ্রাধিকার পুনরুদ্ধার, রোগনির্ণয় নয়। সমস্যা ব্যবস্থাপনা একটি বা অনেক ঘটনার অন্তর্নিহিত কারণ তদন্ত করে পুনরাবৃত্তি বন্ধ করে, এবং জানা ত্রুটি ও বিকল্প সমাধানের একটি রেকর্ড রাখে। পরিবর্তন ব্যবস্থাপনা (ITSM অর্থে) লাইভ এস্টেটে পরিবর্তন কীভাবে মূল্যায়ন, অনুমোদন ও রিলিজ করা হয় তা নিয়ন্ত্রণ করে যাতে একটি জিনিস ঠিক করতে গিয়ে অন্যটি না ভাঙে। এই তিনটি চর্চা পরিচালনার মূল, এবং এরা পরস্পর জড়ানো: একটি ঘটনা একটি সমস্যা তুলতে পারে, যার সমাধান একটি পরিবর্তন হিসেবে সরবরাহ করা হয়।

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

সাইট রিলায়াবিলিটি ইঞ্জিনিয়ারিং, SLI, SLO, SLA ও এরর বাজেট। সাইট রিলায়াবিলিটি ইঞ্জিনিয়ারিং (SRE), Google-এ উদ্ভূত, পরিচালনায় সফটওয়্যার-প্রকৌশল শৃঙ্খলা প্রয়োগ করে। এটি নির্ভরযোগ্যতা মাপে একটি সেবা স্তর সূচক (SLI) দিয়ে, যা প্রাপ্যতা বা বিলম্বের মতো একটি মেট্রিক, একটি সেবা-স্তর উদ্দেশ্য (SLO)-র বিপরীতে, যা সেই মেট্রিকের একটি অভ্যন্তরীণ লক্ষ্য। একটি সেবা-স্তর চুক্তি (SLA) হলো বাহ্যিক, প্রায়ই চুক্তিগত, প্রতিশ্রুতি, সাধারণত অভ্যন্তরীণ SLO-র চেয়ে শিথিল করে নির্ধারিত। ১০০% ও আপনার SLO-র মধ্যকার ব্যবধান হলো এরর বাজেট: ফিচার পাঠানো বন্ধ করে স্থিতিশীল করতে হওয়ার আগে আপনি যতটা অনির্ভরযোগ্যতা খরচ করতে পারেন। ক্লিনিক্যাল সিস্টেমে SLO অবশ্যই চিকিৎসকদের সঙ্গে নির্ধারণ করতে হবে, কারণ "গ্রহণযোগ্য" ডাউনটাইম একটি নিরাপত্তা-বিচার, কেবল প্রকৌশলগত নয়।

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

অন-কল, রোটা ও সার্ভিস ডেস্ক। অন-কল রোটা নিশ্চিত করে একজন যোগ্য মানুষ সারাক্ষণ অ্যালার্টে সাড়া দিতে পারেন; ২৪/৭ পরিচর্যা পরিবেশে এগুলো অপরিহার্য, এবং মানবিক ও টেকসই হতে হবে। একটি সার্ভিস ডেস্ক (বা হেল্প ডেস্ক) শেষ ব্যবহারকারীদের জন্য একক যোগাযোগ বিন্দু, যে চিকিৎসক লগ ইন করতে পারছেন না, যে রিসেপশনিস্টের বুকিং স্ক্রিন জমে গেছে, সহায়তা দেয়, ঘটনা লগ করে এবং তা এগিয়ে পাঠায়।

DevOps, কনফিগারেশন ব্যবস্থাপনা ও CMDB। DevOps এবং SRE নীতি "আপনি গড়েন, আপনি চালান" একটি সেবা যে দল গড়ে সেই দলকেই তা চালানোর দায়িত্ব দেয়, ডেভেলপমেন্ট ও অপারেশনসের ব্যবধান ঘুচিয়ে। কনফিগারেশন ব্যবস্থাপনা একটি সেবা গড়া উপাদান ও তাদের সম্পর্কের একটি নির্ভুল রেকর্ড রাখে, প্রায়ই একটি কনফিগারেশন ব্যবস্থাপনা ডেটাবেস (CMDB)-এ; এটি ছাড়া ঘটনার সময় "এই পরিবর্তন কী প্রভাবিত করবে?" প্রশ্নের নিরাপদে উত্তর কেউ দিতে পারে না।

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

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

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

2. "ওপস-এর দিকে দেয়ালের ওপার দিয়ে ছুড়ে দেওয়া" বিরোধী-ধরনটি এড়ান। একটি প্রকল্প দলকে সেবা গড়ে তা এমন একটি আলাদা অপারেশনস দলকে হস্তান্তর করতে দেবেন না যারা তা তৈরি হতে দেখেনি। "আপনি গড়েন, আপনি চালান" প্রয়োগ করুন: সেবাটি যে দল বোঝে তাকেই তার নির্ভরযোগ্যতার জন্য জবাবদিহিকারী রাখুন, অথবা অন্তত একটি সুচিন্তিত, নথিবদ্ধ সেবা-স্থানান্তর চালান, ভাগ করা অন-কল ও একটি ওয়ারেন্টি কালসহ। গড়া ও চালানোর মধ্যকার দেয়ালেই জ্ঞান, মালিকানা ও নিরাপত্তা ফসকে যায়।

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

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

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

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

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

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

9. অন-কলকে টেকসই এবং সহায়তাকে মানবিক করুন। পর্যাপ্ত জনবলযুক্ত, ন্যায্যভাবে পারিশ্রমিকপ্রাপ্ত ও মানবিক অন-কল রোটা নকশা করুন, স্পষ্ট ঊর্ধ্বতন-প্রেরণ ও বাস্তবসম্মত প্রত্যাশাসহ, ক্লান্ত সাড়াদাতারা ঠিক সবচেয়ে গুরুত্বপূর্ণ মুহূর্তে ধীর, ত্রুটিপ্রবণ সিদ্ধান্ত নেন। সার্ভিস ডেস্ককে একটি ২৪/৭ ক্লিনিক্যাল কর্মীবাহিনীর প্রকৃত চাহিদা অনুযায়ী সম্পদ দিন, এবং সম্মুখ-সারির কর্মীদের সমস্যা জানানোর একটি দ্রুত, সম্মানিত পথ দিন। আপনার সহায়তার মান হলো আপনার সেবা থেকে পরিচর্যা কর্মীরা যে মান অভিজ্ঞতা করেন।

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

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

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

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

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

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

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

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

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

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

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

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

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

স্টার্ট-আপ#

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

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

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

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

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

সরকার#

একটি জাতীয় সংস্থা এমন সেবা পরিচালনা করে যা লক্ষ লক্ষকে স্পর্শ করতে পারে, তাই একটি বিভ্রাট সংসদীয় ও জনআস্থার পরিণতিসহ একটি জাতীয় ঘটনা, এবং নির্ভরযোগ্যতা লক্ষ্য জনজবাবদিহিতার বিষয়। সরকারি ডেলিভারি ITSM-কে যুক্ত করে GOV.UK Service Manual-এর প্রত্যাশার সঙ্গে যে লাইভ সেবা যথাযথভাবে পরিচালিত, পর্যবেক্ষিত ও পুনরাবৃত্ত হবে, লঞ্চে জমাট নয়, এবং রেকর্ড-রক্ষণ ও সাইবার-নিরাপত্তা (NCSC, DSPT) সংক্রান্ত বিধিবদ্ধ দায়িত্বের সঙ্গে। ব্যয় নিয়ন্ত্রণ ও বহু-বছরের অর্থায়ন নিষ্পত্তি "চালানো" অর্থায়ন কেমন দেখায় তা আকার দেয়, এবং নিছক মাপ ব্যবসায়িক ধারাবাহিকতা, সমন্বিত বড়-ঘটনা সাড়া এবং দশকের রেকর্ডসহ লিগ্যাসি জাতীয় সিস্টেমের নিরাপদ ডিকমিশনিংয়ের ঝুঁকি বাড়ায়। ট্রেড-অফ হলো আশ্বাস ও স্থিতিস্থাপকতা বনাম গতি ও খরচ, যা খোলা চোখে, নজরদারির অধীনে মীমাংসিত।

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

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

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

চেকলিস্ট#

• প্রতিটি লাইভ সেবার একজন নামধারী মালিক এবং তার পরিচালনগত জীবনের জন্য একটি সুরক্ষিত চালানোর বাজেট আছে।
• প্রতিটি সেবা যে দল চালায় তারা তা কীভাবে গড়া হয়েছিল বোঝে (অথবা ওয়ারেন্টি ও ভাগ করা অন-কলসহ একটি নথিবদ্ধ স্থানান্তর আছে)।
• SLI ও SLO সংজ্ঞায়িত, এবং ক্লিনিক্যাল সিস্টেমের লক্ষ্য চিকিৎসকদের সঙ্গে নির্ধারিত; বাহ্যিক SLA অভ্যন্তরীণ SLO-র চেয়ে শিথিল।
• পর্যবেক্ষণযোগ্যতা (লগ, মেট্রিক, ট্রেস) ও লক্ষণ-ভিত্তিক অ্যালার্টিং কেবল সার্ভারের স্বাস্থ্য নয়, চিকিৎসক ও ব্যবহারকারীর অভিজ্ঞতা প্রতিফলিত করে।
• ঘটনা ব্যবস্থাপনায় তীব্রতার স্তর, সাড়ার লক্ষ্য, একজন ঘটনা-কমান্ডার ভূমিকা এবং সাড়ার সময় একটি একক সত্যের উৎস আছে।
• সমস্যা ব্যবস্থাপনা মূল কারণ ঠিক করে; ঘটনা-পরবর্তী পর্যালোচনা দোষারোপহীন এবং তাদের পদক্ষেপ সমাপ্তি পর্যন্ত ট্র্যাক করা হয়।
• পরিবর্তন ব্যবস্থাপনা যথাযথ-মাপের: মানসম্মত পরিবর্তন পূর্ব-অনুমোদিত ও স্বয়ংক্রিয়; কেবল ঝুঁকিপূর্ণ পরিবর্তন ক্লিনিক্যাল মতামতসহ পর্যালোচিত।
• ব্যবসায়িক-ধারাবাহিকতা ও ক্লিনিক্যাল ডাউনটাইম পদ্ধতি লিখিত, বিপদ-লগের সঙ্গে যুক্ত, এবং অন্তত বার্ষিক মহড়া দেওয়া।
• অন-কল রোটা পর্যাপ্ত জনবলযুক্ত, মানবিক ও ন্যায্যভাবে পারিশ্রমিকপ্রাপ্ত; সার্ভিস ডেস্ক প্রকৃত ২৪/৭ চাহিদা অনুযায়ী সম্পদপ্রাপ্ত।
• একটি কনফিগারেশন রেকর্ড (CMDB বা সমতুল্য) উপাদান, নির্ভরতা, সংস্করণ ও মালিক তালিকাভুক্ত করে এবং নিরাপত্তা প্যাচিং সমর্থন করে।
• একটি ডিকমিশনিং পরিকল্পনা রক্ষণ-আইনের অধীনে ডেটা স্থানান্তর/আর্কাইভ, ব্যবহারকারী পুনর্নির্দেশ এবং নিরাপত্তা ও নিরীক্ষা রেকর্ড সংরক্ষণ ঢাকে।

মূল উৎস#

• ITIL 4 — সেবা মূল্য ব্যবস্থা ও ব্যবস্থাপনা চর্চা (ঘটনা, সমস্যা, পরিবর্তন, সার্ভিস ডেস্ক, সেবা স্তর ব্যবস্থাপনা) — PeopleCert / AXELOS।
• Google — Site Reliability Engineering ও The Site Reliability Workbook (SLI, SLO, এরর বাজেট, অন-কল, দোষারোপহীন পোস্ট-মর্টেম)।
• GOV.UK Service Manual — একটি লাইভ সেবা পরিচালনা ও পুনরাবৃত্তি; একটি সেবার অবস্থা মনিটরিং; লঞ্চের পরে একটি সেবা রক্ষণাবেক্ষণ।
• NHS England — ক্লিনিক্যাল ঝুঁকি ব্যবস্থাপনা মান DCB0129/DCB0160 এবং সিস্টেম ডাউনটাইমকে ক্লিনিক্যাল বিপদ হিসেবে বিবেচনা (বিষয় 1.6 দেখুন)।
• NHS England / NCSC — সাইবার-নিরাপত্তা পরিচালনা, Data Security and Protection Toolkit (DSPT), এবং ২০১৭ WannaCry ঘটনার শিক্ষা (বিষয় 1.7 দেখুন)।
• ISO/IEC 20000 (IT সেবা ব্যবস্থাপনা) ও ISO 22301 (ব্যবসায়িক ধারাবাহিকতা ব্যবস্থাপনা সিস্টেম)।
• DevOps Research and Assessment (DORA) — ডেলিভারি ও পরিচালনগত কর্মক্ষমতা (মনিটরিং, পরিবর্তন, নির্ভরযোগ্যতা) সংযোগকারী সামর্থ্য।
• নেতৃত্বের কাছে পরিচালনগত ও নির্ভরযোগ্যতা প্রতিবেদনের জন্য OKR ও KPI (বিষয় 10.0 — উদ্দেশ্য ও মূল ফলাফল (OKR) দেখুন)।

তথ্যসূত্র#

1. IT service management — Wikipedia — https://en.wikipedia.org/wiki/IT_service_management
2. ITIL — Wikipedia — https://en.wikipedia.org/wiki/ITIL
3. Incident management — Wikipedia — https://en.wikipedia.org/wiki/Incident_management
4. Change management (ITSM) — Wikipedia — https://en.wikipedia.org/wiki/Change_management_(ITSM)
5. Business continuity planning — Wikipedia — https://en.wikipedia.org/wiki/Business_continuity_planning
6. Site reliability engineering — Wikipedia — https://en.wikipedia.org/wiki/Site_reliability_engineering
7. Service-level agreement — Wikipedia — https://en.wikipedia.org/wiki/Service-level_agreement
8. Service-level objective — Wikipedia — https://en.wikipedia.org/wiki/Service-level_objective
9. Service level indicator — Wikipedia — https://en.wikipedia.org/wiki/Service_level_indicator
10. Observability (software) — Wikipedia — https://en.wikipedia.org/wiki/Observability_(software)
11. DevOps — Wikipedia — https://en.wikipedia.org/wiki/DevOps
12. Configuration management database — Wikipedia — https://en.wikipedia.org/wiki/Configuration_management_database
13. Help desk — Wikipedia — https://en.wikipedia.org/wiki/Help_desk
14. Site Reliability Engineering (SRE book) — Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy (eds.), Google — https://sre.google/books/
15. ITIL 4 Foundation and service management practices — PeopleCert / AXELOS — https://www.peoplecert.org/browse-certifications/it-governance-and-service-management/ITIL-1/itil-4-foundation-2565
16. Service Manual: operating a service and monitoring its status — Government Digital Service, GOV.UK — https://www.gov.uk/service-manual/technology/monitoring-the-status-of-your-service
17. Clinical risk management standards DCB0129 and DCB0160 — NHS England (Clinical Safety) — https://digital.nhs.uk/services/clinical-safety
18. Investigation: WannaCry cyber attack and the NHS — National Audit Office — https://www.nao.org.uk/reports/investigation-wannacry-cyber-attack-and-the-nhs/
19. ISO/IEC 20000-1 — IT service management systems — International Organization for Standardization — https://www.iso.org/standard/70636.html
20. ISO 22301 — Security and resilience: business continuity management systems — International Organization for Standardization — https://www.iso.org/standard/75106.html
21. DevOps Research and Assessment (DORA) capabilities — Google Cloud / DORA — https://dora.dev/