Comments 268
UFO just landed and posted this here
Это с одной стороны. А с другой, у любого облака ценник чуть ли не до х10 доходит, по сравнению с физическими серверами. И если всё равно нужно за свой счёт беспокоиться о сохранности данных — по сути, админить самостоятельно свою инфраструктуру — то на кой тогда черт нужно это облако? За ту же цену можно будет купить в несколько раз больше ресурсов в виде физического железа, в добавок в двух разных ДЦ, ещё и админа-аутсорсера на сдачу нанять.
Ну а какие сложности тогда так и поступить? Другое дело, что, если физический сервер выйдет из строя, или админ-аутсорсер не так нажмёт на кнопку, эффект может быть тем же, а устранение проблемы — дольше. Так что ценник ценником, а организация системы таким образом, чтобы обеспечивать надёжное хранение, — этап отдельный и не менее необходимый.
а не надо зря сущностей плодить… Вот если рядом с дата-центром взорвется ядерная боеголовка…
Люди, которые платили яндексу, платили больше, надеясь на экспертизу в области, надежность (как следствие) и предсказуемость результата. А оказалось, платили лишь за бренд. Не оправдываю их, но после такого как-то пропадает уверенность в таких компаниях. Если их надежды не оправдались, тогда вопрос — зачем пользоваться яндексом и платить больше?
Гораздо более дешевые хостеры годами живут без таких факапов. А тут такое. Выводы о ценности такой услуги напрашиваются сами собой. Буду рад услышать аргументированные доводы, почему после этого стоит выбрать яндекс, если таковые найдутся
Люди, которые платили яндексу, платили больше, надеясь на экспертизу в области, надежность (как следствие) и предсказуемость результата. А оказалось, платили лишь за бренд. Не оправдываю их, но после такого как-то пропадает уверенность в таких компаниях. Если их надежды не оправдались, тогда вопрос — зачем пользоваться яндексом и платить больше?
Гораздо более дешевые хостеры годами живут без таких факапов. А тут такое. Выводы о ценности такой услуги напрашиваются сами собой. Буду рад услышать аргументированные доводы, почему после этого стоит выбрать яндекс, если таковые найдутся
Вопрос в том, на экспертизу в какой области — организации хостинга или таки надёжности хранения данных. Это всё же вещи сильно разные. И годами можно жить не то что без факапов, но и даже без бэкапов; опыт некоторых сервисов это подтверждает. А потом случится что-то, и приехали… В любом случае только пользователю известно, как именно для него нужно хранить данные надёжно. И это сугубо его экспертиза.
А убеждать кого-то в выборе того или иного сервиса или необходимости (отсутствия необходимости) его смены несерьёзно. Это каждый решает для себя сам.
А убеждать кого-то в выборе того или иного сервиса или необходимости (отсутствия необходимости) его смены несерьёзно. Это каждый решает для себя сам.
И тогда зачем платить больше?) Я ведь об этом. Цена должна быть обоснована.
Выбор сервиса для тех или иных целей — не выбор религии, поэтому убеждать и обосновывать нужно. Чем более осознанно вы подойдете к этому вопросу, тем меньше вреда смогут нанести возможные последствия, тем меньше времени займет дальнейшая работа и тем проще будет развиваться дальше.
Выбор сервиса для тех или иных целей — не выбор религии, поэтому убеждать и обосновывать нужно. Чем более осознанно вы подойдете к этому вопросу, тем меньше вреда смогут нанести возможные последствия, тем меньше времени займет дальнейшая работа и тем проще будет развиваться дальше.
Только вот всех деталей, на основании которых теоретически должно делаться такое осознание, не предоставляет никто. А заодно никто также не гарантирует, что не возьмёт в один прекрасный момент на работу раздолбая, хотя в этом случае (когда возьмут) с точки зрения потребителя следовало бы снизить плату за сервис. :)
Есть масса товарищей, которые выбрали хранение данных в облаке «потому что». Осознание выбора не приходит в момент выбора, увы.
Ах, да. Админу надо зарплату платить, да еще не стырил бы данных каких-нибудь ценных.
Менеджерам на квартальные не хватает из-за какого-то бездельника))
Ах, да. Админу надо зарплату платить, да еще не стырил бы данных каких-нибудь ценных.
Менеджерам на квартальные не хватает из-за какого-то бездельника))
Гораздо более дешевые хостеры годами живут без таких факапов
Это же случайность.
То есть вы предлагаете полагаться «на авось».
Все облака — это по сути все теже компы с носителями «у Васи под столом», которые тоже могут сломаться. Просто в случае серьезных вендоров вероятность сбоя очень близка к 0 — мы платим за это деньги.
Как вариант, поступать можно по аналогии с бэкапом на диски — делать копию на два независимых диска, снижая вероятность сбоя в разы. Например, делать бекапы в гугл и в дропбокс как в наиболее стабильные.
Как вариант, поступать можно по аналогии с бэкапом на диски — делать копию на два независимых диска, снижая вероятность сбоя в разы. Например, делать бекапы в гугл и в дропбокс как в наиболее стабильные.
Чтобы говорить «мы платим за это деньги», надо, чтобы это самое «это» было прямо прописано в договоре между провайдером и пользователем; тогда у провайдера юридически появится ответственность за сбои как минимум на сумму уплаты. И то договор договором, а сбои всё равно происходят. И своей ответственности в договорах провайдеры, конечно, стараются избежать. А пользователю реально остаётся надеяться только на несколько разных мест (те же бэкапы в Google или Dropbox, что Вы привели как пример): хоть кто-нибудь, да не ошарашит сюрпризом.
UFO just landed and posted this here
облако нужно для гранулярности и скорости деплоя. Нельзя облаком заменять физические сервера «в лоб» — получается хуже и дороже.
Что мешает нанять штатного админа? Он и одной трети от рядового маркетолога-продажника не стОит. Зато вся инфраструктура под присмотром 7*24. Зачем постоянно надо экономить на спичках?
У разного масштаба бизнеса разные возможности. Если мы 95% времени справляемся без админа, то при наличии свободных ресурсов лучше нанять ещё одного программиста или продажника, их легко загрузить на 100%. Т.е. либо админ на аутсорс, который один раз настроит и будет заниматься восстановлением в случае аварии, либо своими силами. Кому-то крупному — да, админ обойдётся дешевле, чем облако. Но облака актуальнее как раз для мелкого бизнеса.
Но всё равно непонятно как сопоставить риски. Штатный админ точно так же может накосячить с бэкапами, и в случае чего мы окажемся в ситуации, что часть данных пропадёт.
Но всё равно непонятно как сопоставить риски. Штатный админ точно так же может накосячить с бэкапами, и в случае чего мы окажемся в ситуации, что часть данных пропадёт.
Интересно узнать, как вы себе поставляете зарплату "рядового маркетолога-продажника", если не секрет? Хороший админ*3 — это как бы дофига денег, точно про рядового говорим, а не про топ-менеджера?
UFO just landed and posted this here
… Спит и отдыхает, но быть на телефоне — обязан. Имхо, сейчас бизнес диктует свои правила — если текущий админ не будет доступен 7*24 — вместо него будет доступен следующий админ, а текущий уволен.
В некоторых условиях и программист должен быть доступен 24х7, чтобы предельно быстро пофиксить баг. С доплатой и поблажками, разумеется.
У вас в профиле написано «IT-специалист» но мыслите вы как типичный «эффективный менеджер» — не нужно путать потребности бизнеса и откровенный шантаж спеца.
Нужно 24*7 — сразу минимум 2 админа, в идеале 3 ибо отпуска никто не отменял, а с вашим подходом, в самый критичный меомент админ скажет «гуляйте чудики, горите в своём котле».
Нужно 24*7 — сразу минимум 2 админа, в идеале 3 ибо отпуска никто не отменял, а с вашим подходом, в самый критичный меомент админ скажет «гуляйте чудики, горите в своём котле».
Нужно 24*7 — сразу минимум 2 админа, в идеале 3 ибо отпуска никто не отменялдаже больше трех:
8-часовой рабочий день с двумя выходными в неделю — уже 3 человека для пятидневки без учета отпусков и больничных
Я что-нибудь говорил про работу в режиме 24*7? Быть доступным это значит реагировать на экстренные инциденты. Все остальные дела как и текучка в нерабочее время — идут лесом. Представьте — вы единственный админ в конторе. Отключили электричество или там потоп какой-нибудь. Ваши действия в нерабочее время — забить или отреагировать. Уверен, если забьете — то завтра же окажетесь на бирже труда — и это правильно.
Затопило единственную серверную, а архивных копий нет? Админ стал больше не нужен.
А что если я, как единственный админ в конторе, уехал в отпуск на море?
Не имеешь права, должен быть доступен 24*7, не дальше озера в районе города — твоё море :)
Ой это уже детский сад начинается. Какие проблемы — хоть за океан лети, подключай роуминг и будь на почте/васапе. Я сам работаю в таком режиме. Трудно — да. Напрягает — не то слово. Но ничего — не расплавился. Бывало решал из-за океана крупные инциденты типа вставшей 1С и глюкавившего Core-свитча — провода тыкать просил знакомых. Шеф потом премией этот решенный гемор компенсировал. Так что это и плюс того что ты один — до этого работал в команде 3-х «эффективных» вайтишнегов — и что — всё равно никто ничего не шарит, что делать если пришел пушной зверек, долбили по каждому случаю.
Быть доступным это значит реагировать на экстренные инциденты.
Это называется дежурство на дому. Есть у медиков.
У админов и прочего технического люда такого режима работы юридически вроде нету. И ваше требование вероятно не законно. Но даже если закрыть на это глаза и провести аналогию с медиками, то у админа на домашнем дежурстве час идет за половину рабочего часа, то есть за 16 часов дежурства набегает 8 часов сверхурочных. По закону сверхурочных не может быть более 4 часов в течении двух часов подряд. Следовательно ваше требование и с этой стороны не законно.
И это я не затрагиваю еще вопрос оплаты сверхурочных.
UPD. Прочитал дальнейшие комментарии. Вывод: на вас ездит бизнес как на лохе, а вы мало того что гордитесь этим, так еще и считаете что другие должны жить также. Не надо так.
Вы о сверхурочных у среднестатистического работодателя попросите и не забудьте все законами и статьями подкрепить. Но потом не удивляйтесь если всё будет как в этом ролике www.youtube.com/watch?v=R7zQ00Rrqsc ЗЫ Бизнес ездит на всех, на ком-то быстрее на ком-то медленнее. Я повторюсь — но не поверите, когда я работал в компании «эффективных» меня тот бизнес просто заездил. Сейчас — работаю один — начальство наезжает только по делу, поэтому почему бы не быть лояльным к компании с другой стороны?
всё будет как в этом ролике
Я и был в такой ситуации) Когда был молодой и неопытный и меня хотели напрячь, возмутился. Весь отдел 6 «админов» заржал. Тогда я осознал глубину задницы. Отдел терпил, как «ведро с крабами», и тут я выскочка, который не хочет так жить. И сменил профессию на программиста)
поэтому почему бы не быть лояльным к компании с другой стороны?
Так в том то и дело, что это личный выбор каждого, быть лояльным за плюшки, например как у вас премии, или нет, но уж никак не «профессиональный долг настоящего сварщика».
Бизнес ездит на всех, на ком-то быстрее на ком-то медленнее
Это совершенно нормально. Он так и должен поступать.
Бизнесу совсем незачем вас нанимать иначе.
Любой бизнес требует от вас работы выдавать больше, чем платит вам.
А разница между стоимостью созданного вами и полученным вами за это вознаграждением — идет на развитие бизнеса и на прибыль владельцам.
Без этого существование бизнеса смысла и лишено вовсе.
Тут вопрос только в том: устраивает ли лично вас лично ваша конкретная рабочая нагрузка и лично ваша конкретная компенсация за эту нагрузку.
у админа на домашнем дежурстве час идет за половину рабочего часаКоллега, поделитесь нормативным документом? Я раньше дежурил на телефоне за четверть ставки.
Это называется дежурство на дому. Есть у медиков.
А в полиции — это еще более строго.
Смею полагать, и у админов на каких-то «ядерных/космических объектах» и т.п. — тоже есть подобное. И, возможно, что и вполне официально «военизировано» несение службы там.
В остальных случаях — добровольное соглашение между работником и работодателем.
Бывает — с доплатой. Бывает — без оной.
Представьте — вы единственный админ в конторе. Отключили электричество или там потоп какой-нибудь. Ваши действия в нерабочее время — забить или отреагировать.
Мои действия — немедленно написать заявление об увольнении.
Уверен, если забьете — то завтра же окажетесь на бирже труда — и это правильно.
Нет. Я окажусь на бирже труда сегодня, а завтра я уже буду работать в нормальных условиях.
Я не админ, но знаю, что хороших админов сейчас днем с огнём не сыскать. Их разбирают как горячие пирожки. Так зачем сидеть в какой-то говноконторе, которая требует быть на связи 24/7, но нанимать админов на смену не хочет?
Представьте — вы единственный админ в конторе. Отключили электричество или там потоп какой-нибудь. Ваши действия в нерабочее время — забить или отреагировать.
Мои действия — немедленно написать заявление об увольнении.
Нет. Я окажусь на бирже труда сегодня, а завтра я уже буду работать в нормальных условиях.
Гы.
И потом эти люди еще обижаются, что им «так мало платят, какие работодатели жадные».
А мало платят просто за недостаточную ответственность по разрешению сложных для фирмы ситуаций.
Наблюдаю картину в фирме, где персонал делится на 2 больших класса:
Одни поддерживают работу фирмы годами, что бы не случилось. Не с восторгом, но выходят на работу в выходные, если очень надо (к слову, это раза 4 за 2 года). И эта часть сотрудников получает более чем нормальные зарплаты. Стабильно годами.
Им дают, если надо любые авансы, любые кредиты без процентов и пр. и пр.
Ну и «обычные», которые «от звонка до звонка» и зарплаты у них те самые, «кот наплакал».
Вы конечно скажите — «так им и платят, вот они и работают».
А я скажу, что причинно-следственная связь тут обратная.
И потом эти люди еще обижаются, что им «так мало платят, какие работодатели жадные».
Какие «эти люди»? Я вот не жалуюсь. Мне хорошо платят.
И хорошим админам сейчас тоже отлично платят. Думаю, они тоже не жалуются.
Наблюдаю картину в фирме, где персонал делится на 2 больших класса:
Одни поддерживают работу фирмы годами, что бы не случилось. Не с восторгом, но выходят на работу в выходные, если очень надо (к слову, это раза 4 за 2 года). И эта часть сотрудников получает более чем нормальные зарплаты. Стабильно годами.
Подождите. Какие два класса?
Я отвечал вот на это:
Представьте — вы единственный админ в конторе.
Как один админ может делиться на два класса?
Если в компании несколько админов и нормально организован «on call», то это нормальня ситуация. И конечно за «on call» должны доплачивать.
Представьте — вы единственный админ в конторе.
Как один админ может делиться на два класса?
Запросто.
Мне, в частности, в свое время говорили, что предпочитают работать именно со мной, потому что я всегда доступен, даже в выходные, даже поздней ночью, а вот другой админ включал рабочий телефон только с 8 и до 17 часов и только с понедельника по пятницу.
В результате мои нескромные запросы по зарплате никого и не смущали.
Когда фирма решала с кем из нас работать — на момент когда у них все активно развивалось — предпочитали меня.
При выходе на стагнацию — переключились на более дешевого специалиста, несмотря на некоторые проблемы с его доступностью.
И конечно за «on call» должны доплачивать.
Вам никто и ничего не должен.
Это — только как вы сами сможете договориться.
Вопрос оплаты — сугубо индивидуален.
Кого-то устраивает одна сумма и один стиль работы. А кого-то — другая сумма и другой стиль работы.
Упомянутый выше админ, спустя некоторое время, купил землю и сейчас строит там дом.
С этого момента он стал доступен на телефоне и в выходные и поздно вечером.
Догадываетесь, почему так стало?
Даю подсказку: построить свой дом — это дорого.
Представьте — вы единственный админ в конторе. Отключили электричество или там потоп какой-нибудь.
Либо у этого единственного мега-админа уже заранее написаны инструкции, что если отключилось электричество — охранник Вася или Петя щиток проверит. Если затопило — Сантехник Гриша пусть сушит. А я приду в понедельник, повключаю сервера. И мне ничего не будет, так как с руководством есть договоренность что подобные факапы меня не касаются.
Либо нужно заранее бить тревогу, что один админ — это нереально. Нужны отпуска, нужны выходные, нужны больничные. Минимум два, либо пусть нанимают аутсорс контору, с админами по вызову.
UFO just landed and posted this here
Нормально построенный «бизнес процесс» не предполагает наличие кого-то доступного 24х7…
Если нужна круглосуточная поддержка — это решается дежурными операторами в режимесутки\трое.
Это же только при определенном достаточном для организации этого масштабе предприятия.
Фирм, когда масштаб попадает на границу — уже надо бы, но возможности еще ограничено — полным-полно.
Не нужно возводить в абсолют — не требуется 100% обеспечения доступности. Проспите звонок — ну и проспите звонок. Как отдельный частный случай — это не критично. Главное, чтобы остальные 30 звонков не проспали.
Это всего лишь компромиссный вариант — если вы не уезжаете каждые выходные из города, то статистически вы скорее доступы, чем недоступны.
Этого вполне достаточно.
Другой вопрос: а устраивает ли это лично вас при лично вашей зарплате. Или возможно, вам имеет смысл поднять разговор о доплате из-за необходимости всегда быть на связи.
P.S.:
В большом количестве случаев даже и приезжать не нужно. А зачастую проблема решается даже не полноценным удаленным вмешательством, а всего-навсего командой по телефону «нажми зеленую кнопочку, дождись красной лампочки и нажми синюю кнопочку».
имеет смысл поднять разговор о доплате из-за необходимости всегда быть на связи.
Тут не о «доплате» надо вопрос поднимать, а о полноценной почасовой оплате по ставке. С повышающим коэффициентом в ночи и праздники. Потому, что нахождение в режиме standby — это точно такая же полноценная работа, так почему она должна оплачиваться как-то иначе?
Разумеется, в этом случае пропущенный звонок — повод для санкций, это работает в обе стороны. Кого-то такая модель работы устроит, наверное.
А если «на тебе три копейки сверху и будь доступен 24х7» — это лесом сразу.
у меня была такая работа, когда я был один админ, веб студия, могли позвонить и ночью и в выходные, но это были редкие ситуации, пара раз в год. А главное — там было адекватное начальство, которое понимало что я могу быть и недоступен, без всех этих закидонов «иначе уволим».
Ну и я принимал меры, чтобы меньше дёргаться. авто переключение нагрузки в резервный дц при проблемах в основном (несколько раз было, что дц перегревался, несколько раз отключали питание а дизель не запустился). И до сих пор им помогаю по звонку, хотя много лет там не работаю.
Ну и я принимал меры, чтобы меньше дёргаться. авто переключение нагрузки в резервный дц при проблемах в основном (несколько раз было, что дц перегревался, несколько раз отключали питание а дизель не запустился). И до сих пор им помогаю по звонку, хотя много лет там не работаю.
Как называется ваша контора, чтобы ни в коем случае туда не попасть? Первое ощущение что mail.ru group, но нет — админов там много.
Рассчитывать что админ доступен 100% это тупо. Он может уйти в отпуск (а отпуск это значит 0% доступность и никак иначе!), серьёзно заболеть, быть допустим в поезде где сотовые ловят пару часов в сутки (даже если успеет принять звонок, инет там может выдавать 100 кбит и то недолго, лично сталкивался), может просто быть за рулём, ответить может а что-то начать делать только через час, если в пробку не встанет… А если ваш админ просто вас бросит и сбежит, или умрёт — фирму можно закрывать? Есть способы уволиться с минимальной передачей дел или вообще без неё.
Это всё-равно что говорить «поставим 1 диск в сервер, если он сломается, то будет доступен новый диск, а этот выкинут». А что данные потеряются это видимо не важно. И новый админ точно потребует дообучения под местные реалии, как правильно обманывать тупое начальство и обходить его тупые закидоны итд.
Если ит для фирмы важно — админов должно быть МИНИМУМ 2. Иначе это беспросветная тупость руководства и ничего более.
Рассчитывать что админ доступен 100% это тупо. Он может уйти в отпуск (а отпуск это значит 0% доступность и никак иначе!), серьёзно заболеть, быть допустим в поезде где сотовые ловят пару часов в сутки (даже если успеет принять звонок, инет там может выдавать 100 кбит и то недолго, лично сталкивался), может просто быть за рулём, ответить может а что-то начать делать только через час, если в пробку не встанет… А если ваш админ просто вас бросит и сбежит, или умрёт — фирму можно закрывать? Есть способы уволиться с минимальной передачей дел или вообще без неё.
Это всё-равно что говорить «поставим 1 диск в сервер, если он сломается, то будет доступен новый диск, а этот выкинут». А что данные потеряются это видимо не важно. И новый админ точно потребует дообучения под местные реалии, как правильно обманывать тупое начальство и обходить его тупые закидоны итд.
Если ит для фирмы важно — админов должно быть МИНИМУМ 2. Иначе это беспросветная тупость руководства и ничего более.
Ой всё — нет времени читать вашу писанину — я всё равно при своем мнении.!
Это всё зависит от ресурсов. Как бы мы ни настраивали автоматическое резервирование, всё равно рано или поздно потребуется ручное вмешательство, возможно один раз за несколько лет, но потребуется. И здесь мы конечно можем посадить нескольких админов на зарплату и на круглосуточное дежурство, но довольно часто это overkill.
Возможно дешевле будет:
— делегировать эти функции другим сотрудникам (да даже руководству), если у них хватит квалификации
— договориться с админом таки быть доступным ночью/во время отпуска, денежно его смотивировать. Если заранее была договорённость о таких случаях, и админ не против — то я не вижу проблемы. Можно прописать время реакции на проблему.
— держать отдельного удалёнщика на случай экстренного восстановления в нерабочее время
— возможно в каких-то случаях выгоднее просто позволить сервису лежать до выхода админа на работу, и выплата компенсаций за простой будет дешевле, чем держать несколько человек.
Возможно дешевле будет:
— делегировать эти функции другим сотрудникам (да даже руководству), если у них хватит квалификации
— договориться с админом таки быть доступным ночью/во время отпуска, денежно его смотивировать. Если заранее была договорённость о таких случаях, и админ не против — то я не вижу проблемы. Можно прописать время реакции на проблему.
— держать отдельного удалёнщика на случай экстренного восстановления в нерабочее время
— возможно в каких-то случаях выгоднее просто позволить сервису лежать до выхода админа на работу, и выплата компенсаций за простой будет дешевле, чем держать несколько человек.
у любого облака ценник чуть ли не до х10 доходит, по сравнению с физическими серверами.Позвольте тут встрять. Мы очень любим сервера на ovh и hetzner, те что десктопные, соотношение цена/качество великолепное, но даже по сравнению с ними облако стоит всего в 3-4 раза дороже, при условии постоянной равномерной нагрузки. Если же речь идет о настоящем серверном оборудовании расположенном в настоящем качественном ДЦ и неравномерной нагрузке — облако раза в 2 дороже получится, не больше. Откуда разница в 10х?
если всё равно нужно за свой счёт беспокоиться о сохранности данных — по сути, админить самостоятельно свою инфраструктуру — то на кой тогда черт нужно это облако?Облако эЭто не вирт.хостинг где хостер по идее должен бегать вокруг с салфеткой и подливать винишко, пока рубишь деньги на сайте. Облако это просто гибкий резиновый железный сервер, все нюансы с сохранностью данных остаются, а с админством зачастую даже усложняются.
Сервера AWS явно больше х2.
но даже по сравнению с ними облако стоит всего в 3-4 раза дороже
Хотелось бы увидеть рассчеты и тесты. К примеру, может получалось, что если считать за одно и тоже разделяемое за счет гипертрединга ядро с частотой 2.1 в облаке, и физическое ядро процессора i9-9900K c частотой 3.60 (а по факту, даже больше за счет небольшого повышения частоты в среднем) в хецнере, то выходило х3 по затратам?
То, что я видел, ну не выходит 3-4 раза от хецнера. Скорее в х7-х8 поверю
Меня больше смущает, что на стоимости в 1000 долларов за железо + администрирование, эти 3-4 раза дороже выйдут как раз 3-4 тысячи долларов. У бизнеса часто возникают серьезные вопросы в духе «А за что мы переплачиваем 2-3 тысячи вечнозеленых»? Не за надежность ли и возможность экстренно вертикально/горизонтально и быстро нарастить мощности? Не за сохранность ли данных и администрирование железок?
Такие минусы, как произошли у Яндекса заставляют задуматься о желании переехать туда. С их-то ценником, мне кажется, можно не допускать такое. Надеюсь, что они, реально, сделают выводы и такого не повторится.
P.S. Если потерялись данные — проблема не Яндекса, а бизнеса (читай, админа), который не настроил бэкапы, тут я не оправдываю. Хотя, конечно, хостинг доверие потерял и часть данных гарантированно вылетели в трубу — за это тоже нужно давать хорошую плюшку.
P.P.S. Если упал какой-то важный сервис по ошибке Яндекса, то, на мой взгляд, Яндекс должен возместить ущерб такого падения. И дать шоколадку сверху.
Такие минусы, как произошли у Яндекса заставляют задуматься о желании переехать туда. С их-то ценником, мне кажется, можно не допускать такое. Надеюсь, что они, реально, сделают выводы и такого не повторится.
P.S. Если потерялись данные — проблема не Яндекса, а бизнеса (читай, админа), который не настроил бэкапы, тут я не оправдываю. Хотя, конечно, хостинг доверие потерял и часть данных гарантированно вылетели в трубу — за это тоже нужно давать хорошую плюшку.
P.P.S. Если упал какой-то важный сервис по ошибке Яндекса, то, на мой взгляд, Яндекс должен возместить ущерб такого падения. И дать шоколадку сверху.
А с другой, у любого облака ценник чуть ли не до х10 доходит, по сравнению с физическими серверами
Если вы пытаетесь использовать облачные ресурсы так как привыкли с ресурсами выделенными только вам — да, конечно, цена вас неприятно удивит.
Так ведь и смыл облака в том, что вы платите за реально потребляемые ресурсы, что позволяет вам простым и недорогим способом переживать пиковые скачки нагрузок и легко масштабироваться по небходимости — а за эту возможность нужно платить.
При грамотной архитектуре вашей системы, заточенной под облако, и при верной оценке профиля предполагаемой нагрузки — вы будете платить вполне разумную цену.
Обычно, чуть выше, чем без облаков — такая наценка за гибкость. Но это именно что чуть-чуть выше.
При грамотной архитектуре вашей системы, заточенной под облако, и при верной оценке профиля предполагаемой нагрузки — вы будете платить вполне разумную цену.
Тут то дьявол и скрывается) Не раз видел кейсы, когда затраты на написание кода, который позволит запустить приложение в облаке, и грамотно его масштабировать + трата ресурсов рантайма на сериализацию и десериализацию превышали затраты на high-end железо в 10-30 раз.
Условно, есть платформа страховой/банка/ритейла, которая содержит БД и обслуживает несколько тысяч клиентов и миллионы транзакций в день.
Вася силами небольшой команды взял за основу двухзвенку с одной огромной реляционной базой, которую установил на 4-х процессорный сервер (сразу уточню, что на Xeon Gold, а не E7, ибо радикально дешевле) с 3ТБ ОЗУ и десятком NVMe дисков. И еще купил такой же, чтобы он реплицировал первый по транзакт логу, и ждал своего часа, пока первый сдохнет, и мог взять на себя нагрузку через 5 секунд даунтайма. Да, нанял толкового ДБА (возможно, на фриланс на часов 5 в месяц), который почистил SQL код от лишних блокировок. Итого, затратил $100K
Петя же сделал все, как надо. Разбил все по микросервисам, нанял 5 команд разрабов, каждая из которых превышает по размеру васину (ибо микросервисов много, а интеграции между ними сами себя не сделают), сделал грамотный шардинг, реализовал общение микросервисов между собой через кафку, развернул в облаке да подключил автоскейлинг и лоад беленсинг. И да, базу взял монго, ибо реляционные не сильно хорошо скейлятся как правило.
Суровая правда жизни в том, что хоть решение Пети и будет обходится в облаке не сильно дороже, а то и дешевле, чем решение Пети, развернутое на земле (все таки, автоскейлинг да сезонность сделают свое дело), но будет требовать х10, а то и х100 вычислительной мощности по сравнению с решением Васи, и где-то надо будет эту мощность купить. И вполне может выйти, что Петя будет платить $100K амазону каждый месяц. Не забываем, что +4 команды программистов тоже чего-то стоят. Да и средний программист Пети стоит дороже, чем у Васи, ибо не может стоит одинаково крутой спец по клауд решениям и зашкварный говнокодер, привыкший писать прямые запросы в СУБД;)
Продукт «облако» это API для быстрого создания виртуалок в чужом дц, за свои деньги.
Оно совершенно не избавляет от необходимости реализовывать отказоустойчивость на более высоких уровнях, просто позволяет делать это чуть удобнее/быстрее.
Оно совершенно не избавляет от необходимости реализовывать отказоустойчивость на более высоких уровнях, просто позволяет делать это чуть удобнее/быстрее.
Рассматривайте облако как дешёвый VPS на чужом сервере, который сегодня есть, а завтра нет. Не из-за сбоя или ошибки админа, а вот просто проснулись и его нет. И проектируйте инфраструктуру так, чтобы она это переживала.
Если сделать всё правильно и применять облака нужными местами, то из них с лихвой можно выжать те деньги, которые за них просят. Но, конечно, если хранить боевую СУБД на облачной виртуалке, то ничем хорошим это не закончится.
Если сделать всё правильно и применять облака нужными местами, то из них с лихвой можно выжать те деньги, которые за них просят. Но, конечно, если хранить боевую СУБД на облачной виртуалке, то ничем хорошим это не закончится.
Рассматривайте облако как дешёвый VPS на чужом сервере, который сегодня есть, а завтра нет. Не из-за сбоя или ошибки админа, а вот просто проснулись и его нет.
А лучше так любой рантайм рассматривать) И к входным данным относиться, как к троянским коням, которые намеренно невалидны, чтобы увалить программу. И да, сарказм при написании коммента не включен.
Если хранить боевую СУБД на железном сервере, это тоже ничем хорошим не закончится, поскольку ресурс накопителей ограничен, а выходить из строя они могут неожиданно (как и тереться виртуалки).
А в облаке боевая СУБД будет хранится в вакууме? Или накопители там с секретной фабрики секретного производителя жестких дисков?
Скажем так — на сервере общего пользования (в облаке) пользователь вообще не знает, где и как лежат его данные, насколько сильно идёт загрузка по i/o от других клиентов и т. д. Считается только почему-то, что данные там лежат в нескольких копиях, и при выходе чего-то из строя это не становится проблемой. Но… короче, несколько мест, назначенных самим пользователем, всегда кошернее, чем один сервер или одно облако.
Админить и бекапить, это разные вещи.
UFO just landed and posted this here
Яндексу минусы за:
— то что сотрудник имеет доступ удалять машины клиентов
— за то что сотрудник удалил данные
— за то что не оповестили об аварии
— за то что не могут восстановить удаленные машины
Итого четыре минуса.
— то что сотрудник имеет доступ удалять машины клиентов
— за то что сотрудник удалил данные
— за то что не оповестили об аварии
— за то что не могут восстановить удаленные машины
Итого четыре минуса.
В остальном ситуация вполне рядовая.Мы бы так не сказали.
Тут архитектурно-идеологическая ошибка, это же не железный сбой, не софтовый сбой нарушающий целостность данных, это отсутствие элементарной защиты от человеческого фактора.
Окей, пусть раздолбай админ снес часть облаков. Но почему они сразу были физически удалены? Почему не просто помечены удаленными? Ведь стандартная процедура это шаг 1) отключение вдс и шаг 2) удаление вдс. Почему яндекс выполнил оба этих шага одновременно? Ведь это элементарные «стандарты», в том числе на случай ошибок. Эти шаги должны быть разнесены по времени хотя бы на 24 часа, а то и больше.
Это все равно что админ ввел на сервере rm -rf / и всему пришел кирдык, потому что работал из под рута, а не из под юзера. Так не делается. Не на таком уровне.
Я бы немного подругому вопрос поставил. Есть идеальная картинка и есть бизнес который позволяет из маржи учитывать бизнес риски связанные с потерей информации.
А есть другой довольно большой слой обычных разработчиков и мелкого бизнеса которые ранают свои инстансы в облаке. Одним удобно с точки зрения деплоя, вторым с точки зрения стоимость\поддержкла.
По хорошему хотелось бы посмотреть на соотношение людей которые бекапят облака vs людей которые полагаются на хостинг оператора.
(Ps У самого 4 виртуалки в облаке Хецнера. Честно — не бекаплюсь)
А есть другой довольно большой слой обычных разработчиков и мелкого бизнеса которые ранают свои инстансы в облаке. Одним удобно с точки зрения деплоя, вторым с точки зрения стоимость\поддержкла.
По хорошему хотелось бы посмотреть на соотношение людей которые бекапят облака vs людей которые полагаются на хостинг оператора.
(Ps У самого 4 виртуалки в облаке Хецнера. Честно — не бекаплюсь)
У яндекса это постоянство качества. То папку с виндой снесут при удалении яндекс-диска, то виртуалки, теперь.
Ну вот теперь только посмейте сказать, что «самый крутой хостер» в мире AWS не терял данные. У него было несколько крупных нашумевших аварий. Плюс большая куча мелких частных случае.
Вы можете потерять данные из-за чего угодно.
Из-за пожара в датацентре, из-за описанной в статье человеческой ошибки, из-за скачка электроэнергии и т.п.
Если вам эти данные действительно нужны — просто используйте для дублирования несколько разных датацентров (и лучше разных хостеров).
Вы можете потерять данные из-за чего угодно.
Из-за пожара в датацентре, из-за описанной в статье человеческой ошибки, из-за скачка электроэнергии и т.п.
Если вам эти данные действительно нужны — просто используйте для дублирования несколько разных датацентров (и лучше разных хостеров).
Только сохранить так последние минуты\секунды весьма сложно будет.
Вопрос мотива. Если вам это действительно нужно — вы придумаете, как это сделать. Способы есть.
Есть, только ни очень больно могут ударить по производительности.
Разумеется. САР-теорему ещё никто не обошел. Нет спала надеяться, что её обойдёт Яндекс. Поэтому план по сохранности данных нужно составлять с учётом своей специфики.
Безусловно, но это так же вопрос баланса. Или быстрее, но есть риск потерять данные (и он приемлим — скорость важнее), или надежнее, но скорость падает и нагрузка растет. Чудес не бывает.
Подтверждаю на опыте нашей фирмы. 5 лет хостились на своих собственных серверах, расположенных в дата-центре. 3x сервера, 3x RAID, «ни единого разрыва».
Сейчас пробуем AWS и пока-что не очень все радужно. За 60 дней два раза полностью исчез инстанц. оба раза получили от амазона автоматическую отписку в стиле «сорян, такое бывает». Я, конечно, и сам понимаю, что не бывает 100% доступности. Но два факапа за 60 дней на одном единственном инстансе это не радует, от слова совсем.
Понятно, что у нас есть асинхронные бэкапы, понятно что можно их восстановить. Не понятно как спасать транзакции, прошедшие в последние минуты и часы, причем без потерь в производительности.
Сейчас пробуем AWS и пока-что не очень все радужно. За 60 дней два раза полностью исчез инстанц. оба раза получили от амазона автоматическую отписку в стиле «сорян, такое бывает». Я, конечно, и сам понимаю, что не бывает 100% доступности. Но два факапа за 60 дней на одном единственном инстансе это не радует, от слова совсем.
Понятно, что у нас есть асинхронные бэкапы, понятно что можно их восстановить. Не понятно как спасать транзакции, прошедшие в последние минуты и часы, причем без потерь в производительности.
В том и дело, что, при возне с физическими серверами, вопрос «что делать, если сервер упадет» возникает чаще как теоретический момент, вроде как «мы тут все уже настроили, все круто, а вдруг все же будет серверу алес»? Ответ понятен, ставим второй сервер, делаем на него репликацию данных. Но, как показывает жизнь, проверять вживую всю эту защиту приходится нечасто, потому что сервера, вообще говоря, горят довольно редко.
Но только не инстансы в публичных облаках. Чем более оторвано от физики предлагаемое к аренде решение, тем сложнее понять, что с ним происходит. Грубо, в AWS о ситуации на физическом хосте знает только ПО управления облаком (и из него может посмотреть сотрудник поддержки; только людей живых в ДЦ совсем мало, так что — разговор скорее про контролирующий софт). И если что-то пошло не так (а машин там дофига, понятное дело), не факт, что все успеет с упреждением переехать и спастись. Ну спасать данные, которые по договору можно потерять, смысла вообще нет. Проще запилить скрипт «да, шит-хеппенс, с вашей ВМ случилось именно это».
Ну и да, облака сильны другим, они не про отдельные виртуалки, они про много не очень надежных ВМ, которые в сумме, порождаясь по мере необходимости, выдерживают многое, в т.ч. и выход отдельных ВМ из строя.
Самое гадкое, что первая часть марлезонского балета подхода — это «я вместо одной ВМ запилю пару», вторая — «я вместо пары ВМ в одной AZ» запилю несколько в нескольких, плюс балансировку", а третья, «опытная» — «я кроме нескольких AZ добавлю-ка в мое приложение ВМ-ки в разных облаках, ибо х.з.» Плюс, конечно, хитровыдуманная балансировка, автоскейлинг и пр. — и счета становятся не в 2-3 раза больше, чем было бы не хецнере, а прямо сильно заметно выше.
Но только не инстансы в публичных облаках. Чем более оторвано от физики предлагаемое к аренде решение, тем сложнее понять, что с ним происходит. Грубо, в AWS о ситуации на физическом хосте знает только ПО управления облаком (и из него может посмотреть сотрудник поддержки; только людей живых в ДЦ совсем мало, так что — разговор скорее про контролирующий софт). И если что-то пошло не так (а машин там дофига, понятное дело), не факт, что все успеет с упреждением переехать и спастись. Ну спасать данные, которые по договору можно потерять, смысла вообще нет. Проще запилить скрипт «да, шит-хеппенс, с вашей ВМ случилось именно это».
Ну и да, облака сильны другим, они не про отдельные виртуалки, они про много не очень надежных ВМ, которые в сумме, порождаясь по мере необходимости, выдерживают многое, в т.ч. и выход отдельных ВМ из строя.
Самое гадкое, что первая часть марлезонского балета подхода — это «я вместо одной ВМ запилю пару», вторая — «я вместо пары ВМ в одной AZ» запилю несколько в нескольких, плюс балансировку", а третья, «опытная» — «я кроме нескольких AZ добавлю-ка в мое приложение ВМ-ки в разных облаках, ибо х.з.» Плюс, конечно, хитровыдуманная балансировка, автоскейлинг и пр. — и счета становятся не в 2-3 раза больше, чем было бы не хецнере, а прямо сильно заметно выше.
Физические сервера не только горят довольно редко, но и поставляются (если речь о собственных) довольно долго, да и денег стоят, хоть и разово. И, если нет резерва, то на случай возникновения проблемы с сервером надо закладывать запас времени и планировать действия.
Да. На то мы и опытные ит-ники, чтобы планировать и иметь резерв, так? А то у вас и нас получается: либо быстро, но ненадёжно, либо долго, но дубово надёжно.
Странно только, что в облаках вм-ки крутятся на таких же железных машинах, но крутятся сильно менее надёжно. Нонсенс, но именно так!
Есть еще промежуточный вариант: сейчас многие датацентры предлагают аренду серверов по цене аренды юнита. Притом по факту от отправки скана заказа менеджеру до получения kvm-доступа проходило 2-3 дня. Условия вполне лояльные — не менее года аренды.
Навскидку розничный ценник сервера получается как года этак 3 аренды.
То есть при необходимости держать сервер в датацентре — такой арендованный выходит в 4 раза дешевле.
Навскидку розничный ценник сервера получается как года этак 3 аренды.
То есть при необходимости держать сервер в датацентре — такой арендованный выходит в 4 раза дешевле.
Ну, за 2-3 дня простоя посещаемого сервиса начальство по головке не погладит. Но тут, конечно, всё зависит от случая. По хорошему надо иметь аварийные планы и постоянно мониторить ситуацию, чтобы их оперативно менять, а также периодически делать «тренировочные» восстановления: это помогает оценить время восстановления, чтобы в случае реальной проблемы ориентировать начальство по срокам.
что-то как-то вам не везет. я работаю как минимум с 5-10 учетными записями AWS. На каждом по 2-5, есть и 15-20 instanc'ов. Работаю порядка 3 лет. Была ситуация у одного клиента, когда AWS предупредил, что есть проблемы на стороне физического оборудования, что может привести к потере данных — и поэтому надо пересоздать ваш инстанс — чтобы он был создан на новом физическим оборудованием.
> За 60 дней два раза полностью исчез инстанц
Работаю с AWS с 2015. Много Production-окружений, много клиентов/аккаунтов.
Ни разу такого не было.
Может быть, вы что-то не так делаете? Да и саппорт Амазона не отвечает в духе «сорян, такое бывает» — у них очень адекватная и грамотная поддержка.
Как отметили в комментарии выше — да, у них бывает необходимость переноса ЕС2 на другой физический сервер, но в таком случае они чуть ли не за месяц присылают уведомление, и не удаляют его — а останавливают, и переносят. За всё время такое было раза 3 за всё время.
Работаю с AWS с 2015. Много Production-окружений, много клиентов/аккаунтов.
Ни разу такого не было.
Может быть, вы что-то не так делаете? Да и саппорт Амазона не отвечает в духе «сорян, такое бывает» — у них очень адекватная и грамотная поддержка.
Как отметили в комментарии выше — да, у них бывает необходимость переноса ЕС2 на другой физический сервер, но в таком случае они чуть ли не за месяц присылают уведомление, и не удаляют его — а останавливают, и переносят. За всё время такое было раза 3 за всё время.
Сталкивались с такими же проблемами и отписками в Azure.
Каждая такая история учит и закаляет админов настраивать реплики, бекапы, снимки. Просто лень не тренирует нас, а факапы — да.
Есть только один минус — прайс вырастает x2 из-за этой необходимости. Облака не спасают :(
Есть только один минус — прайс вырастает x2 из-за этой необходимости. Облака не спасают :(
Помните лет 5-6 тому назад, какой-то облычный хостинг просто упал на 3 дня, и на хабре вели лайв-репортажи о том, что у кого лежит, и что им отвечает саппорт этого сервиса. Клауди или как-то так.
UFO just landed and posted this here
Облако Селектело ложилось на день почти (и человеческий фактор и трансиверы и все разом), и 404 вел некоторый репортаж…
Лихо аватар amarao у вас отпечатался в памяти.
cloudmouse у которых ceph сломался?
linode?
В 2011 году амазон тоже терял данные:
go.backupland.com/crash/amazon_crash/amazon_crash.html
Так что делать бэкапы нужно не только тем сервисом, в котором данные хранятся.
go.backupland.com/crash/amazon_crash/amazon_crash.html
Так что делать бэкапы нужно не только тем сервисом, в котором данные хранятся.
UFO just landed and posted this here
Можно им же, но это чревато: threatpost.com/hacker-puts-hosting-service-code-spaces-out-of-business/106761
так тут же не так давно проскакивала новость про AWS когда из-за ошибки в софте инстансы бэкапились с ошибкой и вне зависимости от кол-ва копий и их георспределенности восстановиться возможности не было — вместо инстанаса восстанавливалось что-то из /dev/random
В общем никогда нельзя пренебрегать третим правилом бэкапа — проверить разворачивается ли он
В общем никогда нельзя пренебрегать третим правилом бэкапа — проверить разворачивается ли он
Так у Яндекса же тоже только один цод лег, даже не регион, а цод.
Не понимаю комментарий пользователя в твиттере
Да, отчасти, когда какой-нибудь разработчик покупает вдс для своих нужд и тестов он не будет заботиться о бекапах (порой), потому что ему нужно просто что-то протестировать; но тут держим в уме, что он имеет в себе локальные копиии своего проекта.
Да, когда школьник покупает вдс для своего майнкрафт сервера — он так же не будет хранить бекапы либо потому что не умеет, либо потому что «ну зачем, в облаках же все круто».
И почему-то все так и считают, что раз «облако», то SLA 99.999%, потери данных никогда не было, нет и не будет, просадок связности не случается и на «мейнтейнс» они никогда не уходят. Но, имхо, это все как-то в реальной жизни не работает.
Мне кажется, что на физических своих серверах, что на серверах в облаке все равно нужно хранить не один и не два бекапа в разных частях для критичных данных. То есть бекамим внутри вм, бекамим на другую вм в Облаке в другой зоне, бекамим на какую-нибудь домашнюю тачку, если есть. И, как мне кажется, это best practice. И даже если данные потеряются, то головной боли при их восстановлении будет намного меньше.
Там нельзя размещать ценные данные!
Да, отчасти, когда какой-нибудь разработчик покупает вдс для своих нужд и тестов он не будет заботиться о бекапах (порой), потому что ему нужно просто что-то протестировать; но тут держим в уме, что он имеет в себе локальные копиии своего проекта.
Да, когда школьник покупает вдс для своего майнкрафт сервера — он так же не будет хранить бекапы либо потому что не умеет, либо потому что «ну зачем, в облаках же все круто».
И почему-то все так и считают, что раз «облако», то SLA 99.999%, потери данных никогда не было, нет и не будет, просадок связности не случается и на «мейнтейнс» они никогда не уходят. Но, имхо, это все как-то в реальной жизни не работает.
Мне кажется, что на физических своих серверах, что на серверах в облаке все равно нужно хранить не один и не два бекапа в разных частях для критичных данных. То есть бекамим внутри вм, бекамим на другую вм в Облаке в другой зоне, бекамим на какую-нибудь домашнюю тачку, если есть. И, как мне кажется, это best practice. И даже если данные потеряются, то головной боли при их восстановлении будет намного меньше.
Мне нравится правило 3-2-1
- 3 копии данных минимум
- 2 разных типа носителя(облака/диски/лееты)
- 1 оффсайт бэкап
именно.
я, конечно, понимаю пользователей, которые хотят «купить и не париться» относительно ничего, ведь «ну я ж в облаке».
… но, думаю, эти пользователи не имеют за собой каких-нибудь огромных продакшенов. А те, у кого такое уже случалось, научены опытом…
я, конечно, понимаю пользователей, которые хотят «купить и не париться» относительно ничего, ведь «ну я ж в облаке».
… но, думаю, эти пользователи не имеют за собой каких-нибудь огромных продакшенов. А те, у кого такое уже случалось, научены опытом…
Разве не в этом основное преимущество облака, на которое напирают маркетологи?
да, вы правы; кажется это то, на что опираются многие.
но ещё раз, как мне кажется, здравый человек или опытный администратор будет знать, что даже если сервер в облаке — это не сразу +100 к безопасности.
но ещё раз, как мне кажется, здравый человек или опытный администратор будет знать, что даже если сервер в облаке — это не сразу +100 к безопасности.
Есть другая крайность: здравый человек или опытный администратор очень очень скептически относятся к облакам и используют только в крайнем случае после долгих расчетов для очень специфических задач.
вы абсолютно правы
Почему обязательно специфических? Если у меня есть некий не критичный (задублированный) сервис, по которому не жалко в случае чего что-то потерять (их можно где угодно поднять ещё хоть десяток, и даже бывает нужно, если нагрузка большая), а реальное железо под него обойдётся дороже, вполне сойдёт.
Если планируешь опереться на облако, лучше иметь под рукой парашют.
— Уже не основное. нет.
Прозрачность в подсчетах затрат.
Быстрое масштабирование вверх и вниз, большой выбор готовых шаблонов, удобство мониторинга, резервного копирования и управления.
И только как плюс: вы можете построить отказоустойчивое решение. )
Прозрачность в подсчетах затрат.
Быстрое масштабирование вверх и вниз, большой выбор готовых шаблонов, удобство мониторинга, резервного копирования и управления.
И только как плюс: вы можете построить отказоустойчивое решение. )
Это преимущество надо воспринимать не как гарантию, а как снижение вероятности.
Допустим есть вероятность в 3%, что что-то станет с продом за год. Это очень много.
Поэтому есть backup) Наличие backup позволяет нам восстановить данные. Но тоже не 100% данных, и не со 100% вероятностью. Допустим и там и там по 99%
Тогда наш урон это 3% * (1% + 1%) = 0.06%
Если мы к этом еще добавляем облако, которое теряет ваши данные раз в 1 млн случаев, то вероятность потерять данные для вас становится еще меньше.
Если мы копируем данные в другой ДЦ, от другого вендора — то мы еще раз многократно снижаем вероятность ущерба.
Вот за это снижение вероятности мы и платим.
Допустим есть вероятность в 3%, что что-то станет с продом за год. Это очень много.
Поэтому есть backup) Наличие backup позволяет нам восстановить данные. Но тоже не 100% данных, и не со 100% вероятностью. Допустим и там и там по 99%
Тогда наш урон это 3% * (1% + 1%) = 0.06%
Если мы к этом еще добавляем облако, которое теряет ваши данные раз в 1 млн случаев, то вероятность потерять данные для вас становится еще меньше.
Если мы копируем данные в другой ДЦ, от другого вендора — то мы еще раз многократно снижаем вероятность ущерба.
Вот за это снижение вероятности мы и платим.
Разве не в этом основное преимущество облака, на которое напирают маркетологи?
А это такая же маркетоложная ложь как и «у нас скидки ДО 90%»
Облако позволяет избежать части проблем, например, легко мигрировать сервис на другой сервер, если железо на старом сдохло.
Но, к примеру:
Если ваш сервис очень плохо переживает неожиданное отключение — то никакая защита в облаке вам не поможет. Вы должны сами об этом позаботится.
Плюс проверка бэкапа, не забыли? :)
Концепция сменилась. 3-2-1-1
Добавилось правило:
Еще одна копия находится в не доступа админа.
Что бы обидчивый админ не снес все копии разом.
Добавилось правило:
Еще одна копия находится в не доступа админа.
Что бы обидчивый админ не снес все копии разом.
Имхо, правильным будет "экземпляра", а не "копии". Продакшн и 2 резервные копии, одна из которых далеко-далеко.
Осталось только, чтобы авторы правила "3-2-1" (Veeam) сами стали использовать именно такую трактовку.
Это все равно не помогает. Беда в необходимости синхронного лога репликации данных на другой точке. Когда речь идет про свое железо, можно сделать синхронный стендбай для базы, который висит на оптике в цоде, расположенном в 10 километрах. Латенси будет достотачно мал, даже для платежной системы или чего-нибудь такого. В облаках латенси между зонами или регионами (я уж не говорю про другое облако) не позволяет делать быстрые синхронные реплики.
Можно извращаться с N асинхронных реплик, в надежде, что суммарно получится восстановится in time. Можно попытаться разбить данные горизонтально на много реплик, чтоб снизить площадь поражения, но все равно гарантию это не даёт.
Справедливости ради, надо сказать, что Яндекс крупным клиентам в легкую оптику подтянет — все же локальность провайдера играет роль.
«мейнтейнс»
Maintenance — «мэйнтэнэнс».
Это называется Disaster Recovery Plan. Что делать если на ваш ДЦ вдруг упала ядерная бомба, например.
Ещё бы кто объяснял «стартаперам», что размещение хоть в каком облаке виртуальной машины в принципе не гарантирует её постоянной работы без плановых перезагрузок.
А то купят подписку, разместят на одной машине фронтенд, бакенд и базу данных, а потом возмущаются, что доступность не 100% и машинка «без предупреждения» перезагружается.
Нужна непрерывность — закладывайте дублирование ролей.
Про резервное копирование уже только ленивый не написал. Не буду повторяться.
А то купят подписку, разместят на одной машине фронтенд, бакенд и базу данных, а потом возмущаются, что доступность не 100% и машинка «без предупреждения» перезагружается.
Нужна непрерывность — закладывайте дублирование ролей.
Про резервное копирование уже только ленивый не написал. Не буду повторяться.
UFO just landed and posted this here
доступность доступностью, но факапы могут случаться же у всех.
Ну дык для этого и приложение должно быть спроектировано должным образом — фронты за ELB на ASG, база с Multy-AZ. Автоматически это только для полностью managed services делается (типа Lambda, Dynamo, S3 и тд)
Эммм нет: Ажур например так сразу и говорит, что раз в месяц будем тушить ваши виртуалки (и тушат, на несколько секунд правда) — берите несколько в разных availability zones (или как они там у них называются).
А мы, кстати, не тушим, хоть и похожи на Azure.
Они и так всё знают. Просто это бизнес — баланс денег и рисков. Учиться этому долго и порой больно. Но я думаю пострадавшие сделают выводы и в следующий раз правильно оценят риски.
Риск это же вероятность. Оценка вполне могла быть корректной — что риск мал. Но даже событие с минимальной вероятностью может случится если вероятность все-таки выше 0. Как вы не оценивайте вы никуда не денетесь от этого факта. Собственно и здесь — случилось маловероятное событие. Бывает, никуда не деться.
UFO just landed and posted this here
Ну нет, не все же так просто. Какие бы бэкапы вы не создавали все равно будет шанс что все сразу потеряется. Глобальный катаклизм, неуданое стечение обстоятельств когда три датацентра сразу накрылись, что угодно еще. В любом случае это оценка вида «как много денег будет стоить снижение риска до определенного процента», где проценты естественно условны, точно их подсчитать зачастую невозможно конечно. Плюс оценка вида «как много денег мы вообще можем потратить на защиту данных чтобы все еще остаться с прибылью». Чисто физически есть только один вариант как можно точно не потерять данные — вообще их не иметь.
Всегда есть шанс, что у вас бекапы забекапят уже убитую систему.
надежности в 1 не бывает.
надежности в 1 не бывает.
Ну если бы быть стартапером так легко и просто, что прикинул на коленке, ну может быть, а может и не быть, авось пронесёт, то наверно все были бы успешными бизнесменами. Опыт, чутьё, мозги и мышление на шаг вперед — вот что отличает успех от страданий.
Подтверждаю, коснулось.
Буду ли после этого уходить из Яндекса? Не факт.
Есть и плюсы, которые терять не хочется. Ну, например, довольно оперативная и адекватная ТП.
Буду ли после этого уходить из Яндекса? Не факт.
Есть и плюсы, которые терять не хочется. Ну, например, довольно оперативная и адекватная ТП.
В который раз убеждаюсь: нельзя слепо доверять какому-либо одному провайдеру/облаку данные, которые критически важны для тебя. Всё важное необходимо хранить как минимум в нескольких местах.
Хотя пользуешься услугами таких гигантов как Яндекс или Гугл, почему-то до последнего не веришь, что у них такое возможно.
Хотя пользуешься услугами таких гигантов как Яндекс или Гугл, почему-то до последнего не веришь, что у них такое возможно.
А у меня уже «почту на домене» не могут вернуть около двух месяцев. Ящики еще работают, а управлять ими не могу.
Кстати, а почему я не могу участвовать в опросе?
Реальность такова, что нельзя складывать яйца в одну корзину. У всех бывают сбои, все допускают ошибки. Нельзя пользоваться одним интернет-провайдером, нельзя пользоваться одним мобильным оператором, нельзя пользоваться одним облаком.
Сам до недавнего времени держал все данные в OneDrive. Вот уже 2 месяца как Майкрософт заблокировал мою учётку и не отвечает на запросы. То же может случится и с любым другим облаком, в том числе корпоративным, уверяю, во всех политиках использования написано о том, что провайдер имеет на это право.
Все думают, что их это не коснётся. Я тоже так думал, я обыкновенный пользователь, ничего противозаконного не делал, но это всё никого не волнует — должен держать вторую копию или делать регулярные бэкапы, так и написано в условиях использования.
Меня тоже коснулось. Очень жаль, но бекап у меня достаточно старый.
Больше всего поразило, что они даже не сделали рассылку по жертвам удаления. Никак не связались вообще. При этом они знали, какие машины были удалены — в личном кабинете в логе действий значилось «Пользователь '-' удалил виртуальную машину xxx».
Я сам буду съезжать с Яндекса, доверие было не оправдано.
Больше всего поразило, что они даже не сделали рассылку по жертвам удаления. Никак не связались вообще. При этом они знали, какие машины были удалены — в личном кабинете в логе действий значилось «Пользователь '-' удалил виртуальную машину xxx».
Я сам буду съезжать с Яндекса, доверие было не оправдано.
Скажите, а вы по-прежнему разработчик в Яндексе или информация из вашей февральской статьи устарела?
А как они отличили бы тех, кто действительно сам удалил, от тех, у кого удалилось при этом инцеденте?.. По времени в логах?
Если бы разослали лишним, то ничего страшного не произошло бы. Достаточно добавить одно лишнее предложение с извинениями за ложное беспокойство.
Вы хотите сказать, что у них ещё и логгирования всех действий нет, и админ может что-то удалить без подробных следов в логах?
Хотя тот факт, что уведомления не разослали, именно на это и намекает…
Хотя тот факт, что уведомления не разослали, именно на это и намекает…
За одного битого двух не битых дают.
Вот теперь там можно размещать данные ;)
Вот теперь там можно размещать данные ;)
Я.облако же на OpenStack же?
Тыкните плиз в решения по централизованному бакапу OpenStack VM из облака?
На Backup в том же облаке надеяться бессмысленно.
Тыкните плиз в решения по централизованному бакапу OpenStack VM из облака?
На Backup в том же облаке надеяться бессмысленно.
UFO just landed and posted this here
Я вас, умоляю, как буд-то гугл не пролюбливал почту безвозвратно части клиентов, или авс не теряла данные ebs и не присылали письма счастья, что извините, но произошел факап. Хорошего Вам дня)
Яндекс письма не прислал. Вот ведь в чем вопрос.
Прислал. И, например, мне, даже наш менеджер звонил
Люди говорят, через 6+ часов только прислал. Когда они и сами были явно в курсе.
Амазон присылает через 15 минут.
А ibm/softlayer вообще присылает все включая " у нас тут свич глючит, вроде вас не затрагивает, но вы имейте в виду" и " мы не уверены, что проблема у нас, но тут spotted какието мелкие задержки(+5-10ms от нормы), мы выясняем и вам сообщим".
Амазон присылает через 15 минут.
А ibm/softlayer вообще присылает все включая " у нас тут свич глючит, вроде вас не затрагивает, но вы имейте в виду" и " мы не уверены, что проблема у нас, но тут spotted какието мелкие задержки(+5-10ms от нормы), мы выясняем и вам сообщим".
может, стоит учеть тот факт, что ibm, aws и etc. на рынке облачных решений уже не первый и не второй год?
насколько я понимаю и исхожу из статьи, Я.Облако запустилось в 2018 году. Не прошло почти и года.
почти все учатся на своих ошибках; думаю, и они научатся.
насколько я понимаю и исхожу из статьи, Я.Облако запустилось в 2018 году. Не прошло почти и года.
почти все учатся на своих ошибках; думаю, и они научатся.
Общению с клиентами можно учиться и на чужих ошибках так-то. Как восстановить данные — это да, пусть учаться. Как сообщить о факапе клиентам — мировых примеров множество со всеми мыслимыми вариантами. Выбрать достаточно хороший чтобы поменьше терять репутацию на факапах не то чтобы невозможно. Для этого не нужно ждать своего факапа.
Ниже уже написали, я тоже к этому склоняюсь. Скорее всего, «подростковая» болезнь. Уверен, что они сами там в шоке, что такое смогло произойти) И, мне кажется, была некоторая паника, а не «простой инцидент», когда легко и непринужденно разослали письма
Нету средства от факапа кроме полного бэкапа.
Есть механизмы, который снижают риски.
Это правильное проектирование бэкэнда проекта. С учетом того, что может натворить человек в пьяном угаре.
Алкоголь опасен!
У одной игрушки была забавная авария — админы пролили пиво на прод.
У одной игрушки была забавная авария — админы пролили пиво на прод.
В давние времена админы одного ДЦ два раза вытаскивали мне не мой сервак. Было забавно (а ещё я крыл себя матом за то, что сэкономил на IP-KVM, зато заучил, что перед sudo ifconfig eth0 down надо внимательно проверить, что это не ssh сессия).
Проще иметь два интерфейса на каждом серваке и managment сетку.
error 588: the server is drunk
На сильно используемых серверах бэкап становится неактуальным уже в момент создания оного. Хотя с бэкапом и при таком раскладе подняться часто намного проще, чем без.
UFO just landed and posted this here
Печально. Проблема коснулась и меня… Камни в огород клиентов понятны, да они не делают бэкапы, да не так часто. Но зачем? Облачные сервера созданы для того, чтобы не заботиться об этом. Вероятность медного таза есть всегда. Особенно в реалиях, где продакнш сервер может упасть из-за проблем с блокировками. Но не суть.
Конкретно этот случай — большой косяк Яндекса и любого аналогичного ему сервиса.
Яндекс предупредил клиентов странным образом и не всех пострадавших. Это минус. О проблеме я узнал, когда дополнительный обслуживающий сервер сообщил мне об этом СМСкой (письмо от Яндекса пришло через несколько часов). Данные не пострадали, но пострадал аптайм. Т.е. когда машина падает по вине хостера — это можно пережить и сервер поднимался сам. а потом мы смотрим почему такое могло случиться. Держать дополнительный failover сервер стоит значительно дороже, чем доп.сервер обслуживания и не требуется на текущем этапе развития проекта.
Вторым косяком является то, что Яндекс допустил подобное. Это не техническая ошибка, а человеческий фактор. Существуют механизмы которые предупреждают, либо требуют дополнительных подтверждений при операциях массовых изменений.
Третий косяк: Яндекс молодцы, что сообщили об этом пострадавшим. Но остальные об инциденте не знали. Хорошо бы признать ошибку, извиниться и объяснить подробности. А еще бы возместить хоть как-то простой.
Клиентом Яндекса, вероятно, быть не перестану, но осадок остался. Былая надежность и стабильность Яндекса уже в прошлом после прихода эффективного менеджмента. Каждый раз да натыкаюсь на косяки в их продуктах.
Вы в целом правы, кроме вот этого:
Былая надежность и стабильность Яндекса уже в прошлом после прихода эффективного менеджмента.Яндекс никогда не был шикарной компанией без косяков. Тут же в комментариях вспоминают случаи с почтой и с яндекс диском. Очередной менеджер может и сделал хуже, но оно никогда идеально не было все же.
Косяки есть всегда и везде у любой компании. Я оцениваю ситуации в динамике. До 2012 Яндекса работал лучше, стабильнее и быстрее, а руководство более технически подкованным, чем сейчас. Сейчас же все иначе: менеджеры хорошо управляют людьми, но не проектами, просто потому что нет достаточного понимания специфики работы той или иной технологии. Зато есть скрам, дедлайны и показатели доходности проекта. И состряпать продающее решение "здесь и сейчас", пока его не состряпал конкурент работает. Сервис есть, приносит доход. Но до конца не отвечает ожиданиям потребителя. Как минимум по критерию безопасности и надежности. Эта тенденция глобальна.
Об том есть прекрасное размышление https://habr.com/ru/post/435268/
Касаемо косяков Почты и Диска — это как раз последствия. До 2012 года проблем Яндекса с точки зрения клиента можно было пересчитать по пальцам. Да, были, да крупные. Но сейчас крупнее и больше. Пример: https://habr.com/ru/post/357410/
И состряпать продающее решение «здесь и сейчас», пока его не состряпал конкурент работает. Сервис есть, приносит доход.А раньше не так разве было? Вспомнить тот же яндекс бар например — чем не решение вида «получить денег побольше сейчас и плевать на репутацию»? Если говорить про конкретные сервисы, то вы наверное правы, но в целом компания никогда не славилась безупречным сервисом. И попахивающие решения у них всегда были, года не проходит без очередного связанного с ними скандала.
Попахивающие продукты и качество отдельных взятых сервисов — не слишком связаны.
Если говорить о культуре менеджеров, то — вполне. Менеджер который решает состряпать дурно пахнущее решение чтобы получить денег здест и сейчас точно так же будет склоняться к решению в сервисе которое ухудшит его стабильность но позволит заработать вот сейчас. И наоборот — если есть забота о репутации, то и продукты пахнуть будут поменьше и сервисы работать постабильнее. И я говорю именно о том, что направление развития в Яндексе никогда не было в этом плане идеальным. Там всегда были готовы запилить что-то чтобы получить денег сейчас и пофиг на репутацию. Они не всегда это делали, да и вообще обобщать нехорошо, но говорить что эти процессы начались недавно — точно неправильно.
Алекса-бар, помнится, лет 16 назад тоже был в антималварных базах, при этом компания считается серьезной.
«Облачные сервера созданы для того, чтобы не заботиться об этом.»
А для чего тогда созданы облачные сервера?
Чтобы уносить туда прод без бэкапов, DR/HA/etc.?
Ну ок))
А для чего тогда созданы облачные сервера?
Чтобы уносить туда прод без бэкапов, DR/HA/etc.?
Ну ок))
Облачные сервера созданы для того, чтобы не заботиться об этом.
Нет. Облачные серверы созданы для того, чтобы не держать инфраструктуру у себя. Но собирать систему за вас там никто не будет. Могут по доброте душевной или чтоб подстраховать себя, но не обязаны. А если их таки обязать и потребовать гарантии, то ценник будет уже не облачный, а заоблачный.
Это рассуждение сходно популярной мысли из недалёкого прошлого: «RAID создан для того, чтобы не думать о бэкапах» :)
В том же датацентре с облаком можно как правило арендовать и физическую железку, в несколько раз дешевле. Я держу данные в облаке только из-за удобства масштабирования: если ресурсов не хватает, то можно автоматом поднять ещё одну виртуалку или добавить ресурсов существующей. И судя по опыту, облака ни разу не надёжнее железок, по сути там добавляется ещё одна точка отказа: сама облачная инфраструктура.
Но стоит ли переплачивать в несколько раз только из-за удобного масштабирования?
Но стоит ли переплачивать в несколько раз только из-за удобного масштабирования?
Помню, когда-то было такое письмо от одного облачного провайдера (не буду говорить название):
«Сегодня в одном из пулов базовых дисков одновременно с работами по обновлению программного обеспечения произошел аппаратный сбой, повлекший за собой потерю данных. Проблема на данный момент устранена, однако часть дисков была уничтожена без возможности восстановления.
Резервное копирование указанной информации не производилось (ввиду особенностей работы виртуальных машин с блочными устройствами, крайне тяжело сделать надежную систему, которая сохраняла бы консистентные резервные копии, которые гарантированно корректно разворачивались при восстановлении).»
Когда-то давно, когда мне хватало виртуального хостинга — я вообще не задумывался о бэкапах, знал что всегда можно откатиться через веб-интерфейс провайдера (тоже не 100% надёжность конечно, но для тех сайтов хватало). Теперь мне приходится создавать аккаунт на другом облаке, настраивать бэкапы, следить чтобы в один момент бэкапы не перестали работать, периодически проверять нормально ли бэкапится, а если что-то случится — надеяться что инкремент соберётся без ошибок (а собирается он дофига времени).
«Сегодня в одном из пулов базовых дисков одновременно с работами по обновлению программного обеспечения произошел аппаратный сбой, повлекший за собой потерю данных. Проблема на данный момент устранена, однако часть дисков была уничтожена без возможности восстановления.
Резервное копирование указанной информации не производилось (ввиду особенностей работы виртуальных машин с блочными устройствами, крайне тяжело сделать надежную систему, которая сохраняла бы консистентные резервные копии, которые гарантированно корректно разворачивались при восстановлении).»
Когда-то давно, когда мне хватало виртуального хостинга — я вообще не задумывался о бэкапах, знал что всегда можно откатиться через веб-интерфейс провайдера (тоже не 100% надёжность конечно, но для тех сайтов хватало). Теперь мне приходится создавать аккаунт на другом облаке, настраивать бэкапы, следить чтобы в один момент бэкапы не перестали работать, периодически проверять нормально ли бэкапится, а если что-то случится — надеяться что инкремент соберётся без ошибок (а собирается он дофига времени).
Некоторые облачные провайдеры (Hetzner, например) предоставляют услуги резервирования за дополнительную плату. Вероятно, где-то включено и в основной тариф.
Другое дело, что это ни раньше, ни сейчас не гарантия сохранности и off-site не заменяет. И облако может целиком стать недоступным по какой-то причине, и собственное здание может сгореть или туда придут какие-нибудь негодяи и всё украдут или арестуют.
Ну и собственный бэкап часто в принципе удобнее и возможности его шире.
Другое дело, что это ни раньше, ни сейчас не гарантия сохранности и off-site не заменяет. И облако может целиком стать недоступным по какой-то причине, и собственное здание может сгореть или туда придут какие-нибудь негодяи и всё украдут или арестуют.
Ну и собственный бэкап часто в принципе удобнее и возможности его шире.
Помню, была статья о том, как Амазон просрал данные, и намеренно заблокировал бекап, чтобы клиент не мог его скачать. Причем, клиент был довольно крупный, что-то вроде выделенного менеджера имел. Тогда была самая логичная идея, что клиенту случайно попали данные других клиентов, и в амазоне решили, что если это вскроется, то будет большим зашкваром, чем самовольное удаление данных и бекапов с неадекватными объяснениями
Последней точкой в моём отношении к облакам был ответ ТП крупного эластичного облака о том, что для решении проблемы с недоступностью сервиса придётся дождаться ночной физической перезагрузки сервера с пятницы на субботу.
Я один в последнее время офигеваю с того, как яндекс дифферинцируется, лезет вовсюда, а потом случаются всякие факапы в виде постоянных автоаварий в каршеринге, смертей курьеров на работе в еде или потеря данных пользователей в облаке?
Если бы мне сказали, что мои данные были потеряны из за пожара, скочка напряжения или другого случая, я бы еще подумал о том, что бы понять и простить. Однако, может я странно рассуждаю, но среди всего этого, именно человеческий фактор выглядит как то уж очень не подобающе для такой компании. Случиться может все что угодно, от этого ни кто не застрахован. Но в моем понимание этот человеческий фактор выглядит как: «ой, да тут всего одно значение поправить, оно точно не может половать ни каких тестов, это же элементарно, ща поправим и быстренько в прод зафигачим и все ок будет». Это как то уж на слишком халатный случай смахивает и плохо продуманные техпроцессы. Имхо.
Как раз от скачка напряжения и от пожара скорее всего там всё защищено дублированием. А вот от человеческого фактора не может защитить вообще ничто.
Почему ничто?
Как можно выпилить руками всё (описанное) так, что раскатать назад, пусть очень-очень долго и на некое состояние «до», невозможно вообще? Дубли, рейды, все нюансы tier? Или оно как-то вообще рандомно существует на миллионах носителей как некое пространство, рандомно занимающееся чтением-записью на основе некой файловой структуры?
Ладно, я не разбираюсь в облаках, но вот у меня хостер хранит 7 снимков (по одному на день недели) в отдельном кластере 100 гигового VPS. Даже, если я полностью выпиливаю VPS до состояния невменяемости, либо не дай bsod что-то случается с физиком у хостера, — они поднимают его «днём до». Что не так с облаком?
Как можно выпилить руками всё (описанное) так, что раскатать назад, пусть очень-очень долго и на некое состояние «до», невозможно вообще? Дубли, рейды, все нюансы tier? Или оно как-то вообще рандомно существует на миллионах носителей как некое пространство, рандомно занимающееся чтением-записью на основе некой файловой структуры?
Ладно, я не разбираюсь в облаках, но вот у меня хостер хранит 7 снимков (по одному на день недели) в отдельном кластере 100 гигового VPS. Даже, если я полностью выпиливаю VPS до состояния невменяемости, либо не дай bsod что-то случается с физиком у хостера, — они поднимают его «днём до». Что не так с облаком?
Т. е., в «такой» компании должны работать только роботы, которые человеческий фактор полностью исключают?
«Когда хочешь удалить машины со статусом 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
# ...
Был тут на собеседовании в одной, почти такой же большой компании на должность сис. админа. Или как сейчас модно — SRE инженер. Не взяли, к сожалению, но было интересно. А главное, что я понял, растут они быстрее, чем успевают строить грамотную инфраструктуру. Поэтому, затыкают дыры грамотными админами, которые одним взглядом могут починить стойку серверов. При этом всё это, на живую.
Не ошибается, тот, кто ничего не делает. Хорошо это или нет, сложно сказать, не удивлюсь, если в Google, да и везде так же. Хотя в своей книге они пишут красиво. Кто ж в книге правду скажет.
В любом случае, админы грамотные, но всего лишь люди. И их очень редкие ошибки, могут вам дорого обойтись. В той же книге написано, что Гугл закладывает на отказоустойчивость процентов 99.99 остальное очень дорого. А при больших масштабах это много и не хотелось бы попасть в оставшийся процент.
Что надёжней? Хороший админ с кучей, не только вашего, оборудования или плохой админ на вашем сервере? ИМХО более менее одинаково, т.к. плохой админ всё сразу вряд ли сотрёт, совсем клинический случай не берём, но будут частые небольшие простои. А при хорошем админе простоев меньше, но уж если случилось, то как в этом случае.
Не ошибается, тот, кто ничего не делает. Хорошо это или нет, сложно сказать, не удивлюсь, если в Google, да и везде так же. Хотя в своей книге они пишут красиво. Кто ж в книге правду скажет.
В любом случае, админы грамотные, но всего лишь люди. И их очень редкие ошибки, могут вам дорого обойтись. В той же книге написано, что Гугл закладывает на отказоустойчивость процентов 99.99 остальное очень дорого. А при больших масштабах это много и не хотелось бы попасть в оставшийся процент.
Что надёжней? Хороший админ с кучей, не только вашего, оборудования или плохой админ на вашем сервере? ИМХО более менее одинаково, т.к. плохой админ всё сразу вряд ли сотрёт, совсем клинический случай не берём, но будут частые небольшие простои. А при хорошем админе простоев меньше, но уж если случилось, то как в этом случае.
А я об снимал видео на эту тему… ппц, если бы у меня сейчас всё слетело, то можно было бы «вешаться» и всему бизнесу кранты.
Бекапы бекапами, но на развёртывание, восстановление, судебные иски от заказчиков уйдёт уйма времени, денег, ресурсов и денег.
Бекапы бекапами, но на развёртывание, восстановление, судебные иски от заказчиков уйдёт уйма времени, денег, ресурсов и денег.
Если хотите уменьшить затраты на потери от простоя, то есть такой подход Infrastructure as Code + CI/CD. Обычно это означает что скрипты на полный запуск всего окружения храняться в репо и можно с нажатием кнопки перезапустить все разом. Терраформ хорошо подходит даже если у вас несколько облаков.
Некоторые компании (например нетфликс) преднамеренно выключают сервисы рандомным способом, что бы убедиться что система может с этим справится. Посмотрите в сторону Chaos Engineering.
Некоторые компании (например нетфликс) преднамеренно выключают сервисы рандомным способом, что бы убедиться что система может с этим справится. Посмотрите в сторону Chaos Engineering.
тут должны скоро выложить интересный подкаст про бекапы, возможно кому-то будет интересно послушать в свете данного события =)))
Никто не застрахован от человеческого фактора.
Облака развеиваются ветром
Харе бухать!
Shell это зло, нужно использовать нормальное прикладное ПО.
Я из тех, кому яндекс подарил 200Гб на облачном диске за то, что их клиент попытался снести винду. Я доволен. С нетерпением жду ещё багов. Хочу терабайт.
В этом случае проблема, на мой взгляд, скорее в том, что маркетологи (цель которых — продать) рекламируют облако (не только от Яндекса) как абсолютно надежное.
А реальность, увы, гораздо сложнее…
А реальность, увы, гораздо сложнее…
Какие-то уж слишком добрые комментарии к подобному событию. Сервис открылся в прошлом году, в этом у него уже такое происшествие. Это ведь не стартап, это ведь не проект школьников. Особенно смешно на этом фоне выглядят комментарии типа «А вот у Amazon, у тех вообще вона чо». Вы же напоминаете тех кто при любой критике ситуации в стране, тут же вспоминают проблемы в США и Обаму.
Яндекс, как и все остальные сервисы, не идеален. В Яндексе на разных уровнях инфраструктуры уже были сбои раньше, случаются в настоящее время, и будут происходить в будущем.
Радует, что в абсолютном большинстве случаев (а может и во всех) виной был человеческий фактор, т.е. наши с вами коллеги-расп*здяи, против которых защититься сложнее всего.
Радует, что в абсолютном большинстве случаев (а может и во всех) виной был человеческий фактор, т.е. наши с вами коллеги-расп*здяи, против которых защититься сложнее всего.
Ну кто его знает, что за команда пилит облако внутри Яндекса? Может быть, это вполне себе стартап с парой-тройкой десятков человек. А отсылка к AWS, как мне кажется, не потому, что это США. А потому, что это флагман рынка. Если бы они были, например, Шведы или Белорусы, отсылка работала бы так же
Я тихо злорадствую. Вообще, по уже существующим отзывам по разным ресурсам, не удивлен их фейлу(ам). Можно сказать «я так и знал». С другой стороны тем кто побывал на их собеседованиях ни кто не скажет в фидбеках — «с каждым бывает и у нас бывают промахи». У меня даже такое впечатление что автор одной статьи там побывал. Так что те кто хотел, думаю, давно им все высказал.
Эм. А кого приводить в пример-то, кидаясь какашками? У AWS тоже можно нагуглить достаточно много инцедентов.
И где же те специалисты, которые проходят все круги ада в процессе найма? Или эти быстро соображающие товарищи настолько резкие, что сначала делают, а потом только думают? После подобных происшествий навороченные собеседования Тындекса являются смехотворными. Не помогает ведь. Запороли пользовательские данные, кому то в руководстве следует застрелиться чтобы смыть такой позор.
Круги ада можно пройти только в процессе работы.
Иногда кажется, что реакция компаний и подход к публикации новостей приводят к тому, что сотрудники начинают считать, что успешно проходить собеседования и получать +10 000 рублей к зарплате гораздо важнее, чем не совершать самые тупые ошибки.
Например, я видел крайне мало новостей о каких-то сбоях/утратах данных/утечках баз, которые сопровождались бы пометкой о том, что технический руководитель лишён премии и бонусов, программисты отправлены на аттестацию, команда тестировщиков наказана, а безопасникам поставили в трудовую штамп «не подходит для умственной работы». Не то, что я бы считал, что все компании ничего не делают с разгильдяями, но пишут об этом крайне мало. И у многих работников возникает ощущение, что за эпичный провал почти ничего не будет, а вот удачное собеседование принесёт прибавку к зарплате, либо офис с полдником. Поэтому почему бы не стать экспертами в собеседованиях, либо не пытаться взяться за непосильные или неадекватно трудные задачи?
Например, я видел крайне мало новостей о каких-то сбоях/утратах данных/утечках баз, которые сопровождались бы пометкой о том, что технический руководитель лишён премии и бонусов, программисты отправлены на аттестацию, команда тестировщиков наказана, а безопасникам поставили в трудовую штамп «не подходит для умственной работы». Не то, что я бы считал, что все компании ничего не делают с разгильдяями, но пишут об этом крайне мало. И у многих работников возникает ощущение, что за эпичный провал почти ничего не будет, а вот удачное собеседование принесёт прибавку к зарплате, либо офис с полдником. Поэтому почему бы не стать экспертами в собеседованиях, либо не пытаться взяться за непосильные или неадекватно трудные задачи?
И правильно делают, что не наказывают. Если создать атмосферу страха, то нечего будет защищать в итоге. Толковые айтишники уйдут к конкурентам. Те, что останутся, будут по 10 раз все перепроверять, и находить любые причины не делать сколько нибудь рискованные фичи в принципе. Клиенты уйдут к конкурентам, где готовы к факапам, и за счет этого быстро развиваются.
У большинства серьезных компаний есть политика нераскрытия внутренней кухни. Вы никогда не узнаете кто виноват в конкретном косяке. Более того, в наиболее критичных случаях, виновного сотрудника даже не уволят сразу, поскольку в этом случае будет понятен виновный.
Компания может признать вину (взрыв Galaxy Note 7), не признать вину, но загладить ее (зеленые экраны Huawei Mate 20 Pro), не признать вину, по крайней мере сразу (потеря связи iPhone 4). Но в любом случае коммуницировать с сообществом покупателей будут либо топы, либо никто (втихую поменяют устройство).
Потому что успехи и неудачи принадлежать корпорации, а не отдельному человеку.
Компания может признать вину (взрыв Galaxy Note 7), не признать вину, но загладить ее (зеленые экраны Huawei Mate 20 Pro), не признать вину, по крайней мере сразу (потеря связи iPhone 4). Но в любом случае коммуницировать с сообществом покупателей будут либо топы, либо никто (втихую поменяют устройство).
Потому что успехи и неудачи принадлежать корпорации, а не отдельному человеку.
Судя по комментариям, «человеческий фактор» по умолчанию воспринимается как ошибка админов. А ведь есть и другая возможность, тоже попадающая под определение человеческого фактора — умышленное приченение вреда (в том числе и замаскированное под ошибку). Быть может, технически всё сделано у них грамотно, но кто-то имел намерение сделать плохо, и обладал соответствующим уровнем доступа. Ну и сделал.
Ничего не утверждаю, просто фантазирую вслух.
Ничего не утверждаю, просто фантазирую вслух.
Привет, это команда Облака. Пишем здесь только сейчас, потому что было важно разобраться в произошедшем.
Коротко о самом инциденте. На 16 мая были запланированы регулярные технические работы по остановке и удалению виртуальных машин заблокированных пользователей. Но при формировании списка был применен неверный принцип фильтрации, и в список попали активные машины. Удаление было остановлено, как только мы обнаружили ошибку.
Мы приносим извинения за этой сбой. Всем, кого он затронул, в качестве компенсации будут начислены гранты в Облаке. Кроме того, для пострадавших пользователей мы временно отключим тарификацию снимков дисков. И гранты, и нулевая тарификация вступят в силу в течение трёх рабочих дней.
Для предотвращения подобного в будущем мы, во-первых, в рамках процедуры блокировок облаков строго разделим остановку и удаление виртуальной машины и её дисков. Во-вторых, при удалении диска виртуальной машины будет автоматически создаваться его копия.
Вот наш пост с подробным разбором произошедшего: https://cloud.yandex.ru/blog/posts/2019/05/16information
Это не первая проблема яндекс облака за пару месяцев. В прошлый раз 2 vm из 20 упали в read only из-за «балансировки хранилища» (база prometheus покараптилась). Это не должно быть моей проблемой, если я плачу 2-3 раза больше голого железа.
Ну вот сколько раз приходилось мне обосновывать меджменту, что второй слейв с отставанием реплики на 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
Как-то решил войти в кинопоиск… По старому логину не пустило. Яндекс успокаивает: ничего не потерялось, если у вас есть старый логин, предлагает ввести: ввожу — такой логин не найден. Ок, думаю, накатаю вопрос в QA и всё решится. И накатал, но не отправил, потому что последнее поле требовало скан документа, удостоверяющего личность. ВТФ?!
Однажды из Я.Облака пропали файлы сделанных заданий в универ, я их потерял а поддрежка не смогла ничего сделать. Пришлось заново сделать.
Не дошёл до яндекс.облака. Моё знакомство с ним выглядело примерно так: регистрация, нужен аккаунт яндекса (не было в нём нужды никогда). Ладно, логично, завёл их аккаунт, возвращаюсь — на следующем шаге с меня требуют номер телефона. Тут всё и закончилось, зачем им мой номер? Я даже не виртуалку хотел, а всего лишь воспользоваться API TTS.
Боюсь представить его состояние на момент происшествия. Наверное он в глубокой тильте (((
Ребята, так и отмечено (добавлено),
yandex.ru/legal/cloud_termsofuse/?lang=ru#index__section_hq4_3cp_1fb
3. Прочие условия
Яндекс не предоставляет никаких гарантий в отношении безошибочной и бесперебойной работы Платформы или отдельных её компонентов и/или функций
yandex.ru/legal/cloud_termsofuse/?lang=ru#index__section_hq4_3cp_1fb
Фотку классную подобрали))
С Яндекс диском работаю давно, всё работает стабильно, никаких сбоев не замечал.
Радует, что Яндекс на месте не стоит, придумывают новые сервисы и дорабатывают предыдущие.
Радует, что Яндекс на месте не стоит, придумывают новые сервисы и дорабатывают предыдущие.
Много комментариев было про стоимость.
Публичное облако всегда дешевле использовать на коротком временном промежутке. Больших капитальных затрат не требует на Оборудование, помещение и т.д.
В долгосрочной перспективе облако будет всегда или почти всегда дороже.
Поэтому облако имеет смысл использовать для проверки своих бизнес идей. Если идея выгорела, можно обдумывать переход на свое оборудование или аренду стойки в дата центре с конкретным SLA или еще что-нибудь.
Может сам Яндекс будет предоставлять услуги с требованиями по SLA для тех, кто хочет инфраструктуру на аутсорс отдать.
Про потерю данных и резервное копирование. В Условиях использования указано: «3.1. Платформа предоставляется на условиях «как есть» (as is). Яндекс не предоставляет никаких гарантий в отношении безошибочной и бесперебойной работы Платформы или отдельных её компонентов...» и так далее.
В целом от инцидента Яндекс станет только лучше. Думаю, больше они такого фейла не допустят. Но могут допустить другие :)
А про доп услугу в виде SLA им стоит подумать.
Публичное облако всегда дешевле использовать на коротком временном промежутке. Больших капитальных затрат не требует на Оборудование, помещение и т.д.
В долгосрочной перспективе облако будет всегда или почти всегда дороже.
Поэтому облако имеет смысл использовать для проверки своих бизнес идей. Если идея выгорела, можно обдумывать переход на свое оборудование или аренду стойки в дата центре с конкретным SLA или еще что-нибудь.
Может сам Яндекс будет предоставлять услуги с требованиями по SLA для тех, кто хочет инфраструктуру на аутсорс отдать.
Про потерю данных и резервное копирование. В Условиях использования указано: «3.1. Платформа предоставляется на условиях «как есть» (as is). Яндекс не предоставляет никаких гарантий в отношении безошибочной и бесперебойной работы Платформы или отдельных её компонентов...» и так далее.
В целом от инцидента Яндекс станет только лучше. Думаю, больше они такого фейла не допустят. Но могут допустить другие :)
А про доп услугу в виде SLA им стоит подумать.
Ну это естественно. Начинаем на облаках, затем, когда облака начинают стоить слишком дорого или больше не устраивают по надёжности — переносим на более правильное для ситуации решение. Другое дело, что я например никак не могу найти время/ресурсы на этот перенос, поэтому до сих пор переплачиваю за кучу виртуалок в облаке.
То, что свои данные всё равно нужно самому сохранять — верно. «Не бывает слишком много резервных копий».
В таких случаях есть один ресурс, который никто и никогда не возместит: время. То время, которое потратите на восстановление из резервной копии, пусть даже все данные удалось спасти, и минут через немного всё заработало вполне штатно.
И да, «ложки вернули, но осадок остался». Доверия к Яндекс.Облаку теперь меньше. У меня большой опыт работы с AWS, но подобного рода ляпов там таки не было. Хотя были и потери данных, и потери виртуальных машин в целом.
В таких случаях есть один ресурс, который никто и никогда не возместит: время. То время, которое потратите на восстановление из резервной копии, пусть даже все данные удалось спасти, и минут через немного всё заработало вполне штатно.
И да, «ложки вернули, но осадок остался». Доверия к Яндекс.Облаку теперь меньше. У меня большой опыт работы с AWS, но подобного рода ляпов там таки не было. Хотя были и потери данных, и потери виртуальных машин в целом.
Sign up to leave a comment.
Shit happens. Яндекс удалил часть виртуальных машин в своем облаке