mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-13 22:30:37 +08:00
Merge pull request #10869 from HankChow/master
翻译完成 20181008 3 areas to drive DevOps change.md
This commit is contained in:
Xingyu.Wang
GitHub
commit
24ee404ca2
@ -1,110 +0,0 @@
|
||||
HankChow translating
|
||||
|
||||
3 areas to drive DevOps change
|
||||
======
|
||||
Driving large-scale organizational change is painful, but when it comes to DevOps, the payoff is worth the pain.
|
||||
|
||||
|
||||
Pain avoidance is a powerful motivator. Some studies hint that even [plants experience a type of pain][1] and take steps to defend themselves. Yet we have plenty of examples of humans enduring pain on purpose—exercise often hurts, but we still do it. When we believe the payoff is worth the pain, we'll endure almost anything.
|
||||
|
||||
The truth is that driving large-scale organizational change is painful. It hurts for those having to change their values and behaviors, it hurts for leadership, and it hurts for the people just trying to do their jobs. In the case of DevOps, though, I can tell you the pain is worth it.
|
||||
|
||||
I've seen firsthand how teams learn they must spend time improving their technical processes, take ownership of their automation pipelines, and become masters of their fate. They gain the tools they need to be successful.
|
||||
|
||||
![Improvements after DevOps transformation][3]
|
||||
|
||||
Image by Lee Eason. CC BY-SA 4.0
|
||||
|
||||
This chart shows the value of that change. In a company where I directed a DevOps transformation, its 60+ teams submitted more than 900 requests per month to release management. If you add up the time those tickets stayed open, it came to more than 350 days per month. What could your company do with an extra 350 person-days per month? In addition to the improvements seen above, they went from 100 to 9,000 deployments per month, a 24% decrease in high-severity bugs, happier engineers, and improved net promoter scores (NPS). The biggest NPS improvements link to the teams furthest along on their DevOps journey, as the [Puppet State of DevOps][4] report predicted. The bottom line is that investments into technical process improvement translate into better business outcomes.
|
||||
|
||||
DevOps leaders must focus on three main areas to drive this change: executives, culture, and team health.
|
||||
|
||||
### Executives
|
||||
|
||||
The bottom line is that investments into technical process improvement translate into better business outcomes.
|
||||
|
||||
The larger your organization, the greater the distance (and opportunities for misunderstanding) between business leadership and the individuals delivering services to your customers. To make things worse, the landscape of tools and practices in technology is changing at an accelerating rate. This makes it practically impossible for business leaders to understand on their own how transformations like DevOps or agile work.
|
||||
|
||||
The larger your organization, the greater the distance (and opportunities for misunderstanding) between business leadership and the individuals delivering services to your customers. To make things worse, the landscape of tools and practices in technology is changing at an accelerating rate. This makes it practically impossible for business leaders to understand on their own how transformations like DevOps or agile work.
|
||||
|
||||
DevOps leaders must help executives come along for the ride. Educating leaders gives them options when they're making decisions and makes it more likely they'll choose paths that help your company.
|
||||
|
||||
For example, let's say your executives believe DevOps is going to improve how you deploy your products into production, but they don't understand how. You've been working with a software team to help automate their deployment. When an executive hears about a deploy failure (and there will be failures), they will want to understand how it occurred. When they learn the software team did the deployment rather than the release management team, they may try to protect the business by decreeing all production releases must go through traditional change controls. You will lose credibility, and teams will be far less likely to trust you and accept further changes.
|
||||
|
||||
It takes longer to rebuild trust with executives and get their support after an incident than it would have taken to educate them in the first place. Put the time in upfront to build alignment, and it will pay off as you implement tactical changes.
|
||||
|
||||
Two pieces of advice when building that alignment:
|
||||
|
||||
* First, **don't ignore any constraints** they raise. If they have worries about contracts or security, make the heads of legal and security your new best friends. By partnering with them, you'll build their trust and avoid making costly mistakes.
|
||||
* Second, **use metrics to build a bridge** between what your delivery teams are doing and your executives' concerns. If the business has a goal to reduce customer churn, and you know from research that many customers leave because of unplanned downtime, reinforce that your teams are committed to tracking and improving Mean Time To Detection and Resolution (MTTD and MTTR). You can use those key metrics to show meaningful progress that teams and executives understand and get behind.
|
||||
|
||||
|
||||
|
||||
### Culture
|
||||
|
||||
DevOps is a culture of continuous improvement focused on code, build, deploy, and operational processes. Culture describes the organization's values and behaviors. Essentially, we're talking about changing how people behave, which is never easy.
|
||||
|
||||
I recommend reading [The Wolf in CIO's Clothing][5]. Spend time thinking about psychology and motivation. Read [Drive][6] or at least watch Daniel Pink's excellent [TED Talk][7]. Read [The Hero with a Thousand Faces][8] and learn to identify the different journeys everyone is on. If none of these things sound interesting, you are not the right person to drive change in your company. Otherwise, read on!
|
||||
|
||||
Essentially, we're talking about changing how people behave, which is never easy.
|
||||
|
||||
Most rational people behave according to their values. Most organizations don't have explicit values everyone understands and lives by. Therefore, you'll need to identify the organization's values that have led to the behaviors that have led to the current state. You also need to make sure you can tell the story about how those values came to be and how they led to where you are. When you tell that story, be careful not to demonize those values—they aren't immoral or evil. People did the best they could at the time, given what they knew and what resources they had.
|
||||
|
||||
Most rational people behave according to their values. Most organizations don't have explicit values everyone understands and lives by. Therefore, you'll need to identify the organization's values that have led to the behaviors that have led to the current state. You also need to make sure you can tell the story about how those values came to be and how they led to where you are. When you tell that story, be careful not to demonize those values—they aren't immoral or evil. People did the best they could at the time, given what they knew and what resources they had.
|
||||
|
||||
Explain that the company and its organizational goals are changing, and the team must alter its values. It's helpful to express this in terms of contrast. For example, your company may have historically valued cost savings above all else. That value is there for a reason—the company was cash-strapped. To get new products out, the infrastructure group had to tightly couple services by sharing database clusters or servers. Over time, those practices created a real mess that became hard to maintain. Simple changes started breaking things in unexpected ways. This led to tight change-control processes that were painful for delivery teams, so they stopped changing things.
|
||||
|
||||
Play that movie for five years, and you end up with little to no innovation, legacy technology, attraction and retention problems, and poor-quality products. You've grown the company, but you've hit a ceiling, and you can't continue to grow with those same values and behaviors. Now you must put engineering efficiency above cost saving. If one option will help teams maintain their service easier, but the other option is cheaper in the short term, you go with the first option.
|
||||
|
||||
You must tell this story again and again. Then you must celebrate any time a team expresses the new value through their behavior—even if they make a mistake. When a team has a deploy failure, congratulate them for taking the risk and encourage them to keep learning. Explain how their behavior is leading to the right outcome and support them. Over time, teams will see the message is real, and they'll feel safe altering their behavior.
|
||||
|
||||
### Team health
|
||||
|
||||
Have you ever been in a planning meeting and heard something like this: "We can't really estimate that story until John gets back from vacation. He's the only one who knows that area of the code well enough." Or: "We can't get this task done because it's got a cross-team dependency on network engineering, and the guy that set up the firewall is out sick." Or: "John knows that system best; if he estimated the story at a 3, then let's just go with that." When the team works on that story, who will most likely do the work? That's right, John will, and the cycle will continue.
|
||||
|
||||
For a long time, we've accepted that this is just the nature of software development. If we don't solve for it, we perpetuate the cycle.
|
||||
|
||||
Entropy will always drive teams naturally towards disorder and bad health. Our job as team members and leaders is to intentionally manage against that entropy and keep our teams healthy. Transformations like DevOps, agile, moving to the cloud, or refactoring a legacy application all amplify and accelerate that entropy. That's because transformations add new skills and expertise needed for the team to take on that new type of work.
|
||||
|
||||
Let's look at an example of a product team refactoring its legacy monolith. As usual, they build those new services in AWS. The legacy monolith was deployed to the data center, monitored, and backed up by IT. IT made sure the application's infosec requirements were met at the infrastructure layer. They conducted disaster recovery tests, patched the servers, and installed and configured required intrusion detection and antivirus agents. And they kept change control records, required for the annual audit process, of everything was done to the application's infrastructure.
|
||||
|
||||
I often see product teams make the fatal mistake of thinking IT is all cost and bottleneck. They're hungry to shed the skin of IT and use the public cloud, but they never stop to appreciate the critical services IT provides. Moving to the cloud means you implement these things differently; they don't go away. AWS is still a data center, and any team utilizing it accepts the related responsibilities.
|
||||
|
||||
In practice, this means product teams must learn how to do those IT services when they move to the cloud. So, when our fictional product team starts refactoring its legacy application and putting new services in in the cloud, it will need a vastly expanded skillset to be successful. Those skills don't magically appear—they're learned or hired—and team leaders and managers must actively manage the process.
|
||||
|
||||
I built [Tekata.io][9] because I couldn't find any tools to support me as I helped my teams evolve. Tekata is free and easy to use, but the tool is not as important as the people and process. Make sure you build continuous learning into your cadence and keep track of your team's weak spots. Those weak spots affect your ability to deliver, and filling them usually involves learning new things, so there's a wonderful synergy here. In fact, 76% of millennials think professional development opportunities are [one of the most important elements][10] of company culture.
|
||||
|
||||
### Proof is in the payoff
|
||||
|
||||
DevOps transformations involve altering the behavior, and therefore the culture, of your teams. That must be done with executive support and understanding. At the same time, those behavior changes mean learning new skills, and that process must also be managed carefully. But the payoff for pulling this off is more productive teams, happier and more engaged team members, higher quality products, and happier customers.
|
||||
|
||||
Lee Eason will present [Tales From A DevOps Transformation][11] at [All Things Open][12], October 21-23 in Raleigh, N.C.
|
||||
|
||||
Disclaimer: All opinions are statements in this article are exclusively those of Lee Eason and are not representative of Ipreo or IHS Markit.
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/18/10/tales-devops-transformation
|
||||
|
||||
作者：[Lee Eason][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/leeeason
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://link.springer.com/article/10.1007%2Fs00442-014-2995-6
|
||||
[2]: /file/411061
|
||||
[3]: https://opensource.com/sites/default/files/uploads/devops-delays.png (Improvements after DevOps transformation)
|
||||
[4]: https://puppet.com/resources/whitepaper/state-of-devops-report
|
||||
[5]: https://www.gartner.com/en/publications/wolf-cio
|
||||
[6]: https://en.wikipedia.org/wiki/Drive:_The_Surprising_Truth_About_What_Motivates_Us
|
||||
[7]: https://www.ted.com/talks/dan_pink_on_motivation?language=en#t-2094
|
||||
[8]: https://en.wikipedia.org/wiki/The_Hero_with_a_Thousand_Faces
|
||||
[9]: https://tekata.io/
|
||||
[10]: https://www.execu-search.com/~/media/Resources/pdf/2017_Hiring_Outlook_eBook
|
||||
[11]: https://allthingsopen.org/talk/tales-from-a-devops-transformation/
|
||||
[12]: https://allthingsopen.org/
|
||||
99
translated/talk/20181008 3 areas to drive DevOps change.md
Normal file
99
translated/talk/20181008 3 areas to drive DevOps change.md
Normal file
@ -0,0 +1,99 @@
|
||||
推动 DevOps 变革的三个方面
|
||||
======
|
||||
推动大规模的组织变革是一个痛苦的过程。对于 DevOps 来说，尽管也有阵痛，但变革带来的价值则相当可观。
|
||||
|
||||
|
||||
|
||||
避免痛苦是一种强大的动力。一些研究表明，[植物也会通过遭受疼痛的过程][1]以采取措施来保护自己。我们人类有时也会刻意让自己受苦——在剧烈运动之后，身体可能会发生酸痛，但我们仍然坚持运动。那是因为当人认为整个过程利大于弊时，几乎可以忍受任何事情。
|
||||
|
||||
推动大规模的组织变革得过程确实是痛苦的。有人可能会因难以改变价值观和行为而感到痛苦，有人可能会因难以带领团队而感到痛苦，也有人可能会因难以开展工作而感到痛苦。但就 DevOps 而言，我可以说这些痛苦都是值得的。
|
||||
|
||||
我也曾经关注过一个团队耗费大量时间优化技术流程的过程，在这个过程中，团队逐渐将流程进行自动化改造，并最终获得了成功。
|
||||
|
||||
![Improvements after DevOps transformation][3]
|
||||
|
||||
图片来源：Lee Eason. CC BY-SA 4.0
|
||||
|
||||
这张图表充分表明了变革的价值。一家公司在我主导实行了 DevOps 转型之后，60 多个团队每月提交了超过 900 个发布请求。这些工作量的原耗时高达每个月 350 天，而这么多的工作量对于任何公司来说都是不可忽视的。除此以外，他们每月的部署次数从 100 次增加到了 9000 次，高危 bug 减少了 24%，工程师们更轻松了，<ruby>净推荐值<rt>Net Promoter Score</rt></ruby>（NPS）也提高了，而 NPS 提高反过来也让团队的 DevOps 转型更加顺利。正如 [Puppet 发布的 DevOps 报告][4]所预测的，用在技术流程改进上的投资可以在业务成果上明显地体现出来。
|
||||
|
||||
而 DevOps 主导者在推动变革是必须关注这三个方面：团队管理，团队文化和团队活力。
|
||||
|
||||
### 团队管理
|
||||
|
||||
组织架构越大，业务领导与一线员工之间的距离就会越大，当然发生误解的可能性也会越大。而且各种技术工具和实际应用都在以日新月异的速度变化，这就导致业务领导几乎不可能对 DevOps 或敏捷开发的转型方向有一个亲身的了解。
|
||||
|
||||
DevOps 主导者必须和管理层密切合作，在进行决策的时候给出相关的意见，以帮助他们做出正确的决策。
|
||||
|
||||
公司的管理层只是知道 DevOps 会对产品部署的方式进行改进，而并不了解其中的具体过程。当管理层发现你在和软件团队执行自动化部署失败时，就会想要了解这件事情的细节。如果管理层了解到进行部署的是软件团队而不是专门的发布管理团队，就可能会坚持使用传统的变更流程来保证业务的正常运作。你可能会失去团队的信任，团队也可能不愿意作出进一步的改变。
|
||||
|
||||
如果没有和管理层做好心理上的预期，一旦发生意外的生产事件，都会对你和管理层之间的信任造成难以消除的影响。所以，最好事先和管理层之间在各方面协调好，这会让你在后续的工作中避免很多麻烦。
|
||||
|
||||
对于和管理层之间的协调，这里有两条建议：
|
||||
|
||||
* 一是**重视所有规章制度**。如果管理层对合同、安全等各方面有任何疑问，你都可以向法务或安全负责人咨询，这样做可以避免犯下后果严重的错误。
|
||||
* 二是**将管理层的重点关注的方面输出为量化指标**。举个例子，如果公司的目标是减少客户流失，而你调查得出计划外的停机是造成客户流失的主要原因，那么就可以让团队对故障的<ruby>平均检测时间<rt>Mean Time To Detection</rt></ruby>（MTTD）和<ruby>平均解决时间<rt>Mean Time To Resolution</rt></ruby>（MTTR）实行重点优化。你可以使用这些关键指标来量化团队的工作成果，而管理层对此也可以有一个直观的了解。
|
||||
|
||||
|
||||
|
||||
### 团队文化
|
||||
|
||||
DevOps 是一种专注于持续改进代码、构建、部署和操作流程的文化，而团队文化代表了团队的价值观和行为。从本质上说，团队文化是要塑造团队成员的行为方式，而这并不是一件容易的事。
|
||||
|
||||
我推荐一本叫做《[披着狼皮的 CIO][5]》的书。另外，研究心理学、阅读《[Drive][6]》、观看 Daniel Pink 的 [TED 演讲][7]、阅读《[千面英雄][7]》、了解每个人的心路历程，以上这些都是你推动公司技术变革所应该尝试去做的事情。
|
||||
|
||||
理性的人大多都按照自己的价值观工作，然而团队通常没有让每个人都能达成共识的明确价值观。因此，你需要明确团队目前的价值观，包括价值观的形成过程和价值观的目标导向。也不能将这些价值观强加到团队成员身上，只需要让团队成员在目前的硬件条件下力所能及地做到最好就可以了
|
||||
|
||||
同时需要向团队成员阐明，公司正在发生组织上的变化，团队的价值观也随之改变，最好也厘清整个过程中将会作出什么变化。例如，公司以往或许是由于资金有限，一直将节约成本的原则放在首位，在研发新产品的时候，基础架构团队不得不通过共享数据库集群或服务器，从而导致了服务之间的紧密耦合。然而随着时间的推移，这种做法会产生难以维护的混乱，即使是一个小小的变化也可能造成无法预料的后果。这就导致交付团队难以执行变更控制流程，进而令变更停滞不前。
|
||||
|
||||
如果这种状况持续多年，最终的结果将会是毫无创新、技术老旧、问题繁多以及产品品质低下，公司的发展到达了瓶颈，原本的价值观已经不再适用。所以，工作效率的优先级必须高于节约成本。
|
||||
|
||||
你必须强调团队的价值观。每当团队按照价值观取得了一定的工作进展，都应该对团队作出激励。在团队部署出现失败时，鼓励他们承担风险、继续学习，同时指导团队如何改进他们的工作并表示支持。长此下来，团队成员就会对你产生信任，并逐渐切合团队的价值观。
|
||||
|
||||
### 团队活力
|
||||
|
||||
你有没有在会议上听过类似这样的话？“在张三度假回来之前，我们无法对这件事情做出评估。他是唯一一个了解代码的人”，或者是“我们完成不了这项任务，它在网络上需要跨团队合作，而防火墙管理员刚好请病假了”，又或者是“张三最清楚这个系统最好，他说是怎么样，通常就是怎么样”。那么如果团队在处理工作时，谁才是主力？就是张三。而且也一直会是他。
|
||||
|
||||
我们一直都认为这就是软件开发的本质。但是如果我们不作出改变，这种循环就会一直保持下去。
|
||||
|
||||
熵的存在会让团队自发地变得混乱和缺乏活力，团队的成员和主导者的都有责任控制这个熵并保持团队的活力。DevOps、敏捷开发、上云、代码重构这些行为都会令熵增加速，这是因为转型让团队需要学习更多新技能和专业知识以开展新工作。
|
||||
|
||||
我们来看一个产品团队重构遗留代码的例子。像往常一样，他们在 AWS 上构建新的服务。而传统的系统则在数据中心部署，并由 IT 部门进行监控和备份。IT 部门会确保在基础架构的层面上满足应用的安全需求、进行灾难恢复测试、系统补丁、安装配置了入侵检测和防病毒代理，而且 IT 部门还保留了年度审计流程所需的变更控制记录。
|
||||
|
||||
产品团队经常会犯一个致命的错误，就是认为 IT 部门是需要突破的瓶颈。他们希望脱离已有的 IT 部门并使用公有云，但实际上是他们忽视了 IT 部门提供的关键服务。迁移到云上只是以不同的方式实现这些关键服务，因为 AWS 也是一个数据中心，团队即使使用 AWS 也需要完成 IT 运维任务。
|
||||
|
||||
实际上，产品团队在迁移到云时候也必须学习如何使用这些 IT 服务。因此，当产品团队开始重构遗留的代码并部署到云上时，也需要学习大量的技能才能正常运作。这些技能不会无师自通，必须自行学习或者聘用相关的人员，团队的主导者也必须积极进行管理。
|
||||
|
||||
在带领团队时，我找不到任何适合我的工具，因此我建立了 [Tekita.io][9] 这个项目。Tekata 免费而且容易使用。但相比起来，把注意力集中在人员和流程上更为重要，你需要不断学习，持续关注团队的弱项，因为它们会影响团队的交付能力，而修补这些弱项往往需要学习大量的新知识，这就需要团队成员之间有一个很好的协作。因此 76％ 的年轻人都认为个人发展机会是公司文化[最重要的的一环][10]。
|
||||
|
||||
### 效果就是最好的证明
|
||||
|
||||
DevOps 转型会改变团队的工作方式和文化，这需要得到管理层的支持和理解。同时，工作方式的改变意味着新技术的引入，所以在管理上也必须谨慎。但转型的最终结果是团队变得更高效、成员变得更积极、产品变得更优质，客户也变得更快乐。
|
||||
|
||||
免责声明：本文中的内容仅为 Lee Eason 的个人立场，不代表 Ipreo 或 IHS Markit。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/18/10/tales-devops-transformation
|
||||
|
||||
作者：[Lee Eason][a]
|
||||
选题：[lujun9972][b]
|
||||
译者：[HankChow](https://github.com/HankChow)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/leeeason
|
||||
[b]: https://github.com/lujun9972
|
||||
[1]: https://link.springer.com/article/10.1007%2Fs00442-014-2995-6
|
||||
[2]: /file/411061
|
||||
[3]: https://opensource.com/sites/default/files/uploads/devops-delays.png "Improvements after DevOps transformation"
|
||||
[4]: https://puppet.com/resources/whitepaper/state-of-devops-report
|
||||
[5]: https://www.gartner.com/en/publications/wolf-cio
|
||||
[6]: https://en.wikipedia.org/wiki/Drive:_The_Surprising_Truth_About_What_Motivates_Us
|
||||
[7]: https://www.ted.com/talks/dan_pink_on_motivation?language=en#t-2094
|
||||
[8]: https://en.wikipedia.org/wiki/The_Hero_with_a_Thousand_Faces
|
||||
[9]: https://tekata.io/
|
||||
[10]: https://www.execu-search.com/~/media/Resources/pdf/2017_Hiring_Outlook_eBook
|
||||
[11]: https://allthingsopen.org/talk/tales-from-a-devops-transformation/
|
||||
[12]: https://allthingsopen.org/
|
||||
|
||||
Loading…
Reference in New Issue
Block a user