devops三大原则

自单击本文以来，您可能想知道为什么没有达到DevOps流程期望的质量，效率和满意度。 也许您认为其他组织正在取得比您更大的成就。 如果是这样，您可能正在尝试做其他人正在做的事情，而不是独立思考并建立适合您组织的DevOps计划。

回归本源

花点时间考虑一下您想使用DevOps实现的目标以及原因。 最终，我们所有人都希望更快地构建和开发软件。 如果我们采用任何敏捷方法（scrum，看板，SAFe等），那是因为我们相信它将帮助我们实现这一目标。

怎么样？ 通过不断地检查和适应。

一切都是为了更快地实现目标 。 您和您的团队或公司的目标是为实现的 。 这些可能不是您六个月，十二个月或十八个月之前计划的目标。

一个强大的DevOps组织具有适应能力和自我修复能力。 它具有一些简单的规则，可以使自组织系统出现，从而为整个组织的利益做出决策，而无需中央授权

为了大规模实现DevOps，您需要一种管理策略。 您不能仅仅关注诸如持续集成/持续交付或类的技术实施。 以下八项原则指导着我们如何实现大规模DevOps。

1.建立一个工作队，而不是一个团队

以最简单的形式，DevOps可以看作是交付过程中敏捷的扩展。 这是打破开发团队和运营团队之间孤岛的一种方法。 DevOps 团队在其他团队之间找到了自己的位置，在dev和ops孤岛之间添加了一个“ DevOps孤岛”。 相比之下，DevOps 模糊了开发人员和操作人员之间的界线，将它们组合在一起。 这不仅仅是将“团队”重命名为“任务组”； 这是一种完全不同的战略方法，可以扩展您的DevOps实践。

将您的工作队视为多能力中心。 其目的是加入一个项目，并帮助开发人员和运维团队尽一切可能加快交付过程的速度，而不仅仅是CI / CD的实施。

例如，技术债务可以通过以下方式消耗您的速度：

• 不采用最新的性能更新会降低您的产品速度，并可能导致自定义代码变通办法。
• 如果不实施最新的安全更新，则可能需要供应商的额外支持（换句话说，就是金钱），但是许多组织只有在出现安全漏洞之前才会对其进行处理。 这可能会对公司造成很多损害，而且要承担损害赔偿责任，这意味着要使用本可以用于扩展业务的资源。
• 软件和工具的迁移计划可能需要6到18个月的时间。 在开始迁移计划之前等待他们达到使用寿命（EOL）会对业务产生重大影响和成本，并减慢产品团队的工作速度。

一个工作队以其高超的技能和多样化的成员而闻名，他们可以通过以下方式帮助其他项目和部门：

• 确定缓慢的流程（例如，入职面试，在多个冲刺中工作的现场团队）
• 自动化缓慢的流程（例如，按需登台环境，应用程序测试，平台测试，基础架构测试，虚拟机模板，容器构建过程，ChatOps）
• 帮助人们提高绩效（例如，培训实验室，新雇佣工，棕色皮包午餐，聚会）
• 确保团队可以继续并维持他们的工作

2.创建一个自组织的系统

当您看到一群鸟在飞翔时，您可能会注意到没有一只鸟在编排它们的运动。 简单的规则可以使自组织系统出现，从而使整个团队受益。

在符合DevOps的公司中，团队需要能够以很少甚至没有开销的方式彼此同步。 例如，开发团队可以与服务提供商交互，而不必与内部团队同步。 他们必须在内部实现这种无同步能力。

以下是我的三个简单规则（找到适合您组织的规则）：

• 全面了解团队的可用性（例如，开发，构建，服务状态，人员规划）
• 授予对正在进行的工作的完全访问权限（例如，杀死电子邮件和政治事务，而使用在线论坛来处理所有事情：项目，任务，会议记录，链接，讨论）
• 一次处理一项任务以防止上下文切换

为了遵守我的规则，我每天打开我的电子邮件应用程序两次。 我禁用了Slack通知，每小时查看一次。 所有的浪费都消失了，出现了真正的东西，如果我急需的话，人们会打电话或来我的办公桌旁。 我还使用手机上的应用程序和基于的计时器应用程序来帮助我集中精力。

您必须不断检查和调整，以便团队可以找到自己的实施和处理规则的方式。 需要注意的三件事：

• 我相信第一次迭代将是不完美的，因为采用速度很慢并且伴随迭代
• 在获得速度之前，您必须先接受减速
• 帮助团队公开内部信息是DevOps工作队的一部分

3.与敏捷教练紧密合作

DevOps是敏捷的扩展，因此您需要与敏捷教练一起工作。 如果需要，请雇用一位，因为您需要一位拥护者。 您所谓的“数字化转型”取决于与他人共同建立愿景。 您必须建立共识，因为您不一定总能找到正确的答案。

在当今的组织中，每个人都有关于如何实现DevOps的想法。 如果他们不相信您在做正确的事情，那么他们会降低整个系统的速度（有意或无意）。 人们需要了解您在做什么以及为什么。 一旦达成共识，就让倡导者去做。 这是继续取得进步所需要的平缓的开始。

4.对团队进行软技能培训

我建议提供关于软技能的简短，高度集中和实用的培训-DevOps团队每天使用的工具而不必成为高级用户。 以我的经验，每个人都对这种方法感到满意，并且采用率立即增加。

我为团队训练的一些软技能包括：

• manbetx客户端打不开：古铜/初学者或金/终极有什么区别？ 我们可以添加什么功能？
• 我们如何以及为什么签署Git提交
• SSH协议
• 重击高级用法
• Sed / Awk
• 的OpenSSL

5.授权团队

通过给团队一些空间来提高参与度。 是的，必须建立信任并认真对待。 明确限制他们的责任以及您希望他们实现的目标。

了解他们可以（并将）突破这些限制。 不过，让他们自己决定是否进行。

最重要的是，当发生故障时，您会知道并可以控制中断区域，而当您授权团队时，这种情况更有可能发生。

6.不确定是你的朋友

这是一个简单的循环：

1. 让一小群工程师参与真正的最终用户关键绩效指标（KPI）
2. 让他们决定如何实现他们
3. 管理如何处理任何故障
4. 重复

帮助小组进行KPI审查。 像天使投资人一样与初创公司合作：对许多公司竞标（请记住这是关于规模的），控制失败，并扩大和收集成功。

请记住，如果从失败中学到任何东西，失败仍然是失败。 否则，它将成为经验。 经验是决定质量的因素。

作为经理，不要专注于失败。 取而代之的是，专注于无罪的验尸：我们如何防止它再次发生？ 如果可以，请参加验尸。

7.这（不只是）关于技术实施

DevOps旨在帮助将敏捷和精益开发原则扩展到生产。 通常，这被视为自动化交付过程，但更多。

Google在DevOps出现之前很久就引入了 （SRE），它实现了DevOps原理。 DevOps（通常是敏捷）可以看作是一种进化机制：不断失败，修复和尝试适应。

一些最佳实践（例如 ）和技术体系结构（例如容器编排和微服务）是我们生活中的头等公民，因为它们通过设计趋向于解决从故障中恢复的速度和隐秘性。 根据定义，这既敏捷又精益。

8.保持最新

使用许多可用资源。 阅读 ，订阅 （ ）的每周一次的时事通讯，并参与诸如或 。

结论

敏捷和DevOps的倡导者试图帮助公司提高适应性。 许多传统和大型公司似乎都认为DevOps只是在大肆宣传。 以我的经验，这与生存有关。

---

接下来要读什么

翻译自:

devops三大原则