关于运维脚本如何在运维人员之间传承和再利用的问题？

根据企业的规模不同，解决方法也不尽相同。如果企业不是很大，脚本量也不多，建议可以通过管理手段进行约束。如果规模较大，建议选择通过如下手段进行传承和再利用：

1、将脚本编写拟定规范，根据企业实际不断进行完善。例如命名规范、语法规范、适用范围、适用时间等。

2、设立脚本专家团队，对脚本的生产准入进行把关或者直接编写规范和脚本。例如，脚本是否符合规范，是否经过验证测试，规范是否需要进行更新完善等。

3、通过版本化工具管理脚本。不要再将脚本存在自己的个人电脑中，而是将其存在于版本化管理工具中，例如GIT。谁、什么时间、因为什么原因修改了脚本的什么地方，都需要有记录。

4、尽量原子化设计脚本，让脚本功能尽量单一，提高可阅读性和可维护性。

5、注释。企业文化和个人习惯直接其实是有关联的，作为管理人员可以有意无意地培养。

6、通过自动化平台将脚本封装成系统功能，例如某个软件的安装。

大家可以根据自己企业的实际情况逐步解决这个问题。

这个问题很常见，不要说脚本在运维人员间传承，就连自己写的脚本，过6个月，我宁愿再写一个。。。
如何解决，按照软件开发流程，标准化。。。这个不容易，运维工程师有多少是有过开发经验的，那具体如何解决，第一：注释，第二：注释，第三，注释。短脚本不讨论，长脚本编写时按模块，每个模块写清楚作用，实现，接收传递的参数等重要信息，就算读不懂，大不了自己写一个，能实现相同功能就行了，其中模块还能单独拿出来使用。反正我是只读注释，包括自己写的，因为感觉看代码不如再写一遍。

制定规范，写好注释，写好文档，最好有个流程图。然后就够了

在编写脚本的时候就根据既定的规范写好注释，完成脚本后提交脚本的使用手册

按照开发管理过程规范来要求运维开发，包括脚本。

运维人员不是开发人员，团队里没有代码交流的环境，上面没有特别擅长编程的上司，既不能依赖团队合作，也不能获得优秀指导（一看就能帮你发现问题）。因此运维人员不擅长编写、也不适合维护冗长的代码，即使写了，注定就是一个半成品，首先难以推广无法持续改进，对于本人也往往是用完既废的多 。

一个脚本中包含10~20条指令以下，是最佳记忆效果，可以随时修改复用，越用越熟练，越改越完善。 短小才是保持永恒的秘密！因为短小才能为继，为继才能持续优化改进。
代码一长，无论何种注释，对非编程工作环境下的运维人员而言都难以为继。语法规范等各项代码要求虽然好，但是对于运维团队而言，毕竟运维重心不是写脚本，所以也不好苛求。

笔者想说的是，与其为运维团队制订各种代码编写规矩，不如针对运维特色编写一些短小的脚本， 用搭模块的方式组合、调用。尽量让每个脚本变得精简短小。用于设计脚本模块与彼此调用的精力不能少于制订代码编写规则的精力。