从业务角度来看，DevOps 是什么？

如果您在我们的应用程序名称中看到"DevOps"，这意味着我们必须正确解释该术语，我们会这样做，但角度会有所不同。让我们从业务角度看看 DevOps 是什么。

首先你应该知道，DevOps 没有明确的定义。是的。

大多数情况下，DevOps 的特点是关键原则：共享所有权、工作流程自动化和快速反馈。

而且，你可能已经听过"咒语"：

DevOps 不是一个角色。

您可以在 DevOpsKube 网站上查看精彩文章 -什么是 DevOps？它到底意味着什么？

如果你想要摘要：

DevOps 是一种文化或理念，旨在弥合开发和运营团队之间的差距，通过自动化基础设施、代码部署和应用程序的持续监控来提高生产力和协作。

这个辩护有什么问题吗？这是技术性的。而且完全不顾生意！

工程师们经常忘记"所有 IT"都与 IT 有关，而与业务有关。我们忘记了我们所做的所有那些精彩的事情，并不是"因为我们可以"，而是因为一些赚钱的企业需要它。

如果我说从业务角度来看所有"自动化"、"运营"、"开发"、"监控"都是不必要的，那会让工程师感到困惑。

企业不关心它，因为企业就是销售门票或进行体育投注或销售金融服务等。它根本与 IT 无关。

您是否听说过或遇到过这样的情况：公司中的某些流程完全是手动的，并且/或者需要很多人来做，或者耗时太长？您觉得该流程可以实现自动化，并且可以节省大量工时，但没有人愿意或计划实现自动化。这没关系。

是的，你没听错，没问题。在优化成本或流程缓慢影响业务需求之前，都可以。企业不仅仅因为自动化而重视自动化。

让我们尝试尽可能以非技术的方式来定义 DevOps。

* DevOps * - 是一种开发和采用工具的服务，帮助企业以自助服务的方式维护软件产品生命周期的各个阶段。

听起来不太简单，对吧？让我们在这里解释一下每个单词。

在一系列大规模的个人数据泄露之后，企业意识到他们必须花费更多的资源来进行安全加固，结果DevOps变成了DevSecOps......最近几年出现了新的领域，其中"Ops"应该与某些东西联系起来：DataOps、FinOps ETC...

那么让我们停止讨论 DevOps 术语。

通常，当人们试图定义 DevOps 是什么时，他们会陷入"枚举解释"："你应该进行 CI/CD、配置管理、使用云计算、基础设施作为代码，这里无穷无尽的列表"。

因此，我们在 DevOps 术语定义上遇到了混乱......并非所有项目都需要云计算（你好大型机），当你说"CD"时，你的意思是持续交付或部署（？），并非所有项目都需要基础设施（你好 Kubernetes）等等。

在所有列表的中间是AUTOMATION。它需要专门的文章来介绍它，但是是的，伙计们，DevOps 与自动化无关，并不是每个自动化都是以 DevOps 方式完成的，并不是每个 DevOps 活动都可以或值得自动化。

是的。DevOps工程师（平台团队、DevX、SRE 等）为团队提供服务，客户是维护应用程序的整个公司或软件产品团队。或者任何其他想要执行 Ops 相关任务的人，而无需了解各种"-Ops"领域的知识。

让我困惑的是，许多 DevOps 部门的人都认为"他们在做工作"，不！你们提供的是服务。你们是在满足业务需求。

正是这种小小的心态阻碍了许多优秀工程师在职业生涯中取得成功。在许多情况下，DevOps 中的软技能比技术技能更有价值。

工具化是一套简单的用户界面，可以帮助人们制作与软件生命周期相关的复杂事物，而无需深入了解 SRE/DevOps 实践（或其他技术领域）。是的，工具化就是通过简单的 UI"隐藏复杂性"。"业务就像图片"，不是因为它很愚蠢，而是因为技术细节与业务无关。

另一方面，这种新工具为那些不了解技术细节但现在可以进行交流和协作的人们创造了新的习惯用法。

通常我们有全公司范围的 DevOps 工具，需要在产品团队层面采用，例如我们有用于应用程序日志搜索的 Splunk 或用于应用程序监控和故障排除的 AppDynamics，但并非所有应用程序/团队都使用它，必须首先采用此类工具，并对团队进行使用培训。

自助服务意味着个人或团队从头到尾使用您的工具自己的流程。 DevOps 团队仍然负责该工具，这意味着它应该按预期工作，但他们并不关心该工具如何使用。使用是产品团队的绝对责任，如果工具正常工作，一切后果都是你的问题。

这种转变极大地改变了 DevOps 团队和产品团队之间的协作规则。运维团队经常遇到这样的情况：运维必须为开发人员完成"所有魔法"，而他的问题将得到解决。如果开发人员忘记评论代理使用情况或没有为他的服务器正确配置网络，只要有一个工具可以用来自己解决问题，这并不重要。 "对不起，伙计，你拥有它！"

嗯，这篇文章很长。简要总结：