DevOps 和 IaC 的話題非常流行並且發展迅速。 然而，大多數作者在整個過程中處理純技術問題。 我將描述特定於一家大公司的問題。 我沒有解決方案——一般來說，問題是致命的，存在於官僚主義、審計和“軟技能”領域。
既然文章標題是這樣，那丹妮莉絲就當貓了，跑到企業那邊去了
毫無疑問，現在出現了新舊衝突。 在這些衝突中，往往既沒有對錯之分。 事情就這樣發生了。 但是，為了不至於毫無根據，我們將從這個屏幕開始：
這就是所謂的變更請求。 您會看到大約三分之一的字段需要從各種目錄中填寫，其餘字段在其他選項卡中。 必須填寫這樣的文檔，以便將腳本應用到生產服務器，或上傳新文件，並且通常可以更改某些內容。
字段的數量如此之多，以至於我編寫了用於填充這些字段的小自動化。 而且，這個頁面的寫法是自動化工具看不到它的字段，唯一可能的解決辦法就是用AutoIt傻傻地用鼠標敲坐標。 評估絕望的程度以決定這一點：
因此，您採用 jenkins、chef、terraform、nexus 等，並愉快地將所有這些部署到您的開發中。 但現在是將其發送給 QA、UAT 和 PROD 的時候了。 你有一個 Nexus 工件，你收到了一封來自 DBA 的信，內容如下：
親愛的，
首先，你的關係你可以想像我無法訪問你的關係
其次，所有變更都必須作為變更請求提交。
您需要將 SQL 腳本與 Nexus 隔離並將它們附加到變更請求。
如果更改不是緊急的，則應在發布後 7 天內完成（僅限週末）
當你的變更請求被一群人批准後，DBA 將執行你的腳本，甚至通過郵件將結果的屏幕截圖發送給你。此致，您的 DBA，從大型機開始就一直在這里工作。
你知道這讓我想起什麼嗎？ 半自動化：機器人拿著框架，工人用大鎚敲打。 好吧，真的，如果一切都完全手動完成，那麼這個 Nexus 有什麼用呢？
但不要為此責怪企業！ 當然，這很血腥，但是所有這些帶有變更請求的官僚主義都是被迫的，並且來自審計員。 企業必須以這種方式工作，期間。 他別無選擇。 而審計是一件很保守的事情。 例如，關於長偽複雜和頻繁更改的密碼不好的事實，已經說了多少，但企業將是最後更改它的地方。 還有部署和其他一切。
順便說一句，有一次我試圖為 terraform 創建一個文件，但我沒有成功。 我無意中發現了“項目會計帳單代碼”標籤的含義，但我一直沒弄清楚——我沒有足夠的軟技能。
我什至不接受被動 Luddism 的話題 - 哦，你的自動化威脅到我的工作安全，我不想學習任何新東西，所以我會悄悄地破壞。
那麼，解決方案是什麼？ ITSM 系統有一個非常原始的 API 來自動生成文檔。 一般來說，這些系統中的大多數都來自大型機時代。 也許有人真正了解現代 ITSM 系統？ 也許有人有整合現代 DevOps 和官僚主義的成功經驗？ 當然，這不是關於純粹腐敗的站點，它實際上每天都可以在那裡部署，而是，例如，銀行業，它受到審計員的監管，並且與更高的環境非常隔離。
只是不要忘記，您所有的幻想都僅限於審計。 這改變了一切。 評論區等你哦！
來源： www.habr.com