Wszyscy mówią o procesach rozwoju i testowania, szkoleniach personelu, zwiększaniu motywacji, ale tych procesów jest mało, gdy minuta przestoju usługi kosztuje fortunę. Co zrobić, gdy przeprowadzasz transakcje finansowe w ramach surowego SLA? Jak zwiększyć niezawodność i odporność twoich systemów, pomijając rozwój i testowanie?
Następna konferencja HighLoad++ odbędzie się 6 i 7 kwietnia 2020 roku w Petersburgu. Szczegóły i bilety można znaleźć pod . 9 listopada, 18:00. HighLoad++ Moskwa 2018, sala „Deli + Kalkuta”. Tezy i .
Evgeny Kuzovlev (dalej – EK): – Przyjaciele, cześć! Nazywam się Kuzovlev Evgeny. Jestem z firmy EcommPay, konkretnie z jej działu IT, działu IT grupy firm. Dzisiaj porozmawiamy o przestojach – o tym, jak ich unikać, jak minimalizować ich skutki, jeśli nie uda się ich uniknąć. Temat jest następujący: „Co robić, gdy minuta przestoju kosztuje 100 000 dolarów”? Jesteśmy, w przeddzień, porównywalni z tymi cyframi.
Czym zajmuje się EcommPay IT?
Kim jesteśmy? Dlaczego tu przed wami stoję? Dlaczego mam prawo wam coś opowiadać? O czym porozmawiamy tutaj bardziej szczegółowo?
Grupa firm EcommPay to międzynarodowy acquirer. Procesujemy płatności na całym świecie – w Rosji, Europie, w Azji Południowo-Wschodniej (All Around the World). Mamy 9 biur, 500 pracowników w sumie, z czego około połowy to specjaliści IT. Wszystko, co robimy, wszystko, na czym zarabiamy pieniądze, zrobiliśmy samodzielnie.
Wszystkie nasze produkty (a mamy ich całkiem sporo – w naszym portfelu dużych produktów IT mamy około 16 różnych komponentów) sami napisaliśmy; sami je piszemy, sami rozwijamy. Obecnie przeprowadzamy około miliona transakcji dziennie (mówiąc „miliony” – to chyba będzie poprawniejsze). Jesteśmy dość młodą firmą – mamy zaledwie sześć lat.
6 lat temu to był taki startup, kiedy przyszli panowie razem z biznesem. Połączyła ich idea (nic więcej poza pomysłem), i ruszyliśmy. Jak każdy startup, biegliśmy szybciej... Dla nas szybkość była ważniejsza niż jakość.
W pewnym momencie się zatrzymaliśmy: uświadomiliśmy sobie, że już nie możemy żyć w takim tempie i przy takim poziomie jakości i musimy przede wszystkim skupić się na jakości. W tym momencie podjęliśmy decyzję o stworzeniu nowej platformy, która będzie odpowiednia, skalowalna i niezawodna. Rozpoczęliśmy prace nad tą platformą (zaczęliśmy inwestować, rozwijać programowanie, testowanie), ale w pewnym momencie zrozumieliśmy, że rozwój i testowanie nie pozwalają nam osiągnąć nowego poziomu jakości usługi.
Tworzycie nowy produkt, wprowadzacie go do produkcji, ale wciąż coś może pójść nie tak. Dzisiaj porozmawiamy o tym, jak osiągnąć nowy, wyższy poziom jakości (jak my to zrobiliśmy, nasze doświadczenia), pomijając programowanie i testowanie; porozmawiamy o tym, co można zrobić w eksploatacji – co eksploatacja może zrobić samodzielnie, co może zaoferować testowaniu, aby wpłynąć na jakość.
Czas przestoju. Przykazania eksploatacji.
Zawsze główny kamień węgielny, o którym dzisiaj będziemy rozmawiać – czas przestoju. Straszne słowo. Jeżeli mamy przestój – wszystko jest źle. Biegniemy, aby to naprawić, admini trzymają serwer – oby nie padł, jak śpiewa się w tej piosence. O tym dzisiaj porozmawiamy.
Kiedy zaczęliśmy zmieniać nasze podejścia, sformułowaliśmy 4 przykazania. Są one przedstawione na slajdach:
Te przykazania są dość proste:
- Szybko zidentyfikować problem.
- Jeszcze szybciej go wyeliminować.
- Pomóc zrozumieć przyczynę (później, dla programistów).
- I zstandaryzować podejścia.
Zwrócę uwagę na punkt nr 2. Wyeliminujemy problem, a nie go rozwiązujemy. Rozwiązanie to sprawa drugorzędna. Dla nas kluczowe jest, aby użytkownik był ochroniony przed tym problemem. On będzie istniał w jakimś izolowanym środowisku, ale to środowisko w żaden sposób nie będzie z nim w kontakcie. Właściwie przeszliśmy przez te cztery grupy problemów (niektóre omówimy dokładniej, inne mniej dokładnie), opowiem, co stosujemy, jakie mamy odpowiednie doświadczenie w rozwiązaniach.
Usuwanie problemów: kiedy się zdarzają i co z nimi zrobić?
Zacznijmy od punktu numer 2 – jak szybko rozwiązać problem? Mamy problem – musimy go rozwiązać. „Co z tym zrobić?” – to kluczowe pytanie. Kiedy zaczęliśmy myśleć o rozwiązaniu problemu, wypracowaliśmy pewne wymagania, które muszą być przestrzegane podczas rozwiązywania problemów.
Aby sformułować te wymagania, zadaliśmy sobie pytanie: „Kiedy pojawiają się u nas problemy”? Okazało się, że problemy występują w czterech przypadkach:
- Awaria sprzętowa.
- Błąd zewnętrznych usług.
- Zmiana wersji oprogramowania (ten słynny deployment).
- Eksplozja wzrostu obciążenia.
O pierwszych dwóch nie będziemy rozmawiać. Awaria sprzętowa jest dość łatwa do rozwiązania: wszystko powinno być zduplikowane. Jeśli chodzi o dyski – powinny być skonfigurowane w RAID, jeśli to serwer – serwer powinien być zduplikowany, jeśli macie infrastrukturę sieciową – powinno być drugie kopiowanie infrastruktury sieciowej, krótko mówiąc, należy to zduplikować. A jeśli coś przestaje działać, przełączacie się na zapasowe zasoby. Tutaj trudno powiedzieć coś więcej.
Drugim przypadkiem jest błąd zewnętrznych usług. Dla większości systemów to w ogóle nie jest problem, ale nie dla nas. Ponieważ przetwarzamy płatności, jesteśmy takim agregatorem, który stoi pomiędzy użytkownikiem (który wprowadza dane swojej karty) a bankami, systemami płatniczymi („Visa”, „MasterCard”, „Mir”) itd. Nasze zewnętrzne usługi (systemy płatnicze, banki) mają skłonność do awarii. Nie możemy na to wpływać, ani wy (jeśli korzystacie z takich usług).
Co wtedy zrobić? Tutaj są dwa warianty. Po pierwsze, jeśli możecie, powinniście w jakiś sposób zduplikować tę usługę. Na przykład, jeżeli możemy, przekierowujemy ruch z jednej usługi na drugą: jeśli przetwarzaliśmy karty przez „Sberbank”, a „Sberbank” ma problemy – przekierowujemy ruch [warunkowo] na „Raiffeisen”. Drugą rzeczą, którą możemy zrobić, to bardzo szybko zauważyć awarię zewnętrznych usług, dlatego porozmawiamy o reakcji na nie w następnej części raportu.
W rzeczywistości z tych czterech możemy konkretnie wpłynąć na zmianę wersji oprogramowania – podjąć działania, które poprawią sytuację w kontekście wdrożeń i gwałtownego wzrostu obciążenia. Właściwie to zrobiliśmy. Tutaj, znowu, mała uwaga…
Z tych czterech problemów kilka można rozwiązać od razu, jeśli masz chmurę. Jeśli korzystasz z chmur „Microsoft Azure”, „Ozon”, używasz naszych usług w chmurze od „Yandexu” lub „Mail.ru”, to przynajmniej problemy sprzętowe stają się ich zmartwieniem i od razu wszystko działa dobrze w kontekście awarii sprzętowych.
Jesteśmy trochę nietypową firmą. Tutaj wszyscy mówią o „Kubernetesie”, chmurach – my nie mamy ani „Kubernetesu”, ani chmur. Mamy za to serwery w wielu centrach danych, i na tym sprzęcie musimy funkcjonować, musimy za to wszystko odpowiadać. Dlatego w tym kontekście będziemy rozmawiać. Cóż, o problemach. Pierwsze dwa pominiemy.
Zmiana wersji oprogramowania. Podstawy
Nasi programiści nie mają dostępu do produkcji. Dlaczego tak? Bo jesteśmy certyfikowani zgodnie z PCI DSS, a nasi programiści po prostu nie mają prawa kręcić się w „produkcji”. Koniec. Całkowicie. Dlatego odpowiedzialność programowania kończy się w momencie, gdy przekazano wersję do wydania.
Nasza druga podstawa, która również nam mocno pomaga – to brak unikalnych, nieudokumentowanych wiedzy. Mam nadzieję, że u Was jest podobnie. Bo jeśli nie – napotkacie problemy. Problemy pojawią się, gdy ta unikalna, nieudokumentowana wiedza nie będzie obecna w odpowiednim czasie w odpowiednim miejscu. Powiedzmy, że jedna osoba wie, jak wdrożyć konkretny komponent – tej osoby nie ma, jest na urlopie lub jest chora – i wszystko, macie problemy.
I trzecia podstawa, do której doszliśmy. Doszliśmy do niej przez ból, krew, łzy – doszliśmy do tego, że każda nasza wersja zawiera błędy, nawet jeśli jest bezbłędna. Zdecydowaliśmy, że gdy coś wdrażamy, kiedy czegoś wprowadzamy na produkcję – nasza wersja ma błędy. Ustaliliśmy wymagania, którym nasz system musi sprostać.
Wymagania dotyczące zmiany wersji oprogramowania
Te wymagania to trzy:
- Musimy szybko cofnąć wdrożenie.
- Musimy zminimalizować wpływ nieudanej aktualizacji.
- I musimy mieć możliwość szybkiego, równoległego wdrożenia.
Dokładnie w takim porządku! Dlaczego? Ponieważ po pierwsze, podczas wdrażania nowej wersji prędkość nie ma znaczenia, ale ważne jest, aby w razie problemów szybko cofnąć zmiany i zminimalizować wpływ. Ale jeśli masz zestaw wersji w produkcji, w których znalazła się błąd (jak grom z jasnego nieba, nie było wdrożenia, ale błąd występuje) – wtedy szybkość kolejnego wdrożenia staje się istotna. Co zrobiliśmy, aby zaspokoić te wymagania? Skorzystaliśmy z takiej metodologii:
Jest dobrze znana, nie wynaleźliśmy jej – to Blue/Green deploy. Co to znaczy? Dla każdej grupy serwerów, na których działają twoje aplikacje, powinna być kopia. Kopia "ciepła": nie ma na niej ruchu, ale w każdej chwili można skierować ruch na tę kopię. Ta kopia zawiera poprzednią wersję. I w momencie wdrożenia, wdrażasz kod na nieaktywną kopię. Następnie skierujesz część ruchu (lub cały) na nową wersję. W ten sposób, aby zmienić przepływ ruchu ze starej wersji na nową, wystarczy wykonać jedno działanie: musisz w upstreamie zmienić balancer, skierować ruch – z jednego upstreamu na drugi. To bardzo wygodne i rozwiązuje problem szybkiej zmiany, szybkiego cofnięcia.Tutaj też rozwiązanie drugiego zagadnienia – minimalizacja: możesz skierować na nową linię, na linię z nowym kodem tylko część swojego ruchu (powiedzmy, 2%). I te 2% – to nie 100%! Jeśli stracisz 100% ruchu przy nieudanym wdrożeniu – to jest straszne, jeśli stracisz 2% ruchu – to jest nieprzyjemne, ale nie straszne. Co więcej, użytkownicy prawdopodobnie nawet tego nie zauważą, ponieważ w niektórych przypadkach (nie we wszystkich) ten sam użytkownik, naciskając F5, trafi na inną, działającą wersję.
Blue/Green deploy. Routing
Nie wszystko jest takie proste z „Blue/Green deployment”... Wszystkie nasze komponenty można podzielić na trzy grupy:
- to frontend (strony płatności, które widzą nasi klienci);
- jądro przetwarzania;
- adapter do współpracy z systemami płatności (banki, „MasterCard”, „Visa”...).
Istnieje tu jednak jeden niuans – chodzi o routing pomiędzy liniami. Jeśli po prostu przełączasz 100% ruchu, nie ma tych problemów. Ale jeśli chcesz przełączyć 2%, zaczynają się pytania: „Jak to zrobić?” Najprostsze, wprost: możesz skonfigurować losowy wybór, Round Robin w nginx, i masz 2% – w lewo, 98% – w prawo. Ale to nie zawsze działa.
Na przykład, użytkownik wchodzi w interakcję z systemem nie za pomocą jednego żądania. To normalne: 2, 3, 4, 5 żądań – twoje systemy mogą być podobne. A jeśli ważne jest, aby wszystkie żądania użytkownika trafiły do tej samej linii, do której trafiło pierwsze żądanie, lub (drugi moment) wszystkie żądania użytkownika trafiły na nową linię po przełączeniu (mógł zacząć wcześniej z systemem, przed przełączeniem) – wtedy to losowe rozdzielenie nie jest odpowiednie. W takim przypadku są następujące opcje:
Pierwsza opcja, najprostsza – na podstawie podstawowych parametrów klienta (IP Hash). Masz IP i dzielisz w prawo-lewo na podstawie adresu IP. Wtedy zadziała drugi opisany przeze mnie przypadek, kiedy nastąpiło wdrożenie, a użytkownik już mógł zaczynać pracę z twoim systemem, i od momentu wdrożenia wszystkie żądania będą kierowane na nową linię (na tę samą, powiedzmy).Jeśli z jakichś powodów to ci nie odpowiada i musisz koniecznie wysyłać żądania do tej samej linii, do której trafiło pierwotne, inicjujące żądanie użytkownika, masz dwie opcje...
Pierwsza opcja: możesz skorzystać z płatnego nginx+. Tam jest mechanizm Sticky sessions, który przy pierwszym żądaniu użytkownika przypisuje mu sesję i wiąże ją z danym apstrym. Wszystkie kolejne żądania użytkownika w ramach okresu życia sesji będą wysyłane do tego samego apstryma, do którego przypisano sesję.To nam nie odpowiadało, ponieważ już mieliśmy zwykłego nginx. Przejście na nginx+ – nie jest to drogie, po prostu było to dla nas trochę bolesne i niewłaściwe. „Sticky sessions” na przykład nie działają dla nas z bardzo prostego powodu, że „Sticky sessions” nie dają możliwości routingu według zasady „Albo-albo”. Można ustawić, że robimy „Sticky sessions” na przykład po adresie IP lub po adresie IP i ciasteczkach lub po parametrach POST, ale zasada „Albo-albo” jest już bardziej skomplikowana.
Dlatego doszliśmy do czwartego rozwiązania. Wzięliśmy nginx w wersji "na sterydach" (to openresty) – to taki sam nginx, który dodatkowo wspiera włączanie skryptów last. Możesz napisać skrypt last, podsunąć go temu "openresty" i ten skrypt będzie wykonywany, gdy przyjdzie zapytanie od użytkownika.
I napisaliśmy, właściwie, taki skrypt, zainstalowaliśmy sobie "openresty" i w tym skrypcie przechodzimy przez 6 różnych parametrów przez konkatenację "Lub". W zależności od dostępności danego parametru, wiemy, czy użytkownik przeszedł na jedną stronę, czy na inną, na jedną linię, czy na drugą.
Blue/Green deploy. Zalety i wady
Oczywiście, można było to zrobić trochę prościej (używać tych samych „Sticky sessions”), ale mamy jeszcze taki niuans, że nie tylko użytkownik wchodzi w interakcję w ramach jednego przetwarzania jednej transakcji… Wchodzą w interakcję z nami także systemy płatności: my, po tym jak przetworzymy transakcję (wysyłając zapytanie do systemu płatności), otrzymujemy callback.
I powiedzmy, że jeśli w naszym konturze możemy przetoczyć adres IP użytkownika we wszystkich zapytaniach i na podstawie adresu IP użytkowników dzielić, to nie możemy powiedzieć tej samej „Vizie”: „Chłopaki, jesteśmy taką retro-firmą, niby międzynarodową (na stronie i w Rosji)… A przekażcie nam, proszę, adres IP użytkownika dodatkowo w dodatkowym polu, wasz standardowy protokół”! Oczywiście, że się na to nie zgodzą.
Dlatego to dla nas nie pasowało – zrobiliśmy openresty. W związku z tym, z routingiem mamy to tak:Błędy/Green deploy ma, odpowiednio, zalety, o których mówiłem, i wady.
Wad są dwie:
- musisz zajmować się routingiem;
- drugą główną wadą są koszty.
Musisz mieć dwa razy więcej serwerów, potrzebujesz dwa razy więcej zasobów operacyjnych, musisz wkładać dwa razy więcej wysiłku w utrzymanie tego całego zoo.
A propos, wśród zalet jest jeszcze jedna rzecz, o której wcześniej nie wspomniałem: masz zapas w przypadku wzrostu obciążenia. Jeśli doświadczasz eksplozji wzrostu obciążenia, na ciebie spadło wielu użytkowników, po prostu włączasz drugi serwer do rozkładu 50 na 50 – i od razu masz x2 serwery w swoim klastrze, dopóki nie rozwiążesz problemu z dostępnością serwerów.
Jak szybko wdrożyć?
Rozmawialiśmy o tym, jak rozwiązać problem minimalizacji i szybkiego wycofania zmian, ale pytanie pozostaje: „Jak szybko wdrożyć?”
Tutaj krótko i wszystko prosto.- Musisz mieć system CD (Continuous Delivery) – bez niego ani rusz. Jeśli masz jeden serwer, możesz wdrożyć ręcznie. Mamy około półtora tysiąca serwerów i ręcznie półtora tysiąca, jak łatwo się domyślić – moglibyśmy zatrudnić zespół wielkości tej sali tylko do wdrożeń.
- Wdrożenie powinno być równoległe. Jeśli masz wdrożenie sekwencyjne, to źle. Jeden serwer – w porządku, półtora tysiąca serwerów będziesz wdrażać przez cały dzień.
- Znowu, dla przyspieszenia, to już prawdopodobnie nie jest konieczne. Podczas wdrażania zwykle wykonywana jest budowa projektu. Masz projekt webowy, jest część frontendowa (robisz webpack, zbierasz npm – coś w tym stylu), i ten proces zasadniczo nie trwa długo – około 5 minut, ale te 5 minut mogą być krytyczne. Dlatego my, na przykład, tak nie robimy: te 5 minut usunęliśmy, wdrażamy artefakty.
Co to jest artefakt? Artefakt to zbudowana wersja, w której wykonano już wszystkie etapy budowy. Ten artefakt przechowujemy w magazynie artefaktów. W swoim czasie korzystaliśmy z dwóch takich magazynów – to był Nexus i teraz jFrog Artifactory. „Nexus” początkowo używaliśmy, ponieważ zaczęliśmy korzystać z tego podejścia w aplikacjach Java (doskonale się do tego nadawał). Potem dodaliśmy do niego część aplikacji napisanych w PHP; „Nexus” już nie nadawał się, więc wybraliśmy jFrog Artifactory, który potrafi zarządzać praktycznie wszystkim. Doszliśmy nawet do tego, że w tym magazynie artefaktów przechowujemy własne pakiety binarne, które tworzymy dla serwerów.
Eksplozja wzrostu obciążenia
Rozmawialiśmy o zmianie wersji oprogramowania. Następne, co mamy, to eksplozja wzrostu obciążenia. Tutaj myślę, że pod eksplozją wzrostu obciążenia rozumiem nieco błędną rzecz…
Stworzyliśmy nowy system – jest on zorientowany na usługi, nowoczesny i piękny, wszędzie są pracownicy, wszędzie kolejki, wszędzie asynchroniczność. W takich systemach dane mogą podążać różnymi ścieżkami. Do pierwszej transakcji mogą być zaangażowani 1., 3. i 10. pracownik, do drugiej transakcji – 2., 4. i 5. I dzisiaj, powiedzmy, rano mamy strumień danych, który angażuje pierwsze trzy pracowników, a wieczorem nagle się zmienia i angażuje inne trzy pracowników.
I tutaj wychodzi na to, że musisz w jakiś sposób skalować pracowników, musisz jakoś skalować swoje usługi, ale przy tym nie dopuścić do nadmiaru zasobów.
Określiliśmy dla siebie wymagania. Te wymagania są dosyć proste: aby była tam odkrywalność usług, parametryzacja – wszystko standardowe do budowy takich skalowalnych systemów, poza jednym punktem – amortyzacją zasobów. Powiedzieliśmy, że nie jesteśmy gotowi do amortyzacji zasobów, aby serwery grzały powietrze. Wzięliśmy «Consul», wzięliśmy «Nomad», który zarządza naszymi pracownikami.Dlaczego to dla nas problem? Cofnijmy się na chwilę. Za nami stoi teraz około 70 systemów płatności. Rano ruch przechodzi przez «Sberbank», potem «Sberbank» pada, na przykład, i przełączamy go na inny system płatności. Mieliśmy 100 pracowników do «Sberbanku», a po tym musimy nagle podnieść 100 pracowników dla innego systemu płatności. I to wszystko powinno się odbywać bez udziału człowieka. Bo jeśli jest udział człowieka – inżynier musi siedzieć 24/7, który tylko tym się zajmuje, bo takie awarie, gdy 70 systemów jest za tobą, zdarzają się regularnie.
Dlatego przyjrzeliśmy się «Nomad», który ma otwarty adres IP i napisaliśmy naszą rzecz Scale-Nomad – ScaleNo, która robi mniej więcej to: śledzi wzrost kolejki i zmniejsza lub zwiększa liczbę pracowników w zależności od dynamiki zmiany kolejki. Gdy to zrobiliśmy, pomyśleliśmy: «Może otworzymy to na licencji open source?» Potem spojrzeliśmy na to – jest proste jak dwa grosze.
Do tej pory nie open-source'owaliśmy, ale jeśli po prezentacji, po uświadomieniu sobie, że potrzebujesz takiego narzędzia, zgłosi się przynajmniej 3-5 osób – proszę cię, napisz do mnie. Jeśli zbierze się chociaż 3-5 osób – otworzymy to na licencji open source.
Jak to działa? Zobaczmy! Na wstępie: po lewej stronie znajduje się kawałek naszego monitorowania: to jedna linia, na górze – czas przetwarzania zdarzeń, w środku – liczba transakcji, na dole – liczba pracowników.Jeśli spojrzymy, na tym obrazku wystąpiła awaria. Na górnym wykresie jedna z linii wystrzeliła w górę po 45 sekundach – jedna z systemów płatności przestała działać. Natychmiast zarejestrowano ruch przez 2 minuty i nastąpił wzrost kolejki w innym systemie płatności, gdzie nie było pracowników (nie wykorzystaliśmy zasobów – przeciwnie, wykorzystaliśmy zasoby prawidłowo). Nie chcieliśmy przeciążać – było minimalne obciążenie, około 5-10 pracowników, ale nie mogli sobie z tym poradzić.
Na ostatnim wykresie widać "garb", który pokazuje, że "Skaleno" podniosło tę liczbę dwukrotnie. A potem, gdy wykres lekko opadł, trochę ją zmniejszyło – liczba pracowników została zmieniona automatycznie. Tak to działa. Porozmawialiśmy o punkcie nr 2 – "Jak szybko pozbyć się przyczyn".
Monitorowanie. Jak szybko zidentyfikować problem?
Teraz pierwszy punkt – "Jak szybko zidentyfikować problem?" Monitorowanie! Musimy szybko zrozumieć pewne rzeczy. Jakie rzeczy musimy szybko zrozumieć?
Trzy rzeczy!- Musimy szybko rozumieć i rozpoznać działanie naszych własnych zasobów.
- Musimy szybko wykrywać awarie, monitorować działanie systemów, które są dla nas zewnętrzne.
- Trzeci punkt – wykrywanie błędów logicznych. To wtedy system działa, a wszystkie wskaźniki są w porządku, ale coś jest nie tak.
Tutaj pewnie nie powiem nic szczególnie nowego. Będę kapitanem Oczywistości. Szukaliśmy tego, co jest dostępne na rynku. Stworzyliśmy "wesoły zoo". Takie zoo mamy teraz:
Używamy "Zabbiksa" do monitorowania "sprzętu", do monitorowania kluczowych wskaźników serwerów. "Okmeter" stosujemy do baz danych. "Grafana" i "Prometeusz" używamy do wszystkich innych wskaźników, które nie pasowały do dwóch pierwszych, przy czym część – z "Grafaną" i "Prometeuszem", część – "Grafana" z "Influxem" i Telegrafem.Rok temu chcieliśmy użyć New Relic. To świetne narzędzie, potrafi wszystko. Ale im więcej potrafi, tym droższe jest. Kiedy zwiększyliśmy liczbę serwerów do 1500, przyszedł do nas przedstawiciel i powiedział: „Zawrzyjmy umowę na następny rok”. Spojrzeliśmy na cenę i stwierdziliśmy, że tego nie zrobimy. Teraz rezygnujemy z New Relica, mamy około 15 serwerów monitorowanych przez New Relic. Cena okazała się zupełnie szalona.
Mamy jedną funkcję, którą zrealizowaliśmy sami – to Debugger. Najpierw nazwaliśmy go „Bagger”, ale potem odwiedził nas nauczyciel angielskiego, mocno się śmiał i zmieniliśmy nazwę na „Debugger”. Co to jest? To narzędzie, które w 15-30 sekund na każdym elemencie, jak „czarna skrzynka” systemu, uruchamia testy ogólnej funkcjonalności komponentu.
Na przykład, jeśli to zewnętrzna strona (strona płatności) – otwiera ją i sprawdza, jak powinna wyglądać. Jeśli to przetwarzanie, wysyła testową „transakcję” – sprawdza, czy ta „transakcja” dotarła. Jeśli chodzi o połączenie z systemami płatności – odpowiednio wysyłamy testowe zapytanie, gdzie możemy, i patrzymy, czy wszystko jest w porządku.
Jakie wskaźniki są ważne dla monitorowania?
Co monitorujemy głównie? Jakie wskaźniki są dla nas ważne?
- Czas odpowiedzi / RPS na frontach – to bardzo ważny wskaźnik. Od razu wskazuje, że coś jest nie tak.
- Liczba przetworzonych wiadomości we wszystkich kolejkach.
- Liczba pracowników.
- Podstawowe metryki poprawności.
Ostatni punkt – metryka „biznesowa”. Jeśli chcesz monitorować to samo, musisz określić jedną lub dwie metryki, które są dla ciebie kluczowe. Nasza taka metryka – to przepustowość (to stosunek liczby udanych transakcji do ogólnego strumienia transakcji). Jeśli w niej coś zmienia się w interwale 5-10-15 minut – oznacza, że mamy problemy (jeśli zmiana jest drastyczna).
Jak to u nas wygląda – przykład jednego z naszych paneli:
Po lewej stronie znajdują się 6 wykresów, które pokazują odpowiednio liczbę pracowników i liczbę wiadomości w kolejkach. Po prawej stronie znajdują się RPS, RTS. Na dole znajduje się ta konkretna metryka 'biznesowa'. Na 'biznesowej' metryce od razu widać, że coś poszło nie tak na dwóch średnich wykresach... To akurat wskazuje na spadek kolejnego systemu, który stoi za nami.Drugą rzeczą, którą musieliśmy zrobić, było śledzenie awarii zewnętrznych systemów płatności. Użyliśmy OpenTracing – mechanizmu, standardu, paradygmatu, który pozwala na śledzenie rozproszonych systemów; i nieco go zmodyfikowaliśmy. Standardowy paradygmat OpenTracing mówi, że budujemy śledzenie każdego pojedynczego zapytania. To nie było nam potrzebne, więc opakowaliśmy to w łączną, agregacyjną trasę. Stworzyliśmy narzędzie, które pozwala nam monitorować prędkość systemów, które stoją za nami.
Wykres pokazuje, że jeden z systemów płatności zaczął odpowiadać w ciągu 3 sekund – pojawiły się u nas problemy. Przy tym ta rzecz zareaguje, gdy problemy się zaczęły, w interwale 20-30 sekund.Trzecia klasa błędów monitorowania, które istnieją, to monitorowanie logiczne.
Szczerze mówiąc, nie wiedziałem, co narysować na tym slajdzie, ponieważ długo szukaliśmy na rynku czegoś, co by nam odpowiadało. Nic nie znaleźliśmy, więc musieliśmy to zrobić sami.
Co rozumiem przez monitorowanie logiczne? Wyobraźcie sobie: robicie sobie system (na przykład klon 'Tindera'); zrobiliście go, uruchomiliście. Udzielający sobie uwagi menedżer, Wania Pupkin, zainstalował go na swoim telefonie, widzi tam dziewczynę, lajkuje ją… a lajka otrzymuje nie dziewczyna – lajk trafia do ochroniarza Michaiła z tego samego centrum biznesowego. Menedżer schodzi na dół, a potem się zastanawia: 'Dlaczego ten ochroniarz Michaił tak przyjemnie się do niego uśmiecha?'W takich sytuacjach… Dla nas ta sytuacja brzmi trochę inaczej, ponieważ (jak pisałem) to jest utrata reputacji, która pośrednio prowadzi do strat finansowych. Mamy odwrotną sytuację: możemy ponieść bezpośrednie straty finansowe – na przykład, jeśli przeprowadziliśmy transakcję uznaną za udaną, a okazała się nieudana (lub odwrotnie). Musieliśmy stworzyć własne narzędzie, które śledzi na podstawie wskaźników biznesowych liczbę udanych transakcji w dynamice w określonym okresie. Nic nie znaleźliśmy na rynku! To właśnie tę myśl chciałem przekazać. Na rynku nie ma nic do rozwiązania tego typu problemów.
To było w kontekście tego, jak szybko zauważyć problem.
Jak określić przyczyny wdrożenia
Trzecia grupa zadań, które rozwiązujemy, to po tym, jak zidentyfikowaliśmy problem, po tym, jak się go pozbyliśmy, dobrze byłoby zrozumieć przyczynę dla rozwoju, dla testowania i coś z tym zrobić. Odpowiednio, musimy prowadzić badania, musimy przeanalizować logi.
Jeśli mówimy o logach (główna przyczyna - logi), główna część logów znajduje się u nas w ELK Stack – prawie wszyscy tak mają. Ktoś może nie mieć w ELK, ale jeśli zapisujesz logi w gigabajtach, to prędzej czy później dojdziesz do ELK. My zapisujemy je w terabajtach.
Tutaj jest problem. Naprawiliśmy błąd dla użytkownika, zaczęliśmy kopać, co się wydarzyło, weszliśmy do 'Kibany', wprowadziliśmy tam ID transakcji i otrzymaliśmy taki długi raport (pokazuje dużo). I w tym raporcie nic nie jest jasne. Dlaczego? Ponieważ nie wiadomo, która część odnosi się do którego workera, która część odnosi się do którego komponentu. I w tej chwili zrozumieliśmy, że potrzebujemy śledzenia – tego samego OpenTracing, o którym mówiłem.Pomyśleliśmy o tym rok temu, zwróciliśmy swoją uwagę w stronę rynku i tam okazały się dwa narzędzia – to 'Zipkin' i 'Jaeger'. 'Jaeger' to w zasadzie ideologiczny następca, ideologiczne przedłużenie 'Zipkina'. W 'Zipkinie' wszystko jest dobre, poza tym, że nie potrafi agregować, nie potrafi włączać logów do śledzenia, tylko śledzenie czasowe. A 'Jaeger' to wspierał.
Zobaczyliśmy na «Egerze»: można instrumentować aplikacje, można pisać w Api (standard Api dla PHP w tamtym czasie, prawda, nie był zatwierdzony – to było rok temu, a teraz już jest zatwierdzony), w absolutnie nie było klienta. „OK”, pomyśleliśmy, i napisaliśmy własnego klienta. Co nam z tego wyszło? Oto mniej więcej tak to wygląda:
W «Egerze» na każdą wiadomość tworzone są spany. To znaczy, kiedy użytkownik otwiera system, widzi jeden lub dwa bloki na każdy przychodzący request (1-2-3 – ile było przychodzących requestów od użytkownika, tyle bloków). Aby użytkownikom było łatwiej, do logów i czasowej analizy dodaliśmy tagi. W przypadku błędu nasza aplikacja oznaczy log odpowiednim tagiem Error. Można odfiltrować po tagu Error i wyświetlą się tylko spany, które zawierają ten blok z błędem. Oto jak to wygląda, jeśli rozwinęlibyśmy span:
Wewnątrz spana jest zbiór śladów. W tym przypadku są to trzy testowe ślady, a trzeci ślad mówi nam, że wystąpił błąd. Przy tym widzimy tutaj również czasową analizę: mamy na górze – oś czasu, na której widzimy, w którym przedziale czasowym nasz log został zapisany.Odpowiednio, zadziałało świetnie. Napisaliśmy własne rozszerzenie i udostępniliśmy je jako open source. Jeśli chcesz pracować z analizą czasową, jeśli chcesz pracować z «Egerem» w języku PHP – tu jest nasze rozszerzenie, zapraszamy do użycia, jak się mówi:
Nasze rozszerzenie to klient do pracy z OpenTracing Api, zrobione jako php-extension, czyli musisz je zbudować i umieścić w systemie. Rok temu nie było nic innego. Teraz pojawiły się inne klienci, które są komponentami. Tutaj sprawa należy do ciebie: albo pobierasz komponenty za pomocą composera, albo korzystasz z rozszerzenia, wybór należy do ciebie.Standardy korporacyjne
Porozmawialiśmy o trzech przykazaniach. Czwarte przykazanie – to standaryzować podejścia. O co w tym chodzi? To mniej więcej o tym:
Dlaczego tutaj jest słowo „korporacyjne”? Nie dlatego, że jesteśmy dużą lub biurokratyczną firmą, nie! Słowo „korporacyjne” chciałem użyć w kontekście tego, że każda firma, każdy produkt powinien mieć swoje standardy, a ty również. Jakie standardy mamy my?- Mamy regulamin wdrożeń. Bez niego nigdzie się nie posuwamy, nie możemy. Wdrożenia odbywają się u nas około 60 razy w tygodniu, co oznacza, że praktycznie wciąż przeprowadzamy wdrożenia. Mamy w regulaminie zakaz wdrożeń w piątek – zasadniczo nie wdrażamy w ten dzień.
- Dokumentacja jest u nas obowiązkowa. Żaden nowy komponent nie trafia do produkcji, jeśli nie ma na niego dokumentacji, nawet jeśli pochodzi z pracy naszych inżynierów RnD. Wymagamy od nich instrukcji dotyczącej wdrożenia, mapy monitorowania oraz ogólnego opisu (tak, jak programiści potrafią napisać) tego, jak dany komponent działa i jak go rozwiązywać.
- Rozwiązujemy nie przyczynę problemu, a sam problem – o czym już mówiłem. Ważne jest dla nas, aby chronić użytkownika przed problemami.
- Mamy dopuszczenia. Na przykład, nie uważamy za przestój, jeśli przez dwie minuty straciliśmy 2% ruchu. To zasadniczo nie trafia do naszej statystyki. Jeśli straty są większe w proporcjach procentowych lub czasowych, już to uwzględniamy.
- I zawsze piszemy post mortemy. Cokolwiek się u nas wydarzy, każda sytuacja, w której coś nie działa zgodnie z planem w produkcji, zostanie odzwierciedlona w post mortem. Post mortem to dokument, w którym opisujesz, co się wydarzyło, szczegółowy harmonogram, co zrobiłeś w celu naprawy i (to jest obowiązkowy blok!) co zrobisz, aby uniknąć tego w przyszłości. To jest niezbędne do analizy.
Co uznajemy za przestój?
Do czego to wszystko doprowadziło?Doprowadziło to do tego, że (mieliśmy pewne problemy ze stabilnością, co nie odpowiadało ani klientom, ani nam) w ciągu ostatnich 6 miesięcy nasz wskaźnik stabilności wyniósł 99,97. Można powiedzieć, że to niewiele. Tak, mamy do czego dążyć. Z tego wskaźnika, mniej więcej połowa to stabilność, która jest w zasadzie nie nasza, a naszego zapory aplikacji internetowej, która przed nami stoi i jest używana jako usługa, ale dla klientów to bez znaczenia.
Nauczylibyśmy się spać po nocach. W końcu! Pół roku temu nie potrafiliśmy. I na tej nuty, z naszego podsumowania chciałbym dodać jedną uwagę. Wczoraj wieczorem odbył się wspaniały wykład na temat systemu zarządzania reaktorem jądrowym. Jeśli słyszą mnie ludzie, którzy pisali ten system – proszę, zapomnijcie o tym, co mówiłem o „2% – to nie przestój”. Dla was 2% to przestój, nawet jeśli na dwie minuty!
To wszystko! Wasze pytania.
O load balancerach i migracji z bazy danych
Pytanie z publiczności (dalej – P): – Dobry wieczór. Bardzo dziękuję za ten administracyjny wykład! Pytanie krótkie, na temat waszych load balancerów. Wspomnieliście, że macie WAF, więc jak rozumiem, jako load balancer używacie jakiegoś zewnętrznego…
EK: – Nie, jako load balancer używamy naszych własnych usług. W tym przypadku WAF jest dla nas wyłącznie narzędziem ochrony przed DDoS.
P: – Można powiedzieć kilka słów o load balancerach?
EK: – Jak już mówiłem, to grupa serwerów w openresty. Mamy obecnie 5 grup rezerwowych, które odpowiadają wyłącznie… to znaczy serwer, na którym stoi wyłącznie openresty, tylko przekazuje ruch. Dla zrozumienia, ile utrzymujemy: nasz standardowy przepływ ruchu to kilka setek megabitów. Radzą sobie dobrze, nawet nie mają z tym problemu.
P: – Też proste pytanie. Istnieje wdrożenie Blue/Green. A co robicie, na przykład, z migracjami z bazy danych?
EK: – Dobre pytanie! Zobaczcie, w wdrożeniu Blue/Green mamy osobne kolejki dla każdej linii. To znaczy, jeśli mówimy o kolejkach zdarzeń, które są przekazywane od jednego worker’a do drugiego, są osobne kolejki dla niebieskiej i zielonej linii. Jeśli mówimy o samej bazie danych, to celowo ją zmniejszyliśmy, jak mogliśmy, przenieśliśmy prawie wszystko do kolejek, w bazie danych przechowujemy tylko stos transakcji. I stos transakcji mamy wspólny dla wszystkich linii. W kontekście bazy danych: nie dzielimy jej na niebieską i zieloną, ponieważ oba warianty kodu muszą wiedzieć, co dzieje się z transakcją.
Przyjaciele, mam jeszcze taki mały prezent, aby Was zmotywować – książka. Muszę ją wręczyć za najlepsze pytanie.
P: – Dzień dobry. Dziękuję za wykład. Pytanie takie. Monitorujecie płatności, monitorujecie usługi, z którymi się komunikujecie… Ale jak monitorujecie to, że ktoś w jakiś sposób przeszedł na Waszą stronę płatności, dokonał płatności, a projekt zaksięgował mu pieniądze? To znaczy, jak monitorujecie, że merchant jest dostępny i przyjął Wasz callback?
EK: – «Merchant» w naszym przypadku jest dokładnie takim samym zewnętrznym serwisem, jak system płatności. Monitorujemy czas odpowiedzi «merchanta».
O szyfrowaniu bazy danych
P: – Witaj. Mam małe pytanie. Czy mają Państwo wrażliwe dane zgodne z PCI DSS? Chciałem się dowiedzieć, jak przechowujecie PAN-y w kolejce, które musicie przetwarzać? Czy używacie jakiegoś szyfrowania? A stąd wynika drugie pytanie: zgodnie z PCI DSS konieczne jest okresowe ponowne szyfrowanie bazy w przypadku zmian (np. zwolnienie administratorów) – jak w takim przypadku odbywa się to z dostępnością?
EK: – Doskonałe pytanie! Przede wszystkim, nie przechowujemy PAN-ów w kolejkach. Nie mamy prawa przechowywać PAN-ów w otwartej formie, w zasadzie, dlatego korzystamy z specjalnej usługi (nazywamy ją "Keydemon") – to usługa, która robi tylko jedno: przyjmuje wiadomość jako wejście i zwraca wiadomość zaszyfrowaną. I to zaszyfrowane wiadomości przechowujemy. W związku z tym długość klucza wynosi pod 1 KB, aby było to naprawdę poważne i niezawodne.P: – Czy teraz już potrzebne są 2 kilobajty?
EK: – Wydaje mi się, że jeszcze wczoraj było 256… Gdzie tu jeszcze?!
W związku z tym to pierwsza rzecz. A po drugie, istniejące rozwiązanie obsługuje procedurę ponownego szyfrowania – są tam dwie pary "keków" (kluczy), które dostarczają „dek”, które szyfrują (key – to klucze, dek – to pochodne kluczy, które szyfrują). I w przypadku inicjacji procedury (odbywa się to regularnie, co 3 miesiące lub ± jakieś) ładujemy nową parę "keków", a nasze dane są ponownie szyfrowane. Mamy osobne usługi, które wyciągają wszystkie dane, szyfrują je na nowo; do danych przypisany jest identyfikator klucza, którym zostały zaszyfrowane. W związku z tym, jak tylko dane zostaną zaszyfrowane nowymi kluczami, usuwamy stare klucze.
Czasami płatności trzeba przeprowadzać ręcznie…
P: – Czyli jeśli przeszła reklamacja jakiejś operacji, to odszyfrowujecie ją starym kluczem?
EK: – Tak.
P: – Jeszcze jedno małe pytanie. Kiedy występuje jakiś błąd, awaria, incydent, to konieczne jest ręczne przetwarzanie transakcji. Takie sytuacje się zdarzają.
EK: – Tak, zdarzają się.
P: – Skąd bierzecie te dane? Czy sami ręcznie wchodzicie do tego magazynu?
EK: – Nie, to oczywiste – mamy pewny system back-office, który zawiera interfejs dla naszego wsparcia. Jeśli nie wiemy, w jakim statusie jest transakcja (na przykład, gdy system płatności nie odpowiedział z powodu timeoutu) – nie mamy żadnej wiedzy, to znaczy, że ostateczny status przypisujemy dopiero w momencie, gdy mamy pełną pewność. W takim przypadku wrzucamy transakcję do specjalnego statusu do ręcznej obróbki. Rano, następnego dnia, jak tylko wsparcie dostaje informację, że w systemie płatności zostały takie transakcje, ręcznie je przetwarzają w tym interfejsie.
P: – Mam parę pytań. Jednym z nich jest kontynuacja strefy PCI DSS: jak wyprowadzacie ich logi? Pytanie wynika z tego, że programista mógł wpisać do logów cokolwiek! Drugie pytanie: jak wypuszczacie hotfixy? Ręcznie w bazie – to jedna opcja, ale mogą być też darmowe hotfixy – jaka tam jest procedura? I trzecie pytanie, chyba związane z RTO, RPO. Mieliście dostępność na poziomie 99,97, niemal cztery dziewiątki, ale rozumiem, że macie i drugi, i trzeci, i piąty centrum danych... Jak zajmujecie się ich synchronizacją, replikacją i wszystkim innym?EK: – Zacznijmy od pierwszego. Czy pierwsze pytanie dotyczyło logów? U nas, gdy pisane są logi, działa warstwa, która maskuje wszystkie wrażliwe dane. Sprawdza ona według maski i dodatkowych pól. W związku z tym nasze logi wychodzą już z zamaskowanymi danymi oraz zgodnie z PCI DSS. To jedno z regularnych zadań przypisanych działowi testów. Muszą oni sprawdzać każde zadanie, w tym logi, które piszą, i to – jedno z regularnych zadań podczas przeglądu kodu, aby kontrolować, czy programista czegoś nie zapisał. Następna kontrola odbywa się regularnie przez dział bezpieczeństwa informacji mniej więcej raz w tygodniu: wybiórczo zbierane są logi z ostatniego dnia i są one analizowane przez specjalny skaner-analityk na serwerach testowych, aby to wszystko sprawdzić.
O hot-fixach. To jest uwzględnione w naszym regulaminie wdrożeń. Mamy osobny punkt dotyczący hot-fixów. Uważamy, że wdrażamy hot-fixy 24 godziny na dobę, gdy jest to potrzebne. Gdy tylko wersja jest gotowa, gdy tylko przeszła testy, gdy mamy artefakt – czuwający administrator systemowy zostaje powiadomiony przez call center wsparcia i wdraża to w momencie, gdy jest to konieczne.O 'czterech dziewiątkach'. Liczba, którą teraz mamy, została rzeczywiście osiągnięta, a my dążyliśmy do niej jeszcze w jednym centrum danych. Obecnie mamy drugie centrum danych i zaczynamy routować między nimi, a kwestia replikacji między centrami danych to naprawdę złożony temat. Próbowaliśmy to rozwiązać różnymi metodami: używaliśmy TaranTula – nie udało się, od razu mówię. Dlatego doszliśmy do wniosku, że zamawiamy 'Senser' ręcznie. Nasza aplikacja w zasadzie działa w trybie asynchronicznej synchronizacji 'zmiana – zakończone' między centrami danych.
P: – Jeśli macie drugie centrum, to dlaczego nie pojawiło się trzecie? Bo Split-brain nikt jeszcze…
EK: – A my nie mamy 'Split-brain'. Ponieważ każda aplikacja działa w trybie multimaster, nie ma dla nas znaczenia, do którego centrum przyszło zapytanie. Jesteśmy gotowi na to, że jeśli jedno centrum danych padnie (na to się przygotowujemy) i w trakcie zapytania użytkownika przeskoczy na drugie centrum, naprawdę jesteśmy gotowi stracić tego użytkownika; ale będą to jednostki, absolutne jednostki.
P: – Dobry wieczór. Dziękuję za prezentację. Mówiłeś o swoim debugerze, który w produkcji uruchamia testowe transakcje. A opowiedz mi o testowych transakcjach! Jak głęboko to sięga?
EK: – Przechodzi pełny cykl całego komponentu. Dla komponentu nie ma różnicy między testową a rzeczywistą transakcją. A z punktu widzenia logiki to po prostu osobny projekt w systemie, w którym uruchamiane są tylko testowe transakcje.
P: – A gdzie ją odcinacie? Oto Core wysyła…
EK: – My za 'Korem' w tym przypadku dla testowych transakcji… Mamy pojęcie routingu: 'Core' wie, do którego systemu płatności należy wysłać – wysyłamy do fikcyjnego systemu płatności, który po prostu zwraca http i to wszystko.
P: – Proszę powiedzieć, czy wasza aplikacja jest napisana jako jeden ogromny monolit, czy może podzieliliście ją na jakieś usługi lub nawet mikroserwisy?
EK: – Oczywiście, nie mamy monolitu, mamy aplikację zorientowaną na usługi. Mamy żart, że nasze usługi są z monolitów – są naprawdę wystarczająco duże. Nie można ich nazwać mikroserwisami, ale to właśnie usługi, wewnątrz których działają pracownicy rozproszonych maszyn.
Jeśli usługa na serwerze zostanie skompromitowana…
P: – W takim razie mam kolejne pytanie. Nawet gdyby to był monolit, nadal powiedziałeś, że macie wiele tych serwerów instant, które w zasadzie przetwarzają dane, więc pytanie brzmi: "W przypadku skompromitowania jednego z serwerów instant lub aplikacji, czy jest tam jakiś system kontroli dostępu? Kto co może robić? Do kogo się zwracać, po jakie dane?"
EK: – Tak, zdecydowanie. Wymagania dotyczące bezpieczeństwa są dość poważne. Po pierwsze, mamy otwarte ruchy danych, a porty są tylko te, przez które z góry zakładamy ruch danych. Jeśli komponent komunikuje się z bazą danych (na przykład z 'MySQL') przez port 5-4-3-2, to tylko port 5-4-3-2 będzie otwarty, a inne porty, inne kierunki ruchu nie będą dostępne. Poza tym trzeba zrozumieć, że w produkcji istnieje około 10 różnych obszarów bezpieczeństwa. I nawet jeśli aplikacja została w jakiś sposób skompromitowana, broń Boże, to napastnik nie będzie miał dostępu do konsoli zarządzania serwerem, ponieważ to jest inna strefa sieciowa bezpieczeństwa.P: – A mnie w tym kontekście bardziej interesuje kwestia, że macie pewne kontrakty z usługami – co mogą robić, przez jakie „akcje” mogą się ze sobą łączyć… W normalnym przebiegu pewne określone usługi żądają jakiegoś ciągu, listy „akcji” od innych. Do innych w normalnej sytuacji się nie zwracają, a ich zakresy odpowiedzialności są różne. Jeśli jednak jedna z nich zostanie skompromitowana, czy będzie mogła wykonać „akcje” tej usługi…?
EK: – Rozumiem. Jeśli w normalnej sytuacji z innym serwerem komunikacja była dozwolona, to – tak. Zgodnie z umową SLA nie monitorujemy, że masz prawo jedynie do pierwszych 3 „akcji”, a 4 „akcja” nie jest dozwolona. To byłoby dla nas prawdopodobnie zbędne, ponieważ w ogóle posiadamy 4-poziomowy system ochrony dla konturów. Wolimy chronić się poprzez kontury, a nie na poziomie wnętrzności.
Jak działają Visa, MasterCard i „Sberbank”
P: – Chciałem wyjaśnić kwestię przełączania użytkownika z jednego centrum danych do drugiego. Jak wiem, „Visa” i „MasterCard” działają na binarnym, synchronicznym protokole 8583, są tam miksy. Chciałem zapytać, czy przełączanie dotyczy bezpośrednio „Vizy” i „MasterCard”, czy chodzi o systemy płatnicze, do procesorów?
EK: – To dotyczy miksów. Miksy mamy w jednym centrum danych.
P: – Mówiąc wprost, macie jeden punkt połączenia?
EK: – Dla „Vizy” i „MasterCard” – tak. Po prostu dlatego, że „Visa” i „MasterCard” wymagają poważnych inwestycji w infrastrukturę, aby zawrzeć osobne umowy na uzyskanie drugiej pary miksów, na przykład. Są zarezerwowane w ramach jednego centrum danych, ale jeśli, nie daj Boże, padnie nam centrum danych, w którym są miksy do podłączenia do „Vizy” i „MasterCard”, to połączenie z „Viza” i „MasterCard” zostanie utracone…
P: – Jak mogą być zarezerwowane? Wiem, że „Visa” zezwala tylko na jedno połączenie w zasadzie!
EK: – Oni dostarczają sprzęt. W każdym razie otrzymaliśmy sprzęt, który jest wewnętrznie mocno zarezerwowany.
P: – Czyli serwer od ich Connects Orange?..
EK: – Tak.
P: – A co w tym przypadku: jeśli wasze centrum danych znika, jak dalej korzystać? Czy po prostu ruch się zatrzymuje?
EK: – Nie. W takim przypadku po prostu przełączymy ruch na inny kanał, który, oczywiście, będzie dla nas droższy, droższy dla klientów. Ale ruch nie będzie szedł przez nasze bezpośrednie połączenie z „Viza”, „MasterCard”, a przez tak zwanego „Sberbank” (bardzo uproszczone).
Przepraszam, jeśli uraziłem pracowników „Sberbanku”. Ale według naszych statystyk, z rosyjskich banków „Sberbank” pada najczęściej. Nie mija miesiąc, aby „Sberbank” nie miał jakiegoś problemu.
Trochę reklamy 🙂
Dziękujemy, że jesteś z nami. Podobają Ci się nasze artykuły? Chcesz zobaczyć więcej interesujących materiałów? Wspieraj nas składając zamówienie lub polecając nas znajomym, , unikatowy odpowiednik serwerów entry-level, który został stworzony przez nas dla Ciebie: (dostępne opcje z RAID1 i RAID10, do 24 rdzeni i do 40GB DDR4).
Dell R730xd dwa razy tańszy w centrum danych Equinix Tier IV w Amsterdamie? Tylko u nas w Holandii! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — od 99 dolarów! Czytaj o tym
Źródło: habr.com
