Kanto de Glacio (Bloody Enterprise) kaj Fajro (DevOps kaj IaC)

La temo de DevOps kaj IaC estas tre populara kaj disvolviĝas rapide. Tamen, la plej multaj aŭtoroj traktas pure teknikajn problemojn laŭ tiu ĉi vojo. Mi priskribos la problemojn karakterizajn de granda kompanio. Mi ne havas solvon - la problemoj, ĝenerale, estas fatalaj kaj kuŝas en la areo de burokratio, revizio kaj "molaj kapabloj".

Kanto de Glacio (Bloody Enterprise) kaj Fajro (DevOps kaj IaC)
Ĉar la titolo de la artikolo estas tia, Daenerys, kiu transiris al la flanko de Enterprise, rolos kiel la kato.

Sendube, nun estas kolizio de malnova kaj nova. Kaj ofte en ĉi tiuj kolizioj estas nek pravo nek malĝuste. Tiel okazis. Sed, por ne esti senbazaj, ni komencos per ĉi tiu ekrano:

Kanto de Glacio (Bloody Enterprise) kaj Fajro (DevOps kaj IaC)

Ĉi tio estas la tiel nomata Ŝanĝo-Peto. Vi vidas ĉirkaŭ trionon de la kampoj, kiuj devas esti plenigitaj el diversaj dosierujoj, la ceteraj kampoj estas en aliaj legosignoj. Tia dokumento devas esti plenigita por apliki la skripton al la produktservilo, aŭ alŝuti novajn dosierojn, aŭ ĝenerale ŝanĝi ion ajn.

La nombro da kampoj estas tia, ke mi skribis mian propran etan aŭtomatigon por plenigi ĉi tiujn kampojn. Krome, ĉi tiu paĝo estas skribita tiel, ke neniuj aŭtomatigaj iloj povas vidi ĝiajn kampojn, kaj la sola ebla solvo estis uzi AutoIt por stulte klaki la koordinatojn per la muso. Taksi vian nivelon de malespero fari tion:

Kanto de Glacio (Bloody Enterprise) kaj Fajro (DevOps kaj IaC)

Do, vi prenas jenkins, kuiriston, terraform, nexus, ktp., kaj feliĉe deplojas ĉion al via dev. Sed venas la tempo sendi ĝin al QA, UAT kaj PROD. Vi havas Nexus-artefakton kaj vi ricevas leteron de la DBA kun io tia:

Kara,

Antaŭ ĉio, vian ligilon, kiun vi povas havi por vi mem, mi ne havas aliron al via Nexus
Due, ĉiuj ŝanĝoj devas esti elsenditaj kiel Ŝanĝpeto.
Vi devas ĉerpi la SQL-skriptojn de Nexus kaj alligi ilin al la Ŝanĝa Peto.
Se la ŝanĝo ne estas Krizo, ĉi tio devus esti farita 7 tagojn antaŭ liberigo (ekskluzive dum Semajnfino)
Kiam via Ŝanĝa Peto estas aprobita de amaso da homoj, la DBA ekzekutos vian skripton kaj eĉ sendos ekrankopion de la rezulto per poŝto.

Plej korajn salutojn, via DBA, kiu laboras ĉi tie ekde la tagoj de ĉefkomputilo.

Ĉu vi scias, pri kio ĉi tio memorigas min? Duonaŭtomatigo: la roboto tenas la kadron, kaj la laboristo trafas ĝin per sledmartelo. Nu, vere, kio estas la signifo de ĉi tiu Nexus se tiam ĉio estas farita tute permane?

Sed Enterprise ne devus esti kulpigita pro tio! Ĝi estas, kompreneble, sanga, sed ĉi tiu tuta burokratio kun Ŝanĝpetoj estas devigita kaj venas de revizoroj. Enterprise devas funkcii tiel, punkto. Li ne povas fari ĝin alimaniere. Kaj revizio estas tre konservativa afero. Ekzemple, kiom oni diris pri tio, ke longaj pseŭdokompleksaj kaj ofte ŝanĝitaj pasvortoj estas malbonaj, sed entreprenoj estos la lasta loko, kie ĉi tio estos ŝanĝita. Ankaŭ kun deplojoj kaj ĉio alia.

Cetere, mi iam provis krei dosieron por terraform, sed ĝi ne funkciis. Mi stumblis pri la signifo de la etikedo 'Projekta Kontada Faktura Kodo', kiun mi neniam sukcesis eltrovi - mi ne havis sufiĉe da molkapabloj.

Mi eĉ ne prenas la temon de pasiva ludismo - ho, via aŭtomatigo minacas mian laborsekurecon, mi volas nenion novan lerni, do mi trankvile sabotos ĝin.

Nu, kio povus esti la solvo principe? La ITSM-sistemo havas ekstreme primitivan API por aŭtomate generi dokumentojn. Kaj ĝenerale, la plej multaj el ĉi tiuj sistemoj venas de la tempoj de ĉefkomputiloj. Ĉu iu konas iujn vere modernajn ITSM-sistemojn? Ĉu iu havas sukcesan sperton integrante modernan DevOps kaj burokration? Ni, kompreneble, ne parolas pri pure vendaj retejoj, kie efektive povas okazi ĉiutage disvastigo, sed, ekzemple, la banka sektoro, kiu estas sub revizoroj kaj tre forta izolado en pli altaj medioj.

Nur ne forgesu, ke ĉiuj viaj fantazioj estas limigitaj de la revizio. Kaj tio ŝanĝas ĉion. Mi atendas vin en la komentoj!

fonto: www.habr.com

Aldoni komenton