来源https://stormatics.tech/blogs/the-best-postgresql-databases-are-boring-on-purpose最好的 PostgreSQL 数据库是有意无聊的无聊是一种投资。刺激是一笔账单。生产环境中最平静的 PostgreSQL 部署都有一个共同点它们很无聊。页面保持安静。仪表盘保持绿色。值班工程师在周二晚上安心读书。而运行这些数据库的人会坦率地告诉你无聊本身就是一种成就。暂时想想飞行这件事。每个人都想要的航班是这样的机长打个招呼餐食准时送达几小时后飞机在正确的城市着陆。那次飞行很无聊。但这也是一个小小的奇迹。在那次无聊的飞行背后是数十年的纪律累积。是在模拟器上积累了数千小时的飞行员。是拿着已经执行过上百次检查单的机械师。是空中交通管制员、气象系统、冗余的液压系统以及整个行业都会阅读和学习的事故后复盘报告。乘客体验到的是平静。而其他所有人都在为此付出努力。生产数据库同样值得被这样看待。保持飞行无聊需要什么一次无聊的飞行是巨大冰山露在水面上的可见尖端。证书需要续期。发动机需要按计划检查。手册一旦有新的认知就必须更新。实习飞行员在独自坐在左座之前需要与资深机长一起飞行多年。当世界某个地方确实出了问题时那份报告会成为业内每个运营商的必读材料。这是大多数人在赞叹航空旅行变得多么安全时往往会忘记的部分。安全是一项持续的投资。当一家航空公司开始在无聊的部分偷工减料时航班就不再无聊了。用同样的视角看待 PostgreSQL一旦你接受了无聊是目标运营的图景就会重新组织。一个无聊的 PostgreSQL 部署是这样的autovacuum 针对工作负载进行了调优复制延迟保持在已知范围内备份按照演练过的节奏进行恢复参数反映了当前的工作负载监控有基线容量在增长之前就做好了规划模式在上线前经过了审查并且值班手册是经过实践检验的而不是写完就忘了。清单上的每一项单独看都不起眼。但它们加在一起就是平静的模样。成本账用两个故事来讲述想象两个运行着类似 PostgreSQL 工作负载的组织。第一个组织精打细算。团队很敏锐数据库大部分时间表现得体用于主动工作的预算很少。然后某个周五下午一个长时间运行的查询持有了一个锁导致连接池阻塞。应用程序变慢然后停滞。四个工程师被拉进来。CTO 加入了电话会议。对客户的承诺推迟了。到了周一早上团队恢复了服务并写了一份复盘报告其中提出了六项预防性工作但大部分都会被搁置因为下一次事故已经在酝酿之中。日历上节省下来的钱在一个下午就连本带利地还回去了。第二个组织在无聊的工作上进行可预测的投入。一位资深 PostgreSQL 工程师每周审查慢查询日志。季度健康检查会揪出那个即将成为问题的索引。当写入模式发生变化时会重新审视 autovacuum 设置。值班轮值可能每月只处理一个轻微的小问题而且通常发生在工作时间通常在客户注意到之前就已解决。第二个组织的年度总支出在主动运维方面通常更大但在其他所有方面都显著更小。更低的事故频率、更短的事故持续时间、更少从产品开发中被抽调的工程师、悄然累积的客户信任以及一个随着时间推移而不断改进的架构因为团队有精力去改进它。一旦你加上事故的长期成本客户流失、干扰开发、声誉拖累、无休止的开会这笔账几乎总是倾向于无聊的那条路。大多数运维人员凭直觉已经知道这一点。困难之处在于要在下一次事故证明这个观点之前说服决策者为此投入。图片文字反应式运维日历上可预测的节省事故期间不可预测的开支资深工程师被拉入火线救急架构债务不断累积每次事故都侵蚀客户信任焦躁的值班轮值主动式运维日历上稳定、可预测的投入事故期间可控的开支资深工程师专注于产品工作架构随时间改进客户信任悄然累积安静的值班轮值英雄主义陷阱这部分容易引发争论所以我直说了。工程文化赞美那些凌晨 3 点拯救了生产环境的工程师。Slack 频道里满是掌声。这个故事会在全员大会上被讲述。这次恢复成为传奇的一部分。航空业的做法恰恰相反。当然在燃油泄漏后成功着陆的飞行员会获得奖章。但那个本可以在起飞前就发现泄漏的维护团队才获得了预算。整个行业的组织方式就是为了让英雄主义罕见因为每一次英雄主义行为也都证明了系统允许某些环节出错。数据库运维同样需要这种转变。频繁响起的寻呼机是一个值得倾听的信号。一个把恢复手册背得滚瓜烂熟的团队恰恰说明他们的数据库被允许“刺激”了太久。目标是更少的英雄和更多无聊的星期二。“刺激”实际上是什么样子在讨论节奏之前先明确这种模式会有所帮助。一个刺激的数据库有一些明显的迹象大多数运行着它的团队至少能当场认出其中三点。值班轮值有其节奏而且这个节奏很嘈杂。寻呼消息成批出现常常在相同的时间窗口内。团队给那些反复出现的问题起了非正式的绰号那个总是在月底出现的查询那个在周日晚上阻塞一切的任务那个每季度停止更新一次的仪表盘。每个人都知道变通方法。但没人有时间去修复根本原因。性能毫无征兆地变化。上周运行只需 200 毫秒的查询今天需要 4 秒没人能说清楚为什么。团队会搬出那老几样的解释统计信息、autovacuum、嘈杂邻居按顺序尝试直到某个奏效。修复被应用了。根本原因仍未确认。六周后同样的症状再次出现循环重新开始。资深工程师每周有相当一部分时间泡在事故响应频道里。产品路线图在一个个周五下午悄然推迟。计划中的功能被延期因为本应构建它的团队在上个冲刺周期花了三天时间追踪一个复制延迟问题结果发现是一个没人记录的长耗时分析查询所致。备份是存在的但上一次完整的恢复演练是很久以前的事了。团队相当确定在真正的灾难中备份是有效的。“相当确定”这话很难说出口所以往往就不说了。架构决策被推迟因为没有精力去处理。那个能简化三个下游系统的模式变更又要再等一个季度。那个能让清理工作平静下来的分区策略又要再等一个季度。每一次推迟单独看都有道理。但它们加在一起形成了一种朝向更多“刺激”的缓慢漂移。如果上述模式中有两三个听起来很熟悉那么这个数据库已经被允许“刺激”一段时间了。意识到这一点就是本文前面的成本账不再抽象的时刻。账单已经在支付了。问题在于该怎么办。有意无聊每周是什么样子一个实用的节奏会有所帮助。这个节奏本身就成为了成果。每日团队根据基线审查各项指标并对告警噪音进行分类确保真正的信号保持清晰。每周快速检查慢查询趋势、膨胀健康状况和复制延迟模式。每月团队在真实数据上演练一次备份恢复根据实际增长审查容量并根据当前工作负载检查参数的合理性。每季度进行一次全面的性能健康检查着眼于整个系统而非其症状。每年团队执行一次真正的故障转移有计划的、在监督下的并将其视为一次学习事件。所有这些全都是平凡的工作。而正是这些工作让数据库保持无聊。为什么这对您的组织很重要PostgreSQL 是有史以来功能最强大的数据库之一。在熟练的手中在纪律的约束下运行它可以悄无声息地承载巨大的工作负载多年。获得这种体验的组织正是那些有意决定在无聊部分进行投资的组织。深厚的 PostgreSQL 专业知识持续地应用使得数据库成为公司其余部门不再需要操心的那部分栈。那种平静是目标。它也是成就。