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

Наш продукт — это платформа, автоматизирующая продажу облачных сервисов и приложений. Мы продаем инструмент, на основе которого люди строят свой бизнес. Нужно пояснить, что это не коробочный продукт, его нельзя просто купить и поставить. Для этого нужно совместно с нами определить конфигурацию платформы в зависимости от имеющейся инфраструктуры, проработать конечную архитектуру, в соответствии с ней доработать платформу (Custom Software Development), затем правильно настроить и интегрировать ее с разнообразными бек-офис системами. И одна из моих обязанностей — курирование разработки ключевых компонентов платформы. Также я отвечаю за релизы, то есть выстраиваю процесс работы всей нашей команды так, чтобы с определенной регулярностью (сейчас это 3-4 раза в год) у нас появлялись сборки продукта, которые мы можем отдавать клиентам. С тех пор, как мы стали частью Ingram Micro, главным нашим клиентом являемся мы сами. У нас есть очень жесткое правило: когда мы выпускаем какой-то релиз, то именно мы обновляемся на него в первую очередь. Раньше мы выкатывали релиз очень аккуратно, то есть сначала давали маленьким клиентам, потом клиентам побольше, а самые большие клиенты обновлялись примерно через год. Сейчас всё наоборот. После выхода нового релиза одна из самых наших больших инсталляций — Ingram Micro — переходит на него в течение месяца. Чтобы было понятно, какие задачи и проблемы стоят перед нами, нужно сначала рассказать про историю нашего продукта, которая складывается из историй продуктов поменьше.

Давным давно

В 1999 году в Новосибирске появилась компания Plesk, которая выпустила одноимённый продукт, написанный на РНР — панель управления хостингом, которая позволяла автоматизировать какие-то внутренние процессы. Сразу после создания панели новосибирцы решили написать новый продукт, Plesk 2, но уже на C++ и Java. Это были самые модные технологии в конце девяностых. Но пока писали эту вторую версию, в 2003-м Plesk была куплена компанией SWsoft. Примерно в то же время SWsoft приобрела биллинговую систему, а также немецкую компанию Confixx, создавшую ПО для автоматизации одиночных веб-серверов. После этого все вышеупомянутые продукты начали интегрировать. В результате получился набор инструментов, необходимый сервис-провайдерам для управления сервисами: платформа для веб-хостинга Plesk 2, которая потом превратилась в Parallels Operations Automation, и биллинговая система Parallels Business Automation. Целевой аудиторией по-прежнему были хостеры, мы автоматизировали хостинг сайтов и почты, а так же виртуальных машин на основе контейнерной виртуализации Virtuozzo. Мы имели дело с контейнерами задолго до того, как это стало модно

Волшебный мир телекомов

В конце 2000-х мы открыли для себя большой мир телеком-операторов. Потенциал рынка облачных услуг и SaaS-сервисов руководство компании осознало задолго до того, как это стало трендом, и мы начали переделывать свою бизнес-модель. Из on-premise-платформы — когда провайдер покупает себе дата-центр или стойку в дата-центре, и ставит туда свои сервера, — наш продукт превратился в платформу, которая автоматизировала продажу облачных сервисов, предоставляемых кем-то другим. Ключевой компонентой платформы является стандарт APS, который описывает, каким образом в нашу платформу можно интегрировать любой внешний сервис. Интересна история появления этого стандарта. Когда мы предоставляли услугу хостинга веб-сайтов, самыми популярными системами управления содержимым сайтов были WordPress и Joomla, и в принципе, с тех пор мало что поменялось. И APS изначально делался для упаковки этих веб-приложений, чтобы при продаже хостинга можно было продать установку WordPress одной кнопкой. Но когда пришло озарение про облачные сервисы, мы начали переделывать свой продукт в платформу, а APS — в стандарт для интегрирования любых сервисов. Любых — Office 365, Azure или каких-нибудь антивирусов.

Какие изменения были на телеком-рынке во второй половине 2000-х? Их сервисы, во-первых, начали стоить сильно меньше, а во-вторых, биллинг пользователей сильно упростился. Если помните, в конце 1990-х—начале 2000-х был популярный вопрос: «С какой секунды у тебя начинается тарификация, с первой, с пятой?». Первая минута звонка могла стоить одних денег, следующие могли быть дешевле. В результате этого, телекомы нуждались в большом сложном ПО, в специалистах для его разработки и эксплуатации, чтобы можно было выставлять абонентам корректные счета. В последние годы всё не так. Сейчас я плачу 400 рублей в месяц и получаю, по сути, безлимит. Сложность тарификации снизилась, освободились корпоративные IT ресурсы, которые нужно куда-то применять. Кроме того, поток денег, генерируемых голосовой связью и SMS, начал резко пересыхать в связи с появлением программ коммуникации, таких как Skype и WhatsApp. Телекомы почувствовали надвигающуюся угрозу превращения в data pipe, трубу для интернета и нулевой маржинальностью. Поэтому им стало важно открывать для себя какие-то новые области, диверсифицировать бизнес, чем они сейчас и занимаются. К примеру «ВымпелКом», владелец бренда «Билайн», недавно переименовался в «Веон» и стал позиционировать себя не как телеком, а как компанию, специализирующуюся в области цифровых технологий. Мы эту тенденцию поняли много лет назад, как и некоторые телекомы. И в результате мы начали переориентировать продукт на новую категорию клиента. Мы выпустили вторую версию стандарта APS (а потом ещё и версии 2.1 и 2.2), расширяющие возможности интеграции. Традиционные сервисы (хостинг веб-сайтов, почты, виртуальных машин) сменились многообразием облачных сервисов, интегрированных в нашу платформу.

Какие при этом возникали сложности? Хостеры и телекомы — принципиально разные. У телекома всё должно быть многократно дублировано, высокодоступно, сертифицировано, документировано, постоянно бэкапиться и тому подобное. При этом много разных отделов, зачастую воюющих друг с другом, субподрядчики, кошмарная бюрократия. У хостеров, как правило, небольшой коллектив, всего несколько ключевых людей, и даже руководители хорошо подкованы технически. В телекомах технари до верхнего эшелона власти не долетают. Также в случае телекомов уже есть ERP, CRM, какой-то свой собственный биллинг, у клиентов есть личный кабинет и счёт в системе. Соответственно, требования к нашему софту радикально выросли, особенно в плане гибкости конфигураций и возможностей интеграции, поддерживаемых нагрузок, сложности биллинга, простоты оперирования достаточно сложными процессами, качества документации.

Наши задачи

Масштабирование

Сейчас мы увеличиваем количество поддерживаемых нашей системой пользователей в 2-3 раза каждый год, при этом наряду с ростом количества пользователей у нас растёт и удельное количество сервисов на одного пользователя, а также идёт постоянное усложнение модели продажи сервисов. А вообще все с нетерпением ждут (а я ещё и немного со страхом ) так называемого hockey stick effect, когда рост системы из линейного превратится в экспоненциальный. В первую очередь эти надежды связывают с IoT (ожидается, что в этот момент количество потребляемых сервисов начнёт очень быстро расти) и окончательной смертью десктопов и традиционной модели продажи софта.

Возможность интеграции с существующими системами

Как я уже говорил, у многих наших клиентов (телекомов) уже есть какие-то свои BSS -системы, и наша платформа должна уметь с ними работать. Простейший пример — у любого телекома уже есть гигантская база из нескольких десятков миллионов пользователей. Наш продукт должен так интегрироваться в имеющуюся систему, чтобы в него можно было подтягивать данные о пользователях при помощи SSO. А дальше уже начинаются варианты – как выписывать инвойсы? Как производить оплату? Можно использовать нашу компоненту, можно использовать уже существующие системы, такие как SAP или Oracle Finance. Мы можем сами списывать деньги с кредитной карты пользователя, а можем вообще выключить наш компонент, отвечающий за платежи, и использовать уже существующий в инфраструктуре провайдера. До какого-то момента мы решали эту задачу с помощью настроек, позволяющих модифицировать поведение продукта, но несколько лет назад выбрали более системный подход – мы разбиваем платформу на микросервисы, которые общаются друг с другом, используя стабильные документированные API, это открывает безграничные возможности для интеграции, но при этом означает тотальный рефакторинг. И нужно понимать, что при этом мы не должны сломать существующих клиентов.

Стоимость оперирования

Для примера опишу одну из решаемых нами задач. Как было раньше? Когда выходил новый релиз, хостер сначала морально готовился к испытанию под названием апгрейд, потом в выходные проводил его, некоторое время нервничал, если что-то ломалось ,— засыпал нас тикетами и проклятьями, мы на лету всё чинили и бежали все вместе дальше. У телекомов всё не так :- всегда есть три экземпляра системы — Dev, Staging и Production. Любое изменение сначала пробуется на Dev, при этом процесс документируется. Затем задокументированный процесс проверяется на Staging, и только после этого применяется к Production. То же самое происходит при запуске нового сервиса или практически любом изменении конфигурации.

Наш софт должен поддерживать этот подход. То есть он должен помогать экономить время операторов системы. Потому что время, то есть деньги, которые тратятся на оперирование нашей системы, вычитаются из прибыли, которую наша система приносит. А для нас важно, чтобы наши клиенты были прибыльными, потому что тогда они довольны нами. Поэтому мы делаем большой объём работ, чтобы адаптировать платформу под современные требования — автоматизируем всё, что только можно, используя Docker и Kubernetes, добавляем возможность синхронизации настроек между системами; недавно мы подали заявку на патент встроенной системы самопроверки, использующей cucumber, интерпретирующий gherkin, одним из авторов которого, я, кстати, являюсь.

Эпоха Ingram Micro

В 2015 году нас купил Ingram Micro, который на тот момент на основе нашей платформы запустил свой облачный бизнес. Ingram Micro — крупнейший в мире дистрибьютор IT -товаров и сервисов, компания из списка Top100 Fortune с оборотом более 40 миллиардов долларов и бизнесом в более чем 130 странах. Традиционный бизнес Инграма переживает испытания, в чём-то схожие с проблемами телекомов — продажи железа падают, особенно в серверном сегменте (который является наиболее маржинальным). При этом значительная доля дохода получалась от сопутствующих продаж софта. Сейчас компании перестают покупать серверное железо и мигрируют в облака, конечные пользователи всё чаще отказываются от персональных компьютеров в пользу планшетов и смартфонов, софт (такой, как Microsoft Office) продаётся не на дисках вместе с ноутбуками, а по подписочной модели в виде сервисов. Для того, чтобы не упустить, а наоборот возглавить этот тренд, был создан департамент Ingram Micro Cloud.

Ingram отличается от большинства других наших клиентов тем, что он продаёт свои сервисы не конечным пользователям, не малому бизнесу, а реселлерам, которые в свою очередь перепродают эти сервисы. Одна из особенностей нашей платформы, которая отличает её от других решений, заключается в том, что в нашей платформе можно строить неограниченную иерархию реселлеров, собственно это и дало возможность использовать нашу систему для нужд Инграма. Благодаря этой модели появляется много интересных задач, связанных с биллингом, так как теперь мы должны обсчитывать продажи от реселлеров конечным пользователям, от Инграма к реселлерам и от поставщиков сервисов к Инграму.

Чтобы было понятнее, объясню на примере. Майкрософт выставляет нам раз в месяц счёт на несколько десятков миллионов долларов. К этому моменту мы уже выставили счета нашим реселлерам, рассчитали скидки для них в зависимости от объёма проданного, подготовили инвойсы для их клиентов, собрали с них деньги, заблокировали сервис для тех клиентов, которые не платят, и готовы провести сверку для всех этих финансовых документов. Помножьте это на количество стран, в которых мы уже работаем (около 30 и это количество постоянно растёт), добавьте расчёт налогов, различные способы и модели оплаты, скидок, и вы примерно поймёте, чем мы тут занимаемся. А, да, ещё всем типам пользователей нужно дать панель, причём каждому свою (реселлеру — такую панель, в которой удобнее продавать услуги, конечному пользователю — панель, в которой можно управлять своими сервисами, посмотреть финансовые отчёты, докупить новые сервисовы).

Что же самое сложное в процессе разработки?

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

Над нашим продуктом трудится больше 300 человек, распределённых по нескольким командам, не подчиняющимся друг другу, а работающим параллельно. Описание такой структуры компании заслуживает отдельного рассказа, потому что при таком масштабе многие процессы, строятся совсем иначе, чем когда работаешь параллельно с 5-10 людьми. Через годы я пронёс несколько убеждений, которые всё это время подтверждались на практике. Например, я стараюсь сделать так, чтобы мои команды были сбалансированными. Практически любая из них может выполнять любые задачи. Конечно, в каких-то компонентах они разбираются лучше, чем в других. Но при этом у меня нет искусственного разделения, что одна команда может делать вот эту компоненту, а другая — только вот эту. Это позволяет свободно перемещать сотрудников между командами, если возникает такая необходимость. Когда в командах возникают узкие специализации, то зачастую это очень вредный паттерн, особенно когда появляются люди-компоненты (программисты, работающие с одной компонентой, про которую больше никто ничего не знает). В одиночку людям свойственно заблуждаться и постепенно сходить с ума, сила — в команде, как бы банально это не звучало.

Очень важная часть моей работы заключается в том, чтобы люди знали, что происходит вокруг них, то есть делились информацией. Если отбросить периодические и, увы, неизбежные моменты, когда я выступаю кризис-менеджером, то большую часть времени я налаживаю потоки коммуникаций внутри команды, помогаю информации свободно распространяться. Звучит просто, но увы не только лишь все понимают необходимость и важность информационного обмена. Зачастую у нас самое сложное — не писать написать или изучить какой-то фреймворк, а согласовать изменения так, чтобы финальный результат устроил всех. Да, конечно, в нашей сфере бывают люди, которые не хотят ни с кем разговаривать и не считают, что должны кому-то рассказывать. Они настаивают, чтобы им просто дали сложную задачу, и они молча её решат. Некоторое количество таких людей мне даже нужно, чтобы они могли брать специфические проблемы, погрузиться в задачу на два месяца, а потом всплыть с решением. Но таких людей не должно быть слишком много, и нельзя позволять идее обособленности заражать остальных. Нужно как-то примирить эти две категории, а большинство — научить разговаривать и объяснять, что нужно делать.

Но не поймите меня неправильно, конечно, техническая грамотность является необходимым условием. Лично я с недоумением смотрю на людей, которые называют себя программистами, но при этом ни разу в жизни не читали Design Patterns GoF, не знают (хотя бы примерно), как работают базовые сортировки и что такое оценка сложности алгоритма, не умеют в многопоточноcть или хотя бы приблизительно не представляют, как внутри устроены компьютеры — что такое pn переход, конвейер, регистры. В конце концов, инженер — это человек, понимающий, как устроены вещи, которыми он пользуется (это моё собственное определение ).

Постоянный анализ — неотъемлемая составляющая эффективной работы, причем анализировать надо как результаты, так и намерения, как краткосрочные, так и долгосрочные. Помимо достаточно стандартных iteration review и standup’ов, периодически мы устраиваем крайне полезное упражнение – команды анализируют свои достижения за последние год-два, насколько успешно используется новая функциональность. Это очень здорово позволяет понять, как обстоят дела в действительности. Дизайн и обсуждение предстоящих работ — ещё более полезная активность, к сожалению, склонная к захождению в тупик в сложных случаях и далеко не такая весёлая, как ковбойское программирование, поэтому тут мы пытаемся сохранять баланс между продуманностью и фаном.

В целом как-то так, в дальнейших статьях мы продолжим рассказ о нашей компании, с большей конкретикой и более подробными деталями.