无论是系统运维，还是应用运维，均可分为“纯手工”—> “脚本化”—> “自动化”—>“智能化”几个阶段，其中自动化阶段，主要是将一些重复性人工操作和运维经验封装为程序或脚本，一方面避免重复性操作及风险，另一方面提高执行效率。在自动化运维的转变过程中，经常使用的可能就是shell脚本了，今天主要分享下shell脚本开发在运维工作中的一些经验总结。
小脚本有大智慧，别小看几十行代码，夹杂着系统设计、代码规范和操作经验等等细节，在建设自动化运维的工作中，还是很值得我们研究学习的，下面总结这些也都是源于各位脚本达人和我们在自身工作中“遇到的坑”、“摔过的跟头”和“排过的雷”，与大家共享。
这里主要介绍并参考我行已经形成的一些shell编写规范，编写时严格遵守这些规范，不仅使编写人受益，同时也能提高使用者的执行效率。
2）脚本编写时，注意格式对齐，如所有的循环或者判断语句前后的语句进行对齐，以及case的选取完全，如：
3）脚本开头执行时，执行如下命令，在执行过程中若遇到使用了未定义的变量或命令返回值为非零，将直接报错退出：
4）建议将命令行的每个参数放在单引号、双引号中，特别是rm、mv等可能对生产现有数据造成修改的操作，建议使用垃圾箱策略：rm操作转意为mv操作，制定文件保存目录，以防回退，并定期清理：
5）命令行中参数需要使用‘*’、‘？’通配符的，应依据最精确匹配原则，如能确定文件、目录名称的前缀、后缀、扩展名及其他可识别关键字的，须在参数中包含该信息，如能确定文件、目录的长度应使用‘？’通配符，不得使用‘*’，推荐的使用方式：
不推荐使用的方式：
禁止使用的方式：
6）给数值型变量的赋值后，需由手段保证变量的值为数值型，避免在后续的处理中出现异常：
7）在判断条件中使用的变量，必须包含在双引号中，如：
禁止使用的方式：
8）对文件进行打包备份时，必须使用相对路径进行打包，如：
严禁将全路径打入tar包，如：
9）对于打包后还需进行压缩的文件，建议使用管道进行处理，如：
不建议两部分分开执行：
10）使用ps命令筛选进程时，如能确定进程所属用户，必须在参数中指定用户名称，如其输出作为kill命令的输入，则必须指定进程所属用户，如：
这里介绍的主要是日常shell编写中遇到比较隐蔽或看似简单，却难以发现的“坑”，编写中应尽量避免使用，使用更优的方法避免重蹈覆辙。
1）更新文件使用>不用cp
2）使用kill前确认
关键字用-w精确匹配字段；
kill前后都保留现场,两次ps -ef|grep -w关键字|grep -v grep >>/tmp/kill_进程名_.backup；
删除前要校验，获取进程号是否唯一，避免多杀或误杀的情况。
3）使用rm前确认
删除前备份删除对象信息，避免使用变量，直接使用文件和目录名；
如果必须使用时，删除前，建议检查避免误删，删除目录和文件信息保留：
建议禁用find遍历根目录进行查找，同时删除前进行确认，避免多删或误删的情况。
4）For循环的坑
for循环的in条件按空格来区分，避免进入不正确或死循环。
5）while循环的禁忌
如果还想使用循环中的变量，不要while结合管道使用。
6）慎用cp
这句话基本上正确，但同样有空格分词的问题。所以应当用双引号：
但是如果凑巧文件名以-开头，这个文件名会被cp当作命令行选项来处理。
可以试试下面这个：
但也可能再碰上一个不支持–选项的系统，所以最好用下面的方法：
7）慎用cd
避免使用cd到操作目录再操作的方式，可能导致进入目录失败，误删除，如：
建议如下：
8）用[[ ]]代替[ ]
当$var为空时，上面的命令就变成了[ =”bar” ]
类似地，当$var包含空格时：
[ space words here = “var” ]两者都会出错。所以应当用双引号将变量括起来：
[ “$var” = var ] 几乎完美了。
但是，当$var以-开头时依然会有问题。在较新的bash中你可以用下面的方法来代替，[[ ]]关键字能正确处理空白、空格、带横线等问题。
另注意，[[适用于字符串，如果是数值，要用如：(( $var > 8 ))
9）管道操作中不要同时读写文件
10）cd的易错问题
cd有可能会出错，导致要执行的命令就会在你预想不到的目录里执行了。所以一定要记得判断cd的返回值。
如果你要根据cd的返回值执行多条命令，可以用||。
关于目录的一点题外话，假设你要在shell程序中频繁变换工作目录，如下面的代码：
不如这样写：
括号会强制启动一个子shell，这样在这个子shell中改变工作目录不会影响父shell（执行这个脚本的shell），就可以省掉cd -的麻烦。
目前行里自动化工具越来越多，无论是应用的MAOP或系统的SMDB，自动化实现都还是日常运维脚本的调用，结合日常运维的一些经验，脚本中就更需要考虑周全和控制风险。这里介绍一些结合运维场景的脚本应用，希望规避以前犯过的错，重点在控制风险。
1）支持交互式脚本的应用
很多脚本中需要进行交互，在规避风险的同时，需要通过自动化工具发布来支持交互，可以使用expect，示例如下：
也可以使用curl工具来替代简单的交互：
#FTP SFTP下载
curl-u ftpuser:ftppassword -O “sftp://ftp_ip:ftp_port/pathfile”
#FTP SFTP上传
curl-u ftpuser:ftppassword –ftp-create-dirs-T upfile “sftp://ftp_ip:ftp_port/filepath/upfile”
2）脚本规范执行和日志追溯
直接执行的脚本很危险，要提示用户如何使用脚本，并记录日志以便跟踪。
示例如下：
3)脚本的并发锁控制
避免多人同时执行或并发同时执行的异常问题，建议增加锁机制，示例如下：
4）控制脚本不退出的风险
周期频繁执行的脚本，需要防止脚本hang住不退出，导致后续脚本再次执行。
5）避免集中发布脚本造成的风险
使用ftp、sftp传输、下载文件，或者集中访问存储端口时，尽量增加发布对象散列，避免集中操作造成存储端口拥堵，跨防火墙流量超限报警等影响。
6）避免文件无限增长的风险
向一个文件中追加数据时，一定要设置阀值，必要时清空，避免文件无限增大：
目录增加清理过期文件策略，避免产生的文件越来越多，造成文件节点用尽:
目录中的文件过多，会报参数太长错误无法删除，建议放在循环中遍历删除：
总结：
鉴于以上脚本，我们可以从中汲取一些经验,规避一些风险：
通过增加日志记录输出和脚本执行的方法说明，并自动交互和传递参数，避免执行脚本的操作风险；利用文件锁机制和运维中一些规避风险的方法，使得脚本自动执行起来更便捷更安全。
1. 通过规范类脚本的定义，标准常量定义、清晰的注释、函数和变量大小写用法，细节中可以看出严谨，即使只有几行，也能体现出一名优秀脚本开发人员的素质。
2. 通过易错类脚本中的“坑”，使得 shell面向过程的编写更得心应手，让脚本规范的同时，逻辑也更严谨清晰，避免了错误,也提高了脚本的开发效率。
3. 通过运维场景的脚本应用，规避各种开发和执行过程中的风险，使得shell脚本不仅能支持自动化发布，更可以全面智能化的为运维服务。
往期推荐
设计微服务架构，相关设计模式如何运用？
这份Redis6.0集群搭建教程，项目肯定用得上
4种SpringBoot 接口幂等性的实现方案！最后一个80%以上的开发会踩坑
掌握Git命令的本质，开发时才会得心应手
Shell 脚本进阶，经典用法及其案例
Java 线程池配置的常见误区
优化 Nginx HTTPS 延迟 – 看我如何让Nginx提速 30%的？
在实际项目开发中，你遇到过Spring事务失效的场景吗？如何解决？
请你谈谈Linux中用于文本处理的awk命令？
2.3W字，这可能是把Nginx讲得最全面的一篇文章了，建议收藏备用
各个大厂喜欢用的Hystrix到底有什么优点？
END
若觉得文章对你有帮助，随手转发分享，也是侠梦继续更新的动力。
