站点可靠性工程文档

体系结构

• Microsoft Azure 架构良好的框架
• Azure 应用程序体系结构指南
• 参考体系结构和示例工作负载
• Azure 的 Microsoft 云采用框架
• 在 Azure 上构建微服务
• Azure 数据体系结构指南
• 云最佳做法
• 设计可靠的 Azure 应用程序
• 云设计模式
• 面向 AWS 专业人员的 Azure
• 面向 GCP 专业人员的 Azure
• 性能调优
• 在 Azure 体系结构中心中查看详细信息

监视

• Azure Monitor 概述
• 将指标与 Azure Monitor 配合使用
• 将日志与 Azure Monitor 配合使用
• 使用 Application Insights 管理应用程序性能
• 将分布式跟踪与 Azure Monitor 配合使用
• 查看有关 Azure Monitor 的详细信息

预配和交付

• Azure Resource Manager
• Azure 上的 Terraform
• GitHub 操作
• Azure Pipelines

扩展

• 自动缩放概述
• 自动缩放指南
• 为自动缩放进行开发
• 性能效率支柱概述
• 扩大式设计
• 可靠性模式

区域性

• 站点可靠性工程的演变
• 构建 SRE：来自外部的区域性
• 多文化团队的文化细微差别和有效协作
• SRE 的演变以及对 SRE 促变因素日益增长的需求
• 反馈循环：SES 如何受益，以及实现其潜力所需的内容
• 了解业务指标可以实现更好的 SRE
• 站点可靠性永不结束的故事
• 在运营中，每天都是星期一

事件响应和事件后审查

• 构建复原能力：如何从事件中了解详细信息
• 两个事后调查的故事：人类因素视图
• 自动化的讽刺：三个部分的喜剧
• 对接电话： 一个波兰人
• 一对一的 SRE

监视和可观测性

• 超过 6 亿会员和数百个微服务：我们如何扩展监视系统以跟上
• 离开被击败的路径：将可观测性焦点从服务移动到客户
• 你得到的是你所测量的 - 为何指标非常重要
• 抵御风暴：如何预警拯救农场
• 捕获并分析数百万个查询而没有任何开销
• 事件相关性：减少 MTTR 的新方法
• 可靠的监视功能如何为 LinkedIn 源的高可用性提供支持
• 减少 MTTR 和误报：LinkedIn的事件关联

实践和原则

• 可用性 - 超越高可靠性指标而思考
• 适用于 SRE 的心理模型
• 创建应用程序时优先考虑信任
• Java 讨厌 Linux。 处理这个问题。
• 理解 SRE 实践的阶段并描述其特征
• 安全性和 SRE：自然力乘数
• 生产改进评论：从修复债务中咬掉
• 确保高性能应用程序的可靠性
• 服务评分卡 - 将卓越运营游戏化
• 如何通过深挖并曝光服务问题来改善服务

团队和管理

• 代码黄色：帮助运营顶级团队以智能方式
• 在没有管理的情况下领先：成为 SRE 技术领导者
• 不同公司的 SRE 实现形式之间的差异
• 100 个团队，100 种失败方法
• 开始参与 SRE 的原因、内容和方式
• 建立并运转 SRE 团队
• 大学生到 SRE：加入入门级人才
• LinkedIn SRE：从开始到全球规模
• 在全球最大的软件公司中拼接 SRE DNA 序列
• 将第 1 层毛虫转换为蝴蝶

工具和技术

• Azure SREBot：不仅仅是聊天机器人- 用于粉碎缓解时间的智能机器人
• TrafficShift：大规模避免灾难
• 让我们构建分布式文件系统
• TCP - 体系结构、增强功能和优化
• BGP - Internet 的主干
• 无服务器模式下的 Ops
• 我们如何使用 Kafka 扩展数据库基础结构
• SRE 网络：对应用程序进行故障排除时需要了解什么
• Ambry - LinkedIn 的分布式不可变对象存储
• BPerf - 针对生产的 Bing.com 云分析
• DNS：新式问题的旧解决方案
• 在 LinkedIn 使用 Rum DNS 进行流量转向

扩展

• 流量预测和压力测试基础结构
• 大规模学习很困难！ 故障模式分析和脏数据
• 缩放分布式有状态系统：LinkedIn案例研究
• 大规模调试 - 从单机到生产
• 大规模构建集中式缓存基础结构
• 可缩放编码 - 找到错误
• 在 LinkedIn 管理容量
• InStream：使用 BitTorrent、Python、Salt 和 Kafka 进行大规模分发
• 避免和打破容量束缚
• 全球流量路由和故障转移的演变