Фото из архива hoster.by
Хостинг-провайдеры, особенно, те, у которых на обслуживании десятки тысяч онлайн-проектов, не любят говорить о своих факапах. Тем не менее, по словам технического директора hoster.by Дениса Отвалко, «падения неизбежны у любого провайдера, но его задача — без остановки бороться с гравитацией».
Вместе с руководителем службы технической поддержки Даниилом Нарейко он ответил на неудобные вопросы dev.by о сбоях, ошибках и о том, почему крупный провайдер не скрывает от клиентов правду об инцидентах.
«Выход из строя сразу двух страхующих друг друга контроллеров передачи данных — это реально»
Если без долгих вступлений — почему случаются падения?
Даниил. Потому что произошла фатальная череда не связанных между собой событий. Искать единственную причину или виновного — распространенная ошибка и прямой путь к повторным неприятностям. Например, руководитель попросил сделать что-то вне регламента, исполнитель поспешил, защита от его действий в системе не была предусмотрена — и произошёл капитальный сбой.
Денис. Прозвучит спорно, но опыт показывает, что правильнее искать причину не падения, а сбоя работоспособности всей системы, который случается в результате. Падения — это часть эксплуатации инфраструктуры и они неизбежны у любого провайдера. Техника редко, но выходит из строя. А вот как сделать так, чтобы работоспособность сервиса при падении полностью не остановилась, и один сбой не тянул за собой другие — это уже правильный вопрос.
Даниил. Приведу пример. В конце весны столкнулись с болезненной ситуацией: были проблемы с системой хранения данных в облаке. Ещё на этапе проектирования услуги мы заложили разные варианты отказоустойчивости: купили дорогое оборудование и отказались от «узких мест» в инфраструктуре, сбой на которых влечёт за собой проблемы во всей системе. Но вышли из строя сразу два контроллера передачи данных, которые должны были подстраховывать друг друга. Казалось бы, как такое могло случиться?
Обратились к производителям: выяснилось, что причина в микропрограммном обеспечении. Пришлось обновить практически всё облако — а это простой практически у всех клиентов. Окей, пусть ночью, но тем не менее, это сильный удар по uptime. Перед нами стоял выбор — оставить «как есть» и ждать следующего сбоя, или исправить причину. Первый вариант нам никак не подходил.
Сколько тогда продлился простой?
Денис. У некоторых клиентов сервисы не работали примерно полтора часа. Надо было корректно отключить проекты, провести необходимые процедуры, включить обратно и проверить, как всё работает. Максимум — четыре часа, но это единичные клиенты. Потери данных, к счастью, не было.
Как объясняли ситуацию клиентам и какой была их реакция?
Даниил. Говорили как есть: что проводили техническое обновление, что оно необходимо для предотвращения сбоев в будущем. Золотое правило банально — говорить правду, потому что подавляющее большинство людей с пониманием относятся к таким ситуациям. Есть, конечно, и те, с кем нужно работать индивидуально, но мы к этому тоже относимся с пониманием.
Какие ещё бывают причины сбоев в работе хостинга?
Денис. Их можно классифицировать. Есть аппаратный сбой, или выход из строя определенных компонентов: диска, памяти, чего-то ещё. Нужно быть готовым к подобным проблемам и иметь на их случай регулярно пополняемый резерв оборудования. Мы стараемся максимально унифицировать оборудование, всегда держим в резерве несколько единиц железа, которые подойдут для разных услуг.
Фото из архива hoster.by
Есть программный сбой. Если это коммерческий продукт, то большой вес имеют репутация и скорость поддержки поставщика, если свободное ПО — то собственные компетенции.
Самый сложный тип ошибок — человеческий фактор. С ним тоже можно работать и предупреждать многие проблемы, но искоренить его на сто процентов нереально.
Аварийный выход из строя диска или целого сервера может привести к полной потере данных?
Денис. Выход диска из строя происходит безболезненно, если использовать избыточные массивы разных уровней (RAID1, RAID10) и диски с «горячей заменой» (именно так мы делаем в hoster.by). Если же в сервере выйдет из строя одновременно несколько дисков, то станет понятно, почему всегда рекомендуют своевременно делать резервные копии. Правда, даже правильно настроенные бэкапы делаются не ежеминутно, поэтому частичная потеря данных возможна.
Даниил. Современный хостинг-провайдер всегда принимает основные меры для обеспечения отказоустойчивости. Многие вещи предусматриваются заранее, поэтому выход из строя диска или блока питания обычно не влечёт за собой последствий.
Денис. Значительно сложнее дела обстоят с отказоустойчивостью на уровне приложений. Эти вопросы силами одного хостера не решаются.
«Однажды был случай, когда админу пришлось решать проблему клиента из леса»
Жёсткие аварии оборудования случались в вашей практике?
Денис. Я работаю в hoster.by со дня его основания и за это время повидал всякое. Выходили из строя диски, сервера, коммутаторы. Все компоненты оборудования когда-нибудь да выходили из строя. Но такие случаи нельзя назвать жёсткими, и они не всегда приводят к аварии.
У сисадминов есть инструкции на такой случай?
Даниил. Мы называем такие ситуации «инцидентами», и их устранение касается всех сотрудников компании, а не только сисадмина.
Начинается всё с того, что срабатывает система мониторинга или обращается клиент. Уведомление о неполадках регистрируется дежурным администратором. Инцидент подтверждается, информация передаётся инженеру, который отвечает за работу конкретного сервиса. Он устраняет инцидент, сообщает дежурному, а тот передает информацию клиенту и остальным сотрудникам компании. Руководители анализируют инцидент и принимают меры, чтобы минимизировать риск его повтора.
То есть в компании существует отдельная роль «администратора в чрезвычайных ситуациях»?
Даниил. Не совсем. За каждым сервисом или продуктом закреплён свой администратор, и когда инцидент случается в его зоне ответственности, подключается именно он. Это не значит, что только он может что-то сделать. Но тут, как в музыке: одно дело сыграть мелодию по нотам, и совсем другое — исполнить её с закрытыми глазами и на принципиально другом уровне мастерства. Ответственный за продукт — это всегда человек с большим опытом, углубленными знаниями и крепкими нервами.
По какому принципу выбираются админы для каждого сервиса?
Даниил. Продукты имеют свою специфику. Узкоспециализированные роли — например, администратор по базам данных, почте, веб-серверам, бэкапам — формируются на основе навыков и опыта сотрудников.
Денис. В процессе работы всегда понятно, что конкретному человеку ближе и получается у него лучше всего.
Эти админы работают в режиме скорой помощи в любое время суток?
Денис. У нас все администраторы работают в режиме скорой помощи, просто у каждого своя роль в цепочке. Несколько лет назад был случай, когда админ вызвался решать проблему клиента из леса, где был в походе. И дело не в том, что больше никто не смог бы разобраться, а в ответственности человека за продукт.
В лесу был интернет?
Денис. Был, но не очень хороший. Его товарищи лазали на дерево вешать антенну для усиления сигнала. К счастью, этого было достаточно. Сегодня такое представить уже невозможно, потому что человеческие ресурсы, как и оборудование, задублированы. Кстати, именно из-за необходимости держать избыточные ресурсы хостинг является низкомаржинальным продуктом.
«Увольнять за ошибки — первый шаг по превращению талантливых людей в ботов»
Известно множество историй о том, как крупные ИТ-компании теряли большие объёмы данных из-за неверных действий сисадминов. Как обезопасить себя от таких ошибок?
Денис. Мы через это тоже проходили. Я не преувеличу, если скажу, что каждый из наших опытных администраторов проходил через более или менее болезненные ошибки. Мы не можем полностью регламентировать действия людей, которые должны искать решения в сложных ситуациях. Строгий регламент возможен только на первых уровнях техподдержки: ограничить доступ, написать инструкции, рассчитывать на процесс управления изменениями. Но стопроцентный контроль не реализуем и не нужен.
У специалиста должна быть возможность действовать по своему усмотрению, а когда это необходимо — даже нестандартно.
Увольняли сотрудников из-за совершенных ошибок?
Денис. Нет, но взыскания были. Увольнять за ошибки — это первый шаг к тому, что люди будут работать только по инструкции из-за боязни сделать что-то не так, и из талантливых людей превратятся в ботов. Важно убедиться, что специалист сделал выводы. Глупые ошибки являются надёжной прививкой от будущих серьёзных факапов.
Можете привести примеры проблем, которые произошли из-за невнимательности или неопытности сотрудников техподдержки?
Денис. Из недавнего: кто-то отвлёк админа во время работы и он просто ввел команду в другую консоль.
И что случилось?
Денис. Перезагрузились сервера, которые не должны были перезагружаться. Клиенты от этого не пострадали, но неприятно, что ошибка случилась на ровном месте.
Вы упоминали уровни сисадминов. Можете рассказать подробнее?
Даниил. В технической поддержке мы выделяем четыре уровня. Первый — это базовая поддержка и консультирование клиентов. Второй уровень — это уже решение нестандартных проблем, в том числе мониторинг инфраструктуры. Третий уровень — ответственные за сервис, о них мы говорили выше. Третий уровень подключается, если второй уровень не справляется или случился инцидент. Четвертый уровень — самые квалифицированные специалисты: они ограждены от общего потока запросов и работают с ключевыми клиентами.
А ключевые клиенты — это кто?
Денис. Чаще всего, это те, кто выходит за рамки стандартных услуг. Например, те, кому нужно собрать индивидуальную систему или построить отказоустойчивый кластер. Часто мы сопровождаем работу таких проектов.
Каким компаниям нужны подобные услуги? Большим интернет-магазинам?
Денис. Это не обязательно большие компании, но почти всегда их бизнес полностью «интернетозависим».
Даниил. Крупные проекты, которые требуют больших вычислительных мощностей и специального подхода к архитектуре системы. Им нужны индивидуальные отказоустойчивые решения, которые исключают простой бизнеса.
Что вы понимаете под отказоустойчивыми решениями? Те, которые никогда не выходят из строя?
Даниил. Это распространенное заблуждение. Нужно разграничивать понятия отказоустойчивости и безотказности. Это принципиально разные вещи.
В фильме о Джеймсе Бонде, когда ему простреливали колесо в машине, пробоина автоматически закрывалась, колесо накачивалась и Бонд продолжал путь — это пример отказоустойчивого решения. Неприятность может случиться, но предусмотрены меры, которые не повлекут срыв миссии. В случае с безотказным решением, колесо вообще не могло бы быть простреленным. Чувствуете разницу? Поэтому в случае с любым видом хостинга правильнее говорить об отказоустойчивости.
Денис. Мы ещё на уровне разработки архитектуры услуг прорабатываем все варианты возможных сбоев и падений. Выбираем оборудование с возможностью горячей замены аппаратных элементов, дублируем элементы в потенциальных точках отказа, настраиваем автоматическое переключение между основным и резервным оборудованием, и так далее. Готовим так называемый план disaster recovery — если простым языком, то это детальный сценарий восстановления системы в случае критических сбоев. Но как бы точно всё ни было реализовано, всегда будут неучтённые ситуации. Это опыт и школа, которые перерастают в уровень провайдера.
Фото из архива hoster.by
«Если задублированы 9 компонентов из 10 — это не отказоустойчивое решение»
Какая услуга «самая отказоустойчивая»?
Денис. Кластер на основе облака. Но он нужен не всем, важно понимать специфику бизнеса клиента. Во-первых, размещая приложение в облаке, проблемы могут возникнуть именно на стороне приложения, и даже покупка площадки по цене боинга не обеспечит стабильную работу. Во-вторых, потенциальный получасовой простой раз в год может обойтись бизнесу на порядок меньше, чем сложное отказоустойчивое решение. Так что всегда нужно находить баланс, а не просто смотреть на самое надёжное и дорогое.
Почему отказоустойчивое решение — это так дорого?
Денис. В нём дублируются все без исключения роли и функции. Если задублированы 9 компонентов из 10 — это не отказоустойчивое решение, одна проблема перечеркнёт всю работу. Например, для организации кластера MySQL необходимо минимум 3 сервера. Более того, резервирование происходит на разных уровнях: сервера, дата-центра, страны и т. д. Поэтому в зависимости от задачи цены могут отличаться на порядки. Надо понимать, действительно ли это экономически целесообразно для бизнеса.
Значит, при выборе провайдера не нужно стремиться к заветным «пяти девяткам» — 99,999% гарантии доступности системы?
Даниил. Эти цифры уже касаются SLA (Service Level Agreement) — соглашения об уровне обслуживания, которое заключается между клиентом и провайдером. «Пять девяток» может нарисовать каждый, но это скорее маркетинговый ход. На белорусском рынке чаще всего встречаются цифры от 99,5% до 99,8%. Но давайте задумаемся: как хостинг-провайдер может рассчитать подобную доступность?
Обычно считают время простоя системы за определенный период времени. Например, сайт будет недоступен 5 минут в год.
Даниил. Обычно в гарантию не входят плановые и срочные работы, инциденты по вине третьей стороны. Или бывает так, что провайдер гарантирует «пять девяток», но нигде не прописывает ответственность за нарушение условий договора.
Но как провайдер может вычислить время доступности услуги? Экспертно? Нет. На основании статистики за прошлый год? По опыту, раз в год и палка стреляет — в дата-центр Rackspace как-то въехал грузовик и вызвал пожар.
Цифры, указанные в SLA, формируются из-за конкуренции. В своё время был хайп, начали использовать такой подход.
Хотите сказать, что «пять девяток» — показатель, высосанный из пальца?
Даниил. Не совсем. Важно помнить, что SLA — не гарантия доступности, а компенсация в рамках договора. Это как переходить дорогу на зелёный сигнал светофора: не лишним будет предварительно посмотреть по сторонам, потому что на самом деле гарантий нет, есть только правила и наказание за их несоблюдение.
Какие условия SLA предлагает hoster.by?
Даниил. В зависимости от услуг и требований клиента мы предлагаем 99,5% и 99,95% доступности. И возвращаем деньги за невыполнение этих показателей.
«Падали все, включая AWS и Google Cloud»
Как часто сбой данных происходит из-за неправильной архитектуры приложений заказчика?
Денис. К сожалению, нередко сталкиваемся с этим. Многое в работе системы зависит от самого клиента и его разработчиков. Распространённое поведение: есть проблема — звони хостеру, ругайся. А лучше сразу напиши пост в соцсети. Недавно как раз была такая ситуация: оказалось, что проблема была в неоптимальных запросах в базу данных — вопрос, который должны решать разработчики клиента. Мы с пониманием относимся к таким случаям и готовы помогать разбираться. Просто хотелось бы чуть более эффективного двустороннего взаимодействия и понимания, что если что-то не работает, это не обязательно сторона хостинга.
Вы практикуете bug bounty?
Денис. Не могу сказать, что в компании программа bug bounty официально оформлена с конкретными суммами, но да, мы несколько раз платили пользователям за найденные уязвимости.
Ошибки провайдера — это опыт или потеря репутации?
Денис. Здесь всё просто. Падали все, включая AWS и Google Cloud. Ошибки, с которыми справились и которые больше не возникают, — это опыт. Благодаря ему, мы становимся лучше. А ошибки, повторяющиеся раз за разом, приводят к потере репутации.
Даниил. Вместо того, чтобы горячиться и искать «безотказного» хостинг-провайдера, которого не существует, бизнесу стоит посмотреть, как его провайдер работает с ошибками и действительно ли устраняет первопричины проблем.
Важно понимать, что крупный сбой никогда не происходит по какой-то одной причине — это всегда сочетание сразу нескольких факторов. Например, неправильно настроенная система безопасности на стороне клиента плюс ошибка технического специалиста на стороне провайдера как последняя капля.
Можно сравнить факапы с авиакатастрофами: к сожалению, они происходят, о них все говорят, но самолеты остаются самым безопасным видом транспорта, потому что сбой — это всегда цепочка причин, и шансы, что события сложатся именно так, крайне малы.
Как относитесь к негативным отзывам?
Денис. С благодарностью. Маркетологи называют их «точками роста», мы — поводом задуматься и стать лучше. К слову, хорошим опытом клиенты редко делятся, а плохим — почти всегда. Чем крупнее компания, тем этих отзывов больше. А учитывая, что hoster.by давно обслуживает большую часть белорусских сайтов и треть рынка облаков, то было бы странно периодически не быть «антигероями». К счастью, пока справляемся.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.