Роман Веселов: «В ИТ возможно все, или я недостаточно профессионален»

Нельзя лишь два байта уместить в один – все остальное вполне реально, считает Роман Веселов, директор по информатизации компании «ТрансКонтейнер». На запросы бизнеса он не говорит «нет», а ищет и находит способы их реализовать. В поисках новых возможностей происходит миграция всей инфраструктуры компании в облака, разработан онлайн-сервис, которым пользуются практически все клиенты компании.

Как давно ваша компания предоставляет онлайн-сервисы своим клиентам?

В свое время у нас 1000 заказов в день принимали 200 человек в региональных центрах. Теперь всё происходит онлайн. Клиенту сразу при обращении известна цена перевозки, включая международные маршруты, в любой момент можно отследить дислокацию груза. Но так было не всегда.

В 2007 году, чтобы организовать перевозку груза через «ТрансКонтейнер», вы должны были взять приложение из своего договора, сделать столько ксерокопий, сколько необходимо для оформления заказов, заполнить все от руки, прийти в ближайший наш офис, часа два или три постоять в очереди, и тогда у вас может быть приняли бы заказ или же отправили обратно, потому что вы что-то забыли вписать в бланк.

Первый президент РЖД Геннадий Фадеев рассказывал, как к нему на прием пришла женщина, которая ожидала свой груз в контейнере. Она обратилась на станцию, в отделение дороги, а затем и в Министерство путей сообщения с просьбой посодействовать в доставке контейнера. Геннадий Матвеевич был удивлен столь большой просрочкой в доставке, но еще больше удивился, когда узнал, что в Министерстве и сами не смогли определить местонахождение контейнера. Уровень развития информационных систем не позволял этого сделать: работа строилась на телефонных переговорах и бумажных отчетах.

Первые проекты по созданию онлайн-сервисов мы начали в 2008 году, но теми приложениями пользовалось ограниченное количество компаний, так как они были очень тяжелыми. В 2012 году стало ясно, что без онлайн-инструмента формирования и обработки заказов не обойтись: общаться с клиентами надо в цифровом формате.

Семь лет спустя практически 100% наших клиентов используют онлайн-сервис iSales. Осталось буквально несколько, которые его не применяют, но это очень крупные уникальные клиенты с особыми запросами. Проект внедрения iSales был признан лучшим в категории «Транспорт» в конкурсе «Проект года» сообщества ИТ-директоров Global CIO, состоявшемся в 2018 году.

iSales полностью ориентирован на ввод данных и управление через веб-интерфейс. Следующий стратегический шаг – переход на прямое взаимодействие ИТ-систем с нашими заказчиками. Такой механизм уже создан, мы тестируем его и ведем переговоры с партнерами, заинтересованными в интеграции. С момента старта проекта в 2017-м мы планировали опубликовать API, с помощью которого любая компания сможет получить доступ к нашей системе онлайн-заказа и мониторинга грузов, и концу текущего года намерены завершить эту работу.

Как определяли метрики, необходимые для работы сервиса?

Я знал, какими должны быть показатели. Например, на создание заказа я разрешаю потратить не более минуты общего времени. Время получения ставки – первичной оценки перевозки – не должно превышать 15 секунд. Минута – это весь процесс от ввода пароля клиентом до получения нами оплаты. Имеется в виду минута чистых действий – если кто-то уходит пить кофе посреди заказа, это в счет не идет. Но если наша система не дает первую ставку за 15 секунд – значит, она работает с серьезным отклонением. И теперь мы в этот норматив укладываемся. Раньше это время составляло две с половиной минуты. Этот параметр – 15 секунд – был мной задан архитекторам и разработчикам системы с самого начала. Потому что я знаю из своей практики, что должно быть именно так: в данном вопросе быстродействие крайне важно для бизнеса.

Раньше я руководил филиалом нашей компании в Санкт-Петербурге. Поэтому, как именно действуют сотрудники в любой ситуации и как работают все наши бизнес-процессы, представляю отчетливо. И знаю, как их автоматизировать. Возглавил департамент ИТ по решению генерального директора компании.

Иногда бизнес может не знать, какие ИТ-инструменты доступны. Соответственно, мы должны предпринимать определенные действия и знакомить сотрудников с инструментарием, существующим для решения подобных задач. Я делаю это систематически, что всегда окупается и, как говорится, выстреливает.

На модель сервисного обслуживания с нашими бизнес-подразделениями мы еще не перешли, только начали ею заниматься. Я просто не мог предложить им SLA с 80%-ной доступностью, который мы только и могли гарантировать. За последние три года мы сделали значительный рывок в повышении надежности инфраструктуры и теперь вышли на показатели доступности ИТ-сервисов на уровне 98–100%. Теперь можно и нужно вести переговоры с бизнесом о заключении SLA для конкретных сервисов. Мы в процессе таких переговоров со всеми подразделениями компании.

Как удалось этого добиться?

Ключевую роль сыграли два фактора: налаживание постоянного мониторинга сервисов и переход от традиционного собственного ЦОДа к облачной модели на базе IaaS и PaaS и SaaS.

Прежде всего было необходимо разобраться со стабильностью работы. Проблема заключалась в том, что по нашим данным все функционировало: серверы в порядке, сеть есть, базы данных подняты, а пользоваться сервисом заказов клиенты не могут. В ИТ-департаменте все нормально, а мне звонит генеральный директор и спрашивает, почему не рассчитать стоимость? Наше ключевое бизнес-приложение – iSales – сложная связка ПО и оборудования, а потому найти слабое звено в реальном времени у службы эксплуатации не было шансов.

Причем я сам иногда узнавал о наших сбоях от своих старых клиентов, знавших меня еще по Санкт-Петербургу. А зачем же до такого доводить? Ведь непрерывность работы сервисов – мой KPI. Внедрение системы мониторинга (фото) многократно повысило надежность системы, сократило время реакции и простоев. Теперь пользователи чаще всего даже не знают, что у нас что-то ломалось.

На табло в моем кабинете вынесены не отдельные приложения или инфраструктурные элементы и их работоспособность, а сервисы целиком – скажем, сервис управления продажами или сервис управления исполнением заказа. Я мониторю семь ключевых из них и вижу ответственных дежурных, но информация о работоспособности систем поступает в автоматическом режиме, а не по их докладу.

Мониторинг сделан на базе Zabbiх и Grafana. Zabbix имитирует прохождение транзакций по всей цепочке систем, обеспечивающих сервис. При таком подходе любые сбои выявляются сразу. Видно превышение нормативов быстродействия сервисов, все падения – на их основе вычисляется SLA. Каждый инцидент – а превышение норматива это инцидент – расследуется, составляется отчет, обсуждаются действия персонала по устранению проблемы. Основная задача не в том, чтобы быстро починить, а в том, чтобы выявить причину сбоя и устранить ее. Без этого кейс не закрывается. Если надо, при систематических сбоях фрагмент системы будет полностью переделан.

Я могу скорректировать даже готовое решение, которое перестало удовлетворять текущим потребностям. Это, конечно, непросто, зато мы быстро берем на вооружение самые новые технологии. Часто переделки позволяют устранить систематически возникающие проблемы, причины которых так и остаются неясными.

Сам Zabbix размещен в моем ЦОДе, расположенном в нашем здании. Так что если сеть пропадет в здании, мы об этом даже не узнаем. Система мониторинга не сможет отчитаться о сбое. Правда, за два года еще такого не было. Однако я считаю проблему серьезной, поэтому рассматриваю SaaS-систему для мониторинга

Недавно на конференции в Сан-Франциско познакомился с компанией, предоставляющей внешний облачный сервис, который умеет мониторить все стандартные сервисы компаний Microsoft, Google, Amazon. Можно быстро и просто обучить его мониторить наш iSales, и потом мы полностью перейдем на него. Тогда своя внутренняя система мониторинга станет не нужна. Эта действующая система мониторинга появилась в 2017 году, когда наша компания еще только вступала в облака. Но, конечно, она должна быть облачной, как и все остальное.

Каким был ваш путь к облакам? Завершен ли он?

С самого начала iSales создавался в облаке. Раньше я должен был постоянно инвестировать огромные ресурсы в свой ЦОД для поддержания его работоспособности, обновлять оборудование. Я просто не мог обеспечить надлежащую надежность, или это стоило бы космических денег. 2015 год показал, что и с поставками могут быть очень серьезные проблемы. Мне стало ясно, что надо переходить на облачное развертывание. Весь 2017 год мы переходили к облачной модели, и теперь по итогам 2018-го уровень доступности сервисов достиг 99%.

В основном все приложения делаем сами. Свои аналитики, свои ключевые разработчики. На рынке берем только программистов, специализирующихся на кодировании, если нужно сократить срок внедрения. До 2015 года у нас было очень много аутсорсинга разработки, в том числе внешние ключевые компетенции. В результаты мы иногда не понимали логики работы собственных ИТ-систем. Теперь мы полностью ушли от такой зависимости. Скорее всего, будем расширять команду, потому что модулей требуется все больше.

Заданные нормативы быстродействия iSales потребовали от команды отчаянных усилий. Два месяца шло проектирование, выбор архитектуры. Ребята приходили такие счастливые, когда получалось! Использовали микросервисы, распараллеливание потоков, и многие другие новые подходы. Для нас это не дань моде, а необходимость. Создана собственная команда разработки, позволяющая реализовать полный цикл создания ПО и владеющая всеми современными технологиями: руководители проектов со специализацией в управлении собственным производством, аналитики (бизнес- и системный анализ), разработчики; тестировщики, DevOps.

Самым рискованным было решение о переводе приложения в облака, о построении его там. Сейчас это облако ПАО «Ростелеком». Поддержка российских облачных провайдеров тогда, в 2017 году, была еще далека от идеала и нужного уровня зрелости. Но, несмотря на это, мы решили для начала оставить данные в России. Поэтому, когда требовалось реализовать уже архитектурные вопросы, обсуждалось применение Docker, микросервисов и связанных с ними подходов, стало ясно, что эти разработки Google, Microsoft, Amazon и других облачных операторов развиваются стабильно и пользоваться ими вполне надежно, а со временем мы можем добавить западные решения в мультиоблачную архитектуру.

Для меня самым важным было то, что в долгосрочной перспективе создаваемая ИТ-система будет развиваться в облаках надежно и нужный уровень доступности будет обеспечен. За два года iSales ни разу не «упал» из-за внутренних проблем. Связанный с ним ОТМ (Oracle Transportation Management) – тяжелое приложение, если оно выходит на пик производительности, это сказывается на работоспособности iSales и проблемы случались.

Пока у нас гибридная архитектура: часть приложений в своем ЦОДе, часть в облаке, но это не целевой вариант. Мы движемся к полноценному облачному развертыванию корпоративной инфраструктуры, и 30% приложений уже в облаке. В этом году мы хотим выйти на 70%, и в 2020-м – на 100%. Хочу заменить, все наши кастомизированные решения на SaaS и наши собственные разработки должны оказаться в PaaS, затем нам совершенно не понадобится свой ЦОД.

Как вы переходили в облако «Ростелекома»?

Первый конкурс, в котором победил «Ростелеком» (названия трех других претендентов я тогда впервые услышал), был на выделение IaaS-мощностей. В начальный момент я был готов к тому, что переезд в «Ростелеком» окажется напряженным, и, возможно, нам даже придется вернуться в свой ЦОД. Было много переговоров с топ-менеджерами провайдера, потому что следовало с самого начала обеспечить хороший SLA, что тогда, два года назад, представлялось совсем неочевидным фактом. Три месяца прошли очень напряженно, но поддержка «Ростелекома» проявилась с сильной стороны – переезд состоялся на отлично!

У меня работает бригада администраторов – это традиционные «железные» люди, им нужно «железо», новое и свежее, причем желательно почаще. Я за два последних года переквалифицировал их в администраторов облака. У тебя есть консоль, ты видишь параметры, в ЦОД ходить не нужно. Им это было очень тяжело, но постепенно, за год, трансформация произошла. Часть администраторов сама переобучилась, часть прошла обучение. Теперь они очень хорошо справляются. Следующий шаг – уйти из IaaS в PaaS. Я не планирую покупать в дальнейшем лицензии на базы данных, а собираюсь брать их по подписке.

Моя цель не гибридность, а чистое облако, причем у нескольких провайдеров. И когда мы первый раз обсуждали, как будем работать с несколькими облачными площадками, наши администраторы собирались ехать в командировку и лично налаживать интеграцию между ЦОДами провайдеров, но я их вовремя отговорил: все через API. А теперь «облачное» мышление стало нормой.

Уровень надежности облаков стремительно растет. Уже есть технологии, позволяющие в режиме горячей замены перераспределять нагрузку, исключать засбоившую виртуальную машину и спокойно разбираться с ней дальше, а все приложения продолжают между тем работу в других, мгновенно поднятых окружениях – доли секунды на это уходят. Наши провайдеры идут, естественно, хоть и с запозданием, но тем же путем, что и Google с Amazon. Я их сотрудников все время встречаю на международных конференциях: перенимают опыт. Любой облачный провайдер теперь понимает, что если меня не устроят SLA, все наши системы в течение двух дней уедут к их конкурентам. Технически с этим переходом нет никаких проблем.

А что говорит обо всем этом ваша служба безопасности?

Я общение со службой безопасности понимаю как здоровую содержательную дискуссию. Они всегда были противовесом для меня, на уровне генерального директора обозначали серьезные риски, которые мы тщательно прорабатывали. Санкции, антисанкции, персональные данные – подобные темы мы постоянно обсуждали и просчитывали. Если мы сидим и боимся всего на свете – к нам и бизнес относится соответствующе. А если мы смелые и открытые для изменений – то и реакция на наши инициативы другая. Но и кибербезопасность – ключевой фактор построения любого решения. Поэтому тут без коллег из службы безопасности никуда.

Сотрудники службы безопасности тоже научились работать в облаке, и даже более спокойны теперь, чем раньше. Прежде, если кто-то скачал файл из корпоративной сети, можно было и не понять, что это случилось и кто это сделал. А в облачных средах фиксируются многие действия, о чем работники предупреждаются сразу.

Какой оказалась экономика владения облаками?

Новый ЦОД я специально не строю, хотя еще в 2016 году такой проект был запланирован. Теперь я уже совершенно не понимаю, зачем бы нам мог понадобиться свой дата-центр.

Мои расчеты владения iSales в своем ЦОДе показывают, что это втрое дороже, чем у облачного провайдера. Иметь ЦОД у себя – значит заводить резервный ЦОД и держать копии приложений и систем. Предположим самый плохой вариант: iSales недоступен 4 часа в первой половине рабочего дня. Это возможно в случае очень серьезной, скорее всего, энергетической аварии, нечто на уровне катастрофы. Считаем убытки: они будут, но это сумма намного меньше, нежели затраты на собственный резервный ЦОД в течение года. И нашему бизнесу это понятно. Заказы, которые не принятые в первой половине дня, будут обработаны во второй половине. А вот иметь второй резервный iSales у другого провайдера – это легко, это для меня не проблема.

Еще один вопрос – быстродействие. Сейчас, если я приду к генеральному директору с просьбой купить новый сервер, от идеи до реализации уйдет примерно четыре месяца. За какое время можно поднять аналогичную мощность в Amazon, Google или «Ростелекоме»? Четыре минуты. Параллельно мы постоянно пробуем другие облака. Очень нравится Microsoft Azure и Google Cloud Platform. Надо понимать, что там не только автоматически покрывают пики и биллинг считает только реально полученные услуги и мощность. Там идет автоматический мониторинг загруженности ресурсов, и мне предлагают свернуть виртуальные машины, если они не используются, то есть снизить мои расходы. «Яндекс» анонсировал свой PaaS и IaaS. Думаю, у них все эти механизмы тоже есть, и мы намерены пробовать. Amazon, «СберКлауд» – мы хотим попробовать все.

Например, мы избавились от собственного ЦОДа. Но остается сеть, и она тоже очень дорого стоит. А зачем она? Она уже не нужна. Идея «иметь что-то внутри компании свое и контролируемое» на одной чаше весов, а на другой – цена этого удовольствия, уже весьма сомнительного и далеко не обязательного. Сейчас сеть еще нужна, потому что работают внутренние приложения. А если все действует по API?

У нас в компании 3 тысячи человек. На конференции Google я слышу рассказы клиентов, которые перевели свои 40 или 240 тысяч сотрудников на облачные приложения. На этом фоне мы выглядим очень скромно со своими нагрузками. Смотришь, как они на сцене рассказывают про свои проекты миграции, и думаешь, ну и чего я со своими 3 тысячами боялся... Затем возвращаешься на работу, открываешь ИТ-стратегию, берешь 16-ю страницу и кладешь ее в начало документа. Вызываешь администраторов и говоришь: все, забудьте вы про свои покупки серверов, мы будем делать совершенно иначе. И никакие риски, о которых мы два года назад переживали, не реализовались.