AirJD 焦点
AirJD

没有录音文件
00:00/00:00
加收藏

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

发布者 devops
发布于 1435628842063  浏览 4015 关键词 DevOps, 网络安全 
分享到

第2页

微博平台护城河 

构建高效的防御体系

@王关胜
  
 



第3页

  大纲 

微博平台业务介绍 平台防御体系框架设计 平台层实践 新浪故障管理

小结 & QA 



第4页

1.微博平台业务介绍 



用户  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 用户模型:全量,高中低频,地区,灰度模型(如尾号) 



第6页

  大纲 

微博平台业务介绍 平台防御体系框架设计 平台层实践 新浪故障管理

小结 & QA 



第7页

1.什么是防御体系 

防御体系四要素



极简的架构  稳健的架构  美丽的架构 



.简  .稳  .美  架构 



监控 



.快  .准  .全 



性能好&冗余够  快速动态扩容  压测&容量预警 



.够  容量  干预  .多  .动  .细  .警  .效 



实时性&报警快  误报少&报警准  无遗漏&覆盖全 

预案全&手段多  操作快&方案细  干预行之有效 



第8页

2.防御体系框架 




 
 
 
 

架构 



监控 



容量 



运维四化建设 运维数据接⼝口

规范业务⽇日志 全链路SLA

服务 快速 隔离 失败

防御标准化 



Web Http MC(Q) 



四层 七层

Processor RPC

资源层

MySQL  Redis  Hbase 



平台架构 



干预 

分⼯工&职责&KPI 标准流程规范 定期巡检&演练 7x24⼩小时轮班

定期 知识 培训 管理

防御制度 



第9页

  大纲 

微博平台业务介绍 平台防御体系框架设计 平台层实践 新浪故障管理

小结 & 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 

  



第11页

防御架构设计之隔离 



l
 隔离:80-20原则 

u 业务层:  Ø 基于SLA的快速失败  Ø 代码分层与服务化  Ø 异步解耦合 

u 部署层:  Ø 核心链路独立部署  Ø 多机房容灾 

u 基础架构层:  Ø 核心服务设备网络层隔离  Ø 交换机上联容灾 



微博平台部署架构 



隔离方法 

多机房部署 

核心服务独立域名,上下行分开  七层独立部署  核心服务独立服务池  Tomcat线程保护  快速失败  服务化及独立部署 

核心资源独立部署  外部依赖异步解耦 



第12页

防御架构设计之多机房实践 



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 节点 新浪综合运维平台



第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 



第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 



第16页

业务监控Dashboard 



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 



第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 数据展示:异常的节点可获取异常数据 



产品展示图 



第19页

3.主动防御-容量评估 

l
平台容量评估实践 

u压力测试方式: 

Ø 单接口压测:模拟请求(http_load)  Ø 单机压测: 

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

Ø 服务池压测:全链路压测 

ü  机房间流量切换(核心服务)  ü  Nginx upstream自动变更 

                  ps:  粒度:1/单IDC Nginx集群数量  Ø资源容灾与压测:Touchstone(基于tc) 

u容量评估产出: 

Ø 基于Python的自动化压测工具  Ø 水位预警工具  Ø 容量报表   



集群容量数据一览图 



第20页

4.主动防御-干预手段 

l
 有效的干预手段是快速解决问题&故障的基石 

流程&制度 



异常处理预案
 



定期循检
 



故障演练
 



干预手段 



7x24小时轮班
 



重大事件响应
 



操作方案 

重启/回滚/紧急上线
  服务降级/封禁
  快 流量切换
  Docker机动池
 

慢 扩容
  限流
  数据修复
 



第21页

应急预案-服务降级 

l
 预案:100+ 

u 日常&应急预案 

u 重大活动,三节等预案手册 

l
 服务降级:5000+ 

u 原则:覆盖全,开关避免手输  u 方案: 

Ø 业务代码框架层实现,动态修改运行时环境  Ø Tomcat监听端口,支持check/on/off/status  Ø 集成运维工具系统  u 范围: 



降级Web UI 



第22页

  大纲 

微博平台业务介绍 平台防御体系框架设计 平台层实践 新浪故障管理

小结 & QA 



第23页

1.新浪故障管理制度 

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



•周知各相 关方关注 服务



•实施数据 修复



第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级 



故障故障报告单 



故障描述  影响时长  发现途径  影响用户  责任部门 



微博故障报告单(要点)  故障标题 



所属产品线  开始时间  故障原因  影响用户数  责任人 



影响功能  发现时间  根本原因  计算方法  故障分类 



故障级别 恢复时间 触发原因 投诉情况 处理过程



改进措施 



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



支持文件格式:*.ppt, *.pptx, *.pdf
上传最后阶段需要进行在线转换,可能需要1~2分钟,请耐心等待。