mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-13 22:30:37 +08:00
TSL
This commit is contained in:
Xiaobin.Liu
parent
48588fa2ea
commit
d47656fca0
@ -1,101 +0,0 @@
|
||||
[#]: subject: "6 tips for building an effective DevOps culture"
|
||||
[#]: via: "https://opensource.com/article/23/1/tips-effective-devops-culture"
|
||||
[#]: author: "Yauhen Zaremba https://opensource.com/users/yauhen-zaremba"
|
||||
[#]: collector: "lkxed"
|
||||
[#]: translator: "lxbwolf"
|
||||
[#]: reviewer: " "
|
||||
[#]: publisher: " "
|
||||
[#]: url: " "
|
||||
|
||||
6 tips for building an effective DevOps culture
|
||||
======
|
||||
|
||||
Why would you want to build a [DevOps][1] culture? There are many benefits to the streamlined collaboration of the development and operations teams. A major goal is efficiency: Increasing the speed of new software deployments and reducing idle time for workers. Fostering trust between colleagues can improve employee satisfaction, produce new innovations, and positively impact profitability.
|
||||
|
||||
[DevOps][2] is a broad philosophy with a range of interpretations. In other words, you can visit 40 companies and find 40,000 different ideas about using DevOps effectively in the workplace. This diversity of opinion is actually a good thing–so many perspectives are useful for building stronger teams. This guide will look at the top tips for encouraging better collaboration between colleagues within a DevOps culture.
|
||||
|
||||
Each section offers a different aspect of DevOps culture and looks at ways to introduce it into your workforce.
|
||||
|
||||
![DevOps includes collaboration, workflow, infosec, and iteration.][3]
|
||||
|
||||
### Continuous development of processes
|
||||
|
||||
This core tenet of DevOps culture sets it apart from many other types of workplace ethos. The DevOps philosophy says that it is essential to make mistakes because it shows you are trying out new ideas.
|
||||
|
||||
The heart of DevOps culture is a commitment to evolving creativity. Practically, that means not yelling at your direct reports when test results show that things were better before they changed it. It means recognizing that progress is not linear and success is never a straight line.
|
||||
|
||||
DevOps expert [Gene Kim][4] advocates for risk-taking and experimentation. This implies letting your team work on unusual tasks to find new insights.
|
||||
|
||||
Should your organization be profit-driven? Can you allow your teams to try something new? I'm talking about something other than unrelated passion projects. Continuous process development means being open to upgrading present methods. Great sales leaders appreciate that results matter more than presenteeism, so it is always crucial to focus on how teams are working rather than how much.
|
||||
|
||||
### Readily give feedback and actively seek it
|
||||
|
||||
Increased trust between individuals is another key feature of a thriving DevOps culture. Whether your staff is learning how to build affiliate network contacts or trying to design their next [UX][5] survey, everyone should be open to feedback on their work. But this will never happen until your teammates respect each other's opinions and trust that feedback is given in a spirit of good intention.
|
||||
|
||||
This culture may sound impossible to cultivate; indeed, some companies will struggle to achieve this more than others. Granted, a large part of the success of giving and receiving feedback depends on the personalities of your employees. It is possible to screen for this during the recruitment process.
|
||||
|
||||
Before you expect staff to readily offer feedback to colleagues and seek it in the first place, you should lead by example. Members of the C-suite should be modeling this behavior, openly asking members of the company to pose probing questions about their strategic decisions, and providing balanced feedback.
|
||||
|
||||
![DevOps is the intersection of development, quality assurance, and operations][6]
|
||||
|
||||
### Always look for improvements
|
||||
|
||||
Building on increased intellectual trust between colleagues, your team should look for ways to improve its work. The nature of DevOps means the software development team will be producing deployments more rapidly than with traditional approaches.
|
||||
|
||||
However, this culture of openness to improvement can positively impact departments beyond development and operations. Ask yourself what other areas of your business could do with a burst of optimism.
|
||||
|
||||
Be on the lookout for training and upskilling opportunities. Even if a training course is less salient than advertised, the chance to network with industry professionals and build contacts for the future can only enhance the diversity of ideas within your organization.
|
||||
|
||||
### Save ideas for later development
|
||||
|
||||
Part of your DevOps toolchain should be a heavily used account on [Git][7]. You can use Git as a common repository for scripts produced during software development and other related projects. Known as "version control," Git allows programmers to save iterations of their work and reuse or improve the work of others.
|
||||
|
||||
You're aiming for the ability to keep hold of good ideas for future use. A certain pathway did not work out for specific reasons. However, just because that set of ideas was wrong for the time it was conceived does not mean it can never become helpful in the future.
|
||||
|
||||
As the entire focus of DevOps rests on end-to-end ownership of software in production, saving iterations of developments truly supports this principle. You want to see an improved focus on and commitment to the software testing project at hand.
|
||||
|
||||
A simple way to incorporate this is to request that developers include ideas for future work in the developer contract and final project report. Make sure tech services managers know they should ask for examples of side-branching ideas that cropped up during the build. The more minds aware of these little innovations, the more likely someone will remember one when needed.
|
||||
|
||||
### Sit close together (physically or virtually)
|
||||
|
||||
The goal is to share a common understanding of one another's job roles and how they interrelate. You can achieve this in a few simple ways, summarized by three words: Sit close together. Invite other teams to your meetings and share user feedback reports in their entirety. Have lunch together, plan virtual happy hours together, and generally make sure your colleagues are in close proximity. About 90% of teams with a mature DevOps protocol report a clear understanding of their responsibilities to other teams compared to only about 46% of workers in immature DevOps teams.
|
||||
|
||||
Although it can be tempting to form cliques with like-minded folk and only hang out with staff hired to carry out the same tasks as you, this is terrible for the business as a whole. Whether you like it or not, all humans are multi-faceted and capable of contributing their unique talents to a whole host of scenarios.
|
||||
|
||||
The idea of closer collaboration is to honor the ability of anyone to suggest improvements to the products or work processes going on around them. If you only ever sit at a distance from the other departments within the company, you will miss countless opportunities to share intelligent ideas. After all, you often learn best in the free flow of ideas during a conversation.
|
||||
|
||||
### Commit to automation
|
||||
|
||||
You should be looking to automate mundane and repetitive tasks in the name of efficiency and process acceleration. Every industry has boring–and quite frankly, silly–exercises carried out daily or weekly.
|
||||
|
||||
Whether this is manually copying data from one page to another or typing out audio transcripts by hand, staff at every level should insist that machines take on such burdens where possible. The reality is automation technology advances every single year, and operational processes should, too. [Automation testing][8] is so crucial to DevOps that it is the second principle of the CALMS framework (the "C" of which stands for "culture").
|
||||
|
||||
How can you make this happen? Invite staff to openly express which aspects of their job they feel could be automated and then–here is the crucial part–support the facilities needed to automate them. That might mean a $600 annual subscription to a software program, a complete enterprise application modernization, or two days of developers' time to build a new tool to use in-house.
|
||||
|
||||
Either way, you should assess the benefits of automation and consider how much time you could save for everyone. DevOps statistics continually indicate just how much better off modern companies are by integrating these beneficial principles year after year.
|
||||
|
||||
### Explore new ways of working successfully
|
||||
|
||||
A culture shift doesn't happen overnight. The sooner you start, though, the sooner you see results. In my experience, people embrace change when it's a genuine improvement on what has gone before. DevOps provides a framework for such improvements. Whether you're just getting started with DevOps in your organization or simply want to improve your existing culture, consider the above points and how they relate to your organization's future.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/23/1/tips-effective-devops-culture
|
||||
|
||||
作者：[Yauhen Zaremba][a]
|
||||
选题：[lkxed][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/yauhen-zaremba
|
||||
[b]: https://github.com/lkxed
|
||||
[1]: https://opensource.com/resources/devops
|
||||
[2]: https://opensource.com/article/22/2/devops-documentation-maturity
|
||||
[3]: https://opensource.com/sites/default/files/2022-12/devop.png
|
||||
[4]: https://enterprisersproject.com/user/gene-kim
|
||||
[5]: https://opensource.com/article/22/7/awesome-ux-cli-application
|
||||
[6]: https://opensource.com/sites/default/files/2022-12/devop-venn.png
|
||||
[7]: https://opensource.com/article/22/11/git-concepts
|
||||
[8]: https://opensource.com/article/20/7/open-source-test-automation-frameworks
|
||||
@ -0,0 +1,102 @@
|
||||
[#]: subject: "6 tips for building an effective DevOps culture"
|
||||
[#]: via: "https://opensource.com/article/23/1/tips-effective-devops-culture"
|
||||
[#]: author: "Yauhen Zaremba https://opensource.com/users/yauhen-zaremba"
|
||||
[#]: collector: "lkxed"
|
||||
[#]: translator: "lxbwolf"
|
||||
[#]: reviewer: " "
|
||||
[#]: publisher: " "
|
||||
[#]: url: " "
|
||||
|
||||
构建高效的 DevOps 文化的 6 个技巧
|
||||
======
|
||||
|
||||
你为什么要构建 [DevOps][1] 文化？开发和运营团队的精简协作有很多好处。效率是首要目标：提高新软件部署的速度，减少等待的时间。培养同事之间的信任可以提升员工的满意度，激发新的创新，并对盈利能力产生积极的影响。
|
||||
|
||||
[DevOps][2] 是一个很广泛的范畴，大家的理解也见仁见智。每个公司对于如何实行 DevOps 也各不相同。这种意见的多样性实际上是一件好事--这么多的观点对于建立更强大的团队是很有用的。本指南将探讨在 DevOps 文化中鼓励同事之间更好地合作的最高技巧。
|
||||
|
||||
下面每个部分从不同的视角介绍 DevOps 文化，并争取将它引入你的工作中去。
|
||||
|
||||
![DevOps includes collaboration, workflow, infosec, and iteration.][3]
|
||||
|
||||
### 流程的持续开发
|
||||
|
||||
DevOps 文化的这一核心原则使它与许多其他类型的工作区别开来。DevOps 哲学说，犯错是有积极意义的，因为这表明你在尝试新的想法。
|
||||
|
||||
DevOps 文化的核心是不停地创造。实际上，这意味着当测试结果显示事情由于你的改动而变坏时，不要懊恼。我们要认识到，进化的过程不是线性的，通往成功的道路也从来不是一条直线。
|
||||
|
||||
DevOps 专家[Gene Kim][4] 主张勇于承担风险和进行实验。鼓励你的团队尝试不寻常的任务，以得到新的领悟。
|
||||
|
||||
你的组织应该以利润为导向吗？你能允许你的团队尝试一些新东西（非指个人兴趣项目）吗？持续的流程开发意味着对升级目前的方法持开放态度。优秀的销售领导懂得，结果比出勤率更重要，因此，关注团队的工作方式而不是工作量的多少始终是关键。
|
||||
|
||||
### 随时提供反馈并积极寻求反馈
|
||||
|
||||
成员之间增加信任是蓬勃发展的 DevOps 文化的另一个关键特征。无论你的员工是在学习如何建立联盟网络联系，还是试图设计他们的下一个 [UX][5] 调查，每个人都应该对他们工作的反馈持开放态度。但是，除非你的团队成员尊重彼此的意见，并相信反馈是本着善意的精神提出的，否则这永远不会发生。
|
||||
|
||||
这种文化听起来可能是很难培养的；事实上，一些公司会比其他公司更努力地实现这一点。诚然，给予和接受反馈的成功很大程度上取决于员工的个性。在招聘过程中，也可以对此进行筛选。
|
||||
|
||||
在你期望员工随时向同事提供反馈并主动寻求反馈之前，你应该以身作则。高管应该以身作则，公开要求公司成员对其战略决策提出探究性问题，并提供相应的反馈。
|
||||
|
||||
![DevOps is the intersection of development, quality assurance, and operations][6]
|
||||
|
||||
### 不断改进
|
||||
|
||||
在同事之间增加智力信任的基础上，你的团队应该寻找方法来改善其工作。DevOps 的性质意味着软件开发团队将比传统方法更迅速地进行部署。
|
||||
|
||||
这种开放的改进文化可以对开发和运维以外的部门产生积极的影响。你也可以自己去探索，企业还有哪些领域会受到积极的影响。
|
||||
|
||||
留意培训和提高技能的机会。即使一个培训课程没有广告上说的那么突出，但有机会与行业专家建立联系，并与未来建立联系，这可以提高你的组织内的思想多样性。
|
||||
|
||||
### 为以后的开发保存当前的想法
|
||||
|
||||
频繁使用的 [Git][7] 账户应该是你的 DevOps 工具链的一部分。你可以用 Git 作为软件开发和其他相关项目中产生的脚本的共同仓库。Git 作为 "版本控制" 工具而被熟知，Git 允许程序员保存他们工作的迭代、复用或改进其他人的工作。
|
||||
|
||||
你的目标是有能力保留好的想法供将来使用。某个方法由于某种原因没有成功。然而，那套想法在当时是错误的，并不意味着它在未来永远无法成为有用的东西。
|
||||
|
||||
由于 DevOps 的整个重点在于生产环境中的软件的端到端所有权，因此保存开发的迭代真正支持这一原则。你希望看到对手头的软件测试项目的持续关注和投入。
|
||||
|
||||
一个简单的方法是要求开发者在开发者合同和最终项目报告中包含对未来工作的想法。确保技术服务经理知道他们应该要求提供在建设过程中出现的旁门左道的想法的例子。意识到这些小创新的人越多，在需要的时候就越有可能有人记住一个。
|
||||
|
||||
### 坐在一起（物理上或逻辑上）
|
||||
|
||||
目标是对彼此的工作角色以及它们之间的相互关系有一个共同的理解。你可以通过几个简单的方法实现这一目标，用一句话概括：坐在一起。邀请其他团队参加你们的会议，完整地分享用户反馈报告。一起吃午饭，一起计划虚拟的快乐时光，一般来说，要确保你的同事都在一起。大约 90% 的拥有成熟的 DevOps 协议的团队报告说，他们清楚地了解自己对其他团队的责任，而在不成熟的 DevOps 团队中，只有大约 46% 的工作者清楚地了解自己的责任。
|
||||
|
||||
虽然与志同道合的人结成小团体，只与被雇来执行与你相同任务的员工一起玩耍是很诱人的，但这对整个企业来说是很糟糕的。无论你喜欢与否，所有的人都是多面手，能够在一系列的情况下贡献自己的独特才能。
|
||||
|
||||
密切协作的想法是尊重任何人对其周围正在进行的产品或工作流程提出改进建议的能力。如果你与公司内的其他部门保持一定的距离，你将会错过无数次分享智慧想法的机会。毕竟，你往往在交流中学习得最好。
|
||||
|
||||
### 致力于自动化
|
||||
|
||||
你应该以提高效率和加速流程的方式，将单调的和重复的任务变为自动化。每个行业都有无聊的--说得直白一点，愚蠢的--每天或每周都要进行的工作。
|
||||
|
||||
无论是手工将数据从一页复制到另一页，还是手工打出音频记录，每个级别的工作人员都应该坚持让机器在可能的情况下承担这些负担。现实是自动化技术每年都在进步，操作流程也应该如此。[自动化测试][8] 对 DevOps 非常关键，它是 CALMS 框架的第二个原则（其中的 “C”代表“文化”）。
|
||||
|
||||
你怎样才能实现这一点？邀请员工公开表达他们认为工作的哪些方面可以自动化，然后--这里是关键的部分--支持实现自动化所需的设施。这可能意味着每年花 600 美元订阅一个软件程序、一套完整的企业应用现代化解决方案或开发人员的两天时间来建立一个新的工具在内部使用。
|
||||
|
||||
|
||||
无论哪种方式，你都应该评估自动化的好处，考虑你可以为每个人节省多少时间。DevOps 的统计数据不断表明，现代公司通过整合这些有益的原则，年复一年地得到了很大的改善。
|
||||
|
||||
### 探索成功的新工作方式
|
||||
|
||||
文化转变不会在一夜之间发生。不过，你越早开始，就越早看到结果。根据我的经验，当变化是对以前的真正改进时，人们会接受它。DevOps 为这种改进提供了一个框架。无论你是刚刚在你的组织中开始使用 DevOps，还是仅仅想改善你现有的文化，请考虑以上几点以及它们与你组织的未来的关系。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/23/1/tips-effective-devops-culture
|
||||
|
||||
作者：[Yauhen Zaremba][a]
|
||||
选题：[lkxed][b]
|
||||
译者：[lxbwolf](https://github.com/lxbwolf)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]: https://opensource.com/users/yauhen-zaremba
|
||||
[b]: https://github.com/lkxed
|
||||
[1]: https://opensource.com/resources/devops
|
||||
[2]: https://opensource.com/article/22/2/devops-documentation-maturity
|
||||
[3]: https://opensource.com/sites/default/files/2022-12/devop.png
|
||||
[4]: https://enterprisersproject.com/user/gene-kim
|
||||
[5]: https://opensource.com/article/22/7/awesome-ux-cli-application
|
||||
[6]: https://opensource.com/sites/default/files/2022-12/devop-venn.png
|
||||
[7]: https://opensource.com/article/22/11/git-concepts
|
||||
[8]: https://opensource.com/article/20/7/open-source-test-automation-frameworks
|
||||
Loading…
Reference in New Issue
Block a user