司机教育稳定性突击加固

导读

本文介绍了把一个自运维服务突击升级为一级服务的过程。

背景

百川是司机教育体系的代号。该项目一直不温不火,SRE将其定位是 “接近业务自运维的服务”。824乐清顺风车杀人事件后,公司决定从9月13日起,所有司机出车前必须参加安全考试,考试不通过不允许出车。这样,百川 突然由边缘服务变成了主流程

实施

为了将百川建设到主流程级别的稳定性,SRE组织了为期一周的突击行动。基本行动步骤如下,

  1. 内部讨论:在SRE小组内对齐信息、统一认知,明确资源投入,确定接下来的支持计划
  2. 业务沟通:和研发同学协商制定稳定性突击计划,并任务分解
  3. 服务学习:了解业务逻辑,确定核心模块,建立一个基本的服务全景图
  4. 容量评估:了解容量现状,预估913峰值Qps,提前申请机器资源
  5. 依赖梳理:确定核心模块的上下游依赖,重点关注强依赖的SLA
  6. 监控建设:使用Odin日志监控,建设问题发现和定位能力
  7. 服务扩容:增加混部、提升核心模块容量,全量演练、备用资源随时可用于扩容
  8. 运维限流:梳理高耗时接口,约定接入层限流阈值和预案,并提前演练
  9. 业务降级:通过Apollo通道,为高耗时和主流程接口增加业务降级开关,并提前演练
  10. 压力测试:进行一次3倍于预估流量峰值的压测,峰值持续5分钟,直接压线上环境
  11. 灰度放量:正式上线前一天放量5%,验证服务的可用性和分批放量能力
  12. 上线值班:913凌晨全部放量,SRE在线值班,和研发一起共保服务稳定性
  13. 长期优化:和研发同学一起确认后续的改进事项,包括流程规范、性能优化、压测常态化、定位能力建设等

当然,上述部分事项是在工作进展中逐渐补全的。事后证明, 服务学习、监控建设、运维限流、业务降级、压力测试是最核心的几个环节

内部讨论

收到公司安全考试的决策后, SRE第一时间发起内部讨论 。参与人主要是SRE小组长、业务线SRE的AB角色成员,讨论的主要目标是 对齐信息、统一认知、明确资源投入等。讨论结论中最重要的一条是:尽快(当天)和业务组织一次面对面的沟通,进一步了解安全考试的业务详情。资源方面,SRE内部决定将百川安全考试项目做成一个专项来抓,短期内可以投入1个完整人力。

业务沟通

SRE内部沟通后, 当天和研发同学进行了面对面沟通 。研发同学同步了接下来的工作事项:安全考试是全新的产品需求,需要在7天内完成 产品需求沟通、上下游流程确认、新功能实现、链路压测等,短期内需求变更会比较频繁,接下来一周在北京封闭开发。SRE同步了稳定性突击建设的规划和任务分解,重点说明了需要研发同学支持的部分,说明了本周会投入1个人力帮助百川稳定性提升。

服务学习

在和业务面对面沟通的现场,SRE学习了安全考试的主流程,了解了流量处理的各个环节。特别的,安全考试是由司机出车来导流。为了不太影响司机出车,业务API团队对安全考试做了熔断处理(30ms不回执则跳过安全考试),正是这个熔断处理让百川的稳定性压力降低了一个数量级,这是后话。

在和业务面对面沟通的现场,还重新梳理了模块的服务等级,需要SRE高优保障的只有两个核心模块。

通过服务学习,确定了主流程、核心模块,建立了服务的全景图 ,让接下来的容量管理、依赖梳理、监控建设等有了明确的目标,SRE得以集中力量、做短时间突破。当然,后续通过对服务日志的学习,对服务全流程有了更深入细致的了解。

容量评估

资源申请流程长、耗时久,因此在完成服务学习后,首先启动扩容评估(而不是依赖梳理、监控建设等)。

根据安全考试的业务逻辑推算,百川的峰值Qps预计在300左右(这里使用了mock值)。为确保稳定性,按照1000的Qps来预估。由于没有历史参考,SRE很难预估需要扩容的机器数量。最后几乎是拍脑门决策:核心模块由原来的4实例相互混部到8台物理机(机器资源利用与不足10%),同时借用30台物理机备用(最后只借到了10台,但1台都没有被使用,尴尬的一逼)。

无法准确量化资源消耗时,申请尽量多的备用机器 ,这很可能是SRE的第一反应。此时,如果能全局共享备机池、同时提升资源借用的效率,由机器资源造成的成本压力也不会太大。当然,更应该做的是SRE消灭无法准确量化容量的问题根源。

依赖梳理

百川未接入metrics,业务日志较详细,因此,在研发童鞋无暇响应的情况下,SRE尝试 通过业务日志来快速梳理出服务的依赖方

通读两个核心模块的日志,共花费了3个小时的时间,产出了上下游依赖服务,及其黄金三指标提取方式。百川的依赖方主要有 mysql、redis、kafka、hbase、druid、hive、passport等,经业务确认只有 mysql、redis 是主流程的强依赖。之后,研发同学主动承担起了 mysql、redis 的容量评估和确认工作,SRE没有再花心思。

值得注意的是,从日志原文中提取黄金三指标的过程需要研发同学确认和配合,这个过程也是最耗时的部分。事前不做规范约定,事后再尝试沟通解决,这样的做法成本很高。

监控建设

这里的监控建设,主要指的是业务监控建设(基础监控开机即用,基本不用操心)。百川服务没有上报业务指标,SRE通过日志提取出业务的关键信息。

业务监控建设重点是上下游调用质量,通过黄金三指标来衡量 。按照重要程度,将上下游调用分为 主流程、重要接口、剩余接口三个等级。主流程公司级大盘(灭火图)全覆盖,对错误加一级报警、对延时加二级报警。重要接口Odin大盘覆盖,对错误和延时加三级报警。剩余接口暂不关注。

在后续的压力测试、限流演练、降级演练、灰度放量、全量接入环节,主流程占据了80%的关注度,主流程的报警功能也被一一验证。只在压力测试接近峰值、全量接入的第一个峰值时,重要接口才被给与了20%的关注度。

服务扩容

百川的扩容分为两部分:混部扩容和临时扩容。混部扩容,是将核心模块部署到较空闲的机器上,混部状态将常态化执行下去。百川之前的机器资源使用率较低,这是混部扩容的前提。临时扩容是为了应对新品上线造成的流量峰值,所使用的机器是临时借用的、不会常态化执行下去。实际上,我们只做了扩容演练、验证了临时资源的网络连通性,在压力测试证明现有资源足够之后,临时扩容就再未被执行过:-D

在服务扩容期间,遇到的基础环境不一致、白名单缺失等问题不下三次,SRE对扩容工具也很生疏,这些都严重降低了扩容救命的时效性 —— 在基础设施和工具平台不完善的情况下 没有经过全量演练的扩容预案基本都是自欺欺人 。好在我们抽出了足够的时间和耐心,在流量接入前三天完成了一次全量演练,并将扩容步骤固化到了wiki中。

运维限流

到目前(201809)为止, 运维限流是最有效的止损手段 ,没有之一。为了用好这个大杀器,我们按照如下步骤做了详细的准备:

  • 梳理高耗接口。按照最近一天的访问情况,梳理出 耗时最高 的top50接口
  • 确定限流入口。百川的服务,需要在router、intouer上同时限流。
  • 进行限流演练。在router、inrouter各抽取一个非核心接口,做一次完整的限流演练
  • 约定限流预案。SRE给出大概20个接口和阈值,容量不足时可以不经讨论、直接限流

当然,流量接入的当天服务容量完全足够,运维限流没有被执行。我们 优先选择耗时最高的接口做限流 ,原因是:高耗时接口对 mysql 等资源消耗最大、限流后效果最明显(这个结论不一定普适)。另外, 运维限流只能做到单机限流到1 (集群20台机器最小Qps是20),限流到0保命的需求只能交给业务降级来实现。

业务降级

SRE几乎没有参与百川的业务降级环节。一方面,业务降级基本是通过业务配置动态下发来实现的,SRE短时间绝无精通的可能。另一方面,降级通道Apollo是开放给研发同学自由使用的,研发同学甚至是SRE自己都不认为 SRE应该主导业务降级 。百川主要是因为第一个原因。

业务降级是重要的、灵活的止损手段之一, 对业务降级设计和实施的放任体现了SRE工作的失职 。近期已经发生了多次研发操作降级开关导致的故障,给稳定性工作带来了极大挑战。

压力测试

QA同学主导了百川新功能的压力测试,SRE表示喜闻乐见。在整个过程中,SRE协助理清压测目标、把控压测质量、给出改进建议,其他事项全部交由QA和研发同学来主导。美中不足的是,以百川为代表的java体系尚无完备的压测改造方案,本次压测时间紧只能直接压线上。

总体来说,QA对压力测试的实施更专业,SRE只需 把压测当成性能测试工具、用好即可。压力测试能够产出一个基本的容量预估,可以为服务扩容、运维限流、业务降级、监控报警等提供可靠的数据依据。

灰度放量

正式流量接入前,SRE给出灰度放量到10%的建议,这与产品侧的想法不谋而合。经历压测之后,大家对灰度放量没有太多的担心,一切进展顺利。

灰度放量主要是用来验证功能的正确性,是大面积故障的最后一道拦截保障。

上线值班

安全考试项目全量上线是在913凌晨05:00。SRE组织1个人力来值守,应对现场的稳定性突发事件。一切进行的很顺利,安全考试项目平稳度过了第一天。流量也正向我们预估的那样:峰值Qps达到了300左右(mock值),与司机出车持平。

全量上线前夕SRE和研发同学并没有就值班事宜进行协商,好在双方都是责任感爆棚、不约而同。如果能 提前沟通好值班计划,相信效果会更好。

总结

百川安全考试稳定性是一个典型的救火项目。在突击优化阶段,SRE更看重服务容量、故障发现、止损能力的建设,投入小、产出快。在长期优化阶段,服务性能优化、规范流程预防、定位能力建设、优雅止损手段等将会成为主要的着力点。



Prev     Next