数仓体会之（布署升级脚本与文档）

在项目现场，经常看到运维人员对一些布署升级文档的理解不到位而导致在这过程中出现很多问题，运维人员觉得文档写的不够清楚，操作流程不够详细，而编写文档的研发人员则抱怨运维人员技术水平不够，基本技能不够等等，在此，本着解决问题的态度谈谈一些看法。

一，我们的脚本运行环境尽量一致，能在服务器下运行的尽量服务器环境运行。

尽量的把脚本传输至服务器下运行。客户端环境可能各不相同，比如客户端java版本，数据库版本等不同的原因，会出现各种各样的问题。

二，所有执行命令都应该在文档中详细列出步骤 。

且命令是可以直接copy使用，而不是截图。要想问题尽量少就必须让操作简单，因此，所有步骤脚本在文档上都必须有，运维人员照着一步步执行下去，文档中不应该出现只是一个目标而要靠运维人员自己去想该怎么执行。例如：文档中出现，备份XX用户的xx表，这种只是目标没有执行过程的步骤是应该禁止的。可行做法是，必须文档列出执行步骤，或者脚本中自动实现这些备份功能，而只是要求运维人员运行某个脚本，而运行脚本命令也必须详细列出，总之一句话，不要让运维人员想怎么操作，而就是运维人员照着文档操作就够了。

三，脚本与文档版本分类

例如，全国有国地税，环境可能有aix、linux，因此，对应文档脚本中尽量是运维人员能根据当地的环境情况选择一种版本，而不是统一布署一个版本后再要求里面进行增减的个性化调整，尽量让出错的环境减少到最小。

四，程序与人工权衡方面，程序或脚本上事先编写的复杂来达到操作尽量简单。

尽量通过程序来检测一些操作错误， 例如：脚本运行的用户，可能文档中有说明是哪使用如个用户登录再执行，但运维人员可能错误或忘记用户切换，导致错误用户运行。

五，任何环节都应该考虑可能出错而可以回退上个版本。

考虑数据的备份或上版本程序备份，(上版本程序可能是由于一个大版本后的若干升级版本而存在的），必须进行升级失败回退操作的系统演练。

六，布署升级过程花费时间的考虑

考虑操作对系统的影响性，保证升级过程不会影响正常的业务操作，比如，考虑晚上升级或非工作日升级，针对一些耗时过长是否要考虑分多次多个时间来进行阶段升级。

七、针对脚本出错断点续跑的考虑

脚本执行的错误日志的记录，以及执行步骤多、时间长的内容要考虑断点续跑问题，以减少总体时间达到操作更容易成功。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/134308/viewspace-2140294/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/134308/viewspace-2140294/