Кадр из фильма Мстители: Война бесконечности
По сообщению пользователя dobrovolskiy 15 мая 2019 года в результате человеческой ошибки Яндекс удалил часть виртуальных машин в своем облаке.
Пользователь получил письмо от техподдержки Яндекса с таким текстом:
Сегодня мы проводили технические работы в Яндекс.Облаке. К сожалению, из-за человеческого фактора были удалены виртуальные машины пользователей в зоне ru-central1-c, которые хоть раз находились в статусе SUSPENDED. Мы сразу заметили ошибку и остановили удаление. Увы, некоторые ВМ и их boot-диски были удалены.
В результате пользователем были полностью потеряны некоторые продакшн-сервера. Бекапы у пострадавшего были, но часть данных всё равно утрачена безвозвратно. Обычно Яндекс компенсирует даун-тайм своих сервисов, согласно своей политике, но кто компенсирует потерю данных?
UPD Яндекс официально подтвердил инцидент и прокомментировал ситуацию.
Сервис Яндекс.облако был запущен в 2018 году. Это первый серьезный инцидент в его истории, но не первый в истории компании. В прошлом Яндекс.Почта однажды безвозвратно потеряла все вложения из хранимых писем, а клиент Яндекс.Диска при установке или обновлении стирал все файлы на компьютере пользователя.
Если вы столкнулись с чем-то подобными, приглашаю вас поделиться опытом в комментариях. Остальных призываю проверить свои данные в облаках и подумать о бэкапах.
Комментарии (232)
nrgian
17.05.2019 03:24+2Ну вот теперь только посмейте сказать, что «самый крутой хостер» в мире AWS не терял данные. У него было несколько крупных нашумевших аварий. Плюс большая куча мелких частных случае.
Вы можете потерять данные из-за чего угодно.
Из-за пожара в датацентре, из-за описанной в статье человеческой ошибки, из-за скачка электроэнергии и т.п.
Если вам эти данные действительно нужны — просто используйте для дублирования несколько разных датацентров (и лучше разных хостеров).
Jeditobe Автор
17.05.2019 03:28+2
Alexsandr_SE
17.05.2019 11:00Только сохранить так последние минуты\секунды весьма сложно будет.
prudnitskiy
17.05.2019 12:31+1Вопрос мотива. Если вам это действительно нужно — вы придумаете, как это сделать. Способы есть.
Alexsandr_SE
17.05.2019 13:34Есть, только ни очень больно могут ударить по производительности.
prudnitskiy
17.05.2019 18:37Безусловно, но это так же вопрос баланса. Или быстрее, но есть риск потерять данные (и он приемлим — скорость важнее), или надежнее, но скорость падает и нагрузка растет. Чудес не бывает.
dax
17.05.2019 16:58+5Подтверждаю на опыте нашей фирмы. 5 лет хостились на своих собственных серверах, расположенных в дата-центре. 3x сервера, 3x RAID, «ни единого разрыва».
Сейчас пробуем AWS и пока-что не очень все радужно. За 60 дней два раза полностью исчез инстанц. оба раза получили от амазона автоматическую отписку в стиле «сорян, такое бывает». Я, конечно, и сам понимаю, что не бывает 100% доступности. Но два факапа за 60 дней на одном единственном инстансе это не радует, от слова совсем.
Понятно, что у нас есть асинхронные бэкапы, понятно что можно их восстановить. Не понятно как спасать транзакции, прошедшие в последние минуты и часы, причем без потерь в производительности.
achekalin
17.05.2019 17:16+1В том и дело, что, при возне с физическими серверами, вопрос «что делать, если сервер упадет» возникает чаще как теоретический момент, вроде как «мы тут все уже настроили, все круто, а вдруг все же будет серверу алес»? Ответ понятен, ставим второй сервер, делаем на него репликацию данных. Но, как показывает жизнь, проверять вживую всю эту защиту приходится нечасто, потому что сервера, вообще говоря, горят довольно редко.
Но только не инстансы в публичных облаках. Чем более оторвано от физики предлагаемое к аренде решение, тем сложнее понять, что с ним происходит. Грубо, в AWS о ситуации на физическом хосте знает только ПО управления облаком (и из него может посмотреть сотрудник поддержки; только людей живых в ДЦ совсем мало, так что — разговор скорее про контролирующий софт). И если что-то пошло не так (а машин там дофига, понятное дело), не факт, что все успеет с упреждением переехать и спастись. Ну спасать данные, которые по договору можно потерять, смысла вообще нет. Проще запилить скрипт «да, шит-хеппенс, с вашей ВМ случилось именно это».
Ну и да, облака сильны другим, они не про отдельные виртуалки, они про много не очень надежных ВМ, которые в сумме, порождаясь по мере необходимости, выдерживают многое, в т.ч. и выход отдельных ВМ из строя.
Самое гадкое, что первая часть марлезонского балета подхода — это «я вместо одной ВМ запилю пару», вторая — «я вместо пары ВМ в одной AZ» запилю несколько в нескольких, плюс балансировку", а третья, «опытная» — «я кроме нескольких AZ добавлю-ка в мое приложение ВМ-ки в разных облаках, ибо х.з.» Плюс, конечно, хитровыдуманная балансировка, автоскейлинг и пр. — и счета становятся не в 2-3 раза больше, чем было бы не хецнере, а прямо сильно заметно выше.lubezniy
17.05.2019 22:05Физические сервера не только горят довольно редко, но и поставляются (если речь о собственных) довольно долго, да и денег стоят, хоть и разово. И, если нет резерва, то на случай возникновения проблемы с сервером надо закладывать запас времени и планировать действия.
achekalin
17.05.2019 23:20Да. На то мы и опытные ит-ники, чтобы планировать и иметь резерв, так? А то у вас и нас получается: либо быстро, но ненадёжно, либо долго, но дубово надёжно.
Странно только, что в облаках вм-ки крутятся на таких же железных машинах, но крутятся сильно менее надёжно. Нонсенс, но именно так!
d-stream
18.05.2019 01:26Есть еще промежуточный вариант: сейчас многие датацентры предлагают аренду серверов по цене аренды юнита. Притом по факту от отправки скана заказа менеджеру до получения kvm-доступа проходило 2-3 дня. Условия вполне лояльные — не менее года аренды.
Навскидку розничный ценник сервера получается как года этак 3 аренды.
То есть при необходимости держать сервер в датацентре — такой арендованный выходит в 4 раза дешевле.
dth_apostle
18.05.2019 00:11что-то как-то вам не везет. я работаю как минимум с 5-10 учетными записями AWS. На каждом по 2-5, есть и 15-20 instanc'ов. Работаю порядка 3 лет. Была ситуация у одного клиента, когда AWS предупредил, что есть проблемы на стороне физического оборудования, что может привести к потере данных — и поэтому надо пересоздать ваш инстанс — чтобы он был создан на новом физическим оборудованием.
setevoy4
18.05.2019 07:58> За 60 дней два раза полностью исчез инстанц
Работаю с AWS с 2015. Много Production-окружений, много клиентов/аккаунтов.
Ни разу такого не было.
Может быть, вы что-то не так делаете? Да и саппорт Амазона не отвечает в духе «сорян, такое бывает» — у них очень адекватная и грамотная поддержка.
Как отметили в комментарии выше — да, у них бывает необходимость переноса ЕС2 на другой физический сервер, но в таком случае они чуть ли не за месяц присылают уведомление, и не удаляют его — а останавливают, и переносят. За всё время такое было раза 3 за всё время.
lehha
17.05.2019 06:29Каждая такая история учит и закаляет админов настраивать реплики, бекапы, снимки. Просто лень не тренирует нас, а факапы — да.
Есть только один минус — прайс вырастает x2 из-за этой необходимости. Облака не спасают :(
Matvey-Kuk
17.05.2019 16:25Мы сделали проект мультиклаудным почти сразу и скорее ради шутки. Потом один из провайдеров положил регион на 7 часов. Поняли, что не зря шутили.
Terras
17.05.2019 06:44Помните лет 5-6 тому назад, какой-то облычный хостинг просто упал на 3 дня, и на хабре вели лайв-репортажи о том, что у кого лежит, и что им отвечает саппорт этого сервиса. Клауди или как-то так.
prostofilya
17.05.2019 07:59Мб gitlab? Правда, это было года 2-3 назад. У них был стрим с восстановлением бд, емнип.
sav6622
17.05.2019 09:06+1Облако Селектело ложилось на день почти (и человеческий фактор и трансиверы и все разом), и 404 вел некоторый репортаж…
chupasaurus
17.05.2019 12:12Лихо аватар amarao у вас отпечатался в памяти.
Drugok
17.05.2019 07:47В 2011 году амазон тоже терял данные:
go.backupland.com/crash/amazon_crash/amazon_crash.html
Так что делать бэкапы нужно не только тем сервисом, в котором данные хранятся.
vlreshet
17.05.2019 14:38В случае амазона — можно им же, но несколько копий в разных регионах. Один бекап в европу, другой в сша. Вероятность что проблема затронет сразу несколько регионов…
athacker
17.05.2019 18:00Можно им же, но это чревато: threatpost.com/hacker-puts-hosting-service-code-spaces-out-of-business/106761
CherryPah
17.05.2019 19:21+1так тут же не так давно проскакивала новость про AWS когда из-за ошибки в софте инстансы бэкапились с ошибкой и вне зависимости от кол-ва копий и их георспределенности восстановиться возможности не было — вместо инстанаса восстанавливалось что-то из /dev/random
В общем никогда нельзя пренебрегать третим правилом бэкапа — проверить разворачивается ли он
ZloyKishechnik
17.05.2019 07:56+4Не понимаю комментарий пользователя в твиттере
Там нельзя размещать ценные данные!
Да, отчасти, когда какой-нибудь разработчик покупает вдс для своих нужд и тестов он не будет заботиться о бекапах (порой), потому что ему нужно просто что-то протестировать; но тут держим в уме, что он имеет в себе локальные копиии своего проекта.
Да, когда школьник покупает вдс для своего майнкрафт сервера — он так же не будет хранить бекапы либо потому что не умеет, либо потому что «ну зачем, в облаках же все круто».
И почему-то все так и считают, что раз «облако», то SLA 99.999%, потери данных никогда не было, нет и не будет, просадок связности не случается и на «мейнтейнс» они никогда не уходят. Но, имхо, это все как-то в реальной жизни не работает.
Мне кажется, что на физических своих серверах, что на серверах в облаке все равно нужно хранить не один и не два бекапа в разных частях для критичных данных. То есть бекамим внутри вм, бекамим на другую вм в Облаке в другой зоне, бекамим на какую-нибудь домашнюю тачку, если есть. И, как мне кажется, это best practice. И даже если данные потеряются, то головной боли при их восстановлении будет намного меньше.
ultral
17.05.2019 08:31Мне нравится правило 3-2-1
- 3 копии данных минимум
- 2 разных типа носителя(облака/диски/лееты)
- 1 оффсайт бэкап
ZloyKishechnik
17.05.2019 08:36именно.
я, конечно, понимаю пользователей, которые хотят «купить и не париться» относительно ничего, ведь «ну я ж в облаке».
… но, думаю, эти пользователи не имеют за собой каких-нибудь огромных продакшенов. А те, у кого такое уже случалось, научены опытом…Henry7
17.05.2019 09:05Разве не в этом основное преимущество облака, на которое напирают маркетологи?
ZloyKishechnik
17.05.2019 09:09да, вы правы; кажется это то, на что опираются многие.
но ещё раз, как мне кажется, здравый человек или опытный администратор будет знать, что даже если сервер в облаке — это не сразу +100 к безопасности.Henry7
17.05.2019 10:15+2Есть другая крайность: здравый человек или опытный администратор очень очень скептически относятся к облакам и используют только в крайнем случае после долгих расчетов для очень специфических задач.
lubezniy
17.05.2019 14:39Почему обязательно специфических? Если у меня есть некий не критичный (задублированный) сервис, по которому не жалко в случае чего что-то потерять (их можно где угодно поднять ещё хоть десяток, и даже бывает нужно, если нагрузка большая), а реальное железо под него обойдётся дороже, вполне сойдёт.
DikSoft
17.05.2019 10:57— Уже не основное. нет.
Прозрачность в подсчетах затрат.
Быстрое масштабирование вверх и вниз, большой выбор готовых шаблонов, удобство мониторинга, резервного копирования и управления.
И только как плюс: вы можете построить отказоустойчивое решение. )
niko1aev
17.05.2019 15:13Это преимущество надо воспринимать не как гарантию, а как снижение вероятности.
Допустим есть вероятность в 3%, что что-то станет с продом за год. Это очень много.
Поэтому есть backup) Наличие backup позволяет нам восстановить данные. Но тоже не 100% данных, и не со 100% вероятностью. Допустим и там и там по 99%
Тогда наш урон это 3% * (1% + 1%) = 0.06%
Если мы к этом еще добавляем облако, которое теряет ваши данные раз в 1 млн случаев, то вероятность потерять данные для вас становится еще меньше.
Если мы копируем данные в другой ДЦ, от другого вендора — то мы еще раз многократно снижаем вероятность ущерба.
Вот за это снижение вероятности мы и платим.
nrgian
17.05.2019 16:58Разве не в этом основное преимущество облака, на которое напирают маркетологи?
А это такая же маркетоложная ложь как и «у нас скидки ДО 90%»
Облако позволяет избежать части проблем, например, легко мигрировать сервис на другой сервер, если железо на старом сдохло.
Но, к примеру:
Если ваш сервис очень плохо переживает неожиданное отключение — то никакая защита в облаке вам не поможет. Вы должны сами об этом позаботится.
awsswa59
17.05.2019 10:11Концепция сменилась. 3-2-1-1
Добавилось правило:
Еще одна копия находится в не доступа админа.
Что бы обидчивый админ не снес все копии разом.equand
18.05.2019 14:41Можно снизить до 2-2-2-1
2 Копии.
2 Разных места.
2 Проверка DR.
1 Место для копирования проверенного бекапа с защитой от перезаписи.
reff
18.05.2019 23:06Имхо, правильным будет "экземпляра", а не "копии". Продакшн и 2 резервные копии, одна из которых далеко-далеко.
Осталось только, чтобы авторы правила "3-2-1" (Veeam) сами стали использовать именно такую трактовку.
divanikus
17.05.2019 17:53Это называется Disaster Recovery Plan. Что делать если на ваш ДЦ вдруг упала ядерная бомба, например.
DikSoft
17.05.2019 08:07+1Ещё бы кто объяснял «стартаперам», что размещение хоть в каком облаке виртуальной машины в принципе не гарантирует её постоянной работы без плановых перезагрузок.
А то купят подписку, разместят на одной машине фронтенд, бакенд и базу данных, а потом возмущаются, что доступность не 100% и машинка «без предупреждения» перезагружается.
Нужна непрерывность — закладывайте дублирование ролей.
Про резервное копирование уже только ленивый не написал. Не буду повторяться.Pydeg
17.05.2019 09:03Но ведь высокая доступность и есть задача облака, иначе за что вообще ему платят? Другой вопрос, что есть SLA и его нужно учитывать
ZloyKishechnik
17.05.2019 09:11доступность доступностью, но факапы могут случаться же у всех.
dumistoklus
17.05.2019 09:34Факапы могут случаться у всех, но не дело переносить вину инициатора факапа на тех, кто не делает бекапы.
CDK
17.05.2019 10:31+3вина — на инициаторе факапа
проблема — у тех, кто не делает бекапы
это как с пешеходом
Stas911
17.05.2019 19:12+1Ну дык для этого и приложение должно быть спроектировано должным образом — фронты за ELB на ASG, база с Multy-AZ. Автоматически это только для полностью managed services делается (типа Lambda, Dynamo, S3 и тд)
The_Kf
17.05.2019 23:11Эммм нет: Ажур например так сразу и говорит, что раз в месяц будем тушить ваши виртуалки (и тушат, на несколько секунд правда) — берите несколько в разных availability zones (или как они там у них называются).
А мы, кстати, не тушим, хоть и похожи на Azure.
Mugik
17.05.2019 09:42Они и так всё знают. Просто это бизнес — баланс денег и рисков. Учиться этому долго и порой больно. Но я думаю пострадавшие сделают выводы и в следующий раз правильно оценят риски.
dimm_ddr
17.05.2019 11:13Риск это же вероятность. Оценка вполне могла быть корректной — что риск мал. Но даже событие с минимальной вероятностью может случится если вероятность все-таки выше 0. Как вы не оценивайте вы никуда не денетесь от этого факта. Собственно и здесь — случилось маловероятное событие. Бывает, никуда не деться.
wtpltd
17.05.2019 11:46Оценка вполне могла быть корректной — что риск мал.
Оно немножко не так. С одной стороны вы оцениваете свои потери: данные за час могу потерять, за день — дорого, за месяц — зарываем фирму. С другой стороны затраты — во что обойдется резервирование раз в час-день-месяц. И вот тогда можно подобрать приемлемый вариант резервирования.
А если просто брать, не знаю… Из 1000 виртуалок за год сдохла одна, значит вероятность .1% — нафиг бекапы — это «на авось». Потому что .1% это мало, но если туда попасть, то вы теряете 100% данных. Такие оценки создают иллюзию надежности.dimm_ddr
17.05.2019 13:53Ну нет, не все же так просто. Какие бы бэкапы вы не создавали все равно будет шанс что все сразу потеряется. Глобальный катаклизм, неуданое стечение обстоятельств когда три датацентра сразу накрылись, что угодно еще. В любом случае это оценка вида «как много денег будет стоить снижение риска до определенного процента», где проценты естественно условны, точно их подсчитать зачастую невозможно конечно. Плюс оценка вида «как много денег мы вообще можем потратить на защиту данных чтобы все еще остаться с прибылью». Чисто физически есть только один вариант как можно точно не потерять данные — вообще их не иметь.
arheops
17.05.2019 14:42Всегда есть шанс, что у вас бекапы забекапят уже убитую систему.
надежности в 1 не бывает.
Mugik
17.05.2019 13:59Ну если бы быть стартапером так легко и просто, что прикинул на коленке, ну может быть, а может и не быть, авось пронесёт, то наверно все были бы успешными бизнесменами. Опыт, чутьё, мозги и мышление на шаг вперед — вот что отличает успех от страданий.
DikSoft
17.05.2019 15:13… Я бы ещё одно качество добавил: компетентность (профессионализм). А то количество процентное дилетантов начинает реально портить репутацию оставшимся хорошим парням с горящими глазами.
negasus
17.05.2019 08:30Подтверждаю, коснулось.
Буду ли после этого уходить из Яндекса? Не факт.
Есть и плюсы, которые терять не хочется. Ну, например, довольно оперативная и адекватная ТП.
Prof
17.05.2019 08:31В который раз убеждаюсь: нельзя слепо доверять какому-либо одному провайдеру/облаку данные, которые критически важны для тебя. Всё важное необходимо хранить как минимум в нескольких местах.
Хотя пользуешься услугами таких гигантов как Яндекс или Гугл, почему-то до последнего не веришь, что у них такое возможно.negasus
17.05.2019 09:04+1Все так. Просто всегда хочется верить, что крупный провайдер позаботится о сохранности за меня) Но надо гнать от себя эту мысль
senglory
18.05.2019 10:47Крупный провайдер в первую очередь позаботится чтобы его задница была прикрыта страховкой. А также чтобы его лимит ответственности за повреждения был не выше разумной цифры.
xsash
17.05.2019 08:36-3А у меня уже «почту на домене» не могут вернуть около двух месяцев. Ящики еще работают, а управлять ими не могу.
archimed7592
17.05.2019 09:11Реальность такова, что нельзя складывать яйца в одну корзину. У всех бывают сбои, все допускают ошибки. Нельзя пользоваться одним интернет-провайдером, нельзя пользоваться одним мобильным оператором, нельзя пользоваться одним облаком.
Сам до недавнего времени держал все данные в OneDrive. Вот уже 2 месяца как Майкрософт заблокировал мою учётку и не отвечает на запросы. То же может случится и с любым другим облаком, в том числе корпоративным, уверяю, во всех политиках использования написано о том, что провайдер имеет на это право.
Все думают, что их это не коснётся. Я тоже так думал, я обыкновенный пользователь, ничего противозаконного не делал, но это всё никого не волнует — должен держать вторую копию или делать регулярные бэкапы, так и написано в условиях использования.
dumistoklus
17.05.2019 09:39-1Меня тоже коснулось. Очень жаль, но бекап у меня достаточно старый.
Больше всего поразило, что они даже не сделали рассылку по жертвам удаления. Никак не связались вообще. При этом они знали, какие машины были удалены — в личном кабинете в логе действий значилось «Пользователь '-' удалил виртуальную машину xxx».
Я сам буду съезжать с Яндекса, доверие было не оправдано.triton
17.05.2019 10:02Скажите, а вы по-прежнему разработчик в Яндексе или информация из вашей февральской статьи устарела?
Nashev
17.05.2019 12:57А как они отличили бы тех, кто действительно сам удалил, от тех, у кого удалилось при этом инцеденте?.. По времени в логах?
GarfieldX
17.05.2019 19:53+1Если бы разослали лишним, то ничего страшного не произошло бы. Достаточно добавить одно лишнее предложение с извинениями за ложное беспокойство.
VitalKoshalew
18.05.2019 22:36Вы хотите сказать, что у них ещё и логгирования всех действий нет, и админ может что-то удалить без подробных следов в логах?
Хотя тот факт, что уведомления не разослали, именно на это и намекает…
antirek
17.05.2019 10:28+2За одного битого двух не битых дают.
Вот теперь там можно размещать данные ;)
ustas33
17.05.2019 10:36Я.облако же на OpenStack же?
Тыкните плиз в решения по централизованному бакапу OpenStack VM из облака?
На Backup в том же облаке надеяться бессмысленно.
andrey_aksamentov
17.05.2019 10:43Так себе облачные технологии, если в них безвозвратно пропадают файлы.
Это уже облачная лотерея получается.dimm_ddr
17.05.2019 11:15Так она всегда такой и была. Вопрос только в том, насколько велика вероятность потерять данные. Полностью от такой вероятности можно избавиться только не имея данных вообще.
ksr123
19.05.2019 02:20А как эту вероятность вообще можно оценить в долгосрочной перспективе?
dimm_ddr
20.05.2019 09:59Оценивать известный опыт, смотреть на проффесионализм и время на рынке, на отзывы, на технические детали. Это сложный процесс и он, на самом деле, вне моей компетенции, я только примерно представляю как это делать.
P6i
17.05.2019 11:07Я вас, умоляю, как буд-то гугл не пролюбливал почту безвозвратно части клиентов, или авс не теряла данные ebs и не присылали письма счастья, что извините, но произошел факап. Хорошего Вам дня)
arheops
17.05.2019 11:44+2Яндекс письма не прислал. Вот ведь в чем вопрос.
negasus
17.05.2019 13:23-1Прислал. И, например, мне, даже наш менеджер звонил
arheops
17.05.2019 14:25Люди говорят, через 6+ часов только прислал. Когда они и сами были явно в курсе.
Амазон присылает через 15 минут.
А ibm/softlayer вообще присылает все включая " у нас тут свич глючит, вроде вас не затрагивает, но вы имейте в виду" и " мы не уверены, что проблема у нас, но тут spotted какието мелкие задержки(+5-10ms от нормы), мы выясняем и вам сообщим".ZloyKishechnik
17.05.2019 15:19может, стоит учеть тот факт, что ibm, aws и etc. на рынке облачных решений уже не первый и не второй год?
насколько я понимаю и исхожу из статьи, Я.Облако запустилось в 2018 году. Не прошло почти и года.
почти все учатся на своих ошибках; думаю, и они научатся.dimm_ddr
17.05.2019 16:03Общению с клиентами можно учиться и на чужих ошибках так-то. Как восстановить данные — это да, пусть учаться. Как сообщить о факапе клиентам — мировых примеров множество со всеми мыслимыми вариантами. Выбрать достаточно хороший чтобы поменьше терять репутацию на факапах не то чтобы невозможно. Для этого не нужно ждать своего факапа.
negasus
17.05.2019 18:24Ниже уже написали, я тоже к этому склоняюсь. Скорее всего, «подростковая» болезнь. Уверен, что они сами там в шоке, что такое смогло произойти) И, мне кажется, была некоторая паника, а не «простой инцидент», когда легко и непринужденно разослали письма
ElvenSailor
17.05.2019 11:15Нету средства от факапа кроме полного бэкапа.
tech42
17.05.2019 11:21Есть механизмы, который снижают риски.
Это правильное проектирование бэкэнда проекта. С учетом того, что может натворить человек в пьяном угаре.DrunkBear
17.05.2019 12:08Алкоголь опасен!
У одной игрушки была забавная авария — админы пролили пиво на прод.JerleShannara
17.05.2019 14:20+1В давние времена админы одного ДЦ два раза вытаскивали мне не мой сервак. Было забавно (а ещё я крыл себя матом за то, что сэкономил на IP-KVM, зато заучил, что перед sudo ifconfig eth0 down надо внимательно проверить, что это не ssh сессия).
arheops
17.05.2019 21:12Проще иметь два интерфейса на каждом серваке и managment сетку.
JerleShannara
18.05.2019 01:00Во времена заката эпохи серверов на Pentium-3, такие решения стоили весьма дорого. И ДЦ просил за второй порт тоже прилично.
arheops
18.05.2019 01:58Да, потому сервера просто соединялися попарно ;)
У нас даже в 2U както было 4 сервера и свич внутри одного корпуса.JerleShannara
18.05.2019 02:58Ну это либо google-style, либо колхозище =) То, что я тогда ездил «чинить» было HP LP1000r, да, у него был IPMI, но самого начального уровня, и высовывать его в интернет было весьма недальновидно, поэтому в сеть смотрел второй интерфейс. И сервант был один увы.
lubezniy
17.05.2019 14:42На сильно используемых серверах бэкап становится неактуальным уже в момент создания оного. Хотя с бэкапом и при таком раскладе подняться часто намного проще, чем без.
tech42
17.05.2019 11:16+1Печально. Проблема коснулась и меня… Камни в огород клиентов понятны, да они не делают бэкапы, да не так часто. Но зачем? Облачные сервера созданы для того, чтобы не заботиться об этом. Вероятность медного таза есть всегда. Особенно в реалиях, где продакнш сервер может упасть из-за проблем с блокировками. Но не суть.
Конкретно этот случай — большой косяк Яндекса и любого аналогичного ему сервиса.
Яндекс предупредил клиентов странным образом и не всех пострадавших. Это минус. О проблеме я узнал, когда дополнительный обслуживающий сервер сообщил мне об этом СМСкой (письмо от Яндекса пришло через несколько часов). Данные не пострадали, но пострадал аптайм. Т.е. когда машина падает по вине хостера — это можно пережить и сервер поднимался сам. а потом мы смотрим почему такое могло случиться. Держать дополнительный failover сервер стоит значительно дороже, чем доп.сервер обслуживания и не требуется на текущем этапе развития проекта.
Вторым косяком является то, что Яндекс допустил подобное. Это не техническая ошибка, а человеческий фактор. Существуют механизмы которые предупреждают, либо требуют дополнительных подтверждений при операциях массовых изменений.
Третий косяк: Яндекс молодцы, что сообщили об этом пострадавшим. Но остальные об инциденте не знали. Хорошо бы признать ошибку, извиниться и объяснить подробности. А еще бы возместить хоть как-то простой.
Клиентом Яндекса, вероятно, быть не перестану, но осадок остался. Былая надежность и стабильность Яндекса уже в прошлом после прихода эффективного менеджмента. Каждый раз да натыкаюсь на косяки в их продуктах.
dimm_ddr
17.05.2019 11:19Вы в целом правы, кроме вот этого:
Былая надежность и стабильность Яндекса уже в прошлом после прихода эффективного менеджмента.
Яндекс никогда не был шикарной компанией без косяков. Тут же в комментариях вспоминают случаи с почтой и с яндекс диском. Очередной менеджер может и сделал хуже, но оно никогда идеально не было все же.tech42
17.05.2019 12:15Косяки есть всегда и везде у любой компании. Я оцениваю ситуации в динамике. До 2012 Яндекса работал лучше, стабильнее и быстрее, а руководство более технически подкованным, чем сейчас. Сейчас же все иначе: менеджеры хорошо управляют людьми, но не проектами, просто потому что нет достаточного понимания специфики работы той или иной технологии. Зато есть скрам, дедлайны и показатели доходности проекта. И состряпать продающее решение "здесь и сейчас", пока его не состряпал конкурент работает. Сервис есть, приносит доход. Но до конца не отвечает ожиданиям потребителя. Как минимум по критерию безопасности и надежности. Эта тенденция глобальна.
Об том есть прекрасное размышление https://habr.com/ru/post/435268/
Касаемо косяков Почты и Диска — это как раз последствия. До 2012 года проблем Яндекса с точки зрения клиента можно было пересчитать по пальцам. Да, были, да крупные. Но сейчас крупнее и больше. Пример: https://habr.com/ru/post/357410/
dimm_ddr
17.05.2019 13:56+1И состряпать продающее решение «здесь и сейчас», пока его не состряпал конкурент работает. Сервис есть, приносит доход.
А раньше не так разве было? Вспомнить тот же яндекс бар например — чем не решение вида «получить денег побольше сейчас и плевать на репутацию»? Если говорить про конкретные сервисы, то вы наверное правы, но в целом компания никогда не славилась безупречным сервисом. И попахивающие решения у них всегда были, года не проходит без очередного связанного с ними скандала.
saboteur_kiev
17.05.2019 15:30Попахивающие продукты и качество отдельных взятых сервисов — не слишком связаны.
dimm_ddr
17.05.2019 16:07+1Если говорить о культуре менеджеров, то — вполне. Менеджер который решает состряпать дурно пахнущее решение чтобы получить денег здест и сейчас точно так же будет склоняться к решению в сервисе которое ухудшит его стабильность но позволит заработать вот сейчас. И наоборот — если есть забота о репутации, то и продукты пахнуть будут поменьше и сервисы работать постабильнее. И я говорю именно о том, что направление развития в Яндексе никогда не было в этом плане идеальным. Там всегда были готовы запилить что-то чтобы получить денег сейчас и пофиг на репутацию. Они не всегда это делали, да и вообще обобщать нехорошо, но говорить что эти процессы начались недавно — точно неправильно.
ksr123
19.05.2019 02:23Алекса-бар, помнится, лет 16 назад тоже был в антималварных базах, при этом компания считается серьезной.
whiplash
17.05.2019 12:32«Облачные сервера созданы для того, чтобы не заботиться об этом.»
А для чего тогда созданы облачные сервера?
Чтобы уносить туда прод без бэкапов, DR/HA/etc.?
Ну ок))
AlxDr
17.05.2019 13:41Облачные сервера созданы для того, чтобы не заботиться об этом.
Нет. Облачные серверы созданы для того, чтобы не держать инфраструктуру у себя. Но собирать систему за вас там никто не будет. Могут по доброте душевной или чтоб подстраховать себя, но не обязаны. А если их таки обязать и потребовать гарантии, то ценник будет уже не облачный, а заоблачный.
Это рассуждение сходно популярной мысли из недалёкого прошлого: «RAID создан для того, чтобы не думать о бэкапах» :)
tcapb1
17.05.2019 14:43В том же датацентре с облаком можно как правило арендовать и физическую железку, в несколько раз дешевле. Я держу данные в облаке только из-за удобства масштабирования: если ресурсов не хватает, то можно автоматом поднять ещё одну виртуалку или добавить ресурсов существующей. И судя по опыту, облака ни разу не надёжнее железок, по сути там добавляется ещё одна точка отказа: сама облачная инфраструктура.
Но стоит ли переплачивать в несколько раз только из-за удобного масштабирования?
tcapb1
17.05.2019 11:24Помню, когда-то было такое письмо от одного облачного провайдера (не буду говорить название):
«Сегодня в одном из пулов базовых дисков одновременно с работами по обновлению программного обеспечения произошел аппаратный сбой, повлекший за собой потерю данных. Проблема на данный момент устранена, однако часть дисков была уничтожена без возможности восстановления.
Резервное копирование указанной информации не производилось (ввиду особенностей работы виртуальных машин с блочными устройствами, крайне тяжело сделать надежную систему, которая сохраняла бы консистентные резервные копии, которые гарантированно корректно разворачивались при восстановлении).»
Когда-то давно, когда мне хватало виртуального хостинга — я вообще не задумывался о бэкапах, знал что всегда можно откатиться через веб-интерфейс провайдера (тоже не 100% надёжность конечно, но для тех сайтов хватало). Теперь мне приходится создавать аккаунт на другом облаке, настраивать бэкапы, следить чтобы в один момент бэкапы не перестали работать, периодически проверять нормально ли бэкапится, а если что-то случится — надеяться что инкремент соберётся без ошибок (а собирается он дофига времени).AlxDr
17.05.2019 13:37Некоторые облачные провайдеры (Hetzner, например) предоставляют услуги резервирования за дополнительную плату. Вероятно, где-то включено и в основной тариф.
Другое дело, что это ни раньше, ни сейчас не гарантия сохранности и off-site не заменяет. И облако может целиком стать недоступным по какой-то причине, и собственное здание может сгореть или туда придут какие-нибудь негодяи и всё украдут или арестуют.
Ну и собственный бэкап часто в принципе удобнее и возможности его шире.
algotrader2013
18.05.2019 12:23Помню, была статья о том, как Амазон просрал данные, и намеренно заблокировал бекап, чтобы клиент не мог его скачать. Причем, клиент был довольно крупный, что-то вроде выделенного менеджера имел. Тогда была самая логичная идея, что клиенту случайно попали данные других клиентов, и в амазоне решили, что если это вскроется, то будет большим зашкваром, чем самовольное удаление данных и бекапов с неадекватными объяснениями
prolis
17.05.2019 12:00Последней точкой в моём отношении к облакам был ответ ТП крупного эластичного облака о том, что для решении проблемы с недоступностью сервиса придётся дождаться ночной физической перезагрузки сервера с пятницы на субботу.
george1313
17.05.2019 12:28Я один в последнее время офигеваю с того, как яндекс дифферинцируется, лезет вовсюда, а потом случаются всякие факапы в виде постоянных автоаварий в каршеринге, смертей курьеров на работе в еде или потеря данных пользователей в облаке?
pbludov
17.05.2019 14:50И ведь не поспоришь! Если бы Яндекс ничего не делал, то и факапов не было бы.
Впрочем, в мире достаточно компаний, которые не факапят именно таким образом.
dedalqq
17.05.2019 12:28+1Если бы мне сказали, что мои данные были потеряны из за пожара, скочка напряжения или другого случая, я бы еще подумал о том, что бы понять и простить. Однако, может я странно рассуждаю, но среди всего этого, именно человеческий фактор выглядит как то уж очень не подобающе для такой компании. Случиться может все что угодно, от этого ни кто не застрахован. Но в моем понимание этот человеческий фактор выглядит как: «ой, да тут всего одно значение поправить, оно точно не может половать ни каких тестов, это же элементарно, ща поправим и быстренько в прод зафигачим и все ок будет». Это как то уж на слишком халатный случай смахивает и плохо продуманные техпроцессы. Имхо.
Arqwer
17.05.2019 13:24+3Как раз от скачка напряжения и от пожара скорее всего там всё защищено дублированием. А вот от человеческого фактора не может защитить вообще ничто.
Sonikelf
17.05.2019 19:08+1Почему ничто?
Как можно выпилить руками всё (описанное) так, что раскатать назад, пусть очень-очень долго и на некое состояние «до», невозможно вообще? Дубли, рейды, все нюансы tier? Или оно как-то вообще рандомно существует на миллионах носителей как некое пространство, рандомно занимающееся чтением-записью на основе некой файловой структуры?
Ладно, я не разбираюсь в облаках, но вот у меня хостер хранит 7 снимков (по одному на день недели) в отдельном кластере 100 гигового VPS. Даже, если я полностью выпиливаю VPS до состояния невменяемости, либо не дай bsod что-то случается с физиком у хостера, — они поднимают его «днём до». Что не так с облаком?
lubezniy
17.05.2019 14:45Т. е., в «такой» компании должны работать только роботы, которые человеческий фактор полностью исключают?
Cheater
17.05.2019 13:01«Когда хочешь удалить машины со статусом status: SUSPEND, но что-то пошло не так».
$ grep "SUSPEND" vm-status.log | grep -o -P "(?<=machine name: )\w+" | xargs -I{} rm -Rf /customer-data/vms/{} $ cat vm-status.log #... machine name: unneeded-vm status: SUSPEND machine name: customer-production-server status: ACTIVE machine name: customer-production-server status change: POWER at 2019-04-05 23:22:02 machine name: customer-production-server status change: SUSPENDED at 2019-04-05 20:13:02 # ...
izyk
17.05.2019 13:32+2Был тут на собеседовании в одной, почти такой же большой компании на должность сис. админа. Или как сейчас модно — SRE инженер. Не взяли, к сожалению, но было интересно. А главное, что я понял, растут они быстрее, чем успевают строить грамотную инфраструктуру. Поэтому, затыкают дыры грамотными админами, которые одним взглядом могут починить стойку серверов. При этом всё это, на живую.
Не ошибается, тот, кто ничего не делает. Хорошо это или нет, сложно сказать, не удивлюсь, если в Google, да и везде так же. Хотя в своей книге они пишут красиво. Кто ж в книге правду скажет.
В любом случае, админы грамотные, но всего лишь люди. И их очень редкие ошибки, могут вам дорого обойтись. В той же книге написано, что Гугл закладывает на отказоустойчивость процентов 99.99 остальное очень дорого. А при больших масштабах это много и не хотелось бы попасть в оставшийся процент.
Что надёжней? Хороший админ с кучей, не только вашего, оборудования или плохой админ на вашем сервере? ИМХО более менее одинаково, т.к. плохой админ всё сразу вряд ли сотрёт, совсем клинический случай не берём, но будут частые небольшие простои. А при хорошем админе простоев меньше, но уж если случилось, то как в этом случае.
AndrewShmig
17.05.2019 13:36-2А я об снимал видео на эту тему… ппц, если бы у меня сейчас всё слетело, то можно было бы «вешаться» и всему бизнесу кранты.
Бекапы бекапами, но на развёртывание, восстановление, судебные иски от заказчиков уйдёт уйма времени, денег, ресурсов и денег.
luckystewie
17.05.2019 15:38Если хотите уменьшить затраты на потери от простоя, то есть такой подход Infrastructure as Code + CI/CD. Обычно это означает что скрипты на полный запуск всего окружения храняться в репо и можно с нажатием кнопки перезапустить все разом. Терраформ хорошо подходит даже если у вас несколько облаков.
Некоторые компании (например нетфликс) преднамеренно выключают сервисы рандомным способом, что бы убедиться что система может с этим справится. Посмотрите в сторону Chaos Engineering.
Carburn
17.05.2019 16:15Shell это зло, нужно использовать нормальное прикладное ПО.
chupasaurus
17.05.2019 16:42Чем обёртка над шеллом отличается от шелла?
Нормальное прикладное ПО не заменит проблемы между клавиатурой и креслом™.
AI4
17.05.2019 16:27В этом случае проблема, на мой взгляд, скорее в том, что маркетологи (цель которых — продать) рекламируют облако (не только от Яндекса) как абсолютно надежное.
А реальность, увы, гораздо сложнее…
zenkov
17.05.2019 17:03+3Какие-то уж слишком добрые комментарии к подобному событию. Сервис открылся в прошлом году, в этом у него уже такое происшествие. Это ведь не стартап, это ведь не проект школьников. Особенно смешно на этом фоне выглядят комментарии типа «А вот у Amazon, у тех вообще вона чо». Вы же напоминаете тех кто при любой критике ситуации в стране, тут же вспоминают проблемы в США и Обаму.
Henry7
17.05.2019 18:25Яндекс, как и все остальные сервисы, не идеален. В Яндексе на разных уровнях инфраструктуры уже были сбои раньше, случаются в настоящее время, и будут происходить в будущем.
Радует, что в абсолютном большинстве случаев (а может и во всех) виной был человеческий фактор, т.е. наши с вами коллеги-расп*здяи, против которых защититься сложнее всего.
negasus
17.05.2019 18:27Ну кто его знает, что за команда пилит облако внутри Яндекса? Может быть, это вполне себе стартап с парой-тройкой десятков человек. А отсылка к AWS, как мне кажется, не потому, что это США. А потому, что это флагман рынка. Если бы они были, например, Шведы или Белорусы, отсылка работала бы так же
panteleymonov
17.05.2019 18:36Я тихо злорадствую. Вообще, по уже существующим отзывам по разным ресурсам, не удивлен их фейлу(ам). Можно сказать «я так и знал». С другой стороны тем кто побывал на их собеседованиях ни кто не скажет в фидбеках — «с каждым бывает и у нас бывают промахи». У меня даже такое впечатление что автор одной статьи там побывал. Так что те кто хотел, думаю, давно им все высказал.
kemko
17.05.2019 18:37Эм. А кого приводить в пример-то, кидаясь какашками? У AWS тоже можно нагуглить достаточно много инцедентов.
GarfieldX
17.05.2019 18:44+1И где же те специалисты, которые проходят все круги ада в процессе найма? Или эти быстро соображающие товарищи настолько резкие, что сначала делают, а потом только думают? После подобных происшествий навороченные собеседования Тындекса являются смехотворными. Не помогает ведь. Запороли пользовательские данные, кому то в руководстве следует застрелиться чтобы смыть такой позор.
pyrk2142
19.05.2019 07:26Иногда кажется, что реакция компаний и подход к публикации новостей приводят к тому, что сотрудники начинают считать, что успешно проходить собеседования и получать +10 000 рублей к зарплате гораздо важнее, чем не совершать самые тупые ошибки.
Например, я видел крайне мало новостей о каких-то сбоях/утратах данных/утечках баз, которые сопровождались бы пометкой о том, что технический руководитель лишён премии и бонусов, программисты отправлены на аттестацию, команда тестировщиков наказана, а безопасникам поставили в трудовую штамп «не подходит для умственной работы». Не то, что я бы считал, что все компании ничего не делают с разгильдяями, но пишут об этом крайне мало. И у многих работников возникает ощущение, что за эпичный провал почти ничего не будет, а вот удачное собеседование принесёт прибавку к зарплате, либо офис с полдником. Поэтому почему бы не стать экспертами в собеседованиях, либо не пытаться взяться за непосильные или неадекватно трудные задачи?algotrader2013
19.05.2019 22:06+1И правильно делают, что не наказывают. Если создать атмосферу страха, то нечего будет защищать в итоге. Толковые айтишники уйдут к конкурентам. Те, что останутся, будут по 10 раз все перепроверять, и находить любые причины не делать сколько нибудь рискованные фичи в принципе. Клиенты уйдут к конкурентам, где готовы к факапам, и за счет этого быстро развиваются.
AI4
20.05.2019 09:56У большинства серьезных компаний есть политика нераскрытия внутренней кухни. Вы никогда не узнаете кто виноват в конкретном косяке. Более того, в наиболее критичных случаях, виновного сотрудника даже не уволят сразу, поскольку в этом случае будет понятен виновный.
Компания может признать вину (взрыв Galaxy Note 7), не признать вину, но загладить ее (зеленые экраны Huawei Mate 20 Pro), не признать вину, по крайней мере сразу (потеря связи iPhone 4). Но в любом случае коммуницировать с сообществом покупателей будут либо топы, либо никто (втихую поменяют устройство).
Потому что успехи и неудачи принадлежать корпорации, а не отдельному человеку.
chernish2
17.05.2019 21:33Судя по комментариям, «человеческий фактор» по умолчанию воспринимается как ошибка админов. А ведь есть и другая возможность, тоже попадающая под определение человеческого фактора — умышленное приченение вреда (в том числе и замаскированное под ошибку). Быть может, технически всё сделано у них грамотно, но кто-то имел намерение сделать плохо, и обладал соответствующим уровнем доступа. Ну и сделал.
Ничего не утверждаю, просто фантазирую вслух.
yacloud
17.05.2019 21:35+6Привет, это команда Облака. Пишем здесь только сейчас, потому что было важно разобраться в произошедшем.
Коротко о самом инциденте. На 16 мая были запланированы регулярные технические работы по остановке и удалению виртуальных машин заблокированных пользователей. Но при формировании списка был применен неверный принцип фильтрации, и в список попали активные машины. Удаление было остановлено, как только мы обнаружили ошибку.
Мы приносим извинения за этой сбой. Всем, кого он затронул, в качестве компенсации будут начислены гранты в Облаке. Кроме того, для пострадавших пользователей мы временно отключим тарификацию снимков дисков. И гранты, и нулевая тарификация вступят в силу в течение трёх рабочих дней.
Для предотвращения подобного в будущем мы, во-первых, в рамках процедуры блокировок облаков строго разделим остановку и удаление виртуальной машины и её дисков. Во-вторых, при удалении диска виртуальной машины будет автоматически создаваться его копия.
Вот наш пост с подробным разбором произошедшего: https://cloud.yandex.ru/blog/posts/2019/05/16information
Temmokan
20.05.2019 06:46+1Любопытно, на сколько ещё давно известных грабель вы наступите, прежде чем будете тщательнее всматриваться в траву.
alexesDev
18.05.2019 12:12Это не первая проблема яндекс облака за пару месяцев. В прошлый раз 2 vm из 20 упали в read only из-за «балансировки хранилища» (база prometheus покараптилась). Это не должно быть моей проблемой, если я плачу 2-3 раза больше голого железа.
DimaSmirnov
18.05.2019 12:34Ну вот сколько раз приходилось мне обосновывать меджменту, что второй слейв с отставанием реплики на 1-2 часа просто необходим, чтобы защититься от DROP или TRUNCATE — и ведь спасало несколько раз от «шаловливых ручек» разрабов. Но это по-поводу SQL, а в том-же ceph есть «rbd_mirroring_delete_delay» / RBD Trash… да, дороже, но всё-же безопаснее.
$ rbd --cluster cluster1 --pool mirror rm image
Removing image: 100% complete...done.
$ rbd --cluster cluster2 --pool mirror info image
rbd: error opening image image: (2) No such file or directory
$ rbd --cluster cluster2 --pool mirror trash list --all --format json --pretty-format
[
{
"id": "10346b8b4567",
"name": "image"
}
]
$ rbd --cluster cluster2 --pool mirror trash restore --image new_image_name 10346b8b4567
$ rbd --cluster cluster2 --pool mirror ls
new_image_name
porn
19.05.2019 03:49Как-то решил войти в кинопоиск… По старому логину не пустило. Яндекс успокаивает: ничего не потерялось, если у вас есть старый логин, предлагает ввести: ввожу — такой логин не найден. Ок, думаю, накатаю вопрос в QA и всё решится. И накатал, но не отправил, потому что последнее поле требовало скан документа, удостоверяющего личность. ВТФ?!
skynet32rus
19.05.2019 10:16Однажды из Я.Облака пропали файлы сделанных заданий в универ, я их потерял а поддрежка не смогла ничего сделать. Пришлось заново сделать.
a1mighty
19.05.2019 10:16Не дошёл до яндекс.облака. Моё знакомство с ним выглядело примерно так: регистрация, нужен аккаунт яндекса (не было в нём нужды никогда). Ладно, логично, завёл их аккаунт, возвращаюсь — на следующем шаге с меня требуют номер телефона. Тут всё и закончилось, зачем им мой номер? Я даже не виртуалку хотел, а всего лишь воспользоваться API TTS.
kentuck1213
19.05.2019 10:16Боюсь представить его состояние на момент происшествия. Наверное он в глубокой тильте (((
maxorik
19.05.2019 10:16Ребята, так и отмечено (добавлено),
3. Прочие условияЯндекс не предоставляет никаких гарантий в отношении безошибочной и бесперебойной работы Платформы или отдельных её компонентов и/или функцийstukalovvd
19.05.2019 10:17С Яндекс диском работаю давно, всё работает стабильно, никаких сбоев не замечал.
Радует, что Яндекс на месте не стоит, придумывают новые сервисы и дорабатывают предыдущие.
Tavian
19.05.2019 10:17Много комментариев было про стоимость.
Публичное облако всегда дешевле использовать на коротком временном промежутке. Больших капитальных затрат не требует на Оборудование, помещение и т.д.
В долгосрочной перспективе облако будет всегда или почти всегда дороже.
Поэтому облако имеет смысл использовать для проверки своих бизнес идей. Если идея выгорела, можно обдумывать переход на свое оборудование или аренду стойки в дата центре с конкретным SLA или еще что-нибудь.
Может сам Яндекс будет предоставлять услуги с требованиями по SLA для тех, кто хочет инфраструктуру на аутсорс отдать.
Про потерю данных и резервное копирование. В Условиях использования указано: «3.1. Платформа предоставляется на условиях «как есть» (as is). Яндекс не предоставляет никаких гарантий в отношении безошибочной и бесперебойной работы Платформы или отдельных её компонентов...» и так далее.
В целом от инцидента Яндекс станет только лучше. Думаю, больше они такого фейла не допустят. Но могут допустить другие :)
А про доп услугу в виде SLA им стоит подумать.
Temmokan
20.05.2019 06:44То, что свои данные всё равно нужно самому сохранять — верно. «Не бывает слишком много резервных копий».
В таких случаях есть один ресурс, который никто и никогда не возместит: время. То время, которое потратите на восстановление из резервной копии, пусть даже все данные удалось спасти, и минут через немного всё заработало вполне штатно.
И да, «ложки вернули, но осадок остался». Доверия к Яндекс.Облаку теперь меньше. У меня большой опыт работы с AWS, но подобного рода ляпов там таки не было. Хотя были и потери данных, и потери виртуальных машин в целом.
wtpltd
Ну случается. У маленьких случается, у больших случается. В облаках случается, на земле случается.
Если у чувака потерялись критичные данные, значит он неправильно оценил риски и пролюбил стратегию резервного копирования.
Яндексу минус. Чуваку минус.
В остальном ситуация вполне рядовая. Яндекс чуваку шоколадку должен адекватную — явно не с небоскреб размером.
Kroid
Это с одной стороны. А с другой, у любого облака ценник чуть ли не до х10 доходит, по сравнению с физическими серверами. И если всё равно нужно за свой счёт беспокоиться о сохранности данных — по сути, админить самостоятельно свою инфраструктуру — то на кой тогда черт нужно это облако? За ту же цену можно будет купить в несколько раз больше ресурсов в виде физического железа, в добавок в двух разных ДЦ, ещё и админа-аутсорсера на сдачу нанять.
lubezniy
Ну а какие сложности тогда так и поступить? Другое дело, что, если физический сервер выйдет из строя, или админ-аутсорсер не так нажмёт на кнопку, эффект может быть тем же, а устранение проблемы — дольше. Так что ценник ценником, а организация системы таким образом, чтобы обеспечивать надёжное хранение, — этап отдельный и не менее необходимый.
x67
а не надо зря сущностей плодить… Вот если рядом с дата-центром взорвется ядерная боеголовка…
Люди, которые платили яндексу, платили больше, надеясь на экспертизу в области, надежность (как следствие) и предсказуемость результата. А оказалось, платили лишь за бренд. Не оправдываю их, но после такого как-то пропадает уверенность в таких компаниях. Если их надежды не оправдались, тогда вопрос — зачем пользоваться яндексом и платить больше?
Гораздо более дешевые хостеры годами живут без таких факапов. А тут такое. Выводы о ценности такой услуги напрашиваются сами собой. Буду рад услышать аргументированные доводы, почему после этого стоит выбрать яндекс, если таковые найдутся
lubezniy
Вопрос в том, на экспертизу в какой области — организации хостинга или таки надёжности хранения данных. Это всё же вещи сильно разные. И годами можно жить не то что без факапов, но и даже без бэкапов; опыт некоторых сервисов это подтверждает. А потом случится что-то, и приехали… В любом случае только пользователю известно, как именно для него нужно хранить данные надёжно. И это сугубо его экспертиза.
А убеждать кого-то в выборе того или иного сервиса или необходимости (отсутствия необходимости) его смены несерьёзно. Это каждый решает для себя сам.
x67
И тогда зачем платить больше?) Я ведь об этом. Цена должна быть обоснована.
Выбор сервиса для тех или иных целей — не выбор религии, поэтому убеждать и обосновывать нужно. Чем более осознанно вы подойдете к этому вопросу, тем меньше вреда смогут нанести возможные последствия, тем меньше времени займет дальнейшая работа и тем проще будет развиваться дальше.
lubezniy
Только вот всех деталей, на основании которых теоретически должно делаться такое осознание, не предоставляет никто. А заодно никто также не гарантирует, что не возьмёт в один прекрасный момент на работу раздолбая, хотя в этом случае (когда возьмут) с точки зрения потребителя следовало бы снизить плату за сервис. :)
Zundapp
Есть масса товарищей, которые выбрали хранение данных в облаке «потому что». Осознание выбора не приходит в момент выбора, увы.
Ах, да. Админу надо зарплату платить, да еще не стырил бы данных каких-нибудь ценных.
Менеджерам на квартальные не хватает из-за какого-то бездельника))
nrgian
Это же случайность.
То есть вы предлагаете полагаться «на авось».
wtpltd
Да, это так в любом случае. Это ваше имущество, ваша ценность. Это как с банком — он отвечает за ваши деньги. Но это не отменяет того, что вы должны беспокоится о сохранности денег и соблюдать какие-то правила безопасности. Ну, не знаю: не разглашать пин-код, платить в инете с виртуальной карты и т.п.
Аварийное восстановление, это отдельная самостоятельная задача. Необходимо решить за какой период времени мы можем себе позволить потерять данные, в какие сроки поднять резерв. В общем, протокол, в котором расписаны действия каждого в аварийной ситуации. И тренировки, конечно.
vitamin
> Это как с банком — он отвечает за ваши деньги.
После того, как деньги попали в банк, они перестали быть вашими (surprise!) Это собственность банка, а к вам у него возникает liability. С легальной точки зрения.
lubezniy
«отвечает» — это и есть liability.
prudnitskiy
облако нужно для гранулярности и скорости деплоя. Нельзя облаком заменять физические сервера «в лоб» — получается хуже и дороже.
scruff
Что мешает нанять штатного админа? Он и одной трети от рядового маркетолога-продажника не стОит. Зато вся инфраструктура под присмотром 7*24. Зачем постоянно надо экономить на спичках?
tcapb1
У разного масштаба бизнеса разные возможности. Если мы 95% времени справляемся без админа, то при наличии свободных ресурсов лучше нанять ещё одного программиста или продажника, их легко загрузить на 100%. Т.е. либо админ на аутсорс, который один раз настроит и будет заниматься восстановлением в случае аварии, либо своими силами. Кому-то крупному — да, админ обойдётся дешевле, чем облако. Но облака актуальнее как раз для мелкого бизнеса.
Но всё равно непонятно как сопоставить риски. Штатный админ точно так же может накосячить с бэкапами, и в случае чего мы окажемся в ситуации, что часть данных пропадёт.
Hardcoin
Интересно узнать, как вы себе поставляете зарплату "рядового маркетолога-продажника", если не секрет? Хороший админ*3 — это как бы дофига денег, точно про рядового говорим, а не про топ-менеджера?
sumanai
Админ не спит не отдыхает?
scruff
… Спит и отдыхает, но быть на телефоне — обязан. Имхо, сейчас бизнес диктует свои правила — если текущий админ не будет доступен 7*24 — вместо него будет доступен следующий админ, а текущий уволен.
16tomatotonns
В некоторых условиях и программист должен быть доступен 24х7, чтобы предельно быстро пофиксить баг. С доплатой и поблажками, разумеется.
POS_troi
У вас в профиле написано «IT-специалист» но мыслите вы как типичный «эффективный менеджер» — не нужно путать потребности бизнеса и откровенный шантаж спеца.
Нужно 24*7 — сразу минимум 2 админа, в идеале 3 ибо отпуска никто не отменял, а с вашим подходом, в самый критичный меомент админ скажет «гуляйте чудики, горите в своём котле».
d-stream
8-часовой рабочий день с двумя выходными в неделю — уже 3 человека для пятидневки без учета отпусков и больничных
mmvds
5 человек — 4 посменно по 12 часов с плавающим графиком + 1 человек 8*5 в обычное время или по графику на отпуска/болезни
vlivyur
Вот-вот, все почему-то забывают про отпуска (а в отпуск всем хочется почему-то в один сезон — летом), а это сразу +20%, либо кто-то непрофильный будет этим заниматься.
POS_troi
В зависимости от загрузки и проблемности инфраструктуры. На некоторые и 20и не хватит :)
scruff
Я что-нибудь говорил про работу в режиме 24*7? Быть доступным это значит реагировать на экстренные инциденты. Все остальные дела как и текучка в нерабочее время — идут лесом. Представьте — вы единственный админ в конторе. Отключили электричество или там потоп какой-нибудь. Ваши действия в нерабочее время — забить или отреагировать. Уверен, если забьете — то завтра же окажетесь на бирже труда — и это правильно.
Henry7
Затопило единственную серверную, а архивных копий нет? Админ стал больше не нужен.
scruff
Это не админ а тряпка тогда.
mayorovp
А что если я, как единственный админ в конторе, уехал в отпуск на море?
POS_troi
Не имеешь права, должен быть доступен 24*7, не дальше озера в районе города — твоё море :)
scruff
Ой это уже детский сад начинается. Какие проблемы — хоть за океан лети, подключай роуминг и будь на почте/васапе. Я сам работаю в таком режиме. Трудно — да. Напрягает — не то слово. Но ничего — не расплавился. Бывало решал из-за океана крупные инциденты типа вставшей 1С и глюкавившего Core-свитча — провода тыкать просил знакомых. Шеф потом премией этот решенный гемор компенсировал. Так что это и плюс того что ты один — до этого работал в команде 3-х «эффективных» вайтишнегов — и что — всё равно никто ничего не шарит, что делать если пришел пушной зверек, долбили по каждому случаю.
POS_troi
Если это есть нормальная ситуация и режим, то я лучше постою вон там в сторонке, с печеньками и одЫкватным ойти :)
scruff
Если вас устраивает стандартная зарплата ИТ, то можете еще и кофе налить — это пока бесплатно. Но если хотите чего-то большего по деньгам — придётся чем-то жертвовать.
vlivyur
А отдыхать когда?
POS_troi
Ойтишник или как? Всё делать на работе + платить аренду работодателю :)
edogs
Облако эЭто не вирт.хостинг где хостер по идее должен бегать вокруг с салфеткой и подливать винишко, пока рубишь деньги на сайте. Облако это просто гибкий резиновый железный сервер, все нюансы с сохранностью данных остаются, а с админством зачастую даже усложняются.
iproger
Сервера AWS явно больше х2.
algotrader2013
Хотелось бы увидеть рассчеты и тесты. К примеру, может получалось, что если считать за одно и тоже разделяемое за счет гипертрединга ядро с частотой 2.1 в облаке, и физическое ядро процессора i9-9900K c частотой 3.60 (а по факту, даже больше за счет небольшого повышения частоты в среднем) в хецнере, то выходило х3 по затратам?
То, что я видел, ну не выходит 3-4 раза от хецнера. Скорее в х7-х8 поверю
be_a_dancer
Меня больше смущает, что на стоимости в 1000 долларов за железо + администрирование, эти 3-4 раза дороже выйдут как раз 3-4 тысячи долларов. У бизнеса часто возникают серьезные вопросы в духе «А за что мы переплачиваем 2-3 тысячи вечнозеленых»? Не за надежность ли и возможность экстренно вертикально/горизонтально и быстро нарастить мощности? Не за сохранность ли данных и администрирование железок?
Такие минусы, как произошли у Яндекса заставляют задуматься о желании переехать туда. С их-то ценником, мне кажется, можно не допускать такое. Надеюсь, что они, реально, сделают выводы и такого не повторится.
P.S. Если потерялись данные — проблема не Яндекса, а бизнеса (читай, админа), который не настроил бэкапы, тут я не оправдываю. Хотя, конечно, хостинг доверие потерял и часть данных гарантированно вылетели в трубу — за это тоже нужно давать хорошую плюшку.
P.P.S. Если упал какой-то важный сервис по ошибке Яндекса, то, на мой взгляд, Яндекс должен возместить ущерб такого падения. И дать шоколадку сверху.
nrgian
Если вы пытаетесь использовать облачные ресурсы так как привыкли с ресурсами выделенными только вам — да, конечно, цена вас неприятно удивит.
Так ведь и смыл облака в том, что вы платите за реально потребляемые ресурсы, что позволяет вам простым и недорогим способом переживать пиковые скачки нагрузок и легко масштабироваться по небходимости — а за эту возможность нужно платить.
При грамотной архитектуре вашей системы, заточенной под облако, и при верной оценке профиля предполагаемой нагрузки — вы будете платить вполне разумную цену.
Обычно, чуть выше, чем без облаков — такая наценка за гибкость. Но это именно что чуть-чуть выше.
algotrader2013
Тут то дьявол и скрывается) Не раз видел кейсы, когда затраты на написание кода, который позволит запустить приложение в облаке, и грамотно его масштабировать + трата ресурсов рантайма на сериализацию и десериализацию превышали затраты на high-end железо в 10-30 раз.
Условно, есть платформа страховой/банка/ритейла, которая содержит БД и обслуживает несколько тысяч клиентов и миллионы транзакций в день.
Вася силами небольшой команды взял за основу двухзвенку с одной огромной реляционной базой, которую установил на 4-х процессорный сервер (сразу уточню, что на Xeon Gold, а не E7, ибо радикально дешевле) с 3ТБ ОЗУ и десятком NVMe дисков. И еще купил такой же, чтобы он реплицировал первый по транзакт логу, и ждал своего часа, пока первый сдохнет, и мог взять на себя нагрузку через 5 секунд даунтайма. Да, нанял толкового ДБА (возможно, на фриланс на часов 5 в месяц), который почистил SQL код от лишних блокировок. Итого, затратил $100K
Петя же сделал все, как надо. Разбил все по микросервисам, нанял 5 команд разрабов, каждая из которых превышает по размеру васину (ибо микросервисов много, а интеграции между ними сами себя не сделают), сделал грамотный шардинг, реализовал общение микросервисов между собой через кафку, развернул в облаке да подключил автоскейлинг и лоад беленсинг. И да, базу взял монго, ибо реляционные не сильно хорошо скейлятся как правило.
Суровая правда жизни в том, что хоть решение Пети и будет обходится в облаке не сильно дороже, а то и дешевле, чем решение Пети, развернутое на земле (все таки, автоскейлинг да сезонность сделают свое дело), но будет требовать х10, а то и х100 вычислительной мощности по сравнению с решением Васи, и где-то надо будет эту мощность купить. И вполне может выйти, что Петя будет платить $100K амазону каждый месяц. Не забываем, что +4 команды программистов тоже чего-то стоят. Да и средний программист Пети стоит дороже, чем у Васи, ибо не может стоит одинаково крутой спец по клауд решениям и зашкварный говнокодер, привыкший писать прямые запросы в СУБД;)
Krokodilewhile
Продукт «облако» это API для быстрого создания виртуалок в чужом дц, за свои деньги.
Оно совершенно не избавляет от необходимости реализовывать отказоустойчивость на более высоких уровнях, просто позволяет делать это чуть удобнее/быстрее.
Archon
Рассматривайте облако как дешёвый VPS на чужом сервере, который сегодня есть, а завтра нет. Не из-за сбоя или ошибки админа, а вот просто проснулись и его нет. И проектируйте инфраструктуру так, чтобы она это переживала.
Если сделать всё правильно и применять облака нужными местами, то из них с лихвой можно выжать те деньги, которые за них просят. Но, конечно, если хранить боевую СУБД на облачной виртуалке, то ничем хорошим это не закончится.
algotrader2013
А лучше так любой рантайм рассматривать) И к входным данным относиться, как к троянским коням, которые намеренно невалидны, чтобы увалить программу. И да, сарказм при написании коммента не включен.
lubezniy
Если хранить боевую СУБД на железном сервере, это тоже ничем хорошим не закончится, поскольку ресурс накопителей ограничен, а выходить из строя они могут неожиданно (как и тереться виртуалки).
friday13ant
Админить и бекапить, это разные вещи.
dumistoklus
Яндексу минусы за:
— то что сотрудник имеет доступ удалять машины клиентов
— за то что сотрудник удалил данные
— за то что не оповестили об аварии
— за то что не могут восстановить удаленные машины
Итого четыре минуса.
nexus478
И ведь правда, итого четыре минуса :)
scruff
Из 1-го минуса вытекает вопрос — не сливает ли Я-кс мои данные куда-то налево? Ибо это много хуже, чем эти данные просто потерять.
FRAGIL3
Думаете данные не удалили, а вырезали и вставили?
RedSnowman
Если сервера компании находятся в рф, то вопрос сей вытекать не должен.
Firz
Напишите в МДВ/ФСБ, может у них по свежее копия есть, из нее и восстановитесь)
edogs
Тут архитектурно-идеологическая ошибка, это же не железный сбой, не софтовый сбой нарушающий целостность данных, это отсутствие элементарной защиты от человеческого фактора.
Окей, пусть раздолбай админ снес часть облаков. Но почему они сразу были физически удалены? Почему не просто помечены удаленными? Ведь стандартная процедура это шаг 1) отключение вдс и шаг 2) удаление вдс. Почему яндекс выполнил оба этих шага одновременно? Ведь это элементарные «стандарты», в том числе на случай ошибок. Эти шаги должны быть разнесены по времени хотя бы на 24 часа, а то и больше.
Это все равно что админ ввел на сервере rm -rf / и всему пришел кирдык, потому что работал из под рута, а не из под юзера. Так не делается. Не на таком уровне.
cat_crash
Я бы немного подругому вопрос поставил. Есть идеальная картинка и есть бизнес который позволяет из маржи учитывать бизнес риски связанные с потерей информации.
А есть другой довольно большой слой обычных разработчиков и мелкого бизнеса которые ранают свои инстансы в облаке. Одним удобно с точки зрения деплоя, вторым с точки зрения стоимость\поддержкла.
По хорошему хотелось бы посмотреть на соотношение людей которые бекапят облака vs людей которые полагаются на хостинг оператора.
(Ps У самого 4 виртуалки в облаке Хецнера. Честно — не бекаплюсь)
IgorPie
У яндекса это постоянство качества. То папку с виндой снесут при удалении яндекс-диска, то виртуалки, теперь.