不做DevOps的痛苦

通过从应用程序中学习企业APM产品，发现更快，更高效的性能监控。 参加AppDynamics APM导览！

摘要

AppDynamics的顾问Sean Stanford拥有十余年的DevOps实践经验，亲眼目睹了组织实践，理念和工具如何影响公司交付应用程序和服务的能力。 这是他关于一家尚未接受DevOps的公司的告诫故事，该公司因此而遭受的痛苦，以及它最终如何发现问题的根源。

为了计划新的软件项目和维护现有的部署，DevOps帮助组织在整个开发生命周期中在所有利益相关者之间建立更牢固的联系。 因此，DevOps在全球Swift流行也就不足为奇了。 在Evans Data的最新全球发展调查中 ，有72％的开发人员报告说他们在正式的DevOps环境中工作，从特定的开发操作交互到企业范围的实施。

当然，DevOps的实践可能因组织而异（有关快速概述，请查看我们的AppDynamics 入门 ）。

以我的经验，不接受DevOps的组织这样做的风险很大。 不久前，一家大型房地产开发商向AppDynamics寻求帮助。 该公司的.NET安装程序存在第三方Web资产管理库的问题，该库具有特定的写入磁盘配置要求。

在开发环境中正确配置了这些要求，但在生产环境中没有正确配置。 而且由于开发人员与Prod分离，没有使这些环境保持同步的流程，因此该公司没有意识到这一疏忽。

最终结果是：生产中持续存在的性能问题。 并且由于IIS自动重新启动设置在一定时间间隔后回收了应用程序池，因此该公司无法确定持续的应用程序实例崩溃的根本原因。

寻找原因

该公司联系AppDynamics，询问我们是否可以弄清为什么应用程序持续崩溃。 我们检测了他们的系统，该系统以前没有运行过APM软件。 查看AppDynamics系统日志后，我们立即发现问题的根源：该应用程序无权在生产环境中写入磁盘。

这一发现促使该公司进行了漫长的内部测试和环境比较过程，从而发现了Dev和Prod之间的众多配置差异。

得到教训

从根本上讲，功能失调的文化是造成公司生产困境的主要原因。
例如，包括管理，运营和开发在内的各个利益相关者之间存在很多摩擦，有时包括主要争论。 这是从Dev到Prod的“代码丢在墙上”的经典案例。 这些派系之间的沟通非常差，实际上，承包商是开发，运营和管理层之间的主要联络人。

此外，每当技术从业人员离开公司时， 部落知识就会流失。 当AppD出现时，开发人员都不知道麻烦的第三方工具，也不知道如何使用它。 甚至前面提到的承包商（孤立的派系之间的唯一联系）也没有意识到问题的效用及其发挥的关键作用。

避免通过DevOps痛苦

团队之间的沟通和知识转移至关重要。 对于持续集成和持续部署（CI / CD），每个环境（Dev，Prod等）都应尽可能相似。 环境之间的主要配置差异通常会导致负面结果。
DevOps的主要宗旨是使您的环境标准化。 如果您在一个开发人员的机器上构建代码，那么它应该以完全相同的方式在任何地方运行。

软件行业正在朝这个方向发展。 “如今，大多数开发人员都指出，他们的开发团队中有一部分包括运营工程师。” 埃文斯数据研究发现。 “向DevOps的迁移不仅影响了利益相关者的角色，还影响了开发团队的组成。”

实施DevOps实践与可靠的APM解决方案相结合，将使您的组织避免痛苦，并获得对代码性能的更深入了解。

了解有关AppDynamics如何在DevOps旅程中如何帮助您自己的组织的更多信息。

通过从应用程序中学习企业APM产品，发现更快，更高效的性能监控。 参加AppDynamics APM导览！

翻译自: https://www.javacodegeeks.com/2018/06/pain-doing-devops.html