第2页
微博平台护城河
构建高效的防御体系
@王关胜
构建高效的防御体系
@王关胜
第3页
大纲
微博平台业务介绍 平台防御体系框架设计 平台层实践 新浪故障管理
小结 & QA
微博平台业务介绍 平台防御体系框架设计 平台层实践 新浪故障管理
小结 & QA
第4页
1.微博平台业务介绍
用户 8亿注册用户 8000万+DAU 1.75亿MAU
系统 200+集群 3000+设备 日均6百亿Hits
运维 150ms-4个9 Docker：53% 变更：15次/周
用户 8亿注册用户 8000万+DAU 1.75亿MAU
系统 200+集群 3000+设备 日均6百亿Hits
运维 150ms-4个9 Docker：53% 变更：15次/周
第5页
2.面临的挑战
l
产品迭代快，变更多
l
技术改造多，业务依赖复杂
l
大型运营活动及三节保障
u 让红包飞，春晚大考
l
热门事件：最大30倍瞬间峰值
u #周一见# #且行切珍惜# #马航370# #刘翔摔倒#
l
日常不定时的Push
u 分类：应用内Push，应用外Push，运营及活动Push u 落地页：业务模块，如话题，热门微博 u 用户互动时间：<1h u 下发速度：快，中，慢 u 用户模型：全量，高中低频，地区，灰度模型（如尾号）
l
产品迭代快，变更多
l
技术改造多，业务依赖复杂
l
大型运营活动及三节保障
u 让红包飞，春晚大考
l
热门事件：最大30倍瞬间峰值
u #周一见# #且行切珍惜# #马航370# #刘翔摔倒#
l
日常不定时的Push
u 分类：应用内Push，应用外Push，运营及活动Push u 落地页：业务模块，如话题，热门微博 u 用户互动时间：<1h u 下发速度：快，中，慢 u 用户模型：全量，高中低频，地区，灰度模型（如尾号）
第6页
大纲
微博平台业务介绍 平台防御体系框架设计 平台层实践 新浪故障管理
小结 & QA
微博平台业务介绍 平台防御体系框架设计 平台层实践 新浪故障管理
小结 & QA
第7页
1.什么是防御体系
防御体系四要素
极简的架构 稳健的架构 美丽的架构
.简 .稳 .美 架构
监控
.快 .准 .全
性能好&冗余够 快速动态扩容 压测&容量预警
.够 容量 干预 .多 .动 .细 .警 .效
实时性&报警快 误报少&报警准 无遗漏&覆盖全
预案全&手段多 操作快&方案细 干预行之有效
防御体系四要素
极简的架构 稳健的架构 美丽的架构
.简 .稳 .美 架构
监控
.快 .准 .全
性能好&冗余够 快速动态扩容 压测&容量预警
.够 容量 干预 .多 .动 .细 .警 .效
实时性&报警快 误报少&报警准 无遗漏&覆盖全
预案全&手段多 操作快&方案细 干预行之有效
第8页
2.防御体系框架
架构
监控
容量
运维四化建设 运维数据接⼝口
规范业务⽇日志 全链路SLA
服务 快速 隔离 失败
防御标准化
Web Http MC(Q)
四层 七层
Processor RPC
资源层
MySQL Redis Hbase
平台架构
干预
分⼯工&职责&KPI 标准流程规范 定期巡检&演练 7x24⼩小时轮班
定期 知识 培训 管理
防御制度
架构
监控
容量
运维四化建设 运维数据接⼝口
规范业务⽇日志 全链路SLA
服务 快速 隔离 失败
防御标准化
Web Http MC(Q)
四层 七层
Processor RPC
资源层
MySQL Redis Hbase
平台架构
干预
分⼯工&职责&KPI 标准流程规范 定期巡检&演练 7x24⼩小时轮班
定期 知识 培训 管理
防御制度
第9页
大纲
微博平台业务介绍 平台防御体系框架设计 平台层实践 新浪故障管理
小结 & QA
微博平台业务介绍 平台防御体系框架设计 平台层实践 新浪故障管理
小结 & QA
第10页
1.防御架构设计之防单点
l
防单点
u 调用链路上避免单点
Ø 无状态：前端，队列处理，RPC支持503机制
u 线性扩容，平滑上下线，在线调整
Ø 业务代码层支持，运维只需改配置
u 核心资源设计为分层访问
缓存分级
Web L1 L1 L1 L1 10G 10G 10G 10G Master 10G 10G 10G 10G Slave
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
防单点
u 调用链路上避免单点
Ø 无状态：前端，队列处理，RPC支持503机制
u 线性扩容，平滑上下线，在线调整
Ø 业务代码层支持，运维只需改配置
u 核心资源设计为分层访问
缓存分级
Web L1 L1 L1 L1 10G 10G 10G 10G Master 10G 10G 10G 10G Slave
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
第11页
防御架构设计之隔离
l
隔离：80-20原则
u 业务层： Ø 基于SLA的快速失败 Ø 代码分层与服务化 Ø 异步解耦合
u 部署层： Ø 核心链路独立部署 Ø 多机房容灾
u 基础架构层： Ø 核心服务设备网络层隔离 Ø 交换机上联容灾
微博平台部署架构
隔离方法
多机房部署
核心服务独立域名，上下行分开 七层独立部署 核心服务独立服务池 Tomcat线程保护 快速失败 服务化及独立部署
核心资源独立部署 外部依赖异步解耦
l
隔离：80-20原则
u 业务层： Ø 基于SLA的快速失败 Ø 代码分层与服务化 Ø 异步解耦合
u 部署层： Ø 核心链路独立部署 Ø 多机房容灾
u 基础架构层： Ø 核心服务设备网络层隔离 Ø 交换机上联容灾
微博平台部署架构
隔离方法
多机房部署
核心服务独立域名，上下行分开 七层独立部署 核心服务独立服务池 Tomcat线程保护 快速失败 服务化及独立部署
核心资源独立部署 外部依赖异步解耦
第12页
防御架构设计之多机房实践
l
核心问题
u 机房间延时： 用户的请求应该在本机房内完成 u 专线质量 u 部署范围：
Ø 核心业务路径本地部署 Ø 依赖业务数据同步
u 数据异地多写：
Ø 部署业务消息化 Ø 多机房同步组件（MytriggerQ，WMB）
u 七层规则：非核心路径穿透北京 u 数据一致性 u 配置基础设施 u 技术改造对线上业务的影响
多机房组件
l
核心问题
u 机房间延时： 用户的请求应该在本机房内完成 u 专线质量 u 部署范围：
Ø 核心业务路径本地部署 Ø 依赖业务数据同步
u 数据异地多写：
Ø 部署业务消息化 Ø 多机房同步组件（MytriggerQ，WMB）
u 七层规则：非核心路径穿透北京 u 数据一致性 u 配置基础设施 u 技术改造对线上业务的影响
多机房组件
第13页
2.主动防御-监控体系
监控数据API
同比&环比 面积图 趋势 函数 警铃 邮件 短信 私信 WEB 移动APP Diy Dashboard 合并 联系人分组 报警配额
load cpu mem swap Net disk inode ping Io proc thread tcp_c
Message cs pgmf
基础资源
Nginx状态 Jvm & GC
线程 端口监控
应⽤用程序
集群单机健康状态 Profile & WatchMan 接口稳定性（99.95%） 资源线程池&分布耗时
业务监控
核心模块数据 资源层数据 业务层数据 部署层数据
运维数据
SinaWatch Jpool_agent Logtailer SinaScript 节点 新浪综合运维平台
监控数据API
同比&环比 面积图 趋势 函数 警铃 邮件 短信 私信 WEB 移动APP Diy Dashboard 合并 联系人分组 报警配额
load cpu mem swap Net disk inode ping Io proc thread tcp_c
Message cs pgmf
基础资源
Nginx状态 Jvm & GC
线程 端口监控
应⽤用程序
集群单机健康状态 Profile & WatchMan 接口稳定性（99.95%） 资源线程池&分布耗时
业务监控
核心模块数据 资源层数据 业务层数据 部署层数据
运维数据
SinaWatch Jpool_agent Logtailer SinaScript 节点 新浪综合运维平台
第14页
平台业务监控实践
l
业务日志标准化：profile.log
u 监控分类:
7大类
API
MC&MCQ MySQL依赖
SERVICE Redis依赖 Hbase依赖
资源层
HTTP依赖
u 指标项：API举例 C-‐计数 T-‐时间 单位：ms
指标 total_count slowThreshold slow_count
avg-time
ival1
说明 调用量 SLA 慢请求 平台耗时 <500
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 }
ival2
<500-‐1s>
ival3
<1s-‐2s>
ival4
<2s-‐4s>
ival5
> 4s
类型 C T C T C C C C C
l
业务日志标准化：profile.log
u 监控分类:
7大类
API
MC&MCQ MySQL依赖
SERVICE Redis依赖 Hbase依赖
资源层
HTTP依赖
u 指标项：API举例 C-‐计数 T-‐时间 单位：ms
指标 total_count slowThreshold slow_count
avg-time
ival1
说明 调用量 SLA 慢请求 平台耗时 <500
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 }
ival2
<500-‐1s>
ival3
<1s-‐2s>
ival4
<2s-‐4s>
ival5
> 4s
类型 C T C T C C C C C
第15页
业务监控方案
l
监控选型：Logtailer + Statsd + Graphite
l
Logtailer封装
基于Graphite的方案
u Python实现的agent
Logtailer
web
app
u 分布式1存储（一致性Hash） u 打包发送（UDP协议）
Statsd
u 本地Cache（10s）
l
Graphite优化
HAproxy
Nginx
u 高可用部署 u 接入Memcached
carbon-‐relay carbon-‐relay
graphite-‐web
u Whisper I/O优化（合并写）
l
监控数据量
u Metrics: Statshd: 100k/s Carbon:1800k/s u 指标项：1000+
carbon-‐cache whisper
carbon-‐cache whisper
carbon-‐cache whisper
u 报警：<300
l
监控选型：Logtailer + Statsd + Graphite
l
Logtailer封装
基于Graphite的方案
u Python实现的agent
Logtailer
web
app
u 分布式1存储（一致性Hash） u 打包发送（UDP协议）
Statsd
u 本地Cache（10s）
l
Graphite优化
HAproxy
Nginx
u 高可用部署 u 接入Memcached
carbon-‐relay carbon-‐relay
graphite-‐web
u Whisper I/O优化（合并写）
l
监控数据量
u Metrics: Statshd: 100k/s Carbon:1800k/s u 指标项：1000+
carbon-‐cache whisper
carbon-‐cache whisper
carbon-‐cache whisper
u 报警：<300
第16页
业务监控Dashboard
l
Graphite Dashboard
u 丰富的函数操作及聚合规则 u 定制用户自己的Dashboard u 移动端APP u 强大的接口
业务模块Dashboard
APP端Dashboard
APP端报警通知
l
Graphite Dashboard
u 丰富的函数操作及聚合规则 u 定制用户自己的Dashboard u 移动端APP u 强大的接口
业务模块Dashboard
APP端Dashboard
APP端报警通知
第17页
业务监控-完善方案
l
改进版业务监控
用户
4/7层
集群
部 署线
日志查询 报警平台 业务Dashboard Trace
依赖层
资源依赖 Http依赖
服务依赖 RPC
App log Jvm log
Sina Watch Sina Scripts
logstash StatsD
ElasticSearch Mfiter
Sina Atp
Kibana
日志查询 报警平台
Graphite
Dashboard
Spark Hbase
WatchMan
Trace UI
l
改进版业务监控
用户
4/7层
集群
部 署线
日志查询 报警平台 业务Dashboard Trace
依赖层
资源依赖 Http依赖
服务依赖 RPC
App log Jvm log
Sina Watch Sina Scripts
logstash StatsD
ElasticSearch Mfiter
Sina Atp
Kibana
日志查询 报警平台
Graphite
Dashboard
Spark Hbase
WatchMan
Trace UI
第18页
单机健康状态监控
l
集群单机健康状态监控
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%
接口平均耗时 <100ms 100-500ms
>5% >1s
u 实现方案
u 数据通道：agent(Python) -> SinaWatch ->API -> Dashboard u 健康状态判断：算法（区间权重 + 优先级 + 硬性指标） u 数据展示：异常的节点可获取异常数据
产品展示图
l
集群单机健康状态监控
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%
接口平均耗时 <100ms 100-500ms
>5% >1s
u 实现方案
u 数据通道：agent(Python) -> SinaWatch ->API -> Dashboard u 健康状态判断：算法（区间权重 + 优先级 + 硬性指标） u 数据展示：异常的节点可获取异常数据
产品展示图
第19页
3.主动防御-容量评估
l
平台容量评估实践
u压力测试方式：
Ø 单接口压测：模拟请求（http_load） Ø 单机压测：
ü 线上引流：Tcpcopy(放大/多台引至一台) ü 调整Nginx权重：平台自动化化压测系统
Ø 服务池压测：全链路压测
ü 机房间流量切换（核心服务） ü Nginx upstream自动变更
ps: 粒度：1/单IDC Nginx集群数量 Ø资源容灾与压测：Touchstone（基于tc）
u容量评估产出：
Ø 基于Python的自动化压测工具 Ø 水位预警工具 Ø 容量报表
集群容量数据一览图
l
平台容量评估实践
u压力测试方式：
Ø 单接口压测：模拟请求（http_load） Ø 单机压测：
ü 线上引流：Tcpcopy(放大/多台引至一台) ü 调整Nginx权重：平台自动化化压测系统
Ø 服务池压测：全链路压测
ü 机房间流量切换（核心服务） ü Nginx upstream自动变更
ps: 粒度：1/单IDC Nginx集群数量 Ø资源容灾与压测：Touchstone（基于tc）
u容量评估产出：
Ø 基于Python的自动化压测工具 Ø 水位预警工具 Ø 容量报表
集群容量数据一览图
第20页
4.主动防御-干预手段
l
有效的干预手段是快速解决问题&故障的基石
流程&制度
异常处理预案
定期循检
故障演练
干预手段
7x24小时轮班
重大事件响应
操作方案
重启/回滚/紧急上线
服务降级/封禁
快 流量切换
Docker机动池
慢 扩容
限流
数据修复
l
有效的干预手段是快速解决问题&故障的基石
流程&制度
异常处理预案
定期循检
故障演练
干预手段
7x24小时轮班
重大事件响应
操作方案
重启/回滚/紧急上线
服务降级/封禁
快 流量切换
Docker机动池
慢 扩容
限流
数据修复
第21页
应急预案-服务降级
l
预案：100+
u 日常&应急预案
u 重大活动，三节等预案手册
l
服务降级：5000+
u 原则：覆盖全，开关避免手输 u 方案：
Ø 业务代码框架层实现，动态修改运行时环境 Ø Tomcat监听端口，支持check/on/off/status Ø 集成运维工具系统 u 范围：
降级Web UI
l
预案：100+
u 日常&应急预案
u 重大活动，三节等预案手册
l
服务降级：5000+
u 原则：覆盖全，开关避免手输 u 方案：
Ø 业务代码框架层实现，动态修改运行时环境 Ø Tomcat监听端口，支持check/on/off/status Ø 集成运维工具系统 u 范围：
降级Web UI
第22页
大纲
微博平台业务介绍 平台防御体系框架设计 平台层实践 新浪故障管理
小结 & QA
微博平台业务介绍 平台防御体系框架设计 平台层实践 新浪故障管理
小结 & QA
第23页
1.新浪故障管理制度
l
组织形式
u 实体
Ø 故障管理组--跟进故障 Ø 业务方及运维核心人员--解决故障
u 虚拟：TDO-各部门专家
Ø 支持故障Review，深入挖掘故障本因
u 沟通方式：
Ø 在线：电话，QQ及群，其他IM Ø 通知：短信，邮件
l
管理制度
u 拥抱故障 u KPI--故障记分
Ø 运营KPI与产品良好的用户体验挂钩 Ø 处理故障能力与KPI挂钩
u 奖惩制度：
Ø 设立运维季度奖，涵盖面广 Ø 人为故障，责任到人，通告及罚钱
l
组织形式
u 实体
Ø 故障管理组--跟进故障 Ø 业务方及运维核心人员--解决故障
u 虚拟：TDO-各部门专家
Ø 支持故障Review，深入挖掘故障本因
u 沟通方式：
Ø 在线：电话，QQ及群，其他IM Ø 通知：短信，邮件
l
管理制度
u 拥抱故障 u KPI--故障记分
Ø 运营KPI与产品良好的用户体验挂钩 Ø 处理故障能力与KPI挂钩
u 奖惩制度：
Ø 设立运维季度奖，涵盖面广 Ø 人为故障，责任到人，通告及罚钱
第24页
2.新浪故障处理流程
•接收报障 •判断是否 为故障
接收
故障管理组流程
通知
•启动故障 通报流程
•跟进处理 进展
跟进
升级
•判断及启 动升级策 略
•确 认解决 •发 出恢复 通报
解决
后续
•故障讨论会 •发送报告 •跟进改进措施
运维&开发故障处理流程
•周知相关 领导及服 务台
•初步判断 问题并定 解决方案
•如有上线 及变更优 先回滚
•多方方案 并行推进
•以停止故 障影响为 目的
故障管理组主要工作
确认故 障现象
•与报障 来源部门 确认具体 现象
故障通 知
•第 一时间 通知主要 工程师及 TDO
•10分钟内 发出短信 及邮件
协调跟 进
•与TDO协 调相关部 门处理
•每30分钟 通报一次 进展
级别预 判升级
•技术方向 升级
•故 障管理 方向升级
•客服方向 升级
故障解 决
•确认故障 恢复
•5 分钟内 发出短信
•召开故障 讨论会
故障报 告
•第一版报 告故障4小 时后发
•故障报告 最终版2个 工作日内 发出
数据修复流程
•提交数据 修复变更 申请
•主管审批 并确定负 责人
•数据修复 方案 review
•周知各相 关方关注 服务
•实施数据 修复
•接收报障 •判断是否 为故障
接收
故障管理组流程
通知
•启动故障 通报流程
•跟进处理 进展
跟进
升级
•判断及启 动升级策 略
•确 认解决 •发 出恢复 通报
解决
后续
•故障讨论会 •发送报告 •跟进改进措施
运维&开发故障处理流程
•周知相关 领导及服 务台
•初步判断 问题并定 解决方案
•如有上线 及变更优 先回滚
•多方方案 并行推进
•以停止故 障影响为 目的
故障管理组主要工作
确认故 障现象
•与报障 来源部门 确认具体 现象
故障通 知
•第 一时间 通知主要 工程师及 TDO
•10分钟内 发出短信 及邮件
协调跟 进
•与TDO协 调相关部 门处理
•每30分钟 通报一次 进展
级别预 判升级
•技术方向 升级
•故 障管理 方向升级
•客服方向 升级
故障解 决
•确认故障 恢复
•5 分钟内 发出短信
•召开故障 讨论会
故障报 告
•第一版报 告故障4小 时后发
•故障报告 最终版2个 工作日内 发出
数据修复流程
•提交数据 修复变更 申请
•主管审批 并确定负 责人
•数据修复 方案 review
•周知各相 关方关注 服务
•实施数据 修复
第25页
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、影响微博功能
20% 2、影响服务时长
15% 3、影响用户范围
15% 4、用户投诉级别
10% 5、影响服务程度
10% 6、影响用户时段
故障评分
64.5
故障级别：
2 3 4 1 2 1 C级
故障故障报告单
故障描述 影响时长 发现途径 影响用户 责任部门
微博故障报告单（要点） 故障标题
所属产品线 开始时间 故障原因 影响用户数 责任人
影响功能 发现时间 根本原因 计算方法 故障分类
故障级别 恢复时间 触发原因 投诉情况 处理过程
改进措施
服务影响时长=服务恢复时间-故障开始时间
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、影响微博功能
20% 2、影响服务时长
15% 3、影响用户范围
15% 4、用户投诉级别
10% 5、影响服务程度
10% 6、影响用户时段
故障评分
64.5
故障级别：
2 3 4 1 2 1 C级
故障故障报告单
故障描述 影响时长 发现途径 影响用户 责任部门
微博故障报告单（要点） 故障标题
所属产品线 开始时间 故障原因 影响用户数 责任人
影响功能 发现时间 根本原因 计算方法 故障分类
故障级别 恢复时间 触发原因 投诉情况 处理过程
改进措施
服务影响时长=服务恢复时间-故障开始时间