方法论与技术栈双管齐下的运维可用性能力建设（三）

3Google SRE的可用性保障

关于Google SRE的理解在之前梳理的文章中做了一些总结，以下仍引用那篇小文中的理解：

SRE这个名词最早是从《Google SRE运维解密》一书中获得，全称是Site Reliability Engineering，翻译过来就是：站点可靠性工程师。Google对SRE的职责描述为：确保站点的可用，为了达到这个目的，一方面他需要对站点涉及的系统、组件熟悉，也要关注生产运行时的状态。

为此，他需要自开发并维护很多工具和系统支撑系统的运行，比如自动化发布系统，监控系统，日志系统，服务器资源分配和编排等。SRE是一个综合素质很高的全能手，如果对他的能力进行分解主要有三块：

熟悉系统架构与运行状态：SRE需要懂服务器基础架构、操作系统、网络、中间件容器、常用编程语言、全局的架构意识、非常强的问题分析能力、极高的抗压能力（以便沉着高效地排障），他们还需要懂性能调优理论。为了保证系统架构的高可用，SRE甚至会有意识的破坏自己的系统，以提高系统可用性。

熟悉运维涉及的管理方法：SRE需根据企业自身发展需要，清楚运维涉及的各项工作的流程方法论，比如故障处理、应用发布、可用性管理等等，SRE十分重视运维流程的持续改善，比如对故障的追丁溯源，怀疑一切的方式持续改进。

运维开发+产品经理：SRE在运行保障过程中的手段更加自动化，更高效，这种高效来源于自动化工具、监控工具的支撑，且他们还需要是这些工具的主要开发者，他们要不断优化和调整，使整个工具箱使起来更加得心应手。为此SRE有一个50%的理念，就是50%用于日常保障，50%用于项目性的工作，这个项目性的工作主要体现在运维开发与运维产品经理的角色。

总的来说，BCM更关注于从管理层面可用性能力建设方法论，而从Google现有的分享来看，Google SRE更关注于技术层面的可用性能力建设，两者都值得我们在可用性能力建设中借鉴，以下仅从一个局部梳理我理解的可用性能力建设的一些方面。

三、运维可用性能力建设（技术手段）

关于技术手段方面的可用性能力建设，将从运维把控技术架构的高可用的标准化策略的生产环境准入门槛、运用数据分析及专家意见进行信息系统架构的持续优化、运维工具建设提高问题的预测或加快可用性的恢复三方面进行梳理。

1架构的可用性标准化

不同运维领域的运维人员在局部都会有很多架构可用性建设的经验，由于我对基础设施、网络、服务器、数据库、系统等方面的可用性能力建设接触较少，故在本章只从信息系统架构的可用性进行梳理。梳理架构的可用性是希望以运维团队可以把控的角度，对信息系统的架构可用性的准入条件进行提前的标准化。

从运维团队看，有些大型的互联网运维团队具备研发基础组件的能力，比如腾讯QQ团队提到的它们研发了服务名词服务模块，应用系统的开发团队按这个模块进行服务注册与消费的设计；或者是建立基于容器的PaaS平台，开发团队按PaaS平台规范进行设计等等。

基于系统稳定性角度看，我觉得这些由运维团队建立的标准化模块需要建立在一个强大研发能力的运维团队与相对开放式的运维开发协同大环境之下。从相对比较普适的架构可用性建设看，可以考虑先从以下几方面进行建设：

1）应用架构高可用

双机备份

我们提到的双机备份通常有两种方式，一种是冷备，一种是热备，两者区别是，前者的主备切换需要人工介入，后而不需要人工介入。这种方式，像windows操作系统的群集管理工具，Linux操作系统HACMP等具备这种双机切换的能力。

从信息系统上，当前传统的关系型数据库，以及一些版本比较旧的应用系统通常是采用这种双机备份的方式。在处理双机备份时，需要重点关注主备机实时的异常探测，数据的同步问题，以及备机服务的接管能力。

通常来说，主备机之间会有一个心跳机制定时进行检测主机是否处理正常运行状况，比如windows的群集会主动探测主机的资源是否在线，这里的资源包括IP、服务等是否可用；

数据的同步上，主要针对实时更新的数据更新，采用共享存储、将非共享存储作为一个资源在异常时加载到备机服务，或采用数据实时复制的方式；

备机服务的接管则依靠切换软件在异常时执行提前准备好的切换脚本实现服务的接管；

运维团队需要针对双机备份的架构要求提前制定标准，避免主机异常时无法自主发现，发现后备机无法接管完整的数据，或备机服务接管需要人工进行复杂的操作介入等问题。

双机备份架构虽然简单，但也有一些缺点，比如主备切换期间的业务不可用，需要突破单机的性能瓶，备份机闲置状态带来的资源浪费，备份机的可用性管理也经常出问题，容易出现紧急情况下备机不可用的情况，所以如果有条件尽量减少采用双机备份的方式。

集群&负载均衡&分布式

负载均衡与分布式的架构概念比较容易混淆，在我的理解中，负载均衡架构是多个服务做一堆同类的事情，每件事情相互独立；分布式的架构则是将一件复杂的事情分解出多个部份，由多个服务去做，再通过架构实现多个分解事情处理结果的合并。

负载均衡的架构的出现主要是解决单一服务器设备或服务无法承担性能要求，因为通常对单机服务器性能的优化带来的成本远大于横向多台负载服务器的扩展，且带来更灵活的扩展性，尤其是X86化、虚拟化、容器化等云化技术的推动。

负载均衡架构通常需要具备负载均衡算法、健康检查、会话保持的负载均衡软件或硬件来提供架构上的可用性，其中常用见负载均衡算法有轮询、最小连接数、最快响应时间，或基于数据包内容的分发；健康检查则通常是对网络连通性、服务端口监控等方式检测；会话保持则是需要有一个机制保证一个用户多次请求由同一台服务器处理（当然，现在互联网公司也提出无状态的解决思路）。

Hadoop的mapreduce、HDFS等组件是分布式架构典型的例子，比如mapreduce的运算过程即是“input - > map -> reduce -> output"，它的作用就是为了缩短单个计算任务的执行时间来提升效率。

理论上讲由于分布式架构可能会影响某一个节点的异常导致这个业务的失败，所以类似于mapreduce、HDFS这类分布式架构在设计之初就考虑了系统可能是异常的情况，在这些组件的设计上考虑了异常机制。

另外，为了进一步提高可用性还增加了一些关联组件来保障可用性，比如运用Yarn来实现资源的调配，运用ZK实现服务的注册消费等。

从上述三种架构看，正常情况下负载均衡/分布式架构优于双机备份的架构，至于负载均衡与分布式架构哪个好，我觉得只有哪个更适合具体的应用场景，所以我们在架构的可用性能力标准化建设方面，可以考虑如下：

针对不同的业务模块的类型制定优先选用的架构部署方式作为运维准入的门槛，并提前提交应用系统开发团队。

针对标准化架构，考虑建立统一的标准化组件模块，比如硬件的负载均衡模块、软件的负载均衡及分布式架构模块、标准化的PAAS层的集群管理模板，标准化的脚本等优化工作。

在非功能性层面考虑高可用的保障，在非功能性层面的高可用保障，运维的人都知道开发团队很少主动考虑应用系统的非功能性功能的设计，比如让开发提供服务异常时的报警这件事情况上，我觉得运维在工具建设过程中需考虑更多一些，为开发提供事件集中处理平台的标准接口，方便开发团队将异常信息提供给运维。同样，在应用部署工具中考虑应用程序在多个节点上的应用同步机制；在监控工具层面考虑应用服务异常时的服务重启自愈等等，这些高可用保障方式需要有一定的标准化程序包的落地。

上述的高可用架构主要是针对同一数据中心内的部署架构，如果放在多中心的角度，还会有跨中心的高可用解决方案，比如灾备环境的业务负载能力，这就不仅从请求分流、应用负载等要求，对数据同步等能力也要求很高这里不再作进一步细化。

2架构优化

在架构优化方案中，运维用得比较多的是：

纵向扩展：加服务器资源，换性能更强的服务器提升服务能力

横向扩展：增加节点，比如拆分数据库、增加负载均衡的服务节点、按地区分拆应用等方式提升服务能力

在一些数据量发展相对少的系统中，纵向扩展是最快也是最有效的解决方案，但对于业务量高速扩张的应用，第1种方案显然无法解决问题，这时候需要用到横向扩展的架构优化思路。具体的实施思路如下：

1）业务垂直拆分，服务化：从业务角度规划Service，Service化完成后，业务就独立了，这样DB读写权限可以得到划分。

梳理应用系统交易类型，把查多写少、查少写多的交易进行分离，再进行拆分，实现交易服务化。

2）数据库读写分流：数据库读写分流带来的好处是，数据库可以分库了。

在数据库中将不同的应用拆分不同的实例

在数据库前面加上cache，减少对数据库的压力

将查询类比较多的业务从交易数据库中拆分出来，并在此基础之上再进一步拆分查询类的数据库，拆分写的数据库，实现了读写分离（不是完全的读与分离，但是有侧重读与写，我们认为根据不同的应用需要有主与从数据库。

分布式数据库，即将第3）点的主、从数据建立多个集群，分布式部署数据库。USERID来区分，比如1000001是第一个库；2000001是第二个库，以此类推；按地区来区分，比如长江以南与长江以北的客户来分别部署数据库

3）服务逻辑分组：上面是物理上的分离，但硬件成本、维护成本高，所以需要从应用层对服务进行扩展，分组。

横向增加应用服务节点，通过负载均衡分发策略来实现应用性能负载。

4）应用业务流程的优化：业务流程的改造是最根本的解决，去掉一些花俏的业务功能，分拆业务流程到不同的服务，或限制业务功能的使用时间或数量等等。

5）同步改异步的方案：增加并发性。异步本身不是什么高深的技术，关键是哪些业务可以走异步，这更体现架构师的业务理解能力和综合能力。

6）限制峰值：运维人员需要知道一个应用或数据库的峰值是多少，知道峰值后就可以考虑如何限制峰值。

7）数据库监控：SQL是影响数据库性能的重要因素，系统会对慢查询SQL进行分析，分析后的慢查询自动发给相关研发和DBA进行优化。

8）适度才好：在平时，流量上来后数据库的性能出现瓶颈时，要具体问题具体分析，不能盲目的进行扩容、拆分、硬件升级等，先要根据具体的SQL效率、性能，结合数据库本身情况分析判定，也许调整一下索引，SQL语句做一下调整即可解决并发量上来后的性能问题。

宝企通IT服务作为智能化工单系统龙头，拥有多年优化SLA经验，能够有效提高员工对IT的服务满意度。是一款支持SAAS、本地化部署、源码交付的运维工单系统(SAAS免费试用，企业微信--工作台--添加应用，搜索“IT服务”，排名第一的就是)。目前是全网众多企业选择的工单类产品，支持手机验证码或账号验证，员工自助修改域账号密码，具备智能化派单模式工程师响应快减少员工等待时间。自定义知识库可提升工程师专业技能水平，帮助工程师迅速判断员工问题，极大提升员工报单体验。系统还能够大幅提升职能部门可以服务的用户数，有效降低专业人力成本开支，提高业务执行效率，展现工作成果。产品服务好能为用户免费开发个性化需求，连续多年被魔力象0评为leaders位置，市场占有率爆发式增长