DevOps ir IaC tema yra labai populiari ir greitai vystosi. Tačiau dauguma autorių šiuo keliu sprendžia grynai technines problemas. Aprašysiu didelei įmonei būdingas problemas. Neturiu sprendimo – problemos apskritai yra lemtingos ir slypi biurokratijos, audito ir „minkštųjų įgūdžių“ srityje.
Kadangi straipsnio pavadinimas toks, Daenerys, perėjęs į Enterprise pusę, atliks katės vaidmenį.
Be jokios abejonės, dabar vyksta seno ir naujo susidūrimas. Ir dažnai šiuose susidūrimuose nėra nei teisingo, nei neteisingo. Tiesiog taip atsitiko. Tačiau, kad nebūtų nepagrįsti, pradėsime nuo šio ekrano:
Tai yra vadinamasis pakeitimų prašymas. Iš įvairių katalogų matote apie trečdalį laukelių, kuriuos reikia užpildyti, likę laukai yra kitose žymose. Toks dokumentas turi būti užpildytas, norint pritaikyti scenarijų gamybos serveriui, įkelti naujus failus arba apskritai ką nors pakeisti.
Laukų skaičius yra toks, kad aš parašiau savo mažą automatiką šiems laukams užpildyti. Be to, šis puslapis parašytas taip, kad jokie automatikos įrankiai nematytų jo laukų, o vienintelė galima išeitis buvo naudoti AutoIt kvailai pele spustelėti koordinates. Įvertinkite savo nevilties lygį, kad tai padarytumėte:
Taigi, jūs paimate jenkinus, šefą, terraformą, nexusą ir t. t. ir su džiaugsmu pateikiate visa tai savo kūrėjui. Tačiau ateina laikas siųsti jį QA, UAT ir PROD. Turite „Nexus“ artefaktą ir iš DBA gaunate tokį laišką:
gerb.
Visų pirma, jūsų nexus, kurį galite turėti sau, aš neturiu prieigos prie jūsų Nexus
Antra, visi pakeitimai turi būti pateikti kaip pakeitimų užklausa.
Turite ištraukti SQL scenarijus iš Nexus ir pridėti juos prie pakeitimo užklausos.
Jei pakeitimas nėra skubus, tai reikia padaryti likus 7 dienoms iki išleidimo (išskirtinai savaitgalį).
Kai jūsų pakeitimų užklausą patvirtins daugybė žmonių, DBA vykdys jūsų scenarijų ir net išsiųs rezultato ekrano kopiją paštu.Pagarbiai, jūsų DBA, kuris čia dirba nuo pagrindinio kompiuterio laikų.
Ar žinai, ką man tai primena? Pusiau automatika: robotas laiko rėmą, o darbuotojas trenkia plaktuku. Na, tikrai, kokia šio Nexus prasmė, jei tada viskas daroma visiškai rankiniu būdu?
Tačiau „Enterprise“ dėl to nereikėtų kaltinti! Tai, žinoma, kruvina, bet visa ši biurokratija su pakeitimų prašymais yra priverstinė ir kyla iš auditorių. Įmonė turi dirbti taip, taškas. Jis negali to padaryti kitaip. O auditas yra labai konservatyvus dalykas. Pavyzdžiui, kiek daug kalbėta apie tai, kad ilgi pseudo sudėtingi ir dažnai keičiami slaptažodžiai yra blogi, tačiau įmonės bus paskutinė vieta, kur tai bus pakeista. Taip pat su dislokavimu ir visa kita.
Beje, vienu metu bandžiau sukurti failą terraformui, bet nepavyko. Suklupau už žymos „Projekto apskaitos atsiskaitymo kodas“ reikšmė, kurios taip ir nepavyko išsiaiškinti – man neužteko minkštųjų įgūdžių.
Aš net nesiimu pasyvaus ludizmo temos - oi, jūsų automatika kelia grėsmę mano darbo saugumui, nenoriu nieko naujo išmokti, todėl tyliai tai sabotuosiu.
Na, koks iš principo galėtų būti sprendimas? ITSM sistema turi itin primityvią API automatiniam dokumentų generavimui. Ir apskritai dauguma šių sistemų atkeliauja iš pagrindinių kompiuterių laikų. Ar kas nors žino tikrai modernias ITSM sistemas? Ar kas nors turi sėkmingos patirties integruojant modernią „DevOps“ ir biurokratiją? Žinoma, mes kalbame ne apie grynai pardavimo svetaines, kuriose iš tikrųjų gali būti diegiama kiekvieną dieną, bet, pavyzdžiui, apie bankų sektorių, kuris yra auditorių kontroliuojamas ir labai stipriai izoliuotas aukštesnėje aplinkoje.
Tik nepamirškite, kad visas jūsų fantazijas riboja auditas. Ir tai viską keičia. Laukiu jūsų komentaruose!
Šaltinis: www.habr.com