devops實(shí)踐指南.jpg

導(dǎo)言：展望DevOps新世界

1. 在現(xiàn)實(shí)中，系統(tǒng)經(jīng)常被破壞，服務(wù)和產(chǎn)品總是不盡如人意，團(tuán)隊(duì)的潛力無法得到正常發(fā)揮；在現(xiàn)實(shí)中，開發(fā)和IT運(yùn)維是對立的，測試和信息安全活動(dòng)總是在項(xiàng)目晚期才進(jìn)行，這導(dǎo)致即使發(fā)現(xiàn) 了問題也來不及修復(fù)；在現(xiàn)實(shí)中，產(chǎn)品和服務(wù)交付中的關(guān)鍵活動(dòng)往往全都需要手動(dòng)操作和互相交接，我們總是要等待其他人的工作完成才能進(jìn)行自己的工作；在現(xiàn)實(shí)中，特性交付的周期一次次被拖延，質(zhì)量也頻頻出現(xiàn)問題，特別是與生產(chǎn)環(huán)境部署相關(guān)的部分，進(jìn)而對客戶和業(yè)務(wù)造成了負(fù)面影響。結(jié)果，不僅是我們的工作無法按預(yù)期完成，整個(gè)公司也對IT部門的業(yè)績不滿意，甚至導(dǎo)致預(yù)算被削減，IT員工沒有成就感，感覺無力改變流程及其結(jié)果。怎么辦？我們需要改變工作方式，沒錯(cuò)，DevOps能夠給我們指引方向。Pxvii
2. 在制造業(yè)革命前（20世紀(jì)80年代的制造業(yè)革命），制造廠的平均交貨周期為6周，能按時(shí)交貨的訂單不到總量的70%。隨著精益實(shí)踐的廣泛實(shí)施，到2005年，產(chǎn)品的平均交貨周期縮短到3周以下，按時(shí)交貨的訂單超過總量的95%。而那些沒有實(shí)施精益實(shí)踐的廠商，不但漸漸失去了市場，有的甚至破產(chǎn)了。
   到21世紀(jì)初，由于技術(shù)的快速發(fā)展以及敏捷原則和實(shí)踐的應(yīng)用，新功能開發(fā)所需的時(shí)間已經(jīng)從幾年縮短至幾個(gè)月，但是部署到生產(chǎn)環(huán)境仍然需要幾周甚至數(shù)月，而且部署過程中還總是伴隨著大量不可預(yù)知的狀況。到2010年，隨著DevOps的出現(xiàn)，以及硬件、軟件和公有云的不斷商品化，任何特性（甚至整個(gè)公司的創(chuàng)建）都可以在幾個(gè)星期內(nèi)完成，并在幾小時(shí)或幾分鐘內(nèi)部署到生產(chǎn)環(huán)境中。Pxviii
3. 在幾乎所有的IT公司中，開發(fā)部門和IT運(yùn)維部門之間都存在一種固有沖突，這會(huì)讓公司業(yè) 績下滑，進(jìn)而導(dǎo)致新產(chǎn)品和新功能的上市時(shí)間拉長、質(zhì)量下降、服務(wù)中斷時(shí)間增加，甚至導(dǎo)致技術(shù)債務(wù)量與日俱增。Pxix
4. “技術(shù)債務(wù)”這個(gè)術(shù)語是Ward Cunningham首次提出的。類似于金融債務(wù)，技術(shù)債務(wù)是指我們當(dāng)前所做出的決定會(huì)導(dǎo)致一些問題，而這些問題隨著時(shí)間的推移會(huì)越來越難解決，未來可采取的措施也越來越少。即使我們審慎地承擔(dān)技術(shù)債務(wù)，也依然會(huì)產(chǎn)生利息。Pxix
5. 開發(fā)部門和IT運(yùn)維部門的目標(biāo)是對立的，這通常是產(chǎn)生技術(shù)債務(wù)的一個(gè)因素。IT公司需要負(fù)責(zé)的事情很多，其中包括下面兩個(gè)必須實(shí)現(xiàn)的目標(biāo)：Pxix
   • 對變化莫測的市場做出反應(yīng)；
   • 為客戶提供穩(wěn)定、可靠和安全的服務(wù)。

開發(fā)部門通常負(fù)責(zé)對市場變化做出響應(yīng)，以最快的速度將新功能或者變更上線。而IT運(yùn)維部門則要以為客戶提供穩(wěn)定、可靠和安全的IT服務(wù)為已任，讓任何人都很難甚至無法引入可能會(huì)危害生產(chǎn)環(huán)境的變更。這種配置方式讓開發(fā)部門和IT運(yùn)維部門的目標(biāo)和動(dòng)因之間存在巨大的沖突。稱這種配置為“根本的、長期的沖突”——公司對不同部門的考核和激勵(lì)不同，阻礙了公司全局目標(biāo)的實(shí)現(xiàn)。

6. 絕大多數(shù)投資項(xiàng)目都在某種程度上依賴于信息技術(shù)。俗話說：“想要做出一個(gè)不會(huì)帶來任何IT變更的商業(yè)決策幾乎不可能?！盤xxi
7. 許多心理學(xué)家認(rèn)為，創(chuàng)建一個(gè)讓人感覺無能為力的系統(tǒng)，是我們能對人類同胞做的最具破壞性的一件事——我們剝奪了他人控制自己成果的能力，甚至營造了一種文化，讓人們因?yàn)楹ε略馐軕土P、失敗或危及生存而不敢做正確的事。這創(chuàng)造了“習(xí)得性無助”的環(huán)境，人們變得不愿或 無法采取行動(dòng)來避免未來遇到同樣的問題。Pxxii
8. 自動(dòng)化測試可以幫助開發(fā)人員快速發(fā)現(xiàn)錯(cuò)誤（通常在幾分鐘之內(nèi)），實(shí)現(xiàn)更快速的修復(fù)以及6真正的學(xué)習(xí)。如果錯(cuò)誤是在6個(gè)月后的集成測試中發(fā)現(xiàn)的，那時(shí)相關(guān)的記憶和因果關(guān)系早已消退，想從中學(xué)習(xí)是不可能的。自動(dòng)化測試使技術(shù)債務(wù)不再積累，問題在發(fā)現(xiàn)之后就立即被修復(fù)了。如果需要，這還可以調(diào)動(dòng)整個(gè)公司參與問題的處理，因?yàn)榭傮w目標(biāo)高于局部目標(biāo)。Pxxiii
9. 在出現(xiàn)問題時(shí)，我們進(jìn)行不指責(zé)的事后分析，這并不是要懲罰某人，而是為了更好地理解導(dǎo)致事故的原因，以及如何防止事故再次發(fā)生。這個(gè)方法強(qiáng)化了我們的學(xué)習(xí)文化。我們還通過舉辦 內(nèi)部技術(shù)研討會(huì)來提高技能，保證所有人不是在教就是在學(xué)。Pxxiv
10. 應(yīng)用了DevOps的高績效公司在以下方面的表現(xiàn)遠(yuǎn)超低績效同行：Pxxv
    • 吞吐量指標(biāo)；
    • 代碼和變更部署次數(shù)（頻繁30倍）；
    • 代碼和變更部署前置時(shí)間（快200倍）；
    • 可靠性指標(biāo)；
    • 生產(chǎn)環(huán)境部署（變更成功率高60倍）；
    • 平均服務(wù)恢復(fù)時(shí)間（快168倍）；
    • 組織性能指標(biāo)；
    • 生產(chǎn)力、市場份額以及營業(yè)目標(biāo)（大約2倍以上）；
    • 市值增長（3年內(nèi)高出50%）。
11. Frederick Brooks 在其著名的《人月神話》一書中強(qiáng)調(diào)過這一點(diǎn)。他解釋說，當(dāng)項(xiàng)目延遲時(shí)，增加更多的開發(fā)人員不僅降低了單個(gè)開發(fā)人員的生產(chǎn)力，而且也降低了整體的生產(chǎn)力。Pxxv

第一部分 DevOps介紹

1. DevOps的三步工作法：流動(dòng)、反饋及持續(xù)學(xué)習(xí)與實(shí)驗(yàn)。P1
   • 流動(dòng)原則：它加速了從開發(fā)、運(yùn)維到交付給客戶的流程。
   • 反饋原則：它使我們能建設(shè)出更安全可靠的工作體系。
   • 持續(xù)學(xué)習(xí)與實(shí)驗(yàn)原則：它打造出一種高度信任的文化和一種科學(xué)的工作方式，并將對組織的改進(jìn)和創(chuàng)新作為日常工作的一部分。
2. DevOps和它所產(chǎn)生的技術(shù)、架構(gòu)及文化實(shí)踐，體現(xiàn)了哲學(xué)和管理學(xué)原則的融合。P1
3. DevOps基于精益、約束理論、豐田生產(chǎn)系統(tǒng)、柔性工程、學(xué)習(xí)型組織、安全文化、人員優(yōu)化因素等知識(shí)體系，并參考了高信任管理文化、服務(wù)型領(lǐng)導(dǎo)、組織變動(dòng)管理等方法論。把所有這些最可信的原則綜合地應(yīng)用到IT價(jià)值流中，就產(chǎn)生出DevOps這樣的成果。將它貫徹于整個(gè)技術(shù)價(jià)值流中，涉及產(chǎn)品管理、開發(fā)、QA、IT運(yùn)維和信息安全專員等不同角色，在更低的成本和努力下，保障產(chǎn)品的高質(zhì)量、可靠性、穩(wěn)定性和安全性。P1
4. 精益的兩個(gè)主要原則包括：堅(jiān)信前置時(shí)間（把原材料轉(zhuǎn)換為成品所需的時(shí)間）是提升質(zhì)量、客戶滿意度和員工幸福感的最佳度量指標(biāo)之一 ；小批量任務(wù)的交付是縮短前置時(shí)間的一個(gè)關(guān)鍵因素。P2
5. 在敏捷宣言中，一個(gè)重要的原則是“頻繁地交付可工作的軟件，交付周期可以是數(shù)星期也可以是數(shù)月，推薦更短的周期”，并強(qiáng)調(diào)使用小批量任務(wù)進(jìn)行增量發(fā)布，而非大規(guī)模的作業(yè)和瀑布流程的發(fā)布。同時(shí)，強(qiáng)調(diào)建立自組織的小團(tuán)隊(duì)，讓成員在高度信任的環(huán)境中愉悅地工作。P2
6. 精益社區(qū)中大多數(shù)企業(yè)都沒有抓住精益的核心——改善套路（Kata）。 他解釋說，所有企業(yè)都有日常的工作流程，而這些日常工作決定了最終的產(chǎn)出。通過設(shè)定目標(biāo)， 制訂每周的詳細(xì)計(jì)劃，并持續(xù)改善日常工作，如此循序漸進(jìn)，才能達(dá)到優(yōu)化和改進(jìn)的目的。P3

第1章 敏捷、持續(xù)交付和三步法

1. Value Stream Mapping 一書中把價(jià)值流定義為“一個(gè)組織基于客戶的需求所執(zhí)行的一系列有序的交付活動(dòng)”。在 DevOps 中，我們通常將技術(shù)價(jià)值流定義為“把業(yè)務(wù)構(gòu)想轉(zhuǎn)化為向客戶交付價(jià)值的、 由技術(shù)驅(qū)動(dòng)的服務(wù)所需要的流程”。P4
2. 在第一個(gè)階段中，工作主要包括設(shè)計(jì)和開發(fā)，它和精益產(chǎn)品開發(fā)有很多相似之處：都具有高度的變化性和不確定性，不僅需要?jiǎng)?chuàng)意，某些工作還可能無法重來，這導(dǎo)致無法確定總體處理時(shí)間。在第二個(gè)階段中，工作主要包括測試和運(yùn)維，它類似于精益制造。相比前一個(gè)階段，它需要?jiǎng)?chuàng)造性和專業(yè)技能，力求可預(yù)見性和自動(dòng)化，將可變性降到最低（如短的和可預(yù)測的前置時(shí)間，接近零缺陷），并滿足業(yè)務(wù)目標(biāo)。P5
3. 前置時(shí)間在工單創(chuàng)建后開始計(jì)時(shí)，到工作完成時(shí)結(jié)束；處理時(shí)間則從實(shí)際開始處理這個(gè)工作時(shí)才開始計(jì)時(shí)，它不包含這個(gè)工作在隊(duì)列中排隊(duì)等待的時(shí)間。因?yàn)榍爸脮r(shí)間是客戶能夠體驗(yàn)到的時(shí)間，所以我們把重點(diǎn)放在縮短前置時(shí)間而不是處理時(shí)間上。P5
4. 技術(shù)價(jià)值流中的第三個(gè)關(guān)鍵指標(biāo)是完成時(shí)間和精確的總花費(fèi)時(shí)間的百分比（%C/A）。該指標(biāo)反映了價(jià)值流中的每個(gè)步驟的輸出質(zhì)量。P7
5. 三步工作法：DevOps的基礎(chǔ)原則。P7
   • 第一步，實(shí)現(xiàn)開發(fā)到運(yùn)維的工作快速地從左向右流動(dòng)。為了最大程度地優(yōu)化工作流，需要將工作可視化，減小每批次大小和等待間隔，通過內(nèi)建質(zhì)量杜絕向下游傳遞缺陷，并持續(xù)地優(yōu)化全局目標(biāo)。
   • 第二步，在從右向左的每個(gè)階段中，應(yīng)用持續(xù)、快速的工作反饋機(jī)制。該方法通過放大反饋環(huán)防止問題復(fù)發(fā)，并能縮短問題檢測周期，實(shí)現(xiàn)快速修復(fù)。通過這種方式，我們能從源頭控制質(zhì)量，并在流程中嵌入相關(guān)的知識(shí)。這樣不僅能創(chuàng)造出更安全的工作系統(tǒng)，還可以在災(zāi)難性事故發(fā) 生前就檢測到并解決它。
   • 第三步，建立具有創(chuàng)意和高可信度的企業(yè)文化，支持動(dòng)態(tài)的、嚴(yán)格的、科學(xué)的實(shí)驗(yàn)。通過主動(dòng)地承擔(dān)風(fēng)險(xiǎn)，不但能從成功中學(xué)習(xí)，也能從失敗中學(xué)習(xí)。通過持續(xù)地縮短和放大反饋環(huán)，不僅能創(chuàng)造更安全的工作系統(tǒng)，也能承擔(dān)更多的風(fēng)險(xiǎn)，并進(jìn)行試驗(yàn)幫助自己比競爭對手改進(jìn)得更快， 從而在市場競爭中戰(zhàn)勝他們。

第2章 第一步：流動(dòng)原則

1. 通過持續(xù)加強(qiáng)工作內(nèi)容的可視化，減小每批次大小和等待間隔，內(nèi)建質(zhì)量以防止缺陷向下游傳遞，從而增強(qiáng)流動(dòng)性。通過加速技術(shù)價(jià)值流的流動(dòng)，可以縮短滿足內(nèi)部客戶和外部客戶需求的前置時(shí)間，進(jìn)一步提高工作質(zhì)量，并使我們更加敏捷，能夠比競爭對手更為出色。P9
2. 技術(shù)行業(yè)的工作內(nèi)容是不可見的，這是其與制造業(yè)價(jià)值流相比的一個(gè)顯著差異。另一方面，技術(shù)工作的流轉(zhuǎn)通過單擊一次鼠標(biāo)就可以完成，譬如將工單重新指派給另一個(gè)團(tuán)隊(duì)。由于點(diǎn)擊的操作太過容易，所以不同團(tuán)隊(duì)可能會(huì)因?yàn)樾畔⒉煌暾鴮⒐ぷ鳌疤邅硖呷ァ?，存在的問題也會(huì)被傳遞到下游工序，而這些問題完全是不易察覺的，直到無法按時(shí)向客戶交付產(chǎn)品，或者應(yīng)用程序在生產(chǎn)環(huán)境中出了問題。P9
3. 通過限制在制品數(shù)，還能更容易地發(fā)現(xiàn)工作中的阻礙。P10
4. 在精益中，一個(gè)重要的經(jīng)驗(yàn)是：為了縮短前置時(shí)間和提高交付物質(zhì)量，應(yīng)當(dāng)持續(xù)不斷地追求小批量模式。理論上，最小的批量是單件流，也就是每次操作只執(zhí)行一個(gè)單位產(chǎn)品的處理。P12
5. 一項(xiàng)工作在團(tuán)隊(duì)之間交接時(shí)，需要大量的溝通——請求、委派、通知、協(xié)調(diào)，而且經(jīng)常需要排優(yōu)先級(jí)、調(diào)度、消除沖突、測試和驗(yàn)證。這些工作可能還需要使用不同的工單系統(tǒng)或項(xiàng)目管理系統(tǒng)，編寫技術(shù)規(guī)范文檔，用會(huì)議、電子郵件或電話的形式進(jìn)行溝通，可能還涉及文件共享服務(wù)器、FTP服務(wù)器和Wiki頁面的使用。
   為了減少這類問題的出現(xiàn)，要么努力減少交接次數(shù)，要么用自動(dòng)化方式執(zhí)行大部分操作，要么重新調(diào)整組織結(jié)構(gòu)，讓團(tuán)隊(duì)不必依賴其他人就可以獨(dú)立地為客戶提供價(jià)值。因此，要通過減少隊(duì)列中的等待時(shí)間以及非增值工作的時(shí)間來增加流動(dòng)性。P13
6. 在任何價(jià)值流中，總是有一個(gè)流動(dòng)方向、一個(gè)約束點(diǎn)，任何不針對此約束點(diǎn)而做的優(yōu)化都是假象。P14
   • 識(shí)別系統(tǒng)的約束點(diǎn)；
   • 決定如何利用這個(gè)系統(tǒng)約束點(diǎn)；
   • 基于上述決定，考慮全局工作；
   • 改善系統(tǒng)的約束點(diǎn)；
   • 如果約束點(diǎn)已經(jīng)突破了，請回到第一步，但要杜絕慣性導(dǎo)致的系統(tǒng)約束。
7. 在DevOps的轉(zhuǎn)型過程中，如果希望前置時(shí)間從月或季度縮短為幾分鐘，那么一般需要依次優(yōu)化下面的約束點(diǎn)。P14
   • 環(huán)境搭建。
   • 代碼部署。
   • 測試的準(zhǔn)備和執(zhí)行。
   • 緊密耦合的架構(gòu)。
8. 精益中對浪費(fèi)的常用定義是“使用了超出客戶需求和他們愿意支付范圍的任何材料或資源的行為”。P15
9. 浪費(fèi)和困境是軟件開發(fā)過程中導(dǎo)致交付延遲的主要因素。關(guān)于浪費(fèi)和困境的部分類型。P15
   • 半成品：它指的是價(jià)值流里任何還沒有徹底完成的工作。
   • 額外工序：在交付過程中執(zhí)行的、并未給客戶增值的額外工作，可能包括那些在下游工10作中心從沒使用過的文檔，或是對輸出結(jié)果做出的并不增值的評(píng)審或?qū)徟?/li>
   • 任務(wù)切換：將人員分配到多個(gè)項(xiàng)目和價(jià)值流里后，他們需要進(jìn)行上下文切換，并管理工 作之間的依賴關(guān)系，這會(huì)在價(jià)值流中耗費(fèi)額外的工作量和時(shí)間。
   • 等待：由于資源的競爭而在工作之間產(chǎn)生了等待，這將增加周期時(shí)間，延遲了向客戶交付價(jià)值。
   • 移動(dòng)：信息或數(shù)據(jù)在工作中心之間移動(dòng)的工作量。
   • 缺陷：由于信息、材料或產(chǎn)品的錯(cuò)誤、殘缺或模糊，而需要一定的工作量來確認(rèn)。缺陷 的產(chǎn)生和被檢測出來的時(shí)間間隔越長，解決問題就越困難。

第3章 第二步：反饋原則

1. 反饋回路是學(xué)習(xí)型組織和系統(tǒng)思維的重要組成部分。反饋和前饋回路讓系統(tǒng)內(nèi)各部件之間的關(guān)系增強(qiáng)或抵消。P18
2. 在制造業(yè)，如果缺乏有效的反饋機(jī)制，往往會(huì)釀成重大質(zhì)量和安全問題。有這樣一個(gè)典型的案例：通用汽車的弗里蒙特制造廠既沒有有效的流程來檢測裝配過程中的問題，也沒有明確的步驟來解決問題。結(jié)果導(dǎo)致了各種問題，比如發(fā)動(dòng)機(jī)倒置，汽車缺少方向盤或輪胎，甚至是由于根本無法啟動(dòng)，不得不把汽車拖出裝配流水線。P19
3. 反饋回路不但能讓問題的快速探測和修復(fù)成為可能，而且還能告訴我們?nèi)绾畏乐箚栴}復(fù)發(fā)。這樣做不但提高了工作系統(tǒng)的質(zhì)量和安全性，還創(chuàng)造了組織性知識(shí)。P19
4. 群策群力的原因如下：P20
   • 防止把問題帶入下游的處理環(huán)節(jié)，否則不但修復(fù)的成本和工作量會(huì)呈指數(shù)級(jí)增加，而且還會(huì)欠下技術(shù)債；
   • 防止工作中心啟動(dòng)新的工作，那樣可能會(huì)在系統(tǒng)中引入新的錯(cuò)誤；
   • 如果問題還沒有得到解決，那么工作中心在下一次操作（如55秒后）中，可能還會(huì)遇到相同的問題，需要更高的修復(fù)成本。
5. 全民總動(dòng)員是“實(shí)時(shí)的問題識(shí)別、定位和處理（在制造業(yè)稱為對策或糾正措施）循環(huán)的一部分。這就是休哈特提出的循環(huán)（即PDCA環(huán))——計(jì)劃（Plan）、實(shí)施
   （Do）、檢查（Check）、改進(jìn)（Act），后來由愛德華茲·戴明推廣并得到了迅猛發(fā)展”。P20

第4章 第三步：持續(xù)學(xué)習(xí)與實(shí)驗(yàn)原則

1. 技術(shù)價(jià)值流的核心是建立高度信任的文化。它強(qiáng)調(diào)每個(gè)人都是持續(xù)學(xué)習(xí)者，必須在日常工作中承擔(dān)風(fēng)險(xiǎn);通過科學(xué)的方式改進(jìn)流程和開發(fā)產(chǎn)品，從成功和失敗中積累經(jīng)驗(yàn)教訓(xùn)，從而識(shí)別有價(jià)值的想法，摒棄無用的想法。另外，所有局部的經(jīng)驗(yàn)都會(huì)快速轉(zhuǎn)化為全局性的改進(jìn)，從而幫助整個(gè)組織嘗試和實(shí)踐新技術(shù)。P23
2. 企業(yè)文化中安全和績效重要性的鼻祖之一。他曾指出，在醫(yī)療機(jī)構(gòu)中，患者的生命安危高度依賴于醫(yī)療機(jī)構(gòu)的“生機(jī)”文化。他定義了三種類型的文化。P24
   • 病態(tài)型：病態(tài)型組織的特點(diǎn)是組織中存在大量恐懼和威脅。由于政治原因，個(gè)體為了保全自身利益，通常會(huì)隱瞞真相或者歪曲事實(shí)。在這種組織中，故障和事故經(jīng)常被隱瞞。
   • 官僚型：官僚型組織的特點(diǎn)是規(guī)則和流程僵化，所有部門通常都“自掃門前雪”。在這種組織中，通過評(píng)判系統(tǒng)處理事故，結(jié)果往往恩威兼施。
   • 生機(jī)型：生機(jī)型組織的特點(diǎn)是積極探索和分享信息，讓組織更好地履行使命。在這種組織中，整個(gè)價(jià)值流中所有的員工共同承擔(dān)責(zé)任，對事故進(jìn)行積極反思，并進(jìn)行真正的根因調(diào)查。
3. 如果不指責(zé)，員工就沒有了恐懼，沒有了恐懼，就能夠做到坦誠，而坦誠能夠有效預(yù)防事故。消除指責(zé)能夠有效實(shí)現(xiàn)學(xué)習(xí)型組織，使“組織自我診斷和自我優(yōu)化，并能熟練地定位和解決問題”。P25
4. 領(lǐng)導(dǎo)力的優(yōu)秀并非體現(xiàn)在做出的所有決定都是對的。相反，更卓越的領(lǐng)導(dǎo)力其實(shí)是為團(tuán)隊(duì)創(chuàng)造條件，讓團(tuán)隊(duì)能在日常工作中感受到這種卓越。換句話說，這需要領(lǐng)導(dǎo)者和員工們共同的努力，每個(gè)人都相互依存，缺一不可。P28
5. 清晰地描述出要解決的問題，對解決方案所做的假設(shè)，驗(yàn)證假設(shè)的方法，對結(jié)果的解釋，以及如何利用經(jīng)驗(yàn)進(jìn)行下一個(gè)迭代。P28
   • 上一步做了什么？發(fā)生了什么？
   • 你從中學(xué)到了什么？
   • 現(xiàn)狀如何？
   • 下一個(gè)目標(biāo)條件是什么？
   • 當(dāng)前工作有什么阻礙？
   • 下一步做什么？
   • 期望的結(jié)果是什么？
   • 什么時(shí)候能進(jìn)行復(fù)查？

第二部分 從何處開始

第5章 選擇合適的價(jià)值流作為切入點(diǎn)

1. 我們必須認(rèn)真挑選轉(zhuǎn)型項(xiàng)目，因?yàn)樵谟龅嚼щy時(shí)，我們并沒有退路。必須仔細(xì)挑選和保護(hù)那些最有可能改善組織現(xiàn)狀的重點(diǎn)轉(zhuǎn)型項(xiàng)目。P32
2. 他們的第一個(gè)目標(biāo)，是提高發(fā)布速度或?qū)崿F(xiàn)按需發(fā)布，從而擁有更強(qiáng)的迭代能力和對客戶反饋的響應(yīng)能力。為此，他們專門組建了一個(gè)為移動(dòng)端應(yīng)用提供支持的產(chǎn)品團(tuán)隊(duì)，讓這個(gè)團(tuán)隊(duì)能夠獨(dú)立地開發(fā)、測試并向客戶交付價(jià)值。通過這種方式，該團(tuán)隊(duì)不再需要依賴內(nèi)部的其他團(tuán)隊(duì)，也不再需要與它們協(xié)作。此外，將一年一次的規(guī)劃改為持續(xù)規(guī)劃。這樣一來，他們便能根據(jù)客戶需求為移動(dòng)端應(yīng)用制作一份獨(dú)立的優(yōu)先級(jí)工作清單，從而避免由于同時(shí)支持多個(gè)產(chǎn)品而導(dǎo)致的優(yōu)先級(jí)沖突。P33
3. 軟件服務(wù)或產(chǎn)品常被分為綠地項(xiàng)目和棕地項(xiàng)目，這兩個(gè)術(shù)語最初用于描述城市規(guī)劃和建設(shè)項(xiàng)目。綠地項(xiàng)目是指在未開發(fā)的土地上建設(shè)的項(xiàng)目，而棕地項(xiàng)目則是指在以前用于工業(yè)生產(chǎn)的土地上建設(shè)的項(xiàng)目，這樣的土地可能受到有毒物質(zhì)或污染物的侵蝕。P34
4. 應(yīng)用的年齡并不是影響性能的主要因素；相反，性能取決于應(yīng)用架構(gòu)在當(dāng)前（或重構(gòu)后）是否具有可測試性和可部署性。P35
5. 高德納公司近年來幫助雙模IT（bimodalIT）這一概念得到普及。雙模IT指的是企業(yè)能夠支持各種類型的服務(wù)演進(jìn)。在雙模IT中，傳統(tǒng)的記錄型系統(tǒng)是指類似于ERP的系統(tǒng)，它的交易和數(shù)據(jù)的正確性是至關(guān)重要的；交互型系統(tǒng)則是指面向客戶或員工的可交互系統(tǒng)，例如電子商務(wù)系統(tǒng)和辦公軟件。記錄型系統(tǒng)的變化速度通常較慢，稱這種系統(tǒng)為“類型1”，側(cè)重于“做得正確”。交互型系統(tǒng)的變化速度通常較快，因?yàn)樗枰焖夙憫?yīng)反饋，通過實(shí)驗(yàn)找到最能滿足客戶需求的方式。稱這種系統(tǒng)為“類型2”，側(cè)重于“做得快速”。P36
6. 所謂跨越鴻溝，是指客戶困難并找到比創(chuàng)新者和早期采用者更大的群體。P36
7. 擴(kuò)大DevOps范圍。P37
   • 發(fā)現(xiàn)創(chuàng)新者和早期采用者：一開始，把重點(diǎn)放在真正有意愿改進(jìn)的團(tuán)隊(duì)上。這些同事與我們志同道合，他們是探索DevOps的第一批志愿者。這些同事最好受人尊重，并對組織中的其他人有著很大的影響力。他們的支持有助于提升創(chuàng)新的可信度。
   • 贏得沉默的大多數(shù):在下一階段，力求將DevOps實(shí)踐擴(kuò)展到更多的團(tuán)隊(duì)和價(jià)值流，目標(biāo)是建立更穩(wěn)固的群眾基礎(chǔ)。通過與接受DevOps的團(tuán)隊(duì)合作，即便他們并不是最有影響力的團(tuán)隊(duì)，也能對擴(kuò)大群眾基礎(chǔ)有所幫助。有了更多的成功之后，就會(huì)產(chǎn)生從眾效應(yīng)，進(jìn)一步增強(qiáng)影響力。需要謹(jǐn)慎避免與唱反調(diào)的人發(fā)生沖突。
   • 識(shí)別”釘子戶”:所謂“釘子戶”，是指那些高調(diào)的、有影響力的反對者。他們最有可能抵制（甚至破壞）DevOps計(jì)劃。一般來說，只有在獲得大多數(shù)人的支持并建立起足夠穩(wěn)固的群眾基礎(chǔ)后，才考慮如何應(yīng)對這個(gè)群體。
8. “小魚在小池塘里成為大魚?！蓖ㄟ^謹(jǐn)慎地選擇DevOps轉(zhuǎn)型的切入點(diǎn)，我們在組織的某些領(lǐng)域內(nèi)進(jìn)行實(shí)驗(yàn)、學(xué)習(xí)并創(chuàng)造價(jià)值，但不會(huì)給整個(gè)組織帶來不可逆的后果。同時(shí)，通過這種方式，我們能夠建立穩(wěn)固的群眾基礎(chǔ)，贏得在組織中推廣DevOps的機(jī)會(huì)，從而獲得更多支持者的認(rèn)可和感激。P38

第6章 理解、可視化和運(yùn)用價(jià)值流

1. 在選擇好DevOps試點(diǎn)應(yīng)用或服務(wù)后，必須確定價(jià)值流的所有成員，他們有責(zé)任共同為客戶創(chuàng)造價(jià)值。確定了價(jià)值流的相關(guān)成員之后，下一步是深入理解工作方式，并用價(jià)值流圖進(jìn)行記錄。在價(jià)值流中，最初的工作是確定客戶需求或進(jìn)行業(yè)務(wù)構(gòu)思，這由產(chǎn)品負(fù)責(zé)人完成；然后，開發(fā)團(tuán)隊(duì)接手，他們通過編程實(shí)現(xiàn)相關(guān)功能，并將代碼提交到版本控制系統(tǒng)中；接下來，在類生產(chǎn)環(huán)境中對功能進(jìn)行集成和測試，最后部署到（理想情況下）能為客戶創(chuàng)造價(jià)值的生產(chǎn)環(huán)境中。P40
2. 繪制價(jià)值流圖的目標(biāo)并不是記錄所有的步驟和細(xì)節(jié)，而是識(shí)別出阻礙價(jià)值流快速流動(dòng)的環(huán)節(jié)，從而縮短前置時(shí)間和提高可靠性。根據(jù)價(jià)值流參與團(tuán)隊(duì)所提供的全部信息，應(yīng)該重點(diǎn)分析和優(yōu)化下面兩類工作：P41
   • 需要等待數(shù)周甚至數(shù)月的工作，例如準(zhǔn)備類生產(chǎn)環(huán)境、變更審批流程或安全審查流程等；
   • 引發(fā)或處理重大返工的工作。
3. 價(jià)值流圖的初始版本應(yīng)該只包含重要的流程模塊。即使是針對復(fù)雜的價(jià)值流，參與小組通常也可以在幾個(gè)小時(shí)內(nèi)繪制出包含5~15個(gè)模塊的價(jià)值流圖。每個(gè)模塊至少應(yīng)包括工作項(xiàng)的前置時(shí)間和處理時(shí)間（分別為圖 6-1 中的 LT 和 VA2），以及由下游消費(fèi)者測量的%C/A。P41
4. 應(yīng)該組建專門的轉(zhuǎn)型團(tuán)隊(duì)，并使之獨(dú)立于負(fù)責(zé)日常運(yùn)作的部門（他們稱前者為“專職團(tuán)隊(duì)”，稱后者為“績效引擎”）。最重要的是，這個(gè)團(tuán)隊(duì)?wèi)?yīng)該負(fù)責(zé)實(shí)現(xiàn)明確定義的、可度量的、系統(tǒng)級(jí)的目標(biāo)（例如，將“從提交代碼到部署至生產(chǎn)環(huán)境”這一過程的前置時(shí)間減少50%）。為了做到這一點(diǎn)，應(yīng)該采取以下措施：P43
   • 轉(zhuǎn)型團(tuán)隊(duì)的成員專門執(zhí)行DevOps轉(zhuǎn)型工作（而不是讓他們繼續(xù)做之前的工作，但要花 20%的時(shí)間來做DevOps轉(zhuǎn)型）；
   • 選擇熟悉多個(gè)領(lǐng)域的通才作為團(tuán)隊(duì)成員；
   • 選擇與其他部門長期保持良好關(guān)系的人作為團(tuán)隊(duì)成員；
   • 如果可能，為團(tuán)隊(duì)找一個(gè)獨(dú)立的辦公區(qū)域，使各位成員盡可能多地相互交流，并和其他部門保持適當(dāng)?shù)木嚯x。
5. 在任何 DevOps 轉(zhuǎn)型項(xiàng)目中，都需要保持小跨度的改進(jìn)計(jì)劃，正如創(chuàng)業(yè)公司做產(chǎn)品開發(fā)或客戶開發(fā)一樣。應(yīng)該努力在數(shù)周內(nèi)(最差也應(yīng)該在數(shù)月內(nèi))獲得可度量的改進(jìn)成果或者可用的數(shù)據(jù)。通過縮短計(jì)劃跨度和迭代間隔，可以做到以下幾點(diǎn)：P44
   • 具備重新計(jì)劃和更改優(yōu)先級(jí)的能力和靈活性；
   • 減少工作從實(shí)施到生效的延遲時(shí)間，從而加強(qiáng)反饋回路，這將更有可能強(qiáng)化期望的行為——初步成功有利于加大投入；
   • 從迭代中更快地獲得經(jīng)驗(yàn)，并將其用于下一次迭代；
   • 能夠更省力地獲得改進(jìn)；
   • 在日常工作中更快地實(shí)現(xiàn)有意義的差異化改進(jìn)；
   • 降低項(xiàng)目還沒有取得成果就被終止的風(fēng)險(xiǎn)。
6. 為了積極地管理技術(shù)債務(wù)，要確保至少把20%的開發(fā)和運(yùn)維時(shí)間投入到重構(gòu)、自動(dòng)化工作、架構(gòu)優(yōu)化以及非功能性需求（有時(shí)也稱為“質(zhì)量屬性”）上，例如可維護(hù)性、可管理性、可擴(kuò)展性、可靠性、可測試性、可部署性和安全性等。P44
7. 產(chǎn)品負(fù)責(zé)人和工程師之間的協(xié)作是這樣的：產(chǎn)品負(fù)責(zé)人需要考慮把團(tuán)隊(duì)20%的資源分配給與工程相關(guān)的活動(dòng)，用于重寫或重構(gòu)代碼庫中有問題的部分，或者工程師認(rèn)為有必要改進(jìn)的部分，從而避免有一天他們對團(tuán)隊(duì)說：“我們需要停下來重寫所有代碼?！比绻闆r已經(jīng)非常糟糕了，那就可能需要投入30%甚至更多的資源。然而，如果發(fā)現(xiàn)團(tuán)隊(duì)認(rèn)為他們不需要20%的資源就能做這些事情，我會(huì)感到非常擔(dān)心。P44
8. LinkedIn 的“反轉(zhuǎn)行動(dòng)”（Operation InVersion）在兩個(gè)月內(nèi)，停止所有特性開發(fā)，并對計(jì)算環(huán)境、部署和架構(gòu)進(jìn)行全面的優(yōu)化。P45

第7章 參考康威定律設(shè)計(jì)組織結(jié)構(gòu)

1. 康威在他的論文中寫道：“在對工作難度和工作時(shí)間進(jìn)行了初步評(píng)估以后，其中5人被分配到了COBOL開發(fā)小組，剩余3人被分配到了ALGOL開發(fā)小組。結(jié)果是，COBOL編譯器有5個(gè)執(zhí)行階段，ALGOL編譯器則有3個(gè)。”之后，康威提出了著名的康威定律：“軟件的架構(gòu)和軟件團(tuán)隊(duì)的結(jié)構(gòu)是一致的，說白了就是‘如果讓4個(gè)團(tuán)隊(duì)開發(fā)同一個(gè)編譯器，那么編譯器最后會(huì)有 4 個(gè)執(zhí)行階段’?！盤50
2. 在決策科學(xué)領(lǐng)域，主要有3種組織結(jié)構(gòu)類型:職能型、矩陣型和市場型。P51
   • 職能型組織結(jié)構(gòu)注重提高專業(yè)技能、優(yōu)化分工或降低成本。這些組織以專業(yè)技能為中心， 有助于促進(jìn)職業(yè)發(fā)展和技能發(fā)展，并且通常具有多層次的組織結(jié)構(gòu)。運(yùn)維部門通常采用這種組織結(jié)構(gòu)（即服務(wù)器管理員、網(wǎng)絡(luò)管理員和數(shù)據(jù)庫管理員等都被劃分成單獨(dú)的小組）。
   • 矩陣型組織結(jié)構(gòu)試圖結(jié)合職能型和市場型。然而，正如許多管理矩陣型組織或身處其中的人所看到的那樣，這種組織結(jié)構(gòu)通常都非常復(fù)雜。例如，一名員工可能需要向兩個(gè)甚至更多的經(jīng)理匯報(bào)。有時(shí)，矩陣型組織既實(shí)現(xiàn)不了職能型結(jié)構(gòu)的目標(biāo)，也實(shí)現(xiàn)不了市場型結(jié)構(gòu)的目標(biāo)。
   • 市場型組織結(jié)構(gòu)注重快速響應(yīng)客戶需求。這種組織往往有著扁平化的結(jié)構(gòu)，由多個(gè)跨職能的部門組成（例如市場營銷部門和工程技術(shù)部門等），整個(gè)組織可能往往存在冗余現(xiàn)象。很多實(shí)施DevOps的杰出組織采用了這種結(jié)構(gòu)。舉兩個(gè)極端的例子。在亞馬遜和 Netflix，每個(gè)服務(wù)團(tuán)隊(duì)不僅要負(fù)責(zé)特性的交付，而且還要負(fù)責(zé)服務(wù)支持。
3. 執(zhí)行工作的人通常都不太理解自己的工作與價(jià)值流目標(biāo)有什么關(guān)系（“我之所以要配置這臺(tái)服務(wù)器，是因?yàn)閯e人要我這么做”）。這樣就無法讓員工發(fā)揮創(chuàng)造性和主動(dòng)性。P52
4. 如果運(yùn)維部門的每個(gè)職能團(tuán)隊(duì)都要同時(shí)服務(wù)于多個(gè)價(jià)值流（即多個(gè)開發(fā)團(tuán)隊(duì)），那么問題更是雪上加霜，因?yàn)樗袌F(tuán)隊(duì)的時(shí)間都很寶貴。為了使開發(fā)團(tuán)隊(duì)及時(shí)完成工作，運(yùn)維部門常常不得不將問題反映到管理層，從經(jīng)理、總監(jiān)一直到?jīng)Q策者（通常是總經(jīng)理），再由決策者按照組織的全局目標(biāo)（而不是局部目標(biāo)）為工作安排優(yōu)先級(jí)。然后，決策再逐級(jí)下達(dá)至各個(gè)職能部門，最后調(diào)整局部的優(yōu)先級(jí)，而這又會(huì)降低其他團(tuán)隊(duì)的速度。每個(gè)團(tuán)隊(duì)都在加速工作，而最終的結(jié)果卻是所有項(xiàng)目都以同樣緩慢的速度向前推進(jìn)。P52
5. 以市場為導(dǎo)向的團(tuán)隊(duì)不但要負(fù)責(zé)特性開發(fā)，而且在整個(gè)應(yīng)用生命周期中還要負(fù)責(zé)測試、安全、部署和生產(chǎn)環(huán)境的運(yùn)維。這些跨職能團(tuán)隊(duì)可以獨(dú)立運(yùn)作——能夠設(shè)計(jì)和開展用戶實(shí)驗(yàn)，構(gòu)建和交付新特性，在生產(chǎn)環(huán)境中部署并運(yùn)行服務(wù)，不依賴于其他團(tuán)隊(duì)就能修復(fù)任何缺陷，從而加快行動(dòng)的步伐。亞馬遜和 Netflix 正是采用了這種模式，這也是亞馬遜快速發(fā)展的一個(gè)主要原因。P53
6. 只要服務(wù)團(tuán)隊(duì)能夠快速（最好是按需）從運(yùn)維團(tuán)隊(duì)獲得可靠的幫助，那么集中式的職能型運(yùn)維組織也可以實(shí)現(xiàn)高效運(yùn)轉(zhuǎn)，反之亦然。包括谷歌、Etsy和GitHub在內(nèi)的許多著名DevOps公司都保留了職能型運(yùn)維團(tuán)隊(duì)。P53
7. 在談到開發(fā)和運(yùn)維的共同目標(biāo)時(shí)，Ticketmaster的首席技術(shù)官Jody Mulkey說：“在過去近 25 年的時(shí)間里，我一直用美式橄欖球比賽來比喻Dev和Ops。其中，Ops是防守組，試圖阻止對方得分；Dev則是進(jìn)攻組，其目標(biāo)是盡全力得分。而有一天，我突然意識(shí)到這個(gè)比喻并不恰當(dāng)，因?yàn)镈ev和Ops從來沒有在同一時(shí)間出現(xiàn)在球場上，他們實(shí)際上不屬于同一個(gè)團(tuán)隊(duì)!”。他繼續(xù)說道：“我現(xiàn)在用的比喻是，Ops是進(jìn)攻內(nèi)鋒，Dev則負(fù)責(zé)重要位置（如四分衛(wèi)或外接手）。Dev的工作是持球沖鋒，Ops的工作則是保證Dev有足夠的時(shí)間向前沖。”P55
8. “兩個(gè)比薩原則”保持團(tuán)隊(duì)規(guī)模小型化——兩個(gè)比薩夠團(tuán)隊(duì)的所有成員吃，這樣的團(tuán)隊(duì)通常有5~10人，這種規(guī)模限制有以下 4 個(gè)重要作用。P57
   • 它確保團(tuán)隊(duì)成員對系統(tǒng)有清晰、相同的理解。當(dāng)團(tuán)隊(duì)規(guī)模變大時(shí)，如果要讓所有人都了
     解系統(tǒng)狀況，需要溝通的信息量就會(huì)成倍增加。
   • 它限制正在開發(fā)的產(chǎn)品或服務(wù)的增長率。通過限制團(tuán)隊(duì)的規(guī)模，系統(tǒng)的發(fā)展速度也受到限制，這也有助于保證團(tuán)隊(duì)成員對系統(tǒng)有相同的理解。
   • 它分散權(quán)力并實(shí)現(xiàn)自主。每個(gè)“雙比薩”團(tuán)隊(duì)都盡可能地自主工作。團(tuán)隊(duì)負(fù)責(zé)人直接向管理層匯報(bào)，由他決定團(tuán)隊(duì)負(fù)責(zé)的關(guān)鍵業(yè)務(wù)指標(biāo)(又稱適應(yīng)度函數(shù))，并將其作為團(tuán)隊(duì)實(shí)踐的總體評(píng)估標(biāo)準(zhǔn)。然后，團(tuán)隊(duì)能夠自主采取行動(dòng)來最大限度地提升該指標(biāo)。
   • 領(lǐng)導(dǎo)“雙比薩”團(tuán)隊(duì)是讓員工獲得領(lǐng)導(dǎo)經(jīng)驗(yàn)的一種方式。在這樣的環(huán)境中，即使失敗了也不會(huì)有災(zāi)難性后果。亞馬遜的策略有一個(gè)關(guān)鍵要素，即“雙比薩”團(tuán)隊(duì)的組織結(jié)構(gòu)與面向服務(wù)架構(gòu)之間的聯(lián)系。

第8章 將運(yùn)維融入日常開發(fā)工作

1. 大魚游戲公司的 DevOps 轉(zhuǎn)型，展示了集中式運(yùn)維團(tuán)隊(duì)如何取得以市場為導(dǎo)向的成果。以下是3個(gè)通用的策略：P62
   • 構(gòu)建自服務(wù)能力，幫助開發(fā)人員提高生產(chǎn)力;
   • 將運(yùn)維工程師融入服務(wù)團(tuán)隊(duì);
   • 如果運(yùn)維工程師人數(shù)緊張，則可以采用運(yùn)維聯(lián)絡(luò)人模式。
2. 運(yùn)維部門若想取得以市場為導(dǎo)向的成果，一種做法是創(chuàng)建一套集中式的平臺(tái)和工具集服務(wù)，讓所有開發(fā)團(tuán)隊(duì)都能夠通過使用這套平臺(tái)和服務(wù)來提高生產(chǎn)力，例如搭建類生產(chǎn)環(huán)境、部署流水線、自動(dòng)化測試工具、生產(chǎn)環(huán)境遙測控制臺(tái)等。P62
3. 運(yùn)維提供的所有平臺(tái)和服務(wù)應(yīng)該是全自動(dòng)化的，并且能按需提供，不需要開發(fā)人員提交工單，然后再等待運(yùn)維團(tuán)隊(duì)手動(dòng)處理，這能保證運(yùn)維不成為客戶的瓶頸。P62
4. “以支持工程團(tuán)隊(duì)的創(chuàng)新和速度為先。我們不為這些團(tuán)隊(duì)構(gòu)建、打包或部署任何產(chǎn)品，也不為他們管理配置。相反，我們構(gòu)建自助工具。他們可以依賴我們的工具，但不能依賴我們的勞動(dòng)力?！盤63
5. 由于各種原因（如成本或者資源不足），可能無法給每個(gè)產(chǎn)品團(tuán)隊(duì)都分派運(yùn)維工程師，但可以給每個(gè)產(chǎn)品團(tuán)隊(duì)指定一位運(yùn)維聯(lián)絡(luò)人。運(yùn)維聯(lián)絡(luò)人也要參加團(tuán)隊(duì)的站會(huì)，把團(tuán)隊(duì)的需求納入整體的運(yùn)維計(jì)劃，并且在必要的時(shí)候執(zhí)行相關(guān)任務(wù)。在發(fā)生資源競爭或優(yōu)先級(jí)沖突時(shí)，團(tuán)隊(duì)依賴運(yùn)維聯(lián)絡(luò)人推進(jìn)問題的解決。派遣的運(yùn)維工程師的責(zé)任是理解下列內(nèi)容：P64
   • 新產(chǎn)品的功能是什么，為什么要開發(fā)這個(gè)產(chǎn)品；
   • 它是怎樣工作的，可運(yùn)維性如何，可擴(kuò)展性和監(jiān)控能力如何；
   • 怎樣監(jiān)控和收集指標(biāo)，如何確認(rèn)應(yīng)用的功能正常；
   • 架構(gòu)和模式是否與以往的做法不同，這樣做的理由是什么；
   • 是否對基礎(chǔ)設(shè)施有額外的需求，它的使用對基礎(chǔ)設(shè)施容量的影響如何；
   • 特性的發(fā)布計(jì)劃。
6. 每日站會(huì)的目的是在整個(gè)團(tuán)隊(duì)范圍內(nèi)分享信息，同時(shí)了解所有正在做和將要完成的工作。通過讓團(tuán)隊(duì)成員相互分享信息，可以發(fā)現(xiàn)面臨難題的任務(wù)，然后用互助的方式找到解決方法，從而從整體上推進(jìn)工作。P65
7. 看板圖是工作可視化管理的理想工具?？梢暬菍⑦\(yùn)維工作融入產(chǎn)品價(jià)值流的關(guān)鍵。如果在這方面做得好，不管組織結(jié)構(gòu)如何調(diào)整，我們都能取得以市場為導(dǎo)向的成果。P67

第三部分 第一步：流動(dòng)的技術(shù)實(shí)踐

1. 將QA人員和運(yùn)維人員的任務(wù)集成到團(tuán)隊(duì)的日常工作中，能夠減少救火、困境以及瑣事的發(fā)生，讓團(tuán)隊(duì)成員的工作高效且充滿樂趣。這不僅能提升團(tuán)隊(duì)的工作質(zhì)量，也能增強(qiáng)組織的競爭力。P69

第9章 為部署流水線奠定基礎(chǔ)

1. 為了使工作快速可靠地從開發(fā)流向運(yùn)維，應(yīng)當(dāng)保證價(jià)值流的每個(gè)階段都使用類生產(chǎn)環(huán)境。此外，這些環(huán)境必須能用自動(dòng)化的方式進(jìn)行搭建。在理想情況下，應(yīng)該使用腳本和存儲(chǔ)在版本控制系統(tǒng)中的配置信息按需搭建，而不需要依賴運(yùn)維團(tuán)隊(duì)進(jìn)行手動(dòng)操作。部署流水線的目標(biāo)就是能夠基于版本控制系統(tǒng)中的信息重復(fù)搭建整套生產(chǎn)環(huán)境。P70
2. 在過程中保證質(zhì)量，而不是事后檢查質(zhì)量。P70
3. 導(dǎo)致軟件發(fā)布變得混亂或具有破壞性甚至災(zāi)難性結(jié)果的一個(gè)主要原因，是在發(fā)布過程中才首次看到應(yīng)用如何在類生產(chǎn)環(huán)境中處理真實(shí)的數(shù)據(jù)。P71
4. 可以使用自動(dòng)化的方式完成以下操作：P72
   • 復(fù)制虛擬化環(huán)境(如 VMware 虛擬機(jī)鏡像、執(zhí)行 Vagrant 腳本，以及啟動(dòng) Amazon EC2 虛 擬機(jī)鏡像文件)；
   • 構(gòu)建“裸金屬物理機(jī)”的自動(dòng)化環(huán)境搭建流程(例如，使用 PXE 方式通過基線鏡像進(jìn)行 安裝)；
   • 使用“基礎(chǔ)設(shè)施即代碼”的配置管理工具(例如 Puppet、Chef、Ansible、SaltStack、CFEngine 等)；
   • 使用操作系統(tǒng)自動(dòng)化配置工具(例如 Solaris Jumpstart、Red Hat Kickstart 和 Debian preseed)；
   • 使用一組虛擬鏡像或容器(例如 Vagrant 和 Docker)搭建環(huán)境；
   • 在公有云(例如 Amazon Web Services、Google App Engine 和 Microsoft Azure)、私有云或其他 PaaS(平臺(tái)即服務(wù)，如 OpenShift 和 Cloud Foundry 等)中創(chuàng)建新環(huán)境。
5. 版本控制系統(tǒng)記錄了對系統(tǒng)中的文件或文件集合所做的變更?？梢赃M(jìn)行提交、對比、合并以及從倉庫中還原出以前修訂版本的對象。版本控制系統(tǒng)還能通過把生產(chǎn)環(huán)境中的對象回滾到之前版本來降低風(fēng)險(xiǎn)。將所有的源文件和配置文件都納入版本控制系統(tǒng)后，它就變成了唯一精確體現(xiàn)系統(tǒng)預(yù)期狀態(tài)的代碼倉庫。P73
6. 為了確保即使在發(fā)生災(zāi)難性事故時(shí)，也可以重復(fù)且精確地（最好還能快速地）恢復(fù)生產(chǎn)環(huán)境， 必須把下列資源也納入版本控制系統(tǒng)：P73
   • 應(yīng)用的所有代碼和依賴項(xiàng)(例如庫、靜態(tài)內(nèi)容等)；
   • 任何用于創(chuàng)建數(shù)據(jù)庫模式的腳本、應(yīng)用的參考數(shù)據(jù)等；
   • 所有用于搭建環(huán)境的工具和工件；
   • 任何構(gòu)建容器所使用的文件；
   • 所有支持自動(dòng)化測試和手動(dòng)測試的腳本；
   • 任何支持代碼打包、部署、數(shù)據(jù)庫遷移和環(huán)境置備的腳本；
   • 所有項(xiàng)目工件(例如需求文檔、部署過程、發(fā)布說明等)；
   • 所有云平臺(tái)配置文件；
   • 創(chuàng)建支持多種基礎(chǔ)設(shè)施服務(wù)（例如企業(yè)服務(wù)總線、數(shù)據(jù)庫管理系統(tǒng)、DNS區(qū)域文件、防火墻配置規(guī)則和其他網(wǎng)絡(luò)設(shè)備）所需的任何其他腳本或配置信息。

第10章 實(shí)現(xiàn)快速可靠的自動(dòng)化測試

1. 如果沒有自動(dòng)化測試，那么我們編寫的代碼越多，測試代碼所花費(fèi)的時(shí)間和金錢也會(huì)越多。在大多數(shù)情況下，這種商業(yè)模式對于任何技術(shù)組織而言都是無法擴(kuò)展的。P77
2. 團(tuán)隊(duì)不接受任何沒有通過自動(dòng)化測試的變更。他們搭建了持續(xù)集成流水線，同時(shí)設(shè)置了測試覆蓋率監(jiān)控指標(biāo)，確保逐漸提高測試覆蓋率，并編寫了測試規(guī)范和指南，堅(jiān)持讓團(tuán)隊(duì)內(nèi)部和外部的相關(guān)人員都照章執(zhí)行。P78
3. 正確的持續(xù)集成實(shí)踐總是可以確保代碼處于可部署和可交付的狀態(tài)。P79
   • 在任何時(shí)候，構(gòu)建和測試流程都能夠運(yùn)行，無論工程師的個(gè)人工作習(xí)慣如何。
   • 獨(dú)立的構(gòu)建和測試流程確保工程師能理解構(gòu)建、打包、運(yùn)行和測試代碼所需的全部依賴
     項(xiàng)（即消除“應(yīng)用在開發(fā)人員的筆記本電腦上能運(yùn)行，但是在生產(chǎn)環(huán)境中不行”的問題）。
   • 將應(yīng)用的可執(zhí)行文件和配置打包，并可以在環(huán)境中重復(fù)安裝。
   • 將應(yīng)用打包到可部署的容器中，而不是把程序代碼打包。
   • 以一致、可重復(fù)的方式進(jìn)行類生產(chǎn)環(huán)境的配置。
4. 有了部署流水線基礎(chǔ)設(shè)施之后，還必須有持續(xù)集成實(shí)踐，這需要以下3個(gè)方面的配合：P81
   • 全面且可靠的自動(dòng)化測試套件，用于驗(yàn)證可部署狀態(tài)；
   • 一種在驗(yàn)證測試失敗時(shí)，可以“停掉整條生產(chǎn)線”的文化；
   • 開發(fā)人員在主干上工作，并小批量提交變更，而不是在生命周期很長的特性分支上工作。
5. 自動(dòng)化測試從快到慢分為如下幾類。P82
   • 單元測試:通常獨(dú)立測試每個(gè)方法、類或函數(shù)。
   • 驗(yàn)收測試:通常整體測試應(yīng)用，確保各個(gè)功能模塊按照設(shè)計(jì)正常工作。
   • 集成測試:保證應(yīng)用能與生產(chǎn)環(huán)境中的其他應(yīng)用和服務(wù)正確地交互，而不再調(diào)用打樁的接口。
6. 可以得出一個(gè)推論:最快速的測試應(yīng)該盡可能多地發(fā)現(xiàn)錯(cuò)誤。P83
7. 搭建性能測試環(huán)境很可能比為應(yīng)用準(zhǔn)備生產(chǎn)環(huán)境還要復(fù)雜。因此，可能需要在項(xiàng)目啟動(dòng)時(shí)就搭建性能測試環(huán)境，并確保能夠?yàn)楸M早、正確地搭建準(zhǔn)備好所需資源。P86
8. 我們認(rèn)為團(tuán)隊(duì)目標(biāo)高于個(gè)人目標(biāo)——在幫助他人推進(jìn)工作的同時(shí)，也幫助了整個(gè)團(tuán)隊(duì)。這包括幫助他人解決構(gòu)建或自動(dòng)化測試的問題，甚至進(jìn)行代碼審查。P88

第11章 應(yīng)用和實(shí)踐持續(xù)集成

1. 開發(fā)人員在自己的分支上獨(dú)自工作的時(shí)間越長，就越難將變更并入主干。事實(shí)上，當(dāng)分支個(gè)數(shù)和每個(gè)分支上的變更數(shù)同時(shí)增加時(shí)，合并難度會(huì)驟增。P90
2. 盡管分支策略有很多種，但是可以分為以下兩類。P92
   • 提高個(gè)人生產(chǎn)力：所有人都在自己的分支上工作。每個(gè)人都獨(dú)立地工作，并且不能干擾其他人；然而，代碼合并將是一場噩夢。協(xié)作將變得相當(dāng)困難，每個(gè)人都不得不謹(jǐn)小慎微地合并代碼，即便是完成系統(tǒng)里最小的部分也是如此。
   • 提高團(tuán)隊(duì)生產(chǎn)力：所有人都在同一個(gè)區(qū)域里工作。并沒有分支，只有一條很長、不可被中斷的主干;也沒有規(guī)則，因此代碼的提交過程很簡單。但是，任何一次提交都有可能破壞整個(gè)項(xiàng)目，同時(shí)導(dǎo)致項(xiàng)目中斷。
3. 大批量合并的另外一個(gè)副作用是，合并難度越大，開發(fā)人員就越不可能（也越不愿意）改進(jìn)和重構(gòu)代碼，因?yàn)橹貥?gòu)很可能導(dǎo)致其他所有人返工。在這種情況下，人們就更不愿意去修改那些在整個(gè)代碼庫中都有依賴項(xiàng)的代碼。不幸的是，這樣的代碼往往價(jià)值最高。P93

第12章 自動(dòng)化和低風(fēng)險(xiǎn)發(fā)布

1. 當(dāng)完整記錄目前的部署流程以后，下一步的目標(biāo)便是盡可能地簡化和自動(dòng)化手動(dòng)步驟，舉例 如下：P98
   • 將代碼打包成便于部署的格式；
   • 創(chuàng)建預(yù)配置的虛擬機(jī)鏡像或容器；
   • 將中間件的部署和配置自動(dòng)化；
   • 將安裝包或者文件復(fù)制到生產(chǎn)服務(wù)器；
   • 重啟服務(wù)器、應(yīng)用或者服務(wù)；
   • 基于模板生成配置文件；
   • 通過執(zhí)行自動(dòng)化冒煙測試，確保系統(tǒng)能正常運(yùn)行，并且配置正確；
   • 運(yùn)行各種測試程序；
   • 將數(shù)據(jù)庫遷移工作腳本化和自動(dòng)化。
2. 為了更好地促進(jìn)工作，需要一個(gè)可以由開發(fā)人員或運(yùn)維人員來執(zhí)行的代碼發(fā)布流程，并且在理想情況下，應(yīng)該不需要任何手動(dòng)操作或工作交接。這個(gè)流程的步驟如下。P101
   • 構(gòu)建:部署流水線必須基于版本控制系統(tǒng)構(gòu)建可部署到任何環(huán)境(包括生產(chǎn)環(huán)境)的軟件包。
   • 測試:任何人都應(yīng)該能夠在他們的工作站上或測試系統(tǒng)中運(yùn)行任何一個(gè)自動(dòng)化測試套件。
   • 部署:任何人都應(yīng)該能夠?qū)⑦@些軟件包部署到具有訪問權(quán)限的任何環(huán)境，通過執(zhí)行（已提交到版本控制系統(tǒng)中的）腳本來完成部署。
3. 金絲雀發(fā)布，F(xiàn)acebook為了采用這種發(fā)布模式而創(chuàng)建的運(yùn)行環(huán)境組。P108
   • A1組：僅向內(nèi)部員工提供服務(wù)的生產(chǎn)環(huán)境服務(wù)器。
   • A2組：僅向一小部分客戶提供服務(wù)的生產(chǎn)環(huán)境服務(wù)器，在軟件達(dá)到某些驗(yàn)收標(biāo)準(zhǔn)后部署（自動(dòng)化部署或手動(dòng)部署均可）。
   • A3組：其余的生產(chǎn)環(huán)境服務(wù)器，軟件在 A2 組中達(dá)到某些驗(yàn)收標(biāo)準(zhǔn)后再部署。
4. 集群免疫系統(tǒng)擴(kuò)展了金絲雀發(fā)布模式，將生產(chǎn)環(huán)境的監(jiān)控系統(tǒng)和發(fā)布流程聯(lián)系起來，并在面向用戶的生產(chǎn)系統(tǒng)的性能超出預(yù)定范圍時(shí)（如新用戶的轉(zhuǎn)化率低于15%~20%），自動(dòng)回滾代碼。P108
5. 黑啟動(dòng)技術(shù)成為可能——先把所有特性都部署到生產(chǎn)環(huán)境中，然后對客戶不可見的特性執(zhí)行測試。對于大規(guī)模或高風(fēng)險(xiǎn)的變更來說，黑啟動(dòng)過程往往持續(xù)數(shù)周，從而保證在正式發(fā)布之前使用類生產(chǎn)負(fù)載安全地進(jìn)行測試。P110

第13章 降低發(fā)布風(fēng)險(xiǎn)的架構(gòu)

1. 緊耦合架構(gòu)不僅會(huì)降低生產(chǎn)力，還會(huì)影響安全變更的能力。接口定義清晰的松耦合架構(gòu)則與20之相反，它優(yōu)化了模塊間的依賴關(guān)系，提高了生產(chǎn)力和安全性，讓小型且高產(chǎn)的“雙比薩”團(tuán)隊(duì)可以執(zhí)行小的變更，并能安全和獨(dú)立地進(jìn)行部署。因?yàn)槊總€(gè)服務(wù)都有一個(gè)定義明確的API，所以更容易測試，團(tuán)隊(duì)之間的服務(wù)等級(jí)協(xié)議條款也更容易確定。P115

第四部分 第二步：反饋的技術(shù)實(shí)踐

1. 通過放大日常工作中的反饋信號(hào)，可以在問題發(fā)生的時(shí)候，立刻識(shí)別并解決它們，同時(shí)將工作系統(tǒng)打造得更加安全，讓我們有信心在生產(chǎn)環(huán)境中實(shí)施變更的同時(shí)開展產(chǎn)品實(shí)驗(yàn)，確信能夠快速探測和修復(fù)故障。為了達(dá)到以上效果，需要探索和落實(shí)如下工作：P123
   • 建立能定位和解決故障的遙測系統(tǒng)；
   • 使用監(jiān)控更好地預(yù)測故障，感知業(yè)務(wù)目標(biāo)的達(dá)成情況；
   • 將用戶研究和反饋融入到研發(fā)團(tuán)隊(duì)的工作中；
   • 為開發(fā)和運(yùn)維提供反饋，讓他們能安全地部署應(yīng)用；
   • 用同行評(píng)審和結(jié)對編程的反饋方式，提高工作質(zhì)量。

第14章 建立能發(fā)現(xiàn)并解決問題的遙測系統(tǒng)

1. 遙測被廣泛定義為“一個(gè)自動(dòng)化的通信過程，先在遠(yuǎn)程采集點(diǎn)上收集度量數(shù)據(jù)，然后傳輸給與之對應(yīng)的接收端用于監(jiān)控”。P125

第15章 分析遙測數(shù)據(jù)以更好地預(yù)測故障和實(shí)現(xiàn)目標(biāo)

第16章 應(yīng)用反饋實(shí)現(xiàn)安全部署

1. 通過建立服務(wù)發(fā)布指南，有助于確保用整個(gè)組織的集體智慧，特別是運(yùn)維團(tuán)隊(duì)所累積的經(jīng)驗(yàn)， 去幫助每一個(gè)產(chǎn)品開發(fā)團(tuán)隊(duì)。服務(wù)發(fā)布指南和要求可能包括以下內(nèi)容。P155
   • 缺陷計(jì)數(shù)和嚴(yán)重性:應(yīng)用程序是按設(shè)計(jì)運(yùn)行的嗎?
   • 告警的類型/頻率:在生產(chǎn)環(huán)境中應(yīng)用程序所產(chǎn)生的告警數(shù)量是否太多，無法得到支持?
   • 監(jiān)控覆蓋率:監(jiān)控覆蓋的范圍是否夠大，能夠?yàn)榛謴?fù)故障服務(wù)提供足夠的信息?
   • 系統(tǒng)架構(gòu):服務(wù)松耦合的程度是否足以支持生產(chǎn)環(huán)境中高頻率的變更和部署?
   • 部署過程:在生產(chǎn)環(huán)境中代碼部署的過程是不是可預(yù)測的、確定性的和足夠自動(dòng)化的?
   • 生產(chǎn)環(huán)境的整潔:是否有跡象表明生產(chǎn)習(xí)慣已經(jīng)足夠好，可以讓其他任何人提供生產(chǎn)
     支持?
2. 要求產(chǎn)品團(tuán)隊(duì)在生產(chǎn)環(huán)境中管理自己開發(fā)的服務(wù)，會(huì)促使開發(fā)人員轉(zhuǎn)換到運(yùn)維的工作視角，但這是在LRR和HRR的指導(dǎo)下進(jìn)行的，這不僅使服務(wù)轉(zhuǎn)換變得更容易、更可預(yù)測，而且有助于在上游與下游工作中心之間建立同理心。P158

第17章 將假設(shè)驅(qū)動(dòng)的開發(fā)和A/B測試融入日常工作

1. Jez Humble指出：“驗(yàn)證業(yè)務(wù)模式或產(chǎn)品理念的最低效的方法，是構(gòu)建完整的產(chǎn)品以查看設(shè)想中的需 求是否真實(shí)存在?！盤160

第18章 建立評(píng)審和協(xié)作流程以提升當(dāng)前工作的質(zhì)量

1. 豐田生產(chǎn)系統(tǒng)的核心理念之一是“最了解問題的人通常是離問題最近的人”。讓距離工作越來越遠(yuǎn)的人來做相關(guān)審批的步驟，這實(shí)際上可能會(huì)降低工作成功的概率。P169
2. 保持小批量尺寸的原則也適用于代碼評(píng)審。變更的批量越大，評(píng)審工程師理解這些工作需要花費(fèi)的時(shí)間就越長，他們的負(fù)擔(dān)也越大。正如Randy Shoup所說：“變更的批量與整合這個(gè)變更的潛在風(fēng)險(xiǎn)之間存在著非線性的關(guān)系——從10行代碼的變更到100行代碼的變更，發(fā)生錯(cuò)誤的風(fēng)險(xiǎn)不止高出10倍。“請程序員來審查10行代碼，他會(huì)找到10個(gè)問題。請他審查500行代碼，他會(huì)說看起來都不錯(cuò)?！盤171
3. 代碼評(píng)審的指導(dǎo)原則如下。P171
   • 每個(gè)人在將代碼提交到主干以前，必須要有同行來評(píng)審他們的變更。
   • 每個(gè)人都應(yīng)該持續(xù)關(guān)注其他成員的提交活動(dòng)，以便識(shí)別和審查出潛在的沖突。
   • 定義哪些變更屬于高風(fēng)險(xiǎn)的變更，從而決定是否需要請領(lǐng)域?qū)＜遥ɡ鐢?shù)據(jù)庫變更、安全性敏感的身份驗(yàn)證模塊等）來進(jìn)行審查。
   • 如果提交的變更尺寸太大了，以至于讓人很難理解——換句話說，閱讀了幾遍代碼還無法理解，或者需要提交者進(jìn)行解釋——那么這個(gè)變更就需要分解成多個(gè)較小的變更來提交，使之一目了然。
4. 代碼評(píng)審有如下幾種形式。P171
   • 結(jié)對編程:程序員結(jié)對地在一起工作。
   • “肩并肩”:在一名程序員編寫了一段代碼后，評(píng)審程序員接著就逐行閱讀他的代碼。
   • 電子郵件送審:在代碼被簽入到代碼管理系統(tǒng)中后，系統(tǒng)就立刻自動(dòng)向評(píng)審者們郵寄一份代碼。
   • 工具輔助評(píng)審:編碼者和審閱者都使用專門用于代碼評(píng)審的工具。
5. 在Gerrit代碼評(píng)審流程中觀察到的問題是，開發(fā)人員通常需要等待整整一周的時(shí)間，才能得到他們所需要的評(píng)審結(jié)果。更糟糕的是高級(jí)開發(fā)人員的感受：“即使是一個(gè)簡單的變更，也無法迅速地進(jìn)入代碼庫，這是令人非常沮喪和崩潰的體驗(yàn)，因?yàn)槲覀儫o意中創(chuàng)造了一個(gè)讓人無法忍受的瓶頸。有能力對變更評(píng)論‘+1’的人都是高級(jí)工程師，他們還有許多其他職責(zé)，所以通常對初級(jí)開發(fā)人員所做的修復(fù)或生產(chǎn)力不太關(guān)心。P175

第五部分 第三步：持續(xù)學(xué)習(xí)與實(shí)驗(yàn)的技術(shù)實(shí)踐

第19章 將學(xué)習(xí)融入日常工作

1. Netflix團(tuán)隊(duì)通過運(yùn)行“搗亂猴”（Chaos Monkey）不斷地將故障注入到預(yù)生產(chǎn)和生產(chǎn)環(huán)境中，從而實(shí)現(xiàn)了運(yùn)維上的恢復(fù)性目標(biāo)。P181
2. 如果對待事件和事故的反應(yīng)被認(rèn)為是不公正的，就可能阻礙安全調(diào)查，從而在從事安全關(guān)鍵性工作的人員中引發(fā)恐懼而非正念，使組織更加官僚而不是更加小心謹(jǐn)慎，并且誘發(fā)職業(yè)性保密、逃避和自我保護(hù)。P181
3. 人為錯(cuò)誤并不是問題的原因；恰恰相反，人為錯(cuò)誤是我們提供的工具存在設(shè)計(jì)問題而造成的后果。P181
4. 有兩個(gè)有效的實(shí)踐有助于創(chuàng)造公正的學(xué)習(xí)型文化：一是不指責(zé)的事后分析；二是在生產(chǎn)環(huán)境中引入受控的人為故障，用于創(chuàng)造機(jī)會(huì)針對復(fù)雜系統(tǒng)中不可避免的問題進(jìn)行練習(xí)。P182
5. 在不指責(zé)的事后分析會(huì)議上，我們會(huì)做以下事情：P182
   • 構(gòu)建時(shí)間表，從多個(gè)角度收集關(guān)于故障的所有細(xì)節(jié)，保證不會(huì)懲罰犯錯(cuò)誤的人；
   • 通過讓所有工程師詳細(xì)說明自己如何導(dǎo)致了故障，使他們能夠提高安全性；
   • 允許并鼓勵(lì)那些犯錯(cuò)誤的人成為教育他人以后不會(huì)犯同樣錯(cuò)誤的專家；
   • 營造一個(gè)自由決策的空間，讓人們決定是否采取行動(dòng)，并且把對所做決定的評(píng)判放在
     事后；
   • 制定預(yù)防類似事故的對策，并確保記錄這些對策、目標(biāo)日期和負(fù)責(zé)人，以便進(jìn)行跟蹤。
6. 組織唯一的可持續(xù)競爭優(yōu)勢就是比對手更快的學(xué)習(xí)能力。P189

第20章 將局部經(jīng)驗(yàn)轉(zhuǎn)化為全局改進(jìn)

1. 在聊天室中自動(dòng)化執(zhí)行操作具有許多優(yōu)點(diǎn)（和通過命令行運(yùn)行自動(dòng)化腳本相比）：P190
   • 每個(gè)人都能看到發(fā)生的一切；
   • 新來的工程師也可以看到團(tuán)隊(duì)的日常工作及其執(zhí)行方式；
   • 看到其他人互相幫助時(shí)，人們也會(huì)更傾向于尋求幫助；
   • 建立起組織學(xué)習(xí)，知識(shí)得到快速積累。
2. 將自動(dòng)化運(yùn)維和聊天室集成在一起有助于記錄和分享我們的觀察和問題解決過程，使其成為日常工作中不可分割的一部分。這還加強(qiáng)了透明、協(xié)作的文化，有益于我們所有的工作。P191
3. GitHub創(chuàng)造的協(xié)作環(huán)境能夠?qū)⒃诰植繉W(xué)習(xí)到的知識(shí)轉(zhuǎn)化為整個(gè)組織的經(jīng)驗(yàn)。P191

第21章 預(yù)留組織學(xué)習(xí)和改進(jìn)的時(shí)間

1. 改善閃電戰(zhàn)經(jīng)常采取的形式是，一個(gè)小組聚在一起，專注探究一個(gè)存在問題的流程......改善閃電戰(zhàn)通常持續(xù)幾天，目標(biāo)是優(yōu)化流程，方法則是集中地讓流程之外的人給通常在流程里的人提建議。P198
2. 我們每隔幾個(gè)月就舉行一次黑客馬拉松，每個(gè)人都為自己的新想法設(shè)計(jì)原型。最后，整個(gè)團(tuán)隊(duì)聚在一起，檢閱所有已經(jīng)完成的工作。P200
3. 為了全面提升谷歌內(nèi)部的自動(dòng)化測試實(shí)踐，他們使用了改善閃電戰(zhàn)、內(nèi)部教練，甚至內(nèi)部認(rèn)證計(jì)劃。P203

第六部分 集成信息安全、變更管理和合規(guī)性的技術(shù)實(shí)踐

1. 我們不僅要提高安全性，而且還要?jiǎng)?chuàng)建更易于審計(jì)、能證明控制有效性的流程，以遵從監(jiān)管義務(wù)和合同義務(wù)。相關(guān)的舉措如下：P205
   • 使安全成為每個(gè)人工作的一部分；
   • 將預(yù)防性的控制代碼集成到共享代碼庫中；
   • 將安全性與部署流水線集成；
   • 將安全性與監(jiān)控集成，從而更好地檢測和恢復(fù)；
   • 保護(hù)部署流水線；
   • 將部署活動(dòng)與變更審批流程集成；
   • 減少對職責(zé)分離的依賴；

第22章 將信息安全融入每個(gè)人的日常工作

1. 當(dāng)涉及信息安全和合規(guī)性時(shí)，我們發(fā)現(xiàn)在項(xiàng)目結(jié)束時(shí)解決項(xiàng)目阻塞比開始階段更加昂貴，其中信息安全阻塞的成本最高。在此過程中，‘用演示證明合規(guī)性’成為了我們盡早消除所有復(fù)雜性的一個(gè)慣例。P208

第23章 保護(hù)部署流水線

1. 幾十年來，我們將職責(zé)分離用作減少軟件開發(fā)過程中欺詐或犯錯(cuò)風(fēng)險(xiǎn)的主要控制手段之一。 大多數(shù)軟件開發(fā)生命周期都已經(jīng)接受的做法是:要求將開發(fā)人員變更提交給代碼庫管理員接受審 查和批準(zhǔn)變更，然后由IT運(yùn)維將變更部署到生產(chǎn)環(huán)境。P
   224