Было ли в этом году в России хоть одно заметное ИТ-мероприятие, на котором бы не затрагивалась проблема облачных вычислений или хотя бы просто не упоминались облака в выступлениях докладчиков? Признаться, еще пару недель назад на этот вопрос можно было бы дать категоричное “Нет"! Но сейчас есть возможность столь же уверенно ответить — “да, такое было!” Причем, в качестве примера можно привести конференцию, где обсуждались вопросы разработки и эксплуатации сложных ИТ-систем с использованием самых современных подходов к созданию ИТ-инфраструктуры. Да, именно так было на 2-м ежегодном “Форуме технологий” компании Mail.Ru Group, прошедшем в середине ноября в Москве и собравшем более 800 технических ИТ-специалистов (в два раза больше, чем на первом таком мероприятии год назад).

Основной темой нынешней конференции было обсуждение вопросов стабильной работы интернет-порталов. Хотя, вместо “облаков” использовалось более понятное “веб-сайт”, на самом деле речь шла об обеспечении надежной работы именно базовой ИТ-инфраструктуры, в том числе в условиях динамического изменения нагрузки на систему со стороны огромного числа конечных пользователей. Не случайно, по данным организаторов, среди слушателей число представителей корпоративного сектора было примерно сопоставимо с числом веб-разработчиков.

Для поставщиков внешних онлайновых сервисов вопросы стабильности и производительности намного важнее, чем для поставщиков корпоративных систем, ориентированных на крупных пользователей. Из-за разового сбоя с перегрузкой приложений или задержки в его выполнении сотрудники компании вряд ли будут увольняться. А вот веб-пользователь может просто уйти к конкуренту. Казалось бы, бесплатные услуги — какие могут быть претензии к поставщику? Но, опять же бесплатность имеет оборотную сторону медали: пользователя тут ничего не держит, он может сменить поставщика сервиса одним кликом.

Сказав об этом в своем докладе, открывшем конференцию, вице-президент и технический директор Mail.Ru Group Владимир Габриелян отметил, что, по статистике Mail.ru, для среднего российского сайта показатель стабильной работы (uptime) составляет 98,6% (5 суток простоя в год), крупных сайтов Рунета — 99,96% (4 часа простоя в год), и это тоже много. По оценкам компании, если говорить о причинах аварий (см. таблицу), то в половине случаев они связаны с установкой нового или обновленного ПО (ошибки в новых версиях программ, ошибки при конфигурировании). Еще четверть случаев также обусловлена ПО, но тут речь идет о более сложных ситуациях, связанных, например, с выходом на предельные режимы работы систем. Самая редкая причина – выход из строя инфрастуктуры датацентров (например, электропитания). Но если посмотреть на качественную сторону дела (время простоя вследствие аварии), то наряду с сетевыми проблемами наиболее часты как раз аварии датацентров (по 30%).

По мнению докладчика, одним из ключевых средств обеспечения стабильности сайта является постоянный мониторинг его функционирования со стороны владельца. Именно владельца, поскольку пользователи возложат вину в простое на него, а не на провайдера (сетевого или хостинга), которого они к тому же даже не знают. Владимир Габриелян привел 10 причин, почему следует организовать мониторинг, сделав при этом акцент на то, что стоимость обеспечения мониторинга ничтожна по сравнению со стоимостью разработки сервиса.

Он сообшил, что в Mail.ru используется более 140 различных типов мониторинга (в том числе мониторинг всех мониторингов), что позволяет следить за более, чем 150 тыс. объектов наблюдения. Мониторинг контролируют все 70 системных администраторов Mail.ru, девять из них занимаются только этим, само наблюдение ведется круглосуточно.

Разумеется, только одного мониторинга недостаточно — нужно также резервирование систем и постоянное решение задач балансировки нагрузки. Для расчета средств резервирования в Mail.ru применяют такие формулы: для серверов обработки данных — N+1 (1 резервный на группу серверов определенного типа, например для вeb-серверов N=10), для хранилищ данных — 2N + офлайновая копия для отката в аварийной ситуации, запас по сетевой инфраструктуры для пиковых нагрузок — 35%. Разумеется, ввод в действие резерва должен выполняться в автоматическом режиме и достаточно быстро. В Mail.ru используется горячее резервирование, когда все запасные системы находятся в постоянном рабочем состоянии.

В качестве примера создания отказоустойчивой системы была приведена и подробно описана схема организации работы HTTP-сервиса, в том числе с использованием двух дата-центров. Было также сказано о том, что для обеспечения отказоустойчивости нужно применять модульную архитектуру проекта, которая, в частности, не дает системе “упасть” в случае выход из строя того или иного функционального блока.

Отдельно Владимир Габриелян остановился на вопросе запуска нового проекта, что обычно связано с использованием новых версий ПО. Разумеется, тут очень важно качество тестирования до запуска программ в эксплуатацию. Но это, конечно, не может исключить ошибки полностью, поэтому в любом случае полезен вариант сплит-тестирования — опробования нового сервиса на небольшой группе пользователей. Крайне желательно, чтобы ПО имело средства отката системы на предыдущий шаг. И наконец, для борьбы с авариями нужно иметь четкие и постоянно проверяемые планы действий, в том числе каждого члена коллектива, в случае возникновения проблем. Еще требуется планирование реакции на аварии, которые, как мы сказали выше, неизбежны. Любой сбой должен быть проанализирован с участием широкого круга специалистов, по результатам нужно сделать выводы.

И все же облачная тема на конференции была затронута, но уже вне основной программы мероприятия. В ходе обсуждения был задан такой вопрос: “Что надежнее в плане стабильности — облачные технологии или выделенные серверы с горячим резервированием?”. Владимир Гарбиелян высказал довольно консервативную точку зрения: “До тех пор пока ИТ не является вашим основным направлением бизнеса — я за облачные технологии. Как только вам по соображениям безопасности бизнеса понадобится полный контроль над ИТ-инфраструктурой, вы неминуемо перейдете к выделенным серверам с горячим резервированием”.

Причины аварий сайтов (источник: Mail.ru)
Тип аварии Количество, %
по числу по времени простоя
Сетевые 8 30
Аварии дата-центров 1 30
Программные аварии 25 15
При развертывании ПО 50 20
Аварии оборудования 16 5