И все таки, я бы попросил, сообщить Вас мне номер тикета или хотя бы логин в приват, чтобы я мог разобраться почему тикет гулял двое суток и Вам не смогли предоставить вменяемый ответ, моя задача реагировать на любые жалобы в работе ТП, проверять их и оптимизировать их работу, чтобы подобных проблем не возникало в будущем.
Да я не переживаю ), просто хочется, что было понимание, как у автора поста, так и у других хабровчан, что это не просто блажь сотрудника ТП, а нормальная устоявшаяся практика призванная оптимизировать работу, в которой нет ничего криминального. В конце концов, все мы приезжая в автосервис отдаем ключи от машины сотруднику этого самого автосервиса и не переживаем, на счет того — «а вдруг он будет кататься на моей машине?!!!».
Есть недоработки в магистральном оборудовании (Не только Huawei, такая же проблема есть и у Juniper при работе с IPv6), которые приводят к такому глюку. Как я написал в моем комменте, реализация IPv6 еще весьма сыра в некоторых местах.
Борьба с DDoS-ами задача не простая, Особенно при наших текущий объемах трафика и количестве клиентов (одного известного анти-ддосера даже дико пошатало, когда мы просто попробовали взять у них защиту, а это люди, которые не первый год занимаются данным вопросом).
Но мы движемся в направлении решения данной задачи.
Можете сообщить номер тикета в ТП, посмотрю, что за проблема была? Для анализа работы сети мы советуем использовать mtr, и эта информация с Вашей стороны действительно помогает выявить проблемные места в передачи трафика через Интернет. Довольно часто возникают проблемы у транзитных провайдеров и информация собранная с помощью mtr, позволяет нашим сетевикам понять, с кем из операторов связи надо связаться для устранения проблемы.
Приветствую всех, отвечу по порядку:
1. Поскольку достаточно большое количество наших пользователей не являются продвинутыми админами (а именно они чаще всего пишут тикеты), то практика предоставления рутового доступа к VDS вполне оправдана. Во-первых, тем самым пользователь санкционирует доступ к своим данным наших сотрудников (в отличие от того, если мы сами полезем доступными нам методами). Во-вторых, никто не требует его предоставлять силой. Это право клиента давать доступ нашим сотрудникам или не давать. Опять же, если клиент не хочет разглашать свой любимый пароль, можно: а) поменять на временный пароль; б) создать альяс рута (произвольный пользователь с uid:gid=0:0) и предоставить его; в) создать обычного юзера и дать ему права через sudo. Любой профессиональный админ должен знать о таких способах. Данная практика была выработана на основе общей статистики работы тех. поддержки и позволяет сократить количество итераций и время обработки тикетов. Исправили проблему — меняйте пароль и работайте дальше.
Поверьте, нашей поддержке вот ни разу не интересно, что находится внутри Вашей VDS, у нас их уже 8000 шт. и никто не будет копаться в Ваших данных. При ежемесячном количестве обращений в ТП, которое уже составляет порядка 10к тикетов, у ребят на это нет ни времени, ни сил, не желания. К тому же, они также несут ответственность за разглашение информации, это прописано в трудовых договорах.
2. IPv6 — еще достаточно сырой протокол и даже в топовых провайдерских железках еще очень много багов в его реализации или отсутствия реализации некоторых функций, которые приводят к подобным багам. Как это ни странно, проблема залипания IPv6 — адреса, действительно лечится указанным Вами способом. Первая линия ТП просто не знала о такой особенности, по этому пошла по стандартному регламенту с предоставлением доступа к VDS (поверьте, в 95% случаев предоставление доступа действительно помогает решить проблему клиента или как минимум ускорить ее решение). Вам достаточно было просто написать «Я знаю, что проблема не внутри моей VDS, доступ дать не могу, передайте тикет сетевому инженеру».
3. В виду возникновения такой проблемы, мы обязательно проинструктируем первую линию ТП о способе ее решения. Если первая линия знает решения какого либо вопроса, то она просто дает инструкцию и не просит ни каких доступов.
4. Huawei находится на стадии тестирования и официально мы его пока не анонсировали. Новости в Твиттере и других соц. сетях по поводу его установки лишь отражают то, чем мы занимаемся в настоящий момент, над какими проектами работаем. В том же Твиттере, например, проскакивала и фотография Radware, которая также была на нашем тестовом стенде и сейчас мы ждем, более мощную железку, чтобы можно было ее испытать в нашей сети. Когда мы полностью внедрим свое анти-DDoS решение, будет официальный анонс и статья о наших приключения здесь на Хабре.
Если данная стандартная просьба задела какие либо Ваши чувства, то приношу за это свои извинения от лица компании и от себя лично.
Отнюдь, очень интересно, если есть что сказать про саппорт, то пишите, с номерами тикетов, чтобы я мог ознакомиться, В нашей команде уже почти 40 человек и уследить за работой всех сотрудников я не могу. Также, не могу, чисто физически, перечитывать все тикеты, количество которых превышает 7000 в месяц. По этому. если есть какие то жалобы на работу моих людей, всегда готов выслушать и принять меры по исправлению вектора их работы.
Я не очень в курсе проблем с электропитанием у тех коллег, которых Вы перечислили, могу только сказать за себя, за год работы ни одна стойка в нашем ДЦ не была обесточена во время работы.
Также, ни одно сетевое устройство не выходило из строя.
Единственная проблема с доступностью нового ДЦ была связана с обывом оптики, это было в июле прошлого года, тогда мы еще не успели достроить резерв, он был запущен только к концу августа. На считая первого обрыва, в течение этого года было еще 2, по одному на каждом кабеле, обе аварии прошли незаметно для пользователей.
Были еще проблемы общего характера связанные с DDoS-атаками и мы как раз активно занимаемся решением этой проблемой и последние пару месяцев мощные ддосы уже не беспокоили наших клиентов.
Но насколько я знаю, надежность по TIER не учитывает недоступность ресурсов ДЦ из-за сетевых атак. Оценивается только надежность физической инфраструктуры.
Доступность самого ЦОД и доступность отдельно взятой услуги несколько разные вещи.
Доступность ЦОД, по сути, складывается из непрерывного наличия электроэнергии, холода и передачи интернет-трафика (и то, некоторые ДЦ не занимаются сами телекоммуникациями и отдают это на сторонних операторов связи, с которыми клиент дата-центра договаривается самостоятельно).
В случае с gibson_dev, имела место быть программная проблема на отдельно взятом хостинговом сервере, при том, что сам сервер был доступен, как и большинство сайтов на нем. Так что данная проблема не имеет ни какого отношения к уровням TIER самого ДЦ.
Например, за прошедший год с начала ввода в эксплуатацию нашего нового ДЦ, его аптайм по холоду и электричеству составил 100%, при том, что было 2 случая отсутствия электропитания по основному электровводу из города…
Ни в коем случае. Я же не отрицаю, что были проблемы. Просто моя задача показать общественности, что мы не стоим на месте и постоянно развиваемся, признаем ошибки и исправляем их.
Поддержка тоже меняется. Штат расширяется, ужесточаются регламенты работы. Жалоб на долгий ответ сейчас практически нету.
На счет 12 часов недоступности — не нашел такого в Ваших тикетах. Только упоминание о периодической недоступности.
Проблема была не явная, по этому потребовалось некоторое время на то, чтобы ее отловить.
По тикету 712472, проблема была в серии мощных DDoS-атак в начале этого года. С тех пор утекло много воды и стабильность нашей сети стала гораздо выше.
Если я правильно идентифицировал Ваш аккаунт (у нас 5 пользователей у которых есть «gibson» в имени логина), то:
1. У Вас была услуга хостинга — а в этой статье мы говорим про ресселинг VDS.
2. Проблема была на одном из хостинговых серверов и уже давно решена. Все тикеты с проблемами еще прошлогодние.
Но мы движемся в направлении решения данной задачи.
1. Поскольку достаточно большое количество наших пользователей не являются продвинутыми админами (а именно они чаще всего пишут тикеты), то практика предоставления рутового доступа к VDS вполне оправдана. Во-первых, тем самым пользователь санкционирует доступ к своим данным наших сотрудников (в отличие от того, если мы сами полезем доступными нам методами). Во-вторых, никто не требует его предоставлять силой. Это право клиента давать доступ нашим сотрудникам или не давать. Опять же, если клиент не хочет разглашать свой любимый пароль, можно: а) поменять на временный пароль; б) создать альяс рута (произвольный пользователь с uid:gid=0:0) и предоставить его; в) создать обычного юзера и дать ему права через sudo. Любой профессиональный админ должен знать о таких способах. Данная практика была выработана на основе общей статистики работы тех. поддержки и позволяет сократить количество итераций и время обработки тикетов. Исправили проблему — меняйте пароль и работайте дальше.
Поверьте, нашей поддержке вот ни разу не интересно, что находится внутри Вашей VDS, у нас их уже 8000 шт. и никто не будет копаться в Ваших данных. При ежемесячном количестве обращений в ТП, которое уже составляет порядка 10к тикетов, у ребят на это нет ни времени, ни сил, не желания. К тому же, они также несут ответственность за разглашение информации, это прописано в трудовых договорах.
2. IPv6 — еще достаточно сырой протокол и даже в топовых провайдерских железках еще очень много багов в его реализации или отсутствия реализации некоторых функций, которые приводят к подобным багам. Как это ни странно, проблема залипания IPv6 — адреса, действительно лечится указанным Вами способом. Первая линия ТП просто не знала о такой особенности, по этому пошла по стандартному регламенту с предоставлением доступа к VDS (поверьте, в 95% случаев предоставление доступа действительно помогает решить проблему клиента или как минимум ускорить ее решение). Вам достаточно было просто написать «Я знаю, что проблема не внутри моей VDS, доступ дать не могу, передайте тикет сетевому инженеру».
3. В виду возникновения такой проблемы, мы обязательно проинструктируем первую линию ТП о способе ее решения. Если первая линия знает решения какого либо вопроса, то она просто дает инструкцию и не просит ни каких доступов.
4. Huawei находится на стадии тестирования и официально мы его пока не анонсировали. Новости в Твиттере и других соц. сетях по поводу его установки лишь отражают то, чем мы занимаемся в настоящий момент, над какими проектами работаем. В том же Твиттере, например, проскакивала и фотография Radware, которая также была на нашем тестовом стенде и сейчас мы ждем, более мощную железку, чтобы можно было ее испытать в нашей сети. Когда мы полностью внедрим свое анти-DDoS решение, будет официальный анонс и статья о наших приключения здесь на Хабре.
Если данная стандартная просьба задела какие либо Ваши чувства, то приношу за это свои извинения от лица компании и от себя лично.
Также, ни одно сетевое устройство не выходило из строя.
Единственная проблема с доступностью нового ДЦ была связана с обывом оптики, это было в июле прошлого года, тогда мы еще не успели достроить резерв, он был запущен только к концу августа. На считая первого обрыва, в течение этого года было еще 2, по одному на каждом кабеле, обе аварии прошли незаметно для пользователей.
Были еще проблемы общего характера связанные с DDoS-атаками и мы как раз активно занимаемся решением этой проблемой и последние пару месяцев мощные ддосы уже не беспокоили наших клиентов.
Но насколько я знаю, надежность по TIER не учитывает недоступность ресурсов ДЦ из-за сетевых атак. Оценивается только надежность физической инфраструктуры.
Доступность ЦОД, по сути, складывается из непрерывного наличия электроэнергии, холода и передачи интернет-трафика (и то, некоторые ДЦ не занимаются сами телекоммуникациями и отдают это на сторонних операторов связи, с которыми клиент дата-центра договаривается самостоятельно).
В случае с gibson_dev, имела место быть программная проблема на отдельно взятом хостинговом сервере, при том, что сам сервер был доступен, как и большинство сайтов на нем. Так что данная проблема не имеет ни какого отношения к уровням TIER самого ДЦ.
Например, за прошедший год с начала ввода в эксплуатацию нашего нового ДЦ, его аптайм по холоду и электричеству составил 100%, при том, что было 2 случая отсутствия электропитания по основному электровводу из города…
На счет 12 часов недоступности — не нашел такого в Ваших тикетах. Только упоминание о периодической недоступности.
Проблема была не явная, по этому потребовалось некоторое время на то, чтобы ее отловить.
1. У Вас была услуга хостинга — а в этой статье мы говорим про ресселинг VDS.
2. Проблема была на одном из хостинговых серверов и уже давно решена. Все тикеты с проблемами еще прошлогодние.