Automatyzacja i programowanie w świecie infrastruktury

Krzysztof Kempiński
Jun 15 · 16 min read

W ramach podcastu “Porozmawiajmy o IT” miałem okazję porozmawiać z Piotrem Wojciechowskim o automatyzacji i programowaniu w świecie infrastruktury.

Posłuchaj naszej rozmowy w wersji audio 🎧 👇

Cześć! Mój dzisiejszy gość to konsultant IT, architekt rozwiązań sieciowych, programista, entuzjasta rozwiązań chmurowych, partner w firmie Inleo, zajmuje się zagadnieniami z zakresu routingu, switchingu, IP MPLS, SDN oraz cloud computingu. Bloger, w wolnym czasie deweloper w projektach open source, między innymi Ansible. Miłośnik kotów i muzyki elektronicznej. Moim i Waszym gościem jest Piotr Wojciechowski.

Cześć, Piotrze! Bardzo miło mi gościć Cię w podcaście.

Cześć! Dziękuję za zaproszenie, witam wszystkich słuchaczy.

Padło tu dużo pojęć, ale wszystko prowadzi nas do tematu tego odcinka, którym jest automatyzacja i programowanie w świecie infrastruktury. Ale zacznijmy od standardowego elementu każdego mojego podcastu, czyli od pytania do Ciebie, Piotrze. Czy słuchasz podcastów? Jeśli tak, to może masz swoje ulubione audycje?

Praktycznie cały czas w ciągu dnia leci jeden podcast, on się nazywa DnbRadio, dlatego że dla mnie muzyka jest tłem do wykonywania prawie wszystkich czynności, także tych zawodowych. Czasami nawet zapominam wyłączyć muzykę na czas jakichś calli. Muzyka z tych podcastów, bo to są sety didżejskie, które trwają po trzy godziny, jest dobrym motywatorem do tego, żeby się skupić na pracy, bo gadanie mnie trochę bardziej rozprasza.

Z bardziej gadających podcastów, to okazjonalnie tylko słucham Cyber, Cyber, jak się pojawiają dobre tematy, również niektórzy goście u Ciebie. Z takich nie informatycznych, powiedzmy, około informatycznych rzeczy lubię podcast Mała Wielka Firma. Inne rzeczy tylko punktowo, jak się pojawi jakiś temat, który chcę zgłębić i okazuje się, że jest to w formie podcastu, a nie tylko czytania, to ewentualnie wtedy szukam i odsłuchuję. Chociaż chyba wolę książki.

Jasne, ja też nie potrafię pracować i jednocześnie słuchać rozmów. To angażuje pewnie podobną część mózgu, więc bardzo ciężko jest mi się skupić na jednym albo na drugim, a takie przeskakiwanie też nie jest efektywne.

Chciałbym Cię zapytać o taką rzecz, o której coraz więcej się słyszy, która przybliża trochę świat infrastruktury i programowania, czyli definiowanie infrastruktury kodem. Infrastructure as a code — to pojęcie jest coraz modniejsze. Chciałbym Cię poprosić o to, żebyś trochę przybliżył, czym to podejście jest, czym się charakteryzuje, na jaki problem odpowiada?

Jeżeli spojrzymy na infrastrukturę historycznie, to mamy jednak hardware. Hardware, który kojarzy się wszystkim z niebieskim kablem konsolowym do portu Cisco i zaczynamy konfigurować to urządzenie. W naszym nowoczesnym świecie, gdzie budowa aplikacji to nie jest wypuszczanie produktu raz na pół roku, tylko to są bardzo dynamiczne zmiany, które muszą odzwierciedlać się w infrastrukturze, musimy zacząć programować infrastrukturę od samego budowania jej.

Oczywiście chmura publiczna bardzo tutaj pomogła, tam nie mamy fizycznego sprzętu, do którego się dostajemy. Nawet ten tradycyjny sprzęt sieciowy, który jest wirtualizowany, można już nie konfigurować ręcznie, ale wpisać w cały proces budowania infrastruktury dla konkretnej aplikacji. Infrastruktura bez aplikacji nie ma sensu, jak i aplikacja bez infrastruktury nie ma sensu.

Te dwa środowiska połączyły się ze sobą już bardziej ściśle. Używając konkretnych języków programowania, nazwijmy to tak szeroko, po prostu wpisujemy proces budowania zwirtualizowanej infrastruktury dla tej aplikacji. Niezależnie czy ta infrastruktura będzie na koniec na tak zwanym bare metalu, czy będzie rzeczywiście zwirtualizowana, czy całkowicie w chmurze, jest programowana po to, żeby spełniać wymogi tej aplikacji i reprogramowana wraz ze zmianą tej aplikacji bądź potrzeb, które się pojawiły w czasie jej eksploatowania. Jednak to biznes narzuca nam, co jako informatycy robimy.

Tak, dokładnie. Usłyszałem o tym po raz pierwszy kilka lat temu na konferencji. Oczywiście wtedy pokazywano przykład, jak mniej więcej użyć infrastructure as a code po to, by definiować taką infrastrukturę działającą w chmurze. Myślę, że wielu osobom to skojarzenie przychodzi na myśl jako pierwsze, kiedy słyszą infrastructure as a code, czyli chmura. Ale okazuje się, że z wykorzystaniem tego podejścia możemy też programować tradycyjną infrastrukturę, o której na początku powiedziałeś. Czy to faktycznie jest równie popularne i czy te dwa podejścia różnią się od siebie, czy też nie ma to żadnego znaczenia?

Efektem końcowym zawsze jest fizyczne czy wirtualne urządzenie sieciowe, które ma wgraną jakąś konfigurację. Patrząc na tradycyjne rozwiązania, które mamy, to nadal jednak to urządzenie gdzieś istnieje. To jest kwestia tego, w jaki sposób zarządzamy tym urządzeniem, jak szybko jesteśmy w stanie wprowadzić zmiany, zrekonfigurować bądź postawić nowe urządzenie od podstaw. I to rzeczywiście działa w ten sposób, że na koniec wynik, który otrzymujemy nie różni się dużo od tego, co robimy. Natomiast możemy szybciej reagować na pewne rzeczy.

Jeżeli używamy zaawansowanej telemetrii, możemy zautomatyzować proces rekonfiguracji infrastruktury po to, żeby szybko odpowiadać na pewne zdarzenia, które wykrywają systemy monitoringu. Jeżeli mówimy o wdrożeniu czy skalowalności pewnego systemu teleinformatycznego, to automatyzacja pozwala nam wykonać zmianę, na którą kiedyś potrzebowaliśmy dwa tygodnie w dwie godziny. Jeżeli potrzebujesz zwirtualizować liczbę firewalli, bo Twoja infrastruktura już nie jest w stanie wyrobić z ilością nachodzących pakietów z politykami, jesteśmy w stanie to szybko zrobić. Przenieść polityki — nie ma problemu, odwzorowujemy je, ponieważ one są gdzieś zaprogramowane, opisane.

Jednocześnie mamy dodatkowy element bezpieczeństwa związany z tym, że gdzieś jest repozytorium tego, w jaki sposób ta infrastruktura jest programowana. W związku z tym możemy śledzić te zmiany wstecz, możemy wprowadzać poprawki, możemy testować na osobnych środowiskach poprawki, które są wprowadzane i wpisać je w cały model życia tej sławnej aplikacji, dla której to wszystko budujemy.

To też zależy, co robimy. Są systemy komercyjne, są systemy open source’owe. Systemy komercyjne próbują jeszcze bardziej zdjąć tę inżynierską część pracy dając, nie chcę powiedzieć: „pani sekretarce”, portal do wyklikiwania infrastruktury. Ale już od wielu lat, jak przychodzimy do jakiegokolwiek biura, mamy sieć guestową. To nie informatyk generuje nam dostęp do guestowego WiFi. Robi to recepcja, mimo że osiągnięcie tego wymaga pewnych czynności automatycznych. Wykreowanie konta, danie dostępu, przydzielenie odpowiednich uprawnień temu gościowi to czynności, które wykonywane są w sposób automatyczny na systemach IT.

Po części idea przejścia w automatyzację ma też przenieść ciężar budowania systemu IT czy wyklikiwania jego warunków brzegowych co najmniej z poziomu technicznego na poziom biznesowy. Nie widzę docelowo problemu, żeby to project manager powiedział na podstawie tabel — myślę, że każdy project manager powinien umieć zanalizować tabelkę — że początkowo potrzebujemy jakąś grupę wirtualnych urządzeń, na których to będzie działało. Potem możemy to dalej skalować oczywiście.

Rozumiem. Dotknąłeś tu dwóch obszarów, mianowicie infrastruktury i osób standardowo odpowiedzialnych za infrastrukturę oraz aplikacji tworzonych przez programistów. Czyli dwa światy, które do tej pory były może nie antagonizujące, ale bardzo często zrzucające odpowiedzialność za pewne niedoróbki na siebie nawzajem. Był rozdźwięk, rozstrzał pomiędzy programistami i osobami, które później uruchamiały to na przykład tworząc infrastrukturę. Jedni i drudzy za mało wiedzieli o swojej pracy, żeby zrozumieć z jakimi problemami na co dzień się mierzą. Oczywiście jakiś czas temu pojawiła się filozofia czy też podejście DevOps, które trochę zasypuje te różnice. Chciałbym Cię zapytać, jak Ty to widzisz ze swojej pracy. Czy te podziały są na tyle znaczące, że to widać? Czy wprowadzenie rozwiązań automatyzacji infrastructure as a code może przybliżyć jeden i drugi obóz do siebie?

Musi przybliżyć, bo jak tego nie przybliży, to nic nie osiągniemy, a zrobimy sobie nawzajem tylko krzywdę. Masz rację, że światy programistów i ludzi od infrastruktury były bardzo od siebie oddalone. Brak zrozumienia po części wynika moim zdaniem z błędów w nauczaniu. Na poziomie uniwersytetów czy politechnik jest za dużo matematyki, która się przydaje tylko naukowcom, a nie w praktycznych umiejętnościach zawodowych. Umiejętności programistycznych uczy się trochę w oderwaniu od technologii, z którymi programiści będą obcowali. Kończymy na tym, że programista pisząc aplikację sieciową w ogóle nie rozumie, jak działa sieć i mechanizmy. Skrajnym przypadkiem, wielokrotnie przeze mnie spotykanym jest to, że programiści próbują otwierać sesję TCP i trzymać ją w nieskończoność. A potem się dziwią, że włącza się firewall, aplikacja się rozjeżdża i winią infrastrukturę. Nie rozumieją tych podstawowych metod. Tego dialogu już od dawna brakowało.

Masz rację, że światy programistów i ludzi od infrastruktury były bardzo od siebie oddalone. Brak zrozumienia po części wynika moim zdaniem z błędów w nauczaniu. Na poziomie uniwersytetów czy politechnik jest za dużo matematyki, która się przydaje tylko naukowcom, a nie w praktycznych umiejętnościach zawodowych. Umiejętności programistycznych uczy się trochę w oderwaniu od technologii, z którymi programiści będą obcowali. Kończymy na tym, że programista pisząc aplikację sieciową w ogóle nie rozumie, jak działa sieć i mechanizmy.

Rzeczywiście, wchodząc w automatyzację, świat infrastruktury musi przyjąć programistyczne podejście, czyli musi nauczyć się Gita, musi rozumieć, jak działają repozytoria, musi rozumieć mechanizmy automatyzacji oraz to, jak działają kontenery. Mimo że kontenery nie są częścią infrastruktury sieciowej, mogą być elementem w niektórych routerach, gdzie aplikacja może być wyniesiona. Mamy cały świat, który ludzie od infrastruktury muszą zrozumieć, ale jednocześnie deweloperzy muszą zacząć rozmawiać z ludźmi od infrastruktury na temat tego, jak można zrobić coś dobrze albo lepiej, w jaki sposób można wykorzystać infrastrukturę albo czego nie wolno robić.

DevOps, o którym wspomniałeś, rzeczywiście wymusza zderzenie tych dwóch światów. To zderzenie może być czasem bardzo bolesne, bo to są często ludzie, którzy rozmawiają zupełnie innymi językami. Obracamy się w jednym świecie IT, a korzystamy z innych słowników. W momencie kiedy zaczynamy zderzać te światy ze sobą, to rzeczywiście dochodzi do fajnego porozumienia. Programiści zaczynają rozumieć, że aplikacja nie działa w próżni. To, że te pakiety są przesyłane, jest wynikiem infrastruktury, która ma swoje konkretne ograniczenia. Być może aplikacja musi w jakiś sposób te ograniczenia monitorować, żeby zareagować na poziomie aplikacyjnym, a nie tylko infrastrukturalnym. Pewne rzeczy, tak jak wspomniana wiecznie żyjąca sesja TCP, to nie jest dobre rozwiązanie. Jednocześnie ludzie, którzy zarządzają czy programują infrastrukturę są w stanie zrozumieć też pewne wymagania deweloperów, ograniczenia języków, bibliotek, które są używane. Czasami może nam się wydawać, że coś jest przecież proste, że to się da zrobić. To nie do końca tak działa.

Jest jeszcze oczywiście cała kwestia związana ze skalowalnością. Ludzie od infrastruktury często nie rozumieją problemów związanych z tym, że aplikacje nie skalują się tylko przez dokładanie kolejnych wątków czy kontenerów do całego rozwiązania. Skalowalność infrastruktury musi też być powiązana z tym, w jaki sposób działa sama aplikacja. Pole do kompromisu, do wzajemnego zrozumienia jest i na pewno wszyscy wyjdziemy z tego trochę mądrzejsi i bardziej poukładani jako świat IT. Zresztą nie wiem, czy zauważyłeś, bardzo często się mówi, że IT to programiści, programiści i ci drudzy, prawda?

Właśnie, cieszę się przede wszystkim, że tak optymistycznie do tego podchodzisz. Ja też mam wrażenie, że to idzie w dobrym kierunku, bo faktycznie musimy wrócić do czegoś, co było dosyć oczywiste, kiedy ja zaczynałem karierę w IT. Nazwałbym te osoby, które wówczas pracowały, takimi full stackami, ale przez cały stack technologiczny. To były najczęściej osoby, które nie tylko potrafiły uruchomić aplikację i ogarnąć infrastrukturę, ale również na przykład napisać trochę kodu. Miały takie szersze zrozumienie.

Oczywiście można dyskutować, czy rozwój technologii zablokował możliwość bycia ekspertem we wszystkim. Natomiast w pewnym momencie osiągnęliśmy dużą granulację specjalizacji IT, do tego stopnia, że jedna ręka nie wiedziała, co robi druga. Teraz powoli zaczyna się odwrotny trend, żeby jednak łączyć wiedzę z różnych dziedzin, bo to na skraju powstają zazwyczaj najfajniejsze rozwiązania. Mam wrażenie, że ruch DevOps sporo pomógł. Nie obrażanie się na siebie, ale wzajemne zrozumienie swoich ograniczeń i uwspólnienie języka to jest to, co może nas popchnąć dalej.

Ale też budowanie projektów w ten sposób, że jednak project managerowie nie traktują samej infrastruktury jako usługi, która musi być im świadczona, tylko jako element całego projektu. Podejście musi się też zmienić na levelu project managerskim.

Z pewnością. Powiedziałeś, że mamy podział na programistów i tych innych.

I bezpieczniki jeszcze.

Tak, na tych innych. Często słyszę taki zarzut, że przecież branża IT, to nie jest tylko programowanie. Tymczasem my znowu mówimy o programowaniu. Mówimy o infrastrukturze i mówimy o programowaniu, czyli znowu programowanie wdziera się w kolejną branżę. Chcę Cię zapytać, czy faktycznie jest tak, że ludzie od infrastruktury powinni znać programowanie, czy jest to pewien dodatek, który wnosi coś nowego, ale jeszcze nie jest niezbędny? Jak Ty patrzysz na połączenie tych dwóch dziedzin?

Powinni, co nie znaczy, że muszą. Oczywiście zawsze mogą, tak jak programiści COBOL-a, czekać bardzo długo, żeby teraz być niezbędnymi na rynku. Pytanie tylko, czy to jest właściwa ścieżka? Trzeba mieć świadomość tego, jakie są trendy i w którą stronę świat IT zmierza. Wystarczy spojrzeć na duże korporacje, które inwestują bardzo dużo pieniędzy w rozwiązania zautomatyzowane, w szerzenie tej wiedzy. Jeżeli nie tylko jedna firma idzie w tę stronę, to znaczy, że coś musi być na rzeczy. Po drugie biznes wymaga tego usprawnienia, ponieważ inaczej brak automatyzacji generuje zbyt duże koszty i firma przestaje być konkurencyjna.

Jako inżynierowie infrastruktury możemy nie wchodzić w automatyzację i próbować sobie znaleźć pewne wąskie działki, które nie zostaną albo w minimalnym stopniu zostaną zautomatyzowane i w tej działce grzecznie siedzieć. Wielu osobom to odpowiada, wiele osób boi się zmian, przyzwyczajeni są do konsoli i taka zmiana jest dla nich pewną rewolucją. Może tych osób nie należy wrzucać na głęboką wodę, tylko dać im czas na spokojną transformację i pozostanie ekspertem w pewnych bardzo wąskich dziedzinach, ale ze zrozumieniem, że ten świat obok istnieje.

Wszyscy musimy stać się programistami tej automatyzacji, ponieważ inaczej docelowo nie będziemy mieli pracy, taka jest prawda. Konfigurowanie przez konsolę przestaje być czymś powszechnym. W dużych systemach mamy zero-touch provisioning, czyli podłączenie i zautomatyzowanie nawet pierwszego etapu konfiguracji jest już czymś bardzo ważnym. Jak spojrzymy wstecz, z punktu widzenia inżynierskiego, to my ograniczamy trochę tę automatyzację do programowania.

Ale spójrzmy na większe projekty. Kiedyś w Excelu były generowane szablony konfiguracji wgrywane na komputery. Jak zaczniemy patrzeć na pewne rzeczy, które wcześniej przygotowywaliśmy, to też jest to jakaś forma automatyzacji naszych czynności. My z tą automatyzacją wbrew pozorom mamy już styczność, tylko my jej nie nazywaliśmy jeszcze nigdy w ten sposób. To teraz nazwijmy rzeczy po imieniu i dodajmy do tego tę aplikację, która zaczyna być ważna, z którą musimy jako infrastruktura współdziałać.

Żeby jeszcze dobitniej zrozumieć to, dlaczego warto — bo tak jak powiedziałeś, może na ten moment jeszcze nie trzeba, ale z pewnością warto, zwłaszcza myśląc o przyszłości — spróbujmy zastanowić się, jakie korzyści daje programowanie i automatyzacja infrastruktury dla takiego inżyniera, który na co dzień zajmuje się infrastrukturą, jak również dla firmy, która ewentualnie w ten sposób będzie swoją infrastrukturę definiować i w ten sposób nią zarządzać.

Moim zdaniem, podstawowa zaleta z punktu widzenia inżyniera jest taka, że nauczymy się, jeśli jeszcze nie umiemy, albo udoskonalimy logiczne myślenie. Programowanie jest ściśle związane z algorytmiką, a mam takie wrażenie, że często osoby, które kończą jakieś punktowe kursy produktowe i przechodzą do zarządzania i budowania pewnych systemów, nie mają analitycznego podejścia do tego, co chcą osiągnąć. Jak powinien działać ten mechanizm? Jak powinno się go zaprojektować? Jakie mogą być tego wady i zalety? Takie algorytmiczne myślenie wdrażane już na wczesnych etapach nauki będzie dobre dla architektów, ale także dla ludzi, którzy pracują w centrach operacyjnych. Rozwiązywanie problemów bez sensownego algorytmicznego podejścia do zanalizowania tego problemu tak naprawdę nie ma sensu. To jest trochę rzucanie się w ciemno — może tu jest błąd, a może tu — a nie proces, który następuje.

Programowanie jest ściśle związane z algorytmiką, a mam takie wrażenie, że często osoby, które kończą jakieś punktowe kursy produktowe i przechodzą do zarządzania i budowania pewnych systemów, nie mają analitycznego podejścia do tego, co chcą osiągnąć. Jak powinien działać ten mechanizm? Jak powinno się go zaprojektować? Jakie mogą być tego wady i zalety? Takie algorytmiczne myślenie wdrażane już na wczesnych etapach nauki będzie dobre dla architektów, ale także dla ludzi, którzy pracują w centrach operacyjnych.

Oprócz typowych skillów programistycznych, nauczenia się nowego języka, nowych produktów, mamy skille softowe związane z algorytmiką, analityką, które zawsze nam się przydają. Z punktu widzenia inżyniera poznawanie nowych produktów to jest coś, co powinno być elementem naszej codziennej pracy, nawet jeżeli pracujemy w centrum operacyjnym. Powinniśmy poszerzać swoje horyzonty, rozumieć co się dzieje na rynku, w jakikolwiek sposób próbować dotykać nowych produktów. Zresztą praktycznie każdy dostawca chmury publicznej zachęca nas do poznania tych usług oferując darmowy dostęp do wybranych podstawowych usług, dodatkowe pakiety dla studentów, licencje dla studentów.

Oczywiście to jest marketingowe zagranie „poznaj nasz produkt, może zostaniesz”. Ale student wchodzi i ma możliwość zobaczenia, jak się buduje sieć, maszyny wirtualne, systemy load balancingu, systemy bezpieczeństwa w trzech głównych chumrach od trzech głównych dostawców. Nie musi od razu robić certyfikatów w tym kierunku, choć oczywiście może. Natomiast wiedza i pojęcie o tym, jak działa infrastruktura czy właśnie te natywne chmurowe aplikacje, jak ja to nazywam, czyli coś, czego nie osiągniesz we własnym labie, daje naprawdę dużą wiedzę o tym, jakie narzędzia są wykorzystywane. Co za tym idzie, będzie można kreować swoją ścieżkę kariery, dostosowywać do tego, jakie są trendy, ale także lepiej rozumieć wymagania biznesu, który chce z pewnych narzędzi skorzystać bądź właśnie wymagania programistów, którzy będą próbowali z tych narzędzi korzystać.

Uważam więc, że każdy inżynier powinien starać się codziennie poszerzać swoją wiedzę i wejście w automatyzację na pewno otwiera całe spektrum nowego świata. Oczywiście rozwiązania komercyjne też są rozwiązaniami związanymi z automatyzacją, choć tutaj może być trochę ciężej do wejścia. Prawdopodobnie firma musi kupić szkolenie, ale często vendorzy oferują różnego rodzaju warsztaty, żeby zachęcić do produktu. Ja zawsze mam taką maksymę, że jeżeli szef nie pozwala ci się rozwijać, to zmień pracę. Jeżeli nie pozwala nawet uczestniczyć w darmowych warsztatach, to jest to żółte światło, że może coś jest jednak nie tak.

Jeżeli firma nie będzie automatyzować czynności, to nie będzie redukować kosztów. Redukcję kosztów można oczywiście zrobić przez zwolnienia, ale zwolnienia są wtedy, kiedy brakuje zleceń. Zleceń brakuje dlatego, że firma jest za droga na rynku, nie jest konkurencyjna i koło się zamyka. Musimy automatyzować czynności, dlatego że inni to robią. Jeżeli nasz konkurent potrafi wykonać konfigurację w czasie o połowę krótszym od nas albo angażując połowę zespołu, to automatycznie będziemy drożsi. Musimy albo obniżać ceny, ciąć zatrudnienie i pensje, szukać oszczędności w innych działach, albo konkurować tym, że jesteśmy w stanie to wykonać lepiej, szybciej, taniej korzystając właśnie z różnego rodzaju narzędzi zautomatyzowanych.

Automatyzacja może być zarówno związana z operacjami, utrzymywaniem infrastruktury, sprawdzeniem, testami bezpieczeństwa, jak i z budowaniem czy obrabianiem danych, których potrzebujemy na końcu do wykonania ręcznej konfiguracji. Oczywiście rozmawiamy tutaj o automatyzacji w infrastrukturze, ale dane, które będziemy wykorzystywali, liczbę serwerów, numery VLAN-ów, sprawdzenie, czy się nie pokrywa adresacja, która została wstępnie nadana też można zautomatyzować. Są to akurat czynności, które potencjalnie można wykonać skończoną liczbą studentów, ale po co? Taniej jest jednak maszyną wirtualną, która za nas to wykona, a zatrudnionego studenta lepiej rozwijać w bardziej fachowych rzeczach niż analizowanie tabelek Excela.

Przyszło mi na myśl, że kolejnym benefitem może być pewna standaryzacja infrastruktury za pomocą kodu, dzięki czemu nowym osobom w zespole łatwiej jest zrozumieć, co się dzieje. Ograniczamy wiedzę plemienną polegającą na tym, że jest jeden super informatyk, super admin, który potrafi zaczarować w konsoli. Jest to bardziej przejrzyste, bardziej udokumentowane, bardziej jawne dla nowych osób. To kolejna przewaga, która może zmniejszyć na przykład ryzyko rotacji w firmie i utraty wiedzy. Nie wiem czy się ze mną zgodzisz?

Tak. Wspomniałeś o utrzymaniu infrastruktury, ja bym to nawet rozszerzył do budowania nowych projektów. Jeżeli mamy czynności powtarzalne, które są w większości projektów wdrażanych u klientów i będą one zautomatyzowane, to mamy ustandaryzowany produkt, z którym łatwiej pójść do klienta. Idziemy i pokazujemy, że wdrażamy bezpieczeństwo, mamy swoje template’y do wdrożenia i sprawdzenia reguł bezpieczeństwa na firewalla, skalowania tych firewalli czy wykonywania okresowych testów. To są nasze standardy, jest to fajnie opisane i mamy x zadowolonych klientów, którzy z tego korzystają. Na podstawie tych szablonów tworzymy ustandaryzowaną usługę, którą zawsze jest łatwiej sprzedać niż każdemu klientowi oferować coś bardzo unikalnego.

Jasne, oczywiście, że tak. Z programowaniem jest tak, że ta umiejętność wymaga czasu, zaangażowania i wielu ćwiczeń, żeby być sprawnym w posługiwaniu się językiem programowania, w zrozumieniu tych konceptów. Takie podejście, kiedy pewnego dnia szef decyduje, że teraz będziemy wszystko automatyzować za pomocą kodu, nie jest najlepsze. Dobrze by było, gdyby inżynierowie pracujący nad infrastrukturą mieli czas, żeby się nauczyć tej umiejętności, poznać ją trochę, poeksperymentować. Chcę Cię zapytać o to, jak zachęcić inżyniera, który zajmuje się infrastrukturą do tego, żeby zainwestował swój dodatkowy czas w to, żeby poznać narzędzia programowe pozwalające mu automatyzować? Jak przekonać taką osobę, żeby zrozumiała, że to jest inwestycja w przyszłość, w rozwój?

Opieram się tutaj w dużej mierze na swoich projektach, na produktach open source’owych. Przy produktach komercyjnych zazwyczaj jest tak, że firma odgórnie decyduje się na wdrożenie konkretnego produktu, ponieważ widzi w sprzedaży jakąś wartość biznesową, zostało tak sprzedane. W związku z tym dziś systemy automatyzacyjne dużych korporacji mogą być wdrażane i tutaj produkt jest trochę narzucony. Więc trzeba raczej przekonać inżyniera, żeby chciał korzystać z tego produktu niż przekonywać do własnej automatyzacji.

Przekonanie do tego, że warto wejść i poszerzać swoje horyzonty jest wtedy, kiedy inżynier zaczyna widzieć wartość dodaną do pracy, zarówno w swojej karierze, jak i dla całej firmy. I nie może to być metoda straszenia, bo widziałem już takie przykłady pod tytułem: „Wszyscy się automatyzują, to my musimy, bo jak nie, to będą zwolnienia”. No nie, to jest już skrajna patologia, niestety takie rzeczy też się dzieją, że automatyzacja w firmie z jednej strony jest wprowadzana bez przemyślenia, a z drugiej strony jest siłą narzucana inżynierom. Inżynierowie muszą zrozumieć i poznać wartość.

To jest proces, w którym pokazujemy, co można zrobić, dlaczego coś robimy, w jaki sposób to robimy, żeby oni potem przełożyli pewne, nie chcę powiedzieć hasła i slogany, ale pewne pokazy, bo ja lubię prezentować tego typu rzeczy na podstawie demo. Ty mi skonfiguruj pięćdziesiąt switchy, a ja Ci to zrobię skryptem — to jest namacalny dowód, który każdy jest w stanie poczuć, że jeżeli tego nie będzie robił, to zostaje gdzieś w tyle. I dalej składamy z takich klocków podejście do tego, co możemy zrobić. Szukamy benefitów dla firmy i dla konkretnego projektu. Czasem dla konkretnego projektu możemy zrobić coś szybciej, a czasami zrobimy to jednocześnie dla dziesięciu klientów, a nie dla dwóch w tym samym czasie. Szukamy tego typu benefitów. I szukamy w jaki sposób zachęcić ludzi, żeby te systemy automatyzacji tworzyli.

W przypadku rozwiązań open source’owych jest to cykl, który dzieje się wewnątrz firmy, nie kupujemy produktu. Nawet jeśli weźmiemy przykładowo Ansible’a, mamy masę playbooków, z których możemy skorzystać, ale większość to są i tak opublikowane szablonowe rozwiązania, które na koniec musimy dostosować do swoich potrzeb. Jeżeli mamy projekt, w którym musimy zmienić description na wszystkich portach przełączników, a mamy ich w sieci tysiąc, to nawet jeśli mamy szablon nadal musimy dopracować cały skrypt, żeby spełniał nasze założenia, był bezpieczny, a najlepiej jeszcze, żebyśmy wiedzieli jak zautomatyzować bezpiecznie jego uruchamianie. Nawet jeśli mamy zautomatyzowany proces, to musimy mieć jeszcze infrastrukturę, która będzie tę automatyzację obsługiwała, a co ciekawe na tej infrastrukturze możemy się najlepiej uczyć automatyzacji.

Uczmy się nowych produktów. Jeżeli potrzebujemy Ansible’a, to nauczmy się go postawić, jeżeli potrzebujemy Jenkinsa, nauczmy się go postawić, zobaczmy jak to się robi, a może zarządzajmy już od razu tym Jenkinsem w sposób zautomatyzowany. Ja pokazuję, i to pokazuję ludziom od sieci, mojego domowego laba, w którym Jenkins buduje się sam codziennie z repozytorium i aktualizuje się na moim serwerze, bo stwierdzam, że chcę mieć zawsze działającą najnowszą wersję. Budowa Jenkinsa odbywa się w samym Jenkinsie, więc jest pokazane, jak te narzędzia można ze sobą wykorzystywać, łączyć. Jest do tego oczywiście GitLab, gdzie jest repozytorium skryptu Jenkinsa, ale to już jest namacalny dowód, że coś się dzieje, że ja nie muszę wykonywać tych czynności. Budując ten system automatyzacji, buduję własną infrastrukturę, która już się na tej automatyzacji opiera w jakiś sposób. I to jest pierwsze wejście. Jeżeli coś zepsujemy w Labie, to spoko, to jest pole do nauki, przynajmniej powinno być pole do nauki. Gorzej jak Lab jest na infrastrukturze klienta, to już nie jest dobry pomysł. Ale mamy pole do nauki, w ramach którego możemy popełniać błędy i zobaczyć namacalnie, że automatyzacja infrastruktury działa, czy to u nas na serwerze czy w chmurze publicznej.

Budując ten system automatyzacji, buduję własną infrastrukturę, która już się na tej automatyzacji opiera w jakiś sposób. I to jest pierwsze wejście. Jeżeli coś zepsujemy w Labie, to spoko, to jest pole do nauki, przynajmniej powinno być pole do nauki. Gorzej jak Lab jest na infrastrukturze klienta, to już nie jest dobry pomysł. Ale mamy pole do nauki, w ramach którego możemy popełniać błędy i zobaczyć namacalnie, że automatyzacja infrastruktury działa, czy to u nas na serwerze czy w chmurze publicznej.

Ta standaryzacja, o której wspomniałeś, jest także dodatkową wartością w przypadku, kiedy mamy środowiska, które są oparte po części na on-premie, po części na chmurach publicznych, takie typowo hybrydowe rozwiązania. Możemy zobaczyć, jak korzystając z jednej bazy wiedzy zapisanej na GitLabie, możemy wdrażać te same procesy bardzo szybko w różnych środowiskach. To jest do przetestowania najpierw w Labie, zanim pójdzie na produkcję do klienta, ale jest to świetne pole doświadczalne.

👉 Czytaj dalej na: https://porozmawiajmyoit.pl/poit-120-automatyzacja-i-programowanie-w-swiecie-infrastruktury/

kkempin’s dev blog

Dev and life blog. Thoughts about programming, design patterns, Ruby and life.

Krzysztof Kempiński

Written by

IT expert. Ruby on Rails/iOS/Elixir programmer. Blogger. Podcaster.

kkempin’s dev blog

Dev and life blog. Thoughts about programming, design patterns, Ruby and life.