高质运维：需要运维脚本软件的开发能力
在笔者经验中，从高效运维到高质运维，不可缺少的一环是运维人员的开发能力。
所以笔者历次招聘网络运维、安全运维人员的时候，面试必问有无写过脚本，最复杂的脚本写了多少行，是简单流水账还是分支、循环都用上。
笔试就一定会有一道脚本编程题。
| 笔者： |
国际认证信息系统审计师（CISA） 软考系统分析师 软件工程硕士 |
不过，应届生基本没有这方面能力，面试只能摇头，笔试时这道题都是交白卷。
其实题目也不复杂，几乎没有算法--就只是顺序分支循环三大结构的 SHELL 脚本编程。
题目的根本目的只是考察应聘人能否把比如分开多次手工敲命令实现的，或者是在 UI 上这里点点那里划划实现的过程，转化为脚本。
其次就是考察应聘人能否在根本目的的基础上，进一步地实现通过脚本编程进行纯文本文件的处理，涉及输入输出重定向、管道过滤等基本操作。
至于用什么脚本语言是完全不限。说白了就是 BASH、PowerShell或BAT 都随便，写 Python 能行也可以。
发散的范围严格限定在操作系统范围内，不涉及什么 Zabbix，Nagios 之类的网管软件。
而且还是开卷考试，半天时间可以随便上网查上网抄。
所以这种交白卷的情况，一直让笔者觉得怅然，也可能是高材生都不来笔者曾经所在的这个行业吧。
笔者认为，对运维人员首先要强调动手能力，这是毫无争议的。
但能动手，只是基本要求。
运维人员发挥动手能力，解决运维的技术问题，处置过程的速度快，能应对的范围广，这是高效运维：但也只是人的高效而已，并不是“信息化运维”这个高一级维度视角的高效，也不是高质。
如何达到信息化运维具有高质量，各种信息化治理、基础架构服务管理框架比如 ITIL、COBIT 等等，都不会直接指出要具体做到什么程度。
所以笔者在之前的文章中强调了运维文档（比如操作规程）的质量特性：可用性、准确性和完整性是确保运维质量的前提，并强调了人的因素对质量特性的影响。
而如果要把质量因素具体落实到运维文档的内容，那么文档的内容就应该能体现出以下这些质量要求：
执行过程无歧义、能处置异常情况、可重复执行、执行过程可审计。
稍作解释如下：
1、无歧义：描述的操作过程必须是清晰的，避免模棱两可或含混不清的描述，确保所有运维人员可以准确理解和执行。
2、环境自适应：操作内容需要对不同的环境和条件的适应或调整进行表达，以确保其在各种情况下都能有效执行或中止执行。
3、可重复：流程和操作步骤必须是一致的、可重复的，确保不同人员在不同时间操作时，结果也是一致的。
4、可审计：所有操作过程和变更必须记录在案，确保每一步都有据可查，从而满足审计和合规要求。
要实现这些隐含要求，运维文档就需要实现脚本软件代码化。
运维过程不仅是操作过程描述、操作命令的复制粘贴，而应该是可执行的代码。
因此，运维人员就必须具备运维脚本的编程能力。
这就是笔者考察运维人员的目的。
其实运维脚本的开发也是软件开发的一种，区别于信息系统的开发，有自己的特点：
功能实现单元化、运行过程零交互或较少交互、与运行环境的关联性强、需要高健壮性、输入输出可重定向。
1、功能实现单元化：一个脚本代码单元文件只实现一种特定运维功能。这样可以使脚本代码易于理解、测试和维护，紧扣文档进行版本管理也会更方便。
2、运行过程零交互或极少交互：脚本代码执行期间不需要人工介入，或仅在极少情况下需要人为干预。这样可以增加脚本代码执行效率，实现自动化和批量执行的运维，符合可重复性和可审计性的要求。
3、与运行环境的关联性强：脚本执行期间能够对运行环境（如操作系统、网络配置等）进行探测和识别，动态加载相应预定义的运行配置实现运行。对于不匹配的环境则拒绝运行并告警。这样可以使得脚本能具有运行环境敏感性，避免在错误的环境下的错误执行。反之则是在特定的环境下的执行过程会更可靠，从而提高了运维自动化的可靠性。
4、需要高健壮性：脚本在意外情况下（如错误、故障）能稳定和优雅地处理异常、实现告警，并给出详细的过程记录日志，以支撑事后的回顾排错。这样可以充分增强运维操作的可靠性，使运维过程更加稳定和可预期，更能通过审计。
5、输入输出可重定向：脚本的输入参数能灵活地接受不同的来源比如命令行参数、其它脚本的输出；输出可以定向到不同的目标比如文件、日志系统、监控系统或作为其它脚本的输入参数。这样可以使脚本的运行更加灵活，促成自动化运维流程的集成，实现更复杂的运维功能。同时也是实现可审计的必要特性。
笔者归纳的以上5个特点也同时符合 ITIL 和 COBIT 对服务管理和流程规范化的要求，尤其是符合对这些管理框架对风险管理的要求，可以有效实现降低风险。
按以上特点实现的运维脚本程序，也就符合了运维文档软件代码化内容的质量特性要求。
笔者在公众号/个人网站曾经发布过自己编写的一些运维功能脚本，读者可以作为参考：
其实现在运维脚本软件开发的难度已经降低了很多，因为有了 AI 的支持。
在没有 AI 支持时，比如 PowerShell，不仅要学习其语法，还需要充分了解运维操作以及运维操作对应的 Cmdlet，导致学习曲线的开头部分甚至比许多软件开发语言要陡峭。
而现在只要把需要实现的运维操作详细描述，大模型就能输出大致上正确的脚本代码，结合反复测试和迭代几次后，就可以获得有效的最终脚本代码。
强调“大致上正确”的原因是笔者实测还没发现哪个大模型能一次就输出完全正确的 PowerShell 或者 BASH 脚本，估计是训练语料不足。
例如笔者在编写《高质运维：WSUS 补丁更新服务器优化措施》一文期间，尝试让通义灵码和 ChatGPT4 输出自动设置内存页锁定 LPIM 那段代码，无论怎样反复提示都还是有错，最后的结果只能是自己动手合并和修改这两个 AI 的输出。
所以要做好任何事情，前提还是自己得懂。
本站微信订阅号：
本页网址二维码：