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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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