The topics of DevOps and IaC are very popular and are developing rapidly. However, most authors address only the technical issues along this path. I will describe the problems characteristic of large companies. I don’t have solutions — the problems are generally fatal and lie in the realms of bureaucracy, auditing, and 'soft skills.'
Given that the title of the article is such, Daenerys, who has turned to the side of Enterprise, will serve as the cat.
Undoubtedly, there is a clash between the old and the new happening right now. And often in these collisions, there are neither right nor wrong parties. That's just how it is. But to avoid speaking without proof, let’s start with this screen:
This is what is called a Change Request. You see about a third of the fields that need to be filled out from various directories; the remaining fields are in other tabs. This document must be filled out in order to apply a script to production. server, or to upload new files and generally to change anything.
The number of fields is such that I wrote my own little automation to fill in these fields. Moreover, this page is written in such a way that no automation tools can see its fields, and the only possible solution was to use AutoIt to click randomly at coordinates. Just evaluate the level of desperation that it took to resort to that:
So, you take Jenkins, Chef, Terraform, Nexus, and the like, and happily deploy all of this on your dev environment. But then comes the time to send it to QA, UAT, and PROD. You have the Nexus artifact, and you receive an email from the DBA with text like this:
Dear,
First of all, regarding your Nexus, I don't have access to your Nexus.
Secondly, all changes should be formalized as a Change Request.
You need to extract the SQL scripts from Nexus and attach them to the Change Request.
If the change is not an emergency, it should be done within 7 days of the release (exclusively on the weekend).
When your Change Request is approved by a host of people, the DBA will execute your script and even send a screenshot of the result by email.Sincerely, your DBA who has been working here since the mainframe era.
You know what this reminds me of? Semi-automation: a robot holds the fixture, while a worker pounds it with a sledgehammer. Truly, what's the point of this Nexus if everything is done manually afterward?
However, we shouldn't blame Enterprise for this! Sure, it's a harsh environment, but all this bureaucracy with Change Requests is mandatory and comes from auditors. Enterprise has to operate this way, and that's that. It can't do otherwise. And audits are fundamentally conservative. For instance, it has often been said that long pseudo-complex and frequently changed passwords are a bad idea, but enterprises will be the last places to change that. The same goes for deployments and everything else.
By the way, I once tried to create a file for terraform, but I couldn't manage it. I stumbled on the meaning of the tag ‘Project Accounting Billing Code’, which I could never figure out — I lacked the necessary soft skills.
I'm not even touching on the topic of passive Luddism — oh, your automation threatens my job security, I don't want to learn anything new, so I'll quietly sabotage it.
So what could be a solution, in principle? The ITSM system has an extremely primitive API for automatically generating documents. Moreover, most of these systems trace back to the era of mainframes. Does anyone know of truly modern ITSM systems? Does anyone have successful experience integrating modern DevOps with bureaucracy? We're not talking about purely sales sites, where there could genuinely be a deployment every day, but, for example, the banking sector, which is under auditors and has very strong isolation of higher environments.
Just don't forget that all your fantasies are limited by audits. And that changes everything. I'll be waiting for your comments!
Source: habr.com
