论运维自动化：不同阶段有不同难点，技术要适配业务

运维 自动化运维 DevOps

很多企业都认识到自动化运维的重要性，这是走向规模扩大化的必经之路，同时可以减轻运维工程师的负担。一个完善的运维系统应该是怎么样的？运维系统实现全面自动化应该怎么做，从哪里开始？

带着上述问题，InfoQ对蘑菇街运维经理赵成进行了专访。赵成有着八年的运维经验，积累了非常丰富的电信级和互联网业务研发和运维经验；为2015年ArchSummit北京大会的明星讲师，并著有蘑菇街DevOps实践及心路历程一文。在即将到来的12月份2016 ArchSummit北京，赵成担任运维专场《运维创造价值的时代》出品人。

受访嘉宾介绍：
赵成，花名谦益，近10年研发和运维经验，期间非常有幸见证和参与了几个电信级和互联网产品从无到有的创造，从微量到海量的成长过程，个人也随着产品的发展壮大，经历了多轮炼狱般的磨练和蜕变，积累了非常丰富的电信级和互联网业务研发和运维经验。现在负责美丽联合集团（原蘑菇街、美丽说和淘世界）运维团队的管理以及运维体系建设工作，专注于运维创造价值，以及云计算时代运维的转型和突破。

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应用都遵循这套标准，我们的持续集成、发布及部署，只需要基于这个标准开发一套即可。反之，如果每个应用的套路各不相同，那开发和适配的工作量可想而知；当系统扩大到了一定体量之后，就不再是单纯的自动化能解决的问题了。

目录配置标准：

这里谈谈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的理念和协作方式也就是这样开展起来的。

InfoQ: 技术上具体而言，运维自动化难点有哪些？蘑菇街在运维自动化的过程中，遇到过最大的挑战？

赵成： 运维自动化的难点，我想应该是分阶段的：

1) 第一个阶段，是无到有的基础建设阶段，这个过程中，可能最重要的是第3个问题回答的部分，如何能够开展起来，这一阶段我们也是摸索了一段时间，不断地学习和交流，也借鉴了业界的一些优秀经验，从一头雾水到思路明确，关键是还是摸清楚这样一套体系应该怎么样的，应该怎么起步，方法上主要还是学习和交流，所以这样看下来，这个阶段技术不是难点，更重要的是在规划上要做好。

2) 第二个阶段，运维场景的整合阶段，也就是当前业界所提到的场景化运维这样一个思路，同时也是我们当前正在经历的一个阶段。这里直接拿一个我们最常见的应用扩容的实际场景举例，对于扩容这样一个需求，乍看上去，就是分配几台机器然后上线，但是对于一个大型的互联网系统来说，这样一个原生需求分解下来，通常会涉及到以下几个环节，机器申请、机器审核、机器分配、基础环境初始化、应用环境初始化、代码部署（涉及到前端的，还要有关联部署）、VIP配置变更、DNS配置变更、ACL策略配置（DB&网络）、应用启动、端口&服务状态检测、应用服务注册上线、线上业务引流、监控和告警指标检查。Ok，这样一个复杂的过程，其中的每一个点都是一个自动化的环节，可能都会有一个自动化的工具平台或脚本支持。所以可以看到，一个应用扩容的原生需求场景，在实际执行时是需要拆解成很多的原子操作，每个原子操作又可能是不同的人来负责，同时随着业务、稳定性和安全要求的变化，可能还会相应的原生操作的增删改需求。所以这种情况下，我们必须要通过对现实运维工作场景的提炼和抽象，归纳出所有的运维场景，通过流程和规则将以上的原子操作进行串联和整合，从而使得运维和开发同学只需要面对某一个场景，当场景触发后，通过流程和SLA自动化或自助地驱动每个环节的完成，而不是靠人去找，或者靠人去盯着驱动，整个技术团队依赖的是运维的能力，而不是运维的人。

所以这个阶段，总结下来，技术仍然不是最大的挑战和难点，难点是对运维场景和业务的理解，考验的是运维业务分析、抽象、归纳和整合能力。

3) 第三个阶段，智能运维阶段，比如智能告警、故障自愈、运营辅助决策等，我们前面提到的稳定性、体验和成本，也很大程度上依赖这个阶段的建设工作，因为这个阶段我们正在尝试，不能说有很多的实践经验和成果，所以在此就不在班门弄斧了。有兴趣的同学可以看一下腾讯的蓝鲸和织云两个运维体系，或许可以有更多的收获。

不过我想在这个阶段，技术上的挑战性将会是非常大的，因为智能化决策离不开数据支持、规则的建立，所以大数据、机器学习以及各类决策算法应用的引入将会是比较大的挑战。

InfoQ：你们运维团队规模和职能的演变过程分别是怎样的？

赵成：在2013年之前，我们并没有专职的运维同学，当时业务和资源体量并不大，系统也没有很高的复杂度，都是开发同学承担日常的运维工作。

2013-2014年底，我们3名专职的运维同学，基本什么事情都做，主机、OS、网络、应用、Cache、DB等等都要负责，属于全能型选手，有一些简单的运维系统和平台来做日常工作的支持，但是大部分仍然要靠人工处理。

2015年之后，随着业务快速发展和体量规模的日益庞大。首先，驱动着我们的技术架构发生了如下的几个重要有变化：

1. PHP开始转向Java服务化：从原来的Url接口调用转变成了RPC的调用方式；我们的Java服务化框架Tesla正式大规模上线到生产环境；线上应用的数量也从原来相对单一的PHP一套代码和应用，快速分解为几十到上百个应用。

2. 中间层技术方案转向中间件技术方案：早期采用了缓存中间层、DB中间层等；为了解决连接数这个主要问题，开始转向专业的中间件技术方案，比如消息中间件Corgi、分布式数据库中间件Raptor、以及分布式存储MoguCache等解决方案。

3. DB分库分表：随着数据量的急速增长，开始朝着分库分表的方向发展，比如商品和交易，目前已经做到了8个分片；同时对于大量的离线或者冷数据，转向了HBase这样的技术解决方案。

4. 虚拟化和私有云技术引入：为了提升资源利用率和部署效率，我们引入了KVM和Docker的虚拟化及容器技术，并以此为基础打造了我们自己的私有云平台。

业务技术的快速发展，运维面临的挑战难度系数直接指数级上升。如果运维体系跟不上，业务开发的效率和业务运行的稳定性将收到直接影响。所以也正是在这个阶段我们开始思考如何从整体上去规划运维体系和架构，从而能够快速的适应业务技术架构的发展。到目前为止，我们运维体系的调整变化有如下五个方面：

1. 基础部分：管理上标准化的落地，技术上CMDB、资源管理、应用配置管理以及应用上下线等日常基础工作自动化的建设。关于这一块内容，大家可以看一下我在2015北京ArchSummit峰会上的分享内容。

2. 效率：持续集成&发布系统的开发，能够支持线下和线上多环境、预发和Beta多版本的管理和发布；同时能够跟日常项目管理结合，从项目维度来管理集成和发布的规范性。具体内容大家可以看一下我在ArchSummit微课堂交流群里的分享。

3. 稳定性：如前面提到的全链路系统、容量评估系统、开关系统、限流降级系统、预案系统等等，也是稳定性团队与运维团队共同协作的成果。相关内容可以参考我的同事苏武在今年深圳ArchSummit峰会上的分享。

4. 监控系统：开发了Setnry监控系统，支持应用为维度的自定义和自助式的配置（注：Setnry由监控系统团队同学负责主要开发，运维同学参与技术和产品需求的设定。）

5. 用户体验：如ATS静态化，以及ATS在私有云和公有云结合的混合云解决方案。在今年618的时候，公有云支持了我们详情页和会场页三分之一的流量，用户体验大大提升。关于这一块，可以参考我的同事无锋在今年北京QCon上的分享。

好了，最后回到问题上来，团队的规模和职能的演变，是随着要做的事情而变化，而不是单纯地去扩大人力规模。目前我们团队分为4个小组，20人左右的规模，每个小组都是在领域内有非常高专业程度的同学组成。

1. 基础运维团队：负责IDC、主机、OS以及其他硬件方面的运维工作
2. 应用运维团队：负责应用的日常维护工作，以及稳定性保障和性能优化
3. DBA团队：负责线上DB的稳定和安全，以及DB的自动化运维
4. 运维开发团队：负责运维体系和自动化的开发和建设工作

InfoQ: 您有哪些给运维同学的建议？

赵成：下面谈一下对运维同学职业方向和发展的建议吧。以基础运维和应用运维为例，我们在职责划分和职业方向上规划时，一直在强调：我们不能简简单单的把自己定位成是被动响应或者是开发的延续；如果是这样定义，那只能是别人说什么我们就做什么。我们应该要从单纯运维向技术运营的方向去发展：要把日常运维工作中做的事情不断地总结归纳，提炼出有价值的产品功能和需求；进一步要能够具备一定的产品设计和系统规划能力，从而向运维开发、稳定性、监控等周边团队提出我们的需求（也只有运维能够准确地提出这样的需求，因为只有运维对线上的痛点最有感触，并且对系统的整体性把握度也最高），与周边团队形成指导和协作的状态；同时产品和系统落地使用后，我们能够通过产品和系统的使用和数据的分析，更好地指导应用和业务如何优化做设计和开发。我们认为这样一种协作模式才是真正的DevOps，我们期望的DevOps是一种团队理念和协作模式，无时无刻不在我们的日常工作中体现着。

所以，只要是对业务发展和稳定性有益的事情，同时又是跟运维相关的，我们都是会支持的。如上所说，运维的同学如果能够很好的把握住设计和运营的方向，就非常容易成长为一位运维架构师甚至是业务架构师，从而也把自己的职业发展空间打开了。

当然，有些同学的技术能力非常强，喜欢钻研技术，从业务体量和并发量上说，我们的基础部件如LVS、Nginx、JDK、Tomcat等等都仍然有很大的优化空间，还有哪些非常好的技术可以落地来支持我们的业务，只要能落地，如果感兴趣，去搞吧。同时，一些前瞻性的技术，如数据分析、数据建模、机器学习，也是很好的学习方向。我们是100%鼓励技术专家的这个成长方向。

不过这里最后还是强调一点，我们做的任何事情和使用的技术，一定是从业务现状和问题出发去选择技术，而不能拿技术来要求业务进行适配。凡是不以业务为出发点或者不能够跟业务相结合的技术，就不会有生命力。切记！

InfoQ: 运维人员需要学习哪些知识去提高自己的价值呢？

赵成：对于运维新手们，一定要学习编程，数据结构、算法和设计模式一样很重要（未来的运维如果不懂开发、不懂架构，对于后面的发展极为不利）；同时对于网络、硬件、OS这些基础知识也要打好扎实的技术。我建议大家可以看看Google SRE这本书。这里想说的是，Google SRE的要求是要比开发的要求要高很多的，不仅仅要具备开发能力，对网络、硬件、OS这些也要具备才可以，不懂这些你只能当开发，是做不了SRE的，同时SRE还要定期与业务开发轮岗去写业务的代码，出现问题的时候SRE是可以不依赖开发直接改代码来解决问题的。

对于运维老司机们，因为工作背景的原因，在写代码上或许没什么优势，但是在这个行当里摸爬滚打这么多年的经验就是最宝贵的财富。不过怎么样能够更好地将经验转化成优势，就需要注重产品设计和系统规范能力；同时可以去主动学习一下大数据分析、机器学习这些前沿技术的应用，如何能够应用到日常工作中过来，也是会大作为的。

总体而言，运维的同学不要给自己设限，凡是跟工作相关的技术、原理和业务都可以深入下去摸个清楚，一段时间后，一定可以有成长。

InfoQ：感谢赵成老师接受我们的采访，期待ArchSummit全球架构师峰会上您策划的运维专题。