引导互联网计算机的DevOps
所有创业公司在生存的每个阶段都面临独特的挑战和问题。DFINITY基金会，一个总部位于瑞士的不以营利为目的、延伸网络的使用功能的公司，也不例外。
像任何新组织一样，我们不得不发展和适应DevOps（Development & Operations）和其他实践，以应对不同的障碍。
在学习清楚地传达了我们对软件直接在互联网上运行的开放式开发平台的愿景之后，我们创建了一个路线图，将这一愿景转化为具有独特功能的分散式架构，可以按周期性的节奏进行构建和交付。
该路线图由五个里程碑组成，最终在2020年第四季度公开发布，尽管有全球流行病的阻碍，但我们没有错过任何一个截止日期。
在发布名为Tungsten的开发人员网络之前，今年将主要精力放在交付功能而不丢失速度上，这是我们面临的主要挑战，必须持续引导对此版本以及将来版本的操作责任。
我们都听到过类似的故事，这些故事涉及操作团队以确定性的方式贯穿检查表，而没有找出问题的根本原因。
更糟糕的是，他们很快就会放弃，并且抵制发起变更，从而增加了工作量的复杂性。
推动DevOps
我们确定DFINITY的DevOps不会发生这种情况，因此我们将这些核心的文化试金石嵌入到组织中。
创建SLO和SLI以使跨功能清晰
在2019年底，在没有服务可运行之前，我们开始考虑服务水平目标（SLO）和服务水平指标（SLI），这些对于为研发和运营团队提供一种通用的、可量化的本地语言来衡量服务的性能至关重要。
SLI是针对服务性能的一个明确定义的指标，理想情况下应关注于用户可见的服务行为，SLO设置指标的目标以及测量指标的时间窗口。
为了与SLI和SLO进行沟通，在整个组织中提供了培训材料，包括与各个工程团队进行交谈，在管理会议上讨论最佳实践以及在组织范围内的会议上进行概述。
此外，研发团队的领导者也批准了该方法。
为了提供明确的运营期望和强制功能，我们将SLO的早期版本确立为高度优先的OKR。
另外，SLO必须反映用户可见的服务方面，这一点至关重要。
来自Honeycomb.io的CTO指出：“花枝招展并不重要，如果你的用户不开心。”
SLO并非一劳永逸的东西，随着服务的发展以及您捕获UX的能力的提高，它们需要进行更新。
制定SLO给具有运营责任的员工明确的期望实现，如果服务在SLO中执行（并且SLO代表用户的幸福感），则说明一切运行顺利。
开发软件的工程师还应该帮助在生产中运行该软件
为了引导具有运营和支持能力的团队，我们需要确保我们不会创建一个缺乏工程技能的孤立团队。在这种情况下，操作是一个软件工程问题，这意味着我们需要让开发人员参与。
就软件在生产中的运行方式而言，开发该软件的工程师应具有游戏的感官。如果有问题，这些工程师将最有能力诊断他们并提出并实施必要的修复程序，为此需要组织的支持。
我们强调高级工程师必须能够运行所构建的软件，我们不想陷入在没有适当监督或培训的情况下将少数初级工程师推入深渊的陷阱，因此我们还期望所有工程师都能够操作该软件，而不论其资历如何。
我们在加利福尼亚州帕洛阿尔托的每个办公地点都建立了两个由5至10个开发人员组成的团队，包括旧金山和苏黎世，最初在整个组织中都配备了志愿者。
每个星期，每个站点的一名团队成员负责服务的主要运营责任，而不是他们的常规项目工作，他们知道，如果有任何问题，全体员工都会提供帮助，我们计划每6到9个月将新人员转入这些临时小组。
建立最佳规模的沟通团队
运营团队的规模也很重要，如果团队太小，人们会经常在电话上，如果团队太大，他们将很少被召集，以至于他们要么忘记如何操作生产堆栈，要么他们的知识将过时。
我们通过每日日志和非正式的共享沟通渠道（例如Slack）共享状态更新，还有每周一次的会议，将一个人的责任转嫁给另一个人。
这帮助我们确定了能力差距，我们的团队成员遍布世界各地，我们已经认识到，如果问题需要团队在工作时间之外提供专业知识，那么先回滚然后再进行调查是绝对可以的。
DevOps团队很早就决定，我们不会从24/7支持开始，而是在欧洲和美国的工作时间内提供支持，而欧洲和美国是我们大多数早期访问客户所在的地方。
在整个过程中，我们一直对更广泛的组织透明，指出什么是什么，什么不是很好，以及我们如何改进流程。
结论
幸运的是，像COVID-19这样的前所未有的全球性事件并未对我们的运营产生重大影响。
就是说，亲自塑造我们的流程并在人们第一次上班时亲自出现在他们身上是很有价值的，而且我们绝对感到失去它的影响。
但是，尽管如此，我们仍然成功地引导了DevOps团队，我们期待着团队的不断发展。
作者：Nik Clayton
翻译：Catherine
进Dfinity官方社群，请添加小助手微信：
comiocn
长按关注
Dfinity官方微信
给你第一手资讯和项目信息
更可随时答疑解惑