注：机翻，未校。
The Origins of DevOps: What’s in a Name?
As DevOps prepares for its second decade of existence, it might be worth a stroll down memory lane to revisit the origins of DevOps methods—and even the term itself.
随着DevOps为其存在的第二个十年做准备，可能值得沿着记忆之路漫步，重新审视DevOps方法的起源，甚至是这个术语本身。
Pre-2007: A Perfect Storm of Events 2007年之前：一场完美的事件风暴
Prior to 2007, a series of circumstances came together that would eventually give birth to what we know today as DevOps.
在 2007 年之前，一系列情况汇集在一起，最终诞生了我们今天所知道的 DevOps。
“Lean manufacturing” was already well-established as a set of best practices for manufacturing. Often branded as the “Toyota Manufacturing Method,” lean manufacturing strives for process optimization across the manufacturing floor. (Sidebar: Toyota leaders were originally inspired by the ingenious assembly line methods introduced by Ford Motor Company.) “Continuous improvement” is the mantra for lean manufacturing and practitioners continually evaluate ways to:
“精益生产”已经作为一套制造业的最佳实践得到了广泛的认可。精益制造通常被称为“丰田制造方法”，致力于在整个制造车间进行流程优化。（侧边栏：丰田的领导者最初受到福特汽车公司推出的巧妙装配线方法的启发。“持续改进”是精益生产的口号，从业者不断评估以下方法：
- Keep inventory at a minimum. Lean manufacturing means minimal inventory on hand: raw materials (materials used to produce goods) and finished inventory (completed products waiting to be assigned to an order and/or shipped).
将库存保持在最低限度。精益生产意味着手头的库存最少：原材料（用于生产商品的材料）和成品库存（等待分配给订单和/或发货的已完成产品）。 - Minimize the queue of orders. Ideally, orders received should move immediately into fulfillment mode. A key metric of lean manufacturing will always be “order to ship” time.
最小化订单队列。理想情况下，收到的订单应立即进入履行模式。精益生产的一个关键指标始终是“从订单到发货”的时间。 - Maximize efficiency in the manufacturing process. Process re-engineering and improved automation will marry into a goal to produce goods as quickly as possible. Each station of operation along the way (cut, weld, assemble, test, etc.) is evaluated for inefficiencies.
最大限度地提高制造过程中的效率。流程再造和自动化程度的提高将实现一个目标，即尽快生产产品。沿途的每个操作站（切割、焊接、组装、测试等）都经过评估，以确定是否存在效率低下。
In IT, traditional waterfall methods of application development were already giving way to rapid, iterative methods such as agile. “Speed” was the battle cry, even if quality output was occasionally compromised in the pursuit of rapid development and deployment. Similarly, on the operations and infrastructure side of IT, Cloud Computing and, in particular, infrastructure as a service (IaaS) and platform as a service (PaaS) were coming into their own as mature service offerings.
在 IT 领域，传统的瀑布式应用程序开发方法已经被敏捷等快速迭代方法所取代。“速度”是战斗口号，即使在追求快速开发和部署的过程中，质量输出偶尔会受到影响。同样，在IT的运营和基础设施方面，云计算，特别是基础设施即服务（IaaS）和平台即服务（PaaS）正在成为成熟的服务产品。
Finally, a fledgling set of tools classified as “continuous integration (CI)” tools began to emerge. The notion of CI tools was birthed and branded by Grady Brooch back in 1991 in his Brooch Method.
最后，一套被归类为“持续集成（CI）”工具的新兴工具开始出现。CI 工具的概念是由 Grady Brooch 于 1991 年在他的 Brooch Method 中诞生并打上烙印的。
2007-2008: A Frustrated Belgian 2007-2008： 一个沮丧的比利时人
Belgian consultant, project manager and agile practitioner Patrick Debois took on an assignment with a Belgian government ministry to help with data center migrations. In particular, his role was in certification/readiness testing. His duties required him to straddle activities and relationships between the application development teams and the operations teams (server, database network). His experiences—and frustrations over the walls of separation and lack of cohesion between application methods and infrastructure methods—planted seeds of discontent for Debois. His desire for a better way would soon lead him to action.
比利时顾问、项目经理和敏捷实践者 Patrick Debois 在比利时政府部门接受了一项任务，帮助进行数据中心迁移。具体而言，他的角色是认证/准备测试。他的职责要求他跨越应用程序开发团队和运营团队（服务器、数据库网络）之间的活动和关系。他的经历——以及对应用方法和基础设施方法之间缺乏凝聚力的隔离墙的挫败感——为 Debois 埋下了不满的种子。他对更好方法的渴望很快导致他采取行动。
In 2008, at the Agile Conference in Toronto, Andrew Schafer posted an offer to moderate an ad hoc “Birds of a Feather” meeting to discuss the topic of “Agile Infrastructure.” Only one person showed up to discuss the topic: Patrick Debois. Their discussions and sharing of ideas with others advanced the concept of “agile systems administration.” In that same year, Debois and Shafer formed an Agile Systems Administrator group on Google, with limited success.
2008 年，在多伦多的敏捷大会上，Andrew Schafer 提出了一个提议，希望他能主持一个临时的“Birds of a Feather”会议，讨论“敏捷基础设施”这个话题。只有一个人来讨论这个话题：帕特里克·德布瓦。他们与他人的讨论和分享想法，推动了“敏捷系统管理”的概念。同年，Debois 和 Shafer 在 Google 上成立了一个敏捷系统管理员小组，但收效甚微。
2009: The Case for Dev and Ops Cooperation 2009 年：开发和运营合作的案例
At the O’Reilly Velocity Conference, two Flickr employees—John Allspaw, senior vice president of technical operations, and Paul Hammond, director of engineering—gave a now-famous presentation titled, “10+ Deploys per Day: Dev and Ops Cooperation at Flickr.” The presentation had a dramatic flair to it, as Allspaw and Hammond would role-play the contentious interplay between representatives of Development and Operations during a typical software deployment, along with all the finger-pointing/blame that goes on, such as, “It’s not my code, it’s your machines!” Their presentation made the case that the only rational way forward is for application development and operations activities to be seamless, transparent and fully integrated. Over time, this presentation has reached legendary status, and is historically viewed as the seminal moment in time for that called out to the IT industry for methods that we now know as DevOps.
在 O’Reilly Velocity 大会上，两位 Flickr 员工——技术运营高级副总裁 John Allspaw 和工程总监 Paul Hammond——做了一场现在著名的演讲，题为“每天 10+ 次部署：Flickr 的开发和运营合作”。这个演讲有一种戏剧性的气息，因为Allspaw和Hammond将扮演一个典型的软件部署过程中开发和运营代表之间有争议的相互作用，以及所有的指责/责备，例如，“这不是我的代码，这是你的机器！他们的介绍表明，唯一合理的前进道路是使应用程序开发和运营活动无缝、透明和完全集成。随着时间的流逝，这个演讲已经达到了传奇的地位，并且在历史上被视为一个开创性的时刻，它呼吁IT行业采用我们现在所知的DevOps方法。
Unable to attend in person, Debois watched the Allspaw/Hammond presentation by video stream. He was inspired, and—at the prompting of others through social media—formed his own conference called Devopsdays in Ghent, Belgium. By this point in time, the term “DevOps” had officially landed in the history books.
由于无法亲自参加，Debois 通过视频流观看了 Allspaw/Hammond 的演讲。他受到启发，在其他人通过社交媒体的推动下，在比利时根特成立了自己的会议，名为Devopsdays。至此，“DevOps”一词已正式载入史册。
2010: DevOps in the United States 2010 年：美国的 DevOps
With a growing constituency, a Devopsdays conference is held for the first time in the United States in Mountain View, California, on the heels of the Velocity annual conference. Fast forward to 2018: There are more than 30 Devopsdays conferences already scheduled for 2018, including dozens across the United States.
随着选区的不断壮大，在Velocity年会之后，Devopsdays会议首次在美国加利福尼亚州山景城举行。快进到 2018 年：2018 年已经安排了 30 多场 Devopsdays 会议，其中包括美国各地的数十场。
2013: ‘The Phoenix Project’ 2013年：《凤凰计划》
For many of us, another noteworthy moment in the history of DevOps was the publishing of the book, “The Phoenix Project,” written by Gene Kim, Kevin Behr and George Spafford. This fictional novel tells the story of an IT manager thrust into a seemingly hopeless situation, as he’s charged with salvaging a mission-critical ecommerce development project that’s gone off the rails. His mysterious mentor, a board member steeped in the disciplines of lean manufacturing, guides the main character into new ways of thinking about IT and application development, introducing the concept of DevOps along the way.
对于我们中的许多人来说，DevOps历史上另一个值得注意的时刻是由Gene Kim、Kevin Behr和George Spafford撰写的《凤凰计划》一书的出版。这部虚构的小说讲述了一名 IT 经理陷入看似绝望的境地的故事，因为他被指控挽救一个偏离轨道的关键任务电子商务开发项目。他的神秘导师是一位深谙精益制造学科的董事会成员，他引导主角采用新的思维方式来看待 IT 和应用程序开发，并在此过程中引入 DevOps 的概念。
(Sidebar: The Phoenix Project helped inspire us to write “Outsource or Else!” a similar business fable in which a VP of Software uses DevOps when outsourcing development of a major new product.)
（侧边栏：凤凰项目激发了我们写“外包否则！”的灵感，这是一个类似的商业寓言，其中软件副总裁在外包主要新产品的开发时使用DevOps。
DevOps for the Future 面向未来的 DevOps
It’s reasonable to describe DevOps as a journey, or perhaps an aspiration, rather than defined destination. DevOps, like lean manufacturing, seeks continuous improvement, seeking higher output, greater efficiencies and even continuous deployment. Automated tools that support DevOps continue to evolve.
将DevOps描述为一个旅程，或者可能是一个愿望，而不是定义的目的地，这是合理的。DevOps和精益制造一样，追求持续改进，追求更高的产出、更高的效率，甚至持续部署。支持 DevOps 的自动化工具不断发展。
Much has been accomplished since the inception of DevOps in the last decade and we expect to see even more in 2018 and beyond.
自DevOps成立以来，在过去十年中已经取得了很多成就，我们预计在2018年及以后将看到更多。
— Steve Mezak
via：
-
The Origins of DevOps: What’s in a Name? - DevOps.com By: Steve Mezak on January 25, 2018
https://devops.com/the-origins-of-devops-whats-in-a-name/
什么是 DevOps？看这一篇就够了！
本文作者：Daniel Hu
一、前因
我是一个 “DevOps 工程师”，于是总会遇到有人问我：“什么是 DevOps？”
这个问题看似特别基础，基础到很多人懒得回答。但其实冷静一秒，问自己一句 “什么是 DevOps？” 可能每个 DevOps 工程师都知道 “什么是 DevOps”，但是他们给出的答案不尽相同。
所以我会怎么回答这个呢？下面我们展开来聊聊。
特别强调：本文仅代表我个人现阶段的粗浅认知，本文观点不代表 思码逸 公司也不代表 DevStream 团队。
二、记忆
我第一次看到 DevOps 这个词，大概是在 2016 年的秋天。那时候我在 H3C 从事云计算研发相关工作。记得我接到的第一个任务是研究 OpenStack 的一个 CICD 相关的组件，叫做 Solum，那是我第一次知道什么是 CICD，第一次看到 DevOps 这个词。没错，只是看到 DevOps，但是我无法记住 DevOps 的定义。或者说，当时我甚至没有找到一个清晰易懂的关于 DevOps 的定义。可能很多人和我当年一样，对 DevOps 的印象，就是Dev + Ops。
2018 年的夏天，我开始在太保成研任云平台 PaaS 组负责人，兼任太保云 CMO (Configuration Management Officer) 一职。没错，我依旧是一个 “云平台研发工程师”，但是再一次与 DevOps 结缘。太保云的 CMO，简单说就是负责太保云平台的源码管理、研发协作流程、版本管理、CICD、制品管理、发版流程等等。这个时候我其实已经开始研究一些 DevOps 相关的工具了，比如 GitLab、Jenkins、禅道、Artifactory、Nexus 等等；同时也在主导一些 DevOps 文化层面的建设，比如怎样的模式或行为在团队里是被鼓励的，怎样的事情是被禁止的…… 不过我只是在制定规则，而没有意识到这是 “文化”。总之，那几年我也算是投身于 DevOps，致力于提升团队研发效率、交付效率与交付质量，但是同时我没有去仔细思考过 “什么是 DevOps？” 这个问题，我也没有刻意去思考过自己是不是在玩 DevOps。
去年 (2021 年) 年底，我加入了 思码逸，我的 title 第一次从 “xxx 云平台研发工程师” 变成了 “xxx DevOps 工程师”（xxx 表示初级、中级、高级等）。那天我开玩笑说：“以前，我在云原生领域兼职玩 DevOps；以后，我在 DevOps 领域兼职玩云原生”。
好吧，这会我是名正言顺的 “xxx DevOps 工程师” 了，我总该知道 “什么是 DevOps” 吧！
三、他们说……
我们先来看一下几家典型的公司是如何定义他们眼中的 DevOps 的，包括：
- Atlassian（代表产品：Jira、Trello 等）
- 微软
- AWS
3.1、Atlassian 回答 “什么是 DevOps？”
Atlassion 有一篇题为 DevOps 的文章，里面有这样一句话：
DevOps is a set of practices, tools, and a cultural philosophy that automate and integrate the processes between software development and IT teams. It emphasizes team empowerment, cross-team communication and collaboration, and technology automation.
我尝试翻译一下：DevOps 是一系列 实践、工具 和一个融合开发及 IT 团队的 文化理念。DevOps 强调赋能团队、跨团队沟通与协作以及技术自动化。
可以看到 Atlassian 给的等式是：
DevOps = 工具 + 实践 + 文化
Atlassian 还提到一个 DevOps 团队包含了开发和 IT 运维，大家一起协作，共同参与产品的整个生命周期，一起为提升软件质量和加速软件开发过程而努力。DevOps 模式下开发和运维不再是独立的 “筒仓”，而是几乎被整合成一个团队，这个团队的工程师技术栈会覆盖开发、测试、运维等。同时 DevOps 团队会利用一系列的 DevOps 工具链来实现诸如持续集成、持续发布、流程自动化、高效协作等等目的。
Atlassion 给的 “无穷环” 长这样：
用 “无穷环” 表示 DevOps 生命周期，是因为 DevOps 的根本理念是 “持续”，也就是 “没有终点”。Atlassion 将整个 DevOps 生命周期分成 6 个阶段，分别是：
- 计划（Plan）
- 构建（Build）
- 持续集成和部署（或者交付）（Continuous Integration and Deployment or Delivery）
- 监控和告警（Monitor and Alert）
- 运维（Operate）
- 持续反馈（Continuous Feedback）
另外从这个环里我们还能看到 Atlassian 想强调沟通与协作是贯穿 DevOps 生命周期全过程的。
3.2、微软回答 “什么是 DevOps？”
微软这篇 Introduce the foundation pillars of DevOps: Culture and Lean Product 我特别喜欢！这个标题的意思是 “介绍 DevOps 的基柱：文化和精益产品”。
文章第一句话：
DevOps is the union of people, process, and products to enable continuous delivery of value to our end users.
DevOps 是人、过程和产品的结合，使能持续地向终端用户交付价值。
微软还提到：
Typically, the goal for Development is to deliver more features faster, and the goal of Operations is to achieve better system stability. DevOps aligns these disciplines by using a framework of best practices proven to increase speed to market while improving system stability.
多数情况下，开发的目标是快速发布更多的新特性，而运维的目标是保证更高的系统可用性。DevOps 通过切实可行的最佳实践体系来拉齐这两个目标，在提升系统稳定性的同时加速产品交付到市场的速度。
这里微软可以看到微软给的第一个等式：
DevOps = 人 + 过程 + 产品
然后微软从 “人 + 过程 + 产品” 进一步提炼了 DevOps 的 4 大基柱：文化、精益产品、架构和技术。
也就是：人 + 过程 + 产品 -> 文化、精益产品、架构 + 技术
微软给的 “无穷环” 长这样：
图里描绘的 DevOps 生命周期还是分成 6 个阶段，分别是：
- 计划（Plan）
- 构建（Build）
- 持续集成（Continuous Integration）
- 部署（Deploy）
- 运维（Operate）
- 持续反馈（Continuous Feedback）
外加贯穿整个 DevOps 生命周期全过程的 “协作（Collaboration）”。
在图外，微软还定义了对其而言 DevOps 的 8 大能力：
- 持续计划（Continuous Planning）
- 持续集成（Continuous Integration）
- 持续发布（Continuous Delivery）
- 持续运维（Continuous Operations）
- 持续质量（Continuous Quality）
- 持续安全（Continuous Security）
- 持续协作（Continuous Collaboration）
- 持续改进（Continuous Improvement）
- 每次看到这里我总觉得微软的图该更新一版 *。
另外微软有一句特别有深度总结：
What is new? Continuous Everything. The process is a journey and requires a growth mindset to continually evolve and improve.
“Continuous Everything”，铿锵有力！微软强调 DevOps 过程是一段没有终点的旅途，要求我们抱着成长的观念模式，持续地改进，永不满足。
3.3、AWS 回答 “什么是 DevOps？”
不难猜到，AWS 也有 一篇文章 来回答 “What is DevOps?”
DevOps is the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity.
DevOps 是文化理念、实践和工具等的组合，能够提升一个组织快速交付应用和服务的能力。
这里 AWS 给了一个等式：
DevOps = 文化 + 实践 + 工具
不过这篇文章里 AWS 不落俗套，没有画一个自己的 “无穷环”，而是给了这样一张图：
这里提到了：
- 构建（Build）
- 测试（Test）
- 发布（Release）
- 监控（Monitor）
- 计划（Plan）
还可以看到这个 “交付管道” 和 “反馈环” 连接的是 “企业” 和 “客户”，可见 AWS 希望强调 “DevOps 的目的是更快地向客户交付”。
四、DevOps 文化
我曾一度片面以为 DevOps 要解决的问题就只是工具问题，也就是如何选择或者开发好用的 DevOps 工具 or 平台，从而提升企业内部整个研发生命周期的运行效率。不记得是哪一天，我突然有一个强烈的想法：工具只是工具而已，文化建设才是成败的关键！
文化决定了我们如何去做事，工具决定了，决定了啥？可能啥也决定不了。因为我认为工具也是被文化所决定的。
4.1、什么是文化？
简单说，文化就是一个组织的社交遗产，也就是一个组织对于其成员的各种行为的响应模式。
比如当我们说一个企业有 “加班文化” 时，其实是在说在这个企业内，员工加班会得到奖赏，而不加班会受到惩罚。或者我们说一个企业是 “狼性文化”、“奋斗者文化”…… 不同的文化背后对应的也就是这个企业对于员工不同行为的不同响应模式。
一个企业的文化决定了在这个企业内：
- 什么事情是对的，什么事情是错的；
- 什么事情是重要的，什么事情是不重要的；
- 什么事情是值得做的，什么事情是不值得做的。
所以文化决定了一个企业会去招聘哪些人，会开除哪些人，会提拔哪些人。
看到这里可能你已经在思考自己呆过的企业对员工有哪些要求，在鼓励什么，在惩罚什么…… 没错，此刻在你脑海中闪现的一幕幕就是企业文化。
4.2、什么是 DevOps 文化？
这幅图大家肯定都不陌生：
什么是 DevOps 文化？
其实从这幅图中我们就能看到文化的影子。我们都知道 DevOps 强调打通开发团队与运维团队的壁垒，要求两个团队拉齐认知与责任，不再各自为战，而是一起为更快地交付更高质量的产品而努力。没错，这就是最基础的 DevOps 文化。
那么如何拉齐认知与责任呢？
首先可以确认的是，我们在组织架构上直接融合 Dev 和 Ops 团队，这并不是一个 DevOps 团队。人是不是坐在一起，改变的只是沟通的效率。这里我想强调两点：
- 责任共担，在一个 DevOps 模式组建团队里，每个人都需要为软件开发交付的整个生命周期而负责；
- 技能共享，通过持续学习，互相学习，让本是传统 Dev 的工程师学习 Ops 的技能，同时传统 Ops 的工程师也需要学习 Dev 的技能。
Dev 与 Ops 互相学习彼此领域技能，每个人都懂开发又懂运维，抱着 “成长的观念”，持续学习，不满足于当前已掌握的技术栈。
但是我们也需要意识到不能要求每个工程师都精通开发与运维，这是不可能的。这里说的 Dev 掌握 Ops 能力，更多的是 Dev 能够借助完善的工具链从而掌握 “应用运维” 的能力，能够在自己完成开发之后，有能力和权限将应用部署上线，同时线上应用出问题后，能够直接对其负责，定位、修复、更新升级等。而一些基础设施的运维能力需要独立出来考虑，比如机房里的局域网配置、虚拟机挂 NAS 盘等传统运维能力。
同理 Ops 需要理解应用开发的生命周期，知道 Dev 的痛点，尤其是在流程上的痛点，比如怎样提升应用的构建速度，怎样优化应用的 cd 流程等，Ops 要关注应用的 “生产过程”，进而发力去优化这个过程或相应的工具，让应用能够更可靠更快速地完成 cicd 流程等，更容易地部署上线或者对外交付。也就是说我们并不是要求 Ops 也去写业务代码，而是协助 Dev 去解决业务代码之外的痛点，让 Dev 能够更加专注于业务功能实现。
最后，一个 DevOps 模式组件的团队中每个人都为整个软件研发生命周期的速度和质量负责，每个具体的角色就像一个大头钉，底部很宽，代表着技术面广，关注整个软件研发生命周期的所有环节；同时顶部很高，在某个环节里专注，做好做精。
DevOps 成功落地的关键是什么？
我们前面说到的 “其乐融融” 的场景，我们希望 Dev 和 Ops 能够互相学习，共担责任，一起为更快更好地交付产品而努力。但是，工程师们为什么要这样做？他们的动力在哪里？
4.3、领导与激励
Gartner 曾出过一个分析报告，表明在 2023 年，90% 的 DevOps 改革将会失败（相较于预期）。而失败的主要原因是领导层管理方法的局限。
其实这是显而易见的，DevOps 可以称为一种 “改革”，而很多人是抵触 “变化”，抵触 “新事物” 的。比如 DevOps 鼓励接受失败，快速失败，从失败中学习经验，进而在更长的时间维度上争取更大的成功。但是可能你遇到的刚好是一个 “失败惩罚型” 领导，那么你的团队就会惧怕失败，从而放弃创造与尝试新技术，选择安于现状。
一个技术团队的领导首先自己需要懂技术，有丰富的经验，这是基础要求。但是除此之外，更重要的是团队领导能够激励整个团队，去发挥整个团队的主观能动性，让所有团队成员都能够有动力持续学习，快速学习，同时也能够敢于失败，快速失败且不惧怕失败，把失败当做一个学习的机会，进而不断成长，让整个团队的战斗力能够越来越强。
所以领导怎样激励工程师呢？
福利？比如一些大厂提供的免费零食或者定期的下午茶？免费的咖啡或者午餐？
没错，作为一个工程师，这一切的福利都会让其开心，但是其实无法激励其更加认真努力地工作。工程师的薪资水平普遍不低，所有这些零食也好，咖啡也好，大概率不会到其月薪的零头。同理，工程师找工作时，看重的也绝不会是一个企业是否提供免费午餐和下午茶。
那么工程师看重的是什么？
在选择一家企业的时候，可能工程师第一个考虑的是薪资，剩下的可能是成长的空间、工作内容是否感兴趣等等等等。但是进入一家公司以后，真正开始工作的时候，工程师看重的是什么？我认为可能是：
-精通
-自驱
-目标
我们逐个来解释一下。
1. 精通
我们在某个工作方向做的好，我们擅长某个技术方向，进而很好地完成相应的工作，这时候我们会有一种成就感，满足感，我们会觉得自己得心应手，同时大概率会获得认可，赞扬，因此接下来的时间里我们就更加愿意在这个方向上继续努力，做的更好。也就是说一个工程师能够有机会专注于自己精通的技术上发力，那么他大概率会感受到激励。
反例是什么呢？比如你是一个 Java 工程师，但是你的领导擅长 PHP，并且觉得 PHP 是世界上最好的语言，于是要求整个团队转向使用 PHP，这时候你会放弃自己研究多年的 Java 技术栈，努力学习 PHP 并决心干出一番成绩吗？
2. 自驱
我们希望组建一个学习型、创造型的团队，每个人能够持续成长，乐于创新，自我驱动。这就需要领导能够允许团队花时间去学习，去输入，而不是一味地输出，每时每刻汇报自己写了几行代码。同时这也要求领导自身勇于接受新事物，拥抱变化，而不是 “不求有功，但求无过”。举个例子：假如你的领导最担心的是线上应用出事故，并且他认为稳定的第一要素就是不要引入新技术，新工具，那么这时候你的领导也不会在意你是不是有时间学习，也不会允许你花时间去研究新技术，因为这一切只会带来不稳定。如果领导害怕失控，因而拒绝创新，那么这样的团队成员也就只能满足于实现日复一日的常规需求开发迭代，而不会享受技术，自我驱动，拥抱创新。
3. 目标
显而易见，团队每个成员都需要知道自己为什么做？目的是什么？目标是什么？而不是领导心里藏着一个目标，然后简单地指挥团队成员完成一件件具体的零散的工作项。如果团队成员只知道今天需要完成事务 A，明天需要完成事务 B，而不知道为什么要做，最终要做成什么样，那么大家只会满足于机械地完成任务，而不会有动力追求 “如何做得更好”。
五、总结
所以 DevOps 是什么？
我尝试给出我的答案：
DevOps 是一种文化理念、工具与实践的结合，目的是更快更可靠地向用户持续交付价值。其中最重要的是文化，文化要求 Dev 和 Ops 团队责任共担，目标一致，也要求整个团队持续学习，抱着成长的心态，Continuously Everything。其次 DevOps 离不开高效的工具集，工具是自动化的基础。最后我们要在各个环节追求最佳实践，不管是工具的使用，还是团队的协作模式，沟通方法上面。
最后，关于标题 “什么是 DevOps？看这一篇就够了！”，我想告诉你，DevOps 文化里不存在 “够了”，所以我不得不承认，我撒谎了。本文只代表我个人现阶段的粗浅认知，我建议你查阅更多的资料，持续学习，永不满足。当然如果本文对你有一点点的帮助，那么我很满足。
via:
-
什么是 DevOps？看这一篇就够了！- 博客园 玩转 DevOps 和研发效能 posted on 2022-08-04 11:43
https://www.cnblogs.com/DevLake-DevStream/p/what-is-devops.html
