关于秘密 ,「从0到1」 Peter Thiel

断断续续读完了「从0到1」这本书,距离这本书当初火爆的时间早已经过去,当时没去读,前几天逛书店的时候没找到中意的书,就买来这本学习一下。

从0到1

尼采曾在精神错乱前写道:“个人发生精神错乱很少见,但对群体、正当、国家、时代而言精神错乱却很普遍。” 如果你能识别出那些不切实际的大众观点,你就能看到隐藏在这些观点背后的反主流事实。

这也算是全书最重要的知识点:关于秘密——对于初创公司而言,你需要拥有看出本行业秘密的能力,这个才是初创公司制胜的基石。这让我想到前阵子去听知识产权的讲座,老师特意提到了各国加入WTO时,对知识产权涵盖范围的商定期间:在大家普遍认同的,发明,作品,商标等等之外,美国强势的一定需要加入额外的两项: 一个是集成电路布图设计;另外一个就是商业秘密。虽然第一个集成电路方面的强调在今天看来毫无必要,甚至是有些鸡肋,以至于当今为之申请知识产权保护的公司都少之又少;但是商业秘密的加入却帮助了很多公司,公司与之相关的纠纷不断,证实了当初的明智提议。美国战后迅速崛起,可谓深谙公司成长之道。

对于书中圈点的一些语句,我做了一些摘抄,黑体字为原文。

还有什么有价值的公司没有成立?

“幸福的家庭总是相似的,不幸的家庭各有各的不幸。” 而在商业中,情形恰恰相反。企业成功的原因各有不同:每个垄断企业都是靠解决一个独一无二的问题获得垄断地位;而企业失败的原因却相同:他们都无法逃脱竞争。

一个初创企业完美的目标市场是特定的一小群人。

要尽可能地躲开竞争。

当人们缺少具体的实施计划,他们就会依照惯例,尽量把多种选择组合起来。我们学习大量的无用的东西,没有一个具体的目标的学习,没有计划和明确目的的学习。

计划自己明确的未来,没有计划的进步就叫“演化”。 

从钱的角度:

幂次法则(power law) ,指数方程描述的是最不平均的分配。它完整的定义了我们周围的环境,而我们几乎毫无察觉。

“你应该将全部注意力放在你擅长的事情上,而且在这之前要仔细想一想未来这件事情是否会变得很有价值。”

销售人员在背后要付出很多才能使销售工作看起来容易进行,而这些往往被技术精英忽视。

每个失败者都运用被普遍认可的观点来描述自己的璀璨未来。但是伟大的企业是构筑在秘密之上,这是它们取得成功的独特原因,而别人却对此一无所知。

最好的项目可能是人们忽视的项目,或没有大肆宣扬的项目;最好的问题是无人尝试解决的问题。

这本书切入的角度很棒,阅读的过程我不断觉得,书中的很多知识其实并不仅限于公司方面,对于个人成长也是一样。很多人可以在社会活动中活得轻松自如,也是一样找到了那个秘密,看问题时的站的位置更高;研究问题时钻入的更深:也就是我们期望的具有的:聪明人的特质

而这本书则向我们介绍了 聪明公司的特质

 

uhk 键盘入手体验

历时接近半年,我的 uhk 键盘终于到货了,体验了接近两个星期后,这里写一些上手的感受,如果时间短懒得读,这里说一下摘要: 真好用,快去买吧!

印象中我开始在意电脑键盘这个事情,是从白色塑料壳的 macbook 开始,此笔记本作为 mac 的入门本很不错,但是可惜的是笔记本的掌托边缘不是一体式设计,两块塑料面板的接缝处并非圆滑,用久了总觉得划手腕,尤其是夏天,小臂会被压出痕迹。因此去买了当时一款外接苹果键盘,键盘较长且有小键盘。从如今流行的外接键盘以小为美的风气看,这个键盘携带有些不便,虽然轻薄。薄膜键盘手感一般,用久了,难免有松松垮垮的感觉。

于是接下来就入手了 Daskeyboard 的 Model S Professional for mac。那些年此键盘常年在桌上,虽说也有厌烦的时候,但偶尔切换回笔记本键盘也可以换换手感。当时看中它的几点优势:

Model S Professional for mac front view

  1. 青轴 + Mac 键盘 Layout : 与笔记本的键盘的使用习惯一致
  2. 键冒上的字体 Geek 感十足,
  3. 键盘有钢板,放在桌子上很稳当。

Daskeyboard 在国外程序员圈子中的的口碑还挺不错,虽说国内用的人少,但偶尔有几个识货的同事路过,还是能顺便聊上一会儿。此后的日子也陆续买过几款比较普通的,例如罗技的蓝牙键盘(为了便携打字,连接 iPad用);ikbc 的入门款(为了试试 Cherry 红轴),但都没有用得长久。其中一个主要原因是:我放弃了 Mac 阵营,切换回了PC,重新投入Linux 桌面的怀抱。

自从 MBP 开始使用蝴蝶键盘开始,我对苹果的好感一落千丈,尝试了多次去适应那古怪手感的键盘,都以失败而告终,加之此键盘的故障率极高,自从我们公司统一购买的 MBP 13″,键盘故障此起彼伏,小伙伴们经常有按键失灵的抱怨,而且散热差。终于我也忍受不了,跟公司申请用 X1C 替换掉了 MBP,纯粹因为键盘的原因我放弃了 MacOS,虽说有时候还真挺怀念MacOS下的软件和流畅的界面。但随着这些年 Ubuntu 的易用性逐渐提升, 以及 Chrome 在日常使用中的比例越来越大, OS 的选择的分界线开始变得模糊起来,对我而言。

如果你能适应的了 Ubuntu 或者 Windows,就可以完全不用忍受 MBP 糟糕的体验了。换上了 X1C 和 Ubuntu 的组合后,外接键盘的选择就更宽广了。于是在 2018 年双十一结束后,为了犒劳一下那段时间几乎被压力压傻的自己,决定奢侈一把,入手 UHK。

购买分体式键盘的想法随着手腕酸痛的加剧而愈加强烈,在入手 UHK 之前,我还购买了一款微软的入门键盘 4000 做了尝试:

这键盘分体的感觉还能凑合一下,但是它的手感完全是一种折磨,跟X1C的笔记本键盘都没法比,于是买回来的当天就开始积灰,最后我送给了还在使用更差键盘的同事。接下来就要说说UHK ,它同时满足了我对键盘的种种需求:

  1. 机械键盘,轴可以选择 [√]
  2. 分体式设计,减轻手腕的负担 [√]
  3. 不会有特殊的键盘Layout,例如 HHKB 那种左下角键的缺失,我完全没法用 [√]
  4. 使用习惯可以让我无缝切换到笔记本键盘上,甚至是他人的PC键盘 [√]
  5. 可编程和方便的修改各种参数 [√]
  6. 不要蓝牙键盘 [√]
  7. 能跟轨迹球配合 [√]
  8. 小巧 [√]

参考了市面上的种种,能够同时满足以上需求的只有 UHK ,似乎这键盘唯一的缺点就是需要 ,因为键盘是下单了之后才开始制作,小作坊式的生产模式。卖家完全是键盘的狂热爱好者,他们也终于忍受不了市面上种种傻X一样的键盘,决心众筹一款自己也喜欢用的产品。慢工出细活的前提下,就可以经常在Twitter 上看到各种键盘玩家对UHK 的晒图的同时,都免不了感慨一下:终于到了啊!于是就这样,我在2018年双十一结束,算上帮同事代买的一个无刻青轴,外加我的 Linux 红轴,从他们的官网下单了2个键盘,开始了漫长的等待。这期间很多同事见我面的第一句都是问:到了么?大家都心照不宣的知道是在问什么。甚至还有同事在跟我打赌,他手头的业务上线和我的键盘邮寄到公司,究竟哪一个会更早发生。

截止到目前,这个是我使用最顺畅的键盘,没有之一。完全满足了我对键盘种种预期,只是没有购买他们的木头掌托有些遗憾,以后可以考虑跟着其他配件模块一起购买,然后再开始新一轮等待 😂

用心做 geek 产品的人值得支持。

Prometheus Thanos Design 介绍

Thanos Logo

本文主要内容翻译自 Thanos Design文档

Thanos 以 Prometheus sidecar 的方式运行, 为 Prometheus 提供了全局查询,备份,以及历史数据访问的功能。Thanos 的集群组件有以下3个功能:

一 指标源

Thanos提供了两个组件作为数据来源: Prometheus sidecar 和 rule nodes. 其中 sidecar 部分实现了一个gRPC 服务,是基于 Prometheus 的 HTTP 和 remote-read APIs 的; 而 rule node 部分 直接运行在 Prometheus 存储引擎上。

说说 Prometheus 2.0存储引擎的备份部分: prometheus 拉回来的 metrics 数据以 block 形式存储在本地磁盘, 而一个 block 其实就是一个目录,目录中有3个组成:

  • chunks , 这部分比较大,就是真正的时序 Metrics 存储
  • index, 可以通过 labels 来查询时序 series 数据,靠的就是这个 index文件
  • meta.json , 这个文件存储了本block的 stats, time range, 和 compaction level 这样的信息. 下面有示例

那么 Thanos 是如何进行备份的呢?上面的 meta.json 就是关键, thanos 扩展了这个 json 文件,加入了 Thanos所特有的 metadata 信息。而后上传到块存储上。

二 存储

对于那些存储在远端对象存储的 block 数据, Store Node 充当了网关的功能。实现了跟指标源相同的 gRPC API 接口,来访问对象存储中的指标数据。它会持续不断的更新 bucket 中的 block , 并将对 metrics 的请求翻译为对象存储的请求。为了降低对远端对象存储的访问数量,它采取了一些手段:例如, 通过 metadata (时间区间,lables 之类的) 过滤 block;又或者对于频繁查询的 index,直接cache起来。

Prometheus 2.0 存储层已经对读放大进行了优化。例如,按照时间和指标名字,连续的尽量放在一起。而 store node是感知到存储文件的结构的,因此可以很好的将指标存储的请求翻译为最少的 object storage 请求。对于那种大查询,一次可以拿成百上千个 chunks 数据。

只有 index 数据是放入 cache的,chunk 数据虽然也可以,但是就要大几个数量级了。目前,从对象存储获取 chunk 数据只有很小的延时,因此也没什么动力去将 chunk 数据给 cache起来,毕竟这个对资源的需求很大。

Stores & Data Sources 其实是一回事

因为 data node 和 data source 提供了相同的 gRPC Store API 接口,因此对于 Client 而言可以把他们当成一个东西来对待。 加之,每一种 Store API的实现都对外声明了自己所能提供数据的 meta data,因此 Client 对特定的数据请求,就可以最小化到仅请求必要的 node。

本质上来说, Store API就是通过一组标签匹配器(从PromQL中获得的)和时间范围来查找数据。 它返回在块数据中找到的压缩样本块。 它纯粹是一种数据检索API,不提供复杂的查询执行。

三 查询层 (Query Layer)

查询器是无状态且可以水平可伸缩的实例,它们在Store API 暴露出的接口之上实现了PromQL 这种查询语言。

Compactor 压缩器
压缩器是一个单例进程, 它会将对象存储 Bucket 中的多个小 Block 合并成 大 Block ,它会大大降低对象存储的空间占用,从 Bucket 中获取数据的请求
也会变少。

将来, Compactor 还会承担指标降精度, Retention 等批量任务。

扩展性
Thanos 的所有组件都不包含 Sharding 功能, 真正具有扩展性的组件其实是 Query Node,它是无状态的,可以随意扩展;扩展存储能力依赖外部的对象存储系统。

Store, rule 和 Compactor预期中是运行在一个实例中,或者是HA。就跟 Prometheus 一样, 功能性的 Sharding 其实并不常见。

例如, 规则集( rule sets)可以被分割到多个 规则节点(rule node)上, Store 则可以通过让不同数据中心使用不同 Bucket 。

另外

Prometheus 新版 tsdb 的作者 Fabian Reinartz 设计了 2.0 格式存储 的 tsdb,相较于老版,极大的提升了存储的性能。相信各位从 Prometheus 1.X 版本升级过来的同学一定会对这次升级印象极深(如果你看过磁盘io的数据的话)。这里有篇 slide 介绍: 。同时 Fabian Reinartz 也是 Thanos 的最主要贡献者