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