弱者道之用——谈技术工作中的守弱问题

本文从那个性能分析的系列中暂时抽出来一下,发表一下感想,谈谈技术团队的互相协助问题。

道德经的模型我在这里总结抽象过一次:老子哲学思想的精髓是什么? - in nek 的回答。那里是从类似“哲学”思考这个角度来总结的。这里我再从工作实践的角度来抽象一次。

“名”是个非常强大的东西,它不但用于交流,还用于思考,它直接影响你的决策模型。但名并不是事实,我们很容易会被名掩盖了对事实的认识和判断。

人的思考除了有“名”这个缺陷,其实还有“实时性”这个缺陷,很多东西轮不到你面面俱到地进行穷举,所以我们才有“守”这个概念。“守”的意思,是说,你在决策的最后一刻,你能使用的最后几个逻辑要素。

你把什么作为你瞬时决策的依据?

这个在战略阶段你的决策和在战术阶段你的决策依据是不同的。比如你要从城东家里到城西,在家里研究地图的时候,可能你的判断是出门先往东,然后在2公里处掉头,再往西直达目的地。这个分析作为你出门以后守的一个条件,就是“出门后一定不能直接往西,要先去东边的绕过西边的屏障以后才往西”。

而你不研究地图就出门,很可能你出来就直接奔西边去(这时你守的只有方向),结果发现前面是个工地,你根本走不过去,你就只能回头,可能走更长的路才能到达目的地,甚至到不了目的地。

但如果你研究了地图,但你出门的时候往东的路在堵车,你又知道往西的路修通的可能性接近0,你就可能可以考虑往北去,辗转走到掉头的路口,继续向西去。我们解决具体的问题总是在战术上,战术最大。但如果你事前可以准备,战略可以为战术提供无与伦比的帮助。人的思考深度,比的正是你可以在视觉上拉高多少来看整个问题的逻辑。

这就是战略的作用。战略“守”的东西,和“战术”守的东西是不一样的。战略是经过一些研究,把一些在战术中要“守”的东西贯彻给战术,加大战术成功的筹码。

这种东西在工作中无处不在。我们写完设计文档就要Review,Review的目的是别人给你提意见,你想避免犯错误。但直觉上我们听到意见又会很不爽。如果在战略上考虑过这个问题,你就会在Review中就守一个原则“意见其实是越多越好,别人是来帮我的”,但如果如果你顺应自己的眼前观感,你就会本能拒绝别人给你的Review意见,当作是一种挑事了。

这就是为什么反者道之动。因为构架决策基本上都是和战术相反的,如果战术层面就能搞定的东西,根本不需要构架决策干什么事。你在家里研究去城西的战略,会加入“走人行道”这一条吗?不会,因为那是战术层面的东西,根本不需要你去“守”。那是你在战术阶段本来就会守的东西,浪费在战略阶段毫无意义。

道德经是帝王之术(不是小人眼中那种只想荣华富贵,妻妾成群,驾驭下属,得点个人小便宜的所谓的“帝王之术”,而是真正把要成事的领导者的艺术),它的战略决策思路是,无论你想干什么,首先的工作是让布朗运动变成有向运动。因为我们首先要承认,“我”,个人在成事上几乎作用可以忽略。就算你当了总裁,当了皇帝,你让你手下的员工都不要领工资,让身边的大臣统统自杀,你看看行不行?集体是个平衡系统,力量在集体本身上,而不是在你个人身上。你做的是系统的平衡,不是取代集体去努力。集体中的每个个体都有一个动力,他们互相作用,变成“热”(布朗运动就是热),而你的工作是把热能变成动能,把这个集体移动到你想他们去的那个位置上。

而要让集体形成力量,他们必须能够匹配起来,我们看看这副图:


如果人和人之间都是这种突出的形状,他们是不可能匹配的,你得让不同的性格,不同目标的人在一定的外力下,匹配在一起,像这样:


很多时候,其实这样也是不够的,因为这表面看来匹配了,但看他们的细节,他们仍是有分歧的,比如这样:


这就是为什么我们和人沟通,不熟的时候还是好朋友,住到一起就成了仇敌了。或者某人是总统候选人的时候你很喜欢他,当了总统你就恨他了。

细节需要打磨才能最后匹配。一个集体要实现非布朗运动,就要通过一定的动力,把非主目标的动力分量平衡掉,剩下进步的动力。圣人的工作,不是提供集体前进的动力,而是提供让细节匹配的力量。进步的动力是集体本身的,不是圣人的。这就是无为。不提供集体前进的动力就是无为。所以构架师的工作不是写代码,而是让大家可以好好写代码和进行配合,实现系统的成功,如果构架师把“写代码”作为“守”的目标,这个架构师就离开进行战略引路的工作职责了。

好了,现在我们再理解一下为什么要不争。圣人需要为天下溪,为集体积累一点一滴的力量,把集体的力量释放出来,变成洪水,如果圣人自己就去和个体的力量对抗,这个集体哪里有什么力量?真正的圣人,是要让这个集体中的每个个体在目标方向去张牙舞爪,在偏离的力量上让他们互相平衡,实现匹配,类似这样:

如果圣人跑出来秀存在感,就成这样了:


这就变成新一轮的布朗运动,只是产生热,目标就不可能达成的。所以,君子不欲碌碌如玉,不求落落如石。

这是道德经整个战略的基础。理解这个基础,我们现在可以谈一下个人战略上的"守弱"。道德经说知其雄,守其雌,知其白,守其黑。这个策略的背后的考虑是什么呢?

我练形意拳的时候,有一个心法学会以后,经过一定练习,对整个技术水平有很大提升的,那就是:守中节。中节,对于整个手臂来说,就是前臂。我们无论防守还是攻击,手(拳头的位置)的距离是最长的,前臂相对来说更短。所以,我们下意识是守在稍节,就是手上,这就是守强,但我们不守强,我们守弱,解决问题的时候,总首先用前臂来进攻和防守,这个结果是,无论是进攻还是防守,手(拳头)永远都会突出去,都会成为对方的威胁。这就是守弱的作用,因为强就是强,强是不需要守的,强会自动发挥作用。强是已经解决的问题,守要守在还没有解决的问题上。你要去城西,别人没有自行车,你有,你要解决的问题是好好看路,骑这么快,会撞着人的,而不是老想着:我噻,我有自行车耶,看到没有?我有自行车耶……这于解决问题有何收益?忘掉强,守着弱,你就一直走在向前的路上,这就叫夫唯不居,所以不去。

这就是战略上的守弱原则。你爸是李刚,你吃个饭把李刚抬出来,上个厕所又把李刚抬出来,转眼李刚进去了,你也进去了。所以,我们取弱不取强,让弱变成强,这样你才是安全的。

我突然想起来谈这个,涉及到前一篇博文,那个Cache Invalidation引起的性能下降的问题,我和相关硬件的设计人员交流过多次,发现他们经常很容易守强,他们总是说,"这个东西表现出来就是巴拉巴拉,其他东西你不用管",其实根本就不是不用管,因为在那个模型中,他们根本就保证不了性能,如果软件不考虑他们的这个要素,他们根本就保证不了性能输出。他们坚持(守)在不能作为可靠依靠的"外面",而不是他们真正有信心的"里面"。这样整个交流就失败了。其实不光做硬件的人会这样,很多软件工程师,也会把自己的一亩三分地看得非常神圣,在外面加上一层厚厚的保护壳,抽象一个非常粗糙的外部接口,希望把自己保护在里面,这样是实现不了团结和竞争力的。很多人守强,也是因为对自己缺乏自信,不想漏怯。所以拼命用各种自己没有信心的概念来“武装”自己,让自己看起来很强大,却不知道自己最强大的正是你自己看起来最弱的部分。我不懂Linux的driver-bus-device模型,但我确切知道我写driver的probe函数的时候是有人传给我一个struct device来知会我中断和IO的位置在哪里的。这一点上我有坚定的信心。这就是守弱。我对driver-bus-device模型有粗浅的认识,这个可以作为我讨论的基础,但我在别人的有道理的意见上不会刻意坚持(特别是不会为了面子而坚持),因为我真正的信心是建立在“我写过一个能正常工作的Sensor驱动”这样的东西上的。这就叫守弱。

守弱的工程师,应该形成这样另一个沟通结构:

看见没有,我们的整个设计有确切不可更改的部分,有不可退让的原则(黑色部分),也有柔软的部分,我们要坚守在后面的部分,而不是非可相信的部分,这就是守弱,我们守弱了,才后可能真正知道如何合作才是最好的,如果我们一方守强,守弱一方才控制整个合作的主动,所以强者死之徒,弱者生之徒,这还是有可能合作的。但如果两方都强,就没有合作的机会了:

生之徒的工程师坚持的是不可变更的"弱"的一部分,外在表现是柔软的,所以他们才能和人配合,找到可以和对方合作的细节,形成坚不可摧的力量(集体的力量),我们每个工程师,如果有心要取得很大的进展,就需要学习圣人之道,学会借用集体的力量。

也就是,虚心实腹。你做一个中断控制器,就老老实实说你会遇到上升沿会如何,遇到下降沿会如何,多高频率的抖动会过滤,之后怎么报到总线上,怎么设置VMID让CPU知道是哪个虚拟机的中断。你不要自以为是地给软件抽象为:“我会通知你的虚拟机的,不用担心”。担你个头,我虚拟机什么意思估计你都不知道(因为每个平台的虚拟机方案在硬件设计阶段,它的概念还在设计阶段,硬件是不可能知道软件概念中的“虚拟机”到底是指什么的,比如你把ARMSecureFW看作虚拟机或者虚拟机调度器的一部分吗?),什么叫“通知虚拟机”你更不知道。你守在你根本就搞不清楚的概念上,那整个合作就变得非常粗糙,从而也失去力量了。

我经常说软件工程师应该好好学习一下《哈利波特》,因为哈利波特能在复杂的逻辑中找到出路,是因为哈利波特的思考方式就是很典型的守弱思维。比如说,他要办DA的时候,要找一个地方和其他同学一起练习魔法,向多比求助的时候他怎么描述的?“我需要一个地方,能让28个人练习黑魔法防御术而不被老师们发现,尤其是‘乌姆里奇教授’”。看见没有,这才是“原始需求”,而我们更多工程师如果描述这个需求,他们会描述为“我需要一个房子,100平方米,有软垫,有洗手间,有……”。如果你这样描述,多比就不会提供“Room of Requirement”了。我们很多技术讨论中,工程师就是被那种看似专业,实际被自己的误解带偏,最后还要被自己的面子锁死的错误观点所左右,最终让整个沟通和合作失效的。

其实,我这里说的“弱”,只是看起来的弱。从置信度和坚强度上来说,这个弱其实是一个强。我们很多工程师(中国工程师尤甚,欧美,乃至印度的工程师都比我们好)写技术文档,特别喜欢用大而不当的概念来包装自己的设计。比如,“本设备支持流表Offloading,流表格式如下……”。我每次看到这种描述就发毛:什么叫“流”?什么是流表Offloading?在很多评审会议上,常常只有我才会问这种不合时宜的问题:什么叫流?然后整个会议室的人看着我,用同情的态度来说:“Kenneth老大,下来我们给你解释一下”。我说“不用,你们给我一句话的定义,什么是‘流’?”。然后,你会发现,其实没有一个人对“流”有清晰的定义,他们说,“流啊,就是流啊,就是那些Socket啊什么的……”。最后大家就会发现,其实我们都不知道流是什么,却为流offloading谈得不亦乐乎。这种情况,我会先给一个我的定义:“流是具有相同数据特征的,流过(发送或者接收)本网络设备的一组包的有序序列”。然后有人开始说,“对,差不多,不过发和收我们是看作不同的流的……”,OK,那我修正如下:“流是具有相同数据特征的,单向的,流过本网络设备的一组数据包的有序序列",好了,现在没有反对意见了吧?那我提出第二个问题:“我们的NIC可以匹配那些特征?支持哪些调度目标?”……这种讨论和思维模式就叫守弱。其实这个弱是非常强的,因为我们的基础非常坚实,看起来定义一些非常显浅的,直白的,基础的东西,但以这个为基础抽象的高层概念非常坚实。但如果你没有这样的基础概念,所有看起来的“强”不过是海市蜃楼。我们很多人看不起自己实实在在做的东西。比如NIC的设计师其实肯定是知道他如何处理每个特定的包的,但他们觉得那个东西不够高大上,非要封装很高级的,自己其实没有把握的概念,其他人看到这样的概念,自己其实也不懂,但又不好意思显得自己太蠢,也不敢问,结果就是大家都在一个糊糊涂涂的讨论中,形成一些不可依赖的意见。结果就是战略阶段一事无成,战术阶段修修补补。不少中国工程师觉得架构没有什么用,其实道理也在这里,他们不懂守弱,就不会懂怎么做架构设计,从而也就体会不到架构能给他们带来的强大的力量了。

守弱的思维策略,是我们真切认识世界,构建有效战略逻辑的开始(战略逻辑自由度极高,评判只能在战术阶段,所以,是否有效时战略逻辑的唯一评判标准,这个靠看样子是看不出来的),不但可以用于工程师,也可以用于任何行业,不但可以用于集体,也可以用于个人,我们对世界的认识,坚固的逻辑要落在不可退让的事实上,而不是落在抽象的概念上。这就是虚心实腹或者守弱。

编辑于 2017-06-15

文章被以下专栏收录