关于 X-Y 问题的思考

发现一个问题千万不要立即去解决这个问题，而是应该思考到底系统上有什么漏洞，才导致了这个问题的产生。——王兴《九败一胜》

一次偶然的机会看到了陈皓关于 XY 问题的描述引发我对项目中一直“无解”问题的重新思考。

X-Y problems

X-Y problems 的描述定义有一个官方网站：https://xyproblem.info/，最初 X-Y problems 还是用来思考如何正确地问问题：没有去问怎么解决问题 X，而是去问解决方案 Y 应该怎么去实现和操作。

日常项目设计开发有许多糟糕的产品和代码都是因为 X-Y 问题导致的。因为思考提问的人以为自己找到了问题所在，而解决问题的时候懒得思考就根据问的问题开始实现方案了。在软件开发设计的时候还会有几种 X-Y 问题的变种值得注意：

把手段当目的，会用自己所喜欢的技术和方法来反推用户的需求
并不清楚想解决的用户需求是什么而认为开发 Y 功能能够满足用户就直接去做 Y 的需求，不是推敲解决用户需求的 X 问题是什么
对于个人的职业发展的问题 X 是成长为有更强的技能和能力，这个可以拥有比别人更强的竞争力，从而可以有更好的报酬，但确走向了 Y：全身心地追逐 KPI
本来我们想达成的 X 是做出更好和更有价值的产品，但最终走到了 Y：通过各种手段提升 DAU 等数据来衡量

怎么避免 X-Y problems

X-Y problems 最初是告诉人们如何问问题，相比提出一个明确的解决方案 X，思考本质的问题 Y 往往非常辛苦而且容易徒劳无功，至少提出来解决方案 X 能显得自己是思考过的，这会导致在一个完全错误的方向浪费了大量的时间和精力。针对 X-Y problems 我总结了几个维度的思考方法，试着给出这个问题的解法，另外也提升对于问题的思维能力。

问问题视角

Always describe what you want to fix, not what (you think) the problem is.

Explain your need, not only the solution you want to implement.

Define expectation and the current behavior instead of just your request.

在问问题的时候

描述问题症状而非你的猜测
描述目标而不是过程
清楚明确的表达你的问题以及需求

答问题视角

Make sure you are solving the real issue, not the current need.

Ask questions to understand the nature of the problem.

Identify the difference between the existing outcome and the requested functionality.

在答问题的时候

多问几个问题尽可能的还原真正的需求
问一下要解决这个问题的原因
问一下现在的情况是怎么样的，希望的样子是什么

思考问题视角

从逻辑维度（从上往下）和时间维度（从前往后）分别思考问题，有更多角度来观察和思考会提升对问题的认知，尽可能的找到正确的问题做到有的放矢。

1、向上看

在提出问题的时候先停下来思考是否这是某个大问题的子集。

2、向下看

思考问题还有没有其他的解决方法（Z solution），如果有它的优劣分别是什么？用其他方法的结果是什么？ROI 怎么样？

3、向前看

思考下如果解决了这个问题，是否会衍生其他问题。如果发现即使这个问题解决了后续还有不能解决的问题，要停下来思考的是这个问题是否是本质问题，或者说这条路是否能走得通。

4、向后看

思考是否是因为之前的一些（临时性的）策略导致今天的问题产生。那时候的决策放在今天来看是否还合理？是否需要对原始的规则进行修改？

工作问题推演

按照上面总结的 X-Y 的多视角分析，我打算来推敲一下我在项目中一直"无解"的问题："讲不清楚做的东西价值是什么"。由于这段思考和推演跟工作内容相关，为了避免涉及商业机密或者引发职业守则问题，我不会谈及具体的技术和方案内容，只是以逻辑推导的方式来自洽问题的"求解过程"。

问题背景

组内在做一个代号 P 的项目，我们给它的定位是一个通用的 ebpf 管理调度平台负责解决 k8s 集群中进行 bpf 调度管理的问题。

问题思考

1、问题视角

为什么需要一个 bpf 管理平台？

bpf 使用起来没有很好的管理手段，例如 load、attach、unload、map create、map pin，再有就是目前 bpf 没有策略化管理的能力。

什么场景下需要 bpf？

安全、监控、网络等等场景都可以借助 bpf 的能力。

安全需要 bpf 解决什么问题？监控需要 bpf 解决什么问题？网络需要 bpf 解决什么问题？有别的解法吗？

安全可以借助 bpf 来做入侵检测、阻断等问题，监控可以借助 bpf 来做细粒度、低消耗的监控，网络需要 bpf 解决搞效率的转发等问题。上述这些都有别的解决方案能做，各有优劣。

bpf 管理平台跟要解决的问题的关系是什么？

安全、监控、网络等等场景都有共性的 bpf 策略化管理的东西，如果有一个好的管理平台那么就可以提升各个场景使用 bpf 的效率。

2、思考视角

bpf 管理平台是节点运维管理平台的一部分吗？例如 iSEE 那种 DevOps 平台。

bpf 管理跟计算节点的 cgroup fs 等资源类似可以借助 DevOps 之类的平台进行策略化管控。

bpf 管理有别的方式来是实现吗？

Cillium 的 Pod 形态管理 bpf.

有了 bpf 管理平台之后，解决安全、监控、网络等场景问题的时候会有衍生问题吗？这些问题好解决吗？

有问题可能是暂时无法解决的，依赖 kernel 的演进，例如 bpf verify，例如 bpf 策略互斥的问题（复杂集群可能会出现“按下葫芦起了瓢”的不可预测问题）。

需要 bpf 管理平台有什么历史原因吗？

kernel 门槛，kernel 版本支持 bpf 能力不一致

问题总结

bpf 管理平台这件事情我持否定态度：

策略化管理 bpf 是解决方案并不是需要解决的问题，安全、网络、监控都是我们基于管理平台反推出来的需求，所以 Pangolin 没有自己要解决的问题，也就是意味着抛开主观客观的原因导致网络、安全、监控这些场景不需要 bpf 的时候 Pangolin 自身无法演进，也就是说这个平台的价值可能所剩无几；
考虑到 kernel hookpoint、kernel version、kernel verifier 等限制，策略化管理过程对于“按下葫芦起了瓢”的问题无法解决；
如果 kernel 社区对 bpf 支持加大演进力度，发展为解释器进行脚本的形态来做 bpf 的对外接口，这对于管理平台来讲是降维打击；
bpf 能解决的问题其实有其他手段，考虑到 ROI、技术栈等问题，这就意味着管理平台的吸引力不够强，没有足够的人参与到平台，那么这个平台只能是一个技术自嗨的产物；
bpf 提供的能力跟业务场景是耦合的，bpf 程序跟平台作为统一抽象层之间还有 gap 需要“胶水”粘合，这个会是平台发展很大的阻力；

但是，在公司不能内部，上述问题可能不是问题：

人情因素导致不需要担心无人用
内部场景，可以加各种限制和要求
人情因素“胶水”总会有人来做

综上，从一个产品的角度 P 项目显然是不行的，从一个内部项目的角度来讲 P 项目是无可厚非的，无论是满足技术提升、还是落地成果都没有什么大问题，起码有一定的场景 buyin，只不过也就仅此而已了，在哪儿不是给人打工呢！起码我们还有一个不错的 bpf 框架来提升 bpf 的开发使用体验。

P.S.

如果我自己去 lead 一个 bpf 相关的项目，我想做什么：
锚定一个领域（例如安全），深耕该领域需要解决的问题，有效利用 bpf 的带来的技术红利让我的项目在这个领域发挥别人少有的价值。