微博平台护城河  构建高效的防御体系

@王关胜    

微博平台业务介绍

平台防御体系框架设计

平台层实践

新浪故障管理

小结 � & � QA � 

�  � 大纲 � 

1.微博平台业务介绍 � 

用户 � 

8亿注册用户 � 

8000万+DAU � 

1.75亿MAU � 

系统 � 

200+集群 � 

3000+设备 � 

日均6百亿Hits � 

运维 � 

150ms-4个9 � 

Docker：53% � 

变更：15次/周 � 

2.面临的挑战 � 

� 

� 

l  产品迭代快，变更多 � l  技术改造多，业务依赖复杂 � l  大型运营活动及三节保障 � 

u  让红包飞，春晚大考 � 

l  热门事件：最大30倍瞬间峰值 � u  #周一见# � #且行切珍惜# � #马航370# � #刘翔摔倒# � 

l  日常不定时的Push � u  分类：应用内Push，应用外Push，运营及活动Push � u  落地页：业务模块，如话题，热门微博 � u  用户互动时间：<1h � u  下发速度：快，中，慢 � u  用户模型：全量，高中低频，地区，灰度模型（如尾号） � 

微博平台业务介绍

平台防御体系框架设计

平台层实践

新浪故障管理

小结 � & � QA � 

�  � 大纲 � 

1.什么是防御体系 � 

架构 � 

容量 � 

监控 � 

干预 � 

实时性&报警快 � 

误报少&报警准 � 

无遗漏&覆盖全 � 

防御体系四要素

性能好&冗余够 � 

快速动态扩容 � 

压测&容量预警 � 

极简的架构 � 

稳健的架构 � 

美丽的架构 � 

预案全&手段多 � 

操作快&方案细 � 

干预行之有效 � 

.快 � 

.全 � 

.准 � 

.简 � 

.美 � 

.稳 � 

.多 � 

.效 � 

.细 � 

.够 � 

.警 � 

.动 � 

2.防御体系框架 �         

四层七层

WebRPC

Processor规范业务⽇日志

Http MC(Q) � 

资源层MySQL �  Redis �  Hbase � 

平台架构 � 

运维四化建设

全链路SLA

运维数据接⼝口分⼯工&职责&KPI标准流程规范

监控 �  容量 � 架构 �  干预 � 

定期巡检&演练7x24⼩小时轮班定期培训

知识管理

防御标准化 �  防御制度 � 

服务隔离

快速失败

微博平台业务介绍

平台防御体系框架设计

平台层实践

新浪故障管理

小结 � & � QA � 

�  � 大纲 � 

1.防御架构设计之防单点 � l  防单点 � 

u  调用链路上避免单点 � Ø  � 无状态：前端，队列处理，RPC支持503机制 � 

u  线性扩容，平滑上下线，在线调整 � Ø  业务代码层支持，运维只需改配置 � 

u  核心资源设计为分层访问 � 

缓存分级 � 

10G 10G 10G 10G Master � 

10G 10G 10G 10G Slave � 

Web

L1 L1 L1 L1

DB

(1) �  � select � one � of � L1 � cache（include � master）,get � from � it �  � (2) �  � if � L1 � exist, � return; � if � not � exist,get � from � master. �  � (3) �  � if � master � exist, � return, � and � set � L1; � else � if � not � exist, � get � from � slave �  � (4) �  � if � slave � exist, � return,set � master � and � L1; �  � else � if � not � exist, � get � from � db � (5) �  � if � db � exist,return,set � master, � slave � and � L1; � else � throw � exception � (6) �  � if � has � new � data � (mcq � process), �  � update � all � of � L1, �  � master, � slave �  �  � 

访问逻辑 � 

防御架构设计之隔离 � l  隔离：80-20原则 � 

u  业务层： � 

Ø  基于SLA的快速失败 � 

Ø  代码分层与服务化 � 

Ø  异步解耦合 � 

u  部署层： � 

Ø  核心链路独立部署 � 

Ø  多机房容灾 � 

u  基础架构层： � 

Ø  核心服务设备网络层隔离 � 

Ø  交换机上联容灾 � 

微博平台部署架构 � 多机房部署 � 

核心服务独立域名，上下行分开 � 

七层独立部署 � 

核心服务独立服务池 � 

Tomcat线程保护 �  快速失败 � 

服务化及独立部署 � 

核心资源独立部署 � 

外部依赖异步解耦 � 

隔离方法 � 

防御架构设计之多机房实践 � l  核心问题 � 

u  机房间延时： � 用户的请求应该在本机房内完成 � 

u  专线质量 � 

u  部署范围： �  � Ø  核心业务路径本地部署 � 

Ø  依赖业务数据同步 � 

u  数据异地多写： � Ø  部署业务消息化 � 

Ø  多机房同步组件（MytriggerQ，WMB） � 

u  七层规则：非核心路径穿透北京 � 

u  数据一致性 � 

u  配置基础设施 � 

u  技术改造对线上业务的影响 � 

多机房组件 � 

2.主动防御-监控体系 � 

新浪综合运维平台SinaWatch Jpool_agent Logtailer SinaScript

基础资源 应⽤用程序 业务监控 运维数据

load � cpu � mem � swap � 

Net � disk � inode � ping � 

Io � proc � thread � tcp_c � 

Message � cs � pgmf �  端口监控 � 

线程 �  � 

Jvm � & � GC � 

Nginx状态 � 

资源线程池&分布耗时 � 

接口稳定性（99.95%） � 

Profile � & � WatchMan � 

集群单机健康状态 � 

部署层数据 � 

业务层数据 � 

资源层数据 � 

核心模块数据 � 

Diy � Dashboard � 移动APP �  联系人分组 � 合并 �  报警配额 � WEB � 

警铃 �  邮件 �  短信 �  私信 � 同比&环比 �  面积图 �  趋势 �  函数 � 

节点

监控数据API

平台业务监控实践 � l  业务日志标准化：profile.log � 

u 监控分类:  7大类    

 

 u 指标项：API举例 C-­‐计数 T-­‐时间 单位：ms       指标 �  total_count �  slowThreshold �  slow_count �  avg-time �  ival1 �  ival2 � 

� ival3 �  ival4 �  ival5 � 

� 

说明 �  调用量 �  SLA �  慢请求 �  平台耗时 �  <500 �  <500-­‐1s>  

� <1s-­‐2s>  

� <2s-­‐4s>  

� > 4s  

� 类型 �  C �  T �  C �  T �  C �  C �  C �  C �  C � 

资源层 � 

API � 

MC&MCQ �  MySQL依赖 � SERVICE � 

HTTP依赖 � 

Hbase依赖 � Redis依赖 � 

API日志样例： � { � "type":"API", � "name":"/statuses/friends_timeline", � "slowThreshold":0, � "total_count":0, � "slow_count":0, � "avg_time":"00.00", � "interval1":0, � "interval2":0, � "interval3":0, � "interval4":0, � "interval5":0 � } � 

业务监控方案 � l  监控选型：Logtailer � + � Statsd � + � Graphite � l  Logtailer封装 � 

u  Python实现的agent � 

u  分布式1存储（一致性Hash） � 

u  打包发送（UDP协议） � 

u  本地Cache（10s） � 

l  Graphite优化 � u  高可用部署 � 

u  接入Memcached � 

u  Whisper � I/O优化（合并写） � 

l  监控数据量 �  � u  Metrics: � Statshd: � 100k/s � Carbon:1800k/s � 

u  指标项：1000+ �  � 

u  报警：<300 � 

Logtailer

Statsd

Nginx HAproxy

carbon-­‐relay

whisper

carbon-­‐cache

whisper

carbon-­‐cache

whisper

carbon-­‐cache

carbon-­‐relay graphite-­‐web

web app

基于Graphite的方案 � 

业务监控Dashboard � l  Graphite � Dashboard �  �  � 

u  丰富的函数操作及聚合规则 � 

u  定制用户自己的Dashboard � 

u  移动端APP � 

u  强大的接口 � 

� 

� 

� 

业务模块Dashboard � 

APP端Dashboard �  APP端报警通知 � 

业务监控-完善方案 � l  改进版业务监控 �  �  � 

� 

� 

� 

� 

� 

集群 � App � log �  � 

Jvm � log � logstash �  Kibana � ElasticSearch � 

StatsD �  Mfiter � 

Graphite � 

资源依赖 �  �  Http依赖 �  � 

服务依赖 �  �  RPC �  � 

依赖层 � 

4/7层 � 

Sina � Watch �  � 

Sina � Scripts �  Sina � Atp � 

用户 � 

日志查询 � 

报警平台 � 

Dashboard � 

Spark �  Hbase �  WatchMan �  Trace � UI � 

部署线 � 

日志查询 � 

报警平台 � 

业务Dashboard � 

Trace � 

单机健康状态监控 � l  集群单机健康状态监控 � 

u  指标定义 �  � 

� 

u  实现方案 � u  数据通道：agent(Python) � -> � SinaWatch � ->API � -> � Dashboard � 

u  健康状态判断：算法（区间权重 � + � 优先级 � + � 硬性指标） � 

u  数据展示：异常的节点可获取异常数据 � 

分类 �  影响因素 �  好-正常 �  坏-亚健康 �  糟糕-异常 � 

系统 �  Load �  <12 �  12<X<24 �  >24 � 

Cpu_idle �  <30% �  10%<X<30% �  <10% � 

Iowait �  <20% �  20%<X<35% �  >50% � 

Swap �  <500M �  1G<X<2G �  >2G � 

业务 �  5xx错误比率 �  <1% �  1%<x<5% �  �  >5% � 

接口平均耗时 �  <100ms �  100-500ms �  >1s � 

产品展示图 � 

3.主动防御-容量评估 � l 平台容量评估实践 � 

u 压力测试方式： � Ø  � 单接口压测：模拟请求（http_load） � Ø  � 单机压测： � 

ü 线上引流：Tcpcopy(放大/多台引至一台) � ü 调整Nginx权重：平台自动化化压测系统 �  �  � 

Ø  � 服务池压测：全链路压测 � ü  � 机房间流量切换（核心服务） � ü  � Nginx � upstream自动变更 � 

�  �  �  �  �  �  �  �  �  �  �  �  �  �  �  �  �  � ps: �  � 粒度：1/单IDC � Nginx集群数量 � Ø 资源容灾与压测：Touchstone（基于tc） � 

u 容量评估产出： � Ø  基于Python的自动化压测工具 � Ø  水位预警工具 � Ø  容量报表 �  � 

集群容量数据一览图 � 

4.主动防御-干预手段 � l  有效的干预手段是快速解决问题&故障的基石 � 

异常处理预案   重启/回滚/紧急上线  

服务降级/封禁  

流量切换  

干预手段 � 

限流  

Docker机动池  

数据修复  

快

慢

定期循检  

故障演练  

7x24小时轮班  

重大事件响应  

流程&制度 �  操作方案 � 

扩容  

应急预案-服务降级 � l  预案：100+ � 

u  日常&应急预案 � u  重大活动，三节等预案手册 � 

l  服务降级：5000+ � u  原则：覆盖全，开关避免手输 � 

u  方案： � 

Ø  业务代码框架层实现，动态修改运行时环境 � 

Ø  Tomcat监听端口，支持check/on/off/status � 

Ø  集成运维工具系统 � 

u  范围： � 

降级Web � UI � 

微博平台业务介绍

平台防御体系框架设计

平台层实践

新浪故障管理

小结 � & � QA � 

�  � 大纲 � 

1.新浪故障管理制度 � l  组织形式 � 

u  实体 � Ø  故障管理组--跟进故障 � 

Ø  业务方及运维核心人员--解决故障 � 

u  虚拟：TDO-各部门专家 � 

Ø  支持故障Review，深入挖掘故障本因 � 

u  沟通方式： � 

Ø  在线：电话，QQ及群，其他IM � 

Ø  通知：短信，邮件 � 

l  管理制度 � u  拥抱故障 � 

u  KPI--故障记分 � Ø  运营KPI与产品良好的用户体验挂钩 � 

Ø  处理故障能力与KPI挂钩 � 

u  奖惩制度： � 

Ø  设立运维季度奖，涵盖面广 � 

Ø  人为故障，责任到人，通告及罚钱 � 

2.新浪故障处理流程 � 

• 接收报障 • 判断是否为故障

接收

• 启动故障通报流程

通知 • 跟进处理进展

跟进

• 判断及启动升级策略

升级 • 确认解决 • 发出恢复通报

解决

• 故障讨论会 • 发送报告

• 跟进改进措施

后续

故障管理组流程 � 

• 与报障来源部门确认具体现象

确认故障现象

故障通知

• 与TDO协调相关部门处理

• 每30分钟通报一次进展

协调跟进

• 技术方向升级

• 故障管理方向升级

• 客服方向升级

级别预判升级

• 第一时间通知主要工程师及TDO

• 10分钟内发出短信及邮件

• 确认故障恢复

• 5分钟内发出短信

• 召开故障讨论会

故障解决

• 第一版报告故障4小时后发

• 故障报告最终版2个工作日内发出

故障报告

故障管理组主要工作 � 

运维&开发故障处理流程 � 

数据修复流程 � 

• 周知相关领导及服务台

• 初步判断问题并定解决方案

• 如有上线及变更优先回滚

• 多方方案并行推进

• 以停止故障影响为目的

• 提交数据修复变更申请

• 主管审批并确定负责人

• 数据修复方案review

• 周知各相关方关注服务

• 实施数据修复

3.新浪故障报告 � l  故障定级 � 

u  级别：5级，E级为重要问题 � 

u  指标：6类，每类细化指标 � 

Ø  每个产品线指标不同，每类多级 � 

Ø  重要产品按功能模块划分多级，赋分 � 

u  公式：故障级别计算公式 � 

l  故障原因 � u  原则：每一个故障及问题追查本因 � 

u  分类：研发类和产品线 � 

u  分级：一级分类和二级分类 � 

Ø  一级分类： � 

²  网络类 � 

²  局方故障 � 

²  应用软件 � 

²  硬件设备 � 

²  系统类 � 

²  人为因素 � 

微博故障定级规则 � 

A级：85分以上 � 

B级：71-84分 � 

C级：61-70分 � 

D级：41-60分 � 

E级：41及分以下（备案不发） � 

权重值 �  衡量指标 �  衡量指标级别 � 

30% �  1、影响微博功能 �  2 � 

20% �  2、影响服务时长 �  3 � 

15% �  3、影响用户范围 �  4 � 

15% �  4、用户投诉级别 �  1 � 

10% �  5、影响服务程度 �  2 � 

10% �  6、影响用户时段 �  1 � 

故障评分 �  64.5 �  故障级别： �  C级 � 

微博故障报告单（要点） � 

故障标题 � 

故障描述 �  所属产品线 �  影响功能 �  故障级别

影响时长 �  开始时间 �  发现时间 �  恢复时间

发现途径 �  故障原因 �  根本原因 �  触发原因

影响用户 �  影响用户数 �  计算方法 �  投诉情况

责任部门 �  责任人 �  故障分类 �  处理过程

改进措施 � 

服务影响时长=服务恢复时间-故障开始时间 � 

故障定级规则 �  故障故障报告单 �