poc код что это

Почему никогда не стоит использовать Proof of Concept в продакшене

Никогда не встречал разработчика, не любящего создавать всевозможные proof of concept (POC). Возможность построить что-то новое с нуля, чтобы протестировать теорию/процесс/технологию… Сама мысль об этом вдохновляет меня.

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

Частично привлекательность создания proof of concept заключается в широте способов их применения. Можно создать POC для чего угодно! Хотите ли вы создать что-то забавное, научить кого-то незнакомой концепции, придумать идею для бизнеса или научиться использовать новую технологию для решения проблемы — варианты просто бесчисленны.

Но стоит быть аккуратными со своими ожиданиями. Я постоянно вижу, как разработчиков просят просто брать в продакшен их POC. Не делайте этого!

Proof of concept — это именно концепция. Это не «рабочая лошадка» для продакшена, соответствующая всем рекомендациям, общепринятым шаблонам и процессам разработки. Это инструмент для демонстрации идеи за короткий промежуток времени.

Сегодня мы поговорим о четырёх причинах, по которым POC ни за что не должно попадать в продакшен.

Продакшен изменяет способ разработки

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

Не важно, как вы реализуете результат, если в результате сможете доказать свою правоту.

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

БОльшую часть времени нужно тратить на реальный продукт, а не на POC, которое продаёт вашу идею владельцу продукта.

Proof of concept должно передать вашу идею за как можно более короткий промежуток времени.

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

Оно не предназначено для этого

Ваше POC создавалось, чтобы проиллюстрировать суть. Это идея. Она не создавалась с расчётом на нагрузки продакшена.

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

Нет, вы попросите составить чертёж в CAD, всё просчитать, найти несущие нагрузку конструкции и формализовать проект, прежде чем к нему приступать.

Ваше proof of concept — это набросок на листе. Он выполнил свою цель и продемонстрировал чёткое направление, но в продакшене вы использовать его точно не будете. Его нужно проработать, правильно спроектировать, разбить на истории и задокументировать.

Если команда разработки использует методологии agile, то этот процесс будет выглядеть примерно так:

Proof of Concept хрупки

Вы отлично справились. Вы создали POC, единственное назначение которого — демонстрация работающего примера новой концепции. Его создание почти не заняло времени, и вашему руководству оно понравилось. Отлично!

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

Но вы-то знаете правду.

В нём нет обработки ошибок. Вы создали ПО, которое будет работать в идеальных условиях. Как только вы отклонитесь от реализованного в коде процесса, он сломается.

На обзоре спринта вы не отклоняетесь от сценария демонстрации, и на то есть причины. Если вы нажмёте кнопку X вместо кнопки Y, всё развалится. Но это нормально! Вы создали именно то, что и должны были создать. Proof of concept продемонстрировало именно то, что и должно было показать.

Хотя подобные ситуации в продакшене считаются багами, в proof of concept они багами не являются. Помните, это просто черновик, а не готовый чертёж.

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

Во второй раз всегда получается лучше

Век живи — век учись. Практикуйся. В следующий раз повезёт.

Что общего у всех этих фраз?

Они подразумевают, что чем больше вы чем-то занимаетесь, тем лучше будут результаты.

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

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

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

Воспринимайте POC как поучительный урок. Проиллюстрируйте идею и научитесь кодировать концепцию. Найдите все подводные камни. Будьте готовы, что потом найдёте новые. Приготовьтесь к созданию более качественного ПО.

Заключение

Proof of concept всегда стоит потраченного на него времени. Даже если результат докажет, что вам не стоит использовать проверяемую концепцию, по крайней мере, вы не потратили на выяснение этого много времени.

POC дают нам шанс поэкспериментировать с чем-то новым и взвесить свои решения перед тем, как приступать к реализации. Но они не являются реализацией. Хотя иногда может возникать искушение встроить этот код в приложение в продакшене, не стоит этого делать.

Используйте proof of concept как отправную точку. Пользуйтесь его уроками как руководством, чтобы создать нечто лучшее. Ужесточите требования к тому, что вы сделали. А потом начинайте новую итерацию.

Не распыляйтесь при создании сборок POC. Создавайте их как можно быстрее. Тратьте максимально возможное время на работу над реальным ПО, обладающим безопасностью, устойчивостью к сбоям и надлежащей обработкой ошибок.

На правах рекламы

Серверы для разработчиков и не только! Недорогие VDS на базе новейших процессоров AMD EPYC и хранилища на основе NVMe дисков от Intel для размещения проектов любой сложности, создавайте собственную конфигурацию сервера в пару кликов!

Источник

Публикация PoC-кода дает злоумышленникам фору в 47 дней

Раннее раскрытие PoC-кода может помочь сообществу ИБ-экспертов и подтолкнуть разработчиков ПО быстрее выпустить исправления.

Исследователи из компании Kenna Security объединились со специалистами из Cyentia Institute и провели анализ 473 уязвимостей, обнаруженных начиная с 2019 года, эксплуатация которых была зафиксирована в реальных атаках Эксперты предупредили, что когда PoC-код для эксплуатации уязвимости публикуется в открытом доступе, злоумышленники получают 47-дневную фору для осуществления своих целей.

В течение 15 месяцев команда исследователей собирала данные о том, когда была обнаружена та или иная уязвимость, когда был зарезервирован и получен идентификатор CVE, когда был выпущен патч, а также информацию о первом случае обнаружения уязвимости соответствующими сканнерами и эксплуатации уязвимости злоумышленниками. По результатам исследования, PoC-код для эксплуатации уязвимости публиковался в открытом доступе примерно в одном из четырех (24%) случаев, и большинству эксплуатаций CVE (70%) предшествовала публикация PoC-кода.

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

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

Хорошей новостью является то, что процессы ответственного раскрытия информации об уязвимостях работают достаточно хорошо. Около 60% уязвимостей исправляются до официальной публикации CVE, а в течение нескольких дней после публикации CVE этот показатель увеличивается до 80%.

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

Источник

Best practices для клиент-серверного проекта PoC

Типичный клиент-серверный проект PoC (Proof of Concept) для веба состоит из клиента с GUI, сервера c бизнес логикой и API между ними. Также используется база данных, хранящая оперативную информацию и данные пользователей. Во многих случаях необходима связь с внешними системами со своим API.

Когда у меня возникла необходимость в создании проекта PoC, и я начал разбираться в деталях, то оказалось, что порог вхождения в веб-программирование весьма высок. В крупных проектах для каждого компонента есть выделенные специалисты: front-end, back-end разработчики, UX/UI дизайнеры, архитекторы баз данных, специалисты по API и информационной безопасности, системные администраторы. В небольшом PoC надо самому во всем разобраться, выбрать подходящее техническое решение, реализовать и развернуть. Ситуацию ухудшает тот факт, что из обучающих материалов не всегда понятно, почему предлагается сделать именно так, а не иначе, есть ли альтернативы, является ли решение best practice или это частное мнение автора. Поэтому я разработал заготовку под названием «Common Test DB», отвечающую лучшим практикам. Ее можно использовать для начала любого проекта, остается только наполнить функциональным смыслом.

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

Требования к проекту PoC

Начнем с минимальных требований к проекту PoC. В статье «Блокчейн: что нам стоит PoC построить?» я уже рассматривал из каких частей состоит универсальная информационная система. В этой статье подробно разберем состав типичного проекта PoC. Даже минимальный проект в клиент-серверной архитектуре требует значительной функциональности и технической проработки:

Технологический стек

Далее разберем подробно все требования к PoC. Начнем с сервера.

Сервер

HTTP сервер

В качестве HTTP сервера я пробовал два варианта:

HTTPS запросы

Говоря про HTTP, я всегда подразумеваю HTTPS, т.к. без него крайне сложно построить безопасное взаимодействие между клиентом и сервером. Для поддержки HTTPS надо:

Для организации работы HTTPS протокола нужен SSL сертификат. Существуют бесплатные сертификаты Let’s Encrypt, но солидные сайты получают платные сертификаты от доверительных центров сертификации CA (Certificate Authority). Для наших тестовых целей на локальном хосте достаточно, так называемого, self-signed certificate. Он генерируется с помощью утилиты openssl:

Далее отвечаем на несколько вопросов про страну, город, имя, email и т.п. В результате получаем два файла:

С Express сервером все достаточно просто, можно взять стандартный пакет HTTPS из Node.js, и использовать официальную инструкцию: How to create an https server?

После реализации HTTPS сервера используем полученные файлы server.key и server.crt и стандартный для HTTPS порт 443.

Взаимодействие с внешними системами

Самая известная библиотека для реализации HTTP/HTTPS запросов: Axios. Она используется как в сервере для вызова API внешних систем, так и в клиенте для вызова API сервера. Есть еще варианты библиотек, которые можно использовать для специфичных целей: Обзор пяти HTTP-библиотек для веб-разработки.

Взаимодействие с базой данных

Для работы с базой данных я использовал самую популярную библиотеку для Node.js: Sequelize. В ней мне больше всего нравится то, что переключиться между различными типами баз данных можно всего лишь изменив несколько настроечных параметров. При условии, конечно, что в самом коде не используется специфика определенной базы. Например, чтобы переключиться с SQLight на PostgreSQL, надо в конфигурационном файле сервера заменить:

И при необходимости изменить имя базы, пользователя и хост.

В PoC я использовал базу данных SQLite, которая не требует установки. Для администрирования баз данных есть хорошо развитые GUI:

Безопасность доступа к данным

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

Существуют несколько моделей контроля доступа к данным. Помимо Discretionary Access Control (DAC) OWASP рекомендует (Access Control Cheat Sheet) использовать следующие:

Безопасность вызовов API

В моей предыдущей статье я рассматривал все возможные угрозы: Безопасность REST API от А до ПИ. В PoC реализованы следующие механизмы:

Для защиты от угроз, перечисленных далее, я использовал пакет helmet, который позволяет задать значения для определенных HTTP заголовков:

Защита от DoS

Необходимо защитить сервер и от отказа в обслуживании (DoS-атаки). Например, ограничить число запросов от одного пользователя или по одному ресурсу в течении определенного времени.

Для Node.js существуют средства, позволяющие автоматически реализовывать ограничения на число запросов и сразу посылать ответ «429 Too Many Requests», не нагружая бизнес логику сервера.

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

Безопасность конфигурационных параметров

Настройки для клиента и сервера хранятся в файлах config в JSON формате. Чувствительные настройки сервера нельзя хранить в config файлах, т.к. они могут стать доступны в системах версионного контроля. Для такой информации как: логины/пароли для базы данных, ключи доступа к API и т.д. надо использовать специализированные механизмы:

Логирование

Стандартные требования к логированию:

Мониторинг

Мы не будем останавливаться на внешних система мониторинга: Обзор систем мониторинга серверов, т.к. они начинают играть важную роль не на этапе PoC, а в промышленной эксплуатации.
Обратимся к внутренним системам, которые позволяют наглядно посмотреть, что сейчас происходит с сервером, например пакет express-status-monitor. Если его установить, то по endpoint

можно наглядно мониторить простейшие параметры работы сервера, такие как загрузка CPU, потребление памяти, http нагрузку и т.п. Приведу скриншот из нашего примера. На скриншоте горит красная плашка Failed и может показаться, что что-то не так. Но, на самом деле, все в порядке, т.к. вызов API сознательно делается на несуществующий endpoint:

База данных

Структура базы данных

В нашем примере реализованы две таблицы с говорящими именами:

Еще одна особенность нашей схемы в том, что один столбец таблицы Data задан в формате JSON. Такой формат удобно использовать, если внешняя система возвращает данные в JSON. В этом случае можно просто записать полученные данные, не тратя усилия на парсинг, а потом делать SQL запросы, используя расширенный синтаксис. Описание работы со столбцами JSON можно найти в официальной документации баз данных. В качестве независимого описания мне понравилась статья на Хабре, в которой описаны все варианты запросов: «JSONB запросы в PostgreSQL.

Cхема таблицы Users:

Начальные значения

Клиент

HTTPS запросы

Для безопасной передачи информации клиент использует HTTPS протокол. Для запросов используется та же библиотека, что и на сервере для вызова API внешних систем: Axios.

RESTful API

REST API лучше реализовывать, используя стандартные средства, чтобы было проще тестировать и документировать, например SwaggerHub
Наше REST API сформировано по правилам Open API и использует стандартные HTTP методы для манипуляции объектами из таблиц Users и Data. В схеме нашего API не все сделано по чистым правилам REST, но главное соблюдена общая концепция.

Хорошей практикой является ограничение объёма возвращаемых данных. Для этого используются параметры в запросе: фильтр (filter), ограничение (limit) и смещение (offset). В примере этого нет, но в промышленных системах эта функциональность должна быть реализована. Но даже если реализованы ограничивающие механизмы на клиенте, должна осуществляться дополнительная проверка на сервере на максимальные значения. В нашем примере в конфигурации сервера реализован ограничитель на максимальное число возвращаемых строк из базы, который подставляется в SELECT запросы: limit: 1000

Интересная возможность — встроить Swagger прямо в сервер, далее подложить ему YAML, реализующий API и по endpoint:

получить стандартную Swagger панель управления и осуществлять тестирование и просмотр документации. Скриншот Swagger, встроенного в наш сервер:

GraphQL

Существуют и альтернативы REST API, например GraphQL. Данный стандарт разработан Facebook и позволяет избавиться от недостатков REST:

Регистрация, аутентификация и авторизация пользователей

Если приложение доступно из Интернета, то в форме регистрации имеет смысл использовать функциональность reCaptсha от Google для защиты от ботов и DoS атак. В нашем примере я использую пакет vue-recaptcha.

Для использования reCaptсha нужно на сайте Google зарегистрировать приложение, получить sitekey и прописать его в настройках клиента. После этого на форме появится, известный всем, вопрос про робота:

В примере реализована регистрация пользователей с помощью логина/пароля и с использованием Google Account.

Далее в статье разберем практическую реализацию.

Аутентификация по логину/паролю (Basic Authentication)

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

Раскодируем его открытыми средствами. Например самый простой способ загрузить на сайт https://jwt.io.

Мы видим, что информация, помещенная в JWT не зашифрована, а только подписана ключом сервера и туда нельзя помещать чувствительные к разглашению данные!

Аутентификация с помощью Google Account (Token-Based Authentication)

Тут посложнее, поэтому нарисую диаграмму:

1. Пользователь заходит на GUI PoC, выбирает “Login with Google».

2. Клиент запрашивает у сервера SessionId и настройки Google. Настройки надо предварительно получить с сайта Google, например, по инструкции из моей статьи: Современные стандарты идентификации: OAuth 2.0, OpenID Connect, WebAuthn.

3. Клиент сохраняет SessionId в sessionStorage браузера.

4. Из браузера формируется GET запрос на Google Authorization Server (красная стрелка). Для понимания алгоритма, надо обратить внимание, что ответ на этот запрос браузер получит от Google только в самом конце call flow на шаге 13 и это будет 307 (Redirect).

Формат GET запроса:

6. Пользователь вводит свои логин/пароль от Google аккаунта.

7. Google проверяет пользователя и делает GET запрос на адрес Callback с результатом аутентификации, “Authorization Code” в параметре code и нашем SessionId в параметре state:

11. Проверяем, что email пользователя существует, или создаём нового пользователя c email из токена. При этом SessionId и полученные от Google токены сохраняются в базе.

12. Только теперь отвечаем Google HTTP кодом 307 (Redirect) и заголовком Location c адресом на клиенте:

13. И только теперь Google отвечает браузеру с тем же кодом 307 (Redirect) и заголовком Location с заданным нами адресом

14. Браузер переходит на адрес, указанный в Location и клиент определяет, что произошла успешная аутентификация пользователя с помощью Google аккаунта

15. Клиент, по сохраненному в sessionStorage SessionId, получает на сервере токен и данные пользователя

16. Клиент сохраняет токен в localStorage браузера

На этом процедура аутентификации с помощью Google аккаунта завершена и можно переходить к штатной работе приложения.

Прием, обработка и визуализация данных

Сделаем стандартный вид приложения, как рекомендует Google:

Для создания новых данных используется простая форма ввода:

Архитектура

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

Заключение

Остается только в канун Нового Года пожелать, чтобы сбылись все ваши самые заветные PoC!

Источник

Proof of Concept: Как проверить, что внедрение ML стоит свеч

Недавно в уютном чатике дата сатанистов подняли вопрос, как правильно «продавать» внутренние проекты по машинному обучению. Оказалось, что многие из нас весьма брезгливо относятся к экономическому обоснованию своей деятельности. Меж тем, чтобы провести минимальную оценку рентабельности проекта, никакого MBA не нужно — в небольшой статье (10 страниц текста, ке-ке-ке) я расскажу вам, что такое рентабельность инвестиций, как оценить её для внутреннего проекта, какую роль в этом играет Proof of Concept, и почему в реальной жизни всё может пойти не так. Делать мы всё это будем вокруг вымышленного проекта по автоматизации составления расписаний для колл-центра. Добро пожаловать под кат!

Наш вымышленный проект

В колл-центре работает 100 операторов. Они работают по плавающему расписанию, выходя на работу сменами по 8 или 12 часов. Смены начинаются в разное время и расставлены так, чтобы обеспечивать дежурство множества людей в часы пик и малого количества людей в холодные часы по ночам и выходным. Расписание планирует дежурный супервайзер колл-центра темными пятничными вечерами, на глазок планируя нагрузку на следующую неделю.

Один 8-часовой день работы оператора колл-центра стоит компании 2.000 руб. Если считать, что в году 250 рабочих дней, то колл-центр обходится компании в 100 х 2.000 х 250 = 50 млн руб в год. Если мы автоматизируем составление расписания, мы сможем прогнозировать почасовую нагрузку и расставлять смены так, чтобы варьировать число дежурных операторов в зависимости от прогнозной нагрузки. Если наш прогноз и расстановка смен окажется хотя бы на 10% лучше, чем прогноз и расстановка супервайзера, получится экономия аж 5 млн руб. в год. Если нам действительно удастся выжать 10% улучшения, проект однозначно окупится. Или нет. Давайте подумаем, как вообще принимать такие решения.

Как считают ROI

Прежде, чем начинать большой проект, неплохо бы оценить его экономическую целесообразность. Хрестоматийный способ сделать это — посчитать возврат на инвестиции, ROI.

ROI (Return on Investment) — это показатель доходности проекта, равный отношению доходов к затраченным инвестициям. ROI ¯\_(ツ)_/¯ ). Картинка оттуда же — на ней пример прогноза нагрузки.

Для начала, нам удалось предсказывать почасовую нагрузку с WAPE = 14%. Удалось достичь ошибки меньше 10% на 43% часов, меньше 20% на 70% часов.
Вообще, это очень неплохо — мы достаточно точно ловим и суточные колебания, и недельные циклы, и среднесрочные тренды. Обжигаемся только на случайных флуктуациях, и, скорее всего, избежать их не удастся.

По нагрузке мы сможем легко вычислить число операторов, которые должны быть в смене в данный час. Мы написали жадный неоптимальный алгоритм планировщика смен и вычислили, что что нам удается сэкономить 10% смен на прогнозной нагрузке. При этом оказалось, что если мы в дополнение к 12-часовым сменам введем 8-часовые и умно расставим их по суткам, можем сэкономить еще 5%.

Переводим показатели в деньги. Текущая стоимость годового содержания колл-центра — 50 млн руб в год. Наш эксперимент показал, что мы можем уменьшить эту сумму на 15%, что приведет к экономии до 7,5 млн руб в год, а за весь срок жизни — до 22,5 млн руб.

Это очень хороший эффект, и так и хочется признать PoC успешным. Давайте, однако, задержимся и проанализируем, что может пойти не так.

Риски, влияющие на экономический эффект

Мы получили положительный эффект за счет сокращения числа сотрудников. Число сотрудников мы смогли сократить за счет сокращения числа смен. Число смен мы смогли сократить за счет перераспределения их по предсказанной нагрузке. Нагрузку мы смогли предсказывать с помощью моделирования на основе исторических данных.

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

Во-вторых, мы предсказали нагрузку достаточно точно, но, тем не менее, в 30% случаев ошибаемся больше, чем на 20%. Может оказаться, что такая ошибка в час пик приводит к недопустимому росту длительности ожидания. Супервайзеры примут решение закладывать резервные смены для покрытия рисков.

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

Итого, нам нужно заложить резервные смены в часы пик и поддерживать немного «балласта» в тихие недели. А кроме того, нам нужно будет заложить расходы на поддержание модели.
Настало время поговорить о расходах и рисках, с ними связанных.

Разработка и сопровождение, их стоимость и риски

По ходу проведения PoC нам стало понятно, что нужно делать для промышленной реализации решения.

Во-первых, нужно выстроить стабильно работающий процесс сбора данных. Оказалось, что мы достаточно легко можем получать данные из CRM. Однако, данные о расписании операторов мы были вынуждены собирать по крупицам. Значит, нам придется сначала сделать автоматизированную систему контроля расписаний операторов. Удачное совпадение, что результаты планирования мы тоже будем выгружать в эту систему. Мы оценили, что на разработку выгрузки из CRM у нас уйдет неделя-две. Разработка системы для управления расписанием потребует месяца два, и есть риск, что мы ошиблись в оценке в разы.

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

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

Просуммируем расходы в оптимистичном, реалистичном и пессимистичном вариантах.

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

Оптимистичный — 5 дней на CRM, 40 дней на систему управления расписанием, 5 дней на прогнозирование, 10 дней на составление расписаний, 5 дней на инфраструктуру, 3х12х0,5 дней на ее поддержку, и 2х3 дней на редкие дообучения модели. Итого 65 рабочих дня на разработку, 24 дня на поддержку. Итоговая стоимость решения — 1,3 млн руб на разработку + 0,48 млн руб на поддержку за 3 года.

Реалистичный — 10 + 60 + 10 + 20 + 10 + 3х12х1 + 5х3 = 110 разработки и 51 поддержки, 2,2 + 1,02 млн руб.

Пессимистичный — это когда все пошло не так. 20 + 80 + 20 + 40 + 10 + 3х12х2 + 5х5 = 170 разработки и 97 поддержки, 3,4 + 1,94 млн руб.

Отметим, что около 40% стоимости уходит на поддержку, как ни крути.

Оценка ROI и целесообразности проекта

При оптимистичной оценке мы получали 15% экономию на рабочей силе, что приводило нас к экономии 22,5 млн руб за срок жизни проекта, из которых 7,5 млн руб сваливалось на нас в первый год. Оптимистичная оценка расходов показывала всего 1,3 + 0,48 млн руб, что дает +6,2 млн (+377% ROI) в первый год и +21 млн руб (+1160% ROI) за время жизни. Божественно.

Однако, если реализуется хотя бы часть рисков, ситуация изменится. Если окажется, что на часы пик выпадает 50% смен, и мы захотим поддерживать 10%-ный резерв, мы тут же потеряем 5% эффекта. Еще 2,5% расходов на неэластичность штата — и вот мы потеряли в сумме 7,5% из 15% эффекта. Получаем всего 3,75 млн руб доходов в год, 11,25 млн за срок жизни. Это реалистичная оценка доходов.

Вычтем из этого расходы по реалистичной оценке — 2,2 млн на разработку и 1,02 на поддержку. Получим +55% ROI в первый год, +252% за срок жизни. Результат все равно достойный, но вывод о внедрении выглядит уже не таким однозначным.

Теперь давайте перестрахуемся и добавим 20%-ный резерв в часы пик. Мы потеряли еще 5% эффекта, осталось всего 2,5% сокращения расходов, или 1,25 млн в год, 3,75 млн за срок жизни. Это пессимистичная оценка эффекта, но эффект всё ещё хотя бы есть. Теперь при реалистичной оценке расходов проект не окупается в первый год, и только на горизонте в 3 года немного выходит в +17% ROI. Кажется, положить деньги на депозит выглядит надёжнее. Таким образом, при реалистичной оценке доходов и расходов мы уже не можем себе позволить 20%-ную перестраховку.

При реализации пессимистичного сценария разработки расходы составят 3,4 млн руб в первый год. Приемлемый ROI +121% мы получим только в самом радужном случае. На горизонте 3х лет также окупится с +108% ROI «средний» по доходам сценарий.

Таким образом, видно, что реалистично ждать от проекта ROI +55% в первый год и +252% за все время жизни, однако, мы будем вынуждены сильно ограничивать себя в резервах. И если мы не уверены в компетенциях собственной разработки, то проект лучше вообще не начинать.

P.S. Делать свое или купить готовое

Живой менеджер изучил бы альтернативные решения еще до внедрения PoC, но у нас же умозрительный проект, да? К тому же, про сторонние закрытые решения статью не напишешь.

Для начала, есть очень важный стоп фактор — каким будет исход разработки, сильно зависит от компетенций компании. Если компания не уверена в своих разработчиках и DS’ах, вероятность пессимистичного исхода слишком велика. В этом случае нужно однозначно использовать решение от вендора. Просто исходя из этого соображения, просто по этому пути идут все нетехнологические компании. Технологические компании отличаются тем, что сила их команды даёт шансы на оптимистичный исход. Вот тут начинается математика.

Решения от вендоров биллятся, исходя из стоимости аренды рабочего места. По нашей «реалистичной» оценке дохода в 7,5%, мы экономим на одном рабочем месте 37,5 тыс. руб в год. Это и есть максимальная стоимость решения. Если решение стоит дешевле — оно принесет положительный ROI. С собственной разработкой все сложнее — окупаемость зависит от числа операторов. За первый год положительный ROI возможен при расходах на операторов в 26,66 млн в год, что достигается при 53 операторах. За три года положительный ROI начинается от 27 операторов.

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

Источник