企业自动化运维巡检管理方案.docx

企业自动化运维巡检管理方案1自动化运维谈谈原生态需求自动化运维、DevOps一大堆和运维相关的新名词、新概念层出不穷，一下子让大家产生了极大的惶恐情绪，仿佛一下子什么都不会干了，什么都不会了。在一个企业中，运维的使命包括:系统建设、控制成本、优质服务、风险防范四个，那么基于这些使命，在运维上要做到的有哪些呢？1.?稳定运行包含变更管理、应急预案、投产演练、业务监控等2. 资源管理资源信息管理、容量管理、性能管理3. 标准化运行规范、系统审计、作业调度、批量4. 精确管理可计量、可视化不管是在没有”自动化运维”的5年前，还是有了”自动化运维“的现在，企业的这几个基本需求是不会改变的，那么是否以前的企业运维团队都是傻子，都不知道要做这些事儿？不是这样的，任何一个在运维团队的管理人员，脑子里会一直装着这些需求（不像我，脑子里经常有”不能描述的敏感词“），只是以前的能力实现要受限于大型IT公司（例如HP、IBM等等）的产品限制，当然，还有预算的限制。现在的世界发生了一些改变，X86+Linux的普遍以及开源世界的蓬勃发展，让大家一下子看到世界上多了很多的可以随时拿过来并且几乎没有预算门槛的工具，比如puppet、saltstack、ansible等等。结果，事情从以前的乙方产品推动项目，变成了社区技术推动项目，实际上这2点都是不对的，正确的姿势是技术决定可行性、需求推动项目！当然，现在的新的业务形态，例如如火如荼的“互联网+”给自动化运维带来了新的需求点，就是敏捷响应，那么，我们在来罗列一下自动化运维能够响应的所有需求1. 标准化部署2. 系统审计3. 系统巡检4. 敏捷部署5. 批量变更6. 自动化应急响应需求列出来了，那么，是否企业中能够使用自动化运维来实现所有的这些应用呢？ 貌似还不是那么一回事儿，举个例子：批量变更，这是自动化运维的一个功能点，但是，目前传统企业中，所有的变更是要遵从“变更管理”的，所以，很多变更只能“一个应用一个应用”的变更，那么感觉上的“批量”，就变成了“小批量”甚至是“微批量”，那么，自动化运维在批量变更上的引入，是否不仅没有降低作业工作量，反而增加了管理复杂度了呢？2自动化运维出错后的风险控制问题以我行实际案例为例，自动化运维确实可以给运维人员带来方便，减轻工作量。但自动运维有一个致命的缺点：操作透明、运维程序出错后容易导致不可逆的生产故障。自动化运维，我们简单来说，有3大类操作：规范遵从、部署、操作变更。部署实际上不会有你所说的风险问题，因为系统还没有上线。规范遵从、操作变更都会产生风险，那么如何降低风险：1. 遵从变更流程， 即便用了自动化运维，也只能在变更窗口进行变更，不能突破企业的变更流程。2. 变更推送，管理员控制变更的动作，而不是系统自己处理，这就是puppet里面说的pull还是push。3. 用了自动化运维，实际上就算是DevOps了，那么你的一个变更动作，要先测试的，puppet中的测试环境，就是干这个用的，先测好，然后小规模变更，然后大规模批量变更。换句话说，就是要“半自动“，而不是互联网那种”全自动“从运维实际出发，其实运维从诞生到发展至今都是为了提供业务稳定，高效的运行，而使用自动化与人工的差别是一种批量化处理大规模性问题与精细化处理对口故障，国外优秀成功的案例就是分而治之，我想用在中国也是很合适的。1.自动化运维机制的制定，针对专业系统制定专业方案，提供相应的运维制度2.人员配备上，将复杂问题简单化，系统问题，专业化，各司其职，互相配合3.开发对口的专业运维系统，将具体的故障问题可视化，故障发生做到事出有源，事后可控。4.强化专业知识技能，面对大规模性事件，做好模拟响应，这个很重要，我们在实验室就是模拟各种灾难...3适合中小银行使用的自动化运维产品想找到一款适合中小银行使用的应用级别的自动化运维产品 主要实现自动巡检 系统信息采集 新系统上线前合规性检查 程序自动部署 生产系统与灾备系统间应用版本比对等功能（chaozi84 北京银行 系统运维工程师）现在可以使用的工具很多，最常用的就是puppet和ansible，在一些银行中都有相关案例。puppet比较适合做状态保持类的工作，建行用的就是puppetansible适合做一次性批量工作但是，我有一些建议：1. 银行中的“批量”工作实际上并没有那么多，这个是受限于银行的变更流程，所以2. puppet+mco也可以实现批量的命令执行，但是，在进行批量命令执行的时候，要注意黑白名单的问题，避免误操作导致大批系统的故障，目前这些工具还不怎么提供黑白名单的功能，这个需要自行开发我在客户现场使用的foreman+puppet+mcollective，然后自己按照客户需求做了定制的界面和定制的功能，包括一些基于安全的风险防范。提问者（