关于 X-Y 问题的思考
9 min read

关于 X-Y 问题的思考

程序员开发设计的时候如何避免陷入 XY 问题的困境
关于 X-Y 问题的思考
Photo by Ehimetalor Akhere Unuabona / Unsplash
发现一个问题千万不要立即去解决这个问题,而是应该思考到底系统上有什么漏洞,才导致了这个问题的产生。——王兴《九败一胜》

一次偶然的机会看到了陈皓关于 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 的带来的技术红利让我的项目在这个领域发挥别人少有的价值。

References

  1. (Fantastic) XY Problems and How to Avoid Them
  2. 3 Tips to Overcome the XY Problem
  3. X-Y Problem 酷 壳 - CoolShell
  4. The XY Problem
  5. XY problem - Wikipedia
  6. How to solve an XY problem?. What is your real issue?

Public discussion

足迹