To jest 172. odcinek podcastu Porozmawiajmy o IT, w którym z moim gościem rozmawiam o transformacji infrastruktury w banku. Sponsorem tego odcinka jest mBank S.A. Przypominam, że w poprzednim odcinku rozmawiałem o języku R. Wszystkie linki oraz transkrypcję dzisiejszej rozmowy znajdziesz pod adresem porozmawiajmyoit.pl/172. 

Ocena lub recenzja podcastu w Twojej aplikacji jest bardzo cenna, więc nie zapomnij poświęcić na to kilku minut. Od niedawna można wystawiać oceny podcastom w Spotify. Będzie mi bardzo miło, jeśli w ten sposób odwdzięczysz się za treści, które dla Ciebie tworzę. Dziękuję.

Ja się nazywam Krzysztof Kempiński, a moją misją jest poszerzanie horyzontów ludzi z branży IT. Środkiem do tego jest między innymi ten podcast. Wspierając mnie przez Patronite, komentarz w social mediach czy podzielenie się tym odcinkiem z innymi, pomagasz w realizacji tej misji. A teraz życzę Ci już miłego słuchania!

Odpalamy!

 

Cześć! Mój dzisiejszy gość to dyrektor departamentu infrastruktury informatycznej w mBank S.A., bankowiec z ponad 20-letnim doświadczeniem w takich specjalizacjach, jak zarządzanie infrastrukturą IT, transformacja technologiczna czy rozwój kanałów cyfrowych. Moim i Waszym gościem jest Aleksander Gawroński.

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

 

Cześć! Dzień dobry, witam Ciebie, witam Wszystkich.

 

Dzisiaj z Alkiem będę rozmawiał o tym, z czym wiąże się i jak wygląda transformowanie i unowocześnianie infrastruktury IT w takiej instytucji, jaką jest bank.

Ale zanim do tego przejdziemy, to standardowo rozpocznę rozmowę od pytania, czy słuchasz podcastów. Jeśli tak, to może masz jakieś audycje, o których warto tutaj powiedzieć?

 

Tak, bardzo często słucham podcastów, to jest taka moja, jak ja to mówię, joggingowa przyjemność, tzn. kiedy sobie biegam, to zazwyczaj czegoś słucham. Może rozpocznę trochę nietypowo, teraz ze względu na sytuację geopolityczną, to trochę przestawiłem się na obserwację świata zewnętrznego, więc mogę tutaj powiedzieć, że teraz akurat dosyć często słucham podcastów albo YouTubów Strategy and Future albo Historia realna.

Ale wracając do naszej branży, to ja dużo czasu wolnego poświęcam bardziej hobbystycznie na tematy cyber security i tutaj mogę polecić Defense in Depth , to jest jeden bardzo fajny podcast, i taki hackerski bardziej: Darknet Diaries – to dosyć interesujące, też mogę polecić.

Z naszego rodzimego podwórka Niebezpieczniki też nagrywają trochę podcastów, a z takiej działki bardziej merytorycznej na pewno polecam Patoarchitektów, podcasty Łukasza Kałużnego, który też z nami dużo współpracuje. I Twój podcast wpada mi też w ucho, czasem wyszukując pewne tematy, kilka odsłuchałem, na pewno mogę polecić bardzo ciekawy odcinek o kulturze IT, bo akurat ten temat kiedyś mocniej zgłębiałem i natknąłem się na bardzo fajną rozmowę na Twoim kanale. Myślę, że tyle mogę polecić, żeby nie zanudzić słuchaczy.

 

Jednym słowem: sporo biegasz, skoro faktycznie udaje Ci się przesłuchiwać tyle podcastów. Dzięki za te rekomendacje.

Przechodząc już do naszej rozmowy, zawsze lubię myśleć o systemach bankowych jak o takim cały czas działającym organizmie, który nigdy nie śpi i działa 24/7 i praca nad takimi systemami to można powiedzieć, że nieco praca na otwartym sercu – nie da się po prostu tego wyłączyć, zrobić swojej roboty i włączyć wszystkiego ponownie.

I w duchu tego stwierdzenia chcę Cię zapytać, jak wobec tego dokonaliście tego typu dzieła pod względem infrastrukturalnym, łącząc BRE Bank, mBank i MultiBank jakiś czas temu?

 

Oczywiście, masz rację, tzn. praca w takiej instytucji jak bank to jest bardzo duże wyzwanie z perspektywy infrastruktury informatycznej, ponieważ musimy zapewnić maksymalnie dużą dostępność. Oczywiście robimy przerwy serwisowe w paru miejscach, pracujemy też nad tym, żeby maksymalnie je skracać, tak żeby nasi klienci nie odczuwali niedogodności związanych z niedostępnymi systemami, ale tak, to jest główne wyzwanie w tej naszej działce. Jeszcze biorąc pod uwagę, że nie jesteśmy jeszcze w chmurze (o czym będziemy zapewne za chwilę rozmawiać), to będąc w Data Center i na naszych standardowych rozwiązaniach i systemach, to czasem trzeba to wyłączać, żeby przełączyć, a z drugiej strony nie możemy sobie pozwolić tak jak inne branże na dłuższe przestoje.

Ale wracając do odpowiedzi na Twoje pytanie, to może samo połączenie marek to był bardzo długotrwały proces i on się składał z wielu etapów, to wiadomo, że klienci widzą pewien punkt w czasie, kiedy nas nastąpił ten rebranding marketingowy, zmiana logo itd., natomiast od strony systemów informatycznych to był bardzo długotrwały proces.

U nas akurat z perspektywy infrastruktury IT, on się zbiegł z innym bardzo dużym projektem, tzn. migracją Data Center. Na moim LinkedInie jest bardzo fajny, krótki film na ten temat, który nakręciliśmy, więc jak ktoś jest zainteresowany, to może sobie obejrzeć, ale może trochę parę słów o szczegółach. 

My jako mBank z jednej strony jesteśmy młodą instytucją, ale z drugiej strony to już parę ładnych lat, nie jesteśmy jakimś start-upem, który ma rok, więc z perspektywy infrastruktury informatycznej trochę nam się już zebrało takiego legacy i sytuacja wyglądała tak, że mieliśmy rozrzuconą infrastrukturę po kilku Data Center, też tak mówiąc brutalnie, w tzw. oldschoolowym stylu, czyli w naszych siedzibach też była część serwerowni. I podjęliśmy decyzję i dosyć duży wysiłek, żeby pozbyć się takiej architektury od strony infrastrukturalnej i wylądowaliśmy w dwóch (jednych z najnowocześniejszych w Polsce) Data Center, gdzie mamy fajnych partnerów, kolokatorów, w których jesteśmy, i to było bardzo duże ćwiczenie, tzn. przenoszenie systemów, serwerów do tych nowych serwerowni. 

I też może to, co jest ważne przy okazji łączenia brandów i w ogóle łączenia pewnych systemów, robienia infrastruktury w uproszczony i spójny sposób dla całego banku, to to, co często kojarzy się w naszej branży z taką migracją Data Center, polega na tym, że po prostu pakuje się serwery i przenosi z miejsca na miejsce. I my postanowiliśmy ten proces z jednej strony wykorzystać szansę i taki punkt w czasie, kiedy mamy atencję ludzi z IT i otoczenia, żeby też podnieść się technologicznie w paru miejscach. 

Więc wdrażaliśmy parę rzeczy typu SDN-y, wspólne środowiska storage’owe, dużym celem był też projekt wirtualizacji, tzn. te maszyny, które były fizyczne, musiały zostać zwirtualizowane w procesie migracji, tzn. była specjalna bramka logiczna, żeby przewieźć blachę z miejsca na miejsce, trzeba było trochę się nagimnastykować i uzasadnić potrzebę posiadania własnego sprzętu, a nie przenoszenia się w kierunku wirtualizacji czy też chmury prywatnej. 

I dzięki temu osiągnęliśmy bardzo duży uzysk, czyli z perspektywy dzisiejszego dnia z tej warstwy infrastrukturalnej jesteśmy jakby state of the art, top of the top, czyli mamy zabezpieczone wszystko, świetnie ogarnięte od strony zabezpieczenia, prąd i itp. A z drugiej strony udało się też nam podciągnąć technologicznie warstwy wyższe. I mamy bardzo dobry punkt wyjściowy do przygody chmurowej, ponieważ nie mamy takiej presji, że musimy iść do chmury, bo mamy jakieś stare Data Center i to nam nie działa, tylko możemy to robić bardziej w takim trybie przemyślanym i spokojnym.

 

Powiedziałeś, że wykorzystaliście tę migrację czy też transformację infrastruktury do tego, żeby ulepszyć pewne obszary, żeby zdecydować się na nowocześniejsze rozwiązania. Zastanawiam się, czy transformacja infrastruktury w takiej instytucji, jaką jest bank, to jest pomysł działów IT, które chcą ten, powiedziałbym, dług technologiczny czasami gdzieś zakopać, czy też może jest to decyzja i strategiczne podejście całej organizacji? Jakie jest Twoje zdanie na ten temat?

 

Odpowiem najpierw trochę humorystycznie, że z perspektywy infrastruktury IT nasza obecność wygląda tak, że jak coś nie działa, jest awaria, to wtedy wszyscy wiedzą, że jesteśmy, a jak wszystko działa, to wszyscy o nas zapominają. To jest trochę taka nasza proza życia i to trochę się łączy z Twoim pytaniem.

Odpowiedź jest trochę pośrodku. Powiem, jak to konkretnie u nas wygląda. Co do zasady wiadomo, że za tego typu projekty odpowiedzialność leży po stronie IT, bo po stronie biznesowej nie ma takiej wiedzy. Z perspektywy biznesu jeśli działa, to działa, i super. I to jest nasza odpowiedzialność, że ma działać. Wiadomo, że wybucha, jak jakieś tam koszty rosną, są jakieś awarie, wtedy z perspektywy ogólnozarządczej takie rzeczy widać. Ponieważ u nas takiego przykładu nie ma, więc my oczywiście sterujemy i kierujemy tego typu projektami. 

Natomiast na pewno muszę oddać swojej organizacji, czyli mBankowi, że mamy bardzo duże wsparcie, zarówno naszych partnerów biznesowych, jak i ze strony zarządczej. I jest pełne zrozumienie naszych działań, więc nie czujemy się w żaden sposób ignorowani, wręcz przeciwnie. Czyli mamy pełne wsparcie, natomiast wiadomo, że my ten temat leadujemy i to jest nasza odpowiedzialność. 

Czyli my wiemy, że to trzeba robić, za to mamy płacone, to jest nasza odpowiedzialność, żeby być bardzo nowoczesnym i żeby technologia umożliwiała robienie biznesów w jak najlepszy sposób, natomiast organizacja musi to wspierać. 

I myśląc teoretycznie o innych organizacjach, gdzie IT nie ma wsparcia biznesu i ogólnozarządczego, to tam są problemy. U nas to zrozumienie jest, bo jesteśmy mocno digitalnym, technologicznym bankiem i uważamy się za pionierów i liderów w wielu obszarach technologicznych i nasz biznes bardzo dobrze to rozumie i nas w tym wspiera. W takim sensie, że jak my nie będziemy w tej technologii z przodu, to biznesowo też nie będziemy z przodu, więc to zrozumienie jest w naszej organizacji.

 

I myśląc teoretycznie o innych organizacjach, gdzie IT nie ma wsparcia biznesu i ogólnozarządczego, to tam są problemy. U nas to zrozumienie jest, bo jesteśmy mocno digitalnym, technologicznym bankiem i uważamy się za pionierów i liderów w wielu obszarach technologicznych i nasz biznes bardzo dobrze to rozumie i nas w tym wspiera. W takim sensie, że jak my nie będziemy w tej technologii z przodu, to biznesowo też nie będziemy z przodu, więc to zrozumienie jest w naszej organizacji.

 

A gdzie w tym mitycznym trójkącie: stakeholderzy, IT i użytkownicy jest wpływ użytkowników? Bo powiedziałeś, że stakeholderzey, rozumiani np. jako zarząd czy cała organizacja, wspiera taką migrację czy transformację. IT powinno być świadome tego, co robi, i powinno też wykorzystać tę okazję do usprawnień. A co dla użytkowników? Co dla klientów, dla pracowników banku? Czy taka migracja powinna być zupełnie transparentna, że logując się następnego dnia do banku, nie powinni zauważyć różnicy, czy też może właśnie również powinniśmy wykorzystać tak dużą operację, żeby maksymalnie dużo usprawnień zaserwować tej grupie?

 

Naszym założeniem była cicha niewidzialna migracja, czyli stealths, ponieważ ta migracja Data Center to nie był taki one shot, że zrobiliśmy to w jeden weekend. Było kilkanaście tur relokacyjnych, kiedy różnej jakości systemy w różnych konfiguracjach były migrowane z tych starych Data Center do nowego Data Center. 

I założeniem tego było, żeby ani biznes, ani klienci zewnętrzni i wewnętrzni tego nie odczuli z perspektywy niedostępności. I to nam się udało, ponieważ nie mieliśmy żadnej awarii ani przestojów, było kilkanaście tur relokacyjnych, większość z nich była bezprzerwowa. Kilka było przerwowych w ramach okien serwisowych, ale tego jakby klienci nie widzieli. Naszym celem od strony IT jest dostarczać te usługi w sposób bezprzerwowy, niezauważalny dla klienta z perspektywy przerw czy też niedostępności systemu.

Natomiast z drugiej strony też, odpowiadając na to, co mówisz, staramy się maksymalnie robić pewne uzyski biznesowe, czyli jeżeli mamy okno serwisowe, to żeby pewne rzeczy poprawić i usprawnić. Mamy zaplanowane tyle, ile się da w danym oknie. Warto też pamiętać o tym, że z perspektywy w ogóle biznesu bankowego i w Polsce, i na świecie bardzo rośnie ruch transakcyjny. 

To jest tak, że ilość przelewów, które wykonywaliśmy 10 lat temu, a to, co się dzieje teraz, że każdy klika, przez telefon wysyła sobie 2 zł, grosza, rozliczenia za lunche, cuda wianki, tzn. ta łatwość tego spowodowała, że to właśnie u nas, w infrastrukturze się kończy tym, że my musimy cały czas dostarczać większą pojemność naszych systemów, żeby to wszystko obsłużyć. Więc bardzo często tego typu ćwiczenia wykonujemy po to, żeby zwiększać capacity, po to, żeby nie stanęło kiedyś w miejscu albo żeby nie było zwolnień.

Więc może z perspektywy klienta to jest tak, że działało i działa, ale jak byśmy nie podejmowali tych działań, to by się tam kiedyś zamuliło, bo wszystkie systemy mają jakąś swoją wydajność i pewne ograniczenia, więc bardzo dużo uwagi przykładamy ku temu, żeby się tak nigdy nie stało, czyli żeby zawsze wszystko śmigało tak, jak trzeba.

 

A od strony technologicznej? Zastanawiam się, jak to się robi. Powiedziałeś, że to przenoszenie zajęło trochę czasu. Czy to się robi w ten sposób, że poszczególne usługi w kolejnym etapie się przenosi, czy też może stosuje się jakieś podejście typu A/B testing, np. pewnej grupie użytkowników serwuje się tylko nowe rozwiązanie? Jesteś w stanie coś tutaj zdradzić?

 

Z mojej perspektywy poruszasz trochę inne wątki, ponieważ tematy typu A/B testing i pewne rzeczy, które próbujemy robić od strony serwowania aplikacji i dostarczania rozwiązań, są już bardziej, powiedziałbym, po stronie deweloperskiej i dostarczania już aplikacji i rozwiązań. I to ma niewiele wspólnego już z tematami typu migracja infrastruktury czy dostarczanie infrastruktury, więc ja będąc w tej działce bardziej infrastrukturalnej, w tym wątku typu serwowanie do klientów różnych ficzerów czy testowanie rzeczy nie uczestniczę bezpośrednio. Naszą rolą jest dostarczenie wydajności, by można było to realizować i działać.

Natomiast odpowiadając na pytanie, jak wygląda ta migracja dużych systemów pomiędzy Data Centrami, to musi być to dobrze zaplanowane, żebyśmy pewne grupy systemów razem łączyli, przenosili, bo to są historyjki tego typu, że jak zostawisz bazę danych w serwerowni 300 km dalej, to już tematy typu latency mają wpływ na to, że to działa, rozpina się itd., a nasza infrastruktura jest oczywiście bardzo złożona i skomplikowana ze względu na to, że zapewniamy też wysokie HA, czyli dla wszystkich systemów ważnych, oczywiście krytycznych, kluczowych itd., mamy zawsze dwie nogi rozłożone i zbalansowanie, no przeróżne usługi. Więc przenoszenie tego tak w locie jest dosyć trudne.

Natomiast są tury fizyczne, czyli że system działa na jednej nodze, druga noga jest pakowana na specjalną ciężarówkę, serwery są owijane w folię bąbelkową i są tam przewożone autostradą. To nawet ciekawe, bo z perspektywy IT rzadko takie operacje są, a to jest nawet interesujące, jak śledzimy, gdzie te ciężarówki jeździły, czy już dojechały, jak to się rozpakowuje, wkłada. Czyli jedna noga chodzi, druga noga jest przewożona, odpalana, wstawiana jest druga noga, wtedy jadą po tą drugą nogę, która była, dowożą ją, rozstawiają w drugiej serwerowni, więc to nawet takich parę ćwiczeń logistycznych.

Wbrew pozorom jednak akurat ta część bardzo logistyczna jest taka bardzo wizualna i fajna i ponieważ logistyka jest dobrze zorganizowana, to nie mamy nigdy problemów w tym ćwiczeniu. Nigdy nie zgubiła nam się żadna ciężarówka. Mieliśmy specjalne wręcz konwoje, żeby minimalizować ryzyko takich rzeczy typu stłuczka czy wypadek. Za to większe wyzwanie od strony logicznej, takie że, jak jest złożona architektura, to przepinanie tematów i przede wszystkim jak ląduje dany system w nowym otoczeniu sieciowym, takie prozaiczne rzeczy jak podpięcie systemu, gdy okazuje się, że ktoś kiedyś, 100 lat temu zhardcodował jakiś adres IP, taka proza życia. 

20 lat temu w mBanku pewne rzeczy powstawały bardziej start-upowo i tego typu grzechy przy takich operacjach właśnie wychodzą. I takie tematy trzeba rozwiązać w niedzielę o 2 w nocy w pół godziny czy w godzinę, bo inaczej się sypie harmonogram. Więc tego typu historyjek mamy do opowiedzenia dużo i są ciekawe, ale jak jest dobry plan, to to wychodzi i da się to zorganizować.

 

To faktycznie niesamowite przygody i tak jak mówisz, coś w tym jest, że jak działa, to lepiej nie dotykać, bo dopiero kiedy coś się zmieni, to wychodzi, że to, co powstało jako legacy i powstało w zupełnie innym otoczeniu technologicznym i działało, to lepiej tego nie ruszać.

Ale wróćmy do infrastruktury, bo to jest core naszej dzisiejszej rozmowy. Opowiadamy o infrastrukturze, to jest de facto złożony temat pod względem obszarów, bo możemy mówić o fizycznych serwerach, o sieciach, o wirtualnych serwerach, usługach sieciowych, jest tych komponentów całkiem sporo.

Czy to wszystko przenosi się w ten sam sposób, czy też może stosuje się zupełnie inne podejścia do różnych usług z tej infrastruktury?

 

Każdy z tych komponentów wygląda trochę inaczej. Trzeba to dobrze poskładać w logiczną całość, więc przy tego typu migracjach i przy przenoszeniu systemów trzeba to dobrze zaplanować i poruszać się warstwami, więc wiadomo, że tak jak w Data Center budujemy najpierw warstwę taką bardzo fizyczną, kioski, okablowanie… Chłopaki z Data Center się ze mnie śmieją, jak tak to nazywam, ale tamta cała kabelkomania, światłowody, corningi i tego typu historyjki trzeba dobrze ogarnąć, więc to musi iść na początku.

Potem największym wyzwaniem jest aspekt sieci, bo tutaj mamy dużo kwestii związanych z bezpieczeństwem, z zapewnieniem ciągłości działania, czyli wchodzą firewalle, load balancery, i ponieważ my akurat przy tej migracji staraliśmy się maksymalnie unowocześnić nasze otoczenie sieciowe, to było to największym wyzwaniem, bo to robiliśmy trochę od nowa, powiedzmy, w nowoczesny sposób, a z drugiej strony musieliśmy testować, czy systemy się odnajdą w tym otoczeniu.

Osobny wątek to stawianie całego tematu storage’owego, czyli macierze, przenoszenie danych, zorganizowanie tego w taki sposób, żeby dane były w nowym ośrodku i w starym, co szczególnie w wysoko transakcyjnych systemach, takich jak bankowe, to jest dosyć duże wyzwanie, żeby na żywym organizmie działać, nie możemy zgubić żadnej transakcji, to są takie wolumeny, że ręcznie nie da się usiąść i doklepać, więc to wszystko musi się zgadzać. 

A to, co może wszyscy najbardziej kojarzą jako taką rzecz, to przenoszenie serwerów, skracając, to może są dwa główne przypadki. Najfajniej przenosi się zwirtualizowane serwery, bo mamy hosty w jednym miejscu, w drugim, wciska się play i tym światłowodem serwery przenoszą się do drugiego miejsca, tam się je odpala i gra muzyka. A z serwerami fizycznymi jest właśnie ta przygoda, co opowiadałem, ciężarówki itd. 

Dlatego też celem tego ćwiczenia było, żeby maksymalnie tego, jak ja to mówię, szpeju się pozbyć. Bo my wcześniej byliśmy organizacją start-upową, był system, kupowała swoje serwery, tak się kiedyś robiło, a teraz jak już mamy o wiele większą atencję na ESG, na tematy prądowe i w ogóle, logiczne i bezpieczeństwa, to wirtualizacja i chmura prywatna to jest to, na co postawiliśmy. 

I tu też mogę się pochwalić, że na całej tej operacji zużycie prądu spadło nam o połowę. Tylko dzięki temu, że przenieśliśmy się na nowszy sprzęt, bardziej wydajny jeżeli chodzi o energochłonność, a z drugiej strony przez to, że pozbyliśmy się bardzo dużej ilości sprzętu fizycznego i go zwirtualizowaliśmy. To był bardzo duży uzysk. I finansowy i ku chwale środowiska.

 

Każdy z tych komponentów wygląda trochę inaczej. Trzeba to dobrze poskładać w logiczną całość, więc przy tego typu migracjach i przy przenoszeniu systemów trzeba to dobrze zaplanować i poruszać się warstwami, więc wiadomo, że tak jak w Data Center budujemy najpierw warstwę taką bardzo fizyczną, kioski, okablowanie… Chłopaki z Data Center się ze mnie śmieją, jak tak to nazywam, ale tamta cała kabelkomania, światłowody, corningi i tego typu historyjki trzeba dobrze ogarnąć, więc to musi iść na początku.

 

Ja przypominam, że moim gościem jest Aleksander Gawroński z mBank S.A. 

Idziemy o krok dalej w naszej rozmowie. Chmura. Chmura zmieniła myślenie o infrastrukturze, mBank korzysta z możliwości chmury. Zastanawiam się, co zaważyło o tym, że zdecydowaliście się na ten kierunek transformacji cyfrowej.

 

Temat chmury to temat rzeka. Postaram się nie przegadać go za dużo. Na poziomie takim holistycznym i bardzo górnolotnym powiedziałbym: nie ma wyjścia. W sensie to jest taki mega trend. Mogę podeprzeć tę wypowiedź. Miałem ostatnio przyjemność być w Data Center jednego z dużych dostawców chmurowych. Oni to mają zorganizowane i zoptymalizowane, nie ma warstwy sieciowej, wszystko jest po stronie software’owej, nie mają urządzeń sieciowych, hardware do nich przyjeżdża już gotowy w rakach, serwery są wydesignowane i dostawcy dostarczają do nich już gotowe komponenty wg ich otwartego na open source, jak te serwery wyglądają. 

Skracając historię, i w ogóle efektywność energetyczna, to, jak przykładają do tego wagę, nie chłodzą klimatyzacją, tylko wodą. Raz, że ekologicznie, dwa, że dużo taniej, to nawet z perspektywy takiego Data Center w dłuższym terminie nie mamy możliwości konkurować efektywnościowo z takim Data Center chmurowym. 

Kolejne aspekty są takie, że czy chcemy, czy nie chcemy, jesteśmy uzależnieni od tych dużych graczy od strony ich rozwiązań i licencji i widać, że wszyscy duzi gracze promują rozwiązania chmurowe. I to doprowadza do tego, że za tzw. 10 lat ci, którzy zostaną z pewnymi rozwiązaniami on-prem, będą płacić 3–5 razy drożej. Ten trend już się rozpoczął. 

Więc jak nie idziesz do chmury, okej, dadzą Ci jakiś wybór, ale to jest takie legacy. Zostań sobie na Windows XP – świetny pomysł, tylko z tego praktycznie się nie da korzystać, bo nie będzie ani łat bezpieczeństwa, ani jakichś software’owych, a będzie do tego 10 razy drożej. 

I biorąc pod uwagę tego typu ogólne spostrzeżenia, to odpowiedź jest taka, że nie ma wyboru. 

Teraz wchodząc w case instytucji finansowej w Polsce, to tu się pojawiają pewne wyzwania, przede wszystkim regulacyjne. My jesteśmy teraz właśnie w takim miejscu, że wracając do początku mojej wypowiedzi: że mega trend i że trzeba tam iść, a z drugiej strony mamy pewne ograniczenia i musimy tak trochę lawirować między tymi wszystkimi czynnikami, żeby jednak do tej chmury iść. 

I my zaczynamy, tzn. jesteśmy w takim miejscu, że mamy największe wdrożenie M365, czyli całego pakietu office’owego, wszystkie Teamsy, i to mam w chmurze, i to była dla nas duża przygoda regulacyjna, i też wiele się nauczyliśmy. Teraz jesteśmy na takim etapie, że stawiamy dwie landing zone dla naszych deweloperów u dwóch dostawców chmurowych. Jedna już jest dostępna, druga będzie za chwilę. I powoli zaczynamy tam stawiać drobne systemy, czyli jesteśmy na etapie uczenia się, jeżeli chodzi o rozwiązania własne. 

A jeżeli chodzi jeszcze o wykorzystanie chmury, to co już teraz robimy dobrze i co nam wychodzi, mamy kilka rozwiązań SaaS-owych i uważam, że z perspektywy dnia dzisiejszego, jak ma się dobry governance, który my już mamy, to trzeba korzystać z tego typu rozwiązań. Czyli coś już jest gotowe, korzystajmy z tego w chmurze, bo już ci dostawcy czasem nawet wersji on-premowych nie oferują, a to jest najbardziej sensowny i najkorzystniejszy układ, że płacimy pay as go za to, co potrzebujemy i korzystamy z tej głównej wartości chmury, że jest szybko, jest dostępne, nie trzeba wdrażać i nie wiadomo co robić.

Kończąc ten wątek związany z naszymi systemami, zaczynamy to realizować. W naszej strategii przyjęliśmy, że 70% kluczowych systemów będziemy mieli w 2025 r. przygotowanych i w schemacie chmury hybrydowej lub chmury publicznej. Bo może też ważne jest to, że postawiliśmy bardzo fajną chmurę prywatną opartą o kubernetesy, którą sami zażądamy. 

I teraz jest wysiłek po stronie deweloperskiej, żeby nasze systemy do tego dostosowywać. I musimy się odnaleźć w takiej realnej rzeczywistości. Mamy biznes, klientów, świat nie stanie teraz na 3 lata i nie będzie czekał, bo akurat mBank zdecydował się na pójście do chmury prywatnej. Więc musimy trochę gonić jedno i drugie, ale jesteśmy na dobrej drodze. Jestem tutaj optymistyczny, że ten plan, który mamy jest dobry i że to zrealizujemy.

 

Super! Tak sobie myślę, że ta chmura, o której mówisz, to jest taki trochę base word, bo wiele się za tym kryje, wiele osób różne rzeczy ma na myśli, mówiąc o chmurze. Gdybyśmy tak spojrzeli z punktu widzenia infrastruktury IT, to jak bardzo mBank jest obecnie w chmurze? Jakie obszary, jakie usługi chmury są wykorzystywane?

 

W nawiązaniu do tego, co przed chwilą omówiłem, to może porządkując tę historię: Na pewno całe środowisko wewnętrzne zdecydowaliśmy się, żeby mocno zainwestować w rozwiązania Microsoftu. I mamy cały pakiet office’owy, M365, Teamsy, całą pocztę też mamy w chmurze i ponieważ zdecydowaliśmy się na to, że jak już zainwestowaliśmy w to partnerstwo z Microsoftem, to chcemy to maksymalnie wykorzystać. Czyli to wszystko, co dają rozwiązania chmurowe, od tego dostawcy i w tych pakietach, które mamy, chcemy też optymalizować. 

Czyli posługując się takim prozaicznym przykładem, nie mamy Zooma, bo mamy Teamsy. Zawsze pojawia się dyskusja, gdy mówię o wyższości świąt Bożego Narodzenia nad Wielkanocą, czy lepsze Teamsy czy Zoomy itd., ale Teamsy są zintegrowane z tym, co mamy. Microsoft wykonał dużo pracy, bo Teamsy już nie mulą i mają wiele ficzerów. I to działa i cała organizacja na tym chodzi. 

Do tego staramy się też maksymalnie zutylizować to, co jest dodatkowo, aplikacje, które dają to otoczenie. Powoli będziemy wdrażać rozwiązania Power Appsów, Power BI, wszystko, co tam jest, staramy się maksymalnie utylizować, po to, żeby nie kupować czegoś na zewnątrz i nie wydawać i żeby maksymalnie korzystać z tej scenerii, którą daje to środowisko. Więc to, czego używamy tu i teraz to jest jeden z największych pakietów rozwiązań, parkując to w przegródkę SaaS. 

Mamy kilkanaście rozwiązań SaaS-owych, kupionych dla pewnych biznesów czy dla pewnych części banku, z których korzystamy. I to też się dobrze sprawdza, bo tak jak mówię, płacimy za to, z czego korzystamy, użytkownicy są zadowoleni. IT jest bardzo transparentne, w sensie, że to mamy na zewnątrz i regulacyjnie to mamy dobrze ograne, więc z perspektywy tego, co musimy dochować jako bank, to tutaj względem regulatora i procedur, i regulacji mamy to ograne. Natomiast ta historia z naszym IAS-em, czyli właśnie, żeby stawiać infrastrukturę i tam przechodzić, to jest to najtrudniejszy punkt, który startujemy. Więc w tych kategoriach, jeżeli chodzi o PAS i IAS, to tu zaczynamy. Wystawiamy to do deweloperów, można już tam robić, pierwsze koty za płoty już są w tym obszarze, ale największe wyzwanie to przebudowywanie aplikacji. 

Jesteśmy teraz na etapie takich punktów decyzyjnych, że pewnych aplikacji nie będziemy dotykać, z przeróżnych względów, bo to jest racjonalność kosztowa, biznesowa, architektoniczna. Więc pewne rzeczy nie będą ani w chmurze publicznej, ani prywatnej, ale z większością rzeczy chcemy podjąć ten wysiłek. Po to, żeby nie zostać z tym legacy. Bo te legacy zawsze Cię dogania, czasem później, czasem wcześniej, a wiemy, że te najważniejsze rzeczy od strony klientowskiej muszą chodzić w tej nowoczesnej technologii. I teraz właśnie układamy to w taką road mapę do 2025 r., żeby to zrealizować.

 

Jesteśmy teraz na etapie takich punktów decyzyjnych, że pewnych aplikacji nie będziemy dotykać, z przeróżnych względów, bo to jest racjonalność kosztowa, biznesowa, architektoniczna. Więc pewne rzeczy nie będą ani w chmurze publicznej, ani prywatnej, ale z większością rzeczy chcemy podjąć ten wysiłek. Po to, żeby nie zostać z tym legacy. Bo te legacy zawsze Cię dogania, czasem później, czasem wcześniej, a wiemy, że te najważniejsze rzeczy od strony klientowskiej muszą chodzić w tej nowoczesnej technologii. I teraz właśnie układamy to w taką road mapę do 2025 r., żeby to zrealizować.

 

Zastanawiam się nad tym procesem migracji, bo mBank jest przykładem takiego success story, jeżeli chodzi o proces migracji do chmury, ale jestem przekonany, że tam bez problemów, przeszkód i wyzwań się nie obyło. Mówiłeś o tym, że nie da się zapauzować świata na trzy lata, żeby tego dokonać, że trzeba działać pod okiem regulatora. Co jeszcze w tym kontekście przeszkód czy wyzwań pojawia się, jeśli bank myśli o migracji do chmury?

 

Jak konkurencja słucha, to niech wyjmuje notatniki, bo to najważniejsze rzeczy, które trzeba wziąć pod uwagę. O części już wspominałem, ale może też to uporządkuję. 

Z perspektywy gracza typu instytucja finansowa w Polsce, punkt pierwszy to regulacje. I na ten temat niestety trzeba poświęcić więcej czasu, niż się wszystkim wydaje. Ten zestaw dokumentacji, który trzeba przygotować i przeanalizować to jest kwestia takiej smutnej roboty, papierkowej, i to jest jedna rzecz. Ale też jakby zrozumieć logikę, która za tym idzie, bo nie to, że narzekam na ten nasz przysłowiowy KNF, bo te regulacje mają swój sens, jak się dobrze zrozumie, co za tym stoi. Jakie bezpieczniki są wbudowane w ten proces, to te bezpieczniki trzeba też po swojej stronie wbudować, żeby to pójście do chmury nie było takie na hurra, ale mocno przemyślane. Więc na to trzeba mieć na pewno dobry team i na to poświęcić sporo czasu, żeby wypracować te rzeczy.

Drugi temat, który wydaje się, że pójdzie normalnie, a z tego co widać, jak sprawa wygląda na rynku, jest bardzo trudny, to jest szeroko rozumiane bezpieczeństwo, czyli cybersecurity. Czyli mówiąc po ludzku, bezpieczników chmurowych jest mało na rynku. To jest bardzo trudny temat. A tutaj jest w ogóle trochę, bym powiedział, name of the game, jeżeli chodzi o wejście w chmurę, szczególnie jak się jest bankiem, bo jak się jest jakimś portalem, który publikuje artykuły średnio ważnej treści, jak coś położysz źle, to możesz wycofać, przecinek poprawić itd., Z perspektywy banku tutaj nie ma litości. My nie możemy wystawić danych, żeby ktoś miał do nich dostęp, albo że ktoś coś zapomniał. 

A chmura zmienia bardzo wiele, ponieważ, trochę wracając do tych naszych Data Center i infrastruktory on-premowej. My mamy bardzo wiele buforów bezpieczeństwa, tak to lubię nazywać, że nasi bezpiecznicy zalali nas betonem w tylu miejscach, że jak będzie błąd nawet w jakiejś tam jednej warstwie, albo coś tam się rozszczelni, to jest sześć innych, które wyłapują pewne procedury. 

W chmurze jest trochę inaczej, bo jest admin, który ma jakieś dostępy, oczywiście spłycam, bo to jest bardziej złożona historia, ale mówiąc krótko, tam dwóch ziomków może trzy fistaszki poprzestawiać i wszystkie dane może udostępnić na cały świat. W sensie, że nie ma takich buforów, że są jakieś tam firewalle nasze, różne inne zabawki bezpieczeństwa, które nas chronią. W chmurze tego nie ma. To wszystko się wyklikuje na panelu, designuje i jest o wiele łatwiej o problem. 

Więc wracając może do wątku całej wypowiedzi, trzeba poświęcić bardzo dużo atencji na bezpieczeństwo i tego się uczyć, i zrobić to dobrze. Szczególnie że nasze wymagania regulacyjne, pewne tematy typu LogBoxy, klucze, szyfrowanie danych na miejscu są bardzo liczne i żeby je spełnić, to nie jest standardowe. I to, czego się nauczyliśmy nawet w relacjach z naszymi partnerami chmurowymi, to, że nasze wymagania są bardzo, bardzo wysokie w porównaniu ze standardem rynkowym. 

Więc jak się pojawia u nich zwykły klient, to nie ma tych wymagań, a jak pojawia się instytucja finansowa z Polski, to się otwierają takie demony, że my jako instytucja z Polski, mamy bezpośredni kontakt z trzecią linią, albo nawet z ludźmi, którzy coś tam developują po stronie chmury w Stanach Zjednoczonych. Mieliśmy nawet takie case’y, które przeszliśmy. 

Więc ten drugi aspekt cyberbezpieczeństwa jest mega ważny i trzeba o to zadbać, bo bez tego się nie pojedzie. Będzie zderzenie ze ścianą, bo albo Ci się nie uda wejść do tej chmury, albo możesz pójść za bardzo na freestyle’u, a tutaj życie nie wybaczy błędów. Bo o ile we własnym Data Center zazwyczaj są zorganizowane tak jak u nas, że jeden drobny błąd zawsze może być kompensowany przez inne warstwy zabezpieczeń, to w chmurze jest to trudniejsze, żeby tak to zorganizować. 

I trzeci wątek. Ja się śmieję, że w każdej organizacji jest taki pewien kontrast, rywalizacja infrastruktura – deweloper. I to jest trochę tak, że infrastruktura, czyli ta działka, w której ja pracuję, ma dostarczyć tę chmurę, bo platformy są po stronie infrastruktury i chmura jest jedną z platform computing power, że mamy to dostarczyć. I oczywiście jak zawsze development narzeka, że to źle, że za późno, że czegoś tam nie można włączyć, tak czy inaczej narzekają, okej. Ja to oczywiście spłycam tak humorystycznie, oczywiście mają rację, że czasem nie wszystko idzie tak, jak trzeba, może coś za wolno, nie tak, jak byśmy chcieli, mamy swoje wyzwania, ale finalnie ja trochę mówię tak: nie czekajcie na te wszystkie ficzery, zacznijcie robić po swojej stronie, bo macie takie aplikacje, że dostosowanie ich do chmury nie potrwa miesiąc. Wy macie swój development, swój biznes, a zrobienie takiego refaktoringu pod chmurę w skrajnych przypadkach oznacza wręcz przepisanie systemu. I to trzeba zacząć robić. 

Więc nie ma co sekwencyjnie do tego podchodzić, że ktoś Wam wystawi chmurę, a potem nagle się tam zadzieje, że w tej chmurze się zaczniecie, tylko to jest też bardzo długi proces po stronie aplikacji, żeby rozpocząć analizę i zaplanować zmiany w tym systemie, w kodzie, tak, żeby tej chmury można było używać. I to jest ta warstwa aplikacyjna. 

Ostatnia rzecz, którą chcę powiedzieć, to jest know-how. Ludzie muszą się z tego szkolić, trzeba o tym czytać, trzeba to robić, samo to się nie zadzieje. My mamy szkolenia, darmowe certyfikaty chmurowe, staramy się maksymalnie ten temat promować i zachęcać. Oczywiście nie jesteśmy mega zadowoleni, ze to się dzieje, powinno to iść trochę szybciej, więc to jest też aspekt, którego nie można zaniedbać. 

Sytuacja jest taka, że ktoś tam, nieważne, infrastruktura czy ktokolwiek, przyjdzie i mówi: dobra, macie chmurę, tu wszystko działa itd., a przychodzi deweloper, który przez 20 lat robił po swojemu, a teraz nagle ta chmura i on w ogóle nie wie, o co chodzi. I trzeba wyszkolić całą organizację. Oczywiście nie tylko deweloperów, ale gości od DevOpsów, adminów, bezpieczników. Bezpiecznik, który robił w on-premie, a bezpiecznik, który jest w chmurze, to jest trochę inna już kategoria. Więc trzeba się szkolić.

 

No właśnie. Infrastruktura, aplikacja i ludzie. Mówiłeś na początku, że IT w mBanku to jest całkiem spora jego część. Mówiłeś też, że niektórych kompetencji na rynku, np. bezpieczników, dramatycznie wręcz brakuje. I tak się zastanawiam, czy w takich fundamentalnych zmianach jak migracja, transformacja infrastruktury IT bądź do innego Data Center, bądź do chmury, czy to się robi tylko tymi wewnętrznymi zasobami, że tak to kolokwialnie ujmę, czy korzysta się z pomocy z zewnątrz?

 

Wydaje mi się, że my wybraliśmy w miarę optymalny model, tzn. taki, że korzystamy z pomocy firm zewnętrznych, właśnie w tematach takich bardzo, gdzie musimy wbić jakąś flagę, czyli ogarnąć tę dokumentację do końca, postawić landing zone albo przetestować bezpieczeństwo pewnych rzeczy. Ze względu na to, że nawet ciężko pozyskać pewne zasoby, to korzystamy z firm zewnętrznych. Natomiast nasze podejście jest takie, że mamy swój zespół cloud center of excellence, który jest bardzo silny merytorycznie i prowadzi ten temat.

I może o tym powinienem wspomnieć, że bez takiego zespołu też się daleko nie pojedzie. Czyli kompetencje trzeba budować wewnętrznie. I my posiłkujemy się firmami zewnętrznymi tam, gdzie chcemy pozyskać know-how, albo jest do wbicia jakaś flaga projektowa. Natomiast całe know-how i całe otoczenie musi zostać wewnątrz, bo to ma być nasz docelowy model pracy. To jest trochę inna dyskusja, ile za te 10 lat będziemy w chmurze, a ile w on-premie, ale na pewno będziemy bardzo dużo w chmurze i dlatego ten know-how musi zostawać. 

Czyli trzeba to organizować w taki sposób, że tam, gdzie potrzebujesz i chcesz przyspieszyć prace albo je zrealizować, trzeba się wspierać zasobami zewnętrznymi, które mają know-how i robiły coś, bo czasem bez sensu jest wymyślać koło na nowo, ale podstawą tego myślenia powinno być to, że ten know-how zostaje w firmie, że są ludzie, którzy tutaj się tym zajmują i jest budowana struktura organizacyjna i logiczna, i know-how do tego, żeby dalej te tematy chmurowe działy się w organizacji. 

Bo ja sobie tego nie wyobrażam tak, że zamawiamy projekt, przyjdźcie i zróbcie nam chmurę, i przychodzi jakaś duża firma za duże pieniądze na dwa lata i potem oni znikają, a tutaj nikt nie będzie wiedział, o co chodzi. To nie zadziała w ten sposób.

 

Bo ja sobie tego nie wyobrażam tak, że zamawiamy projekt, przyjdźcie i zróbcie nam chmurę, i przychodzi jakaś duża firma za duże pieniądze na dwa lata i potem oni znikają, a tutaj nikt nie będzie wiedział, o co chodzi. To nie zadziała w ten sposób.

 

Czyli taki zdrowy balans. Myślę, że warto też jeszcze podsumować temat działalności banku na rynku regulowanym. Bo w kontekście infrastruktury może to znaczyć wiele rzeczy, wiele zaszytych mechanizmów, które mogą się odbezpieczyć i uratować sytuację, jeśli zajdzie taka potrzeba. Ale z drugiej strony taką operacyjną, jak to nazwałeś, nudną pracę pt. wypełnianie dokumentacji. 

Mnie bardziej interesuje to, jak działalność banku na takim regulowanym rynku w kontekście transformacji infrastruktury ma związek z tym, że podejmuje się określone decyzje, a określonych np. nie można; że na określone rozwiązania można się zdecydować, na inne nie. Jak duży jest ten wpływ?

 

Wydaje mi się, że dosyć duży, przez to, że są te bezpieczniki wbudowane i trzeba bardzo dużo tej pracy wykonać. Finalnie bank ma zapewnić bezpieczeństwo pieniędzy klientów, i to jest najważniejsze. Więc jeżeli mamy do wyboru, czy pieniądze mają być bezpieczne, czy w aplikacji mobilnej ma być nowy fistaszek, który tam gdzieś pieniądze z ptaszkiem wysyła, to okej, musimy się przeprosić z tym, do czego zostaliśmy powołani, że pieniądze mają być najbezpieczniejsze, i to jest numer 1.

 

Pewnie, to jest taki cel, a jednocześnie ten proces budowania tej infrastruktury, która ma zapewnić to bezpieczeństwo i jakość, to niekończący się proces. W związku z tym trzeba być na bieżąco z tym, co tam się dzieje, jakie nowości się pojawiają, jakiego typu trendy na rynku się pojawiają. 

O to właśnie chciałem Cię zapytać, bo domyślam się, że jako osoba odpowiedzialna za tę infrastrukturę IT, musisz być na bieżąco z nowościami. 

W Twojej ocenie, o jakich ciekawych trendach w zarządzaniu infrastrukturą IT możemy dzisiaj mówić?

 

O cloudzie już ani słowa więcej, bo już przegadaliśmy ten temat, ale to jest temat nr 1, więc cloud na pewno.

Drugi temat to cyberbezpieczeństwo. Często mówię, że swoich kolegów z bezpieczeństwa widuję częściej niż swoją żonę. I to jest prawda, nawet z perspektywy kilku lat, ostatni rok więcej kontaktów miałem z bezpieczeństwem niż ze swoimi partnerami z developmentu czy nawet ze swoim szefem. To pokazuje, że ten temat zacieśnienia współpracy z bezpieczeństwem jest istotnym trendem. Więc tego nie można przeoczyć, bo jak się to prześpi, to po ciemnej stronie mocy jest taki postęp w technologii, w organizacji, ci tzw. hackerzy to już nie są pryszczate nastolatki, które coś tam sobie dłubią, ale normalne przedsiębiorstwa, które mają swoją pierwszą linię. To, co tam się dzieje, to jest kosmos. Więc przed tym trzeba się bronić. 

A od strony SRE, czyli Site Reliability Engineering, to jest też coś, do czego próbujemy dążyć, czyli zapewnianie dostępności usług, większa automatyzacja i pilnowanie, żeby od strony infrastruktury iść w taką stronę bardziej nowoczesną. Pełna automatyzacja, wysoka dostępność usług, mierzenie, optymalizacja przez kod – w tę stronę idziemy i wydaje mi się, że to jest przyszłość tej działki. Rola oldschoolowych adminów będzie powoli odchodziła w przeszłość, a ludzie z infrastruktury to będą ludzie, którzy potrafią kodować, optymalizować i zapewniać wysoką dostępność usług.

 

Super! Moim gościem dzisiaj był Aleksander Gawroński z mBank. Rozmawialiśmy o transformacji infrastruktury IT w banku. 

Alku, bardzo Ci dziękuję za poświęcony czas, za tę rozmowę.

 

Dzięki, cała przyjemność po mojej stronie. Gdyby ktoś coś chciał ode mnie więcej się dowiedzieć, zapraszam do kontaktu poprzez LinkedIn, tam najłatwiej ze mną się skontaktować. Dzięki za rozmowę. Było bardzo przyjemnie. Mam nadzieję, ze podcast będzie się dobrze słuchał.

 

Jestem o tym przekonany. Dzięki wielkie. Oczywiście wszystkie linki będą w notatce do odcinka. A ja za dzisiaj dziękuję.

Do usłyszenia! Cześć!

I to na tyle z tego, co przygotowałem dla Ciebie na dzisiaj. Po więcej wartościowych treści zapraszam Cię do wcześniejszych odcinków. A już teraz, zgodnie z tym, co czujesz, wystaw ocenę, recenzję lub komentarz w aplikacji, której słuchasz lub w social mediach.  

Zawsze możesz się ze mną skontaktować pod adresem krzysztof@porozmawiajmyoit.pl lub przez media społecznościowe. 

Ja się nazywam Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o transformacji infrastruktury w banku. Zapraszam do kolejnego odcinka już za tydzień.

Cześć!