mBank: modernizujemy środowisko IT zastanawiając się, czy będzie nam dane skorzystać ze wszystkich dobrodziejstw public cloud

Z Krzysztofem Dąbrowskim, wiceprezesem zarządu ds. operacji i informatyki w mBanku rozmawiamy o strategii na lata 2021-2025; wykorzystaniu rozwiązań cloud computing i barierach z tym związanych; dostosowywaniu się technologicznie do przyszłej migracji, na razie w oparciu o private cloud, ale bez konieczności sprostania ogromowi wyzwań legislacyjnych związanych z public cloud; sukcesywnej modernizacji systemów legacy; korzyściach wynikających z tego procesu; modernizacji procesu wytwarzania oprogramowania i podejściu banku do zrównoważonego rozwoju.

Jak dużą rolę w strategii na lata 2021-2025 będą odgrywać rozwiązania oparte o publiczne usługi cloud computing? Mówi się w niej o konteneryzacji, a także rozszerzeniu możliwości w zakresie usług IaaS, ale raczej w kontekście chmury prywatnej…

mBank ma to szczęście, że jest w stosowaniu usług chmury obliczeniowej w awangardzie branży finansowej. Taki był też wydźwięk tego, co mówiliśmy na Europejskim Kongresie Finansowym. Wspominałem tam o uruchomieniu z sukcesem rozwiązań IT – funkcjonujących w pełni w chmurze – dla naszej spółki mElements, zajmującej się płatnościami internetowymi (opisywaliśmy ten projekt w ITwiz 1/2022 – przyp. red.).

Jesteśmy dumni z tego projektu, choć – patrząc na stopień wykorzystania rozwiązań cloud computing w innych branżach na świecie – tak naprawdę nie ma się z czego cieszyć. Dodatkowo, okupione to było tytaniczną pracą prawników, aby jedną, relatywnie niedużą spółkę, uruchomić w chmurze. Nakład naszej pracy na początku tego projektu był dramatycznie duży.

Czy nam się to podoba czy nie, sektor finansowy idzie w stronę chmury. Duże „ciśnienie” na chmurę nie wynika jednak tylko z tego, że nagle dostawcy dostarczyli rozwiązania fundamentalnie lepsze pod każdym względem od np. chmury prywatnej, a raczej z tego, że ten model po prostu bardziej się im opłaca. Skoro więc właściwie wszyscy liczący się dostawcy globalni „wiosłują” w tym samym kierunku, to nie zatrzymamy tego megatrendu.

Ewidentnie widać, że branża IT jest zdeterminowana, aby skonwertować klientów do modelu chmurowego, nawet ryzykując utratę części przychodów z powodu niedostarczenia danego rozwiązania w wersji on-premise. W efekcie, coraz więcej funkcji i usług znajduje się wyłącznie po stronie chmury. To zaś generuje coraz większą presję na migrację do niej.

Czemu tak „opornie” idzie wykorzystanie chmury w polskim sektorze finansowym?

Jeszcze nikt w sektorze w Polsce nie przeszedł tzw. pełnego cyklu migracji do chmury. Składa się na niego kilka etapów. Na początek jest to wyjęcie z własnego centrum danych istotnego fragmentu systemów bankowych wraz z danymi klientów (które to dane podlegają tajemnicy bankowej). Następnym krokiem jest wyniesienie tego do chmury – oczywiście w zgodzie z wymaganiami Komisji Nadzoru Finansowego. Dalej, uruchomienie tam migrowanego rozwiązania i korzystanie z niego przez co najmniej rok. Następnie pozytywne przejście audytu KNF i otrzymanie ewentualnych zaleceń związanych ze stosowanym w chmurze rozwiązaniem. Wreszcie, wdrożenie ich i dalsze utrzymywanie na platformie cloud computing.

W związku z tym mBank stawia na rozwiązania hybrydowe. Bardzo duża część transformacji technologicznej może zostać wykonana w ramach chmury prywatnej. Jest to praca, która się nie zmarnuje, niezależnie od dalszego rozwoju sytuacji regulacyjnej. W ten sam sposób, w kolejnym kroku, możemy uruchomić to samo rozwiązanie w chmurze publicznej. Pozwala nam to jednocześnie nie zatrzymywać prac i mieć czas na przejście ścieżki prawnej. Tym bardziej, że regulacje ciągle się zmieniają. Dziś np. są bardziej przyjazne chmurze niż przed komunikatem chmurowym KNF ze stycznia 2020 roku. Nie wiem jednak, co będzie za kolejne dwa lata. Dlatego chcemy być gotowi na każdy, także niekorzystny rozwój sytuacji.

Co wstrzymuje mBank przed szerszym wykorzystaniem public cloud?

Brutalna prawda jest taka, że większość prac związanych z migracją do chmury to dostosowanie istniejących już systemów IT do pracy w środowisku chmurowym. Zupełnie nowe systemy, które można od podstaw napisać tak, by były zgodne z chmurą, to zdecydowana mniejszość portfela aplikacji każdego CIO bankowego w Polsce.

Pracy więc jest ogromnie dużo, a nie zawsze istnieje sensowny rachunek ekonomiczny, który przemawiałby za pokryciem jej kosztów. Jeśli coś działa i nie wymaga dużego zaangażowania po stronie IT, a jedynie wgrywania „łatek” i zmiany platformy sprzętowej raz na 5 lat, to po co fundować sobie ewentualne problemy? A dodatkowo w wypadku znaczącej większości tych aplikacji mielibyśmy dużo dodatkowej pracy. Przez to nie wdrażalibyśmy nowości ważnych z punktu widzenia biznesu, a z punktu widzenia klienta biznesowego – dostarczalibyśmy to samo tylko z chmury zamiast z naszego data center.

Dlatego najłatwiej w chmurze realizować projekty nowe, w których nie mamy obciążeń rozwiązaniami legacy. Oprócz start-upów nie ma jednak organizacji, w których realizowane są wyłącznie tego typu inicjatyw.

Chcę jednak podkreślić, że docelowo będziemy w chmurze. Po prostu szukamy rozwiązań, które pomogą nam wykonać to „ćwiczenie” tak, by jego rachunek ekonomiczny miał dla nas biznesowy sens.

Czy dostarczanie przez hyperscalers rozwiązań, które mogą stać w firmowym centrum danych – takich, jak Azure Stack; AWS Outposts czy Google Distributed Cloud Hosted – ułatwia korzystanie z rozwiązań dostępnych tylko w chmurze?

Oczywiście, że tak. Gdy weźmie się typową aplikację z architekturą 3-4 warstwową, własną bazą danych, logiką, front-endem, to – jeśli jest to coś małego – stosunkowo łatwo to spakować i skonteneryzować. Schody zaczynają się przy dużych systemach.

Warto pamiętać, że podejście chmurowe – co do zasady – zakłada skalowanie horyzontalne. Jest więc odpowiednie, gdy chcemy kupować „dużo komputerów”, a nie „duże komputery”. Duże komputery w chmurze nie są też tak atrakcyjne, jak wiele małych. Mają też ograniczenia co do pojemności. W dodatku nasz system nie jest nawet gotowy na autoskalowanie infrastruktury, o którym tyle mówią dostawcy. W takim przypadku – w razie potrzeby – dodaje się procesorów, a nie wykorzystuje autoscaling.

Firmom, które mają od lat infrastrukturę skalowalną wertykalnie – posiadają dwie bazy pasive-active i przetwarzają dużą liczbę transakcji, a tak działa większość systemów w Polsce – nie jest łatwo przenieść się do chmury. Sama zamiana CAPEX na OPEX nie „da szczęścia”. W dodatku, zmiana ta często okazuje się droższa. Własny sprzęt możemy np. dłużej amortyzować. Cloud computing jest zaś rozliczane co miesiąc za wykorzystane, a często także za tylko zarezerwowane, zasoby.

W strategii mBanku zapisano, że do roku 2025 70% kluczowych systemów ma być gotowych do pracy w chmurze. Co to znaczy w praktyce?

Idziemy system po systemie. Zaczynamy je oczyszczać ze starych technologii. Czasami jest tak, że to dostawcy – wprost lub nie – nas do tego zmuszają. Przykładowo, częścią naszego stosu technologicznego jest .NET. Od lat korzystaliśmy z klasycznej jego wersji, która jednak nie jest wspierana w chmurze. Jednocześnie Microsoft zapowiedział, że za jakiś czas w ogóle przestanie ją wspierać. W związku tym jesteśmy zmuszeni przejść przez wszystkie systemy i jeden po drugim przenieść je na .NET Core. Jeśli jednak będziemy już je „ruszać”, to od razu przeniesiemy całość na kontenery. Przeanalizujemy też jakie jeszcze elementy musimy wymienić, aby nie były nam kulą u nogi. Po takiej modernizacji, aplikacja trafi na naszą chmurę.

Po drodze oczywiście trzeba do tego dorobić całą automatyzację m.in. provisioningu i deploymentu. Aplikacja po przejściu takiego liftingu będzie co prawda wykonywała te same funkcje, ale już na nowszych technologiach i w sposób mocno zautomatyzowany. A jeśli nawet same technologie nie będą aż tak nowsze, to przynajmniej będą opakowane i zarządzane bardziej współcześnie. Taka migracja daje dodatkowy zwrot z inwestycji w postaci mniejszej liczby błędów ludzkich, mniejszego zaangażowania zespołu IT, a także skrócenia czasu prac serwisowych i wdrożeniowych.

Zautomatyzowaliśmy już cały proces wdrożenia bankowości korporacyjnej na produkcję. Kiedyś w nocy mieliśmy jedynie czas zrobić dobrze wdrożenie, przetestować nowe funkcje, zostawić niewielki bufor na nieprzewidziane zdarzenia i już trzeba było otwierać oddziały banku. W wypadku niepowodzenia mogliśmy tylko wycofać wdrożenie i spróbować ponownie następnego dnia. Dzięki automatyzacji dziś ten sam proces jesteśmy w stanie w ciągu jednej nocy wykonać kilka razy. Możemy więc przeprowadzić całe wdrożenie. Zatrzymać się. A jeśli coś jest nie tak, wycofać się. Odnaleźć ewentualny problem. Naprawić go i uruchomić ponownie roll-out. Tę procedurę możemy powtórzyć kilkukrotnie zanim następnego dnia otworzymy bank. Od strony operacyjnej jest do dla nas ogromny zysk. Proces wdrożenia stał się łatwiejszy, powtarzalny i bez ryzyka błędów ludzkich.

Czy stopniowa, opisana przez Pana modernizacja infrastruktury IT wpisuje się w – również zapisany w strategii – zwiększony poziom dojrzałości procesu wytwarzania oprogramowania. W jaki sposób chcą Państwo to osiągnąć?

Jak najbardziej. Przede wszystkim sami jesteśmy dużym wytwórcą oprogramowania. Większość tego, co robimy, to nasz własny produkt. W zakresie podnoszenia dojrzałości procesu wytwórczego chcemy m.in. podnieść poziom testów automatycznych. Im starsze systemy, w tym większym stopniu jest to dziś robione ręcznie. Wszystkie nowe rozwiązania są tworzone z testami. Natomiast starsze stopniowo dostosowujemy do tego standardu.

Realizujemy też projekty związane z ogólnie pojętą automatyzacją procesu wytwórczego. To, że wciąż wiele czynności przeprowadzanych jest ręcznie, spowalnia nas i jest źródłem wielu problemów. Tymczasem przez ostatnie 10 lat wydarzyło się bardzo wiele rzeczy w branży IT, m.in. w zakresie nowoczesnych technik wytwarzania oprogramowania, z których warto skorzystać. To jest to, na czym nam zależy.

Tworząc nowe oprogramowanie, największy nacisk kładziemy w banku na jakość i bezpieczeństwo. Myślę, że znacznie powyżej średniej rynkowej. Choć oczywiście nie znaczy to, że nie zależy nam przy tym na jak najkrótszym time-to-market i innowacjach dla naszych klientów.

Czy mBank korzysta już, albo planuje skorzystać z usług chmury publicznej? Ponownie cytując strategię: „wprowadzony ma zostać ustandaryzowany sposób wdrażania rozwiązań opartych o SaaS i PaaS”.

Korzystamy z tego w tym sensie, że nasza spółka mElements, obsługująca płatności Paynow, ma całą infrastrukturę uruchomioną w 100% w chmurze. Nie chcieliśmy wyciągać „ze środka” banku pojedynczego elementu środowiska IT i umieszczać go w chmurze. Wówczas i tak musielibyśmy zadbać o to, aby taka hybrydowa infrastruktura wyglądała jak jeden system. To byłby znaczący nakład pracy i środków przeznaczanych po stronie banku na utrzymanie takiego systemu – w sumie dający mały zysk. Nie chcieliśmy też przenosić do chmury niszowego rozwiązania.

Wydawało nam się, że nasza bramka płatnościowa to rozwiązanie wystarczająco duże, realizujące istotny fragment naszej działalności. Zdecydowaliśmy się więc wydzielić i zmigrować do chmury całą tę część naszej działalności. W całości w chmurze mamy też nasz API PSD2. Zrealizowaliśmy też najszersze – w polskiej bankowości – wdrożenie Office 365. W chmurze mamy również system do zarządzania operacjami. Trochę więc tych rzeczy jest.

Byliśmy jedną z pierwszych instytucji, która najpierw przygotowała pełną dokumentację techniczną opisującą to, jak chcemy działać w chmurze, i przekazała ją do Komisji Nadzoru Finansowego. W efekcie dostaliśmy zgodę i uruchomiliśmy projekt. Znam banki, które nie poszły aż tak transparentnie. W ich przypadku prawdziwa próba generalna będzie więc miała miejsce później.

Jednak nakład pracy – od strony legislacyjnej i aspektów dostosowania się do wymogów bezpieczeństwa – jest ogromny. Dodatkowo, każdy projekt zmaga się z tym z osobna. Dlatego w naszej strategii zapisaliśmy wprowadzenie standardów tak, aby – zgodnie z zasadą Pareto – 80% kosztów używanych serwisów ponieść raz, przy pierwszym projekcie chmurowym. Mogą one być nawet większe. Ale chcemy potem móc używać tego „fundamentu” w kolejnych migracjach do chmury. Dodawać będziemy jedynie 20% specyficznych dla danej usługi narzędzi.

Nie da się tego jakoś „usystematyzować”, np. w kolejnym komunikacie KNF?

Skorzystam z okazji, że wypowiadam się do mediów, i przypomnę, że na Europejskim Kongresie Finansowym zaproponowałem, aby Komisja Nadzoru Finansowego rozważyła certyfikację rozwiązań chmurowych. Teraz każdy bank, który będzie chciał być w chmurze Microsoft Azure, Google Cloud Platform czy Amazon Web Services, musi odrabiać tę samą pracę domową od początku. Często osobno dla każdego rozwiązania. Gdyby zaś była dostępna certyfikacja KNF, która mówi, że dane rozwiązanie w chmurze jest w porządku, to sam bank nie musiałby tego robić. Skoncentrowałby się na tym, co jest specyficzne dla niego i opisał tylko „deltę”. Oznaczałoby to – przy zagwarantowaniu tego samego poziomu zgodności – mniej pracy dla banków i mniej pracy dla regulatora który weryfikuje przekazywaną dokumentacje.

Dopóki tego nie ma, sami staramy się tak przygotować, aby wewnętrznie nie dublować pewnych działań związanych z migracją kolejnych rozwiązań IT do chmury. To obniża barierę wejścia do chmury dla wewnętrznych projektów mBanku. Teraz czasami jest tak, że gdy nasi pracownicy zaczynając myśleć o „odpaleniu” czegoś w chmurze, to ostatecznie z takiego projektu rezygnują. Za dużo mają przy tym dodatkowej pracy. Funkcjonalność potencjalnego produktu zostaje przyćmiona uciążliwą ścieżką dojścia do niego.

Kluczowe dla mBanku w strategii na lata 2021-2025 będzie także cyberbezpieczeństwo. W jakim kierunku będą rozwijać się te rozwiązania? W strategii mówi się m.in. o szerszym wykorzystaniu uczenia maszynowego i sztucznej inteligencji…

W praktyce oznacza to, że będziemy kontynuować to, co zaczęliśmy już kilka lat temu. W mBanku stosujemy już uczenie maszynowe – czy bardziej ogólnie, techniki Data Science, dzięki czemu jesteśmy w stanie radzić sobie dużo lepiej z cyberzagrożeniami.

Trzeba pamiętać, że obszar ten obejmuje dwa światy. Choć niestety zlewają się one, gdy dyskutuje się o nich w mediach. Pierwszy to „klasyczne” cyberbezpieczeństwo, czyli ochrona przed atakami hakerskimi. Drugi zaś to kradzieże i wyłudzenia, które też dzieją się w świecie cyfrowym i również zajmuje się nimi dział bezpieczeństwa. W tym obszarze instytucje finansowe mają dużo więcej pola do popisu. Tu już nie ma aż tylu prostych, gotowych rozwiązań od dostawców, jak w przypadku cybersecurity, a jednocześnie różnych wektorów ataków jest bardzo dużo.

Techniki oparte o Machine Learning mają więc o wiele większe zastosowanie do monitorowania aktywności transakcyjnej i wyłapywania anomalii. Jest też o wiele większa przestrzeń na kreatywność „branżową”. W tym obszarze mamy spore sukcesy. Nie chwalimy się tym, bo w cybersecurity im ciszej, tym lepiej. Aktualny front walki to dziś jednak przede wszystkim wyłudzenia i przed tym naszych klientów próbujemy chronić, chociaż zadanie to nie jest łatwe gdyż przestępstwo odbywa się poza systemami banku i polega głównie na socjotechnice. Z jednej strony można by powiedzieć, że jeśli klient sam, z własnej woli przelał swoje oszczędności przestępcom, to ponosi odpowiedzialność za swoje czyny, ale z drugiej strony, jeśli mamy podejrzenie, że „coś się dzieje” to możemy próbować przestrzec klientów

W kontekście cyberbezpieczeństwa dużo mówi się m.in. o regulacji DORA, która będzie nakładać nowe obowiązki m.in. na członków zarządu. Czy mBank dostosowuje się już do zapisów tej dyrektywy?

Ciężko się dostosować do czegoś, co – jak rozumiem – nie zostało jeszcze do końca uchwalone. Choć oczywiście śledzimy postępy prac nad DORA. Osobiście jednak uważam, że po wejściu tych zapisów w życie ciężko będzie, zwłaszcza mniejszym graczom rynkowym.

Jeżeli będziemy musieli tak często, jak chcą autorzy projektu, robić testy penetracyjne wszystkich systemów przy pomocy specjalistów ds. bezpieczeństwa, to nie znajdziemy tylu pentesterów na rynku. Największe instytucje sobie poradzą, bo po prostu kupią lub zarezerwują niezbędne zasoby. Natomiast nie wystarczy ich dla 50-70 proc. podmiotów w sektorze finansowym. Może więc powinniśmy zrobić krok w tył i przeprowadzić „studium wykonalności”? Cóż z tego, że będzie regulacja, jeśli w praktyce jej zapisy nie będą możliwe do spełnienia przez większość podmiotów?

Intencje i cel rozumiem, ale trzeba je dostosować czy to do poziomu ryzyka, czy też możliwości rynkowych. Może w pewnych aspektach wystarczy automat? Może nie zawsze każdy test musi przeprowadzać człowiek?

Ostatnio jak rozmawialiśmy, na początku pandemii Covid-19, zastanawiał się Pan czy tak długi okres poza biurem nie spowoduje rozluźnienia więzi w zespołach. Czy tak się stało? Jak bank sobie z tym poradził?

Mogę to pytanie podsumować jednym zdaniem: przez ostatnie dwa lata zbudowałem bardzo mało nowych relacji z nowozatrudnionymi osobami. „Jedziemy” na starych relacjach. Najgorzej mają więc osoby, które albo zmieniają pracę, albo dopiero zaczynają karierę. Na poziomie operacyjnym wszystko oczywiście działa. Dużo trudniej jest na poziomie ludzkim. Nie ma właściwie sposobu na to, aby się zżyć z innymi członkami zespołu. Oby to się szybko skończyło… A nawet jeśli w ramach zespołów udaje nam się pokonywać te trudności to już w skali całej organizacji – zaczynamy być trochę takimi małymi wyspami. Myślę, że potrzeba maksimum kreatywności nas wszystkich, by poradzić sobie z tym wyzwaniem.

W ciągu kilku lat mBank chce stać się liderem zrównoważonej bankowości i zrównoważonego rozwoju ESG – Environmental, Social & Governance. Co to znaczy dla osoby nadzorującej m.in. pion IT?

Rozwiązania IT wpływają na środowisko, ponieważ są znaczącym konsumentem energii. Jako bank kupujemy zieloną energię w obszarze data center, ale również w ten sposób zasilana jest już np. centrala naszego banku.

Musimy także starać się obniżać zapotrzebowanie na energię. Nie zawsze jest to proste, ponieważ bank rośnie. Może więc być tak, że choć obniżymy współczynnik jej zużycia per klient, to całkowite zużycie wzrośnie. Możemy starać się, aby ten wzrost był wolniejszy niż wzrost bazy klientów. Udaje nam się to osiągać np. poprzez wymianę rozwiązań IT na nowsze, bardziej energooszczędne. Jeden serwer nowej generacji może zastąpić kilka starszych maszyn.

Potencjalnie też wszystkie realizowane przez nas migracje systemów IT są swego rodzaju odpowiedzią mBanku na konieczność zapewnienia zrównoważonego rozwoju. Jeśli bowiem we właściwy sposób przeprowadzi się migrację do chmury obliczeniowej, to możemy – w ramach Unii Europejskiej – skorzystać z centrum danych znajdującego się w kraju, w którym dominuje zielona energia. Mix energetyczny w Polsce wygląda tak, że dla wszystkich chętnych zielonej energii niestety nie starczy.

Czy strategia ESG wpłynie na relacje z partnerami? Na Zachodzie dużo się mówi o tym, że firmy oczekują od dostawców – np. chmury publicznej – tego by zadeklarował, w jaki sposób przyczynia się do ochrony środowiska, np. redukcji emisji gazów cieplarnianych czy stopnia wykorzystania odnawialnych źródeł energii. Czy to będzie ważne dla mBanku?

Stosujemy kodeks dla dostawców i partnerów biznesowych, który zawiera istotne dla nas aspekty związane z ochroną środowiska, odpowiedzialnością społeczną i ładem korporacyjnym. Oczekujemy, że nasi dostawcy dostosują się do naszych zasad. Nawiasem mówiąc, nie powinno być to dla nich nic trudnego, bo mBank nie jest jedyną organizacją, która stawia w strategii na aspekty ESG i narzuca partnerom tego typu wymogi. Większość, renomowanych dostawców na pewno szybko się do nich dostosuje, a jeśli nie to będą dostarczać swoje produkty i usługi komuś innemu. Wszyscy idą w kierunku ESG, jedyne pytanie jest o to, jakie będzie tempo wdrażania tego typu strategii w skali Polski? Kierunek ten jest jednak nieunikniony.

Technologiczne założenia nowej strategii mBanku na lata 2021-2025 „Od ikony mobilności do ikony możliwości” można znaleźć na stronie Banku.

Jej kluczowe elementy to:

• jakość dostarczania oprogramowania;
• poprawa reakcji na incydenty;
• transformacja do gotowości do działania w chmurze;
• cyberbezpieczeństwo;
• aplikacje mobilne;
• zastosowanie sztucznej inteligencji i uczenia maszynowego.