Wszyscy mówią o procesach rozwoju i testowania, szkoleniu personelu, zwiększaniu motywacji, ale te procesy nie wystarczą, gdy minuta przestoju usługi kosztuje ogromne pieniądze. Co zrobić, gdy przeprowadzasz transakcje finansowe w ramach ścisłego SLA? Jak zwiększyć niezawodność i odporność na awarie swoich systemów, eliminując rozwój i testowanie?
Najbliższa konferencja HighLoad++ odbędzie się 6 i 7 kwietnia 2020 w St. Petersburgu. Szczegóły i bilety na . 9 listopada, 18:00. HighLoad++ Moskwa 2018, Delhi + hala Kalkuta. Tezy i .
Evgeniy Kuzovlev (dalej – KE): - Przyjaciele, cześć! Nazywam się Kuzovlev Evgeniy. Jestem z firmy EcommPay, specyficznym działem jest EcommPay IT, dział IT grupy firm. A dzisiaj porozmawiamy o przestojach - o tym, jak ich uniknąć, jak zminimalizować ich skutki, jeśli nie da się ich uniknąć. Temat brzmi następująco: „Co zrobić, gdy minuta przestoju kosztuje 100 000 dolarów”? Patrząc w przyszłość, nasze liczby są porównywalne.
Co robi EcommPay IT?
Kim jesteśmy? Dlaczego stoję tu przed tobą? Dlaczego mam prawo Ci coś tutaj powiedzieć? A o czym będziemy tutaj mówić bardziej szczegółowo?
Grupa spółek EcommPay jest międzynarodowym nabywcą. Obsługujemy płatności na całym świecie - w Rosji, Europie, Azji Południowo-Wschodniej (na całym świecie). Mamy 9 biur, łącznie 500 pracowników, z czego nieco mniej niż połowa to specjaliści IT. Wszystko, co robimy, wszystko, na czym zarabiamy, zrobiliśmy sami.
Wszystkie nasze produkty (a mamy ich całkiem sporo - w naszej linii dużych produktów IT mamy około 16 różnych komponentów) sami napisaliśmy; Sami piszemy, rozwijamy się. I w tej chwili przeprowadzamy około miliona transakcji dziennie (miliony to chyba właściwe określenie). Jesteśmy dość młodą firmą - mamy dopiero około sześciu lat.
6 lat temu to był taki start-up, kiedy do firmy dołączyli chłopcy. Połączyła ich idea (nie było nic poza ideą) i pobiegliśmy. Jak każdy startup, działaliśmy szybciej... Dla nas szybkość była ważniejsza niż jakość.
W pewnym momencie zatrzymaliśmy się: zdaliśmy sobie sprawę, że nie możemy już żyć z taką szybkością i jakością, więc musimy najpierw skupić się na jakości. W tym momencie postanowiliśmy napisać nową platformę, która będzie poprawna, skalowalna i niezawodna. Zaczęli pisać tę platformę (zaczęli inwestować, rozwijać, testować), ale w pewnym momencie zdali sobie sprawę, że rozwój i testowanie nie pozwoliły nam osiągnąć nowego poziomu jakości usług.
Tworzysz nowy produkt, wprowadzasz go do produkcji, a mimo to coś gdzieś pójdzie nie tak. A dzisiaj porozmawiamy o tym, jak osiągnąć nowy poziom jakości (jak tego zrobiliśmy, o naszym doświadczeniu), eliminując rozwój i testowanie; porozmawiamy o tym, co jest dostępne do eksploatacji - jaką operację może wykonać sama, co może zaoferować testom, aby wpłynąć na jakość.
Przestoje. Przykazania działania.
Zawsze głównym kamieniem węgielnym, tak naprawdę dzisiaj będziemy mówić o przestojach. Straszne słowo. Jeśli mamy przestoje, wszystko jest dla nas złe. Biegniemy, żeby go podnieść, admini trzymają serwer - nie daj Boże, żeby nie upadł, jak to mówią w tej piosence. O tym właśnie dzisiaj porozmawiamy.
Kiedy zaczęliśmy zmieniać nasze podejście, sformułowaliśmy 4 przykazania. Mam je zaprezentowane na slajdach:
Przykazania te są dość proste:
- Szybko zidentyfikuj problem.
- Pozbądź się go jeszcze szybciej.
- Pomóż zrozumieć przyczynę (później dla programistów).
- I standaryzować podejścia.
Chciałbym zwrócić Państwa uwagę na punkt nr 2. Pozbywamy się problemu, a nie go rozwiązujemy. Podejmowanie decyzji jest sprawą drugorzędną. Dla nas najważniejsze jest to, że użytkownik jest chroniony przed tym problemem. Będzie istnieć w jakimś izolowanym środowisku, ale to środowisko nie będzie miało z nim żadnego kontaktu. Właściwie omówimy te cztery grupy problemów (niektóre bardziej szczegółowo, niektóre mniej szczegółowo), powiem ci, czego używamy, jakie mamy odpowiednie doświadczenie w rozwiązaniach.
Rozwiązywanie problemów: kiedy się zdarzają i co z nimi zrobić?
Ale zaczniemy nie po kolei, zaczniemy od punktu nr 2 – jak szybko pozbyć się problemu? Wystąpił problem - musimy go naprawić. „Co powinniśmy z tym zrobić?” - główne pytanie. A kiedy zaczęliśmy myśleć o tym, jak rozwiązać problem, opracowaliśmy dla siebie pewne wymagania, jakie musi spełniać rozwiązywanie problemów.
Formułując te wymagania, postanowiliśmy zadać sobie pytanie: „Kiedy mamy problemy”? Jak się okazało, problemy występują w czterech przypadkach:
- Awaria sprzętu.
- Usługi zewnętrzne nie powiodły się.
- Zmiana wersji oprogramowania (to samo wdrożenie).
- Wzrost ładunku wybuchowego.
Nie będziemy rozmawiać o dwóch pierwszych. Awarię sprzętu można rozwiązać po prostu: musisz mieć wszystko zduplikowane. Jeśli są to dyski, dyski muszą być zmontowane w RAID; jeśli jest to serwer, serwer musi zostać zduplikowany; jeśli masz infrastrukturę sieciową, musisz dostarczyć drugą kopię infrastruktury sieciowej, czyli bierzesz ją i zduplikuj to. A jeśli coś zawiedzie, przełączasz na moc rezerwową. Trudno tu powiedzieć coś więcej.
Drugim jest awaria usług zewnętrznych. Dla większości system nie stanowi żadnego problemu, ale dla nas nie. Ponieważ przetwarzamy płatności, jesteśmy agregatorem, który stoi pomiędzy użytkownikiem (który wprowadza dane swojej karty) a bankami, systemami płatności (Visa, MasterCard, Mira itp.). Nasze usługi zewnętrzne (systemy płatności, banki) mają tendencję do zawodzenia. Ani my, ani Ty (jeśli masz takie usługi) nie mamy na to wpływu.
Co wtedy zrobić? Istnieją dwie opcje tutaj. Po pierwsze, jeśli możesz, powinieneś w jakiś sposób zduplikować tę usługę. Na przykład, jeśli możemy, przenosimy ruch z jednej usługi do drugiej: na przykład karty zostały przetworzone przez Sbierbank, Sbierbank ma problemy - przenosimy ruch [warunkowo] do Raiffeisen. Drugą rzeczą, którą możemy zrobić, to bardzo szybko zauważyć awarie usług zewnętrznych, dlatego o szybkości reakcji porozmawiamy w dalszej części raportu.
Tak naprawdę z tych czterech możemy konkretnie wpłynąć na zmianę wersji oprogramowania – podjąć działania, które doprowadzą do poprawy sytuacji w kontekście wdrożeń i w kontekście gwałtownego wzrostu obciążenia. Właściwie to właśnie zrobiliśmy. Tutaj znowu mała uwaga...
Z tych czterech problemów kilka można rozwiązać natychmiast, jeśli masz chmurę. Jeśli jesteś w chmurach Microsoft Azhur, Ozone lub korzystasz z naszych chmur Yandex lub Mail, to przynajmniej awaria sprzętu staje się ich problemem i od razu wszystko staje się dla Ciebie w porządku w kontekście awarii sprzętu.
Jesteśmy firmą nieco nieszablonową. Tutaj wszyscy mówią o „Kubernetach”, o chmurach – nie mamy ani „Kubernetów”, ani chmur. Ale mamy stojaki ze sprzętem w wielu centrach danych i jesteśmy zmuszeni żyć na tym sprzęcie, jesteśmy zmuszeni być za to wszystko odpowiedzialni. Dlatego będziemy rozmawiać w tym kontekście. A więc o problemach. Pierwsze dwa zostały usunięte z nawiasów.
Zmiana wersji oprogramowania. Bazy
Nasi programiści nie mają dostępu do produkcji. Dlaczego? Tyle, że mamy certyfikat PCI DSS, a nasi programiści po prostu nie mają prawa ingerować w „produkt”. To wszystko, kropka. W ogóle. Dlatego odpowiedzialność za rozwój kończy się dokładnie w momencie, gdy programiści przesyłają kompilację do wydania.
Drugą naszą podstawą, która również bardzo nam pomaga, jest brak unikalnej, nieudokumentowanej wiedzy. Mam nadzieję, że u Ciebie będzie tak samo. Ponieważ jeśli tak nie jest, będziesz mieć problemy. Problemy pojawią się, gdy ta wyjątkowa, nieudokumentowana wiedza nie będzie obecna we właściwym czasie i miejscu. Załóżmy, że masz jedną osobę, która wie, jak wdrożyć konkretny komponent – tej osoby nie ma, jest na wakacjach lub jest chora – to wszystko, masz problemy.
I trzecia podstawa, do której doszliśmy. Doszliśmy do tego przez ból, krew, łzy – doszliśmy do wniosku, że każdy nasz build zawiera błędy, nawet jeśli jest bezbłędny. Sami o tym zdecydowaliśmy: kiedy coś wdrażamy, kiedy wprowadzamy coś do produkcji, mamy kompilację zawierającą błędy. Sformułowaliśmy wymagania, które musi spełniać nasz system.
Wymagania dotyczące zmiany wersji oprogramowania
Istnieją trzy wymagania:
- Musimy szybko wycofać wdrożenie.
- Musimy zminimalizować skutki nieudanego wdrożenia.
- Musimy także mieć możliwość szybkiego wdrożenia równoległego.
Dokładnie w tej kolejności! Dlaczego? Ponieważ, po pierwsze, podczas wdrażania nowej wersji nie jest ważna szybkość, ale ważne jest, aby w przypadku, gdy coś pójdzie nie tak, szybko się wycofać i mieć minimalny wpływ. Jeśli jednak masz w produkcji zestaw wersji, dla których okazuje się, że jest błąd (niespodziewanie, nie było wdrożenia, ale jest błąd) – ważna jest dla Ciebie szybkość późniejszego wdrożenia. Co zrobiliśmy, aby sprostać tym żądaniom? Zastosowaliśmy następującą metodologię:
Jest to dość dobrze znane, nigdy tego nie wymyśliliśmy - jest to wdrożenie niebiesko-zielone. Co to jest? Musisz mieć kopię dla każdej grupy serwerów, na których zainstalowane są Twoje aplikacje. Kopia jest „ciepła”: nie ma na niej ruchu, ale w każdej chwili ruch ten może zostać przesłany do tej kopii. Ta kopia zawiera poprzednią wersję. W momencie wdrożenia wdrażasz kod w nieaktywnej kopii. Następnie przełączasz część ruchu (lub całość) na nową wersję. Zatem, aby zmienić przepływ ruchu ze starej wersji na nową, wystarczy wykonać tylko jedną czynność: zmienić balanser na upstream, zmienić kierunek - z jednego upstream na drugi. Jest to bardzo wygodne i rozwiązuje problem szybkiego przełączania i szybkiego cofania.Tutaj rozwiązaniem drugiego pytania jest minimalizacja: możesz wysłać tylko część swojego ruchu na nową linię, na linię z nowym kodem (niech będzie to np. 2%). A te 2% to nie 100%! Jeśli straciłeś 100% ruchu z powodu nieudanego wdrożenia, jest to przerażające; jeśli straciłeś 2% ruchu, jest to nieprzyjemne, ale nie jest przerażające. Co więcej, użytkownicy najprawdopodobniej nawet tego nie zauważą, ponieważ w niektórych przypadkach (nie we wszystkich) ten sam użytkownik, naciskając klawisz F5, zostanie przeniesiony do innej, działającej wersji.
Wdrożenie niebieskiego/zielonego. Rozgromienie
Jednak nie wszystko jest takie proste „Wdrożenie Blue/Green”... Wszystkie nasze komponenty można podzielić na trzy grupy:
- to jest frontend (strony płatności, które widzą nasi klienci);
- rdzeń przetwarzający;
- adapter do współpracy z systemami płatności (banki, MasterCard, Visa...).
I jest tu niuans - niuans leży w prowadzeniu między liniami. Jeśli po prostu przełączysz 100% ruchu, nie będziesz mieć tych problemów. Ale jeśli chcesz zamienić 2%, zaczynasz zadawać pytania: „Jak to zrobić?” Najprostsza rzecz jest prosta: możesz ustawić Round Robin w Nginx przez losowy wybór i masz 2% w lewo, 98% w prawo. Ale to nie zawsze jest odpowiednie.
Przykładowo w naszym przypadku użytkownik wchodzi w interakcję z systemem za pomocą więcej niż jednego żądania. To normalne: 2, 3, 4, 5 żądań - Twoje systemy mogą być takie same. A jeśli zależy Ci na tym, aby wszystkie żądania użytkownika trafiały do tej samej linii, w której przyszło pierwsze żądanie, lub (drugi punkt) wszystkie żądania użytkownika trafiały do nowej linii po przełączniku (mógł zacząć pracować wcześniej z system, przed przełącznikiem), - to ten losowy rozkład nie jest dla Ciebie odpowiedni. Następnie dostępne są następujące opcje:
Pierwsza opcja, najprostsza, opiera się na podstawowych parametrach klienta (IP Hash). Masz adres IP i dzielisz go od prawej do lewej według adresu IP. Wtedy sprawdzi się dla Ciebie drugi przypadek, który opisałem, kiedy nastąpiło wdrożenie, użytkownik mógł już rozpocząć pracę z Twoim systemem i od momentu wdrożenia wszystkie żądania będą kierowane do nowej linii (powiedzmy do tej samej).Jeśli z jakiegoś powodu Ci to nie odpowiada i musisz wysyłać żądania na linię, z której pochodziło początkowe żądanie użytkownika, masz dwie możliwości...
Pierwsza opcja: możesz kupić płatny nginx+. Istnieje mechanizm Sticky Sessions, który na pierwsze żądanie użytkownika przypisuje mu sesję i wiąże ją z jednym lub drugim serwerem nadrzędnym. Wszystkie kolejne żądania użytkowników w trakcie trwania sesji zostaną wysłane do tego samego źródła, w którym sesja została opublikowana.To nam nie odpowiadało, ponieważ mieliśmy już zwykły nginx. Przejście na nginx+ nie oznacza, że jest drogie, po prostu było dla nas nieco bolesne i niezbyt właściwe. Na przykład „Sesje Sticks” nie sprawdziły się w naszym przypadku z prostego powodu: „Sesje Sticks” nie pozwalają na routing w oparciu o opcję „Albo-albo”. Tam możesz określić, co robimy „Sticks Sessions”, na przykład według adresu IP lub adresu IP i plików cookie lub parametru końcowego, ale „albo-albo” jest tam bardziej skomplikowane.
Dlatego doszliśmy do czwartej opcji. Wzięliśmy nginx na sterydy (to jest openresty) - to ten sam nginx, który dodatkowo wspiera włączenie ostatnich skryptów. Możesz napisać ostatni skrypt, dać mu „otwartą przerwę”, a ten ostatni skrypt zostanie wykonany, gdy nadejdzie żądanie użytkownika.
I faktycznie napisaliśmy taki skrypt, ustawiliśmy się na „openresti” i w tym skrypcie sortujemy 6 różnych parametrów poprzez konkatenację „Or”. W zależności od obecności tego czy innego parametru wiemy, że użytkownik wszedł na tę czy inną stronę, w tę czy inną linię.
Wdrożenie niebieskiego/zielonego. Zalety i wady
Oczywiście można było to chyba nieco uprościć (użyj tych samych „Sesji przyklejonych”), ale mamy też taki niuans, że nie tylko użytkownik wchodzi z nami w interakcję w ramach jednego przetwarzania jednej transakcji… Ale systemy płatności również z nami współdziałają: po przetworzeniu transakcji (poprzez wysłanie żądania do systemu płatności) otrzymujemy zwrot pieniędzy.
I powiedzmy, że jeśli w naszym obwodzie możemy przekazywać adres IP użytkownika we wszystkich żądaniach i dzielić użytkowników na podstawie adresu IP, to nie powiemy tej samej „Visy”: „Stary, jesteśmy taką firmą retro, wydaje się, że być międzynarodowym (na stronie internetowej i w Rosji)... Podaj nam adres IP użytkownika w dodatkowym polu, Twój protokół jest ustandaryzowany”! Wiadomo, że się nie zgodzą.
Dlatego u nas to nie zadziałało - zrobiliśmy openresty. Odpowiednio, dzięki routingowi otrzymaliśmy coś takiego:Wdrożenie Blue/Green ma zatem zalety, o których wspomniałem, i wady.
Dwie wady:
- musisz zająć się routingiem;
- drugą główną wadą jest koszt.
Potrzebujesz dwa razy więcej serwerów, potrzebujesz dwa razy więcej zasobów operacyjnych, musisz włożyć dwa razy więcej wysiłku w utrzymanie całego zoo.
Swoją drogą, wśród zalet jest jeszcze jedna rzecz, o której nie wspomniałem wcześniej: masz rezerwę na wypadek wzrostu obciążenia. Jeśli obciążenie rośnie gwałtownie, masz dużą liczbę użytkowników, po prostu dodajesz drugą linię do rozkładu 50 do 50 i od razu masz w klastrze serwery x2, dopóki nie rozwiążesz problemu posiadania większej liczby serwerów.
Jak przeprowadzić szybkie wdrożenie?
Rozmawialiśmy o tym, jak rozwiązać problem minimalizacji i szybkiego wycofywania, ale pozostaje pytanie: „Jak szybko wdrożyć?”
Tutaj jest krótko i prosto.- Musisz mieć system CD (Continious Delivery) – nie możesz bez niego żyć. Jeśli masz jeden serwer, możesz wdrożyć go ręcznie. Mamy oczywiście około półtora tysiąca serwerów i półtora tysiąca uchwytów - możemy umieścić dział wielkości tego pomieszczenia tylko do wdrożenia.
- Wdrożenie musi być równoległe. Jeśli wdrożenie jest sekwencyjne, wszystko jest złe. Jeden serwer to normalna sytuacja, przez cały dzień będziesz wdrażać półtora tysiąca serwerów.
- Ponownie, w przypadku przyspieszenia, prawdopodobnie nie jest to już konieczne. Podczas wdrażania projekt jest zwykle budowany. Masz projekt webowy, jest część front-endowa (robisz tam webpacka, kompilujesz npm - coś w tym stylu), a proces ten w zasadzie jest krótkotrwały - 5 minut, ale te 5 minut może bądź krytyczny. Dlatego na przykład tego nie robimy: usunęliśmy te 5 minut, wdrażamy artefakty.
Co to jest artefakt? Artefakt to złożona konstrukcja, w której wszystkie części zostały już ukończone. Przechowujemy ten artefakt w magazynie artefaktów. Kiedyś korzystaliśmy z dwóch takich magazynów - był to Nexus, a teraz jFrog Artifactory. Początkowo korzystaliśmy z „Nexusa”, ponieważ zaczęliśmy ćwiczyć to podejście w aplikacjach Java (bardzo mu pasowało). Następnie umieścili tam niektóre aplikacje napisane w PHP; i „Nexus” nie był już odpowiedni, dlatego wybraliśmy jFrog Artefactory, który może artefakteryzować prawie wszystko. Doszliśmy nawet do tego, że w tym repozytorium artefaktów przechowujemy własne pakiety binarne, które zbieramy dla serwerów.
Wzrost ładunku wybuchowego
Rozmawialiśmy o zmianie wersji oprogramowania. Następną rzeczą, którą mamy, jest gwałtowny wzrost obciążenia. Mam tutaj prawdopodobnie na myśli gwałtowny wzrost obciążenia, co nie jest do końca właściwe...
Napisaliśmy nowy system - jest zorientowany na usługi, modny, piękny, wszędzie pracownicy, wszędzie kolejki, wszędzie asynchronia. W takich systemach dane mogą przepływać różnymi strumieniami. Do pierwszej transakcji można wykorzystać 1., 3., 10. pracownika, do drugiej transakcji - 2., 4., 5. A dzisiaj, powiedzmy, rano masz przepływ danych, który wykorzystuje pierwszych trzech pracowników, a wieczorem zmienia się radykalnie i wszystko wykorzystuje pozostałych trzech pracowników.
I tutaj okazuje się, że trzeba jakoś skalować pracowników, trzeba jakoś skalować swoje usługi, ale jednocześnie zapobiegać rozdęciu zasobów.
Zdefiniowaliśmy nasze wymagania. Wymagania te są dość proste: wykrywanie usług, parametryzacja – wszystko jest standardowe przy budowaniu takich skalowalnych systemów, z wyjątkiem jednego punktu – amortyzacji zasobów. Powiedzieliśmy, że nie jesteśmy gotowi amortyzować zasobów, aby serwery podgrzewały powietrze. Wzięliśmy „Konsula”, wzięliśmy „Nomada”, który zarządza naszymi pracownikami.Dlaczego jest to dla nas problem? Cofnijmy się trochę. Mamy już za sobą około 70 systemów płatności. Rano ruch przechodzi przez Sbierbank, potem na przykład Sbierbank spadł i przełączamy go na inny system płatności. Przed Sbierbankiem mieliśmy 100 pracowników, a potem musimy gwałtownie zwiększyć liczbę 100 pracowników na rzecz innego systemu płatności. Pożądane jest, aby wszystko to działo się bez udziału człowieka. Bo jeśli jest udział człowieka, to 24 godziny na dobę powinien tam siedzieć inżynier, który tylko to powinien robić, bo takie awarie, gdy za sobą ma 7 systemów, zdarzają się regularnie.
Dlatego przyjrzeliśmy się Nomadowi, który ma otwarte IP, i napisaliśmy własną rzecz, Scale-Nomad - ScaleNo, która w przybliżeniu wykonuje następujące czynności: monitoruje wzrost kolejki i zmniejsza lub zwiększa liczbę pracowników w zależności od dynamiki z kolejki. Kiedy to zrobiliśmy, pomyśleliśmy: „Może uda nam się to otworzyć?” Potem spojrzeli na nią - była prosta jak dwie kopiejki.
Póki co nie mamy tego open source, ale jeśli nagle po raporcie, gdy uświadomisz sobie, że czegoś takiego potrzebujesz, będziesz tego potrzebować, moje kontakty są na ostatnim slajdzie - napisz do mnie. Jeżeli zgłosi się minimum 3-5 osób to zasponsorujemy.
Jak to działa? Przyjrzyjmy się! Patrząc w przyszłość: po lewej stronie fragment naszego monitoringu: jest to jedna linia, na górze czas przetwarzania zdarzenia, w środku liczba transakcji, na dole liczba pracowników.Jeśli się przyjrzysz, na tym zdjęciu jest błąd. Na górnym wykresie jeden z wykresów uległ awarii w ciągu 45 sekund – padł jeden z systemów płatności. Natychmiast w ciągu 2 minut wprowadzono ruch i kolejka zaczęła rosnąć na innym systemie płatności, na którym nie było pracowników (nie wykorzystaliśmy zasobów - wręcz przeciwnie, pozbyliśmy się ich prawidłowo). Nie chcieliśmy ogrzewać – była minimalna liczba, około 5-10 pracowników, ale nie mogli sobie poradzić.
Ostatni wykres pokazuje „garb”, co oznacza po prostu, że „Skaleno” podwoiło tę kwotę. A potem, gdy wykres trochę się obniżył, nieco go obniżył – liczba pracowników zmieniała się automatycznie. Tak to działa. Rozmawialiśmy o punkcie numer 2 - „Jak szybko pozbyć się powodów”.
Monitorowanie. Jak szybko zidentyfikować problem?
Teraz pierwszy punkt brzmi: „Jak szybko zidentyfikować problem?” Monitorowanie! Musimy szybko zrozumieć pewne rzeczy. Jakie rzeczy powinniśmy szybko zrozumieć?
Trzy rzeczy!- Musimy zrozumieć i szybko zrozumieć wydajność naszych własnych zasobów.
- Musimy szybko zrozumieć awarie i monitorować działanie systemów zewnętrznych w stosunku do nas.
- Trzeci punkt to identyfikacja błędów logicznych. To wtedy system działa dla Ciebie, wszystko jest normalne według wszystkich wskaźników, ale coś idzie nie tak.
Prawdopodobnie nie powiem ci tutaj niczego tak fajnego. Będę Kapitanem Oczywistym. Szukaliśmy tego, co było na rynku. Mamy „zabawne zoo”. Oto rodzaj zoo, które mamy obecnie:
Używamy Zabbix do monitorowania sprzętu, do monitorowania głównych wskaźników serwerów. Do baz danych używamy Okmetera. Używamy „Grafany” i „Prometeusza” do wszystkich innych wskaźników, które nie pasują do pierwszych dwóch, niektóre z „Grafaną” i „Prometeuszem”, a niektóre z „Grafaną” z „Influxem” i Telegrafem.Rok temu chcieliśmy skorzystać z New Relic. Fajna rzecz, potrafi wszystko. Ale choć może wszystko, jest taka droga. Kiedy urosliśmy do 1,5 tys. serwerów, przyszedł do nas sprzedawca i powiedział: „Zawrzyjmy umowę na przyszły rok”. Patrzyliśmy na cenę i powiedzieliśmy, że nie, nie zrobimy tego. Teraz porzucamy New Relic, zostało nam około 15 serwerów pod nadzorem New Relic. Cena okazała się absolutnie dzika.
Jest jedno narzędzie, które sami wdrożyliśmy - jest to Debugger. Na początku nazywaliśmy go „Bagger”, ale potem przeszedł obok nas nauczyciel angielskiego, dziko się zaśmiał i zmienił nazwę na „Debagger”. Co to jest? Jest to narzędzie, które tak naprawdę w ciągu 15-30 sekund na każdym komponencie, niczym „czarna skrzynka” systemu, przeprowadza testy ogólnej wydajności komponentu.
Przykładowo, jeśli istnieje strona zewnętrzna (strona płatności), po prostu ją otwiera i patrzy, jak powinna wyglądać. Jeśli jest to przetwarzanie, wysyła testową „transakcję” i upewnia się, że ta „transakcja” dotrze. Jeśli jest to połączenie z systemami płatności, tam, gdzie to możliwe, wysyłamy żądanie testowe i sprawdzamy, czy u nas wszystko jest w porządku.
Jakie wskaźniki są istotne przy monitorowaniu?
Co głównie monitorujemy? Jakie wskaźniki są dla nas ważne?
- Bardzo ważnym wskaźnikiem jest czas reakcji/RPS na frontach. Od razu odpowiada, że coś jest z Tobą nie tak.
- Liczba przetworzonych wiadomości we wszystkich kolejkach.
- Liczba pracowników.
- Podstawowe metryki poprawności.
Ostatnim punktem jest metryka „biznesowa”, „biznesowa”. Jeśli chcesz monitorować to samo, musisz zdefiniować jeden lub dwa wskaźniki, które będą dla Ciebie głównymi wskaźnikami. Naszym miernikiem jest przepustowość (jest to stosunek liczby udanych transakcji do całkowitego przepływu transakcji). Jeśli coś się w nim zmienia w odstępie 5-10-15 minut, to znaczy, że mamy problemy (jeśli zmienia się radykalnie).
Jak to u nas wygląda to przykład jednej z naszych tablic:
Po lewej stronie znajduje się 6 wykresów, jest to według linii - liczba pracowników i liczba wiadomości w kolejkach. Po prawej stronie – RPS, RTS. Poniżej znajduje się ten sam wskaźnik „biznesowy”. A w metryce „biznesowej” od razu widać, że coś poszło nie tak na dwóch środkowych wykresach… To po prostu kolejny system, który za nami stoi i który upadł.Drugą rzeczą, którą musieliśmy zrobić, było monitorowanie upadku zewnętrznych systemów płatności. Tutaj wzięliśmy OpenTracing - mechanizm, standard, paradygmat pozwalający śledzić systemy rozproszone; i trochę się to zmieniło. Standardowy paradygmat OpenTracing mówi, że budujemy śledzenie dla każdego indywidualnego żądania. Nie potrzebowaliśmy tego i zapakowaliśmy to w podsumowanie, ślad agregacji. Stworzyliśmy narzędzie, które pozwala nam śledzić prędkość systemów za nami.
Z wykresu wynika, że jeden z systemów płatności zaczął odpowiadać już w 3 sekundy – mamy problemy. Co więcej, ta rzecz będzie reagować, gdy zaczną się problemy, w odstępie 20-30 sekund.Trzecią klasą istniejących błędów monitorowania jest monitorowanie logiczne.
Szczerze mówiąc, nie wiedziałam, 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 zrobić to sami.
Co mam na myśli mówiąc o monitorowaniu logicznym? Cóż, wyobraź sobie: tworzysz sobie system (na przykład klon Tindera); udało Ci się, uruchomiłeś. Odnoszący sukcesy menadżer Wasya Pupkin umieścił to na swoim telefonie, widzi tam dziewczynę, lubi ją… i to nie trafia do dziewczyny – to samo trafia do ochroniarza Michałycza z tego samego centrum biznesowego. Kierownik schodzi na dół i zadaje sobie pytanie: „Dlaczego ten ochroniarz Michałych tak miło się do niego uśmiecha?”W takich sytuacjach... Dla nas ta sytuacja brzmi trochę inaczej, bo (pisałem) to utrata reputacji, która pośrednio prowadzi do strat finansowych. U nas sytuacja jest odwrotna: możemy ponieść bezpośrednie straty finansowe – np. jeśli przeprowadziliśmy transakcję jako udaną, ale zakończyła się ona niepowodzeniem (lub odwrotnie). Musiałem napisać własne narzędzie, które śledzi liczbę udanych transakcji w czasie za pomocą wskaźników biznesowych. Nie znalazłem nic na rynku! To jest dokładnie ta myśl, którą chciałem przekazać. Na rynku nie ma nic, co rozwiązałoby tego typu problem.
Chodziło o to, jak szybko zidentyfikować problem.
Jak określić przyczyny wdrożenia
Trzecia grupa problemów, które rozwiązujemy, ma miejsce po zidentyfikowaniu problemu, po pozbyciu się go, dobrze byłoby zrozumieć powód rozwoju, testowania i coś z tym zrobić. W związku z tym musimy zbadać, musimy podnieść kłody.
Jeśli mówimy o logach (głównym powodem są logi), większość naszych logów znajduje się w ELK Stack - prawie każdy ma to samo. Dla niektórych może nie być w ELK, ale jeśli będziesz pisać logi w gigabajtach, to prędzej czy później trafisz do ELK. Zapisujemy je w terabajtach.
Jest tu problem. Naprawiliśmy to, poprawiliśmy błąd dla użytkownika, zaczęliśmy grzebać, co tam było, weszliśmy do Kibany, wprowadziliśmy tam identyfikator transakcji i otrzymaliśmy taki obrus (dużo pokazuje). I w tym obrusie absolutnie nic nie jest jasne. Dlaczego? Tak, ponieważ nie jest jasne, która część należy do którego pracownika, która część należy do którego komponentu. I w tym momencie zdaliśmy sobie sprawę, że potrzebujemy śledzenia – tego samego OpenTracing, o którym mówiłem.Pomyśleliśmy o tym rok temu, zwróciliśmy uwagę na rynek, a tam były dwa narzędzia - „Zipkin” i „Jaeger”. Takim ideologicznym spadkobiercą, ideologicznym następcą „Zipkina” jest bowiem „Jager”. W Zipkinie wszystko jest dobrze, z tą różnicą, że nie umie agregować, nie wie jak uwzględniać logi w śladzie, tylko śledzenie czasu. I „Jager” to poparł.
Przyjrzeliśmy się „Jagerowi”: można instrumentować aplikacje, można pisać w Api (standard Api dla PHP w tamtym czasie nie został jednak zatwierdzony - to było rok temu, ale teraz został już zatwierdzony), ale tam absolutnie nie był klientem. „OK” – pomyśleliśmy i napisaliśmy do naszego własnego klienta. Co otrzymaliśmy? Tak to mniej więcej wygląda:
W Jaeger dla każdej wiadomości tworzone są zakresy. Oznacza to, że gdy użytkownik otwiera system, widzi jeden lub dwa bloki dla każdego przychodzącego żądania (1-2-3 - liczba żądań przychodzących od użytkownika, liczba bloków). Aby ułatwić użytkownikom, dodaliśmy tagi do logów i śladów czasowych. Odpowiednio, w przypadku wystąpienia błędu, nasza aplikacja oznaczy log odpowiednim znacznikiem Error. Możesz filtrować według znacznika błędu i zostaną wyświetlone tylko przęsła zawierające ten blok z błędem. Tak to wygląda, jeśli rozszerzymy zakres:
Wewnątrz przęsła znajduje się zespół śladów. W tym przypadku są to trzy ślady testowe, a trzeci ślad mówi nam, że wystąpił błąd. Jednocześnie widzimy tutaj ślad czasu: u góry mamy skalę czasu i widzimy, w jakim odstępie czasu zarejestrowano ten lub inny dziennik.W związku z tym wszystko poszło dla nas dobrze. Napisaliśmy własne rozszerzenie i udostępniliśmy je na zasadach open source. Jeśli chcesz pracować ze śledzeniem, jeśli chcesz pracować z „Jagerem” w PHP, jest nasze rozszerzenie, zapraszamy do korzystania, jak to mówią:
Mamy to rozszerzenie - jest to klient dla OpenTracing Api, jest wykonane jako rozszerzenie php, to znaczy trzeba je złożyć i zainstalować w systemie. Rok temu nie było inaczej. Teraz są inni klienci, którzy są podobnymi komponentami. Tutaj decyzja należy do Ciebie: albo wypompujesz komponenty za pomocą kompozytora, albo użyjesz rozszerzenia według własnego uznania.Standardy korporacyjne
Rozmawialiśmy o trzech przykazaniach. Czwarte przykazanie dotyczy standaryzacji podejść. O czym to jest? Chodzi o to:
Dlaczego pojawiło się tutaj słowo „korporacja”? Nie dlatego, że jesteśmy dużą lub biurokratyczną firmą, nie! Chciałem tutaj użyć słowa „korporacyjny” w kontekście tego, że każda firma, każdy produkt powinien mieć swoje standardy, łącznie z Tobą. Jakie mamy standardy?
- Mamy regulamin rozmieszczenia. Bez niego nigdzie się nie ruszamy, nie możemy. Wdrażamy około 60 razy w tygodniu, czyli wdrażamy niemal stale. Jednocześnie mamy np. w regulaminie rozmieszczania tabu dotyczące rozmieszczania w piątek – w zasadzie nie rozmieszczamy.
- Wymagamy dokumentacji. Żaden nowy komponent nie trafia do produkcji, jeśli nie ma na to dokumentacji, nawet jeśli narodził się pod piórem naszych specjalistów RnD. Wymagamy od nich instrukcji wdrożenia, mapy monitorowania i przybliżonego opisu (no cóż, jak programiści mogą napisać) tego, jak działa ten komponent, jak go rozwiązać.
- Rozwiązujemy nie przyczynę problemu, ale problem - o czym już mówiłem. Ważne jest dla nas, aby chronić użytkownika przed problemami.
- Mamy zezwolenia. Na przykład nie uważamy za przestój, jeśli w ciągu dwóch minut straciliśmy 2% ruchu. W zasadzie nie jest to uwzględniane w naszych statystykach. Jeśli jest to bardziej procentowe lub tymczasowe, to już policzyliśmy.
- I zawsze piszemy sekcje zwłok. Cokolwiek się z nami stanie, każda sytuacja, w której ktoś zachował się nienormalnie podczas produkcji, znajdzie odzwierciedlenie w sekcji zwłok. Sekcja zwłok to dokument, w którym opisujesz, co Ci się przydarzyło, szczegółowo opisujesz czas, co zrobiłeś, aby to naprawić i (jest to obowiązkowy blok!), co zrobisz, aby zapobiec takim wydarzeniom w przyszłości. Jest to obowiązkowe i konieczne do późniejszej analizy.
Co uważa się za przestój?
Do czego to wszystko doprowadziło?Doprowadziło to do tego, że (mieliśmy pewne problemy ze stabilnością, nie odpowiadało to 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 około połowa to stabilność jakby nie nasza, ale naszej zapory sieciowej aplikacji internetowej, która stoi przed nami i jest używana jako usługa, ale klienci się tym nie przejmują.
Nauczyliśmy się spać w nocy. Wreszcie! Sześć miesięcy temu nie mogliśmy. I w związku z wynikami chciałbym poczynić jedną uwagę. Wczoraj wieczorem ukazał się wspaniały raport na temat systemu sterowania reaktorem jądrowym. Jeśli ludzie, którzy napisali ten system, mnie słyszą, proszę zapomnieć o tym, co powiedziałem o „2% to nie przestój”. Dla Ciebie 2% to przestój, nawet jeśli trwa dwie minuty!
To wszystko! Twoje pytania.
O balanserach i migracji baz danych
Pytanie od publiczności (dalej – B): – Dobry wieczór. Dziękuję bardzo za taki raport administratora! Krótkie pytanie dotyczące Waszych balanserów. Wspomniałeś, że masz WAF-a, czyli jak rozumiem używasz jakiegoś zewnętrznego balansera...
EK: – Nie, korzystamy z naszych usług jako balansera. W tym przypadku WAF jest dla nas wyłącznie narzędziem do ochrony przed DDoS.
W: – Czy możesz powiedzieć kilka słów o balanserach?
EK: – Jak już mówiłem, jest to grupa serwerów w openresty. Mamy teraz 5 grup rezerwowych, które odpowiadają wyłącznie... to znaczy serwer obsługujący wyłącznie openresty, obsługujący tylko ruch proxy. W związku z tym, aby zrozumieć, ile posiadamy: mamy teraz regularny przepływ ruchu na poziomie kilkuset megabitów. Dają sobie radę, czują się dobrze, nawet się nie nadwyrężają.
W: – Również proste pytanie. Oto wdrożenie w kolorze niebieskim/zielonym. Co robisz na przykład z migracją baz danych?
EK: - Dobre pytanie! Spójrz, w przypadku wdrożenia Blue/Green mamy osobne kolejki dla każdej linii. Oznacza to, że jeśli mówimy o kolejkach zdarzeń przesyłanych od pracownika do pracownika, istnieją oddzielne kolejki dla linii niebieskiej i dla linii zielonej. Jeśli mówimy o samej bazie danych, to celowo ją zawęziliśmy do granic możliwości, przenieśliśmy wszystko praktycznie do kolejek, w bazie przechowujemy jedynie stos transakcji. A nasz stos transakcji jest taki sam dla wszystkich linii. Z bazą danych w tym kontekście: nie dzielimy jej na niebieską i zieloną, ponieważ obie wersje kodu muszą wiedzieć, co dzieje się z transakcją.
Kochani, mam też dla Was małą nagrodę – książkę. I ja powinienem zostać nagrodzony za najlepsze pytanie.
W: - Cześć. Dziękuję za raport. Pytanie jest takie. Monitorujesz płatności, monitorujesz usługi, z którymi się komunikujesz... Ale jak monitorować, aby ktoś jakimś cudem trafił na Twoją stronę płatności, dokonał płatności, a projekt zasilił go pieniędzmi? To znaczy, w jaki sposób monitorujesz, czy sprzedawca jest dostępny i przyjął Twoje oddzwonienie?
EK: – „Akceptant” jest dla nas w tym przypadku dokładnie tą samą usługą zewnętrzną, co system płatności. Monitorujemy szybkość reakcji sprzedawcy.
O szyfrowaniu baz danych
W: - Cześć. Mam trochę powiązane pytanie. Masz wrażliwe dane PCI DSS. Chciałem wiedzieć, jak przechowujesz numery PAN w kolejkach, do których musisz się przenieść? Czy używasz jakiegoś szyfrowania? A to prowadzi do drugiego pytania: zgodnie z PCI DSS konieczne jest okresowe ponowne szyfrowanie bazy danych w przypadku zmian (zwolnienie administratorów itp.) – co w tym przypadku dzieje się z dostępnością?
EK: - Cudowne pytanie! Po pierwsze, nie przechowujemy numerów PAN w kolejkach. Zasadniczo nie mamy prawa przechowywać PAN nigdzie w przejrzystej formie, dlatego korzystamy ze specjalnej usługi (nazywamy ją „Kademon”) - jest to usługa, która robi tylko jedno: odbiera wiadomość jako wejście i wysyła wysłać zaszyfrowaną wiadomość. I przechowujemy wszystko w tej zaszyfrowanej wiadomości. W związku z tym długość naszego klucza jest mniejsza niż kilobajt, więc jest to poważne i niezawodne.W: – Czy potrzebujesz teraz 2 kilobajtów?
EK: – Wydaje się, że jeszcze wczoraj było 256… No bo gdzie indziej?!
W związku z tym jest to pierwsze. Po drugie, rozwiązanie, które istnieje, wspiera procedurę ponownego szyfrowania - istnieją dwie pary „keków” (kluczy), które dają „talie” szyfrujące (klucze to klucze, dek to pochodne kluczy szyfrujących) . A jeśli procedura zostanie wszczęta (zdarza się to regularnie, od 3 miesięcy do ± kilku miesięcy), pobieramy nową parę „ciasteczek” i ponownie szyfrujemy dane. Mamy osobne usługi, które zgrywają wszystkie dane i szyfrują je w nowy sposób; Dane przechowywane są obok identyfikatora klucza, którym są szyfrowane. W związku z tym, gdy tylko zaszyfrujemy dane nowymi kluczami, usuwamy stary klucz.
Czasami płatności trzeba dokonać ręcznie...
W: – To znaczy, jeśli nadejdzie zwrot pieniędzy za jakąś operację, czy nadal odszyfrujesz go starym kluczem?
EK: - TAk.
W: – W takim razie jeszcze jedno małe pytanie. W przypadku awarii, upadku lub zdarzenia konieczne jest ręczne przeforsowanie transakcji. Jest taka sytuacja.
EK: - Tak czasami.
W: – Skąd bierzesz te dane? A może sam odwiedzasz ten magazyn?
EK: – Nie, oczywiście, że mamy jakiś system back-office, który zawiera interfejs do naszego wsparcia. Jeśli nie wiemy, w jakim statusie znajduje się transakcja (np. do czasu, gdy system płatności odpowiedział timeoutem), nie wiemy a priori, czyli status ostateczny nadajemy jedynie z pełną pewnością. W takim przypadku nadajemy transakcji specjalny status do ręcznego przetwarzania. Rano następnego dnia, gdy tylko support otrzyma informację, że takie a takie transakcje pozostają w systemie płatności, przetwarza je ręcznie w tym interfejsie.
W: – Mam kilka pytań. Jednym z nich jest kontynuacja strefy PCI DSS: jak zalogować się do ich obwodu? To pytanie jest spowodowane tym, że programista mógł umieścić cokolwiek w dziennikach! Drugie pytanie: jak wdrażać poprawki? Używanie uchwytów w bazie danych jest jedną z opcji, ale mogą być dostępne bezpłatne poprawki — jaka jest tam procedura? A trzecie pytanie prawdopodobnie dotyczy RTO, RPO. Twoja dostępność wyniosła 99,97, prawie cztery dziewiątki, ale jak rozumiem, masz drugie centrum danych, trzecie centrum danych i piąte centrum danych... Jak je synchronizować, replikować i wszystko inne?EK: - Zacznijmy od pierwszego. Czy pierwsze pytanie dotyczyło logów? Kiedy piszemy logi, mamy warstwę, która maskuje wszystkie wrażliwe dane. Patrzy na maskę i na dodatkowe pola. W związku z tym nasze dzienniki zawierają już zamaskowane dane i obwód PCI DSS. Jest to jedno ze stałych zadań przydzielanych działowi testów. Muszą sprawdzić każde zadanie, łącznie z zapisywanymi przez siebie logami, i jest to jedno ze stałych zadań podczas przeglądania kodu, aby mieć pewność, że programista czegoś nie zapisał. Kolejne kontrole tego są regularnie przeprowadzane przez dział bezpieczeństwa informacji mniej więcej raz w tygodniu: logi z ostatniego dnia są wybiórczo zbierane i przepuszczane przez specjalny skaner-analizator z serwerów testowych, aby wszystko sprawdzić.
Informacje na temat poprawek. Jest to uwzględnione w naszym regulaminie wdrażania. Mamy osobną klauzulę dotyczącą poprawek. Wierzymy, że wdrażamy poprawki przez całą dobę, kiedy ich potrzebujemy. Gdy tylko wersja zostanie zmontowana, gdy tylko zostanie uruchomiona, gdy tylko będziemy mieli artefakt, mamy dyżurującego administratora systemu na wezwanie wsparcia, który wdraża go w momencie, gdy jest to konieczne.O „czterech dziewiątkach”. Wynik, który mamy obecnie, został rzeczywiście osiągnięty i zabiegaliśmy o niego w innym centrum danych. Teraz mamy drugie centrum danych i zaczynamy trasować między nimi, a kwestia replikacji między centrami danych jest naprawdę nietrywialnym pytaniem. Próbowaliśmy rozwiązać to jednocześnie na różne sposoby: próbowaliśmy użyć tej samej „Tarantuli” - nam to nie wyszło, powiem ci od razu. Dlatego ostatecznie zamówiliśmy „sensy” ręcznie. Tak naprawdę każda aplikacja w naszym systemie przeprowadza asynchroniczną synchronizację typu „zmiana dokonana” pomiędzy centrami danych.
W: – Skoro dostałeś drugi, to dlaczego nie dostałeś trzeciego? Bo nikt jeszcze nie ma rozszczepionego mózgu...
EK: – Ale nie mamy Split Brain. Dzięki temu, że każda aplikacja sterowana jest przez multimastera, nie ma dla nas znaczenia, do jakiego centrum trafiło zgłoszenie. Jesteśmy gotowi na to, że jeśli jedno z naszych data center ulegnie awarii (na tym polegamy) i w trakcie żądania użytkownika przełączy się na drugie data center, to rzeczywiście jesteśmy gotowi stracić tego użytkownika; ale będą to jednostki, jednostki absolutne.
W: - Dobry wieczór. Dziękuję za raport. Mówiłeś o debugerze, który uruchamia pewne transakcje testowe w środowisku produkcyjnym. Ale opowiedz nam o transakcjach testowych! Jak głęboko to sięga?
EK: – Przechodzi pełny cykl całego komponentu. W przypadku komponentu nie ma różnicy pomiędzy transakcją testową a transakcją produkcyjną. Jednak z logicznego punktu widzenia jest to po prostu odrębny projekt w systemie, na którym przeprowadzane są wyłącznie transakcje testowe.
W: -Gdzie to odcinasz? Tutaj Core wysłał...
EK: – W tym przypadku jesteśmy za „Korem” jeśli chodzi o transakcje testowe… Mamy coś takiego jak routing: „Kor” wie, do którego systemu płatności wysłać – wysyłamy do fałszywego systemu płatności, który po prostu daje sygnał http i to wszystko.
W: – Powiedz mi, proszę, czy Twoja aplikacja została napisana w jednym wielkim monolicie, czy też podzieliłeś ją na jakieś usługi lub nawet mikroserwisy?
EK: – Nie mamy oczywiście monolitu, mamy aplikację zorientowaną na usługi. Żartujemy, że nasz serwis wykonany jest z monolitów – są one naprawdę dość duże. Trudno nazwać to mikrousługami, ale są to usługi, w ramach których działają pracownicy rozproszonych maszyn.
Jeśli usługa na serwerze zostanie naruszona...
W: – W takim razie mam następne pytanie. Nawet gdyby był to monolit, nadal powiedziałeś, że masz wiele takich serwerów błyskawicznych, wszystkie zasadniczo przetwarzają dane, a pytanie brzmi: „W przypadku naruszenia bezpieczeństwa jednego z serwerów błyskawicznych lub aplikacji, dowolne indywidualne łącze Czy mają jakąś kontrolę dostępu? Który z nich co potrafi? Z kim mam się kontaktować w celu uzyskania jakich informacji?
EK: - Tak, zdecydowanie. Wymogi bezpieczeństwa są dość poważne. Po pierwsze, mamy otwarte przepływy danych, a porty to tylko te, przez które z wyprzedzeniem przewidujemy przepływ ruchu. Jeśli komponent komunikuje się z bazą danych (powiedzmy z Muskulem) poprzez 5-4-3-2, tylko 5-4-3-2 będzie dla niego otwarty, a inne porty i inne kierunki ruchu nie będą dostępne. Ponadto musisz zrozumieć, że w naszej produkcji istnieje około 10 różnych pętli bezpieczeństwa. I nawet jeśli aplikacja została w jakiś sposób skompromitowana, nie daj Boże, osoba atakująca nie będzie mogła uzyskać dostępu do konsoli zarządzania serwerem, ponieważ jest to inna strefa bezpieczeństwa sieci.W: – I w tym kontekście bardziej interesujące dla mnie jest to, że masz określone umowy ze służbami – co mogą zrobić, poprzez jakie „akcje” mogą się ze sobą kontaktować… A w normalnym toku pewne konkretne służby żądają jakichś wierszu, lista „akcji” po drugiej stronie. Wydaje się, że w normalnej sytuacji nie zwracają się do innych i mają inne obszary odpowiedzialności. Czy jeśli jedno z nich zostanie naruszone, będzie w stanie zakłócić „działania” tej usługi?..
EK: - Rozumiem. Jeśli w normalnej sytuacji z innym serwerem komunikacja była w ogóle dozwolona, to tak. Zgodnie z umową SLA nie monitorujemy, czy dozwolone są tylko pierwsze 3 „akcje”, a czy nie są dozwolone 4 „akcje”. Jest to dla nas chyba zbędne, bo mamy już 4-stopniowy system zabezpieczeń w zasadzie dla obwodów. Wolimy się bronić konturami, a nie na poziomie wnętrzności.
Jak działają Visa, MasterCard i Sberbank
W: – Chcę wyjaśnić kwestię dotyczącą przenoszenia użytkownika z jednego centrum danych do drugiego. O ile wiem, Visa i MasterCard działają w oparciu o binarny protokół synchroniczny 8583 i tam są miksy. A chciałem wiedzieć, teraz mamy na myśli zmianę – czy jest to bezpośrednio „Visa” i „MasterCard”, czy przed systemami płatności, przed przetwarzaniem?
EK: - To jest przed miksami. Nasze miksy znajdują się w tym samym centrum danych.
W: – Z grubsza mówiąc, czy masz jeden punkt połączenia?
EK: – „Visa” i „MasterCard” – tak. Po prostu dlatego, że Visa i MasterCard wymagają dość poważnych inwestycji w infrastrukturę, aby zawrzeć osobne umowy na przykład na uzyskanie drugiej pary miksów. Są one zarezerwowane w ramach jednego centrum danych, ale jeśli, nie daj Boże, nasze centrum danych, w którym są miksy do łączenia się z Visa i MasterCard, umrze, wówczas będziemy mieli utracone połączenie z Visą i MasterCard...
W: – Jak można je zarezerwować? Wiem, że Visa umożliwia w zasadzie tylko jedno połączenie!
EK: – Sami dostarczają sprzęt. W każdym razie otrzymaliśmy sprzęt, który w środku jest w pełni redundantny.
W: – Więc stojak pochodzi z Connects Orange?..
EK: - TAk.
W: – Ale co w tym przypadku: jeśli Twoje centrum danych zniknie, jak możesz z niego nadal korzystać? A może po prostu ruch ustał?
EK: - NIE. W takim przypadku po prostu przeniesiemy ruch na inny kanał, co oczywiście będzie droższe dla nas i droższe dla naszych klientów. Ale ruch nie będzie przechodził przez nasze bezpośrednie połączenie z Visa, MasterCard, ale przez warunkowy Sbierbank (bardzo przesadzone).
Przepraszam serdecznie, jeśli obraziłem pracowników Sbierbanku. Ale według naszych statystyk wśród rosyjskich banków najczęściej upada Sbierbank. Nie ma miesiąca, żeby coś nie spadło w Sbierbanku.
Kilka reklam 🙂
Dziękujemy za pobyt z nami. Podobają Ci się nasze artykuły? Chcesz zobaczyć więcej ciekawych treści? Wesprzyj nas składając zamówienie lub polecając znajomym, , unikalny odpowiednik serwerów klasy podstawowej, który został przez nas wymyślony dla Ciebie: (dostępne z RAID1 i RAID10, do 24 rdzeni i do 40 GB DDR4).
Dell R730xd 2 razy taniej w centrum danych Equinix Tier IV w Amsterdamie? Tylko tutaj w Holandii! Dell R420 — 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2x960 GB SSD 1 Gb/s 100 TB — od 99 USD! Czytać o
Źródło: www.habr.com