25. 附錄
附錄 1 DevOps 的大融合
我們認(rèn)為 DevOps 正在得益于一場令人難以置信的管理實踐大融合，各種實踐相互促進和銜接在一起，并形成了一種獨特的實踐集合，它能對組織的軟件開發(fā)轉(zhuǎn)型和 IT 產(chǎn)品或服務(wù)交付模式的轉(zhuǎn)型產(chǎn)生極大的幫助。
John Willis 稱之為“DevOps 的大融合”。下面盡量按時間順序介紹這次大融合里的各種元素。
請注意，這里并不詳細(xì)介紹它們，而只是概要地介紹各種思維的演進，以及發(fā)生在它們之間的難以置信的鏈接，最終導(dǎo)致了 DevOps 的應(yīng)運而生。
精益運動
精益運動始于 20 世紀(jì) 80 年代，衍生自豐田生產(chǎn)系統(tǒng)（TPS）。TPS 包括價值流映射、看板和全面生產(chǎn)維護等。
精益的兩個主要原則是：
- (1) 堅信前置時間（把原材料轉(zhuǎn)換為成品所需的時間）是提升質(zhì)量、客戶滿意度和員工幸福感的最佳預(yù)測指標(biāo)；
- (2) 小批量尺寸是短前置時間的一個最佳預(yù)測指標(biāo)，理論上講最理想的批量尺寸是“單件流”（即“1×1”的流，庫存為 1，批量尺寸為 1）。
精益原則專注于為客戶創(chuàng)造價值，要求系統(tǒng)性思考，持之以恒，擁抱科學(xué)思維，創(chuàng)建流和拉動（而不是推動）的模式，從源頭保證質(zhì)量，以謙遜為導(dǎo)向，尊重每一個人。
敏捷運動
始于 2001 年?！懊艚菪浴笔怯?17 位軟件開發(fā)領(lǐng)域的頂尖大師編寫的，目的是掀起一場推廣輕量級軟件開發(fā)方法（如 DP 和 DSDM-動態(tài)系統(tǒng)開發(fā)方法）的運動，用敏捷替代瀑布式等重量級軟件開發(fā)過程以及替代統(tǒng)一軟件開發(fā)過程（RUP）這樣的方法論。
它的一個關(guān)鍵原則是：“頻繁地交付可工作的軟件，交付周期可以是數(shù)星期也可以是數(shù)月，推薦更短的周期。”另外還有兩個原則，一個是小型的、自我激勵的團隊?wèi)?yīng)工作在高度信任的模式下，一個強調(diào)小批量尺寸。敏捷還和一系列的工具和實踐相關(guān)，如 Scrum、站會等。
Velocity 大會運動
從 2007 年開始，由 Steve Souders、John Allspaw 和 Jesse Robbins 等人組織并發(fā)起了 Velocity大會，目的是為 IT 運維和網(wǎng)站性能調(diào)優(yōu)人員提供一個聚首的機會。在 2009 年的 Velocity 會議上，John Allspaw 和 Paul Hammond 做了主題為“每日 10 次部署：Dev 和 Ops 在 Flickr 的協(xié)作”的演講。
敏捷基礎(chǔ)設(shè)施運動
在 2008 年的多倫多敏捷會議上，Patrick Debois 和 Andrew Schafer 主持了一場名為“羽毛之鳥”專題研討，探討如何將敏捷原則應(yīng)用于基礎(chǔ)設(shè)施，而不僅限于應(yīng)用程序代碼。他們很快得到了一些志同道合的思考者的響應(yīng)，其中也包括 John Willis。后來，Patrick 又深受 John 和 Hammond的“每日 10 次部署：Dev 和 Ops 在 Flickr 的協(xié)作”演講的鼓舞，于 2009 年在比利時的根特市，舉辦了第一次 DevOpsDays 活動，創(chuàng)造了“DevOps”這個詞。
持續(xù)交付運動
在持續(xù)構(gòu)建、測試和集成等開發(fā)實踐的基礎(chǔ)上，Jez Humble 和 David Farley 發(fā)展出了持續(xù)交付的理念，其中包括確保將代碼和基礎(chǔ)設(shè)施始終處于可部署狀態(tài)的“部署流水線”，并且確保所有提交到主干的代碼都能安全地部署到生產(chǎn)環(huán)境里。
這個想法最早是在 2006 年的敏捷大會上公布于眾的，Tim Fitz 在他的一篇名為“持續(xù)部署”的博文中完善了這個概念。
豐田套路運動
在 2009 年，Mike Rother 編寫了《豐田套路：轉(zhuǎn)變我們對領(lǐng)導(dǎo)力與管理的認(rèn)知》一書，書中描述了他對豐田 20 年研究的收獲。這期間他理解了豐田生產(chǎn)系統(tǒng)（TPS）的因果機制并對其作了綜述。書中介紹了“豐田成功背后隱形的管理例程和思維模式及其不斷改進和調(diào)整……以及其他公司如何在他們的組織中踐行類似的例程和思維模式”。
他的結(jié)論是，精益社區(qū)錯失了與所謂的“改善套路”相關(guān)的最重要的實踐。 他解釋說，每個組織都有工作日程，豐田成功的關(guān)鍵因素是改進了工作習(xí)慣，并將其植入到組織里每個人的日常工作中。豐田套路建立了一種迭代、增量、科學(xué)的解決問題的方法，追求共同的企業(yè)目標(biāo)。
精益創(chuàng)業(yè)運動
在 2011 年，Eric Ries 編寫了《精益創(chuàng)業(yè)：新創(chuàng)企業(yè)的成長思維》一書，總結(jié)了他在一家硅谷創(chuàng)業(yè)公司 IMVU 的經(jīng)驗教訓(xùn)。這本書的核心思想基于 Steve Blank 的《四步創(chuàng)業(yè)法》一書和持續(xù)部署技術(shù)。Eric Ries 還給出了相關(guān)實踐并定義了一些術(shù)語，包括最小化可行產(chǎn)品（MVP）、構(gòu)建 - 度量 - 學(xué)習(xí)的循環(huán)，以及很多持續(xù)部署的技術(shù)模式。
精益用戶體驗運動
在 2013 年，Jeff Gothelf 撰寫了《精益設(shè)計：設(shè)計團隊如何改善用戶體驗》一書，其中描寫了如何改進“模糊前端”，并解釋了產(chǎn)品經(jīng)理如何在投入時間和資源以前制定業(yè)務(wù)假設(shè)實驗，籍此獲取關(guān)于業(yè)務(wù)的信心。有了精益設(shè)計，全面優(yōu)化業(yè)務(wù)假設(shè)、功能開發(fā)、測試、部署和為客戶發(fā)布服務(wù)的工具就齊了。
Rugged Computing 運動
2011 年，Joshua Corman、David Rice 和 Jeff Williams 深入考察了軟件開發(fā)周期晚期進行應(yīng)用程序和環(huán)境安全加固的無效性。 根據(jù)考察結(jié)果，他們提出了名為 Rugged Computing 的哲學(xué)，旨在構(gòu)建包含穩(wěn)定性、可擴展性、可用性、生存性、可持續(xù)性、安全性、可支持性、可管理性和防御性等的非功能性需求框架。
DevOps 強調(diào)高頻率發(fā)布，可能會給質(zhì)量保證（QA）和信息安全（Infosec）帶來巨大的壓力，因為當(dāng)部署頻率從每月或每季度一次提升到每天數(shù)百或數(shù)千次時，信息安全或質(zhì)量保證的工作周期就不再是兩周一次了。Rugged Computing 運動假設(shè)當(dāng)前的多數(shù)信息安全防護措施是沒用的。
附錄 2 約束理論和核心的長期沖突
約束理論主要討論核心沖突云（通常稱為“C3”）的作用。圖 A-1 是 IT 的沖突云示意圖。
在 20 世紀(jì) 80 年代，在制造業(yè)里核心的長期沖突非常普遍。所有工廠經(jīng)理都有兩項重要的業(yè)務(wù)目標(biāo)：提高銷量，降低成本。 問題是，為了保持銷量，庫存就要增加，以確保始終能滿足客戶需求。
然而，要降低成本，就應(yīng)該減少庫存，以確保資金沒有占用在在制品上。在制品指按客戶訂單生產(chǎn)的但還不能立即發(fā)貨的產(chǎn)品。
應(yīng)用精益原則能解決以上沖突，例如減小批量尺寸，減少在制品數(shù)量，以及縮短和放大反饋回路。 這樣工廠的生產(chǎn)率、產(chǎn)品質(zhì)量和客戶滿意度都會得到顯著提高。
DevOps 工作模式背后的原理與制造業(yè)變革的原則是相同的，那就是優(yōu)化 IT 價值流，將業(yè)務(wù)需求轉(zhuǎn)化成為向客戶提供價值的能力和服務(wù)。
附錄 3 惡性循環(huán)列表
《鳳凰項目》中描繪的惡性循環(huán)如表 A-1 所示。
附錄 4 交接和隊列的危害
隊列等待時間會隨著交接次數(shù)的增加而延長，因為隊列是由于交接而產(chǎn)生的。圖 A-2 顯示了一個工作中心資源的繁忙程度與等待時間的關(guān)系。漸變的曲線顯示了為什么“一個 30 分鐘的簡單變更”通常卻需要幾周的時間才能完成。某些工程師和項目組若過于繁忙，通常就會變成瓶頸。當(dāng)一個項目組滿負(fù)荷時，任何需要它完成的任務(wù)都會被淹沒在隊列里，如果沒有人進行催促或提高優(yōu)先級，該任務(wù)將永遠(yuǎn)也不能完成。
在圖 A-2 中，橫坐標(biāo)表示在一個項目組里某特定資源的繁忙百分比，縱坐標(biāo)是等待時間（或者更準(zhǔn)確地說是隊列長度）。曲線的形狀表明，在資源利用率超過 80%以后，等待時間會急速攀升到頂點。
附錄 5 工業(yè)安全誤區(qū)
對復(fù)雜系統(tǒng)幾十年的研究表明，人們的處理策略都是基于幾個誤區(qū)：
- 誤區(qū) 1：人為錯誤是意外和事故最主要且唯一的根源。
- 誤區(qū) 2：如果人遵守了既定的規(guī)程，那么系統(tǒng)就是安全的。
- 誤區(qū) 3：安全性可以通過設(shè)置權(quán)限和防護來提升。保護層次越多，安全性就越高。
- 誤區(qū) 4：事故發(fā)生的根本原因（“真相”）可以通過事故分析來確定。
- 誤區(qū) 5：事故調(diào)查就是識別事實和原因之間的邏輯和關(guān)聯(lián)關(guān)系。
- 誤區(qū) 6：安全性總是優(yōu)先級最高的，不容降低。
誤區(qū)與真相之間的區(qū)別如表 A-2 所示。
附錄 6 豐田安燈繩
許多人問，如果安燈繩每天被拉了 5000 次，那么生產(chǎn)工作怎么會完成呢？確切地說，并不是每個安燈繩都會導(dǎo)致整個裝配線的停止。相反，當(dāng)安燈拉繩被拉下時，監(jiān)督那個工作中心的團隊領(lǐng)導(dǎo)有 50 秒時間解決這個問題。如果在 50 秒內(nèi)問題沒解決，沒有裝配完畢的車輛就將越過地板上畫的那條線，然后這條裝配線才會停止（見圖 A-3）。
附錄 7 軟件包產(chǎn)品
為了將復(fù)雜的軟件包產(chǎn)品（COTS，commercial off-the-shelf software；如 SAP、IBM WebSphere、Oracle WebLogic）也納入版本控制，我們可能不得不去掉廠商提供的圖形化的點擊操作模式的安裝工具。為此需要了解廠商提供的工具的用途，還需要一個干凈的服務(wù)器安裝圖片，需要比對文件系統(tǒng)，并將新增的文件納入版本控制。將那些與安裝環(huán)境無關(guān)的文件都放在同一個位置（“基礎(chǔ)安裝”），將環(huán)境有關(guān)的文件放入各自的目錄（“測試”或者“生產(chǎn)”）。通過這種方式，軟件安裝操作就變成了版本控制的操作，可視化效果和可重復(fù)性都更好了，速度也提升了。
我們可能還要轉(zhuǎn)換應(yīng)用配置設(shè)置，把它們也納入版本控制。例如，可以將存儲在數(shù)據(jù)庫里的應(yīng)用配置轉(zhuǎn)換為 XML 文件，XML 文件也可以轉(zhuǎn)換為應(yīng)用配置。
附錄 8 事后分析會議
事后分析會議的議程樣例如下。
- 首先由會議主持或協(xié)調(diào)人做會議啟動發(fā)言，強調(diào)這個會議是對事不對人的事后分析會議，我們的重點不是發(fā)生過的事，也不會去推測“本來會怎樣”或“本來有可能怎樣”。協(xié)調(diào)人可以宣讀來自 Retrospective.com 網(wǎng)站的“回顧基本指導(dǎo)原則”。此外，協(xié)調(diào)人將提醒大家，得出的任何對策都一定要分配到具體的人，如果糾正措施不能成為這個會議后的首要任務(wù)，那么這就不是糾正措施。（這是為了防止會議上討論了一系列好想法，可是永遠(yuǎn)也不付諸行動。）
- 在會議期間要對事故完整的時間表達成一致的認(rèn)識。包括在什么時間、是誰發(fā)現(xiàn)的問題，通過什么途徑發(fā)現(xiàn)的問題（例如，自動監(jiān)測、手動檢測、客戶反饋），在什么時間服務(wù)得到了徹底的恢復(fù)，等等。我們還將在事故發(fā)生期間所有的外部討論歸納到時間表中。提到“時間表”，大家可能會理解為調(diào)查問題并解決問題的步驟。實際上，特別是在復(fù)雜的系統(tǒng)中，導(dǎo)致事故發(fā)生的事件可能會有許多，并且將會采取多種解決問題的故障排查方案和措施。 在這項活動中，我們試圖記錄所有的事件和所有參與者的觀點，并盡可能地建立出各種可能的因果關(guān)系的假設(shè)。
- 事后分析團隊將列出所有造成事故的人為因素和技術(shù)因素，并將其歸類，如“設(shè)計決策”“修復(fù)”“發(fā)現(xiàn)的問題”等。團隊將使用頭腦風(fēng)暴和“十萬個怎么樣”方法，對他們認(rèn)為特別重要的誘因進行深入挖掘，從而探索更深層次的誘因。所有的觀點都應(yīng)當(dāng)?shù)玫桨莺妥鹬?，不允許爭論或否認(rèn)其他人已經(jīng)確認(rèn)的誘因。會議協(xié)調(diào)人特別需要注意的是，必須確保做這項活動的時間充足，而且團隊不應(yīng)嘗試去異存同，不要試圖確定出一個或幾個“根本原因”。
-
與會人員要就會后首要任務(wù)清單達成一致意見。清單所列內(nèi)容需要集思廣益，并選擇能防止問題復(fù)發(fā)的任務(wù)，或者能更快發(fā)現(xiàn)問題并復(fù)原的任務(wù)。列表還可以包括改進系統(tǒng)的其他方式。
我們的目標(biāo)是確定實現(xiàn)預(yù)期結(jié)果的最小增量步驟，而不是“大爆炸”式的變更，因為那不僅需要更長的實施時間，還會推遲改進。我們還會生成一份單獨的列表，列出那些優(yōu)先級較低的任務(wù)，并為其分配一個負(fù)責(zé)人。如果將來發(fā)生類似的問題，就可以基于這些任務(wù)制定對策。 -
與會人員還要討論事故的衡量指標(biāo)和事故對組織造成的影響。例如，我們可以使用下列指標(biāo)來定量描述事故。
- 事件嚴(yán)重性：這個問題的嚴(yán)重程度。嚴(yán)重性會直接影響服務(wù)和客戶。
- 總停機時間：服務(wù)完全不可用的時間。
- 檢測時間：發(fā)現(xiàn)問題所需的時間。
- 解決時間：知道問題以后恢復(fù)服務(wù)所用時間。
Etsy 公司的 Bethany Macri 是這么總結(jié)的：“在事故分析中對事不對人并不意味著沒有人承擔(dān)責(zé)任，而是想了解在什么情況下允許人員執(zhí)行變更，或者誰引入的問題。沒有責(zé)難，就沒有顧慮；沒有了顧慮，就可以坦誠相待?！?/p>
附錄 9 猿猴軍團
在 2011 年 AWS 的美東服務(wù)中斷事故之后，Netflix 曾就如何自動處理系統(tǒng)故障討論過多次。一個名為“搗亂猴”的服務(wù)就是這些討論的結(jié)果。
此后，搗亂猴逐漸演變成了一套全系列的工具，內(nèi)部稱之為“Netflix 猿猴軍團”，用來模擬災(zāi)難的不同程度
- 搗亂大猩猩：模擬整個 AWS 可用區(qū)域（ZA）的故障。
- 搗亂金剛：模擬整個 AWS 地區(qū)（Region）的故障，如北美或歐洲。
- 延遲猴子：在其 RESTful 客戶端服務(wù)器的通信層人為引入的延遲或停機，以模擬服務(wù)降級，并確保相關(guān)服務(wù)正常工作。
- 一致性猴子：查找并關(guān)閉不符合最佳實踐的 AWS 實例（例如，實例不屬于任何自動伸縮組，或服務(wù)目錄中沒有值班工程師的電子郵件地址）。
- 醫(yī)生猴子：檢查每個運行的實例，找到不健康的實例，如果負(fù)責(zé)人沒有及時修復(fù)，就主動關(guān)閉實例。
- 看門猴子：確保他們的云環(huán)境沒有混亂和浪費，搜索未使用的資源并處理。
- 安全猴子：一致性猴子的升級版，找到并終止有安全違規(guī)或漏洞的實例，例如 AWS 安全組配置錯誤。
附錄 10 上線時間透明化
Lenny Rachitsky 這么陳述他所謂的“上線時間透明化”的優(yōu)勢。文章來源：http://www.zghlxwxcb.cn/news/detail-732156.html
- (1) 支持的成本下降。因為用戶能夠自己識別系統(tǒng)里的問題，無需打電話或發(fā)電子郵件給支持部門。用戶不再需要猜測是本地問題還是全局性問題，并且可以在跟運維抱怨之前更快速地定位問題。
- (2) 在宕機期間能與客戶更良性溝通。利用互聯(lián)網(wǎng)傳播的優(yōu)勢而不是電子郵件、電話這種一對一性方式，能實現(xiàn)更好的溝通效果。在客戶溝通上省事了，就有更多時間來解決問題。
- (3) 讓客戶在發(fā)生宕機事故時有明確的可尋求幫助的途徑，不必再四處搜索論壇、Twitter 或博客。
- (4) 信任是所有 SaaS 應(yīng)用成功的基石?？蛻魧⒆约旱臉I(yè)務(wù)和生計都押寶在了你的服務(wù)或平臺上。現(xiàn)有和潛在的客戶都需要信任服務(wù)。他們想確保當(dāng)服務(wù)出現(xiàn)問題時自己也有知情權(quán)。讓他們實時了解意外事件是建立信任的最佳方法，向客戶隱瞞實情不再可取。
- (5) 認(rèn)真負(fù)責(zé)的 SaaS 提供商早晚都會提供公開的健康度儀表板，這只是時間問題，因為用戶有這樣的需求。
26. 術(shù)語
DOP & Handbook Glossary文章來源地址http://www.zghlxwxcb.cn/news/detail-732156.html
| 英文 | 中文 |
|---|---|
| A/B Testing | A/B 測試 |
| Acceptance Stage | 驗收階段 |
| Acceptance Test-Driven Development (ATDD) | 驗收測試驅(qū)動開發(fā) |
| Acceptance Test | 驗收測試 |
| Accident | 事故 |
| Affinity | 親和 |
| Agile | 敏捷 |
| Andon Cord | 安燈繩 |
| Anomaly Detection Technique | 異常探測技術(shù) |
| Antifragility | 抗脆弱性 |
| Application Deployment | 應(yīng)用部署 |
| Artifact Management | 構(gòu)件制品庫管理 |
| Artifact | 制品 |
| Automated Test | 自動化測試 |
| Automation | 自動化 |
| Backlog | 待辦事項列表 |
| Bad Apple Theory | 壞蘋果理論 |
| Bad Path | 壞路徑 |
| Batch Size | 批次尺寸、批量大小 |
| Blame | 指責(zé) |
| Blameless Post Mortem | 不指責(zé)的事后分析 |
| Blamelessness | 免責(zé) |
| Blue-Green Deployment | 藍(lán)綠部署 |
| Blue-Green Deployment Pattern | 藍(lán)綠部署模式 |
| Branching Strategy | 分支策略 |
| Brownfield | 棕地 |
| Build | 構(gòu)建 |
| Business Value | 業(yè)務(wù)價值 |
| Canary Release | 金絲雀發(fā)布 |
| Canary Release Pattern | 金絲雀發(fā)布模式 |
| Card | 卡片 |
| Change Category | 變更類別 |
| Change Schedule | 變更計劃 |
| Cloud Computing | 云計算 |
| Cloud Configuration File | 云配置文件 |
| Cluster Immune System Release Pattern | 集群免疫系統(tǒng)發(fā)布模式 |
| Code Branch | 代碼分支 |
| Code Review Form | 代碼審查表 |
| Codified Nfr | 成文的非功能需求 |
| Collaboration | 協(xié)作 |
| Commit Stage | 提交階段 |
| Commit Code | 提交代碼 |
| Compliance Requirement | 合規(guī)性要求 |
| Compliance Checking | 合規(guī)性檢查 |
| Compliancy Officer | 合規(guī)檢測官 |
| Configuration Management | 配置管理 |
| Container | 容器 |
| Continuous Deployment | 持續(xù)部署 |
| Continuous Integration | 持續(xù)集成（CI） |
| Continuous Delivery | 持續(xù)交付（CD） |
| Conways Law | 康威定律 |
| Cycle Time | 周期時間 |
| Defect Tracking | 缺陷跟蹤 |
| Definition Of Done (DoD) | 完成的定義 |
| Dev Ritual | 開發(fā)慣例 |
| Developer | 開發(fā)人員 |
| Development | 開發(fā) |
| Devops Transformation | DevOps 轉(zhuǎn)型 |
| Downstream/Upstream | 下游/上游 |
| Downwards Spiral | 惡性循環(huán) |
| E-Mail Pass-Around | 電子郵件輪查 |
| Expand/Contract Pattern | 擴張/收縮模式 |
| Exploratory Test | 探索性測試 |
| Fast Feedback | 快速反饋 |
| Feature | 特性 |
| Feature Flag | 特性標(biāo)志 |
| Feature Toggle | 特性開關(guān) |
| Feedback/Feedback Loop | 反饋/反饋回路 |
| Feedforward/Feedforward Loop | 前饋/前饋回路 |
| Flow | 流動 |
| Gated Commit | 門控提交 |
| Gaussian Distribution | 高斯分布 |
| Green Build | 綠色構(gòu)建 |
| Greenfield | 綠地 |
| Handoff | 交接 |
| Hand-Off Readiness Review | 交接就緒評審 |
| Happy Path | 愉快路徑 |
| Hypothesis-Driven Development | 假設(shè)驅(qū)動開發(fā) |
| Incident | 事件 |
| Information Radiator | 信息輻射器 |
| Infosec | 信息安全 |
| Infrastructure Automation | 基礎(chǔ)架構(gòu)自動化 |
| Infrastructure As Code | 基礎(chǔ)架構(gòu)即代碼 |
| Integration Tests | 集成測試 |
| I-Shaped, T-Shaped, E-Shaped | I 型、T 型、E 型 |
| Iteration | 迭代 |
| Itsm (It Service Management) | IT 服務(wù)管理 |
| Ji-Kotei-Kanketsu (JKK) | 質(zhì)量檢查（JKK） |
| Just Culture | 公正文化 |
| Just-In-Time (JIT) | 準(zhǔn)時制 |
| Kaizen (In Lean) | 改善 |
| Kaizen Blitz (Or Improvement Blitz) | 改善閃電戰(zhàn) |
| Signboard | 看板 |
| Kata | 套路 |
| Large Batch Size Merge | 大批量合并 |
| Latent Defect | 潛在缺陷 |
| Lauching Guidance | 發(fā)布指導(dǎo) |
| Launch Readiness Review | 投產(chǎn)就緒評審 |
| Lead Time | 前置時間 |
| Lean | 精益 |
| Learning Culture | 學(xué)習(xí)文化 |
| Logging Level | 日志級別 |
| Loosely Coupled Architecture | 松耦合架構(gòu) |
| Micro-Service | 微服務(wù) |
| Minimum Viable Product | 最小化可行產(chǎn)品 |
| Monitoring Framework | 監(jiān)控框架 |
| Monolithic Application | 單體應(yīng)用 |
| Monolytics | 單體應(yīng)用 |
| MTTR | 平均恢復(fù)時間 |
| Non-Functional Requirement (NFR) | 非功能性需求 |
| Non-Functional Requirement (NFR) Testing | 非功能需求測試 |
| (Non) Ideal Testing Pyramid | （非）理想測試金字塔模型 |
| One-Piece-Flow | 單件流 |
| Operations | 運維 |
| Operations Story | 運維故事 |
| Ops Liaison | 運維聯(lián)絡(luò)人 |
| Organisational Typology Model | 組織結(jié)構(gòu)模型 |
| Organization Archetype | 組織原型 |
| Organizational Learning | 組織級學(xué)習(xí) |
| Over-The-Shoulder | 觀察者評審 |
| Package | 包 |
| Pair Programming | 結(jié)對編程 |
| Peer Review | 同行評審 |
| Pilot | 試點 |
| Pipeline | 流水線 |
| Plan-Do-Check-Act Cycle (PDCA Cycle) | 計劃-實施-檢查-改進循環(huán)（戴明環(huán)） |
| Post-Mortem | 事后分析 |
| Process Time | 處理時間 |
| Product Owner | 產(chǎn)品負(fù)責(zé)人 |
| Pull Request Process | 拉動請求流程 |
| QA | 質(zhì)量保證 |
| Reduce Batch Size | 降低批次尺寸 |
| Reduce Number Of Handoffs | 減少交接次數(shù) |
| Regression Test | 回歸測試 |
| Release Branch | 發(fā)布分支 |
| Release Manager | 發(fā)布經(jīng)理 |
| Release Pattern | 發(fā)布模式 |
| Retrospective | 回顧 |
| Rhythm | 節(jié)奏 |
| Roll-Back | 回滾 |
| Sad Path | 不愉快路徑 |
| Safety Culture | 安全文化 |
| Safety Conditions | 安全條件 |
| Scaling | 規(guī)?；?/td> |
| Scrum | Scrum |
| Scrum Master | Scrum Master |
| Security Testing | 安全測試 |
| Self Service Capability | 自服務(wù)能力 |
| Service Deployment | 服務(wù)部署 |
| Service Level Agreement (SLA) | 服務(wù)級別協(xié)議（SLA） |
| Shared Goal | 共同目標(biāo) |
| Shared Operations Team (SOT) | 共享運維團隊 |
| Shared Version Control | 共享版本控制 |
| Single Repository | 單一存儲庫 |
| Smoke Testing | 冒煙測試 |
| Sprint | 沖刺 |
| Staging | Staging |
| Staging Environments, SIT | 準(zhǔn)生產(chǎn)環(huán)境 |
| Stakeholder | 利益干系人 |
| Standard Deviation | 標(biāo)準(zhǔn)差 |
| Standard Operations | 標(biāo)準(zhǔn)運維 |
| Static Code Analysis | 靜態(tài)代碼分析 |
| Swarm | 聚集、聚焦、會診、圍觀（動詞） |
| Swarming | 聚集 |
| System Of Engagement (SOE) | 交互系統(tǒng) |
| System Of Records (SOR) | 記錄系統(tǒng) |
| Technical Debt | 技術(shù)債務(wù) |
| Technology Adaption Curve | 技術(shù)適應(yīng)曲線 |
| Technology Executive | 技術(shù)主管 |
| Telemetry | 遙測 |
| Test Coverage Analysis | 測試覆蓋率分析 |
| Test Story | 測試故事 |
| Test-Driven Development | 測試驅(qū)動開發(fā) |
| The Downward Spiral - TDS | 下行螺旋 |
| The Agile Manifesto | 敏捷宣言 |
| The Lean Movement | 精益運動 |
| The Simian Army: Chaos Gorilla Chaos Kong Conformity Monkey Doctor Monkey Janitor Monkey Latency Monkey Security Monkey |
猿猴軍團（可靠性監(jiān)控服務(wù)）： 搗亂大猩猩 搗亂金剛 一致性猴子 醫(yī)生猴子 看門猴子 延遲猴子 安全猴子 |
| The Three Ways | 三步工作法 |
| Theory Of Constraints | 約束理論 |
| Ticketing System | 工單系統(tǒng) |
| Tightly-Coupled | 緊耦合 |
| Tool-Assisted Review | 工具輔助評審 |
| Tool | 工具 |
| Toyota Production System (TPS) | 豐田生產(chǎn)系統(tǒng) |
| Toyoto Kata | 豐田套路 |
| Transformation Team | 轉(zhuǎn)型團隊 |
| Trunk | 主干 |
| User Story | 用戶故事 |
| Value Stream Mapping | 價值流映射 |
| Value Stream | 價值流 |
| Velocity | 速率 |
| Version Control | 版本控制 |
| Virtualized Environment | 虛擬化環(huán)境 |
| Visible | 可視的 |
| Visualisation | 可視化 |
| Waste | 浪費 |
| Waste Reduction | 減少浪費 |
| Waterfall | 瀑布式 |
| WIP (Work In Progress / Process) | 在制品 |
| WIP Limit | 在制品限制 |
| Work Center | 工作中心 |
到了這里，關(guān)于《DevOps實踐指南》- 讀書筆記（九）的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
