DevOps（开发运维）如今是科技人士挂在嘴边的热词，但遗憾的是，类似圣经，每个人都引用DevOps的只言片语，但真正理解并能执行的人极少。这就像是美女，一万个人每个心中对美女有一万个定义，但是它不能阻挡我们对美好事物的向往和动力。

首先我们在这里还原DevOps事物的本来面目。

百度百科对于DevOps的定义：
DevOps（英文Development和Operations的组合）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运营工作必须紧密合作。

Wikipedia对DevOps的定义：
DevOps是软件开发、运维和质量保证三个部门之间的沟通、协作和集成所采用的流程、方法和体系的一个集合。 它是人们为了及时生产软件产品或服务，以满足某个业务目标，对开发与运维之间相互依存关系的一种新的理解。 ...... DevOps并不仅仅关注软件部署，它是部门间沟通协作的一组流程和方法。

那么DevOps 在你眼中又是怎样的一个存在。近期我们在社区组织了一个有关自动化运维方面的探讨，来了解一下广大的社区会员心中对DevOps是如何理解的，DevOps 距离我们还有多远，企业实施DevOps的都有哪些阻力和困难，哪些企业已经开始涉及，有哪些好的经验值得我们去学习和借鉴的呢，下面内容就逐步的向大家进行汇报。

目前运维现状

目前很多企业还是处于零散的运维状态，每一块可能都有直接的产品，但是很难用一个平台统一管理，系统管理员精力相对还是比较分散。比如存储和SAN网络的自动巡检工作，很多企业还是依靠人工来进行。
我是一名公司服务器管理人员，由于工作繁忙，急需一个可靠性、安全性和操作性都比较好的自动化运维操作管理监控平台，或者是软件，这样我比较轻松愉快的工作。
目前好多都在使用这种人肉运维，感觉可以在运维过程中逐渐摸索需求并将之加以系统实现，在这个过程中最主要还是思维和观念的转变，很多软件只要是界面或者控制台可以操作的，很多提供API的相关接口，可以从简单的脚本化运维，逐渐的改变为web界面的方式，架构模式可以参考Zabbix
总结：很多企业还是处于没有自动化运维，人肉运维，或者自动化程度不高的局面，需要选择适合企业一种或多种相对自动化的运维方式。

自动化运维距离有多远

自动化运维的需求一直都在，不理左右，解决方案或远或近，加强投入的方面可以围绕“提供更多服务、减少更多操作”的思路来进行。
自动化运维本身就是一个不断进化的系统
如果应用系统相对稳定，可以从运维的经验中总结出适合自己系统的自动化运维需求，然后开发实现

总结：从这里我们可以看出来，企业需要自动化运维，或大或小，来解放我们的精力，有时间有能力去做更有价值的事。

自动化运维的困难

系统维护于无形之中是我入行后一直持有的理念，但运维工作如果过于技术化和智能化，某些人会感觉你整日无事可做，这是企业中常有的现象。他们不会看到你在底层所做的各种技术性工作，相反会质问你为什么有那么多的空闲时间。对于这一点，本人近几年深有体会。所以很多时候明明可以费些精力写出的脚本，在这种环境下也会变得越来越懒惰。追求自动化运维的道路不是一帆风顺的，这其中不仅仅有技术能力的原因，更多的则是受企业环境的制约
越来越多的场景下部署了运维自动化软件，主动运维越来越多，更多的场景采用开源软件，运维+开发 运维人员学习的东西越来越多，运维自动化之后，对于运维人员的需求越来越少，如何更进一步提升运维人员学习能力？
运维和开发部门历来属于两个不同部门，甚至有点仇人的意味，相互沟通太少，抱怨太多，很多时候导致整个项目最终效果不好。

总结：不管出于个人的角度还是团队的角度，DevOps是个好东西，但是也有很多困难，在于立场不同，目标不同，沟通和协作的方式，以及公司流程机制的等问题的大环境下必然要面对的问题，要想做好DevOps 是一种思想的转变，配合适合的流程制度协作完成，望大家积极面对。

自动化运维关注点

自动化运维省时省力，如果公司没有强大开发人员，想把一般配置shell或bat脚本做个简单的分装。就是运维人员看到的是软件需要账户密码登录平台，里面是一条一条命令。后端是每条命令对应一个文件夹，文件家里是脚本，需要修改的时候我修改脚本就好了。
请问现在自动化运维一般的内容与范围有哪些呢? 是运维中的所有活动都是自动化运维的目标范畴吗?
近来，devops、一体化运维等新的运维方式和技术倍受关注，那么在传统企业中的运维人员，该如何重构运维流程呢

自动化运维我们有哪些比较好的工具

越来越多的场景下部署了运维自动化软件，主动运维越来越多，更多的场景采用开源软件，运维+开发 运维人员学习的东西越来越多，运维自动化之后，对于运维人员的需求越来越少，如何更进一步提升运维人员学习能力
就市场上开源的各种软件来说，直接拿来部署使用并不能很好符合需求，这里有部分功能开发需求，比如应用自动部署，一键备份，一键启停，界面化运维等，而ganglia、nagios、zabbix部署后，又会有二次封装的需求，这些如果只是运维人员可能很难做成，那么投入开发人员么，几人呢？
通过开发语言实现运维自动化，哪种语言比较好？怎么抉择？
自动化部署和发布应用的一般流程有哪些？
自动化云管理平台如何实现？
等等诸多有关自动化运维管理方面的问题。
总结：面对自动化运维，大多企业还是欢迎的，但是可能由于在这方面起步比较晚，经验还是比较欠缺和不完善，还有诸多问题需要解决。下面章节我们将对以上方面的问题做针对性的介绍和分享，希望大家相互学习，共同提高。

如何完善建设和完善运维自动化

运维小工具介绍

系统部署：aix：nim linux（redhat）：cobbler
日常监控：zabbix oracle：oem ，grid control，elk，Nagios 、Cacti、Smokeping和veemon
网络：dig，netstat，tracert，telnet，ping，smokeping
存储：ibm tpc 和ibm storage manager
动作类：ansible puppet salt
构建类：jekins maven
自定义脚本shell 和python
资产管理平台对于运维还是很重要的，桌面可以使用ocs，微软的sccm，其他的可以使用python 定制开发 如xadmin 等小工具。

选择开发语言

应该先按照自己规划的技术栈来挑选对应的开源软件，然后针对性的选择二次开发的语言。毕竟我们运维的目的是快速达到目标而不是写一个NB的新软件出来。
所以，如果配管方面你选了ansible你就应该用python，选了puppet就应该用ruby；监控方面你选了nagios就应该用perl，选了zabbix就应该用php；日志方面选了logstash就该用ruby，选了heka就改用golang。这都是灵活的。主要还是结合自己企业的环境来做。

自动化运维的范畴

现在很多企业都是一个管理员管理多个业务系统，精力严重的不够。当然还有很多其他方面的事情需要配合处理，如果有一套高效的运维机制和平台支撑，那样解放不少精力。
诸如以下几个方面：

1. 资产管理
   这个工作需要耗费很多的精力，很多企业目前还停留在excel表格模式，还是有很多不便之处
2. 监控
   目前很多长篇可以做到大面上的监控（cpu，内存，磁盘），如果要涉及全备需要很多定制，诸如：应用端口，连接数，业务系统反应慢，诸如sql的定位，存储，ＳＡＮ同一监控等等。
3. 巡检
   巡检工作大多还是手工方面，还是需要人为的去做。
   ４. 软件的批量部署，应用自动发布等

运维自动化参考指标

所谓标准应该是一个模糊的界定，每个企业都有自己的标准，可以参照国有企业等保级别的要求。。
要想提前一步，更加智能的发现问题，加强监控建设无疑是比不可少的。同时还要配置公司相应的问题处理流程。否则发现问题也是每人会及时处理。
监控建设涉及方法面面，重点方面要加大投入。

传统行业如何重构运维流程

感觉每个行业，或者具体到每个企业还都是不一样的。 首要需要CTO 层面如何看待这个事情，或者具体重视到什么程度。
可以参考两个方向：

1. 如果企业足够重视，可以选择一款或者几款比较成熟的软件，在结合自己企业的场景定制一下，基本上是可以满足企业需求的。当然有能力可以直接开发，运维。
2. 如果只是管理员想提高一下效率，恐怕只有使用开源或者小团队独立开发一些小工具来做，在很大程度上也是可以的。完全可以节省很多日常的重复劳动，大大提高效率。需要运维团队有些积累，和使用开发语言的能力。

自动化运维平台选择关注

可以参考几个方面：

1. 首先可以立足于监控层面（cpu，内存，交换分区，连接数，日志严重级别等）
2. 触发自动化处理流程（诸如邮件，短信和具体的问题处理流程环节）
3. 具体到每个环节由具体的人员审核或操作 。
4. 整个环节依次进行，流程清晰。
   当然漂亮的报表功能也可以添加进去，自动邮件发送。

devops的实现形式

目前的国有银行很多都是运维部门和开发部门职责划分明确，在进行运维开发方面进行团队组建，比如开发人员对系统运维缺少一定的经验，而运维人员多数则欠缺开发能力。如果要实现良好的自动化运维的理想方式应该是人员既懂开发也懂运维。这种方式在跨部门组建时往往不是技术细节方面的事情，很多得需要领导层面意识的转变，一方面转变传统的依靠人肉运维的观念，另一方面需要转变部门职责的划分形式。

自动化部署和发布应用的一般流程

自动化部署，每个企业都是不一样的。
目前大多企业还是停留在应用部署，业务停止的级别上，就是停止当前应用，重新发布。
对于一些走在前面的行业，业务场景要求业务是不能中断的，大多还是逐步发布或更新。这样在有问题的时候回退和影响面影响都会比较小。
多大自动发布都有经过几个环节：
开发环境发布----测试环境发布---生产预发布----生产发布
代码管理大多都有统一的管理平台，诸如svn或git 进行。
具体到操作：
刚开始要上传代码包到指定地方，在什么环境发布就需要在什么环境去代码存放地自动获取代码，测试一个周期后，然后在进行下一个阶段的发布环节直至生产发布完毕。
其中很重要的就是功能测试，bug修改，性能监控，代码管理方面。

知识分享与借鉴

本次活动很多社区会员积极分享了一些在实际运维工作当中可以提高工作效率的脚本或工具，在开发自动化运维方面活动或少参与了进去，分享了实际工作的当中的技巧或经验。
主要涉及以下几个方面：

使用SHELL或Python 完成日常监控

• 通过系统或软件命令使用shell或python将关心的信息抓取和展现出来。构成监控。比如内存使用可以使用vmstat来收集到文件中，是为shell
• 如果只是局限于主机性能的监控，那么用shell结合系统命令可以得到系统资源（CPU、内存、磁盘IO等）的利用率（utilization）、饱和度（saturation）和错误（error）度量，然后将结果用正则分解，结果可以做成短信或者存入数据库
• 没有监控软件的企业可以使用python和shell 定制开发一个小巧适合企业的运维小工具。诸如应用端口是否连接异常，OS是否有报错等
• 使用Python编写小工具完成日常应用程序的是否异常监控，异常自动重启
• 使用SHELL完成用户登录操作系统和执行命令的操作记录
• 使用SHELL完成AIX OS系统的健康检查
• 使用SHELL完成WAS 日志的日常巡检

使用SHELL或python完成软件安装

• 可以使用cobbler 软件自动部署redhat操作系统，SHELL 脚本批量初始化操作系统，安装常用软件。比如建立内部yum源，使用脚本批量安装部署软件。
• 使用SHELL脚本完成PowerHA软件和补丁的安装
• 使用python编写小程序
• 使用SHELL 完成AIX OS系统的初始化工作

IBM WAS 中间件的应用发布自动化管理

IBM WAS 中间件的应用发布自动化管理日常使用WAS的过程中，我们主要有两种方式1：jenkins插件：主要用于我们开发的CI/CD的测试开发环境，在完成日构建后即可自动部署war，非常方便python脚本：2 由于生产和测试环境的隔离，在生产环境中我们使用pyhton调用WAS的接口编写了一套部署脚本，这样可以将测试过的war直接自动部署生产环境

目前公司主要使用was 中间件平台，每天都有好几次的应用发布，前期我们平台管理员的工作量非常的大，不胜其烦。后来找第三方基于was 做了一个自动发布的小工具，应用管理员没人会有一个账户，每当需要发布的时候应用管理员在工具里提一个申请，写好应用系统名称和计划时间，上传war包，带平台管理员审核后，让后业务系统在指定时间进行发布，如果生产系统发布会检查这个应用是否已经在开发测试系统上发布过，否则不允许。等等，极大的解放了平台管理员的劳动量。

总结：

这些实际的工作经验都是广大社区会员在通往DevOps 自动化运维的道路上一次次的探索和经验总结，在提高工作效率，完善自我和做好的DevOps的道路上，我们也许还没有什么经验，或许哪里还有所不足，但是希望广大社区会员可以在后续的道路上持续交流，分享经验，共同进步。
我们的目标是：让代码高速运转起来，让工作的幸福指数升起来！