【重磅】运维自动化的最佳实践探索
嘉宾介绍
老王：“互联网运维杂谈”公众号作者，两年电信boss系统研发、五年腾讯运维经历，而后在YY和UC带过业务运维和运维研发。
主题介绍
大家好，这些年来，我经历了不同形态的业务和不同规模的运维，今天我主要和大家分享我这些年来关于运维自动化的一些认识和实践，包括如下八点：
-
自动化需要整体规划
-
自动化的基础是标准化
-
首先从持续交付开始
-
DevOps的四观
-
善于借助研测的力量
-
不一定强依赖CMDB
-
以NO OPS为最终目标
-
Docker等不是干掉运维
以下为详细内容，敬请欣赏。
1.自动化需要整体规划
没有整体的规划始终觉得运维是在建一个个的工具，没法形成递进式的实现策略。
边界的识别是通过分层体系来构建DevOps自动化工具栈，而不是用一个工具解决所有问题，和智锦的观点类似：
千万不要以为puppet/salt/ansible所管理的配置工具能够解决所有运维自动化的问题（不过小企业运维另论哈）。
运维场景是寻找自动化平台实现的驱动力，可以衡量成本和收益比， 不要为了自动化而自动化。
我把其中的每一块都抽象成服务，比如说基础设施及服务（IAAS部分）、配置及服务、流程及服务（ITIL部分）、架构及服务（PAAS部分）、数据及服务、监控及服务等等。
持续集成平台，我把他单独提出来，它很特别：是一个应用交付的主线，他涉及的点很多，自动化编译、自动化测试、自动化部署等等，另外横跨了多个团队，带来的收益很高。
监控及服务也很特别，对于我来说，一切数据都应该有监控的能力，所以我更多觉得监控是一种数据化的应用，和数据分析一样，个人监控观点是“ 先数据、后监控 ”。
我习惯把它们映射到对应的层次上，对每一层的自动化手段都不一样，其实我觉得底层的资源及服务和系统服务层应该越简单越好，最好不要在系统层面上有依赖，比如说特殊的网络设置，特殊的DNS设置。
严格 禁止系统内部调用通过运维系统路径 ，比如说DNS、LVS，目的就是为了 简化服务间的依赖 ，对于运维来说部署一个完整的服务，就要做到部署一个包这么简单。
另外一个维度就是运维场景的识别，业务形态不一样，场景就不一样，逐步挑选对运维收益最大的部分自动化实现它。
正文到此结束
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
