谈谈运维标准化

在下周广州的DevOps运维交流会上，我准备了150页的PPT，目前正在简化中，自己也特意提前把一些内容分享出来，到时候在交流会上简化描述。

备注：我把标准化当做运维的基础，它对运维平台及数据平台有着重要的影响。对于应用运维来说，标准化是有方法和套路的，首先是这个标准化一定是运维主导的，不是研发主导，生产环境在你手，是需要把生产环境的可运维性为标准的；其次标准化的东西很多，这个就看运维人思考的边界在哪儿？

本文没有提服务器标准化，我觉得业界有两种变化，第一BAT牵头制定的天蝎标准化；第二个就是云平台服务，做上层运维的同学就更不需要关注底层的硬件标准化了；第三，很多小的公司对服务器标准化需求不是太强烈。所以思考更多的是上层运维的标准化。

备注：配置标准化的难度非常高，不过我觉得可以和研发多强调其带来的好处，我看到的好处有三个方案。自动拓扑发现、配置管理更加简单、工具建设成本降低。

• 自动拓扑发现，如果定了很好的配置结构，可以从配置中直接读取访问的外部服务信息、DB信息、MC信息等等。
• 配置管理更加简单。对于一个海量服务来说，配置管理必须建设配置中心来解决，因为配置太复杂；而对于一个规模不大的业务来说，可以把配置管理的标准制定，然后统一遵守即可。我们现在的配置就定义了清晰的目录结构，那些是运维需要关注的配置，那些研发需要关注的配置，然后配置在三个环境的差异，统一到define.conf重定义解决，把需要管理的多个配置对象变成一个。
• 工具建设成本降低。就拿刚刚描述的来说，管理一个配置文件和管理是个配置文件的代价完全不同，我们都知道基于文本的配置文件管理，过多的配置文件容易出错。因此到海量服务的规模，必须要上配置中心，配置中心要解决多个维度的配置管理问题，比如说集群类型、环境类型、机房等等。最关键的是，还要通过配置中心来实时的监控大规模集群中的配置一致性的问题。

备注：我们把配置做了分类，有些是账号安全，有些是白名单，有些是http配置等等。通过变量来定义${**}配置在生产环境和测试环境都有不同。如果配置不做标准化，则需要开发编写详细的配置文档，然后运维逐个修改，现在则在线上直接可视化修改。注意其中的${***}部分，这块是变量，最终的取值都是在define.conf中定义了。

备注：对于应用环境来说，真正的配置环境标准化，也就以上那几个方面。其中包的管理、权限管理和配置管理则是非常重要的几个方面。

• 角色权限。主要是限定运维和研发的权限，一定要把研发者的权限从生产环境隔离开来，只开发只读用户，供查阅日志使用。
• 包管理。包的管理涉及的东西很多，可以很细致。后面详述。
• 配置管理。之前已经说过思路，一种就是配置要标准，另外一种就是配置中心。

备注：我们从包的定义／生命周期和包的规范等多个角度定义了包的管理。对于很多运维同学来说，我们看到的包就如同rpm或者yum那么简单，但是从可运维性的要求来说，需要把这些全部定义清楚，这样才能把它的管理可视化。无论是在yy还是在uc，我们都把其管理当作核心的运维自动化要求，因为成某种程度上来说，大部分的变更都是包的变更。稍微打通一下，我们便可以和持续集成对接，变成一个完善的／通用的持续部署平台。这个地方引申一个问题，针对这么多的细节，如果没有一个管理平台，那么这些规范形同虚设，所以我们在做规范的同时，一定要考虑平台实现，把这些细节藏在平台之后。如下图给了一个【包生命周期】和【包上线的流程图】，供大家参考！

备注：我们都在知道对于一个面向用户的服务调用产生了之后，到内部系统肯定会触发多次的远程调用，那么不同的内部微服务之间，需要通过标准化的协议来实现。服务规模不大的情况下，http协议即可，实现成本很低。当前我们就提供了一个标准的http协议面向业务的封装，通过这样的封装在底层进一步实现了容错和负载均衡调度。具体的算法是【服务降权】和【重连监测】，前者是服务容错，后者是服务恢复。算法所依赖的指标就是一些业务访问统计出来的指标。

备注：我这个地方也给出了两种服务调用之间的差异，图上部分红色部分，是配置文件定义的服务调用，下面是两种服务调用的差异，我们可以看到底下的normalRequest调用，可以看到通过正常的http请求发起，典型的DNS问题无法规避，因此也达不到可运维性要求，必须改变掉。

备注：一个好的server容器框架可以让运维的工作事半功倍，JWS（java web server）的框架就属于这一类。当初UC根据play框架来进行匹配改造，逐渐演进到现在，基本上很多运维工作都是它来干了。比如说监控统计、服务调度、统一的配置管理服务等等。我们现在也围绕它打造了几个平台，持续部署平台，名字服务中心调度平台等等。这些平台目前已经成为运维的核心系统，特别是名字服务中心，后面会逐步收敛成运维的故障发现、定位平台。

备注：离开腾讯之后，自己也多多少少写了一些运维规范，上面是根据“规范”关键字在自己的本地电脑中搜索的结果，其实我更想说，一定要把他写出来，只有写出来的东西，才认为是认真思考过的，并且是考虑清楚的。这是体现运维做事的一个规范！！！

总结：

这些标准化和规范都是为了让人和系统更有效率和效力的做事。效率是速度、效力是结果。很多时候不做规范，开始做运维平台建设，到最后会失控，或者就变成了ssh的可视化封装。看似非常灵活，其实这种自由带来的结果就是行为不可控。我也对标准化提炼了一些观点：

• 标准化没有边界。在你看到有问题的地方，都可以设定规范和标准化，但是要考虑在平台中如何实现，同时要权衡成本。
• 标准化以可运维性为目标。我们做这么多的标准化，不就是为了让大家一眼就能看得明白，基于它们构造的运维能力，人人可以对接。
• 标准化以简化运维平台建设为度量。除了早期的一些流程，对线上的所有标准化，都可以理解成是为了简化运维平台建设，这些规范必须沉淀到平台中，才能真正做到方便运维。
• 标准化是有层次的。硬件、OS、应用、协议.....。
• 标准化意味着运维理解的精确度。可以自己体会一下，你不会觉得运维无事可做，或者就是提供服务器的。

我把相关的规范打包，如果你有需要，可以给29956914@qq.com发送邮件，邮件标题［所在公司名］［公司运维人数］［邮箱地址］（注意标题规范哈），到时我会发送给你。