Кейс из России: построение инфраструктуры для финансового сервиса Fondy

Команда платежной системы для интернет-магазинов Fondy написала для vc.ru колонку о том, как устроена инфраструктура проекта — с какими проблемами сталкивались при проектировании, как их решали.

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

• 35 сотрудников обеспечивают работу офисов в России, Украине, Латвии, Чехии, Великобритании, Словакии и Казахстане, покрывая тем самым две больших юрисдикции: EC и СНГ.
• Более 30 серверов обеспечивают гарантированную работоспособность (Service Level) системы на уровне 99,95% (не более 20 минут запланированного, а также непредвиденного простоя в месяц) и готовы к многократному росту нагрузки.
  
• Разработка выполняется по методологии Continuous Integration с применением автоматизированного тестирования, что позволяет устанавливать обновления на production систему по несколько раз в день, не боясь получить большое количество ошибок.
  
• Бизнес-процессы построены так, что каждая новая функциональность проходит этап от идеи до реализации за 2-3 недели, а запуск нового проекта не более 3-4 месяцев.

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

Начало

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

• гендиректор — бизнес-процессы, операционные, финансовые, юридические задачи, создание продуктов;
• технический директор — технологическая архитектура, разработка ПО, проектный менеджмент.

А в команду наймем таких специалистов:

• системный администратор;
• два backend-разработчика;
  
• два frontend-разработчика;
  
• тестировщик для ручного и автоматизированного тестирования;
• бухгалтер;
• юрист;
• специалист финансового мониторинга;
  
• специалист антифрод-мониторинга.

Далее мы приступили к поиску нужных сотрудников. И с первыми проблемами мы столкнулись довольно быстро.

Проблема 1. Поиск сотрудников

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

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

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

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

Проблема 2. Запуск MVP в запланированные сроки

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

Нам никак не удавалось загрузить сотрудников работой хотя бы на 50%. Постоянно где-то возникало узкое горлышко: то задача еще не описана, то не готов сервер для развертывания среды разработки и тестирования, то команда не понимает приоритета задач.

В системе учета задач не было четких процессов, а все задачи валились одной кучей, из которой разработчик выбирал либо произвольную задачу, либо ту, которая ему больше всего нравится. Большинство задач зависали на «последней миле» — вроде бы все подзадачи сделаны, но собрать все «кирпичики» не получается.

Сначала вам кажется, что что-то не так с командой, и видимо вы наняли слабых специалистов, и стоит многих уволить или заменить. Но на самом деле основная проблема — это отсутствии бизнес-процессов.

Совет: для построения инфраструктуры, в которой разработка идет быстро, задачи проходят каждый этап (постановка, разработка, тестирование, релиз) в кратчайший срок важно привлечь в проект специалистов, имеющих за плечами опыт в командах, работавших по гибким методологиям, таким как Agile, Scrum, XP.

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

Проблема 3. Быстрый рост, масштабирование и автоматизация процессов

Когда процессы постепенно у нас начали налаживаться, появляться первые клиенты, обороты расти, очередным испытание для нас стало выделение ресурсов на автоматизацию процессов.

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

Перед нами стала дилемма — с одной стороны мы не могли остановить разработку релизов и бросить и без того небольшие ресурсы разработки на автоматизацию бэкофисных операций, с другой, если бы количество наших клиентов увеличилось в десять раз, нам бы пришлось нанять еще 10–20 специалистов, что съело бы все наши доходы и загнало в большой минус.

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

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

Проблема 4. Где размещать серверное оборудование, какое ПО выбирать и сколько это должно стоить

После года работы мы начали подсчитывать, сколько нам обходится серверное оборудование и программное обеспечение. И здесь нам на руку сыграл большой опыт и выверенное годами решение.

Мы не стали покупать собственное железо и строить аппаратную инфраструктуру, а для размещения серверов выбрали облако Amazon AWS, которое представлено в 38 зонах доступности по всему миру и соответствует десяткам стандартов, норм, сертификатов безопасности, имеет защиту от DDoS и физического доступа сторонних лиц и организаций.

Общее количество серверов Amazon, по данным сторонних аналитиков, уже в 2012 году составляло почти полмиллиона, что дает практически неограниченные возможности для масштабирования. Страшно подумать, сколько нужно ресурсов и времени потратить, чтобы обеспечить хотя бы малую часть того, что делает Amazon в инфраструктуре своего проекта собственными силами.

На этапе разработки продукта нам такой выбор дал большие преимущества — первые полгода всё серверное оборудование нам стоило не более $300 в месяц. Этого времени нам хватило для разработки MVP и проверки гипотезы нашей бизнес-модели.

С точки зрения затрат на программное обеспечение — мы всегда были сторонниками открытого ПО. Существует ошибочное мнение, что open-source-продукты менее безопасны из-за своего открытого программного кода и несут большие риски для бизнеса с точки зрения уязвимости, стабильности и качества технической поддержки. Но как компания, которая проходит ежегодный аудит безопасности и ежеквартальное внешнее сканирование на попытки вторжения, мы можем утверждать — открытое ПО ничуть не уступает именитым проприетарным продуктам известных софтверных гигантов, а в некоторых аспектах даже превосходит.

Совет. При развертывании собственной аппаратной инфраструктуры обратите внимание на облачные решения. Они как правило дешевле в эксплуатации при небольших объемах и проще в конфигурации и поддержке. В нашей ситуации один системный администратор в состоянии обеспечивать поддержку более 30 серверов без ущерба общей эффективности. Также существенно сокращают расходы open-source-продукты: базы данных, серверы приложений, CMS, CRM, системы контроля версий кода и трекинга задач.

Помимо этого стоит уделить особое внимание корпоративной безопасности. В последнее время большое количество кибератак направлены именно на бизнес. С этой точки зрения стоит доверить свою безопасность специализированным компаниям и инструментам, например, системам защиты от DDoS, обнаружения вторжения, внешнего сканирования на уязвимости.

Проблема 5. Как обеспечить стабильность инфраструктуры и защититься от падений

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

Стоит всегда ожидать, что в любой момент любая часть вашей инфраструктуры может выйти из строя: сервер, приложение, линия телефонной связи колл-центра, магистральный интернет-провайдер. Поскольку мы подписываем с нашими клиентами контракт (Service Level Agreement), который гарантирует уровень сервиса 99,95%, то чтобы его в полной мере выполнять мы постарались максимально зарезервировать все критические узлы нашей инфраструктуры и придерживаемся стратегии «пускай падает» — на случай падения у нас всегда есть резервные копии сервисов, которые в большинстве случаев включаются в работу автоматической системой мониторинга.

Также в компании разработан Disaster recovery plan — документ, который описывает матрицу эскалации ИТ-инцидентов (куда бежать, что делать, каким специалистам звонить) а также зоны ответственности сотрудников и топ-менеджеров по бизнес-процессам, которые были нарушены.

Совет

Шаг 1: настройте мониторинг ваших сервисов — есть несколько бесплатных приложений, которые позволяют, например, уведомлять в Telegram или Slack, если ваш сайт стал недоступен.

Шаг 2: постарайтесь в первую очередь зарезервировать те узлы, которые требуют наименьших ресурсов для этого: основной сайт, приложения, базу данных. Если есть возможность, сделайте так, чтобы основная база данных и резервная находились в разных географических зонах или датацентрах (вспоминаем историю с молнией в Amazon).

Шаг 3: проработайте матрицу эскалации инцидентов. Разграничьте разные возможные ситуации по их критичности и назначьте ответственных сотрудников. Определите для них максимальные сроки реакции, например, если основной сайт компании не доступен, то:

• сотрудник мониторинга должен позвонить системному администратору в течении пять минут;
• если в течении 20 минут дозвониться не удалось, или проблема не решается — позвонить техническому директору;
  
• если еще в течении 1 часа проблема не устранена — сообщить топ-менеджменту посредством SMS;
  
• если еще в течении двух часов проблема не устранена — сообщить топ-менеджменту в режиме телефонного звонка с организацией конференц-кола с остальными участниками матрицы эскалации.
  

Проблема 6. Как не погрязнуть в операционной рутине и продолжать производить инновации

На данный момент основной проблемой, с которой мы, как предприятие, ставшее на «рельсы» бизнес-процессов боремся — это разработка инноваций в том же темпе, который мы набрали на старте. Увеличивая обороты мы постепенно начинаем погружаться в ежедневные операционные задачи, которые порой занимают столько ресурсов, что основное время команды приходится тратить на поддержку текущих процессов, а не созидание нового.

С целью адаптации к быстро меняющимся требованиям бизнеса и финтех-индустрии мы сейчас разделяем нашу команду на два подразделения: Innovation и Operation Team. Основные задачи Operation Team заключаются в поддержании уровня сервиса текущего бизнеса и обеспечение доходов существующей бизнес-модели.

В свою очередь, первоочередным для Innovation Team является поддержка быстрых изменений — генерация новых идей и продуктов, внедрение инноваций, следование трендам рынка и потребностям бизнеса. Мы верим, что и с этой проблемой нам также удастся справиться.