终于在 2023 春节上班之后的第一周把 QCon 北京的演讲搞完了，本文记录一些过程中的点点滴滴。
接到邀请还是 22 年 3 月底的时候，有一天主管问我，有个 QCon 5 月份演讲的机会，你去不去？可以把你手头现在做的工作讲一讲。当时也没有想太多，就答应了下来。
主题是基础设施，然后按照邓邓主编的要求，提供了议题申请单，写了一下大概要讲什么东西，之后就开始写写画画 PPT 什么的，结果一个月后通知，因为疫情会议延期，具体时间待定。等到了 10 月份的时候，再次通知说定到了 11 月份，想着这次应该没有问题了吧，结果天不遂人愿，疫情再次冲击北京（也就是放开前最后的那个月），继续延期待定。12 月份放开后，基本上大家全感染了，邓邓发来个单子，统计了下每个人的期望时间信息，最后春节期间，终于反馈说，敲定了 2 月 5-7 举办。
最终确认 2 月份举办的时候，PPT 已经过去半年了，都有点忘了… 本来计划年后请一周的假，也提前了 5 天赶了回来，毕竟还要再准备下 PPT，以及更新一些近半年的内容。按要求是演讲 45min，所以准备了近 40 页的 PPT，以及对应的演讲稿。折腾这些东西也花了几天的时间，包括重新整理演讲思路，整体结构，还有需要画的各种图等等。
因为 QCon 报销了讲师的所有打车、车票、酒店的费用，想着大床房不能浪费，就和老婆一起去北京了，她玩她的，我准备我的，都开心 😋 毕竟疫情也是憋了快半年了。
2 月 4 日晚上到的北京，和一个大学同学简单叙了下旧，就入住酒店了。在亮马河边，还是比较舒适的。
2 月 5 日
早上去了四季酒店，签了个到，拿了讲师的牌子，之后就可以畅通无阻看各个演讲了，相关记录如下。
FinOps：从概念到落地
上午的场子是三个宴会厅合在一起的，巨大无比，9 点 10 分去了就已经没什么位子了，毕姥爷的演讲，怎么也得认真听一下。
全文主要讲了 FinOps 这个概念的前世今生，以及毕姥爷自己在这个方向创业所看到的问题、场景和解决方案。因为 FinOps 主要还是从创业者自己或者管理层之类的，从成本角度出发，在当前这个降本增效的大背景之下，尽可能的在维持业务及架构稳定性的基础上，降低在云服务上的开销。毕竟钱不好赚的时候，还是需要省着点用的。
一个关键的前提在于可衡量。毕竟如果你不知道你自己的公司里面的云资源当前的水位是什么样子的，那就会被技术牵着鼻子走了，说多少是多少。这里提到了一个最简单的衡量指标就是全天或一周的平均资源利用率。毕姥爷表示，目前大部分企业的计算型节点全天的平均 CPU 利用率是 < 10% 的，建议使用 < 20% 作为是否浪费的衡量标准。
在提升资源利用率方面，提到了几种方式：
- 充分发挥单机能力。一种是降低云服务的规格，另外一种是通过 Auto Scaling 进行高峰时期的动态扩容。但也都有缺点，尤其是 Auto Scaling 在突增高峰的场景会来不及反应，而且也不太适合高频操作什么的。这里举了一个 airbnb 的例子，在 2020 年通过 Auto Scaling 节省了 5% 的云资源账单
- 结合错峰复用及不同优先级任务混部，充分发挥整个集群的能力。这块技术上非常成熟，但实现难度也非常的高，但实现之后，对整体的成本优化效果非常明显。比如 Google Borg 论文揭示，Google 在实现混部之后，降低了 20%-30% 的机器数量，整体利用率可以提升近 50%
- 通过 Serverless 提升资源利用率。这个是理想的终极方案，也就是完美的实现了按实际请求计费。但缺点是目前适用的场景还很有限，离关键的在线类型业务的 Workload 采用 Serverless 还有很长的距离，有很多的技术难点需要等待去突破
因为面向国内，所以全程毕姥爷也是很默契的只提海外报告及数据，不提国内 🙂
开源芯片的发展现状、机遇和未来
这场演讲是中国科学院计算技术研究所包云岗带来的，算是给我这种小白做了很不错的科普介绍，全场看下来大概就是芯片这块前路漫漫，荆棘遍地，还需要大家共同努力。
芯片设计整体是四部走，首先是根据指令集手册，通过微架构设计，产出设计文档；再通过工程开发，产出 RTL 代码；最后再通过 EDA 工具，产出芯片版图。
因为处理器的指令集大部分都属于公司私有，无法获取，或者说需要授权费，所以 2010 年，UC Berkeley 开始开发一套开放免费的指令集 RISC-V。
其中有一页 PPT 是关于 RISC-V 的五个谬误，觉得很不错，记录一下：
- 谬误一：RISC-V是开源处理器，就像 Linux是开源操作系统一样
- RISC-V 是一种开放标准，类比于以太网标准、USB 标准
- RISC-V 国际基金会类比于制定以太网标准的 IEEE 802.3 工作组
- 谬误二：选择成熟封闭式 ISA 比选择开放式 RISC-V 更安全可靠
- 封闭式 ISA 与公司命运绑定，若公司不景气，ISA 就会消失，例如 DEC VAX、DEC Alpha 均已经绝迹
- 封闭式 ISA 并不代表稳定，如 MIPS 被卖给六家企业，ARM 有三个东家，商业模式随不同东家而改变
- 谬误三：封闭式 ISA 没有碎片化的软件生态
- ARMv1 到 ARMv7 使用 32 位地址空间，ARMv8-A 支持64位，但和 ARMv8-M 不兼容
- 谬误四：相比封闭式 ISA，RISC-V 的模块化会导致软件生态更碎片化
- RISC-V 已通过配置机制(Profile)规范化软件生态
- 谬误五：鉴于以上几点，RISC-V 不可能成为主流ISA
- 技术上，RISC-V 可以支持从嵌入式到超级计算机
- 商业上，更开放的标准更有生命力
当前，高性能 RISC-V 处理器开始涌现，美国这边有 SiFive P670，对标 ARM Cortex A78，主频 3.4GHz@5nm，还有 Ventana Veyron V1，对标 ARM Neoverse v1，主频 3.6GHz@5nm。中国这边是香山V2（南湖），对标 ARM Cortex A76，主频 2GHz@14nm。
最后，提到了中科院联合 18 家企业联合发起北京开源芯片研究院，进行“香山”处理器核的产品化改造和后续架构研发，加速推动开源芯片生态。通过开源模式实现联合开发。
乐观者前行，Infra 出海的挑战与机遇
这个演讲是经纬中国的合伙人熊飞带来的，从投资人的视角来看 Infra 相关的创业和出海注意事项，以及给大家的一些建议。干货很多。
首先讲了当前资本市场的挑战。
第一个是外部环境，2017~2019 年的三年期美债收益率是 1-2%，但因为 2020 年的新冠疫情，迅速降到了 0.1%，美债的低利率大大推动了其他资产价格的提升，也产生了 2020~2021 两年的大牛市。2022 年，美债利率快速上升达到 4.7%，是过去十年的最高水平。利率的高企使得股票等资产的吸引力下降，产生了当前美股的巨大下行周期。毕竟美债是信用最好的，这类超低风险的资产都能产生 4%+ 的利率，为什么还要投入资金到高风险的股市等场景呢。
第二个是估值体系下降。企业服务的平均 PS 从 20 倍下跌到 6 倍，估值分化加剧，市场更看重 NDR 等收入健康指标。
第三个是热点转移。2022 年上半年数据，主要还是半导体芯片以及信息化服务这些。
在 Infra 这个领域，是受资本影响波动最大的，因为收入周期长、早期投入大、客户预算受经济波动显著。这个很好理解，毕竟现在大家手头都没钱了，Infra 这个事情，又不像其他的企业基本盘的服务，Infra 缝缝补补又三年也不是不可以。
在熊飞的视角里，目前 Infra 公司是比较困难的，Infra 公司必须从高增速高消耗，转型为中增速低消耗；从合同为先，到卡住毛利、现金为王；以及创造足够长的战略缓冲器，推荐 24~36 个月。
当然 Infra 公司也有它自己吸引人的一方面，毕竟 Infra 是全球最标准化的产品，以及海外和国内基本是 1 美元对 1 人民币，投入产出比的差异很大，如果能够形成标准，则可以全球通吃。
最后提到了一些落地策略：
- 做好长期的准备，因为实际上一款 Infra 从开始到成熟可能要数年的时间，战略定力要好
- 坐一望二，基于中国，放眼海外。毕竟中国有着庞大的人口基数，可以有更复杂的场景供验证，如果能以更低的成本扛住更大规模的业务场景，出海后是有碾压优势的
- 核心管理团队要走出去，不能远程指挥。出海后需要在当地指挥作战，不然都会输得很惨
- 子弟兵和外部专家的比例要合理。初期的话，可以三七开，70% 的子弟兵，30% 的雇佣兵
- 找准产品的价值主张，注意文化的迭代过程
微服务从 PaaS 到 Serverless 的演进
下午第一场和第二场分别听了字节和百度百科的 DevOps 流程实践。不过整体感觉没有太多的参考，毕竟这块感觉阿里的实践更好 😋 全程参考下就好了。
第三场是字节 Serverless 负责人演讲的，讲的非常好，最后打广告的那本书也在狗东入了，回来细读一下。此处不展开了。
支持亿级制品管理系统的设计
最后一场是 JFrog 的制品管理系统。主要讲了 JFrog 作为一款制品管理系统，内部是如何设计的，以支撑上亿的制品数量。
对于海量的文件存储，使用了去重的存储设计。具体来说就是，文件上传之后，以 checksum 值重新命名，数据库里面存放的只是文件的路径和 checksum。这样可以实现多个相同文件引用到同一个实体存储制品上，降低存储开销。并且在海量文件检索的时候，效率也非常的高。其实就是类似百度网盘这种光速上传的实现。
为了优化服务自身和远端存储之间的响应速度，JFrog 额外设计了文件读写缓存层，分为 Cache-fs(读取缓冲区） 和 Eventual（写缓冲区）。Cache-fs 用于优化 Artifactory 和远程存储之间的流量。这个 LRU 缓存将托管最近上传和下载的制品。Eventual 用于在使用慢速、远程存储时优化上传过程。这会开启异步上传，不需要等制品真的上传到远端存储就可以立刻开始使用。一旦制品已经上传到远端存储中，它就会在缓存中删除自身。
另外 JFrog 也提供了 Docker 的 P2P 分发能力，开启该功能后可以快 6 倍左右。
听完了今天的场次之后，晚上去参见了讲师晚宴，味道不错，也看到了不少大佬，认识了一些人。回酒店之后继续打磨演讲稿，对着镜子顺了两遍之后就睡觉了。
2 月 6 日
今天听的场次不多，主要是还得调整下自己的 PPT 还有演讲稿。参加的场次相关记录如下。
技术领导力实战
阿里的同事演讲的，还不错，比较有参考价值。主要说了一下一个合格的技术领导者应该应该做哪些事情，不应该做哪些事情。
一些反模式：
- 闷头干模式：延续独立贡献者的工作方法，所有方案自己做，所有代码自己写
- 路由器模式：上级任务往下转发，任务结果收集汇报
- 高压模式：对上过渡汇报，对下持续增加，辅以不科学的价值宣导
- 不决策模式：不对任何需求 say no，或者决策全部下放，并让下属承担决策后果
- 有业务无工程模式：高度关注短期业务交付，不管工程质量
如果挑出来一件对技术 Leader 最重要的事情，那么就是招聘。对于人才的重视体现在以下几点：
- 每周花几个小时做招聘、面试、1-on-1 沟通
- 对每次面试严格要求
- 不要因为项目压力而降低对招聘的需求
- 欣赏和你不同的想法和观点
- 充分授权，并敢于对此负责
在面试的时候，需要重视候选人的工程能力（在线编码，历史代码等），对齐职业发展目标，另外也需要看一下是否沟通简单、逻辑清晰。
在 OKR 的制定上，需要关注下面几点：
- OKR 应该体现团队为谁服务（for who），即围绕价值阐述
- 反例：罗列技术指标，且和用户会有什么变化无关
- OKR 应该体现聚焦（即取舍），资源有限，集中精力办大事
- 反例：罗列 8 个 O，20 个 KR
- OKR 应该要尽可能量化（不必 100%），用来校准方向，且量化不应被用来考核绩效
- 反例：全是形容词，看不到数字
- 反例：主管拿着 OKR 告诉员工做到 xxx 绩效就是 yyy
- OKR 的承接应该遵循单一负责人的原则
- 反例：OKR 的负责人没有，或者 OKR 的负责人有一堆
- OKR 应该公开，且根据实际情况沟通调整
- 反例：一线员工看不到主管的 OKR，看不到更高层级主管的 OKR
在如何建设工程文化方面，提出了几点方法：
- 要求代码开放，要求 code review，要求 unit test
- 搭建 CI 看板
- 技术领导者每天参与 code review
- 绩效考核、晋升考核中纳入“技术素养”的要求
- 定义阶段性技术目标，降低系统复杂度（如：下线服务，架构治理）
如果技术管理者不亲力亲为，工程文化往往被牺牲。
技术管理者应该自习 Review 团队中的每一个故障，因为从中可以看到：
- 系统架构是否存在问题（例如：存在不合理的依赖）
- 研发流程是否存在问题（例如：代码提交没有单元测试覆盖）
- 运维应急能力是否存在问题（例如：是否第一时间操作扩容）
多数故障是工程能力不足的症状表现。
另外一个很重要的事情是建设开放透明的文化。有几个不开放透明的例子：
- A 同学把自己写的代码设置为 private，他人不知道其工程能力，老板也不在乎，但是他非常会写 PPT 汇报
- B 同学找 C，D 单独沟通后获取了大量的信息，和老板单独汇报（选取对自己有益的信息），促成了老板做出对自己有利的决策
- B 同学就某个想法找 C，D 聊完后，包装成自己的观点，和老板单独沟通，给老板造成他能力强的印象
- X 领导在一年中多次改变团队目标，但是未和团队解释这些变化的原因，导致团队士气低落
- 晋升季的时候，B 同学被晋升了，但是领导没有向大家清晰的公开晋升标准以及 B 同学何以满足这些标准，导致团队各种猜测
关于如何建设开放透明文化的方法：
- 开放团队所有的代码和文档
- 关键决策公开群组、会议讨论，鼓励离线记录讨论
- 公开晋升、奖励等标准，公开其过程
- 公开团队和个人目标（如：OKR）
最后谈及安全感。管理者需要意识到人类普遍对安全感的需求，对地位和尊重的需求。
从 0 到 N 孵化卓越开源项目实践 —— 一起孵化 Apache SeaTunnel
这一场里面，确实学到了关于开源项目很多不一样的内容，以及不一样的思路。
对于一个开源项目的成功，需要积累天时地利人和几个条件：
- 天时：在合适的时间出现，一般来说，开源项目满足各领风骚数 5 年的定律
- 地利：需要能够一句话说明你的开源项目是什么：产品的赛道、解决的问题、产品的边界。痛点明确、边界清晰才有利于开源项目的扩展，什么都想做的开源项目，基本上都失败了
- 人和：技术大牛 or 屌丝众创，开源影响力，开源理解力，以及团队的韧性
这里郭大侠分析了几个开源项目的例子：
- Spark。天时：Spark 架构的创新、5 年 Hadoop 社区三足鼎立的局面；地利：基于 HDFS 生态，高性能处理；人和：Berkeley AMP-Lab 强大影响力和基金会的帮助。
- ClickHouse。天时：向量计算的论文落地，互联网运营兴起，用户行为分析；地利：卓越的产品定位，以及中俄关系友好；人和：极致产品理念吸引开发者、中国开源的小伙伴、开源社区和运营。
- SeaTunnel。天时：各种数据引擎的引爆、Sqoop 的退役；地利：注重各种数据源的打通，和 Flink、Spark 差异化；人和：中国开源的热度，ClickHouse 社区，DS 社区。
开源的底层逻辑是用户、开发者、商业公司、商业用户之间的信任。信任是可以传递的。对开源软件而言，重要的还是社区，是用户。
社区的核心运营靠的不是运营，而是认知：
- 天时（引爆点）：此时此刻，行业内哪些事情正在发生？未来时刻，哪些是行业趋势，还有多久？过去时刻，哪些类似项目没有火，原因？
- 地利（抓痛点）：伤其十指，不如断其一指。真需求？伪需求？用户是检验开源的唯一标准
- 人和（扩触点）：行业内最有影响力的用户？行业内最有影响力的社区？行业内最具影响力的人？
对于开源而言，需要确认自己项目的核心价值观，谈钱也不寒颤。
- 商业为先 —— 开源获客运营项目
- 开发者优先 —— Apache 项目
- 开源用户优先 —— 为爱发光项目（例如 ClickHouse）
- 人类资产沉淀优先 —— 各种基金会内部项目
- 改变人类优先 —— 各种 AI 项目
关于开源协议，这里也画了一张图，很形象：
对于开源的商业收入模式，也有一张图，可供参考：
今天除了听上面的两个讲座之前，就没有关注别的了。专心在酒店里面打磨 PPT，控制时间到 45min，最终效果自己还比较满意。然后 PPT 的终稿也发给了邓邓这边。
2 月 7 日
今天一大早吃完早饭就去了，途中还被告知今天出品人没来，需要客串下主持人。不过也好，正好提前拿话筒熟悉熟悉，今天我在第三个，先观察下前两个演讲，学习一下。
前面两位同学时间都控制的很好，误差不超过 5min，我也准时开始。其实真的上去讲了之后，反而没有任何紧张的感觉了，整体讲下来效果还不错，需要说的都表达了出来，时间控制的也刚刚好。之前比较担心的 QA 环节卡壳也没有出现，有两位现场观众提问，也都尽自己所能提供出来答案了。
讲完之后和同专题的几个人一起去吃饭，天南海北聊了一通，就各奔东西了。下午和老婆在周边简单转了一下，吃了个饭，就踏上了回程的高铁。凌晨 1 点钟到家睡觉，也算是累个半死。
后记
回来之后的几天，反馈说有 62 开场观众，退场后 58 投票人数，57 满意，1 中等，满意度 98.28%。还真的挺出乎意料的，想想这一周的辛苦也算没有白费，感谢各位观众老爷~
本届 Qcon 相关的 PPT 都可以在 https://ppt.infoq.cn/list/106 下载到。