运维Shell开发经验总结》几个阶段，自动化阶段主要是将一些重复的手工操作和运维经验封装成程序或脚本，一方面避免重复操作和风险，另一方面为了提高执行效率，在自动化运维的改造过程中，可能会经常用到shell脚本，今天主要分享一些shell脚本开发在运维工作中的经验总结，小脚本蕴含大智慧。小看几十行代码，夹杂着系统设计、代码规范、操作经验等细节，在构建自动化运维的工作中，还是值得研究和学习的，下面总结这些，来源于《自己工作中遇到的坑”、“摔跟头”、“过雷”，分享给大家欧。这里主要介绍和参考我行形成的一些shell编写规范。在写作时严格遵守这些规范，不仅有利于写作者，也能提高用户的执行效率。1）脚本开头，应有脚本功能说明、参数使用说明、作者姓名、创建/修改日期、版本信息。case的对齐和选择就完成了，比如：3）开始执行脚本的时候，执行下面的命令。如果在执行过程中使用了未定义的变量或者命令的返回值非零，会直接报错退出：4）建议把命令行的每个参数都用单引号和双引号括起来，尤其是rm，mv和其他可能修改现有生产数据的操作。推荐使用垃圾桶策略：rm操作转换为mv操作，文件保存目录，防止回滚，定期清理：5）如果命令行参数需要使用'*','?'通配符，应采用最精确的匹配原则，如可以确定文件名和目录名的前缀、后缀、扩展名等可识别的关键字，参数中必须包含该信息。如果可以确定文件或目录的长度，则“？”应使用通配符代替“*”。推荐用法：不推荐用法：禁止方法：6）给数值变量赋值后，需要保证该变量的值是数值，以免后续处理出现异常：7）判断条件中使用的变量必须用双引号括起来，如：禁止使用方式：8）打包备份文件时，必须使用相对路径进行打包，如：严禁输入完整tar包中的路径，如：9）对于打包后需要压缩的文件，建议使用Pipeline处理，如：不建议将两部分分开执行：10）使用ps命令时过滤进程，如果可以确定进程的用户，则必须在参数中指定用户名，如果将输出作为kill命令的输入，则必须指定进程为用户，如：what这里介绍的是mai日常shell编写中遇到的只是隐藏的或看似简单但难以发现的“陷阱”，在编写中应尽量避免，并采用更好的方法避免重蹈覆辙。1）更新文件时使用>不使用cp>修改回滚文件时，保留原文件的属性组和权限，避免使用cp时权限属性组被修改。2）使用kill前，用-w确认关键字，精确匹配字段；保持kill前后的场景，两次ps-ef|grep-wkeyword|grep-vgrep>>/tmp/kill_process_name_.backup;删除前先检查进程ID是否唯一，以免误杀或误杀。3）使用rm确认删除前备份删除的对象信息，避免使用变量，直接使用文件和目录名；如果一定要用，删除前建议勾选，避免误删，删除目录和文件信息保留：建议禁用find遍历根目录搜索目录，删除前确认，避免冗余或误删.4）for循环的坑for循环的in条件以空格区分，避免进入错误或死循环。5）while循环的禁忌如果你还想在循环中使用变量，就不要把while和管道一起使用。6）谨慎使用cp这句话基本上是正确的，但是也有空格分词的问题。所以应该使用双引号：但是如果文件名恰好以-开头，文件名将被cp视为命令行选项。可以尝试以下方法：但也可能会遇到不支持--选项的系统，所以最好使用以下方法：7）谨慎使用cd，避免使用cd到操作目录再操作，这样可能会导致进入目录失败，误删，如：建议如下：8）将[]替换为[[]]当$var为空时，上述命令变为[="bar"]同理，当$var包含空格：[spacewordshere="var"]两者都会出错。所以变量应该用双引号括起来：["$var"=var]几乎完美。但是$var以-开头的时候还是有问题。在较新的bash中，您可以改用下面的方法，[[]]关键字可以正确处理空白、空格和水平线。另外注意[[适用于字符串，如果是值，使用如：(($var>8))9)管道操作中不要同时读写文件不能读写一个文件同时在同一个流水线操作。根据管道的实现方式，文件将被截断为0字节，或者增长到填满整个硬盘。如果要改变原文件的内容，只能先将输出写入一个临时文件，然后再使用mv命令。10）cd的易错问题cd可能会出错，导致要执行的命令在一个意想不到的目录下执行。所以一定要记得判断cd的返回值。如果要根据cd的返回值执行多条命令，可以使用||。关于目录的一点题外话，假设你想在shell程序中经常改变工作目录，如下代码：最好这样写：括号会强制启动一个子shell，这样改变这个子shell中的工作目录不会影响父shell（执行这个脚本的shell），可以省去cd-的麻烦。目前，业界的自动化工具越来越多。无论是应用的MAOP，还是系统的SMDB，自动化实现依然是日常运维脚本的调用。结合日常运维的一些经验，脚本需要更加周到，控制风险。这里结合运维场景做一些脚本应用，希望能避免之前犯的错误，着重控制风险。1）支持交互式脚本的应用很多脚本都需要是交互式的。在规避风险的同时，需要通过自动化工具发布，支持交互。你可以使用期待。示例如下。也可以使用curl工具代替简单的交互：#FTPSFTP下载curl-uftpuser:ftppassword-O"sftp://ftp_ip:ftp_port/pathfile"#FTPSFTP上传curl-uftpuser:ftppassword--ftp-create-dirs-Tupfile"sftp://ftp_ip:ftp_port/filepath/upfile"2）脚本规范执行和日志可追溯性直接执行脚本是非常危险的。应提示用户如何使用脚本，并记录日志以供跟踪。示例如下：3）脚本的并发锁控制，避免了多人同时执行或同时并发执行的异常问题。建议加锁机制。示例如下：4）控制脚本不退出的风险循环中频繁执行的脚本，要防止脚本挂不退出，导致后续脚本再次执行。5)规避脚本集中发布带来的风险。使用ftp、sftp传输下载文件，或集中访问存储端口时，尽量增加发布对象的哈希值，避免集中操作导致存储端口拥堵，跨防火墙流量过大限制警报和其他影响。6)避免文件***增长的风险在向文件添加数据时，一定要设置一个阈值，必要时清除它，以避免文件***增长：添加一个策略来清理目录中的过期文件，以避免moreandmoregeneratedfiles太多，导致文件节点耗尽：目录中的文件太多，会报参数太长，无法删除的错误。建议循环遍历删除：总结：针对上面的脚本，我们可以从中吸取一些经验，规避一些风险：通过添加日志记录输出和脚本执行方法指令，自动交互并传递参数给避免执行脚本的操作风险；在运维中使用文件锁机制和一些规避风险的方法，让脚本自动执行更方便、更安全。1、通过规范的脚本定义，标准的常量定义，清晰的注释，函数和变量大小写的使用，细节处可见严谨，哪怕只有几行，也能体现一个优秀的脚本开发者的素质。2、通过易错脚本中的“坑”，让shell面向过程的写法更加得心应手。在脚本标准化的同时，逻辑更加严谨清晰，避免了错误，提高了脚本的开发效率。3、通过运维场景的脚本应用，规避开发执行过程中的各种风险，让shell脚本不仅支持自动发布，更全面、智能地为运维服务。
