总体架构设计评审第三天

乙方评审 4 人组中的第四个终于出场了，负责的是基础架构建设方案的评审，包括服务器资源、存储资源的规划和预计使用情况。本来乙方的方案书文档做的是不错的，对于各种基础数据、业务数据以及对硬件资源的需求都列的很细致，可是这厮一上来就被甲方的几个具体问题给问住了。

为什么突然又要求多加两台服务器？为什么XX系统分配了那么多CPU和内存？为什么XX系统对于存储的要求这么大，而甲方原有的系统却只有十分之一？计算公式里某个参数的定义是什么？为什么同一个方案里面前后的数据计算用的参数都不一致？

——呃。。。这个嘛，我要问问XX同事。。。。那个嘛，我要回去问问开发的同事为什么要这么多。。。。可能是我们算错了，我再回去算算。。。。我先打个电话。。。。。。。

被问的急了就随口诌一个答案出来，并且拒绝打开word的标记功能，一边讲一边自己偷偷的改文档，不让我们知道他改了什么。后来貌似开始应付了，不理会别人的问题，一边玩手机一边念文档，很想暴扁他！

唉。。。相当的不专业啊！我敢打赌，这厮来评审之前，根本就没有认真看过方案。

到了最后，那位仁兄终于承认，这份方案不是他写的。。。。唉，那还来凑人数！

总体架构设计评审预审基本结束，发现最大的问题是乙方负责基础架构、系统架构、应用部署的各team互相缺乏沟通：

负责基础架构的说不清为什么应用需要这么多服务器，说不清性能计算的依据；

负责应用部署的说不清为什么某某应用要分3台负载均衡，为什么XX系统需要一个前端代理，为什么数据库这么分区，需要多少个系统帐号，为什么要配那么多进程；

负责系统架构的人说系统的架构可以满足性能需求，但是又说不清结合基础架构和应用部署如何来实现这个性能的最优化。

说白了就是负责基础架构和应用部署的人的对系统不熟，负责系统架构的人对基础架构和应用部署都不熟，大家各干各的，都不考虑将来系统上线的时候该怎么办。

相对的，甲方从业务、系统架构、基础架构、应用部署、系统运维等等方面都非常专业。乙方则只能牵强的不断给自己的方案做各种解释。

又是典型的三边项目：边干，边学，边改造。。。