你的问题是什么？

念研究生的时候，我导师开组会最喜欢问的一个问题就是“你(研究)的问题是什么”。

以前觉得这个问题非常无厘头，而且回答他的时候一定要字斟句酌，一个不小心就会被他怼。

举个例子，你有一个 idea，说我想研究发烧了如何退烧，他就会问你你的问题是什么。

如果你回答我研究的问题是“如何退烧”，那肯定会被他喷，这个问题研究的范围太宽泛了，可能像张文宏那样的感染科泰斗才有资格发一篇综述或者指南去归纳。

那就缩小点，我研究“布洛芬退烧的原理”，还是会被喷，布洛芬太窄了，不能揭示普遍的学术原理，没有什么价值。

Fine，那我改成“非甾体抗炎药退烧的原理”，那总该有普遍性了吧？依然会被喷，这个原理上个世纪早就被研究地很透彻了，你这是炒冷饭。

那什么样的算是他心目中合格的问题呢？“使用布洛芬治疗 COVID-19 引发的高热是否可能导致体内 ACE2 受体增加从而导致病情恶化”可能算一个。

仅仅是举个例子，我读研念的是计算机，不是生物制药。我导师的这个口头禅让我的师兄师姐、师弟师妹和我自己非常头疼，觉得他就是无理取闹。

但是工作之后发现，定义好自己的问题简直是最重要的一个技能，尤其是对搞基础设施、中间件的同学。

想象一下，几年前，我们的基础设施解决的是什么问题？如何发现磁盘故障、如何监控物理机资源、如何快速发布应用 blahblah，虚拟化、服务化已经算比较高端的话题了。这些琐碎、繁杂、低价值的工作根本原因是基础设施的“问题域”定义地太窄。世界上所有的磁盘都会有问题，任何一条光缆都有可能被挖断。与其把问题定义成“监控故障”，为什么不把问题定义成“如何让你的应用对故障免疫”呢？

为什么？因为解决前面的小问题路径清晰，有明确的方法论，而解决后面的问题则需要重新发明一套世界观。

Google 搞了近 10 年的 Borg，然后用 Go 写了个 Kubernetes，并且告诉大家，从今天起，忘掉物理机，忘掉 commandline，忘掉 imperative operation，给我一个 declarative 的目标，我来帮你实现并且维护这个状态。Kubernetes 的出现可以说重新定义了 infra 要解决的问题，和他比起来，OpenStack 这些只能说是基于人类几十年运维硅基智能的经验缝缝补补又三年的过渡方案。

Kubernetes 会是 infra 的终极形态吗？没人能给出答案。但是如果搞 infra 的人一天到晚还在折腾以前那些东西，今天的我可能每天有三分之二的工作时间要处理线上乱七八糟的报警上面。

最近我的部门和搞容器的部门合并了——搞中间件和搞容器的人本来就不该分成两拨，因为迟早搞 infra 的人要去吃 middleware 的菜，搞 middleware 的人再不主动往 infra 去下沉恐怕就会变成另一个 J2EE 了。

但是什么才是下一代的 middleware 呢？比如我搞消息队列的，这个领域 pub/sub 模型搞了十几年了，Confluent 的估值都几十亿刀了，没人能否认现有的模型很强大，但是谁也说不出来什么才是 MQ 要解决的下一个问题。RocketMQ 没有给出答案，Pulsar 也没有给出答案，Event Streaming 看上去也不像是我们需要的答案。我们组两周开一次双周会，周会上老板让大家聊下最近的新想法，然后就会陷入一阵尴尬的沉默。每到这个时候我就会想起来我研究生导师的灵魂拷问:

“你的问题究竟是什么？”