架構 Microsoft Azure Well-Architected Framework Azure 應用程式架構指南 參考結構與範例工作負載 適用於 Azure 的 Microsoft 雲端採用架構 在 Azure 上建置微服務 Azure 資料架構指南 雲端最佳做法 設計可靠的 Azure 應用程式 雲端設計模式 適用於 AWS 專業人員的 Azure 適用於 GCP 專業人員的 Azure 效能微調 在 Azure 架構中心查看更多資訊
監視 Azure 監視器概觀 使用 Azure 監視器進行計量 使用 Azure 監視器進行記錄 Application Performance Management 與 Application Insights 使用 Azure 監視器進行分散式追蹤 深入了解 Azure 監視器
文化特性 網站可靠性工程的演進 建置 SRE：Outside-In 的文化特性 多元文化小組的文化差異和有效合作 SRE 的演進和對 SRE Catalyzer 需求不斷增加 意見反應迴圈：SRE 有哪些好處以及還需要哪些步驟來發揮其潛力 了解業務計量可讓您的 SRE 更加完善 網站可靠性是永無止境的目標 每天都必須認真執行作業
監視和可檢視性 超過 6 億會員和數百種微服務：如何擴展監視系統以跟上需求的腳步 脫離窠臼：將可檢視性的焦點從服務轉移到客戶 有量必有得—計量至關重要的原因 渡過難關：預警系統如何拯救農場 無需花費任何費用即可擷取和分析數百萬個查詢 事件關聯：減少 MTTR 的全新方法 強大的監視功能如何為 LinkedIn 摘要提供高可用性 減少 MTTR 和錯誤升級：Linkedin 上的事件關聯
練習和原則 可用性—思考超過 9 秒 SRE 的心理模型 建立應用程式時以信任優先 Java 討厭 Linux。 正面迎戰。 描繪特性和了解 SRE 實行的各個階段 安全性與 SRE：自然加乘效果 生產改進檢閱：減輕債務負擔 確保高效能應用程式的可靠性 服務記分卡—遊戲化的卓越營運方式 如何藉由挑毛病來改善服務
小組與管理 黃牌警示：運用智慧方法協助不穩定的小組 不擔任管理職的情況下領導團隊：成為 SRE 技術領導者 跨公司的 SRE 實作差異 100 個小組、100 種失敗的方法 SRE 為什麼參與、參與哪些項目以及如何開始著手進行 正在建置與執行 SRE 小組 SRE 的大學生：加入團隊貢獻所學 LinkedIn SRE：從草創時期到全球規模 在全球最大的軟體公司中重組 SRE DNA 序列 從初級毛毛蟲蛻變為蝴蝶
工具與技術 Azure SREBot：不僅是聊天機器人，還可以透過智慧型機器人減少緩和時間 TrafficShift：避免大規模災害 建立分散式檔案系統 TCP—結構、增強功能和調整 BGP—網際網路的骨幹 無伺服器中的作業 如何使用 Kafka 調整資料庫基礎結構 SRE 的網路：對應用程式進行疑難排解時需要了解什麼 Ambry—LinkedIn 的分散式不可變物件儲存 BPerf—Bing.com 生產中的雲端分析 DNS：新式問題的舊解決方案 使用 Rum DNS @ LinkedIn 進行流量導向
調整大小 流量預測和壓力測試基礎結構 大規模學習很困難！ 中斷模式分析和錯誤資料 調整分散式具狀態的系統：LinkedIn 案例研究 大規模偵錯—從單一設備到生產 大規模建置集中式快取基礎結構 可調整編碼—查找錯誤 管理容量 @ LinkedIn InStream：使用 BitTorrent、Python、Salt 和 Kafka 進行大規模發佈 避免和突破容量監獄 全球流量路由和容錯移轉的演變
