> поскольку Вы никаких работ не производили, то, очевидно, проблема с роутингом у аплинка.
> Вы связываетесь со специалистами ДЦ
А зачем ДЦ? То есть тут вообще зависимости от того, в каком ЦОДе размещаться, я не вижу.
Свой ЦОД — аплинк все равно не свой, связываемся с аплинком.
Чужой ЦОД — аплинк, скорей всего, не ЦОДа (хотя может быть и так, конечно, но слабо верится, что крупный провайдер будет брать те аплинки, которыми рулит ЦОД).
Это я к тому, что каждая проблема по разному решается и риски в ней уменьшать можно тоже по разному. Проблемы аплинков решаются не ЦОДами, а собственными анонсами и оговоренным порядоком взаимодействия с саппортом (или лучше сразу выше — NOC службой) того провайдера, который дает вам аплинк.
> Если бы накосячили Ваши сотрудники, а не сотрудники ДЦ, проблема стала бы понятной гораздо раньше и реакция на инцидент была бы более быстрой.
По факту, при существующем положении вещей в современном хостинге и рынце ЦОДов, в принципе, ситуаций (инцидентов), когда необходимо аварийное вмешательство дежурного инженера ЦОДа — очень и очень не много. Сходу даже пример сложно привести. Разве что перезагрузка по питанию, в случае невозможности удаленно это провести (KVM, IPMI не работают) — что тоже является крайне редкой ситуацией (по крайней мере у нас, тьфу 3 раза).
Безусловно, чем меньше прослоек — тем оперативней будет решаться инцидент (при поставленных, эффективных бизнес-процессах по разрешению оного, конечно).
Прослоек у хостера всегда достаточно и, конечно, все стараются их минимизировать, беря на личный контроль все процессы, которые завязаны на контрагентов.
Например, для оперативной борьбы с DoS-атаками приличные хостеры давно анонсируют сети сами, управляя blackhole-коммьюнити и прочими премудростями.
Только вот гарантии, что собственные специалисты сделают лучше/хуже — нет.
Мой сотрудник в ЦОД может точно также переткнуть линк на коммутаторе, что и сотрудник ЦОДа. Причем примерно с той же степенью вероятности.
То, что ХЦ условно «теряет в качестве» — тенденция достаточно давняя и связана она прежде всего со сложностью масштабируемости этого самого качества в условиях бизнеса в сфере массовых услуг (отдельные решения менеджмента и человеческий факт в целом — не рассматриваю тут).
Что Панов, что Кононенко, оба по своему правы. По своему, потому что доля правды и там и там есть, как мне кажется.
И Панов бы не ушел, не будь «преступником» (цитируя его слова) хотя бы насколько то.
И Кононенко хоть и все говорит разумно (как еще, на прессу то), но и лукавит во многом.
Дискуссии пользователя
Впишусь немного в дискуссию:
> поскольку Вы никаких работ не производили, то, очевидно, проблема с роутингом у аплинка.
> Вы связываетесь со специалистами ДЦ
А зачем ДЦ? То есть тут вообще зависимости от того, в каком ЦОДе размещаться, я не вижу.
Свой ЦОД — аплинк все равно не свой, связываемся с аплинком.
Чужой ЦОД — аплинк, скорей всего, не ЦОДа (хотя может быть и так, конечно, но слабо верится, что крупный провайдер будет брать те аплинки, которыми рулит ЦОД).
Это я к тому, что каждая проблема по разному решается и риски в ней уменьшать можно тоже по разному. Проблемы аплинков решаются не ЦОДами, а собственными анонсами и оговоренным порядоком взаимодействия с саппортом (или лучше сразу выше — NOC службой) того провайдера, который дает вам аплинк.
> Если бы накосячили Ваши сотрудники, а не сотрудники ДЦ, проблема стала бы понятной гораздо раньше и реакция на инцидент была бы более быстрой.
Не факт.
На самом деле не факт. Далеко.
По факту, при существующем положении вещей в современном хостинге и рынце ЦОДов, в принципе, ситуаций (инцидентов), когда необходимо аварийное вмешательство дежурного инженера ЦОДа — очень и очень не много. Сходу даже пример сложно привести. Разве что перезагрузка по питанию, в случае невозможности удаленно это провести (KVM, IPMI не работают) — что тоже является крайне редкой ситуацией (по крайней мере у нас, тьфу 3 раза).
Безусловно, чем меньше прослоек — тем оперативней будет решаться инцидент (при поставленных, эффективных бизнес-процессах по разрешению оного, конечно).
Прослоек у хостера всегда достаточно и, конечно, все стараются их минимизировать, беря на личный контроль все процессы, которые завязаны на контрагентов.
Например, для оперативной борьбы с DoS-атаками приличные хостеры давно анонсируют сети сами, управляя blackhole-коммьюнити и прочими премудростями.
Только вот гарантии, что собственные специалисты сделают лучше/хуже — нет.
Мой сотрудник в ЦОД может точно также переткнуть линк на коммутаторе, что и сотрудник ЦОДа. Причем примерно с той же степенью вероятности.
То, что ХЦ условно «теряет в качестве» — тенденция достаточно давняя и связана она прежде всего со сложностью масштабируемости этого самого качества в условиях бизнеса в сфере массовых услуг (отдельные решения менеджмента и человеческий факт в целом — не рассматриваю тут).
Мысль, думаю, понятна)
Что Панов, что Кононенко, оба по своему правы. По своему, потому что доля правды и там и там есть, как мне кажется.
И Панов бы не ушел, не будь «преступником» (цитируя его слова) хотя бы насколько то.
И Кононенко хоть и все говорит разумно (как еще, на прессу то), но и лукавит во многом.