A DevOps Manifesto(翻译）DevOps宣言

DevOps宣言 翻译

原文链接
BY ERNEST MUELLER | OCTOBER 15, 2010 邵栋 翻译 2017.5.22

最近大家在讨论曾经在德国汉堡的DevOpsDays上讨论的DevOps宣言，我在想，现有的敏捷软件开发宣言有什么问题？我们不能把这个作为统一的指导原则吗？
让我们看一下敏捷软件开发宣言的价值观和原则。如果不是从纯代码开发者的观点，而是从系统的角度来看这份宣言应该是怎么样的？下面是我的一个尝试：

DevOps宣言

我们一直在实践中探寻更好的运行系统的方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：

个体和互动 高于 流程和工具
工作的系统 高于 详尽的文档
客户以及程序员合作 高于 合同谈判
响应变化 高于 遵循计划

也就是说，尽管右项有其价值，我们更重视左项的价值。

这没有很大的不同。在我看来，我们可以毫无保留地接受一些条款。作为一个以系统管理为工作的人，我对个体和互动高于流程和工具感到紧张（这是否会促进牛仔心态？） - 但这并不是说自动化和工具不好，事实上它是必要的（看看敏捷软件开发实践，有明确的过程和工具），但是参与的人应该永远是主要关注点。 我的观点是敏捷宣言与开发、运维或业务无关，这是一个通用的合作模板。而对于Ops vs Dev而言，“DevOps”有非常不同的观点吗？不是很多。

我们还有敏捷软件开发的十二条原则， 仍然是抽象度很高的内容，但这里是我认为我们开始在现有列表之外有更多独特的问题。

DevOps宣言背后的原则

我们遵循这些原则：

1. 我们最重要的目标，是通过持续不断地及早交付有价值的功能使客户满意。 （比“软件”更通用）

2. 软件功能只有在完整的系统交付给客户后才能实现。对于用户来说，非功能性需求与功能性需求一样重要。（新：为什么系统很重要）

3. 基础设施是代码，应该同样进行开发和管理。 （新。）

4. 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。（相同。）

5. 经常地交付可工作的功能，相隔几星期或一两个月，倾向于采取较短的周期。（软件 - >功能）

6. 业务人员、开发人员和运维人员必须相互合作，项目中的每一天都不例外。 （添加运维人员。）

7. 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。 （相同。）

8. 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。 （相同。）

9. 可工作的软件并进行完整交付是进度的首要度量标准。（添加系统。）

10. 敏捷过程倡导可持续开发。责任人、开发人员、运维人员和用户要能够共同维持其步调稳定延续。 （添加运维人员。）

11. 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。 （相同。）

12. 以简洁为本，它是极力减少不必要工作量的艺术。（相同 - KISS原则）

13. 最好的架构、需求和设计出自自组织团队。（相同。）

14. 团队定期地反思如何能提高成效，并依此调整自身的举止表现。 （相同。）

这是一个极简集。

这听起来像是仍然把软件放在第一位吗？是。这是合适的。系统是向用户传达软件功能的，它们独立存在没有任何价值，我是作为一个系统管理人员说这句话的。然而，我在几个地方将“软件”改为“功能” - 使用系统和现有软件（开源，COTS等），您可以为用户提供有价值的功能，而无需您的团队编写代码。

无论如何，我喜欢将自己将运维工作内容插入到现有的敏捷过程中的想法，而不是另起炉灶的“DevOps宣言”，那样会不得不回答很多原始敏捷宣言已经回答的问题（例如“业务怎么样？”） 。我认为DevOps的要点之一就是“嗨，敏捷背后的概念是完整的，但是我们忘了在合作中包括我们的运维人员，可以理解，因为10年前，大多数应用程序都是桌面软件，但是现在许多（大多数）是服务，我们是创建和交付应用程序的重要组成部分。“

大家的想法是？