Hejto.pl
Dodaj post

Wpisz coś do wyszukania (minimum 2 znaki)

AWS crash causes $2,000 Smart Beds to overheat and get stuck upright [EN]

Mistrz

w Technologia

81piorunów

Awaria AWS spowodowała, że niektóre z łóżek sprzedawanych przez Eight Sleep miały problemy z przegrzewaniem się, chłodzeniem lub całkowitą utratą kontroli nad łóżkiem. Urządzenia nie miały trybu offline i były kontrolowane przez internet.

Komentarze (46)

Gruba ryba3piorunów

Jestem smart łóżko.
To powiedz coś po smartłóżkowemu.
"wstawaj, zesrałeś się"

Gwiazdor2piorunów

>Urządzenia nie miały trybu offline i były kontrolowane przez internet.

Wyborny design. Zaprojektuj produkty tak ze w razie utraty łączności odpierdala szajs xD Profit.

Gwiazdor0piorunów

@Odczuwam_Dysonans No dlatego jestem wręcz oczarowany designem :grinning: Przeciez to jest pierwsza rzecz o ktorej sie mysli. Chyba, że to nie przeoczenie a feature :grinning:

Fenomen0piorunów

@elmorel po prostu trzyma ostatnie ustawienie. Samo założenie sterowania tylko przez apkę na zewnętrznym serwerze jest głupie, ale przecież producent powinien założyć tak banalny problem, jak awaria internetu w domu. Wystarczyłoby żeby po 15min bez połączenia program się zresetował. To znaczy też do dupy, ale jak bardzo trzeba klepać usługę na pałę, żeby coś takiego olać xD

Osobistość5piorunów

Każdy człowiek, który kupuje domowy sprzęt AGD mogący działać tylko online jest nierozważny.

Fanatyk0piorunów

@Jarasznikos przeczytaj mój komentarz jeszcze raz

Osobistość0piorunów

@redve A co ma do tego blik?

Fanatyk0piorunów

@Jarasznikos kupowanie w ogóle sprzętu który działa tylko online to proszenie sie o kłopoty. Wiele razy jak chciałem to nie mogłem zapłacić blikiem

Fanatyk9piorunów

Co? XD to jak one działały, termometr z łóżka wysyłał aktualną temperaturę do chmury, ta decydowała co zrobić i odsyłała informację np "przestań grzać"? XDDD
IoT pełną gębą

Fenomen0piorunów

@ZohanTSW po prostu dostęp tylko z apki, apka gada tylko z zewnętrznym serwerem, nie ma niczego lokalnie, pewnie jedynie przycisk do parowania urządzenia. Czyli tak, tak jak piszesz xD

Fanatyk25piorunów

Dave Plummer nagrał filmik na temat awarii i generalnie wychodziłoby, że sama awaria jednego sharda AWS nie byłaby problemem, tylko że ludzie którzy stawiali na nich usługi zakładali że AWS "nie może mieć awarii" i nawet jeśli mieli uruchomione usługi zapasowe to... na tym samym shardzie xD

Lider2piorunów

@eloyard magia chmury nie? :grinning: Inna sprawa, że to pięknie unaoczniło skalę spatologizowania tego jak obecnie wszystko musi być "smart", wszystko musi mieć apkę i być permanentnie wpierdolone do sieci, bo inaczej będzie to będzie zły produkt. Jeszcze tylko dojebać na to subskrypcję i mamy komplet raka.

Fanatyk2piorunów

@Tom.Ash Tak naprawdę zależy przede wszystkim od budżetu, i SLA jakie ktoś ma z klientami. Obstawiam, że goście od łóżek nie mieli żadnego, i całość skończy się na pojęczeniu przez klientów.

Amazon to pewnie i rekomenduje, ale jeśli chodzi o narzędzia do wsparcia takich setupów, to jest krucho - RDSa postawisz jednym kliknięciem w 2 albo 3 AZ, ale już żeby robić multi-region, musisz się sam z tym cackać (chyba, że coś się w ostatnim roku zmieniło).

Tytan3piorunów

@LondoMollari zależy czy interesuje Cię HA czy DR. Chyba sam AWS dla Disaster Recovery rekomendował korzystanie z wielu regionów.

Fanatyk2piorunów

@LondoMollari kwestia co się stawia. Jak stawiasz usługę lokalną, to wal lokalnie na jeden region. Ale jak stawiasz coś kontynentalnego lub globalnego, to rozproszenie geograficzne staje się oczywiste. Bo zwielokrotnienie serwisów bez tego, to jak powiedzenie że mam backup, bo w kompie jest raid-1. A mówiąc prościej twierdzenie że "taka redundancja jest standardem" to jak w tym starym kawale, że najprostszym sposobem na przepaloną żarówkę jest ogłoszenie ciemności nowym standardem.

Fanatyk8piorunów

@eloyard Podobno padły wszystkie AZ (availability zone'y) w regionie us-east-1. Teoretycznie, właśnie setupy multi-AZ mają przed czymś takim chronić - np. bazy czy grupy autoscalingowe z reguły stawia się w rozproszeniu między wiele AZ, ale jest to daremne, kiedy padną wszystkie AZ-ki.

Jakby ktoś by bardzo chciał, to może oczywiście postawić infra w rozproszeniu na różne regiony, zamiast multi-AZ w obrębie jednego regionu, ale jest to trudniejsze, droższe i wolniejsze niż poleganie na AZ-kach, które są standardowym sposobem zapewnienia redundancji. Gdybym coś takiego miał stawiać, to prędzej bym się zastanowił nad rozproszeniem między wielu providerów cloudowych.

GURU6piorunów

@eloyard u nas kiedyś wyszło z jedną apką, że front i backend były spięte na krzyż xD

Fenomen20piorunów

Ciekaw jestem czy inżynierowie produkujący to gówno używają go xD.

Sum1piorunów

@matips ci co robią w security na pewno nie :smiley:

Lider2piorunów

@matips nie, przeciętnego hindusa nie stać na łóżko za 2000usd plus transport i cło

Fanatyk22piorunów

ciekawe czego jeszcze niedługo nie będzie można zrobić bez internetu

Lider0piorunów

@MostlyRenegade co najwyżej nie mogłem wziąć narzędzi i musiałem sobie radzić bez nich

Fanatyk1piorunów

@Felonious_Gru czyli jak się apka wyje*bała to miałeś fajrant, prawda?

Prawda? ( ͡° ͜ʖ ͡°)

Gruba ryba31piorunów

Dobrze ze to AWS nie kontrolowało samochodów, pociągów, samolotów

Gwiazdor1piorunów

@30ohm Masz bardzo wąską perspektywę i aroganckie podejście. Idealnie połączenie :grinning: Daj mi już spokój :grinning:

Fanatyk0piorunów

@elmorel czyli produkt się nie spina więc dajemy jednego dostawcę, bo przecież cloud jest taki wspaniały i nigdy nie padnie. Wybacz kolejny raz, ale robiłem w firmie z takim podejściem. Jak im jebnęła sprzedaż z powodu problemów z aplikacją właśnie z takiego podejścia, nagle znalazły się środki aby zrobić rozproszoną infrastrukturę.

Nadal uważam, że brak jakiegokolwiek zabezpieczenia nawet w postaci śpiącego środowiska u innego dostawcy to totalna amatorka.

Gwiazdor0piorunów

@Odczuwam_Dysonans Ale my tu dyskutujemy teraz o uzytku AWS w ogólności, a nie o samym designie rozwiznia, ktory jest po prostu tragiczny. Jak niżej gdzieś wspomniałem, brak dostępu do sieci to jest chyba jedna z pierwszych rzeczy o której powinni pomyśleć :grinning:

Fenomen4piorunów

@elmorel ale myślisz, że większość odbiorców takiego przykładowego łóżka znalazło informację, że w razie problemu z internetem ich sprzęt może nie nadawać się do użytku (zakładając że utknie na grzaniu/chłodzeniu)? Myślisz że to jest gdzieś zaznaczone?

Ja nie neguję rozwiązań chmurowych, ale nawet głupia Tuya opiera automatyzacje na bramce, a nie przetwarzaniu komend tylko za pośrednictwem zewnętrznego serwera. Te łóżka są przykładem złej implementacji IoT. Przecież to absurdalne, nie ma tutaj czego bronić. Użytkownik nie powinien mieć takich rozterek.

Gwiazdor1piorunów

@30ohm Znam takich jak ty, z jedna perspetywą i też gadają z równie wielką pewnością siebie nie majac pełnego przegladu sytuacji biznesowej, także nie imponuje mi to :grinning:

Fanatyk1piorunów

@elmorel obecnie pracuje w miejscu gdzie chmura to podstawa i opieranie produktu na jednym dostawcy to czysta głupota. My nie odczuliśmy że coś mocno było nie tak. Ale za to z usługami powiązanymi był problem. Ostatnia awaria AWS pokazuje czego nie kupować.

Gwiazdor1piorunów

@30ohm Swietnie, witam kolege z branży nadal twierdze, że masz aroganckie podejscie.

Fanatyk1piorunów

@elmorel wyobraź sobie że parę lat temu projektowałem soft i sprzęt pod iot torpedując debilne pomysły

Gwiazdor2piorunów

@30ohm I jasnie pan arbitralnie bedzie decydowal o potrzebach konsumentów i producentow. Niezła arogancja.

Fanatyk9piorunów

@elmorel to nie jest rozwój. To jest robienie elektro śmieci. W wielu przypadkach komunikacja online non-stop jest zbędna

Gwiazdor0piorunów

@30ohm To nie kupuj takich produktów. Nie rozumiem narzekania na rozwój technologiczny. Idź do wioski Amiszów się realizować :grinning:

Fanatyk4piorunów

@elmorel owszem ale ładowanie do wszystkiego połączenia do internetu to rak obecnych czasów

Gwiazdor2piorunów

@30ohm @PlatynowyBazant Przeciez to nie ma nic do rzeczy. Problem opisany w artykule to kwestia implementacji softu a nie tego z jakiego dostawcy firma korzystała.