自动化运维-谈谈原生态需求

现在自动化运维、DevOps一大堆和运维相关的新名词、新概念层出不穷，一下子让我们这帮技术屌丝们产生了极大的惶恐情绪，仿佛一下子什么都不会干了，什么都不会了。

        在我早期出门和别人忽悠"自动化运维”的时候，会碰到朋友们2种截然不同的反应，一种好像碰到了救世主，认为运维的一切问题能够迎刃而解，简直是拿到了江湖卖艺人的"大力丸”,另一种反应冷淡。

        恰恰是这些反应冷淡的人，让我能够给自己的大脑中放上2个老北京冰棍儿给自己降降温，然后从头思考企业运维的当前需求和未来需求，然后从需求、价值层面考虑运维系统的建设和完善。

        在一个企业中，运维的使命包括:系统建设、控制成本、优质服务、风险防范四个,那么基于这些使命，在运维上要做到的有哪些呢？

        1. 稳定运行   包含变更管理、应急预案、投产演练、业务监控等

        2. 资源管理   资源信息管理、容量管理、性能管理

        3. 标准化      运行规范、系统审计、作业调度、批量

        4. 精确管理   可计量、可视化

        上面这4点内容，还希望同学们帮忙补充完善。

        那么我们从这一点考虑，就会发现，不管是在没有”自动化运维”的5年前，还是有了”自动化运维“的现在，企业的这几个基本需求是不会改变的，那么是否以前的企业运维团队都是傻子，都不知道要做这些事儿？

        不是这样的，任何一个在运维团队的管理人员，脑子里会一直装着这些需求（不像我，脑子里经常有”不能描述的敏感词“），只是以前的能力实现要受限于大型IT公司（例如HP、IBM等等）的产品限制，当然，还有预算的限制。

        现在的世界发生了一些改变，X86+Linux的普遍以及开源世界的蓬勃发展，让大家一下子看到世界上多了很多的可以随时拿过来并且几乎没有预算门槛的工具，比如puppet、saltstack、ansible等等。

        结果，事情从以前的乙方产品推动项目，变成了社区技术推动项目，实际上这2点都是不对的，正确的姿势是技术决定可行性、需求推动项目！

        讲到这一点，我们再想一想我们一直讨论的“自动化运维”能够实现上面4大类里面的哪一些需求，是不是感觉一下子失落了很多？

        当然，现在的新的业务形态，例如如火如荼的“互联网+”给自动化运维带来了新的需求点，就是敏捷响应，那么，我们在来罗列一下自动化运维能够响应的所有需求（这个也欢迎同学们提出指正意见）

        1. 标准化部署

        2. 系统审计

        3. 系统巡检

        4. 敏捷部署

        5. 批量变更

        6. 自动化应急响应

        需求列出来了，那么，是否企业中能够使用自动化运维来实现所有的这些应用呢？ 貌似还不是那么一回事儿，举个例子：

        批量变更，这是自动化运维的一个功能点，但是，目前传统企业中，所有的变更是要遵从“变更管理”的，所以，很多变更只能“一个应用一个应用”的变更，那么感觉上的“批量”，就变成了“小批量”甚至是“微批量”，那么，自动化运维在批量变更上的引入，是否不仅没有降低作业工作量，反而增加了管理复杂度了呢？

        大家回想一下携程的自动化发布乌龙事件吧。。。