七叶笔记 » golang编程 » 滴滴运维标准化实践二三事

滴滴运维标准化实践二三事

作者简介:

来炜

国内首款开源企业级监控系统Open-Falcon的负责人,目前担任滴滴出行运维总监。

在展开正文之前,我们先分享一下记录片《 超级工厂:宜家家居 》的故事,宜家作为全球知名的家具领导品牌,在全球几十个国家和地区,拥有数百个商场。

宜家的全球化采购和直销模式,能够取得如此巨大的成功,与宜家在创办初期,就确立的标准化设计理念有关。

在宜家,如果一个产品不能被扁平化包装运输,那么即使设计再精妙,也不会被批量生产。设计和运输同样重要!

坚持「可运输性」的设计理念,降低了产品到达终端用户的成本。便宜、快捷的体验,进一步推动着宜家的持续发展。

同样的,规模化的运维,不能再是见招拆招,追着业务满世界跑,应该全局统筹,将多变的业务需求抽象为高度统一的运维模型,通过平台来体系化的支撑。

我们希望能有这么一个标准化的魔法箱子,把我们的代码,打包进去,运行、维护、扩容、容灾都是流水线的方式自动化进行。

根据“ 熵理论 ”:

  1. 一个孤立的系统,始终会趋向于越来越乱(无序化)的方向发展。

  2. 如果要让一个系统变得更有序,必须有外部能量的输入。

所以对于我们动辄几千上万台的互联网行业来讲,加上特有的「快速试错」理念加持,这个庞大的、错综复杂的系统,总是倾向于越来越乱。

这就需要我们格外投入精力,才能让系统朝着有序的方向发展。

如果我们在设计或者开发阶段,欠下更多的债,埋下更多的坑,那么在产品的运行维护阶段,就要加倍偿还这些技术债务。

债总是在那里,只是在哪个阶段还的问题,systems do not run themselves。

规模化的互联网运维

经常会有人问,1个人支撑10台服务器和1个人支撑2000台服务器,到底哪个更难一些?

当运维支撑体系不完善,业务模块都不同构,监控方式、部署方式百花齐放,1个人要支撑10台服务器,就已经疲于应付,处于要崩溃的边缘了;

相反,如果所有的服务,都是同样的监控方式、部署方式,同时运维支持体系都是自动化的,那么1个人支撑2000台服务器,也是轻松加愉快的。

以滴滴为例,在四年时间里,从最初只有四台服务器,发展到现在的数万台设备,在这样的发展速度下,显然我们要采用规模化的运作方式,提高运维效率,自动化一切是摆在我们面前唯一的出路。

一切系统的设计,都是在满足一定假设前提下的产物,而自动化的前提,恰恰就是“ 标准化 ”。

总之,在一个统一的标准和实践引导下,所有人去尽可能靠拢,那么事情会变得简单很多!

所以,半年时间里,我们主要围绕着三个方面在推进服务标准化的事情:

配置管理

常见的配置包括以下一些内容:

  • 各种开关,比如降级的开关、debug开关、ab测试的开关等。

  • 各种可配参数,比如超时时间、并发数、日志级别等。

  • 上下游连接信息。

上下游的连接信息,与环境的耦合度最高,是最复杂、最多变、最难处理的部分。

我们看看大家一般都是怎么来对付上下游连接信息的:

  • 通过LVS来管理 ,即 vip:port -> real-server-ip:port 列表。

这种方案的好处就是充分利用了LVS的高可用特性以及负载均衡、健康检查能力,将上下游的耦合转移到LVS的配置中。

这样的坏处也显而易见,配置管理虽然集中化了,但是流量也集中化了,存在严重的单点风险。

  • 通过 nginx 来管理 ,即ip:port/server/location -> upstream列表。

这种该方案的优缺点,同LVS方案,只不过是工作在七层罢了。

  • 通过DNS来管理 及domain -> ip列表

这种方案负载均衡策略太单一,同时切换速度太慢。

  • 通过zookeeper/etcd来管理

这是非常经典的方案,成熟度较高,只不过在网络发生分区的时候容易出问题。

  • 通过本地配置文件来管理

这是最原始的方案了,上下游的连接信息,直接写在模块的配置文件中,散落在目标服务器上。使得整个拓扑关系不清晰,故障切换速度慢。

针对这些现实情况,我们迫切需要建设配置管理,来解决:

  • 代码(配置)和环境解耦合,用户写好代码,不用再关注测试环境、线上多套集群的差异性,不用关注实例具体跑在哪些资源上。

  • 配置集中化管理,使得我们具有自动化拓扑的能力,以及快速切换的能力。

  • 支持即时生效、健康检查、负载均衡。

此外,自动注册和发现,这些特性都可以在现有的基础上,方便的叠加。

对于运维的系统和基础设施建设,理念的一致性和延续性非常重要,当前的任何一个方案,都要充分考虑和未来三年的长远方向是否一致,今天所做的工作是否在为长远目标铺路。

最忌讳的情况就是后来的方案需要不停的推翻早先的方案,业务的改造成本是要重点考虑的。

监控

监控是整个运维环节,乃至整个产品生命周期中最重要的一环,事前及时预警发现故障,事后提供翔实的数据用于追查定位问题,分析业务指标等。

那么残酷的现实情况是怎样的呢?

  • 在线日志分析,使用各种 正则表达式 来提取相关指标

这种方案,定制化程度高,维护成本高,试想想,过了三个月,面对你所配置的一大堆正则表达式规则,你有勇气去面对和维护吗?

同时在线分析日志,会对在线服务器造成较大的性能消耗。

  • 离线日志分析

该方案时效性较低,对日志的耦合高,同时大量日志的传输分析需要的资源消耗也是非常可观的,不够经济,不够轻量。

  • 实例自身暴露相关status接口

这种方式,理念已经较为先进了,研发在设计和开发模块的时候,就已经充分预见到了需要暴露哪些指标,来有效的监控自身的运行状态和各种统计信息。

但是一千个人眼里有一千个哈姆雷特,每位研发同学都有自己的见解,于是这些接口输出格式和意义各不相同,缺乏一致性的规范,在整体运维的层面,造成困难。

  • 各种「外挂」形式的监控程序

这种应该是最糟糕、最落后的方式了,研发在设计和开发模块的时候,没有一丝丝的“监控”意识,没有暴露自身的状态和信息,甚至也没有打印相关重要日志。

等到这样的代码上线后,才想起来,是不是需要加一些监控。

那么对于这些既成事实,受限于业务的压力,运维只能抛却原则和底线,无奈妥协,然后想尽各种旁门左道的办法,给业务模块写监控外挂。

这些外挂和每个模块自身特性紧密耦合,业务一不小心改了,监控外挂就得跟着改;同时如果每个业务模块都这么搞,基本上这些业务就处于事实上的“不可运维”状态了。

看完上面的几种情况分析,再一次说明, 规模化的运维 ,不能是见招拆招, 应该全局统筹

针对监控,我们提炼了两条基本原则:

  1. 坚持业务指标采集是代码的一部分原则不动摇,提高指标覆盖率。

  2. 监控方式和指标要标准化,工具支撑系统化。

原则1,没有人比模块的研发人员,更清楚其工作机制,更关心其运行状态,模块自身的可运维性就是代码功能的重要组成部分。

每次业务逻辑部分的代码变更,都应该伴随着监控指标采集的相应更改。

有了原则1,还远远不够,没有好的工具和体系支撑,提高指标覆盖率就是一句空话。

在运维层面,应该制定统一的监控标准,推行统一的最佳实践,提供统一强大便捷的metrics lib库支撑。

这样才能更容易的推进自动化进程,以及更高的监控指标覆盖度。

谈谈监控标准化,标准如何定义?

1. 每个业务的每个接口,都要可被监控。

2. 每个接口的监控指标,必须至少包含:

cps

latency-50th/75th/95th/99th…

error_rate

error_count

3. 可以在2的基础上,扩充相关自定义指标,比如:

caller

callee

这样就可以细化到调用关系级别的数据。

4. 所有的指标上报,采用主动push机制,无需预先注册。

有了上面的一些标准化的指导思想,我们就可以着手开发lib库,推进业务模块接入了。

以nginx为例,监控指标采集,可以参考我们的实现:

采集到的指标包括:

  • api tag: 即nginx request uri,各统计项按照uri区分。当api为保留字 serv 时,代表nginx所有请求的综合统计。

  • error_count、upstream统计项根据实际情况,如果没有则不会输出。

有了这些标准化的指标,很少的几个告警策略就能覆盖到绝大数的业务模块,而不用担心针对每个业务添加不同的告警策略。

同时可以针对每个业务,根据不同的用户,建立各自的 dashboard ,比如针对老板、研发、运维、测试,关注的dashboard侧重点都有所不同。

每个服务都要有自己的 大盘

大盘可能长这样

大盘也可能长这样

部署

说起来很简单,部署就是将代码、配置、数据,在一组资源上,保持给定数量的实例在运行。

但,现实是骨感的, 存在 着这样那样的 痛点

  • 新业务接入沟通成本高

  • 环境依赖多(PHP/java/golang/c++)

  • 上下游连接信息管理乱(拓扑不明确,散落在各个目标服务器上)

  • 用户体验不统一(编译打包、发单、审核、执行、观察各个环节脱节)

  • 增量更新存在协同上的问题

部署和变更,我们的一些原则:

  • 以版本为发布单位

  • 统一的接入流程和打包规范(也可以很方便的构建为docker image)

  • 集中化的配置管理,配置与线上环境 解耦

  • 统一的上线流程和检查机制(preview、小流量、集成监控告警、集成趋势图)

  • 日志依赖解耦(网络日志)

可以预见,经过坚持不懈的标准化改造,线上服务:

  • 配置和环境解耦了

  • 监控标准化了

  • 部署规范化了

  • 日志网络化了

  • 数据service化了

  • 实例自发现了

  • 资源容器化了

全自动化调度,顺势而为罢了。

原文链接:

关于OpenFalcon

Open-Falcon是一个开源的、企业级的、高可用、可扩展的监控系统。

最早由小米运维团队发起和开源,目前已经成为国内互联网公司使用最广泛的监控系统之一,并形成了良好的开源社区和用户基础,积累了一批核心的社区开发成员。

目前活跃社区成员2000+,核心开发成员来自小米、美团、快网、滴滴等多家公司。()

如果您想了解更多关于部署、监控、配置管理的知识,可以通过以下方式获得:

1.扫描下面的二维码,关注我们的公众号:

QQ群号:516088946

相关文章