Edit安全
本篇和下篇文章均为InfoQ专访内容。
性能优化
InfoQ：您从事运维行业已经8年了，根据您的我的经验和理解，一个全面的运维系统须要完成哪些工做呢？服务器
赵成：这是个比较大，可是很是好的一个问题。这个问题大，是由于它能够转译为运维的范畴问题，简单说就要讨论运维究竟是作什么的。微信
若是这问题没有思考和解释清楚的话，那么对于一个非运维同窗，从外行的视角看，每每会简单粗暴地认为，运维就是搬机器拉网线的，高级一点的会熟练地编写Shell、Python和Perl脚本。而若是一个运维同窗对这个问题理解不清楚，那么短时间内将会影响他在工做中的定位，长期会影响他的职业道路的发展和选择。架构
因此，我想仍是要花些篇幅把这对这块的理解讲清楚。运维
关于运维的范畴，个人理解总结下来应该包括五个维度：效率、稳定、安全、体验和成本。其中效率和稳定多是运维同窗最本职最应该优先作好的事情；安全、体验和成本是运维同窗在基础作好的前提下，可以更进一步的方向。下面详细说明一下：
(1).效率
这里重点指的是平常运维例行工做的效率，由于这些工做是运维最基础的工做：资源分配&回收、域名配置、VIP配置、持续集成&发布、应用部署、应用扩容&缩容等。一般提到的运维自动化，大可能是集中在这些工做上，由于这些工做偏平常和重复。性能运维自动化的目标就是解放运维的生产力，提高运维效率，下降人为失误，把运维的能力沉淀到运维的技术平台上，让周边的人和系统依赖的是运维的能力，而不是运维的人，同时运维的同窗能够有更多的精力去作更有价值的事情。目前业界自动化的解决方案很是丰富，也造成了必定的方法论和套路，因此建议多借鉴业界经验，优先把这些问题解决掉。优化
(2).稳定（质量）
能够经过监控、全链路、强弱依赖、限流降级、容量评估、预案平台等措施，让业务运行更加稳定。作好这一点，须要有相对比较独立、专业的监控和稳定性平台来支持。spa这部分目标是最大程度地保障系统的稳定性和运行质量。即便出现问题，也可以快速发现、快速响应、快速（自动）恢复。.net
(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、应用配置管理和持续集成&发布。
a、CMDB：这运维自动化的基石，重要性不言而喻。有特别要说明的一点，不然外界容易对CMDB产生错误的认识：CMDB不只仅是硬件和资源的信息记录，更重要是要创建起应用与资源之间对应关系。创建了这个关联关系，以此为基础，配套着应用配置管理、监控、发布、稳定性等系统的建设，才能最终造成体系化的运维平台，这样的平台才有力量和生命力，不然只是碎片化的运维模式。
应用配置管理（上图中的应用服务）：
前面提到的标准化部分，涉及到基础环境、基础软件和应用配置的信息；这些大量的信息在后续的自动化过程当中会被使用到，须要借助应用配置管理平台更好更便捷地管理起来。
这里须要提示一点：让CMDB只提供最基础的资源信息和应用-资源的关联关系，不指望把基础的CMDB作得太重。起初蘑菇街把这些信息放到了CMDB的系统中，可是实现起来后发现CMDB变成了一个大杂烩，所以后来把这些信息剥离出来放到了应用配置管理中。
c、持续集成和发布：从咱们自身发展的过程看，在Java应用服务化以后，应用的数量会大大增长，同时单个应用迭代周期和速度也会更快，这正是服务化的优点。
不过也带来了挑战，即对发布效率和发布中服务稳定性产生了更高要求。若是这个环节跟不上，会直接影响业务上线甚至是公司商业策略上的执行。
所以，CMDB和应用配置管理两个基础工做作好以后，必定要优先将这一部分作起来。经过发布系统的开发，咱们的DevOps的理念和协做方式也就是这样开展起来的。
原文连接：http://www.infoq.com/cn/news/2016/09/DevOps-automation-operation-2
本文分享自微信公众号 - 成哥的世界（forrest_thinking）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。