上：自动化运维

运维 DevOps

InfoQ：您从事运维行业已经8年了，根据您的个人经验和理解，一个全面的运维系统需要完成哪些工作呢？

赵成：这是个比较大，但是非常好的一个问题，这是运维的范畴问题，大白话说就是运维到底是干啥的。我想这个问题，对于一个运维的同学如果理解不清楚，将会对他在工作中的定位产生影响，甚至会影响着他职业道路的发展和选择。对于一个非运维同学，如果我解释不清楚，从外部的视角看，简单粗暴的理解，运维就是搬机器拉网线的，高级一点的会熟练的编写shell、python和perl脚本。
所以，我想还是要花些篇幅把这对这块的理解讲清楚。
关于运维的范畴，我的理解总结下来应该包括几个维度：效率、稳定、安全、体验和成本。其中效率和稳定可能是运维同学最本职最应该优先做好的事情，安全、体验和成本是运维同学在基础做好的前提下，能够更进一步的方向，下面详细说明一下：
(1). 效率
这块跟日常的运维例行工作紧密相关，如资源分配&回收、域名配置、VIP配置、持续集成&发布、应用部署、应用扩容&缩容等，这块是运维最基础的工作，通常提到的运维自动化，大多是集中在这些工作上，因为这些工作偏日常和重复，目前业界的自动化的解决方案也非常完善了，所以可以优先把这些问题解决掉，目标就是解放运维的生产力，提升运维效率，降低人为失误，让运维的同学可以有更多的精力去做更有价值的事情。
(2). 稳定（质量）
让业务运行更加稳定，监控、全链路、强弱依赖、限流降级、容量评估、预案平台等，这块需要有相对比较独立和专业的监控和稳定性平台来支持，目标是最大程度的保障系统的稳定和运行质量，即使出现问题，也能够快速发现、快速响应、快速（自动）恢复。
(3). 安全
安全是与运维同等级别的一块专业领域，但同时又是跟运维紧密相关的，运维同样要关注安全，因为安全出现导致的问题，往往也会给运维带来沉重地防护和修复成本。我们经常提到的，各类主机安全、DB安全、Web安全、应用安全等等，与此相关的还有漏洞、DDos、CC等关键词。
(4). 体验
这里提到的体验，指的是终端用户的访问体验，非功能或产品使用体验，对于运维来说就是要关注访问速度。作为开发的同学来讲，可能更多的注意力会放在自己负责的代码以及该部分的性能问题，不会关注到端到端全流程的性能和体验。但是运维可以站在全局的角度来审视和治理整个端到端全链路的性能情况，并给出对应的性能优化建议。
(5). 成本
成本问题，也就是技术ROI（投入产出比）的问题，当系统规模和体量变大之后，掌控在运维手中的各类资源，将占整个研发团队支出的大头。如果没有很好的成本控制意识和策略，资源体量将会持续增大，甚至是翻倍或指数级的增长，对于公司成本会是非常大的负担和压力。
如何能够更高效地被充分利用起来，如何能够最大限度的减少成本支出，是我们必须要去考虑的问题。如服务器CPU资源利用率的提升（引申出来各种虚拟化、容器或云资源的使用）、IDC&CDN流量带宽使用的管控，还有人力的投入和成本的管控。
问题小结：
以上便是我们理解的运维范畴，可以看到这个范畴其实可以是很大的，或者这样来说，只要最终是跟线上业务运行相关的工作，运维都是要关注的，如果运维仅仅是片面和狭隘地给自己限定一个范围，无法做到提前统筹和规划，就很容易变成被动响应的角色。
以上提到的几个维度，在一个公司里，包括蘑菇街，都会有不同的专业团队来承担，比如我们就有安全团队、稳定性团队、监控团队等等，但是在日常工作中，运维团队跟这些团队是不分彼此的，因为每一项工作或项目最终要以线上实际现状为导向，而运维是最清楚和了解这些细节的，同时最终产品或功能都要通过运维来落地和运营。
同时，以上的几个维度不是孤立存在的，而是相互影响和互为依赖的，比如效率高、稳定性好、体验优越、安全等级高，成本（硬件、带宽和人力）必然更加容易管控，同时会下降。再比如，稳定性相关的系统比如全链路、容量评估做的好，体验工作开展起来也更加方便。
所以，运维是贯穿整个软件生命周期的持续性工作，对待运维工作也必须要有更全局的视角。而且业务体量做到一定程度之后，如果运维体系和效率跟不上，一定会是拖业务发展后腿的，所以对于互联网企业，对于运维的理解和定位必须要有重新的审视和理解才可以。

InfoQ：这几类工作是否都可以实现运维自动化？

** 赵成：**这是一定可以的。我想自动化不仅仅是对运维，作为技术人，我们目标就是将所有人工的操作实现自动化。自动化是我们的方向、思路和技术实现的方式。

InfoQ：一个传统系统，如果想实现运维自动化，您建议应该从哪里先开始呢？

赵成：我建议两个方面上入手：
1) 管理上，标准化，一定要标准先行。这包括OS的基础配置标准化、基础软件（如Tomcat、JVM）配置标准化、应用配置标准化、流程规范标准化等等。做到了标准化，消除了各种差异，才能为后续的自动化开发铺平道路。举个例子，下图是我们Java应用的目录配置标准，全站几百个Java应用都遵循这套标准，那我们的持续集成和发布以及部署，只需要基于这个标准开发一套即可，但是如果每个应用各不相同，那开发和适配的工作量可想而知，到了一定体量之后，就不是单纯的自动化能解决的问题了。

！p1

这里联想到Docker，Docker里面强调到的一个核心理念就是Run Anywhere，为了达到这个目标，Docker提供了一系列的标准技术套件，从而保证各种环境的一致性，这里仔细研究一下就会发现，其实Docker解决的很大的一个问题就是应用标准化，把技术和标准全部统一掉。
原文是：Docker provides an integrated technology suite that enables development and IT operations teams to build, ship, and run distributed applications anywhere.
如下图所示，我们在标准化上下了很大的功夫，做自动化之前，一定是标准先行，标准化一切！

2) 技术和建设上，我想一个渐进的过程应该是，CMDB、应用配置管理和持续集成&发布。
 CMDB，运维自动化的基石，重要性不言而喻。这里特别要说明的一点是，也是外部对于CMDB的一个误解，CMDB不仅仅是硬件和资源信息的记录，更重要的作用是建立起应用和资源对应关系。其它如配置管理、监控、发布、稳定性等等这些运维平台才会有生命力，才能形成体系的力量，不然都将是碎片化的运维模式。

 应用配置管理（上图中的应用服务），CMDB是基础，我们不期望把它做的过重，在前面提到的标准化部分，涉及到了大量的基础环境、基础软件和应用配置的信息，这些信息在后续的自动化的过程中会被使用到，如果更好更便捷地管理起来，这时就需要通过这个应用管理平台维护起来。起初我们把这些信息放到了CMDB的系统中，但是发现实现起来CMDB变成了一个大杂烩，所以后来我们把这些信息剥离出来放到了应用配置管理中，同时让CMDB只提供最基础的资源信息和应用-资源的关联关系。
示例如下，一个Nginx+Tomcat模板的应用，它基线配置管理部分：

 持续集成和发布，从我们自身发展的过程看，在Java应用服务化之后，应用的数量会大大增加，同时迭代周期和速度也会更快，这正是服务化的优势。不过同样带来了问题和挑战，就是对于发布效率和发布过程中服务的稳定性的更高要求。如果这个环节跟不上，会直接影响业务上线甚至是公司商业策略上的执行。所以，CMDB和应用配置管理基础做好之后，一定要优先将这一部分做起来。通过发布系统的开发，我们的DevOps的理念和协作方式也就是这样开展起来的。