李刚 百度服务可用性工程建设

ArchSummit

2018/12/09 发布于 技术 分类

文字内容
1. 百度服务可用性工程建设 李刚 百度共享技术平台部
3. 李刚 百度服务可用性工程技术负责人 曾任全国海关信息中心、中国光大银行总行 科技部架构师 在系统性、工程化建设服务可用性,大规模 分布式服务高可用架构设计等方面经验丰富
4. • 服务可用性问题回顾 • 基于故障和经验驱动的可用性管理 • 百度服务可用性工程解决方案 • 落地示例项目一:变更分级发布 • 落地示例项目二:故障盲测
5. 近几年业界发生的『新闻级』服务可用性故障 影响 15 10 8 5 14 11 9 0 2015年年 2016年年 2017年年 2018年年 数据来源:业界公开报道的互联网上市公司服务可用性故 障,包括:BATJ、美团、新浪、网易、携程、Google、 Amazon、Apple、Microsoft、Facebook • 对用户的伤害 影响衣食住行 财产损失 • 对公司的伤害 PV、GMV损失 商业赔付 公司信誉下降 给竞品机会
6. 通常的可用性管理方式:基于故障和经验驱动 百度历史上可用性故障经验借鉴 • 2015.03:骨干网络故障 • 2015.07 : 大促服务容量不足 • 2016.01:程序变更核心模块大面积出core • 。。。。。。 业界历史上可用性故障经验借鉴 • 2015.05:光纤被挖断,服务因网络故障 • 2015.05 : 整个站点被误删,服务异常 • 2016.01:网络变更,云服务大面积不可用 • 。。。。。。 各种各样的可用性改进措施 流量调度 权限隔离 过载保护 分级发布 网络Qos管理 降级 。。。 防攻击 快速回滚 灾备建设
7. 问题:逐个解决故障,效率低下,代价惨重! 已发生的故障 l 效率极低! 规模 产品线 数量 众多 平台 数量 几十 机器 规模 庞大 故障数 /年 几百 潜在的故障隐患 l 代价惨重!(黑天鹅事件) • A业务踩过的坑,B业务重复踩 • 成熟业务线踩过的坑,新兴业务线重复踩 • 都未踩过的坑,大家一起踩
8. 百度可⽤用性⼯工程解决⽅方案
9. 可用性影响因素 访问 服务 用户 研发工程师 程序/数据 /配置更新 应用 服务 基础设施 状态变化 攻击 服务 黑客 执行运维 操作 运维工程师 系统 异常 基础设施管理工程师 第三方公司/平台
10. 访问 服务 用户 程序/数据 /配置更新 研发工程师 可用性工程需求 容量 管理 容错 管理 安全 管理 攻击 发布 管理 应用 服务 服务 黑客 监控 管理 系统异常 故障 管理 灾难 管理 预案 管理 变更 执行运维 管理 操作 运维工程师 基础设施 状态变化 第三方公司/平台 基础设施管理工程师
11. 预防 发布管理 变更管理 容量管理 安全管理 容错管理 可用性工程需求 发现 监控管理 止损 故障管理 灾难恢复 灾难管理 预案管理
12. 预防故障发生能力 n 程序 代码、测试、变更规范 n 操作 操作规范、操作审计 n 运营 容量规划 n 防攻击 防攻击能力 n 平台/第三方服务 服务SLA n 基础设施 基础设施SLA 可用性工程技术标准 服务可用性能力 预防故障扩散能力 故障快速发现能力 故障定位止损能力 n 程序调度 调度容错 n 资源隔离 流量成份隔离 核心服务资源优先 n 部署隔离 逻辑服务单元拆分 核心功能逻辑独立 关联解耦 部署网段打散 分级发布 单点消除 n 权限隔离 登录隔离 信任关系管控 n 内部关键服务感知 n 外部关键依赖感知 关键上游服务感知 平台依赖感知 网络故障感知 第三方服务感知 n 故障定位 智能故障定位 n 流量调度 外网流量调度 内网流量调度 n 流控 n 降级 n 回滚/修复 n 重启 n 冻结变更 灾难恢复能力 n 数据备份恢复 n 应用备份恢复 n 基础平台备份恢复 n 灾难恢复预案 n 灾难恢复技术支持人 员 百度服务可用性工程能力模型
13. 可用性工程落地框架 用户端 预防 分级发版 接入层 防攻击 应用 服务 基础 平台 服分分容 务级级量 隔发操压 离布作测 无新闻级故障,服务整体可用率>99.995% 平台化服务能力输出 发现 定位/止损 灾难恢复 端监控 端流量调度 外网监控 外网流量调度 单 智内 机 统 内应 能网 房 快服过弹 一 网用 监监 故 障 流 量 故 障 自 速 回 务 降 载 保 性 伸 备 份 控控 定调 动 滚级护缩 恢 位度 止 复 损 Case Study 机制 可用性 技术标准 可用性 能力审计 故障 盲测
14. 项目1:变更分级发布 问题 多机房故障是可用性损失的重灾区 变更是导致多机房故障的“头号杀手” 94.70% 多机房故障总损失 单机房故障总损失 74% 变更引发 其他引发 技术方案 变 更 部署信号 系 统 Stage1 IDC1 单实例 反馈、决策(停止/继续?) Stage2 IDC1 m%实例 (m<=5) Stage3 IDC1 100%实例 Stage4 IDC2/3/4… 各m%实例 (m<=5) Stage5 IDC2/3/4… 100%实例 每级stage自动检查(pvlost/core/平响…) 监控系统
15. 变更检查遇到的问题 检查指标覆盖不全 5000 3877 4000 3000 2000 1000 0 928 10 9 1351 795 57 26 模块1 模块2 模块3 模块4 监控项 变更检查项 检查指标阈值难以精确设置 80 阈值太高:问题无法发现 60 阈值太低:误拦截 变更 40 时段 20 0 0 7 10 16 20 23 4 9 14 18 22 0 9 平响
16. 变更智能检查 • 引入所有监控指标数据 • 引入变更对照组 整体 思路 实验组:本次变更 变更时段 指标 变化 T检验 度量 对照组: 历史第一次变更 VS 变更时段 历史第二次变更 变更时段 …… 一致度 判定 ?????? + ?????? Z检验 ?????? ?????? − ?????? 历史第N次变更 变更时段 历史T值均值 历史T值正常 波动上下限 历史变更指标 变化T值 待检测变更指 标变化T值 实验组:本次变更 整体 变更时段 思路 对照组:未变更机房1服务 VS 变更时段 未变更机房2服务 变更时段 …… 实验 组变 化预 测 Y 线性 变更后指标值 回归 预测 变更前指标值 X 一致度 判定 T检验 未变更机房N服务 变更时段
17. 项目2:故障盲测 场景1:机房级故障盲测 问题:不存在“绝对可靠,永不宕机的机房” 服务存在单点 服务跨机房混联 容量冗余不足 xx.baidu.com xx.baidu.com xx.baidu.com 架构 机房A Service A Service B Service C 机房B Service A Service B 机房A Service A Service B Service C 机房B Service A Service B Service C 机房A Service A Service B Service C 机房B 容量过载 Service A Service B Service C 单点服务Service C 所在机房 影响 A故障,导致服务整体故障 机房A或机房B故障,无法通过切流 量完全止损 N+1冗余不足,导致机房A故障, 切流量至B机房时容量过载
18. 项目2:故障盲测 场景1:机房级故障盲测 问题域 盲测技术方案:网络断续拥塞,程度逐级加重 业务影响调研 盲测方案 如何制造机房级故障? 约束条件 [1] 可用性损失 < Error budget 目标 以最小可用性代价, 达成盲测效果 搜索单物理机房完全中断1分钟 业务影响摸底测试 • 测试机房:A机房 • 准备工作:提前切走A机房99%流量 • 故障制造:Default Qos拥塞->在线 Qos丢包率5%->在线Qos丢包率50% • 摸底结果:MAX(PV损失天级占比) < 0.0001% Default Qos拥塞 3分钟 在线Qos 5%拥塞 3分钟 在线Qos 50%拥 塞3分钟 超核 IDC 数据中心核心 集群 核心1 TOR 集群 核心2 RS1 RS… 集群 核心3 [1] Error budget理念由google提出,https://landing.google.com/sre/interview/ben-treynor.html
19. 项目2:故障盲测 场景2:服务实例级故障盲测 问题:机房级故障盲测无法做到“指哪打哪” 盲测技术方案:指定服务节点,通过资源消耗制造故障 Server(BdMonkeyKeeper) Control Server Init Letout/ TakeBack Modify Config Deploy Server Deploy 集群控制系统 Client on RS(BdMonkey) Run SysConf HTTP 集群控制系统 HTTP Client on RS(BdMonkey) Run SysConf 资源操作接口工具(CPU、内存、IO、网络)
20. 回顾总结 1 • 服务可用性问题回顾 - 对用户的影响 - 对公司的影响 2 • 基于故障和经验驱动的可用性管理 - 效率低下 - 代价惨重 3 • 百度服务可用性工程解决方案 - 可用性技术标准 - 工程落地框架 4 • 工程化落地项目示例 - 变更分级发布 - 故障盲测
21. OPSTABLE 各业 务线 OPSM 基础 Keep The Site Up, 基础 设施 Whatever The Reason 平台 工程 效率 质量 保证 我们的组织 • OPSTABLE:一个横向组织 - 整体负责百度服务可用性;制定可用性技术标准; 平台化输出可用性工程能力 - 由各业务线、平台团队高可用专家组成 - 不同技术方向和背景,共同的目标 我们坚持 • 用系统性、工程化、平台化方法解决服务可用性问题! • Case Study文化,认真复盘每一个可用性Case,细节 刨根问底! • follow through文化,对每一个TODO跟进到底!
25. 欢迎扫码反馈