人人都知道,互联网是个钱多责小离家近的好行业。这个行业流传着许多飞檐走壁技术大师的故事,激励了很多学过高数课的年轻人。本文意在讨论互联网技术大师的修炼之道,试图找到一个共通的速成模式,希望对年轻人有所助益。


第一步:先进大厂


进大厂是成为大师的第一步,无可通融。


有些小朋友说“大厂HR卡学历,不让我进,可我还是想当技术大师,怎么办啊?“


我只能遗憾地表示,小朋友你生不逢时啊。


你看那些到处开课的技术大师,他们十几年前入职 Google /阿里/腾讯的时候,你还系着红领巾在小学校园里玩老鹰捉小鸡;今天你都参加工作了,大师的头衔还是 Ex-Googler/前腾讯架构师/前阿里云研究员。你简历里没有这么个招牌,名片都不好印啊,到时候你请的水军都不太好吹啊。


有小朋友问我:“按你这么说, Linus Torvalds 也不够格了?”


我查了一下,这个叫 Linus Torvalds 的,本硕学校倒是不错。赫尔辛基大学在 QS 排名 96,算是荣誉 985 吧,可以保他的简历不会因为双非被扔掉。但是毕业后的工作经验不太行,先是在没名气的 Transmeta 干了五年,连个小组长都没升上去,后来在一个叫 OSDL 的莫名其妙的公益组织干,估计 package 里只有基本薪酬。HR 这一关,他恐怕难过。


等等,我眼睛是不是坏了?他是1969年出生的?今年55岁了?大厂 35 岁的工程师都算重点清理对象。他这个超龄 20 年还没当上小组长的工程师,只能当晚班保安啦,就不要谈什么技术大师了。


第二步:要公开地鄙视工程技术


围棋大师要热爱围棋,电影大师要热爱电影,文学大师要热爱文学,这好像是天经地义的。


但是我们习惯于降维打击的互联网行业从业者从来不在乎这些规矩,恰恰相反,互联网的技术大师是鄙视和憎恨技术的。


你和中国互联网技术大师坐下来吃火锅,90%的可能性,你还没吃到第一块羊肉卷,就会听到一句话:“技术是为业务服务的。”


90%的可能性有另外一个技术大师附和:“是啊,是啊,技术不赚钱,赚钱的才是技术。”


那么,“技术是为业务服务的”这句话究竟意味着什么呢?我大概归纳一下,有两点:


1. 软件工程团队是业务方的施工队。


2. 施工队不需要什么工程能力建设。


软件工程团队是施工队


这是一个事实。互联网公司的竞争力不来自于 IT 技术。滴滴不是由于 App 做得好才被司机采纳的,淘宝不是由于 Java 写得好才吸引商家的。马化腾和张小龙想要揽功的时候,都号称自己是第一产品经理,或者谦虚地说第一产品体验官,从来不说自己是第一架构师或者第一程序员,这也说明产品经理才是团队的核心角色。


互联网公司里,软件工程团队的任务是把产品经理的图纸在机器上用代码落地;工地上,施工队的任务是把设计师的图纸在地基上用混凝土落地。两者定位几乎雷同,最大的区别是,设计院不能随便修改图纸,而产品经理可以半夜在钉钉群里@倒霉的码农改需求。


所以,有年轻人问技术大师:“大师,你怎么还在用过期三年的MySQL 5.1/过期四年的CentOS 6/过期十多年以至于算不清究竟过期十几年的 GCC 4.2?” 大师就会坐下来,语重心长地和年轻人说:“技术是为业务服务的。新版本的 MySQL 能给产品带来营收吗?不能。老版本的 MySQL 会妨碍公司毛利润吗?不会。所以,年轻人,不要盲目追求新技术,要围绕业务价值思考问题。” 不等被绕晕的年轻人醒过来,大师已经飘走了。


像芬兰 Aiven 公司这种通知邮件,技术大师们是一定不会发的:


所有在我们平台上运行的、已开启的 Aiven for Kafka 3.5 版本服务,在 2024 年 7 月 31 日之后将接受强制性维护更新至升级路径中的下一个版本 3.6。


这些更新对于服务的持续安全和稳定至关重要,并为您提供新功能和增强。为了简化流程,Aiven将完全代表您管理版本更新。


因此,这些更新无法被禁用,但您可以通过在到期日 2024 年 7 月 31 日之前随时启动升级来定制体验,以测试与您的应用程序的兼容性,并减轻任何与 Aiven for Kafka 3.5 依赖相关的意外问题。


要知道,Aiven 公司的主营业务就是代客户维护 Kafka 集群。他们居然冒着触怒客户的风险,强迫客户升级 Kafka 版本,简直是以下犯上,和互联网技术大师们的理念完全不符。


施工队不需要工程能力建设


承上所述,既然是施工队,那么吃苦耐劳就是第一美德。技术大师作为施工队的包工头,从经理那里接活,派到码农头上,就尽到主要职责了。


有些人说软件工程团队也是工程团队,因此要写文档,写测试用例,做代码评审,建持续发布系统,扫描安全漏洞,还要维护 API 兼容,甚至对变量命名规则挑剔得很,要用什么 linter 工具在什么 CI 系统里自动检查。实不相瞒,互联网从业者管他们叫繁琐学派的老学究。互联网从业者们在技术大师的带领下,就一个字:快。如果你要三个字,那就是:短!平!快!


我们以 API 为例。像Werner Vogels 这些外企老学究,就在发布 API 的时候怕这怕那,他在2020年接受Tom Killalea采访[1]的时候说:


我想指出另一件事。亚马逊作为零售商和AWS在技术上的一个重大区别在于,零售业可以大胆实验,如果客户不喜欢,你可以关闭它。但在AWS中你不能这么做。客户会在你的基础上构建他们的业务,你不能仅仅因为不再喜欢它或认为其他东西更好就拔掉插头。


你必须非常谨慎地关注API设计。API是永恒的。


作为对比,我们可以看下大师们怎么快速制定 API [2]的:



互联网行业里,这是一个非常好的文档。只有学究们才会注意到:


1. Json 不支持注释符号,这实际上是一个非法的json。


2. 大多数变量命名是帕斯卡命名法,但是Member_Account是独创的蛇形帕斯卡双重命名法。


3. 人类看到的第二个 Member_Account 的值是“peter”,但是愚蠢的计算机看到的是前后有空格的“ peter ”,这会导致测试案例失败。


4. Shutup 英文的意思是“闭嘴”,对应的中文写成禁言,实在是太客气了。


但是,如上所述,技术是为业务负责的。即时通信业务大获成功,根本不需要在乎这些软件工程中无关紧要的细节。


我们的技术大师们,主要关注点更高的维度:



正如技术大师们常说的那样,初级程序员才会在意计算机语言的优劣。像 Mark Russinovich 这样,身为微软 Azure CTO,却故意引发 Rust 和C/C++ 语言的争论,很可能是因为他没有掌握上面那个词汇表,所以他只能谈点技术。



第三步:当好画家


有时候,在成为大师的路上,在写 PPT 和听 PPT 之余,你也会被逼着搞技术,比如要你做个架构设计。


这时候,你就要祭出大绝招:四横三竖藏宝图。


这个图几乎像孙悟空一样多变,可以用来应付一切差事。下面我列举几个样板。


1. 这个云平台架构图[3]



2. 这个微服务架构图[4]



3. 这个大数据平台图[5]



细心的朋友能看出来,这些图虽然来自不同的厂商,但是结构上有共通的模式:


1. 横向的分为三层、四层或者五层


a. 先不管什么架构,最底下一层放计算、存储、网络三个方块,总是没错的。


b. 然后往上堆两个中间层,可以是资源池,可以是PaaS能力,也可以是机器学习模块,凭你兴趣,随便自选,反正没人认真看。


c. 上面一层,就比较讲究了。


i. 如果是卖出去的产品,你这一层最好是金融应用/政务应用/新能源应用三个小方块,显得你已经考虑过业务场景适配了,是懂得支持业务的技术老专家。


ii. 如果不巧是公司内部使用的平台,你这一层就可以画一条长长的横线,写上“流量统一接入层”,或者“用户自助服务Console”,显示你在为公司打造一个通用的技术底座。


iii. 如果实在不是有多个用户的系统,你就画个虚线,然后放个火柴人,注明“系统用户”,显示你充分考虑到公司跨部门的拉通协作,形成了价值闭环,是值得提拔的高潜人才。


2. 竖向的,就分三列


a. 中间一列,放上面说的几层。不再赘述。


b. 左边放运维系统。你把统一日志、统一告警、统一巡检几个小方块放进去,就很合适。注意统一两个字不能少,这显示你设计系统的时候,充分考虑了要给公司打下共享的技术底座。


c. 右边放安全系统。这一列必须是一个绿色大长条一查到底,显示你这个图里有一个全栈的安全考量,让人感到放心。当然,长条里面,你还是可以放点认证、权限、DDoS、漏洞扫描、安全教育之类的方块。


d. 有时候,你需要拔高高度,可以把上述两列合并成一列,让运维和安全挤一挤,腾出地方画一列“大数据管理制度建设”,显示你不仅负责做技术架构,还考虑了整个软件生命周期的交付阶段,连客户的制度建设都在你的规划之中。


3. 没有了


    有年轻朋友问:“你这个架构图全是长条块和小方块,看不出模块关系,也无法指导开发,有什么用啊?”


    我就要代技术大师们说一句了:“差不多得了。架构师不是神笔马良,画出来就可以了,难道还真的负责变现啊?”


    记住,你是架构师,也是画家。高级画家要留白,留下空白供观众去想象。你的架构图也要留白,留下空白供码农去猜测。


    第四步:不要写代码


这一条很直观,我们就不加解释了。互联网的技术大师没有一个写代码的,就像外企员工都有个Peter/Sunshine 英文名一样,属于行业惯例。


我们倒是可以看看外国的一些反面例子。


Rob Pike 生于1956年,比上面那个芬兰来的 Linus 还大十三岁。本来他心智的调性还是有体感的,进了 Google 公司,但是因为没能调到山景城总部的原因,缺乏端到端的拉齐能力和高维度的认知格局,在发明 golang 之后没能打出联动组合拳,无法塑造一个有感知度的护城河作为业务抓手,总而言之,没有给 Google 赚到钱,所以他 67 岁了还在一行一行地写代码[6]



甚至在 2024 年新年第一天,还在改文档[7]



年轻朋友们,引以为戒,不要重蹈他的覆辙了。


总结


技术大师自然不是四步可以练成的,还有第五步开源软件参数炼丹,第六步开源软件魔改毁容,第七步自建三角轮子,第八步造百亿用户高并发系统,第九步提出哲学理念云原生 4.0,第十步跪求公关发稿打造神话。但是限于时间,我们就下期再谈了。


参考资料:

[1]2020年接受Tom Killalea采访:https://queue.acm.org/detail.cfm?id=3434573

[2]腾讯大师们怎么快速制定 API :https://avc.qcloud.com/wiki/im/wiki_pdf/4_jishitongxunyun/3_shujuguanlirestjiekou/6_qunzuguanli.pdf

[3]云平台架构图:https://bbs.huaweicloud.com/blogs/299434

[4]微服务架构图:https://cloud.tencent.com/developer/article/2071724

[5]大数据平台图:https://help.aliyun.com/document_detail/85629.html

[6]67岁了还在一行一行地写代码:https://github.com/robpike/ivy/commit/37646b2ee1ca79a56aa7c8d4866ba307567eb3fc

[7]2024 年新年第一天,还在改文档:https://github.com/golang/go/issues/64919


本文来自微信公众号:云计算散弹枪(ID:Young-Ziyi2),作者:瑞典马工