Ein Lied von Eis (Bloody Enterprise) und Feuer (DevOps und IaC)

Das Thema DevOps und IaC erfreut sich großer Beliebtheit und wächst rasant. Allerdings befassen sich die meisten Autoren nebenbei mit rein technischen Problemen. Ich werde die spezifischen Probleme eines großen Unternehmens beschreiben. Ich habe keine Lösung – Probleme sind im Allgemeinen fatal und liegen im Bereich der Bürokratie, der Prüfung und der „Soft Skills“.

Ein Lied von Eis (Bloody Enterprise) und Feuer (DevOps und IaC)
Da der Titel des Artikels so lautet, wird Daenerys als Katze fungieren und sich auf die Seite der Enterprise stellen

Zweifellos kommt es jetzt zu einem Aufeinanderprallen von Alt und Neu. Und oft gibt es bei diesen Kollisionen weder richtig noch falsch. Es ist einfach so passiert. Aber um nicht unbegründet zu sein, beginnen wir mit diesem Bildschirm:

Ein Lied von Eis (Bloody Enterprise) und Feuer (DevOps und IaC)

Dabei handelt es sich um den sogenannten Change Request. Sie sehen etwa ein Drittel der auszufüllenden Felder aus verschiedenen Verzeichnissen, der Rest der Felder befindet sich in anderen Registerkarten. Ein solches Dokument muss ausgefüllt werden, um das Skript auf den Produktionsserver anzuwenden, neue Dateien hochzuladen und generell etwas zu ändern.

Die Anzahl der Felder ist so groß, dass ich meine kleine Automatisierung zum Ausfüllen dieser Felder geschrieben habe. Darüber hinaus ist diese Seite so geschrieben, dass keine Automatisierungstools ihre Felder sehen können, und die einzig mögliche Lösung bestand darin, AutoIt zu verwenden, um die Koordinaten dumm mit der Maus anzutippen. Schätzen Sie den Grad der Verzweiflung ein, die Sie zu diesem Thema getroffen haben:

Ein Lied von Eis (Bloody Enterprise) und Feuer (DevOps und IaC)

Sie nehmen also Jenkins, Chef, Terraform, Nexus usw. und setzen das alles freudig auf Ihrem Entwickler ein. Aber es ist Zeit, es an QA, UAT und PROD zu senden. Sie haben ein Nexus-Artefakt und erhalten einen Brief von DBA mit etwa diesem Inhalt:

Liebe,

Erstens, Ihr Nexus. Sie können sich vorstellen, dass ich keinen Zugriff auf Ihren Nexus habe
Zweitens müssen alle Änderungen als Änderungsantrag eingereicht werden.
Sie müssen die SQL-Skripte von Nexus isolieren und an die Änderungsanforderung anhängen.
Wenn es sich bei der Änderung nicht um einen Notfall handelt, sollte sie innerhalb von 7 Tagen nach der Veröffentlichung erfolgen (ausschließlich am Wochenende).
Wenn Ihr Änderungsantrag von mehreren Personen genehmigt wird, führt der DBA Ihr Skript aus und sendet sogar einen Screenshot des Ergebnisses per E-Mail.

Mit freundlichen Grüßen Ihr DBA, der seit Mainframe hier arbeitet.

Weißt du, woran mich das erinnert? Halbautomatisierung: Der Roboter hält den Rahmen und der Arbeiter schlägt mit einem Vorschlaghammer darauf. Nun, was nützt dieses Nexus wirklich, wenn dann alles komplett manuell erledigt wird?

Aber machen Sie nicht Enterprise dafür verantwortlich! Es ist natürlich blutig, aber diese ganze Bürokratie mit Änderungsanfragen ist erzwungen und kommt von den Prüfern. Unternehmen müssen so funktionieren, Punkt. Er kann es nicht anders machen. Und Audit ist eine sehr konservative Sache. Wie viel wurde zum Beispiel darüber gesagt, dass lange pseudokomplexe und häufig geänderte Passwörter schlecht sind, aber Unternehmen werden die letzten Orte sein, an denen dies geändert werden kann. Auch mit Bereitstellungen und allem anderen.

Übrigens habe ich einmal versucht, eine Datei für Terraform zu erstellen, aber es ist mir nicht gelungen. Ich bin über die Bedeutung des Tags „Abrechnungscode für Projektbuchhaltung“ gestolpert, habe es aber nie geschafft herauszufinden, da mir die Soft Skills fehlten.

Ich gehe nicht einmal auf das Thema des passiven Luddismus ein – oh, Ihre Automatisierung gefährdet meine Arbeitsplatzsicherheit, ich möchte nichts Neues lernen, also werde ich stillschweigend sabotieren.

Was könnte also die Lösung sein? Das ITSM-System verfügt über eine äußerst primitive API zur automatischen Generierung von Dokumenten. Und im Allgemeinen stammen die meisten dieser Systeme aus der Zeit der Großrechner. Vielleicht kennt jemand wirklich moderne ITSM-Systeme? Vielleicht hat jemand eine erfolgreiche Erfahrung mit der Integration von modernem DevOps und Bürokratie? Dabei handelt es sich natürlich nicht um rein korrupte Websites, auf denen es wirklich jeden Tag eingesetzt werden kann, sondern beispielsweise um den Bankensektor, der unter Prüfer steht und sehr stark von höheren Umgebungen isoliert ist.

Vergessen Sie nur nicht, dass alle Ihre Fantasien auf Auditing beschränkt sind. Und das verändert alles. Wir freuen uns auf Sie in den Kommentaren!

Source: habr.com

Kommentar hinzufügen