1. 控制層囊括所有在後臺運行的成功處理生產負載的軟體和服務

1.1. 處理用戶生產數據的那些軟體，就是生產軟體

1.2. 主要工作是管理其他軟體的軟體，就是控制層

1.3. 工具和問題之間存在著重疊和空白，並不是每個工具組合都能協同工作，不存在能解決所有問題的萬能軟體包

1.4. 在集成工具時要耗費巨大的精力，進行大量的實驗，經歷無數的錯誤

2. 適合的控制層工具

2.1. 當考慮控制層時，請記住其中的每一部分都是可選的

2.1.1. 有了日誌記錄和監控這些控制層選項，就有助於開展事後分析、事故恢復和缺陷發現等工作

2.1.2. 沒有這些選項，上述工作將花費更長的時間，甚至根本沒有辦法完成

2.2. 控制層越先進，其實現和運維的成本就越高

2.3. 控制層中的每個工具都有持續的運維成本

2.3.1. 將持續的運維成本看作權衡固定成本與可變成本

2.3.1.1. 專職運維人員的固定成本

2.3.1.2. 部署加速、事故恢復和服務整備等可變成本

2.4. 2007年

2.4.1. 記錄日誌和監控幾乎是一個商業化的市場

2.5. 如今

2.5.1. 這個市場幾乎是開源的

2.5.2. 最困難的問題變成瞭如何從所有精良的開源軟體中選擇一個自己滿意的工具

2.6. 不要誤以為必須安裝所有工具

2.6.1. 控制層工具的發展日新月異，要持續評估不同解決方案的開銷和難度

3. 機械效益

3.1. 機械效益指人類可以依靠簡單機器增強自身力量

3.1.1. 阿基米德說過：“給我一個支點，我能撬動地球。”

3.2. 既能幫大忙，也能幫倒忙

3.2.1. 強大的杠桿作用使人花很少的力量就能做出巨大的改變

3.3. 運行得太快也有問題

3.3.1. 無論怎樣，一旦關閉的實例數量超過了總伺服器容量的50%，自動化工具就應該停下來，從而使人們能夠確認移除容量確實是正確的行為

4. 平臺和生態系統

4.1. 監控團隊應該能夠幫助相關人員響應應用程式告警

4.2. 監控團隊不會進行監控，而會幫助其他人實現自行監控

4.3. 一種從占有某個領域向為客戶提供服務的思維轉變。

4.4. 監控團隊提供了一個開發團隊可以使用的介面，並負責編寫介面的實現細節，而且在持續支持其介面協議的過程中，可以隨時改變實現細節

4.5. 監控團隊只負責實現相關工具，讓其客戶通過這些工具實現自身的監控器

4.6. 平臺團隊的資料庫管理員主要負責保持資料庫健康運行，資料庫管理員要確保資料庫具有足夠的容量

4.6.1. 資料庫管理員應該關註創建高性能和高穩定的平臺

4.7. 數據模型的設計工作則由應用程式團隊負責

4.7.1. 一個應用程式能很輕易地做出有害的模式變更，從而影響其他資料庫消費者

4.7.2. 使用基於SQL的RDBMS要求我們為每個服務分配一個單獨的物理資料庫

4.8. 平臺團隊的目標是為客戶賦能

5. 開發環境就是生產環境

5.1. 如果你的開發伺服器鏡像是一個帶有已知配置的全新虛擬機，那就太棒了

5.2. 如果QA環境和生產環境能由同一個自動化工具創建，並且QA環境存有經過匿名化處理的一周以來的生產環境用戶數據樣本，那麼你就繼續保持吧

5.3. 開發人員完成工作所需的工具、服務和環境，應該以生產級別的SLA對待

5.4. 開發平臺就是創造軟體這項工作的生產環境

6. 整個系統的明晰性

6.1. 當網路規模較大時，“部分系統故障”也是正常的運維狀態

6.2. 即使是網路規模較小的場景，在一切都沒有運行的情況下，系統也應該能夠繼續“存活”一段時間

6.3. 真實用戶監控

6.3.1. real-user monitoring，也可稱其為RUM

6.3.2. 判斷用戶體驗的最佳方式是直接測量

6.4. New Relic或Datadog等服務

6.5. AppDynamics或CA公司的APM

6.6. 3個優勢

6.6.1. 能快速啟動，無須構建基礎設施或配置監控軟體，很有可能在一小時內就開始收集數據了

6.6.2. 能為各種技術提供代理軟體和連接器，這使所有監控集成到一處更加容易

6.6.3. 儀錶盤和可視化界面往往比開源替代方案設計得更精美

6.6.4. 商業服務，需要支付訂閱費

6.7. 開源工具

6.7.1. 要投入人力和基礎設施等相對隱性的成本

6.8. 經濟價值高於技術價值

6.8.1. 大多數軟體則是為了創造經濟價值而存在

6.8.2. 成本也會源自運維工作量

6.8.2.1. 軟體越難以運維，人們在運維上所花費的時間就越多

6.8.3. 成本源自平臺和運行時系統

6.8.3.1. 有些語言能讓程式員快速編程，但需要更多實例處理特定的工作負載（這樣就增加了成本）

6.8.4. 監控、日誌收集、告警和儀錶盤等手段的經濟價值，其實是高於其技術價值的

6.9. 日誌和統計信息

6.9.1. 日誌收集器能以推或拉的模式進行工作

6.9.2. 推模式意味著實例能在網路上推送日誌，此時通常使用歷史悠久的syslog協議

6.9.3. 推模式對容器非常有用，它們無須額外保存狀態，且通常沒有本地存儲

6.9.4. 使用拉模式，那麼收集器就在中央電腦上運行，且能連接所有已知主機進而遠程複製日誌，服務只將其日誌寫入本地文件

6.9.5. 僅將所有日誌保存在一臺主機上，就已經小有成就了

6.9.6. Splunk在當今日誌索引領域占據主導地位

6.9.7. 由Elasticsearch、Logstash和Kibana組成的“三駕馬車”則是另一組流行的工具

6.9.8. 度量指標

6.9.8.1. 大多數度量指標資料庫會對最近的樣本進行細粒度的度量

6.9.8.2. 隨著樣本變老，它們會將樣本聚合到越來越大的時間跨度

6.9.8.2.1. 今天的網卡錯誤率能以秒為單位查閱

6.9.8.2.2. 如果要查閱過去7天的錯誤率，則最細能以分鐘為單位查閱

6.9.8.2.3. 如果要查閱7天之前的，則最細僅能以小時為單位查閱

6.9.8.2.4. 好處

6.9.8.2.4.1. 節省不少磁碟空間

6.9.8.2.4.2. 讓長時間跨度的查詢成為可能

6.10. 監控點

6.10.1. 流量指示

6.10.1.1. 頁面請求量、頁面請求總數、事務計數、併發會話數

6.10.2. 每種類型的業務交易

6.10.2.1. 已處理的業務交易數量、被終止的業務交易數量、所創造的業務價值（以元為單位）、事務持續時長、業務轉化率、業務完成率

6.10.3. 用戶

6.10.3.1. 用戶群分析或分類、用戶使用技術的偏好、註冊用戶百分比、用戶數量、使用模式、使用中遇到的錯誤數量、登錄成功數量、登錄失敗數量

6.10.4. 資源池健康狀況

6.10.4.1. 是否處於啟用狀態、總資源數量（適用於連接池、worker線程池和其他所有資源池）、檢出資源的數量、高水位線、所創建的資源數量、所銷毀的資源數量、資源檢出的總次數、等待某資源而被阻塞的線程數量、某線程被阻塞等待的次數

6.10.5. 資料庫連接健康狀況

6.10.5.1. 拋出的SQLException數量、查詢數量、查詢的平均響應時間

6.10.6. 數據消費量

6.10.6.1. 用於展示的實體或行的數量、數據在記憶體和磁碟中的占用量

6.10.7. 集成點健康狀況

6.10.7.1. 斷路器狀態、超時次數、請求數量、平均響應時間、良好響應數量、網路錯誤數量、協議錯誤數量、應用程式錯誤數量、遠程端點的實際IP地址、當前併發請求數、併發請求高水位線

6.10.8. 緩存健康狀況

6.10.8.1. 緩存項數量、緩存所占記憶體量、緩存命中率、垃圾收集器刷新的緩存項數量、緩存配置的上限、緩存項創建所用時間

6.10.9. 隱含的時間條件“最近n分鐘”或“自上次複位以後”

6.10.10. 要衡量系統連續的度量指標的標稱範圍，“用某時間段的平均值加上或減去兩個標準差”不失為一個實用的經驗法則

6.10.11. 不存在適用於所有組織的正確度量時間段

6.10.11.1. 對零售商來說，強烈地關註在“每年最忙一周”里所得到的度量指標

6.10.11.2. 如旅游、花卉和體育，與訪問流量最相關的度量往往發生在節假日或重大活動期間