DevOps和IaC主题非常受欢迎并且正在迅速发展。 但是，大多数作者在此过程中仅涉及技术问题。 我将描述一个大公司的特征问题。 我没有解决方案-这些问题通常是致命的，并且在于官僚机构，审计和“软技能”领域。
由于文章标题是这样的，因此Dineris将扮演猫的角色，他转而使用Enterprise的一面
无疑，现在存在着新旧冲突。 在这些冲突中，常常没有权利，没有罪恶感。 就这样。 但是，为了避免毫无根据，我们将从此屏幕开始：
这就是所谓的变更请求。 您会从各种目录中看到大约三分之一需要填写的字段，其他选项卡中的其余字段。 为了将脚本应用于生产服务器或上载新文件，并且通常更改某些内容，必须完成此类文档。
字段的数量是如此之多，以至于我为填写这些字段而编写了一些自动化的文章。 而且，编写此页面的目的是使自动化工具无法看到其字段，并且唯一可能的解决方案是使用AutoIt愚蠢地用其坐标敲击鼠标。 评估绝望程度以决定这一点：
因此，您选择了詹金斯，厨师，terraform，关系等，然后将其全部愉快地部署到您的开发人员中。 但是现在是将其发送给质量检查，UAT和PROD的时候了。 您拥有Nexus工件，并且收到DBA的来信，内容大致如下：
亲爱的
首先， 您的联系可以想象我无法使用您的Nexus
其次，所有变更必须作为变更请求发布。
您需要将它们隔离为Nexus并附加到“更改请求”的SQL脚本。
如果更改不是“紧急”更改，则应在发布7天后（仅限周末）执行此操作
当您的变更请求发送一堆人时，DBA将执行您的脚本，甚至通过邮件发送结果的屏幕截图。
真诚的，您的DBA从大型机时代开始就在这里工作。
你知道这让我想起什么吗？ 半自动化：机器人握住床，工人用大锤击打它。 那么，真的，如果所有操作都是完全手动完成的，那么Nexus的用途是什么？
但是企业不应该受到责备！ 他当然很血腥，但是所有带有“变更请求”的官僚机构都是强迫性的，来自审计师。 企业必须定期地那样工作。 否则他是不可能的。 审计是非常保守的事情。 例如，有人说，长时间的伪复杂密码和经常更改的密码不好，但是企业将是最后更改密码的地方。 还有部署和其他所有内容。
顺便说一句，我曾经尝试为terraform创建一个文件，但没有成功。 我偶然发现了“ Project Accounting Billing Code”标签的价值，但我仍然找不到它-软技能还不够。
我什至没有讨论被动嘲弄的话题-哦，您的自动化威胁到我的工作安全，我不想学习任何新知识，所以我会悄悄地破坏它。
那么，原则上什么是解决方案？ ITSM系统具有一个非常原始的API，可以自动生成文档。 无论如何，这些系统中的大多数来自大型机时代。
也许有人知道真正的现代ITSM系统？ 谁能成功集成现代DevOps和官僚机构？ 当然，这并不是纯粹地出售每天真正可以部署的站点，而是例如银行部门，该部门处于审计师的掌控之下，并且与较高环境隔离开来。
只是不要忘记，所有幻想都受到审核的限制。 一切都会改变。 在评论中等待您！