实践|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-Cloud/swan 欢迎 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 目标定位内容很多，在各个行业落地时不尽相同，所以要基于现实，拥抱变化，为了更好应对事故，坚持做推演和演练，在事故总结方面对产品做建言，故此在工具的研发上也会有决策权。