Вместо этого можно арендовать виртуальный дата-центр у надежного IaaS-провайдера и сосредоточить усилия на разработке программного обеспечения, сфокусироваться на своем основном бизнесе.
Представляем вашему вниманию интервью с Виктором Канаевым, руководителем отдела облачных вычислений компании «Первый БИТ» (Сервис ЛАЙВ). Виктор давно занимается SaaS-проектом на базе 1С, и мы не смогли пройти мимо возможности задать ему пару вопросов о специфике работы в IaaS-облаке, критериях выбора облачного провайдера и особенностях инфраструктуры проекта облачной 1С.
Виктор, насколько мне известно, ваше подразделение примкнуло к компании «Первый БИТ» не так давно для развития облачных проектов. Расскажи, чем занимаетесь сейчас и почему решили пойти в облака?
Верно, «Первый БИТ» существует на рынке уже 18 лет, а наше подразделение появилось в структуре только 5 лет назад. Изначально мы были отдельной организацией и занимались аутсорсингом малых и средних компаний. За то время, я бы сказал, мы успели познать всю боль заказчика в части построения адекватной серверной инфраструктуры. Далеко не каждой компании есть смысл вкладываться в серверную, нанимать администраторов и т. п. Они и не вкладывались, а на выходе получались те самые ужасные системы из стоящего под столом сервера с наполовину работающей бухгалтерией и внезапными сбоями. Собственно, поэтому мы и хотели заниматься именно облачными проектами – потому что верили в удобство и выгоду новой идеи для бизнеса. С одной стороны, нет больших первоначальных расходов, с другой – за серверную часть отвечают профессионалы.
Но ведь ваши клиенты – как правило, небольшие организации с несколько старомодным взглядом на управление. Насколько легко они переходят в облачную среду? И вообще, почему именно 1С?
К моменту появления «Лайв технологий» (так мы называемся) в структуре «Первого БИТа» на рынке уже оформилась готовность к облачным решениям. Как вы помните, популярность термина «облачные вычисления» тогда только набирала обороты, но перспективы были уже вполне оценимы. Для «Первого БИТа» было очевидным создание облачного направления именно на базе продукта 1С. Решение было как имиджевым, так и дальновидным – возможностью использовать накопленный многолетний опыт в новом направлении. К тому же редкому человеку в России нужно объяснять, что такое 1С и в чем преимущества системы. Да и подобную гибкость конфигурации сложно найти в узкоспециализированных SaaS-продуктах. В конечном итоге наша миссия – сделать услугу удаленного доступа к базам 1С такой же простой, как почта в каком-нибудь Gmail. В наше время кто угодно может с легкостью зарегистрироваться в онлайн-сервисах электронной почты и, не задумываясь, обмениваться письмами. Мы хотим сделать доступ к 1С таким же простым и удобным для любой компании.
А на базе IaaS решили строиться из-за финансовых соображений или чего-то еще?
При запуске проекта мы, конечно же, рассматривали массу вариантов с покупкой и арендой железа. Не буду вдаваться сейчас в муки выбора и расчеты, но выбор пал на IaaS. Перспектива аренды мощностей выглядела наиболее здравой, если принять во внимание, что основной бизнес компании заключается в разработке ПО. Администрирование серверов и построение отказоустойчивых ЦОД – это уже не наш профиль, и лучше делегировать подобные вопросы кому-то еще. Практически как по учебнику: сфокусироваться на бизнесе, а второстепенные задачи обслуживания перепоручить.
Насколько я знаю, в облако «ИТ-ГРАДа» вы перешли не так давно, а до этого размещались за границей. Расскажите немного об этом опыте. И почему решили перенести все в РФ?
Все верно, мы стартовали не на отечественных мощностях, а на американских и английских провайдерах. Тогда и технологии у них были более зрелые, и наш отечественный бизнес активно стремился разместиться где-то подальше – отсюда и такой выбор. Со страной размещения вообще интересно получается: если 5 лет назад бизнес в основном требовал, чтобы данные находились НЕ в России, то в последние пару лет все обстоит с точностью до наоборот. С чем связано – сказать сложно. Может, это закон о персональных данных сыграл роль, политическая обстановка или что-то еще – не суть важно. Но теперь предложение разместиться за рубежом обычно встречают решительным отказом. С учетом того, что мы работаем более чем с 1000 компаний (не пользователей, как некоторые любят считать – именно компаний), статистика вполне репрезентативна.
То есть переезд произошел в угоду спросу?
Конечно. Не могу сказать, что дело было только в этом, но в какой-то момент размещение в РФ стало более оправданным с точки зрения ведения бизнеса и разумной экономии.
Хостились изначально, наверное, у Amazon? Разница между отечественными и американскими поставщиками ощущается?
Amazon, конечно, вспоминают в первую очередь, но мы работали не с ним. 5 лет назад они не предлагали виртуальных машин на Windows, поэтому пришлось работать с другими поставщиками. Сейчас же бизнес уже не хочет за рубеж, а Amazon не торопится открывать ЦОД на территории России. Поэтому в обозримом будущем работу с ними не планируем. Хотя компания искренне поражает меня технической красотой своих решений и возможностями автоматизации.
Интересно. А что именно тебя «зацепило» в их облаке?
Больше всего мне нравится их эксклюзивная фишка «биржа мощностей». Идея в том, что клиенты могут перепродавать арендованные у Amazon мощности. Фактически поставщику все равно, как используются уже приобретенные ресурсы, а у заказчиков часто простаивают мощности. Соответственно, есть биржа, где клиент может выставить на продажу свободные ресурсы по собственной цене для всех желающих. Зачастую стоимость таких предложений ниже исходных от Amazon. Благодаря всему этому можно реализовывать интересные варианты автоматизации. Например, я видел в работе сценарий с автоматической балансировкой серверной нагрузки, где перед переносом сервера сначала опрашиваются именно «биржевые» дешевые ресурсы. И только если там ничего не нашлось, сервер запускается на новых ресурсах Amazon. В этом плане отечественному облачному рынку есть куда расти.
За время тесной работы с облаками у вас наверняка сформировалось свое видение «правильного» облака и ЦОД. Расскажешь?
Строго говоря, требования у нас с самого начала были вполне стандартные и со временем не менялись – надежность и скорость работы. Внезапно, да? Но теперь мы немножко сменили фокус. Дело в том, что любые ИТ-системы все равно ломаются, равно как и корабли, машины, любые другие механизмы. Поэтому мы добавили еще один критерий – открытость и способность провайдера находить компромиссные решения в кризисных ситуациях.
То есть качество техподдержки?
Не совсем. Тут стоит проиллюстрировать на примере. За рубежом нередко встречается подход Service Management, когда при аварии провайдер не дает обратной связи по ходу работ и не прогнозирует их завершение. Вместо этого вам просто начисляют компенсацию за время простоя и объясняют, что простой этот невыгоден провайдеру в первую очередь и потому они и так делают все возможное для скорейшей починки. Дескать, «мы все знаем, не отвлекайте от ремонта». И такой подход вполне имеет право на существование, за исключением одной ситуации – когда клиентом провайдера является поставщик более «высокоуровневой» услуги. Если вы организуете свое SaaS-решение и для этого используете мощности другого провайдера, то при его аварии попадаете в своеобразный информационный вакуум. Вы не знаете, когда все вернется к нормальному виду, что транслировать клиентам и как объяснять им недоступность сервиса. В таком случае компенсация от нижестоящего провайдера вам не сильно поможет, ведь фактически простаивает не одна организация, а сотни. Именно поэтому для нас важнее умение и готовность поставщика обсуждать такие моменты и находить компромиссные решения.
Но ведь сразу и не узнаешь, насколько потенциальный поставщик «гибок». Как вы оцениваете этот критерий заранее?
У нас есть своеобразное ноу-хау. За время существования подразделения мы сотрудничали более чем с 20 различными дата-центрами и выработали собственную методику тестирования услуг. Если кратко, то методика делится на техническую и бизнес-составляющие. Если с технической все просто (прогон синтетических и симуляционных тестов на пробном пуле ресурсов), то с бизнес-частью интереснее. В ходе пробы нового провайдера наши представители бизнеса общались с представителями бизнеса провайдера, а мы следили за скоростью и качеством ответов. И по тому, как и с какой скоростью отвечают разные компании, можно сделать вывод о поддержке в будущем. Банальный, но показательный пример: просишь что-то изменить в КП, а поставщик уходит в месячное совещание. Очевидно, что их система принятия решений никак не ориентирована на скорость. По результатам технического и бизнес-тестирования мы делаем заключение о соответствии потенциального провайдера нашим ожиданиям.
Любопытно. И как, осечки были?
Конечно, были и ошибки. Даже двухкомпонентная оценка ничего не гарантирует, но мы хотя бы снижаем вероятность наткнуться на неподходящую компанию в дополнение к проверке работоспособности их технологий.
Кстати, о технологиях. Расскажешь, как технически устроен ваш сервис?
Все наши проекты строятся из типовых блоков (назовем это так). Каждый блок состоит из Windows-сервера с базой 1С и встроенной клиентской части; для нагруженных проектов мы еще разделяем на разные машины клиента и базу. Помимо самой инфраструктуры 1С в качестве вспомогательных сервисов существуют Active Directory, Linux-машины для маршрутизации и прочих сетевых функций, терминальная ферма Windows, системы мониторинга. Получается, что велосипед мы не изобрели – обычная масштабируемая enterprise-инфраструктура в облаке IaaS. Что касается самого приложения, то мы поддерживаем как актуальные версии 1С 8.2/8.3, так и архаичную «семерку». Для подключения клиентов используем службу терминалов (RDP). Почему не веб-доступ к 1С? Конечно, сама 1С бухгалтерия 8.2 готова к работе через веб, но вот выстраиваемые вокруг нее сервисы – далеко не всегда. Например, рабочее место операциониста в вебе работает прекрасно, а главного бухгалтера – нет. Поэтому пока придерживаемся более старомодной, но стабильно работающей схемы.
А как решаете вопрос скорости, надежности приложений и инфраструктуры? Используете ли какие-то технологии повышения доступности?
Что касается скорости, мы практически не используем клиент-серверный режим 1С благодаря побочному эффекту файлового режима на терминальном сервере. Как известно, файловый режим не подходит для организаций с несколькими одновременно работающими пользователями – система блокировок файлов базы просто не позволит комфортно работать (все эти «1С тупит», «база висит» как раз оттуда). Но в небольшой организации причиной тормозов является сеть, которая не в состоянии быстро прогонять туда-сюда гигабайты данных. Но если клиенты и сервер находятся на одной машине, такой проблемы нет вообще. Даже несовершенство блокировок особенно не заметно, ведь данные перегоняются практически мгновенно. В результате мы можем построить более простую инфраструктуру без SQL и без потери качества услуги. Что касается надежности, то тут вопрос неоднозначный. За 5 лет мы собрали некоторую статистику доступности сервиса и выяснили, что сама 1С-инфраструктура достаточно стабильна и статистически значимых аварий у нас не было. Остается думать больше о надежности Windows-инфраструктуры. Но и тут не все так просто, ведь даже кластеры и дорогие сложные схемы распределения нагрузок не страхуют «от всего». Да и заказчик предпочтет не тратиться на «условно-полезное» дополнение. Поэтому мы решили организовать надежный бэкап на все случаи жизни. Тогда любая авария на сервере клиента решается очень просто: разворачиваем новый пустой «кубик» системы и туда заливаем данные из резервной копии.
Хорошо, а если с облаком что-то случится или с дата-центром – задумывались ли о Disaster Recovery?
В свое время мы просчитывали разные варианты DR для нашего SaaS и выяснили пару забавных моментов. В таких случаях бизнес очень хорошо считает деньги и сравнивает скорость восстановления из бэкапов с ценой за DR-решение. Вы знаете, очень часто компании готовы потерпеть час и подождать восстановления данных силами ИТ-отдела. И за все время существования компании мы так и не нашли такую стоимость DR решения, которая удовлетворила бы значимый процент заказчиков. Более того, многие из них искренне удивляются, когда узнают, что катастрофоустойчивая система – отдельная «фича» и в комплект решения «по умолчанию» не входит. Так что сейчас мы не считаем целесообразными подобные проекты для услуги – они банально не найдут спроса.
Что ж, с настоящим все понятно. А что с планами на будущее? Как планируете развивать сервис и в какую сторону смотрите?
Сейчас мы плотно работаем над другим проектом – системой мониторинга для НЕ IT-специалистов. Все технари любят окружить какое-нибудь приложение кучей датчиков, контролировать все процессорные показатели, объем памяти, место на дисках и т. д. и т. п. Но бизнесу – людям, далеким от IT, – это все не нужно. Вместо множества датчиков и показателей они просто хотят знать, работает их корпоративная почта или нет; есть у офиса доступ в Интернет или нет. Список можно дополнить, но основная идея в том, чтобы IT-система оповещала бизнес только о значимых для них вещах. Благодарим Виктора за интересную беседу и пополнение нашей копилки знаний по реализованным проектам в IaaS-облаке «ИТ-ГРАДа».
