sre1
sre和传统it运维的区别：
- sre深度参与开发阶段的工作，对应用的设计实现方案/依赖/运行时的资源消耗等都有严格的规约
- sre本身也要做很多开发工作，开发各种工具进行自动化解决运维问题和故障
- 按照sre的规约，由开发人员自行进行程序的上线部署和更新。
sre真正实现了devops
运维应该是作为一项工程存在，有标准和规范。不能依靠个人英雄主义。
我们运维人员应当称为这个新的名字sre。Site Reliability Engineer 站点可靠性工程师
关键词就是 软件工程理念 + 自动化工具
（题外话，感想：一个软件工程，不只是最终的成品软件和架构设计是有价值的，真实的设计过程，思考经历，经验的沉淀，总结教训都是非常有价值的。实现细节永远只是短暂的，而文档化的设计过程却是无价之宝）
软件工程有时候和养孩子很像：虽然孕育一个孩子的过程是艰辛的，但是以后的养育孩子才是更需要花费长久精力的事情。但是目前我们软件行业的关注绝大部分都集中在开发阶段，对运维阶段设计的很少。
如果说软件工程师专注于生孩子，那么sre就是专注于养孩子。进行整个软件系统的生命周期管理，从设计到部署，不断迭代，最后下线退役。
sre理念：
对细节不懈关注，做好充足的灾难预案和准备工作，时刻警惕着，不放过一切机会去避免灾难发生。
对sre的传统运维工作设置一个上限 50%。sre必须有重组的时间进行编程。设计出切实解决问题的系统。
这需要管理层的介入
sre的核心方法论
- 确保长期关注研发工作
- 在保障服务slo前提下最大化迭代速度
当前敏捷开发的主要矛盾是迭代创新的速度和产品稳定度之间的矛盾
监控系统
一个需要人工阅读邮件和分析警报来决定目前是否需要采取某种行动的系统从本质上就 是错误的。监控系统不应该依赖人来分析警报信息，而是应该由系统自动分析，仅当需 要用户执行某种操作时，才需要通知用户
应急事件处理
评价一个团队将系统恢复到正常情况的最有效指标，就是MTTR。平均恢复时间。
任何需要人工操作的事情都只会延长恢复时间。 一个可以自动恢复的系统即使有更多的 故障发生，也要比事事都需要人工干预的系统可用性更高。
应急事件的处理关键在于运维手册。SRE 将大部分工作重心放在“运维手册”的维护 上
变更管理
大概70%的生产事故由某种部署的变更而触发。
变更管理的最佳实践是使用自动化来完成以下几个项目：
● 采用渐进式发布机制。
● 迅速而准确地检测到问题的发生。
● 当出现问题时，安全迅速地回退改动。
将人工因素排除在流程之外，变更执行的速度和安全性同时得到了 提高。
因为人很容易被大量重复性劳动的关注疲劳所影响
需求预测和容量规划
需求预测和容量规划简单来说就是保障一个业务有足够的容量和冗余度去服务预测中的 未来需求。
一个业务的容量规划，不仅仅要包括自然增长(随着用户 使用量上升，资源用量也上升),也需要包括一些非自然增长的因素以应对突发情况。
容量规划有几个步骤是必需的：
● 必须有一个准确的自然增长需求预测模型，需求预测的时间应该超过资源获取的 时间。
● 规划中必须有准确的非自然增长的需求来源的统计。
● 必须有周期性压力测试，以便准确地将系统原始资源信息与业务容量对应起来。
SRE 应该主导容量规划和资源部署的过程
资源部署
资源的 部署和配置必须能够非常迅速地完成，而且仅仅是在必要的时候才执行，因为资源通常 是非常昂贵的。而且这个部署和配置的过程必须要确保能够正确地执行完毕，
效率与性能
SRE 可以通过模型预测用户需求，合理部署和配置可用容量， 同时可以改进软件以提升资源使用效率。通过这三个因素能够大幅度推动一个服务的效 率提升(但是并非全部)。