{"id":35092,"date":"2019-10-31T22:02:18","date_gmt":"2019-10-31T19:02:18","guid":{"rendered":"https:\/\/prohoster.info\/blog\/bitriks24-bystro-podnyatoe-ne-schitaetsya-upavshim\/"},"modified":"2019-10-31T22:02:18","modified_gmt":"2019-10-31T19:02:18","slug":"bitriks24-bystro-podnyatoe-ne-schitaetsya-upavshim","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/bitriks24-bystro-podnyatoe-ne-schitaetsya-upavshim","title":{"rendered":"Bitrix24: \"Szybko podniesione nie jest uwa\u017cane za upad\u0142e\"","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Obecnie us\u0142uga \u201eBitrix24\u201d nie dysponuje setkami gigabit\u00f3w ruchu ani ogromnym parkiem serwer\u00f3w (cho\u0107 oczywi\u015bcie istnieje ich sporo). Mimo to dla wielu klient\u00f3w jest to g\u0142\u00f3wne narz\u0119dzie pracy w firmie, prawdziwa aplikacja krytyczna dla biznesu. Dlatego awaria \u2014 w \u017cadnym wypadku nie mo\u017ce mie\u0107 miejsca. A co je\u015bli awaria jednak si\u0119 zdarzy, ale us\u0142uga \u201eodrodzi\u0142a si\u0119\u201d tak szybko, \u017ce nikt tego nie zauwa\u017cy\u0142? I jak udaje si\u0119 zrealizowa\u0107 failover bez utraty jako\u015bci pracy i liczby klient\u00f3w? Aleksander Demidow, dyrektor ds. us\u0142ug chmurowych \u201eBitrix24\u201d, opowiedzia\u0142 w naszym blogu o tym, jak przez 7 lat istnienia produktu ewoluowa\u0142 system rezerwacji.<\/p>\n

\"Bitrix24:
\n<\/a><\/noindex>
\n\u201eW formacie SaaS uruchomili\u015bmy \u201eBitrix24\u201d 7 lat temu. G\u0142\u00f3wn\u0105 trudno\u015bci\u0105 by\u0142a prawdopodobnie nast\u0119puj\u0105ca kwestia: przed uruchomieniem publicznym w formacie SaaS, ten produkt istnia\u0142 po prostu w formie rozwi\u0105zania pude\u0142kowego. Klienci kupowali go od nas, instalowali na swoich serwerach, zak\u0142adali portal korporacyjny \u2014 wsp\u00f3lne rozwi\u0105zanie do komunikacji mi\u0119dzy pracownikami, przechowywania plik\u00f3w, zarz\u0105dzania zadaniami, CRM, i tak dalej. Do 2012 roku zdecydowali\u015bmy, \u017ce chcemy uruchomi\u0107 to jako SaaS, samodzielnie administruj\u0105c, zapewniaj\u0105c odporno\u015b\u0107 na awarie i niezawodno\u015b\u0107. Zbierali\u015bmy do\u015bwiadczenie w tym procesie, poniewa\u017c do tego momentu po prostu go nie mieli\u015bmy \u2014 byli\u015bmy tylko producentami oprogramowania, a nie dostawcami us\u0142ug. <\/p>\n

Uruchamiaj\u0105c us\u0142ug\u0119, rozumieli\u015bmy, \u017ce najwa\u017cniejsze to zapewni\u0107 odporno\u015b\u0107 na awarie, niezawodno\u015b\u0107 i sta\u0142\u0105 dost\u0119pno\u015b\u0107 us\u0142ugi, poniewa\u017c je\u015bli masz zwyk\u0142\u0105 stron\u0119 internetow\u0105, sklep na przyk\u0142ad, i ona przestaje dzia\u0142a\u0107 przez godzin\u0119 \u2014 cierpisz tylko ty, tracisz zam\u00f3wienia, tracisz klient\u00f3w, ale dla samego twojego klienta \u2014 to nie jest zbyt krytyczne. Oczywi\u015bcie jest zawiedziony, ale poszed\u0142 i kupi\u0142 na innej stronie. A je\u015bli to aplikacja, na kt\u00f3rej opiera si\u0119 ca\u0142a praca wewn\u0105trz firmy, komunikacja, podejmowanie decyzji, to najwa\u017cniejsze jest zdobycie zaufania u\u017cytkownik\u00f3w, czyli nie zawodzenie ich i nie pada\u0107. Dlatego \u017ce ca\u0142a praca mo\u017ce stan\u0105\u0107, je\u015bli co\u015b wewn\u0105trz nie b\u0119dzie dzia\u0142a\u0107.<\/p>\n

Bitrix24 jako SaaS<\/h4>\n

\nPierwszy prototyp zbudowali\u015bmy rok przed publicznym uruchomieniem, w 2011 roku. Zaj\u0119\u0142o nam to oko\u0142o tygodnia, przetestowali\u015bmy go \u2014 by\u0142 nawet dzia\u0142aj\u0105cy. To znaczy, mo\u017cna by\u0142o wej\u015b\u0107 do formularza, wpisa\u0107 nazw\u0119 portalu, tworzy\u0142 si\u0119 nowy portal, zak\u0142adana by\u0142a baza u\u017cytkownik\u00f3w. Przyjrzeli\u015bmy si\u0119 temu, ocenili\u015bmy produkt i przez ca\u0142y rok dalej go rozwijali\u015bmy. Mieli\u015bmy du\u017ce zadanie: nie chcieli\u015bmy tworzy\u0107 dw\u00f3ch oddzielnych baz kodu, nie chcieli\u015bmy wspiera\u0107 osobno produktu pude\u0142kowego i osobno rozwi\u0105za\u0144 chmurowych \u2014 chcieli\u015bmy wszystko robi\u0107 w ramach jednego kodu. <\/p>\n

\"Bitrix24:
\n
\nTypowa aplikacja internetowa w tamtym czasie to jeden serwer, na kt\u00f3rym dzia\u0142a\u0142 jaki\u015b kod PHP, baza MySQL, pliki by\u0142y przesy\u0142ane, dokumenty, zdj\u0119cia umieszczane w folderze upload \u2014 i to wszystko dzia\u0142a\u0142o. Niestety, uruchomienie krytycznie niezawodnej us\u0142ugi internetowej na tym jest niemo\u017cliwe. Nie obs\u0142ugiwano tam rozproszonego cache'a ani replikacji baz danych. <\/p>\n

Sformu\u0142owali\u015bmy wymagania: musi mie\u0107 mo\u017cliwo\u015b\u0107 umiejscowienia w r\u00f3\u017cnych lokalizacjach, wspiera\u0107 replikacj\u0119, idealnie, aby mie\u015bci\u0142 si\u0119 w r\u00f3\u017cnych geograficznie rozdzielonych centrach danych. Podzieli\u0107 logik\u0119 produktu i w\u0142a\u015bciwe przechowywanie danych. Musi mie\u0107 mo\u017cliwo\u015b\u0107 dynamicznego skalowania w zale\u017cno\u015bci od obci\u0105\u017cenia, a statyk\u0119 w og\u00f3le zewn\u0119trznie wydzieli\u0107. Z tych powod\u00f3w powsta\u0142y wymagania do produktu, kt\u00f3ry rozwijali\u015bmy przez ca\u0142y rok. W tym czasie w platformie, kt\u00f3ra okaza\u0142a si\u0119 jednolita \u2014 dla rozwi\u0105za\u0144 pude\u0142kowych oraz dla naszej w\u0142asnej us\u0142ugi \u2014 wprowadzili\u015bmy wsparcie dla rzeczy, kt\u00f3re by\u0142y nam potrzebne. Wsparcie dla replikacji MySQL na poziomie samego produktu: to jest, programista, kt\u00f3ry pisze kod \u2014 nie musi si\u0119 martwi\u0107, jak b\u0119d\u0105 rozdzielane jego zapytania, korzysta z naszego API, a my umiej\u0119tnie rozdzielamy zapytania do zapisu i odczytu mi\u0119dzy masterami i slave'ami. <\/p>\n

Wprowadzili\u015bmy wsparcie na poziomie produktu dla r\u00f3\u017cnych obiektowych magazyn\u00f3w chmurowych: Google Storage, Amazon S3 \u2014 plus wsparcie Open Stack Swift. Dlatego by\u0142o to wygodne zar\u00f3wno dla nas jako us\u0142ugi, jak i dla programist\u00f3w, kt\u00f3rzy pracuj\u0105 z rozwi\u0105zaniem pude\u0142kowym: je\u015bli korzystaj\u0105 po prostu z naszego API do pracy, nie musz\u0105 si\u0119 martwi\u0107, gdzie ostatecznie plik zostanie zapisany, lokalnie w systemie plik\u00f3w czy trafi do obiektowego magazynu plik\u00f3w.<\/p>\n

Ostatecznie od razu zdecydowali\u015bmy, \u017ce b\u0119dziemy rezerwowa\u0107 na poziomie ca\u0142ego centrum danych. W 2012 roku w pe\u0142ni wystartowali\u015bmy w Amazon AWS, poniewa\u017c mieli\u015bmy ju\u017c do\u015bwiadczenie w pracy z t\u0105 platform\u0105 \u2014 nasza w\u0142asna strona by\u0142a tam hostowana. Przyci\u0105ga\u0142o nas to, \u017ce w ka\u017cdym regionie Amazon ma kilka stref dost\u0119pno\u015bci \u2014 w ich terminologii, kilka centr\u00f3w danych, kt\u00f3re s\u0105 w miar\u0119 niezale\u017cne i pozwalaj\u0105 nam rezerwowa\u0107 na poziomie ca\u0142ego centrum danych: je\u015bli jedno z nich nagle zawiedzie, bazy s\u0105 replikowane w trybie master-master, serwery aplikacji internetowych s\u0105 rezerwowane, a statyka trafia do obiektowego magazynu S3. Obci\u0105\u017cenie jest r\u00f3wnowa\u017cone \u2014 w tamtym czasie przez elb Amazon, ale nieco p\u00f3\u017aniej przeszli\u015bmy do w\u0142asnych r\u00f3wnowa\u017cnik\u00f3w obci\u0105\u017cenia, poniewa\u017c potrzebowali\u015bmy bardziej skomplikowanej logiki. <\/p>\n

Co chcieli\u015bmy \u2014 to i otrzymali\u015bmy...<\/h4>\n

\nWszystkie podstawowe rzeczy, kt\u00f3re chcieli\u015bmy zapewni\u0107 \u2014 niezawodno\u015b\u0107 samych serwer\u00f3w, aplikacji internetowych, baz danych \u2014 dzia\u0142a\u0142y dobrze. Najprostszy scenariusz: je\u015bli kt\u00f3re\u015b z naszych aplikacji internetowych zawiedzie, to sprawa jest prosta \u2014 s\u0105 wy\u0142\u0105czane z r\u00f3wnowa\u017cenia obci\u0105\u017cenia. <\/p>\n

\"Bitrix24:
\n
\nUszkodzone maszyny r\u00f3wnowa\u017cnik obci\u0105\u017cenia (wtedy by\u0142 to elb Amazon) sam oznacza\u0142 jako unhealthy, wy\u0142\u0105cza\u0142 rozk\u0142ad obci\u0105\u017cenia na nie. Dzia\u0142a\u0142 automatyczny skalowanie Amazon: gdy obci\u0105\u017cenie ros\u0142o, do grupy auto-skalowania dodawano nowe maszyny, obci\u0105\u017cenie rozdzielano na nowe maszyny \u2014 wszystko by\u0142o dobrze. Z naszymi r\u00f3wnowa\u017cnikami obci\u0105\u017cenia logika jest podobna: je\u015bli co\u015b si\u0119 stanie z serwerem aplikacji, usuwamy z niego zapytania, eliminujemy te maszyny, uruchamiamy nowe i kontynuujemy prac\u0119. Schemat przez te wszystkie lata troch\u0119 si\u0119 zmienia\u0142, ale wci\u0105\u017c dzia\u0142a: jest prosty, zrozumia\u0142y i nie ma z tym \u017cadnych trudno\u015bci. <\/p>\n

Dzia\u0142amy na ca\u0142ym \u015bwiecie, szczyty obci\u0105\u017cenia u klient\u00f3w s\u0105 absolutnie r\u00f3\u017cne i, szczerze m\u00f3wi\u0105c, powinni\u015bmy mie\u0107 mo\u017cliwo\u015b\u0107 przeprowadzania r\u00f3\u017cnych prac serwisowych z dowolnymi komponentami naszego systemu w dowolnym czasie \u2013 niewidocznie dla klient\u00f3w. Dlatego mamy mo\u017cliwo\u015b\u0107 wy\u0142\u0105czenia bazy danych, przenosz\u0105c obci\u0105\u017cenie na drugie centrum danych. <\/p>\n

Jak to wszystko dzia\u0142a? \u2014 Przekierowujemy ruch do dzia\u0142aj\u0105cego centrum danych \u2014 je\u015bli to awaria centrum danych, to ca\u0142kowicie, je\u015bli to nasze planowe prace z jak\u0105\u015b jedn\u0105 baz\u0105, to cz\u0119\u015b\u0107 ruchu obs\u0142uguj\u0105cego tych klient\u00f3w przekierowujemy do drugiego centrum danych, wstrzymujemy replikacj\u0119. Je\u015bli potrzebne s\u0105 nowe maszyny do aplikacji webowych, poniewa\u017c obci\u0105\u017cenie wzros\u0142o w drugim centrum danych, automatycznie si\u0119 uruchamiaj\u0105. Ko\u0144czymy prace, replikacja si\u0119 odnawia i przywracamy ca\u0142e obci\u0105\u017cenie z powrotem. Je\u015bli musimy r\u00f3wnolegle przeprowadzi\u0107 jakie\u015b prace w drugim DC, na przyk\u0142ad zainstalowa\u0107 aktualizacje systemowe lub zmieni\u0107 ustawienia w drugiej bazie danych, to generalnie powtarzamy to samo, tylko w drug\u0105 stron\u0119. A je\u015bli to awaria, to robimy wszystko banalnie: w systemie monitorowania u\u017cywamy mechanizmu event-handlers. Je\u015bli aktywuje si\u0119 kilka kontroli i status przechodzi w krytyczny, uruchamiany jest ten handler, procesor, kt\u00f3ry mo\u017ce wykona\u0107 t\u0119 czy inn\u0105 logik\u0119. Dla ka\u017cdej bazy mamy zapisane, kt\u00f3ry serwer jest dla niej serwerem zapasowym, i gdzie nale\u017cy przekierowa\u0107 ruch w przypadku jej niedost\u0119pno\u015bci. W historii korzystamy w r\u00f3\u017cnym stopniu z nagios lub jego fork\u00f3w. Generalnie podobne mechanizmy s\u0105 praktycznie w ka\u017cdym systemie monitorowania, co\u015b bardziej skomplikowanego na razie nie u\u017cywamy, ale by\u0107 mo\u017ce kiedy\u015b b\u0119dziemy. Teraz monitorowanie dzia\u0142a na niedost\u0119pno\u015b\u0107 i ma mo\u017cliwo\u015b\u0107 co\u015b przekierowa\u0107.<\/p>\n

Czy wszystko zarezerwowali\u015bmy?<\/h4>\n

\nMamy wielu klient\u00f3w z USA, wielu klient\u00f3w z Europy, wielu klient\u00f3w z Bliskiego Wschodu \u2014 Japonii, Singapuru itd. Oczywi\u015bcie znaczn\u0105 cz\u0119\u015b\u0107 naszych klient\u00f3w stanowi\u0105 osoby w Rosji. Pracujemy, wi\u0119c, w wielu regionach. U\u017cytkownicy oczekuj\u0105 szybkiej reakcji, istniej\u0105 wymagania dotycz\u0105ce przestrzegania r\u00f3\u017cnych lokalnych przepis\u00f3w, a w ka\u017cdym regionie rezerwujemy i tak dwa centra danych. Dodatkowo mamy jeszcze inne us\u0142ugi, kt\u00f3re r\u00f3wnie\u017c wygodnie jest lokowa\u0107 w obr\u0119bie jednego regionu \u2014 dla klient\u00f3w tam dzia\u0142aj\u0105cych. Serwery aplikacji REST, serwery autoryzacji s\u0105 mniej krytyczne dla og\u00f3lnej pracy klienta, mo\u017cna na nie prze\u0142\u0105cza\u0107 si\u0119 z akceptowalnym op\u00f3\u017anieniem, ale nie chcemy wymy\u015bla\u0107 nowego sposobu monitorowania ich i co z nimi robi\u0107. Dlatego w maksymalnym stopniu staramy si\u0119 korzysta\u0107 z ju\u017c istniej\u0105cych rozwi\u0105za\u0144, a nie rozwija\u0107 u siebie jak\u0105\u015b kompetencj\u0119 w zakresie dodatkowych produkt\u00f3w. Czasem zwyczajnie korzystamy z prze\u0142\u0105czania na poziomie DNS, a \u017cywotno\u015b\u0107 us\u0142ugi okre\u015blamy tym samym DNS. W Amazonie istnieje us\u0142uga Route 53, ale to nie jest tylko DNS, w kt\u00f3rym mo\u017cna doda\u0107 rekordy i na tym koniec \u2014 jest znacznie bardziej elastyczne i wygodne. Dzi\u0119ki niemu mo\u017cna zbudowa\u0107 us\u0142ugi geo-rozproszone z geolokalizacj\u0105, definiuj\u0105c, sk\u0105d pochodzi klient, i przydzielaj\u0105c mu r\u00f3\u017cne rekordy \u2014 umo\u017cliwia to tak\u017ce budow\u0119 architektur failover. Te same health-checki ustawia si\u0119 w samej us\u0142udze Route 53, definiujemy endpointy, kt\u00f3re s\u0105 monitorowane, ustalamy metryki oraz protoko\u0142y, na podstawie kt\u00f3rych okre\u015blamy \u201e\u017cywotno\u015b\u0107\u201d us\u0142ugi \u2014 TCP, HTTP, HTTPS; ustalamy cz\u0119stotliwo\u015b\u0107 sprawdzania, kt\u00f3re okre\u015blaj\u0105, czy us\u0142uga dzia\u0142a czy nie. W samym DNS wpisujemy, co b\u0119dzie primary, co b\u0119dzie secondary, na co prze\u0142\u0105czy\u0107, je\u015bli dzia\u0142a health-check w Route 53. Wszystko to mo\u017cna zrobi\u0107 za pomoc\u0105 innych narz\u0119dzi, ale co jest wygodne \u2014 ustawia si\u0119 to raz, a potem w og\u00f3le nie my\u015blimy o tym, jak wykonujemy kontrole, jak odbywa si\u0119 prze\u0142\u0105czanie: wszystko dzia\u0142a samo.<\/p>\n

Pierwsze \u201ebo\u201d<\/b>: jak i czym rezerwowa\u0107 sam route 53? A nu\u017c stanie si\u0119 co\u015b z\u0142ego? Na szcz\u0119\u015bcie nigdy nie napotkali\u015bmy na te pu\u0142apki, ale znowu, przede mn\u0105 b\u0119dzie opowie\u015b\u0107, dlaczego uznali\u015bmy, \u017ce warto zrobi\u0107 rezerwacj\u0119. Zabezpieczamy si\u0119 na wszelki wypadek. Kilka razy dziennie wykonujemy pe\u0142ny eksport wszystkich stref, kt\u00f3re mamy w route 53. API Amazona pozwala na spokojne wydanie ich w formacie JSON, a my mamy kilka serwer\u00f3w zapasowych, na kt\u00f3re to konwertujemy, eksportujemy w postaci konfiguracji i mamy, m\u00f3wi\u0105c og\u00f3lnie, backupow\u0105 konfiguracj\u0119. W razie czego mo\u017cemy szybko j\u0105 r\u0119cznie uruchomi\u0107, nie trac\u0105c danych ustawie\u0144 DNS.<\/p>\n

Drugie \u201eale\u201d<\/b>: co w tym obrazie jeszcze nie jest zarezerwowane? Sam balancer! Mamy roz\u0142o\u017cenie klient\u00f3w wed\u0142ug region\u00f3w zrobione bardzo prosto. Mamy domeny bitrix24.ru, bitrix24.com, .de \u2014 w tej chwili jest ich oko\u0142o 13 r\u00f3\u017cnych, kt\u00f3re dzia\u0142aj\u0105 w najr\u00f3\u017cniejszych strefach. Doszli\u015bmy do nast\u0119puj\u0105cego wniosku: w ka\u017cdym regionie \u2014 swoje balancery. Tak \u0142atwiej rozdziela\u0107 na regiony w zale\u017cno\u015bci od tego, gdzie jest najwi\u0119ksze obci\u0105\u017cenie w sieci. Je\u015bli dochodzi do awarii na poziomie jednego balancera, po prostu wyci\u0105gamy go z eksploatacji i usuwamy z dns. Je\u015bli wyst\u0119puje jaki\u015b problem z grup\u0105 balancer\u00f3w, s\u0105 one rezerwowane w innych lokalizacjach, a prze\u0142\u0105czanie mi\u0119dzy nimi odbywa si\u0119 za pomoc\u0105 w\u0142a\u015bnie route53, poniewa\u017c dzi\u0119ki kr\u00f3tkiemu ttl prze\u0142\u0105czenie nast\u0119puje w maksimum w ci\u0105gu 2, 3, 5 minut. <\/p>\n

Trzecie \u201eale\u201d<\/b>: co jeszcze nie jest zarezerwowane? S3, to prawda. Umieszczaj\u0105c pliki, kt\u00f3re przechowujemy u u\u017cytkownik\u00f3w w S3, szczerze wierzyli\u015bmy, \u017ce jest on niezawodny i nic tam nie trzeba rezerwowa\u0107. Ale historia pokazuje, \u017ce rzeczywisto\u015b\u0107 jest inna. W og\u00f3le, Amazon opisuje S3 jako podstawow\u0105 us\u0142ug\u0119, poniewa\u017c sam Amazon u\u017cywa S3 do przechowywania obraz\u00f3w maszyn, konfiguracji, obraz\u00f3w AMI, zrzut\u00f3w... I je\u015bli S3 pada, jak to mia\u0142o miejsce raz przez te 7 lat, kiedy eksploatujemy bitrix24, ci\u0105gnie ze sob\u0105 mn\u00f3stwo innych problem\u00f3w \u2014 niedost\u0119pno\u015b\u0107 uruchamiania wirtualek, awarie w dzia\u0142aniu api itd. <\/p>\n

S3 mo\u017ce r\u00f3wnie\u017c zawie\u015b\u0107 \u2014 tak zdarzy\u0142o si\u0119 kiedy\u015b. Dlatego doszli\u015bmy do nast\u0119puj\u0105cego wniosku: jeszcze kilka lat temu w Rosji nie by\u0142o powa\u017cnych publicznych obiektowych magazyn\u00f3w, a my rozwa\u017cali\u015bmy mo\u017cliwo\u015b\u0107 stworzenia czego\u015b w\u0142asnego... Na szcz\u0119\u015bcie nie zacz\u0119li\u015bmy tego robi\u0107, poniewa\u017c pogr\u0105\u017cyliby\u015bmy si\u0119 w ekspertyzie, kt\u00f3rej nie posiadamy, i z pewno\u015bci\u0105 pope\u0142niliby\u015bmy b\u0142\u0119dy. Obecnie magazyny zgodne z s3 dost\u0119pne s\u0105 w Mail.ru, Yandexie oraz u kilku innych dostawc\u00f3w. Ostatecznie doszli\u015bmy do wniosku, \u017ce chcemy mie\u0107, po pierwsze, replikacj\u0119, a po drugie, mo\u017cliwo\u015b\u0107 pracy z lokalnymi kopiami. Dla konkretnego regionu rosyjskiego korzystamy z us\u0142ugi Mail.ru Hotbox, kt\u00f3ra jest zgodna z s3 przez API. Nie potrzebowali\u015bmy \u017cadnych powa\u017cnych poprawek w kodzie aplikacji, wi\u0119c stworzyli\u015bmy nast\u0119puj\u0105cy mechanizm: w s3 s\u0105 wyzwalacze, kt\u00f3re uruchamiaj\u0105 si\u0119 przy tworzeniu\/usuni\u0119ciu obiekt\u00f3w, a Amazon ma taki serwis jak Lambda \u2014 to bezserwerowe uruchamianie kodu, kt\u00f3re wykona si\u0119 w\u0142a\u015bnie przy aktywacji tych lub innych wyzwalaczy.<\/p>\n

\"Bitrix24:
\n
\nZrobili\u015bmy to bardzo prosto: gdy wyzwalacz zostaje uruchomiony, wykonujemy kod, kt\u00f3ry skopiuje obiekt do magazynu Mail.ru. Aby w pe\u0142ni uruchomi\u0107 prac\u0119 z lokalnymi kopiami danych, potrzebujemy jeszcze synchronizacji zwrotnej, aby klienci z rosyjskiego segmentu mogli pracowa\u0107 z magazynem, kt\u00f3ry jest im bli\u017cej. Mail ma wkr\u00f3tce doko\u0144czy\u0107 wyzwalacze w swoim magazynie \u2014 b\u0119dzie mo\u017cna ju\u017c na poziomie infrastruktury realizowa\u0107 synchronizacj\u0119 zwrotn\u0105, ale na razie robimy to na poziomie naszego w\u0142asnego kodu. Je\u015bli widzimy, \u017ce klient umie\u015bci\u0142 jaki\u015b plik, to na poziomie naszego kodu umieszczamy zdarzenie w kolejce, przetwarzamy je i wykonujemy replikacj\u0119 zwrotn\u0105. Jest w tym jeden problem: je\u015bli zachodzi jaka\u015b operacja z naszymi obiektami poza naszym produktem, czyli za pomoc\u0105 jakich\u015b narz\u0119dzi zewn\u0119trznych, nie we\u017amiemy tego pod uwag\u0119. Dlatego czekamy na wyzwalacze na poziomie magazynu, aby niezale\u017cnie od tego, sk\u0105d uruchomili\u015bmy kod, obiekt, kt\u00f3ry do nas trafi\u0142, by\u0142 kopiowany w drug\u0105 stron\u0119. <\/p>\n

Na poziomie kodu dla ka\u017cdego klienta definiujemy oba magazyny: jeden uwa\u017cany jest za podstawowy, a drugi za zapasowy. Je\u015bli wszystko dzia\u0142a dobrze, korzystamy z magazynu, kt\u00f3ry jest nam bli\u017cej: czyli nasi klienci w Amazonie korzystaj\u0105 z S3, a ci, kt\u00f3rzy pracuj\u0105 w Rosji, korzystaj\u0105 z Hotbox. Gdy aktywuje si\u0119 sygna\u0142, musimy po\u0142\u0105czy\u0107 failover i prze\u0142\u0105czamy klient\u00f3w na inny magazyn. Sygna\u0142 ten mo\u017cemy ustawia\u0107 niezale\u017cnie w regionach i prze\u0142\u0105cza\u0107 ich w obie strony. W praktyce jeszcze z tego nie korzystali\u015bmy, ale mechanizm ten zosta\u0142 przewidziany i my\u015blimy, \u017ce kiedy\u015b ten proces prze\u0142\u0105czenia b\u0119dzie nam potrzebny i przydatny. Ju\u017c jeden raz si\u0119 to zdarzy\u0142o. <\/p>\n

Ojej, a tw\u00f3j Amazon uciek\u0142...<\/h4>\n

\nW tym kwietniu mija rocznica rozpocz\u0119cia blokad Telegramu w Rosji. Najbardziej poszkodowanym dostawc\u0105, kt\u00f3ry ucierpia\u0142 z tego powodu, jest Amazon. I, niestety, bardziej ucierpia\u0142y rosyjskie firmy, kt\u00f3re dzia\u0142a\u0142y na ca\u0142y \u015bwiat. <\/p>\n

Je\u015bli firma jest globalna, a Rosja dla niej to zaledwie ma\u0142y segment, 3-5% \u2014 to w ten czy inny spos\u00f3b mo\u017cna si\u0119 nimi po\u015bwi\u0119ci\u0107. <\/p>\n

Je\u015bli to firma wy\u0142\u0105cznie rosyjska \u2014 jestem pewien, \u017ce trzeba lokalizowa\u0107 si\u0119 \u2014 po prostu u\u017cytkownikom b\u0119dzie wygodniej, komfortowo, b\u0119dzie mniej ryzyk. <\/p>\n

A je\u015bli to firma dzia\u0142aj\u0105ca globalnie, i ma mniej wi\u0119cej r\u00f3wn\u0105 liczb\u0119 klient\u00f3w z Rosji i z innych cz\u0119\u015bci \u015bwiata? \u0141\u0105czno\u015b\u0107 segment\u00f3w jest wa\u017cna i powinny one w ten czy inny spos\u00f3b wsp\u00f3\u0142pracowa\u0107 ze sob\u0105. <\/p>\n

Na koniec marca 2018 roku Roskomnadzor wys\u0142a\u0142 do najwi\u0119kszych operator\u00f3w pismo, \u017ce planuj\u0105 zablokowa\u0107 kilka milion\u00f3w adres\u00f3w IP Amazon, aby zablokowa\u0107... komunikator Zello. Dzi\u0119kujemy tym dostawcom \u2014 skutecznie rozes\u0142ali pismo wszystkim, i pojawi\u0142o si\u0119 zrozumienie, \u017ce \u0142\u0105czno\u015b\u0107 z Amazonem mo\u017ce si\u0119 rozpa\u015b\u0107. To by\u0142 pi\u0105tek, w panice przybiegli\u015bmy do koleg\u00f3w z servers.ru, m\u00f3wi\u0105c: \u201ePrzyjaciele, potrzebujemy kilku serwer\u00f3w, kt\u00f3re nie b\u0119d\u0105 w Rosji, nie w Amazonie, lecz, na przyk\u0142ad, gdzie\u015b w Amsterdamie\u201d, aby m\u00f3c w jaki\u015b spos\u00f3b umie\u015bci\u0107 tam nasze. vpn<\/a> i proxy dla niekt\u00f3rych endpoint\u00f3w, na kt\u00f3re nie mo\u017cemy wp\u0142ywa\u0107, na przyk\u0142ad endpointy tego samego s3 \u2014 nie mo\u017cemy pr\u00f3bowa\u0107 uruchomi\u0107 now\u0105 us\u0142ug\u0119 i otrzyma\u0107 inny adres IP, musimy si\u0119 tam jako\u015b dosta\u0107. W ci\u0105gu kilku dni skonfigurowali\u015bmy te serwery, uruchomili\u015bmy je i og\u00f3lnie, na czas rozpocz\u0119cia blokad byli\u015bmy gotowi. Ciekawe, \u017ce RKN, patrz\u0105c na zamieszanie i wywo\u0142an\u0105 panik\u0119, powiedzia\u0142: \u201eNie, teraz niczego blokowa\u0107 nie b\u0119dziemy\u201d. (Ale to dok\u0142adnie do momentu, kiedy zacz\u0119li blokowa\u0107 Telegram.) Skonfigurowawszy mo\u017cliwo\u015bci omijania i zdaj\u0105c sobie spraw\u0119, \u017ce blokady nie wprowadzono, nie zaj\u0119li\u015bmy si\u0119 tym mimo wszystko. Tak, na wszelki wypadek. <\/p>\n

\"Bitrix24:
\n
\nAnd so, in 2019, we are indeed living under blocking conditions. Last night, I was watching: about a million IPs continue to be blocked. However, nearly all of Amazon has been unblocked, at the peak there were up to 20 million addresses\u2026 In general, the reality is that connectivity, good connectivity \u2014 may suddenly not be there. It may not be there for technical reasons \u2014 fires, excavators, all that. Or, as we have seen, not purely technical reasons. Therefore, someone big and large, with their own ASs, can probably manage this in other ways \u2014 direct connect and other things at the L2 level. But in the simple scenario, like us or even smaller, it's wise to have redundancy at the server level, set up somewhere else in advance, configured with VPNs, proxies, with the ability to quickly switch configurations in those segments that are critical for you in terms of connectivity. This has come in handy for us repeatedly when the Amazon blocks started; we used it in the worst case to send S3 traffic through them, but gradually it all unraveled.<\/p>\n

And how to back up\u2026 an entire provider?<\/h4>\n

\nObecnie nie mamy scenariusza na wypadek awarii ca\u0142ego Amazonu. Mamy podobny scenariusz dla Rosji. W Rosji wsp\u00f3\u0142pracowali\u015bmy z jednym dostawc\u0105, u kt\u00f3rego starali\u015bmy si\u0119 zapewni\u0107 kilka lokalizacji. Rok temu napotkali\u015bmy problem: nawet mimo \u017ce to by\u0142y dwa centra danych, ju\u017c na poziomie konfiguracji sieci dostawcy mog\u0105 wyst\u0105pi\u0107 problemy, kt\u00f3re dotkn\u0105 oba centra. Mo\u017cemy zatem do\u015bwiadczy\u0107 niedost\u0119pno\u015bci w obu lokalizacjach. Oczywi\u015bcie, tak si\u0119 sta\u0142o. W efekcie przemy\u015bleli\u015bmy architektur\u0119 wewn\u0119trzn\u0105. Nie zmieni\u0142a si\u0119 ona znacz\u0105co, ale w Rosji mamy teraz dwa lokalizacje, kt\u00f3re s\u0105 u dw\u00f3ch r\u00f3\u017cnych dostawc\u00f3w. Je\u015bli u jednego co\u015b zawiedzie, mo\u017cemy prze\u0142\u0105czy\u0107 si\u0119 na drugiego.<\/p>\n

Hipotetycznie rozwa\u017camy dla Amazon mo\u017cliwo\u015b\u0107 rezerwacji na poziomie innego dostawcy; mo\u017ce to by\u0107 Google, mo\u017ce jeszcze kto\u015b inny... Ale dotychczas obserwowali\u015bmy w praktyce, \u017ce gdy wyst\u0119puj\u0105 awarie w ramach jednej strefy dost\u0119pno\u015bci Amazon, awarie na poziomie ca\u0142ego regionu s\u0105 dosy\u0107 rzadkim zjawiskiem. Dlatego teoretycznie mamy wyobra\u017cenie o tym, \u017ce by\u0107 mo\u017ce zrobimy rezerwacj\u0119 'Amazon \u2014 nie Amazon', ale na razie na praktyce takiego nie ma. <\/p>\n

Kilka s\u0142\u00f3w o automatyzacji<\/h4>\n

\nCzy automatyzacja jest zawsze potrzebna? Warto tu przypomnie\u0107 efekt Dunninga-Krugera. Na osi 'x' mamy nasze wiedz\u0119 i do\u015bwiadczenie, a na osi 'y' \u2014 pewno\u015b\u0107 naszych dzia\u0142a\u0144. Najpierw nic nie wiemy i zupe\u0142nie nie jeste\u015bmy pewni. Nast\u0119pnie wiemy troch\u0119 i stajemy si\u0119 mega-pewni \u2014 to tzw. 'szczyt g\u0142upoty', dobrze ilustrowany obrazkiem 'g\u0142upota i odwaga'. Potem ju\u017c troch\u0119 si\u0119 nauczyli\u015bmy i jeste\u015bmy gotowi do dzia\u0142ania. Nast\u0119pnie natrafiamy na powa\u017cne problemy, wpadaj\u0105c w dolin\u0119 rozpaczy, kiedy wydaje si\u0119, \u017ce co\u015b wiemy, a w rzeczywisto\u015bci nie wiemy zbyt wiele. Nast\u0119pnie, wraz z nabieraniem do\u015bwiadczenia, stajemy si\u0119 coraz bardziej pewni siebie.<\/p>\n

\"Bitrix24:
\n
\nNasza logika dotycz\u0105ca r\u00f3\u017cnych prze\u0142\u0105cze\u0144 automatycznie w przypadku awarii dobrze opisuje ten wykres. Zacz\u0119li\u015bmy, nie umiej\u0105c nic, praktycznie wszystkie prace by\u0142y wykonywane r\u0119cznie. Potem zrozumieli\u015bmy, \u017ce mo\u017cna wszystko zautomatyzowa\u0107 i, jakby, spa\u0107 spokojnie. I nagle stajemy na mega-minie: mamy fa\u0142szywy alarm i prze\u0142\u0105czamy ruch tam i z powrotem, kiedy w rzeczywisto\u015bci nie powinno si\u0119 tego robi\u0107. W zwi\u0105zku z tym psuje si\u0119 replikacja lub co\u015b innego \u2013 oto ta dolina rozpaczy. A potem przychodzimy do zrozumienia, \u017ce do wszystkiego trzeba podchodzi\u0107 z rozwag\u0105. To znaczy, warto polega\u0107 na automatyce, przewiduj\u0105c mo\u017cliwo\u015b\u0107 fa\u0142szywego alarmu. Ale! je\u015bli konsekwencje mog\u0105 by\u0107 katastrofalne, lepiej pozostawi\u0107 to do oceny zespo\u0142u dy\u017curnego, in\u017cynierom dy\u017curnym, kt\u00f3rzy upewni\u0105 si\u0119, sprawdz\u0105, \u017ce faktycznie jest awaria i podejm\u0105 niezb\u0119dne dzia\u0142ania r\u0119cznie\u2026<\/p>\n

Podsumowanie<\/h4>\n

\nW ci\u0105gu 7 lat przeszli\u015bmy drog\u0119 od tego, \u017ce kiedy co\u015b si\u0119 psu\u0142o, panikowali\u015bmy, do zrozumienia, \u017ce problemy nie istniej\u0105 \u2013 s\u0105 tylko zadania, kt\u00f3re nale\u017cy rozwi\u0105zywa\u0107. Kiedy budujesz jaki\u015b serwis, sp\u00f3jrz na niego z g\u00f3ry, oce\u0144 wszystkie ryzyka, kt\u00f3re mog\u0105 si\u0119 wydarzy\u0107. Je\u015bli od razu je dostrzegasz \u2013 to przewiduj rezerwacj\u0119 i mo\u017cliwo\u015b\u0107 zbudowania infrastruktury odpornej na awarie, poniewa\u017c ka\u017cdy punkt, kt\u00f3ry mo\u017ce ulec awarii i doprowadzi\u0107 do niesprawno\u015bci serwisu \u2013 z pewno\u015bci\u0105 to zrobi. I nawet je\u015bli wydaje ci si\u0119, \u017ce niekt\u00f3re elementy infrastruktury na pewno nie zawiod\u0105 \u2013 jak na przyk\u0142ad s3, to i tak we\u017a pod uwag\u0119, \u017ce mog\u0105. I przynajmniej teoretycznie miej plan dzia\u0142ania w przypadku, gdyby co\u015b si\u0119 sta\u0142o. Miej plan zarz\u0105dzania ryzykiem. Gdy my\u015blisz o tym, \u017ceby wszystko robi\u0107 automatycznie lub r\u0119cznie \u2013 oce\u0144 ryzyko: co si\u0119 stanie, je\u015bli automatyka zacznie wszystko prze\u0142\u0105cza\u0107 \u2013 czy nie doprowadzi to do gorszej sytuacji w por\u00f3wnaniu do awarii? Mo\u017ce gdzie\u015b warto znale\u017a\u0107 rozs\u0105dny kompromis mi\u0119dzy automatyzacj\u0105 a reakcj\u0105 in\u017cyniera dy\u017curnego, kt\u00f3ry oceni rzeczywist\u0105 sytuacj\u0119 i zrozumie, czy co\u015b od razu nale\u017cy prze\u0142\u0105czy\u0107, czy \u201etak, ale nie teraz\u201d.<\/p>\n

Rozs\u0105dny kompromis mi\u0119dzy perfekcjonizmem a rzeczywistymi zasobami, czasem, pieni\u0119dzmi, kt\u00f3re mo\u017cesz wyda\u0107 na schemat, kt\u00f3ry w ko\u0144cu otrzymasz.<\/p>\n

Niniejszy tekst jest uzupe\u0142nion\u0105 i rozszerzon\u0105 wersj\u0105 wyst\u0105pienia Aleksandra Demidowa na konferencji Uptime dzien 4<\/a><\/noindex>.<\/i>
\n
\u0179r\u00f3d\u0142o: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u041d\u0430 \u0441\u0435\u0433\u043e\u0434\u043d\u044f\u0448\u043d\u0438\u0439 \u0434\u0435\u043d\u044c \u0443 \u0441\u0435\u0440\u0432\u0438\u0441\u0430 \u00ab\u0411\u0438\u0442\u0440\u0438\u043a\u044124\u00bb \u043d\u0435\u0442 \u0441\u043e\u0442\u0435\u043d \u0433\u0438\u0433\u0430\u0431\u0438\u0442 \u0442\u0440\u0430\u0444\u0438\u043a\u0430, \u043d\u0435\u0442 \u043e\u0433\u0440\u043e\u043c\u043d\u043e\u0433\u043e \u043f\u0430\u0440\u043a\u0430 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432 (\u0445\u043e\u0442\u044f \u0438 \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u0445, \u043a\u043e\u043d\u0435\u0447\u043d\u043e, \u043d\u0435\u043c\u0430\u043b\u043e). \u041d\u043e \u0434\u043b\u044f \u043c\u043d\u043e\u0433\u0438\u0445 \u043a\u043b\u0438\u0435\u043d\u0442\u043e\u0432 \u043e\u043d \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u043e\u0441\u043d\u043e\u0432\u043d\u044b\u043c \u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u043e\u043c \u0440\u0430\u0431\u043e\u0442\u044b \u0432 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438, \u044d\u0442\u043e \u043d\u0430\u0441\u0442\u043e\u044f\u0449\u0435\u0435 business-critical \u043f\u0440\u0438\u043b\u043e\u0436\u0435\u043d\u0438\u0435. \u041f\u043e\u044d\u0442\u043e\u043c\u0443 \u043f\u0430\u0434\u0430\u0442\u044c \u2014 \u043d\u0443, \u043d\u0438\u043a\u0430\u043a \u043d\u0435\u043b\u044c\u0437\u044f. \u0410 \u0447\u0442\u043e \u0435\u0441\u043b\u0438 \u043f\u0430\u0434\u0435\u043d\u0438\u0435 \u0432\u0441\u0435-\u0442\u0430\u043a\u0438 \u0441\u043b\u0443\u0447\u0438\u043b\u043e\u0441\u044c, \u043d\u043e \u00ab\u0432\u043e\u0441\u0441\u0442\u0430\u043b\u00bb \u0441\u0435\u0440\u0432\u0438\u0441 \u0442\u0430\u043a \u0431\u044b\u0441\u0442\u0440\u043e, \u0447\u0442\u043e \u043d\u0438\u043a\u0442\u043e \u043d\u0438\u0447\u0435\u0433\u043e \u0438 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":26389,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-35092","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47\u201eBitrix24\u201d: \u201eSzybko podniesione nie jest uwa\u017cane za opad\u0142e\u201d | ProHoster","description":"Na dzie\u0144 dzisiejszy us\u0142uga \u201eBitrix24\u201d nie dysponuje setkami gigabit\u00f3w ruchu, nie ma ogromnego parku serwer\u00f3w (chocia\u017c istniej\u0105cych, oczywi\u015bcie, jest mn\u00f3stwo).","canonical_url":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/bitriks24-bystro-podnyatoe-ne-schitaetsya-upavshim","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pl_PL","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u00ab\u0411\u0438\u0442\u0440\u0438\u043a\u044124\u00bb: \u00ab\u0411\u044b\u0441\u0442\u0440\u043e \u043f\u043e\u0434\u043d\u044f\u0442\u043e\u0435 \u043d\u0435 \u0441\u0447\u0438\u0442\u0430\u0435\u0442\u0441\u044f \u0443\u043f\u0430\u0432\u0448\u0438\u043c\u00bb | ProHoster","og:description":"\u041d\u0430 \u0441\u0435\u0433\u043e\u0434\u043d\u044f\u0448\u043d\u0438\u0439 \u0434\u0435\u043d\u044c \u0443 \u0441\u0435\u0440\u0432\u0438\u0441\u0430 \u00ab\u0411\u0438\u0442\u0440\u0438\u043a\u044124\u00bb \u043d\u0435\u0442 \u0441\u043e\u0442\u0435\u043d \u0433\u0438\u0433\u0430\u0431\u0438\u0442 \u0442\u0440\u0430\u0444\u0438\u043a\u0430, \u043d\u0435\u0442 \u043e\u0433\u0440\u043e\u043c\u043d\u043e\u0433\u043e \u043f\u0430\u0440\u043a\u0430 \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432 (\u0445\u043e\u0442\u044f \u0438 \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u044e\u0449\u0438\u0445, \u043a\u043e\u043d\u0435\u0447\u043d\u043e, \u043d\u0435\u043c\u0430\u043b\u043e).","og:url":"https:\/\/prohoster.info\/pl\/blog\/administrirovanie\/bitriks24-bystro-podnyatoe-ne-schitaetsya-upavshim","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:02:18+00:00","article:modified_time":"2019-10-31T19:02:18+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"35092","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-02-04 14:51:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:10:27","updated":"2026-02-04 14:51:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts\/35092","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/comments?post=35092"}],"version-history":[{"count":1,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts\/35092\/revisions"}],"predecessor-version":[{"id":156668,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/posts\/35092\/revisions\/156668"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/media\/26389"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/media?parent=35092"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/categories?post=35092"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pl\/wp-json\/wp\/v2\/tags?post=35092"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}