导读
本文介绍了把一个自运维服务突击升级为一级服务的过程。
背景
百川是司机教育体系的代号。该项目一直不温不火，SRE将其定位是 “接近业务自运维的服务”。824乐清顺风车杀人事件后，公司决定从9月13日起，所有司机出车前必须参加安全考试，考试不通过不允许出车。这样，百川 突然由边缘服务变成了主流程 。
实施
为了将百川建设到主流程级别的稳定性，SRE组织了为期一周的突击行动。基本行动步骤如下，
- 内部讨论：在SRE小组内对齐信息、统一认知，明确资源投入，确定接下来的支持计划
- 业务沟通：和研发同学协商制定稳定性突击计划，并任务分解
- 服务学习：了解业务逻辑，确定核心模块，建立一个基本的服务全景图
- 容量评估：了解容量现状，预估913峰值Qps，提前申请机器资源
- 依赖梳理：确定核心模块的上下游依赖，重点关注强依赖的SLA
- 监控建设：使用Odin日志监控，建设问题发现和定位能力
- 服务扩容：增加混部、提升核心模块容量，全量演练、备用资源随时可用于扩容
- 运维限流：梳理高耗时接口，约定接入层限流阈值和预案，并提前演练
- 业务降级：通过Apollo通道，为高耗时和主流程接口增加业务降级开关，并提前演练
- 压力测试：进行一次3倍于预估流量峰值的压测，峰值持续5分钟，直接压线上环境
- 灰度放量：正式上线前一天放量5%，验证服务的可用性和分批放量能力
- 上线值班：913凌晨全部放量，SRE在线值班，和研发一起共保服务稳定性
- 长期优化：和研发同学一起确认后续的改进事项，包括流程规范、性能优化、压测常态化、定位能力建设等
当然，上述部分事项是在工作进展中逐渐补全的。事后证明， 服务学习、监控建设、运维限流、业务降级、压力测试是最核心的几个环节 。
内部讨论
收到公司安全考试的决策后， 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更看重服务容量、故障发现、止损能力的建设，投入小、产出快。在长期优化阶段，服务性能优化、规范流程预防、定位能力建设、优雅止损手段等将会成为主要的着力点。