SRE思想

1 规模效应

业务越庞大，服务器就越多，服务越多，就越需要拆分成分布式架构。架构越复杂，对运维的能力要求就越高、出错的概率就越大，运维的工作量就越大。因此就要更多开发提升效率的工具。

而在小企业，业务没有那么庞大，公司没有能力也不需要sre，只需要几个初级的linux系统管理员，做些手动的操作就可。

所以，sre在小企业是无法诞生的，因为没有起因。

2 SRE出身

2.1 做什么

软件工程师专注于软件系统的设计和实现。

需要另一个职业，专注于软件系统在整个生命周期中的保持稳定运行、发现问题，和软件工程师沟通甚至参与、约束他们的开发，以改进整个软件系统。

这个职业，google称之为站点可靠性工程师（SRE）。

他们要做什么？

1 参与软件系统的设计和改进，防止他们开发一些很容易在基础架构层面出bug的东西。

2 开发运维平台，比如软件工程师设计组件状态抛出接口，SRE从接口拉取数据并设计组件运行状态图表。

3 强化软件系统可靠性。比如所有组件的监控以及自动化反应、处理任何潜在的性能瓶颈。

2.2 会什么

1 传统运维技能

2 用软件技术自动化手动运维操作的开发能力

3 懂开发人员的部分技术

2.3 前身

1 运维学开发

2 开发学运维

2.4 工作目标

单元部署、业务变更、故障处理也许都是手动操作的，这些工作也许花掉了运维很多时间。

第一步，就是保证足够的时间来编程，自动化某些人工流程。

第二步，继续编程，开发详尽的监控功能，并使程序能自动处理故障。

第n步，还是编程，以消灭所有人为操作为目标。

然后把web界面直接开放给运营或者开发，让他们自己去部署。这样应用运维就可以从部署中解放出来。

3 可靠性

用户不满意服务，就意味着玩家流失，就意味着业务的估值下降。

考虑几个问题

1 我现在的业务，在用户的使用习惯中，可靠性要达到多少才算满意？

2 在业务运行的过程中，哪些不完善的机制导致了业务出现问题，如何才能在机制层面解决这些问题？

3 可靠性、人力成本和设备成本之间的平衡点在哪？

4 错误预算：运维的目标不是保证100%的可靠性，多少量的生产事故是可接受的？我需要设定目标。

4 监控系统

一个系统不可能不出故障，重点是可以快速定位故障，快速解决故障。所以需要监控系统。监控系统是保证系统可靠性的核心手段之一。

主要有几类监控

1 可以自动化分析处理的，属于可预见、既定方案的

2 需要人工参与处理的，属于不可预见，没有既定方案的