2.7               對吞吐量和延遲進行分析。

應當對核心服務的使用者互動進行吞吐量和延遲的分析，從而瞭解它們的影響。結合其他運營操作，比如定期資料庫維護、運營配置（加入新使用者，使用者遷移）和服務除錯等，進行吞吐量和延遲的分析。這樣做對於捕捉由週期性管理任務所帶動的問題是頗有裨益的。對於每個服務，都應當形成一個度量標準，用於效能規劃，比如每個系統的每秒使用者訪問數，每個系統的併發線上人數，或者某些將關聯工作負載對映到資源需求的相關度量標準。

2.8               把運營的實用工具作為服務的一部分對待。

把運營的實用工具作為服務的一部分對待。由開發、測試、專案管理和運營所產生的運營實用工具應當交給開發團隊進行程式碼審查，提交到主原始碼樹上，用同一套進度表跟蹤，進行同樣的測試。最頻繁出現的現象是，這樣的實用工具對於任務有至關重要的影響，但幾乎都沒有經過測試。

2.9              

理解訪問模式。在規劃新特性時，一定要記得考慮它們會給後端儲存帶來哪些負載。通常，服務模型和服務開發人員與儲存抽象得非常開，以至於他們全然忘記了它們會給後端資料庫帶來的額外負載。對此的最佳實踐把它作為規範建立起來，裡面可以有這樣的內容：“這項功能會給基礎結構的其他部分帶來什麼樣的影響？”然後在這項特性上線之後，對它進行負載的測量和驗證。

2.10           讓所有工作版本化。

做好在混合版本的環境中執行的準備。我們的目標是執行單版本的軟體，但是多個版本可能會在首次展示和生產環境測試的過程中並存。所有元件的n 版和n+1版都應當能夠和平共存。

2.10.1         保持最新發布版的單元/功能測試。

這些測試是驗證n － 1 版本的功能是否被破壞的重要方法。我們推薦大家更進一步，定期在生產環境中執行服務驗證（後面會詳細介紹）。

2.10.2         避免單點故障。

單點故障的產生會導致整個服務或者服務的某些部分停工。請選擇無狀態的實現。不要將請求或者客戶端繫結在特定的伺服器上，相反，將它們負載均衡在一組有能力處理這樣負載的伺服器上。靜態雜湊或者任何靜態的伺服器負載分配都會時不時遭受資料和/ 或查詢傾斜問題的困擾。在一組機器可以互換時，要做到橫向伸展是非常容易的。資料庫通常會發生單點故障，而資料庫伸縮仍然是網際網路級大規模服務的設計中最為困難的事情之一。良好的設計一般會使用細粒度的分割槽，且不支援跨分割槽操作，以在多臺資料庫伺服器之間進行高效伸展。所有的資料庫狀態都會進行冗餘儲存（至少在一臺）完全冗餘的熱待機伺服器上，並且在生產環境中會頻繁進行故障轉移測試。