Comments 49
Перенеси бы прошлый провайдер этого клиента в первую очередь с минимальным даунтаймом всячески помогая клиенту, лояльность клиента выросла бы значительно, и они остались бы довольны сервисом еще надолго.
А затем делать уже две площадки после того, как этот кризис закончится.
Надеюсь догадаются делать вторую площадку у третьего провайдера :)
А зачем пользоваться такими хостерами?
Возьмите Amazon или Google Cloud там точно не будет такого. Если пугает перспектива прихода РКН — сервер за 5€ в Москве для проксирования запросов.
Опционально вместо прокси в РФ, логичнее даже взять в Белоруси, на них ркн не распростроняется
Проксирование запросов – это костыль, который для компании такого калибра неприемлем.
Есть формальные требования хранить персональные данные в России как минимум и недавние блокировки Amazon и Google как максимум.
Есть формальные требования хранить персональные данные в России как минимум и недавние блокировки Amazon и Google как максимум.
Сам так не делаю, но, формально, если держать копию данных в России (на слабой, store-only, машине), а основной сервер на Амазоне, то «формальные требования хранить персональные данные в России» не нарушаются. Это мило обсуждалось в треде про блокировки РКН, когда выяснилось, что после их начала где-то встали кассы, и еще что-то случилось, чего бы не произошло, будь сервера не на Амазоне (читай — не снаружи России).
Вот проксирование запросов — это да, это просто сделает работу медленнее.
А вообще (руки важнее, чем география), ПД потерять и в России можно, и на Амазоне надежно сохранить.
Вот проксирование запросов — это да, это просто сделает работу медленнее.
А вообще (руки важнее, чем география), ПД потерять и в России можно, и на Амазоне надежно сохранить.
Это не костыль это разновидность load balancing
Если там подсуетятся, смогут не только кофе и сыры с бабанами «производить» на половину России, но и трафик гнать!
Мне почему-то кажется, что завязка этой драмы была намного сложнее, чем тут описано. Учитывая, что клиенты были предупреждены за полгода, скорее всего предполагался переезд по частям, клиентам поднимали сеть на втором уровне между ДЦ и предлагали составить расписание заранее, чтобы не было аврала в последние недели перед переездом. Данный заказчик, как и большая часть остальных, решил, что сможет все сделать в последний месяц и очнулся слишком поздно.
Вины с провайдера услуг это никак не снимает, клиент — это клиент, и задерживать сроки, когда он понял, что просрал все полимеры, и ищет для себя выход — не вариант, даже учитывая, что ты его потеряешь.
AWS и GCP, скорее всего не подходят из-за персональных данных. Да и по цене, они не всегда будут дешевле в первом приближении.
Вины с провайдера услуг это никак не снимает, клиент — это клиент, и задерживать сроки, когда он понял, что просрал все полимеры, и ищет для себя выход — не вариант, даже учитывая, что ты его потеряешь.
AWS и GCP, скорее всего не подходят из-за персональных данных. Да и по цене, они не всегда будут дешевле в первом приближении.
За 5 баксов проксимального разве что телеграмм(запрещенный в РФ) можно. В статье было что то про высоконагруженную бд, хватит вам канала/трафика за эти деньги для таких целей? А если нужен постоянно толстый канал и высокое латенси до бд?
Сделали бекап виртуальной машины, привезли его физически на свою площадку на диске и залили в облако.
Так ведь на площадку не пускали, как на диск вы забрали бекап ВМ? Или вы его по каналу в 50 Мб вытягивали (половине от него), но в это что-то не верится.
Интрига, в общем!
утилизирует этот канал
На русском это будет «использует»
Можно и так было сказать (я не автор поста). Но загрузку канала часто называют именно утилизацией (в % к общей пропускной, скажем), а вот «использованием» — как-то не встречалось.
Язык, конечно, штука гибкая, но какие-то слова больше прижились, пусть даже это не особо изящные кальки.
Язык, конечно, штука гибкая, но какие-то слова больше прижились, пусть даже это не особо изящные кальки.
УТИЛИЗИ́РОВАТЬ
Употребить [-реблять] с пользой (перерабатывая, используя каким-н. образом).Толковый словарь русского языка
приведу окончание из вашего источника: «например, утилизировать отходы производства»
Просто использовать что-то по назначению, например, витую пару, чтобы передавать данные) это одно, а использовать испорченную витую пару (перерабатывая) чтобы получить из нее медь (с пользой) — это и есть утилизация.
Просто использовать что-то по назначению, например, витую пару, чтобы передавать данные) это одно, а использовать испорченную витую пару (перерабатывая) чтобы получить из нее медь (с пользой) — это и есть утилизация.
Верно, стоит это занести в словарь странных англицизмов, рядом с «дигитальный» и «продавать экспертизу».
Ждем в тред техдира исходного провайдера, с его рассказом, какой заказчик был геморойщик, и как они ему полгода жизни отдали, а он взял, и обманом свалил — и к кому! #шутка
Лучше распишите, с чего все началось. Я думаю, что история будет поучительна в том как планировать. А то у вас получилось, что провайдер просто бездарь и негодяй, а клиент — ясно солнышко. Как я написал выше, мне почему-то кажется, что клиент затянул с планированием переезда, а потом в самый напряженный период сказал, что переезжает к другим. Со стороны прибыли для провайдера вопрос в приоритете в таком случае как бы ясен.
К данному провайдеру и хостерам вообще отношения не имею, от слова совсем.
К данному провайдеру и хостерам вообще отношения не имею, от слова совсем.
клиент затянул с планированием переезда, а потом в самый напряженный период сказал, что переезжает к другимИ что, это даёт провайдеру право динамить клиента с тех. поддержкой и расширением канала?
Я это не писал. Если действительно дело было, как описано, без всяких объяснений и попыток договорится, то тогда все понятно. Но вся история смотрится как-то нелепо, вы не находите? Причем изложена она конкурентом, который уводил клиента. Да и задача этой статьи больше в пиаре софта, чем в передаче истины. Как на самом деле было дело никто не узнает.
Вот это как нужно было понять:
Со стороны прибыли для провайдера вопрос в приоритете в таком случае как бы ясенЯ это понял — раз клиент всё равно уходит, можно его обслуживать с низким приоритетом.
Именно так.
Если бы у меня был страшный аврал, я бы мог отложить этого клиента на свободное время в конце. И скорее всего, тоже бы отказал ему в расширении канала, поскольку данные под конец срока переливали все. Я бы, конечно, объяснил клиенту ситуацию, и убедил, что у него все будет хорошо, но не сейчас. Все бы зависело от реальной ситуации.
Как себя вел провайдер мы не заем. Как себя вел клиент мы не знаем. Судить обо всем этом достаточно тяжело.
К примеру. У меня сейчас чем-то похожая ситуация, взял проект без должного ТЗ, на время пока у меня простой. Все данные по ТЗ приходится выдирать клещами, из-за этого он практически не продвигается. Со следующей недели у меня будет много работы от основного заказчика, и этот проект даже при идеальном ТЗ будет продвигаться очень медленно. И меня будут делать виноватым, и рассказывать, что я подвел со сроками, сорвал проект и т.д. и т.п.
Если бы у меня был страшный аврал, я бы мог отложить этого клиента на свободное время в конце. И скорее всего, тоже бы отказал ему в расширении канала, поскольку данные под конец срока переливали все. Я бы, конечно, объяснил клиенту ситуацию, и убедил, что у него все будет хорошо, но не сейчас. Все бы зависело от реальной ситуации.
Как себя вел провайдер мы не заем. Как себя вел клиент мы не знаем. Судить обо всем этом достаточно тяжело.
К примеру. У меня сейчас чем-то похожая ситуация, взял проект без должного ТЗ, на время пока у меня простой. Все данные по ТЗ приходится выдирать клещами, из-за этого он практически не продвигается. Со следующей недели у меня будет много работы от основного заказчика, и этот проект даже при идеальном ТЗ будет продвигаться очень медленно. И меня будут делать виноватым, и рассказывать, что я подвел со сроками, сорвал проект и т.д. и т.п.
Интересно, а кто-нибудь из неотпускавшего провайдера эту статью прочел? :)
UFO just landed and posted this here
Риск-менеджмент по-русски.
1) Бюджета на… дублирующую площадку… нет
2) один день простоя… потерями… годовой прибыли
3) ждем полгода о предупрежденной миграции ничего не делаем
4)…
5) провайдер плохой
Хотя провайдер тоже мутный, обе стороны виноваты. Весь бизнес завязан на онлайн — на резервирование похрен.
1) Бюджета на… дублирующую площадку… нет
2) один день простоя… потерями… годовой прибыли
3) ждем полгода о предупрежденной миграции ничего не делаем
4)…
5) провайдер плохой
Хотя провайдер тоже мутный, обе стороны виноваты. Весь бизнес завязан на онлайн — на резервирование похрен.
UFO just landed and posted this here
Вы бы побыли хостером в РФ =)
Сидишь такой в М9 на аренде, а тебе «мы через неделю вам стойки на другой этаж повезем, даунтайм сутки, делайте что хотите». А к стойкам — аплинки (перенос которых в сутки не укладывается), ИБП, полки и куча всего.
Единственный вариант — покупать землю и строить ДЦ самому. И то — экскаваторщики обязательно умудрятся окопать весь участок по периметру и порвать все аплинки. А не купишь землю — тебя арендатор выпнет. Ещё и одолжение сделает — за целых 2 месяца предупредит.
Сидишь такой в М9 на аренде, а тебе «мы через неделю вам стойки на другой этаж повезем, даунтайм сутки, делайте что хотите». А к стойкам — аплинки (перенос которых в сутки не укладывается), ИБП, полки и куча всего.
Единственный вариант — покупать землю и строить ДЦ самому. И то — экскаваторщики обязательно умудрятся окопать весь участок по периметру и порвать все аплинки. А не купишь землю — тебя арендатор выпнет. Ещё и одолжение сделает — за целых 2 месяца предупредит.
Бизнес как раз-таки понимал, что время восстановления из бэкапа удовлетворяет требованиям показателя RTO. А вот обещанный трехдневный даунтайм бизнес не выдержал бы.
Я понимаю, что статья маркетинговая, попиарить карбонит. Но все же.
Ок. Тут уже описали, что бывают случаи, когда прибыль не позволяет.
Это как так? Нет прибыли на то, чтобы организовать дублирование критической инфраструктуры. Хотя ее простой влечет за собой упущенную прибыль, большую прибыль, и репутационные риски.
А тут вообще рукалицо! Было полгода, в течении которых можно было:
1. Связаться с провайдером и договорится о поэтапном ночном переносе серверов на новую площадку.
2. Арендовать дополнительную площадку в облаке и развернуть там резервную инфраструктуру.
3. Купить оборудование и развернуть на новой площадке провайдера или у другого провайдера. Сколько там того оборудования, если объем данных был 5ТБ? Даже если у них использовались тонкие клиенты, в чем я сомневаюсь, та максимум 10 стареньких серверов, которые спокойно могли переехать на 3-4 новых.
В любом случае, резервная инфраструктура пригодится, если все так как описано в статье.
Так что, скорее всего, клиент стоит провайдера, если он на самом деле такой, как вы его описали.
Бюджета на аварийную дублирующую площадку у вас нет.
Ок. Тут уже описали, что бывают случаи, когда прибыль не позволяет.
Бизнес связан с предоставлением медицинских услуг, здесь каждый лишний час промедления стоит дорого: один день простоя грозит финансовыми и имиджевыми потерями, равными годовой прибыли, два часа — начнут страдать клиенты.
Это как так? Нет прибыли на то, чтобы организовать дублирование критической инфраструктуры. Хотя ее простой влечет за собой упущенную прибыль, большую прибыль, и репутационные риски.
Бизнес как раз-таки понимал, что время восстановления из бэкапа удовлетворяет требованиям показателя RTO. А вот обещанный трехдневный даунтайм бизнес не выдержал бы.
А тут вообще рукалицо! Было полгода, в течении которых можно было:
1. Связаться с провайдером и договорится о поэтапном ночном переносе серверов на новую площадку.
2. Арендовать дополнительную площадку в облаке и развернуть там резервную инфраструктуру.
3. Купить оборудование и развернуть на новой площадке провайдера или у другого провайдера. Сколько там того оборудования, если объем данных был 5ТБ? Даже если у них использовались тонкие клиенты, в чем я сомневаюсь, та максимум 10 стареньких серверов, которые спокойно могли переехать на 3-4 новых.
В любом случае, резервная инфраструктура пригодится, если все так как описано в статье.
Так что, скорее всего, клиент стоит провайдера, если он на самом деле такой, как вы его описали.
Не ожидал от КРОК такой унылой рекламы carbonite.
У меня был опыт почудесатее: о переезде не предупреждали. Совсем. Это в США. Бац — всё выключилось, «надолго». Потом включилось. Поддержка реселлера поморозилась — но в итоге честно написали «мы не можем достучаться до хостера, спасайся, кто может». Тут каналам начало плохеть — я чуть раньше слил бОльшую часть, но потом бэкапиться кинулись все :). Этот цирк с неизвестностью был 3 дня! Потом оказалось — возили сервера между датацентрами (и это ещё продолжалось чуток времени), частями и криво настроив сеть (из мира — видим сервер 1 и сервер 2, но сервера друг друга — не видят), и, возможно, разбирая на части — тут понимаешь, что от потери 3 из 4 дисков спасёт только зеркало, RAIDZ2 не вынес такого :).
А бизнес бывает с низкими прибылями — и таки дублировать инфраструктуру может быть не по карману. Это ж не просто «купить железо» — это и неплохо бы переписать софт, и расходы на содрежание железа… И или «авось» или услуга вырастет в цене и ты проиграешь конкуренту с «авось». Вот и выбирайте — «прибыль здесь и сейчас/вложение в разработку сервиса», или «развиваться не за что», или «отдел маркетинга должен напрячься».
Короче, Интернет — эта такая вещь, в которой нужно готовиться к падению атомной бомбы в твой датацентр. Или материально — строя инфраструктуру, или морально — приняв грядущие проблемы как данность.
А бизнес бывает с низкими прибылями — и таки дублировать инфраструктуру может быть не по карману. Это ж не просто «купить железо» — это и неплохо бы переписать софт, и расходы на содрежание железа… И или «авось» или услуга вырастет в цене и ты проиграешь конкуренту с «авось». Вот и выбирайте — «прибыль здесь и сейчас/вложение в разработку сервиса», или «развиваться не за что», или «отдел маркетинга должен напрячься».
Короче, Интернет — эта такая вещь, в которой нужно готовиться к падению атомной бомбы в твой датацентр. Или материально — строя инфраструктуру, или морально — приняв грядущие проблемы как данность.
сдается мне статья полный пиздешь, потому что денег на резерв у нас нет, но два часа простоя это год работы и риски, за год там что 500 рублей прибыль? или 5000? и нах такой бизнес где нет прибыли? хотя 5 ТБ данных, это бизнес должен быть очень крупным и приносить очень много бабосов, я помню огромную бд где было 1000 доков в минуту как раз для сиквела от мелкомягких там база была 250 гигов, не 5 тб, раз там 5 тб, там что все журналы транзакций хранились? или транзакшен лог не транкейтили? вобщем если так технически подойти то много не стыковок и похоже на пиздаболию. так долго переезжал караван, да у него были косяки при переезде, да тачки везли ночью и у них был даунтайм, но!!! они давали на время тачки всем клиентам в новом дц, и единственный гемор был только с дедиками тупо их переключить и потом данные смигрировать, облако вообще безшовно переключилось, а тут речь о виртуалках, кто мешал их смигрировать? в общем тупая рекламе этой софтины под винду, да еще приправленная пиздежом
Пока что меня смущает какое то мутное SLA с трёхдневной реакцией на инцидент. Сейчас даже у любого физика саппорт домашнего интернета зачастую работает 24/7, а тут цод, в нем не то что саппорт, в нем физический доступ должен быть априори заложен
В который раз убеждаюсь мысли что в облака надо идти с очень серьезной подготовкой к рискам. На тех же дедиках с установленной виртуализацией проблемы просто не было бы — арендуется во втором цоде сервер(а), внутри гипервизоров ставишь виртуальные комутаторы, строишь внутренние L2 туннели, собираешь кластер (зависит от системы гипервизоров), настраиваешь шейпинг на виртуальных коммутаторах, настраиваешь проброс в dmz, далее запускаешь живую миграцию. На время переезда конечно из-за скорости интернет канала возможна просадка производительности, но прерывания сервиса не будет. Во время переезда настраиваешь ttl dns'ов на 60 секунд, затем после переезда меняешь A запись(до этого времени будет работать проброс на коммутаторе через l2 туннель первого провайдера). После этого отказываешься от старого провайдера.
И в современных реалиях на дедиках надо брать ssd, они кстати и нагрузку на проц снимают довольно существенно при нагруженной базе и переезды становятся быстрее.
И в современных реалиях на дедиках надо брать ssd, они кстати и нагрузку на проц снимают довольно существенно при нагруженной базе и переезды становятся быстрее.
Sign up to leave a comment.
Как нашего заказчика не хотел отпускать провайдер