996、单身汪、挣的多花的少…似乎一直都是码农的标配，那当夫妻二人都是程序员时，又会擦出什么样的火花呢？

疫情爆发至今已经有一年了，很多双码农家庭两人都得WFH，没了“距离产生美”还能好好过吗？

码农网友戏称：矛盾、争执嘛…肯定是有的，不过大多数时候都是技术PK。

再高的薪水，也追不上开挂的房价
面对日益上涨的房价，收入高如程序员，也会陷入束手无策。尤其是在“宇宙中心”的湾区，疫情不仅没让房价平息，反而涨势更凶！

已经工作三年的Gary说，在美国，即使是一个单间“小黑屋”也要3000美元/月，很多人只能用1500美元租床位！Google还曾有程序员，为买房住在公司停车场整整两年。

所以，很多程序员更愿意找一个同职业的伴侣，因为可以更快实现买房的目标——两份高薪的工作换一套房子，梦想确实是更近了一步。

加班，再也不用担心惹怒另一半了

加班赶项目、24h oncall… 总让程序员的另一半颇有怨言。而但这个困扰，在双码农家庭几乎是不存在的。

九章一位学员Clark，与妻子就职于不同公司，同为码农，加班也强度不相上下。下班回到家，两人怀抱电脑，默契对视一眼后，各自走向喜欢的小角落，开始码代码。

有时候已经准备关灯休息，又突然接到上头的“紧急命令”就得oncall，这时家属也会体谅，把到嘴的脏话换成一杯咖啡。

约会都在聊工作，键盘礼物最心水
有位在湾区工作双码农家庭的女学员常常和我们吐槽：程序员的工作已经渗透到了她家庭生活的每个角落——和同事聊、和朋友聊、甚至和老公出去约会的时候都在聊！
夫妻俩都身为程序员的优点是共同话题真的很多，有时候甚至能在工作上给予对方帮助。

• “老公，帮我调试下这个程序，好像有Bug？”

• “老婆，那个老是改需求的老板终于走了，哈哈……”

还说学员说，他们夫妻间就连互赠的礼物都是键盘座椅这种实用性更强的物品，虽然浪漫性不够，但这也是双码农生活的一抹色彩。

养猫养狗都可以，只有养娃不可行
在湾区，养宠物的年轻夫妇比比皆是，生儿育女的码农家庭却少之又少。“生活费、教育费、托管费……”种种高昂的养娃费用让人不禁感叹孩子活生生就是一个“吞金兽”啊！

《The Market Watch》对湾区8000多个在科技公司就职的年轻员工进行了调查，其中有近六成左右的人表示会因为成本问题推迟生孩子的时间；而房地产公司Zillow“在房价上涨最快的地区，出生率下降最大”的结论也从侧面论证了年轻人们的观点——不是不想养，是养不起！

相比其他收入较低的家庭来说，也许码农家庭不缺钱，但是时间上的匮乏让他们在生娃养娃的这条路上举步维艰。
所以，任何岗位的夫妻结合，都有说不完的酸甜苦辣。相信那些双码农的家庭，用自己的方式在努力、幸福的生活着。

每个人身边。似乎总有一两个名字奇怪的朋友，像小编就有一个朋友，名字中带了个赪字，相信不少小伙伴不认识这个字吧？这个字念chēng，释义红色，也不知道当时这位朋友的家长是怎么想的，反正小编就知道每次要乘飞机了，这位姐姐肯定是提前到机场去办理人工登机牌，因为登机系统根本打不出她这个赪字，据说当年高考也是去派出所开了证明！

很多小伙伴肯定想着，这种问题应该只会在我大天朝出现吧，像外国人那种abcd的字母名字，总不会碰到打不出的情况吧。

唉~这么想的小伙伴可想错了，外国人因为名字出的问题不仅不少，还比我们这种打不出名字的汉字可严重多了，让小编带你领略下这异国的风景吧。

先是一位美国男子，他在20岁的时候将自己名字改成了Raven Felix Null，乍看上去没什么，等一下，Null，程序猿们是不是明白了什么？

在大多数程序里，Null代表着空值，所以绝大多数的系统都会有强控不允许输入Null，但是因为这个小伙子改了这个名字，导致他的名字几乎无法被任何计算机系统成功识别，例如入住酒店，始终无法成功录入姓名，所以一般碰到这类情况的办事人员都会给他一个白吃白喝的机会。

每当有人让小伙子按规定走一遍繁复流程的时候，小伙子就会拿出国外最流行的那套人权主义，你是在看不起我的名字吗？你是在搞歧视吗，不想惹麻烦的商家一般都选择息事宁人，就这样，小伙子吃了无数的霸王餐、住了无数的免费酒店、买了无数免费商品。

而另一位国外友人就没那么好运了，国外一位名叫Rachel True的演员兼作家，因为她名字中含有了True这个单词，而在一般的程序里面，True是作为布尔变量存在的（true or false），导致一些程序就无法识别了，iCloud不幸也在这个程序清单里。

Rachel True因为名字无法正常使用iCloud，为此她也联系了苹果的官方客服，似乎至今都没能帮她解决这个问题。

试想一下，如果你的名字里包含了rm rf、delete、drop等等一系列单词时，保不准这系统哪天就被你搞趴下了。

可千万别以为外国人不会取怪名字，外国人在名字上真的是叫什么的都有，比如NBA就有一个球员叫gay。

最近，PDD的一系列自杀辞退事件，让996这一个敏感话题再次成为焦点。

身为996的主力大军，程序员这一行当自然是感受颇深。谁没有为了项目投产加班加点，谁没有为了甲方的需求变更披荆斩棘？

不过林子大了总有滥竽充数的南郭先生，大家身边应该有过不少那种看上去每天叫嚣自己很忙但实际没有什么产出的家伙吧。

有没有什么好的办法可以把每个人的工作状态真实展露下呢？百度最近申请了一个专利，据说是为了员工工作状态预测，但真的有这么好心？

通过查询启信宝可以看到，该专利的申请人为百度在线网络技术（北京）有限公司，发明名称为“员工工作状态的预测方法、装置、电子设备以及存储介质”，公开日期为1月12日，公开号为CN112215447A。

据该专利摘要显示，该专利申请公开了一种员工工作状态的预测方法、装置、电子设备以及存储介质，其中方法包括：

获取员工的所属组织信息、职位级别信息和通信信息；在此基础上，提取员工与组织匹配表征向量，生成员工的时序特征，对员工的工作状态进行预测。

听着很玄乎是不是？

其实意思就是基于大数据驱动的定量分析客观提取人-组织匹配的表征及其影响，高效、准确的自动对每个时间段内组织适配性进行抽取，能够实时检测组织适配性并对员工行为动态分析及预测。

再通俗一点，就是监视你的工作行为、内容，至于是否会去和你的岗位职级做比对？再鞭策你敲打你榨干你的每一份时间？呵呵，大家都是成年人，你相信百度会拿这个去监督李彦宏?受众群体肯定还只是最基层的员工。

到底是用来监工还是用来其他目的？仁者见仁智者见智。

一些聪明的网友已经开始对此充满疑问

面对着大家的疑问，百度官方1月13日晚在微博发布声明，称该专利是一个管理上的‘人岗匹配’衡量方法，用于吸引、培养和保留人才，和996没有任何关系。
此时此刻，我只想到一句话男人的嘴、骗人的鬼！

老K独家了解到，张勇近期在阿里内网发布文章表示，他对目前阿里的中台并不满意，他直言道，现在阿里的业务发展太慢，要把中台变薄，变得敏捷和快速。

至此，所有争论尘埃落定：阿里彻底拆中台了。

2015年，张勇推出“大中台、小前台”战略。事隔5年，他亲手拆掉自己搭建的中台，这究竟是怎么回事呢？难道中台战略一开始就是个错误吗？听老K来逐一拆解。

阿里“大中台，小前台”已成行业标配

张勇“all in移动”一战成名，推出的手淘App帮助阿里拿到移动互联网时代的头等舱，奠定了他在阿里的江湖地位。

作为阿里一号位，他又提出了“大中台，小前台”战略。推行5年多之后，中台似乎已经成为行业标配，规模稍微大一点的公司都建设了自己的中台。

当初张勇提出中台战略是想打造：统一技术架构、产品支撑体系、数据共享平台、安全体系等等。把整个组织“横”过来，支撑上面多种多样的业务形态。

不可否认阿里的中台，在近5年的发展过程中，有力地支撑了业务的发展。在如此快速的发展之下，每年的双11，从感觉上来说，系统是越来越稳定。中台战略的成效是有目共睹的。

中台解决不了什么问题？

在“大中台，小前台”战略之后，阿里又提出了“五新战略”，即：新零售、新制造、新金融、新技术、新能源。

以阿里现在的体量，它的战略已经不是停留在“小修小补”的阶段，它要解决的是企业持续增长的问题、第二曲线的问题，所以它要做的是颠覆性创新。

先说结果，阿里“新制造”的代表是犀牛智造，CEO 伍学刚曾表示，要做阿里的服饰新制造平台，张勇给犀牛智造的建议就是，设立独立编制，要有自己的业务、技术、开发、产品，类似于一个独立的公司。尽管阿里有很强的中台，有很多现成的基础资源，但对于还处在起步阶段的业务，去找中台要资源，“效率不够高”。

无独有偶，淘宝特价版，这个被外界看做阿里“打”拼多多的重要项目，也是完全独立的编制，从产品、技术、运营一竿子插到底。其根本原因，就是为了追求创新的深度和创新的速度。

难道说，中台战略不能很好的支持企业创新？

中台的基因之痛

中台并不是不支持创新，正相反，阿里中台孵化出“盒马鲜生”这样的现象级产品，如果没有中台，不可能半年打造出一整套线上线下新零售系统。

准确的说，中台适合做“组合式创新”，没法做“颠覆式创新”。

为什么这么说呢？因为，组合式创新，是把现有几个能力进行组合，形成新的能力，它强调能力的标准化，这个恰恰是中台所擅长的。以“盒马鲜生”为例，它复用了中台的商品、库存、用户、支付、AI、安全等多个服务能力，经过重新组合，形成了“零售新物种”。

但是，颠覆式创新，是从根上做创新，它要打烂前台、中台、后台，颠覆现有模式和能力。比如智能制造颠覆传统制造、智能手机颠覆传统手机，你没法在现有生产线上去创造，只有打破原有模式。所以，**中台不支持颠覆式创新，**这是中台的基因所决定的。

阿里的一位中台架构师向老K透露，“现在是要求我们把最抽象的部分留在中台，这样中台就剩下很薄的一层，通过这几年沉淀下来的通用能力来提高效率，可以大大减少人力，释放出来的人去前台做个性化的改造。”

不是中台不行，是场景变了

有人说中台不行了，连阿里都要放弃它了，其实不然。不是中台不行，而是场景变了，中台在提升组织效率、进行组合式创新等方面还是非常优秀的。许多大型企业面临的也是这方面的问题，所以中台依然适用。但是BAT、TMD们更多面临的是颠覆式创新、释放组织创造力等深层次的问题。

从阿里中台的演进来看，中台将越来越薄，是中台发展的一个必然趋势。跟老K在半年前发表的“中台碎片化”理念是不谋而合的，中台会越来越碎、越来越轻。

那么企业老板们，是不是也要跟风把中台变薄呢？

跟！想死你就跟。阿里中台战略在被提出之前，已经做了7、8年服务化。中台战略提出后，又做了5年的组织、技术、业务层面的变革。可见，阿里是有着非常深厚的底蕴和积累的，在国内恐怕找不出第二家这样的企业。

别人有几十年修行的道行，才敢纵身一跃，你这初出茅庐的小屁孩跟着跳，不摔死才怪。

最后，奉劝各位企业老板，企业数字化转型不要盲目跟风，也不能一蹴而就。还是要坚持一点长期主义，步子大了不仅会扯到蛋，很可能会送命。

参考：《阿里电商的关键人物和组织设计》， 晚点LatePost

来源于公众号“程序猿DD”

每个科技大厂的开源项目，几乎都是各领域开发者最重要的研究学习对象。

由于这些开源代码被广泛的阅读，不少源码中的纰漏也就容易被细心的开发者们揭露出来，比如：2018年华为云开源的Service Comb被发现抄袭Go Micro，遭到了网友们强烈的谴责，官方也出来致了歉。不知道是不是这个原因，后来这个Apache顶级项目也越来越没有了声音。

开源行为本身是个好事情，但如果没有做到位，可能也会给自己的品牌减分。这也是为什么很多谨慎的大厂在开源前期一定是会做非常细致的审核工作，才开始真正的开源，不然一些小揪揪在光大细心网友的探索下，总是会掀起一番波澜。

这不，近日一位名为LOLgrep的 Twitter 用户发文，申称在苹果的开源代码中发现了一个文件，这个文件的神奇之处在于是用来兼容腾讯微信的文件，而更有趣的地方在于他的注释，引起了网络上的一番热议。

这个文件名为make_tapi_happy.h，开发过类似api的程序员一定知道，TAPI 是腾讯官方 API 的名称简写。而这个文件的目录地址是在libmalloc下，libmalloc是苹果采用的堆管理结构目录。

从图中我们可以清晰地看到注释语句：

/* WeChat references this, only god knows why.  This symbol does nothing. */
  extern int stack_logging_enable_logging;

only god knows why，如果这句注释是中文的话，多半就是鬼知道这个变量干嘛的，一点屁用都没，从中我们可以看到这名编程的苹果程序员的吐槽之情溢于言表。

他完全不知道这个 stack_logging_enable_logging 变量到底有啥用，只能通过注释来抒发自己的情绪。

让我们再回到3年多前的2017年，当时苹果和微信差点对薄公堂，就因为微信当时包含一个打赏功能，相信不少小朋友都用过。而在苹果的服务条款里，所有苹果ios平台的App 的打赏功能模块都必须走苹果的 IAP 通道，而苹果作为平台方要从中抽取大约 30% 的分成。

而腾讯的说法是自己没有从该功能获利，打赏的金额是直接交给内容创作者的用户，打赏功能只是为了提高用户活跃度，所以不应该被抽取分成。

双方各持己见，多次协商无果，无奈之下，微信先退了一步，关闭了赞赏功能。但是到了2018年，经过腾讯的努力，终于与苹果达成共识，恢复了该功能，而这个make_tapi_happy.h文件的创建日期恰巧就是2018年。

或许当时的苹果就准备开始在其底层开源代码里开发兼容微信的代码。毕竟生意场上没有永远的对手，只有永远的利益。强强联手，才是最佳的答案。但可怜那个一脸懵逼的程序员，只能最终留下了这句only god knows why的吐槽注释。

Adobe Flash Player，但凡用过电脑的同学应该都知道这个名字。

曾几何时，作为装机必备软件清单中的一员，这款基于浏览器的、用于在互联网上显示富媒体内容的插件几乎无处不在。

但是就像再厉害的英雄总有迟暮的时候，Adobe Flash Player就像一个个垂垂老矣的君王，一步一步逐渐走向了生命的尽头。

近日，Adobe公司正式发布了除中国大陆以外的地区的最后一个版本的更新（Adobe将在2020年后继续与重橙网络合作并支持其在中国大陆地区对Flash Player的独家发行与维护！）。

在这次更新中，Adobe公司首先对过去20多年来众多使用该技术并利用该技术创建内容的用户和开发人员表达了感谢，并表示Adobe公司将在今年也就是2020 年 12 月 31 日之后，不再支持 Flash Player，同时从 2021 年 1 月 12 日开始，Adobe公司将阻止 Flash 内容在 Flash Player 中运行！

早在去年，就有数据显示flash在Web端的使用率已经从80%锐减到17%。其实也在去年，Adobe公司就已经宣布过将在2020年彻底停止Flash更新。

虽然知道总有这一天的到来，但是真的到了要说再见的这一时刻，心中总有万分不舍。脑海中浮现了很多曾经给自己和朋友带来欢乐的Flash作品，印象最深刻的是一款叫做蚂蚁抢蛋糕的游戏，要用各种防御塔守护住蛋糕不被蚂蚁抢走。

很可惜的是，刚想在网上重温下这个游戏，却发现很多浏览器都已经不支持flash插件。

也许，Flash就像那些曾经在身边的人一样，笑过哭过，终究变成了一个回忆。

当年玩蚂蚁抢蛋糕的时候其实发现过，越打到后来游戏速度会越慢，现在想想应该就是后面计算越来越复杂，越来越占用cpu所致。这点恰巧就是Flash的致命伤，太消耗CPU资源，更何况，由于技术的原因Flash Player的漏洞过多，很容易引起安全隐患，随着HTML5、WebGL 及 WebAssembly 等技术标准的日渐成熟，Flash 早已经走上被各大厂商淘汰的命运。

YouTube 早在 2015 年就官方正式宣布退出了 Flash，选择了 HTML5。

Adobe 公司也强烈建议所有用户立即卸载 Flash Player 以帮助保护自己的系统。

为了方便用户卸载，他们甚至在通告页面提供了有关如何卸载 Flash Player 的详细信息。

我们再看下，仅今年，就有苹果 Safari 、Linux Lite 5.2 RC1 、LibreOffice 7都已经宣布移除对 Flash 的支持，而Firefox 、Chrome等 也计划在年底或明年初彻底放弃Flash 。

Flash 就像一个时代的巨人，在当初网络不发达的年代，是众人仰望依赖的对象，但大戏总有落幕时，一家家公司的声明，虽能接受，但总让人想起那句树倒猢狲散。

在网上还能看到这样一个16年的提问，回答者对未来的预测相当准确。

不知道当时提问的这位同学最终有没有去学Flash，无论如何，Flash就是我们这代人记忆中的一缕阳光，他让我们了解什么是动画效果，会一直给我们带来美好的回忆。

我们常说，新年新气象！这不，刚开年，各大厂商就忙着发布自己的最新产品。

之前Spring Boot发布了最新的2.4.3版本。

除了Spring Boot，OpenAPI也在近日正式发布了其最新的3.1.0版本规范。

OpenAPI 规范是用于描述 API 的行业标准，它允许开发人员和计算机在不需要访问源代码、文档或网络流量的情况下理解 API 的功能。

本次更新是在3.1.0-rc1版本的基础上进行进一步突破性的优化，让我们一起来看看吧。

新增内容

• 添加了jsonSchemaDialect顶级字段，以允许为模式对象定义默认的$schema值。

更新内容

• 更新了一些链接到更准确的位置。

• 将JSON模式支持更新为最新的2020-12草案。

• 修改了uri和url下的相对引用解析。

• 修改了文件上传描述，以考虑新的JSON模式功能。这包含了一些突破性的变化。

• 规范扩展的x-oai和x-oas前缀现在都保留由OpenAPI进行定义。

一些解释内容

• 路径参数值不能包含未转义的字符/，？或#。

• 进一步解释应该在何处使用引用对象和JSON模式的引用。

• 统一当值为URLs/URIs时的用法。

• 重写路径项的$ref以考虑引用和组件更改。

• 修正了一些例子。

• 微小的文本更改，以提高一致性和可读性。

• 更新引用对象的描述用来进一步阐明其行为意义。

• 进一步更新了Schema对象的描述，以考虑最新的draft和默认使用spec.openapi.org/oas/3.1/dialect/base作为OAS方言。

• 将“Schema Vocabularies”改为“Schema dialects”。

来源于公众号“程序猿DD”

JetBrains正在开发一种被称为Qodana的代码质量检测工具。它将JetBrains IDE具有的智能代码检查带入了项目CI/CD管道中。它可以识别代码中的错误，安全漏洞，重复项和缺陷并提出修复建议。使开发人员轻松地改善代码结构，使代码符合众多准则和标准，解决潜在的性能问题。

该工具可以看作 JetBrains 版本的 SonarQube。

服务形态

目前Qodana还处于早期开发版本，不过已经提供了早期预览版本。最终Qodana将提供多种服务形态：

• 任何CI工具的Docker镜像

• GitHub Actions

• 独立的Qodana App

• TeamCity 插件

• 云服务

支持语言

Qodana目前仅支持PHP，Java和Kotlin项目，并将最终支持JetBrains IDE家族下的语言和技术。

Qodana 试用

首先，从 Docker Hub 拉镜像（最新版本）：docker pull jetbrains/qodana

运行一个临时 Docker 容器对本地的代码进行分析：docker run –rm -it -v <source-directory>/:/data/project/ -p 8080:8080 jetbrains/qodana –show-report

这里source-directory应该指向你的项目的根目录。

例如对本地的c:\Users\felord\IdeaProjects\payment-spring-boot进行扫描：

docker run –rm -it -v c:\Users\felord\IdeaProjects\payment-spring-boot:/data/project/ -p 8080:8080 jetbrains/qodana –show-report

扫描完毕后会生成检查报告，你可以在浏览器中打开http://localhost:8080查看报告。

跟JetBrains家的 IDE 一样使用起来非常简单，有兴趣可以去看一看。目前该项目已经在 GitHub 上提供了用户指南，公众号回复qodana可获取指南，英文好的可以研究一番。我是：码农小胖哥，关注我获取最新的编程资讯。

苹果要搞车，今日被马斯克侧面证实了。

在造车计划、首款新车明年9月发布、还有突破性电池技术等一系列消息之下，苹果这两天成为科技和汽车领域头版头条。

但更劲爆的是，马斯克“火上浇油”，亲自给这一热点曝了新猛料：

在Model 3项目最“至暗时刻”，我曾找库克讨论苹果收购特斯拉的可能性，作价是如今市值的十分之一（约600亿美元）。

但万万没想到，库克连见面的机会都不给一个。

所以马斯克此时自曝这段往事，是就事论事？是嘚瑟？还是想表明苹果一直对造车有动作？

江湖恩怨，我们先从马斯克没展开的这段往事说起。

马斯克说的是啥时候的事儿？

2017~2019年间。

那时候正处于Model 3产能爬坡、交付跟不上，特斯拉资金枯竭的“至暗时刻”。

特别是2018年开始，在成立15年，向市场投放4款车之后，特斯拉还是没能理顺供应链，公司经营也持续亏损。

走量的Model 3车型，此时周产量不足3000，毛利率也为负。

有外媒为特斯拉算了一笔账：每分钟烧掉6700美元。

更难的是，整整一年之后，特斯拉依然没能翻身。

产能问题，还让公司经营问题在2019年统统曝光。

年初开始，特斯拉裁员7%，被寄予厚望的Model 3交付依然没解决，而如果股价继续走低、公司又无法扭亏，现金流可能就会断掉。

2019年3月，美国价值投资人俱乐部VIC，发表了做空报告。

报告中从产品需求减弱、产品安全性能差、资金缺口巨大、马斯克或被免职等多个角度着手进行分析得出结论：这是做空特斯拉的绝佳时机。

该季度财报电话会议上，向来强硬的马斯克甚至开始服软，表示不抵触融资稀释，甚至出于公司发展，卖保险也可以考虑其中。

与此同时，马斯克也在带队“勒紧裤腰带过日子”，抛出了新的成本削减计划，要审查团队的每一笔支出，包括“零部件、工资、差旅费和租金”等等。

但市场并不买账，特斯拉的估价跌破了200美元。

当时有很多分析师，特斯拉已经走在破产边缘，而最大的潜在买家，就是苹果。

这也是马斯克的至暗时刻。

一系列糟心的难关，让他信口开河“私有化”，最终被美国证监会调查，董事长头衔被“吊销”，曾经跟乔布斯相提并论的硅谷钢铁侠，被质疑为“美国贾跃亭”。

崩溃悬崖边上，硅谷钢铁侠接受《纽约时报》采访时脆弱自述：“整日整夜，没有孩子，没有朋友，除了工作，一无所有”。

后来，逆风翻盘的关键，源自中国，源自上海。

2019年1月，特斯拉上海工厂奠基。5个月后，工厂光速建成。

2019年10月，设计年产能50-100万辆的上海超级工厂投产，而且，生产成本比美国低65%。

特斯拉困局，自此开始转折。

有中国压阵的Model 3基本盘，特斯拉整体昂扬向上，市场和资本又开始热捧特斯拉。

2019年四季度，特斯拉在中国销量开始反超北美，特斯拉也实现首次盈利。

2020年1月，马斯克亲自来上海参加国产Model 3交付仪式，在现场激动的说出：

没有中国的支持就没有特斯拉的今天。

甚至还激动的跳舞助兴：

而且随之特斯拉“中国产”，价格门槛也在一降再降，Model 3成为最畅销的电动车车型。

马斯克在中国实现翻身，特斯拉股价开启疯狂模式。

至于今日，特斯拉股价站上640美元大关，市值超过6000亿美元，风头无两。

这才有马斯克“闲坐说玄宗”。

马斯克为啥此时自曝往事？

但是，如果你以为马斯克这是“欢迎友商”入局，壮大电动车、智能车阵营，那就大大错了。

因为众所周知，马斯克可不喜欢苹果。至少作为特斯拉掌舵者，他不喜欢。

早在5年前，苹果开始大肆挖角特斯拉人才，马斯克还不看僧面地对媒体嘲讽说：

苹果只能招我们不要的人，我们把苹果戏称为’特斯拉坟墓’(Tesla Graveyard)。如果你在特斯拉干不下去，那就去苹果吧。我可不是在开玩笑。

后来提到苹果，也鲜有好话，更别提苹果造车，就会跟特斯拉成为直接竞争对手。

所以结合这一系列背景，大概也能管窥马斯克的自曝心态：

当年我钢铁侠山穷水尽，不得不向不喜欢的苹果低头求收购……你库克竟然看都没看一眼。

现在好了，特斯拉市值可已是求收购时作价的10倍了。

嗯，有嘚瑟的成分，也有“曾经对我爱答不理，今天你高攀不起”的心态。

而且苹果造车消息热头之上，此时不“吐槽”，又更待何时？

苹果的造车进展，确实快得出乎预料。

就在最近，路透在内的多家权威外媒曝光：

苹果Apple Car将可能在2021年第三季度推出，并计划在2024年量产。

而且目前中国台湾地区的供应商，正在全力为“苹果汽车”零部件备货。

此外还有消息称，苹果已经在加州的道路上秘密测试了数十辆原型车。

虽然具体样式和供应链合作方，还没有准确消息……

但“苹果要造车”，并不是一个秘密。

早在2013年，苹果进军汽车领域便埋下伏笔，当时推出了“iOS in the car”计划，期望将iOS 7全面整合到各大主流汽车厂商的车载系统之中。

而就在次年，也就是2014年，一个名叫“泰坦项目”（Project Titan）的计划逐渐浮出了水面。

据说“泰坦计划”的最初目标，是像设计iPhone和iMac一样，从零开始打造一款颠覆行业的产品。

为此苹果迅速招兵买马，还在位于库比蒂诺苹果公司总部附近建立了一座汽车实验室。

到了2015年，仅1年时间里，该团队就扩张到了数千人规模。

其中不乏特斯拉、克莱斯勒汽车、大众集团等车企中的优秀人才，包括特斯拉前副总裁Chris Porritt。

然而浩荡声势之下，其后苹果却又被曝出一系列不顺进展。

2016年，泰坦项目的推进工作出现了极大的分歧：

由苹果前汽车项目负责人Steve Zadesky领导的团队，希望开发的是半自动驾驶功能的汽车；而Jonathan Ive领导的团队，则希望打造一个全自动驾驶平台。

换句话说，一个要造整车，一个看重软件平台。两大“领导”意见不合，自然搞不下去。

随后，苹果给出解决方案——返聘当时已经退休的前高管Bob Mansfield，并由他来接管“泰坦项目”。

Bob Mansfield上位，更倾向于“开发软件和支持解决方案”，于是有新消息称：整车研发计划已经被砍。

而且其后一系列苹果汽车方向的举动来看，确实也更加面向软件和技术，比如自动驾驶。

硅谷路上也开始出现苹果的自动驾驶测试车。

此外，就是不停的人才和团队收购进展。

2018年8月，苹果重新把特斯拉大神（此前在苹果工作5年）的Doug Field，带回苹果。

2019年7月，苹果收购吴恩达旗下的自动驾驶创业公司Drive.ai，而且相关文件显示，看重的就是团队。

再后来，苹果还有一系列新专利曝光，从车载到自动驾驶，几乎涉及了智能汽车的方方面面。

并且由于项目负责人再动变动——The Verge最新消息，目前掌舵苹果汽车项目的是“Siri负责人”John Giannandrea。

所以还有过江湖传闻，苹果的软硬件一体汽车，很可能会率先以一个车载AI交互系统亮相。

谁知话音未落，苹果就被曝出了突破性电池技术进展，并且整个项目可以大大提速。

而且虽然苹果从未制造过汽车，特斯拉花了17年才搞定供应链。

但这一突破性进展之后，外界对于苹果造车——即便连影子都还没有，看好也多于看衰。

“虽然汽车不是手机，但如果这个星球上有一家公司有能力实现，最大的可能就是苹果。”

影响：苹果股大涨，特斯拉遇跌

苹果可以在短期内推进电动汽车的消息曝出后，股价大涨，涨幅2.85%。

一夜之间就涨出一个通用汽车。

同时，潜在的苹果汽车供应链上下游公司，也一同受益。

外媒总结：Lumentum（激光芯片）大涨9%，思佳讯（通信）涨超2%，Qorvo（雷达和通信设备）涨1.8%，Jabil（通信设备）涨超1%。

电动汽车芯片制造商Cree也涨超2%。

而激光雷达传感器系统制造商Velodyne Lidar的股价上涨了11%左右。此前苹果测试车辆，使用的就是他们家的激光雷达。

另一家主打性价比可量产激光雷达的制造商Luminar Technologies，股价也上涨了8%。

只是大象入场，有人欢喜，也就有人愁。

对于其它汽车厂商来说，苹果突然加速造车计划，也造成不小冲击波。

最新的美股交易日中，特斯拉跌1.46%，盘中一度跌超5%。

而中国的新势力们也纷纷下跌。

理想汽车跌超6%，小鹏汽车跌超5%，蔚来汽车跌超4%。

华尔街的分析师们，现如今都开启了果粉模式。

Evercore分析师表示：“电池成本是电动汽车大规模普及的主要障碍之一，如果苹果实现了电池技术上的突破，那么这可能成为最终推进生产的动力。”

摩根士丹利分析师在一份报告中表示：“从特斯拉的角度来看，我们一直认为，像苹果这样的科技企业要比传统OEM厂商拥有更强大的竞争力。”

当然，精明如马斯克，自然也不是不知道苹果造车加速带来的影响。

除了自曝被库克无视的往事。

马斯克还明确质疑苹果所谓的“电池突破性进展”：

如果这是真的，就很奇怪。

特斯拉已经在上海工厂的生产中，采用了磷酸铁锂电池。单体电池在化学上是不可能的，最大电压放大100倍都低，除非将它们粘合在一起。

不过，马斯克的质疑也没有引起更大的讨论。

或许是因为太专业插不上话，或许是一切还早。

而对于更多的果粉朋友而言，更关注的话题只有一个：

苹果电动车，送不送充电器？

按照爆料，9月一切就能见分晓~

来源于公众号“程序猿DD”

作为知名的流媒体巨头，Netflix 在全球拥有近 2 亿订阅用户，服务遍及多个国家。本文阐述了 Netflix 的系统监控实践：自研 Telltale，成功运行并监控着 Netflix 100 多个生产应用程序的运行状况。

1 难忘的经历

相信很多运维人都有过这样的经历：

监控系统某个指标超过阈值，触发告警。大半夜里，你被紧急召唤。半睁着眼，你满脸疑惑：“系统真出问题了吗，还是仅仅需要调整下告警？上一次有人调整我们的告警阈值是在什么时候？有没有可能是上游或者下游的服务出现了问题？”

鉴于这是一次非常重要的应用告警，因此你不得不从床上爬起来，迅速打开电脑，然后浏览监控仪表盘来追踪问题源头。忙了半天，你还没确认这个告警是来自于系统的问题，但也意识到，从海量数据中寻找线索时，时间正在流逝。你必须尽快定位告警的原因，并祈祷系统稳定运行。

对我们的用户来讲，稳健的 Netflix 服务至关重要。当你坐下来看《养虎为患》时，你肯定希望它能顺利播放。

多年来，我们从经常在深夜被召唤的工程师那里了解到应用程序监控的痛点：

• 过多的告警

• 太多滚动浏览的仪表盘

• 太多的配置

• 过多的维护

2 Telltale

我们的流媒体团队需要一个全新的监控系统，可以让团队成员快速地诊断和修复问题；因为在系统告警的紧急情况下，每一秒都至关重要！我们的 Node 团队 需要一个仅需一小撮人就能运维大型集群的系统。

因此，我们构建了 Telltale。

Telltale 监控时间轴

Telltale 的特性

• 1、汇集监控数据源，创建整体监控视图

Telltale 汇集了各种监控数据源，从而能创建关于应用程序运行状况的整体监控视图。

• 2、多维度判断应用程序的健康状况

Telltale 可以通过多个维度判断一个应用程序的健康情况，而无需根据单一指标频繁调整告警阈值。

• 3、及时告警

因为我们知道应用程序在什么情况下是正常的，所以能在应用程序有异常趋势时及时通知应用程序的所有者。

• 4、显示关键数据

指标是了解应用程序运行状态的关键。但很多时候，你拥有太多的指标、太多的图表以及太多的监控仪表盘。而 Telltale 仅显示应用程序中有用的相关数据及其上游和下游服务的数据。

• 5、用颜色区分问题的严重程度

我们使用不同的颜色来表示问题的严重程度（除选择颜色之外，还可以让 Telltale 显示不同的数字），以便运维人员一眼就能判断出应用程序的运行状况。

• 6、高亮提示

我们还会对一些监控事件进行高亮提示，比如局部区域的网络流量疏散及就近的 服务部署，这些信息对于全面了解服务的健康情况至关重要，尤其是在真正发生系统故障的情况下。

这就是我们的 Telltale 监控。它现已成功运行并提供监控服务，监控着 Netflix 100 多个生产应用程序的运行状况。

3 应用程序健康评估模型

微服务并非是孤立存在和运行的。它需要特定的依赖，与其他服务进行数据交互，甚至位于不同的AWS区域。

上面的调用图是一个相对简单的图，其中涉及许多服务，实际的调用链可能会更深更复杂。一个应用程序是系统生态的一部分，它的运行状态可能会受到相关属性变化的微弱影响，也有可能会受到区域范围内某些事件的影响从而发生根本性改变。canary的启动可能会对应用程序产生一定影响。在一定程度上，上游或下游服务的部署同样也可以带来一定的影响。

Telltale 通过使用多个维度的数据源构建一个不断自我优化的模型来监控应用程序的健康度：

• Atlas 时序指标

• 区域网络流量疏散

• Mantis 实时流数据

• 基础架构变更事件

• Canary 部署及使用

• 上、下游服务的运行状况

• 表征 QoE 的相关指标

• 告警平台发出的报警

不同的数据源对应用程序健康度的影响权重不同。例如，与错误率增加相比，响应时间的增加对应用程序的影响要小很多；错误代码有很多，但是某些特定的错误代码的影响要比其他错误代码的影响大。

在服务下游部署 canary 可能不如在上游部署带来的效果明显

区域网络流量转移意味着某个区域的网络流量降为零而另一个区域的网络流量会加倍。你可以感受下不同的指标对于监控的影响。监控指标的具体含义决定了我们应该如何科学有效地使用它来进行监控。

在构建应用程序健康状况视图时，Telltale 考虑了所有这些因素。

应用程序健康评估模型是 Telltale 的核心。

4 智能监控

每个服务运维人员都知道告警阈值调整的难度。将阈值设置得太低，你会收到大量虚假告警。如果过度补偿并放宽告警阈值，就会错过重要的异常警告。这样导致的最终结果是对告警缺乏信任。Telltale 可以帮助你免除不断调整相关配置的繁琐工作。

通过提供准确的和严格管理的数据源，我们能让应用程序所有者的设置和配置过程变得更加容易。这些数据源通过按照一定的组合应用到程序的配置中，以实现最常见的服务类型配置。

Telltale 可以自动追踪服务之间的依赖关系，以构建应用程序健康评估模型中的拓扑。通过数据源管理以及拓扑监测，在不用付出很大的努力情况下就能使配置保持最新状态。那些需要手动实践的一些场景仍然支持手动配置和调整。

没有任何一个独立的算法可以适用我们所有的监控场景。因此，我们采用了混合算法，包括统计算法、基于规则的算法和机器学习算法。

不久后，我们将在 Netflix Tech Blog 上发表一篇针对我们监控算法的文章。

Telltale 还具有分析器，可用于趋势探测或内存泄漏监测。智能监控意味着我们的用户可以信赖我们的监控结果。这表明故障发生时，用户能更快地定位和解决系统异常问题。

5 智能告警

智能监控必然会促进智能告警。当 Telltale 检测到应用程序中的运行异常时，就会产生异常事件。团队可以选择通过 Slack、电子邮件或 PagerDuty（均由我们的内部告警系统提供支持）进行告警。

如果该异常问题是由上游或下游系统引起的，则 Telltale 的上下文感知路由会提醒服务对应的维护团队。智能告警还意味着运维团队针对特定异常只会收到一个通知，也就是说，告警风暴已经成为过去式。

Slack 中的 Telltale 通知示例

在系统出现问题时，掌握准确的信息至关重要。我们的 Slack 告警程序还会启动一个包含有关事件上下文信息的线程，提供 Telltale 识别到的异常问题信息及问题产生的原因。正确的上下文可以方便我们了解应用程序的当前状态，以便值班运维的工程师能有针对性的定位和修复问题。

异常告警事件会不断发展而且拥有自己的生命周期，因此及时更新事件状态至关重要。告警异常是好转了还是恶化了？是否要考虑新的监控信息或事件？Telltale 在当前事件发生改变时会更新 Slack 线程。系统返回正常状态后，该线程将被标记为“已解决”，因此用户一眼就能知道哪些异常事件正在处理中，哪些异常事件已成功修复。

这些 Slack 线程不仅仅适用于 Telltale。团队还可以用它们来共享有关事件的其他数据，方便进一步观察、理论分析和讨论。异常信息数据和讨论全部集中在一个线程中，方便达成针对当前异常的共识，有利于更快提出问题的解决方案以及异常事件的事后分析。

我们致力于提高 Telltale 告警的质量。一种方法是向我们的用户学习。因此，我们在 Slack 消息中提供了反馈按钮。用户可以告诉我们以后某些情况不需要再发生告警，或提供某些告警不合理的原因。智能告警意味着用户可以信赖我们的告警。

在 Slack 的 Telltale 通知中描述异常详细信息的一个示例

为什么我的应用服务运行状态欠佳？

各种类型的监控数据、应用程序相关知识以及跨多种服务数据的相关性，有助于 Telltale 检测分析应用程序运行健康度降低的原因。这些原因包括实例异常、相关依赖的监测和部署异常、数据库异常或者网络流量高峰等。突出高亮显示这些可能的原因可以帮助运维人员节省大量宝贵的时间。

6 异常事件管理

Telltale 异常事件摘要的一个示例

当 Telltale 发送告警时，它还会创建一个快照，其中引用了不正常的监控信号数据。随着新监控信息的到来，会将其添加到此快照中。这简化了团队的很多事后审查流程。当需要复查过去的异常问题时，“应用程序事件摘要”功能可以从各个方面显示当前的问题，包括一些关键指标，比如总停机时间和 MTTR（平均解决时间）。我们希望帮助我们的团队了解更多的异常事件的模式，以便提高我们服务的整体可用性。

集群视图下将相似异常事件分组

7 部署监控

可以看出，Telltale 的应用程序健康评估模型及其智能监控功能非常强大，所以我们也会将其应用于安全部署方面。我们从开放源码交付平台 Spinnaker 开始测试。

随着 Spinnaker 逐渐推出新版本，我们使用 Telltale 连续监监控运行新版本实例的运行状态。持续监控意味着新部署在问题出现时能自行停止并进行回滚操作。这意味着部署存在问题时的影响半径较小，持续时间更短。

8 持续优化

在复杂的系统中，运行微服务非常具有挑战性。Telltale 的智能监控和告警功能可以帮助我们运维人员提高系统可用性、降低运维人员的劳动强度并减少工作人员大半夜被叫醒的频率。

我们为 Telltale 做到的这些功能提升感到高兴。但是远没有结束，我们仍在不断探索新算法，以提高告警的准确性。我们将在以后的 Netflix Tech Blog 文章中详细介绍我们的工作进展。

我们仍然在对应用程序健康评估模型进行进一步评估和改进。我们相信服务运行日志和跟踪数据中会包含更多有价值的信息，这样我们就能采集到更有用的指标数据。我们很期待与平台其他团队进行合作，共同开发这些新功能。将新应用监控引入 Telltale 可以享受到很好的服务体验，但是无法很好的进行扩展，所以我们绝对可以优化和提高自服务的用户界面。我们确信，有更好的启发式方法能帮助用户找出影响服务健康度的一些因素。

Telltale 简化了应用程序的监控。