其他公司优秀的技术博客是怎么写出来的

原文链接：How (some) good corporate engineering blogs are written

我和公司技术博客的人比较了一下博客，有一件事我觉得很奇怪，那就是对于一家估值九到十位数的公司来说，我的个人博客的流量比公司技术博客的流量还要多，多一个数量级是很常见的。

我觉得这很奇怪，因为该类科技公司往往有数百到数千名员工。他们绝大多数都比我更有能力写出一篇引人入胜的博客，而公司从拥有吸引人的博客中获得的价值也比我大得多。

就前者而言，公司的员工会比任何一个拥有个人博客的人做过更有趣的工程，有更多有趣的故事，有更深入的知识。关于后者，我的博客可以帮助我找工作，它可以帮助公司招聘。但我只需要一份工作，所以更多的曝光率，顶多让我得到一份稍微好一点的工作，而除了我工作过的一家科技公司外，其他公司都急于招聘，一直把候选人流失给其他公司。而且，我在面试的时候，并没有真正和其他候选人竞争（即使我们面试的是同一份工作，如果公司喜欢的人不止我们一个，通常也只会多做一些工作）。这个博客上关于求职的高阶位是，这个过程中是否能接受大量的非面试反馈，或者说我会不会因为他们进行传统的面试而导致面试失败，而多发一个帖子的边际价值可能就很低。另一方面，公司在招聘时竞争相对直接，所以相对于另一家公司更有说服力对他们来说是有价值的；复制Cloudflare或Segment在工程 "品牌 "上的玩法将是一个显著的招聘优势。这个玩法并不是什么秘密：这些公司向全世界广播他们的产出，并且通常乐于谈论他们的博客过程。

尽管拥有一个 "好的 "公司工程博客的好处看似显而易见，但大多数公司工程博客都充斥着工程师不想读的东西。模糊的、高层次的废话，说什么都是多么神奇，内容营销，关于新的热点的文章（今天，可能是将深度学习用于不恰当的应用；十年前，可能是将 "大数据 "用于不恰当的应用），等等。

为了试图了解拥有优秀企业工程博客的公司有哪些共同点，我采访了三家拥有引人注目的企业工程博客的不同公司（Cloudflare、Heap和Segment）的人员，以及三家拥有蹩脚的公司技术博客的不同公司（我不打算点名）的人员。

从高层次来看，引人注目的技术博客流程具有以下共性：

• 审批程序简单，不需要很多审批

• 很少或不需要非工程方面的批准

• 隐性或显性的关于审批的快速SLO

• 审批/编辑过程主要是让文章对工程师更有吸引力。

• 直接的、高层次的（联合创始人、C级或VP级）支持，保持博客流程的轻量化

不太吸引人的技术博客流程有以下共同特点：

• 审批过程缓慢

• 需要许多批准

• 需要重大的非工程性批准

  • 非工程审批建议的变化，作者认为令人沮丧

  • 来来回回可以持续几个月

• 审批/编辑过程主要是去掉帖子的风险，删除对具体内容的提及，使文章更模糊，减少工程师的兴趣

• 实际上没有对博客的高级支持

  • 领导层可能会同意博客在抽象上是好的，但在具体行动上却不够重视

  • 改革过程中使博客更容易非常困难；以前的努力已经失败了

  • 为减少间接费用而改变程序，需要所有 "利益相关方 "签字(一个案例中有14个)

    • 任何一个利益相关者都可以阻止

    • 任何一个利益相关方都不能批准

  • 利益攸关方对批准任何减少间接费用的行为持谨慎态度

    • 批准涉及到承担感知到的风险（如果发生了不好的事情怎么办），而对他们没有感知到的利益

在一家拥有吸引人的博客的公司，有一个人指出，只有一个审批人和/或一个主要审批人的缺点是，如果这个人很忙，可能需要几周的时间才能让文章获得批准。这很公平，这就是集中审批的一个缺点。然而，当我们与其他流程进行比较时，在一家公司，人们注意到，通常审批需要3到6个月的时间，而尾部案例可能需要一年的时间。

虽然对于习惯了快速发展的公司的人来说，几周的时间似乎很漫长，但对于那些发展较慢的公司的人来说，如果有一个只需要两倍时间的审批流程，他们会欣喜若狂。

以下是我采访的三家公司的流程，按照我的描述（按照sha512sum的顺序呈现，恰好是按照公司规模的增加排序，从几百名员工到近千名员工）：

Heap

• 有人有一个想法，要写一篇文章

• 作家（是工程师）与 "好友 "配对，由好友编辑，然后批准帖子

  • Buddy是一名工程师，他有合理的写作记录

  • 这可能需要几个回合，可能会改变文章的主旨

• 首席技术官宣读并批准

  • 通常只有轻微的反馈

  • 可以提出 "设计师可以把这个图做得更好 "这样的建议

• 发表文章

第一个编辑阶段是将草稿发到一个slack channel，"每个人 "都会对文章发表评论。这是一种不愉快的经历，因为 "每个人 "都会提出意见，需要进行大量的修改。上面的过程是为了避免得到 "太多 "的反馈。

Segment

• 有人有一个想法，要写一篇文章

  • 常常来自：内部文档、外部谈资、已发项目、开源工具（由Segment构建）

• 撰稿人（工程师）写稿子

  • 可让一名高级工程师与他们一起编写草稿

• 直到最近，还没有人真正拥有反馈过程

  • Calvin French-Owen(联合创始人)和Rick(工程经理)通常会给出大部分的反馈

  • 也许还可以从经理和工程领导那里得到反馈

  • 一般来说，第三稿被认为是完成了

  • 现在，有了一个专职编辑，他拥有编辑文章的权利

• 也可以在工程团队中交流，得到15-20人的反馈

• 公关和法务会看看，轻量级的审批

所做的一些改变包括：

• 在试图建立 "工程品牌 "的时候，把深度技术岗位作为重中之重

• 有一次 "博客静修"，用一周时间写一篇文章

• 增加了写作和演讲，作为绩效考核和职业发展的明确奖励标准

虽然有法律和公关的批准，但Calvin指出："一般来说，我们尽量保持相当轻量级。我认为博客更大的问题是缺乏内容或模糊的、高层次的内容。"

Cloudflare

• 有人有一个想法，要写一篇文章

  • 内部博客是企业文化的一部分，有些文章来自内部博客

• 约翰-格雷厄姆-康明(CTO)每篇文章都会阅读，其他人也会阅读和评论

  • 约翰是文章的核准人

• 马修-普林斯(CEO)也支持博客的发展

• "非常快 "的法律审批程序，SLO为1小时

  • 这个过程太轻巧了，一个人并没有把它当做一个批复，另一个人根本没有提到（第三个人提到了这一步）

  • 一般不涉及通信

需要注意的是，这只适用于技术性博文。产品公告有一个更重的过程，因为它们与销售材料、新闻稿等联系在一起。

有一件事我觉得很有意思，Marek在Cloudflare面试是因为他们的博客（2013年这篇关于他们第四代服务器的博客引起了他的注意），他现在既是他们的关键工程师，也是引人注目的Cloudflare博文的主要来源之一。至此，Cloudflare博客至少又产生了几代因为看到博客而接受采访的人，现在又为博客写出了引人注目的文章。

总结

我的看法是，一个公司技术博客的自然状态，大家能得到一点反馈，就是一个很有意思的博客。真正的、有深度的、技术性的写作很匮乏，使得任何半点像样的、诚实的、关于技术工作的公开写作都很有趣。

为了有一个无聊的博客，企业必须主动阻止工程师把有趣的内容放在那里。不幸的是，大公司的自然状态似乎倾向于规避风险，阻止人们写作，以防引起法律或公关或其他问题。个人投稿者（IC）可能会认为，阻止工程师写低风险的技术文章是很荒谬的，同时，C级主管和副总裁经常公开发表意见，变成公关灾难，但大公司的IC没有权力或者觉得自己没有权力去做一些事情，只是因为它有意义。而需要签字批准简化流程的十四个利益相关者中，没有一个人关心简化流程，因为这样做对公司有好处，但对他们并没有真正的影响，而不是当这意味着似乎要为简化流程会增加的风险负责，无论多小。一个愿意承担风险的执行官或高级副总裁可以对后果负责，如果他们对工程师招聘或士气感兴趣，他们可能会看到这样做的理由。

我经常听到比较官僚化的公司的人说的一句话是 "我们这种规模的公司都是这样的"，但事实并非如此。Cloudflare，一个接近1k员工的60亿美金的公司，它的规模与许多其他博客流程更加繁琐的公司相当。公司技术博客的情况似乎与给予真实面试反馈的情况类似。interviewing.io声称，这样做有很大的好处，很少的坏处。其实有些公司确实会给真实的反馈，而且给真实反馈的公司一般都会发现这样做很容易在招聘中占据优势，而且几乎没有什么弊端，但是绝大多数公司都不会这样做，而且这些公司的人会声称，给反馈是不可能的，因为你会被起诉，或者公司会被 "取消"，尽管这种情况一般不会发生在给反馈的公司身上，甚至整个行业都会有给面试反馈的情况。很容易手舞足蹈地说存在一定的风险，当风险来自于多个机构时，很少有人有权力否认含糊不清的风险。

虽然这只是一个小样本，而且从小样本中概括太多是很危险的，但你需要高层支持才能轰破官僚主义的想法与我在其他领域看到的一致，大多数大公司很难做一些简单的、具有明显但扩散价值的事情。虽然这篇文章恰好是关于博客的，但我听到的故事在各种主题上都是同样的形态。

附录:吸引人的博客文章示例

下面提到了一些博客，并附上了为什么我认为这篇文章很有说服力简短的评论。按照sha512哈希逆序。

Cloudflare

• https://blog.cloudflare.com/how-verizon-and-a-bgp-optimizer-knocked-large-parts-of-the-internet-offline-today/

  • 谈了一个影响很多人的真实技术问题，合理深入

  • 及时，在故障发生8小时后就发布了，当时别人还真的很想知道发生了什么事；大多数公司无法这么快的出一篇吸引人的博客，或者只能在特殊情况下才能做到，Cloudflare能够半定期地发布及时的文章。

• https://blog.cloudflare.com/the-relative-cost-of-bandwidth-around-the-world/

  • 对一些数据的探索

• https://blog.cloudflare.com/the-story-of-one-latency-spike/

  • 一则debug故事

• https://blog.cloudflare.com/when-bloom-filters-dont-bloom/

  • 一个开发数据结构的背景下的调试故事

Segment

• https://segment.com/blog/when-aws-autoscale-doesn-t/

  • 对通用服务中陷阱的具体解释

• https://segment.com/blog/gotchas-from-two-years-of-node/

  • 一个通用工具中陷阱的具体例子和解释

• https://segment.com/blog/automating-our-infrastructure/

  • 关于公司如何运作的具体细节；理论上，任何公司都可以写，但很少有人会写

Heap

• https://heap.io/blog/engineering/basic-performance-analysis-saved-us-millions

  • 谈论真正的问题和解决方案

• https://heap.io/blog/engineering/clocksource-aws-ec2-vdso

  • 谈论真正的问题和解决方案

  • 在HN的评论中，工程师(malisper, kalmar)在技术上的回答都有真实的理由，而不是像你在大多数情况下看到的那样，只是普通的混淆视听

• https://heap.io/blog/analysis/migrating-to-typescript

  • 真实讲述第一次推动全公司技术变革的尝试是如何失败的

需要注意的是，这些博客都有不同的风格。我个人比较喜欢Cloudflare博客的风格，它的 "深挖 "技术文章的比例比较高，但不同的人会喜欢不同的风格。有很多风格都可以用。

感谢Marek Majkowski、Kamal Marhubi、Calvin French-Owen、John Graham-Cunning、Michael Malis、Matthew Prince、Yuri Vishnevsky、Julia Evans、Wesley Aptekar-Cassels、Nathan Reed、Jake Seliger、一位匿名评论员，以及来自我没有点名的公司的消息来源的评论/更正/讨论；致谢中明确提到的人没有一个是不太吸引人的博客的信息来源。