wot2015 微博平台护城河-构建高效的防御体系-王关胜
TRANSCRIPT
微博平台护城河 构建高效的防御体系
@王关胜
微博平台业务介绍
平台防御体系框架设计
平台层实践
新浪故障管理
小结 � & � 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级 �
微博故障报告单(要点) �
故障标题 �
故障描述 � 所属产品线 � 影响功能 � 故障级别
影响时长 � 开始时间 � 发现时间 � 恢复时间
发现途径 � 故障原因 � 根本原因 � 触发原因
影响用户 � 影响用户数 � 计算方法 � 投诉情况
责任部门 � 责任人 � 故障分类 � 处理过程
改进措施 �
服务影响时长=服务恢复时间-故障开始时间 �
故障定级规则 � 故障故障报告单 �