विषय 3.8 — सेवा प्रबंधन और लाइव संचालन

स्वास्थ्य और देखभाल में, एक सेवा के जीवन, लागत, और क्लिनिकल जोखिम का अधिकांश हिस्सा लाइव-गो के बाद बैठता है — इसलिए आप एक लाइव सेवा को कैसे चलाते, निगरानी करते, और समर्थन करते हैं यह एक रोगी-सुरक्षा निर्णय है, कोई बैक-ऑफिस बाद का विचार नहीं।

यह स्वास्थ्य और देखभाल में क्यों महत्वपूर्ण है#

लॉन्च शुरुआत है, अंत नहीं। एक डिजिटल सेवा कुछ महीने बनने में बिताती है और, अगर सफल होती है, वर्षों या दशकों तक चलाए जाने में — और चलाना वह जगह है जहां अधिकांश पैसा जाता है और जहां वास्तव में नुकसान होता है। एक साझा देखभाल रिकॉर्ड, एक ई-प्रिस्क्राइबिंग सिस्टम, या एक मातृत्व नोट्स प्लेटफ़ॉर्म अपना मूल्य केवल तब देता है जब यह चालू, सही, और प्रतिक्रियाशील होता है। जब यह घटता या विफल होता है, तो परिणाम असुविधा नहीं बल्कि विलंबित उपचार, छूटी हुई एलर्जी, रद्द किए गए क्लिनिक, और क्लिनिशियन दबाव में अपरिचित कागज़ वर्कअराउंड में वापस लौटना है।

स्वास्थ्य और देखभाल दिन के 24 घंटे, हफ्ते के सातों दिन चलती है, और इसे रोका नहीं जा सकता। जब एक सुपरमार्केट का चेकआउट सिस्टम विफल होता है, ग्राहक प्रतीक्षा करते हैं; जब एक अस्पताल का रोगी प्रशासन सिस्टम विफल होता है, तो एम्बुलेंस को मोड़ा जा सकता है और वैकल्पिक सूचियां स्थगित की जा सकती हैं। यह लाइव संचालन को एक विशिष्ट भार देता है: डाउनटाइम एक क्लिनिकल-सुरक्षा घटना है, और आप इसका पता कैसे लगाते हैं, बढ़ाते हैं, संप्रेषित करते हैं, और इससे कैसे उबरते हैं इसकी योजना आपके देखभाल कर्तव्य का हिस्सा है। 2017 का WannaCry रैनसमवेयर हमला — जिसने हज़ारों NHS अपॉइंटमेंट और ऑपरेशनों को रद्द करने के लिए मजबूर किया — इसका संदर्भ मामला है कि कैसे एक परिचालन विफलता एक रोगी-सुरक्षा और सार्वजनिक-विश्वास संकट बन जाती है (देखें विषय 1.7 — सूचना प्रशासन, डेटा सुरक्षा और साइबर सुरक्षा)।

नेताओं को लाइव संचालन को ईमानदारी से वित्तपोषित और स्टाफ करने की भी आवश्यकता है। स्वास्थ्य-तकनीक में स्थायी विफलता एक लाइव-गो का जश्न मनाना, टीम को भंग करना, और चल रही सेवा को "पूर्ण" मानना है। बिना स्थायी टीम, बिना निगरानी, और बिना ऑन-कॉल कवर वाली एक लाइव सेवा पैसा नहीं बचा रही है — यह चुपचाप क्लिनिकल जोखिम जमा कर रही है जब तक वह दिन नहीं आता जब यह ज़ोर से विफल होती है। सेवा प्रबंधन वह अनुशासन है जो एक लाइव सेवा को सुरक्षित रखता है, और यह निर्माण जितनी ही कठोरता का हकदार है।

मुख्य अवधारणाएं#

सेवा प्रबंधन और "लाइव" चरण। IT सेवा प्रबंधन (ITSM) IT सेवाओं को उनके पूरे जीवन में डिज़ाइन, चलाने, समर्थन, और सुधारने के अभ्यासों का समूह है। GOV.UK और NHS चरण मॉडल में, लाइव वह चरण है जहां एक सेवा निरंतर संचालन में चलती है — अभी भी पुनरावृत्ति करती, अभी भी वित्तपोषित, अभी भी स्वामित्व में — जब तक इसे रिटायर नहीं किया जाता (देखें विषय 3.5 — डिलीवरी जीवनचक्र)। लाइव कोई विश्राम की स्थिति नहीं है; यह जीवनचक्र का सबसे लंबा और सबसे महंगा हिस्सा है।

ITIL 4। ITIL सबसे व्यापक रूप से उपयोग किया जाने वाला ITSM ढांचा है। इसका वर्तमान संस्करण, ITIL 4, पुराने प्रक्रिया-भारी संस्करणों को एक "सेवा मूल्य प्रणाली" और लचीले अभ्यासों के आसपास फिर से तैयार करता है, और Agile, DevOps, और Lean के साथ प्रतिस्पर्धा करने के बजाय उनके साथ बैठने के लिए डिज़ाइन किया गया है। ITIL को एक शब्दावली और आनुपातिक रूप से अपनाने के लिए अभ्यासों की एक जांच-सूची मानें — एक नौकरशाही नहीं जिसे पूरी तरह से आयात किया जाए।

घटना, समस्या, और परिवर्तन प्रबंधन। घटना प्रबंधन एक अनियोजित व्यवधान के बाद यथासंभव जल्दी सामान्य सेवा बहाल करता है — प्राथमिकता रिकवरी है, निदान नहीं। समस्या प्रबंधन पुनरावृत्ति रोकने के लिए एक या कई घटनाओं के अंतर्निहित कारण की जांच करता है, और ज्ञात त्रुटियों और वर्कअराउंड का एक रिकॉर्ड बनाए रखता है। परिवर्तन प्रबंधन (ITSM अर्थ में) नियंत्रित करता है कि लाइव संपत्ति में परिवर्तनों का आकलन, अनुमोदन, और रिलीज़ कैसे किया जाता है ताकि एक चीज़ को ठीक करना दूसरी न तोड़े। ये तीन अभ्यास परिचालन मूल हैं, और वे परस्पर जुड़े हैं: एक घटना एक समस्या उठा सकती है, जिसका फिक्स एक परिवर्तन के रूप में दिया जाता है।

प्रमुख घटना प्रबंधन और व्यावसायिक निरंतरता। एक प्रमुख घटना एक उच्च-प्रभाव घटना है — एक ट्रस्ट में एक क्लिनिकल सिस्टम बंद — जिसे एक परिभाषित घटना कमांडर, संचार, और क्लिनिकल नेतृत्व के साथ एक घोषित, समन्वित प्रतिक्रिया की आवश्यकता है। व्यावसायिक निरंतरता योजना (BCP) व्यवधान के दौरान स्वीकार्य स्तरों पर देखभाल देते रहने की व्यापक क्षमता है, जिसमें परखे गए क्लिनिकल डाउनटाइम प्रक्रियाएं (सुरक्षित कागज़ फ़ॉलबैक) और आपदा रिकवरी शामिल हैं। स्वास्थ्य और देखभाल में ये वैकल्पिक नहीं हैं: सिस्टम बंद रहते हुए रोगियों को सुरक्षित रखना ही पूरा बिंदु है।

Site reliability engineering, SLI, SLO, SLA, और त्रुटि बजट। Site reliability engineering (SRE), जिसकी उत्पत्ति Google में हुई, संचालन में सॉफ़्टवेयर-इंजीनियरिंग अनुशासन लागू करता है। यह सेवा स्तर संकेतक (SLI) — उपलब्धता या विलंबता जैसा एक मीट्रिक — के साथ सेवा-स्तर उद्देश्य (SLO), उस मीट्रिक के लिए एक आंतरिक लक्ष्य, के विरुद्ध विश्वसनीयता मापता है। एक सेवा-स्तर समझौता (SLA) बाहरी, अक्सर संविदात्मक, वादा है, आमतौर पर आंतरिक SLO से ढीला सेट किया जाता है। 100% और आपके SLO के बीच का अंतर त्रुटि बजट है: अविश्वसनीयता की मात्रा जिसे आप सुविधाएं शिप करना बंद करने और स्थिर करने से पहले खर्च कर सकते हैं। क्लिनिकल सिस्टमों में, SLO को क्लिनिशियनों के साथ सेट किया जाना चाहिए, क्योंकि "स्वीकार्य" डाउनटाइम एक सुरक्षा निर्णय है, केवल एक इंजीनियरिंग निर्णय नहीं।

अवलोकन-योग्यता और निगरानी। अवलोकन-योग्यता एक सिस्टम की आंतरिक स्थिति को इसके बाहरी आउटपुट — लॉग, मीट्रिक, और ट्रेस — से समझने की क्षमता है, ताकि आप समस्याओं का पता लगा और निदान कर सकें, आदर्श रूप से उपयोगकर्ताओं से पहले। निगरानी और अलर्टिंग उस डेटा को ऑन-कॉल लोगों के लिए समयबद्ध संकेतों में बदलते हैं। आप एक ऐसी सेवा सुरक्षित रूप से नहीं चला सकते जिसे आप देख नहीं सकते।

ऑन-कॉल, रोटा, और सेवा डेस्क। ऑन-कॉल रोटा सुनिश्चित करते हैं कि एक सक्षम मानव चौबीसों घंटे अलर्ट का जवाब दे सके; एक 24/7 देखभाल सेटिंग में वे आवश्यक हैं, और उन्हें मानवीय और टिकाऊ होना चाहिए। एक सेवा डेस्क (या हेल्प डेस्क) अंतिम उपयोगकर्ताओं के लिए एकल संपर्क बिंदु है — वह क्लिनिशियन जो लॉग इन नहीं कर सकता, वह रिसेप्शनिस्ट जिसकी बुकिंग स्क्रीन जम गई है — समर्थन प्रदान करता, घटनाओं को लॉग करता, और उन्हें आगे रूट करता है।

DevOps, कॉन्फ़िगरेशन प्रबंधन, और CMDB। DevOps और SRE सिद्धांत "आप इसे बनाते हैं, आप इसे चलाते हैं" उस टीम को चलाने का प्रभार देते हैं जो एक सेवा बनाती है, विकास और संचालन के बीच के अंतर को बंद करते हुए। कॉन्फ़िगरेशन प्रबंधन एक सेवा बनाने वाले घटकों और उनके संबंधों का एक सटीक रिकॉर्ड रखता है, अक्सर एक कॉन्फ़िगरेशन प्रबंधन डेटाबेस (CMDB) में; इसके बिना, कोई भी एक घटना के दौरान "यह परिवर्तन क्या प्रभावित करेगा?" का सुरक्षित रूप से उत्तर नहीं दे सकता।

संचालन-बनाम-निर्माण और बंद करना। संगठन निर्माण वित्तपोषण (नई क्षमता बनाना) को संचालन वित्तपोषण (जो मौजूद है उसे चलाना) से अलग करते हैं। संचालन को कम-वित्तपोषित करना अधिकांश परिचालन विफलता की संरचनात्मक जड़ है। और हर सेवा अंततः बंद करने तक पहुंचती है — सुरक्षित रिटायरमेंट, प्रतिधारण कानून के तहत डेटा माइग्रेट या संग्रहीत, और उपयोगकर्ता पुनर्निर्देशित — जो अपने आप में एक परिचालन अनुशासन है।

सर्वोत्तम प्रथाएं#

1. "संचालन" को एक बची हुई चीज़ के रूप में नहीं, एक प्रथम-श्रेणी प्रतिबद्धता के रूप में वित्तपोषित और स्टाफ करें। लाइव-गो से पहले सेवा के परिचालन जीवन के लिए बजट बनाएं — निगरानी, ऑन-कॉल, सेवा डेस्क, सुरक्षा पैचिंग, और निरंतर पुनरावृत्ति — और इसे अगले चमकदार निर्माण द्वारा छापे से बचाएं। यह उद्योग अंगूठे का नियम कि एक सिस्टम चलाना इसके जीवन में इसे बनाने से कहीं अधिक खर्च करता है स्वास्थ्य में भी लागू होता है। निर्माण वित्तपोषण और कोई संचालन वित्तपोषण न वाली एक सेवा एक लॉन्च तारीख वाला एक क्लिनिकल जोखिम है।

2. "इसे ops पर दीवार पार फेंकना" विरोधी-पैटर्न से बचें। एक परियोजना टीम को एक सेवा बनाने और इसे एक अलग संचालन टीम को सौंपने न दें जिसने इसे कभी बनते नहीं देखा। "आप इसे बनाते हैं, आप इसे चलाते हैं" लागू करें: उस टीम को जवाबदेह रखें जो सेवा को इसकी विश्वसनीयता के लिए समझती है, या कम से कम साझा ऑन-कॉल और एक वारंटी अवधि के साथ एक सोच-समझकर, दस्तावेज़ीकृत सेवा-संक्रमण चलाएं। निर्माण और संचालन के बीच की दीवार वह जगह है जहां ज्ञान, स्वामित्व, और सुरक्षा गिर जाते हैं।

3. क्लिनिशियनों के साथ SLO सेट करें और एक त्रुटि बजट प्रबंधित करें। हर सेवा के लिए "पर्याप्त विश्वसनीय" का अर्थ मापने योग्य SLI और SLO के रूप में परिभाषित करें, और उन्हें उन क्लिनिशियनों के साथ संयुक्त रूप से सेट करें जो परिणाम उठाते हैं — एक आपातकालीन-विभाग सिस्टम के लिए उपलब्धता लक्ष्य शुद्ध रूप से एक तकनीकी विकल्प नहीं हैं। सुविधाओं को शिप करने और स्थिर रहने के बीच शाश्वत तनाव को मध्यस्थता करने के लिए त्रुटि बजट का उपयोग करें: जब विश्वसनीयता खर्च हो जाती है, तो रुकें और स्थिर करें। बाहरी SLA को आंतरिक SLO से ढीला रखें ताकि आपके पास एक वादे का उल्लंघन करने से पहले कार्य करने की जगह हो।

4. सेवा को बड़ा बनाने से पहले इसे अवलोकन योग्य बनाएं। लॉगिंग, मीट्रिक, और ट्रेसिंग इंस्ट्रूमेंट करें, और डैशबोर्ड और अलर्ट बनाएं जो उपयोगकर्ता और क्लिनिशियन के अनुभव को प्रतिबिंबित करते हैं, केवल सर्वर स्वास्थ्य नहीं। उन लक्षणों पर अलर्ट करें जो मायने रखते हैं (रोगियों को बुक नहीं किया जा सकता) हर अंतर्निहित झिलमिलाहट के बजाय, अलर्ट थकान से बचने के लिए जो उत्तरदाताओं को पेज नज़रअंदाज़ करना सिखाती है। आप एक ऐसी सेवा को सुरक्षित नहीं रख सकते जिसकी विफलताओं के बारे में आप क्रोधित क्लिनिशियनों से सीखते हैं।

5. अनुशासित घटना, समस्या, और परिवर्तन प्रबंधन चलाएं — आनुपातिक रूप से। घटनाओं को स्पष्ट गंभीरता स्तर, प्रतिक्रिया लक्ष्य, प्रमुख के लिए एक घटना कमांडर, और प्रतिक्रिया के दौरान एक एकल सत्य स्रोत दें। गंभीर घटनाओं को दोष-मुक्त घटना-पश्चात समीक्षाओं और एक समस्या-प्रबंधन प्रक्रिया में फीड करें जो बार-बार सर्वर पुनः आरंभ करने के बजाय मूल कारणों को ठीक करती है। एक सही आकार की प्रक्रिया के माध्यम से परिवर्तनों को नियंत्रित करें — नियमित कम-जोखिम काम के लिए हल्के, मानक, पूर्व-अनुमोदित परिवर्तन; वास्तव में जोखिम भरे परिवर्तनों के लिए केवल एक परिवर्तन सलाहकार समीक्षा — ताकि प्रशासन सुरक्षा की रक्षा करे बिना एक अड़चन बने जो लोगों को इसे बायपास करने के लिए ललचाती है।

6. प्रमुख घटनाओं और क्लिनिकल डाउनटाइम का पूर्वाभ्यास करें, केवल उन्हें दस्तावेज़ीकृत न करें। व्यावसायिक-निरंतरता और क्लिनिकल डाउनटाइम प्रक्रियाओं को लिखें, परखें, और नियमित रूप से अभ्यास करें: देखभाल कागज़ पर कैसे जारी रहती है, स्टाफ को कैसे बताया जाता है कि सिस्टम बंद है, रिकवरी पर डेटा कैसे मिलान किया जाता है, और एक प्रमुख घटना कौन घोषित और कमांड करता है। अपरीक्षित योजनाएं उस दिन विफल होती हैं। इसे अपने क्लिनिकल जोखिम प्रबंधन और खतरा लॉग से स्पष्ट रूप से जोड़ें (देखें विषय 1.6 — क्लिनिकल सुरक्षा और जोखिम प्रबंधन), क्योंकि डाउनटाइम एक ऐसा क्लिनिकल खतरा है जिसके शमन का आप पूर्वाभ्यास कर सकते हैं।

7. घटना-पश्चात सीखने को दोष-मुक्त और प्रणालीगत मानें। हर महत्वपूर्ण घटना के बाद, एक समीक्षा चलाएं जो पूछती है कि सिस्टम ने विफलता की अनुमति कैसे दी, किसे दोष देना है नहीं — क्योंकि दोष रिपोर्टिंग को भूमिगत करता है और नुकसान को दोहराता है। कार्रवाइयां कैप्चर करें, स्वामी सौंपें, और उन्हें समापन तक ट्रैक करें; पैटर्न को समस्या प्रबंधन और डिज़ाइन में फीड करें। एक सीखने वाली संस्कृति एक रोगी-सुरक्षा नियंत्रण है, क्लिनिकल घटना रिपोर्टिंग की "न्यायसंगत संस्कृति" को प्रतिबिंबित करते हुए।

8. एक सटीक कॉन्फ़िगरेशन रिकॉर्ड रखें और पूरी संपत्ति प्रबंधित करें। एक CMDB या समकक्ष सूची बनाए रखें कि क्या चलता है, क्या किस पर निर्भर करता है, कौन से संस्करण तैनात हैं, और हर सेवा का स्वामी कौन है, ताकि एक घटना के दौरान आप मिनटों में "यह क्या प्रभावित करता है?" का उत्तर दे सकें। यह सुरक्षित परिवर्तन, सुरक्षा पैचिंग, और लाइसेंसिंग को आधार देता है, और यह वह जगह है जहां अधिकांश बड़ी NHS संपत्ति सबसे कमज़ोर है। एक अज्ञात, बिना-पैच किया सिस्टम एक आउटेज और एक साइबर-सुरक्षा घटना दोनों की प्रतीक्षा में है (देखें विषय 1.7)।

9. ऑन-कॉल को टिकाऊ बनाएं और मानव का समर्थन करें। ऐसे ऑन-कॉल रोटा डिज़ाइन करें जो पर्याप्त रूप से स्टाफ, निष्पक्ष रूप से मुआवज़ा प्राप्त, और मानवीय हों, स्पष्ट वृद्धि और यथार्थवादी अपेक्षाओं के साथ — बर्नआउट में उत्तरदाता ठीक उन्हीं क्षणों में धीमे, त्रुटि-प्रवण निर्णय लेते हैं जब यह सबसे अधिक मायने रखता है। सेवा डेस्क को एक 24/7 क्लिनिकल कार्यबल की वास्तविक मांग तक संसाधन दें, और फ्रंटलाइन स्टाफ को समस्याओं की रिपोर्ट करने के लिए एक तेज़, सम्मानित मार्ग दें। आपके समर्थन की गुणवत्ता वह गुणवत्ता है जो देखभाल स्टाफ आपकी सेवा से अनुभव करता है।

10. बंद करने की योजना एक नियंत्रित संचालन के रूप में बनाएं। सेवा के लाइव रहते हुए, तय करें कि इसे अंततः कैसे रिटायर किया जाएगा: रिकॉर्ड-प्रतिधारण कानून के तहत डेटा माइग्रेशन या संग्रहीकरण, उपयोगकर्ता पुनर्निर्देशन, क्लिनिशियन सूचना, और खतरा लॉग और ऑडिट ट्रेल का संरक्षण। एक अनियोजित रिटायरमेंट डेटा और उपयोगकर्ताओं को फंसाता है और वैधानिक प्रतिधारण कर्तव्यों का उल्लंघन कर सकता है। एक नियोजित एक ऑडिट योग्य परिचालन परियोजना है, प्रतिस्थापन आने पर एक भागदौड़ नहीं।

आपकी टीम के साथ चर्चा करने के लिए प्रश्न#

1. जब एक महत्वपूर्ण क्लिनिकल सिस्टम बैंक हॉलिडे पर रात 3 बजे बंद हो जाता है, तो ठीक-ठीक कौन क्या करता है — और क्या हमने कभी इसे परखा है? यह प्रश्न एक दस्तावेज़ीकृत योजना और एक वास्तविक क्षमता के बीच के अंतर को मजबूर करता है। स्वास्थ्य और देखभाल में, डाउनटाइम एक क्लिनिकल घटना है: व्यावहारिक प्रश्न यह हैं कि किसे पेज किया जाता है, वे कितनी तेज़ी से जवाब देते हैं, एक प्रमुख घटना घोषित करने का अधिकार किसके पास है, क्लिनिकल स्टाफ को डाउनटाइम प्रक्रियाओं में स्विच करने के लिए कैसे बताया जाता है, रोगी कागज़ पर कैसे सुरक्षित रहते हैं, और रिकवरी पर डेटा कैसे मिलान किया जाता है। बहस करें कि क्या आपके ऑन-कॉल रोटा में वास्तव में असामाजिक घंटों और छुट्टियों में सक्षम कवर है, या क्या यह एक थके हुए व्यक्ति तक पतला हो जाता है जब जोखिम सबसे अधिक होता है। विचार करें कि क्या क्लिनिशियन डाउनटाइम प्रक्रिया जानते हैं और कभी इसका पूर्वाभ्यास किया है, या क्या यह एक बाइंडर में रहती है जिसे किसी ने नहीं खोला। एक अच्छा, ईमानदार उत्तर एक परखी गई प्रतिक्रिया का वर्णन करता है — नामित भूमिकाओं, पिछले साल में एक वास्तविक अभ्यास, और सीखे गए सबकों पर कार्रवाई के साथ — एक नीति दस्तावेज़ नहीं जिसने कभी एक आउटेज नहीं देखा। जहां ईमानदार उत्तर है "हम वास्तव में नहीं जानते", वही स्वयं बोर्ड के सामने लाने के लिए सबसे महत्वपूर्ण खोज है।

2. क्या हम वास्तव में "संचालन" को वित्तपोषित और स्टाफ कर रहे हैं, या हमने लाइव-गो का जश्न मनाया और चुपचाप चले गए? एक सेवा की अधिकांश लागत और क्लिनिकल जोखिम लॉन्च के बाद रहते हैं, फिर भी वित्तपोषण मॉडल नई चीज़ें बनाने को पुरस्कृत करते हैं और पुरानी चीज़ों को चलाना भूखा रखते हैं। बहस करने योग्य तनाव निर्माण वित्तपोषण के संरचनात्मक खिंचाव और वर्षों तक एक लाइव सेवा की निगरानी, पैचिंग, समर्थन, और पुनरावृत्ति के अनाकर्षक, आवश्यक काम के बीच है। अपनी लाइव संपत्ति को ईमानदारी से देखें: कितनी सेवाओं का एक नामित स्वामी, एक वित्तपोषित टीम, वर्तमान सुरक्षा पैच, और काम कर रही निगरानी है — और कितनी अनाथ हैं, असमर्थित सॉफ़्टवेयर पर चल रही हैं, बिना किसी जवाबदेह के? "इसे ops पर दीवार पार फेंकना" पैटर्न पर विचार करें और क्या हर सेवा चलाने वाले लोग समझते हैं कि यह कैसे बनाई गई थी। एक अच्छा उत्तर संरक्षित संचालन बजट, परिचालन जीवन के लिए नामित सेवा स्वामियों, और एक परित्याग के बजाय एक सोच-समझकर सेवा-संक्रमण की ओर इशारा कर सकता है, और यह अनाथ सेवाओं को ईमानदारी से नाम दे सकता है ताकि उन्हें अपनाया, बदला, या रिटायर किया जा सके विफल होने के लिए छोड़ने के बजाय।

3. हम कैसे तय करते हैं कि "पर्याप्त विश्वसनीय" का क्या अर्थ है — और किसकी राय होती है? विश्वसनीयता मुफ़्त नहीं है, और उपलब्धता का एक अतिरिक्त नौ पीछा करने में उस नुकसान से अधिक खर्च हो सकता है जिसे यह रोकता है; लेकिन क्लिनिकल सिस्टमों में, "स्वीकार्य" डाउनटाइम एक सुरक्षा निर्णय है जिसे इंजीनियर अकेले नहीं ले सकते। यह प्रश्न पूछता है कि क्या आपके पास स्पष्ट SLI और SLO हैं, क्या उन्हें उन क्लिनिशियनों और परिचालन नेताओं के साथ सेट किया गया था जो परिणाम उठाते हैं, और क्या आप सुविधाओं को शिप करने और स्थिर रहने को संतुलित करने के लिए एक त्रुटि बजट जैसी किसी चीज़ का उपयोग करते हैं। उस आंतरिक लक्ष्य के बीच के अंतर पर बहस करें जिसे आप प्रबंधित करते हैं और बाहरी SLA जिसका आप वादा करते हैं, और क्या आपकी निगरानी वह मापती है जो क्लिनिशियन वास्तव में अनुभव करते हैं या केवल वह जो सर्वर रिपोर्ट करते हैं। विचार करें कि क्या "हम 99.9% का लक्ष्य रखते हैं" का कोई दांत है — एक परिभाषित माप, उल्लंघन होने पर एक परिणाम, एक स्वामी जो कार्य करता है। एक अच्छा उत्तर एक विश्वसनीयता लक्ष्य को एक क्लिनिकल-सुरक्षा तर्क से जोड़ता है, दिखाता है कि मीट्रिक मापा और स्वामित्व में है, और वर्णन करता है कि टीम बजट खर्च होने पर अलग तरीके से क्या करती है, एक स्लाइड पर एक संख्या के बजाय जिसका कोई प्रबंधन नहीं करता।

4. क्या हम वास्तव में जानते हैं कि हम क्या चलाते हैं — और क्या हम एक घटना के बीच में "यह परिवर्तन क्या प्रभावित करेगा?" का उत्तर दे सकते हैं? अधिकांश बड़ी स्वास्थ्य और देखभाल संपत्तियां ठीक वहीं सबसे कमज़ोर हैं जहां यह सबसे अधिक दर्द देता है: कोई भी यह सटीक, वर्तमान चित्र नहीं रखता कि क्या चलता है, क्या किस पर निर्भर करता है, कौन से संस्करण तैनात हैं, और हर सेवा का स्वामी कौन है। यह प्रश्न जांचता है कि क्या आप एक कॉन्फ़िगरेशन रिकॉर्ड — एक CMDB या समकक्ष — बनाए रखते हैं, या क्या वह ज्ञान मुट्ठी भर लोगों के सिर और एक दशक के अदस्तावेज़ीकृत एकीकरणों में रहता है। वास्तविक परिणामों पर बहस करें: एक परिवर्तन जो चुपचाप एक डाउनस्ट्रीम सिस्टम तोड़ता है, एक सुरक्षा पैच जिसे लागू नहीं किया जा सकता क्योंकि कोई नहीं जानता कि यह क्या छुएगा, एक असमर्थित सर्वर जो केवल तब खोजा जाता है जब यह विफल होता है या शोषित होता है। तनाव यह है कि कॉन्फ़िगरेशन प्रबंधन अनाकर्षक, कभी पूर्ण नहीं, और टालने में आसान है, फिर भी यह सुरक्षित परिवर्तन, पैचिंग, लाइसेंसिंग, और साइबर-लचीलापन को समान रूप से आधार देता है — वही अंधा स्थान जिसने WannaCry को एक संकट बना दिया। एक ईमानदार उत्तर एक बनाए रखी गई सूची का वर्णन करता है जिसमें स्वामी और निर्भरताएं हैं जिन पर लोग भरोसा करते हैं और घटनाओं के दौरान उपयोग करते हैं, और संपत्ति के उन हिस्सों को नाम देता है जो अभी भी अंधेरे में हैं, यह दावा करने के बजाय कि कोई भी बड़ा संगठन वास्तव में नहीं रखता।

5. जब कुछ गलत होता है, तो क्या हम सीखते हैं या दोष देने के लिए किसी को खोजते हैं? आपकी घटना समीक्षाओं की संस्कृति तय करती है कि क्या वही नुकसान फिर से होता है। यह प्रश्न पूछता है कि क्या गंभीर घटनाएं एक दोष-मुक्त, प्रणालीगत समीक्षा को ट्रिगर करती हैं जो पूछती है कि सिस्टम ने विफलता की अनुमति कैसे दी — या क्या वे चुपचाप दोष देने के लिए एक व्यक्ति की खोज करती हैं, जो रिपोर्टिंग को भूमिगत करता है और पुनरावृत्ति की गारंटी देता है। बहस करें कि क्या निकट-चूक और छोटी विफलताएं बिल्कुल सामने आती हैं, या केवल वे आउटेज जो छुपाने के लिए बहुत बड़ी हैं; क्या समीक्षा कार्रवाइयों को स्वामी सौंपे जाते हैं और समापन तक ट्रैक किया जाता है, या लिखा और भुला दिया जाता है; और क्या पैटर्न समस्या प्रबंधन और डिज़ाइन में वापस फीड होते हैं। क्लिनिकल घटना रिपोर्टिंग और "न्यायसंगत संस्कृति" के समानांतर पर विचार करें: वही संगठन रोगी-सुरक्षा घटनाओं के लिए एक परिपक्व, दोष-मुक्त रुख रख सकता है फिर भी IT विफलताओं के लिए एक दंडात्मक, या इसके विपरीत। एक अच्छा उत्तर साक्ष्य के साथ एक सीखने वाली संस्कृति दिखाता है — समीक्षाएं जिन्होंने सिस्टम बदला, कार्रवाइयां बंद, पुनरावृत्ति गिरती — और इसकी एक ईमानदार स्वीकृति कि डर अभी भी कहां रिपोर्टिंग को दबाता है, क्योंकि एक सीखने वाली संस्कृति स्वयं एक रोगी-सुरक्षा नियंत्रण है, कोई नरम अतिरिक्त नहीं।

6. क्या हमने तय किया है कि इस सेवा को अंततः कैसे रिटायर किया जाएगा — जबकि यह इसकी योजना बनाने के लिए अभी भी जीवित है? हर सेवा अंततः बदली या बंद की जाती है, फिर भी बंद करना लगभग हमेशा एक बाद का विचार है, जब उत्तराधिकारी आता है और पुराना सिस्टम पहले से एक बाधा है तब भागदौड़ में किया जाता है। यह प्रश्न पूछता है कि क्या, हर लाइव सेवा के लिए, आपके पास सुरक्षित रिटायरमेंट के लिए एक योजना है: रिकॉर्ड-प्रतिधारण कानून के तहत डेटा माइग्रेट या संग्रहीत, उपयोगकर्ता पुनर्निर्देशित, क्लिनिशियन सूचित, और खतरा लॉग और ऑडिट ट्रेल संरक्षित। इसे गलत करने के विशिष्ट स्वास्थ्य और देखभाल जोखिमों पर बहस करें — फंसे हुए रिकॉर्ड जो वैधानिक प्रतिधारण कर्तव्यों का उल्लंघन करते हैं, अनाथ डेटा जिसे कोई अभिगम नहीं कर सकता, एक "अस्थायी" विरासत सिस्टम जो वर्षों तक बना रहता है बिना-पैच क्योंकि कोई इसके अंत का स्वामी नहीं है। विचार करें कि राष्ट्रीय और उद्यम संपत्तियों में, दशकों के क्लिनिकल रिकॉर्ड एक ऐसे सिस्टम के अंदर बैठ सकते हैं जिसे बिना एक भी कानूनी रूप से आवश्यक रिकॉर्ड खोए बंद किया जाना चाहिए। एक ईमानदार उत्तर रिटायरमेंट को एक नामित, वित्तपोषित, ऑडिट योग्य संचालन के रूप में मानता है जो लाइव-गो से नियोजित है, बाद में खोजी जाने वाली एक लागत नहीं, और कम से कम एक सेवा की ओर इशारा कर सकता है जिसका जीवन-अंत पहले से तय है, टाला नहीं गया।

व्यवहार में: एक स्वास्थ्य और देखभाल उदाहरण#

एक एकीकृत देखभाल प्रणाली (ICS) एक क्षेत्र में अस्पताल क्लिनिशियनों, GP, सामुदायिक टीमों, और घंटों-के-बाहर सेवाओं द्वारा उपयोग किया जाने वाला एक साझा देखभाल रिकॉर्ड चलाती है। यह दो साल पहले लाइव हुआ था; निर्माण कार्यक्रम बंद हो गया है और अब एक स्थायी उत्पाद-और-संचालन टीम इसका स्वामित्व रखती है। उस टीम ने सेवा प्रबंधन कठिन तरीके से सीखा।

शुरुआत में, रिकॉर्ड के पास केवल सर्वर अपटाइम की निगरानी थी। एक सर्दी की शाम, सर्वर "हरे" थे जबकि एक विफल हो रहा एकीकरण चुपचाप GP दवा अपडेट को बहने से रोक देता है — इसलिए अस्पताल क्लिनिशियनों ने एक फार्मासिस्ट के नोटिस करने और सेवा डेस्क को फोन करने से पहले कई घंटों तक बासी दवा सूचियां देखीं। घटना-पश्चात समीक्षा दोष-मुक्त और प्रणालीगत थी: इसने पाया कि वास्तविक समस्या क्लिनिशियन के अनुभव को प्रतिबिंबित करने वाले एक SLI की अनुपस्थिति थी। टीम ने अंत-से-अंत अवलोकन-योग्यता जोड़ी, एक क्लिनिकल सुरक्षा अधिकारी के साथ संयुक्त रूप से सहमत डेटा-ताज़गी के लिए एक SLO, और एक अलर्ट जो अपडेट सुरक्षा सीमा से आगे पिछड़ने पर ऑन-कॉल को पेज करता है। इस खतरे को क्लिनिकल जोखिम खतरा लॉग में जोड़ा गया था (विषय 1.6)।

फिर उन्होंने अपने अभ्यासों को सही आकार दिया। नियमित, कम-जोखिम कॉन्फ़िगरेशन अपडेट तेज़ रोलबैक के साथ एक स्वचालित पाइपलाइन के माध्यम से भेजे गए मानक पूर्व-अनुमोदित परिवर्तन बन गए; केवल वास्तव में जोखिम भरे परिवर्तन क्लिनिकल प्रतिनिधित्व के साथ एक साप्ताहिक परिवर्तन समीक्षा में जाते हैं। एक वास्तविक 24/7 मांग तक संसाधित एक सेवा डेस्क द्वारा समर्थित एक मानवीय ऑन-कॉल रोटा रातों और छुट्टियों को कवर करता है। महत्वपूर्ण रूप से, उन्होंने एक क्लिनिकल डाउनटाइम प्रक्रिया लिखी और अब साल में दो बार इसका अभ्यास करते हैं: मुख्य रिकॉर्ड की एक केवल-पढ़ने योग्य कैश की गई प्रति, एक कागज़ फ़ॉलबैक, क्लिनिशियनों को बताने के लिए एक SMS कैस्केड कि सिस्टम घट रहा है, और रिकवरी पर एक मिलान कदम। जब पिछले वसंत में एक डेटा-सेंटर पावर फॉल्ट ने चालीस मिनट के लिए मुख्य सिस्टम को ऑफ़लाइन कर दिया, तो देखभाल परखे गए फ़ॉलबैक पर जारी रही, घटना कमांडर ने एक शांत समन्वित प्रतिक्रिया चलाई, और कोई रोगी नुकसान नहीं उठा। बोर्ड ने क्लिनिकल-सुरक्षा उपायों से बंधी एक विश्वसनीयता रिपोर्ट देखी, कोई अस्पष्ट आश्वासन नहीं — और सेवा का स्वामित्व अंतिम बंद करने तक नामित और वित्तपोषित है।

क्षेत्र दृष्टिकोण#

स्टार्टअप#

एक छोटी स्वास्थ्य-तकनीक कंपनी के पास अक्सर कोई अलग संचालन फ़ंक्शन नहीं होता, इसलिए "आप इसे बनाते हैं, आप इसे चलाते हैं" एक आकांक्षा के बजाय डिफ़ॉल्ट है — वही इंजीनियर जिन्होंने कोड लिखा वे पेजर रखते हैं। फायदा तेज़ फीडबैक और काम फेंकने के लिए कोई दीवार नहीं है; खतरा एक दो-व्यक्ति ऑन-कॉल रोटा है जो न तो टिकाऊ है न सुरक्षित, और निगरानी जो "क्या सर्वर चालू है?" पर रुकती है। स्टार्टअप को पहले NHS ग्राहक से SLO, बुनियादी अवलोकन-योग्यता, दोष-मुक्त घटना-पश्चात समीक्षा, और एक लिखित डाउनटाइम प्रक्रिया अपनानी चाहिए, क्योंकि एक क्लिनिकल आउटेज अनुबंध और कंपनी दोनों को समाप्त कर सकता है। बिना ITIL समारोह के भी, इरादा — सेवा देखें, तेज़ी से जवाब दें, प्रणालीगत रूप से सीखें, विफल होने पर रोगियों को सुरक्षित रखें — स्वास्थ्य में गैर-परक्राम्य है।

छोटा व्यवसाय#

एक स्थापित छोटा प्रदाता — एक GP प्रैक्टिस, एक सामुदायिक फार्मेसी, एक केयर होम, या एक एकल-साइट क्लिनिक — हर दिन लाइव क्लिनिकल सिस्टम चलाता है लेकिन आमतौर पर कोई समर्पित IT फ़ंक्शन और कोई नहीं जिसका काम सेवा प्रबंधन हो। यहां "संचालन" क्लिनिकल और प्रशासनिक काम के हाशिये में निचोड़ा जाता है, ऑन-कॉल वास्तव में "प्रैक्टिस मैनेजर का मोबाइल" है, और निगरानी एक क्लिनिशियन है जो नोटिस करता है कि बुकिंग स्क्रीन जम गई है। व्यावहारिक प्राथमिकताएं वे कुछ चीज़ें हैं जो रोगियों को सुरक्षित रखती हैं: एक लिखित, अभ्यास की गई डाउनटाइम प्रक्रिया (प्रैक्टिस कागज़ पर कैसे परामर्श करती है और बाद में मिलान करती है), हर आपूर्तिकर्ता तक वृद्धि करने के लिए एक ज्ञात मार्ग जब एक होस्ट किया गया सिस्टम विफल होता है, और उन SLA पर स्पष्टता जो वे आपूर्तिकर्ता वास्तव में देते हैं। स्टार्टअप चरण से आगे एक छोटा स्वतंत्र स्वास्थ्य-तकनीक आपूर्तिकर्ता दर्पण छवि का सामना करता है — इस पर निर्भर वास्तविक ग्राहक लेकिन पतला परिचालन कवर — और तंग नकदी के बावजूद विश्वसनीय समर्थन घंटे और घटना प्रतिक्रिया प्रदान करनी चाहिए। देखभाल का कर्तव्य एक बड़े ट्रस्ट के समान है; संसाधन नहीं, इसलिए अनुशासन ITIL पूर्णता पर सुरक्षा-महत्वपूर्ण बुनियादी बातों की निर्ममता से प्राथमिकता है।

बड़ा संगठन#

एक NHS ट्रस्ट या बड़ा आपूर्तिकर्ता सेवा प्रबंधन को अपने सबसे पूर्ण रूप में चलाता है: एक औपचारिक सेवा डेस्क, ITIL-संरेखित घटना/समस्या/परिवर्तन अभ्यास, परिवर्तन सलाहकार बोर्ड, प्रमुख-घटना और व्यावसायिक-निरंतरता योजनाएं, और अक्सर एक 24/7 संचालन केंद्र। विशिष्ट चुनौती कमज़ोर कॉन्फ़िगरेशन रिकॉर्ड, बिना-पैच सिस्टम, और अस्पष्ट स्वामित्व वाली एक फैली हुई विरासत संपत्ति है — वे स्थितियां जिन्होंने WannaCry को एक संकट बना दिया। क्लासिक विफलताएं इतनी भारी परिवर्तन प्रक्रियाएं हैं कि स्टाफ उन्हें बायपास करता है, और "संचालन" को अगले निर्माण को वित्तपोषित करने के लिए स्थायी रूप से भूखा रखा जाता है। उद्यम के पास अवलोकन-योग्यता, टिकाऊ ऑन-कॉल, और परखी गई निरंतरता को ठीक से करने के संसाधन हैं, इसलिए कार्य अभ्यासों को आनुपातिक और वास्तव में क्लिनिकल रूप से स्वामित्व में रखना है बजाय एक कागज़ी अनुष्ठान के जो झूठा आश्वासन देता है।

सरकार#

एक राष्ट्रीय निकाय ऐसी सेवाएं संचालित करता है जो लाखों को छू सकती हैं, इसलिए एक आउटेज संसदीय और सार्वजनिक-विश्वास परिणामों वाली एक राष्ट्रीय घटना है, और विश्वसनीयता लक्ष्य सार्वजनिक जवाबदेही के मामले हैं। सरकारी डिलीवरी ITSM को GOV.UK Service Manual की इस अपेक्षा के साथ जोड़ती है कि लाइव सेवाओं को उचित रूप से संचालित, निगरानी, और पुनरावृत्त किया जाता है — लॉन्च पर जमा नहीं किया जाता — और रिकॉर्ड प्रतिधारण और साइबर-सुरक्षा (NCSC, DSPT) के आसपास वैधानिक कर्तव्यों के साथ। व्यय नियंत्रण और बहु-वर्षीय वित्तपोषण समझौते आकार देते हैं कि "संचालन" वित्तपोषण कैसा दिखता है, और विशुद्ध पैमाना व्यावसायिक निरंतरता, समन्वित प्रमुख-घटना प्रतिक्रिया, और दशकों के रिकॉर्ड वाले विरासत राष्ट्रीय सिस्टमों के सुरक्षित बंद करने पर दांव बढ़ाता है। समझौता आश्वासन और लचीलापन बनाम गति और लागत है, जांच के तहत खुले में हल किया गया।

सामान्य विफलता मोड#

• इसे ops पर दीवार पार फेंकना। एक निर्माण टीम एक सेवा को एक संचालन टीम को सौंपती है जिसने इसे कभी बनते नहीं देखा; ज्ञान, स्वामित्व, और सुरक्षा अंतराल में गिर जाते हैं। उपाय: "आप इसे बनाते हैं, आप इसे चलाते हैं," या एक वारंटी अवधि और साझा ऑन-कॉल के साथ एक सोच-समझकर संक्रमण।
• अनाथ लाइव सेवा। परियोजना बंद होती है, टीम भंग होती है, संचालन वित्तपोषण वाष्पित होता है; सेवा सड़ जाती है, बिना-पैच रहती है, और चुपचाप क्लिनिकल और साइबर जोखिम जमा करती है। उपाय: परिचालन जीवन के लिए नामित सेवा स्वामी और संरक्षित संचालन बजट।
• सर्वरों की निगरानी, सेवा की नहीं। सब कुछ "हरा" है जबकि क्लिनिशियन बासी या गायब डेटा देखते हैं। उपाय: SLI जो उपयोगकर्ता और क्लिनिशियन के अनुभव को प्रतिबिंबित करते हैं, महत्वपूर्ण लक्षणों पर अलर्टिंग के साथ।
• अपरीक्षित निरंतरता योजनाएं। एक क्लिनिकल डाउनटाइम प्रक्रिया कागज़ पर मौजूद है लेकिन कभी अभ्यास नहीं की गई, इसलिए यह उस दिन विफल होती है। उपाय: नियमित रूप से प्रमुख-घटना और डाउनटाइम योजनाओं का अभ्यास करें और जो टूटता है उसे ठीक करें।
• दोष-संचालित घटना समीक्षा। दोष खोजना रिपोर्टिंग को भूमिगत करता है और नुकसान को दोहराता है। उपाय: ट्रैक की गई कार्रवाइयों के साथ दोष-मुक्त, प्रणालीगत घटना-पश्चात सीखना।
• परिवर्तन प्रक्रिया थिएटर। एक परिवर्तन बोर्ड इतना भारी कि टीमें इसके आसपास रूट करती हैं, या इतना हल्का कि जोखिम भरे परिवर्तन बिना जांचे शिप होते हैं। उपाय: सही आकार — मानक परिवर्तनों को पूर्व-अनुमोदित करें, वास्तव में जोखिम भरे लोगों के लिए समीक्षा आरक्षित रखें।
• कोई कॉन्फ़िगरेशन रिकॉर्ड नहीं। एक घटना के दौरान कोई "यह परिवर्तन क्या प्रभावित करेगा?" का उत्तर नहीं दे सकता। उपाय: स्वामित्व और निर्भरताओं के साथ एक CMDB या समकक्ष बनाए रखें।

परिपक्वता मॉडल#

जांच-सूची#

• हर लाइव सेवा का एक नामित स्वामी और इसके परिचालन जीवन के लिए एक संरक्षित संचालन बजट है।
• हर सेवा चलाने वाली टीम समझती है कि इसे कैसे बनाया गया था (या वारंटी और साझा ऑन-कॉल के साथ एक दस्तावेज़ीकृत संक्रमण मौजूद है)।
• SLI और SLO परिभाषित हैं, और क्लिनिकल सिस्टमों के लक्ष्य क्लिनिशियनों के साथ सेट किए गए थे; बाहरी SLA आंतरिक SLO से ढीले हैं।
• अवलोकन-योग्यता (लॉग, मीट्रिक, ट्रेस) और लक्षण-आधारित अलर्टिंग क्लिनिशियन और उपयोगकर्ता के अनुभव को प्रतिबिंबित करते हैं, केवल सर्वर स्वास्थ्य नहीं।
• घटना प्रबंधन में गंभीरता स्तर, प्रतिक्रिया लक्ष्य, एक घटना-कमांडर भूमिका, और प्रतिक्रिया के दौरान एक एकल सत्य स्रोत है।
• समस्या प्रबंधन मूल कारणों को ठीक करता है; घटना-पश्चात समीक्षाएं दोष-मुक्त हैं और उनकी कार्रवाइयां समापन तक ट्रैक की जाती हैं।
• परिवर्तन प्रबंधन सही-आकार का है: मानक परिवर्तन पूर्व-अनुमोदित और स्वचालित; केवल जोखिम भरे परिवर्तनों की समीक्षा की जाती है, क्लिनिकल इनपुट के साथ।
• व्यावसायिक-निरंतरता और क्लिनिकल डाउनटाइम प्रक्रियाएं लिखी गई हैं, खतरा लॉग से जुड़ी हैं, और कम से कम वार्षिक रूप से अभ्यास की जाती हैं।
• ऑन-कॉल रोटा पर्याप्त रूप से स्टाफ, मानवीय, और निष्पक्ष रूप से मुआवज़ा प्राप्त हैं; सेवा डेस्क वास्तविक 24/7 मांग तक संसाधित है।
• एक कॉन्फ़िगरेशन रिकॉर्ड (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), और 2017 WannaCry घटना से सबक (देखें विषय 1.7)।
• ISO/IEC 20000 (IT सेवा प्रबंधन) और ISO 22301 (व्यावसायिक निरंतरता प्रबंधन प्रणाली)।
• DevOps Research and Assessment (DORA) — डिलीवरी और परिचालन प्रदर्शन को जोड़ने वाली क्षमताएं (निगरानी, परिवर्तन, विश्वसनीयता)।
• नेतृत्व को परिचालन और विश्वसनीयता रिपोर्टिंग के लिए OKR और KPI (देखें विषय 10.0 — उद्देश्य और मुख्य परिणाम (OKRs))।

संदर्भ#

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/