100% czasu działania aplikacji internetowej

312

Otrzymaliśmy dziś interesujący „wymóg” od klienta.

Chcą 100% czasu pracy bez wyłączania awaryjnego w aplikacji internetowej. Z punktu widzenia naszej aplikacji internetowej nie stanowi to problemu. Został zaprojektowany, aby móc skalować na wiele serwerów baz danych itp.

Jednak z powodu problemu z siecią po prostu nie mogę zrozumieć, jak to zrobić.

Krótko mówiąc, aplikacja będzie działać na serwerach w sieci klienta. Jest dostępny zarówno dla osób wewnętrznych, jak i zewnętrznych. Chcą, abyśmy utrzymywali kopię systemu poza witryną, która w przypadku poważnej awarii w ich obiektach natychmiast przejmie i przejmie kontrolę.

Teraz wiemy, że absolutnie nie ma możliwości rozwiązania tego problemu dla ludzi wewnętrznych (gołębi pocztowych?), Ale chcą, aby użytkownicy zewnętrzni nawet tego nie zauważyli.

Szczerze mówiąc, nie mam najmniejszego pojęcia, jak to możliwe. Wygląda na to, że jeśli utracą łączność z Internetem, będziemy musieli dokonać zmiany DNS, aby przekazywać ruch do urządzeń zewnętrznych ... Co oczywiście wymaga czasu.

Pomysły?

AKTUALIZACJA

Dzisiaj rozmawiałem z klientem, który wyjaśnił sprawę.

Utknęli przy wartości 100%, mówiąc, że aplikacja powinna pozostać aktywna nawet w przypadku powodzi. Jednak wymóg ten pojawia się tylko wtedy, gdy go hostujemy. Powiedzieli, że poradzą sobie z czasem przestoju, jeśli aplikacja będzie działać całkowicie na swoich serwerach. Możesz odgadnąć moją odpowiedź.

Nie ja
źródło
49
Nie lekceważ ogromnego przestoju spowodowanego hakowaniem, spójrz na Sony i sieć PlayStation. możesz zagwarantować, że mieli ten sam pomysł 100% czasu pracy i pieniądze / sprzęt, aby to zrobić. wyjaśnij klientowi, że 100% dyspozycyjności jest nierealnym oczekiwaniem, nawet technicy Google wahaliby się, mrucząc „100% dyspozycyjności”. wskazówka btw polega na użyciu dynamicznego DNS, buforują one tylko przez 60 sekund, powinno to obejmować system operacyjny i lokalne serwery DNS.
Silverfire,
182
Osobiście URUCHOMIŁEM od tego klienta tak szybko, jak to możliwe. Podejrzewam, że nie będzie to ostatni szalony pomysł, jaki mogą mieć (z technologicznego punktu widzenia).
GregD
137
Chciałbym móc głosować za twoim klientem.
joeqwerty
81
Jeśli wymyślisz 100% czasu pracy, daj mi znać. Stworzę z nim firmę i sprzedam google. Nie można zagwarantować 100%. Nawet firmy takie jak Microsoft, Amazon czy Google nie pójdą tak wysoko, ponieważ wiedzą, że to niemożliwe. Najlepsze, co widziałem, to 99,999%, a nawet to jest odcinek (5 minut w roku). Najlepsze, co możesz zrobić, to niezawodnie 99,99%.
Matt
39
Wystarczy stworzyć niesamowicie wysoką cenę, aby złożyć szaloną prośbę. To prawdopodobnie przywróci im zmysły. Albo, albo wyśle ​​ich w poszukiwaniu kogoś, kto będzie chciał ich okłamać.
Nate CK,

Odpowiedzi:

368

Oto przydatna tabela Wikipedii w poszukiwaniu dziewiątek:

wprowadź opis zdjęcia tutaj

Co ciekawe, tylko 3 z 20 najlepszych stron internetowych były w stanie osiągnąć mityczną liczbę 5 dziewiątek lub 99,999% czasu sprawności w 2007 roku. Były to Yahoo, AOL i Comcast. W pierwszych 4 miesiącach 2008 r. Niektóre z najpopularniejszych sieci społecznościowych nawet się do tego nie zbliżały.

Z wykresu powinno być oczywiste, jak absurdalne jest dążenie do 100% czasu pracy ...

GregD
źródło
62
Pingdom również nie sprawdza się co sekundę. Co więcej, te, które spełniły pięć dziewiątek, prawdopodobnie nadal miały zlokalizowane zakłócenia, których Pingdom mógł nie wykryć, lub usterki, które sprawiły, że niektóre usługi były niedostępne podczas odpowiedzi na pingi.
ceejayoz
8
Co samo w sobie powoduje, że pięć dziewiątek
budzi
5
Dokładnie. I mają miliardy dolarów do pracy!
ceejayoz
43
Przepraszam, że przeszkadzam w trwającym czacie, ale pytanie OP dotyczyło sposobu, w jaki należy dążyć do celu 100% czasu sprawności na poziomie technicznym, nie koncepcyjnie, jestem pewien, że wie, że nie zawsze jest to możliwe z powodu naturalnych zdarzeń, które zdarzają się w sprzęcie i środowisko. Czy możemy mu w tym pomóc?
David d C e Freitas
5
Do OP: widziałem umowy SLA, które gwarantowały czas sprawności w kontekście „poza normalną konserwacją”. Normalną konserwacją jest oczywiście planowane przestoje na miesiąc dla aktualizacji, poprawek itp., Które zwykle występują w ich najmniej pracowitym dniu w miesiącu w najmniej obciążonych porach miesiąca (zwykle w środku nocy). Muszą mieć pewien rodzaj wskaźników dla swojej firmy w odniesieniu do biznesu. Państwo mogli zaoferować lepszą uptime (4 dziewiątek) dla nich tylko w tamtych czasach.
GregD
186

Poproś, aby zdefiniowali 100% i jak będą mierzone W jakim okresie. Prawdopodobnie oznaczają one prawie 100%, jak mogą sobie pozwolić. Podaj koszty.

Opracować. Przez lata rozmawiałem z klientami o rzekomo absurdalnych wymaganiach. We wszystkich przypadkach używali po prostu nieprecyzyjnego języka.

Dość często przedstawiają elementy w sposób, który wydaje się bezwzględny - na przykład 100%, ale w rzeczywistości przy głębszych badaniach są wystarczająco rozsądne, aby przeprowadzić analizy kosztów i korzyści, które są wymagane, gdy są przedstawiane z kosztorysowaniem danych ograniczających ryzyko. Pytanie o to, jak zmierzą dostępność, jest kluczowym pytaniem. Jeśli nie wiedzą o tym, jesteś w stanie zasugerować im, że należy to najpierw zdefiniować.

Poprosiłbym klienta, aby określił, co by się stało pod względem wpływu / kosztów biznesowych, gdyby witryna uległa awarii w następujących okolicznościach:

  • W najbardziej ruchliwych godzinach x godzin
  • W ich najmniej pracowitych godzinach przez x godzin

A także, jak to zmierzą.

W ten sposób możesz z nimi współpracować w celu ustalenia właściwego poziomu „100%”. Podejrzewam, że zadając tego rodzaju pytania, będą mogli lepiej określić priorytety innych wymagań. Na przykład mogą chcieć zapłacić określone poziomy SLA i naruszyć inne funkcje, aby to osiągnąć.

Preet Sangha
źródło
21
Zgoda. Mogą po prostu oznaczać „bardzo wysoki” czas pracy (górne lata 90-te?) Przy dość solidnej strategii przełączania awaryjnego. Jeśli nie, to wyjaśnienie skali kosztów miałoby ich przekonać ...
Martin Dow
32
+1 za to, że nie wyciąga pochopnych wniosków i zamiast tego prosi klienta o wyjaśnienie, co mają na myśli.
sleske
4
Powtarzam zdanie „nie przeskakiwanie do wniosków” ... jeśli klient oznacza 100% czasu sprawności (minus zaplanowana konserwacja), może to być bardziej uzasadniony wymóg.
Tim Reddy,
1
Jeśli chodzi o wpływ na działalność, faktycznie znamy i rozumiemy ich działalność, a koszty związane z upadkiem witryny nie są finansowe. Więcej wzdłuż tubylców pokazujących widły, potencjalne zawieszki itp.;) Wyobraź sobie, jak 40 000 ludzi pojawia się przy twoich drzwiach i krzyczy. Tego chcą z pasją unikać.
NotMe
7
@ChrisLively Tym bardziej należy rozumieć ryzyko. Dominującym paradygmatem inżynierii bezpieczeństwa jest probabilistyczna ocena ryzyka . Istnieją systemy, które mogą zabić (nie tylko irytować) tysiące ludzi i nadal mają niskie, miejmy nadzieję, dobrze zrozumiane, ale niezerowe prawdopodobieństwo awarii.
poolie
140

Twoi klienci są szaleni. 100% czasu sprawności jest niemożliwe bez względu na to, ile pieniędzy na to wydasz. Prosty i prosty - niemożliwy. Spójrz na Google, Amazon itp. Mają prawie nieskończoną ilość pieniędzy, które mogą rzucić na swoją infrastrukturę, a mimo to nadal mają przestoje. Musisz przekazać im tę wiadomość, a jeśli nadal będą nalegać, by stawiać rozsądne wymagania. Jeśli nie rozpoznają, że pewne przestoje są nieuniknione, to porzuć je.

To powiedziawszy, wydaje się, że masz mechanikę skalowania / dystrybucji samej aplikacji. Część sieciowa będzie musiała obejmować nadmiarowe łącza zwrotne do różnych dostawców usług internetowych, uzyskiwanie ASN i przydziału adresów IP, a także uzyskanie głębokiego dostępu do BGP i rzeczywistego sprzętu do routingu, aby przestrzeń adresów IP mogła w razie potrzeby przemieszczać się między dostawcami usług internetowych.

Jest to, oczywiście, bardzo zwięzła odpowiedź. Nie masz doświadczenia z aplikacjami wymagającymi takiego stopnia bezawaryjności, więc naprawdę musisz zaangażować profesjonalistę, jeśli chcesz zbliżyć się do mitycznego 100% czasu sprawności.

EEAA
źródło
7
Zgoda. Całkowicie. Zwariowany.
jdw
2
oni kiedyś ??
Sirex,
2
@Sirex Odnosząc się do ostatniego eksperymentu @ CERN, w którym stwierdzono, że neutrina podróżują szybciej niż światło. Jednak wyniki muszą jeszcze zostać potwierdzone przez niezależnych naukowców.
TC1,
9
@ TC1 Założę się o 200 $, które się nie mieszczą.
dpatchery
4
@ErikA Wniosek o 100% czasu sprawności wskazuje na nieznajomość parametrów technicznych systemów. W porządku, ponieważ zadaniem klienta jest robienie tego, co robi. Twoim zadaniem jest projektowanie systemów informatycznych. Tacy trudni klienci mogą być koszmarami, ale mogą też stać się Twoimi najlepszymi klientami.
duffbeer703
54

To zdecydowanie interesujące. Nie jestem pewien, czy chciałbym się zobowiązać umownie do 100% czasu sprawności, ale gdybym musiał, sądzę, że wyglądałoby to tak:

Rozpocznij od publicznego adresu IP modułu równoważenia obciążenia całkowicie poza siecią i zbuduj co najmniej dwa z nich, aby jeden mógł przejść do drugiego. Program taki jak Heatbeart może pomóc w automatycznym przełączaniu awaryjnym tych programów.

Lakier jest znany przede wszystkim jako rozwiązanie buforujące, ale ma również bardzo przyzwoite równoważenie obciążenia. Być może byłby to dobry wybór do obsługi równoważenia obciążenia. Można go skonfigurować tak, aby backendy 1 do n były opcjonalnie pogrupowane w reżyserach, które będą ładowały równowagę losowo lub w trybie round-robin. Lakier może być wystarczająco inteligentny, aby sprawdzić zdrowie każdego zaplecza i upuścić niezdrowe tylne końce z pętli, dopóki nie wróci online. Zaplecze nie musi być w tej samej sieci.

Jestem trochę zakochany w elastycznych adresach IP w Amazon EC2, więc prawdopodobnie zbudowałbym moduły równoważące obciążenie w EC2 w różnych regionach lub przynajmniej w różnych strefach dostępności w tym samym regionie. To dałoby ci opcję ręcznego (boskiego zabrania) rozkręcenia nowego modułu równoważenia obciążenia, gdybyś musiał i przeniesienie istniejącego adresu IP rekordu A do nowego pola.

Lakier nie może jednak zakończyć SSL, więc jeśli jest to problem, możesz zamiast tego spojrzeć na coś takiego jak Nginx.

Możesz mieć większość swoich backendów w sieci klientów i jeden lub więcej poza ich siecią. Wierzę, ale nie jestem w 100% pewien, że możesz ustalić priorytety backendów, aby maszyny klientów otrzymały priorytet, dopóki wszystkie nie staną się niezdrowe.

Od tego bym zaczął, gdybym miał to zadanie i niewątpliwie udoskonalił je w trakcie pracy.

Jednak, jak stwierdza @ErikA, to Internet i zawsze będą części sieci, które są poza twoją kontrolą. Będziesz chciał upewnić się, że Twój związek prawny wiąże cię tylko z rzeczami, które są pod twoją kontrolą.

jdw
źródło
2
Przez chwilę myślałem o Amazon i MS do wdrożenia w chmurze, ale w ciągu ostatnich kilku miesięcy oba miały poważne awarie. SSL ma kluczowe znaczenie.
NotMe,
3
Jeśli zamierzasz korzystać z Amazon, zdecydowanie chcesz rozłożyć swoje maszyny wokół 5 stref dostępności. Jest mało prawdopodobne, aby wszystkie ich strefy zgasły w tym samym czasie.
jdw
11
+1 za faktyczne zajęcie się głównym pytaniem PO.
Phil
zawsze będziesz mieć punkt awarii, jdw, o ile w łańcuchu znajduje się nierozproszona rzecz (w twoim przypadku bicie serca, chyba że oczywiście masz wiele takich instancji działających na zdalnych komputerach, wszystkie monitorują się nawzajem, a także twoje serwery, które każdy z nich może zobaczyć lub nie z powodu problemów z siecią wzdłuż routingu). Co prowadzi nas do „przestoju”. Serwery mogą być uruchomione i nadal niedostępne dla klienta bez pulsu, który kiedykolwiek je wykryje, jeśli awaria nie znajduje się na ścieżce routingu.
jwenting 30.09.11
Zgoda. Jak WSZYSTKIE inne wskazało, nie ma czegoś takiego jak 100% czasu sprawności. Wszystko, co możesz zrobić, to spróbować, a to, co opisałem, to jak zacznę próbować.
jdw 30.09.11
30

Nie ma problemu - nieznacznie zmienione brzmienie umowy:

... gwarantuje nieprzerwany czas pracy wynoszący 100% (w zaokrągleniu do zera po przecinku)

Nick Pierpoint
źródło
2
+1 za zwrócenie uwagi, że 100% to nie 100,0% lub 100 000% itd. Liczby dziesiętne mają znaczenie, wskazują na precyzję;)
Żeglarz
4
Zgodnie z niektórymi konwencjami „100%” ma tylko jedną znaczącą liczbę, tak że wszystkie liczby od połowy do jednej zaokrągliby do „100%”; 50% zaokrągliby do 100%.
Thomas Levine
1
W zależności od standardu liczenia, niektórzy powiedzą, że 50% ma dwie meeningfull liczby, gdzie 100% ma trzy meeningful number. 50,5 i 100 są tak samo precyzyjne. Inni policzą cyfry po przecinku. Wtedy 50,5 i 100,4 będą równie dokładne. Jeśli nic innego nie stwierdzono, zakładam, że 100% to 99,5% i więcej. 100,0% to 99,95% i więcej itd.
Tillebeck 18.10.11
26

Jeśli Facebook i Amazon nie mogą tego zrobić, to nie możesz. To takie proste.

Mikrofon
źródło
17
mógłby być mądrzejszy niż wszyscy ich ludzie razem, kto wie: p
Matt
3
100% czasu pracy nie musi być tak dosłownie ludźmi - oznacza: 100% dostępności w czasie, gdy jest to potrzebne. Na przykład systemy bankowe powinny być zawsze dostępne i mają się całkiem dobrze. To, że raz w roku pracują nad konserwacją przez 1 sekundę, nie oznacza, że ​​nie udało im się osiągnąć 100% czasu sprawności.
David d C e Freitas
13
@DavidFreitas - Myślę, że w umowach jest to zwykle dosłownie ...
UpTheCreek
2
@Matt tylko dlatego, że Facebook / Amazon nie może tego zrobić, nie oznacza, że ​​mniejsza strona nie może tego zrobić. Wiele dużych witryn internetowych ma znacznie trudniejsze do pokonania problemy niż mniejsze witryny.
Xorlev,
1
więc mówisz, że nie miałeś 100% czasu bezczynności, ponieważ miałeś klientów, którzy mieli błędy .. plus dns nie jest natychmiastową zmianą, ponieważ masz dostawców usług internetowych, którzy ignorują krótkie TTL
Mike
25

Aby dodać odpowiedź oconnore z Hacker News

Nie rozumiem o co chodzi. Klient chce, abyś zaplanował katastrofę i nie są one zorientowane na matematykę, więc prośba o 100% prawdopodobieństwo wydaje się rozsądna. Inżynier, podobnie jak inżynierowie, pamiętał swój pierwszy dzień prob & stat 101, nie biorąc pod uwagę, że klient może tego nie zrobić. Mówiąc to, nie myślą o nuklearnej zimie, myślą o Fredu rzucającym kawę na serwer biurowy, awarii dysku lub awarii ISP. Ponadto możesz to osiągnąć. Dzięki geograficznie odrębnym, niezależnym serwerom samokontrolującym zasadniczo nie będziesz mieć przestojów. Przy 3 serwerach działających z niezależną (1) trzema 9 niezawodnością i dobrymi trybami przełączania awaryjnego, oczekiwane przestoje są krótsze niż sekunda rocznie (2). Nawet jeśli dzieje się to naraz, nadal znajdujesz się w rozsądnej umowie SLA dla połączeń internetowych, a zatem przestoje praktycznie nie istnieją. Klient nadal musi radzić sobie ze scenariuszami dnia zagłady, ale Godzilla wykluczony, będzie miał usługę, która jest „zawsze” gotowa.

(1) Serwer w LA jest dość niezależny od serwera w Bostonie, ale tak, rozumiem, że istnieje pewne skrzyżowanie związane z wojną nuklearną, chińskimi hakerami rozbijającymi sieć energetyczną itp. Nie sądzę, aby twój klient był zdenerwowany to.

(2) Tryb failover DNS może dodać kilka sekund. Nadal znajdujesz się w scenariuszu, w którym klient musi ponawiać żądanie raz w roku, co ponownie mieści się w rozsądnej umowie SLA i zwykle nie jest traktowane tak samo jak „przestój”. W przypadku awarii, która automatycznie przekierowuje do dostępnego węzła, może to być niezauważalne.

Łowca dżungli
źródło
6
Problem polega na tym, że mówią to w umowie. Co oznacza, że jeśli katastrofa nie występuje i trzeba więcej niż dziesięć sekund, aby wziąć z powrotem online za pośrednictwem witryny kopii musieliby pozycję do sądu.
Shadur
@Shadur: Jeśli naprawdę tego chcą, musisz je naprawdę naładować. Rozłóż serwery geograficznie daleko i szeroko, mam nadzieję, że nie wszędzie będzie katastrofa.
Jungle Hunter
3
Widziałem witrynę, która oferowała 100% gwarancji bezawaryjności lub zwrot pieniędzy. Sztuczka polegała na tym, że naliczyli ładunek łodzi i podzielili na miesiące. Tak więc niektóre miesiące pozostają nieopłacone, a Ty planujesz wszystko wokół tego, a straty pokrywasz w miesiącach, które się sprawdzą.
jldugger
17

Jesteś proszony o coś niemożliwego.

Przejrzyj inne odpowiedzi tutaj, usiądź z klientem i wyjaśnij DLACZEGO jest to niemożliwe, i oceń ich odpowiedź.

Jeśli nadal nalegają na 100% dyspozycyjności, uprzejmie poinformuj ich, że nie da się tego zrobić, i odrzuć umowę. Nigdy nie sprostasz ich wymaganiom, a jeśli umowa nie będzie do końca do niczego, będziesz ukarany karami.

voretaq7
źródło
2
Należy zdefiniować 100%, tj. 100% dostępne, z wyjątkiem prac konserwacyjnych lub aktualizacji, a czas ten będzie ograniczony do godzin ciszy najwyżej przez kilka godzin w miesiącu. Wszystko zależy od celu i sposobu korzystania z aplikacji internetowej w tym przypadku ...
David d C e Freitas
1
i zdefiniuj „przestoje”. Nie mogę nawet teoretycznie zagwarantować, że będą mogli uzyskać dostęp do serwera w Omaha z ich biur w Fairbanks, chyba że kontrolujesz całą sieć pomiędzy nimi (chociaż możesz zapewnić, że serwer jest uruchomiony).
jwenting
Definicje są, IMHO, nieistotne, jeśli wymagają „100% czasu pracy”: nawet jeśli negocjujesz zaplanowaną konserwację i wbudujesz redundancję N + N, jeśli jedna drobna usterka spowoduje nieplanowane ponowne uruchomienie lub mrugnięcie usługi, zrzuciłeś SLA. ZDECYDOWANIE istotne, jeśli negocjujesz SLA 3, 4 lub 5 dziewiątek.
voretaq7
Zależy jednak od warunków umowy SLA, prawda? Jeśli otrzymasz wynagrodzenie w wysokości 100 000 USD miesięcznie, a każda minuta przestoju pociąga za sobą karę w wysokości 1 000 USD, może to być całkowicie wykonalne (jeśli masz inne umowy na amortyzację kosztów 24/7 sysadminów na miejscu).
Michael Borgwardt,
@MichaelBorgwardt są zdecydowanie sposoby, aby „sprawić, by działało” z czysto liczbowego punktu widzenia, ale nadal odmówiłbym ze względu na potencjał złego PR ($ _CLIENT trafia na Twittera i mówi światu, że nie działa, ponieważ $ _PROVIDER jest niekompetentny i nie mogą spełnić warunków umowy SLA! ”). Osobiście wolę 10 mniejszych, bardziej rozsądnych klientów, którzy płacą mi 10 dolarów miesięcznie :-)
voretaq7
13

Cena odpowiednio, a następnie zastrzeż w umowie, że wszelkie przestoje po SLA zostaną zwrócone według stawki, którą płacą.

Zrobił to dostawca usług internetowych w mojej ostatniej pracy. Do wyboru mieliśmy „zwykłą” linię DSL z 99,9% czasu dostępności za 40 USD / mc lub połączone trio T1 z 99,99% czasu dostępności za 1100 USD / mc. Często dochodziło do przestojów trwających ponad 10 godzin miesięcznie, co spowodowało, że ich czas przestoju był znacznie niższy niż 40 USD / mc DSL, ale zwrócono nam tylko około 15 USD, ponieważ na tym kończy się stawka za godzinę * godzin. Wystąpili jak bandyci z umowy.

Jeśli wystawisz rachunki w wysokości 450 000 USD miesięcznie za 100% dyspozycyjności i osiągniesz tylko 99,999%, będziesz musiał zwrócić im kwotę 324 USD. Jestem gotów założyć się, że koszty infrastruktury sięgną 99,999% w okolicach 45 000 $ miesięcznie, zakładając w pełni rozproszone colo, łącza wysyłające na wielu poziomach 1, sprzęt fantazyjny itp.

Bryan Boettcher
źródło
3
Jeśli widzisz, że ktoś obiecuje 100% czasu pracy, to właśnie to robi. Istnieje różnica między obiecaniem 100% czasu pracy a dostarczeniem go. Dobrym pomysłem byłoby wyjaśnienie tego klientowi, jeśli spróbuje on zacytować umowę SLA konkurencji.
sjbotha
10

Jeśli profesjonaliści zastanawiają się, czy dostępność na poziomie 99,999 procent jest kiedykolwiek praktyczną lub ekonomicznie opłacalną możliwością , dostępność na poziomie 99,9999% jest jeszcze mniej możliwa lub praktyczna. Nie mówiąc już o 100%.

Przez dłuższy czas nie osiągniesz celu 100% dostępności. Możesz uniknąć tego przez tydzień lub rok, ale wtedy coś się stanie i będziesz pociągnięty do odpowiedzialności. Wypadek może wahać się od uszkodzonej reputacji (obiecywałeś, że nie dostarczyłeś) po bankructwo od kar umownych.

Paweł Brodacki
źródło
10

Istnieją dwa rodzaje osób, które wymagają 100% czasu pracy:

  1. Ludzie bez absolutnej wiedzy o komputerach, systemach komputerowych lub Internecie. *
  2. Ci, którzy celowo robią z siebie dupę, albo testując twoją zdolność do odmowy (Google „test soku pomarańczowego”), albo próbują uzyskać jakąś umowę SLA w celu uniknięcia wypłaty później.

Moja rada, która wielokrotnie cierpiała na oba rodzaje klientów, nie powinna brać tego klienta. Niech doprowadzą kogoś innego do szaleństwa.

* Ta sama osoba może nie odczuwać zażenowania, pytając o podróż szybszą niż światło, Perpetual Motion, Cold Fusion itp.

Irving
źródło
2
+1 za test soku pomarańczowego .. Podoba mi się i nie wiedziałem o tym :)
Oliver M Grech
8

Komunikowałbym się z klientem, aby ustalić z nim, co dokładnie oznacza 100% czasu sprawności. Możliwe, że tak naprawdę nie widzą różnicy między 99% dyspozycyjnością a 100% dyspozycyjnością. Dla większości osób (tj. Nie administratorów serwera) te dwie liczby są takie same.

jhocking
źródło
6

100% czasu sprawności?

Oto czego potrzebujesz:

Wiele (i redundantnych) serwerów DNS, wskazujących na wiele witryn na całym świecie, z odpowiednimi umowami SLA z każdym dostawcą usług internetowych.

Upewnij się, że serwery DNS są poprawnie skonfigurowane, a TTL jest rozpoznawany skutecznie.

W
źródło
1
Tak, DNS to dobry początek - np. nslookup google.comZwraca 6 różnych adresów IP dla nadmiarowości w przypadku, gdy niektóre z nich nie działają. Również sprawdzić RobTex.com wielkie witryny, aby spojrzeć na niektórych konfiguracjach domen np robtex.com/dns/google.com.html#records
David C d e Freitas
6

To jest łatwe. Umowa SLA Amazon EC2 wyraźnie stwierdza:

„Roczny odsetek przestojów” oblicza się, odejmując od 100% odsetek 5-minutowych okresów w roku serwisowym, w którym Amazon EC2 był w stanie „Region niedostępny”.

http://aws.amazon.com/ec2-sla/

Wystarczy zdefiniować „czas pracy”, aby był relatywny do całego pakietu usług, który faktycznie można utrzymać w 100% przez cały czas i nie powinno być problemów.

Warto również zauważyć, że celem umowy SLA jest określenie, jakie są twoje obowiązki i co się stanie, jeśli nie będziesz w stanie ich spełnić. Nie ma znaczenia, czy klient prosi o 3 lub 5 dziewiątek lub milion dziewiątek - pytanie brzmi, co otrzymają, kiedy / jeśli nie możesz dostarczyć. Oczywistą odpowiedzią jest zapewnienie elementu zamówienia zapewniającego 100% nieprzerwany czas pracy przy 5-krotności ceny, którą chcesz naliczyć, a następnie otrzymają 4x zwrot pieniędzy, jeśli nie uda Ci się osiągnąć tego celu. Możesz strzelić gola!

pola
źródło
5

Zmiany DNS wymagają czasu tylko, jeśli są skonfigurowane tak, aby wymagały czasu. Możesz ustawić TTL na rekord na jedną sekundę - Twoim jedynym problemem będzie zapewnienie terminowej odpowiedzi na zapytania DNS oraz że serwery DNS będą w stanie poradzić sobie z tym poziomem zapytań.

Dokładnie tak działa GTM w F5 Big IP - DNS TTL jest domyślnie ustawiony na 30 sekund, a jeśli jeden członek klastra musi przejąć, DNS jest aktualizowany, a nowy adres IP jest przejmowany prawie natychmiast. Maksymalnie 30 sekund przerwy, ale taki jest przypadek na krawędzi, średnia wynosiłaby 15 sekund.

Paweł
źródło
10
Z mojego doświadczenia wynika, że ​​niektóre serwery DNS zignorują czas TTL, który uważają za nieznośnie niski (pomimo RFC). Coś mniej niż 5 minut staje się nieco niewiarygodne w skali globalnej.
jdw
13
@Paul ignorowanie rzeczywistości nie jest dopuszczalną praktyką, bez względu na to, jak bardzo wkurza wszystkich.
MDMarra,
5
Jestem z JDW w tej sprawie. Widziałem, że wiele serwerów DNS całkowicie ignoruje TTL, nawet ustawienie 1 godziny i domyślnie powraca do około 24 godzin.
NotMe,
6
@Paul - OP nie ma kontroli nad rozwiązaniami DNS wszystkich dostawców usług internetowych na planecie. Ergo, nie mają wyboru, aby powiedzieć „jeśli zamierzasz korzystać z naszej strony internetowej, nie używaj Comcast / Roadrunner / ktokolwiek jako usługodawca internetowy, ponieważ zignorują nasze ustawienia TTL”. Jest to coś, co jest po prostu poza ich kontrolą, a zatem jest zbyt delikatne, aby uznać je za rozwiązanie tego problemu IMHO. Rozwiązanie musi zawierać pewien sposób, aby móc wewnętrznie wymusić adresy IP bez polegania na innych bitach sieci, które mogą nie współpracować.
jdw
3
To trochę tak, jakby nie mieć UPS-a, ponieważ moc „powinna po prostu działać”. To nie jest przyszłościowy sposób na zaprojektowanie systemu. Jeśli wiesz, że z jakiegoś powodu istnieje delikatna część systemu, powinieneś spróbować to wyjaśnić.
jdw
5

Wiesz, że to niemożliwe.

Bez wątpienia klient koncentruje się na widzeniu „100%”, więc najlepsze, co możesz zrobić, to obiecać 100%, z wyjątkiem [wszystkich uzasadnionych przyczyn, które nie są Twoją winą].

Marcin
źródło
Bez wątpienia klient nie chce żadnego rozwiązania. Chcą spadku. Więc mogą powiedzieć, że przynajmniej próbowali.
mbx
Być może. Zakładasz wysoki poziom wskazówek.
Marcin
4

Chociaż wątpię, czy 100% jest możliwe, możesz rozważyć użycie platformy Azure (lub czegoś o podobnej umowie SLA). Co się dzieje:

Twoje serwery to maszyny wirtualne. Jeśli kiedykolwiek wystąpi problem sprzętowy na jednym serwerze, maszyna wirtualna zostanie przeniesiona na nową maszynę. Moduł równoważący obciążenie dba o przekierowanie, aby klient nie widział żadnych przestojów (chociaż nie jestem pewien, jak wpłynie to na stan sesji).

To powiedziawszy, nawet przy tym przełączeniu awaryjnym różnica między 99,999 a 100 graniczy z obłędem.

Musisz mieć pełną kontrolę nad następującymi czynnikami.
- Czynniki ludzkie, zarówno wewnętrzne, jak i zewnętrzne, zarówno złośliwość, jak i impotencja. Przykładem tego jest ktoś pchający coś do kodu produkcyjnego, który powoduje awarię serwera. Co gorsza, co z sabotażem?
- Problemy biznesowe. Co się stanie, jeśli Twój dostawca przestanie działać lub zapomni zapłacić rachunki za prąd lub po prostu zdecyduje się przestać wspierać infrastrukturę bez wystarczającego ostrzeżenia?
- Natura. Co jeśli niepowiązane tornada jednocześnie uderzą w wystarczającą liczbę centrów danych, aby pokonać pojemność tworzenia kopii zapasowych?
- Całkowicie wolne od błędów środowisko. Czy jesteś pewien, że nie istnieje przypadek krawędziowy z jakąkolwiek kontrolą systemu zewnętrznego lub systemu podstawowego, która się nie ujawniła, ale nadal mogłaby to zrobić w przyszłości?
- Nawet jeśli masz pełną kontrolę nad powyższymi czynnikami, czy jesteś pewien, że oprogramowanie / osoba monitorująca to nie przedstawi fałszywych negatywów podczas sprawdzania, czy twój system działa?

JSWork
źródło
2
Azure i EC2 miały ostatnio prawie całkowite i całkowite awarie. Uważam, że platforma Azure została niedawno zdjęta z powodu złego wpisu konfiguracji na serwerze DNS. Tak czy inaczej, dzięki za informacje.
NotMe,
a jeśli moduł równoważenia obciążenia (który wykonuje przełączanie) znika niezauważony (jego monitor może również zostać niezauważony, ad infinitum), gdy węzeł się zepsuje, nadal masz problemy.
jwenting 30.09.11
1
Myślę, że miałeś na myśli „niekompetencję”. „Impotencja” nie powinna mieć dużego wpływu na zdolność personelu IT do wykonywania pracy.
mfinni 30.09.11
4

Szczerze mówiąc, 100% jest całkowicie szalone bez co najmniej wahania pod względem ataku hakerskiego. Najlepiej jest zrobić to, co robią Google i Amazon, ponieważ masz rozproszone geograficznie rozwiązanie hostingowe, w którym witryna i baza danych są replikowane na wielu serwerach w wielu lokalizacjach geograficznych. Zagwarantuje to wszystko w przypadku poważnej katastrofy, takiej jak przecięcie sieci internetowej do regionu (co zdarza się od czasu do czasu) lub coś niemal apokaliptycznego.

Umieściłbym klauzulę na takie przypadki (DDOS, przecięcie szkieletu Internetu, apokaliptyczny atak terrorystyczny lub wielka wojna itp.).

Oprócz tego zajrzyj do usług w chmurze Amazon S3 lub Rackspace. Zasadniczo konfiguracja chmury zapewnia nie tylko nadmiarowość w każdej lokalizacji, ale także skalowalność i rozkład geograficzny ruchu, a także możliwość przekierowywania wokół uszkodzonych obszarów geograficznych. Chociaż rozumiem, że dystrybucja geograficzna kosztuje więcej pieniędzy.

Patrick
źródło
3

Chciałem tylko dodać kolejny głos do imprezy „ można (teoretycznie) zrobić”).

Nie podjąłbym się umowy, która by to sprecyzowała, bez względu na to, ile mi zapłacili, ale jako problem badawczy ma kilka interesujących rozwiązań. Nie jestem wystarczająco zaznajomiony z siecią, aby nakreślić etapy, ale wyobrażam sobie kombinację konfiguracji związanych z siecią + przełączanie awaryjne okablowania elektrycznego / sprzętowego + przełączanie awaryjne oprogramowania, być może w jakiejś konfiguracji lub innej pracy, by to zrobić.

Prawie zawsze istnieje jeden punkt awarii gdzieś w dowolnej konfiguracji, ale jeśli pracujesz wystarczająco ciężko, możesz przesunąć ten punkt awarii w coś, co można naprawić „na żywo” (tzn. Root dns spada, ale wartości są nadal buforowane wszędzie indziej, więc masz czas, aby to naprawić).

Znów nie mówię, że jest to wykonalne. Po prostu nie podobało mi się, że żadna odpowiedź nie odnosiła się do faktu, że nie jest to „wyjście” - to po prostu nie jest to coś, czego naprawdę chcą, jeśli się nad tym zastanowią.

Mahmoud Al-Qudsi
źródło
3

Przemyśl swoją metodologię pomiaru dostępności, a następnie współpracuj z klientem, aby ustalić znaczące cele .

Jeśli prowadzisz dużą witrynę internetową, czas działania nie jest w ogóle przydatny. Jeśli porzucisz zapytania na 10 minut, kiedy Twoi klienci najbardziej ich potrzebują (szczyt ruchu), może to być bardziej szkodliwe dla firmy niż godzinna przerwa o 3 rano w niedzielę.

Czasami duże firmy internetowe mierzą dostępność lub niezawodność, korzystając z następujących wskaźników:

  1. procent zapytań, na które odpowiedziano pomyślnie, bez błędu po stronie serwera (HTTP 500).
  2. procent zapytań, na które odpowiedziano poniżej określonego docelowego opóźnienia .
  3. odrzucone zapytania powinny się liczyć z Twoimi statystykami (patrz poniżej).

Dostępność nie powinna być mierzona za pomocą przykładowych sond, które mogą zgłaszać podmioty zewnętrzne, takie jak pingdom i pingability. Nie polegaj wyłącznie na tym. Jeśli chcesz to zrobić poprawnie, każde pojedyncze zapytanie powinno się liczyć . Zmierz swoją dostępność, patrząc na rzeczywisty, postrzegany sukces.

Najbardziej efektywnym sposobem jest zebranie dzienników lub statystyk z modułu równoważenia obciążenia i obliczenie dostępności na podstawie powyższych wskaźników.

Procent odrzuconych zapytań powinien również liczyć się do twoich statystyk. Może być rozliczany w tym samym segmencie co błędy po stronie serwera. Jeśli występują problemy z siecią lub inną infrastrukturą, taką jak DNS lub moduły równoważenia obciążenia, możesz użyć prostej matematyki, aby oszacować liczbę utraconych zapytań . Jeśli spodziewałeś się zapytań X dla tego dnia tygodnia, ale dostałeś X-1000, prawdopodobnie zrzuciłeś 1000 zapytań. Wyświetlaj ruch w postaci wykresów z zapytaniami na minutę (lub sekundę). Jeśli pojawią się luki, odrzucasz zapytania. Użyj podstawowej geometrii, aby zmierzyć obszar tych luk, co daje całkowitą liczbę odrzuconych zapytań.

Omów tę metodologię ze swoim klientem i wyjaśnij jego zalety. Ustaw linię bazową , mierząc ich bieżącą dostępność. Stanie się dla nich jasne, że 100% jest niemożliwym celem.

Następnie możesz podpisać umowę na podstawie ulepszeń na poziomie podstawowym. Powiedzmy, że jeśli obecnie osiągają 95% dostępności, możesz obiecać dziesięciokrotnie poprawić sytuację , osiągając 98,5%.

Uwaga: ten sposób pomiaru dostępności ma wady. Po pierwsze, samodzielne zbieranie dzienników, przetwarzanie i generowanie raportów może nie być trywialne, chyba że użyjesz do tego istniejących narzędzi. Po drugie, błędy aplikacji mogą zaszkodzić twojej dostępności. Jeśli aplikacja jest niskiej jakości, będzie wyświetlać więcej błędów. Rozwiązaniem tego jest rozważenie tylko 500 utworzonych przez moduł równoważenia obciążenia zamiast tych pochodzących z aplikacji.

W ten sposób sprawy mogą się nieco skomplikować, ale to tylko jeden krok poza pomiarem czasu bezawaryjnej pracy serwera .

Yves Junqueira
źródło
3

Chociaż niektórzy zauważyli tutaj, że 100% jest szalony lub niemożliwy , jakoś nie trafili w sedno. Argumentowali, że powodem tego jest fakt, że nawet najlepsze firmy / usługi nie są w stanie tego osiągnąć.

Cóż, jest o wiele prostsze. Jest to matematycznie niemożliwe .

Wszystko ma prawdopodobieństwo. Może wystąpić jednoczesne trzęsienie ziemi we wszystkich lokalizacjach, w których przechowujesz swoje serwery, niszcząc je wszystkie. Prawdopodobnie jest to absurdalnie małe prawdopodobieństwo, ale nie jest równe 0. Wszyscy dostawcy Internetu mogliby spotkać się z jednoczesnym atakiem terrorystycznym / cyber. Znowu mało prawdopodobne, ale też nie zerowe. Cokolwiek podasz, możesz otrzymać niezerowy scenariusz prawdopodobieństwa, który obniża całą usługę. Ponieważ twój czas dostępności nie może być równy 100%.

Karoly Horvath
źródło
Właściwie przeszedłbym obok szaleństwa lub niemożliwego i nazwałbym to głupcem. Nic, co ludzie wiedzą, to 100%.
quadruplebucky
2

Wybierz książkę o kontroli jakości produkcji za pomocą próbkowania statystycznego. Ogólna dyskusja w tej książce, na którą każdy menedżer byłby narażony podczas ogólnego kursu statystyki w college'u, dyktuje koszty przejścia od 1 usprawiedliwienia na tysiąc, do 1 na dziesięć tysięcy do 1 na milion do 1 na miliard rośnie wykładniczo. Zasadniczo zdolność do osiągnięcia 100% czasu sprawności kosztowałaby prawie nieograniczoną ilość funduszy, podobnie jak ilość paliwa potrzebna do popchnięcia obiektu do prędkości światła.

Z perspektywy inżynierii wydajności odrzuciłbym wymaganie zarówno jako niesprawdzalne, jak i nierozsądne, aby wyrażenie to było bardziej pragnieniem niż prawdziwym wymogiem. Dzięki zależnościom aplikacji, które istnieją poza aplikacjami sieciowymi, rozpoznawaniem nazw, routingiem, defektami wynikającymi z podstawowych komponentów architektonicznych lub narzędzi programistycznych, praktycznie niemożliwe staje się zapewnienie 100% dostępności bez przestojów.

James Pulley
źródło
1

Nie sądzę, że klient faktycznie prosi o 100% czasu pracy, a nawet 99,999% czasu pracy. Jeśli spojrzysz na to, co oni opisują, mówią o tym, gdzie powinni przerwać, jeśli meteor usunie swoje centrum danych na miejscu.

Jeśli wymaganiem jest, aby ludzie z zewnątrz nawet tego nie zauważyli, jak drastyczne to musi być? Czy zaakceptowanie prośby Ajax i ponowne wyświetlenie pokrętła przez 30 sekund użytkownikowi końcowemu jest dopuszczalne?

To są rzeczy, na których zależy klientowi. Gdyby klient myślał o precyzyjnych umowach SLA, wiedziałby wystarczająco dużo, aby wyrazić to jako 99,99 lub 99,999.

Kevin Peterson
źródło
Jeśli klient myśli, że chce „100% czasu nieprzerwanego działania”, i wtedy kończy się to na umowie, możesz się do tego przyzwyczaić, jeśli trafi do sądu. Najlepiej to porozmawiaj i pomóż klientowi zrozumieć, czego naprawdę chcą, zamiast zakładać, że wiesz, co myśli.
Chris S
Och, zgadzam się, że należy to wyjaśnić, zanim dojdzie do zawarcia umowy. Mówię tylko, że należy do tego podejść, ponieważ klient nie komunikuje tego, czego tak naprawdę chce, w przeciwieństwie do klienta proszącego o coś śmiesznego.
Kevin Peterson
1

moje 2 centy. Byłem odpowiedzialny za bardzo popularną stronę internetową dla firmy z wróżbą-5, która zajmowałaby się reklamą super bowl. Musiałem poradzić sobie z ogromnymi skokami ruchu, a sposobem, w jaki to rozwiązałem, było skorzystanie z usługi takiej jak Akamai. Nie pracuję dla Akamai, ale uważam, że ich obsługa jest bardzo dobra. Posiadają własny, inteligentniejszy system DNS, który wie, że dany węzeł / host jest albo obciążony, albo nie działa i może odpowiednio kierować ruchem.

Ciekawą rzeczą w ich usługach było to, że tak naprawdę nie musiałem robić nic bardzo skomplikowanego, aby replikować zawartość na serwerach we własnym centrum danych do ich centrum danych. Ponadto wiem, że dzięki współpracy z nimi bardzo intensywnie korzystali z serwerów Apache HTTP.

Chociaż nie ma 100% czasu sprawności, możesz rozważyć takie opcje rozpraszania treści na całym świecie. Jak rozumiałem, Akamai miał również możliwość lokalizowania ruchu, co oznacza, że ​​gdybym był w Michigan, dostałem zawartość z serwera Michigan / Chicago, a jeśli byłem w Kalifornii, podobno dostałem zawartość z serwera z siedzibą w Kalifornii.

Kilogram
źródło
-1, ponieważ jest to praktyczna odpowiedź, ale w ogóle nie przydatna. Na wszystkie pytania na tej stronie można odpowiedzieć „zatrudnić kogoś innego”, ale nie dlatego tu jesteśmy.
Yves Junqueira,
Pozwolę sobie być innego zdania. „W ogóle nie przydatny?” Z całą pewnością było to dla mnie przydatne i w przeciwieństwie do twojego komentarza „zatrudnić kogoś innego do zrobienia”, przypuszczam, że z twojego rozumowania facet powinien wykopać swój własny kabel światłowodowy i zaprojektować własne przełączniki, a nie je też kupić? Mówisz poważnie, Yves? Brzmisz jak ktoś, kto nie spędził dużo czasu w branży IT.
Kilo
0

Zamiast zewnętrznego przełączania awaryjnego po prostu uruchom aplikację z dwóch lokalizacji jednocześnie, wewnętrzną i zewnętrzną. I zsynchronizuj dwie bazy danych ... Wtedy jeśli wewnętrzne ulegnie awarii, wewnętrzni ludzie nadal będą mogli pracować, a zewnętrzni ludzie będą nadal mogli korzystać z aplikacji. Gdy wewnętrzny wróci do trybu online, zsynchronizuj zmiany. Możesz mieć dwa wpisy DNS dla jednej nazwy domeny lub nawet router sieciowy z okrągłym robinem.

chrześcijanin
źródło
0

W przypadku witryn hostowanych zewnętrznie najbliżej 100% czasu działania to hosting Twojej witryny w Google App Engine i korzystanie z magazynu danych o wysokiej replikacji (HRD) , który automatycznie replikuje dane w co najmniej trzech centrach danych w czasie rzeczywistym. Podobnie serwery frontonu App Engine są automatycznie skalowane / replikowane.

Jednak nawet przy wszystkich zasobach Google i najbardziej zaawansowanej platformie na świecie gwarancja dostępności usługi App Engine SLA wynosi tylko „99,95% czasu w dowolnym miesiącu kalendarzowym”.

espeed
źródło
0

Prosty i bezpośredni: Anycast

http://en.wikipedia.org/wiki/Anycast

Tego właśnie używa CloudFlare, Google i każdej innej dużej firmy, aby wykonywać zbędne, niewielkie opóźnienia, międzykontynentalne przełączanie awaryjne / równoważenie.

Pamiętaj również, że nie można mieć 100% czasu bezczynności, a koszty przejścia z 99,999% do 99,9999% są DUŻO większe.

Leon Waldman
źródło