本文根据高效运维系列微信群专家群友的观点分享整理而成。“高效运维”公众号做为本系列群的官方惟一公众号，原创并独家首发。java
欢迎关注“高效运维”公众号，以避免费参加「运维讲坛」每个月一次的线下交流活动；并抢先赏阅干货满满的各类原创文章（详见文末）。web
编 辑
李 宁@Taole-深（内容收集&文章整理）缓存
萧田国（审核&发布）服务器
嘉宾介绍
老王：“互联网运维杂谈”公众号做者，两年电信boss系统研发、五年腾讯运维经历，然后在YY和UC带过业务运维和运维研发。微信
主题介绍
你们好，这些年来，我经历了不一样形态的业务和不一样规模的运维，今天我主要和你们分享我这些年来关于运维自动化的一些认识和实践，包括以下八点：网络
自动化须要总体规划架构
自动化的基础是标准化运维
首先从持续交付开始ide
DevOps的四观微服务
善于借助研测的力量
不必定强依赖CMDB
以NO OPS为最终目标
Docker等不是干掉运维
如下为详细内容，敬请欣赏。
1. 自动化须要总体规划
没有总体的规划始终以为运维是在建一个个的工具，无法造成递进式的实现策略。
边界的识别是经过分层体系来构建DevOps自动化工具栈，而不是用一个工具解决全部问题，和智锦的观点相似：
千万不要觉得puppet/salt/ansible所管理的配置工具可以解决全部运维自动化的问题（不太小企业运维另论哈）。
运维场景是寻找自动化平台实现的驱动力，能够衡量成本和收益比，不要为了自动化而自动化。
我把其中的每一块都抽象成服务，好比说基础设施及服务（IAAS部分）、配置及服务、流程及服务（ITIL部分）、架构及服务（PAAS部分）、数据及服务、监控及服务等等。
持续集成平台，我把他单独提出来，它很特别：是一个应用交付的主线，他涉及的点不少，自动化编译、自动化测试、自动化部署等等，另外横跨了多个团队，带来的收益很高。
监控及服务也很特别，对于我来讲，一切数据都应该有监控的能力，因此我更多以为监控是一种数据化的应用，和数据分析同样，我的监控观点是“先数据、后监控”。
我习惯把它们映射到对应的层次上，对每一层的自动化手段都不同，其实我以为底层的资源及服务和系统服务层应该越简单越好，最好不要在系统层面上有依赖，好比说特殊的网络设置，特殊的DNS设置。
严格禁止系统内部调用经过运维系统路径，好比说DNS、LVS，目的就是为了简化服务间的依赖，对于运维来讲部署一个完整的服务，就要作到部署一个包这么简单。
另一个维度就是运维场景的识别，业务形态不同，场景就不同，逐步挑选对运维收益最大的部分自动化实现它。
2. 自动化的基础是标准化
自动化平台必须是经验交付平台，而非技术平台。
技术是经验的一部分，而我想强调的是，作每个自动化平台都须要搞清楚：
本身的自动化平台要解决的问题；
能达到的收益；
使用user是谁等。
我将在后面持续交付平台中继续体现这个思路。
我我的认为标准化能体现你对运维理解的精准度及勇气。标准化的推动很须要运维的勇气，不然无法影响研发按照本身的节奏走：
标准化是让人和系统更有效率和效力的作事：效率是快速的作事、效力是正确的作事。
在UC，我彻底是按照这套方法论和节奏去推动运维工做，自动化必定是随着业务发展而发展的。
更须要指出的是，越到后续阶段，运维工做更是须要和研发、测试深度合做完成，因此运维自动化不能忽略研发、测试。另外：
各个部分对自动化都有影响，好比说标准化部分的配置标准化（让配置管理更简单）；
服务化部分的组件向公共服务组件迁移（服务经过API暴露，让服务的管理更简单）；
无状态化的服务双中心改造，服务高可用也是依赖技术而非人来解决。
接下来举两个小例子。
这个图中两个重要的标准化工做就是配置管理标准化和应用包的标准化，基于此构造的持续部署系统很是简单，不用兼容业务的个性化特色。
很庆幸，咱们把全部的java容器所有迁移到自研的容器上，咱们的容器接管了全部共性的研发服务，好比http服务，缓存服务、配置服务…彻底插件化的服务容器。这是可运维性一个很好的例子。
3. 首先从持续交付开始
有些人问，运维自动化该如何开始？
个人通常建议都是把持续集成或者CMDB做为开始主线。持续交付带来的是多个团队的利益和价值，这个工做能够由运维牵头来解决，运维解决的方法能够先从持续部署开始，而后在对接上面的持续集成：
持续部署系统的建设能够联合研发、测试和运维来建设，方便推广，下降噪音（反对声）。
另外，持续交付系统会反向推进运维内部的一些标准化工做，好比说环境标准化、应用标准化等等，由于你的部署要愈来愈简单。
持续集成+持续部署等于持续交付，实现面向用户产品功能的持续交付。
但持续集成仅仅是面向应用交付的能力封装，还不可以成为运维自动化能力的所有，往上有面向业务的全流程自动化（调度平台，实现任务封装），往下有OS级的自动化（配置管理）等等。
这是我作持续集成系统定的一个业务目标（供参考）。持续部署必需要包含对要管理对象的生命周期的管理、一键化变动管理能力，同时还须要对变动后的结果作到持续反馈。业务和服务拓扑是基于以前配置标准化的一个能力实现，没有放到CMDB中。
当前咱们实现持续部署能力有有两套方案，目前UC使用的基于Cloud Foundry封装的UAE平台。
这种对应用有改造要求的PAAS平台不是太好：
一则太复杂，二则底层服务有依赖（好比agent重启，业务进程也要重启）
第二种方案，就是无侵入的运维方案，把运维对持续部署的控制，封装成标准的事件，你们看看RPM包里面的能力就好理解了，再结合持续集成和持续交付的理念，把他们作成可视化。
4. DevOps的四观
我本身对DevOps的一点认识：
文化观：突破部门墙、深度合做的文化。
价值观：持续优化、共享责任、杜绝浪费、关注用户。
共享责任是合做的内在细化，谈合做太虚无缥缈。
思惟观：精益、价值、跨界、敏捷
工具观：自动化平台集（实现价值的交付）+数据化平台集（实现交付价值的衡量）
为何不是DevTest？为何不是TestOps？为何不是DTO？
我本身的理解是D和O表明面向用户服务能力的两端，两端能力的对接是优化的极致。
运维人不少时候都和开发提运维友好，缺忽略咱们本身要作的东西也要研发友好。因此不少时候不要站在“我”的需求立场上，而是“咱们”.
14年DevOps调查报告，指出要“自动化、自动化仍是自动化”。
运维自动化就是要解决运维团队服务能力的吞吐率和延时问题，也即如何更多、更快的提供运维服务，实际上是和线上的服务能力同样的。
须要思考的问题是，制约咱们服务能力的关键因素，是资源约束（服务器不够）、仍是架构约束（架构公共化能力不强）、仍是运维服务约束（运维基础平台DNS/LVS服务能力）？
这个能够不断的驱动咱们思考DevOps的产品形态和状态了。固然人的意识很重要哈，D/O分离应该走向DO合做。
5. 善于借助研测的力量
运维自动化的工做少不了研发测试的支持，有时候运维复杂的系统封装，结果在研发侧作一些小小的改造就能够了，而后部门墙和彼此的强势文化致使DO是分离，而不是合做。
我举两个例子，配置管理和名字服务。
define.conf是把其余底层配置在研发、测试和生产环境的差别消除掉，底层配置文件中采用变量配置方法，经过define.conf在三个环境中定义具体的值来简化配置管理，持续部署系统就变得极度简单，由于只须要管理一个define.conf配置便可。
由于咱们业务规模很小，因此没有提配置中心，配置中心在规模服务化运维下，必需要构造的一个基础服务。须要研发深度支持配合！
名字服务中心是个人我的情节，终于在UC变成了现实。
我相信不少中小企业的服务调用都是经过DNS获取服务地址来实现调用的，这个缺点就是故障的时候，须要运维深度参与故障处理（TTL、JDK缓存等等）
咱们为此特地创建一个名字服务中心，经过它来实现服务名到实例的具体映射，同时调用端统一实现服务的调度、容错。
如今内部业务故障，基本上不须要运维参与切换和处理了，大大简化运维故障处理系统的复杂度，还有服务扩容的时候，服务自动注册不须要人为修改配置文件，更加的自动化。须要研发深度支持配合！
6. 不必定强依赖CMDB
不要以为CMDB是自动化的前提。cmdb和自动化平台的关系有两种：
自动化平台与CMDB的关联发生在某些场景下的某些流程片断，好比说业务上线流程中的资源自动化申请，从CMDB获取信息。
自动化平台把变动的信息回写到CMDB，好比说应用部署系统／DNS系统／LVS系统等信息，目标是把CMDB做为元数据管理的平台，它能够收敛之上服务之间的数据获取接口。
当前咱们是这么干的，可是发挥做用还不大。特别是业务规模不大，而业务变化不是很是频繁时，CMDB的管理仅仅只须要记录资源被谁，用在哪一个业务上便可。在公有云IaaS平台下，CMDB的形态就更简单了。
7. 以NO OPS为最终目标
运维自动化以挑战每一个运维职责部分的“no ops”为目标，好比说服务器交付／应用交付／组件服务交付等等。
最终这种”no ops”的运维平台可让研发本身去完成（持续部署交给研发），也可让用户来帮咱们决策完成（容量驱动变动）
把这些专业的服务能力可视化封装起来，提供API，供其余关联服务调用，体现自服务能力。每一个人运维人应该带着可视化管理的要求去面对本身的平常工做，这样能够确保自动化的能力每一个人都能获取，而且执行结果是一致的。
8. Docker等不是干掉运维
我的认为对运维的影响不是这些技术，而是基于该技术之上的产品化能力。可是不一样服务能力的结合，爆发出来的能量须要运维人注意：
好比说IaaS平台和Docker技术结合，服务调度和名字服务中心结合，微服务对技术架构标准化影响。
所以DevOps不只仅是对D有Ops能力的要求，对O来讲，也要有Dev能力的要求。另外你们能够看看运维还有哪些工做，就知道这些技术对运维的影响了。
分享结束，谢谢你们。
如何一块儿愉快地发展
“高效运维”公众号（以下二维码）值得您的关注，做为高效运维系列微信群（国内领先的运维垂直社区）的惟一官方公众号，每周发表多篇干货满满的原创好文：来自于系列群的讨论精华、运维讲坛精彩分享及群友原创等。“高效运维”也是互联网专栏《高效运维最佳实践》及运维2.0官方公众号。
提示：目前高效运维两个微信主群仅有少许珍贵席位，如您愿意，可添加萧田国我的微信号 xiaotianguo 为好友，进行申请；或申请加入咱们技术交流群（技术讨论为主，没有主群那么多规矩，更热闹）。
重要提示：除非事先得到受权，请在本公众号发布2天后，才能转载本文。尊重知识，请必须全文转载，并包括本行及以下二维码。
题图来自：老王；做者：老王。