1. 最大限度地避免直接對生產系統進行人為操作最為妥善

1.1. 人為干預生產環境會導致問題

1.1.1. 把“無須擺弄”做到極致，就是“不可變”的基礎設施，因為那裡根本就不存在供人擺弄的途徑

1.1.2. 如果系統需要大量手動操作來保持運行，那麼管理員就必須養成始終記日誌的習慣

1.1.3. 通過限制系統管理員登錄生產環境伺服器的需求，鼓勵更好的運維紀律

1.2. 系統應該能夠在沒有人工干預的情況下，至少運行一個發佈周期

1.2.1. 系統應在無須手動清理磁碟或每晚重新啟動的情況下，至少運行一個發佈周期

1.2.2. 在發佈周期中，那些從版本控制系統中持續部署的微服務，應該非常易於實現穩定部署

2. 存儲桶

2.1. 穩態模式表明，針對每個累積資源的機制，要相應存在另一個機制回收該資源

2.2. 隨著數據的累積，存儲桶會以一定的速率填滿

2.3. 存儲桶必須以相同或更快的速率清空數據，否則最終會溢出

2.4. 當該存儲桶溢出時，壞事會發生

2.4.1. 伺服器停機

2.4.2. 資料庫變慢

2.4.3. 拋出錯誤信息

2.4.4. 響應長

3. 數據清除

3.1. 數據清除總會被忽視

3.2. 計算資源總是有限的，因此不能無限制地持續增加消費

3.3. 數據增長最明顯的癥狀，就是資料庫伺服器上的I/O速率穩步增加

3.4. 在恆定的系統負載下，也能看到延遲時間會增加

3.5. 數據清除的另一半工作，是確保在清除數據之後應用程式仍能正常工作，而這需要進行編程和測試

3.6. DBA可以通過創建腳本清除數據，但他們不知道刪除數據之後，應用程式會如何運轉

3.6.1. 為了保持邏輯完整性（特別是在使用對象關係映射工具時），應用程式需要清除自己的數據

4. 日誌文件

4.1. 不要無限量保留日誌文件

4.1.1. 如果日誌文件無限制地增大，最終會填滿其所在的文件系統

4.2. 文件系統空間耗盡之後的狀況就無從得知了

4.2.1. 最好的情況，就是日誌文件系統與任何關鍵數據存儲（例如事務）是分離的，而且應用程式代碼本身具有足夠的安全防護能力，用戶永遠不會意識到有任何錯誤發生

4.3. 最好一開始就避免一直往文件系統里添加內容

4.3.1. 基於日誌文件的大小來配置日誌文件迴轉

4.4. 日誌對系統的明晰性有極大的幫助，確保所有的日誌文件都能被迴轉使用，並最終被清除

4.5. 生產環境系統的日誌文件信噪比很糟糕

4.5.1. 最好能儘快將日誌文件從單個主機上移走，發送到集中式日誌記錄伺服器（例如Logstash），進而對其進行索引、搜索和監控

4.6. 多年保留日誌

4.6.1. 單個機器不可能把日誌保留這麼長時間，大多數機器的壽命也不會這樣長

4.6.2. 最好的辦法是儘快從生產環境的機器中取出日誌，將它們存儲在中央伺服器上，並對其密切監視，防止篡改

4.6.3. 如果合規性要求保留，則在非生產伺服器上執行

5. 記憶體中的緩存

5.1. 記憶體中的緩存可以加快應用程式的運行速度

5.2. 若不對記憶體中的緩存加以控制，執行速度會降低

5.3. 低記憶體的狀態對穩定性和容量都是威脅

5.3.1. 需要限制緩存可消耗的記憶體量

5.4. 如果緩存鍵數量沒有上限，則必須限制緩存大小，並且採用某種形式的緩存失效機制

5.5. 定時刷新緩存是最簡單的緩存失效機制

5.5.1. 定時刷新緩存能夠處理90%的情況

5.6. “最近最少使用”或工作集演算法