肿瘤康复网 > devops涵盖的三个阶段_3个领域推动DevOps变革

devops涵盖的三个阶段_3个领域推动DevOps变革

时间：2019-11-20 09:06:52

相关推荐

devops涵盖的三个阶段

避免疼痛是强大的动力。一些研究表明，即使植物也遭受某种痛苦，并采取措施保护自己。但是，我们有许多例子说明人类有意忍受痛苦，运动常常会伤害人，但我们仍然会这样做。当我们认为付出值得付出痛苦时，我们将忍受几乎所有事情。

事实是，推动大规模组织变革是痛苦的。对于那些不得不改变自己的价值观和行为的人来说，这是痛苦的，对于领导者来说，这也是痛苦的，对于那些只是想工作的人们来说，这也很痛苦。但是，对于DevOps，我可以告诉您痛苦是值得的。

我已经亲眼目睹了团队如何学习他们必须花时间改进其技术流程，拥有自动化管道并成为命运的主人。他们获得了成功所需的工具。

图片由Lee Eason提供。 CC BY-SA 4.0

此图显示了该更改的价值。在我指导DevOps转型的公司中，其60多个团队每月提交900多个发布管理请求。如果您将这些票证保持开放的时间加起来，则每月超过350天。您的公司每月多出350个人日可以做什么？除了上面看到的改进之外，他们每月从100部署到9,000部署，高严重性漏洞，更快乐的工程师减少了24％，并提高了净发起人得分（NPS）。正如Puppet State of DevOps报告所预测的那样，最大的NPS改进与在DevOps旅程中最远的团队联系在一起。最重要的是，对技术流程改进的投资可以转化为更好的业务成果。

DevOps领导者必须专注于三个主要领域来推动这一变化：高管，文化和团队健康。

高管

最重要的是，对技术流程改进的投资可以转化为更好的业务成果。您的组织越大，业务领导力与为您的客户提供服务的个人之间的距离（以及造成误解的机会）就越大。更糟的是，技术中的工具和实践的面貌正在Swift变化。这使得业务领导者几乎不可能自己了解诸如DevOps或敏捷之类的转换是如何工作的。

例如，假设您的高管认为DevOps将改善您将产品部署到生产中的方式，但他们不知道如何。您一直在与软件团队合作，以帮助他们自动化部署。当主管听到部署失败（并且将会失败）时，他们将想了解它是如何发生的。当他们得知软件团队而不是发布管理团队进行了部署时，他们可能会尝试通过宣布所有生产版本必须经过传统的变更控制来保护业务。您将失去信誉，团队将不太可能信任您并接受进一步的更改。

与高管人员建立信任并在发生事件后获得他们的支持所需的时间要比最初对他们进行培训所花费的时间更长。将时间花在建立一致性上，这将在您实施战术变更时获得回报。

建立对齐方式时有两个建议：

首先，不要忽视他们提出的任何约束。如果他们担心合同或担保，请让法律和担保负责人成为您的新好朋友。通过与他们合作，您将建立他们的信任，并避免犯高成本的错误。其次，使用指标在交付团队的工作与高管的关注之间建立桥梁。如果企业的目标是减少客户流失，并且您从研究中知道许多客户由于计划外停机而离开，请强调您的团队致力于跟踪和改善平均检测和解决时间（MTTD和MTTR）。您可以使用这些关键指标来显示有意义的进展，团队和主管可以理解并落后。

文化

DevOps是一种持续改进的文化，专注于代码，构建，部署和操作流程。文化描述了组织的价值观和行为。本质上，我们正在谈论改变人们的行为方式，这绝非易事。

我建议阅读CIO着装中的“狼”。花时间思考心理和动机。阅读Drive或至少观看Daniel Pink出色的TED演讲。阅读《千面英雄》，学习识别每个人所经历的不同旅程。如果这些事情听起来都不有趣，那么您不是推动公司变革的合适人选。否则，请继续阅读！

本质上，我们正在谈论改变人们的行为方式，这绝非易事。大多数理性的人都按照自己的价值观行事。大多数组织没有每个人都能理解并赖以生存的明确价值观。因此，您需要确定导致导致当前状态的行为的组织价值观。您还需要确保能够讲述有关这些价值观是如何形成的以及如何将它们带到您所在的故事。当您讲这个故事时，请注意不要妖魔那些价值观，它们不是不道德或邪恶的。鉴于人们所知道的知识和拥有的资源，人们当时会尽力而为。

说明公司及其组织目标正在改变，团队必须改变其价值观。用对比来表达这一点很有帮助。例如，您的公司在历史上可能比其他方面都节省了成本。那里的价值是有原因的-公司资金短缺。为了推出新产品，基础架构组必须通过共享数据库集群或服务器来紧密耦合服务。随着时间的流逝，这些做法造成了真正的混乱，变得难以维护。简单的更改开始以意想不到的方式破坏事物。这导致了严格的变更控制流程，这对于交付团队来说是痛苦的，因此他们停止了变更。

播放那部电影五年，您最终几乎没有创新，没有继承技术，吸引和保留问题以及劣质产品。您已经发展了公司，但是已经达到了顶峰，并且您无法继续以同样的价值观和行为来成长。现在，您必须将工程效率置于节约成本之上。如果一个选择可以帮助团队更轻松地维护服务，而另一个选择在短期内更便宜，那么您选择第一个选择。

您必须一次又一次地讲这个故事。然后，您必须在任何时候通过团队的行为来表达新的价值，即使他们犯了错，也要庆祝。当团队出现部署失败时，祝贺他们承担风险并鼓励他们继续学习。解释他们的行为如何导致正确的结果并支持他们。随着时间的流逝，团队将看到消息是真实的，并且他们会安全地更改其行为。

团队健康

您是否曾经参加过计划会议，并听到过类似的信息：“直到John休假回来之前，我们才能真正估算出这个故事。他是唯一一个对代码领域足够了解的人。” 或者：“我们无法完成此任务，因为它对网络工程有跨团队的依赖，而设置防火墙的那个人病了。” 或：“约翰最了解该系统；如果他将故事估计为3，那么我们就继续做下去。” 当团队研究这个故事时，谁最有可能做这项工作？是的，约翰会的，这个周期将会继续。

长期以来，我们已经接受这仅仅是软件开发的本质。如果我们不解决问题，我们将使这一循环永存。

熵总是会自然地推动团队走向混乱和健康状况不佳。我们作为团队成员和领导者的工作是有意识地管理这种熵并保持团队健康。 DevOps，敏捷，迁移到云或重构旧版应用程序之类的转换都会放大并加速这种熵。那是因为变革为团队增加了从事新工作所需的新技能和专业知识。

熵总是会自然地推动团队走向混乱和健康状况不佳。让我们看一个产品团队重构其遗留整体的示例。和往常一样，他们在AWS中构建这些新服务。遗留的整体组件已部署到数据中心，由IT进行监视和备份。 IT确保在基础架构层满足应用程序的信息安全要求。他们进行了灾难恢复测试，为服务器打了补丁，并安装和配置了所需的入侵检测和防病毒代理。并且，他们保留了年度审核过程所需的变更控制记录，这些记录已对应用程序的基础架构进行了所有处理。

我经常看到产品团队犯了致命错误，认为IT既是成本又是瓶颈。他们渴望摆脱IT的束缚并使用公共云，但是他们永不停止欣赏IT提供的关键服务。迁移到云意味着您以不同的方式实施这些事情。他们不会消失。 AWS仍然是一个数据中心，任何使用它的团队都要承担相关的责任。

实际上，这意味着产品团队在迁移到云中时必须学习如何进行这些IT服务。因此，当我们虚构的产品团队开始重构其旧版应用程序并将新服务放入云中时，它将需要大量扩展的技能才能成功。这些技能不会神奇地出现（它们是被学习或雇用的），团队负责人和经理必须积极地管理流程。

我之所以建立Tekata.io是因为在我帮助团队发展时找不到任何支持我的工具。 Tekata是免费且易于使用的工具，但该工具并不像人员和流程那样重要。确保您将持续学习融入节奏中，并跟踪团队的弱点。这些薄弱环节会影响您的交付能力，而填补这些薄弱环节通常涉及学习新事物，因此这里有一个很好的协同作用。实际上，有76％的千禧一代认为职业发展机会是公司文化中最重要的元素之一。