运维系统须具备五个维度，全面自动化应分步实现
很多企业都认识到自动化运维的重要性，这是走向规模扩大化的必经之路，同时可以减轻运维工程师的负担。一个完善的运维系统应该是怎么样的？运维系统实现全面自动化应该怎么做，从哪里开始？
带着上述问题，InfoQ对蘑菇街运维经理赵成进行了专访，并将内容整理成上下两篇。赵成有着八年的运维经验，积累了非常丰富的电信级和互联网业务研发和运维经验；为2015年ArchSummit北京站的明星讲师，并著有《蘑菇街DevOps实践及心路历程》一文。
这是个比较大，但是非常好的一个问题。这个问题大，是因为它可以转译为运维的范畴问题，简单说就要讨论运维到底是做什么的。
如果这问题没有思考和解释清楚的话，那么对于一个非运维同学，从外行的视角看，往往会简单粗暴地认为，运维就是搬机器拉网线的，高级一点的会熟练地编写Shell、Python和Perl脚本。
而如果一个运维同学对这个问题理解不清楚，那么短期内将会影响他在工作中的定位，长期会影响他的职业道路的发展和选择。
所以，我想还是要花些篇幅把这对这块的理解讲清楚。
关于运维的范畴，我的理解总结下来应该包括五个维度：效率、稳定、安全、体验和成本。其中效率和稳定可能是运维同学最本职最应该优先做好的事情；安全、体验和成本是运维同学在基础做好的前提下，能够更进一步的方向。下面详细说明一下：
(1). 效率
运维自动化的目标就是解放运维的生产力，提升运维效率，降低人为失误，把运维的能力沉淀到运维的技术平台上，让周边的人和系统依赖的是运维的能力，而不是运维的人，同时运维的同学可以有更多的精力去做更有价值的事情。目前业界自动化的解决方案非常丰富，也形成了一定的方法论和套路，所以建议多借鉴业界经验，优先把这些问题解决掉。
(2). 稳定（质量）
这部分目标是最大程度地保障系统的稳定性和运行质量。即使出现问题，也能够快速发现、快速响应、快速（自动）恢复。
(3). 安全
(4). 体验
(5). 成本
运维工作者需要考虑到服务器CPU资源利用率的提升（引申出来各种虚拟化、容器或云资源的使用）、IDC&CDN流量带宽使用的管控，还有人力的投入和成本的管控。如何使得系统能够更高效地被充分利用起来，如何能够最大限度的减少成本支出，是我们必须要去考虑的问题。
小结：
以上提到的几个维度，在一个公司里，包括蘑菇街，都会有不同的专业团队来承担，比如我们就有安全团队、稳定性团队等等。但是在日常工作中，运维团队跟这些团队是不分彼此的， 因为每一项工作或项目最终要以线上实际现状为导向，而运维是最清楚和了解这些细节的，同时最终产品或功能都要通过运维来落地和运营。
所以，以上的几个维度不是孤立存在的，而是相互影响和互为依赖的。比如如果实现了效率高、稳定性好、体验优越、安全等级高；那么必然地，系统更加容易管控，成本（硬件、带宽和人力）会下降。再比如，稳定性相关的工作比如全链路、容量评估做的好，提升体验的工作开展起来也更加方便。所以，运维是贯穿整个软件生命周期的持续性工作，对待运维工作也必须要有更全局的视角。
此外，当业务体量增长到一定程度时，运维体系和运维效率如果不能匹配地支撑，一定会阻碍业务发展。因此，在技术团队中一定要 对运维有一个正确的理解和定位。
(1). 一定要标准先行，做到技术的标准化。这包括资源标准化、OS的基础配置标准化、基础软件（如Tomcat、JVM）配置标准化、应用配置标准化、流程规范标准化等等。做到了标准化，消除了各种差异，才能为后续的自动化开发铺平道路。
举个例子，下图是我们Java应用部署和目录配置标准，全站几百个Java应用都遵循这套标准，我们的持续集成、发布及部署，只需要基于这个标准开发一套即可。反之，如果每个应用的套路各不相同，那开发和适配的工作量可想而知；当系统扩大到了一定体量之后，就不再是单纯的自动化能解决的问题了。
目录配置标准：
这里谈谈Docker，Docker的一个核心目标就是-Develop,Ship And Run Any Application, Anywhere.为了达到这个目标，Docker提供了一系列的标准技术套件，来保证各种环境的一致性。所以从根本上讲，Docker解决的是应用标准化问题，跟上述我们所说的思路不谋而合，异曲同工，但是Docker的抽象层面更高。简单说明一下：
a、熟悉Docker的同学都知道，下图是Docker容器的High Level架构图，其中的Docker Engine的作用就是屏蔽和隔离应用与基础设施的耦合，从而让应用可以Develop,Ship And Run Anyweher.这里Docker做到了基础设施向上层提供的服务的标准统一。
b、再进一步，Docker Engine提供了标准的REST API 和CLI，来与Docker中的Container、Image、Network和Data vlolumes这些对象来交互，从而将Docker的使用方式进行了标准化。
c、跟应用配置关系最紧密的Dockerfile，如果要构建一个Image镜像，这个是最关键的配置，里面定义了标准的语法命令格式和语法规则，从而保证了不管是何种的应用，最终都可以通过Dockerfile的配置模式，从而实现应用构建的标准化。
d、其它类似Docker Registry等也是类似的思路，这里就不展开讲了。
总结下来，可以看到为了做到标准统一，做到发布和部署效率的提升，从而可以催生出Docker这样火热的技术，说明做标准是多么的重要。
蘑菇街为整个运维体系的标准化（如下图）下了很大的功夫，实现自动化运维之前，一定是标准先行，并且要标准化一切！
(2). 接下来在技术和建设上，我想按照顺序来一个渐进的过程应该是：CMDB、应用配置管理和持续集成&发布。
CMDB：这运维自动化的基石，重要性不言而喻。有特别要说明的一点，否则外界容易对CMDB产生错误的认识：CMDB不仅仅是硬件和资源的信息记录，更重要是要建立起应用与资源之间对应关系。建立了这个关联关系，以此为基础，配套着应用配置管理、监控、发布、稳定性等系统的建设，才能最终形成体系化的运维平台，这样的平台才有力量和生命力，否则只是碎片化的运维模式。
应用配置管理（上图中的应用服务）：
前面提到的标准化部分，涉及到基础环境、基础软件和应用配置的信息；这些大量的信息在后续的自动化过程中会被使用到，需要借助应用配置管理平台更好更便捷地管理起来。
这里需要提示一点：让CMDB只提供最基础的资源信息和应用-资源的关联关系，不期望把基础的CMDB做得过重。起初蘑菇街把这些信息放到了CMDB的系统中，但是实现起来后发现CMDB变成了一个大杂烩，因此后来把这些信息剥离出来放到了应用配置管理中。
示例如下，一个Nginx+Tomcat模板的应用，它基线配置管理部分：
持续集成和发布：从我们自身发展的过程看，在Java应用服务化之后，应用的数量会大大增加，同时单个应用迭代周期和速度也会更快，这正是服务化的优势。
不过也带来了挑战，即对发布效率和发布中服务稳定性产生了更高要求。如果这个环节跟不上，会直接影响业务上线甚至是公司商业策略上的执行。
因此，CMDB和应用配置管理两个基础工作做好之后，一定要优先将这一部分做起来。通过发布系统的开发，我们的DevOps的理念和协作方式也就是这样开展起来的。
画外音：赵成老师策划了《运维创造价值的时代》的专题，会于ArchSummit全球架构师峰会2012北京站与大家见面。
关注高效开发运维长期领取优质文章补给~