文档章节

实践|SRE遇上金融老干部,解决发布协调&监控告警两大难题

数人云
 数人云
发布于 2017/07/28 11:28
字数 3117
阅读 8
收藏 0

Markdown

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

Markdown

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

SRE核心理念

Markdown

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

Markdown

SRE岗位工作职责有:

  • 应急相应
  • 日常运维
  • 工程研发

SRE跟传统运维的工作职责类似,但在工作方式上有很大区别: 1)应急响应主要落实在对监控、应急事件的处理以及事后总结。

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

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

Markdown

SRE的工作原则: 拥抱变化:不担心付出风险而拒绝改变,通过不断的推演和演练发现并解决问题。

服务等级目标:将服务划分等级分配给不同的运维。

减少琐事:节省更多的时间用于开发。

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

金融行业ITSM特性

Markdown

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

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

Markdown

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

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

Markdown

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

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

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

实践—发布协调

Markdown

发布协调在日常的工作中应用很多,如应用上线、变更管理。在SRE指导下,某项目现场成立了类似于发布协调的团队。成立SRE团队与金融行业系统上线特点有关:

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

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

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

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

Markdown

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

Markdown

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

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

Markdown

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

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

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

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

Markdown

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

Markdown

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

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

具体的发布步骤:

  • 第一,检查F5里面的配置
  • 第二,人工检查
  • 第三,上传程序包,配置项管理
  • 最后,重启容器再进行人工检查

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

Markdown

有了发布协调团队后,上线的成功率、自动化程度和发布效率明显提高,减少了人肉操作落实在Jenkins、PipeLine的配置项上,降低错误发生几率。

实践—监控告警

Markdown

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

监控主要解决的问题: 首先要及时发现,时效性很重要,因此需建立监控系统。

为什么会出现故障,要多做事故总结以及后续的故障跟踪。

Markdown

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

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

Markdown

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

容器服务的健康状况通过Marathon的事件Pushgateway推到Prometheus,最后在前台以自己开发的UI查看监控信息和告警上的配置。为方便使用Prometheus的查询做统一封装,减少API使用复杂度。

Markdown

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

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

  • 流量:负载均衡请求的连接数。

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

  • 饱和度:根据不同的系统,如内存资源性系统监控内存使用率,IO读写使用比较高,监控资源IO情况。

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

Markdown

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

Markdown

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

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

目标定位

Markdown

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

© 著作权归作者所有

共有 人打赏支持
数人云
粉丝 16
博文 101
码字总数 328110
作品 0
朝阳
架构师
如何理解 Site Reliability ?

作为谷厂出品的神书《SRE Google运维解密》, 笔者早有耳闻并断断续续阅读过部分内容,最近终于静心品阅了一遍(作为拖延症患者, 写完此文与阅读完原书已间隔约半年),里面的很多理念确实值得细...

曲高和寡_健
2017/10/25
0
0
互联网企业级监控系统 - OpenFalcon

Open-Falcon 人性化的互联网企业级监控系统,Open-Falcon 整体可以分为两部分,即绘图组件、告警组件。其中: 安装绘图组件 负责数据的采集、收集、存储、归档、采样、查询、展示(Dashboard...

UlricQin
2015/05/09
0
21
Google 和 Facebook 如何大规模处理 IT 事件管理 —— 2016 SRE 大会之我

【编者按】本文作者为 Maria Arbisman,主要介绍 Google 与 Facebook 两大巨头是如何大规模处理 IT 事件管理。文章系国内 [ITOM][1] 管理平台 [OneAPM][2] 编译呈现。 [2016 年举办的可靠性工...

OneAPM蓝海讯通
2016/06/15
19
0
谈谈后台服务的灰度发布与监控

版权声明:本文由廖念波原创文章,转载请注明出处: 文章原文链接:https://www.qcloud.com/community/article/149 来源:腾云阁 https://www.qcloud.com/community 为什么要有灰度发布与监控...

偶素浅小浅
2016/11/05
9
0
运维架构服务监控Open-Falcon

一、 介绍 监控系统是整个运维环节,乃至整个产品生命周期中最重要的一环,事前及时预警发现故障,事后提供翔实的数据用于追查定位问题。监控系统作为一个成熟的运维产品,业界有很多开源的实...

小红牛
2017/10/12
0
0

没有更多内容

加载失败,请刷新页面

加载更多

可爱的python测试开发库(python测试开发工具库汇总)

欢迎转载,转载请注明来源: github地址 谢谢点赞 本文地址 相关书籍下载 测试开发 Web UI测试自动化 splinter - web UI测试工具,基于selnium封装。 链接 selenium - web UI自动化测试。 链...

python测试开发人工智能安全
今天
2
0
Shiro | 实现权限验证完整版

写在前面的话 提及权限,就会想到安全,是一个十分棘手的话题。这里只是作为学校Shiro的一个记录,而不是,权限就应该这样设计之类的。 Shiro框架 1、Shiro是基于Apache开源的强大灵活的开源...

冯文议
今天
1
0
linux 系统的运行级别

运行级别 运行级别 | 含义 0 关机 1 单用户模式,可以想象为windows 的安全模式,主要用于修复系统 2 不完全的命令模式,不含NFS服务 3 完全的命令行模式,就是标准的字符界面 4 系统保留 5 ...

Linux学习笔记
今天
2
0
学习设计模式——命令模式

任何模式的出现,都是为了解决一些特定的场景的耦合问题,以达到对修改封闭,对扩展开放的效果。命令模式也不例外: 命令模式是为了解决命令的请求者和命令的实现者之间的耦合关系。 解决了这...

江左煤郎
今天
3
0
字典树收集(非线程安全,后续做线程安全改进)

将500W个单词放进一个数据结构进行存储,然后进行快速比对,判断一个单词是不是这个500W单词之中的;来了一个单词前缀,给出500w个单词中有多少个单词是该前缀. 1、这个需求首先需要设计好数据结...

算法之名
昨天
15
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部