我之前文章里写了诸葛亮的“战败计",诸葛亮最长于形势不佳时尽量降低损失和伤害,这于我们架构师和项目管理者,是非常值得学习的。
对系统架构来讲,最应该谨慎的一件事,就是每一个假设,都可能会变化,每一个环节,都可能在变化的环境中,变化的条件下出错或失败。某一个环节失败,对整个的产品,会产生什么样的影响?要怎样处理?又应当怎样改进以避免错误?
《三国》里经典的一幕,孔明一失街亭,马上意识到整个北伐失败了。后来,每次都是在粮道出现问题,对方又坚守不战的情况下,及时做出反应,或派将护粮道,或退兵。
这也就是我上一篇文章写到的,优秀的将帅,一定有战败计,作为应对形势变化的预案。我们做架构的,也应该对每一种可能出错的情况,有所预案,做好准备,错误情况真的发生是及时处理,不让一个环节上的错误,变成全面崩溃(对战争,就是一败涂地;对技术架构,可能是宕机、业务受到严重影响,客户关系受到严重影响等等)。
我作为系统架构师,看到过很多架构,非常有创造性,技术先进,但是也有很多,考虑业务、考虑创新都非常棒,但是在部件划分和配合工作时,都假定其它组件在按照预期工作(环境和操作者都正常当然会按照预期工作),对环境发生改变和操作者知识不足,操作错误所引发的错误,就没有很好的设计,因为认识不足,所以在后期的实现中,没有合适的预案和处理,导致的后果就是崩溃、甚至宕机、停止服务。
不要认为这只是小事。这个和你所从事的业务类型有关,做个单机版(或网络版)的游戏,崩溃和宕机虽然不爽,但是也没啥,但是如果银行系统宕机呢?QQ虽然用的多,但是真的服务器宕机了也没大事;但是移动电话的交换机系统呢?运载火箭的控制系统呢?系统类型不一样,对健壮性的要求也自然不同,有自己的“底线”,一定是要正确评估自己所架构的对象,来做好错误处理。
对更细节的设计来讲,也是一样,一定是处理正常业务流程的部分,远远少于处理错误流程的代码和工作量。因为一般情况下,正确的路径只有一条,但是所有环节都会出错,可能会出的错误也是千奇百怪,什么情况都有。
对项目管理和控制来讲,就是要清晰的认识到,每一个成员都是有可能出错的,不能按照预期进行工作,这个时候,你的预案是什么?如何能在人员的安排和工作的分配上,尽量避免,或者有补救的措施,尽量让单个成员的错误不影响其他人?如何尽量保证项目的总体目标?
说了这么多,其实核心就是一个意思:
- 在做任何事情的起始阶段,都想好可能会出现的错误,做好预案;
- 某个环节出现错误能够正确识别,正确评估这个错误对整体的影响;
- 如果在出错的情况下,尽量保证总体目标;
- 如果因为出错,总体目标已经是达不到了,那么如何退而求其次,降低损失。
最后,写上两句名言,与大家共勉。希望我们大家都能效仿诸葛亮的“诸葛一生唯谨慎”,做出优秀而健壮的产品架构来。
- 所有的地方都可能会出现错误;
- 所有可能会出现错误的地方,都一定会出现错误