Devops Master輕量級ITSM技術(shù)白皮書

1、EXIN DevOps 白皮書DevOps 輕量級 IT 服務(wù)管理 工作模板目錄 HYPERLINK l _bookmark0 1、概述3 HYPERLINK l _bookmark1 2、計(jì)劃5 HYPERLINK l _bookmark2 3、要求、設(shè)計(jì)9 HYPERLINK l _bookmark3 4、開發(fā)、部署13 HYPERLINK l _bookmark4 5、運(yùn)行16P2DevOps 輕量級 IT 服務(wù)管理1、概述在 IT 服務(wù)管理領(lǐng)域，ITIL*是以安全性和連續(xù)性為目標(biāo)建立和維護(hù) IT 基礎(chǔ)架構(gòu)管理的。但迄今為止， 隨著敏捷和 DevOps 理念的不斷深入，IT 服務(wù)管理的環(huán)

2、境正在變化，前者需要依據(jù)業(yè)務(wù)用戶的需求縮短開發(fā)周期，提高發(fā)布頻率。若保持原有的 ITIL 流程化的管理方式，難以滿足上述需求。為了實(shí)現(xiàn)敏捷和 DevOps 的目標(biāo)，我們需要更輕量級的、更快速的 IT 服務(wù)管理。這是一個(gè)關(guān)鍵的問題。去年，我們聯(lián)合 ITIL 方面的一位專家教練開始研究這一問題。我們的挑戰(zhàn)是：如何去除不宜用的部分，以保持敏捷的速度與頻率？ 我們達(dá)成了這樣的結(jié)論：IT 服務(wù)管理應(yīng)當(dāng)完全聚焦于業(yè)務(wù)連續(xù)性方面。為了做好敏捷開發(fā)與精益運(yùn)維，我們重新組織了 IT 服務(wù)管理，這意味著僅需從 IT 服務(wù)管理中提取關(guān)鍵信息來管理業(yè)務(wù)連續(xù)性要素即可。同時(shí)我們定義了以下數(shù)據(jù)是在哪些流程或活動中發(fā)生的，

3、這些數(shù)據(jù)包括：業(yè)務(wù)活動模式（PBA）、服務(wù)級別需求（SLR）、服務(wù)級別協(xié)議（SLA）、服務(wù)設(shè)計(jì)包（SDP）、服務(wù)級別包（SLP）、服務(wù)驗(yàn)收標(biāo)準(zhǔn)（SAC）及運(yùn)營級別協(xié)議（OLA）。主要思路是：在活動進(jìn)行過程中收集和記錄數(shù)據(jù)。P3從 IT 服務(wù)管理的觀點(diǎn)需要這些數(shù)據(jù)時(shí)，則應(yīng)生成匯總報(bào)告，并使用這些信息。我們稱之為輕量級 IT服務(wù)管理。這不是一份文件，只是信息。 P4需要信息（MRI）以確保業(yè)務(wù)連續(xù)。服務(wù)負(fù)責(zé)人、可靠性工程師和運(yùn)營經(jīng)理識別出與業(yè)務(wù)連續(xù)性相關(guān)的每個(gè)數(shù)據(jù)項(xiàng)，因?yàn)?MRI 是由業(yè)務(wù)環(huán)境、業(yè)務(wù)戰(zhàn)略和產(chǎn)品特征或 IT 服務(wù)特征來決定的。這不會改變敏捷開發(fā)的方式。只會在設(shè)計(jì)與開發(fā)的工作中增加收集

4、數(shù)據(jù)的內(nèi)容，以獲取 MRI。這基本上無需團(tuán)隊(duì)付出額外的時(shí)間和精力。下面將對這個(gè)流程進(jìn)行說明。2、計(jì)劃這一業(yè)務(wù)用于表述服務(wù)需求，由服務(wù)負(fù)責(zé)人設(shè)定愿景、目標(biāo)、預(yù)算、項(xiàng)目范圍、以及產(chǎn)品或項(xiàng)目章程中的預(yù)期收益。服務(wù)負(fù)責(zé)人和運(yùn)維人員協(xié)商并確定 IT 服務(wù)的運(yùn)行時(shí)基礎(chǔ)架構(gòu)及適當(dāng)?shù)?IT 服務(wù)可靠性目標(biāo)。尤其是在云環(huán)境中實(shí)施 IT 服務(wù)時(shí)，這是特別重要的一個(gè)因素。我們首先設(shè)定并配置運(yùn)行時(shí)（Run-time）基礎(chǔ)架構(gòu)，其后開發(fā)人員可以輕易地、明確地理解所需性能、安全級別和現(xiàn)有運(yùn)行時(shí)基礎(chǔ)架構(gòu)的可靠性。開發(fā)人員應(yīng)當(dāng)為在該環(huán)境工作的服務(wù)開發(fā)正確的代碼。一旦運(yùn)行時(shí)基礎(chǔ)架構(gòu)得以確定，該服務(wù)就可獲取轉(zhuǎn)換的基礎(chǔ)架構(gòu)，隨即是

5、用于測試的基礎(chǔ)架構(gòu)和用于開發(fā)的開發(fā)基礎(chǔ)架構(gòu)。另一方面，本階段定義了可靠性目標(biāo)后，該服務(wù)將有一個(gè)清晰的運(yùn)維故事，用于處理所需系統(tǒng)功能的錯(cuò)誤和問題，比如：備份、記錄日志及冗余。在產(chǎn)品或項(xiàng)目章程中確定的基礎(chǔ)架構(gòu)將驅(qū)動架構(gòu)滿足預(yù)定義的非功能性需求。下面是服務(wù)級別協(xié)議(SLA)檢查表的樣例。分類類別項(xiàng)目參考文件a授權(quán)簽訂協(xié)議的組織-1責(zé)任人簽名職位/角色協(xié)議日期簽訂協(xié)議的組織-2責(zé)任人簽名職位/角色協(xié)議日期b服務(wù)描述服務(wù)定義服務(wù)構(gòu)成重要業(yè)務(wù)功能c服務(wù)范圍商定主題目標(biāo)系統(tǒng)/服務(wù)強(qiáng)制的目標(biāo)地區(qū)/地點(diǎn)目標(biāo)組織目標(biāo)人群未覆蓋服務(wù)可選的這些從 SLA 匯總的數(shù)據(jù)宜包含在產(chǎn)品或項(xiàng)目章程中。P5分類類別項(xiàng)目參考文件d

6、服務(wù)時(shí)間正常服務(wù)時(shí)間強(qiáng)制的例外情況及其條件維持服務(wù)有效的方法服務(wù)日歷改變服務(wù)時(shí)間的程序e功能性可提供的最小服務(wù)強(qiáng)制的避免違反 SLA 的可以允許的錯(cuò)誤的描述和數(shù)量重要性與報(bào)告周期f服務(wù)可用性服務(wù)的目標(biāo)可用性水平強(qiáng)制的正常服務(wù)時(shí)間內(nèi)的商定的可用性目標(biāo)可用性的度量周期和度量方法g可靠性允許出現(xiàn)的最大中斷次數(shù)監(jiān)控方法記錄方法強(qiáng)制的平均故障間隔時(shí)間（MTBF）平均服務(wù)事件間隔時(shí)間（MTBSI）中斷的定義h服務(wù)績效應(yīng)答描述強(qiáng)制的有目標(biāo)數(shù)據(jù)的吞吐量描述交易量負(fù)載限制可靠性i批處理時(shí)間對批處理時(shí)間的描述強(qiáng)制的完成時(shí)間重要成果描述輸入時(shí)間輸出時(shí)間地點(diǎn)j服務(wù)連續(xù)性對連續(xù)性計(jì)劃的簡要描述投 標(biāo) 接受者強(qiáng)制的連續(xù)性

7、詳細(xì)計(jì)劃及對 SLA 連續(xù)性的參考P6分類類別項(xiàng)目參考文件服務(wù)連續(xù)性負(fù)責(zé)人k安全安全方針投 標(biāo) 接受者強(qiáng)制的安全負(fù)責(zé)人l客戶支持聯(lián)系方法強(qiáng)制的可聯(lián)系時(shí)間支持服務(wù)可聯(lián)系時(shí)間電話應(yīng)答目標(biāo)值事件應(yīng)答目標(biāo)值擴(kuò)大支持時(shí)間范圍的程序m升級（Escalation）相關(guān)人員通訊錄強(qiáng)制的升級流程和聯(lián)系人描述投訴的定義及投訴管理程序n變更管理參考資料及其內(nèi)容的程序強(qiáng)制的對變更的緊迫程度分類和優(yōu)先級的定義o責(zé)任服務(wù)負(fù)責(zé)人描述強(qiáng)制的p計(jì)費(fèi)計(jì)費(fèi)方法描述計(jì)費(fèi)周期參考計(jì)費(fèi)方針開具發(fā)票程序付款條件罰責(zé)q服務(wù)報(bào)告/審查服務(wù)報(bào)告內(nèi)容頻率時(shí)間選擇分配表強(qiáng)制的評估會議頻率會議類型相關(guān)人員相關(guān)人員的職位r術(shù)語表技術(shù)術(shù)語描述強(qiáng)制的P7分

8、類類別項(xiàng)目參考文件s修訂記錄修訂記錄具體說明修訂日期簽字人這些 SLA 并未以紙質(zhì)文檔的形式被創(chuàng)建，相關(guān)數(shù)據(jù)/記錄以計(jì)費(fèi)服務(wù)（BOS）的形式保存在一個(gè)磁盤文件或數(shù)據(jù)庫中。P83、需求、設(shè)計(jì)包括服務(wù)可靠性需求的用戶故事用于本階段。我們知道，用戶故事最初包括“角色（作為某個(gè)角色）”、“功能（我/我們可以）”和“商業(yè)價(jià)值（為了）”。此外，“條件（我需要）”是有效的。在編寫用戶故事后，要按照架構(gòu)設(shè)計(jì)的視角進(jìn)行重構(gòu)。確保對以下架構(gòu)驅(qū)動因素進(jìn)行描述：功能需求（RF）、質(zhì)量需求（RQ）、業(yè)務(wù)需求（BC）和技術(shù)需求（TC）。用戶故事一旦固定，運(yùn)維故事（Operation Story）就將由運(yùn)維人員創(chuàng)建。運(yùn)維故

9、事應(yīng)當(dāng)如此表述： 無論運(yùn)維操作人員是否正在接受新 IT 服務(wù)訓(xùn)練，其結(jié)果都不會有任何差別。這其中也包含現(xiàn)有基礎(chǔ)架構(gòu)中的所有附加或被修正的配置。而后，測試故事就將由質(zhì)量保證人員（QA）或可靠性工程師創(chuàng)建，應(yīng)與用戶故事和運(yùn)維故事保持一致。若運(yùn)維故事不在現(xiàn)有運(yùn)維能力范圍內(nèi)，則應(yīng)當(dāng)在用戶故事中重構(gòu)。正如大家所了解的，從用戶故事、測試故事和運(yùn)維故事中收集 IT 服務(wù)管理的 MRI 是有效的。尤其是用戶故事，通過與用戶對話，它能夠向 IT 服務(wù)管理提供有益信息。因此，為這一對話準(zhǔn)備檢查清單是有益的。我來舉個(gè)你可以從以下故事中獲取的信息的例子：P91、用戶故事：用戶故事中的角色將對用戶概況（UP）做出描述。

10、用戶故事中的功能將為服務(wù)級別要求（SLR）和服務(wù)級別協(xié)議（SLA）創(chuàng)建信息。用戶故事中的角色、功能和商業(yè)價(jià)值將建立有關(guān)業(yè)務(wù)活動模式（PBA）的信息。用戶故事將為服務(wù)設(shè)計(jì)包（SDP）/服務(wù)級別包（SLP）和服務(wù)驗(yàn)收標(biāo)準(zhǔn)（SAC）生成信息。2、測試故事：服務(wù)驗(yàn)收標(biāo)準(zhǔn)（SAC）的信息可直接從測試場景和測試用例進(jìn)入測試故事。3、運(yùn)維故事：運(yùn)營級別協(xié)議（OLA）的信息可直接從環(huán)境條件進(jìn)入運(yùn)維故事，參考業(yè)務(wù)活動模式（PBA）。工作完成后，所有這些信息都將可以取用，并將被記錄下來。此外，當(dāng)用戶故事中的任務(wù)被敏捷團(tuán)隊(duì)分解后，任務(wù)記錄對于服務(wù)設(shè)計(jì)包（SDP）而言將構(gòu)成有用的信息。同時(shí)，服務(wù)驗(yàn)收標(biāo)準(zhǔn)（SAC）得以

11、驗(yàn)證，以確保品質(zhì)。分類類別項(xiàng)目參考文件a商業(yè)事項(xiàng)產(chǎn)品/項(xiàng)目章程中的商定業(yè)務(wù)條件強(qiáng)制的服務(wù)的適用性定義：何處及如何服務(wù)的接觸點(diǎn)業(yè)務(wù)關(guān)系負(fù)責(zé)人客戶聯(lián)系人b服務(wù)設(shè)計(jì)服務(wù)功能需求（由 Epic 生成）需求報(bào)告（SOR）所描述的服務(wù)功能性定義強(qiáng)制的服務(wù)級別需求（由 Epic 生成）SLA 所保證的服務(wù)級別的定義強(qiáng)制的服務(wù)的運(yùn)維管理（由 Epic 生成）對服務(wù)及其組件的要求包含支持、控制、運(yùn)維、衡量及報(bào)告強(qiáng)制的服務(wù)設(shè)計(jì)和拓?fù)?1（由用戶故事中生成）服務(wù)解決方案與組件設(shè)計(jì)強(qiáng)制的服務(wù)定義強(qiáng)制的服務(wù)模式強(qiáng)制的打包強(qiáng)制的服務(wù)選項(xiàng)可選的服務(wù)組件強(qiáng)制的基礎(chǔ)架構(gòu)強(qiáng)制的業(yè)務(wù)事項(xiàng)/價(jià)值描述服務(wù)描述強(qiáng)制的組件描述強(qiáng)制的服務(wù)設(shè)

12、計(jì)和拓?fù)?2（由發(fā)布包生成）服務(wù)解決方案和組件的轉(zhuǎn)換與運(yùn)維對轉(zhuǎn)換的描述*可選的運(yùn)維說明流程程序度量報(bào)告支持產(chǎn)品協(xié)議（agreements）供應(yīng)商c評估組織就緒狀態(tài)評估業(yè)務(wù)利潤*可選的以下是一份服務(wù)設(shè)計(jì)包（SDP）清單示例。這些數(shù)據(jù)主要來自用戶故事。P10分類類別項(xiàng)目參考文件財(cái)務(wù)評估技術(shù)評估資源評估組織評估外部聯(lián)系評估與服務(wù)提供者訂立合約的能力*可選的與供應(yīng)商訂立合約的能力與分包商訂立合約的能力d服務(wù)生命周期計(jì)劃服務(wù)計(jì)劃（根據(jù)產(chǎn)品待辦事項(xiàng)列表生成）覆蓋生命周期所有階段的完整計(jì)劃或程序*可選的服務(wù)轉(zhuǎn)換計(jì)劃（由發(fā)布中生成）轉(zhuǎn)換策略強(qiáng)制的實(shí)現(xiàn)方法方針風(fēng)險(xiǎn)評估轉(zhuǎn)換方針構(gòu)建機(jī)制（根據(jù)產(chǎn)品待辦事項(xiàng)列表生成）

13、構(gòu)建方針強(qiáng)制的有計(jì)劃地構(gòu)建服務(wù)與組件的條件方法與機(jī)制規(guī)范/控制/技術(shù)/工具/平臺用于測試的機(jī)制（由測試故事生成）測試策略強(qiáng)制的測試環(huán)境與計(jì)劃的條件方法與機(jī)制技術(shù)/工具部署（由發(fā)布中生成）部署方針可選的發(fā)布方針部署計(jì)劃部署條件運(yùn)行驗(yàn)收（由發(fā)布中生成）轉(zhuǎn)換策略*可選的實(shí)現(xiàn)方法策略風(fēng)險(xiǎn)評估P11分類類別項(xiàng)目參考文件轉(zhuǎn)換計(jì)劃界面與彈性計(jì)劃（根據(jù)發(fā)布文件生成）事態(tài)*可選的事件問題（problems）錯(cuò)誤問題（issues）不合格最終服務(wù)驗(yàn)收（由發(fā)布中生成）*可選的服務(wù)驗(yàn)收標(biāo)準(zhǔn)（由發(fā)布中生成）明確服務(wù)生命周期中每個(gè)步驟的驗(yàn)收標(biāo)準(zhǔn)，以促進(jìn)生命周期過程的進(jìn)步， 并將標(biāo)準(zhǔn)投入實(shí)踐中。所有相關(guān)的基礎(chǔ)架構(gòu)*可選的保

14、證期試運(yùn)行期及其標(biāo)準(zhǔn)注：*參考文件一欄中的“可選”上加星號是表示，當(dāng)發(fā)布包確定其為必需時(shí)，該項(xiàng)就是必需的。服務(wù)設(shè)計(jì)包（SDP）的紙質(zhì)文檔未被創(chuàng)建，相關(guān)數(shù)據(jù)/記錄以計(jì)費(fèi)服務(wù)（BOS）的形式保存在一個(gè)磁盤文件或數(shù)據(jù)庫中。從應(yīng)用生命周期管理的角度來看，IT 服務(wù)的壽命終止（EOL）可從 BOS 注冊的數(shù)據(jù)中推斷出來；其中包括：一份服務(wù)級別協(xié)議（SLA）清單、服務(wù)設(shè)計(jì)包（SDP）、服務(wù)級別包（SLP）、服務(wù)驗(yàn)收標(biāo)準(zhǔn)（SAC） 和運(yùn)營級別協(xié)議（OLA）。P124、開發(fā)、部署敏捷中迭代開發(fā)的代碼將可用于發(fā)布。團(tuán)隊(duì)?wèi)?yīng)按服務(wù)驗(yàn)收標(biāo)準(zhǔn)（SAC）核實(shí)測試的結(jié)果，來定義代碼是否可以發(fā)布。把關(guān)人（Gatekeeper

15、）應(yīng)參考服務(wù)設(shè)計(jì)包（SDP）來創(chuàng)建發(fā)布包。在自動化部署管道中，每個(gè)步驟都應(yīng)確定一個(gè)檢查點(diǎn)?？煽啃怨こ處熁虬殃P(guān)人可以根據(jù)發(fā)布包和服務(wù)驗(yàn)收標(biāo)準(zhǔn)（SAC）中的信息，檢查 IT 服務(wù)的狀態(tài)，決定是否繼續(xù)下一步。分類類別項(xiàng)目參考文件a服務(wù)啟動日期由所有利益相關(guān)者商定b保證期由所有利益相關(guān)者商定c最終服務(wù)驗(yàn)收標(biāo)準(zhǔn)由所有利益相關(guān)者商定d部署時(shí)間表向公眾開放的文件或信息強(qiáng)制的e服務(wù)級別協(xié)議（SLA）/服務(wù)級別要求（SLR）由所有利益相關(guān)者審查并商定強(qiáng)制的f服務(wù)對服務(wù)進(jìn)行輸入或更新，檢驗(yàn)其與其他組件的一致性服務(wù)目錄服務(wù)組合強(qiáng)制的g客戶與利益相關(guān)者在配置管理系統(tǒng)（CMS）中得以識別與記錄h運(yùn)行風(fēng)險(xiǎn)執(zhí)行了適當(dāng)?shù)娘L(fēng)險(xiǎn)

16、減輕措施強(qiáng)制的i符合緊急情況或特別狀態(tài)測試完成，記錄在阻礙速度測試進(jìn)度表中緊急情況應(yīng)對行動fail over 相關(guān)行動強(qiáng)制的j用戶由所有用戶定義與通過；創(chuàng)建了合適的賬戶強(qiáng)制的下面展示一份服務(wù)驗(yàn)收標(biāo)準(zhǔn)（SAC）的清單范例。服務(wù)驗(yàn)收標(biāo)準(zhǔn)（SAC）數(shù)據(jù)主要來自測試故事。P13分類類別項(xiàng)目參考文件k負(fù)載因素與性能測量所有項(xiàng)目并納入容量計(jì)劃中在線負(fù)載性能與容量強(qiáng)制的l運(yùn)維完成后審查測試文件，并接受運(yùn)維過程的進(jìn)度過程m批處理運(yùn)行完成，并審查測試文件， 驗(yàn)收批處理作業(yè)打印條件強(qiáng)制的n適當(dāng)執(zhí)行安全手段安全檢查強(qiáng)制的o安全測試p監(jiān)控與測量測量工具與流程準(zhǔn)備就緒強(qiáng)制的q連續(xù)運(yùn)行與持續(xù)運(yùn)營相關(guān)的工作被定義并批準(zhǔn)持續(xù)

17、運(yùn)營相關(guān)成本被定義并批準(zhǔn)r運(yùn)營成本并入財(cái)務(wù)流程和成本模式中s事故和問題的類別及其流程審查或修正新服務(wù)的已知錯(cuò)誤與缺陷強(qiáng)制的t新簽約的供應(yīng)商強(qiáng)制的u由供應(yīng)商、支持團(tuán)隊(duì)、開發(fā)團(tuán)隊(duì)及其他有關(guān)方面審查與修訂的支持協(xié)議服務(wù)級別協(xié)議（SLA） 服務(wù)級別要求（SLR） 運(yùn)營級別協(xié)議（OLA） 合約強(qiáng)制的v被事件-、問題-及其他 IT 支持團(tuán)隊(duì)驗(yàn)收的技術(shù)支持文件強(qiáng)制的w變更請求（RFC），批準(zhǔn)與更新的發(fā)布記錄強(qiáng)制的服務(wù)、服務(wù)級別要求（SLR）、服務(wù)級別協(xié)議（SLA）、運(yùn)營級別協(xié)議（OLA）、合同、應(yīng)用與基礎(chǔ)架構(gòu)組件配置管理系統(tǒng)（CMS）中記錄的細(xì)節(jié)P14分類類別項(xiàng)目參考文件y軟件許可被驗(yàn)證與分配z硬件組件記錄在配置管理系統(tǒng)（CMS）中，保存在固定媒體庫中。aa發(fā)布與維護(hù)相互同意的計(jì)劃發(fā)布政策，頻率機(jī)制bb用戶完整必要的培訓(xùn)，接收用戶文件cc可接受服務(wù)的相關(guān)文件有關(guān)內(nèi)部系統(tǒng)與外部系統(tǒng)、可靠性與