自动化的锅还是人为的锅，是个问题

欢迎大家来到IT世界,在知识的湖畔探索吧!

前言

我们推广自动化（参考前文）已经有一段时间了，在实施和使用过程中发现，使用何种技术不是最重要的，规范和模式才是重点。目前一些应用变更和日常操作也已经用自动化来实现。

原来命令行和复制黏贴的方式已经逐渐被规范化的流程和图形界面替换，技术人员只需一键启动即可执行相应的指令步骤；我们将来可以做到定时触发变更任务，以短信或者其他方式通知技术和业务人员当前变更的进度，实现变更无人化和智能化的高级阶段。

当然，自动化带给技术高效的同时，也会有不确定性的意外发生，毕竟没有人工的掌控，这就需要我们在使用时由外到里循序渐进，由外围到核心的理念去推广。自动化最害怕的问题就是，一用自动化就有问题而用人工操作就没问题，近期我们就遇到这样一个比较奇怪的现象，特此记录总结。

问题

最近我们上线一个应用，在开发测试环境使用自动化流程很顺利，从开始、介质检验、上传、备份、停服、升级、启动到巡检校验每一步都一气呵成，然而到了模拟环境和生产环境却碰到了问题。

在模拟环境当流程跑到服务启动这一步的时候失败，但是登录到目标服务器通过手工操作拉起服务却是正常的，难道是自动化有什么问题？我们用自动化单节点分别又重新执行了一次停止和启动也正常。当时怀疑是环境问题所以也没有细查，毕竟环境问题也是变更中屡见不鲜的，而且模拟和生产环境不是一比一，但是到生产环境仍然存在这个问题，我们必须要解决这个问题了，否则自动化变成了半自动化是我们不愿意看到的！

分析

程序启动失败，那当然是从分析启动日志开始了，日志中发现有数据库打开失败的报错，Oracle的错误码是ORA-12516，很明显这个错误是由于超过数据库的连接最大值导致无法链接登录数据库，然后我们又查了数据库的链接数的最大配置的procress的参数值和占用值。命令如下

• Processes链接数查看：show parameter processes
• 查看当前链接数占用：select count(*) from v@process;

通过查看链接数在服务启动后占用情况并没有超过最大值的配置，我们陷入了愁思，既然启动没有把processes占满，那是什么原因导致的呢？用自动化跑流程的时候报错，而手工登录到服务器去单独拉起服务的时候反而又是正常？

我们把注意力往前移，从启动的前一步也就是从升级这一步去排查，分析了升级包的介质中所有人为主动关于数据库操作的命令都没发现消耗大量链接的操作，最后排查到一个不起眼的命令

• exec UTL_RECOMP.recomp_parallel

这个命令的作用是并发编译数据库无效对象的，如果没有传递任何参数则是在全库范围内编译无效包，并发进程数会受oracle并行参数parallel_max_server的影响，当编译完成后会释放占用的链接数，该命令一般都是技术人员放在升级的最后，去检查并编译无效包的收尾常规动作，所以一般都不会引起足够的重视。

找到了关键点，问题就清晰了。之所以启动服务失败，是因为数据链接数不够，而升级的并发编译动作耗光了有效链接数，因为PROCESSES 为连接Oracle数据库的最大进程数，该值包括了所有后台进程和并发进程，并发进程占用过高，那么剩下的可用进程就不够了。之所以手工去拉起服务成功，是因为手工登录服务器和排查日志分析错误等动作消耗的时间足够并发编译动作的完成了，而自动化上一步和下一步的衔接耗时为秒级甚至毫秒级基本可以忽略不计，没有时间等待并发的释放链接数，这时去拉起服务自然就导致可以用链接数不够，故而失败了。

解决

找到是链接数的真正原因，那么制定解决方法就多了，可以增加数据库的process或者parallel_max_server参数，也可以在调用编译失效包时传递并发数的参数等等，我们是调低 了parallel_max_server的参数设置，确保正常使用的链接数够用即可。不过在此之前为了验证我们的猜想，我们直接执行了exec UTL_RECOMP.recomp_parallel命令，同时用select count(*) from v@process; 命令观察当前链接数占用情况，发现直接打到了parallel_max_server参数设定的值，可见编译无效包确实非常占用数据库并发链接，不过很快就释放掉了。

结语

一个问题的产生可能会导致对现有模式的否定，碰到人工操作可以，而自动化操作失败这样的问题我们会自然而然的产生会不会是自动化不可靠的疑问，这也是常理之中的。我们作为管理者和使用者，要清楚的认识到，任何一个新的技术引进都会对原来已有的习惯和模式带来改变，但是不应该因为某个不确定的问题就否定的自动化带来的高效和规范化，就像世界杯引入了高科技VAR的判罚系统，1.88毫米可以让日本逆转西班牙！

同样此次的变更问题可能就是在人工操作和自动化操作秒级和分钟级的差别导致，人工操作的时候在升级步骤中编译无效包的时候占用的链接数在人工为下一步操作准备前就释放了，而自动化很快，下一步启动的时候链接数还没释放所以导致报错。可能这秒级的问题会让一部分人放弃技术的引进或者怀疑技术的不可靠，但是我们始终坚持找到问题的真正原因才有话语权，有的时候规则可能给人带来不习惯，但是我们要学会尊重规则，尤其是技术人员要有打破砂锅问到底的执着精神，这样安全生产才不是一句空话。

来源微信公众号：思快奇