关注应用程序的支持和维护

作者：门西蒂西·卡斯珀（MncedisiKasper）

应用程序的支持和维护永远都不应该是事后才考虑的事情。由于应用程序超过80%的生命周期都是在维护上，在设计时就应该多多关注支持（support）和维护（maintenance）的问题。忽略这一点，你将会惊恐万分地注视着寄予厚望的应用程序停止工作，宛如失控的野兽，跌入恐怖的死亡深渊，成为你架构师生涯中无法抹去的败绩。

设计应用程序时，大多数架构师主要站在开发人员的角度思考，他们手上有IDE和调试器。当问题出现时，高度熟练的软件工程师会进行调试来发现错误。由于架构师大多出身于开发人员，而非系统管理员，他们很容易会按这种思路来考虑问题。不幸的是，开发人员和支持人员拥有的技能不同，就像开发/测试环境和生产环境有截然不同的目的一样。

下面列举了系统管理员会遇到的一些问题：

• 系统管理员不能重新提交请求消息来重现问题。在生产环境中，也不能对“线上”数据库重发资金交易来查看何处出了问题。
• 一旦应用程序进入了生产环境，修复错误的压力来自于客户和管理人员，不是项目经理和测试团队，而愤怒的总裁将意味着更大的威胁。
• 一旦投入使用，就没有调试器可用了。
• 一旦投入使用，部署工作就需要进行计划安排和协调的。无法把生产环境中的应用程序停几分钟，来测试错误修复的情况。
• 生产环境中的日志记录级别要比开发环境中的低得多。

如果支持规划存在此种缺陷，就会出现下面这些症状：

• 大多数问题都需要开发人员的参与。
• 开发团队和支持团队之间的关系很疏离沉闷，开发人员认为支持团队不懂技术。
• 支持团队讨厌新的应用程序。
• 架构师和开发团队在生产环境上花了很多时间。
• 经常把重启应用程序当作一种解决问题的办法。
• 管理员总是在救火，他们永远都没有时间把系统调整到合适状态。

为了确保应用程序脱离开发人员之手后能成功运行，应该做到：

• 理解开发人员和支持人员确实拥有不同的技能。用
• 在项目中尽可能早的引入支持负责人。
• 将支持负责人作为团队的核心成员之一。
• 让支持负责人参与规划应用程序的支持。

如此设计，则技术支持人员的学习曲线是最小的。可追溯性（Traceability）、审计和日志记录至关重要，当系统管理员很开心时，大家都会开心（尤其是老板）。