Aihe DevOps ja IaC on erittäin suosittu ja kehittyy nopeasti. Useimmat kirjoittajat kuitenkin käsittelevät tällä tiellä puhtaasti teknisiä ongelmia. Kuvaan suuryritykselle ominaisia ongelmia. Minulla ei ole ratkaisua - ongelmat ovat yleensä kohtalokkaita ja liittyvät byrokratiaan, tilintarkastukseen ja "pehmeisiin taitoihin".
Koska artikkelin otsikko on tällainen, Enterprisen puolelle siirtynyt Daenerys toimii kissana.
Epäilemättä nyt tapahtuu vanhan ja uuden törmäys. Ja usein näissä törmäyksissä ei ole oikeaa eikä väärää. Näin siinä kävi. Mutta jotta emme olisi perusteettomia, aloitamme tästä näytöstä:
Tämä on niin kutsuttu muutospyyntö. Näet noin kolmanneksen täytettävistä kentistä eri hakemistoista, loput kentät ovat muissa kirjanmerkeissä. Tällainen asiakirja on täytettävä, jotta komentosarjaa voidaan käyttää tuotantopalvelimessa, ladata uusia tiedostoja tai yleensä muuttaa mitään.
Kenttien määrä on sellainen, että kirjoitin oman pienen automaation näiden kenttien täyttämiseen. Lisäksi tämä sivu on kirjoitettu niin, ettei mikään automaatiotyökalu näe sen kenttiä, ja ainoa mahdollinen ratkaisu oli käyttää AutoIt tyhmästi napsauttamaan koordinaatteja hiirellä. Arvioi epätoivosi tasoa tehdäksesi tämän:
Joten otat jenkinit, kokin, terraformin, nexuksen jne. ja otat ne kaikki iloisesti käyttöön kehittäjällesi. Mutta on aika lähettää se QA:lle, UAT:lle ja PROD:lle. Sinulla on Nexus-artefaktti ja saat DBA:lta seuraavanlaisen kirjeen:
rakas,
Ensinnäkin, nexusi, jonka voit hankkia itsellesi, minulla ei ole pääsyä Nexusiisi
Toiseksi kaikki muutokset on lähetettävä muutospyyntönä.
Sinun on purettava SQL-skriptit Nexuksesta ja liitettävä ne muutospyyntöön.
Jos muutos ei ole hätätilanne, se tulee tehdä 7 päivää ennen julkaisua (ainoastaan viikonloppuna)
Kun joukko ihmisiä hyväksyy muutospyyntösi, DBA suorittaa skriptisi ja lähettää jopa kuvakaappauksen tuloksesta postitse.Ystävällisin terveisin DBA, joka on työskennellyt täällä keskustietokoneen ajoista lähtien.
Tiedätkö mitä tämä muistuttaa minua? Puoliautomaatio: robotti pitää rungosta kiinni, ja työntekijä iskee siihen vasaralla. No, todellakin, mitä järkeä tässä Nexuksessa on, jos sitten kaikki tehdään täysin manuaalisesti?
Mutta Enterprisea ei pidä syyttää tästä! Se on tietysti veristä, mutta kaikki tämä muutospyyntöihin liittyvä byrokratia on pakotettua ja tulee tilintarkastajilta. Yrityksen on toimittava tällä tavalla, piste. Hän ei voi tehdä sitä muuten. Ja tilintarkastus on hyvin konservatiivinen asia. Kuinka paljon on esimerkiksi puhuttu siitä, että pitkät pseudomonimutkaiset ja usein vaihdetut salasanat ovat huonoja, mutta yritykset ovat viimeinen paikka, jossa tämä vaihdetaan. Myös käyttöönottojen ja kaiken muun kanssa.
Muuten, yritin kerran luoda tiedoston terraformille, mutta se ei toiminut. Törmäsin "Project Accounting Billing Code" -tunnisteen merkitykseen, jota en koskaan saanut selville - minulla ei ollut tarpeeksi pehmeää osaamista.
En ota edes passiivisen luddismin aihetta - ah, automaatio uhkaa työturvallisuuttani, en halua oppia mitään uutta, joten sabotoin sen hiljaa.
No, mikä voisi olla periaatteellinen ratkaisu? ITSM-järjestelmässä on erittäin alkeellinen API asiakirjojen automaattista luomista varten. Ja yleensä, useimmat näistä järjestelmistä ovat peräisin keskustietokoneiden ajoilta. Tietääkö kukaan todella nykyaikaisia ITSM-järjestelmiä? Onko kenelläkään onnistunutta kokemusta modernin DevOpsin ja byrokratian yhdistämisestä? Emme tietenkään puhu puhtaasti myyntipaikoista, joissa voi todella olla käyttöönottoa joka päivä, vaan esimerkiksi pankkisektorista, joka on tilintarkastajien alaisuudessa ja erittäin vahvassa eristyksissä korkeammissa ympäristöissä.
Älä vain unohda, että auditointi rajoittaa kaikkia fantasioitasi. Ja se muuttaa kaiken. Odotan sinua kommenteissa!
Lähde: will.com