Есть такой многим известный ретро-автобус с интегрированными бутылками, про который у меня было уже много постов: ЛиАЗ-677 . В частности, впервые в интернетах был подробно разобран принцип работы люминесцентного освещения в нём, которое почти никогда не работало. Как итог, теперь из оставшихся автобусов с работающим освещением - как бы не большинство, что радует :)

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

Как либо классифицировать эту коробку вряд ли получится: она одна такая, плод работы сумрачного советского гения, настоящий "аналоговнет" родом из 1960-х. Передач у неё 3... с половиной:

1) пониженная "первая", движение вперёд

2) прямая "вторая", движение вперёд

2.5) прямая "вторая" с заблокированным гидротрансформатором: коробка просто механически соединяет входной и выходной карданы (да, карданов у этого автобуса два, т.к. коробка расположена отдельно от двигателя), движение вперёд

3) задняя пониженная

Блокировка гидротрансформатора происходит чисто механически, электрика в ней не участвует, поэтому в рамках этого поста мы этот механизм рассматривать не будем.

Все эти передачи, кроме упомянутой выше блокировки, переключает электрика (этакий прообраз роботизированной коробки), а управляются переключения с пульта под рулём. Для 60-х годов, в которых среди коробок передач почти безраздельно царствовала механика с "палкой", это был настоящий "космос".

Вся электрика управления коробкой доступна через люк в салоне напротив передней пассажирской двери:

Теперь рассмотрим электрическую схему управления ГМП поподробнее. Хотел вставить сюда схему из официального мануала к автобусу, но в ней куча ошибок, поэтому просто нарисую её заново:

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

Положение "Н" селектора тоже имеет свой контакт и посылает сигнал "разрешения" запуска электростартера, т.е. если селектор стоит "на скорости", автоматика не даст крутить электростартером (это, к сожалению, не касается "кривого" стартера, и были случаи, что автобус давил водителя, который забыл селектор "на скорости" и заводил автобус "с кривого").

Основной режим работы ГМП - положение "А", т.е. автомат. В этом положении питание с селектора подаётся на концевик переключения скоростей, расположенный на ГМП:

Концевик имеет два положения и переключается центробежным регулятором, который давит на его шток. Пока автобус не разогнался или вообще стоит на месте, центробежный регулятор не давит на шток концевика, концевик питает соленоид первой, пониженной передачи. Как только автобус достаточно разогнался, центробежный регулятор начинает давить на шток концевика, переключая его во второе положение. Соленоид второй передачи запитан не напрямую от этого концевика, а через ещё один концевик, "концевик наката", который отключается, если отпустить педаль газа. Таким образом, если отпустить педаль газа на 2-й передаче, то коробка сама переключается в нейтраль, пока педаль газа не будет нажата снова, или пока автобус не замедлится, переключившись на 1-ю передачу. Этот функционал позволяет экономить топливо, но его можно отключить при помощи отдельного тумблера на селекторе ГМП.

Режим "ПП" (принудительная 1-я передача) реализован просто: соленоид 1-й передачи питается напрямую от этого контакта, в обход концевика переключения скоростей. Таким образом, коробка, что бы не случилось, всегда будет стоять на 1-й передаче, никогда не переключаясь на вторую. Этот режим был реализован для того, чтобы автобусу было легче подниматься в горку.

Ну и осталось разобрать, каким образом заставить автобус ехать назад. С задним ходом тут есть свои особенности: реверс включает чисто механический редуктор, который переключается между положениями вперёд/назад воздухом при помощи поршня, ну а воздух в нужный момент подаёт электроклапан. (Я же сказал, что гений был сумрачным :) Но работало, блин!)

Для того, чтобы начать движение назад, первым делом нужно переключить механку коробки в положение "движение назад". Для этого селектор ГМП переводится в положение "●". В этом положении питание подаётся на соленоид с клапаном, который подаёт воздух из пневмосистемы автобуса в поршень, собственно, втыкающий заднюю передачу.

Т.к. процесс "втыкания" реверса далеко не мгновенный (особенно в зимнее время, когда смазка весьма густая) то преждевременное трогание с места грозит тем, что механика не успеет войти в зацепление, и мы её просто перемелем. Чтобы этого избежать, на поршне включения задней передачи установлен концевик, включающий лампу индикации "задний ход включён" на селекторе ГМП, как только поршень будет "вставлен" до конца. Вместе с этой лампой включаются и задние ходовые огни на корме автобуса.

Несмотря на то, что механика у нас переключена в "движение назад", на положении селектора "●" мы никуда поехать не сможем, т.к. перед механикой у нас стоит гидротрансформатор, который всё ещё в нейтрали. Поэтому как только загорается индикатор заднего хода на селекторе ГМП, его нужно перевести в положение "ЗХ", из которого уже можно трогаться назад.

Электрически положение "ЗХ" представляет собой комбинацию положения "●" и положения "ПП". Т.е. гидротрансформатор будет ехать вперёд всегда на 1-й скорости (разгоняться до 2-й при движении назад не рекомендуется :) ), а механика будет крутить колёса "назад".

С принципом работы разобрались, это было такое слегка затянувшееся вступление к посту. А теперь к сути дела. Электрически все три соленоида (звать их РС-328, не путать с такими же по виду РС-330) представляют собой нехилую такую индуктивность:

А что это значит? Это значит, что при отключении данного соленоида от питания, в нём возникнет нехилая такая ЭДС в силу явления самоиндукции. Напряжение на коммутирующих данный соленоид контактах в момент их разрыва будет достигать сотен вольт, что неизбежно зажжёт дугу, которая постепенно будет уничтожать контакты. Коммутация в цепях ГМП при движении автобуса происходит часто, что, со временем, изнашивает концевики переключения скоростей, наката и, что самое печальное, контактную группу селектора ГМП, который является весьма дефицитным в наше время изделием.

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

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

Дополнительно в схему снаббера добавлены предохранитель (чтобы не случилась КоЗа в цепях ГМП, если диод вдруг выйдет из строя) и светодиодный индикатор включения соленоида.

В итоге вся эта идея оформилась вот в такие симпатичные чОрные коробочки, напечатанные на 3D принтере из пластика PETG:

После установки снабберов искрение на контактах практически отсутствует, а значит, дефицитные запчасти прослужат гораздо дольше, чем предполагал изготовитель :)

Про эту всю эпопею я дополнительно снял два видеоролика:

1) видео про конструкцию снаббера:

2) и видео про испытания опытных образцов на автобусе ЛиАЗ-677МБ компании "МосРетроТранс" по имени "Помидор":

Испытания завершились полностью успешно, и теперь снабберы для цепей ГМП автобуса ЛиАЗ-677 - это уже изделие мелкосерийное.

Всем спасибо за внимание, надеюсь, утомил не сильно.

Пикабу познавательный :)

Ну и поделимся всеми исходниками, конечно. Если вам не терпится посмотреть, то вот исходники, а вот что получилось.

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

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

❯ Чему мы хотели научиться

Я два года работаю в IT (Fullstack: Django, Go, Vue) и по работе мне приходилось сталкиваться с разными технологиями, но я ни разу не писал сервисы полностью, всегда уже были готовые проекты, в которых нужно было что-то дорабатывать. Также у меня есть брат, который вообще не имел опыта в IT, но хотел научиться программировать (с уклоном в Django).

Чтобы приобрести больше уверенности в вопросах создания сервисов, мы решили сделать проект с нуля. Брату хотелось понять как создавать backend на Django, работать с базами данных, а также разбираться с асинхронными задачами, ну а мне было интересно создать PWA на Vue3, научиться работать с картами, набить шишек на DevOps и в целом разработать сервис полностью.

❯ Как выбирали проект

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

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

В то время все закончилось на том, что мы фотографировали нарушения на OpenCamera, после чего я загружал снимки в QGIS и скриптом извлекал данные из EXIF-тегов, осуществлял обратное геокодирование, заполняя слой. Оставалось разобраться с распознаванием автомобильных номеров и разработать функционал формирования документов (запросов/протоколов/писем), но в связи со сменой места работы, работа над проектом была остановлена.

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

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

Чтобы привлечь нарушителя к ответственности, вам необходимо:

1. Зафиксировать факт нарушения, время и место его совершения;

2. Понять кто уполномочен принимать заявления по конкретному типу нарушений на данной территории;

3. Составить заявление с учетом всех юридических тонкостей;

4. Отправить заявление в уполномоченный орган и дождаться ответа.

Вроде бы для гражданина все просто, но на практике все оказалось сложнее. Многие считают что все нарушения правил парковки относятся к полномочиям МВД (ГИБДД/ГАИ), но на самом деле это не так.

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

Кто-то из таких комиссий принимает заявления по электронной почте, у кого-то работает СЭД и есть форма для обращений на сайте, кто-то использует ПОС Госуслуг, ну а некоторые поддерживают сразу несколько способов обращения, либо вовсе принимают заявления только на бумаге...

Обращение в МВД (ГИБДД/ГАИ) — это вообще отдельная история. При разработке их формы обращения, программисты сделали все для того, чтобы граждане вообще не обращались к ним. Например, в форме обращения, «для борьбы со спамом», отключена возможность использования буфера обмена, а максимальный размер вложений в 30Мб является по сути запретом на отправку видео.

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

При отправке обращений через ПОС Госуслуг есть также решения «для борьбы со спамом», о чем напишем чуть ниже.

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

Мы решили создать сервис, который позволит горожанам «в один клик» фиксировать факт правонарушения, а все остальные аспекты взять на себя.

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

❯ Какую задачу решает проект

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

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

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

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

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

На данный момент мы обзвонили не все стоянки, но результат уже достоин внимания: из 17 стоянок по которым мы уже получили данные, только на одной стоянке нет мест, а на остальных — 40-60% свободно! С гаражами ситуация примерно такая же: по данным председателей кооперативов, 30-40% гаражей в городе — брошены и практически не используются.

Причины, которые нам видятся основными:

• во дворе ставить «выгодней» (от предупреждения до 5000 руб. штрафа раз в 1-2 года против 1200-1600 рублей в месяц за стоянку);

• до стоянки или гаража нужно ходить, а «мы привыкли от двери до двери на авто, это же удобно, 21-й век!»;

• низкий шанс получения наказания: за 2023 год, согласно отчетам, на весь город ~300 админ. протоколов (и это не только по парковке);

• нет общественного порицания: люди либо считают это нормой, либо просто молчат;

• нехватка кадров в муниципалитете, чтобы фиксировать большое количество нарушений по всему городу. В Балаково это 27 человек, уполномоченных составлять протоколы (помимо основных обязанностей) на тысячи нарушений;

• отсутствие полноценной информационной работы. Зачастую власти не способны напрямую говорить горькую правду жителям.

В рамках проекта «ХрюХрюКар» мы постарались охватить все описанные выше проблемы.

Посмотреть 12 примеров того, с чем борется ХХК можно ниже:

❯ Что получилось в результате

Карта нарушений:

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

Также на карте есть слой с автомобильными стоянками. Зеленым цветом обозначены стоянки, на которых есть места, а синим — те, куда мы еще не позвонили. Красным цветом отображена стоянка, на которой нет мест. По стоянкам также можно кликать, чтобы посмотреть подробные сведения.

Фиксация нарушений:

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

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

Модерация и отправка заявлений:

Пользователю с правами модератора (членство в группе Moderator), а также суперюзеру доступна консоль модерации. Модераторы не получают в очередь модерации фотографии, авторами которых они являются. Суперюзеры — могут модерировать любые материалы.

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

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

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

Для удобства модератора, в консоли мы связали карту с Google Street View, чтобы было проще геолоцировать фото.

Если с модератором связан заявитель, то у него доступен последний шаг степпера — генерация и отправка заявления.

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

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

Рендеринг заявлений производится с использованием встроенного в Django шаблонизатора.

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

После подтверждения заявления, производится его отправка в уполномоченный орган, все также в фоновой задаче celery.

По состоянию на 05/01/2024 у нас реализована автоматическая отправка только по электронной почте, что покрывает ~90% всех нарушений, которые нам присылают через ХрюХрюКар. Отправка в ГИБДД ведется почти в ручном режиме.

У нас есть простейший скрипт на JS, в который мы подставляем текст заявления из панели администратора Django и, перейдя на форму для подачи обращений уполномоченного органа, выполняем этот код в консоли браузера, чтобы заполнить все поля формы. Далее остается прикрепить файл заявления, подтвердить почту и отправить заявление.

Также мы пробовали осуществлять отправку заявлений через ПОС Госуслуг и нас удивили их методы по «борьбе со спамом». Разработчик из непонятных соображений также запретил использование буфера обмена для пользователя и установил следующие ограничения на количество обращений, направляемых через ПОС: не более одного обращения в час и не более двух в сутки.

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

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

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

Почему именно расширение?

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

❯ Общие результаты в моменте

За 4,5 месяца мы направили 742 заявления, 28 материалов находится на модерации. Сейчас мы получаем в среднем по 10-20 материалов в день и стараемся около 20-и заявлений в день направлять.

Примерно 90% материалов — нарушения, выражающиеся в размещении автомобиля на зелёной зоне (направляются в администрацию БМР), около 9% — стоянка на тротуаре в нарушение ПДД (полномочия отдела ГИБДД МУ МВД «Балаковское»), 1% делят стоянка на месте для инвалидов, автобусных остановках и пешеходных переходах.

За это время на сайте авторизовалось 277 пользователей, из которых:

• 62 присылали одно и более нарушений, в том числе;

• 17 присылали более десяти нарушений, в том числе;

• 9 присылали более двадцати нарушений, в том числе;

• 6 присылали более пятидесяти нарушений, в том числе;

• 4 присылали более ста нарушений.

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

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

За все время работы к нам зашли 5027 уникальных посетителей ~21000 раз. Основные пики посещаемости после таких вот постов (1, 2) в местной группе автомобильной направленности. Люди находят сайт в Яндексе или нашу группу в ВК и уже от туда приходят на сайт, где ищут свои машины.

Мы оперативно получаем положительные ответы от администрации и не очень оперативно — от МВД. Все ответы стараемся выкладывать в группе, но по мере появления свободного времени. Сейчас на почте ждут обработки 53 ответа от администрации и 3 от ГИБДД, это ~250-350 административных производств (администрация в одном ответе отвечает сразу на несколько наших заявлений).

Минус в том, что мы не получаем входящих номеров от администрации (да и не запрашиваем, если честно), поэтому конкретно связать каждый ответ с конкретным заявлением сейчас не представляется возможным.

Из дополнительных источников метрик следует отметить официальные публикации администрации: 1, 2, 3, 4, 5, 6.

Также нами проводится работа с органами власти всех уровней с целью внедрения в Балаково официального приложения на базе ПАК «Помощник Москвы». Это программное решение имеет статус средства, работающего в автоматическом режиме, что позволяет исключить бюрократию в виде административных производств (штрафы будут приходить через несколько дней прямиком на Госуслуги).

Процесс не быстрый, но мы будем стараться добиться такого внедрения у нас, благо куратор проекта в лице ЦОДД Москвы оказался очень адекватным и на первое же наше письмо ответил приглашением на ВКС, где нам изложили все детали и дали рекомендации для внедрения ПАК ПМ в регионах.

❯ Какие технологии мы использовали

Более подробно о технологиях можно почитать тут.

Облачные вычисления и сервисы:

1. TimeWeb Cloud — для всех вычислений (сервер БД, сервер бэкенда, сервер фронтенда, сервер почты).

2. Yandex.Cloud — S3-хранилище для фотографий, заявлений и иллюстраций к типам нарушений.

3. Google Street View API — для просмотра точного местоположения фотографии на панорамах при модерации.

4. OSM — для обратного геокодирования.

5. Yandex.Forms — для форм обратной связи: 1, 2, 3, 4.

Деплоим все это скриптами (1, 2, 3). Хотелось бы прикрутить Kubernetes и GitLab CI/CD, но пока не хватает времени и опыта.

❯ Что требует доработки

1. Камера. На некоторых устройствах (например, на iPhone Pro Max 11) камера не работает. Также наблюдаются проблемы с камерой в следующих браузерах: Яндекс, Samsung Internet, MIUI. Мы понимаем что проблема в некорректном коде компонента камеры, но у нас пока не хватило опыта её исправить. Исправляем работу камеры на одном типе устройств — все ломается на другом. Если есть опыт работы с камерой,будем благодарны за помощь.

2. Несвободная лицензия MDB Vue в редакции Pro. Из-за отсутствия в команде дизайнера, нам пришлось подбирать UI-библиотеку. На этом этапе была допущена ошибка и из-за невнимательности при ознакомлении с лицензией мы не заметили тот факт, что лицензия MDB Vue Pro запрещает распространять под открытой лицензией проект с исходным кодом самой библиотеки MDB Vue Pro. Поэтому мы опубликовали варианты выхода из этой ситуации. Если вкратце, то можно написать несколько компонентов самостоятельно, удалить ненужные несвободные компоненты или вовсе использовать ХХК без фронтенда (например для написания ТГ-бота такой же направленности, как и ХХК).

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

4. DevOps. На данный момент у нас нет CI/CD, Kubernetes, да и в целом есть масса замечаний по деплою. Например, у нас для каждой реплики бэкенда, поднимается свой контейнер с Celery в связке с Redis, что не очень хорошо. Также у нас нет автоматического масштабирования, что в перспективе может привести к проблемам с производительностью. Ну и есть масса замечаний к порядку развертывания. Например, при сборке для staging/production, статика фронта собирается в таком порядке:

   1. Скрипт готовит папки на хосте перед запуском сборки;

   2. Запускается контейнер для сборки статики Django;

   3. Запускается контейнер для сборки статики фронта ХХК и фронта карты стоянок;

   4. Уже после завершения работы трех контейнеров сборки, запускается контейнер с nginx, куда примонтированы директории с собранной статикой.

      По-хорошему, нужно производить сборку backend, frontend, parkings_frontend, а потом уже при сборке Nginx копировать нужные директории/файлы из полученных образов.

      Если есть опыт работы с Kubernetes и GitLab CI/CD, будем рады помощи.

5. Консоль модератора. Необходимы доработки в консоли модератора, а именно: фильтрация, сортировка, поиск.

6. Local-first. На данный момент у нас нет возможности работать при плохом канале связи на стороне клиента. Необходимо реализовать возможность работы с ХХК в режиме, близком к offline. Для этого необходимо переработать часть стора, чтобы он работал с IndexedDB, а также реализовать синхронизацию данных с сервером, не забывая про контроль за временем создания снимков (временем на устройстве), чтобы избежать подлогов (нужен «камертон», работающий через веб-сокеты).

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

8. Исправление логики импорта исходных данных. Сейчас все территории и базовые типы нарушений/полномочия и т.д. у нас импортируются в миграции, это неправильно. Во-первых, не всем нужны эти данные, а во-вторых, после импорта территорий производится их привязка друг к другу, которая из-за не оптимизированного кода и большого объема данных, требует для выполнения минимум 8Гб оперативной памяти и ~10 минут времени. Этот код писался на самом раннем этапе и мы тогда еще не знали про фикстуры и management-команды. Надо будет всю эту логику перенести в management-команду, чтобы она загружала из фикстур заранее подготовленные данные и импортировала их в базу, при необходимости загружая нужные картинки в S3-бакет.

9. Журналирование. Сейчас журналы пишутся в stdout контейнеров и, по сути, хранятся в огромном JSON-файле в одной из директорий docker-compose.Также мы настроили конфиги так, чтобы Nginx и Django их сохраняли еще и в папки, смонтированные на хост.

10. Мониторинг. Сейчас у нас помимо обычного хелсчека, на который стучится Traefik, чтобы определить жив ли контейнер при проксировании запросов,в файле с хелсчеками лежат представления, которые по сути не являются хелсчеками. На эти представления изредка заходит Uptime Kuma, чтобы мы в Телеграмме получали алерты если ресурсы хоста на исходе или что-то не так с бизнес-процессами (не уходит почта, выходят сроки модерации материалов, пользователь или модератор производят много отклоненных материалов). Все это по сути является метриками и необходимо это все, скажем, с использованием Prometheus, передавать на некие дашборды и от туда уже слать алерты.

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

12. Stateless. Сейчас у нас Stateful-архитектура. В частности, когда пользователь присылает фотографию нарушения, мы ее помимо S3, кладем в папку, примонтированную к хосту. После того как запрос успешно выполнился, запускаются фоновые задачи в контейнерах Celery. Одна из таких задач подбирает этот файл из той же папки, делает сжатую копию и стучится в Nomeroff, чтобы распознать номера. Контейнер Nomeroff ходит в ту же папку. В самом конце задачи, файл удаляется. Все это нам уже не очень нравится с архитектурной точки зрения.

13. Тестирование. Сейчас в проекте ровно 0 тестов. По-хорошему нужны не только юнит-тесты, но и нормальные интеграционные тесты.Также мы пока не научились производить нагрузочное тестирование, поэтому на все вычисления (на все серверы) у нас в сумме задействовано 10vCPU и 18Гб памяти, что требует ~7000 рублей в месяц. Нагрузочное тестирование позволит оптимизировать использование ресурсов и сократить затраты.

❯ Планы на будущее

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

На Kotlin доводилось немного писать и в принципе есть понимание как это реализовать, но все упирается в отсутствие времени.

Исключение административных производств (и ХХК, как следствие)

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

1. Мы направляем заявление.

2. Это заявление регистрируют в отделе обращения граждан и относят главе в почту (о да, на бумаге!);

3. С учетом структуры аппарата, письмо «спускается» до исполнителя за 2-4 дня, т.к. каждый разбирает почту и «отписывает» (поручает) подчиненному в рамках возложенных полномочий;

4. Исполнитель готовит запросы в МВД (в ГИБДД и ФМС);

5. Эти запросы перед отправкой проходят ту же самую цепочку согласований, но уже «вверх», что также занимает 2-4 дня;

6. Запросы достаточно долго обрабатываются у адресатов (а бывает и теряются);

7. Приходит ответ на запросы и также «спускается» 2-4 дня. В идеальном случае в ответах есть контакты собственника авто;

8. Если контактов нет, то по адресу регистрации необходимо направить письмо (по тому же пути) касаемо административного протокола. Если контакт есть,то собственника приглашают на составление протокола (что тоже достаточно трудно и затратно по времени).

9. Когда протокол составлен, назначается административная комиссия, состоящая из уполномоченных лиц из разных ведомств. Как правило, комиссии проходили пару раз в месяц и на них приглашалось 20-30 нарушителей. Сейчас периодичность и «наполняемость», естественно, иные.

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

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

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

Информационная работа

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

Бэкенд используется тот же, только добавили отельные модели (1, 2, 3, 4) и сделали простейший эндпоинт.

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

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

❯ Как помочь проекту

Код и компетенции

Лучший вклад, который вы можете сделать, это ваше время и компетенции. Поэтому если есть желание и возможности,мы будем рады предложениям и вашим MR.

Финансовая поддержка

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

Информационная поддержка

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

❯ Ссылки

1. Сайт: xxkap.app и хрюхрюкар.рф;

2. Репозиторий;

3. Группа в ВК;

4. Канал в Telegram;

5. Почта брата — его зовут Игорь и он за время работы над ХХК неплохо вырос как бэкенд-разработчик, ~90% кода backend — его работа. Если кому-то в проект нужен молодой и перспективный backend developer (Django/Flask), напишите ему, пожалуйста.

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

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

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

Спасибо за ваше время!

Новости, обзоры продуктов и конкурсы от команды Timeweb.Cloud — в нашем Telegram-канале ↩