Мы запустили каналы проекта QS: Спецодежда —
«Охрана труда: автоматизация и спецодежда».
Будем делиться:
— практикой учета спецодежды и внедрений
— подходами к автоматизации в охране труда
— кейсами и наблюдениями с проектов
— обновлениями продукта и планами развития
Если вам близка тема охраны труда и автоматизации — подписывайтесь.
Если знаете, кому это может быть интересно — рекомендуйте.
Telegram: https://t.me/qs_specodezhda
Max: https://max.ru/id7810524703_biz
«Охрана труда: автоматизация и спецодежда».
Будем делиться:
— практикой учета спецодежды и внедрений
— подходами к автоматизации в охране труда
— кейсами и наблюдениями с проектов
— обновлениями продукта и планами развития
Если вам близка тема охраны труда и автоматизации — подписывайтесь.
Если знаете, кому это может быть интересно — рекомендуйте.
Telegram: https://t.me/qs_specodezhda
Max: https://max.ru/id7810524703_biz
Немного новостей по проекту Ямщик.
В конце прошлого месяца запустили модуль ответственного хранения. Это отдельное направление бизнеса — помимо логистики, Ямщик оказывает услуги хранения и выдачи продукции на своем складе в Липецке.
Сценарий простой: клиент размещает товар на складе, хранит его там до нужного момента, а дальше продукцию с терминала чаще всего забирает уже заказчик клиента. То есть клиенту Ямщика не нужно самому организовывать склад, выдачу и отдельную работу с конечными получателями. При необходимости доставку может выполнить и логистическое подразделение Ямщика.
С точки зрения разработки, это почти отдельная система. Модуль встроен в общую вебку, но реализован обособленно — со своей базой данных. Связан только с оплатами и выставлением счетов (1С / Юкасса). За счет этого его проще поддерживать и развивать, не трогая остальную часть системы.
Что уже сделали:
— Договоры ответственного хранения
Настройка тарифов: стоимость хранения палета в день, услуги приемки и выдачи.
— Учет движений
Приемка, выдача, текущее состояние по договору.
— Баланс хранения
Система считает, сколько палет хранится на каждый день.
— Дополнительные услуги
Разовые работы вроде палетирования.
— Выставление счетов
Автоматический расчет за период: хранение по дням, приемки, выдачи. Через календарик можно визуально контролировать, за какие дни счет уже выставлен, а за какие еще нет.
Счет формируется и отправляется в основной блок Ямщика с возможностью передачи в 1С или Юкассу.
— Документы
Формирование М-1 на приемку и выдачу.
Блок реализован полностью нашим новым программистом Гулаковым Матвеем.
#Разработка #Ямщик
В конце прошлого месяца запустили модуль ответственного хранения. Это отдельное направление бизнеса — помимо логистики, Ямщик оказывает услуги хранения и выдачи продукции на своем складе в Липецке.
Сценарий простой: клиент размещает товар на складе, хранит его там до нужного момента, а дальше продукцию с терминала чаще всего забирает уже заказчик клиента. То есть клиенту Ямщика не нужно самому организовывать склад, выдачу и отдельную работу с конечными получателями. При необходимости доставку может выполнить и логистическое подразделение Ямщика.
С точки зрения разработки, это почти отдельная система. Модуль встроен в общую вебку, но реализован обособленно — со своей базой данных. Связан только с оплатами и выставлением счетов (1С / Юкасса). За счет этого его проще поддерживать и развивать, не трогая остальную часть системы.
Что уже сделали:
— Договоры ответственного хранения
Настройка тарифов: стоимость хранения палета в день, услуги приемки и выдачи.
— Учет движений
Приемка, выдача, текущее состояние по договору.
— Баланс хранения
Система считает, сколько палет хранится на каждый день.
— Дополнительные услуги
Разовые работы вроде палетирования.
— Выставление счетов
Автоматический расчет за период: хранение по дням, приемки, выдачи. Через календарик можно визуально контролировать, за какие дни счет уже выставлен, а за какие еще нет.
Счет формируется и отправляется в основной блок Ямщика с возможностью передачи в 1С или Юкассу.
— Документы
Формирование М-1 на приемку и выдачу.
Блок реализован полностью нашим новым программистом Гулаковым Матвеем.
#Разработка #Ямщик
🔥5
Итоги апреля 2026
В апреле команды «Качественных решений» продолжили развитие ключевых продуктов и инфраструктурных направлений. Коротко о главных результатах месяца.
QS Спецодежда
В апреле команда активно развивала функциональность, которую долго откладывали из-за приоритетов внедрений и поддержки.
За месяц:
* продолжилось развитие заявок на закупку и коллективную выдачу;
* стартовала работа над справочником ЕТН;
* улучшена мобильная версия системы;
* возобновлена работа над гостевым фондом, подменными выдачами и остановочным ремонтом — функциональностью, которую клиенты давно ожидали;
* запущены новые каналы коммуникации проекта: email-рассылки, Max и Telegram;
* начат процесс регистрации QS Спецодежды в реестре отечественного ПО.
* началась разработка облачной панели управления для нескольких баз QS Спецодежды («торпеды»): уже реализованы сводные графики показателей и анализ отзывов с использованием GigaChat; подробнее об этом направлении расскажем отдельно.
Ямщик
Продолжается развитие логистической платформы «Ямщик».
В апреле команда внедрила модуль ответственного хранения. Ранее об этом проекте мы уже рассказывали отдельной новостью.
Инфраструктура разработки
Внутри отдела разработки начался переход части сервисов на контейнерную инфраструктуру.
Помимо внедрения Docker, команда перерабатывает архитектуру отдельных служб: например, начался вынос хранения видео в S3-совместимое хранилище. Также были переведены первые сервисы и внедрены новые подходы к публикации и защите внутренних систем.
Об этом направлении расскажем подробнее отдельно.
Хорошие админы
Команда системного администрирования продолжила развитие инфраструктурных сервисов для клиентов и внутренних проектов.
В апреле:
* продолжилось развитие VPN-сервисов и резервных схем защищенного обмена данными между филиалами;
* была стабилизирована инфраструктура хранения данных на базе Ceph и внедрен мониторинг кластера;
* организован дополнительный контроль автоматизации маркетплейсов: дежурные администраторы ежедневно проверяют корректность выполнения процессов и оперативно разбирают сбои.
Компания продолжает развивать продукты, инфраструктуру и сервисные направления, постепенно закрывая задачи, которые долгое время оставались в отложенном статусе.
В апреле команды «Качественных решений» продолжили развитие ключевых продуктов и инфраструктурных направлений. Коротко о главных результатах месяца.
QS Спецодежда
В апреле команда активно развивала функциональность, которую долго откладывали из-за приоритетов внедрений и поддержки.
За месяц:
* продолжилось развитие заявок на закупку и коллективную выдачу;
* стартовала работа над справочником ЕТН;
* улучшена мобильная версия системы;
* возобновлена работа над гостевым фондом, подменными выдачами и остановочным ремонтом — функциональностью, которую клиенты давно ожидали;
* запущены новые каналы коммуникации проекта: email-рассылки, Max и Telegram;
* начат процесс регистрации QS Спецодежды в реестре отечественного ПО.
* началась разработка облачной панели управления для нескольких баз QS Спецодежды («торпеды»): уже реализованы сводные графики показателей и анализ отзывов с использованием GigaChat; подробнее об этом направлении расскажем отдельно.
Ямщик
Продолжается развитие логистической платформы «Ямщик».
В апреле команда внедрила модуль ответственного хранения. Ранее об этом проекте мы уже рассказывали отдельной новостью.
Инфраструктура разработки
Внутри отдела разработки начался переход части сервисов на контейнерную инфраструктуру.
Помимо внедрения Docker, команда перерабатывает архитектуру отдельных служб: например, начался вынос хранения видео в S3-совместимое хранилище. Также были переведены первые сервисы и внедрены новые подходы к публикации и защите внутренних систем.
Об этом направлении расскажем подробнее отдельно.
Хорошие админы
Команда системного администрирования продолжила развитие инфраструктурных сервисов для клиентов и внутренних проектов.
В апреле:
* продолжилось развитие VPN-сервисов и резервных схем защищенного обмена данными между филиалами;
* была стабилизирована инфраструктура хранения данных на базе Ceph и внедрен мониторинг кластера;
* организован дополнительный контроль автоматизации маркетплейсов: дежурные администраторы ежедневно проверяют корректность выполнения процессов и оперативно разбирают сбои.
Компания продолжает развивать продукты, инфраструктуру и сервисные направления, постепенно закрывая задачи, которые долгое время оставались в отложенном статусе.
Запустили отдельный промо-сайт для «Хороших админов» — https://промо.хорошиеадмины.рф
Как показала практика, основной сайт админов нам самим очень нравится, но для рекламы он работал не очень хорошо. Поэтому решили сделать отдельную площадку именно под продвижение, тестирование новых идей и услуг.
Там можно быстрее экспериментировать с подачей, проверять гипотезы и смотреть на реакцию посетителей.
Постепенно будем добавлять новые направления, кейсы и пробовать разные рекламные подходы.
#Сайт #Админы
Как показала практика, основной сайт админов нам самим очень нравится, но для рекламы он работал не очень хорошо. Поэтому решили сделать отдельную площадку именно под продвижение, тестирование новых идей и услуг.
Там можно быстрее экспериментировать с подачей, проверять гипотезы и смотреть на реакцию посетителей.
Постепенно будем добавлять новые направления, кейсы и пробовать разные рекламные подходы.
#Сайт #Админы
❤4
Немного истории про Docker в нашей компании.
На самом деле Docker мы используем уже очень давно, просто долгое время это было скорее инфраструктурным инструментом для админов, а не инструментарием для отдела разработки. Точную дату уже даже сложно вспомнить, но массово применять контейнеры начали примерно в районе 2020 года, когда у нас появились XWiki и другие службы инфраструктуры на Linux.
Docker тогда отлично решал простую задачу — развертывание софта со сложными зависимостями. У многих продуктов это вообще рекомендуемый способ установки: скачал контейнер, запустил и не думаешь о том, установлена ли в системе Java или PHP нужной версии.
Потом контейнеры постепенно начали проникать и в разработку.
Например, еще с 2021 года в QS: Спецодежда все SQL-миграции начали тестироваться перед релизом. Мы проверяем что:
— скрипты обновления не содержат ошибок и могут применяться к базе;
— пользователь сможет обновиться даже с самой первой версии программы;
— схема базы после обновления полностью совпадает со схемой чистой установки текущей версии.
В какой-то момент (2022 год) стало понятно, что тестировать это надо сразу на разных версиях MariaDB и MySQL, потому что различия в синтаксисе все же встречаются.
И вот тут Docker оказался очень удобным решением. Мы поднимали нужные версии баз в контейнерах на тестовом сервере и прогоняли полный набор проверок. На тот момент полный цикл тестов занимал больше двух часов. Но сами контейнеры уже были заранее развернуты на тестовом сервере и просто запускались или останавливались по необходимости.
Позже (уже 2025) контейнеры начали использовать и для визуального тестирования. На проекте Ямщик почти год назад через Docker поднимались контейнеры с приложением и Selenium-браузером для автоматического прогона UI-тестов.
Примерно тогда же пришли к мысли, что для тестов из C# кода тоже можно поднимать контейнеры с базами, тем самым значительно подняв актуальность тестов. Потому что наши основные тесты служб долгое время работали на SQLite в памяти. Это создавало проблемы: часть ошибок просто не воспроизводилась, а часть тестов была усеяна различными хаками из-за отличий синтаксиса SQLite от MySQL/MariaDB. При том что у нас большая часть тестов служб по сути интеграционные, потому что основная логика так или иначе завязана на базу данных.
В итоге постепенно перевели тесты служб на контейнеры с MariaDB и даже MongoDB, а заодно переписали и старые тесты SQL-скриптов на использование контейнеров прямо на тестируемой машинке — будь это рабочее место разработчика или сборочный сервер Jenkins. Для тестов поднимался контейнер, в нем разворачивалась база данных и прогонялись тесты.
Более того, это впоследствии позволило запускать пачки тестов параллельно по 10 штук, что сократило время тестирования в разы. В результате тестирование стало не только ближе к реальному продакшену, но и заметно быстрее — полный прогон сократился примерно с двух часов до 10-13 минут.
#Разработка #Docker
На самом деле Docker мы используем уже очень давно, просто долгое время это было скорее инфраструктурным инструментом для админов, а не инструментарием для отдела разработки. Точную дату уже даже сложно вспомнить, но массово применять контейнеры начали примерно в районе 2020 года, когда у нас появились XWiki и другие службы инфраструктуры на Linux.
Docker тогда отлично решал простую задачу — развертывание софта со сложными зависимостями. У многих продуктов это вообще рекомендуемый способ установки: скачал контейнер, запустил и не думаешь о том, установлена ли в системе Java или PHP нужной версии.
Потом контейнеры постепенно начали проникать и в разработку.
Например, еще с 2021 года в QS: Спецодежда все SQL-миграции начали тестироваться перед релизом. Мы проверяем что:
— скрипты обновления не содержат ошибок и могут применяться к базе;
— пользователь сможет обновиться даже с самой первой версии программы;
— схема базы после обновления полностью совпадает со схемой чистой установки текущей версии.
В какой-то момент (2022 год) стало понятно, что тестировать это надо сразу на разных версиях MariaDB и MySQL, потому что различия в синтаксисе все же встречаются.
И вот тут Docker оказался очень удобным решением. Мы поднимали нужные версии баз в контейнерах на тестовом сервере и прогоняли полный набор проверок. На тот момент полный цикл тестов занимал больше двух часов. Но сами контейнеры уже были заранее развернуты на тестовом сервере и просто запускались или останавливались по необходимости.
Позже (уже 2025) контейнеры начали использовать и для визуального тестирования. На проекте Ямщик почти год назад через Docker поднимались контейнеры с приложением и Selenium-браузером для автоматического прогона UI-тестов.
Примерно тогда же пришли к мысли, что для тестов из C# кода тоже можно поднимать контейнеры с базами, тем самым значительно подняв актуальность тестов. Потому что наши основные тесты служб долгое время работали на SQLite в памяти. Это создавало проблемы: часть ошибок просто не воспроизводилась, а часть тестов была усеяна различными хаками из-за отличий синтаксиса SQLite от MySQL/MariaDB. При том что у нас большая часть тестов служб по сути интеграционные, потому что основная логика так или иначе завязана на базу данных.
В итоге постепенно перевели тесты служб на контейнеры с MariaDB и даже MongoDB, а заодно переписали и старые тесты SQL-скриптов на использование контейнеров прямо на тестируемой машинке — будь это рабочее место разработчика или сборочный сервер Jenkins. Для тестов поднимался контейнер, в нем разворачивалась база данных и прогонялись тесты.
Более того, это впоследствии позволило запускать пачки тестов параллельно по 10 штук, что сократило время тестирования в разы. В результате тестирование стало не только ближе к реальному продакшену, но и заметно быстрее — полный прогон сократился примерно с двух часов до 10-13 минут.
#Разработка #Docker
❤1
Но при этом до полноценного использования Docker в продакшене для развертывания служб мы тогда еще не дошли.
Хотя предложения «давайте уже использовать Docker для деплоя» в команде звучали давно 🙂 И я долго отбивался от этого. Потому что это объективно еще один слой абстракции, дополнительная конфигурация и усложнение инфраструктуры.
И на тот момент я не очень понимал, что конкретно мы от этого выиграем. Кроме аргумента «сейчас так модно» 🙂
Тем более что деплой у нас и так уже был почти полностью автоматизирован через Jenkins-скрипты. Большая часть наших служб написана на .NET — поставил один раз runtime на сервер и забыл. С зависимостями проблем почти не было.
Из ручной работы в основном оставалась настройка reverse proxy (Apache/Nginx), получение сертификатов Let's Encrypt и перенос конфигурации при миграции служб между серверами.
А служб у нас к сегодняшнему моменту набралось уже около 25. И это именно наши Endpoint-ы и сервисы, без учета различных cron-скриптов и стороннего софта.
Когда службы начали все чаще переезжать между серверами — из-за балансировки нагрузки, перехода на .NET 8 и других инфраструктурных задач — стало понятно, что ручная настройка proxy и сертификатов начинает напрягать все сильнее.
А тут еще и новый программист пришел из мира микросервисов 🙂 Плюс у админов появились задачи задачи, где так или иначе приходится поддерживать клиентские Docker Swarm-кластеры. И дополнительный опыт не помешает.
В общем, все постепенно сошлось в одной точке, и стало понятно — пора.
Но про то, как именно мы сейчас перевозим службы в Docker и что из этого получилось, расскажем уже в следующих постах 🙂
#Разработка #Docker
Хотя предложения «давайте уже использовать Docker для деплоя» в команде звучали давно 🙂 И я долго отбивался от этого. Потому что это объективно еще один слой абстракции, дополнительная конфигурация и усложнение инфраструктуры.
И на тот момент я не очень понимал, что конкретно мы от этого выиграем. Кроме аргумента «сейчас так модно» 🙂
Тем более что деплой у нас и так уже был почти полностью автоматизирован через Jenkins-скрипты. Большая часть наших служб написана на .NET — поставил один раз runtime на сервер и забыл. С зависимостями проблем почти не было.
Из ручной работы в основном оставалась настройка reverse proxy (Apache/Nginx), получение сертификатов Let's Encrypt и перенос конфигурации при миграции служб между серверами.
А служб у нас к сегодняшнему моменту набралось уже около 25. И это именно наши Endpoint-ы и сервисы, без учета различных cron-скриптов и стороннего софта.
Когда службы начали все чаще переезжать между серверами — из-за балансировки нагрузки, перехода на .NET 8 и других инфраструктурных задач — стало понятно, что ручная настройка proxy и сертификатов начинает напрягать все сильнее.
А тут еще и новый программист пришел из мира микросервисов 🙂 Плюс у админов появились задачи задачи, где так или иначе приходится поддерживать клиентские Docker Swarm-кластеры. И дополнительный опыт не помешает.
В общем, все постепенно сошлось в одной точке, и стало понятно — пора.
Но про то, как именно мы сейчас перевозим службы в Docker и что из этого получилось, расскажем уже в следующих постах 🙂
#Разработка #Docker
👍4❤1🔥1
В прошлом посте рассказывал, как Docker постепенно появился в нашей разработке. Но использовать его для развертывания служб мы долго не спешили.
Когда все же решили переходить, поставили себе несколько практических целей:
— перенос службы на новый сервер должен сводиться к изменению одной строчки в Jenkins или Swarm-файле;
— новый сервер должен подготавливаться максимально просто: поставил Docker и готово;
— в случае аварии перенос службы на другую машину должен занимать не часы и не дни, а около 10–15 минут, пока обновляются DNS записи;
— в будущем должна появиться возможность перейти на Docker Swarm и попробовать онлайн-отказоустойчивость.
При аварийном переносе обычно съедают настройки, конфигурация, сертификаты, файлы и прочие "мелочи", про которые вспоминаешь только когда сервер уже лежит. Мы хотели чтобы аварийный перенос ничем не отличался от обычного деплоя. По сути остается только дождаться обновления DNS.
Первой задачей стало сделать службы полностью stateless.
Адреса баз данных, пароли, токены и прочие настройки принципиально никогда не хранились в коде. Обычно они лежали в
На некоторых проектах мы уже пробовали хранить конфигурацию в Git и просто выкладывать нужные файлы на сервер. Практика оказалась удобной: есть история изменений, ревизии, откаты. Поэтому решили не создавать еще одну точку отказа в виде отдельного хранилища конфигураций и продолжить использовать Git.
Рассматривали вариант хранить настройки прямо внутри контейнера вместе с приложением. Но тогда для смены пароля к базе пришлось бы пересобирать контейнер и заново его публиковать.
В итоге остановились на варианте с передачей конфигурации через Docker композ файл. Так многие настройки можно менять без пересборки приложения.
Следующей проблемой оказались файлы в локальной файловой системе.
Например, Ямщик хранил фотографии и аватарки в папках на сервере. Служба постоматов сохраняла видео сдачи спецодежды тоже в локальных файлах.
При переезде службы на другой сервер все это превращалось бы в отдельную задачу. Поэтому службы переписали на использование S3. Благо такая инфраструктура у нас уже давно была развернута.
Параллельно начали всплывать архитектурные особенности.
Например, сервис отправки электронной почты исторически находился внутри службы мобильного приложения. Хотя фактически уже использовался множеством других систем. Логично было выделить его в отдельную службу.
То же самое касается задач по расписанию. Если завтра служба будет запущена в нескольких экземплярах, такие процессы начнут выполняться одновременно на всех нодах. Поэтому подобные вещи заранее планируем выносить в отдельные сервисы.
Отдельно пришлось решать вопрос логирования.
Раньше службы работали через systemd. При отправке сообщения об ошибке можно было просто прочитать последние строки журнала и приложить их к отчету.
После переезда в Docker эта схема перестала работать. Более того, во время первых экспериментов со Swarm стало понятно, что стандартного docker logs нам тоже не хватит.
В итоге появился собственный логер, который держит последние 300 строк в памяти и может отправить их вместе с сообщением об ошибке на сервер.
На текущий момент из примерно 25 наших служб в Docker уже переведены 7. Остальные продолжают переезжать.
В следующем посте расскажем уже про взгляд со стороны администрирования: Traefik, registry, автоматическое получение сертификатов и то, что в итоге получилось у нас вместо классической схемы с Nginx на каждом сервере.
#Разработка #Docker
Когда все же решили переходить, поставили себе несколько практических целей:
— перенос службы на новый сервер должен сводиться к изменению одной строчки в Jenkins или Swarm-файле;
— новый сервер должен подготавливаться максимально просто: поставил Docker и готово;
— в случае аварии перенос службы на другую машину должен занимать не часы и не дни, а около 10–15 минут, пока обновляются DNS записи;
— в будущем должна появиться возможность перейти на Docker Swarm и попробовать онлайн-отказоустойчивость.
При аварийном переносе обычно съедают настройки, конфигурация, сертификаты, файлы и прочие "мелочи", про которые вспоминаешь только когда сервер уже лежит. Мы хотели чтобы аварийный перенос ничем не отличался от обычного деплоя. По сути остается только дождаться обновления DNS.
Первой задачей стало сделать службы полностью stateless.
Адреса баз данных, пароли, токены и прочие настройки принципиально никогда не хранились в коде. Обычно они лежали в
/etc на сервере. Но если служба должна легко переезжать между серверами, хранить конфигурацию на конкретной машине уже нельзя.На некоторых проектах мы уже пробовали хранить конфигурацию в Git и просто выкладывать нужные файлы на сервер. Практика оказалась удобной: есть история изменений, ревизии, откаты. Поэтому решили не создавать еще одну точку отказа в виде отдельного хранилища конфигураций и продолжить использовать Git.
Рассматривали вариант хранить настройки прямо внутри контейнера вместе с приложением. Но тогда для смены пароля к базе пришлось бы пересобирать контейнер и заново его публиковать.
В итоге остановились на варианте с передачей конфигурации через Docker композ файл. Так многие настройки можно менять без пересборки приложения.
Следующей проблемой оказались файлы в локальной файловой системе.
Например, Ямщик хранил фотографии и аватарки в папках на сервере. Служба постоматов сохраняла видео сдачи спецодежды тоже в локальных файлах.
При переезде службы на другой сервер все это превращалось бы в отдельную задачу. Поэтому службы переписали на использование S3. Благо такая инфраструктура у нас уже давно была развернута.
Параллельно начали всплывать архитектурные особенности.
Например, сервис отправки электронной почты исторически находился внутри службы мобильного приложения. Хотя фактически уже использовался множеством других систем. Логично было выделить его в отдельную службу.
То же самое касается задач по расписанию. Если завтра служба будет запущена в нескольких экземплярах, такие процессы начнут выполняться одновременно на всех нодах. Поэтому подобные вещи заранее планируем выносить в отдельные сервисы.
Отдельно пришлось решать вопрос логирования.
Раньше службы работали через systemd. При отправке сообщения об ошибке можно было просто прочитать последние строки журнала и приложить их к отчету.
После переезда в Docker эта схема перестала работать. Более того, во время первых экспериментов со Swarm стало понятно, что стандартного docker logs нам тоже не хватит.
В итоге появился собственный логер, который держит последние 300 строк в памяти и может отправить их вместе с сообщением об ошибке на сервер.
На текущий момент из примерно 25 наших служб в Docker уже переведены 7. Остальные продолжают переезжать.
В следующем посте расскажем уже про взгляд со стороны администрирования: Traefik, registry, автоматическое получение сертификатов и то, что в итоге получилось у нас вместо классической схемы с Nginx на каждом сервере.
#Разработка #Docker
👍1