SRE运维解密&介绍

1.SRE 介绍

SRE全称为site Reliability Engineering，也就是俗称的站点可靠性工程师。我们可以从SRE中完全解读SRE工程师。

E：意味着工程师engineer，也就是要用计算机科学和软件工程手段来设计和研发大型、分布式计算机软件系统；避免人工手动处理

R：意味着可靠性Reliability，运维工作的重点就是保证产品的稳定可靠运行。如果没有人能够稳定地使用就没有存在的意义

S：意味着服务service，项目以及工具的开发就是为了运维在分布式集群管理系统上运行的具体业务服务

2.DEV 和 OPS 的矛盾

产品发布的流程：环境部署（将现成的软件组件部署于生产环境中，对外提供某种业务服务）、后期维护（保证产品运行期间的正常、稳定）。根据这两种主要步骤，传统的IT公司将相关人员分为两类：研发人员（dev）和运维人员（ops）

传统研发人员和运维人员一直在软件变更的发布速度存在着巨大的分歧：研发人员关注着快速地构建和发布新版本；而运维人员则要避免值班期间的故障发生。而软件、配置的变更则是导致故障发生的主要原因。因此，研发人员和运维人员的目标在本质上就是相悖的。

3.DEV 和 OPS 相统一

为解决上述问题，就需要将研发人员和运维人员相统一，这也就是SRE的核心思想。在一个典型的SRE团队中有两类工程师：研发人员、运维人员。这两类工程师都应具备研发技术和运维技能，但有所侧重。

SRE团队的工作重点在于研发软件系统以替代手工操作，转向自动化运维。因此SRE团队的工作又可以分为两类：研发与运维，这两者的比例应该相等。若专注于运维，则无法推动手工操作转向自动化运维；若专注于开发，则无法了解运维工作的痛点，交付出令人满意的作品。SRE团队应逐步推进产品，最终将基本的运维工作全部消除。

4.SRE 方法论

SRE团队的主要工作并不是单纯的运维，而是开发出自动化运维系统。因此，SRE团队在轮值期间处理事件的时间较少，主要工作是跟踪紧急事务，如事务发生的原因、处理故障的方法、如何恢复服务，并撰写一份事后报告。另外，SRE团队还需要负责新产品、配置的变更。那如何平衡产品变更与业务可靠之间的矛盾呢？

在书中提出了一种方案：错误预算。任何产品都不可能是100%可靠的，而运维工作也就是保证产品的可靠性接近100%，如99.99%。那么余下的0.01%就被称为错误预算。在这个范围内将这个预算用于新功能上线或产品变更。

一般来说，SRE团队要承担以下几类职责：效率与性能优化（可用性、延迟、性能、效率）、变更管理、监控、紧急事务处理以及容量规划与管理

4.1 效率与性能优化

监控和优化整个系统性能，为业务增加容量和提升效率

4.2 变更管理

变更管理应做到以下几点：

1、采用渐进式发布机制

2、迅速而准确地检测到问题的发生

3、当出现问题时，可以安全迅速地回退改动

4.3 监控系统

一个优秀的监控系统会自动分析事故的发生原因，并自动处理事故。只是当需要用户执行某种操作时，才会通知用户。
一般来说，监控系统应该只有三类输出：

1、紧急警报（alert）
用户需要立即执行某项操作

2、工单（ ticket）
预先获取用户的某项操作，日后执行

3、日志（logging）
关注日志，回溯事务发生的原因

4.4 紧急事务处理

可靠性是MTTF（平均失败时间）和MTTR（平均恢复时间）。运维团队比较关注的就是MTTR指标。因此，从手工操作转向自动化运维是势在必行的。

4.5 容量规划与管理

为业务日后的容量和冗余度做规划。一个业务的容量规划，不仅仅要包括自然增长（随着用户使用量上升，资源用量也上升），也需要包括一些非自然增长的因素（新功能的发布、商业推广以及其他因素），同时还需要进行周期性压力测试以调整规划