mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-19 22:51:41 +08:00
120 lines
9.7 KiB
Markdown
120 lines
9.7 KiB
Markdown
DevOps时代的7个领导准则
|
||
======
|
||
|
||
|
||
|
||
如果[DevOps]最终更多的是关于文化而不是任何其他的技术或者平台，那么请记住：没有终点线。而是继续改变和提高--而且最高管理层并没有通过。
|
||
|
||
然而，如果期望DevOps能够帮助获得更多的成果，领导者需要[修订他们的一些传统的方法][2]让我们考虑7个在DevOps时代更有效的IT领导的想法。
|
||
|
||
### 1. 向失败说“是的”
|
||
|
||
“失败”这个词在IT领域中一直包含着特殊的内涵，而且通常是糟糕的意思：服务器失败，备份失败，硬盘驱动器失败-你得了解这些情况。
|
||
|
||
然而一种健康的DevOps文化取决于重新定义失败-IT领导者在他们的字典里应该重新定义这个单词将它的含义和“机会”对等起来。
|
||
|
||
“在DevOps之前，我们曾有一种惩罚失败者的文化，”罗伯特·里夫斯说,[Datical][3]的首席技术官兼联合创始人。“我们学到的仅仅是去避免错误。在IT领域避免错误的首要措施就是不要去改变任何东西：不要加速版本迭代的日程，不要迁移到云中，不要去做任何不同的事”
|
||
|
||
那是过去的一个时代的剧本，里夫斯坦诚的说，它已经不起作用了，事实上，那种停滞是失败的。
|
||
|
||
“那些缓慢的释放并逃避云的公司被恐惧所麻痹-他们将会走向失败，”里夫斯说道。“IT领导者必须拥抱失败并把它当做成一个机遇。人们不仅仅从他们的过错中学习，也会从其他的错误中学习。一种开放和[安全心里][4]的文化促进学习和提高”
|
||
**[相关文章：[为什么敏捷领导者谈论“失败”必须超越它本义]]
|
||
### 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将会很容易被低效吞噬自己而且将会无法完整交付。”
|
||
|
||
自动化是基石，但改变不止于此。
|
||
|
||
“领导者们需要推动自动化，监控和持续的交付过程。这意着对现有的实践，过程，团队架构以及规则的很多改变，”Choy说。“领导者们需要改变一切会阻碍隐藏团队去全利实现自动化的因素。”
|
||
|
||
### 6. 重新思考团队架构和能力指标
|
||
|
||
当你想改变时...如果你桌面上的组织结构图和你过去大部分时候嵌入的名字都是一样的，那么你是时候该考虑改革了。
|
||
|
||
“在这个DevOps的新时代文化中，IT执行者需要采取一个全新的方法来组织架构。”Kail说。“消除组织的边界限制，它会阻碍团队间的合作，允许团队自我组织，敏捷管理。”
|
||
|
||
Kail告诉我们在DevOps时代，这种反思也应该拓展应用到其他领域，包括你怎样衡量个人或者团队的成功，甚至是你和人们的互动。
|
||
|
||
“根据业务成果和总体的积极影响来衡量主动性，”Kail建议。“最后，我认为管理中最重要的一个方面是：有同理心。”
|
||
|
||
注意很容易收集的到测量值不是DevOps真正的指标，[Red Hat]的技术专员Gardon Half写到，“DevOps应该把指标以某种形式和商业成果绑定在一起，”他指出。“你可能真的不在乎开发者些了多少代码，是否有一台服务器在深夜硬件损坏，或者是你的测试是多么的全面。你甚至都不直接关注你的网站的响应情况或者是你更新的速度。但是你要注意的是这些指标可能和顾客放弃购物车去竞争对手那里有关，”参考他的文章，[DevOps 指标：你在测量什么？]
|
||
|
||
### 7. 丢弃传统的智慧
|
||
|
||
如果DevOps时代要求关于IT领导能力的新的思考方式，那么也就意味着一些旧的方法要被淘汰。但是是哪些呢？
|
||
|
||
“是实话，是全部，”Kail说道。“要摆脱‘因为我们一直都是以这种方法做事的’的心态。过渡到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)
|
||
校对：[校对者ID](https://github.com/校对者ID)
|
||
|
||
本文由 [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
|