Wot2015 微博平台护城河-构建高效的防御体系-王关胜

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

微博平台业务介绍
平台防御体系框架设计
平台层实践
新浪故障管理
小结 & 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  用户模型：全量，高中低频，地区，灰度模型（如尾号）

1.什么是防御体系
架构
容量
监控
干预
实时性&报警快
误报少&报警准
无遗漏&覆盖全
防御体系四要素
性能好&冗余够
快速动态扩容
压测&容量预警
极简的架构
稳健的架构
美丽的架构
预案全&手段多
操作快&方案细
干预行之有效
.快
.全
.准
.简
.美
.稳
.多
.效
.细
.够
.警
.动

2.防御体系框架

四层
七层
Web
RPC
Processor
规范业务⽇日志
Http MC(Q)
资源层
MySQL Redis Hbase
平台架构
运维四化建设
全链路SLA
运维数据接⼝口
分⼯工&职责&KPI
标准流程规范
监控容量架构干预
定期巡检&演练
7x24⼩小时轮班
定期
培训
知识
管理
防御标准化防御制度
服务
隔离
快速
失败

1.防御架构设计之防单点
l  防单点
u  调用链路上避免单点
Ø  无状态：前端，队列处理，RPC支持503机制
u  线性扩容，平滑上下线，在线调整
Ø  业务代码层支持，运维只需改配置
u  核心资源设计为分层访问
缓存分级
10G10G 10G 10G Master
10G10G 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
NginxHAproxy
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

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级
微博故障报告单（要点）
故障标题
故障描述所属产品线影响功能故障级别
影响时长开始时间发现时间恢复时间
发现途径故障原因根本原因触发原因
影响用户影响用户数计算方法投诉情况
责任部门责任人故障分类处理过程
改进措施
服务影响时长=服务恢复时间-故障开始时间
故障定级规则故障故障报告单

Wot2015 微博平台护城河-构建高效的防御体系-王关胜

Wot2015 微博平台护城河-构建高效的防御体系-王关胜

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Wot2015 微博平台护城河-构建高效的防御体系-王关胜

Similar to Wot2015 微博平台护城河-构建高效的防御体系-王关胜 (20)

Recently uploaded

Recently uploaded (7)

Wot2015 微博平台护城河-构建高效的防御体系-王关胜