devops工程师

重点 (Top highlight)

Job specs for DevOps engineer jobs often mention a vast variety of duties and responsibilities. Are they hiring for a single role or a whole team?

DevOps工程师工作的工作规格经常提到各种各样的职责。 他们是为单个角色还是整个团队而招聘?

Roles having DevOps in their title hardly share the same meaning. They often have something in common, though. They try to cover for what traditionally would have been the specialization of different professionals.

在其标题中具有DevOps的角色几乎没有相同的含义。 但是,它们通常有一些共同点。 他们试图涵盖传统上不同专业人士的专业知识。

Don’t get me wrong: Cross-functional expertise is definitely important. But I don’t think DevOps means replacing a multitude of specializations with a single role. Different specializations like operations, security, testing, development, product management, and so on are vast and require specific knowledge.

别误会:跨职能专业知识绝对重要。 但是我不认为DevOps意味着用一个角色代替众多专业。 操作,安全性,测试,开发,产品管理等不同的专业领域非常广泛,并且需要特定的知识。

I think the key differentiator of successful DevOps organizations is that they enable effective collaboration. They have as their clear North Star the goal of delivering value to the end user.

我认为成功的DevOps组织的主要区别在于它们可以实现有效的协作。 他们明确指出了向最终用户提供价值的目标。

Overall, I don’t think we should be talking about a DevOps engineer, but rather about DevOps culture in organizations.

总体而言,我认为我们不应该谈论DevOps工程师,而应该谈论组织中的DevOps文化。

But let’s take a step back first.

但是,让我们先退后一步。

DevOps到底意味着什么? (What Does DevOps Mean, Really?)

I tweeted my own definition of DevOps some time ago.

不久前,我在Twitter上发布了自己的DevOps定义。

“DevOps is a highly condensed way of referring to the combination of practices that aim at shortening the software development life-cycle, increase the feedback opportunities and facilitate continuous improvement and experimentation.”

“ DevOps是一种高度融合的方式,指的是旨在缩短软件开发生命周期,增加反馈机会并促进持续改进和试验的实践组合。”

— Alessandro Diaferia (@alediaferia) July 4, 2020

-亚历山德罗·迪亚菲利亚(@alediaferia)2020年7月4日

DevOps organizations incentivise different specialties to collaborate. The intrinsic existing tension between Dev, making changes to the system, and Ops, wanting to keep the system stable, dissolves. The greater good is now the value stream.

DevOps组织鼓励不同的专业进行协作。 解决了对系统进行更改的Dev和想要保持系统稳定的Ops之间固有的现有张力。 现在,更大的好处是价值流。

A stable system that delivers nothing is as useless as an unstable system that keeps offering new functionality.

一个没有提供任何东西的稳定系统,就像一个不断提供新功能的不稳定系统一样,是无用的。

Dev and Ops understand the importance of working together to maximise this flow, to figure out which bets worked out and which ones didn’t.

开发人员和运营人员了解共同努力以最大程度地发挥这种作用,弄清楚哪些赌注有效,哪些赌注无效的重要性。

Organizations that embrace the DevOps mindset can be more effective than the competition at experimenting with new functionality. They quickly validate their assumptions, activating and deactivating functionality by flipping a switch on a dashboard.

尝试DevOps思维方式的组织在尝试新功能方面可能比竞争对手更有效。 他们快速验证自己的假设,通过翻转仪表板上的开关来激活和停用功能。

Incidents become an opportunity for learning rather than a chance of blaming someone.

突发事件成为学习的机会,而不是指责某人的机会。

In general, DevOps organizations learn to adapt and evolve to any situation.

通常,DevOps组织会学习适应各种情况并不断发展。

Overall, I think there shouldn’t be a single DevOps role, but rather a set of specific specialties collaborating effectively.

总体而言,我认为不应只有一个DevOps角色,而应该是一组特定的专业领域进行有效的协作。

This ideal view of the terminology, though, might sometimes clash with the reality of the job market. Companies willing to attract the best talent with the most current skills may end up advertising for roles that are counterproductive in the context of DevOps principles.

不过,这种术语的理想观点有时可能与就业市场的现实相冲突。 愿意吸引具有最新技能的最佳人才的公司最终可能会广告宣传在DevOps原则下适得其反的角色。

But let’s have a look at a few interesting job specs.

但是,让我们看一些有趣的工作规格。

Photo by Jordan Whitfield on Unsplash
乔丹·惠特菲尔德在 Unsplash上 拍摄的照片

公司在寻找什么? (What Are Companies Looking For?)

Let’s read through a few excerpts from job specs I found out there in the wild.

让我们通读我在野外发现的工作规格书摘录。

灵活的问题解决者 (The flexible problem solver)

“DevOps engineers are IT professionals who collaborate with software developers, system operators and other IT staff members to manage code releases. They cross and merge the barriers that exist between software development, testing and operations teams and keep existing networks in mind as they design, plan and test. Responsible for multitasking and dealing with multiple urgent situations at a time, Devops engineers must be extremely flexible.” — A job spec on the internet

“ DevOps工程师是IT专业人员,他们与软件开发人员,系统操作员和其他IT员工合作来管理代码发布。 他们跨越并合并了软件开发,测试和运营团队之间存在的障碍,并在设计,规划和测试时牢记现有网络。 Devops工程师负责多任务处理并一次处理多种紧急情况,因此必须非常灵活。” —互联网上的工作规范

This is one of those classic examples where the organization believes that the DevOps principles should be delegated to a single team.

这是组织认为应将DevOps原则委派给单个团队的经典示例之一。

The spec mentions the myriad of duties that are the responsibility of the DevOps engineers in the company. A DevOps engineer is expected to be responsible for “multi-tasking and dealing with multiple urgent situations at a time.” Therefore, they must be “extremely flexible.”

该规范提到了公司DevOps工程师应承担的无数职责。 DevOps工程师应负责“一次执行多任务并同时处理多个紧急情况”。 因此,它们必须“极其灵活”。

Multitasking and dealing with multiple urgent situations at a time is, for sure, likely to happen anywhere; I don’t think this should be a peculiarity of a role in an organization. On the contrary, a healthy environment empowers every engineer to handle urgent situations and learn from them.

当然,多任务处理和一次处理多种紧急情况很可能在任何地方发生; 我认为这不应该是组织中角色的特殊性。 相反,健康的环境使每位工程师都有能力处理紧急情况并向他们学习 。

Coming across this role, I’d think that the organization is not really trying to adopt DevOps practices. Instead of encouraging people to collaborate and improve, they’re building a dedicated team to throw issues and urgent situations at.

遇到这个角色,我认为该组织并不是真正在尝试采用DevOps做法。 他们没有鼓励人们进行协作和改进,而是建立了一支敬业的团队来解决问题和紧急情况。

This job spec would be a big red flag for me.

这个工作规范对我来说是一个很大的危险信号。

生产力的助推器 (The productivity booster)

“A DevOps engineer combines an understanding of both engineering and coding. A DevOps engineer works with various departments to create and develop systems within a company. From creating and implementing software systems to analysing data to improve existing ones, a DevOps engineer increases productivity in the workplace.” — Another job spec on the internet

“ DevOps工程师结合了对工程和编码的理解。 DevOps工程师与各个部门一起在公司内部创建和开发系统。 从创建和实施软件系统到分析数据以改善现有数据,DevOps工程师可以提高工作场所的生产率。” —互联网上的另一个工作规范

In a DevOps organization, engineers do work with various departments. But what’s the point, then, of having a dedicated DevOps engineer role? Do the other type of engineers not work with the various departments of the organization? Do non-DevOps engineers not analyse data and improve existing systems? Additionally, the job spec claims that a DevOps engineer increases productivity in the workplace. How? Do they radiate productivity?

在DevOps组织中,工程师与各个部门一起工作。 那么,拥有专门的DevOps工程师角色又意味着什么呢? 其他类型的工程师是否不能与组织的各个部门合作? 非DevOps工程师是否不分析数据并改善现有系统? 此外,工作规范还声称DevOps工程师可以提高工作场所的生产率。 怎么样? 它们会辐射生产力吗?

发布经理-但DevOps (The release manager — but DevOps)

“A DevOps engineer works with developers and the IT staff to oversee the code releases. […] Ultimately, you will execute and automate operational processes fast, accurately and securely.”

“ DevOps工程师与开发人员和IT员工一起监督代码发布。 […]最终,您将快速,准确和安全地执行和自动化操作流程。”

My favourite so far, this is quite a condensed one, but the release aspect mentioned in it strikes me as particularly interesting.

到目前为止,我最喜欢的是一个精简的版本,但是其中提到的发布方面使我感到特别有趣。

I tend to separate the concept of deployment from the one of release. Users experience product updates governed by a release policy that may or may not be the same as the deployment policy. This really depends on the strategy of the organization.

我倾向于将发布的概念与发布的概念分开。 用户体验的产品更新受发布策略控制,该发布策略可能与部署策略相同,也可能不同。 这实际上取决于组织的策略。

Regardless of this distinction, though, I believe that constraining the capability of delivering value to the end user to a specific role undermines the agility of an organization.

但是,不管这种区别如何,我都认为将最终用户交付价值的能力限制为特定角色会损害组织的敏捷性。

The teams should be able to continuously release code into production. Mechanisms such as feature flags should control the release of functionality. This means that the code in production doesn’t necessarily activate upon deploying it, making it possible for the organization to control when the functionality actually reaches the user.

团队应该能够不断将代码发布到生产中。 功能标记之类的机制应控制功能的发布。 这意味着生产中的代码不一定会在部署时激活,从而使组织可以控制功能何时真正到达用户。

In general, a deployment should be a non-event: nothing special, just another merge into the main branch that causes code to end up in production.

通常,部署应该是非事件的:没有什么特别的,只是另一个合并到主分支中,这会导致代码最终在生产中使用。

In a fast-paced world like the one we live in, an organization shouldn’t constrain itself by requiring dedicated engineers to release new functionality. Modern environments require companies to always be experimenting. Organizations should empower non-technical teams to run experiments, analyse data, and autonomously decide when to release new functionality. All of this, ideally, shouldn’t require ad hoc intervention from a specific engineer.

在我们生活中这样一个快节奏的世界中,组织不应通过要求专门的工程师发布新功能来约束自己。 现代环境要求公司始终进行试验。 组织应授权非技术团队运行实验,分析数据并自主决定何时发布新功能。 理想情况下,所有这些都不需要特定工程师的临时干预。

Job specs like this one feel like they’re trying to repurpose the role of the release manager to keep up with the latest trends, by just changing a few words.

像这样的工作规范感觉就像他们只是通过更改几句话,就试图重新调整发布经理的角色以跟上最新趋势。

I don’t think release management goes away in a DevOps organization. Rather, release management becomes ensuring that the rest of the organization can be autonomous at releasing. Achieving this means investing in automation and internal tools for the whole company.

我认为在DevOps组织中发布管理不会消失。 相反,发布管理变得可以确保组织的其余部分在发布时可以自治。 实现这一目标意味着要为整个公司投资自动化和内部工具。

平台工程师-但更酷 (A platform engineer — but cooler)

“The DevOps engineer will be a key leader in shaping processes and tools that enable cross-functional collaboration and drive CI/CD transformation. The DevOps engineer will work closely with product owners, developers, and external development teams to build and configure a high performing, scalable, cloud-based platform that can be leveraged by other product teams.”

“ DevOps工程师将是塑造流程和工具的关键领导者,以实现跨功能的协作并推动CI / CD的转型。 DevOps工程师将与产品所有者,开发人员和外部开发团队紧密合作,以构建和配置可被其他产品团队利用的高性能,可伸缩的基于云的平台。”

This is the least bad of the job specs I’ve encountered. It describes a set of responsibilities that usually pertain to a platform or infrastructure team. Most of these teams often get renamed to DevOps Team, and their members become DevOps engineers for fashion reasons.

这是我遇到的工作规格中最差的。 它描述了通常与平台或基础架构团队有关的一组职责。 这些团队中的大多数通常会更名为DevOps团队,并且出于时尚原因,他们的成员成为DevOps工程师。

The platform engineering team is the key enabler for organizations that want to embrace DevOps principles. But thinking that they only pertain to a specific team will hardly result in a successful journey.

平台工程团队是希望采用DevOps原则的组织的关键推动力。 但是认为他们只属于特定的团队并不会成功。

This team will surely be responsible to build the relevant infrastructure that enables the other teams to build on top, but they can’t be left alone in the understanding and application of those principles.

这个团队肯定会负责构建相关的基础架构,以使其他团队能够在此之上构建,但是在理解和应用这些原则时不能孤单。

Developer teams will need to become autonomous at adopting and making changes to those systems. They will need to understand the implications of their code running in production. They must understand how to recognize if the system is not behaving as expected and be able to act to restore it.

开发人员团队需要在采用和更改这些系统时变得自主。 他们将需要了解在生产环境中运行代码的含义。 他们必须了解如何识别系统是否表现出预期的异常并能够采取行动来还原它。

Equally, the product team should spend time understanding what new important capabilities derive from adopting DevOps practices. Code continuously flowing into production behind feature flags, containerization technologies, improved monitoring and alerting, et cetera, open endless opportunities.

同样,产品团队应花时间了解采用DevOps做法会带来哪些新的重要功能。 在功能标记,容器化技术,改进的监视和警报等功能背后,代码不断流入生产环境,带来了无尽的机遇。

Improved user experience and experimentation opportunities, for example, are an important asset to leverage to remain competitive.

例如,改善的用户体验和实验机会是保持竞争优势的重要资产。

Photo by Matteo Vistocco on Unsplash
Matteo Vistocco在 Unsplash上的 照片

公司应该寻找什么? (What Should Companies Be Looking For?)

We’ve just gone through a few job specs that look for variations of a DevOps engineer role, and I’ve outlined what aspects I think are flawed in those roles. But what should companies look for, then?

我们刚刚查看了一些工作规格,以寻找DevOps工程师角色的变体,并且我概述了我认为这些角色存在哪些方面的缺陷。 但是,公司应该寻找什么呢?

Before blindly starting to hire for roles driven by industry fashion trends, organizations should rather invest in understanding what’s holding them back from being DevOps.

在盲目地开始聘请由行业流行趋势驱动的角色之前,组织应该宁愿投资于了解阻碍他们成为DevOps的因素。

In the Unicorn Project, Gene Kim mentions the five ideals of successful DevOps organizations. I think they’re an effective set of principles to take the temperature of your organization in terms of DevOps practices. Those ideals are:

在Unicorn Project中 ,Gene Kim提到了成功的DevOps组织的五个理想。 我认为它们是有效的原则集,可以根据DevOps的实践来提高组织的温度。 这些理想是:

  • Locality and simplicity

    局部性和简单性
  • Focus, flow, and joy

    专注,流畅和欢乐
  • Improvement of daily work

    改善日常工作
  • Psychological safety

    心理安全
  • Customer focus

    以客户为中心

局部性和简单性 (Locality and simplicity)

Making changes to the system, in order to deliver greater value to the end user, should be easy — easy in terms of the team’s autonomy to make changes to the product as well as easy in terms of friction that the technology in use imposes on the changes.

为了向最终用户提供更大的价值,对系统进行更改应该很容易-就团队进行产品更改的自主权而言,这很容易,而所使用技术对产品造成的摩擦也很容易。变化。

专注,流动和欢乐 (Focus, flow, and joy)

Developers should be able to focus on their work and develop software with minimum impediments. This is facilitated by making sure that the software development lifecycle infrastructure is working for the benefit of the engineering organization.

开发人员应该能够专注于他们的工作并以最小的障碍来开发软件。 通过确保软件开发生命周期基础结构为工程组织的利益而工作,这将得到促进。

改善日常工作 (Improvement of daily work)

Continuously learning and improving the conditions in which the work gets done is the key to maximising the flow of value and the happiness of the people doing the work. Successful organizations facilitate a continuously improving environment by enabling engineers to build tools and practices that enhance their daily operations.

不断学习和改善工作完成的条件是最大化价值流和工作人员幸福感的关键。 成功的组织通过使工程师能够构建工具和实践来增强其日常运营,从而促进了持续改善的环境。

心理安全 (Psychological safety)

An organization will hardly be able to improve if the people that are part of it are not incentivised to raise issues and address them. This is not something you solve for by hiring a specific role. It’s the organization’s responsibility to facilitate an environment where constructive feedback is the norm.

如果组织中的员工没有动力提出问题并加以解决,则组织将几乎无法改善。 这不是您通过雇用特定角色来解决的问题。 营造一种以建设性反馈为准则的环境是组织的责任。

以客户为中心 (Customer focus)

Last but not least, the engineering organization, just like any other department in the company, should be sharply focused on the customer. All the efforts should be balanced against what’s best for the customer and, ultimately, for the company.

最后但并非最不重要的一点是,与公司中的其他部门一样,工程组织应以客户为中心。 应该将所有努力与对客户乃至对公司的最佳平衡。

What should companies be looking for then? I think the priority should be on understanding what’s blocking them from fully embracing a DevOps mindset across all departments. Most of the time, you’ll realise that the set of skills you need is already there around you. What’s holding you back is probably the current set of processes through which work gets done at your company.

那么公司应该寻找什么? 我认为首要任务应该是了解阻碍他们全面采用所有部门的DevOps思维方式的因素。 大多数时候,您会意识到所需的技能已经在您身边。 阻碍您前进的因素可能是公司当前完成工作的一系列流程。

Photo by Roi Dimor on Unsplash
Roi Dimor在 Unsplash上的 照片

神话角色 (A Mythical Role)

It feels like the DevOps engineer is a mythical figure that certain organizations pursue in the hope of finding the holy grail of a software engineer capable of doing anything.

好像DevOps工程师是某些组织追求的神话人物,希望找到能够做任何事情的软件工程师的圣杯。

This, of course, will hardly be the case. Recognizing the importance of the single specializations is what makes organizations successful and capable of maximising the expertise of the people that they are made of.

当然,事实并非如此。 认识到单一专业的重要性是使组织成功并能够最大程度地提高其所组成的人员的专业知识的能力。

What happens in a DevOps organization is that responsibilities are redistributed: Developers are empowered to make changes to production environments because organizations recognize the importance of moving fast. This means opportunities for success increase together with the opportunities for failure.

DevOps组织中发生的事情是责任被重新分配:开发人员有权更改生产环境,因为组织意识到快速行动的重要性。 这意味着成功的机会与失败的机会一起增加。

Eliminating barriers and creating a safe space for collaboration helps Dev and Ops work together to resolve issues when they occur. This is what ultimately leads to high performing teams that are incentivised to follow the North Star of the continuous value stream to the end user.

消除障碍并创建安全的协作空间可帮助Dev和Ops共同解决问题。 这最终导致高绩效团队受激励去跟随持续价值流的北极星到最终用户。

Specific DevOps knowledge in terms of technology, tools, and best practices will be required, for sure, but it won’t be something a single role should be responsible for.

当然,需要在技术,工具和最佳实践方面具有特定的DevOps知识,但这不是一个单一角色应负责的事情。

Instead of pursuing a mythical role, then, let’s go after the much more plausible alternative of creating a well-oiled machine where all the people are incentivised to work together in harmony with the clear goal of maximising the value to the end user.

然后,让我们继续追求更合理的替代方案,即创造一个运转良好的机器,让所有人都受到激励,与实现最终用户最大价值的明确目标和谐地合作,而不是扮演神话角色。

Thanks for getting to the end of this article. I sincerely hope you’ve enjoyed it.

感谢您阅读本文结尾。 我衷心希望您喜欢它。

翻译自: https://medium/better-programming/the-mythical-devops-engineer-698e4da12f31

devops工程师

更多推荐

devops工程师_神话般的DevOps工程师