热点应急机制 假期准备 事前 事中 事后
从鹿晗关晓彤恋情事件看运维的节假日准备工作_个人文章 - SegmentFault 思否 https://beta.segmentfault.com/a/1190000011492068
从鹿晗关晓彤恋情事件看运维的节假日准备工作
作者：李雄政，10年+ 证券、电信、互联网领域开发、系统集成、运维经验。 现任腾讯高级工程师，负责社交平台业务运维组管理工作。
导语：鹿晗关晓彤公布恋情，造成微博服务短暂不可用。相关的运维们也不得不提前结束国庆假期，执行各种紧急扩容预案。 而腾讯SNG社交平台运维团队历经数次亿级热点活动，如“春节红包” “ 军装照P图”，他们又是如何应对每次的服务保障呢？
前言
又是一年国庆，10月8日12点，鹿晗在微博公布与关晓彤恋情，截至当日14:50, 该微博共收获462,884次转发、986,409条评论，2,566,617个点赞。造成微博服务短暂不可用。作为运维同行，对此深表同情和理解。
那么，面对这种突如其来的花式秀恩爱热点，作为运维的我们，该如何提前预防呢？腾讯的业务运维团队通常会从业务准备，容量评估，资源准备，扩容与压测四个阶段着手，配合热点应急机制，提前一个月进行节日保障准备。当然，还有对于海量业务的稳固运营至关重要的成熟的运维体系。这一切互相配合，最大化地保障节假日的运维工作有条不紊。
节假日保障
由于社交平台部产品众多，包含空间、微云、相册、P图等，业务运维团队一般会提前一个月进行节日准备，一般会包含以下几个阶段：
1) 业务准备
指标搜集
由业务运维团队牵头对产品进行梳理，由产品团队提供产品技术指标，如某功能上涨多少的业务量。这些业务产品团队的输入作为扩容需求的原始输入。
柔性准备
柔性是以应对大量业务量冲击时，以降低业务体验为代价而实施的一系列运维策略，如在业务高峰期降低客户端拉取后端数据的频率，从而减少对后端的冲击。
2) 容量评估
业务运维与相关开发进行业务指标 与业务模块对应关系适配，进一步评估设备量，通常评估模块设备量有以下几种办法：
反向评估： 结合业务上涨量倍数与当前单负载，计算出扩容的设备数量
公式为:扩容设备量 = （业务上涨倍数当前单机负载设备数量）/ 目标负载 – 当前设备量。
例如： 当前模块有10台设备，单机负载40%，目标负载80%， 业务量需要上涨3倍，需要扩容的设备量为： (340%10)/80% - 10 = 5台。
正向评估：需要有明确的高峰期交易量和单机承载指标。
公式为:扩容设备量 = (高峰期交易量 / 单机负载) – 当前设备量。
例如： 业务高峰期交易量为 8万/秒，单机最承载5千/秒，当前模块10 台设备，需要扩容的设备量为： 80000/5000 - 10 = 6台。
随着经验不断完善，自动容量评估工具也在不断建设与完善中。
3) 资源准备
评估的设备量提交资源团队进行准备。一般设备量不大的情况下会利用存量资源满足，反之则需要提前进行采购备货。
织云设备供给平台依托强力的织云IaaS接口对业务设备进行分配，上层业务只需选择对应地域、机房、机型，即可提供kvm，实体机，docker机型。分配过程对业务透明。
4) 扩容与压测
如前文所述，模块非常规范的情况下，织云能对其进行半自动/全自动扩缩容。扩容后进行压测，进一步确认是否能达到业务上涨的需求。
业务压测
通常业务多地SET化部署，每地各有一条读访问链，我们可以通过前端调度，将业务调度到单地SET，以评估单地SET的支撑能力。
单机压测
通过名字服务，将流量逐步调度到某一台机器，测量单机的业务支撑能力。从而推导模块设备能否支撑业务量。
扩容完成后，如果仍然存在短板，则重新补齐后进行压测。对于不可预见的突发热点，又该如何来保障业务呢？下面给大家介绍下突发热点容量管控机制。
热点应急机制
节假日难免会有一些突发的事件产生，如前所述，基于织云标准，我们的模块非常容易伸缩，可借助织云托管功能进行服务托管，模块出现容量紧缺时，提前进行自动扩容干预。如果由于资源等问题，自动扩容无法解决问题，可由运维启动柔性机制，保障业务可用。
节假日的运维准备工作，以上并不是全部，这背后还需要成熟的运维体系来支撑。
运维体系构成
一个成熟的运维体系通常包括三个部分：人员组织、工具体系和技术规范。三者随着业务的扩张而日益成熟。从组织上保障人员技能专业度与服务质量成熟度，良好的规范约束为组织协同、工具自动化提供了基础；工具解放生产力，提升运维效率，使人员成长更为专业。
技术运营团队组织架构
组织架构在随着业务形态在不断地演变，一般来说，互联网公司的组织架构演变会经历过几个转变期：
1）小团队混合期
一般在组织相对较小的时候，开发人员即运维人员。此阶段一般出现在10人以下的团队，但由于开发要兼做运维工作， 随着人员、业务的增长，容易造成组织混乱、团队效率、故障风险不可控等问题。
2）DO分离初期
此阶段运维开始从开发中分离出来，负责所有运维工作，如设备资源、环境、运维工具体系建设等。团队趋于扁平，但人员分工相对不明确。既管理机房、资源，又要管理运维工具、解决现网业务问题。随着业务的复杂性进一步增大，伴随人员流动性等问题，团队难以应对技术多样化场景，容易因为技术框架不统一而导致运维效率低下、组织运作混乱。从而对团队分工演进提出了更深的要求。
3）运维团队模块化、职业化
运维团队到了一定的规模后，运维设备数量达到数以万计或十万计，整体架构会分散自治，运维团队的分工因此需要更加细致明确。
团队分工没有标准或准则，典型的分工可能是这样的：
- 资源职能团队 - 负责设备资源采购、机房管理（或云上资源管理）、 操作系统层及以下的管理，跨部门运作以保障资源的调度及供应能力。
- 组件运维团队 – 负责各自的组件运维， 一般根据人员技能要求、组件响应SLA要求，可以划分成有状态(stateful)组件团队和无状态(stateless)组件团队。
因为无状态组件是水平可伸缩的，短暂单机故障并不会引起服务不可用，所以对业务服务SLA要求较低。该团队负责整个无状态服务框架及基于其承载的服务的运维工作。而由于有状态服务保存了业务数据，一般会对业务服务SLA要求较高，在单机故障时甚至需要运维及时介入检查或操作。
当然随着大型业务架构演进，自动化的增强，存储层实现故障自愈，我们的业务也实现多地部署，整体业务或模块粒度可进行多地切换容灾。内存型业务的服务SLA也可以相对放松，在这里先不细述。
- 业务运维团队 – 负责业务的整体运维，包括业务规划、架构部署、容灾演练、节假日保障等整体协作性工作。
比如业务的多地容灾部署架构，需要业务运维团队来牵头实施，以项目实施管理的形式将整个项目进行推进，以达到最终保障业务高可用的目的。
如上图所示，以上团队职责相对比较明确，运维工具的开发与健全贯穿在整个运维工作中，并逐步形成工具体系。
运维规范
庞大的业务体系运作，运维团队不可能随着业务的急剧增长而扩张，从而需要有一系列的规范来保证业务运维的有序运作。
传统行业的运维规范相对较为严格，包含以下内容：
- 运维操作SOP – 严格约定操作的步骤、甚至细化到命令操作等。
- 流程 – 一般指变更、故障处理的审批、确认流程，比较常见的规范有ITIL等。
- SLA/OLA协议 – 流程中Milestone点之间的时长或整体时长限制。因故障/变更等级不同而可能有所差异。
- 其他运维规范
而在互联网行业，过于僵硬的规范不易于满足快速迭代的业务需求，所以平时更需要关注现网运行规范，如织云体系中的几个常见规范：
1） 设备模块化、SET化管理理念
依据微服务的差异，将设备划分到不同的模块，多个模块可组成一个SET。这是织云管理设备的理念。
SET化后，一方面可以将模块间访问尽量限制在单地，防止跨城流量穿越而带来额外的流量开销，另一方面可以实现跨地域容灾，保障业务高可用。
2） 统一的包管理规范
统一的包安装、卸载、启停脚本名称，统一的配置文件管理（版本管理、创建、发放等）机制，以便上层管理系统能够统一对其进行管理。
3） 名字服务接入
业务间调用时，所有被调方IP对业务透明，只需要知道名字服务ID，而对被调方扩缩容时只需要通过名字服务管理系统管理名字服务后端的IP即可。杜绝IP写死在代码中或写死在配置文件中的现象。
4） 程序开发规范
这里的开发规范不是指代码规范，而是指通过一定时间的积累，形成的程序逻辑规范，以典型的无状态组件为例，我们从程序逻辑中剥离出来一套框架，框架上实现微线程处理、网络通信、监控等功能，而开发人员只需要根据业务逻辑开发 so 进行挂接即可。
运维工具体系架构
从而需要有一整套机制来规范，运维工具体系对规范进行支撑，总的来说，运维工具体系可以分为以下几个方面：支撑平台、监控、管理体系，我们统称为织云体系。
1） 支撑平台：
所有自动化工作开展的基石，运维体系中不可缺少的部分，包含但不限于以下组件：
CMDB配置管理平台，管理设备信息与模块属性、人员与被管设备/模块间运维关系，基本配置信息等。
自动化命令通道等，提供底层API在大批服务器上执行命令。
基础设施监控平台，如：基础设施运营事件发布、机房设施、服务器性能、故障监控系统等。
2） 监控系统
主动监控：一般采用从组件框架或业务代码埋点，或采用部署探针形式，上报业务数据到监控系统，监控系统进行集中监控。如：业务模块间调用监控、终端APM监控、手机命令字监控等。
被动监控：比较典型的是拨测系统，从内外网模拟客户端访问业务，对业务进行速度或成功率等测试，测试数据集中上报表监控系统，集中进行处理和监控。
旁路监控：在不接触业务本身的情况下对业务进行监控，比较典型的是舆情监控，对外网的舆情进行搜集，进行统一监控。
一切监控的基础是数据，但细粒度数据显然不可能直接让运维人员使用，基于以上数据产生的织云监控体系产品如： 多维监控、日志监控、全链路监控系统，都是一些非常重要的监控产品。
3） 标准化管理体系
支撑运维标准能严格执行的是一个成熟的管理体系，这个体系包括以下组成部分。
a) 标准化：
模块管理： 功能粒度上对服务器打散，形成许多独立的模块，每一个模块有自己的自治体系。
包管理，配置管理：规范开发人员按照标准来进行开发业务包。统一的包安装、卸载、启停、方法。集中式配置文件管理方法等。
标准化组件管控 - 名字服务、容错体系、存储层（内存型、TSSD、硬盘）等基础服务的管控工具。
b) 容量管理：
一系列的容量评估体系，支撑运维人员快速评估容量。为资源规划提供支撑，合理保障活动资源。
高低负载管理，扩缩容、单机负载权重调整、调度等。
c) 其他支撑工具：
为业务场景设计的工具, 如：运营事件管理、机房裁撤、智能调度、等工具。
后记
海量业务稳定运营的背后，一定有一套成熟的运维体系，需要从组织、规范、工具上进行不断演进、持续积累，才能在节（sa）假 (gou）日（liang）准备时有条不紊，做到有备而战，从而做到“高效运维”。
https://mp.weixin.qq.com/s/Ew9NfPtLZV-YW0eXY-2a5w
事前 事中 事后
国庆中秋佳节即将到来之至，为了你和你的家人欢乐渡过整个假期，做为一线的工（ban）程(zhuan)师.写了一篇工作心得希望能帮助大家。本文主要从事前、事中、事后，对人、资源、待办清单维度出发，供大家参考。欢迎大家与我交流和学习
— 事前—
人
云厂商和主管领导 是最为重要资源保障位，没有他们的保障做事起来比较畏首畏脚，跨部门协调问题速度
研发： 对自己应用负责
运维： 对整个的业务稳定性负责
云厂商：（云厂商是7*24*365无休的 只是这个时候保障及时性不是很高） 各个厂商都有护航计划费用比较高 大概总费用的5%-10%）
二线领导：遇到跨部门协调问题 需要领导统一安排指挥（非常重要）
资源
全链路压测评估资源的需求情况及资源需要扩容的情况。
特殊机型资源提前申请保障，就国庆这个假期临近中国电商双11、 资源紧张程度可想而知。提前半个月申请是非常有必要的
check list
-
确认资源位（机器、应用、人员、合理的压测评估）
-
是否需要值班人员（旅游买票等OTA跟假期关联性非常强的平台 请务必值班）
-
云厂商账上是否有充足的余额及DDOS防护资金
-
做合理常规的突发问题上 解决方案思路
-
确认封网时间（计划停止发布的时间）
— 事中—
人
运维 应用owner 二线领导协调
待办计划
-
正常的值班轮询 确认服务正常（核心以运维和应用owner为主）
-
遇到故障解决方案（简单处理故障流程）
— 事后—
人
一线运维及应用owner
待办计划
-
整理假期扩容的资源 进行合理的缩容
-
整理是否需要复盘的机器资源
-
庆功 耍花
-
整理不足的点 我们过年再会
国庆中秋佳节即将到来之至，为了你和你的家人欢乐渡过整个假期，做为一线的工（ban）程(zhuan)师.写了一篇工作心得希望能帮助大家。本文主要从事前、事中、事后，对人、资源、待办清单维度出发，供大家参考。欢迎大家与我交流和学习
— 事前—
人
云厂商和主管领导 是最为重要资源保障位，没有他们的保障做事起来比较畏首畏脚，跨部门协调问题速度
研发： 对自己应用负责
运维： 对整个的业务稳定性负责
云厂商：（云厂商是7*24*365无休的 只是这个时候保障及时性不是很高） 各个厂商都有护航计划费用比较高 大概总费用的5%-10%）
二线领导：遇到跨部门协调问题 需要领导统一安排指挥（非常重要）
资源
全链路压测评估资源的需求情况及资源需要扩容的情况。
特殊机型资源提前申请保障，就国庆这个假期临近中国电商双11、 资源紧张程度可想而知。提前半个月申请是非常有必要的
check list
-
确认资源位（机器、应用、人员、合理的压测评估）
-
是否需要值班人员（旅游买票等OTA跟假期关联性非常强的平台 请务必值班）
-
云厂商账上是否有充足的余额及DDOS防护资金
-
做合理常规的突发问题上 解决方案思路
-
确认封网时间（计划停止发布的时间）
— 事中—
人
运维 应用owner 二线领导协调
待办计划
-
正常的值班轮询 确认服务正常（核心以运维和应用owner为主）
-
遇到故障解决方案（简单处理故障流程）
-
