关于架构的思考(二)——如何解决问题

在《关于架构的思考(一)——什么是问题》中，提到了以下观点：

• 问题的定义：目标和现状有差异

• 问题的分类：异常型问题和改善型问题

• 问题的视角：生活中绝大多数东西都是为了解决特定问题（需求）而存在，可以按照解决的问题来定义

• 问题的重要性：人类社会和个人的发展都是伴随着无数问题的解决，解决问题的层次越高，发展越好

• 问题视角的架构定义：架构是为了解决将现实需求转换为软件实现的问题

• 解决问题的关键：开放式转向封闭式的过程

在现实生活中我们会遇到无数问题，仔细想想我们是不是犯过以下错误：

• 遇到问题，还没有深入分析，就凭着第一印象拍拍脑袋就去解决。
  例子：线上一个接口超时报警了，小李也没多想，直接调高了超时报警参数的时间（看似解决了问题，实际上是埋下了更多的隐患，说不定哪天就雪崩了）
  分析：遇到问题，一定要弄清楚问题背后深层次的原因，否则只是表面看起来“解决了”，且会埋下很多隐患

• 遇到问题需要他人协助解决，自己草率的想了一个解决方案，就去要求他人实现。
  例子：李XX，你帮我在你的业务表里面加一个字段，并且给我提供相关访问接口。（实际上可能根本不需要这个字段，或者不用在别人的表里加字段，而且直接没头没脑的去要求被人干一件事儿，多半会让人觉得很唐突。解决方案可以想，但是一定要用问题本身去沟通，解决方案是讨论的内容）
  分析：要求别人协助解决一个问题的时候，一定要聚焦到问题本身，而不是自己想了一个解决方案去要求别人实现。

• 有人来要求做一件事，没有深入思考这件事的根本目的，就去做了。
  例子：领导说，小李，帮我找个饭店，定个桌子。小李也没详细问，就随便定一个，结果领导大怒：这么低档次的饭店，我怎么好意思去招待人！（看着貌似是一个沟通问题，实际上是小李根本没有去深入思考、了解老板的目的，比如定桌子干嘛、几个人、招待的什么级别的人、偏向于什么口味的餐厅、要不要喝酒等等。。）
  分析：别人要求做什么事情的时候，一定要弄明白做这件事的根本目的是什么，并且举一反三。

上面几种情况，我们多多少少都遇到过。如何解决问题，是非常大的话题和学问，本文尽量努力表述清楚自己粗浅的一些见解，能引起一些思考就好。

我们都知道，一个人解决问题能力的强弱，和掌握知识的深度、广度，以及快速学习能力息息相关。那么，开始之前，先讲一下我们认知事物的过程。

我们在探索新的事物时，一般有以下三个阶段：

总结起来就是如下的一个学习圆环：

学习的黄金圆环，是一个由表及里，不断迭代，不断深入的过程。

在探究本质的时候，会发现新的问题和未知的事物，进而形成一个由问题驱动的学习圆环。

想要提升解决问题的能力，就必须保持好奇心，不停的问为什么，由问题驱动学习，这样解决问题的能力也随之提高。

首先回顾一下异常型问题的定义：

解决异常型问题的关键在于找到问题的本质，我们也可以称之为“根因”。

中医讲究"望闻问切"来定位疾病的根源。这里我们也需要一些手段来找到根因，非常流行和通用的一种方法是“5W1H分析法”（也有叫牛眼分析法的），这里不详细阐述，感兴趣的可以自行搜索学习。下面阐述本文的一些见解。

找到根因，最主要是要弄明白以下几个事情：

他们的关系如下：

其中的核心是找到“到底是谁的问题”，也就是问题的主体，否则后面的工作都属于无用功。大致思路如下：

按照这个循环去剥茧抽丝的找，一定会找到“根因”。下面重点讲述最重要的1步骤，如何确定疑似“问题主体”。

3.1 找到“谁的问题”

所有的问题，都会有各种“相关者”，这些“相关者”存在一定关系，且某个“相关者”会是“问题的主体”。只有找到这个关键的“相关者”，我们才能有的放矢，对症下药，解决问题。

因此，在开始找“谁的问题”之前，我们必须弄明白这个问题中所有的“相关者”，并且弄明白这些“相关者”的关系和作用。

一般来说，从问题最外层的“相关者”出发，一层一层挖掘下去，会形成一个问题相关者的“链式结构”或者“树型结构”，如下分别讲解。

问题相关者：链式结构

以一个我们经常遇到的问题举例：一个web网页无法访问了。我们需要“挖”这个问题涉及到的“相关者”有哪些。也就是要把web网页的调用链弄明白，假设如下：

• 用户的访问终端：手机app/手机浏览器/PC浏览器等等

• 用户的网络类型：wifi，电信/移动等等

• 用户地域&cdn网络：北京用户，第三方cdn运营商/自建cdn等等

• 流量入口服务：lvs&nginx/haproxy&nginx等等

• 服务端：web网页url访问的后端服务

这样形成以下的问题主体链：

注意：要解决这个问题，必须先把整个调用链弄清楚，这个过程如果不熟悉，其实就是一个学习的过程，可以参照“学习圆环”。

针对以上调用链，我们继续“挖”是谁的问题，

• 用户的访问终端：终端是否可以正常访问其他页面，如果是，一般不会是终端问题

• 用户的网络类型：用户网络访问其他服务是否正常

• 用户地域&cdn网络：该地域用户是否大规模有问题，该cdn厂商服务是否稳定

• 流量入口服务：流量入口程序是否稳定，是否有异常/错误发生

• 服务端：针对该web界面访问的url，是否做了正确处理和返回，是否超时

按照这个范围去查，基本可以很快定位出“疑似问题主体”。

问题相关者：树型结构

上面的结构是问题相关者的链式结构，但是如果问题稍微复杂点，形成的就会是一个树形结构。比如，假设web界面调用的url在后端是多层调用，则变成了如下结构：

这种情况下，就需要依次排查是哪个依赖服务发生了故障。这里不再详细说明，总之解决异常型问题，必须先弄明白问题所有的“相关者”以及他们的关系，然后再去逐步定位“疑似问题主体”。

首先回顾一下改善型问题的定义：

解决改善型问题的关键，是要明确目标，并且有计划的去达成目标，我们分解为以下几个阶段去解决改善型问题。

其中，最最重要的就是必须弄明白核心的目标到底是什么，否则从一开始方向就错了，做再多的事情也是白瞎，下面分别讲解。

4.1 what-核心目标是什么

在日常工作和生活中，太多的例子，我们在没有弄明白根本目的之前，就急于开工，但是殊不知从开始就是错的，就像引言中的例子一样。

所以，在接到一个要求或者需求时，一定要问“为什么要这样”，得到回答之后，根据回答再问“为什么”。如此循环，直到弄明白真正的“核心目标/需求”。

我们用引言中的例子来说明：
老板：小李，帮我找个饭店，定个桌子
小李：为什么
老板：我要招待几个客人
小李：为什么
老板：XX项目需要他们帮忙搞定
小李：为什么
老板：因为他们是某某部门的负责人
小李：为什么
老板：你复读机啊！= =#

其实问到第二个为什么，这个例子的核心目标我们就清楚了，核心目标是“XX项目需要客人帮忙搞定”。

划重点：接到要求和需求，至少问两个以上为什么，弄明白真正的核心目标/需求

4.2 who-明确相关利益者

4.1章节中，我们讲了如何获取核心的目标和需求。实现目标的过程中，会涉及到各种人员、资源等。我们必须在真正行动前，弄明白所有的“利益相关者”以及他们的“权责”和“关注的利益”，这样才能做到分清主次、有的放矢。

一般来说，我们可以采取“枚举法”，把所有的“利益相关者”都罗列出来，并且一定要弄明白他们的“权责”和“真正关注的利益”（可以利用4.1章节的办法来弄清利益点）

还以引言的例子来说明，在4.1章节中，我们弄明白了老板的核心目标是“XX项目需要客人帮忙搞定”，我们列举一下相关利益者：

设想，小李本来是一个基层员工，如果他弄明白了老板的核心目标，明确了这些“利益相关者”，并且针对重点人员，有目标的制定计划，最终帮助老板以最小的代价搞定了项目。只要老板不傻，一定会对小李另眼相看，升职加薪是顺带的事儿。

划重点：可以采用“枚举法”列举核心目标实现过程中涉及到的所有“利益相关者”，并明确他们的“权责”以及“真正关注的利益点”(多思考多问为什么，)

4.3 how-如何满足关键利益点

首先我们要在众多的“利益相关者”中，根据同“核心目标”的关系，明确“关键利益者”，从其关注的众多利益点中明确“关键利益点”。并且对其余利益者和利益点做一个主次排序，利用有限的资源去尽量满足。

还以引言的例子来说明，4.2章节中，我们一眼就看到，客人1就是“关键利益相关者”。但是在他关注的利益中，没有更多信息。但是在客人3司机的权责中，我们看到司机熟悉局长的习惯和生活。小李拍拍脑袋，私下去找了司机，给了些许好处，司机就告诉小李，局长的儿子一直没找到合适的工作，局长为此很烦恼。

得到这个关键信息，小李立刻告知了老板，并且根据从司机那里打听来老板的餐饮习惯，定了最合适的酒店。结果不言而喻，老板帮局长搞定了他儿子的工作，局长也帮老板搞定了项目。

划重点：利用有限的资源，优先满足“关键利益者”关注的“关键利益点”

分割线，故事完结，上面的例子不太好，仅为了引发思考，还请见谅。

上面我们提到的解决“改善型问题”的方法，可以用在绝大多数的场景里，也可以运用在一个系统或者项目的全流程中。

本文只提供一个大概的思路和方法，有不少以偏概全的地方，希望大家见谅，能引起一些思考就达到本文的目的了。

我们日常遇到的绝大多数问题都和人相关，以上章节中讲述的是排除了“人性”因素的，解决和人相关的问题，很多时候解决问题的人要做到“洞悉人性”，并且“反人性”。（比如临危不乱、少说多做等等）

举个例子：

• 和女朋友吵架了，这个算一个异常型问题。如果这时候去追究到底是“谁的问题”，那不是找死么

• 女朋友不高兴，你的目标是让她高兴起来，这算一个改善型问题。那解决这问题的时候，你如果去问她为什么不高兴，回答一定是“不为什么”

因此解决问题的高手，一般来说都是是情商很高的人（技术/专业领域，不和人打交道的除外）

关于人性是一个更大的话题，这里就不多讲了，只作为引子提一下。强烈推荐《人性的弱点》这本书，反复看，反复思考，反复反省。

ps：最近正在看一本《思考，快与慢》的书，强烈推荐，有助于提升控制情绪的能力。

总结一下，本文主要阐述了以下观点：

本文中不少内容有点以偏概全，希望大家多多包涵，总体主旨是希望抛砖引玉，引起思考就好。

软件架构作为改善型问题的一类，在《关于架构的思考（三）——回到架构》中会详细探讨，敬请期待。