Taka sobie myśl

[Gość hdmagc]

Tak czytając od pewnego czasu wpisy w "host is down" zauważam pewną niestety prawidłowość.

 

Jeśli coś pada w danej firmie hostingowej, pada również "ich" strona, a zarazem support, system ticketów i pewnie obsługa poczty. Ludziska się zaraz skarżą, że nawet nie ma strony i nie ma gdzie napisać ticketa.

Nie mam zamiaru tutaj podawać żadnych nazw ani niczego, proszę źle nie odbierać i nie kontratakować.

 

Doszedłem do pewnego wniosku.

Czy nie można strony firmowej, systemu ticketów itp, postawić w innym DC, aby było całkowicie niezależne od posiadanych zasobów? Wiem, że teraz każdy tnie koszty, ale przecież może to być nieodpłatnie, na zasadzie wymiany pomiędzy firmami. Jedna ma DC w jednym miejscu, druga w innym i już można się dogadać.

Pewnie ocenicie to jako śmieszna propozycja patrząc pod katem Waszej firmy, ale od strony klienta-użytkownika, ma to ogromne znaczenie. No i jak ładnie i profesjonalnie wygląda wpis: "Niezależny system ticketów i obsługi klienta w zewnętrznej serwerowni". Dla klienta daje to poczucie bezpieczeństwa.

To tylko taka moja myśl, którą można ubrać technicznie i udoskonalić.

Edytowano Czerwiec 14, 2012 przez hdmagc (zobacz historię edycji)

[Gość nrm]

Niekoniecznie to musi być strona firmowa (tutaj nie wziąłeś pod uwagę spraw poza serwerowych np. prawnych związanych z trzymaniem danych u kogoś innego) ale jakiś blog/strona typu STATUS to już musowo powinna być w zupełnie innej lokalizacji.

[Gość nrm]

Raczej większość sprawdza trasę czy ping po stronie firmowej, więc odpada.

To akurat jest mało ważne.

 

A co jak padnie ta niezależna serwerownia?

W przypadku takiego "serwer statusa" także bez znaczenia bo cała reszta działa, a prawdopodobieństwo, że obie padną na raz jest niezwykle niskie

[Gość nrm]

Jak mało ważne? To co mam pisać specjalnego e-maila w jakiej serwerowni będzie znajdować sie moja strona?

Takie informacje są chyba niemal na każdej stronie w zakładce typu firma/onas, firma/infrastruktura.

[Gość nrm]

No ale teraz już szukasz dziury w całym. Wytnij sobie ów "bełkot PR", a dostaniesz "w jakiej serwerowni będzie znajdować sie moja strona"

[Miłosz 2311]

A jak strona główna firmy padnie, to skąd mają sobie ludzie wziąć adres blogu/status sajtu?

[Gość hdmagc]

Nie wspieram działania forum webhostingtalk.pl

Edytowano Styczeń 15, 2013 przez hdmagc (zobacz historię edycji)

[Gość nrm]

Powinni mieć w mailach od firmy, firma powinna lansować mocno taki adres. W momencie awarii / innego kryzysu powinna we wszelkich możliwych kanałach (fejsy-srejsy, twittery itp.) kierować na taki adres. Oczywiście nie jesteś w stanie tak do każdego trafić ani zmusić aby taki adres gdzieś zapisał ale przecież tego nigdy nie będziesz w stanie na tylu osobach wymusić

 

Praktyka pokazuje, że mało kto to robi, a to i tak już bardzo dużo. Weźmy dwa pierwsze przykłady z brzegu: ostatni z beyond - gdzie w kółko wszędzie były głosy o tym, że nie ma strony typu "serwer status", i chyba Hetznera (poprawcie mnie jeżeli źle zapamiętałem) gdzie taka strona jest ale przy ostatnim większym padzie padła razem z całym Hetznerem (obiecali wynieść się z tym poza swoją infrastrukturę - nie sprawdzałem czy faktycznie to zrobili).

[www.mzone.uk 1200]

Niestety nie jesteś przewidzieć awarii, ta może się równie dobrze pojawić w "drugim" DC. Teraz jeszcze pytanie po co to robić?

Zwykły klient który jest z firmą dość długo nawet się nie przejmuje normalną powiedzmy 2h awarią, tylko szaleńcy z forum zaraz robią raban bo strona im nie działa 3 minuty. Do tego warto zwrócić uwagę na koszty, czy to blog, czy też zapasowy serwer w innym DC spowoduje podniesienie kosztów. Blog należy aktualizować, więc musi być osoba co będzie wiedziała co, jak i gdzie, a ta za darmo nie będzie tego wykonywała.

 

Te awarie są tak rzadkie, że umieszczenie systemu tickeów, bloga itp w innym DC mija się moim zdaniem z celem.

[Miłosz 2311]

No dobra.. Jedną rzecz wyjaśniłeś.. To teraz czas na kolejną. A mianowicie jak ci klienci maja na taką stronke trafić? Tylko nie pisz, że mogą sobie wyszukać w googlach, zapisać na kartce, albo zapamiętać.

[Gość nrm]

No niestety, nie mogę się z Tobą Irek zgodzić. Uważam, że osobny server-status jest bardzo istotny co pokazują wszelkie możliwe kryzysy jakie ostatnio wystąpiły. Najgorsze co wystepuje podczas awarii dla klientów to brak informacji - co bardzo często podkreślają.

 

Co do kosztów - można je zminimalizować niemal do zera - wystarczy choćby system blogowy typu np. blogspot czy inny (ogromna ilość serwisów ma blogi na różnych thumblerach i innych).

 

@Miłosz: to już wyżej napisałem - pierwszy akapit.

[Miłosz 2311]

I 99,90% klientów nawet nie pofatyguje się odwiedzić takiej strony

[Kolopik 222]

Mało firm posiada swoje strony oraz poczty i inne w firmach konkurencyjnych ? Już dawno na to wpadli

[Gość nrm]

Aha, jednocześnie uważam, że przenoszenie "ticketów" itp. systemów jest nadmiernym problemem, nieuzasadnione i niepotrzebne. Klienci oczekują informacji - sam serwer status (choćby w formie bloga, nawet z komentarzami) jest wystarczający.

 

I 99,90% klientów nawet nie pofatyguje się odwiedzić takiej strony

Do wszystkich NIGDY nie trafisz, ale jak pokazuje PRAKTYKA w czasie awarii wbrew pozorom takie strony są BARDZO CZĘSTO odwiedzane!!!

[www.mzone.uk 1200]

Uważam, że osobny server-status jest bardzo istotny

Mirek, ale My nie mówimy tu chyba o server-status, tylko o jakimś blogu, chyba, że coś nie zrozumiałem.

Przecież monitoring stawia się na całkiem niezależnej maszynie, nie jest to maszyna z kontami klientów, często jest także w innym DC (tak jest akurat u nas, nie wiem jak jest w innych firmach). Więc monitorowanie serwera jest niezależne i bardziej obiektywne od zdarzeń we własnym DC, druga sprawa, że klienci firmy nie mają z reguły dostępu do takiego monitoringu i bazują na informacjach uzyskanych w panelu klienta lub jak często widzimy to tutaj na forum w Host is Down.

 

Ale tak teraz trochę mi tu podpowiedzieli w biurze ...

Może to całkiem nie taki głupi pomysł gdyby WHT dała miejsce ogłoszeń dla firm o awariach (tylko i wyłącznie), ale bez możliwości komentowania ze strony użytkowników. W przypadku awarii taka wiadomość szybko rozeszła by się po sieci i nie byłoby niepotrzebnych scysji w takim forum.

 

Z drugiej strony ostatnio modny w firmach Facebook, co druga firma ma tam swój fan page, ich klienci chyba wiedzą o takim profilu i tam ewentualnie szukałby także informacji o danej awarii. Tak więc problem odnalezienia strony z informacją od firmy jest chyba w ogóle nie istniejący.

Edytowano Czerwiec 14, 2012 przez www.mzone-net.eu (zobacz historię edycji)

[Gość nrm]

Nie chodzi o monitoring Chodzi o blog / status / jak zwał tak zwał np.

 

http://www.hetzner-status.de/en.html

[www.mzone.uk 1200]

Tak, tak, wiem teraz o czym pisałeś

Bo ja wiem czy to potrzebne?

[elcct 159]

Nie rozumiem w czym problem? Każdy chyba zna adres strony firmy w której kupił serwer?

I dlaczego ktoś by miał pingować stronę firmy, gdy mu padnie zamówiony serwer. Jaki to ma związek?

Według mnie tickety/panel klienta i status, z definicji powinny znajdować się w conajmniej jednym niezależnym DC, jeśli firma dba o klienta.

Tak aby właśnie wyeliminować:

a) panikowanie ludzi na forach, bo tickety nie działają

b) brak możliwość zobaczenia informacji o awarii (strona status)

c) brak możliwości kontaktu z supportem

 

Zwykły klient który jest z firmą dość długo nawet się nie przejmuje normalną powiedzmy 2h awarią

 

To chyba klient, który przywykł do kiepskich usług i myśli, że nie ma lepszych

 

tylko szaleńcy z forum zaraz robią raban bo strona im nie działa 3 minuty

 

Nawet te 3 minuty, to czasem brak parę tysięcy odsłon i realna strata pieniędzy. Brak informacji na taki temat to zrozumiałe, że niektórzy będą chcieli wiedzieć

o co chodzi. Skąd mają wiedzieć ile będzie trwała przerwa i co się stało?

[MikeJones 25]

Od dawna zarowno porzadne firmy shared jak i serwerownie maja swoje strony status czy to twiterrze, blipie czy to na fejsie, a nawet strony firmowe i systemy ticketow w innych serwerowniach... Inna sprawa, ze fascynuje mnie jaki ma sens wydzwanianie czy pisanie do serwerowni albo hostingu jak wszystko calkowicie padlo, wiadomo, ze zauwazyli, wiadomo, ze naprawiaja, chyba samemu mozna wymyslic, ze moze zadziala za godzine a moze za dwie i raczej nikt tej awarii nie zaplanowal co do minuty

Edytowano Czerwiec 14, 2012 przez MikeJones (zobacz historię edycji)

[kafi 2425]

Ta sprawa jest nieco bardziej złożona, niż by się mogło wydawać.

Ogólnie mamy następujące scenariusze:

> działa operator, działa strona;

> nie działa operator, działa strona;

> działa operator, nie działa strona;

> nie działa operator i nie działa strona.

 

Trzymanie kluczowych zasobów (strony głównej, bazy klientów, systemu ticketów) na niekontrolowanej przez siebie infrastrukturze, to pomysł nie oszukujmy się, średni z punktu widzenia bezpieczeństwa. Ot zasada ograniczonego zaufania do konkurencji, bo czasem może się złośliwiec robiący redirect jednego na kilka pakietów na jakiś inny adres IP. Ewentualnie próba wykradnięcia danych. Z biznesowego częściowo też, ze względu na scenariusz (3). Bo jak owy dostawca strony padnie, to będzie larum, że NIE DZIAŁA.

 

Jednak o pewne aspekty rozproszoności oczywiście trzeba zadbać. Pierwszy z nich to serwer DNS obsługujący domenę firmową oraz revdns. Warto, aby nie występowała sytuacja, że domena zaparkowana jest na pięć nameserverów, ale tak na prawdę to jedna fizyczna maszyna z różnymi adresami (nawet i z różnych podsieci, nie ma to znaczenia). Dodatkowo TTL głównych rekordów powinien być w miarę niski, aby móc w razie czego przekierować stronę firmową na inny IP. Do tego owy zapasowy serwer - ale robiący jedynie za zapasową stronę firmową (na którą operator przekieruje w momencie kryzysu wpis A) i zapasowy MX przechowujący tymczasowo pocztę firmową.

 

Operatorzy telco kiedyś rozwiązali ten problem dosyć skutecznie - newsgrupa pl.internet.komunikaty, na której publikowane były informacje o awariach/konserwacjach. No ale teraz już też to zamarło - chyba jedynie tpnet wkleja tam informacje.

Centralny padtracker to całkiem ciekawy pomysł... Ale kto by odważył się podjąć jego realizacji i obsługi? Bo to dosyć duża odpowiedzialność na nim by spadała... Jeśli już, to raczej nie robił by tego za friko, tylko chciał zarobić. A jak tak, to dużej części dostawców by pewnie nie było stać na to i posiłkowali by się jakimiś protezami.

[elcct 159]

Trzymanie kluczowych zasobów (strony głównej, bazy klientów, systemu ticketów) na niekontrolowanej przez siebie infrastrukturze, to pomysł nie oszukujmy się, średni z punktu widzenia bezpieczeństwa. Ot zasada ograniczonego zaufania do konkurencji, bo czasem może się złośliwiec robiący redirect jednego na kilka pakietów na jakiś inny adres IP. Ewentualnie próba wykradnięcia danych. Z biznesowego częściowo też, ze względu na scenariusz (3). Bo jak owy dostawca strony padnie, to będzie larum, że NIE DZIAŁA.

 

No takich rzeczy nie trzyma się w krzakach, a w firmach które spełniają standardy bezpieczeństwa i nie ryzykowałyby swojej reputacji na takie akcje.

[hd-it 18]

No takich rzeczy nie trzyma się w krzakach, a w firmach które spełniają standardy bezpieczeństwa i nie ryzykowałyby swojej reputacji na takie akcje.

 

 

Chcesz trzymać crm-a, system ticketów itd. w ramach infrastruktury u potencjalnej konkurencji?

Edytowano Czerwiec 14, 2012 przez hd-it (zobacz historię edycji)

[elcct 159]

Chcesz trzymać crm-a, system ticketów itd. w ramach infrastruktury u potencjalnej konkurencji?

 

I jak mieliby się do niego dostać? I dlaczego?

[Gość cyferek]

 

I jak mieliby się do niego dostać? I dlaczego?

Zakładając, że kolega Hd-it miał na myśli shared to zwyczajnie, poprzez phpmyadmin

 

Lepiej dbać o swoje, po fakcie (kradzież danych itd.) było by to trudne do udowodnienia - kto, gdzie, kiedy. W końcu root może po sobie posprzątać.

[elcct 159]

Zakładając, że kolega Hd-it miał na myśli shared to zwyczajnie, poprzez phpmyadmin

 

Lepiej dbać o swoje, po fakcie (kradzież danych itd.) było by to trudne do udowodnienia - kto, gdzie, kiedy. W końcu root może po sobie posprzątać.

 

Przecież trzymanie takich rzeczy na shared jest niepoważne...