运维经验的进化

白鳝的洞穴 2020-11-19

463

运维经验是在实际运维工作中不断积累出来的，一般来说是专家或者用户实际遇到过的案例经过抽象化后形成的经验性的东西，可以在今后运维工作中发挥作用。大多数用户现在的运维经验都是停留在运维人员与专家的脑子里，而老白从2017年开始就逐渐把这些东西纳入到了D-SMART这个系统运维工具里了。

采用这种方法的好处是，运维自动化系统可以不断的积累能力，而不是不断的去优化那些华而不实的用户界面。不过作为一个产品，其中的部分运维经验来自于某些具体的用户，在抽象过程中不免考虑不周，因此也需要通过不断的演进优化，从而让这些运维经验更为精准。

昨天一个客户说我们的一条运维经验在他们那里经常报警，不过实际上他们的系统是没问题的。这条运维经验是“如果Oracle数据库中的进程数比会话数高N%(参数），则数据库可能存在登录风暴风险”。大家都知道，一般情况下我们都是使用独立服务器模式登录数据库，每个会话对应一个进程。一些其他进程的数量不会很多。但是某个进程在登录过程中，会话还没产生的时候，就会出现进程数比会话数多很多的情况。

Oracle数据库的登录过程是十分快的，一般来说是几十毫秒到一两百毫秒，因此在正常的情况下，这种情况很少会出现。不过在某些场景下是会出现这种情况的，一个是出现了不合理的登录风暴，一个应用BUG导致大量不正确的登录产生，会导致创建会话缓慢，登录进程积压。第二种情况是如果某个应用的数据库账号改了密码，而部分应用没有同步修改，而应用中没有针对这种情况进行处置，就会导致不断的创建新进程，而这些进程都无法登录成功（因此只有进程，没有会话），这种情况恶化下去，很快系统的processes参数就满了，一些正常要访问数据库的登录也会被阻止了。

不过这个运维经验在这个客户那边遇到了问题，因为这个客户的有些系统大量使用并行操作，因此配备了数百个并行进程，而这些并行进程在IDLE状态的时候，是不分配会话的，因此被我们的运维经验也计算为有进程无会话的情况了。于是这条报警就经常会出现误报的情况。弄清楚了这个问题后，就比较简单了，不过在优化这条运维经验的时候，我们又做了举一反三的分析。对于Oracle数据库，还有什么情况会出现类似的情况呢？经过仔细考虑后，我们又找到了一个元凶,SHARED_SERVER，这种共享服务器模式下使用的服务进程，通过shared_servers参数可以设置其服务进程数。

比如上面的案例，我们将这个参数设置为100，然后通过v$shared_servers来查看：

这些SERVER的状态都是wait(comm)，这是等待连接的状态。因为我们的系统没有使用SHARED SERVER方式访问的客户端，因此这些进程都是没有分配会话的。通过启动100个SERVERD SERVER，D-SMART的运维经验告警系统自动产生了告警信息：

而此时实际上这条运维经验分析的所有问题本系统中都不存在。于是我们就有了优化这条运维经验的思路，在进程数中去掉空闲的并行进程数和空闲的共享服务进程数，然后再和会话数比较，这样出来的告警就更为精准了。

除此之外，我们还获得了一条新的运维经验，如果大量的共享服务进程的空闲比例超过一定比例（比如90%），并且大量共享服务进程长时间处于空闲状态，那么系统的共享服务进程配置是不合理的。

大家看，运维经验就是这样不断的积累的，也只有不断的这样去积累运维经验，运维才不会总是在原地打转转，运维自动化也不会成为花架子。

数据库

文章转载自白鳝的洞穴，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

运维经验的进化

评论