A Song of Ice (Bloody Enterprise) dan Fire (DevOps dan IaC)

Topik DevOps dan IaC sangat popular dan berkembang dengan pantas. Walau bagaimanapun, kebanyakan pengarang berurusan dengan masalah teknikal semata-mata di sepanjang laluan ini. Saya akan menerangkan ciri-ciri masalah syarikat besar. Saya tidak mempunyai penyelesaian - masalah, secara amnya, membawa maut dan terletak pada bidang birokrasi, pengauditan, dan "kemahiran lembut".

A Song of Ice (Bloody Enterprise) dan Fire (DevOps dan IaC)
Oleh kerana tajuk artikel adalah seperti ini, Daenerys, yang telah pergi ke sisi Enterprise, akan bertindak sebagai kucing.

Tidak dinafikan, kini berlaku pertembungan lama dan baru. Dan selalunya dalam perlanggaran ini tidak ada yang betul atau salah. Begitulah ia berlaku. Tetapi, agar tidak menjadi tidak berasas, kami akan bermula dengan skrin ini:

A Song of Ice (Bloody Enterprise) dan Fire (DevOps dan IaC)

Ini adalah apa yang dipanggil Permintaan Perubahan. Anda melihat kira-kira satu pertiga daripada medan yang perlu diisi daripada pelbagai direktori, medan yang selebihnya berada dalam penanda halaman lain. Dokumen sedemikian mesti diisi untuk menggunakan skrip pada pelayan pengeluaran, atau memuat naik fail baharu, atau secara amnya menukar apa-apa.

Bilangan medan adalah sedemikian rupa sehingga saya menulis automasi kecil saya sendiri untuk mengisi medan ini. Selain itu, halaman ini ditulis sedemikian rupa sehingga tiada alat automasi dapat melihat medannya, dan satu-satunya penyelesaian yang mungkin adalah menggunakan AutoIt untuk mengklik koordinat dengan tetikus secara bodoh. Nilai tahap terdesak anda untuk melakukan ini:

A Song of Ice (Bloody Enterprise) dan Fire (DevOps dan IaC)

Jadi, anda mengambil jenkins, chef, terraform, nexus, dsb., dan dengan senang hati mengerahkan semuanya ke pembangun anda. Tetapi tiba masanya untuk menghantarnya kepada QA, UAT dan PROD. Anda mempunyai artifak Nexus dan anda menerima surat daripada DBA dengan sesuatu seperti ini:

sayang,

Pertama sekali, perhubungan anda yang boleh anda miliki sendiri. Saya tidak mempunyai akses kepada Nexus anda
Kedua, semua perubahan mesti dikeluarkan sebagai Permintaan Perubahan.
Anda perlu mengekstrak skrip SQL daripada Nexus dan melampirkannya pada Permintaan Perubahan.
Jika perubahan itu bukan Kecemasan, ini perlu dilakukan 7 hari sebelum dikeluarkan (khusus pada Hujung Minggu)
Apabila Permintaan Perubahan anda diluluskan oleh sekumpulan orang, DBA akan melaksanakan skrip anda dan juga menghantar tangkapan skrin hasil melalui mel.

Salam sejahtera, DBA anda yang telah bekerja di sini sejak zaman kerangka utama.

Adakah anda tahu apa yang ini mengingatkan saya? Separa automasi: robot memegang bingkai, dan pekerja memukulnya dengan tukul besi. Sebenarnya, apa gunanya Nexus ini jika semuanya dilakukan secara manual sepenuhnya?

Tetapi Enterprise tidak boleh dipersalahkan untuk ini! Sudah tentu, ia berdarah, tetapi semua birokrasi dengan Permintaan Perubahan ini dipaksa dan datang daripada juruaudit. Perusahaan mesti bekerja dengan cara ini, tempoh. Dia tidak boleh melakukannya dengan cara lain. Dan pengauditan adalah perkara yang sangat konservatif. Sebagai contoh, berapa banyak yang telah dikatakan tentang fakta bahawa kata laluan pseudo-kompleks yang panjang dan kerap ditukar adalah buruk, tetapi perusahaan akan menjadi tempat terakhir di mana ini akan diubah. Juga dengan penempatan dan segala-galanya.

Dengan cara ini, pada satu masa saya cuba mencipta fail untuk terraform, tetapi ia tidak berfungsi. Saya terjumpa maksud teg 'Kod Pengebilan Perakaunan Projek', yang tidak pernah saya ketahui - saya tidak mempunyai kemahiran insaniah yang mencukupi.

Saya tidak pun mengambil topik Luddisme pasif - oh, automasi anda mengancam keselamatan kerja saya, saya tidak mahu belajar sesuatu yang baharu, jadi saya akan mensabotajnya secara senyap-senyap.

Nah, apa yang boleh menjadi penyelesaian pada dasarnya? Sistem ITSM mempunyai API yang sangat primitif untuk menjana dokumen secara automatik. Dan secara umum, kebanyakan sistem ini datang dari zaman kerangka utama. Adakah sesiapa tahu mana-mana sistem ITSM yang benar-benar moden? Adakah sesiapa yang mempunyai pengalaman berjaya menyepadukan DevOps moden dan birokrasi? Kami, sudah tentu, tidak bercakap tentang tapak jualan semata-mata, di mana sebenarnya boleh ada penggunaan setiap hari, tetapi, sebagai contoh, sektor perbankan, yang berada di bawah juruaudit dan pengasingan yang sangat kuat dalam persekitaran yang lebih tinggi.

Cuma jangan lupa bahawa semua fantasi anda dihadkan oleh audit. Dan itu mengubah segala-galanya. Saya menunggu anda dalam komen!

Sumber: www.habr.com

Tambah komen