Emnet DevOps og IaC er meget populært og udvikler sig hurtigt. Men de fleste forfattere beskæftiger sig med rent tekniske problemer ad denne vej. Jeg vil beskrive de problemer, der er karakteristiske for en stor virksomhed. Jeg har ikke en løsning - problemerne er generelt fatale og ligger inden for bureaukrati, revision og "bløde færdigheder".
Da artiklens titel er sådan, vil Daenerys, der er gået over på Enterprises side, fungere som katten.
Uden tvivl er der nu en kollision mellem gammelt og nyt. Og ofte er der i disse kollisioner hverken rigtigt eller forkert. Sådan skete det. Men for ikke at være ubegrundet, starter vi med denne skærm:
Dette er den såkaldte Change Request. Du ser omkring en tredjedel af de felter, der skal udfyldes fra forskellige mapper, de resterende felter er i andre bogmærker. Et sådant dokument skal udfyldes for at anvende scriptet til produktionsserveren, uploade nye filer eller generelt ændre noget.
Antallet af felter er sådan, at jeg skrev min egen lille automatisering til at udfylde disse felter. Desuden er denne side skrevet på en sådan måde, at ingen automatiseringsværktøjer kan se dens felter, og den eneste mulige løsning var at bruge AutoIt til dumt at klikke på koordinaterne med musen. Vurder dit niveau af desperation for at gøre dette:
Så du tager jenkins, kok, terraform, nexus osv., og implementerer med glæde det hele til din udvikler. Men tiden kommer til at sende den til QA, UAT og PROD. Du har en Nexus-artefakt, og du modtager et brev fra DBA med noget som dette:
Kære,
Først og fremmest, din nexus, du kan have for dig selv. Jeg har ikke adgang til din Nexus
For det andet skal alle ændringer udsendes som en ændringsanmodning.
Du skal udtrække SQL-scripts fra Nexus og vedhæfte dem til ændringsanmodningen.
Hvis ændringen ikke er nødsituation, skal dette ske 7 dage før frigivelse (eksklusivt i weekenden)
Når din ændringsanmodning er godkendt af en flok mennesker, vil DBA udføre dit script og endda sende et skærmbillede af resultatet med posten.Med venlig hilsen din DBA, der har arbejdet her siden mainframens dage.
Ved du hvad det minder mig om? Semi-automatisering: Robotten holder rammen, og arbejderen slår den med en forhammer. Nå, egentlig, hvad er meningen med denne Nexus, hvis alt så gøres helt manuelt?
Men Enterprise skal ikke bebrejdes dette! Det er selvfølgelig blodigt, men alt dette bureaukrati med Change Requests er tvunget og kommer fra revisorer. Enterprise skal arbejde på denne måde, punktum. Han kan ikke gøre det på anden måde. Og revision er en meget konservativ ting. For eksempel, hvor meget er der blevet sagt om, at lange pseudo-komplekse og hyppigt ændrede adgangskoder er dårlige, men virksomheder vil være det sidste sted, hvor dette vil blive ændret. Også med udrulninger og alt muligt andet.
Forresten, på et tidspunkt prøvede jeg at oprette en fil til terraform, men det virkede ikke. Jeg faldt over betydningen af 'Project Accounting Billing Code'-tagget, som jeg aldrig nåede at finde ud af - jeg havde ikke nok bløde færdigheder.
Jeg tager ikke engang emnet passiv luddisme på - åh, din automatisering truer min jobsikkerhed, jeg vil ikke lære noget nyt, så jeg saboterer det stille og roligt.
Jamen, hvad kunne principielt løsningen være? ITSM-systemet har en ekstremt primitiv API til automatisk generering af dokumenter. Og generelt kommer de fleste af disse systemer fra mainframes tid. Er der nogen, der kender nogle virkelig moderne ITSM-systemer? Er der nogen, der har succesfuld erfaring med at integrere moderne DevOps og bureaukrati? Vi taler selvfølgelig ikke om rene salgssteder, hvor der faktisk kan være en udrulning hver dag, men for eksempel banksektoren, som er under revisorer og meget stærk isolation i højere miljøer.
Bare glem ikke, at alle dine fantasier er begrænset af revisionen. Og det ændrer alt. Jeg venter på dig i kommentarerne!
Kilde: www.habr.com