如果說前面的14 種“通用管理實踐”是理論基礎，17 種“服務管理實踐”讓IT 服務于業(yè)務的目標，那么我們在這一部分將要討論的“技術管理實踐”，則是業(yè)務驅動力和競爭優(yōu)勢的“軍備”來源。作為服務提供方，企業(yè)需要通過這些技術，來增強自身與競爭對手的服務差異，并持續(xù)保持用戶的滿意度和使用粘性。

1.部署管理

基礎要點：

1.將新的或變更的軟/硬件、文檔、流程或任何其他組件移置實時環(huán)境中。

2.分階段部署：一次僅部署生產(chǎn)環(huán)境的一部分，按需重復多次，直到部署完成。

3.持續(xù)交付：按需集成、測試和部署，提供頻繁的客戶反饋循環(huán)機會。

4.大爆炸式部署：如果依賴性阻止了新舊組件的并行使用（如新舊版本不兼容的數(shù)據(jù)庫架構），則需要將新的或變更的組件一并部署到所有目標上。

5.拉式部署：通過與服務請求管理的集成，允許用戶選擇并控制更新的時間。

6.為了保證部署之前不會被修改，待部署的組件應被保存在一到多個安全位置，即軟件和文檔的權威媒體庫（Definitive Media Library）。

7.部署工具既有通過與配置管理工具集成，為審計和變更管理提供支持的，又有與服務門戶集成，以支持請求管理實踐的。

8.就云服務的部署而言，如果是IaaS，則組織可以自主、自行地進行部署管理，如果是PaaS 和SaaS，則有供應商控制部署，并確保組織知曉部署計劃與發(fā)生，以便維護受控的環(huán)境。

解讀：

只有完成了上文提到的驗證與測試之后，服務提供方才能著手將正確的、已授權的，以及有質量保障的軟/硬件版本，部署到真實的生產(chǎn)與運營環(huán)境。

如今，憑借著敏捷開發(fā)、DevOps 和連續(xù)部署工具，我們在讓此過程變得比以往更快速與可靠的同時，還需要注意，服務與產(chǎn)品的部署是一個持續(xù)的過程，而非一項的任務或事件。因此，我們需要監(jiān)控生產(chǎn)環(huán)境中的各個組件，恪守實施步驟，以確保每一步都能夠得到平穩(wěn)的推進。

具體說來，我們在部署管理過程中應該重點關注如下幾個方面：

1.通過持續(xù)監(jiān)控，識別并記錄部署過程中出現(xiàn)的任何問題，包括：應用程序的異常閃退、空的引用所拋出的異常、SQL 的連接超時、頁面上產(chǎn)生的HTTP 4XX 和5XX的錯誤，以及線程中止所導致的應用重啟等。

2.新的，特別是變更的組件在被部署前后，往往會對既有的服務所產(chǎn)生流量，以及加載時間的變化。通過監(jiān)控這些關鍵指標，我們能夠順利地找到流量的峰值，進而發(fā)現(xiàn)某些存在著邏輯錯誤的相互調用關系。

3.跟蹤系統(tǒng)與服務的性能指標，以及用戶的滿意度水平。其中包括：請求的響應時間與效果，成功獲取服務的占比，系統(tǒng)的高可用性指標等方面。當然，有些指標的評分也許在部署過程中并不高，但是在部署完成后，憑借著緩存等方面的協(xié)助，能夠很快恢復到正常的水平。

4.保持部署實施團隊之間的溝通與同步，大家各司其職，及時反饋，才能持續(xù)追蹤部署的進度。

在完成了新的或變更組件的部署之后，我們需要進行驗收測試。即：通過自動化的工具，或是邀請部分用戶，參與全面且反復的測試。通常，我們可以將驗收分為初驗和終驗兩個階段：

初驗主要著眼于服務的功能。在初驗中發(fā)現(xiàn)的問題，應當以書面?zhèn)渫浀男问竭M行記錄，由服務提供方承諾解決的時限，并由驗收雙方簽字予以確認和歸檔。

終驗一般發(fā)生在系統(tǒng)試運行或服務被試用了一段時間之后，主要關注的是性能方面。我們可邀請有資質的第三方參與進來，以實現(xiàn)服務的順利交付。

實務：

為了實現(xiàn)順利部署這一目標，我們企業(yè)在部署管理的過程中實施了規(guī)范化的管理。

1.軟硬件類型標準化。無論是網(wǎng)絡設備、服務器端、用戶終端，還是操作系統(tǒng)和應用軟件，我們都有既定的支持和首選的列表，這樣一來，在品牌和型號層面上大幅降低了非兼容性狀態(tài)，同時也縮小了出錯時排查的范圍。

2.安裝配置標準化。我們具體參照和實施的關鍵點包括：

（1）事先設定好硬件設備上架所對應的機房和機架的物理位置。

（2）規(guī)范化網(wǎng)線、電源線的走向、編號，以及色序等。

（3）在服務器端，預先分配好虛擬硬件資源（包括：CPU、內存、磁盤空間、分區(qū)大小等），準備相應的虛擬機文件，定義代碼的上載目錄。

（4）在用戶端，統(tǒng)一通過鏡像文件，來批量部署操作系統(tǒng)及應用。

（5）規(guī)范應用支撐軟件（包括：IIS、Weblogic 等）與數(shù)據(jù)庫的部署路徑和配置順序。

（6）詳細羅列出需要用到的賬號名稱、登錄密碼、權限屬性，以及服務端口號等細節(jié)。

有了前面的規(guī)范化，我們在具體部署中通常還會考慮采取分時間、分空間的實施策略。例如：針對某個新的系統(tǒng)，我們會選擇第一季度在亞洲區(qū)的各個分公司實施，第二季度在歐洲區(qū)的各個分公司部署。我們在充分控制好軟、硬件兼容性的情況下，既做好了新舊系統(tǒng)的共存，又給予用戶體驗和熟悉新系統(tǒng)的時間。

當然，一旦發(fā)現(xiàn)新系統(tǒng)對現(xiàn)有服務產(chǎn)生了不良影響，我們也能根據(jù)事先制定的回退方案切換回舊的系統(tǒng)。

在部署的實施邏輯上，我們將前面基礎要點中提到的拉式部署改進為“推/拉結合”。其中：

“推”是指將新的或改進的服務推送到各個用戶終端上，自動觸發(fā)部署進程。由于帶有一定的強制性，所以該方式一般適用于用戶數(shù)量龐大的關鍵性服務。

“拉”是指用戶通過主動觸發(fā)的方式，通過終端向服務器端請求新的或更新的服務，如病毒簽名庫的升級包等。由于靈活性較強，因此用戶可以在非繁忙時段，自行獲取一些非緊急的更新。

在部署的覆蓋范圍上，我們一般采取的是自動與手動互補的方法。無疑，自動分發(fā)新的或更新的服務，不但保持了整體的一致性，而且能夠突破時間和空間的限制，減輕了實施人員的重復工作量。

不過，對于一些發(fā)生在自動部署過程中的錯誤，人工勘查、判斷，以及手動安裝的優(yōu)勢就非常明顯。因此筆者單位一直采取的是“自動在先，手動攻堅”的互補模式。

在驗收階段，我們除了先后開展上述解讀環(huán)節(jié)提到的初驗與終驗工作之外，還會及時更新配置項數(shù)據(jù)庫，以及已知錯誤知識庫。通過運用普通用戶所容易理解的語言來描述錯誤的特征，我們不但可以提前向用戶傳遞和警示可能碰到的問題，還能夠合理地控制好用戶在使用服務過程中的期望值和體驗度。

此外，相應的技術支持和用戶培訓也是服務部署后期所必不可少的環(huán)節(jié)。

2.基礎架構和平臺管理

基礎要點：

1.目的是監(jiān)控組織內、外部可用的技術解決方案。

2.IT 基礎架構包括：物理和/或虛擬的技術資源，提供交付IT 服務所需的環(huán)境，以及用戶可訪問服務或產(chǎn)品的任何CI。

3.新技術包括：機器學習、聊天機器人、人工智能、移動設備管理和企業(yè)移動管理。

4.組織應設計自己的云管理系統(tǒng)，以便根據(jù)業(yè)務目標、預期的服務質量，以及運營效率，來協(xié)調所有相互關聯(lián)的組件。

5.應當從戰(zhàn)略、戰(zhàn)術和運營三個層面上聯(lián)合實踐，對于云服務的運營和管理包括：

（1）服務財務管理：由于云服務已作為基礎設施被使用，并從運營預算中被支付，因此運營支出（OPEX）比成本支出（CAPEX）更受重視。

（2）供應商管理：由于云服務提供商參與到了發(fā)布管理中，因此需要對IT 安全、數(shù)據(jù)保護，以及合規(guī)等領域進行持續(xù)評估。

（3）能力和性能管理：應監(jiān)控與跟蹤預算，云服務成本的增加，建立閾值報警機制。

（4）變更控制：由于云服務提供商的變更鮮少，甚至無需客戶的批準，因此云服務產(chǎn)品與系統(tǒng)應當多采用標準化的變更方式。

（5）事故管理：應當區(qū)分何為內部問題，何為云服務提供商所支持的服務問題。

（6）部署管理：應當確保用戶的安全登錄，充分利用云服務提供商的資源，實現(xiàn)云服務功能的快速部署，并將其嵌入到已有的內部服務產(chǎn)品中。

解讀：

多年來，隨著各類IT 技術、應用與系統(tǒng)的持續(xù)迭代，各個企業(yè)的IT 基礎架構與平臺都逐步形成了多層次且錯綜復雜的立體結構。我們可以通過硬件、軟件、網(wǎng)絡、系統(tǒng)和管理五個邏輯層面，運用ITIL 4 的思想進行定義與劃分。

在硬件上，包括：機房與數(shù)據(jù)中心，各類基礎資源與設備等。

在軟件上，包括：應用中間件，文檔與協(xié)作平臺等。

在網(wǎng)絡上，包括：內、外部網(wǎng)絡，有線、無線的路由、交換，以及網(wǎng)絡安全設備等。

圖2 企業(yè)基礎架構“城堡”

在系統(tǒng)上，包括：內部OA與郵件，外部信息發(fā)布與客戶交互系統(tǒng)等。

在管理上，包括：基本賬號、組群、響應流程、培訓文檔，以及操作手冊等。

我們可以形象地把它們理解成為如圖2 所示的企業(yè)基礎架構“城堡”。

總的說來，對于傳統(tǒng)和內部的基礎架構與平臺，我們可以參照前文提到過的IT資產(chǎn)與服務配置的管理方式，梳理出架構與平臺的基線。

而對于部署在云端的架構和平臺，由于繼承了云服務的“按需分配、快速發(fā)布、資源池化、彈性伸縮”四大特點，因此我們在管理上也應當注意如下各個方面：

1.按需分配：我們應當持續(xù)跟蹤日俱增的業(yè)務和產(chǎn)品需求。

（1）服務分類與編錄。我們可以對企業(yè)使用到和向外提供的云端業(yè)務，進行服務類型的細化，根據(jù)各個應用和不同系統(tǒng)之間的數(shù)據(jù)流向，勾勒出流轉的邏輯圖表，并清晰地定義出何種數(shù)據(jù)將會在邏輯上存儲在何處，以及它們會受到何種方式的管理和保護等。

（2）服務級別配比。雖然云端業(yè)務降低了IT 運維部門的繁瑣工作量，但是我們需要花費更多的時間從RTO（恢復時間目標）和RPO（恢復點目標）出發(fā)，去評估基礎帶寬、高可用性、用戶并發(fā)、響應時間、備份頻率等方面指標。通過與云服務提供商的協(xié)商和約定，我們需要界定出各種的職責范圍，合理地配備資源，以避免出現(xiàn)盲點。

2.快速發(fā)布：隨著“試錯”成本的降低，云服務的變更與發(fā)布頻率得到了顯著的提高，我們要對配置、變更和測試進行管控。

（1）配置。雖然許多云服務本身就帶有OOTB（開箱即用）的屬性，但是我們需要將其視為IT 資產(chǎn)的一部分，持續(xù)將其錄入或更新到CMDB（配置管理數(shù)據(jù)庫）中。同時，CMDB 里的各種表項和字段應具有可擴充性和可移植性，以方便根據(jù)不同的云端應用場景進行靈活組合與快速迭代。

（2）變更。對于計劃內的主動變更，我們應當對諸如：鏡像與配置模板的修改，云空間配額的調整，以及虛擬CPU/內存資源的增減等方面及時記錄與更新。而對于各種事故或故障所導致的被動變更，IT 部門需要根據(jù)既定的協(xié)議，與云服務提供商通力協(xié)作，各司其職。

（3）測試。我們可以利用云服務的規(guī)模效應，對云端業(yè)務進行各類負載與壓力測試，以及在征得云服務提供商確認的情況下，開展各種漏洞掃描和滲透測試，從而抵御來自縱向的外部威脅，以及橫向的跨租戶攻擊。

3.資源池化：我們應當讓自己的不同云端業(yè)務，充分利用已訂閱的云平臺資源。

（1）動態(tài)調整：憑借著虛擬化主機和軟件定義網(wǎng)絡，以及在構建效率和數(shù)量上的優(yōu)勢，我們能夠根據(jù)與云服務提供商事先簽訂的訂閱或擴容條款，動態(tài)地增配CPU、內存和實例的數(shù)量，以及存儲的空間，進而充分發(fā)揮業(yè)務基礎架構的連續(xù)性和自愈能力。

（2）服務商管理：由于云服務提供商及其平臺已突破了地理空間距離，因此我們只能事先設定好的報告模板和內容項，并通過遠程協(xié)作和訂閱報告的形式來對他們進行考核。因此，我們有必要將提供相似云服務的平臺予以“池化”，以保證自身云端業(yè)務的性能。

4.彈性伸縮：從以往對物理資源的死板預分配，以及對網(wǎng)絡帶寬的滯后管理模式，過渡為憑借著大數(shù)據(jù)分析，實時獲悉云業(yè)務平臺的態(tài)勢，進而做出及時的調整。

（1）持續(xù)監(jiān)控。除了監(jiān)控云端業(yè)務平臺的性能之外，我們還應當對服務在使用過程中所產(chǎn)生的流量和費用，實施財務監(jiān)控。

（2）按需遷移。我們需要靈活地根據(jù)當前云業(yè)務平臺的整體性能，以及運營成本等多方面，將整體或部分業(yè)務平滑、無縫地遷移到其他云服務提供商處。

可見，我們在對基礎架構，特別是云平臺進行日常管理時，除了具備技術能力之外，還需要深耕業(yè)務，善于利用前面討論過的各種管理實踐知識，按需優(yōu)化，發(fā)揮架構平臺對業(yè)務的支撐作用。

實務：

在基礎架構和平臺管理方面，為了避免系統(tǒng)產(chǎn)生中斷和數(shù)據(jù)出現(xiàn)丟失，我們企業(yè)的運維人員會定期開展：鉆機房，登設備，查線路，測應用，跟業(yè)務，訪用戶等活動。通過徹底梳理，我們不但能夠弄清支撐各項交付服務的背后基礎性架構，而且能夠提煉出它們的正?；€，進而排列出不同平臺的優(yōu)先級。

另外，對于支撐云端業(yè)務的新型平臺架構，我們從如下方面嘗試了全面的管理實踐：

1.數(shù)據(jù)的存放與保護。其中包括：

（1）對云存儲空間實施邏輯隔離，數(shù)據(jù)的物理存放符合所在行政轄區(qū)的規(guī)范。

（2）對數(shù)據(jù)進行脫敏和加噪，通過ISO/IEC 27018的相關標準，保護數(shù)據(jù)的隱私。

（3）對靜態(tài)存放與動態(tài)流轉的數(shù)據(jù)采用企業(yè)級加密標準（如：AES 256 bit 和TLS v1.3），以及對云端的業(yè)務數(shù)據(jù)實施恰當?shù)牧舸媾c銷毀策略。

2.賬號與權限管理。其中涉及到：業(yè)務與應用管理員賬號的有效期和密碼強度（如：SOC-2 級強密碼策略），遠程運維的登錄方式（如：Regular-rotated SSH 或MFA）與最小權限，以及平臺管理員的操作監(jiān)控與審計。

3.事件與日志管理。主要包括：集中收集與妥善存儲系統(tǒng)、應用、數(shù)據(jù)庫及云平臺基礎設施所產(chǎn)生的各類事件與日志。

4.安全與風險管理。通常涉及到：

（1）根據(jù)SOC-2 Type II，制定威脅模型和風險評估流程。

（2）根據(jù)“Deny-all”和OWASP Top 10 的相關原則，默認關閉虛擬主機和網(wǎng)絡上的服務端口，定制、維護并更新鏡像的基線。

（3）持續(xù)對云端應用或hypervisor 層采取漏洞掃描，以及滲透測試。

（3）經(jīng)由模擬生產(chǎn)環(huán)境測試之后，方可對系統(tǒng)與應用的升級補丁予以發(fā)布和部署。

（4）通過實時監(jiān)控與分析，提高對抗APT 和DDoS 的能力。

3.軟件開發(fā)和管理

基礎要點：

1.軟件，既可以是單個程序（或程序套件、進程、工作流程），又可以是較大的系統(tǒng)（如：操作系統(tǒng)、環(huán)境或數(shù)據(jù)庫），甚至不限于桌面應用程序、移動應用、嵌入式軟件、以及各類網(wǎng)站。

2.為了確保滿足使用目的，軟件開發(fā)和管理實踐活動包括：

（1）方案架構。

（2）方案設計（用戶界面、客戶體驗、服務設計等）。

（3）軟件開發(fā)。

（4）軟件測試（包括單元測試、集成測試、回歸測試、信息安全測試和用戶驗收測試）。

（5）管理代碼存儲庫，維護完整性。

（6）創(chuàng)建程序包，實現(xiàn)有效和高效的部署。

（7）版本控制，共享并持續(xù)管理小塊代碼。

3.兩種普遍接受的軟件開發(fā)方法是：瀑布式和敏捷方法。

4.根據(jù)“設計、開發(fā)、測試、部署、運營、淘汰”的生命周期，來實施軟件管理。

解讀：

一直以來，大多數(shù)企業(yè)都持續(xù)運用傳統(tǒng)的瀑布式開發(fā)模型，通過可預測的靜態(tài)工作流，來確保開發(fā)團隊能夠根據(jù)預估的成本和截止日期，交付出高質量的軟件。

前文基礎要點中提到的軟件開發(fā)生命周期（Software Development Life Cycle，SDLC）主要涉及如下幾個階段：

1.需求分析。該階段要求從客戶處收集原始需求，并在軟件需求規(guī)范（Software Requirement Specification，SRS）中記錄與業(yè)務相關的要點，并獲得客戶的確認。

2.軟件設計。此階段通常分為兩個步驟：

（1）高級設計（High-Level Design，HLD）：有時也稱概要設計，它交付的是軟件產(chǎn)品的體系結構。

（2）低級設計（Low-Level Design，LLD）：有時也稱詳細設計，它描述的是軟件產(chǎn)品的每一項功能。

3.軟件開發(fā)。開發(fā)人員著手編寫并構建軟件的相關代碼。

4.軟件測試。對可能出現(xiàn)的缺陷進行全面測試。測試人員通常會根據(jù)對于被測項目內部結構，以及實現(xiàn)原理的掌握情況，開展黑盒（完全不知）、白盒（全面知曉）、灰盒（部分了解）三種測試方法。

5.軟件部署。將軟件產(chǎn)品部署并發(fā)布到生產(chǎn)環(huán)境中，以供最終用戶使用。

6.軟件運營。在使用該系統(tǒng)與服務的過程中，用戶碰到的任何實際問題，都需要在該階段，得到持續(xù)且及時的解決。

7.軟件淘汰。當該軟件已無法滿足用戶的需求，或是有新的替代品出現(xiàn)時，該產(chǎn)品就會被有計劃地逐步淘汰掉。

在上述流程中，每一個階段的輸出都是下一個階段的輸入，顯然，這樣的線性固定模型，不但給可能出現(xiàn)的變更帶來了巨大風險與成本，而且使得用戶無法參與到開發(fā)的過程中，只能被動地等待軟件的最終揭曉。

另外，由于測試人員只有在開發(fā)階段結束后才能接觸到代碼，進而開展測試工作，因此該開發(fā)模型會使得開發(fā)人員與測試人員缺乏協(xié)作。

正如上述基礎要點中所提到，近年來，許多企業(yè)都采用了一種新的、非固定線性路徑式的敏捷方法（Agile Method）。作為遵循迭代式開發(fā)的方法，它并不會為項目的全部過程創(chuàng)建各種任務，而是將開發(fā)分為多個迭代周期（Sprint）階段。相比瀑布式開發(fā)，該方法具有如下的優(yōu)點：

由于將單個大項目切割成了多個小任務，因此具有較短的開發(fā)周期，能夠使得項目具有較強的適應性。項目組能夠隨時響應用戶提出的任何重大或微小的變更。

由于每個Sprint 都有一個測試階段，因此在開發(fā)人員每次發(fā)布新的功能后，測試人員都能立即開展回歸測試。而且，用戶也能夠及時給予接受或要求變更的決定。因此，開發(fā)人員、測試人員及用戶能夠持續(xù)交流，并通力協(xié)同。

當然，文檔是敏捷開發(fā)方法的短板。由于開發(fā)過程中的頻繁變更和持續(xù)迭代，因此文檔往往無法及時跟進和到位。這給復雜的大型項目帶來了一定的不確定因素。

實務：

就軟件開發(fā)和管理而言，各種專業(yè)的開發(fā)類技術規(guī)范與框架，都能夠提供詳盡的介紹與討論。那么ITIL 4在該環(huán)節(jié)的管理實踐，其實是對前面討論過的各種通用、服務，以及技術管理要點的綜合運用。

筆者單位除了在大型項目中繼續(xù)沿用瀑布式的開發(fā)方式之外，也在某些特定項目中點嘗試了敏捷模式，特別是有關DevSecOps 的落地。其中包括如下方面：

1.針對不同的應用服務，設置不同的用戶職能組。

2.防止在應用數(shù)據(jù)的傳輸過程中，泄漏任何密碼、口令、證書或私鑰信息。

3.用HashiCorp Vault來管理密鑰，用Sensu 來檢查TTL 證書，以避免使用過期的證書。

4.將多種應用程序的登錄方式統(tǒng)一為單點登錄（SSO），以實現(xiàn)用戶賬號權限的自動匹配。

5.用OWASP（開放式Web 應用程序安全項目）依賴項來檢查Java 和.NET代碼，用RetireJS 檢查JavaScript 代碼，及時發(fā)現(xiàn)無效或過時的依賴項與庫。

6.通過代碼質量的靜態(tài)應用程序安全測試(SAST)，包括SonarQube 和OWASP ZAP，來發(fā)現(xiàn)潛在的內存泄漏、無限循環(huán)，以及程序漏洞。

7.針對本企業(yè)中的所有應用服務，編制一套包含程序功能和使用范圍的分類表。保證表中的每一種應用都帶有版本號、許可證、交付方式、類別、基本描述，以及是否外網(wǎng)可用等特征項。

結語：

常言道，人們其實要的不是某個特殊的鉆頭，而是由它鉆出的孔。本系列在每一個管理實踐中，不但提供了作為“鉆頭”的基礎要點，也給出了作為“安裝說明”的逐條解讀，還展示了作為“鉆孔方法”的企業(yè)實務。

如果說：在ITIL v 3 和2011 里所涉及到的各種流程與職能，是圍繞著IT 服務蓋起了一幢高樓。您只有拾級而上，才能遍歷IT 服務的每一個環(huán)節(jié)，讓IT 系統(tǒng)更加高效且穩(wěn)定地服務于企業(yè)的業(yè)務系統(tǒng)。那么ITIL 4 的34 個管理實踐，則是為企業(yè)打造了一艘服務價值的航母，讓IT 與業(yè)務共同掌舵，通過持續(xù)改進來不斷修正航向，乘風破浪地航行在瞬息萬變的商業(yè)海洋之中。