Go如何帮滴滴支撑海量运维场景

1 .Go如何帮滴滴支撑海量运维场景 秦晓辉 

2 .个⼈简介 秦晓辉 18612185520，qinxiaohui@didiglobal.com 先后履职于百度、小米、⾦⼭云，开源互联⽹监控解决⽅案 Open-Falcon主程，Nightingale开源发起⼈之⼀，现在在滴 滴负责产业云技术中⼼，推动滴滴中后台能⼒商业化输出 

3 .⼤纲 • 海量运维问题域是什么样的 • 为什么选择 Go • 构筑了什么样的运维平台体系 • 如何开始体系化平台的构建 

4 .海量运维问题域是什么样的 

5 .海量运维问题域 典型特点 ⼤量不同语⾔的服务 ⼤规模机器 异地多个机房 有物理机虚拟机容器多种运⾏环境 ⽹络分区多样 各类开源中间件 各类自研⼯具 各种安全要求 ⼤量不同厂商的硬件⼤量过保更迭 对接的⼈多角⾊分⼯细 

6 .海量运维问题域 典型问题 统⼀服务治理困难 机器环境各异 ⽹络抖动带宽争抢 不同的运⾏环境如何提供统⼀的使用体验 各种⽹络分区隔离 各类中间件、自研平台均需构建运维体系 完备的权限审计诉求 每天都有各种硬件故障 每天各种⼈追着你答疑提需求 

7 .海量运维问题域 典型解法 在流量转发层做⽂章 统⼀机器初始化、整包或镜像部署、静态编译 页面和流程层面统⼀，底层驱动式设计 ⽹络分区代理、防⽕墙友好设计 运维体系是平台核⼼+扩展共建的思路 统⼀权限、统⼀日志、统⼀审计 让业务能漂起来不依赖底层硬件 自动化⼯单、知识库构建、答疑机器⼈ 能统⼀的统⼀、能规范的规范、再不济就是统⼀核⼼+周边扩展；分层⼤法；⼯具⽂化 

8 .为什么选择 Go 

9 .为什么选择 Go Go 自身特点 Go 周边⽣态 资源占用少，适合开发agent 并发元语⽅便 静态编译依赖少 上⼿简单、风格统⼀ 

10 .构筑了什么样的运维平台体系 

11 .运维平台体系构筑⽅向 稳定性体系建设 变更体系建设 效率体系建设 成本体系建设 安全体系建设 

12 . 稳定性体系建设 构建⽅向 标准 规范 落地 ⼿段 评价 体系 

13 .稳定性体系建设 相关平台⼯具举例 风险 预防 量化 监控健康分 预案健康分 变更信用分 数据库信用分 监控 发现 报警 业务监控 应用监控 服务监控 基础设施监控 故障 定位 下钻 全局灭⽕图 事件墙 容量⽔位 接⼊层⼤盘 预案 ⽌损 故障自愈 911预案平台 域名切流 变更回滚 管理 问题 复盘 跟进 可用性统计 遗留项管理 故障原因统计 红⿊榜单 

14 .变更体系建设 构建⽅向和平台⼯具举例 环境管理 编译打包 变更发布 服务治理 流量接⼊ 状态监控 装机带外管 编译构建 服务部署 名字服务 四层接⼊ 指标采集 理 堡垒机跳板 代码检测 配置管理 统⼀框架 七层接⼊ 日志采集 机权限分配 机器初始化 ⼯作流管理 数据配送 调用链追踪 域名管理 告警策略 制品镜像库 编排调度 限流熔断 应用防⽕墙 监控⼤盘 

15 . 效率体系建设 构建⽅向 日常⼯作平台化 如果还是找不到⽅向 重复⼯作自动化 问⼀下自⼰如下问题 • 固化的问题自动排查 • 哪些⼯作比较多？ • 固化的预案自动执⾏ • 哪些⼯作比较痛？ • 需求类⼯作自助执⾏ • 哪些⼯作可以做个平台让自⼰更快的完成？ • 巡检类⼯作周期执⾏ • 哪些⼯作可以做个平台让需求⽅自助完成？ • ⼯作流自动执⾏环节 • 哪些⼯作可以固化为脚本让上游自动触发？ 

16 .效率体系建设 相关平台⼯具举例 ChatOps(各类聊天机器⼈) 知识库(有⼈⼀年写2000多篇wiki) 专 业 接 客 运维准⼊ 软件安装 接⼊层变更 服务下线 区 服务器重装 服务器改名 域名申请 出⽹申请 自 监控告警相关 服务治理相关 PaaS类资源操作：数据库、MQ、NoSQL 助 区 日志查询分析 变更发布相关 IaaS类资源操作：虚机、云盘、对象存储 基 命令通道 ⽂件分发 定时任务 任务⼯作流 座 

17 .如何开始体系化平台的构建 

18 .为你的运维平台化之路开个头 

19 .滴滴夜莺简介 Github地址：https://github.com/didi/nightingale Nightingale（滴滴夜莺），衍⽣自Open-Falcon，融⼊了滴滴的最佳实践， 如今是v3版本，已经从⼀款运维监控系统，演化为⼀款运维平台，除了具 备监控告警的能⼒，也融⼊了部分CMDB、资产管理、命令执⾏、告警自 愈的能⼒。运维平台体系化之路，可以用夜莺开个头 :-) 

20 .

21 .

22 .

23 .

24 .夜莺当前产品能⼒ 运维⼯单系统 变更管理 稳定性体系 其他⽅向 机器环境初始化 应用打包编译 监控告警系统 故障定位系统 备份恢复系统 应用变更发布 日常维护类操作 预案管理系统 故障跟踪系统 成本管理系统 配置管理 资产管理 运维安全体系 组织元信息 资源元信息 主机设备 ⽹络设备 容量⽔位系统 权限元信息 服务元信息 机柜机架位 配件耗材 ⽹络访问质量 统⼀底座：统⼀框架、统⼀用户、统⼀角⾊、统⼀审计 下划线部分是当前夜莺已经具备的能⼒ 

25 .夜莺系统架构 

26 .夜莺与Open-Falcon的对比 对比项 Open-Falcon Nightingale • 部分模块存在单点问题，比如告警模块 • 所有模块全部⾼可用，挂掉⼀台机器服务⽆影响 • 使用数据库存储索引⽆法应对海量索引情况 • 自研索引或采用M3DB⽅案可以应对海量索引 架构 • 只有rrd⼀种落盘存储机制，扩展能⼒较弱 • 使用驱动式设计，支持多种后端存储：M3、RRD、InfluxDB • 是个纯粹的监控，体系化考虑较少，缺少完备的 • 体系化程度⾼，以监控告警为核⼼主打能⼒，围绕着建立了部 用户权限体系、资产管理、运维自动化、告警自 分CMDB能⼒、完备的用户权限体系、命令通道和告警自愈等 体系化 愈等 • 整体设计较为简单，除了模板继承机制稍难理解， • 单就监控⽅面易用性更好⼀些，但是因为功能模块较多，学习 整体容易上⼿ 起来确实有⼀定成本 易用性 • 只有RRD⼀种落盘存储机制，存储⽅面扩展能⼒ • 使用驱动式设计，支持多种后端存储：M3、RRD、InfluxDB 较弱 • 可以复用Open-Falcon社区采集插件和Prometheus社区各类 扩展性 • 社区贡献了部分监控采集插件，囊括各类常见对 Exporter，也提供Java、Go的埋点SDK，内置日志监控能⼒ 象的监控采集 

27 . 夜莺与Zabbix的对比 对比项 Zabbix Nightingale • 基于数据库来存储时序数据，容量上限较为明 • 使用驱动式设计，支持多种后端存储：M3、RRD、InfluxDB， 显，TimescaleDB有待⽣产验证；拉取监控数据 ⽣产环境建议M3DB；近期数据在内存拉取监控数据比较快 架构 也比较慢 • 是个纯粹的监控，如果要做CMDB、运维自动化 • 体系化程度⾼，以监控告警为核⼼主打能⼒，围绕着建立了部 相关支持，就需要和其他产品搭配使用了 分CMDB能⼒、完备的用户权限体系、命令通道和告警自愈等 体系化 • 对各类设备的监控支持较好，甚⾄AIX、BSD等 • 设备层面支持常规Linux、Windows、交换机、容器的监控 都有支持 • 对应用业务侧监控支持较好，提供日志提取⽅式和SDK⽅式 监控能⼒ • 对应用业务侧监控支持较差，主要是受限于数据 结构 • 服务端和客户端采用C语⾔，研发⼈员较为难招 • 全部使用Go语⾔开发，和Kubernetes、Prometheus⼀个语⾔， • WEB端采用PHP语⾔，没啥说的，毕竟，这是世 单语⾔系统⼆开难度小⼀些 ⼆开难度 界上最好的语⾔ 

28 . 夜莺与Prometheus的对比 对比项 Prometheus Nightingale • 设计上偏⼯具⼀些，采集策略、告警策略都是 • 产品化程度更⾼⼀些，所有操作都可以通过页面完成，使用复 编辑yaml⽂件，对于多⼈同时使用的场景不够 杂度上相对简单⼀些 易用性 友好 • 与Kubernetes结合紧密，比较容易采集容器相关 • 可以采集容器相关指标，对Kubernetes自身组件，需要借助监 指标，比较容易制作集群监控⼤盘 控插件实现采集，略微麻烦 容器监控 • 对传统物理机、虚机的监控管理不够友好，特别 • 特别适合传统物理机、虚机的监控，树状机器分组机制非常灵 是服务混部情况下，缺少易用的机器分组机制 活，直观易用 设备监控 • 是⼀个纯粹的监控告警系统，不处理其他运维场 • 体系化程度⾼，以监控告警为核⼼主打能⼒，围绕着建立了部 景 分CMDB能⼒、完备的用户权限体系、命令通道和告警自愈等 体系化 

29 .夜莺用户案例