O Zero Trust i koncepcji Site Reliability Engineering (SRE)

Witaj na pokładzie FlyTalks. Subskrybuj, by być na bieżąco z odcinkami, w których gościmy ekspertów IT, praktyków chmurowego biznesu i trendsetterów. A dzisiejszym gościem jest Paweł Dawidowicz, Head of SRE Ramp Network, poznajmy jego świat. Super, że jesteś, świetnie było cię zobaczyć w ramach jednej z odsłoń Google Cloud Days, posłuchać twojej świetnej prezki. Teraz miło cię usłyszeć we FlyTalks.

Również miło, cześć, cześć.

To odcinek podcastu, w którym łączymy świat biznesu i technologii. Gdy będziesz zagłębiał się w swoje technikalia, chciałbym, żebyś miał z tyłu głowy, że słuchają nas ludzie o różnym profilu. Umówmy się, że mówimy po prostu do decydentów i do świata biznesu, ale oczywiście możesz zanurzyć się w deweloperski świat, ale pod warunkiem, że obiecasz, że będziesz trochę tłumaczył pojęcia, dobra?

Okej, jak coś, to krzycz.

Słuchaj, na początek: zauważyłem, że odpisujesz na maile, co w ogóle jest super, natomiast nie wiem, czy znasz takie pojęcie poczty 0.

Słyszałem, słyszałem o tym. Nie, nie prowadzę. W sensie raz na jakiś czas po prostu sprawdzam. Słyszałem o tym, coraz więcej osób nawet u nas pracy w ogóle ma takie podejście i to jest super, ale powiem ci...

Nie sprawdza się.

Nie. Bardzo opieramy, no 99% naszej komunikacji opieramy na Slacku, więc ten mail to jest, powiedzmy, sprawdzam go kilka razy dziennie i tyle.

Okej. Super, bo ja tylko powiem, że metoda 0 poczty polega na tym, że dąży się do 0 odczytanych wiadomości. Jest też druga grupa ludzi na świecie, która ma wiele 0, to znaczy dziesiątki tysięcy czasem, znamy takie trudne przypadki. Rozumiem, że jesteś raczej w tej pierwszej grupie. Gadamy dzisiaj tak naprawdę o profilu twojej profesji. Porozmawiamy sobie na pewno o tym, czym zajmujesz się w firmie. Pogadamy trochę o kwartale, o zmianach produktowych. Pogadamy oczywiście o Ramp Network, bo to jest core naszej rozmowy. I myślę, że takim fajnym wprowadzeniem może być w ogóle pojęcie, po które sięgacie też w materiałach marketingowych, bo przedstawiacie Ramp Network jako platformę, która będzie rewolucjonizować nasze podejście w ogóle do używania Internetu i opiera się też na pojęciu Web3. Ja sobie to tak tłumaczę i takie też opracowanie można znaleźć, że Web1 to było wtedy, kiedy założyliśmy Internet. Web2, kiedy zaczęliśmy jako użytkownicy też tworzyć treści w tym Internecie. Natomiast Web3 już zakłada to podejście, że będzie można łatwiej. No właśnie co? Zmonetyzować swoją pracę, swoją twórczość w sieci? Czym dla ciebie jest Web3?

Dla mnie osobiście to jest właśnie przejście na zdecentralizowane w ogóle kontrakty między ludźmi. W sensie masz swojej identity, które może być niepodważalne, może opierać się właśnie na blockchainie, możesz właśnie przez to zintegrować się z różnymi systemami. Teoretycznie nie będziesz musiał wychodzić, korzystać z jakiejś zewnętrznej firmy typu, nie wiem, bank czy cokolwiek, w którym musisz, nie wiem, poświadczyć swoją osobę. Zazwyczaj zakładasz gdzieś konto czy chcesz coś zrobić, czy w ogóle logujesz się np. do mObywatela, możesz się zalogować przez bank. Bank jest tą instytucją, która w ogóle ma twoje pieniądze, która decyduje o tobie, może tych pieniędzy ci nie dać, jakby coś się stało, a wiemy, że ostatnio dużo dzieje się z bankami. I właściwie nie masz za dużo kontroli. Web3 zakłada tą kontrolę, danie tej kontroli ludziom po prostu. Czyli masz chociażby kryptowaluty, które nie mają jednego centralnego miejsca, w którym ktoś może powiedzieć: "Hej, dzisiaj zamykamy, dzisiaj zabieramy. To, co jest twoje, zostało zabrane", choć właściwie to jest dość zabawne, bo dużo ludzi, właśnie wchodząc do świata Web3, właściwie nie wchodząc, tylko chcąc kupić jakieś kryptowaluty, zakłada konta na giełdach, w których cała ta magia, na czym miał polegać Web3, no to trochę też luck, tak? W sensie, kupujesz sobie właśnie te kryptowaluty na giełdzie, gdzie znowuż nie masz tak naprawdę prywatnego klucza, do którego przypisane są te waluty, tylko znowuż posiada je giełda, czyli podobnie jak było z bankiem. No i potem użytkownicy tracą te pieniądze, bo znowuż jest ten sam problem, że nagle stracili dostęp. No i właśnie to, co my robimy, to staramy się umożliwić prawdziwy onboarding do świata Web3, to znaczy, żeby te klucze, te twoje dobra nie były zarządzane przez nikogo innego, żebyś mógł korzystać ze swoich prywatnych kluczy czy w ogóle żebyś mógł wejść do świata produktów tak naprawdę. Czyli, nie wiem, grasz w jakąś grę, która jest oparta na jakimś blockchainie, chcesz kupić tam jakiejś dobra. Nie musisz wychodzić z tej gry, nie musisz wejść do giełdy, założyć tam jakiegoś konta. Masz swoje identity. My pozwalamy ci kupić przez integrację Rampa w danym produkcie, w łatwy sposób cię zonboardować, czyli zachęcić użytkownika, że nie musi nigdzie tych kont zakładać. My działamy na zasadzie B2B2C, to znaczy działamy z naszymi partnerami, żeby końcowo dotrzeć do klientów i nasi partnerzy integrują nasz widget w swoich aplikacjach, na swoich stronach, na swoich produktach. Czyli tak, muszą przyjść do nas, dogadać się z nami. Ta integracja jest bardzo prosta, to właściwie jest tą naszą magią, że to jest dosłownie paczka, którą musisz zaintegrować. No wiadomo, że musimy dać ci jakiś klucz, żeby to wszystko działało, ale sama integracja jest bardzo prosta. To nie jest tak, że musisz tonę rzeczy poustawiać, żeby te działało, po prostu jest to dość proste.

Mam nadzieję, że trochę uchylisz rąbka tajemnicy, jak udało się to wszystko stworzyć, ale może to przenieśmy w dalszą część naszej rozmowy. Teraz chciałbym trochę podrążyć temat w ogóle Ramp Network. Trochę już napomniałeś. Czym w ogóle się zajmujecie i co jest takim corem i esencją waszej działalności? Gdy tłumaczysz to laikowi, to jak w jednym zdaniu wytłumaczyć, czym zajmuje się Ramp?

Myślę, że po prostu umożliwiamy w łatwy sposób kupno i sprzedaż, to jest istotne, od jakiegoś czasu umożliwiamy też sprzedaż, czyli z powrotem wyjście z tego świata Web3 i z powrotem, czyli w tą drugą stronę, to pierwsze to On Ramp, to drugie to Off Ramp i umożliwiamy to w łatwy sposób przy pomocy... Naszym partnerom umożliwiamy łatwą integrację naszego produktu w ich produkcie, żeby ich klienci mogli w łatwy sposób dokonywać tych zakupów, nie wychodząc z ich produktów.

Przeczytałem właśnie, że ten kwartał był dla was bardzo obiecujący, bo stał się taki globalny dla świata. Mamy 130 krajów z dostępnym Rampem i 38 kryptowalut, które można wymieniać na, jeśli dobrze widzę, dolary, euro i funty brytyjskie, czyli mamy tak naprawdę cały świat, można tak powiedzieć, cały świat pokryty, więc rozumiem, że to jest wielki krok w rozwoju Waszego produktu.

Wydaje mi się, że przeczytałeś teraz o Off Rampie, bo On Ramp globalnie był już dostępny, to Off Ramp właśnie, czyli w tą drugą stronę.

Tak, tak.

Rzeczywiście jakiś czas temu umożliwiliśmy sprzedaż kryptowalut z powrotem na tradycyjne waluty globalnie. I myślę właśnie, że to jest ten kluczowy element onboardingu, paradoksalnie, ludzi do świata Web3, bo dajemy im łatwą też możliwość: "Hej, jak coś, to możesz powrócić". Łatwiej nam postawić nogę, zrobić krok dalej, jeżeli wiemy, że możemy zrobić krok w tył.

To prawda, fajnie mieć taką furtkę. Jeśli chodzi o nową generację Internetu, która wykorzystuje już Web3, to mamy to chyba trochę nakreślone. Teraz pytanie trudniejsze, choć sprowadza się do kilku słów. Jak ogarnia się taką infrastrukturę, która obsługuje globalnie cały świat? Tutaj z pomocą przychodzi Cloud. Pytanie, czy możesz trochę przeprowadzić nas przez drogę i takie podstawowe informacje, co wykorzystujecie, by to wszystko działało, a skoro zarządzacie tak naprawdę kryptowalutami, to ten poziom dostępności, za który ty odpowiadasz i do tego też przejdziemy, musi być możliwie wysoki?

Tak, no dokładnie, tu przychodzi z pomocą Cloud. Szczerze powiedziawszy nie wyobrażam sobie budowania startupu on-premise, to znaczy stawiamy sobie jakąś serwerownię, tam uruchamiamy starego typu aplikacje i w ogóle zarządzanie tym wszystkim od hardware'u w górę, no to są rzeczy, o których raczej nie myślisz. Poziom wejścia teraz jest dużo łatwiejszy, właśnie ten Cloud, w którym te wszystkie, ten cały hardware jest już załatwiony i operujesz na pewnym poziomie abstrakcji. No i właśnie infrastrukturę, której używasz, czyli Cloud, jest globalna, więc już nie masz tego problemu, że: "Okej, chcę robić globalny produkt, ale w sumie to w biurze w Warszawie mam serwer i co dalej z tym robić?". Nie, operujemy właśnie na Google Cloudzie, który z zasady w ogóle, projekty które tam tworzysz są globalne, co jest ciekawe, bo sieci, które tworzysz, bazowo są od razu globalne, w przeciwieństwie np. dla AWS-a, gdzie one były regionalne. To jest taki mały smaczek, ale pokazuje trochę, że Google ma inne podejście. Bardziej ci pomaga zrobić te twoje serwisy globalnymi, mimo to, że to samo możesz zrobić w innych chmurach, ale to jest taki smaczek, który pomaga. No i jak to robimy? Używamy serwisów, właśnie w tym Google'u. Od jakichś prostych, wirtualnych maszyn, czyli nie różni się to za bardzo od tego, jakbyś ty postawił sobie to lokalnie, poza tym, że jeżeli padnie dysk czy cokolwiek innego, no to ta wirtualna maszyna zostanie zastąpiona w minutę czy może dwie. Co jest właśnie kluczowe, że musisz tą aplikację napisać i właśnie tym my się zajmujemy, żeby ta aplikacja jednak, jak coś nam padnie, to była przystosowana do takiego dynamicznego środowiska, w którym ona się zaadaptuje, zrestartuje, uruchomi w kolejnym, na kolejnej instancji.

Pawle, powiedz mi, czy zdradzasz takie szczegóły, czy to już jest poziom tajemnicy firmy, z jakich usług dokładnie korzystacie? Czy głównie opieracie się na jakichś bezserwerowych, czy jednak implementujecie to, jak mówiłeś, na wirtualnych maszynach bardziej?

Ani to, ani to i w sumie... Znaczy zależy. Używamy na pewno też wirtualnych maszyn. Używamy serwerowych narzędzi do niektórych specyficznych rzeczy, szczególnie przy przetwarzaniu danych z data inżynierami, ale takim corem, na którym stoi nasza główna część infrastruktury aplikacyjnej, jest Kubernetes.

Czyli konteneryzacja?

Tak, dokładnie. Właściwie nawet jak stawiamy coś na wirtualnych maszynach, to też są kontenery. Raczej nie schodzimy niżej niż kontenery.

Są tego benefity. Jakie są największe dla ciebie?

Przede wszystkim prostota. Możesz uruchomić sobie taki sam kontenerek na swoim komputerze. Możesz go przetestować w takim samym środowisku, jak będzie uruchamiany na produkcji. Coś, co kiedyś było nie do pomyślenia, bo zazwyczaj jak uruchamiałeś aplikację u siebie, działała, potem ona przechodziła na produkcję czy jakieś kolejne środowisko i okazało się, że: "O nie, to jest zupełnie inny system", tam ktoś jakąś inną zmienną dał, coś się zadziało. Tu nie ma praktycznie, czym się różnić. No i wcześniej jak budowałeś takie obrazy, no bo były też pomysły, żeby od początku zbudować obraz całej wirtualnej maszyny, który będzie miał w sobie aplikacje, tylko to był bardzo wolny proces. W sensie musiałeś zgrać cały obraz praktycznie maszyny, co było wolne, no i nie za bardzo dostosowane do szybkich zmian. Mogłeś też po prostu podmienić jakąś część na tej wirtualnej maszynie, ale to znowuż było nieodporne na błędy, to znaczy bardzo zawodne. Więc tak, te kontenery są dość lekkie, są proste, masz też dużo już zdefiniowanych przez community, w ogóle teraz żyjemy w świecie open-source'u, więc bardzo dużo narzędzi jest już zrobionych przez kogoś. Nie wiem, chcesz uruchomić sobie bazę danych, no to bierzesz sobie taki kontener, który ktoś wyprodukował, oczywiście nie bierzesz pierwszego lepszego z brzegu, tylko oczywiście sprawdzony, danej firmy, która odpowiada za ten produkt, dostosowujesz go tylko do swoich potrzeb jakimiś zmiennymi, no i tyle. Jest to po prostu łatwe, szybkie.

A czy kontenery umożliwiają autoskalowanie, GKE Autopilot, jak to się sprawdza? Czy wtedy Kubernetes sam dobiera maszyny pod potrzeby?

Okej. To, jeżeli chodzi o Kubernetesa, mamy, powiedzmy, 2 poziomy abstrakcji. Jeden to są node'y, czyli rzeczywiście wirtualne maszyny, a drugie to są pody, czyli możemy przyjąć, że takie opakowania na kontenery, dla uproszczenia przyjmijmy, że kontener.

Okej.

Więc mamy te node'y, czyli rzeczywiście fizyczne serwery, które... Znaczy fizyczne, to są wirtualne serwery, ale to nieistotne. Mamy te maszyny, które właśnie ten autopilot np., ale na razie odsuńmy go, Kubernetes zazwyczaj sam potrafi plus minus, w zależności od Cloud providera skalować.

Okej.

Czyli, powiedzmy, chcesz uruchomić sobie 10 kontenerów, każdy kontener potrzebuje 1 core'a, CPU, no to potrzebujesz łącznie 10 core'ów. Masz node'y, które mają, powiedzmy, po 5 core'ów, czyli potrzebujesz 2 node'ów, żeby uruchomić te 10. Jak chcesz uruchomić kontener i masz wolne miejsce na nodzie, to jest to szybkie, instant praktyczny. Jeżeli okazuje się, że na klastrze nie ma miejsca i musisz sobie dociągnąć nowy node, no to to jest postawienie wirtualnej maszyny, no i to chwilę trwa. Czyli znowuż automatycznie, jeżeli tak ustawisz, on zostanie dociągnięty, ale będzie to dłuższe.

To jest kluczowe w przypadku waszych operacji, tutaj liczy się czas?

Zawsze liczy się czas. Wyobraź sobie, że masz aplikację, która automatycznie się skaluje. Masz nagle spike w ruchu, no i chcesz obsłużyć ten spike i skalujesz aplikację, bazując na zużyciu, powiedzmy, jakichś zasobów typu CPU. Nagle te wszystkie twoje kontenery mają zużycie 100%, no i jeżeli przyjdą kolejne requesty i nie zdąży się wyskalować w tym czasie, nowe kontenery nie wystartują, no to zaczniesz throtlować, czyli wszystkie requesty, które przetwarzasz, zaczną spowalniać albo będziesz musiał odciąć ten nowy ruch.

Niepożądana sytuacja, mówiąc delikatnie, w waszym profilu działalności, a tylko zatrzymując się na 30 sekund, jedno pytanie. Kiedy obserwujecie takie największe piki? Czy to jest wiesz, grudzień i zakupy, czy to jest Black Friday, czy to jest w ogóle piątek i co weekend?

Bardzo różnie. Czasem mamy promocję po prostu jakąś z partnerami, partner ma promocję. No to wtedy wiemy, jesteśmy przygotowani na ten skok ruchu. Czasem jakieś rzeczy, które się dzieją po prostu z kryptowalutami, takie ogólnoświatowe, więc widać jakieś trendy i nieraz tak było, że zaczęliśmy się zastanawiać, czy mamy jakiś atak może, czy coś się dzieje, bo ruch skoczył np. 10 czy ileś razy, no i zazwyczaj pytamy się wtedy na kanale i ktoś nam mówi: "Hej, tutaj takie zdarzenia się dzieją na świecie i tu się okazało, że rynek reaguje, więc...".

Czyli rozumiem, że po prostu wy musicie być gotowi na przyjęcie każdego ruchu i Cloud to umożliwia?

Tak. No w sensie Cloud nie zrobi za ciebie roboty. Aplikacja musi być w ogóle dostosowana do tego. Musisz też napisać, utrzymać tą infrastrukturę w dany sposób, żeby to było możliwe. Tak, no, przy serverlessie to jest łatwiejsze, ale z drugiej strony ciężej zrobić skomplikowaną aplikację. No i też musisz ją napisać w dany sposób, żeby też potrafiła się skalować. No, jeżeli twoja aplikacja potrafi się skalować, to zazwyczaj to nie jest problematyczne. Czemu w ogóle, co to znaczy, że aplikacja może się skalować? No to powiesz: "Zróbmy teraz 10 takich aplikacji, bo jest skok ruchu", ale dalej masz miejsce, w którym 2 czy 10 aplikacji musi czekać na siebie, bo tylko 1 może korzystać na raz. Powiedzmy: masz jakąś kolejkę i tylko ta 1 osoba z przodu może coś wyciągnąć, więc nawet jeżeli przyjdzie te 10 kontenerków, w tej kolejce będzie czekać, no to tylko ten pierwszy będzie mógł z tego skorzystać. No więc są pewne takie wrażliwe systemy, specyficzne, które czasem ciężko rozbić. Cloud w tym akurat często pomaga, bo potrafi stworzyć serwisy, które są mocno rozproszone i jakoś ułatwiają wielozadaniowość.

No to 2 pytania tutaj. Po pierwsze, czy dla ciebie Cloud faktycznie nie ma żadnych limitów, jak chodzi o potencjał skalowania, czy zaobserwowałeś taki moment: o kurczę, jakby zasoby oferowane, dajmy na to przez Google, mogą nie wystarczyć, kiedy będziemy rozwijać się tak w tempie jeszcze przez 10 lat?

Wiesz co, my też nie operujemy na taką skalę i też potrzebujesz, w sensie na taką skalę jeszcze, ale też nasz ruch nie jest aż taki ciężki, jeżeli chodzi o zasoby, no bo wyobraź sobie: masz np. sklep. Wchodzisz na taki sklep, masz tonę reklam, tonę produktów, tonę danych. Zanim przejdziesz, zanim coś kupisz, no to wygenerujesz bardzo dużo ruchu. No a teraz my mamy głównie tą bramkę, którą umożliwiamy komuś kupno lub sprzedaż kryptowalut, więc jak już przychodzisz skorzystać z naszego produktu, to przychodzisz w danym celu. Nie boję się tutaj, że zabraknie zasobów w Google'u czy w jakiejś innej chmurze, ale są firmy, które mają takie problemy. Wtedy oni się jakoś inaczej dogadują bezpośrednio z Google'em. Musisz zaplanować, jeżeli będziesz potrzebował za miesiąc dodatkowe 10 000 serwerów, to może się okazać, że ich nie będzie, ale chciałbym mieć taki problem, to było by ciekawe.

Tego ci życzę. Myślę, że dojdziemy do takiego momentu. Słuchaj, wspomniałeś o aplikacji Rampa i zakładam, że to pewnie jest kilka aplikacji, właśnie, jak to wygląda. Pytanie, czy znasz je? Trochę chcę tutaj przechodzić do twojego profilu SRE. Czy ty odpowiadasz za dostępność i niezawodność? A jeśli tak, no to rozumiem, że musisz znać poszczególne komponenty aplikacji?

Tak i nie. W sensie, jak zwykle...

Uwielbiam, "to zależy".

To zależy jak zwykle. Więc tak, musimy rozumieć w ogóle to, na czym aplikacja stoi, to my tworzymy, to my jesteśmy całkowicie odpowiedzialni. Musimy rozumieć, jak aplikacja się ze sobą komunikuje, właśnie sposoby komunikacji międzyaplikacyjne, no to tam wtedy to przychodzi przez tą całą infrastrukturę i musimy zapewnić, że to wytrzyma, że rozumiemy. Właściwie, w ogóle duża część naszej pracy polega na rozumieniu i rozmowie z deweloperami nad tym, czego oni potrzebują, co oni są osiągnąć z tą aplikacją, jak ona powinna działać i wytłumaczyć im, co my możemy im zapewnić i jak wygląda to środowisko produkcyjne. Co trzeba zrobić, żeby właśnie móc to wyskalować itd., ale my też nie możemy zrozumieć wszystkiego, w sensie nie jesteśmy deweloperami tej aplikacji, więc są części, których nie rozumiemy, ale dajemy narzędzia deweloperom i też im odpowiedzialność za te części. Cała metodologia DevOps właśnie zaczęła się od tego, żeby rozwiązać ten problem. Wcześniej miałeś deweloperów i adminów. Ci deweloperzy zrobili aplikację, jakąś zmianę w kodzie i tyle, i hej. Co tam się dzieje na produkcji, jak to działa w ogóle ich nie obchodziło. Administratorzy nie chcieli właśnie tych zmian wprowadzać, no bo wiesz, oni byli odpowiedzialni za to, że to będzie niezawodne, że będzie działać tak jak powinno. Każda zmiana może wprowadzić błąd, więc te zmiany zdarzały się rzadko, np. firmy wypuszczały je raz na miesiąc czy nawet rzadziej, no i ciężko było tak developować. Właśnie ta metodologia DevOps wyszła po to, żeby rozwiązać ten problem, żeby gdzieś uspójnić relacje i dać większą odpowiedzialność deweloperom, zrobić ciągłe wdrażanie, czyli jakakolwiek zmiana przetestowana odpowiednio, zabezpieczona, oczywiście od razu idzie np. na produkcję.

Tutaj trochę muszę znowu wrócić. Czy twoim zadaniem jest zapewnienie niezawodności? Czy da się to jakoś zmierzyć? Czy są wskaźniki, wedle których operujesz, statystyki? Czy podglądacie to i monitorujecie?

Tak, właściwie observability, czyli monitorowanie tych statystyki i tworzenie narzędzi, dawanie tych narzędzi deweloperom, żeby oni mogli sobie określić, bo w ogóle co to znaczy, że aplikacja jest niezawodna? Wracając do pytania: tak, jesteśmy odpowiedzialni właśnie za niezawodność naszego systemu, aplikacji, za pokrycie 24 na dobę, czyli on call, tutaj też z deweloperami w tej inicjatywie jesteśmy. To znaczy, jeżeli coś się dzieje, no to 24 na dobę mamy to pokrycie, ale to nie jest tak, że tylko dzwoni do nas, no bo są jakieś problemy, których my dewelopersko nie rozwiążemy. Jeżeli jakaś część w aplikacji przestała działać, no to tutaj musi nam pomóc deweloper, więc ta niezawodność to... Zawodność może tak, ciężko ją określić, no bo łatwo dać pewne miary, które mówisz, czy w ogóle system odpowiada, nie wiem, procesujemy jakieś transakcje itd., itd., ale im dalej w las wchodzisz, to, co to w ogóle znaczy, że aplikacja działa od strony biznesowej? To znaczy, tu już musi wejść produkt, tu muszą być też deweloperzy, żeby takie metryki przy naszej pomocy wprowadzić i sobie móc sprawdzić, czy wg nich, czy ta ich działka działa. Powiedzmy: procesujemy transakcję. Podstawowe metryki mówią, że system działa, aczkolwiek jest jakaś część, np. procesujemy dla specyficznej grupy, nie wiem, transakcję dużo dłużej, czy właściwie oni nie dostają może tyle pieniędzy, ile powinni, cokolwiek, coś bardziej specyficznego się dzieje, no to ktoś musi to zaimplementować w aplikacji. Musisz zacząć to mierzyć w ogóle, no i my do tej aplikacji nie wejdziemy, bo też nie do końca się na tym znamy. No i tutaj musimy ewangelizować deweloperów, że: "Słuchajcie, mam takie narzędzia, wy jesteście też odpowiedzialni za to, my wam pomożemy", no ale jeżeli nie wprowadzicie takiej metryki, nie wpiszecie playbooka, czyli musisz zrobić metrykę, po której będziesz sprawdzać tą zawodność właśnie. Jeżeli ona przekroczy jakiś poziom, robi się alert, np. page do tego pokrycia 24/7. No i oni wtedy ten problem muszą rozwiązać, ale jeżeli nie dasz instrukcji, bo to jest bardzo specyficzna domenowa wiedza, jak to naprawić, co z tym można zrobić, no to nic z tym za bardzo nie zrobimy. W sensie siądziemy z deweloperem jakimś. Będziemy myśleć, co tam można rozwiązać, ale każdy właśnie taki alert, który idzie do nas, musi być pokryty właśnie playbookiem, czyli informacją, chociaż jakimiś hintami co można zrobić, bo no jesteśmy scale uppem, nie wszystko jest takie super, jakbyśmy chcieli. No jakby pracujemy nad tym i z miesiąca na miesiąc to jest lepsze, no ale czasem musimy iść po prostu na jakieś kompromisy. Lepiej, żeby coś zaalertowało i nie było np. superinstrukcji, jak to rozwiązać, no bo, powiedzmy, te tęgie głowy, które będą rozwiązywać ten problem, jest duża szansa, że i tak, i tak wpadną na to, co można zrobić.

Przypominam, że naszym rozmówcą w ramach FlyTalk jest Paweł Dawidowicz, Head of SRE Ramp Network. Pawle, tak trochę też z kontekstu sobie buduję to, czym zajmujesz się w pracy, jakkolwiek to brzmi, ale poznaję twoje środowisko, poznajemy je wszyscy. Trochę dałeś temu wyraz też, omawiając kontenery. Pytanie też, czy po prostu twoim zadaniem jest w ogóle przemyślenie, jak to wszystko ma się skalować i żeby skalowało się w odpowiedni sposób, takie trochę utrzymanie ruchu, czy to też jest uzupełnienie twojego profilu?

To również. Niezawodność, właśnie dlatego ja lubię tą nazwę "SRE", bo masz w niej w środku słowo klucz "niezawodność". Ta niezawodność to jest zarówno to, żeby system działał, system, który jest przy ruchu standardowym. Żeby system się skalował, czyli znowuż niezawodność przy jakimkolwiek ruchu, czy będzie skok, czy nie, żeby aplikacje były bezpieczne, żeby w ogóle infrastruktura była bezpieczna. Żeby nikt nie mógł tam wejść przez przypadek, żaden haker, nikt nie mógł nas zaatakować, znowuż możemy podciągnąć pod niezawodność. Musimy być niezawodni pod każdym względem. Czyli takie holistyczne podejście do tej infrastruktury, która po prostu musi działać. Działać dobrze, przyjąć każdy wolumen. No i też musimy dużo pracować z deweloperami, żeby ich nakierować na pewne rzeczy, no bo my sami wszystkiego nie zrobimy. Możemy sobie zrobić superinfrastrukturę, ale tak jak wspominałem wcześniej, jeżeli aplikacja nie będzie dostosowana, no to za dużo to nie da.

Niespodzianki się zdarzają. Jeśli moglibyśmy powiedzieć coś na temat niespodzianek ze strony providera, to znaczy, co was zaskakuje najbardziej i powiedzmy, mówiąc delikatnie, utrudnia pracę i co jest taką bieżączką? Słuchają nas Googlersi, masz to okienko, by powiedzieć, co jest do zmiany albo czego nie chciałbyś w ogóle.

O kurczę, nie chciałbym się aż tak rozgadywać. To, co czasem najbardziej przeszkadza, to chyba w jakimkolwiek produkcie, którego będziesz używał, jest np. niezgodność z dokumentacją. Że używasz czegoś, coś nagle nie działa w taki sam sposób jak reszta systemu. Jedno to jest, że jest udokumentowane i nie działa tak jak powinno, jak dokumentacja mówi. To czasem po prostu wysyłamy, poprawiają dokumentację, no tam się tyle rzeczy zmienia, jak w każdym produkcie, tak jak mówię, to nie jest specyficzne, ale to są rzeczy, które bardzo irytują. No bo masz już pewne doświadczenie, wiedzę, chciałbyś po prostu coś postawić wg dokumentacji, nie powinieneś musieć za bardzo się nad tym zastanawiać. Potem tracisz cały dzień, bo okazuje się, że coś nie działało tak jak powinno, a to ciężko znaleźć. No bo jak jest jakiś mały smaczek, wracasz potem znowu do dokumentacji, patrzysz: "Czy ja na pewno dobrze zrozumiałem? Nie no, dobrze zrozumiałem, tak to pokazuje". Potem się okazuje, że jednak okej, to nie działało tak jak powinno.

Dobra. Pytanie trochę o work-life balance. Czy dostajesz powiadomienia w środku nocy, czy raczej śpisz spokojnie?

No to jest właśnie cudowna rzecz w tym on callu, czyli tym pokryciu 24/7, w którym też oczywiście uczestniczę raz na jakiś czas. Jeżeli nie masz on calla, no to po to jest ten on call, żeby osoby, które mają dyżur w danym tygodniu, zostały powiadomione. Więc tak, ja śpię spokojnie, bo wiem, że są osoby, które po prostu są na tej pierwszej linii i zostaną powiadomieni w razie czego. Oczywiście, jeżeli one nie będą mogły rozwiązać problemu, no to problem zostanie wyeskalowany do mnie, ale właściwie to się nigdy nie zdarzyło, zawsze w sumie ta pierwsza linia wystarcza. I to była najwspanialsza rzecz, którą wprowadziłem w Rampie, bo wtedy rzeczywiście mogłem spać spokojnie, wiedząc, że jest tam ktoś, kto czuwa.

Czyli zatrudniając 150 osób, mając siedziby w Londynie, w Miami, w Warszawie, we Wrocławiu, budując globalny biznes ze świata FinTechu, operując na zdecentralizowanej aplikacji, można spać spokojnie?

Tak [śmiech].

Miło. Czy jakieś fajne konferencje planujesz w tym sezonie? Gdzie koncentrujesz swoją uwagę, gdzie szukasz wiadomości i czym żyjesz, by wzbogacać swoje życie zawodowe? LinkedIn czy to już jest passé?

To jest właściwie ciekawe pytanie, bo ostatnio w zespole mieliśmy dużo rozmów na ten temat, skąd bierzemy informacje. Jeżeli chodzi o konferencje, może najpierw to, to jedziemy z zespołem na KubeCon do Amsterdamu, to jest w sumie najważniejsza konferencja w całej Europie dotycząca tego, co robimy, więc mega jaram się po prostu.

I to dosłownie, bo to Amsterdam [śmiech].

[śmiech] Tak, tak. To, że Amsterdam, to akurat przypadek, ale rzeczywiście nie ma po prostu drugiej takiej konferencji w Europie. No w tym roku jest w Amsterdamie. Rok temu nie mogłem na nią pojechać, bo była tydzień przed moim ślubem i bardzo, bardzo, bardzo żałowałem. Próbowałem negocjować, czy może jednak, ale to były jeszcze tematy COVID-u, więc konferencja, wróciłbym chory na swój ślub, no wiadomo, poza tym to...

Zachowałeś się odpowiedzialnie. Jesteś szczęśliwym mężem.

Dokładnie, inaczej mogłoby się zupełnie inaczej potoczyć, no ale tak. To jest konferencja. A skąd czerpać wiedzę? Ja myślę, że tu jest bardzo dużo różnych źródeł, zaczynając np. od LinkedIna. Warto... Powiem ci, że często widzę ciekawe materiały, ogłoszenia właściwie, np. przez Google'a, ich produktów. Te najistotniejsze trafiają tam. Jeżeli chodzi właśnie o takie zmiany, to w ogóle czasem, czy tam changelogi po prostu wchodzę na GitHuba i czytam, że tak powiem, chamskie changelogi, co tam zostało zmienione, bo jestem ciekaw, w jakim tempie rozwija się np. produkt, z którego korzystamy. Tak jak mówiłem, mocno opieramy się na open source'ie, więc potrzebuję zrozumieć, czy oni idą w dobrą stronę, czy oni szybko robią te zmiany, co dokładnie, co tam się dzieje, to daje fajny pogląd. Mam taki koncept, wprowadziliśmy w zespole, nazywa SRE Coffee. Rozmawiamy sobie raz na tydzień godzinkę o jakichś różnych ciekawostkach, o których się dowiedzieliśmy. Przedstawiamy np. jakieś nowe rozwiązania, które moglibyśmy wprowadzić, jakieś proof of concepty, które ktoś zrobił i to bardzo fajnie napędza, bo każdy ma jakiś tam obszar, który jest jego ulubiony, rzuci jakieś hasło, potem ty idziesz do domu i sobie w wolnym czasie o tym czytasz, bo tak. No dużo po prostu w wolnym czasie czytam o tych wszystkich technologiach, których używamy, no bo zwyczajnie w świecie mnie to bawi i wydaje mi się, że fajnie w ogóle się pracuje w IT przez to, że większość ludzi to bawi, że to nie jest tak, że robisz coś, że idziesz na 8 godzin i musisz odwalić robotę, tylko ludzie się tym zwyczajnie jarają jak dzieci często, że kurde, wprowadzamy nową wersję czegoś i ona umożliwi nam rozwiązanie 1000 problemów albo: "Hej, słuchajcie, czytałem czy rozmawiałem z kolegą o jakimś nowym narzędziu, spróbujmy". No i tu znowuż w drugą stronę, musimy, ja niestety muszę bardzo często hamować takie inicjatywy. W sensie są super, ale wiadomo, mamy jakieś biznesowe zobowiązania, które musimy osiągnąć i nie zawsze jest na to miejsce, ale wolę w tą stronę. Wolę czasem być tym złym i zahamować niż pracować z ludźmi, którzy takich pomysłów nie mają.

No to super. To chyba jest takie znamienne w tej branży i trudno znaleźć lepsze środowisko, które chętnie dzieli się wiedzą, robi to za darmo, często w formie konferencji i materiałów udostępnianych w sieci, w formie open source'u w ogóle, więc to jest naprawdę przepiękny świat.

Ja tylko dodam tutaj, przepraszam, że się wtrącę w słowo, ale powiedziałeś "dostępne za darmo", to myślę, że super tutaj w ogóle poziomem wejścia jest książka opublikowana przez Google'a właśnie, która się nazywa "Po prostu SRE" i jest dostępna za darmo na stronie pdfa czy Kindla można pobrać, z tym Kindlem to nie jestem pewien, ale na pewno można normalnie na stronę wejść, przeczytać. Mają też kontynuację, troszkę jakby kontynuację tej książki "SRE Handbook" i to są takie 2 obowiązkowe pozycje, które warto poczytać, jeżeli się myśli o tym zawodzie, ale są ciężkie. W sensie ta pierwsza książka, jest każdy rozdział pisany przez innych ludzi, traktuje o czymś innym, no i zwyczajnie ciężko się to czyta, ale warto.

Czyli do połknięcia raczej nie przed rozmową kwalifikacyjną, tylko jako osobny proces przygotowawczy do tego stanowiska. Pytanie, jak realizujecie Zero Trust? Jesteście w bardzo odpowiedzialnej branży, gdzie tutaj nie ma mowy o pomyłkach, a jeśli już, to są bardzo kosztowne.

Właściwie to, jak poznaliśmy się na tej konferencji, to właśnie o tym Zero Trust'cie w Google'u mówiłem, ponieważ znowuż użyję infantylnego słowa, jaram się tym, bo zmieniło to zupełnie podejście do pracy. To znaczy wcześniej właśnie musiałeś mieć jakiegoś VPN'a, musiałeś w ogóle robić jakieś sieci w biurze właśnie najlepiej i z tej sieci mogłeś dostać się do jakichś zasobów firmy, co w ogóle było meganiebezpieczne, no bo co z tego, że jesteś w firmie, no ale kim ty jesteś, czy jesteś odpowiednią osobą, czy nie dostałeś się przez przypadek do tej sieci? No właściwie wystarczyło, że, no zdalna praca polegała na tym, że miałeś jakiś wirtualny tunel między tobą a w sumie siecią twojej firmy i teoretycznie byłeś w sieci swojej firmy, a jedyne co wystarczyło, to móc wejść do tego tunelu i już mogłeś robić tam, co chciałeś. Zero Trust mówi o tym, żeby nie ufać i zawsze sprawdzać. To znaczy za każdym razem, jak teraz chcesz dostać się do jakiegoś zasobu, to jest sprawdzane, czy to jesteś na pewno ty i czy dane reguły wymagane do tego, żeby dostać się do tego zasobu, zostały spełnione. To znaczy, możesz powiedzieć, że masz jakieś bardziej krytyczne rzeczy, np. właśnie infrastruktura i żeby dostać się do tej infrastruktury, to ty musisz być, np. w jakimś regionie, możesz być w jakiejś godzinie, z jakiejś grupy, z zaaprobowanego urządzenia, w ogóle z przeglądarki np., być może tylko właśnie z Google Chrome'a, co też jest ciekawym rozwiązaniem w Google Workspace, że pozwalają ci zarządzać tym Google Chrome'em, co jest super, bo kontrolujesz punkt wejścia i punkt wyjścia. Czyli kontrolujesz te zasoby gdzieś tam w chmurze, do których ktoś ma się dostać, ale jeszcze kontrolujesz, jak ktoś się dostaje z nich, czyli z tej odpowiedniej przeglądarki, a nie używa sobie, nie wiem, jakiejś nowoczesnej przeglądarki, która jest fajna, ale nie do końca zaufana. Więc co ten Zero Trust umożliwia, no to właśnie to, że nie masz tego konceptu w ogóle sieci. Nie ma czegoś takiego, że ktoś łączy się z biura czy ktoś jest w domu, była jakaś różnica. Po prostu za każdym razem musisz potwierdzić swoje identity i musisz spełnić jakieś reguły. Więc wchodząc np. na takiego Meeta, mogę się uwierzytelnić po prostu w jakiś tam łatwy sposób, ale np. wchodząc na produkcję, muszę się uwierzytelnić kluczem fizycznym za każdym razem. No i w ogóle sam klucz fizyczny plus uwierzytelnienie podstawowe, które masz, powoduje, że ten poziom bezpieczeństwa jest niesamowity i to też właśnie wprowadzenie kluczy fizycznych przy dostępach krytycznych było rzeczą, która pozwoliła mi spać spokojnie, bo jednak SRE w Rampie jest odpowiedzialne za bezpieczeństwo tych krytycznych systemów, więc sam po prostu bardzo chciałem z siebie już, nie przez żadne regulacje czy potrzeby certyfikacji, zabezpieczyć to, jak tylko można. Co w ogóle jest superpostrzegane przez wszystkich audytorów czy jak mieliśmy np. due diligence z inwestorami, jak usłyszeli, że potrzebujemy klucza fizycznego, to jest takie hasełko teraz, które jednak: "Wow, to jest super, fajnie to przemyśleliście". Wiem, że miałeś rozmowę ostatnio właśnie o Zero Trust'cie z przedstawicielem Google'a, no i on właśnie wspominał, że użycie tych fizycznych kluczy umożliwiło im totalne zabezpieczenie przed przejęciem identity.

Dokładnie tak, że jest to w 100% skuteczna metoda. Pawle, jak Cię słucham, to mam też 2 przemyślenia końcowe, że po pierwsze Google i jego podejście Zero Trust oraz Twoje stanowisko wpływają po prostu na spokojny sen całej firmy. I mam nadzieję, że tak będzie przez następne sezony, czego życzę Ramp Network. Paweł Dawidowicz, Head of SRE właśnie w tej firmie, był naszym gościem kolejnego odcinka podcastu FlyTalks. Szalenie dziękuję Ci za rozmowę.

Dzięki również.