作者简介：
来炜
国内首款开源企业级监控系统Open-Falcon的负责人，目前担任滴滴出行运维总监。
在展开正文之前，我们先分享一下记录片《 超级工厂：宜家家居 》的故事，宜家作为全球知名的家具领导品牌，在全球几十个国家和地区，拥有数百个商场。
宜家的全球化采购和直销模式，能够取得如此巨大的成功，与宜家在创办初期，就确立的标准化设计理念有关。
在宜家，如果一个产品不能被扁平化包装运输，那么即使设计再精妙，也不会被批量生产。设计和运输同样重要!
坚持「可运输性」的设计理念，降低了产品到达终端用户的成本。便宜、快捷的体验，进一步推动着宜家的持续发展。
同样的，规模化的运维，不能再是见招拆招，追着业务满世界跑，应该全局统筹，将多变的业务需求抽象为高度统一的运维模型，通过平台来体系化的支撑。
我们希望能有这么一个标准化的魔法箱子，把我们的代码，打包进去，运行、维护、扩容、容灾都是流水线的方式自动化进行。
根据“ 熵理论 ”：
一个孤立的系统，始终会趋向于越来越乱（无序化）的方向发展。
如果要让一个系统变得更有序，必须有外部能量的输入。
所以对于我们动辄几千上万台的互联网行业来讲，加上特有的「快速试错」理念加持，这个庞大的、错综复杂的系统，总是倾向于越来越乱。
这就需要我们格外投入精力，才能让系统朝着有序的方向发展。
如果我们在设计或者开发阶段，欠下更多的债，埋下更多的坑，那么在产品的运行维护阶段，就要加倍偿还这些技术债务。
债总是在那里，只是在哪个阶段还的问题，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，没有人比模块的研发人员，更清楚其工作机制，更关心其运行状态，模块自身的可运维性就是代码功能的重要组成部分。
每次业务逻辑部分的代码变更，都应该伴随着监控指标采集的相应更改。
有了原则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
