6 月 5 日召开了伦敦 DevOps 企业峰会，InfoQ 采访了 Rundeck 公司的联合创始人 Damon Edwards，讨论了 “自助运维（Self-Service Operations）” 的优势与实现。

Edwards 认为，“自助运维”意味着让开发人员和运维人员界定出组织中能够“以服务形式提供”的运维流程。初看而言，自助运维的设计模式比较简单：将运维任务呈现为自动化按钮或 API 的形式，并开放给他人。然而，自助运维实际上是自动化流程思维的一个重大飞跃。

通过采用自助运维，公司将关键的自动化组件分离出来，交由在相关领域中劳动效率最优、最敏捷的组织。自助运维的投资回报率收益体现在：减少有问题或错误的阶段移交导致的中断，减少推向市场花费的时间，增强组织的能力。

Edwards 最后总结说，虽然技术能力很重要，但最终决定自助运维和 DevOps 成败的仍然是组织变革。采访的完整记录链接在文末。

InfoQ：Damon，欢迎光临 InfoQ！能否请你分享在伦敦 DOES 17 峰会上所做演讲的摘要？听众能从演讲中收获些什么？

Damon Edwards：去年，我和 John Wills 做了一次名为“更好、更快、更省钱：如何做到？”的演讲，介绍了一流企业以高质量、低成本为前提实现更快运作的一些技巧。演讲很受欢迎，DevOps.com 甚至将它评为当年最佳 DevOps 演讲。（InfoQ 注：关于 Damon Edward 和 John Wills 的演讲：“更好、更快、更省钱：这对运维意味着什么？(watch?v=j9fC4raB-bA”，更多细节可以访问伦敦 DevOps 企业峰会（DOES）页面。）

所以今年我们当然得继续这个话题。今年我们深入探究这些技巧如何促使运维工作发生转变。John 会谈论基础设施正在发生怎样的变革，尤其是变革对容器化和不可变基础设施设计模式的影响。我会谈论运维组织如何改变工作方式和构建方式。我会重点探讨一种有趣的设计模式，名为“自助运维”。

InfoQ：从你的经验来看，企业内部现有的系统管理团队或运维团队想要采用“自助运维”的工作方式，他们需要做出的最大改变是什么？

Edwards：初看上去，自助运维的设计模式是比较简单的：只要将运维任务呈现为自动化按钮或 API，并开放给他人即可。然而如果深入观察，我们会发现，其中的内涵远不止于此。自助运维是自动化流程思维的一次重大飞跃。

自动化流程有三大关键部分：自动化流程的定义、执行自动化流程的能力，以及对自动化流程安全管理政策的控制。通常来说，这几大部分都是不可分割的，它们都属于运维的一部分（通常由同一个团队处理）。使用自助运维后，企业可以将这些关键部分剥离出来，并交由相关领域中劳动效率最佳和最敏捷的组织来处理。

例如，让开发者定义运维流程，运维审查之后交由同一批开发者来执行，或者交给其他团队处理，这种做法在传统组织中是无法想象的。自助运维就是要打破这一桎梏。

InfoQ：组织在迁移到自助运维之前和之中，应该追踪哪些指标或 KPI？标志着组织成功迁移的“关键指标”是什么？

Edwards：谈到“关键指标”，我推荐使用 DevOps 的经典指标：交付周期（lead time）。它可以是交付环境中的交付周期，也可以是解决一项事件的交付周期。交付周期对业务很关键，要优先关注这一指标。

然而在更高层次上，在组织中所处的位置不同，自助运维的投资回报率收益也不同。 运维支持团队的投资回报率收益包括：缩短事件响应时间、减少错误和返工、增加团队可以处理的支持总量、减少跟进事态（escalation）的响应时间，以及增加其他团队可以处理的运维支持任务。

运维支持以外的团队能得到的收益包括：减少跟进事态的数量、减少等待运维任务执行的时间、减少有问题或错误的阶段移交导致的中断。组织层面得到的好处包括：减少支持成本、缩短推向市场的时间、增强组织的能力。

InfoQ：对于使用已有工具处理服务、工作（如 Jenkins、cron）的运维团队来说，诸如 Rundeck 等自助平台还能提供哪些内容？

Edwards： Jenkins 和 cron 是两种不同的情况，需要分别讨论。

首先，Jenkins 和 Rundeck 可以很好地协作。事实上，Jenkins 是 Rundeck 最流行的集成之一。Jenkins 基本上来说是一个开发工具，是为开发者和开发工程师而设计的。Rundeck 功能全面，是一个用于运维的编排与调度工具。例如，Rundeck 可以获取基础设施、ACL 策略、输出格式和调度功能等信息，它的这些功能都是基于企业运维的需要而设计的。

cron 是一个简单的调度应用，运行在独立的服务器上。Rundeck 可以用作中心化的简单调度工具，但更常见的调度需求会包括工作流、错误处理、通知、接入控制、截流等等。这些一般被称作是“企业工作调度”或“企业负载自动化”。虽然经常有人说自己会使用 Rundeck 合并本地调度器，就像 cron 那样，但Rundeck 更流行的调度器用途是取代旧有的企业工作调度器，如 Control-M、Autosys、Tidal 或 UC4。

InfoQ：总的来说，你认为 DevOps 与想要加速运营的企业组织关系多大？以你来看，在典型的企业环境中，是组织变革的需求更重要还是技术变革的需求更重要？

Edwards： DevOps 非常重要。企业都非常复杂，做事并没有什么捷径可循。我们需要一系列方法来实现目标。DevOps 社区很棒，因为其中包含了很多经实践验证的方法。只要学习 DevOps 社区里经证实有效的手段，并应用到自己的企业就足够了。

如果需要更正式的阐释，我极力推荐《凤凰项目》与同系列的《DevOps 手册》。它们共同探讨了组织变革与技术变革之争的话题，但最终成败的关键依旧是组织变革。所谓组织变革，我指的是人们如何看待和协调周围环境的方法，以及完成必要任务以交付商业价值的方式。

有很多工具可以帮助改变习惯，但是如果这些工具不能影响到组织的变革，只会重蹈覆辙。如果关注组织变革，则工具就会变得易于使用。如果关注工具本身，那么就会面临无穷无尽的组织问题。

（Daniel Bryant原创）

6 月 5 日召开了伦敦 DevOps 企业峰会，InfoQ 采访了 Rundeck 公司的联合创始人 Damon Edwards，讨论了 “自助运维（Self-Service Operations）” 的优势与实现。

Edwards 认为，“自助运维”意味着让开发人员和运维人员界定出组织中能够“以服务形式提供”的运维流程。初看而言，自助运维的设计模式比较简单：将运维任务呈现为自动化按钮或 API 的形式，并开放给他人。然而，自助运维实际上是自动化流程思维的一个重大飞跃。

通过采用自助运维，公司将关键的自动化组件分离出来，交由在相关领域中劳动效率最优、最敏捷的组织。自助运维的投资回报率收益体现在：减少有问题或错误的阶段移交导致的中断，减少推向市场花费的时间，增强组织的能力。

Edwards 最后总结说，虽然技术能力很重要，但最终决定自助运维和 DevOps 成败的仍然是组织变革。采访的完整记录链接在文末。

InfoQ：Damon，欢迎光临 InfoQ！能否请你分享在伦敦 DOES 17 峰会上所做演讲的摘要？听众能从演讲中收获些什么？

Damon Edwards：去年，我和 John Wills 做了一次名为“更好、更快、更省钱：如何做到？”的演讲，介绍了一流企业以高质量、低成本为前提实现更快运作的一些技巧。演讲很受欢迎，DevOps.com 甚至将它评为当年最佳 DevOps 演讲。（InfoQ 注：关于 Damon Edward 和 John Wills 的演讲：“更好、更快、更省钱：这对运维意味着什么？(watch?v=j9fC4raB-bA”，更多细节可以访问伦敦 DevOps 企业峰会（DOES）页面。）

所以今年我们当然得继续这个话题。今年我们深入探究这些技巧如何促使运维工作发生转变。John 会谈论基础设施正在发生怎样的变革，尤其是变革对容器化和不可变基础设施设计模式的影响。我会谈论运维组织如何改变工作方式和构建方式。我会重点探讨一种有趣的设计模式，名为“自助运维”。

InfoQ：从你的经验来看，企业内部现有的系统管理团队或运维团队想要采用“自助运维”的工作方式，他们需要做出的最大改变是什么？

Edwards：初看上去，自助运维的设计模式是比较简单的：只要将运维任务呈现为自动化按钮或 API，并开放给他人即可。然而如果深入观察，我们会发现，其中的内涵远不止于此。自助运维是自动化流程思维的一次重大飞跃。

自动化流程有三大关键部分：自动化流程的定义、执行自动化流程的能力，以及对自动化流程安全管理政策的控制。通常来说，这几大部分都是不可分割的，它们都属于运维的一部分（通常由同一个团队处理）。使用自助运维后，企业可以将这些关键部分剥离出来，并交由相关领域中劳动效率最佳和最敏捷的组织来处理。

例如，让开发者定义运维流程，运维审查之后交由同一批开发者来执行，或者交给其他团队处理，这种做法在传统组织中是无法想象的。自助运维就是要打破这一桎梏。

InfoQ：组织在迁移到自助运维之前和之中，应该追踪哪些指标或 KPI？标志着组织成功迁移的“关键指标”是什么？

Edwards：谈到“关键指标”，我推荐使用 DevOps 的经典指标：交付周期（lead time）。它可以是交付环境中的交付周期，也可以是解决一项事件的交付周期。交付周期对业务很关键，要优先关注这一指标。

然而在更高层次上，在组织中所处的位置不同，自助运维的投资回报率收益也不同。 运维支持团队的投资回报率收益包括：缩短事件响应时间、减少错误和返工、增加团队可以处理的支持总量、减少跟进事态（escalation）的响应时间，以及增加其他团队可以处理的运维支持任务。

运维支持以外的团队能得到的收益包括：减少跟进事态的数量、减少等待运维任务执行的时间、减少有问题或错误的阶段移交导致的中断。组织层面得到的好处包括：减少支持成本、缩短推向市场的时间、增强组织的能力。

InfoQ：对于使用已有工具处理服务、工作（如 Jenkins、cron）的运维团队来说，诸如 Rundeck 等自助平台还能提供哪些内容？

Edwards： Jenkins 和 cron 是两种不同的情况，需要分别讨论。

首先，Jenkins 和 Rundeck 可以很好地协作。事实上，Jenkins 是 Rundeck 最流行的集成之一。Jenkins 基本上来说是一个开发工具，是为开发者和开发工程师而设计的。Rundeck 功能全面，是一个用于运维的编排与调度工具。例如，Rundeck 可以获取基础设施、ACL 策略、输出格式和调度功能等信息，它的这些功能都是基于企业运维的需要而设计的。

cron 是一个简单的调度应用，运行在独立的服务器上。Rundeck 可以用作中心化的简单调度工具，但更常见的调度需求会包括工作流、错误处理、通知、接入控制、截流等等。这些一般被称作是“企业工作调度”或“企业负载自动化”。虽然经常有人说自己会使用 Rundeck 合并本地调度器，就像 cron 那样，但Rundeck 更流行的调度器用途是取代旧有的企业工作调度器，如 Control-M、Autosys、Tidal 或 UC4。

InfoQ：总的来说，你认为 DevOps 与想要加速运营的企业组织关系多大？以你来看，在典型的企业环境中，是组织变革的需求更重要还是技术变革的需求更重要？

Edwards： DevOps 非常重要。企业都非常复杂，做事并没有什么捷径可循。我们需要一系列方法来实现目标。DevOps 社区很棒，因为其中包含了很多经实践验证的方法。只要学习 DevOps 社区里经证实有效的手段，并应用到自己的企业就足够了。

如果需要更正式的阐释，我极力推荐《凤凰项目》与同系列的《DevOps 手册》。它们共同探讨了组织变革与技术变革之争的话题，但最终成败的关键依旧是组织变革。所谓组织变革，我指的是人们如何看待和协调周围环境的方法，以及完成必要任务以交付商业价值的方式。

有很多工具可以帮助改变习惯，但是如果这些工具不能影响到组织的变革，只会重蹈覆辙。如果关注组织变革，则工具就会变得易于使用。如果关注工具本身，那么就会面临无穷无尽的组织问题。

（Daniel Bryant原创）