织云团队告诉你，故障过后如何全面地制定规避措施

作者简介：梁定安，腾讯织云负责人，腾讯运维技术总监，开放运维联盟委员，腾讯云布道师，腾讯学院DevOps讲师，EXIN DevOps Master讲师，凤凰项目沙盘教练，复旦大学客座讲师。

因LOL（英雄联盟）S7总决赛在线抢票玩家数量过多，硬是把独家线上售票机构的服务弄挂了，众多玩家表示很不开心。


官方也发文致歉广大的游戏玩家。

作为一名运维，看到这篇新闻时，我同感不开心。因为这个故障很有可能会导致某个运维小伙伴背黑锅，虽然我们都知道“冰封三尺非一日之寒”，酿成本次故障的原因绝不仅是运维岗的责任，但事与愿违的是，往往“受伤的”却总是运维岗。

Anyway，干得了这行我们就承受得住故障的暴击，但同时我们也要不断的用先进的理论知识来武装自己，提升运维团队的整体实力。让我们一起用DevOps视角来看下，故障发生后，我们如何能做到“引以为鉴，举一反三”制定有效的规避措施，保障类似的故障不再发生。

DevOps的文化精髓CALMS，可以为我们指引改进的方向。

• Culture（文化）- 是指拥抱变革，促进协作和沟通
• Automation（自动化）- 是指将人为干预的环节从价值链中消除。
• Lean（精益）- 是指通过使用精益原则促使高频率循环周期。
• Metrics（指标）- 是指衡量每一个环节，并通过数据来改进循环周期。
• Sharing（分享）- 是指与他人开放分享成功与失败的经验，并在错误中不断学习改进。

首先，DevOps是一种新的思维模式，我们不能以老观点来评判这次抢票的故障。Blameless是一个很关键的词，DevOps提出对待故障的正确方法，是不要责怪，不要罚钱，而是应该让团队在故障中学习和提高。这是Sharing的目标：分享责任、分享经验、分享信息、分享成功与失败，践行持续改善。

DevOps除了告诉我们要blameless要sharing，还有丰富的技术实践供我们参考学习。从IT价值链流转图中，我们能找到可以改进的点。

站在产品岗的角度，反思这次故障，可以尝试以下优化：

• 排队购票机制，从产品体验上引入先来后到的队列机制，可以降低突发大量的用户冲击技术架构。这种招数在社交的场景屡试不爽，如打地鼠抢红包。
• 预估业务量，产品经验有必要提前估算这次购票活动会带来的请求量规模，让技术团队能够有一定的依据来准备容量，可结合英雄联盟的热度和历史经验。
• 错峰预约策略，这是一种产品策略，把相当于把峰值提前打散。如双11的提前预约再抢购，红米手机在QQ空间的活动，先抢资格择日再买。

站在开发团队的角度，在提升架构的性能吞吐的同时，可以站在运维的角度为架构增加些非功能性的特性。

• 高性能web服务，结合分布式、消息队列、逻辑解耦等架构设计思路，提升接入层扛大并发的性能。
• 数据垂直切分，避免热点过度集中压垮DB。
• 自动拒绝服务，防止后台服务发生雪崩。
• 做好实时监控流数据的监控，让运维具备发现异常和响应处理的能力。
• 引入容器技术，让快速扩容具备条件。
• 预留柔性策略开关，以备不时之需。
• 合理选择路由服务，可结合zk实现服务自发现，或用名字服务代替IP直连。

站在测试团队的角度，在对业务逻辑验收完成的前提下，还要监督和保障所有非功能规范都能按要求实现。

• 验收非功能特性，保证应用在上线前，所有可运维性需求都被实现。
• 压测应用性能，把单机吞吐量告知运维，后者可合理的估算容量。
• 测试用例服务化，让运维有能力在完成应用部署后，自动化调用测试用例验证服务功能，以实现自动部署自动上线。

终于轮到运维团队的改进措施，不仅是针对此次抢票故障，运维务必有一套规范流程对业务的运营活动进行质量保障。

• 容量规划，根据业务活动的请求量和单机吞吐量，规划集群的容量，并保证备用buff设备能应对计划外的流量。
• 扩容能力，提高扩容的速度和质量，给开发的架构提建议，给测试的工具提需求，以建设运维自动化为目标。
• 容灾容错预案，调度、柔性的工具和策略要提前准备好，并时常演练，养兵千日用兵一时。
• 参数调优，web性能的优化与内核参数有关，找到最贴切的参数组合，在运维侧为架构优化助力。
• 防攻击能力，每次运营活动，都请保证所有请求的合法性，切勿因为安全问题导致服务不可用。
• 实时的监控与告警，确保在关键时刻你的眼睛没瞎，能在第一时间收到火警，将火苗扑灭。
• 与合作团队多沟通，重大的活动需要郑重对待，但首先得确保每个产品的重大活动都能够通知到运维团队。

综上对抢票故障的规避措施，要想整体提升企业IT能力，关靠个别团队的努力是不足够的，如DevOps方法论体系图描述的一样，我们需要结合精益、敏捷、持续交付、ITSM等理论和技术，为企业打造一个完整的DevOps文化与工具体系。

欢迎关注腾讯织云，获取最新技术资讯