学而思高并发活动保障方案
导读：随着公司业务的不断扩张，尤其是在2020疫情开始后，整个在线教育行业的竞争变得异常严峻，作为这个行业的领路人，用户流量更是成倍增长，这就对我们在线业务运维体系的稳定性提出了更高的要求。
对此网校整体产研部每年寒、暑假都会针对性成立寒、暑特战队。特战队成员为各业务总接口人以及各专项总负责人，特战队成员共同目标为：保障寒、暑假期间百万学员同时稳定上课，无S0事故。
每个部门方向均需要输出负责人review过的保障方案，如需有风险，列出整改计划，这里我们从SRE视角对活动保障体系进行了系统性的梳理和总结，将好的沉淀总体分享给大家。
整体来看，保障大致分成三个阶段：重保前-重保中-重保后
重 保 前
01
架构高可用
1.架构设计的原则
N+1设计：系统中的每个组件都应做到没有单点故障；
回滚设计：确保系统可以向前兼容，在系统升级时应能有办法回滚版本；
禁用设计：应该提供控制具体功能是否可用的配置，在系统出现故障时能够快速下线功能；
监控设计：在设计阶段就要考虑监控的手段；
多活数据中心设计：若系统需要极高的高可用，应考虑在多地实施数据中心进行多活，至少在一个机房断电的情况下系统依然可用；
资源隔离设计：应避免单一业务占用全部资源；
架构应能水平扩展：系统只有做到能水平扩展，才能有效避免瓶颈问题。
2.狡兔双活架构设计总图
02
压测及容量保障
1.全链路接口压测
a.直播全场景压测试
场景业务说明：直播场景比较特殊 ，一个大的直播场景就是一堂课，而一堂课是由多个独立的互动场景构成，所以这里仅仅一个课中场景来整体覆盖，肯定是不能准确真实的找到系统的性能问题的。为了更贴近真实，覆盖的更加深入，我们将直播课中场景按照小的互动形式，再结合着接口依赖，拆分成13个小场景，然后逐一场景去进行压测。
b.平台全场景压测
场景业务说明：
2.监控大盘
监控加固
从物理层面（服务器资源）、服务层面（进程、日志、core）、数据层面（配置一致性、数据一致性）、业务层面（语义监控、访问时延、域名）4个维度进行监控的补全,便于重保当天进行实时监测
a.基础监控加固
做运维，不怕出问题，怕的是出了问题，抓不到现场，两眼摸黑。所以，依靠强大的监控系统，收集尽可能多的指标，意义重大。但哪些指标才是有意义的呢，本着从实践中来的思想，我们在长期摸爬滚打中总结了在系统运维过程中，经常会参考的一些指标，主要包括以下几个类别：
参考文献：https://book.open-falcon.org/zh_0_2/ faq/linux-metrics.html
b.网关集群QPS大屏
c.消息系统大屏
d.网校直播课堂业务监控大屏
3.容量管理
根据容量信息的确认，评估容量风险，如需扩容则安排资源协调和实例创建操作
a.基础容量评估
进行线上环境监控覆盖度检查，补齐缺失监控指标，保障线上环境容量监控的有效性;确保监控覆盖到全部资源/服务，报警功能是否正常;可按照以下性能和容量纬度（包含但不限于）：
用户体验、2.网络层、3.入口层、4.服务层、5.缓存层、6.数据层、7.三方调用
b.压测心得和注意事项
关注服务端
压测是为了找出瓶颈，这个瓶颈可以是cpu的性能（计算）、网络和磁盘（IO）性能等环境上的，也可以是程序的业务逻辑上的。不论如何，压测时一定要将服务端的硬件使用情况监控起来
关注客户端
压测时注意客户端的资源如cpu、带宽等是否已经到了上限，如果到了上限应该及时提升配置，或者做客户端集群（jmeter集群需要大量的带宽用来同步每个agent的压测结果，需要格外注意），最后，还要特别留意你的客户端脚本性能有没有问题
关注程序业务逻辑
对于业务程序，首先需要梳理接口的整体逻辑，比如在什么情况下进行了几次IO
善用排除法为结论背书
排除法也是压测过程中一个重要的手段，如果基本推断到某个地方非常影响性能，可以通过一些手段跳过这个地方的执行，看看性能是否能上来，以此证明你的结论
为你的想法背书，而非想当然
比如，对于网络——如果你认为你压测过程中使用的是HTTP长连接（keepalive），那么你关注服务端和客户端的各种状态的TCP连接数，确定真的是长连接；
比如，如果你认为硬件越多性能越高，那一定要通过压测证明一下，如，同时A压B，C压D，两个压测结果的和是不是单独A压B的两倍；
另外，有一些东西是公论则可以不必去费功夫，因为已经有很多人在很多文章中为你背书了——比如kafka的磁盘顺序写等。
确保压测环境不互相干扰
在云服务上压测，请确定你的服务器资源是独享型，否则压测基本没有什么意义
压测报告务必详细
压测报告不只是给别人看的，更是你自己的工作证明，要详细的罗列用到的硬件，什么环境，压测过程中各个指标的状态，在各种参数情况下程序的吞吐量，压测报告直接反应了一个人的能力，因为你能力越强，你看到的关键参数越多。
打个比方，从前我只关心cpu和内存，所以我做的压测报告里会有这些数据；后来我了解了HTTP长短连接的区别、网络等知识，报告内容有所增加；再后来我发现磁盘也会成为某些程序的瓶颈，磁盘IO也成了压测报告中的内容……
4.安全加固
主要针对外网攻击、注入等问题进行拦截防护；程序本身需要考虑这部分内容（可使用安全扫描进行review)、可以接入阿里云waf进行保护，能够使用https则尽量使用https。
03
放火演练及防护预案
1.放火演练
相信大家都碰到过大半夜被电话叫醒，开始紧张地查验问题，处理故障以及恢复服务的情况。也许就是因为睡前的一个很小的变更，因某种未预料到的场景，引起蝴蝶效应，导致大面积的系统混乱、故障和服务中断，对业务造成影响。尽管有充分的监控告警和故障处理流程，这样的情况仍时有耳闻。问题的症结便在于，对投入生产的复杂系统缺少了解和信心。监控告警和故障处理都是事后的响应与被动的应对，那有没有可能提前发现这些复杂系统的弱点呢？我们尝试通过一些常规故障演练方案以及历史case来进行相关系统放火演练操作，以达到逐步完善系统预案的过程
a.故障放火演练Checklist
b.演练注意事项
演练前：
QA推进RD补充完整每个case方案，完成方案梳理（演练记录），共同确定方案可行性和安全性。包括确定方案演练范围/sop/演练环境（线上、灰度）/预期/风险
准备演练需要数据，包括不限于功能验证课程数据、模拟用户流量的压测脚本&场景（小量即可）
故障平台上创建可执行故障case
对接哪些服务/场景/历史记录
在执行阶段是否需要qa去做验证
演练中：
晚 10:30 or 11:00，checklist；
执行故障，做好过程记录（开始时间、报警、恢复时间等截图、功能验证、存在什么异常问题、是否通过），完成方案梳理（演练记录）内的演练记录/是否通过/执行人一栏。
问题项记录，出现演练不符合预期问题，需记录在演练问题汇总，便于后续跟进定位和复盘。
演练后：
恢复验证，线上功能确保无恙。
更新当晚实施cheklist进度。
跟进需要复测的问题项。
2.混沌测试
a.什么是混沌
2008年8月，Netflix主要数据库的故障导致了三天的停机，DVD租赁业务中断，多个国家的大量用户受此影响。之后 Netflix 工程师着手寻找替代架构，并在2011年起，逐步将系统迁移到 AWS 上，运行基于微服务的新型分布式架构。这种架构消除了单点故障，但也引入了新的复杂性类型，需要更加可靠和容错的系统。为此， Netflix 工程师创建了 Chaos Monkey ，会随机终止在生产环境中运行的 EC2 实例。工程师可以快速了解他们正在构建的服务是否健壮，有足够的弹性，可以容忍计划外的故障。至此，混沌工程开始兴起。
Netflix 开发的 Chaos Monkey 成为了混沌工程的开端，但混沌工程不仅仅是 Chaos Monkey 这样一个随机终止 EC2 实例的实验工具。随后混沌工程师们发现，终止 EC2 实例只是其中一种实验场景。因此， Netflix 提出了 Simian Army 猴子军团工具集，除了 Chaos Monkey 外还包括：
Latency Monkey 在 RESTful 客户端到服务器通信中引入随机延迟，以模拟服务降级并测量上游服务是否正确响应。
Conformity Monkey 在发现不符合最佳实践的实例时将其关闭。
Doctor Monkey 会在每个实例中运行健康检查，同时也通过其他外部监控指标来检测不健康的实例。一旦检测到不健康的实例，将它们从服务中删除，并且在实例所有者找到问题的原因后终止。
Janitor Monkey 搜索未使用的资源并按规则处理，以确保AWS上的环境资源有效避免浪费。
Security Monkey 在发现安全违规或漏洞时，如发现未正确配置的AWS安全组，并终止使用该违规安全组的实例。此外，还会确保所有的 SSL 和 DRM 证书有效且无需续订。
10-18 Monkey （l10n-i18n）针对多个区域和国家的客户提供服务的实例，检查有关语言和字符集的配置。
Chaos Gorilla 模拟了 AWS 可用区域（AZ）的中断，以验证服务是否会自动平衡至可用的 AZ ，而无需人工干预，也不会给用户带来可见的影响。
参考文档：https://aws.amazon.com/cn/blogs /china/aws-chaos-engineering-start/
参考文档：https://github.com/dastergon/awe some-chaos-engineering
参考文档：https://cloud.tencent.com/develop er/article/1622874?from=article.detail.16472 76
参考文档：https://github.com/chaosbladeio /chaosblade/blob/master/README.md
b.为什么我们需要混沌
自从2011年Netflix开发了Chaos Monkey以来，这款软件变得越来越流行。如果想要构建一个分布式系统，就让Chaos Monkey来“糟蹋”这个集群，这样有助于构建出一个更具容错性、弹性和可靠性的系统。
通常情况下，我们会尽可能多地编写单元测试，确保能够覆盖所有的代码逻辑，也会进行足够多的集成测试，确保我们的系统可以与其他组件一起工作，还会执行性能测试，用以改进处理数百万次请求的性能。
然而，这些对于分布式系统来说还远远不够。无论我们做了多少单元测试、集成测试或性能测试，仍然无法保证我们的系统能够应对生产环境的各种不可预测性。我们可能会遇到磁盘故障、机器断电、网络隔离，而这些只是冰山一角。为了让分布式系统更加健壮，我们需要一种方法来模拟不可预知的故障，并测试我们对这些故障的反应。这就是为什么我们需要Chaos Monkey
c.关于混沌未来方向展望
目前混沌测试我们还停留在实验室环境阶段，引入此工具的目的就在于优化原有的故障植入方式，并扩展一些新的植入场景，如网关服务异常，mysql操作，网络异常，特定方法异常等。关于场景植入只是进行了初步设想，其中可能还存在一些细节考虑不够到位，但其实可以看到的是，随着我们性能保障能力的不断提升。我们可以很容易地想像出更多更有效、更智能的可能。
此工具目前的实验场景如下：
自测阶段的故障植入，在不需要变更真实逻辑的情况下，验证自己的异常处理；
组件在测试阶段，模拟底层依赖服务的故障场景，验证系统可用程度，降级方案是否生效等；
业务故障演练时，在不需要变更真实逻辑的情况下，可以人为模拟特定场景的故障异常，验证止损方案是否可是有效的
3.防护预案
a.预案加固
预案基本要求
一个预案对应一个具体的操作场景，解决一个具体的异常问题/故障，包含关键依赖、关键前置依赖及检查点、直接可执行操作步骤、直接可执行回滚步骤、结果验证。重要服务及场景，需要做到人的double check
触发条件需要明确、量化
预期影响是指执行预案过程中及之后的预期影响
结果验证checklist应该包括：动作、指标，通过指标判断是否符合预期
预案尽可能复用，触发条件可以有多个
预案执行过程需要尽可能自动化、高效
制定明确有效的3大预案
流量切换：制定实例间、机房间、地域间的流量切换预案，平台或脚本方式执行，可快速完成生效（要求至少分钟级别）；
服务降级：服务本身做到后台故障对于前端用户无感知，或服务功能降级以保证核心功能可以访问的机制，并且制定一键生效预案，可快速完成服务降级（要求分钟级别）；
快速扩容：服务架构有能力和资源可以在短时间内（要求至少30分钟内）完成快速的扩容操作，并且稳定可靠
网校预案现状
网校狡兔计划共分4个层面，总计整理并完成40余个具体预案
b.容灾加固
多实例建立：避免服务单点情况，改造成多实例（或主备）架构，避免单点故障的风险；多机房建立：建立至少2个机房的实例组，避免单机房故障的风险
04
变更管控
1.管控策略：
早7点-晚10点禁止线上操作
如需在晚10:00 - 早7:00之间进行线上操作
至少提前6小时在“【专项】寒假稳定性保障”群里报备，报备内容包括：操作事项、操作时间、影响范围；操作前请先确认直播在线人数（通过猫头鹰平台首页查看 https://cloud.tal.com/tal-beacon#/1/big-class），确保在线人数低于500人才能进行操作；
如需在早7点-晚10点之间紧急进行线上操作，需要部门N2邮件确认并抄送保障总负责小组成员确认。
2.管控期限：
7.01 - 8.25
重 保 中
01
人员值守
1.响应时间
值班人员必须实时关注核心报警以及问题反馈群；
非值班人员30分钟内必须响应。
周期：7.01 - 8.25
时段：早8:00~晚9:30
重点时段：早晨8:00~12:00 和17:30~9:30
2.值守内容
a. 出现异常时，暑假主值班人员推动拉专项群，拉相关人员：相关RD及leader ，相关QA及leader，相关PM及leader，客诉老师，危机老师等;
b.值班同学需要每天发送日报，同步当天出现的相关线上问题等。
3.值班准则
a.每日关注核心报警群中的报警信息，如有问题，及时和Rd一起确认问题；
b.每日关注核心核心监控大盘，确认是否有异常；
c.每日关注当天的课程场次，暑假保障群中同步“高危”场次以及时间节点；
d.每日确认下所有值班同学是否就位；
e.如有需要，暑假主值班可以临时调整其他值班人员需要关注的群。
02
异常处理
出现疑似故障时：
1. 问题跟进
a. 问题解决原则，先止损，再定位具体原因
故障止损，故障止损负责人负责故障的止损工作，以最快&最稳妥的方式进行恢复尝试和处理；当长时间无法止损时，需要第一时间反馈故障总负责人寻求帮助和方案；当故障止损时，第一时间反馈故障总负责人；
b. 主动和问题反馈人、RD、PM沟通，分析定位问题；
c. 尝试使用各个平台以及日志定位问题；
d. 基于以上结论尝试进行问题复现；
e. 引导相关人员在相关专项群沟通解决。
2.故障通告
故障总负责人负责定期对外进行通告（通告范围需要准确），接受所有外界对于故障的询问；几个关键时间节点必须要同步更新（故障处理进度、止损完成、恢复完成）；如果长时间到达不了下个时间节点，则需要至少1小时同步更新状态；
3.问题解决原则
a. 严重线上问题，必须当天完成，如无法当天修复，需要与相关RD，QA 达成一致；
b. 问题解决后，群里通知相关干系人以及故障总负责人，并同步问题解决结果；问题解决方案集中放到wiki存档记录；
4.根因追查
根因追查负责人负责故障的根因追查，确定彻底恢复的方案，第一时间反馈故障总负责人，由故障总负责人确认方案可行性并且安排人员进行方案执行；如果追查过程中需要任何资源，则第一时间反馈故障总负责人寻求帮助
重 保 后
01
问题记录、复盘总结
在日常运维过程中，出现故障等事故对于我们而言其实是一个很好的复盘学习机会。通过历史监控数据，分析事故其中的根本原因，制定后续应对策略，并且通过运维平台将这些应对策略编辑成标准化、可重用、自动化的运维应用场景，为后续相同问题的处理提供标准且快捷的解决方案。这正是事后回顾这个过程最真实的价值体现
复盘总结就是对于过去的一些服务异常和服务中断情况进行回顾和总结，以确保相同问题下次不会再出现。为了让大家团结协作，我们希望建立一种无指责、透明的事后文化。个人不应该害怕事故，而是确信如果事故发生，团队将会响应和改进系统
1.复盘的具体步骤
a.目标回顾、结果呈现；
b.复述过程、剖析原因；
c.发散思路、总结经验。
2.复盘时注意的几点
a.不计较个人得失，提升团队作战能力能力为前提；
b.敢于反思为什么，深入问题根部思考，开拓思路；
c.公布现有的结果，总结共享所获经验，提升下一次活动质量。
3.复盘落实
跟进历史case study的优化措施，按时落地，验收效果。
02
经验积累
从以往真实的case和历史水位等信息中分析重要数据，提炼出新的重保模式和特点，总结和沉淀一套重大活动保障方案。目的是：避免后续保障中有明显的缺失和遗漏，保障后续活动不出大的问题，同时按照方案指导，降低业务一些过度防护和重复工作。
1.SRE日常组件水位巡检记录存档
2.网关历史沉淀
3.消息历史沉淀
我知道你“在看”哟～