mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-26 21:30:55 +08:00
126 lines
10 KiB
Markdown
126 lines
10 KiB
Markdown
DevOps 时代的 7 个领导力准则
|
||
======
|
||
|
||
> DevOps 是一种持续性的改变和提高：那么也准备改变你所珍视的领导力准则吧。
|
||
|
||
|
||
|
||
如果 [DevOps] 最终更多的是一种文化而非某种技术或者平台，那么请记住：它没有终点线。而是一种持续性的改变和提高——而且最高管理层并不及格。
|
||
|
||
然而，如果期望 DevOps 能够帮助获得更多的成果，领导者需要[修订他们的一些传统的方法][2]。让我们考虑 7 个在 DevOps 时代更有效的 IT 领导的想法。
|
||
|
||
### 1、 向失败说“是的”
|
||
|
||
“失败”这个词在 IT 领域中一直包含着非常具体的意义，而且通常是糟糕的意思：服务器失败、备份失败、硬盘驱动器失败——你的印象就是如此。
|
||
|
||
然而一个健康的 DevOps 文化取决于如何重新定义失败——IT 领导者应该在他们的字典里重新定义这个单词，使这个词的含义和“机会”对等起来。
|
||
|
||
“在 DevOps 之前，我们曾有一种惩罚失败者的文化，”[Datical][3] 的首席技术官兼联合创始人罗伯特·里夫斯说，“我们学到的仅仅是去避免错误。在 IT 领域避免错误的首要措施就是不要去改变任何东西：不要加速版本迭代的日程，不要迁移到云中，不要去做任何不同的事”
|
||
|
||
那是一个旧时代的剧本，里夫斯坦诚的说，它已经不起作用了，事实上，那种停滞实际上是失败。
|
||
|
||
“那些缓慢的发布周期并逃避云的公司被恐惧所麻痹——他们将会走向失败，”里夫斯说道。“IT 领导者必须拥抱失败，并把它当做成一个机遇。人们不仅仅从他们的过错中学习，也会从别人的错误中学习。开放和[安全心理][4]的文化促进学习和提高。”
|
||
|
||
**[相关文章：[为什么敏捷领导者谈论“失败”必须超越它本义][5]]**
|
||
|
||
### 2、 在管理层渗透开发运营的理念
|
||
|
||
尽管 DevOps 文化可以在各个方向有机的发展，那些正在从单体、孤立的 IT 实践中转变出来的公司，以及可能遭遇逆风的公司——需要高管层的全面支持。如果缺少了它，你就会传达模糊的信息，而且可能会鼓励那些宁愿被推着走的人，但这是我们一贯的做事方式。[改变文化是困难的][6]；人们需要看到高管层完全投入进去并且知道改变已经实际发生了。
|
||
|
||
“高层管理必须全力支持 DevOps，才能成功的实现收益”，来自 [Rainforest QA][7] 的首席信息官德里克·蔡说道。
|
||
|
||
成为一个 DevOps 商店。德里克指出，涉及到公司的一切，从技术团队到工具到进程到规则和责任。
|
||
|
||
“没有高层管理的统一赞助支持，DevOps 的实施将很难成功，”德里克说道，“因此，在转变到 DevOps 之前在高层中保持一致是很重要的。”
|
||
|
||
### 3、 不要只是声明 “DevOps”——要明确它
|
||
|
||
即使 IT 公司也已经开始张开双臂拥抱 DevOps，也可能不是每个人都在同一个步调上。
|
||
|
||
**[参考我们的相关文章，[3 阐明了DevOps和首席技术官们必须在同一进程上][8]]**
|
||
|
||
造成这种脱节的一个根本原因是：人们对这个术语的有着不同的定义理解。
|
||
|
||
“DevOps 对不同的人可能意味着不同的含义，”德里克解释道，“对高管层和副总裁层来说，要执行明确的 DevOps 的目标，清楚地声明期望的成果，充分理解带来的成果将如何使公司的商业受益，并且能够衡量和报告成功的过程。”
|
||
|
||
事实上，在基线定义和远景之外，DevOps 要求正在进行频繁的交流，不是仅仅在小团队里，而是要贯穿到整个组织。IT 领导者必须将它设置为优先。
|
||
|
||
“不可避免的，将会有些阻碍，在商业中将会存在失败和破坏，”德里克说道，“领导者们需要清楚的将这个过程向公司的其他人阐述清楚，告诉他们他们作为这个过程的一份子能够期待的结果。”
|
||
|
||
### 4、 DevOps 对于商业和技术同样重要
|
||
|
||
IT 领导者们成功的将 DevOps 商店的这种文化和实践当做一项商业策略，以及构建和运营软件的方法。DevOps 是将 IT 从支持部门转向战略部门的推动力。
|
||
|
||
IT 领导者们必须转变他们的思想和方法，从成本和服务中心转变到驱动商业成果，而且 DevOps 的文化能够通过自动化和强大的协作加速这些成果，来自 [CYBRIC][9] 的首席技术官和联合创始人迈克·凯尔说道。
|
||
|
||
事实上，这是一个强烈的趋势，贯穿这些新“规则”，在 DevOps 时代走在前沿。
|
||
|
||
“促进创新并且鼓励团队成员去聪明的冒险是 DevOps 文化的一个关键部分，IT 领导者们需要在一个持续的基础上清楚的和他们交流”，凯尔说道。
|
||
|
||
“一个高效的 IT 领导者需要比以往任何时候都要积极的参与到业务中去，”来自 [West Monroe Partners][10] 的性能服务部门的主任埃文说道，“每年或季度回顾的日子一去不复返了——[你需要欢迎每两周一次的挤压整理][11]，你需要有在年度水平上的思考战略能力，在冲刺阶段的互动能力，在商业期望满足时将会被给予一定的奖励。”
|
||
|
||
### 5、 改变妨碍 DevOps 目标的任何事情
|
||
|
||
虽然 DevOps 的老兵们普遍认为 DevOps 更多的是一种文化而不是技术，成功取决于通过正确的过程和工具激活文化。当你声称自己的部门是一个 DevOps 商店却拒绝对进程或技术做必要的改变，这就是你买了辆法拉利却使用了用了 20 年的引擎，每次转动钥匙都会冒烟。
|
||
|
||
展览 A： [自动化][12]。这是 DevOps 成功的重要并行策略。
|
||
|
||
“IT 领导者需要重点强调自动化，”卡伦德说，“这将是 DevOps 的前期投资，但是如果没有它，DevOps 将会很容易被低效吞噬，而且将会无法完整交付。”
|
||
|
||
自动化是基石，但改变不止于此。
|
||
|
||
“领导者们需要推动自动化、监控和持续交付过程。这意着对现有的实践、过程、团队架构以及规则的很多改变，” 德里克说。“领导者们需要改变一切会阻碍团队去实现完全自动化的因素。”
|
||
|
||
### 6、 重新思考团队架构和能力指标
|
||
|
||
当你想改变时……如果你桌面上的组织结构图和你过去大部分时候嵌入的名字都是一样的，那么你是时候该考虑改革了。
|
||
|
||
“在这个 DevOps 的新时代文化中，IT 执行者需要采取一个全新的方法来组织架构。”凯尔说，“消除组织的边界限制，它会阻碍团队间的合作，允许团队自我组织、敏捷管理。”
|
||
|
||
凯尔告诉我们在 DevOps 时代，这种反思也应该拓展应用到其他领域，包括你怎样衡量个人或者团队的成功，甚至是你和人们的互动。
|
||
|
||
“根据业务成果和总体的积极影响来衡量主动性，”凯尔建议。“最后，我认为管理中最重要的一个方面是：有同理心。”
|
||
|
||
注意很容易收集的到测量值不是 DevOps 真正的指标，[Red Hat] 的技术专家戈登·哈夫写到，“DevOps 应该把指标以某种形式和商业成果绑定在一起”，他指出，“你可能并不真正在乎开发者些了多少代码，是否有一台服务器在深夜硬件损坏，或者是你的测试是多么的全面。你甚至都不直接关注你的网站的响应情况或者是你更新的速度。但是你要注意的是这些指标可能和顾客放弃购物车去竞争对手那里有关，”参考他的文章，[DevOps 指标：你在测量什么？]
|
||
|
||
### 7、 丢弃传统的智慧
|
||
|
||
如果 DevOps 时代要求关于 IT 领导能力的新的思考方式，那么也就意味着一些旧的方法要被淘汰。但是是哪些呢？
|
||
|
||
“说实话，是全部”，凯尔说道，“要摆脱‘因为我们一直都是以这种方法做事的’的心态。过渡到 DevOps 文化是一种彻底的思维模式的转变，不是对瀑布式的过去和变革委员会的一些细微改变。”
|
||
|
||
事实上，IT 领导者们认识到真正的变革要求的不只是对旧方法的小小接触。它更多的是要求对之前的进程或者策略的一个重新启动。
|
||
|
||
West Monroe Partners 的卡伦德分享了一个阻碍 DevOps 的领导力的例子：未能拥抱 IT 混合模型和现代的基础架构比如说容器和微服务。
|
||
|
||
“我所看到的一个大的规则就是架构整合，或者认为在一个同质的环境下长期的维护会更便宜，”卡伦德说。
|
||
|
||
**领导者们，想要更多像这样的智慧吗？[注册我们的每周邮件新闻报道][15]。**
|
||
|
||
--------------------------------------------------------------------------------
|
||
|
||
via: https://enterprisersproject.com/article/2018/1/7-leadership-rules-devops-age
|
||
|
||
作者：[Kevin Casey][a]
|
||
译者：[FelixYFZ](https://github.com/FelixYFZ)
|
||
校对：[wxy](https://github.com/wxy)
|
||
|
||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||
|
||
[a]:https://enterprisersproject.com/user/kevin-casey
|
||
[1]:https://enterprisersproject.com/tags/devops
|
||
[2]:https://enterprisersproject.com/article/2017/7/devops-requires-dumping-old-it-leadership-ideas
|
||
[3]:https://www.datical.com/
|
||
[4]:https://rework.withgoogle.com/guides/understanding-team-effectiveness/steps/foster-psychological-safety/
|
||
[5]:https://enterprisersproject.com/article/2017/10/why-agile-leaders-must-move-beyond-talking-about-failure?sc_cid=70160000000h0aXAAQ
|
||
[6]:https://enterprisersproject.com/article/2017/10/how-beat-fear-and-loathing-it-change
|
||
[7]:https://www.rainforestqa.com/
|
||
[8]:https://enterprisersproject.com/article/2018/1/3-areas-where-devops-and-cios-must-get-same-page
|
||
[9]:https://www.cybric.io/
|
||
[10]:http://www.westmonroepartners.com/
|
||
[11]:https://www.scrumalliance.org/community/articles/2017/february/product-backlog-grooming
|
||
[12]:https://www.redhat.com/en/topics/automation?intcmp=701f2000000tjyaAAA
|
||
[13]:https://www.redhat.com/en?intcmp=701f2000000tjyaAAA
|
||
[14]:https://enterprisersproject.com/article/2017/7/devops-metrics-are-you-measuring-what-matters
|
||
[15]:https://enterprisersproject.com/email-newsletter?intcmp=701f2000000tsjPAAQ
|