Temaet DevOps og IaC er veldig populært og utvikler seg raskt. Imidlertid håndterer de fleste forfattere rent tekniske problemer langs denne veien. Jeg vil beskrive problemene som er karakteristiske for et stort selskap. Jeg har ingen løsning - problemene er generelt fatale og ligger i området byråkrati, revisjon og "myke ferdigheter".
Siden tittelen på artikkelen er slik, vil Daenerys, som har gått over til Enterprise, fungere som katten.
Uten tvil, nå er det en kollisjon av gammelt og nytt. Og ofte i disse kollisjonene er det verken rett eller galt. Slik ble det. Men for ikke å være ubegrunnet, starter vi med denne skjermen:
Dette er den såkalte endringsforespørselen. Du ser omtrent en tredjedel av feltene som må fylles ut fra ulike kataloger, de resterende feltene er i andre bokmerker. Et slikt dokument må fylles ut for å bruke skriptet til produksjonsserveren, eller laste opp nye filer, eller generelt endre noe.
Antall felt er slik at jeg skrev min egen lille automatisering for å fylle ut disse feltene. Dessuten er denne siden skrevet på en slik måte at ingen automatiseringsverktøy kan se feltene dens, og den eneste mulige løsningen var å bruke AutoIt til å klikke dumt på koordinatene med musen. Vurder nivået av desperasjon for å gjøre dette:
Så, du tar jenkins, kokk, terraform, nexus, etc., og distribuerer gjerne alt til utvikleren din. Men tiden er inne for å sende den til QA, UAT og PROD. Du har en Nexus-artefakt, og du mottar et brev fra DBA med noe sånt som dette:
Kjære,
Først av alt, din nexus du kan ha for deg selv. Jeg har ikke tilgang til din Nexus
For det andre må alle endringer sendes som en endringsforespørsel.
Du må trekke ut SQL-skriptene fra Nexus og legge dem ved endringsforespørselen.
Hvis endringen ikke er nødstilfelle, bør dette gjøres 7 dager før utgivelse (eksklusivt i helgen)
Når endringsforespørselen din er godkjent av en haug med mennesker, vil DBA kjøre skriptet ditt og til og med sende et skjermbilde av resultatet per post.Vennlig hilsen din DBA som har jobbet her siden mainframe-dagene.
Vet du hva dette minner meg om? Semi-automatisering: roboten holder rammen, og arbeideren slår den med en slegge. Vel, egentlig, hva er vitsen med denne Nexusen hvis så alt gjøres helt manuelt?
Men Enterprise bør ikke klandres for dette! Det er selvfølgelig blodig, men alt dette byråkratiet med Change Requests er tvunget og kommer fra revisorer. Enterprise må fungere på denne måten, punktum. Han kan ikke gjøre det på noen annen måte. Og revisjon er en veldig konservativ ting. Hvor mye har for eksempel blitt sagt om det faktum at lange pseudo-komplekse og ofte endrede passord er dårlige, men bedrifter vil være det siste stedet der dette vil bli endret. Også med utplasseringer og alt annet.
Forresten, på en gang prøvde jeg å lage en fil for terraform, men det fungerte ikke. Jeg snublet over betydningen av 'Project Accounting Billing Code'-taggen, som jeg aldri klarte å finne ut - jeg hadde ikke nok myke ferdigheter.
Jeg tar ikke engang på meg temaet passiv luddisme - å, automatiseringen din truer jobbsikkerheten min, jeg vil ikke lære noe nytt, så jeg saboterer det stille.
Vel, hva kan være løsningen i prinsippet? ITSM-systemet har et ekstremt primitivt API for automatisk generering av dokumenter. Og generelt kommer de fleste av disse systemene fra stormaskinens tid. Er det noen som kjenner noen virkelig moderne ITSM-systemer? Er det noen som har vellykket erfaring med å integrere moderne DevOps og byråkrati? Vi snakker selvfølgelig ikke om rene salgssteder, hvor det faktisk kan være en utplassering hver dag, men for eksempel banksektoren, som er under revisorer og veldig sterk isolasjon i høyere miljøer.
Bare ikke glem at alle fantasiene dine er begrenset av tilsynet. Og det forandrer alt. Jeg venter på deg i kommentarfeltet!
Kilde: www.habr.com