Emnet DevOps og IaC er meget populært og udvikler sig hurtigt. Dog berører de fleste forfattere udelukkende tekniske problemer på denne vej. Jeg vil derimod beskrive de problemer, der er karakteristiske for større virksomheder. Jeg har ikke løsninger — problemerne er generelt fatale og ligger inden for bureaukrati, revision og 'soft skills'.
Da titel på artiklen er sådan, vil Daenerys, der har skiftet over til Enterprise, fungere som katten.
Uden tvivl finder der i øjeblikket et sammenstød mellem det gamle og det nye sted. Og ofte er der ingen, hverken de, der har ret, eller dem, der har skyld. Sådan er det bare. Men for ikke at være ordløs, vil vi begynde med denne skærm:
Dette er det såkaldte Change Request. Du ser cirka en tredjedel af felterne, der skal udfyldes fra forskellige registre, de resterende felter findes under andre faner. Et sådant dokument skal udfyldes for at kunne anvende scriptet på production. server, eller uploade nye filer og generelt ændre noget.
Antallet af felter er sådant, at jeg har skrevet min egen lille automatisering til udfyldning af disse felter. Desuden er denne side oprettet på en måde, så ingen automatiseringsværktøjer kan se dens felter, og den eneste mulige løsning var at bruge AutoIt til bare at klikke med musen på koordinaterne. Vurder graden af desperation for at gå så langt:
Så tager du Jenkins, Chef, Terraform, Nexus og andet og glædeligt deployer alt dette på dit dev. Men tiden kommer, hvor det skal sendes til QA, UAT og PROD. Du har en Nexus artefakt, og du modtager et brev fra DBA med omtrent følgende tekst:
Kære,
For det første, jeres Nexus, jeg har ikke adgang til jeres Nexus.
For det andet, alle ændringer skal dokumenteres som Change Request.
SQL scripts skal du udtrække fra din Nexus og vedhæfte til Change Request.
Hvis ændringen ikke er en nødsituation, skal dette gøres 7 dage efter frigivelse (udelukkende i weekenden).
Når dit Change Request er godkendt af en masse mennesker, vil DBA udføre dit script og endda sende et screenshot af resultatet pr. mail.Med venlig hilsen, din DBA, som har arbejdet her siden mainframe-tiden.
Ved du, hvad dette minder mig om? Halvautomatisering: en robot holder støtten, mens en arbejder banker på den med en hammer. Hvad nytter det egentlig med denne Nexus, hvis alt derefter gøres helt manuelt?
Men bør ikke bebrejde Enterprise for dette! Det er selvfølgelig blodigt, men al denne bureaukrati med Change Requests er nødvendig og kommer fra revisorerne. Enterprise er nødt til at arbejde på denne måde, og punktum. Der er ingen anden mulighed. Revision er en meget konservativ ting. Hvor mange gange er der f.eks. blevet sagt, at lange pseudo-komplekse og ofte ændrede adgangskoder er dårlige, men virksomhederne vil være det sidste sted, hvor dette ændres. Det gælder også for deploys og alt andet.
Forresten, jeg forsøgte engang at oprette en fil til terraform, men jeg kunne ikke. Jeg stødte på betydningen af tagget ‘Project Accounting Billing Code’, som jeg aldrig fik opklaret – jeg havde ikke de nødvendige soft skills.
Jeg tager slet ikke emnet passiv luddisme op – åh, din automatisering truer min job-sikkerhed, jeg vil ikke lære noget nyt, så jeg vil stille sabotere.
Og hvilken løsning kan der i princippet være? ITSM-systemet har en ekstremt primitiv API for automatisk at generere dokumenter. Og generelt set kommer de fleste sådanne systemer fra mainframe-tiderne. Er der nogen, der kender virkelig moderne ITSM-systemer? Måske har nogen erfaring med vellykket integration af moderne DevOps og bureaukrati? Det handler selvfølgelig ikke om ren salgswebsteder, hvor der reelt kan være deploy hver dag, men f.eks. banksektoren, som er under revisorer og har en meget stærk isolation af højere miljøer.
Men glem ikke, at alle dine fantasier er begrænset af revisionen. Og det ændrer alt. Jeg ser frem til at høre fra dig i kommentarerne!
Kilde: habr.com
