关于 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 的带来的技术红利让我的项目在这个领域发挥别人少有的价值。
Public discussion