运维，请警惕脚本灾难！

过分依赖是脚本，是运维非标准化的体现！脚本灾难，就是运维场景管理上直接依赖大量的脚本来完成事务。
做运维的同学都知道，脚本是一个必备技能，在每个JD的岗位中必然出现。在我们的日常运维过程中，脚本发挥作用的地方也比比皆是：系统管理的脚本；应用发布的脚本；网络管理的脚本；存储管理脚本等等，更复杂的场景也有用脚本封装来实现的都有。仿佛脚本成了运维的大杀器，特别是python语言起来之后，更是一发不可收拾。在某银行客户中遇到，他们运维积累了近两千个脚本，这真的是对的？
今天我们过分依赖脚本作为一种最初的操作入口，对各类对象进行操作，我形象的给他比喻为是过程编程的模式。在大部分客户中，由于自动化运维平台的缺失，脚本还处于混乱的管理之中，这种混乱表现在：无版本管理；无测试管理；无集中管理，还散乱在各个运维人员手中。这种情况下，脚本的灾难不可避免。
随着这两年的自动化运维平台被不断接受，很多客户开始接受平台的管理模式，大家更接受了一种形态是——原子作业库和基于原子作业之上的调度编排。运维开始变一股脑往运维平台中写原子工具，然后通过运维工具来构建复杂场景的运维场景编排。这个地方尤其要注意：这种编排还是一种过程编排的模式。
在这种模式下，大家不知道注意到一个有意思的现象没？复杂的过程编排，存在大量的复杂参数传递，每一个工具都有入口参数和出口参数的设置，调度设置界面非常难以简化。
如果这么复杂，是不是设计上又是错的呢？那错的根源到底在哪儿？方式、方法或者是理念设计上就出现了错误。在这个机制之下，出于脚本安全的需要，我们有必要强化几个能力的管理：
1.版本的管理。让工具的修改有序进行，可以回溯，对比等等
2.工具的开放性管理。工具设置成公开和私有管理，确保工具使用的范围。
3.工具的审核管理。工具的每一次变更，必须通过审核才能入库。
4.工具在流程中的引用管理。调度流程是引用工具，当工具产生修改，不直接对流程产生影响。
最后一点，我要把具体的做法明确一下，就是流程引用的是工具的快照，确保工具发生修改，能够避免对流程带来影响。就如同在AppStore中应用更新，客户可以收到更新的通知，但不代表系统给你立即更新了。尤其注意！！！
这个时候我想说，引起脚本灾难的核心原因：非标准化的过程管理的思维严重，脚本便是最快的是想工具。
那到底如何解决？如何避免脚本依赖引起的脚本灾难？
首先我必须得说，大量不标准的IT对象存在，我们需要接受脚本存在的合理性，而我们必须要面向未来做出一些改变。如何更有效的管理脚本？在之前讲到的引入version control能力，版本化控制，还不够。我觉得更需要引入IT对象管理的概念，把所有的方法附着到对象上，让工具方法自动继承对象的属性，简化工具的参数管理。何为IT对象？从角色出发，所有行程IT场景管理的都可以称之为对象，比如说网络管理员管理的网络设备；系统管理员管理的OS；DBA管理的数据库等等，是一种业务逻辑世界的理解；应用看到的应用系统，应用组件等等。

对于任何对象，从技术的角度来设定的抽象逻辑是：

​

01、对象属性
是一个对象的描述，和面向对象一样，其中包含很多属性与对象的关系。拿主机做例子，
属性维度：固定资产编号，采购时间，过保时间；

关系维度：负责人，网卡、CPU、内存和IO

​

02、对象的方法
对象的方法就是我们平时的管理动作或者场景，比如说主机的重启，主机的启动/停止，主机的回收，主机的申请等等。这些动作比如对其状态和属性产生影响。
03、对象的状态
对象在服务支撑过程中，必然会产生一些状态信息，是一种运行健康状态的表达。
04、对象的事件
事件是一种状态变化产生的结果，比如说状态异常产生的简单事件，如告警，状态经过模型计算产生的复杂事件，比如说容量事件。当然还有一个维度是人工操作事件。
当然提到了IT对象管理能力，如何降低对象复杂度的表述？这就转换成一个IT对象标准化的课题了，是不是逻辑就简单了。对象的标准化是运维必须面临的课题，必须要直面。把IT对象复杂度降低，你的管理复杂度随之下降。
此时对服务编排就有更高的要求了，不限于过去简单的类流程引擎编排能力，需要把过程编排和对象编排（蓝图编排）合二为一。此时提到的蓝图编排方法，我还不提TOSCA规范，那个我依然今天对很多基础设施来说要求很高，毕竟支持TOSCA的基础设施也不多。请对你的流程编排引擎进行升级吧，让他支持对象编排。自定义对象管理库，把过程编排和对象编排的混合编排能力构建起来，从而满足不同业务管理的需要。
总结来说，避免脚本灾难的方式，必须从过程管理模式变成对象管理模式。以对象作为管理视角，为其构建管理方法（或者脚本或者代码），通过对象来收敛管理入口，避免运维人员直面脚本泛滥。同时基于复杂的场景能力，也起到收敛工具脚本编排的作用。

985大学 211大学 全国院校对比 专升本