数人云实践|SRE赶上金融老干部，解决发布协调&监控告警两大难题

7月15日上海的《DevOps&SRE超越传统运维之道》主题沙龙上，数人云工程师保珠从核心理念、金融行业ITSM特性、发布协调、监控告警、总结定位等方面详细地阐述了数人云在金融场景下的落地实践。

今天主要跟你们分享数人云SRE的落地实践，由于目标客户主要是金融行业，因此基于ITSM特性，介绍实际场景中的发布协调和监控告警。

SRE核心理念

SRE是谷歌十数年运维过程当中演练出来的模式，在实践过程当中积累了不少经验，跟传统运维有一些区别。是创建在DevOps的思想上的运维方面具体实践。

SRE岗位工做职责有：

• 应急相应

• 平常运维

• 工程研发

SRE跟传统运维的工做职责相似，但在工做方式上有很大区别：
1）应急响应主要落实在对监控、应急事件的处理以及过后总结。

2）平常运维包括容量规划、性能监控、并更管理。

3）工程研发方面跟传统运维的区别在于参与研发事件、SLO制定和保障以及自动化，自动化运维是长期目标，也是热点内容。

SRE的工做原则：
拥抱变化：不担忧付出风险而拒绝改变，经过不断的推演和演练发现并解决问题。

服务等级目标：将服务划分等级分配给不一样的运维。

减小杂事：节省更多的时间用于开发。

自动化&简单化：开发的主要目的。

金融行业ITSM特性

金融行业在ITSM的特性主要是分级管理，工做模式上，运维和开发彻底隔离，但这是DevOps思想还没有达成的表现。运维团队规模是线性增加的，如上线一个系统时都会分配1—2个运维人员进行跟进。无论从网络仍是资源分配上，他们的职责更多在应急事件处理和常规变动上。

证监会和银监会有合规运维的要求，好比两地三个数据中心，这是金融行业比较明显的特性。

传统模式和SRE的区别——
传统模式：易招聘，传统行业招聘的运维首先是会Shell，Python等脚本编写，在自动化运维工具上会有新要求，过往经验积累如曾解决的事故，应对的问题。

SRE：难招聘，相对新兴的岗位，很难找到彻底匹配的人才；会有开发上的要求，强调自动化，包括在自动化工具里作编程性的内容，团队协做等等。

接下来分享SRE在两个客户实际场景的落地：某交易所、某商业银行信用卡中心。

SRE平台架构模型如上图，资源供给层是基于数人云的PaaS平台，以Docker容器化管理作资源调动，应用调度分别基于Mesos和Marathon，目前数人云也开源了名为Swan（Mesos调度器，Github地址：https://github.com/Dataman-Cl... 欢迎Star&Fork）的应用调度系统，目标是把Marathon替换掉。然后是软件技术架构层，对应公司里的架构部门，包括采用RPC框架、缓存、消息中心选型等等。

主要分享的内容在DC SRE这一层。再往上包括产品线有TISRE，也有接近于用户数使用的APP SRE，因此我的理解这是长期的建设过程。

实践—发布协调

发布协调在平常的工做中应用不少，如应用上线、变动管理。在SRE指导下，某项目现场成立了相似于发布协调的团队。成立SRE团队与金融行业系统上线特色有关：

• 金融行业里系统较多，包括信贷、信审等等诸多应用，系统逻辑也比较复杂。开发测试环境如物理环境彻底隔离，和互联网行业不一样。互联网行业，都是在线发布，测试环境也许就是生产环境，采用灰度发布或者蓝绿发布模式去作。

• 上线协调须要同时面对多个外包团队，外包团队人员相对不可控，致使沟通成本较高。

• 规模大的系统发布上线周期长。

如何解决以上问题，达到发布进入可控，下降发布失败率，缩短发布时间周期？

上述问题，在SRE的思想中，首先要创建发布协调团队。目前SRE工程师只能自行培养。团队推荐构成：项目经理、架构师、运维工程师、开发工程师。沟通方式以发布上线会议为主，不断Check系统或者产品开展工做。

团队的职责包括：审核新产品和内部服务，确保预期的性能指标和非性能指标。根据发布的任务进度，负责发布过程当中技术相关问题，以及协调外包公司的开发进度等等。

最重要的是要作到发布过程当中的守门员，系统是否上线要由发布协调团队决定。

团队在整个服务生命周期过程当中，不一样阶段，都要进行会议审核才能继续开展工做。会议根据发布的检查列表包括三个方面：架构与依赖、容量规划、发布计划。

在架构与依赖方面的逻辑架构，部署架构，包括请求数据流的顺序，检查负载均衡，日志规范着重配合监控方面的要求。同时检查第三方监控调用时是否进行测试管理等等。

容量规划主要是根据压缩报告作容量预估，以及峰值，好比微信活动比较多，因此会根据预估峰值的公司预算出来须要的资源，再落实到容器上，制定详细计划保障发布的成功率。

制定发布计划，确保成功。

在SRE的指导中，每件事都要落实到工具当中，由工具去检查每一个事项是否落实到位。当时作了发布平台，包括PipeLine、Jenkins，经过其调用负载均衡上的配置F5和配置中心，以及服务注册中心的机制。全部的发布事项基于容器云平台，功能模块包括变动管理、发布管理、流程模板及发布过程监控。

上图是发布平台项目大盘图，能够看到项目在发布流程中执行状况——成功率和失败率。没有发布平台前，整个上线过程管理人员不能实时看到发布具体状况，是卡在网络仍是某一个服务上，所以进度不可控。

有了这样的运维大盘后，整个发布过程能进行可视化跟踪，关键节点须要人工审核。

具体的发布步骤：

• 第一，检查F5里面的配置

• 第二，人工检查

• 第三，上传程序包，配置项管理

• 最后，重启容器再进行人工检查

总体过程都体现了SRE思想，发布平台的每一个步骤都可经过界面配置完成，中间关键点由人工参与，目的是保障产品上线的成功率，避免在上线过程当中手动配置产生问题，致使回滚事件发生。

有了发布协调团队后，上线的成功率、自动化程度和发布效率明显提升，减小了人肉操做落实在Jenkins、PipeLine的配置项上，下降错误发生概率。

实践—监控告警

监控做为一个垂直系统，在数人云的产品体系中举足轻重。监控的重要性深有体会，咱们在某金融公司SRE团队中有1—2名监控专员，专员主要职责是维护监控系统。一个是甲方内部人员，另外一个是数人云的同事。

监控主要解决的问题：
首先要及时发现，时效性很重要，所以需创建监控系统。

为何会出现故障，要多作事故总结以及后续的故障跟踪。

上图为监控系统架构图，基于Prometheus的时序数据库，红线为监控的数据流向，因是Mesos框架，因此左边会看到Mesos运算节点上的监控项。经过容器化的Cadvisor组件收集主机和该主机全部容器的CPU和内存以及磁盘信息。告警部分使用Prometheus的Altermanager组件，支持Webhook方式，经过短信、邮件形式告警。为了过后总结，需将一些告警事件存在数据库中。

绿线主要体如今日志收集和关键字告警，日志收集经过容器化的Logstash组件，首先收集容器内部的中间件，如Tomcat等Web中间件的日志，也能收集应用日志，根据须要会把一些信息丢到Kafka里面，经过大数据平台作在线日志分析。

日志关键字告警是经过自研组件在日志传输过程当中过滤关键字进行事件告警。

容器服务的健康情况经过Marathon的事件Pushgateway推到Prometheus，最后在前台以本身开发的UI查看监控信息和告警上的配置。为方便使用Prometheus的查询作统一封装，减小API使用复杂度。

在SRE体系里很明确提到了监控的4大黄金指标：延迟、流量、错误、饱和度：

• 延迟：监控服务的API以及URL的访问时间，直接配置某一个服务的URL，后台不断去访问，包括访问时间的预值，超过期间发出告警。

• 流量：负载均衡请求的链接数。

• 错误：监控HTTP请求返回码和日志中异常关键字。

• 饱和度：根据不一样的系统，如内存资源性系统监控内存使用率，IO读写使用比较高，监控资源IO状况。

以上指标要在运维的过程当中不断优化，如一些告警多是网络缘由进而产生其余问题，如网络交换机出现问题，直接挂掉平台的Marathon组件，应用上很明显是第三方服务调用，接连会产生不少问题，要把共性问题聚合，减小误告警次数。但减小误告警也可能会把有效告警卡掉，也值得思考。

故障跟踪和过后总结相似，人工操做会延长恢复时间，告警发生时通常由一我的处理，随着时间延长而升级策略，如超过半个小时会逐级上报调用更多的资源处理故障。在故障跟踪上解决线上问题为主，处女座强迫症为辅，作好总结Root Cause更好的反馈到自动化工具上。

事故总结很是重要，解决不意味着结束，要追溯缘由，如交换机重启，致使Marathon的一些问题，总结后发现，最好的解决办法是交换机重启时通知运维，停掉相关组件，交换机恢复后，再启动，如此不影响业务的实际运行。

要从失败中学习，把告警的事件作记录创建知识库，发生问题时方便检索，快速找到解决方案，要总结解决某个事故时如何更快发现问题所在，创建反馈机制，在SRE监控过程当中，不断跟产品作实时反馈，包括链接池的使用状况等，鼓励主动测试，平时运维不会发生的事，尽量想办法去看结果。

目标定位

SRE目标定位内容不少，在各个行业落地时不尽相同，因此要基于现实，拥抱变化，为了更好应对事故，坚持作推演和演练，在事故总结方面对产品作建言，故此在工具的研发上也会有决策权。