1. 變化就是軟體的特性

1.1. 變化保證天天有，存活保障無處尋

1.2. 非每一款軟體每天都需要進行數據修改

1.3. 某些軟體確實沒有進行快速變化和適應的潛力

1.3.1. 航空電子設備和植入式醫療設備所用的軟體的每一次發佈都要經過昂貴和耗時的認證

1.4. 變化（適應性）從發佈那一刻就開始了

1.4.1. 發佈才是軟體生命的開始，在這之前都是醞釀與準備

1.4.2. 當努力與回報之間存在凸型曲線關係時，良好的適應性就能起作用

1.4.3. DevOps會消除行動階段中更多的延遲，並給觀察階段提供大量新的可視化工具

1.5. 系統要麼隨著時間的推移而成長，適應不斷變化的環境，要麼逐漸衰退，直到成本超出利潤，然後死亡

1.6. 如果組織在改變方向時，沒有花時間收集和處理反饋，那麼就會發生顛簸（thrashing）

1.7. 雖然在軟體內部進行了應對變更的設計，但在生產環境中忽視造成變更的行為

2. 工具

2.1. 計算容量，包括專門用途的高記憶體、高輸入、高輸出和高性能圖形處理器配置

2.2. 工作負載管理、自動擴展、虛擬機的安置和覆蓋網路

2.3. 存儲，包括內容定址存儲和文件系統結構存儲

2.4. 日誌收集、索引和搜索

2.5. 度量指標收集和可視化

2.6. 消息排隊和傳輸

2.7. 流量管理和網路安全

2.8. 動態DNS註冊和解析

2.9. 電子郵件網關

3. 平臺的可用性是衡量平臺團隊的標準

3.1. 必須讓應用程式開發團隊，而不是平臺團隊，負責應用程式的可用性

4. 發佈

4.1. 以前的實踐表明，每次發佈通常都是成本高昂且風險巨大的

4.2. 簡單但有害的解決方案是放慢發佈頻率

4.3. 正確的方式是減少每次發佈所需的工作量，刪除發佈過程中需要人為參與的環節，並使整個過程更加自動化和標準化

5. 演化最重要的部分是滅絕，關閉服務，刪除代碼並重新分配團隊成員

6. 謹防高效率

6.1. 讓人們一直忙個不停，而公司的整體步伐卻慢得像蝸牛

6.2. 高效率的價值流具有短交貨期和高吞吐量

6.3. 當使價值流變得更有效率時，你也在將它變得更專業於今天的任務，而這可能在適應未來的任務時，難以進行改變

7. 大泥球法則

7.1. big ball of mud

7.2. 如果不去密切關註，依賴性就會激增，以此產生的耦合性就會將彼此不同的系統，都拉進一個脆弱的整體中

8. 系統架構

8.1. 新推出的系統必須要做一些正確的事情，否則就不會被推出

8.2. 演進式架構

8.2.1. 支持跨維度進行引導式增量變更

8.2.2. 水平耦合更可能成為演進的障礙

8.3. 適合演進式架構的

8.3.1. 微服務

8.3.1.1. 優點

8.3.1.1.1. 非常小的一次性代碼單元

8.3.1.1.2. 強調容量的可伸縮性和團隊規模的自治性

8.3.1.2. 缺點：在監控、跟蹤和持續交付過程中容易與平臺耦合

8.3.2. 微內核和插件

8.3.2.1. 優點

8.3.2.1.1. 進程內及記憶體中的消息傳遞內核，帶有正式的擴展介面

8.3.2.1.2. 適合需求的增量變更，便於合併不同團隊的工作

8.3.2.2. 缺點：易受編程語言和運行時環境的影響

8.3.3. 基於事件

8.3.3.1. 優點

8.3.3.1.1. 偏好非同步消息通信，避免直接調用

8.3.3.1.2. 適用於時間解耦

8.3.3.1.3. 無須更改發佈者，就能新增訂閱者

8.3.3.1.4. 允許從歷史中進行邏輯變更和重建

8.3.3.2. 缺點：隨著時間的推移，易受消息格式的語義變化的影響

8.4. 鬆散的集群

8.4.1. 系統應該是鬆散的集群

8.4.1.1. 在一個鬆散的集群中，丟掉一個實例就如同森林中倒下一棵樹，不會引起轟動效應

8.4.2. 單台伺服器不再扮演差異化的角色

8.4.3. 任何差異化的角色都存在於多個實例中

8.4.4. 一個服務不會有任何獨一無二的實例

8.4.5. 如果一個實例確實需要扮演獨特的角色，那麼它應該使用某種形式的領導者選舉機制

8.4.6. 整個服務可以在失去領導者的情況下存活下來，無須人工干預來重新配置集群

8.5. 全局狀態是隱式上下文中最隱秘的形式

8.5.1. 當需要從“一”切換到“多於一”的協作時，全局狀態會拖慢進程

8.6. 模塊化系統

8.6.1. 模塊化系統天然就比單體系統擁有更多的選擇

8.6.2. 拆分

8.6.2.1. 拆分將設計分解成模塊，或將模塊分解為子模塊

8.6.3. 替代

8.6.3.1. 如果給定模塊化設計，那麼“替代”就是用另一個模塊來替換某個模塊

8.6.3.2. 原模塊和替代模塊需要共用一個通用介面

8.6.3.2.1. 它們具有相同的介面，而且父模塊所需的介面部分也必須相同

8.6.4. 增添和排除

8.6.4.1. 增添是指為系統添加模塊

8.6.4.2. 排除是指從系統中刪除模塊

8.6.5. 反轉

8.6.5.1. 將分佈在多個模塊中的功能上移至系統更高的層級

8.6.5.2. 為變化創造了一個新的維度，並且可以從中顯露出商業機會

8.6.6. 移植

8.6.6.1. 移植視為硬體或操作系統模塊從一個CPU到另一個CPU的轉移

8.6.6.2. 移植加大了耦合的風險

8.6.6.2.1. 增加了一種新的依賴

8.6.6.3. 實例化是將模塊移植到系統中的另一種方式

9. 信息架構

9.1. 信息架構是構造數據的方式

9.2. 每種資料庫都嵌入了一種對世界進行建模的方式

9.3. 我們不能捕獲現實，只能對現實的某些方面進行建模

9.4. 消息、事件和命令

9.4.1. 利用消息肯定會帶來複雜性

9.4.2. 事件通知：一個即發即忘的單向通告，並不期望獲得響應或被使用

9.4.3. 事件承載狀態轉移：在事件中對實體的全部或部分進行複製，方便其他系統完成工作

9.4.4. 事件溯源：將所有變更記錄為描述變更的事件

9.4.5. 命令與查詢職責分離：使用不同的結構進行讀取操作和寫入操作

9.4.5.1. 不是事件，但事件通常會出現在其中的命令一側

9.5. URL

9.5.1. URL是對值的表示的引用，可以通過解析URL來獲取對應的表示，就像解引用指針一樣

9.5.2. URL能夠帶來獲取底層表示所需要的上下文

9.5.3. 需要對發送給用戶的URL進行加密，這樣就能驗證所收到的內容是否對應之前所生成的請求