第一章 SRE与Devops之间的关系

运维是一门很难的学科。

不应将运维视为一个成本中心，否则想要取得实质性的改进变得举步维艰。

关于DevOps的背景情况

DevOps是一套松散的实践理论、指导原则和工作文化，旨在打破IT组织中开发、运维、网络和安全各自为政的局面。

Cultrue 文化

Automation 自动化

Lean continuous 精益持续改进

Metrics 监控指标

Sharing 分享

不再各自为政，即打穿门墙。
意外乃兵家常事。意外不仅仅是某个人的孤立行为而导致的，而是因为在发生了不可避免地意外故障时，保障措施的缺位。
变更要小步快跑。每次的变更要小一点，做的次数要多一点。这种小步快跑的模式，再结合自动测试，出错回滚，就可以实现变更管理方式的转型了，变迁到持续集成(CI)和持续交付或部署(CD)的模式
工具与文化休戚与共。工具是DevOps非常重要的组成部分，但企业文化更应受到高度重视。良好的文化可以解决糟糕的工具造成的麻烦。
准确的度量至关重要。在业务的视角中度量显得尤为重要，尤其是在避免各自为政和解决事故方面。

SRE是一个工作岗位，是一系列工作的实现方式，以及一些使这些工作实践充满动力的信念。如果DevOps是一种理念和工作方法，SRE实现了DevOps中所描述的部分理念，而且比DevOps所定义的工作更加具体、清晰。

运维的痛点也是软件问题 SRE的基本信条：做好运维是一个软件开发问题。
以服务质量目标(SLO)为准绳 SRE不会企图提供100%的可用性。产品团队和SRE团队会为服务的用户群体选择合理的可用性目标，并以SLO为准绳来管理该服务。
尽量减少琐事 对于需要由机器来做的运维任务，通常情况下就应该让机器去完成。琐事绝对不是工作，项目工作才能帮助我们让服务更可靠，更具扩展性。

生产的智慧：通过在生产环境中运行事物而获得的智慧

确定本年度要自动化的工作 要明确哪些内容需要自动化，在什么条件下自动化，如何自动化。
故障解决的越快，进度就越快 SRE参与工作的主要收益不只是提高可靠性，还改善了产品开发的输出。
与开发人员同舟共济(Share ownership) SRE倾向于关注生产问题，而不是业务逻辑问题。理想情况下，产品研发和SRE团队都应该对产品技术栈有整体的了解。
岗位虽不同，工具可统一。

DevOps与SRE的共性：

DevOps与SRE的差异：

DevOps是一种更宽泛的理念和文化。SRE的职责定义就相对狭窄，其工作通常是面向服务而非面向整体业务。

SRE与DevOps所认可的东西相同，但认可的原因略有不同。

有效的运维方法都是相似的，而出问题的方式各不相同。

片面、刻板的激励机制会阻碍成功 不要将激励措施与发布相关的，可靠性相关的成果联系在一起。要允许回撤那些难以驾驭，无可救药的产品支持。
解铃还须系铃人，勿怨他人 请完全消除将生产事故或系统故障归咎于其他团队的念头。
- 应当允许并鼓励在产品需要时修改代码和配置。同时授予职责范围内较高的自由度
- 支持对事不对人的事后总结报告。
维护可靠性是专业化角色 SRE和产品开发可以是两个独立的部门，每个团队都可以有自己的工作重点、优先事项和管理模式，而不必和其他的团队一一对应。这两个团队是相辅相成的。
毋庸斟酌是否，只需推敲时机
尽量在职业发展和物质激励上一视同仁

推荐书籍

Site Reliability Engineering
Effective DevOps
The Phoneix Project
The Practice of Cloud System Administration: DevOps and SRE Practices for Web Service, Volume 2
Accelerate: The Science if Lean Software and DevOps