1、运维理念与实践目标99.9999%服务级别协议（SLA）可用级别1个9在线时间90%年宕机时间36.5天2个999%3.65天3个999.9%8.76小时52.6分钟5.25分钟31.5秒4个999.99%99.999%99.9999%5个96个980年代 瀑布模型 传统软件发布 开发、运维脱节 没有BUG 发布周期 做开发真好 1个980年代90年代 Web软件出现 依然是瀑布模型 开发、运维不再完全脱节 出现Ops组 发布周期 做开发还不错 2个990年代00年代 非服务节点更稳定 竞争加剧 发布更加重要 可靠性也更加重要00年代00年代 开发与运维的矛盾凸显 开发 发布、发布、再发布 运
2、营 稳定、稳定、再稳定 DevOps概念出现 鱼与熊掌是否可以兼得？如何实现99.9999%？堆人？技术？扯皮 运营：审查、深入调查、加长流程 开发：小改动、改标记、改UI、5%实验 网站可靠性工程师（SRE）双方都拿稳定性当回事 发布危险评测不再归于SRE如何实现99.9999%？工程方法 组织架构 管理理念 技术支持工程方法 自运营服务 得到SRE间接支持 SRE运营服务*小SRE负担 重要服务 法律要求 可用SRE 错误预算 6+月自运营 SRE审查 或返回自运营工程方法错误预算 前提 影响稳定性的因素 错误预算=1-SLA 季度结算 计算方法 冻结 没有政治 两个组的共同目标工程方法错
3、误预算 实例 SLA：99.99%可用：0.01%已用：0.003%剩余：0.007%.实例 已用：0.008%剩余：0.002%如果走下一步，是开发的责任工程方法交接稳定性交接HRR发布用户LRRT0T0+6M+X时间工程方法反交接稳定性反交接自运营时间工程方法审查 监视系统 事件寻呼 仪表盘 事件发生频率与类型 系统架构 发布过程 Bug程度、类型与数量组织架构经理3经理2经理1经理3经理2经理2经理1SRE或是？经理1开发开发SRE管理理念 最高级别 必须支持 非最高级别 必须理解 必须执行 数字为王非技术总结 共同目标 共同利益 共同手段 越早合作、越是顺利技术支持SRE SRE能力 不熟悉代码 运营+开发背景 工具 机器、存储、带宽、错误处理、配置、安装、监控、仪表盘 SRE信息支持 邮件系统 咨询时间 学习资源 发布审查列表 发布委员会技术支持发布 测试与发布方法技术支持发布 测试与发布方法技术支持发布 测试与发布方法技术支持发布 测试与发布方法技术支持发布 发布方法技术支持回滚技术支持测试 自动化 单元测试 组件测试 系统测试 压力测试 手工测试技术支持工具 监控 内存 cpu 白盒 黑盒 仪表盘 监控的超集（不至于page)发布期（包括配置更新）on duty期技术支持基础架构 强大的容错基础架构 数据库 网络 存储
