1.2 分析问题并准确地提出问题

了解到需要解决的首要问题后，你需要将其拆分成小的部分，以探明要满足哪些需求。每一个部分都会促使你稍后向客户提出不同的问题。这些问题将会帮你完善POC中没有说清楚的地方，从而确保这些问题合起来，可以把各个角度（也就是业务角度、功能角度，以及技术角度）的业务需求全都照顾到。你可以列一张清单把每个问题的出发点，以及该问题想要解决或回答的事情罗列出来，这样便于记录问题本身，以及它们所针对的业务需求。

此外还要注意在回答问题的过程中，你可能会发现一些限制或障碍，这些挑战也需要在POC阶段予以处理或考虑。你所提出的处理办法需要获得客户同意，他们的决定将会影响最终的解决方案。

接下来以早前邮件提到的项目为例，从几个不同的角度分析该项目：

我们要做一个至少支持10000次网站点击的解决方案，在更新或停机的时候，这个方案依然要能够使用。预算相当少，因此要尽量压低开销，而且最好是能免去预付成本。我们还希望，这个方案能够让项目在其生命期内得以持续壮大。

1.2.1 技术角度

从这个角度进行分析的时候，需要分析与该项目有关的各种技术问题，确定该方案在技术上的需求。

需要分析的问题如下：

❑那封邮件告诉我们，客户需要某种解决方案以支持一定程度的网络点击量，然而并不清楚客户是否已经将Web服务器架设起来了。如果是这样，那么客户需要的可能仅仅是一套负载均衡方案。如果不是这样，那么客户需要的可能既包括NGINX或Apache之类的Web服务器，又包括负载均衡方案。

❑客户提到网站的点击量至少是10000次，然而并没有说多长时间，是每秒、每天、每周，还是每月？

❑客户要求网站在进行更新的过程中继续为用户提供服务；即便进入停机时段，该方案也依然要能够运作。可是，这些说法都太过宽泛，因为可用性以可用时间与应当提供服务的时间之比来确定，该比率需要写成99.999...%的形式，小数点之后的9越多，可用性越强（如果以年为单位，那么可用性为99.9%意味着服务器每年只能停机526分钟）。停机是很难预测的，因此必须提前做出规划，你的方案必须考虑到灾难恢复时的RPO（Recovery Point Objective，恢复点目标）与RTO（Recovery Time Objective，恢复时间目标），而客户并没有提到这两项指标。为了确定该方案所能容许的最长停机时间，必须把这两项指标搞清楚。

❑说到预算，很多人都认为这是个业务问题，但实际上它不仅是业务问题，还会给技术工作带来直接影响。邮件中只是说项目的预算比较紧张，客户想要尽量压低解决方案的开销，但并没有给出具体数字，然而你在制作项目提案的时候，却必须知道这个数字。“最好是能免去预付成本”指的是什么？是对现有资源重新加以利用，还是构建一套新的解决方案？怎样才能在不产生预付成本的前提下实现设计方案呢？对于软件项目来说，要想免去预付成本或克服预算较低的困难，其中一个方法是利用开源软件（Open Source Software，OSS），但能否采用这个方法还得由客户来定。

❑邮件中说到，该方案要能够支持这个项目持续发展下去，这意味着网站的用户群会逐渐壮大，就必须估算出用户的数量与增速，才能给垂直扩展与水平扩展留出适当的余地。垂直扩展意味着逐渐增加计算资源，这要求你考虑客户的采购流程，从而顺利地添置RAM、CPU或存储设备。水平扩展也需要考虑采购流程，此外需要花费相当长的时间，把新开设的节点/服务器/VM（虚拟机）/容器集成到解决方案中。这些问题邮件里都没有提到，但确实包含着相当重要的信息。

图1-2对比了水平扩展与垂直扩展。前者意味着添加更多的节点，后者意味着给现有节点添置更多的资源。

下面这份清单列出了应该询问的问题，可以帮你澄清模糊之处：

❑这个解决方案要求的网站或Web服务器是重新创建，还是利用现有资源改建？

❑10000次点击指的是每秒，还是每天、每周或每月？

❑是否估计过数据库的大小，是否有现成的数据能够指出这一点？

❑由于预算比较低，是否应该考虑使用OSS？

❑若是能用OSS，是否有足够的技术资源来支持这种解决方案？

❑是否有现成的基础设施来管理更新，是否有立即就能使用的版本控制软件？

❑尽量免去预付成本，是否意味着客户已经有了相关的硬件、资源或基础设施（虚拟的或云端的），从而在打造新方案的过程中，可以回收/复用这些？

❑是否有现成的灾难恢复站点，让我们能够以此来实现高可用性？

❑用户数量增加之后，是否必须投入更多的存储资源？还是只需要增加计算资源？

❑是否有执行备份的计划？客户想要用什么办法做备份？

从技术角度来看，一旦开始设计POC，就会冒出许多问题，这些问题是由解决方案中所要使用的软件或硬件引发的。如果客户已经有了现成的基础设施，那就必须知道应该采用什么方式，或者做哪些工作，才能与基础设施相适应。

1.2.2 业务角度

下面从业务角度来分析项目需求，以下几个方面会影响设计：

❑该项目的主要需求在于性能，客户对性能的要求决定了解决方案所能支持的点击量。

❑项目在设计与范围上受到的限制，似乎主要由预算引发。

❑客户并没有提到，实际可以动用的预算有多少。

❑可用性方面的需求会影响业务人员在停机时段做出的反应，然而目前并没有具体的SLA（Service Level Agreement，服务级别协议）。我们必须先明确这一点，才能让解决方案满足业务需求。

❑预付成本是个很大的问题。如果能够使用OSS，那么就可以有效降低成本，因为不需要支付授权费。

❑邮件中提到解决方案要在维护过程中保持运转。这意味着客户愿意通过维护网站来升级或增强效果。

❑邮件中提到“我们还希望，这个方案能够让项目在其生命期内，得以持续壮大”，这意味着该方案在使用的资源上会出现变化，而这种变化直接影响需要花费的资金。

为了澄清业务方面的疑惑，应该询问下面几个问题：

❑根据现在所提的性能要求，如果达不到预期标准会给业务造成什么影响？

❑项目的实际预算是多少？

❑这个预算是否包括维护费用？

❑考虑到那些无法预判的停机与维护情况，这个网站每年最多能下线多少分钟？这会不会导致业务中断？

❑如果发生停机，应用程序可以容许多久收不到数据？

❑是否有数据帮我们估算出网站用户的增长情况？

❑是否有现成的采购流程？

❑申请购买新硬件或新资源后，多久可以获得批准？

1.2.3 功能角度

从功能角度出发，该解决方案需要考虑以下几个方面：

❑客户要求网站支持10000次访问，但并没有说由什么样的人访问？

❑我们只知道方案必须支持10000的点击量，但用户访问这个网站究竟要做什么？

❑方案必须在网站进行更新的时候保持可用。这意味着应用程序将会做出更新，但具体如何更新呢？

为了澄清功能上的疑惑，应该询问下面几个问题：

❑客户的应用程序是给哪种用户使用的？

❑用户访问这个网站是要做什么？

❑应用程序多久更新或维护一次？

❑这个解决方案由谁维护并更新？

❑网站是给公司内部的用户使用，还是给公司外部的用户使用？

功能方面与业务方面的问题有所重叠，因为它们涉及的某些需求是相似的。

把各方面的信息收集全后，编撰一份文档将解决方案所要满足的需求予以总结。一定要跟客户详细核对这些需求并达成共识，令双方都觉得只有满足这些需求，解决方案才算完整。