Построение инфраструктуры для финансового сервиса Fondy

Начало

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

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

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

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

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

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

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

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

Совет

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

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

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

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

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

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

На скриншоте отлично видно соотношение незакрытых задач (400) к общему их количеству (552)

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

Совет

Для построения инфраструктуры, в которой разработка идет быстро, а задачи проходят каждый этап (постановка, разработка, тестирование, релиз) в кратчайший срок, важно привлечь в проект специалистов, имеющих за плечами опыт в командах, работавших по гибким методологиям, таким как 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
   • если еще в течение двух часов проблема не устранена  – сообщить топ-менеджменту в режиме телефонного звонка с организацией конференц-кола с остальными участниками матрицы эскалации