新浪技术保障部运维架构师 王关胜 《构建高效的防御体系》

微博平台护城河构建高效的防御体系@王关胜微博平台业务介绍平台防御体系框架设计平台层实践新浪故障管理小结&QA大纲1.微博平台业务介绍用户8亿注册用户8000万+DAU1.75亿MAU系统200+集群3000+设备日均6百亿Hits运维99.99%Docker：53%变更：15次/周2.面临的挑战产品功能迭代快，系统变更及代码上线次数多突发的热点事件#周一见##且行切珍惜##马航370##刘翔摔倒#每日不定时段的Push内容业务上复杂的依赖关系基于微博的大型运营活动：让红包飞，随手拍…每年一度的三节保障&春晚大考3.突发流量峰值热门事件：最大30倍瞬间峰值微博，转发，评论，赞长微博话题典型案例：日常Push落地页：业务模块，如话题，热门微博下发速度：快，中，慢用户模型：全量，高中低频，地区，灰度模型（如尾号）用户互动时间：1h分类：应用内Push，应用外Push，运营及活动Push微博平台业务介绍平台防御体系框架设计平台层实践新浪故障管理小结&QA大纲1.什么是防御体系架构容量监控干预实时性&报警快误报少&报警准无遗漏&覆盖全防御体系四要素性能好&冗余够快速动态扩容压测&容量预警极简的架构稳健的架构美丽的架构预案全&手段多操作快&方案细干预行之有效.快.全.准.简.美.稳.多.效.细.够.警.动2.防御体系框架四层七层WebRPCProcessor规范业务日志HttpMC(Q)资源层MySQLRedisHbase平台架构运维四化建设全链路SLA运维数据接口分工&职责&KPI标准流程规范监控容量架构干预定期巡检&演练7x24小时轮班定期培训知识管理防御标准化防御制度服务隔离快速失败微博平台业务介绍平台防御体系框架设计平台层实践新浪故障管理小结&QA大纲1.防御架构设计之防单点防单点调用链路上避免单点无状态：前端，队列处理，RPC支持503机制线性扩容，平滑上下线，在线调整业务代码层支持，运维只需改配置核心资源设计为分层访问缓存分级10G10G10G10GMaster10G10G10G10GSlaveWebL1L1L1L1DB(1)selectoneofL1cache（includemaster）,getfromit(2)ifL1exist,return;ifnotexist,getfrommaster.(3)ifmasterexist,return,andsetL1;elseifnotexist,getfromslave(4)ifslaveexist,return,setmasterandL1;elseifnotexist,getfromdb(5)ifdbexist,return,setmaster,slaveandL1;elsethrowexception(6)ifhasnewdata(mcqprocess),updateallofL1,master,slave访问逻辑防御架构设计之隔离隔离：80-20原则业务层：基于SLA的快速失败代码分层与服务化异步解耦合部署层：核心链路独立部署多机房容灾基础架构层：核心服务设备网络层隔离交换机上联容灾微博平台部署架构多机房部署核心服务独立域名，上下行分开七层独立部署核心服务独立服务池Tomcat线程保护快速失败服务化及独立部署核心资源独立部署外部依赖异步解耦隔离方法防御架构设计之多机房实践核心问题机房间延时：用户的请求应该在本机房内完成专线质量部署范围：核心业务路径本地部署依赖业务数据同步数据异地多写：部署业务消息化多机房同步组件（MytriggerQ，WMB）七层规则：非核心路径穿透北京数据一致性配置基础设施技术改造对线上业务的影响多机房组件2.主动防御-监控体系新浪综合运维平台SinaWatchJpool_agentLogtailerSinaScript基础资源应用程序业务监控运维数据loadcpumemswapNetdiskinodepingIoprocthreadtcp_cMessagecspgmf端口监控线程Jvm&GCNginx状态资源线程池&分布耗时接口稳定性（99.95%）Profile&WatchMan集群单机健康状态部署层数据业务层数据资源层数据核心模块数据DiyDashboard移动APP联系人分组合并报警配额WEB警铃邮件短信私信同比&环比面积图趋势函数节点监控数据API平台业务监控实践业务日志标准化：profile.log监控分类:7大类指标项：API举例C-计数T-时间单位：ms指标total_countslowThresholdslow_countavg-timeival1ival2ival3ival4ival5说明调用量SLA慢请求平台耗时500500-1s1s-2s2s-4s4s类型CTCTCCCCC资源层APIMC&MCQMySQL依赖SERVICEHTTP依赖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}业务监控方案监控选型：Logtailer+Statsd+GraphiteLogtailer封装Python实现的agent分布式1存储（一致性Hash）打包发送（UDP协议）本地Cache（10s）Graphite优化高可用部署接入MemcachedWhisperI/O优化（合并写）监控数据量Metrics:Statshd:90k/sCarbon:1800k/s指标项：1000+报警：300LogtailerStatsdNginxHAproxycarbon-relaywhispercarbon-cachewhispercarbon-cachewhispercarbon-cachecarbon-relaygraphite-webwebapp基于Graphite的方案业务监控DashboardGraphiteDashboard丰富的函数操作及聚合规则定制用户自己的Dashboard移动端APP强大的接口业务模块DashboardAPP端DashboardAPP端报警通知业务监控-完善方案改进版业务监控集群ApplogJvmloglogstashKibanaElasticSearchStatsDMfiterGraphite资源依赖Http依赖服务依赖RPC依赖层4/7层SinaWatchSinaScriptsSinaAtp用户日志查询报警平台DashboardSparkHbaseWatchManTraceUI部署线日志查询报警平台业务DashboardTrace单机健康状态监控集群单机健康状态监控指标定义实现方案数据通道：agent(Python)-SinaWatch-API-Dashboard健康状态判断：算法（区间权重+优先级+硬性指标）数据展示：异常的节点可获取异常数据分类影响因素好-正常坏-亚健康糟糕-异常系统Load1212X2424Cpu_idle30%10%X30%10%Iowait20%20%X35%50%Swap500M1GX2G2G业务5xx错误比率1%1%x5%5%接口平均耗时100ms100-500ms1s产品展示图3.主动防御-容量评估平台容量评估实践压力测试方式：单接口压测：模拟请求（http_load）单机压测：线上引流：Tcpcopy(放大/多台引至一台)调整Nginx权重：平台自动化化压测系统服务池压测：全链路压测机房间流量切换（核心服务）Nginxupstream自动变更ps:粒度：1/单IDCNginx集群数量资源容灾与压测：Touchstone（基于tc）容量评估产出：基于Python的自动化压测工具水位预警工具容量报表集群容量数据一览图4.主动防御-干预手段有效的干预手段是快速解决问题&故障的基石异常处理预案重启/回滚/紧急上线服务降级/封禁流量切换干预手段限流Docker机动池数据修复快慢定期循检故障演练7x24小时轮班重大事件响应流程&制度操作方案扩容应急预案-服务降级预案：100+日常&应急预案重大活动，三节等预案手册服务降级：5000+原则：覆盖全，开关避免手输方案：业务代码框架层实现，动态修改运行时环境Tomcat监听端口，支持check/on/off/status集成运维工具系统范围：降级WebUI微博平台业务介绍平台防御体系框架设计平台层实践新浪故障管理小结&QA大纲1.新浪故障管理制度组织形式实体故障管理组--跟进故障业务方及运维核心人员--解决故障虚拟：TDO-各部门专家支持故障Review，深入挖掘故障本因沟通方式：在线：电话，QQ及群，其他IM通知：短信，邮件管理制度拥抱故障KPI--故障记分运营KPI与产品良好的用户体验挂钩处理故障能力与KPI挂钩奖惩制度：设立运维季度奖，涵盖面广人为故障，责任到人，通告及罚钱2.新浪故障处理流程•接收报障•判断是否为故障接收•启动故障通报流程通知•跟进处理进展跟进•判断及启动升级策略升级•确认解决•发出恢复通报解决•故障讨论会•发送报告•跟进改进措施后续故障管理组流程•与报障来源部门确认具体现象确认故障现象故障通知•与TDO协调相关部门处理•每30分钟通报一次进展协调跟进•技术方向升级•故障管理方向升级•客服方向升级级别预判升级•第一时间通知主要工程师及TDO•10分钟内发出短信及邮件•确认故障恢复•5分钟内发出短信•召开故障讨论会故障解决•第一版报告故障4小时后发•故障报告最终版2个工作日内发出故障报告故障管理组主要工作运维&开发故障处理流程数据修复流程•周知相关领导及服务台•初步判断问题并定解决方案•如有上线及变更优先回滚•多方方案并行推进•以停止故障影响为目的•提交数据修复变更申请•主管审批并确定负责人•数据修复方案review•周知各相关方关注服务•实施数据修复3.新浪故障报告故障定级级别：5级，E级为重要问题指标：6类，每类细化指标每个产品线指标不同，每类多级重要产品按功能模块划分多级，赋分公式：故障级别计算公式故障原因原则：每一个故障及问题追查本因分类：研发类和产品线分级：一级分类和二级分类一级分类：网络类局方故障应用软件硬件设备系统类人为因素微博故障定级规则A级：85分以上B级：71-84分C级：61-70分D级：41-60分E级：41及分以下（备案不发）权重值衡量指标衡量指标级别30%1、影响微博功能220%2、影响服务时长315%3、影响用户范围415%4、用户投诉级别110%5、影响服务程度210%6、影响用户时段1故障评分64.5故障级别：C级微博故障报告单（要点）故障标题故障描述所属产品线影响功能故障级别影响时长开始时间发现时间恢复时间发现途径故障原因根本原因触发原因影响用户影响用户数计算方法投诉情况责任部门责任人故障分类处理过程改进措施服务影响时长=服务恢复时间-故障开始时间故障定级规则故障故障报告单