Temat DevOps i IaC jest bardzo popularny i szybko się rozwija. Jednak większość autorów zajmuje się problemami czysto technicznymi na tej ścieżce. Opiszę problemy charakterystyczne dla dużej firmy. Nie mam rozwiązania – problemy w ogóle są fatalne i leżą w obszarze biurokracji, audytu i „umiejętności miękkich”.
Ponieważ tytuł artykułu jest taki, Daenerys, która przeszła na stronę Enterprise, będzie odgrywać rolę kota.
Niewątpliwie teraz następuje zderzenie starego z nowym. I często w tych zderzeniach nie ma ani dobra, ani zła. Tak to się stało. Ale żeby nie być bezpodstawnym, zaczniemy od tego ekranu:
Jest to tak zwane żądanie zmiany. Widzisz około jednej trzeciej pól do wypełnienia z różnych katalogów, pozostałe pola znajdują się w innych zakładkach. Taki dokument trzeba wypełnić, aby móc zastosować skrypt na serwerze produkcyjnym, wgrać nowe pliki, czy w ogóle cokolwiek zmienić.
Ilość pól jest taka, że napisałem własną małą automatyzację wypełniania tych pól. Co więcej, ta strona jest 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 do głupiego klikania myszką na współrzędne. Aby to zrobić, oceń swój poziom desperacji:
Więc bierzesz Jenkinsa, szefa kuchni, terraforma, nexusa itp. i szczęśliwie wdrażasz to wszystko u swojego dewelopera. Nadszedł jednak czas, aby wysłać to do QA, UAT i PROD. Masz artefakt Nexusa i otrzymujesz list od DBA z mniej więcej taką treścią:
Droga,
Po pierwsze, Twój nexus, który możesz mieć dla siebie. Nie mam dostępu do Twojego Nexusa
Po drugie, wszystkie zmiany muszą zostać wydane jako Żądanie Zmiany.
Musisz wyodrębnić skrypty SQL z Nexusa i dołączyć je do żądania zmiany.
Jeśli zmiana nie jest awaryjna, należy tego dokonać na 7 dni przed publikacją (wyłącznie w Weekend)
Kiedy Twoja prośba o zmianę zostanie zatwierdzona przez grupę osób, administrator bazy danych wykona Twój skrypt, a nawet wyśle zrzut ekranu z wynikiem pocztą.Z pozdrowieniami, Twój administrator danych, który pracuje tutaj od czasów komputerów mainframe.
Czy wiesz, co mi to przypomina? Półautomatyzacja: robot trzyma ramę, a pracownik uderza ją młotem. No bo właściwie po co ten Nexus, skoro wszystko robi się całkowicie ręcznie?
Ale Enterprise nie powinien być za to obwiniany! To oczywiście jest krwawe, ale cała ta biurokracja związana z żądaniami zmian jest wymuszona i pochodzi od audytorów. Przedsiębiorstwo musi działać w ten sposób, kropka. Nie może tego zrobić inaczej. A audyt to bardzo konserwatywna sprawa. Ile na przykład powiedziano o tym, że długie pseudo-skomplikowane i często zmieniane hasła są złe, ale przedsiębiorstwa będą ostatnim miejscem, gdzie będzie to zmieniane. Również z wdrożeniami i wszystkim innym.
Nawiasem mówiąc, kiedyś próbowałem utworzyć plik dla terraforma, ale nie zadziałało. Natknąłem się na znaczenie tagu „Kod rozliczeniowy projektu”, którego nigdy nie udało mi się odkryć – nie miałem wystarczających umiejętności miękkich.
Nawet nie poruszam tematu biernego luddyzmu - och, twoja automatyzacja zagraża mojemu bezpieczeństwu pracy, nie chcę się uczyć niczego nowego, więc po cichu to sabotuję.
No cóż, jakie w zasadzie mogłoby być rozwiązanie? System ITSM posiada niezwykle prymitywne API do automatycznego generowania dokumentów. I generalnie większość tych systemów pochodzi z czasów komputerów mainframe. Czy ktoś zna jakieś naprawdę nowoczesne systemy ITSM? Czy ktoś ma udane doświadczenia w integrowaniu nowoczesnego DevOps i biurokracji? Nie mówimy oczywiście o placówkach czysto sprzedażowych, gdzie tak naprawdę codziennie może odbywać się wdrożenie, ale np. o sektorze bankowym, który jest objęty audytorami i bardzo silną izolacją w wyższych środowiskach.
Tylko nie zapominaj, że wszystkie Twoje fantazje są ograniczone przez audyt. A to zmienia wszystko. Czekam na Was w komentarzach!
Źródło: www.habr.com