DevOps 到底是什么？
已发表: 2022-03-11时间简史
为了理解 DevOps，我们必须回到过去只有程序员的时代。
正如道教我们：
古代的程序员是神秘而深刻的。 我们无法理解他们的想法，所以我们所做的只是描述他们的外表：
- 觉知，如渡水的狐狸
- 警觉，像战场上的将军
- 亲切，就像女主人迎接客人一样
- 简单，就像未雕刻的木块
- 不透明，就像黑暗洞穴中的黑色水池
程序员诞生了机器语言。 机器语言催生了汇编程序。 汇编器催生了编译器。 现在有成千上万种语言。 每种语言都有其目的，无论多么谦虚。 每种语言都表达了软件的阴阳。 每种语言在软件中都有自己的位置。
当时，软件开发办公室大多被称为实验室，程序员是科学家。 为了创建一个好的应用程序，程序员必须完全理解应用程序要解决的问题。 他们必须知道应用程序将在哪里使用以及运行它的系统类型。 从本质上讲，程序员对他们的应用程序从规范到开发，再到部署和支持都了如指掌。
然后人性开始发挥作用，我们开始要求更多。 更快的速度，更多的功能，更多的用户，更多的一切。
作为谦虚、谦逊、和平的生物，程序员几乎没有机会在如此大量的有需要的用户总是要求更多的情况下生存下来。 获胜的最佳机会是开始向不同的方向发展，并创造种姓。 很快，程序员作为开发人员、软件工程师、网络管理员、数据库开发人员、Web 开发人员、系统架构师、QA 工程师等新品种的祖先而灭绝。 快速发展和适应外部世界的挑战成为他们 DNA 的一部分。 新种姓可能会在几周内进化。 Web 开发人员变成了后端开发人员、前端开发人员、PHP 开发人员、Ruby 开发人员、Angular 开发人员……这一切都下地狱了。
很快他们都忘记了他们来自同一个父亲，一个程序员。 一个单纯而平和的科学家，只想让世界变得更美好。 他们开始互相争斗，声称他们每个人都是“程序员”的真正后裔，并且他们的血统比其他人更纯洁。
随着时间的流逝，他们将互动减少到最低限度，只在真正需要时才相互交谈。 他们不再为远方家人的成功庆祝，最终甚至不再每隔一段时间就寄一张明信片。
如果他们只探寻自己的感受，就会发现程序员的火花就在他们心中，等待着闪耀，为银河系带来和平。
在他们自私和以自我为中心的征服世界的竞赛中，程序员的后代忘记了他们工作的真正目的——为他们的客户解决问题。 客户开始感受到项目延迟、成本过高甚至失败等行为的痛苦。
每隔一段时间，一颗璀璨的星星就会闪耀，有人会得到灵感，试图在后裔之间建立和平。 他们想出了瀑布。 这是一个绝妙的想法，因为它利用了不同开发人员组仅在必要时进行交流的事实。 当一组完成他们的部分工作时，它会与下一组进行沟通，将工作发送到整个过程中，并且从不回头看。
这工作了一段时间，但像往常一样，人类（客户）再次想要更多。 他们想更积极地参与到软件开发的整个过程中，更频繁地发表意见，甚至在为时已晚的情况下要求更改。
软件项目变得如此容易失败，以至于它被接受为行业标准。 统计数据显示，超过 50% 的项目都失败了，似乎没有什么可做的（ZDNet、CNet）
每一代人都有一些思想开放的人，他们知道所有这些开发人员群体都必须找到一种方法来一起工作、沟通并保持灵活性，以确保他们的客户将获得最好的解决方案。 早在 1957 年，伟大的约翰·冯·诺依曼 (John Von Neumann) 的同事就已经有这些尝试的痕迹。 然而，我们不得不等到 2001 年初才开始革命，当时十几个肮脏的人创建了敏捷宣言。
敏捷宣言基于十二项原则：
- 通过早期和持续交付有价值的软件来满足客户的需求
- 欢迎不断变化的需求，即使是在后期开发中
- 工作软件经常交付（几周而不是几个月）
- 业务人员和开发人员之间密切的日常合作
- 项目是围绕有动力的个人建立的，他们应该被信任
- 面对面交谈是最好的沟通方式（同地办公）
- 工作软件是衡量进度的主要标准
- 可持续发展，能够保持恒定的步伐
- 持续关注卓越的技术和良好的设计
- 简单——最大化未完成工作量的艺术——是必不可少的
- 自组织团队
- 定期适应不断变化的环境
敏捷宣言是为银河带来和平和恢复原力平衡的第一步。 很长一段时间以来，第一次在软件开发过程中连接所有利益相关者是基于文化和“人”的方式，以及程序化和机械化的方式。 人们开始互相交谈，定期见面，并一直在交流想法和评论。 他们意识到他们的共同点比他们想象的要多得多，客户也成为了团队的一部分，而不仅仅是一些外部因素，这些因素预计会寄钱而不会问任何问题。
还有一些障碍需要克服，但未来似乎比以往任何时候都更加光明。 敏捷意味着开放并愿意适应不断的变化。 然而，由于变化太多，很难专注于最终目标和交付。 这就是精益软件开发如何实现的。
迷上了 LSD（双关语）并冒着被流放和被抛弃的风险，一些后代在他们的种姓和软件行业之外寻找解决方案。 他们在一家大型汽车制造商的工作中找到了救赎。 丰田生产系统的简单性令人惊叹，它的精益制造可以很容易地应用于软件开发。
精益有7个原则：
- 消除浪费
- 建立质量
- 创造知识（扩大学习）
- 推迟承诺（尽可能晚地决定）
- 尽快交付
- 尊重人（授权团队）
- 优化整体
除了敏捷之外，精益原则支持心态和专注于做正确的事情，同时在整个过程中保持灵活性。
一旦软件开发团队采用了敏捷和精益，只需再迈出一步，就可以将整套原则应用到整个 IT 中——这最终将我们带到了 DevOps！
进入 DevOps - 三车道高速公路
软件开发团队的老派观点包括业务分析师、系统架构师、前端开发人员、后端开发人员、测试人员等等。 优化软件开发过程，包括敏捷和精益原则，主要集中在这些方面。 一旦应用程序“生产就绪”，它就会被发送给“运维”，包括系统工程师、发布工程师、DBA、网络工程师、安全专业人员等。消除Dev和Ops之间的长城是DevOps的主要驱动力。
DevOps 是对整个 IT 价值流实施精益原则的结果。 IT 价值流将开发延伸到生产，结合了原始程序员的所有“远亲”。
Gene Kim 对 DevOps 解决方案给出了最好的解释，如果你还没有读过The Phoenix Project ，我建议你花点时间去做。
你不应该雇佣 DevOps 工程师，并且 DevOps 不应该是你 IT 中的一个新部门。 DevOps 是一种文化和思维方式，它是整个 IT 的一部分。 没有任何工具可以让您的 IT 成为DevOps 组织，也没有任何级别的自动化能够使您的团队能够为您的客户提供最大价值。
DevOps 通常被称为三路方法，但我将它们视为同一条高速公路的三个车道。 您从第一车道开始，然后加速并切换到第二车道，最终您在第三车道超速行驶。
第一道 - 整个系统的性能是主要焦点，强调系统任何单个元素的性能
通道二 - 确保有一个恒定的反馈循环向上游发送，并且不被忽略
第三道 - 培育实验，不断改进，快速失败
第一道 - 加快速度
了解整个系统的重要性并正确确定工作项的优先级是 IT 组织在采用 DevOps 原则时必须学习的第一件事。 不允许 IT 价值流中的任何人制造瓶颈并减少工作流程。
确保不间断的工作流程是流程中每个人的最终目标。 无论一个人或一个团队扮演什么角色，他们都必须寻求对系统的深刻理解。 采用这种思维方式对质量有直接影响，因为缺陷永远不会发送到下游，因为它们会导致瓶颈。
确保工作不会停滞是不够的。 一个富有成效的组织应该始终寻求增加流量。 有许多方法可以增加流量。 您可以在约束理论、六西格码、精益或丰田生产系统中找到解决方案。 随意选择其中任何一个，想出自己的，或将它们组合起来。
DevOps 原则并不关心您属于哪个团队，如果您是系统架构师、DBA、QA 或网络管理员。 同样的规则适用于每个人，每个人都应该遵循两个简单的原则：
- 保持系统流程不间断
- 随时增加和优化工作流程
车道二 - 加速
不间断的系统流程是单向的，预计从开发到运营。 在理想的世界中，这意味着软件可以快速创建高质量、部署到生产环境并为客户提供价值。
但是，DevOps 不是乌托邦，如果可以实现单向交付，瀑布方法就足够了。 评估可交付成果和沟通流程对于确保质量非常重要。 第一个必须实施的“上游”沟通渠道是 Ops to Dev。
给自己打五分很容易，但寻求反馈并提供反馈是了解真实情况的方式。 当务之急是下游的每一个小步骤都必须有一个即时的上游确认。
如何建立反馈循环并不重要。 您可以邀请开发人员加入支持团队会议，或让网络管理员参与每周的 sprint 计划。 只要您的反馈到位，并且评论得到处理和处理，您的组织就会加快 DevOps 的发展速度。
车道三 - Warp 10
DevOps 快车道不适合弱者。 要进入 DevOps 快车道，您的组织必须足够成熟。 这一切都是关于冒险和从失败中学习，不断尝试，并接受重复和实践是掌握的先决条件。 您经常会听到 Kata 这个词，这是有原因的。 持续的训练和重复会导致精通，因为它使复杂的动作成为例行公事。
但是在你开始组合动作之前，你必须先掌握每一个单独的步骤。
“适合师父的，不适合新手。 在超越结构之前，您必须了解道。”
DevOps 第三条路/快速通道包括每天分配时间进行持续试验，不断奖励团队承担风险，以及将故障引入系统以提高弹性。
为了确保您的组织在实施这些措施时不会崩溃，您必须在所有团队之间创建频繁的反馈循环，同时确保所有瓶颈都清晰，系统流程不中断。
实施这些措施可以让您的组织时刻保持警惕，并能够快速有效地应对挑战。
摘要 - DevOps 组织清单
这是一个清单，您可以使用它来验证DevOps 是如何启用您的 IT 组织的。 请随时对文章发表评论并添加您自己的观点。
- 开发团队和运营团队之间没有隔墙。 两者都是同一过程的一部分
- 从一个团队发送到另一个团队的工作始终经过验证且质量一流
- 没有“堆砌”的工作，所有的瓶颈都处理好了
- 开发团队没有将运营时间用于其活动，因为部署和维护是同一时间框的一部分
- 开发团队不会在周五下午 5 点交付部署代码，让运营部门在周末清理工作
- 开发环境是标准化的，操作可以很容易地复制和扩展它们到生产中
- 开发团队可以在他们认为合适的时候交付新版本，并且操作可以轻松地将它们部署到生产中
- 所有团队之间都有清晰的沟通渠道
- 所有团队成员都有时间进行实验并致力于改进系统
- 定期在系统中引入（或模拟）和处理缺陷。 从每个实验中吸取的经验教训都被记录下来并与所有相关人员分享。 事件处理是例行公事，主要以已知方式处理
结论
使用 Chef、Docker、Ansible、Packer、Troposphere、Consul、Jenkins、SonarQube、AWS 等现代DevOps 工具并不意味着您正在应用 DevOps 原则。 DevOps 是一种思维方式。 我们都是同一个过程的一部分，我们共享相同的时间并共同创造价值。 参与软件交付过程的每个人都可以加快或减慢整个系统的速度。 在开发过程中创建的错误可能会导致系统崩溃，以及错误的防火墙配置。
所有人都是 DevOps 的一部分，一旦您的组织了解这一点，帮助您管理它的工具和技术堆栈就会神奇地出现。