技術管理實踐

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

1.部署管理

基礎要點：

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

2.分階段部署：一次僅部署生產環境的一部分，按需重復多次，直到部署完成。

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

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

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

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

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

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

解讀：

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

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

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

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

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

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

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

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

初驗主要著眼于服務的功能。在初驗中發現的問題，應當以書面備忘錄的形式進行記錄，由服務提供方承諾解決的時限，并由驗收雙方簽字予以確認和歸檔。

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

實務：

為了實現順利部署這一目標，我們企業在部署管理的過程中實施了規范化的管理。

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

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

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

（2）規范化網線、電源線的走向、編號，以及色序等。

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

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

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

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

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

當然，一旦發現新系統對現有服務產生了不良影響，我們也能根據事先制定的回退方案切換回舊的系統。

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

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

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

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

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

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

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

2.基礎架構和平臺管理

基礎要點：

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

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

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

4.組織應設計自己的云管理系統，以便根據業務目標、預期的服務質量，以及運營效率，來協調所有相互關聯的組件。

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

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

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

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

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

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

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

解讀：

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

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

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

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

圖2 企業基礎架構“城堡”

在系統上，包括：內部OA與郵件，外部信息發布與客戶交互系統等。

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

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

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

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

1.按需分配：我們應當持續跟蹤日俱增的業務和產品需求。

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

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

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

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

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

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

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

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

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

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

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

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

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

實務：

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

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

1.數據的存放與保護。其中包括：

（1）對云存儲空間實施邏輯隔離，數據的物理存放符合所在行政轄區的規范。

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

（3）對靜態存放與動態流轉的數據采用企業級加密標準（如：AES 256 bit 和TLS v1.3），以及對云端的業務數據實施恰當的留存與銷毀策略。

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

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

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

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

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

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

（3）經由模擬生產環境測試之后，方可對系統與應用的升級補丁予以發布和部署。

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

3.軟件開發和管理

基礎要點：

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

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

（1）方案架構。

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

（3）軟件開發。

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

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

（6）創建程序包，實現有效和高效的部署。

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

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

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

解讀：

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

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

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

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

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

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

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

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

5.軟件部署。將軟件產品部署并發布到生產環境中，以供最終用戶使用。

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

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

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

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

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

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

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

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

實務：

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

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

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

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

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

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

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

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

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

結語：

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

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