09｜统一调度：只是问题非常多而已，摔出来就行了

Sep 28, 2022



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

09｜统一调度：只是问题非常多而已，摔出来就行了

2022-09-28 毕玄来自北京

《超级访谈：对话毕玄》

课程介绍



讲述：正霖，叶芊

时长25:41大小23.45M



你好，我是叶芊。
　
上节课我们聊到 16 年毕玄拆完运维去带系统软件事业部跟研发效能部的经历。
　
对于高层根本不感兴趣的研发效能团队，定位是个大问题，做了一通现状分析之后，他终于找到了清晰的发力点：短期做代码智能化，长期解研发模式和环境干扰。
　
对于另一个团队——系统软件部，虽然高层给了明确目标，但他说做的也很不顺利，最后能做成也很难讲，可能时机比较巧。
　
作为自己在阿里 14 年的第三大亮点，统一调度的成功居然归因于“时机”？为什么？让我们跟着亲历这个集团级项目的总架构师，看一看当时有哪些障碍？他又是怎么处理的？
　
极客时间：你当时带两个团队，研发效能之外就是统一调度，这个部门的目标是什么？
毕玄：本质也是成本，阿里内部以前有好几套调度系统，这次想做成一套统一的，我们叫 Sigma，向 Borg 的下一代 Omega 致敬。
调度我们做了很多年，2011 年做容器化 T4 就是，核心目标就是为了控制成本，当时我们做了两三年，大概知道了在这方面 Google 的 Borg 做得非常好。
那个时候传闻 Google 认为自己的核心竞争力是什么？最早他就做搜索，他认为自己最重要的竞争力是，一我排序结果的准确度比多数公司好；二做同样的效果我付出的成本是你们的 1/10。这确实是，成本如果差这么远，商业上就没办法做下去了，这里面，Google 觉得调度系统 Borg 承担了很大角色，类似它的 Page Rank 算法，是整体竞争力的一部分。
所以外部很少有 Borg 的信息，保密性做得非常好。后来我们知道一点是，2015 年 Google 发表 Borg 论文，那其实几年前就写好了，只是内部一直摁着不让发，觉得可能对业务的核心竞争力有影响。
极客时间：所以 13 年你们了解到的信息是什么，可以具体说下吗？
毕玄：就是个思路。我们知道了以后都觉得哇这个思路简直太完美了，其实大家都能想到，但我们需要有人给信心，因为这个思路大家都觉得太难。
是这样，因为多数公司的机器会分成很多个池子，最典型的是一个机器池子用来跑在线业务，另外一个用来做大数据的业务。
大数据这个软件的核心设计思想就是尽量并行化，把一台机器的资源全部吃光，所以大数据特别吃资源，能把池子用得特别满。而在线业务，不是不想吃资源，它必须考虑的是什么？是稳定性，如果出问题了，我最好要有足够的冗余，加上一天还有很多不确定的高峰，所以我机器的余量一定是为高峰准备的，利用率就没有办法很高。
极客时间：在线的机器量，可以根据高低峰来伸缩吗？
毕玄：但事实上这是一个悖论。因为对在线来讲，稳定性是最重要的，如果你不断伸缩，万一出问题了，可能得不偿失。很多高峰是无法预测的，即使是淘宝看起来都是做大促才有高峰，但如果有个社会热点，除了微博，淘宝也会受影响，以前比如谁出了名，有了件衣服同款，那立刻爆。这种事情是没有办法预测的。
除非你可以做到秒级以下的伸缩，那可以。我后来带调度，也给了人去探索这个方向，但必须说真的很难，至少目前我们觉得从技术上来讲很难突破，伸缩的风险不那么可控。
极客时间：所以一方面是大数据机器用满，一方面是在线空闲，在线也不好伸缩。
毕玄：很多公司到了一定规模，在线机器增长其实还好，因为在线跟业务基本成正比，就是 QPS，比如说现在 100，明年你希望做到 200，那我就加机器；同时，因为每年的机器比上一年更好，所以从预算角度来讲，公司觉得是合理的，业务增长 20%，你机器增长比如 15%，那当然可以，至少没多出钱，能接受。
但大数据就有问题了。通常大数据机器只要开始用了，每年的增速会越来越快，因为存储量一直在那，而大家想采集的数据细节会越来越多，这样才能更精准地画出特征，所以大数据的机器就会多；另外公司的经营一定会越来越难，以前增长比较容易获得，可以粗放式，但后面你肯定要精细化，但精细化对大数据的要求又越来越高，所以机器会越来越多。
这个时候，技术层面大家都很容易想到一个方案：既然在线这边这么混，大数据这么满，能不能合在一起，让大数据用在线？这就是当时 Borg 给大家的核心思路。
极客时间：把在线和离线混部？
毕玄：对，但其实Borg 自己压根就不是这样，它诞生的时候就认为这两个本来应该在一起，我们以为一组机器跑大数据，一组机器跑在线，它一开始就认为干嘛要分？所以这就是 Google。
极客时间：理念先进，都是机器，我只是时而跑离线时而跑在线。
毕玄：你说对了，Google 觉得反正我机器在这儿了，该跑啥就跑啥，哪有说这个机器只能用来跑这个，没有。
Google 当年有一个高管跳槽到百度，他第一次看预算的时候发现还分大数据机器和在线机器就很疑惑，为什么还要分机器类型？他说我们从来不分。所以百度后来做了 Matrix，拿了两次一百万美金的百度最高奖。其实百度 Matrix 的思路就来源于 Google。
　
极客时间：在离线混部，这个思路倒很直白。
毕玄：这个思路大家确实也能想到，也都觉得应该这么干，很多人就会问了：为什么不这么干？那肯定是有原因的。
从技术上讲，大数据跑到在线确实有很多问题。首先机器以前是分开的，最典型的就是通常在线机器是 1 块盘，大数据机器是 12 块盘，因为它跑的时候需要算非常大的数据，但在线以前数据量非常小，大数据上去跑的时候，存储不够，大家觉得没法搞。
另外物理的基础设施条件也有要求。
第一在线机器和大数据机器要在同一个城市。比如从 A 到 B 的网络我们叫城际带宽，如果不在同一个地方，意味着要走这个，但城际的网络带宽非常贵，你如果跑大数据就更不得了，要求非常高，这条路是不可能的，所以首先要的是大数据和在线搬到同一个机房。
而且当时物理基础设施除了机房，还有网络的问题，以前我们的网络是千兆，对大数据来讲不够用的，它需要万兆以及更高。千兆就要搞各种限制，所以也很痛苦。我们 2014 年只能在上海机房搞个小的试验环境，去做一些试验。
除了基础设施，还有干扰的问题，因为大数据任务会吃光所有的资源，如果你在线也同时跑，会不会影响到在线业务的稳定性？如果被干扰了，导致你的响应时间下去了，就完蛋了，在线业务会不惜一切代价保稳定性，你想如果业务都挂了，省钱有什么意义，对不对？
极客时间：以前机房分开也是出于成本考虑吧？
毕玄：对中国西部城市比如说内蒙古，电非常充足，电费非常便宜，加上温度通常比较低，建机房就很好，很省钱。但问题是互联网的出口通常又在一线城市比如北京、上海这几个点，做在线业务是需要互联网出口的，我必须在这些城市或者附近。
这就奠定了以前大数据、在线都在不同机房，所以 Google 这个思路一开始在中国就做不了。当时我们面临的第一个挑战就是这个，怎么说服高层阿里建一个大机房，让在线和离线搬到同一个地方去？
但这对任何一家公司都是一个非常大的决定。建一个大机房是几十亿的投入，要找到一个地方电费便宜，也要在互联网出口附近，也要探讨清楚 ROI 到底是什么？因为开始肯定要增加投入，以前没有这些，现在砸好多钱，你到底能不能省回来？这就是又是那个论证问题。
极客时间：所以机房问题，团队也没办法，只能等公司决策？
毕玄：那没办法。现在阿里是建在张北、南通等几个地方，但你看这几个地方显然都不是大城市，但离大城市又不远，既享受到了电费、气候，又享受到了互联网出口，这就是非常好的选择。百度最早在阳泉也是，建了一个 30 万台机器的大机房，然后是阿里 15 年建的张北，腾讯也开始，后来思路就全部统一了。
极客时间：后来阿里建了大机房，是因为说服了高层？还是看别人做了？
毕玄：那倒不是，阿里有很多原因，主要是因为云起来了，对我们来讲小机房效率不是很好。所以后来统一调度能做，也很难讲，可能是时机比较巧。
反正后期走这个方向的公司都很痛苦，因为你前期物理设施不是按照这个来的。像 Google 是一开始就是这么来的，所以它不存在这些问题。我们后走这条路的都很尴尬。
　
　
极客时间：在离线混部这么多问题，当时感觉都没有解法，你们做的时候有信心吗？具体进展是怎么样的？
毕玄：信心是有的，因为统一调度说实话跟做异地多活不一样。
这次有参考对象，只是资料不公开而已，但大思路在，所以你的大方向是有的，异地多活是没有大方向的，纯靠自己摸索，完全不知道能不能走通，很可能会走挂，但调度，我们觉得 Google 能干成，至少这条路走下去应该没问题，不会走不通，只是要解决的问题肯定非常多而已。
但在阿里，必须说我们做这件事情难度比百度更大。百度是高层 Push 大家这样做，而且大数据团队有很强的动力，在阿里，我们有很强的动力，但我们是在线业务团队，不是大数据团队，这个事想做成，很多工作是要大数据团队做的，当年他们还有别的很多事情要干，觉得这不是我的重点。
所以各种原因，尽管我们从 14 年开始做，但进展一直比较慢。
物理上的限制，是等 15 年建大机房了才有可能性了，然后网络要升级到万兆，上面升级到 25G，40G，100G，到了 16、17 年那个时候网络都具备了，也没有问题。剩下要解的核心问题就是大数据对在线的干扰，还有两边机器的磁盘不一样。
极客时间：磁盘问题，后来网络好了是不是就解决了？
毕玄：网络升级上去之后我们可以走计算 - 存储分离。
但计算 - 存储分离内部当年也争论非常大。原因是大数据软件在一开始的核心设计思想，除了高度并行、充分使用资源，还有一个是“存储和计算一体化”，就是调度的时候会尽量让任务和存储在同一台机器上，这样算起来最快。但你现在告诉大数据团队不要放在一台机器上，这其实挑战了大数据的很多思想。
所以内部争论非常巨大，但我们反正可以逼着你必须走这条路，比如说卡预算各种。
极客时间：跟以前异地多活一样不给你分机器？
毕玄：对，因为我所有机器是没有磁盘的，你必须走分离，否则我在线给你机器你也跑不了。
所以基本等 16 年阿里开始大力提统一调度，也有了正规军，很多问题才慢慢被解决，一是物理条件具备了，其实是 18 年才具备的，但大家在 16 年开始探讨，觉得这个方向可行，基础设施就去配套准备，所以大机房、网络都在那两年完成了。
极客时间：到 16 年那个时候，对在离线混部方案的价值，大家的认知也统一了？
毕玄：我觉得很大的原因是预算上大数据对成本的压力已经非常大了，必须要控制。
但控制的思路我们探讨了很久，觉得最好最完美的仍然是 Google。你想，在线有一大堆机器在手上，如果能把大数据跑上去，相当于不用花钱的，大家拍脑袋想都觉得能省好多钱，是个好方向。
极客时间：现在就剩下干扰问题。
毕玄：对，就是阿里的操作系统团队。系统软件部在我一开始组建的时候，操作系统团队可能只有 10 个人左右，人很少，然后到 2018 年的时候大概有 100 人，主要就是为了解决干扰问题。
极客时间：你们当时遇到了哪些问题，业界有参考吗？
毕玄：Google 尽管在论文里提及一两句，但不会讲更多细节，他论文的风格一般是这样，只是告诉你我很牛，但要怎么做到这么牛不会讲。你只能自己实践。
我们就必须靠大量人力去堆，在这个过程中肯定会出问题，但只要出了问题以后我有专业的人，可以把问题迅速解决掉就能做。所以我们其实是这样摔出来的，也没有什么。
这因为一方面公司信任，另外一方面是我们的在线业务有回滚、容灾各种策略，也有异地多活可以切流量，相对来讲是在比较安全的情况下做尝试，所以我们也不太在乎，出问题了就把流量切走。
　
极客时间：你们当时尝试的结果怎么样？
毕玄：从 2016 年到 2018 年，我们大概跑到了 1 万台机器，相当于在线有 1 万台可以给离线用，那一年离线少采购了 5000 多台机器，1 台假设 10 万，所以一年省了 5 个亿。
关键是不光这一年，下一年我只要继续扩大在线规模，就能继续省钱，到后面每年省的钱会越来越多，因为技术已经是成熟可以被复用的了。方案上、技术层面上肯定不会有太大问题，剩下全是工程，工程是很缓慢的，你就算技术走通了，工程要完全落地也要个周期。
这可以用一个指标直接体现，公司所有服务器全天的平均利用率，像 Google 就只看这个指标。大部分公司应该都小于 10%，阿里 16 年开始做的时候是 8%，Google 发表论文的时候利用率大概是 50%，这意味着 Google 只用 1/5 的机器就可以做同样的业务，离它讲的核心竞争力非常接近。
极客时间：为什么业界、阿里和 Google 差距这么大？
毕玄：中国公司更难是因为我们不是全球化的，大数据是很高，但晚上没有流量在线就是零，所以你平均一下就完蛋了，利用率就很低，但国外很多公司会好一点。
以前我们问 Facebook 这个问题，因为 Facebook 没有学 Google 走统一调度。我们问为什么？Facebook 说因为我的在线业务全天流量都还挺高的，因为它是一个国际化的网站，全时区覆盖。那我们没有，中国公司这一点确实是个问题。
极客时间：所以从那之后，利用率就成团队重点关注的指标了？
毕玄：阿里每年就在不断地推进利用率指标，我们甚至讲到连财务都理解了，财务挑战研发线的服务器成本，他不关注其他，只看利用率要拉上去。
以前，研发的服务器投入，财务线的人是没有方法挑战的。你说要采购 100 台，财务说太多了，你说业务有多少需求、量多大，所以需要采购，然后财务听完晕倒了，他没有办法反驳你，因为你是拿业务在说事。但后来我们的财务就说看看你们利用率才多少，为什么要采购？不给批。我们训练了他们怎么挑战研发，就很好，连我们 CFO 都懂。
极客时间：利用率，阿里现在做到多少了？
毕玄：我是 2019 年初不带这个团队了，当时从原来的小于 10% 做到了 20% 左右，相当于翻倍了，就意味着成本有可能减半。
Google 这两年据说已经推到了 60%，我们以前认为 50% 是天花板，不可能再多。以前财务也问，你们说利用率可以低，但得告诉我多少是合理的。我们总不能说小于 10% 是合理的，这解释不过去，从技术上也得编个理由，但 50% 我们说是可以解读的。
一是因为这是全天的平均，如果说 50%，意味着高峰肯定会比较高，平均一下已经很少了。第二是多数 CPU 的设计原理都是超线程，你看到两个核，物理上只有一个核，只是说软件层面具备跑出类似两个核的能力，但其实是不可能跑得出来的。所以我们说就打个折，当然这有点忽悠，但财务线非 IT 的人可以理解，觉得比较有道理（笑）。
极客时间：但是现在 Google 推到 60%，这套解释又说不过去了（笑）。
毕玄：没想到 Google 竟然又突破了，做到 60% 左右还是很稳定，所以我们觉得它就是天花板了。
现在阿里这个团队还在做，去年做到了 30% 左右，天花板是 60%，阿里规模这么大，我们假设 50% 是天花板，那 30-50% 也还有很大空间值得努力，ROI 还是非常高的，所以这个团队一直评价都非常好。
　
　
极客时间：调度系统 Sigma，你们当时做的挺早的，看报道 K8s 生态起来了之后，你们就把 Sigma 的技术栈换到上 K8s 了？
毕玄：那是后来，我们 2016 年做的时候，Docker 最火，K8s 还没起来。当时在调度上的竞争非常激烈，因为调度其实会把下面的容器屏蔽掉，Docker 觉得如果自己不往上做调度很危险，就开始做 Swarm，然后 Mesos 是另外一家，Google 刚把 K8s 开源出来。
而且 Google 以前也不做开源，他的套路是发论文然后什么都不干，但他在大数据上的伤害比较大，之前他发了 MapReduce 那几篇三驾马车的论文，发现自己啥也没得到，然后什么 Hadoop 公司全起来了。
关键是后来他做云，云上放 MapReduce，但所有开发者用的接口全部是 Hadoop 接口，导致 Google 不得不去兼容 Hadoop 接口，简直太搞笑了。他们内部觉得我 MapReduce 做的比 Hadoop 好太多了，我是个成熟的很牛的东西，你们竟然不用。
那之后 Google 才发现重要的不是发论文，是做开源抢占开发者，所以在 K8s 上，Google 吸取了教训，开始对新套路有点概念了，我先发论文占领影响力，然后再发一个论文实现的开源产品。但 Google 不擅长做开源，就找了擅长开源圈子玩法的 RedHat，联合起来做 K8s，因为 Borg 跟内部很多系统搅在一起，没办法开源，只能重做。
极客时间：那 16 年你们刚做的时候，技术怎么选的型？
毕玄：我们当时选择了 Swarm 做 Sigma，但 2018 年的时候 K8s 就基本垄断了，我们很多的业务方用的是 K8s 的 API，访问 Sigma 就不通，导致我们必须兼容 K8s 的 API。
但在兼容上面，我们在很多开源路线上都犯过错误，一开始其实有一个开源的东西，但是我们先自研，然后等开源的那个拥有了最多的用户，我们就不断兼容，但是你兼容会越来越痛苦，因为开源一旦起来以后是一个很健康的社群，有非常多公司的合作，会越做越好，到了那个阶段你是抗衡不了社区的。
所以兼容这条路其实是走不下去的，我们就决定不做兼容，把 Sigma 扔掉，基于 K8s 把 Sigma 做的有些东西放到里面去，就是 ASI。
极客时间：兼容的痛苦是指什么？
毕玄：因为社区的关键问题是控制不住，我们当年经历过很多次这个过程。
比如说一开始对我来讲这个阶段非常重要的需求，对他来讲可能一点都不重要，那我们肯定觉得开源做的不好，需求又很急，我们就大量自研做了很多 Patch 的东西。但后面发现开源一旦起来节奏太快，它增加了很多东西，其实覆盖掉了以前我们做的很多改进，这个时候就很尴尬了，到底是升级成它？还是保留自己？我们后来觉得应该尽快升级成开源，因为会被它拉得越来越大。
极客时间：所以 Sigma 的事大家都能接受？当年大家也不太能预料到 K8s 会迅速起来，所以后来 Sigma 换到 K8s 上是比较必然的事？
毕玄：大家能理解也能接受。确实肯定有些人会很不舍，毕竟做了几年，而且业务效果也在，最后不得不扔掉。
但这确实是我们当年判断的失误，如果更早选择 K8s 会更好。但 16 年的时候我们看 Swarm 和 Mesos，加上 K8s 不成熟，不觉得开源有绝对优势，觉得自研有优势有机会。
所以我们后来反思，做技术选型的时候，如果开源界已经有一个很成功的东西，自己又没有什么很颠覆性的思想，还是拥抱开源比较好，没必要挑战。阿里在开源这条路上吃过很多亏，因为以前都自研，HSF 和 Dubbo 也是典型。
极客时间：HSF 和 Dubbo 是指什么，可以具体讲下吗？
毕玄：HSF 是我们自研的产品，Dubbo 是开源的，在整个开发者群体里肯定有最多用户。但阿里收购完一家公司会告诉他，你把 Dubbo 换了，换成 HSF。
很多公司觉得很尴尬，你们进来之后，业务啥也没干，先把技术换掉了，阿里以前经常这么做。我们后来说像这种，就不应该让别人换掉，应该把我们自己换掉，所以 HSF 后来新版本的目标就是换成以 Dubbo 为核心，支持内部 HSF 协议的解析，这样以后收购就非常简单。
极客时间：我们现在站在事后看，当时你们判断开源不成熟，选择自研 Sigma，是不是因为大厂不可能说等两年，等开源成熟？
毕玄：不可能等，而且大厂确实挑战也比较大，要解决的问题很多，所以如果开源如果不是很成熟，很难说我一开始就选择开源。
极客时间：但一个领域，开源如果已经成熟了，大厂才开始用，是不是说明你们没有更前瞻地看到这个领域的问题？
毕玄：大厂很有可能比开源看到更快，所以确实就是你说的很尴尬，现在大厂的自研走上了一条很尴尬的路线。
开源反噬自研是之后业界的长期话题，以前很多公司都是自研，但现在开源已经被玩得太多了，什么都开源，那之前的自研到底怎么办。
反正我们的判断就是，如果开源的东西已经是主流了，比如说像 Spring cloud，那没必要做一个新东西再去跟它竞争，因为我们也只能靠开源去争，但如果没有革命性进步，关键也竞争不过他，所以我们后来做了 Spring Cloud Alibaba，就是觉得我竞争不过你，跟你一起玩好了。策略就是这样，总体还是拥抱开源，因为你要么就自己做个开源，要么就用开源做，就这两条路。
　
水友讨论区今天的对谈到这里就暂时结束了，重点聊毕玄当年做统一调度的经历。
虽然这些年毕玄换了不少领域，但从他对成本的关注这条线讲，之前做的所有事情又能大概串联起来，最早做的容器 T4，到后来的异地多活，到今天的统一调度，后面他创业选择的方向也是做企业的云成本控制 FinOps。这么看，成本可能是一个企业始终关注的话题。
Google 当年分析自己的优势也提到这一点，一是排序结果的准确度比多数公司好，二做同样的效果付出的成本是其他人的 1/10。分析自己所在的团队 / 公司，你觉得优势是什么呢？
关于统一调度的技术选型，我们也聊到了开源和自研的问题，毕玄的反思是“如果开源界已经有一个很成功的东西，自己又没有什么很颠覆性的思想，还是拥抱开源比较好。”你是怎么看的呢？
如果你有更感兴趣的话题，欢迎在评论区留言，如果觉得有启发也欢迎分享给身边的朋友，一起讨论。
读到这一讲，时间线已经走到了 2018 年，毕玄马上就要从阿里离开了，下一讲我们聊聊这个话题。下一讲见。
拓展阅读如果你对统一调度的具体技术细节感兴趣，可以看这几篇：
阿里云云原生写的揭开阿里巴巴复杂任务资源混合调度技术面纱
阿里巴巴中间件写的：给 K8s 装上大数据调度引擎：伏羲架构升级 K8s 统一调度
云技术的新变革：阿里云 13 年后重构全部核心调度系统

分享给需要的人，Ta购买本课程，你将得18元

生成海报并分享

赞 7

提建议

08｜基础团队：研发效能部门，解决不了研发效能问题

10｜出走大厂：离职？还是不离职？这是一个问题

 写留言

精选留言(5)

唐超伟
2022-10-02 来自浙江
调度这个不太懂利用率是怎么计算的
作者回复: 利用率最简单的是看对应的核心指标，例如计算型的业务看cpu，内存利用率，存储型业务看磁盘空间利用率，磁盘iops利用率等。
6
sesamegu
2022-10-07 来自浙江
统一调度想法好直接，不过里面要解决的问题很多，收益到时很好量化
1
Geek_6b0f6f
2022-11-30 来自浙江
google CPU使用率做到50%，阿里做到30%，有什么paper介绍吗？平均使用率做不上去是因为高峰期间无法满足需求吗？
作者回复: 可以去看下borg的论文。平均使用率上不去的主要原因是业务通常都有波峰波谷，以及为了保障业务的高可用，通常要做不小的冗余，如果一直靠临时的弹性，一方面风险太高，另一方面业务的高峰什么其实并不是那么好预测。
术子米德
2022-10-27 来自浙江
🤔☕️🤔☕️🤔 【R】谷歌式的调度不区分机器，思路的起点就不一样，人家做到且认为这是它的核心竞争力之一。【.I.】核心竞争力，问问自己到底是什么？会卡壳。我个人的核心竞争力，来自规划，还是来自总结，或者在别人的反馈里，挑选出几个所谓的竞争力。这真的蛮伤思考力，如果有所谓的思考力的话。如果把竞争力，当做一个目标，以结果形式呈现，那就得问自己，到底怎样的竞争力，在未来的某个时候，以怎样的形式体现。同时产生的问题就是，我到底为何需要这个或那个竞争力，才有从其中挑选所谓的核心竞争力。如果动机来自爱好，似乎喜欢就好，谈何竞争。如果动机来自生存，紧缺时你死我活，宽裕时随遇而安，要么战争，要么平和，谈何竞争。如果动机来自欲念，有还不够要更多更好，到左手换到右手点功夫，就已经嫌弃不够，才是满脑子的竞争。如此说来，核心竞争力的起点，是对欲念的挖掘，只有给自己开掘出一个巨大无比的欲念之坑，才有核心竞争力启动的原点。至于所谓的核心竞争力，无非就是填欲念的路上，人家没有的我有，人家都有的我更强或更省。【.I.】开源，OpenSource，它的本意是开放源头，即让大家知道这玩意儿哪来的，或者说这玩意儿谁在主导。顺着这个思路，即谁在主导就能够看清，或者说可以作为评估如何采纳开源的思路。典型如K8S，谷歌带着红帽小弟在主导，明显其动机是让市面上不再有其它竞争者，那就使用其最好的部分，改造适配到自己的场景。【Q】谷歌的工程师，给我的感觉，除了技术能力，就是所谓的硬能力，还有更多产品意识和价值意识，就是所谓的软能力。在我之前的认识里，硬能力最重要，但是现在发现，软能力同样重要。更伤心的发现，软能力没有在成长过程里得到指引和学习，无论是在学校还是在工作之后。想咨询一下老师，对于软能力有怎样的看法，如果涉及到培养，如何在学校里和工作后持续驯养这种能力？ —— by 术子米德@2022.10.27
展开
作者回复: 软能力，尽管有很多各种各样的培训，但我感觉这个还真挺难，感觉好像还得有师傅带这样的方式。 K8S能做起来，很大程度是因为G家找了红帽这样的师傅。
Jun
2022-09-30 来自北京
Facebook有个叫Twine的系统，也是统一调度的

