供应商秘密"修复"导致关键应用在营业时间无法使用

欢迎来到On Call的另一期内容，The Register的周五专栏，通过分享读者们令人震惊的技术支持故事来改善技术支持生态系统的健康状况。

本周，我们遇到了一位化名为"Raoul"的读者，他向我们讲述了自己曾经担任商业Linux支持顾问的经历。

"我们有一个客户打电话要求我们对他们运行关键业务应用程序的大型服务器进行健康检查，"他告诉On Call。Raoul被给予一周时间来完成这项工作。

客户是一家医疗机构，他们运行的软件是一个复杂的Java网络应用程序，处理包括患者预约、预订管理甚至付款在内的工作。它运行在虚拟机中，基于Postgres数据库、外部存储阵列，跨越三台服务器——其中一台是数据库的热备份服务器。

应用程序运行状况不佳。

"在上午的高峰负载期间，系统会陷入停滞，无响应状态可长达半小时，"Raoul解释说。医疗专家、行政工作人员和患者都要等待应用程序正常运行，这确实是一种不健康的状况。

当Raoul到达现场诊断问题时，他发现现场技术人员正在互相指责。

"虚拟化人员指责存储系统，存储人员指责应用程序，应用程序开发人员指责操作系统，"他说。客户与应用程序供应商的关系也很紧张，因为医疗机构的某人在供应商的支持论坛上发表了不友善的言论，随后出现了法律诉讼威胁。

第二天，Raoul及时赶到现场，看到应用程序在上午10点左右陷入停滞。他检查了应用服务器——运行正常——但注意到数据库服务器非常繁忙。

Raoul保持低调，在工作的第三天等待系统再次锁定。

"我直接前往数据库服务器，看到有人正在运行一个冗长的更新任务，锁定了表行，这意味着所有其他事务都必须等待，"他写道。

Raoul深入挖掘，了解到应用程序供应商发现了他们产品中的一个错误，正在营业时间内在实时系统上修补数据库错误，而没有告知客户。

"我收集了证据，写了报告，并将其提交给管理层，"他告诉On Call。"应用程序开发人员承认他们几个月来就知道这个问题，有一个'几乎准备好'的修复程序，一切都会好起来的。"

Raoul很快了解到情况远非如此，因为在工作的最后两天，他决定对Postgres数据库进行健康检查。

"存储医疗数据、个人信息并处理付款的生产数据库没有访问控制，"他告诉On Call。"它被配置为'ALL ALL ALL'，所以任何系统上的任何用户都可以作为任何用户访问任何数据库。"

这个发现让Raoul感到恶心。

"我几乎从椅子上摔下来，向管理层报告了这件事，他们告诉我开发人员说这是必需的配置，并不担心，"他写道。

"我回家时心里记着永远不要使用那个供应商，"他总结道。

有人向你隐瞒过技术问题的原因吗？不要对On Call隐瞒你的故事！点击这里给On Call发送电子邮件，这样我们就可以在未来的周五分享你的故事。

Q&A

Q1：文章中提到的医疗机构应用程序出现了什么问题？

A：医疗机构运行的Java网络应用程序在上午高峰负载期间会陷入停滞，无响应状态可长达半小时，影响医疗专家、行政工作人员和患者的正常工作。这个应用程序负责处理患者预约、预订管理和付款等关键业务功能。

Q2：供应商是如何"秘密修复"问题的？

A：应用程序供应商发现产品中存在错误后，在营业时间内直接在实时系统上运行冗长的数据库更新任务来修补错误，而没有告知客户。这个更新任务会锁定数据库表行，导致所有其他事务必须等待，从而造成系统在营业时间无法正常使用。

Q3：Postgres数据库存在什么严重的安全问题？

A：生产数据库被配置为"ALL ALL ALL"，这意味着任何系统上的任何用户都可以作为任何用户访问任何数据库，完全没有访问控制。这个数据库存储着医疗数据、个人信息并处理付款，如此配置存在极大的安全风险。