Tematyka DevOps i IaC cieszy się dużą popularnością i szybko się rozwija. Jednak większość autorów koncentruje się wyłącznie na technicznych problemach związanych z tą ścieżką. Ja natomiast opiszę problemy charakterystyczne dla dużej firmy. Nie mam rozwiązań — problemy są generalnie poważne i dotyczą kwestii biurokratycznych, audytu oraz „soft skills”.
Skoro artykuł nosi taki tytuł, to jako kotek wystąpi Daenerys, która przeszła na stronę Enterprise.
Niewątpliwie, obecnie następuje zderzenie starego z nowym. I często w tych kolizjach nie ma ani zwycięzców, ani przegranych. Tak już wyszło. Jednak, aby nie być gołosłownym, zaczniemy od tego ekranu:
To tak zwany Change Request. Widzicie mniej więcej jedną trzecią pól, które trzeba wypełnić z różnych katalogów, pozostałe pola znajdują się na innych zakładkach. Taki dokument należy wypełnić, aby zastosować skrypt w produkcji. serwera, lub wgrać nowe pliki i w ogóle, cokolwiek zmienić.
Liczba pól jest tak duża, że napisałem swoją małą automatyzację do ich wypełniania. Co więcej, ta strona została napisana w taki sposób, że żadne narzędzia automatyzacji nie widzą jej pól, a jedynym możliwym rozwiązaniem było użycie AutoIt, aby po prostu klikać myszką w odpowiednie współrzędne. Oceńcie stopień desperacji, aby zdecydować się na coś takiego:
Więc bierzecie jenkins, chef, terraform, nexus i inne, i radośnie wdrażacie to na swoim dev. Ale przychodzi czas, aby wysłać to do QA, UAT i PROD. Macie artefakt z Nexusa i otrzymujecie e-mail od DBA o mniej więcej takiej treści:
Szanowny Panie,
Po pierwsze, wasz nexus macie, a ja nie mam dostępu do waszego Nexusa.
Po drugie, wszystkie zmiany muszą być sformalizowane jako Change Request.
Skrypty SQL musicie wyodrębnić z Nexusa i załączyć do Change Request.
Jeśli zmiana nie jest nagła, należy to zrobić w ciągu 7 dni od wydania (wyłącznie w weekend).
Gdy wasz Change Request zostanie zatwierdzony przez wielu ludzi, DBA wykona wasz skrypt i nawet wyśle e-mailem zrzut ekranu z wynikiem.Z poważaniem, wasz DBA, który pracuje tu od czasów mainframe.
Wiecie, co mi to przypomina? Półautomatyzację: robot trzyma podstawę, a pracownik uderza w nią młotkiem. No naprawdę, jaki sens ma ten Nexus, skoro potem wszystko robi się całkowicie ręcznie?
Ale nie należy w tym winić Enterprise! Oczywiście, jest on krwawy, ale cała ta biurokracja związana z Change Requests jest wymuszona i pochodzi od audytorów. Enterprise musi tak działać i kropka. Nie może postępować inaczej. Audyt jest bardzo konserwatywną rzeczą. Ile na przykład mówiono o tym, że długie, pseudoskładne i często zmieniane hasła są złe, ale enterprise'y będą ostatnim miejscem, gdzie to się zmieni. Tak samo z wdrożeniami i wszystkim innym.
A propos, w swoim czasie próbowałem stworzyć plik dla terraform, ale mi się nie udało. Potknąłem się na znaczeniu tagu 'Project Accounting Billing Code', którego tak do końca nie udało mi się poznać — zabrakło mi soft skills.
Nie biorę nawet pod uwagę tematu pasywnego luddysty — och, twoja automatyzacja zagraża mojemu bezpieczeństwu pracy, nie chcę uczyć się niczego nowego, więc będę cicho sabotować.
No i jakie może być w zasadzie rozwiązanie? System ITSM ma ekstremalnie prymitywne API do automatycznego generowania dokumentów. A w ogóle, większość takich systemów pochodzi z czasów mainframe'ów. Może ktoś zna naprawdę nowoczesne systemy ITSM? Może ktoś ma udane doświadczenie z integracją nowoczesnego DevOps i biurokracji? Oczywiście mowa tu nie jest o czysto sprzedażowych stronach, gdzie naprawdę może być wdrożenie każdego dnia, a przykładowo o sektorze bankowym, który jest pod nadzorem audytorów i ma bardzo silną izolację wyższych środowisk.
Tylko nie zapominajcie, że wszystkie wasze fantazje są ograniczone przez audyt. I to wszystko zmienia. Czekam na was w komentarzach!
Źródło: habr.com
