DevOps之于Prezi-InfoQ

抖音技术能力大揭密！钜惠大礼、深度体验，尽在火山引擎增长沙龙，就等你来！立即报名>> 了解详情 



 写点什么

本文是“月度DevOps 战报”系列文章的第二篇。每个月我们聆听DevOps 为不同的组织带来了什么，我们学习哪些有效或无效，并描绘出采用DevOps 过程中所面对的挑战。

从内部学习DevOps

引言

Prezi 中像“微创业”一样运作每个产品团队的哲学是尽量去中心化，意味着每个团队都需要自给自足。要实践这种哲学，唯有使用经典DevOps 方法将软件开发人员和有大规模系统运营经验的工程师们进行混编。Prezi 的管理团队注意到了这一点，因而开始在全公司范围推广DevOps。随着这一行动的展开，员工如何发展实践DevOps 所需的技能组的问题变得特别重要。

长期以来，Prezi 拥有由设计师、QA 工程师、开发人员、用户体验研究员和产品经理组成的跨职能团队。尽管如此，直到最近Prezi 也只不过拥有一支“ DevOps 团队”。目前这支团队依旧负责大部分关键任务服务的可用性，例如核心数据库和 HTTP 负载均衡器等。与以前不同的地方是，各个产品团队假定拥有运行其产品或特性的基础架构的所有权。其中许多团队都没有任何有 DevOps 经验的成员，因此学习 DevOps 的基本知识成为它们的首要任务。

传统上，学习一系列技术栈（注：指与某个主题相关的一系列技术组合）需要参加一些一般由供应商组织的课程，并且往往还会获得一份认证。尽管这条经过实践检验的途径拥有许多便利，它依旧是一个笨重的方法，需要公司和员工个人投入大量的金钱和时间。那些熟悉入门课程中大部分内容却又没有准备好进入下一阶段的人，会感到枯燥或迷茫。最后，很不幸的是，供应商课程往往忽略了“大局”并聚焦于其产品线所解决的问题，而不是针对那些学员所面对的问题。考虑到这些缺点，如果可能的话，工程师们最好从他们的同事那里学习。

幸运的是，在每个团队都转向 DevOps 前，Prezi 早就已经开始尝试不同的方法在内部分享信息。所以当我们真正需要在公司内部分享我们拥有的知识的时候，我们已经有了有效的方法。这篇文章的目的正是分享这些“技术”。

训练营

如果你熟悉团队伙伴，那么你很容易向他们学习，但是新员工该怎么办？ Prezi 努力让新加入的工程师跟上代码库和公司价值的发展。解决方案是缩短 Facebook 令人印象深刻的为期 6 周的马拉松式训练，创建自己独有的两周训练营，在其中新雇员花一天时间与构成公司的各支团队共处。设计这样一个“迎新周”的目的是传递若干不同类型的知识。

首先，花一些时间与 Prezi 的每支团队共处，是新人了解其新同事们的好方法。与一般“旋风之旅”中的数千次握手相比，新人更容易通过围绕着有趣主题简短对话或速成课来记住团队成员的名字。除了能够将名字与面孔联系起来，训练营的毕业生们还将知道他们可以找谁来解决某个特定的问题。

其次，训练营为新的 DevOps 工程师提供了鸟瞰视角，来了解 Prezi 的基础架构和代码。一般在简短的演讲后，训练营学员会被分派一个小却相当有挑战性的任务。例如编写一个用于配置 apache 实例的 chef“配方”，并针对为了 Prezi Desktop 使用 hadoop 数据而导出的 prezis 的数量创建仪表盘，这些精心挑选的微型项目不仅是在给定时间内可完成的，而且还对学员自身有帮助，而不仅仅是“附加作业”（注：指没有实际价值、强制安排的任务）。学员一般还会要求与两到三位有经验的工程师沟通，以获取一些解决手头的问题的建议。

最后，训练营向新员工展示了在创业环境中工作是什么样的。Prezi 按团队而不是部门组织，我们没有太多管理层级，但我们有一个用户体验研究团队。所有这些独特之处可能会对新人造成一些迷惘。对新加入的工程师来说，Prezi 的迭代开发风格大概是最难整合到他们的工作习惯中的新概念，而这仅仅是因为这种现象的普遍存在。这里的迭代开发是指遵循构建- 评估- 学习这样的循环。在Prezi 中，我们尝试采用这种“精益创业”的方式，不止用于重要产品决策，还用在15 分钟的小任务以及二者之间任何规模的工作上。每位工程师都有责任通过构建足够好的解决方案来避免浪费，这些解决方案是可测试的，并且如果需要的话，销毁它们也不必消耗大量的时间和精力。Prezi 对启用工作系统的迫切期望，与第一时间寻找完美解决方案的任务恰恰相对立，这在学院和大型组织中是很普遍的现象。一位新加入的团队成员谈到，在训练营中听到每个组都在演讲中谈论重写代码或重新考虑流程，这着实能帮助人理解迭代精神。从训练营毕业后，他对Prezi 的工作方式了解了更多，而且还知道他带来的知识能够帮助谁——学习是双向的。

聚会

结识陌生人是寻找新理念的一种可靠途径，而聚会对于寻找其他组织中面对相似挑战的人而言也是个好办法。除了交流“血汗史”外，与公司之外的工程师们沟通还能够作为一种现实问题的检查。例如，如果我们使用个特定的数据库时遇到了很多麻烦，那么我们就很有必要弄清楚，到底是我们配置的问题，抑或我们采用的这个版本也让其他人吃到了苦头。

Prezi 承办若干技术聚会，聚会一般向与会者免费提供披萨饼和啤酒。这是一个经典的双赢局面：对聚会组织者而言，得到一个免费提供的合适场所是一种很大的帮助。对 Prezi 而言这样的安排则得到以下若干好处。

首先，这便于员工参加与他们日常工作相关的聚会。当我的一位团队成员在布达佩斯DevOps 聚会上做 Apache Kafka 方面的演讲时，我们许多同事都到现场观看，因为他们只需要在下班后爬上楼即可。第二天，每个参加的人都在谈论：基于昨天晚上的演讲，我们应该如何重新考虑为服务分配的硬件总量。

其次，这是个培养员工对技术的兴趣的好办法。如果我痴迷于计算机科学或编程语言方面的某个研究领域，我唯一需要做的就是寻找足够多的人来分享我的兴趣。由于我不需要操心场地，组织这样一场聚会的门槛是非常低的。即使聚会主题目前不能在 Prezi 中运用，也许某一天它会成为解决我们公司面对的某个问题的必要知识。

最后，承办聚会将为 Prezi 带来工程师人才。对任何穿过 Prezi 大门的人来说，显然它并不是一家普通的软件公司。当这些人打算跳槽的时候，很有可能会向 Prezi 投一份简历。

将聚会中提出的一个有趣想法在团队中传播，是引发一场技术讨论的极好途径，这样的讨论可能对所有参与者都有帮助（即使最初的想法被证明无法用于目前的问题）。

便当演讲（Brown bag talks）

讲座也许是最古老的分享知识的形式，而它在 Prezi 中依旧盛行。45 分钟到一个小时的“便当演讲”（取名于听众们用来包装三明治的棕色纸袋）是可选的午餐时间讲座。演讲的主题可以是任何内容。

我们定期邀请讲座嘉宾举办这样的演讲。一些令人难忘的演讲包括由匈牙利前驻美大使带来的欧美贸易关系速成课程，以及 Spotify 的数据服务团队如何应对技术和组织体制挑战的演讲。

任何员工都可以自由地组织这样的演讲。最好的演讲之一是关于 paxos 算法及其备选方案的。演讲者在加入 Prezi 之前已经成是该主题的专家。演讲结束后，听众们对什么是可行的折衷有了新的理解。在我们团队里，当学习了数据一致性后，那些有运营背景的工程师疯狂地努力回忆他们是否曾意外地为 MongoDB 配置了危险的设置。

便当演讲与普通内部演讲的不同之处，在于它非正式的本质。如果某位观众发现这个演讲并不适合自己，他们可以自由离开。因此，只有很少的人会在演讲过程中沉浸于笔记本电脑或智能手机里。这种非正式氛围也有助于演讲者更轻松地传递他的想法，因为在组织演讲内容的时候，他不必考虑是否与整个公司的方向一致。

与即兴谈话相比，这样的演讲活动需要更多的准备，这使其成为与同事分享自己专业知识的有效途径。

编程马拉松 (Hackathons)

最可靠的学习方式是“在工作中学习”。不过这并不意味着你必须独自阅读帮助页面并解决全部问题。对团队的成员来说，互相学习共同解决不常见的问题的一种良好方式。

在布达佩斯的工程总部，Prezi 定期组织编程马拉松活动并欢迎任何有兴趣的人参加。活动由一场关于有待实践的奇思妙想的头脑风暴开始。员工和访客们围绕着热门理念组成了混合的团队。这些团队在接下来的一天半中将通过“hack”（注：这里指编程）来证明他们理念的可行性。

其中一些团队着眼于与 prezi.com 相关的项目，但这并非强制要求。一个明显的反例是某个团队编写了一个能够列出当前谁在办公室的 Web 应用。它通过列出连接到公司 WiFi 网络的无线设备实现这一功能。这个应用的编写很好地搭配了低层 UNIX 编程、Python Web 应用代码，以及在客户端侧的一些巧妙的 JavaScript 代码。

编程马拉松是模拟 DevOps 团队的生活中实际发生的紧急事件的好方法——它们在许多方面都有相似之处。两种情况下，混杂的团队（注：指 dev-ops 的团队组合）都在处理非常模棱两可的问题。此外，时间是一项制约因素，因此团队需要快速解决方案。最后，每个团队成员能够发挥其任何力量以更好地提供贡献，团队就越有可能成功。在技术因素之外，两种环境中团队成员被设定的角色也是相似的。自然而然地，一些成员会承担协调员的角色，其他人则会选择“多干少说”的角色。无须赘述，一个成功的团队同时需要这两种角色。找出每个团队成员的角色，对于准备应对诸如 MySQL 主节点宕机导致停工和数据丢失这样的真正的 DevOps 灾难至关重要。

内部课程

以上介绍的“技术”（注：此处“技术”指公司内部知识分享的方法，而非具体开发技术）都属于知识分享而不是供应商课程。然而，当超过一定技术深度后，这些非正式方法往往就失去了作用，特别是当听众的技术背景过于多样化的时候。

通过可预知的课程安排和适中的速度，学员们有机会完全浸入到课程的主题中。例如，Prezi 组织过一场简要介绍 Haskell 编程的课程，在连续四个周五的早上举行。公司里的每个团队都参加了课程，设计师和 QA 工程师们，与拥有多年函数式编程经验的开发者坐在一起。课程从基本内容开始，以稳定的节奏讲授了相当多的内容。课程鼓励参与者们互相之间以及向导师（他也是一位同事）提问。因此，关于课程内容如何在日常工作中应用的问题和建议上花了许多时间，即使这导致我们偏离了原来的课程计划。虽然我们只在很少的产品系统中使用 Haskell，但这样的灵活性和开放的氛围还是使其成为一次成功的课程。

公司还用类似的方式组织了一个专注于经典计算机科学文章的阅读组。每周都有一位组员介绍阅读列表中的一篇文章。接下来的讨论里，每个组员都可以评论或挑战演讲者对文章的解读。

供应商课程一般由经验丰富的演讲者使用专业教学材料来讲授。这是一种由专家向听众进行单向信息传播的有效方式，其中的一些案例使得参加课程对 Prezi 的工程师是有意义的。Prezi 的内部课程与厂商提供的内容并不是直接竞争关系。相反，组织内部课程的原因根植于这样的现实：单向模型并不是交流的唯一途径。实际上，甚至它也许并不是最重要的一种。毕竟一个 DevOps 团队解决问题的方式，往往是更非结构化的流程，经常需要某人为自己应对某个问题的解决方案进行辩护，或是进行正确的询问以快速寻找导致问题的根本原因。在提供有用的技术信息的同时，这些内部课程和阅读组也绝对有助于提升那些对顺畅运作一个团队所更需要的软技能。

Prezi 正在成为一个演讲公司，这样的氛围特别有利于让员工不仅获得技术方面的成长，还增强分享理念的能力。通过分享能力的提升，工程师将会在技术方面更好的互相帮助。

总结

自从在 Prezi 开始作为 DevOps 工程师的工作以来，我从同事们那里学到了很多很多。帮助其他人解决问题并最终成为更好的工程师的感觉很棒。大部分人希望在类似 Prezi 这样的环境中工作，这里鼓励每个人分享自己的理念，而任何理念都可能受到挑战。Prezi 采用的这些替代供应商课程的知识分享技术有助于创造这样的环境。在 DevOps 团队内促进信息的无障碍流通非常关键，因为团队成员各自背景不同，每个人都可能拥有一些能够帮助其他人的知识。建立团队间的对话也会带来类似的价值。不管公司是否让雇员们参加专业课程，尝试 Prezi 的这些选择都有机会让公司获得收益。