IT-аутсорсинг — удалённая работа в Москве

Системное администрирование. Настройка сервера, Масштабирование бота. Оборудование: Облако. Сервер: базы данных, прокси-сервер. Техническое задание: Инфраструктура для Telegram-бота 🎯 Цель проекта Разработка отказоустойчивой, масштабируемой и сопровождаемой инфраструктуры для Telegram-бота. Требуется продумать и реализовать архитектуру, которая поддерживает: * высокую нагрузку (в перспективе — десятки тысяч пользователей); * масштабирование на несколько нод/серверов; * балансировку нагрузки; * автоматическое обновление кода и схемы базы данных. Также при разработке архитектуры важно учесть, что бот активно выполняет сложные SQL-запросы с JOIN-ами, фильтрацией, агрегацией, вставкой и обновлением данных. Необходимо обеспечить возможность горизонтального масштабирования — запуск нескольких копий бота на разных серверах с общей базой данных. Инфраструктура должна быть развернута в одном из российских облачных провайдеров (VK Cloud, Selectel, Timeweb Cloud или аналог), на виртуальных Linux-серверах. Выбор конкретного провайдера остаётся за исполнителем, однако при прочих равных предпочтение должно отдаваться наиболее бюджетному решению. Требуется настроить репликацию базы данных, балансировку нагрузки, кеширование запросов, а также автоматическое обновление кода и схемы базы при пуше в основную ветку репозитория (CI/CD). Все решения должны быть реализованы на бесплатных и открытых технологиях. Использование Kubernetes не предполагается, так как считается избыточным и затратным для задач данного масштаба. Однако, если исполнитель сможет обосновать, что применение Kubernetes или его минимального окружения даст более простое, устойчивое и экономичное решение — такой вариант может быть рассмотрен. ------------------------------------------------------------------------------------------------------------------ 🧰 Что есть на входе На текущем этапе исходный код Telegram-бота отсутствует — мы ожидаем, что разработчик самостоятельно реализует тестового mock-бота на Python, эмулирующего активную работу с базой данных (любая Open Source СУБД, поддерживающая SQL-запросы — PostgreSQL, ClickHouse и др., на ваш выбор, но с архитектурным обоснованием её необходимости), в частности с большим количеством джойнов (для демонстации достаточно и 3+ таблиц) Основные характеристики этого бота: * интенсивное взаимодействие с базой: частые JOIN, INSERT, UPDATE, DELETE; * сложные SQL-запросы с агрегациями, фильтрацией, группировками; * обновление, вставка, удаление и прочие манипуляции с данными в базе — как можно быстрее, но в пределах 30 минут (NRT допустимо); * база должна быть реплицируемой и поддерживать масштабирование; * выполнение сложных запросов — максимально эффективно (под нагрузкой); * всё взаимодействие с БД должно быть асинхронным (если это возможно на выбранной технологии); * требуется полноценная поддержка Flyway для управления схемой базы: создание базы, таблиц, миграции, обновления. * бот необходим для взаимодействия пользователей с магазинами и товарами. Предполагаем наличие следующих таблиц: юзеры, логи юзеров, магазины, товары, свойства товаров, покупки юзеров, баллы юзеров, задания, типы заданий, ответы юзеров Ожидается, что инфраструктура будет построена в соответствии с остальными требованиями ТЗ: масштабирование, отказоустойчивость, CI/CD, безопасность и документация (подробнее ниже) ------------------------------------------------------------------------------------------------------------------ ✅ Что ожидается от кандидата - Опыт настройки PostgreSQL/GreenPlum/ClickHouse с репликацией и масштабированием; - Опыт настройки CI/CD; - Знание Python, PgBouncer, HAProxy, Docker, K8s, Redis; - Умение документировать шаги; - Готовность работать с mock-кодом без доступа к реальному проекту; - Умение читать SQL и понимать async-запросы; - Ответственность, самостоятельность, надёжность. - Открытость к обсуждениям, своевременная обратная связь и прозрачное информирование заказчика о ходе работ. 🛠 Что требуется 1. Реализация Mock-ового телеграм бота - написание на python + python-telegram-bot 2. Масштабирование - Развернуть PostgreSQL (или расширение: Citus, Patroni и пр.); - Настроить репликацию (streaming, logical и т.п.); - Обеспечить горизонтальное масштабирование (возможность запуска бота на нескольких нодах); - Обеспечить совместимость с Flyway-механизмом миграций (добавление новых миграций должно применяться поверх старых); - Исполнитель предоставляет обоснование выбранного решения для масштабирования PostgreSQL, раскрывая причины выбора конкретного инструмента или расширения, а также преимущества этого подхода с точки зрения отказоустойчивости, производительности, стоимости и удобства поддержки по сравнению с альтернативами. - В случае убедительного обоснования исполнитель может предложить использование альтернативных технологий (например, GreenPlum, ClickHouse или других), если это будет целесообразно для поставленных задач. 2. Балансировка и отказоустойчивость - PgBouncer или аналог — для пула соединений; - HAProxy или аналог — для балансировки трафика между нодами и репликами; - Поддержка отказоустойчивости: отключение одной ноды не нарушает работу всей системы; - Демонстрация восстановлений и переключений вручную или автоматически. 3 Обновление кода Telegram-бота - Возможность обновления кода на всех нодах: - через `git pull + restart`; - либо другим способом, который не прерывает работу всей системы; - Обновление одной ноды не должно мешать остальным; - Данные в базе при обновлении должны сохраняться. 4. CI/CD: auto-deploy при пуше - Настроить CI/CD для автоматического обновления при `git push` в `master`: - обновление кода Telegram-бота; - запуск Flyway миграций; - перезапуск службы бота; - Можно использовать GitHub Actions, GitLab CI, Ansible, rsync и т.п.; - Предоставить `.yml`-конфигурацию + пошаговую инструкцию по настройке. 5. Безопасность - Настроить безопасные роли PostgreSQL (readonly, writer, admin); - Минимизация открытых портов; - Ограничения по IP через конфигурацию `pg_hba.conf`; - Настройка параметров сети в `postgresql.conf` (например, `listen_addresses` и `port`); - Настройка базового firewall (например, UFW) для ограничения доступа к нужным портам. - Желательно обеспечить шифрование трафика между компонентами (PostgreSQL, Redis, бот и пр.) для защиты данных в передаче. 6. Снижение нагрузки - Настроить кеш (Redis или аналог) с TTL и политикой очистки; - По необходимости — использовать materialized views или рекомендации по оптимизации схемы; - Все решения должны поддерживать асинхронную работу (совместимость с `asyncpg`). --- 🧪 Тестирование - отключение одной из нод и проверка устойчивости и продолжения работы системы; - обновление кода должно поддерживать возможность поочерёдного обновления нод; - успешное применение миграций схемы базы данных через Flyway; - масштабирование системы: добавление новой ноды и проверка её интеграции и работы; - восстановление данных после аварийного отключения или перезапуска ноды; - нагрузочное тестирование для подтверждения производительности и масштабируемости системы; - проверка отказоустойчивости компонентов балансировки (PgBouncer, HAProxy); - проверка безопасности: доступ по ролям, ограничение по IP, корректность настроек firewall; - проверка CI/CD пайплайна: успешный деплой кода и миграций без остановки всей системы; - прочие тесты --- 📄 Документация - README + отдельные инструкции: - установка и запуск инфраструктуры; - добавление новых нод; - обновление кода; - миграции; - управление PgBouncer, HAProxy; - структура и использование кеша; - CI/CD: как работает, как добавить новую машину; - Язык изложения — простой, с пояснениями, примерами команд, скриншотами (по возможности); - Пояснение всех переменных `.env`, конфигураций и ключевых команд. --- 📦 Стек и ограничения - Допустимо использовать **Docker и docker-compose**, если это помогает упростить запуск и обслуживание; - Все решения должны быть **бесплатными и open source**; - Развёртывание на **виртуальных Linux-серверах в российских облаках** (например: VK Cloud, Selectel, Timeweb); - Все действия должны быть воспроизводимы вручную или с помощью скриптов и подробно описаны в документации. --- 📋 Приёмка - Полная передача всех материалов: скрипты, миграции, конфигурации, инструкции; - Демонстрация работоспособности системы на 2+ нодах (репликация, масштабирование, кеш, миграции, CI/CD); - Проверка отказоустойчивости (отключение одного из компонентов не останавливает систему); - Проверка корректной работы кеширования и механизма обновления кода; - **Разработчик отказывается от авторских прав** на результат: весь код, инструкции, конфигурации передаются заказчику без ограничений; - **Финальная приёмка производится после демонстрации работы системы и передачи всех материалов**,а также успешного прохождения заказчиком самостоятельной проверки по предоставленным инструкциям: - установка с нуля, - добавление ноды, - обновление кода, - применение миграции, - прохождение базовых тестов; - Приёмка подтверждается обеими сторонами после верификации результата и устранения возможных недочётов. --- 💰 Оплата - Предпочтительный вариант оплаты — через безопасную сделку - Либо иной способ оплаты — по договорённости сторон; - Ожидается оценка сроков и стоимости по этапам от исполнителя. 🧭 Рекомендуемый план разработки и тестирования Ожидается, что разработка и проверка решения будут организованы поэтапно, с учётом лучших практик инфраструктурной сборки. Ниже описан предпочтительный порядок действий, которого желательно придерживаться: 🔹 Этап 1: Локальная сборка - Первичная сборка и отладка инфраструктуры производится на локальной машине исполнителя с использованием `docker-compose`; - Все ключевые компоненты (бот, PostgreSQL, PgBouncer, Redis, Flyway) разворачиваются и тестируются в контейнерах; - Отрабатываются сценарии отказоустойчивости, масштабирования, миграции и кеширования; - Подготавливается структура каталогов, конфигураций и `.env`. 🔹 Этап 2: Настройка CI/CD - Реализуется автоматизация деплоя (например, через GitHub Actions или GitLab CI): - Обновление кода; - Применение миграций; - Перезапуск сервисов; - Проверяется цепочка обновления на тестовом сервере (в Docker или вручную). 🔹 Этап 3: Развёртывание в облаке - Исполнитель может начать тестирование на бесплатных облаках или промо-сервисах (например, пробные аккаунты VK Cloud, Timeweb Cloud, Selectel); - Если этих ресурсов недостаточно — исполнитель формирует краткий запрос к заказчику с предложением: - сколько виртуальных машин потребуется (и с какими параметрами); - на какой срок; - почему выбран конкретный провайдер; - Заказчик рассматривает этот запрос и принимает решение об аренде тестовых ресурсов, исходя из бюджета и целесообразности; - Все тестовые серверы должны быть подобраны с учётом минимальных расходов, без избыточных конфигураций; - Развёртывание производится вручную на 2 и более нодах; - Проверяется: - отказоустойчивость; - масштабирование; - взаимодействие компонентов (Redis, PgBouncer, координатор/воркеры); - полноценный запуск CI/CD; - Оценивается воспроизводимость развёртывания на новой машине по инструкции. 🔹 Этап 4: Передача и проверка заказчиком - Исполнитель предоставляет полные инструкции по воспроизведению среды на стороне заказчика; - Заказчик самостоятельно разворачивает систему по инструкции, обновляет код, применяет миграции и добавляет ноды; - Финальная приёмка проводится только после успешной самостоятельной верификации всех компонентов и сценариев.