狠狠撸

狠狠撸Share a Scribd company logo

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

?
?
Weibo Corporation
Weibo Corporation

新浪微博自11年开始平台化之后，重心后移，计算与存储均移向后端平台。由于微博公开，即时，传播快，互动性等特性，每当遇到明星等公众热点事件，内部笔耻蝉丑，叁节，大型活动“让红包飞”等时，微博在核心功能方面总会面临着巨大的挑战，要建立完备的技术保障方案，都离不开一套完整的防御体系。本次主题主要讨论微博平台在近3年来，随着架构的迁移，在稳定性的基础上建立起来的防御体系

1 of 26
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?? 用户模型：全量，高中低频，地区，灰度模型（如尾号） ?
微博平台业务介绍 平台防御体系框架设计 平台层实践 新浪故障管理 小结 ?& ?QA ? ? ?大纲 ?
1.什么是防御体系 ? 架构 ? 容量 ? 监控 ? 干预 ? 实时性&报警快 ? 误报少&报警准 ? 无遗漏&覆盖全 ? 防御体系四要素 性能好&冗余够 ? 快速动态扩容 ? 压测&容量预警 ? 极简的架构 ? 稳健的架构 ? 美丽的架构 ? 预案全&手段多 ? 操作快&方案细 ? 干预行之有效 ? .快 ? .全 ? .准 ? .简 ? .美 ? .稳 ? .多 ? .效 ? .细 ? .够 ? .警 ? .动 ?
2.防御体系框架 ? ? ? ? ? 四层 七层 Web RPC Processor 规范业务?日志 Http MC(Q) ? 资源层 MySQL ? Redis ? Hbase ? 平台架构 ? 运维四化建设 全链路SLA 运维数据接?口 分?工&职责&KPI 标准流程规范 监控 ? 容量 ?架构 ? 干预 ? 定期巡检&演练 7x24?小时轮班 定期 培训 知识 管理 防御标准化 ? 防御制度 ? 服务 隔离 快速 失败
微博平台业务介绍 平台防御体系框架设计 平台层实践 新浪故障管理 小结 ?& ?QA ? ? ?大纲 ?
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 ?
微博平台业务介绍 平台防御体系框架设计 平台层实践 新浪故障管理 小结 ?& ?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级 ? 微博故障报告单（要点） ? 故障标题 ? 故障描述 ? 所属产物线 ? 影响功能 ? 故障级别 影响时长 ? 开始时间 ? 发现时间 ? 恢复时间 发现途径 ? 故障原因 ? 根本原因 ? 触发原因 影响用户 ? 影响用户数 ? 计算方法 ? 投诉情况 责任部门 ? 责任人 ? 故障分类 ? 处理过程 改进措施 ? 服务影响时长=服务恢复时间-故障开始时间 ? 故障定级规则 ? 故障故障报告单 ?
Wot2015 微博平台护城河-构建高效的防御体系-王关胜

More Related Content

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

  • 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?? 用户模型：全量，高中低频，地区，灰度模型（如尾号） ?
  • 7. 1.什么是防御体系 ? 架构 ? 容量 ? 监控 ? 干预 ? 实时性&报警快 ? 误报少&报警准 ? 无遗漏&覆盖全 ? 防御体系四要素 性能好&冗余够 ? 快速动态扩容 ? 压测&容量预警 ? 极简的架构 ? 稳健的架构 ? 美丽的架构 ? 预案全&手段多 ? 操作快&方案细 ? 干预行之有效 ? .快 ? .全 ? .准 ? .简 ? .美 ? .稳 ? .多 ? .效 ? .细 ? .够 ? .警 ? .动 ?
  • 8. 2.防御体系框架 ? ? ? ? ? 四层 七层 Web RPC Processor 规范业务?日志 Http MC(Q) ? 资源层 MySQL ? Redis ? Hbase ? 平台架构 ? 运维四化建设 全链路SLA 运维数据接?口 分?工&职责&KPI 标准流程规范 监控 ? 容量 ?架构 ? 干预 ? 定期巡检&演练 7x24?小时轮班 定期 培训 知识 管理 防御标准化 ? 防御制度 ? 服务 隔离 快速 失败
  • 10. 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 ? ? ? 访问逻辑 ?
  • 11. 防御架构设计之隔离 ? l?? 隔离：80-20原则 ? u?? 业务层： ? ??? 基于SLA的快速失败 ? ??? 代码分层与服务化 ? ??? 异步解耦合 ? u?? 部署层： ? ??? 核心链路独立部署 ? ??? 多机房容灾 ? u?? 基础架构层： ? ??? 核心服务设备网络层隔离 ? ??? 交换机上联容灾 ? 微博平台部署架构 ? 多机房部署 ? 核心服务独立域名，上下行分开 ? 七层独立部署 ? 核心服务独立服务池 ? Tomcat线程保护 ? 快速失败 ? 服务化及独立部署 ? 核心资源独立部署 ? 外部依赖异步解耦 ? 隔离方法 ?
  • 12. 防御架构设计之多机房实践 ? l?? 核心问题 ? u?? 机房间延时： ?用户的请求应该在本机房内完成 ? u?? 专线质量 ? u?? 部署范围： ? ? ??? 核心业务路径本地部署 ? ??? 依赖业务数据同步 ? u?? 数据异地多写： ? ??? 部署业务消息化 ? ??? 多机房同步组件（MytriggerQ，WMB） ? u?? 七层规则：非核心路径穿透北京 ? u?? 数据一致性 ? u?? 配置基础设施 ? u?? 技术改造对线上业务的影响 ? 多机房组件 ?
  • 13. 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
  • 14. 平台业务监控实践 ? 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 ? } ?
  • 15. 业务监控方案 ? 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的方案 ?
  • 16. 业务监控Dashboard ? l?? Graphite ?Dashboard ? ? ? u?? 丰富的函数操作及聚合规则 ? u?? 定制用户自己的Dashboard ? u?? 移动端APP ? u?? 强大的接口 ? ? ? ? 业务模块Dashboard ? APP端Dashboard ? APP端报警通知 ?
  • 17. 业务监控-完善方案 ? 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 ?
  • 18. 单机健康状态监控 ? 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 ? 产物展示图 ?
  • 19. 3.主动防御-容量评估 ? l??平台容量评估实践 ? u??压力测试方式： ? ??? ?单接口压测：模拟请求（http_load） ? ??? ?单机压测： ? ü?? 线上引流：Tcpcopy(放大/多台引至一台) ? ü?? 调整Nginx权重：平台自动化化压测系统 ? ? ? ??? ?服务池压测：全链路压测 ? ü?? ?机房间流量切换（核心服务） ? ü?? ?Nginx ?upstream自动变更 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?ps: ? ?粒度：1/单IDC ?Nginx集群数量 ? ???资源容灾与压测：Touchstone（基于tc） ? u??容量评估产出： ? ??? 基于Python的自动化压测工具 ? ??? 水位预警工具 ? ??? 容量报表 ? ? 集群容量数据一览图 ?
  • 20. 4.主动防御-干预手段 ? l?? 有效的干预手段是快速解决问题&故障的基石 ? 异常处理预案 ? 重启/回滚/紧急上线 ? 服务降级/封禁 ? 流量切换 ? 干预手段 ? 限流 ? Docker机动池 ? 数据修复 ? 快 慢 定期循检 ? 故障演练 ? 7x24小时轮班 ? 重大事件响应 ? 流程&制度 ? 操作方案 ? 扩容 ?
  • 21. 应急预案-服务降级 ? l?? 预案：100+ ? u?? 日常&应急预案 ? u?? 重大活动，三节等预案手册 ? l?? 服务降级：5000+ ? u?? 原则：覆盖全，开关避免手输 ? u?? 方案： ? ??? 业务代码框架层实现，动态修改运行时环境 ? ??? Tomcat监听端口，支持check/on/off/status ? ??? 集成运维工具系统 ? u?? 范围： ? 降级Web ?UI ?
  • 23. 1.新浪故障管理制度 ? l?? 组织形式 ? u?? 实体 ? ??? 故障管理组--跟进故障 ? ??? 业务方及运维核心人员--解决故障 ? u?? 虚拟：TDO-各部门专家 ? ??? 支持故障Review，深入挖掘故障本因 ? u?? 沟通方式： ? ??? 在线：电话，QQ及群，其他IM ? ??? 通知：短信，邮件 ? l?? 管理制度 ? u?? 拥抱故障 ? u?? KPI--故障记分 ? ??? 运营KPI与产物良好的用户体验挂钩 ? ??? 处理故障能力与KPI挂钩 ? u?? 奖惩制度： ? ??? 设立运维季度奖，涵盖面广 ? ??? 人为故障，责任到人，通告及罚钱 ?
  • 24. 2.新浪故障处理流程 ? ??接收报障 ??判断是否 为故障 接收 ??启动故障 通报流程 通知 ??跟进处理 进展 跟进 ??判断及启 动升级策 略 升级 ??确认解决 ??发出恢复 通报 解决 ??故障讨论会 ??发送报告 ??跟进改进措施 后续 故障管理组流程 ? ??与报障 来源部门 确认具体 现象 确认故 障现象 故障通 知 ??与TDO协 调相关部 门处理 ??每30分钟 通报一次 进展 协调跟 进 ??技术方向 升级 ??故障管理 方向升级 ??客服方向 升级 级别预 判升级 ??第一时间 通知主要 工程师及 TDO ??10分钟内 发出短信 及邮件 ??确认故障 恢复 ??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、影响微博功能 ? 2 ? 20% ? 2、影响服务时长 ? 3 ? 15% ? 3、影响用户范围 ? 4 ? 15% ? 4、用户投诉级别 ? 1 ? 10% ? 5、影响服务程度 ? 2 ? 10% ? 6、影响用户时段 ? 1 ? 故障评分 ? 64.5 ? 故障级别： ? C级 ? 微博故障报告单（要点） ? 故障标题 ? 故障描述 ? 所属产物线 ? 影响功能 ? 故障级别 影响时长 ? 开始时间 ? 发现时间 ? 恢复时间 发现途径 ? 故障原因 ? 根本原因 ? 触发原因 影响用户 ? 影响用户数 ? 计算方法 ? 投诉情况 责任部门 ? 责任人 ? 故障分类 ? 处理过程 改进措施 ? 服务影响时长=服务恢复时间-故障开始时间 ? 故障定级规则 ? 故障故障报告单 ?