Dziś usługa Bitrix24 nie ma setek gigabitów ruchu ani nie ma ogromnej floty serwerów (choć oczywiście jest ich całkiem sporo). Jednak dla wielu klientów jest to główne narzędzie pracy w firmie, aplikacja o znaczeniu krytycznym dla biznesu. Dlatego nie ma mowy o upadku. A co jeśli awaria rzeczywiście miała miejsce, ale usługa „przywróciła działanie” tak szybko, że nikt nic nie zauważył? A jak można wdrożyć Failover bez utraty jakości pracy i liczby klientów? Alexander Demidov, dyrektor usług chmurowych w Bitrix24, opowiadał na naszym blogu o tym, jak ewoluował system rezerwacji na przestrzeni 7 lat istnienia produktu.
„Wprowadziliśmy Bitrix24 jako SaaS 7 lat temu. Główna trudność była prawdopodobnie następująca: zanim został udostępniony publicznie jako SaaS, produkt ten po prostu istniał w formie rozwiązania pudełkowego. Klienci kupili go od nas, hostowali na swoich serwerach, założyli portal korporacyjny - ogólne rozwiązanie do komunikacji pracowników, przechowywania plików, zarządzania zadaniami, CRM i to wszystko. A do 2012 roku zdecydowaliśmy, że chcemy uruchomić go jako SaaS, sami nim administrując, zapewniając odporność na awarie i niezawodność. Po drodze zdobywaliśmy doświadczenie, bo do tej pory go po prostu nie mieliśmy – byliśmy jedynie producentami oprogramowania, a nie usługodawcami.
Uruchamiając usługę zrozumieliśmy, że najważniejsze jest zapewnienie odporności na awarie, niezawodności i stałej dostępności usługi, bo jeśli masz prostą, zwykłą stronę internetową, np. sklep, to spada ona na Ciebie i siedzi tam przez godzinę, tylko ty cierpisz, tracisz zamówienia, tracisz klientów, ale dla samego twojego klienta nie jest to dla niego zbyt krytyczne. Oczywiście był zły, ale poszedł i kupił go w innym miejscu. A jeśli jest to aplikacja, na której opiera się cała praca w firmie, komunikacja, decyzje, to najważniejsze jest zdobyć zaufanie użytkowników, czyli ich nie zawieść i nie upaść. Ponieważ każda praca może zostać przerwana, jeśli coś w środku nie zadziała.
Bitrix.24 jako SaaS
Pierwszy prototyp zmontowaliśmy na rok przed publiczną premierą, w 2011 roku. Złożyliśmy go w około tydzień, obejrzeliśmy, kręciliśmy - nawet działał. Oznacza to, że możesz wejść do formularza, wpisać tam nazwę portalu, otworzy się nowy portal i utworzona zostanie baza użytkowników. Przyjrzeliśmy się temu, ogólnie oceniliśmy produkt, wyrzuciliśmy go na złom i udoskonalaliśmy przez cały rok. Ponieważ mieliśmy duże zadanie: nie chcieliśmy tworzyć dwóch różnych baz kodu, nie chcieliśmy wspierać osobnego produktu w pakiecie, osobnych rozwiązań chmurowych - chcieliśmy to wszystko zrobić w ramach jednego kodu.
Typową aplikacją webową w tamtych czasach był jeden serwer, na którym uruchamiany jest jakiś kod PHP, baza danych mysql, ładowane są pliki, dokumenty, zdjęcia umieszczane są w folderze upload - no cóż, wszystko działa. Niestety, przy użyciu tego nie da się uruchomić krytycznie stabilnej usługi internetowej. Tam rozproszona pamięć podręczna nie jest obsługiwana, replikacja bazy danych nie jest obsługiwana.
Sformułowaliśmy wymagania: jest to możliwość lokalizacji w różnych lokalizacjach, obsługa replikacji, a w idealnym przypadku lokalizacja w różnych geograficznie rozproszonych centrach danych. Oddziel logikę produktu i tak naprawdę przechowywanie danych. Możliwość dynamicznego skalowania w zależności od obciążenia i całkowita tolerancja statyki. Z tych rozważań wyłoniły się wymagania dotyczące produktu, które udoskonalaliśmy w ciągu roku. W tym czasie na platformie, która okazała się ujednolicona - dla rozwiązań pudełkowych, dla własnej usługi - wykonaliśmy wsparcie dla tych rzeczy, które były nam potrzebne. Wsparcie dla replikacji mysql na poziomie samego produktu: czyli programista piszący kod nie myśli o tym jak jego żądania zostaną rozdzielone, korzysta z naszego API, a my wiemy jak poprawnie rozdzielać żądania zapisu i odczytu pomiędzy masterami i niewolnicy.
Zapewniliśmy wsparcie na poziomie produktu dla różnych magazynów obiektów w chmurze: Google Storage, Amazon S3, a także obsługę Open Stack Swift. Dlatego było to wygodne zarówno dla nas jako usługi, jak i dla programistów, którzy pracują z rozwiązaniem w pakiecie: jeśli korzystają z naszego API tylko do pracy, nie myślą o tym, gdzie ostatecznie plik zostanie zapisany, lokalnie w systemie plików lub w magazynie plików obiektowych.
W rezultacie od razu zdecydowaliśmy, że dokonamy rezerwacji na poziomie całego data center. W 2012 roku wystartowaliśmy w całości na Amazon AWS, ponieważ mieliśmy już doświadczenie z tą platformą - hostowaliśmy tam naszą własną stronę internetową. Przyciągnął nas fakt, że w każdym regionie Amazon ma kilka stref dostępności – a właściwie (w swojej terminologii) kilka centrów danych, które są od siebie mniej więcej niezależne i pozwalają nam rezerwować na poziomie całego data center: jeśli nagle zawiedzie, bazy danych są replikowane w trybie master-master, tworzone są kopie zapasowe serwerów aplikacji internetowych, a dane statyczne są przenoszone do magazynu obiektowego s3. Obciążenie jest równoważone - w tamtym czasie przez Amazon Elb, ale nieco później doszliśmy do własnych systemów równoważenia obciążenia, ponieważ potrzebowaliśmy bardziej złożonej logiki.
Chcieli, to mają...
Wszystkie podstawowe rzeczy, które chcieliśmy zapewnić - odporność samych serwerów, aplikacji internetowych, baz danych - wszystko działało dobrze. Najprostszy scenariusz: jeśli zawiedzie któraś z naszych aplikacji webowych, to wszystko jest proste – zostają wyłączone z balansowania.
Balancer (wówczas był to łokieć Amazona) oznaczył niesprawne maszyny jako niezdrowe i wyłączył na nich rozkład obciążenia. Autoskalowanie Amazon zadziałało: gdy obciążenie wzrosło, do grupy autoskalowania dodano nowe maszyny, obciążenie zostało rozdzielone na nowe maszyny - wszystko było w porządku. W przypadku naszych balanserów logika jest mniej więcej taka sama: jeśli coś stanie się z serwerem aplikacji, usuwamy z niego żądania, wyrzucamy te maszyny, uruchamiamy nowe i kontynuujemy pracę. Schemat zmienił się nieco na przestrzeni lat, ale nadal działa: jest prosty, zrozumiały i nie ma z nim żadnych trudności.
Pracujemy na całym świecie, szczyty obciążenia u klientów są zupełnie inne i w sposób polubowny powinniśmy móc w każdej chwili przeprowadzić określone prace serwisowe na dowolnych elementach naszego systemu - niezauważenie przez klientów. Mamy zatem możliwość wyłączenia bazy danych z działania, redystrybuując obciążenie na drugie centrum danych.
Jak to wszystko działa? — Przekierowujemy ruch na działające centrum danych – jeżeli w centrum danych nastąpi awaria, to całkowicie, jeśli taka jest nasza planowana praca z jedną bazą danych, wówczas przekierowujemy część ruchu obsługującego tych klientów do drugiego centrum danych, zawieszając to replikacja. Jeśli do aplikacji internetowych potrzebne będą nowe maszyny ze względu na zwiększone obciążenie drugiego centrum danych, zostaną one uruchomione automatycznie. Kończymy pracę, replikacja zostaje przywrócona i zwracamy cały ładunek z powrotem. Jeśli potrzebujemy odzwierciedlić jakąś pracę w drugim DC, na przykład zainstalować aktualizacje systemu lub zmienić ustawienia w drugiej bazie danych, to generalnie powtarzamy to samo, tylko w drugą stronę. A jeśli to wypadek, to robimy wszystko banalnie: wykorzystujemy mechanizm obsługi zdarzeń w systemie monitorującym. Jeśli zostanie uruchomionych kilka kontroli i status osiągnie krytyczny, wówczas uruchamiamy tę procedurę obsługi, która może wykonać tę lub inną logikę. Dla każdej bazy danych określamy, który serwer ma być dla niej przełączany awaryjnie i gdzie należy przełączyć ruch, jeśli jest on niedostępny. Historycznie rzecz biorąc, używamy nagios lub niektórych jego rozwidleń w takiej czy innej formie. W zasadzie podobne mechanizmy istnieją niemal w każdym systemie monitoringu, na razie nie stosujemy niczego bardziej skomplikowanego, ale może kiedyś to zrobimy. Teraz monitorowanie jest uruchamiane w przypadku niedostępności i ma możliwość przełączenia czegoś.
Czy zarezerwowaliśmy wszystko?
Mamy wielu klientów z USA, wielu klientów z Europy, wielu klientów bliżej Wschodu - Japonię, Singapur i tak dalej. Oczywiście ogromna część klientów znajduje się w Rosji. Oznacza to, że praca nie jest w jednym regionie. Użytkownicy chcą szybkiej reakcji, istnieją wymagania dotyczące zgodności z różnymi lokalnymi przepisami, a w każdym regionie rezerwujemy dwa centra danych, a ponadto istnieją dodatkowe usługi, które z kolei wygodnie jest umieścić w jednym regionie - dla klientów znajdujących się w ten region działa. Procedury obsługi REST, serwery autoryzacji, są mniej krytyczne dla działania klienta jako całości, możesz się między nimi przełączać z niewielkim akceptowalnym opóźnieniem, ale nie chcesz wymyślać koła na nowo, jak je monitorować i co robić z nimi. Dlatego staramy się maksymalnie wykorzystać istniejące rozwiązania, zamiast rozwijać jakieś kompetencje w dodatkowych produktach. A gdzieś banalnie używamy przełączania na poziomie DNS i określamy żywotność usługi przez ten sam DNS. Amazon ma usługę Route 53, ale to nie tylko DNS, w którym możesz wprowadzać wpisy i to wszystko — jest znacznie bardziej elastyczny i wygodny. Dzięki niemu możesz budować usługi rozproszone geograficznie z geolokalizacją, wykorzystując je do ustalenia, skąd pochodzi klient i przekazania mu określonych rekordów - z jego pomocą możesz budować architektury awaryjne. Te same kontrole stanu są skonfigurowane w samej Route 53, ustawiasz monitorowane punkty końcowe, ustawiasz metryki, ustawiasz protokoły w celu określenia „aktywności” usługi - tcp, http, https; ustaw częstotliwość kontroli, które określają, czy usługa działa, czy nie. A w samym DNS określasz, co będzie pierwotne, co będzie wtórne, gdzie się przełączyć, jeśli kontrola stanu zostanie uruchomiona na trasie 53. Wszystko to można zrobić za pomocą innych narzędzi, ale dlaczego jest to wygodne - ustawiamy to raz, a potem w ogóle o tym nie myśl, jak sprawdzamy, jak przełączamy: wszystko działa samo.
Pierwsze „ale”: jak i czym zarezerwować samą trasę 53? Kto wie, co jeśli coś mu się stanie? Na szczęście nigdy nie nadepnęliśmy na te grabie, ale znowu będę miał przed sobą historię, dlaczego pomyśleliśmy, że nadal musimy dokonać rezerwacji. Tutaj z góry rozłożyliśmy dla siebie słomki. Kilka razy dziennie wykonujemy całkowity rozładunek wszystkich stref jakie posiadamy na trasie 53. API Amazona umożliwia łatwe wysyłanie ich w formacie JSON, a my mamy kilka serwerów kopii zapasowych, na których je konwertujemy, przesyłamy w formie konfiguracji i mamy, z grubsza rzecz biorąc, konfigurację kopii zapasowej. Jeśli coś się stanie, możemy szybko wdrożyć to ręcznie, nie tracąc danych ustawień DNS.
Drugie „ale”: Co na tym zdjęciu nie zostało jeszcze zarezerwowane? Sam balanser! Nasz podział klientów według regionów jest bardzo prosty. Mamy domeny bitrix24.ru, bitrix24.com, .de - obecnie jest ich 13 różnych, które działają w różnych strefach. Doszliśmy do następującego wniosku: każdy region ma swoje własne balansery. Ułatwia to dystrybucję między regionami, w zależności od tego, gdzie występuje szczytowe obciążenie sieci. Jeśli jest to awaria na poziomie pojedynczego balansera, wówczas jest on po prostu wyłączany z eksploatacji i usuwany z DNS. Jeśli jest jakiś problem z grupą balanserów, to są one kopiowane na innych stronach, a przełączanie między nimi odbywa się tą samą trasą53, ponieważ ze względu na krótki TTL, przełączanie następuje w ciągu maksymalnie 2, 3, 5 minut .
Trzecie „ale”: Co nie jest jeszcze zarezerwowane? S3, zgadza się. Kiedy umieściliśmy w s3 pliki, które przechowujemy dla użytkowników, szczerze wierzyliśmy, że jest to sprzęt przeciwpancerny i nie ma potrzeby tam niczego rezerwować. Historia pokazuje jednak, że bywa różnie. Ogólnie rzecz biorąc, Amazon opisuje S3 jako usługę podstawową, ponieważ sam Amazon używa S3 do przechowywania obrazów maszyn, konfiguracji, obrazów AMI, migawek... A jeśli s3 ulegnie awarii, co zdarzyło się raz w ciągu tych 7 lat, tak długo jak korzystamy bitrix24, podąża za tym jak fan. Pojawia się cała masa rzeczy – niemożność uruchomienia maszyn wirtualnych, awaria interfejsu API i tak dalej.
A S3 może upaść - raz się to zdarzyło. Dlatego doszliśmy do następującego schematu: kilka lat temu w Rosji nie było poważnych obiektów do składowania obiektów publicznych i rozważaliśmy możliwość zrobienia czegoś własnego... Na szczęście nie zaczęliśmy tego robić, bo zagłębiliśmy się w wiedzę specjalistyczną, której nie mamy, i prawdopodobnie nawalilibyśmy. Teraz Mail.ru ma pamięć kompatybilną z s3, ma ją Yandex i wielu innych dostawców. W końcu doszliśmy do wniosku, że chcemy mieć po pierwsze kopię zapasową, a po drugie możliwość pracy z kopiami lokalnymi. Specjalnie dla regionu rosyjskiego korzystamy z usługi Mail.ru Hotbox, która jest zgodna z interfejsem API s3. Nie potrzebowaliśmy większych modyfikacji kodu wewnątrz aplikacji i stworzyliśmy następujący mechanizm: w s3 znajdują się wyzwalacze wyzwalające tworzenie/usuwanie obiektów, Amazon posiada usługę o nazwie Lambda - jest to bezserwerowe uruchamianie kodu który zostanie wykonany właśnie wtedy, gdy zostaną uruchomione określone wyzwalacze.
Zrobiliśmy to bardzo prosto: jeśli nasz wyzwalacz zostanie uruchomiony, wykonujemy kod, który skopiuje obiekt do magazynu Mail.ru. Aby w pełni uruchomić pracę z lokalnymi kopiami danych, potrzebujemy także odwrotnej synchronizacji, aby klienci będący w segmencie rosyjskim mogli pracować z bliższą im pamięcią masową. Poczta wkrótce zakończy wyzwalanie w swojej pamięci - synchronizację wsteczną będzie można wykonać na poziomie infrastruktury, ale na razie robimy to na poziomie własnego kodu. Jeśli widzimy, że klient zamieścił plik, to na poziomie kodu umieszczamy zdarzenie w kolejce, przetwarzamy je i wykonujemy replikację odwrotną. Dlaczego to jest złe: jeśli wykonujemy jakąś pracę z naszymi przedmiotami poza naszym produktem, czyli w jakiś zewnętrzny sposób, nie bierzemy tego pod uwagę. Czekamy więc do końca, kiedy na poziomie magazynu pojawią się wyzwalacze, aby niezależnie od tego, skąd wykonamy kod, obiekt, który do nas przyszedł, został skopiowany w drugą stronę.
Na poziomie kodu rejestrujemy dla każdego klienta oba magazyny: jeden jest uważany za główny, drugi za zapasowy. Jeśli wszystko jest w porządku, pracujemy z magazynem, który jest bliżej nas: czyli nasi klienci, którzy są w Amazonie, pracują z S3, a ci, którzy pracują w Rosji, pracują z Hotboxem. Jeśli flaga zostanie wyzwolona, należy włączyć przełączanie awaryjne i przełączamy klientów na inny magazyn. Możemy zaznaczyć to pole niezależnie od regionu i przełączać je tam i z powrotem. Nie stosowaliśmy jeszcze tego w praktyce, ale przewidzieliśmy taki mechanizm i uważamy, że kiedyś ten właśnie przełącznik będzie nam potrzebny i się przyda. To już się kiedyś zdarzyło.
No i Amazon uciekł...
W kwietniu tego roku przypada rocznica rozpoczęcia blokowania Telegramu w Rosji. Najbardziej dotkniętym dostawcą, który podlega tej sytuacji, jest Amazon. I niestety bardziej ucierpiały rosyjskie firmy, które pracowały dla całego świata.
Jeśli firma ma charakter globalny, a Rosja to dla niej bardzo mały segment, 3-5% - cóż, w ten czy inny sposób, możesz je poświęcić.
Jeśli jest to firma czysto rosyjska – jestem pewien, że musi być zlokalizowana lokalnie – cóż, będzie po prostu wygodna dla samych użytkowników, wygodna i będzie mniejsze ryzyko.
A co jeśli jest to firma działająca globalnie i mająca w przybliżeniu taką samą liczbę klientów z Rosji i z całego świata? Łączność segmentów jest ważna i muszą one ze sobą współpracować w ten czy inny sposób.
Pod koniec marca 2018 roku Roskomnadzor wysłał do największych operatorów pismo, w którym poinformował, że planują zablokować kilka milionów adresów IP Amazona, aby zablokować… komunikator Zello. Dzięki tym samym dostawcom udało im się wycieknąć list do wszystkich i panowało zrozumienie, że połączenie z Amazonem może się rozpaść. Był piątek, w panice pobiegliśmy do naszych kolegów z serwerów.ru, mówiąc: „Przyjaciele, potrzebujemy kilku serwerów, które będą zlokalizowane nie w Rosji, nie w Amazonie, ale na przykład gdzieś w Amsterdamie”, aby aby móc chociaż w jakiś sposób zainstalować tam własną VPN i proxy dla niektórych punktów końcowych, na które nie mamy żadnego wpływu, np. punkty końcowe tego samego s3 - nie możemy próbować podnieść nowej usługi i uzyskać inne IP, nadal musisz się tam dostać. W ciągu zaledwie kilku dni skonfigurowaliśmy te serwery, uruchomiliśmy je i ogólnie przygotowaliśmy się na moment rozpoczęcia blokowania. Ciekawe, że RKN, patrząc na zamieszanie i panikę, powiedział: „Nie, teraz niczego nie będziemy blokować”. (Ale tak było dokładnie do momentu, kiedy zaczęto blokować Telegram.) Po skonfigurowaniu możliwości obejścia i zdając sobie sprawę, że blokowanie nie zostało wprowadzone, nie zaczęliśmy jednak porządkować całej sprawy. Tak, na wszelki wypadek.
A w 2019 roku nadal żyjemy w warunkach blokowania. Sprawdziłem wczoraj wieczorem: około miliona adresów IP jest nadal zablokowanych. To prawda, Amazon został prawie całkowicie odblokowany, w szczytowym momencie osiągnął 20 milionów adresów... Ogólnie rzecz biorąc, rzeczywistość jest taka, że może nie być spójności, dobrej spójności. Nagle. Może nie istnieć z powodów technicznych – pożary, koparki i tak dalej. Lub, jak widzieliśmy, nie do końca techniczne. Zatem ktoś duży i duży, posiadający własne AS-y, zapewne poradzi sobie z tym w inny sposób - bezpośrednie połączenie i inne rzeczy są już na poziomie l2. Ale w wersji prostej, takiej jak nasza lub jeszcze mniejsza, można na wszelki wypadek mieć redundancję na poziomie serwerów wyniesionych gdzie indziej, skonfigurowanych wcześniej VPN, proxy, z możliwością szybkiego przełączenia na nie konfiguracji w tych segmentach które są krytyczne dla Twojej łączności. Przydało się to nam nie raz, gdy zaczęło się blokowanie Amazona; w najgorszym przypadku pozwoliliśmy przez nie przepuszczać tylko ruch S3, ale stopniowo wszystko zostało rozwiązane.
Jak zarezerwować... całego dostawcę?
W tej chwili nie mamy scenariusza na wypadek upadku całego Amazona. Podobny scenariusz mamy dla Rosji. W Rosji byliśmy hostowani przez jednego dostawcę, od którego wybraliśmy kilka witryn. A rok temu stanęliśmy przed problemem: mimo że są to dwa centra danych, już na poziomie konfiguracji sieci dostawcy mogą pojawić się problemy, które w dalszym ciągu będą dotyczyły obu centrów danych. I możemy stać się niedostępni w obu witrynach. Oczywiście, że tak się stało. Skończyło się na ponownym rozważeniu architektury wnętrza. Nie zmieniło się to zbytnio, ale dla Rosji mamy teraz dwie witryny, które nie pochodzą od tego samego dostawcy, ale od dwóch różnych. Jeśli jedno zawiedzie, możemy przejść na drugie.
Hipotetycznie dla Amazona rozważamy możliwość rezerwacji na poziomie innego dostawcy; może Google, może ktoś inny... Ale jak dotąd zaobserwowaliśmy w praktyce, że o ile Amazonowi zdarzają się wypadki na poziomie jednej strefy dostępności, o tyle wypadki na poziomie całego regionu zdarzają się dość rzadko. Dlatego teoretycznie mamy pomysł, że moglibyśmy dokonać rezerwacji „Amazon to nie Amazon”, ale w praktyce jeszcze tak nie jest.
Kilka słów o automatyzacji
Czy automatyzacja jest zawsze konieczna? W tym miejscu warto przypomnieć efekt Dunninga-Krugera. Na osi „x” znajduje się nasza wiedza i doświadczenie, które zdobywamy, a na osi „y” pewność naszych działań. Na początku nic nie wiemy i nie jesteśmy wcale pewni. Wtedy już trochę wiemy i stajemy się mega pewni siebie – to tzw. „szczyt głupoty”, który dobrze ilustruje obraz „demencja i odwaga”. Potem nauczyliśmy się trochę i jesteśmy gotowi do bitwy. Wtedy popełniamy megapoważne błędy i wpadamy w dolinę rozpaczy, kiedy wydaje nam się, że coś wiemy, ale tak naprawdę nie wiemy zbyt wiele. Następnie, w miarę zdobywania doświadczenia, stajemy się bardziej pewni siebie.
Naszą logikę dotyczącą różnych automatycznych wyłączników w przypadku określonych wypadków bardzo dobrze opisuje ten wykres. Zaczęliśmy – nie wiedzieliśmy jak się do czegokolwiek zabrać, prawie całą pracę wykonywaliśmy ręcznie. Wtedy zdaliśmy sobie sprawę, że możemy do wszystkiego dopiąć automatyzację i jakoś spać spokojnie. I nagle wkraczamy w mega-rake: uruchamiany jest fałszywy alarm i przełączamy ruch tam i z powrotem, gdy w dobrym tego słowa znaczeniu nie powinniśmy byli tego robić. W rezultacie replikacja załamuje się lub coś innego – to jest właśnie dolina rozpaczy. I wtedy dochodzimy do zrozumienia, że do wszystkiego trzeba podejść mądrze. Oznacza to, że warto polegać na automatyzacji, zapewniając możliwość fałszywych alarmów. Ale! jeśli skutki mogą być opłakane, to lepiej zostawić to dyżurnej zmianie, dyżurującym inżynierom, którzy upewnią się i będą monitorować, czy rzeczywiście doszło do wypadku, a niezbędne czynności wykonają ręcznie...
wniosek
W ciągu 7 lat przeszliśmy od faktu, że jak coś spadło, była panika-panika, do zrozumienia, że problemów nie ma, są tylko zadania, które trzeba – i można – rozwiązać. Budując usługę, spójrz na nią z góry, oceń wszystkie ryzyka, które mogą się wydarzyć. Jeśli widzisz je od razu, to zawczasu zapewnij redundancję i możliwość zbudowania infrastruktury odpornej na awarie, bo każdy punkt, który może zawieść i doprowadzić do niesprawności usługi, na pewno to zrobi. I nawet jeśli wydaje Ci się, że niektóre elementy infrastruktury na pewno nie zawiodą – jak samo s3, to mimo wszystko pamiętaj, że mogą. I przynajmniej teoretycznie miej pomysł, co z nimi zrobisz, jeśli coś się stanie. Miej plan zarządzania ryzykiem. Kiedy myślisz o zrobieniu wszystkiego automatycznie lub ręcznie, oceń ryzyko: co się stanie, jeśli automatyka zacznie wszystko przełączać – czy nie doprowadzi to do jeszcze gorszej sytuacji w porównaniu z wypadkiem? Być może gdzieś trzeba zastosować rozsądny kompromis pomiędzy zastosowaniem automatyki a reakcją dyżurującego inżyniera, który oceni rzeczywisty obraz i zrozumie, czy trzeba coś przełączyć na miejscu, czy „tak, ale nie teraz”.
Rozsądny kompromis pomiędzy perfekcjonizmem a prawdziwym wysiłkiem, czasem, pieniędzmi, które możesz przeznaczyć na plan, który ostatecznie będziesz miał.
Niniejszy tekst stanowi zaktualizowaną i rozszerzoną wersję raportu Aleksandra Demidowa z konferencji .
Źródło: www.habr.com