devops 解决了啥问题_解决DevOps转换中最重要的问题

devops 解决了啥问题

恭喜,您已被任命为组织中的DevOps冠军。 那么,您需要解决的最重要的问题是什么?

没有! 不要荒唐:这显然是最重要的过程。 如果团队不同意站立式会议的运行方式,参加者,会议的频率和持续时间以及法定人数需要多少人,那么您将永远无法制定一致,可重复的工作方式模式。

实际上,尽管技术和过程都非常重要,但还有另一个同样重要的组成部分,但通常更难正确:文化。 是的,这是我们技术人员经常要面对的触手可及的事情。 1个

文化

几个月前,我去了一家中型政府机构(碰巧不是在英国),我们来得有点早,去见了首席执行官和首席技术官。 我们被带到首席执行官办公室,等待了一段时间,因为他们两个完成了日常的站立。 他们为迟到一两分钟而道歉,但我没有被冒犯,给我留下了深刻的印象。 在这里,一个组织的参与文化一直很明显地渗透到了高层。

并不是说文化可以从顶部强加于人 -您也不能依靠它从底部3向上渗入-但是这两个C级执行官不仅在建模他们期望从团队其他成员那里获得的行为,而且似乎之后,我们将对该过程进行简短的讨论,以对其进行真正的投资。 如果您可以让管理层投入到流程中,并被视为可以接受,那么至少您可能会与其他小组遇到问题,寻找合理的借口以保持距离并逃之get。

因此,让我们假设管理层认为您应该尝试一下DevOps。 你从哪里开始?

开发人员,打勾? 5

开发人员很可能是您最简单的目标群体。 他们通常热衷于尝试新事物并找到加快事物发展的方法,因此经常可以期望他们采用新技术和方法。 可以说DevOps主要是由开发社区驱动的。

但是,您不应该假设所有开发人员都热衷于接受此更改。 对于某些人来说,事情总是可以完成的-您的开发人员Rick Parfitts,如果您愿意的话-7 。 寻找帮助他们在新世界中高效工作的方法是您工作的一部分,而不仅仅是他们的工作。 如果您有对变革不满意的超级巨星开发人员,则当您试图迫使他们进入勇敢的新世界时,您就有可能疏远和失去他们。 更糟糕的是,如果他们不知所措,那么当他们向经理们解释说如果情况变得更加艰难并降低生产率的情况不会改变的话,您冒险采用DevSecOps的愿景就会受到威胁。

也许您将无法立即将所有系统和人员转移到DevOps。 也许您需要选择以哪些应用程序开头,谁将成为您的第一个DevOps冠军。 也许是时候慢慢行动了。

也许不是:绝对

不,我撒了谎。 您肯定需要缓慢移动。 试图一次改变一切都是灾难的根源。

这适用于变更的所有要素,包括要选择的人员,要选择的技术,要选择的应用程序,要选择的用户群,要选择的用例。 对于这些元素,如果您尝试一次移动所有内容,则会失败。 您会因为多种原因而失败。 您将因我无法想象的原因而失败,更重要的是,由于您无法想象的原因而失败。 但是一些原因将包括:

  • 人们-大多数人-不喜欢改变。
  • 技术不喜欢变化(您不能只是切换而期望一切仍然有效)。
  • 应用程序不喜欢更改(事情以前曾经起作用,或者至少以已知方式失败了)。 您想一口气改变一切吗? 好吧,它们都会以新颖而令人兴奋的9种方式失败。
  • 用户不喜欢更改。
  • 用例不喜欢更改。

一个例外

您在讨论不应一口气更改哪些元素时注意到了我写的“ bar bar”? 做得好。

那是什么例外? 这是最初的团队。 当您选择要更改的初始应用程序并且正在考虑选择进行更改的团队时,请仔细选择成员并选择完整的集合。 这个很重要。 如果您只选择开发人员,仅测试人员,仅安全人员,ops人员,或管理人员(如果从列表中删除一个功能组,则根本不会证明任何事情)。 好吧,您可能已经向社区中的一小部分人证明了这种方法是可行的,但是您会错过一些窍门。 诀窍是:如果您从各个职能部门中选择敏锐的人员,那么失败就很难了。

假设您的第一次尝试非常出色。 您将如何说服其他人复制您的成功并采用DevOps? 好吧,公司通讯,当然。 那将说服到底有多少人? 是的,那个号码。 12另一方面,如果您有来自各个职能部门或组织的团队成员,那么当您成功时,他们会告诉他们的同事,下次您会得到更多支持。

如果失败了,那么如果您明智地选择了您的团队(如果他们都很热情,并且知道“经常失败,请快速失败”是件好事),他们将准备再次出发。

因此,您需要从各个职能部门中选择发烧友。 他们可以研究技术和过程,一旦工作,将由人们来创造这种文化变革。 你可以坐下来享受。 当然,直到下一次危机。


1.好,你是对的。 应该是“我们的技术人员倾向于与之斗争”。 2

2.你以为我要对那些挣扎于易学易用的东西的技术人员有所保留,不是吗? 再读一遍:我说“倾向于”。 那是你得到的最好的。

3.渗透自下而上的过程吗? 我不喝咖啡, 4所以我不知道。

4.人们甚至还会使用渗滤器来煮咖啡吗? 请随时在评论中让我知道。 如果您幸运的话,我可能会装出兴趣。

5.对于美国读者(也许还有其他一些国家/地区),请在此处用“对勾”代替“对勾”。 6

6.对于美国的技术读者,请随时执行s/tick/check/;

7.这是Status Quo 8参考,对此非常抱歉。

8.对于千禧一代的读者,请咨询您喜欢的在线参考引擎,或者只是睁大眼睛继续前进。

9.对于那些说“但我喜欢激动”的人,请尝试在本季度末的周日凌晨2点致电您,当您的首席财务官打电话给您询问为什么上个月的所有销售数据都已损坏时并带有字母“ DEADBEEF”。 10

10.对于不认识的人,这是技术人员经常用作测试数据的字符串,因为a)非数字; b)是数字(十六进制); c)在调试文件中搜索很容易; d)这很有趣。 11

11.虽然看到。 9

12.我要说的只是一个低数字。

本文最初出现在安全博客Alice,Eve和Bob上 ,经许可重新发布。

翻译自: https://opensource.com/article/18/2/most-important-issue-devops-transformation

devops 解决了啥问题

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值