太多的错误，太多的时间投入生产功能，编码了数周，太多可避免的事件，今天每个人都意识到了：开发人员和运维必须相互交谈。好的。但是一旦我们说了那句话，具体我们该怎么做呢？本文的目的是告诉您更多有关DevOps 的信息，以及如何在业务中实施 DevOps。
DevOps 的主要原则
快速提醒DevOps 文化的基础和优势。
DevOps是“Dev”和“Ops”这两个词的缩写，但你可能已经知道了。DevOps 文化旨在打破开发新功能的开发人员和以网站可靠性为目标的运维人员之间的分离。Andrew Shafer 在 2008 年的一次会议上展示了一种先验的对立利益，该会议的一项计划已在全球范围内广为人知：“混乱之墙”。
DevOps 或持续部署的文化
DevOps 的目标是打破这个障碍和孤岛运作。这种协作涉及很多方式，我们将在本文后面讨论，但目标始终相同：让开发人员和运维人员协作以实现共同目标。
最终，这种合作的目标是在不改变质量的情况下更快地实施新功能。这称为持续部署。DevOps 的一个基本概念“反馈循环”说明了这个想法：
- 我部署我的功能；
- 我对它们进行运维；
- 我收集反馈；
- 我更正并部署了新功能。
开发人员的工作在哪里停止，Ops 的工作从哪里开始？
这是一个永恒的问题，无论组织采取什么措施，无论合作原则如何，我们都在谈论两种不同的职业。来自两个不同的技术堆栈。有时，两个位置之间的模糊区别会对您产生影响：
- 产品投入生产：责任重大，投入生产风险在发生事故时直接影响您的用户和您的业务。开发应该对他的增量负责吗？还是交给Ops 呢？因为他们负责稳定？
- 产品代码的质量：Ops 为开发人员提供了测试工具来检查其增量的质量。另一方面，开发人员不应该推卸责任“我编写我的代码，运维会管理它”
- 事后分析：每个事件都必须进行事后分析，对其进行分析并采取纠正措施。
从技术角度来看，问题也随之而来。示例：谁管理环境变量以及如何确保它们安全但不影响开发流程？
所有这些问题都需要解决。每个人都必须知道自己的角色和责任。游戏规则会随着时间而改变，但必须保持清晰并为每个人所知（接受）。
DevOps 的历史
2008 年的 Shafter 会议标志着 DevOps 的开始。
2009 年，第一届“DevOpsday”会议在比利时根特举行。它由敏捷组织顾问 Patrick Debois 创建，随后在国际上发展，并继续成为 DevOps 世界的支柱之一，计划于 2019 年举行 30 多个会议。
2012 年，Puppet 的 Alanna Brown 制作了第一份“ DevOps 状态”报告。几个月后，2013年，“凤凰计划”发布。这个短篇故事讲述了一位 IT 经理卷入了看似无望的情况中的故事。其成功的关键之一将是精益和 DevOps 概念的应用。本书将极大地促进 DevOps 文化的传播。
2019 年，据 IDC称，DevOps 方法是 IT 组织的一大趋势，但 DevOps 仍然只涉及 20% 的应用项目。据估计，2021年这一数字将增长到35%甚至40%。
DevOps 的好处
DevOps 方法将节省您的时间。很多时间。
小例子：
在我们的一位潜在客户的电子商务网站上，某些产品被展示了两次。内部团队花了 19 个工作日才找到原因：一个 cron 在两个不同的地方运行，但触及同一个数据库。Ops 有“cron 在哪里运行”的信息，而开发人员有“cron 正在做什么”的信息。从 2 个团队开始在同一个房间里解决这个 bug 的那一刻起，它在 2 小时内就解决了……
通常，DevOps 将允许您：
- 加快启动时间
- 降低风险
- 加速事件响应
- 提高客户的满意度
如何在公司实施 DevOps？
安排专门的协作时间
开发团队和 运维团队 是否有特定的时间进行协作？或者这是他们冲刺压力之外的额外负担？
我们可以将时间用于这种协作并促进在公司实施 DevOps 文化的一些示例：
设计工作坊：
新功能的设计或新技术的添加必须是开发者和运维探讨的主题。
训练时间：
运维设计的架构是否被开发人员正确使用？这个过程对他们来说容易吗，还是他们缺乏技术知识？尤其是如果您的技术团队的人员流动率很高，那么每周安排DevOps 工具的培训时间 可以解决很多问题。
用户测试：
你要对我说“在 DevOps 的世界中，用户测试必须做什么？？”。你错了。这个愿景可能很烦人，但您的开发人员是 Ops 所部署工具的用户，因此请检查这些工具是否实用并满足他们的需求。
有共同的目标
运维人员和开发人员一起工作的另一种方法是为他们设定共同的目标。这创造了一个良性循环，其中一些人的成功就是其他人的成功，并且每个人都有合作的兴趣。
目标示例：每周 1 次发布，应用程序停机时间为 0
团队设置奖励和庆祝活动，为健康有效的 DevOps 协作奠定基础。
在运营中发展客户文化
这有点反传统，但 Ops 团队是一个跨职能的支持团队，因此有自己的用户。在内部，对于大部分任务，运维团队都有“客户”。您必须在基础架构团队中培养客户服务文化：
- 了解开发者问题
- 根据他们的需求调整解决方案
- 考虑他们的反馈
这是一种思维方式的转变，在 DevOps 文化尚未得到很好实施的许多公司中很难。我们也不能陷入一种不健康的沟通模式，开发人员使用这个“客户”标签来主导 Ops 团队。但是，在 Ops 团队中培养服务文化和客户满意度将提高质量、交付速度以及 Ops 和开发人员之间的沟通。
DevOps 与其他组织方法之间的关系
敏捷： DevOps 通常被视为将敏捷应用于生产世界的一种方式。应用于开发的敏捷方法缩短了用户需求与开发团队之间的距离。DevOps 可以被视为一个附加组件，允许开发团队将新功能快速投入生产。
ArchOps： DevOps 的扩展，从软件架构开始，而不是从部署操作的代码开始。
DataOps：将持续部署和 DevOps 应用于数据分析。DataOps 寻求将数据工程、数据集成、数据安全和数据私有化与运营 (Ops) 相结合。
站点可靠性工程师 (SRE)：站点可靠性工程是 Google 自 2003 年以来开发的一种方法，旨在不断推出新功能，同时保持基础设施的高质量和可用性。DevOps 和 SRE 涵盖了大致相似的问题。
WinOps： WinOps 是用于围绕 Windows 环境的 DevOps 实践的术语
