内部信息源与外部信息源搜索引擎优化方法的异同(Linux创造者Torvalds与VMware首席开源官谈Linux未来的看法)

　　内部信息源与外部信息源搜索引擎优化方法的异同(Linux创造者Torvalds与VMware首席开源官谈Linux未来的看法)

　　编辑 |小智

　　在 8 月 31 日举行的北美开源峰会上，Linux 创造者 Torvalds 在与 VMware 首席开源官 Dirk Hohndel 的对话中分享了他对 Linux 未来的看法。他说，如果他被公交车撞到，他并不担心内核会受到影响。这种假设虽然不吉利，但却是有道理的。为什么？

　　一、工作流程比代码更重要

　　“我真正担心的是打补丁的过程。工作流程比代码更重要，”Torvalds 说。 “如果你有正确的工作流程，代码会自行解决，如果有错误，我们知道如何处理。”

　　他承认自己并不了解内核中的每一行代码，但这并不是一件坏事。 Torvalds 表示，内核的庞*敏*感*词*导致其复杂性不断增加，而开源模型是内核成功的核心。因为在复杂的世界中，处理复杂性的唯一方法是公开交换想法。您无法在封闭环境中管理复杂性。

　　自 1992 年以来，Linus 开始采用其他开发人员的补丁。今天，Linus 拥有一支优秀的内核维护团队。 Linux系统的辅助模式是由Linus负责整体协调和沟通。他将获得十多项核心贡献，每个人都有自己特定的领域和项目内容。每次有新的开发任务，Linus 都会分配给相应的人；而这十多位核心贡献者，都有着自己知名且值得信赖的大师级小团队。 Linus 只需要知道将任务委派给他自己团队的十几个成员中的哪一个即可。

　　Dirk Hohndel 曾经问过 Linus，这种开发模式是否可持续？ Linus笑着回答说，如果现在的团队里有程序员变老变胖（感觉好像在说他们哈哈），不想继续也没有问题，因为会有新的程序员加入德克又问莱纳斯，在内核的不断改进和迭代过程中，你有绝对的决定权吗？ Linus 回答“不”，他衷心鼓励大家根据自己的需要构建叉子。如果这样的想法最终得到好的结果证明，其本质将被吸收到Linux内核项目中。 Dirk 总结说，目前分支开发和代码重吸的模式其实反映了 Linus 本人或他的团队的果断。

　　不难看出Linus等技术大神对软件开发过程的重视。一个设计良好、运行良好的软件开发过程对于提高软件工程的效率和解决突发问题有很大的帮助。那么如果出现问题该怎么办呢？我们来看看Facebook的体验案例。

　　二、Facebook 是如何开发和部署的？

　　Facebook 是全球最大的社交网络网站。早在2017年，其月活就突破了20亿，是微信的两倍多。为了支持这样一个网站的运营并不断发布新功能，Facebook的工程师们是如何做到这一切的？

　　Facebook 的工程师不会像传统软件行业那样使用瀑布模型进行开发。他们不断开发新功能并快速上线，以便用户访问这些新功能。这是大家经常提到的。部署（持续部署）。在他们看来，Facebook 发展永无止境的那一天，代码库在不断增长，随着时间的推移，代码呈现出超线性增长的趋势。

　　在 Facebook，所有前端工程师都在同一个稳定的分支上工作，这也可以加快开发速度，因为它消除了繁琐的分支合并过程。在日常开发中，大家都使用git在本地进行开发，等代码准备好后，就会推送到SVN上（之所以是SVN，这是历史原因），这样开发就自然而然的把代码中的代码和可以上网的代码。

　　但是，为了保证网站的稳定运行，把代码推送到SVN的并不是工程师，以为可以上线，代码就可以发布上线。 Facebook 采用了一种兼顾速度和稳定性的方法——将每日发布与每周发布相结合。所有代码更改默认每周发布一次，每次发布都会收录比较多的更改。每周日下午，发布工程师将代码推送到SVN，然后进行大量的自动测试，包括很多针对性的正确性和性能回归测试，这个版本将成为内部使用的默认版本由 Facebook 员工发布，正式发布通常安排在周二下午。

　　发布工程师会对每个工程师的历史表现进行打分，内部称为“Push Karma”。比如那些经常出现问题的代码，分数会比较低，他们的代码自然会得到更多的“关心”。这样做的目的是控制发布风险，而不是评判某人，所以这个分数是保密的。此外，变更越大，或者在 Code Review 期间讨论的代码越多，风险就越高，它得到的“关心”也就越多。

　　在发布之前，代码已经通过了开发者的单元测试和代码审查。在 Facebook 中，Code Review 是一件非常重要的事情。他们使用名为 Phabricator 的工具进行 Code Reivew，这是相同的代码版本。管理是集成的。

　　除了大量的自动化测试，当每个员工在内部使用Facebook时，就相当于进行了一次高密度的测试。每个员工都可以报告他发现的问题。写代码的人越来越多，代码增长很快，相对来说，测试代码的人也越来越多。

　　在性能方面，Facebook 使用 Perflab 来比较新旧代码的性能。如果新代码的性能不理想，开发工程师不能及时修复，那么相关代码将从本次发布中删除，问题将得到修复。稍后发布。每一个小的性能问题都不能忽视，因为小问题很快就会积累起来，变成影响容量和性能的大问题。 Perflab 可以以图表的形式直观地展示系统的性能。

　　Facebook 的每周发布是分阶段进行的。第一个是H1，部署到一个只能内部访问的服务器上，进行最后的测试。许多公司也称其为“预发布”；其次是H2，部署在数千台服务器上，对少量用户开放；如果H2阶段没有发现问题，则进入H3并部署到所有服务器。

　　如果在此过程中发现问题，工程师会立即修复，然后重新开始分阶段部署。当然，您也可以选择回滚代码。回滚方法有两种，常见的一种是回滚更改及其依赖文件，另一种是回滚整个二进制包。

　　这种“准连续发布周期”的最大优势在于，它迫使我们开发下一代工具、自动化和流程，以支持公司扩张。

　　发布时，变更相关的开发者必须在线，发布工程师会通过IRC机器人确认。如果此人不在，则他的更改将被回滚。这样可以确保在发布之初就可以快速发现和修复问题。当然，在这么大的系统中，有时很难及时发现一些问题。因此，Facebook 会将内部工具 Claspin 与外部信息源（如 Twitter）相结合，持续监控系统的健康状况。

　　通过 Gatekeeper 系统，工程师可以轻松控制有多少用户可以访问特定的新功能。过滤条件可以是地域也可以是年龄，当出现问题时可以快速关闭某个特征的入口。借助Gatekeeper，工程师可以轻松进行A/B 测试，从而快速采集用户的真实体验并对产品进行调整。不要忘记，在 Facebook，工程师选择他们的工作。然后工程师必须选择做东西，看看用户的反应，而不是和一群人坐在会议室里猜测用户想要什么。什么。

　　现在，Facebook 有数千名开发工程师，但没有独立的测试工程师。每个工程师都可以看到所有的代码，并且可以提交补丁，或者提交问题的详细描述。工程师需要自己编写详细的单元测试，并且他们的代码必须通过所有回归测试并支持后续的各种运维任务。

　　他们除了要对自己的代码负责，还要面对各种巨大的挑战，往往要对多种解决方案进行大量的实验。例如，为了解决 PHP 的性能问题，同时开发了三种不同的解决方案。当一个解决方案的负责人发现另一个解决方案更好时，他们就会停下来；最终HipHop赢了，但另外两个团员的精力没有浪费，他们提供了重要的后备能力。

　　阅读 Facebook 体验后，您有何看法？

　　您能否分享一下您目前公司的软件开发和管理流程？