56 关注应该程序的支持和维护

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

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

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

系统管理员不能重新提交请求消息来重现问题。在生产环境中，也不能对“线上”数据库重发资金交易来查看何处出了问题。

一旦应用程序进入了生产环境，修复错误的压力来自于客户和管理人员，不是项目经理和测试团队，而愤怒的总裁将意味着更大的威胁。

一旦投入使用，就没有调试器可用了。

一旦投入使用，部署工作就需要进行计划安排和协调的。无法把生产环境中的应用程序停几分钟，来测试错误修复的情况。

生产环境中的日志记录级别要比开发环境中的低很多。

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

大多数问题都需要开发人员的参与。

开发团队和支持团队之间的关系很疏离沉闷，开发人员认为支持团队不懂技术。

支持团队讨厌新的应用程序。

架构师和开发团队在生产环境上花了很多时间。

经常把重启应用程序当作一种解决问题的办法。

管理员总是在救火，他们永远都没时间把系统调整到合适状态。

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

理解开发人员和支持人员确实具有不同的技能。

在项目中尽可能早地引入支持负责人。

将支持负责人作为团队的核心成员之一。

让支持负责人参与规划应用程序的支持。

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