Навальный набрал 300 000 виртуальных подписей за выдвижение в президенты

По российским законам, именно столько подписей претендент на пост президента России должен предоставить в ЦИК.

Евгений Фельдман / navalny.feldman.photo

Оппозиционер Алексей Навальный на своем сайте объявил , что набрал 300 000 (точнее, 335 782) виртуальных подписей за свое выдвижение кандидатом в президенты России на выборах 2018 г.

По российским законам, именно столько подписей претендент должен предоставить в ЦИК. «Причём в очень короткий срок (40 дней, включая техническое оформление). Причём в «мертвый сезон» - период сбора выпадает на новогодние праздники. Причём подписи должны быть собраны не менее, чем в 40 регионах страны. То есть фактически это ещё один заградительный барьер для участия в выборах», - пишет Навальный.

Как уточняют Ведомости , чтобы преодолеть этот барьер, оппозиционер в декабре 2016 г. объявил сбор «фьючерсов на подпись», чтобы в нужное время быстро собрать 300 000 «идеальных» подписей. Каждая из виртуальных подписей - это e-mail, подтвержденный телефон и краткая анкета человека, пообещавшего поставить реальную подпись за Навального. «У тех кандидатов, которых Кремль хочет видеть на выборах, и бумагу нарезанную возьмут как подписи, мы такое не раз наблюдаем. Наши же подписи будут смотреть под микроскопом», - пишет оппозиционер.

Однако подписей может не хватить: в ЦИК можно сдать не больше 7500 подписей из одного региона, отмечает Навальный. Поэтому, «чтобы снизить риски забраковки в конкретном регионе», Навальный решил собрать не 300 000, а 1 млн подписей. Помимо страховки, это хорошее предвыборное мероприятие, а также способ привлечь волонтеров и напомнить властям о своей реальной поддержке, пишет Навальный.

Как сообщал «Югополис», о том, что собирается участвовать в выборах президента России в 2018 году. Он получил возможность баллотироваться после того, как Верховный суд отменил приговор по делу «Кировлеса».

Навальный получил после того, как Верховный суд России отменил его приговор по делу «Кировлеса».

Летом 2013-го года Алексей Навальный и Петр Офицеров были приговорены к пяти и четырем годам лишения свободы в рамках дела Кировлеса. Уже через несколько дней по неназванной причине реальные сроки были заменены условными.

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

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

Это технический материал, но многие вопросы, которые здесь обсуждаются, непонятны без минимального знания современного политического контекста, поэтому он в необходимой мере описан. Если вас по каким-то причинам пугает слово «Навальный» (оно встретится еще несколько раз) или упоминание демократических институтов, просто не читайте этот текст. В комментариях политические вопросы обсуждаться не будут.

Цель кампании

Регистрация Алексея Навального кандидатом в президенты.

Задачи, поставленные перед IT-отделом

(в хронологическом порядке):

Предварительная регистрация всех, кто готов поставить подпись за выдвижение нашего кандидата;
- Обеспечение работы сети штабов по всей России;
- Создание системы для сбора 315 тысяч идеальных подписей.

Исторический и политический контекст

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

Бесконечные возможности для отказа в регистрации заложены на уровне правил сбора:

• Сбор подписей жестко ограничен по времени;
• На брак по закону отводится небольшой процент от необходимого количества подписей, нельзя сдать подписи с хорошим запасом;
• Невозможно на своей стороне проверить подписи, т. к. данные избирателей должны соответствовать базе ФМС, доступ к которой есть только у государственных органов;
• Графолог при проверке в ЦИК может забраковать любую подпись и не несет юридической ответственности в случае ошибки;
• Сама схема проверки предполагает, что будет значительный процент ложных срабатываний (парадокс теоремы Байеса как заградительный барьер на выборах).

Мы уже сталкивались с этим в Новосибирске, когда собирали подписи для участия в выборах в Законодательное собрание.

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

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

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

Особенности нового сбора подписей

Для сбора подписей за выдвижение кандидата в президенты установлены еще более жесткие условия:

Необходимо сдать не более 315 тысяч подписей;
- Не менее 300 тысяч подписей должны быть признаны действительными;
- От одного региона засчитывается не более 7500 подписей;
- На короткий период сбора (с 27 декабря по 31 января) приходятся продолжительные новогодние праздники, когда многие уезжают в отпуск.

Учитывая предыдущий опыт и новые требования, мы приняли следующие базовые принципы.

Всероссийская сеть штабов

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

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

Сбор подписей только в штабах

Для сбора по домам нам бы пришлось нанять несколько тысяч сборщиков. Каждый, кто хоть раз работал с платными сборщиками (или, например, студентами-социологами), знает, что не все они одинаково трепетно относятся к процедуре и не все преодолевают соблазн просто «нарисовать» подпись-другую. Небрежное заполнение приводит к большому проценту брака, а «рисование» подписей - настолько распространенная проблема, что в ЦИКе предусмотрена проверка графологом. Даже наличие графолога в штате и показательное оформление нескольких заявлений в полицию не может на 100% избавить штаб от «рисовальщиков» (мы проверяли). К тому же сборщик может дорисовывать подписи не только из злого умысла, но и, наоборот, чтобы «помочь штабу».

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

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

Многоступенчатая проверка подписей

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

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

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

Скан паспорта для каждой подписи

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

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

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

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

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

Синхронизация с электронной базой данных

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

Что было сделано в новой версии системы

• Чтобы нам было где собирать подписи, мы развернули сеть региональных штабов. IT-инфраструктура штабов состоит из нескольких физических серверов, ряда виртуалок, 70 роутеров, 230 камер и 189 укомплектованных рабочих станций. Изнутри системой одновременно пользуются более 250 человек.
• Чтобы за короткий период сбора успеть привести в штабы несколько сотен тысяч человек, мы заранее начали регистрацию избирателей на сайте 20!8, где они предварительно подтверждали свои данные.
• Чтобы снизить количество ошибок, мы сделали систему, позволяющую проводить независимые проверки правильности заполнения подписного листа. Система состоит из нескольких веб-приложений и мобильного приложения под две платформы.
• Чтобы загрузить данные в систему, мы собрали (и частично изготовили) комплект оборудования для сканирования паспортов, продумали схему безопасной передачи персональных данных и внедрили ее во всех штабах.
• Чтобы форматирование адреса было корректным с точки зрения избиркома, мы подняли поиск по базе ФИАС и вместе с юристами серьезно повозились с ней, чтобы учесть все требования закона.
• Чтобы (частично) обезопасить штабы и иметь дополнительные аргументы в судах, мы наладили круглосуточную систему видеонаблюдения и записи.
• Чтобы протестировать инфраструктуру, механику, уточнить данные и подготовить штабы к сбору, мы провели большую процедуру предварительной верификации избирателей, через которую прошло 81 750 человек.
• Мы разработали внешний вид подписного листа, систему логистики листов в штабах, а также систему физического хранения и быстрого доступа для центрального штаба.

Основные технологии наших веб-приложений

Основной язык бэкенда: Python.
Фронтенд: JavaScript, jQuery, React, D3.js.
Фреймворки: Django (6 шт), aiohttp (1 шт).
Базы данных: PostgreSQL, Redis и другие.
Полнотекстовый поиск: Sphinx.
HTTP-сервер: Nginx, Varnish.
Тестирование: Jenkins, Browserstack, RobotFramework, Locust.
Мониторинг: Zabbix, Elasticsearch, Kibana, Sentry.
Деплой: Ansible и другие инструменты.
Управление конфигурацией сервера: Chef.

Часть первая: сайт «Навальный 20!8»

Нам предстояло привести в штабы несколько сотен тысяч человек в очень ограниченный промежуток времени. Для этого мы начали регистрацию сторонников прямо в день старта кампании. Рекрутинг и регистрация сторонников - одна из основных задач сайта «Навальный 20!8 », поэтому форма регистрации есть почти на каждой странице.

Так как все это нужно не просто ради красивых цифр, нам важно было знать, что зарегистрировавшиеся сторонники - это настоящие люди, а не боты, уметь поддерживать с ними связь и понимать, в каком городе они прописаны (чтобы прогнозировать выполнение квот по регионам). Поэтому регистрация на сайте была довольно сложной и с обязательным подтверждением номера телефона. Чтобы не обманывать себя и других, в потенциальных подписантов мы записывали только людей, которые заполнили анкету целиком и подтвердили свой телефон. Поэтому на главной странице вместо миллиона с лишним (общее количество регистраций) у нас сейчас только 706 513 «будущих подписей».

С точки зрения сайтостроения это довольно рядовой продукт. Сайт сделан на Python + Django + PostgreSQL, используются стандартный ORM и стандартная админка. За полтора года сайт пережил несколько обновлений: добавлялись разделы, менялась работа формы регистрации, менялись тексты и изображения на страницах. Мы старались не усложнять дизайн, чтобы можно было верстать стандартными блоками, благодаря чему некоторые разделы проходили путь от идеи до запуска за три дня.

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

Карта штабов

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

Карта сделана с использованием прекрасной и многогранной библиотеки d3.js. Писать свой скрипт, а не использовать стандартные Google Maps или Яндекс.Карты мы решили из-за картографической проекции. Есть множество способов сделать развертку эллипсоида Земли на плоскости . В проекции Меркатора объекты сильно растягиваются на северных широтах, а нам нужно больше места в тех районах, где сосредоточены основные крупные города. Кроме того, в проекции Меркатора Россия выглядит довольно странно. Мы выбрали более привычную по учебникам географии коническую проекцию Альберса (Albers-Siberia).

Россия здорового человека (коническая проекция Альберса) и Россия курильщика (проекция Меркатора)

Управление контентом

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

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

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

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

Для отображения блоки преобразуются в нужный формат: HTML для поста, текст для индексирования, RSS или XML для Яндекс.Дзена, JSON для мобильного приложения и так далее. Таким образом мы получаем предсказуемый результат на любом устройстве при достаточно сложном форматировании контента.

Первая версия была основана на коде Sir Trevor . Позже, когда поддерживать спагетти-код Sir Trevor стало тяжело, редактор был переписан на React.

Аналитика

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

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


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

График сделан на d3.js, а фильтрация событий по времени и штабу реализована с использованием библиотеки Crossfilter . Это решение позволяет на клиентской стороне без тормозов интерфейса оперировать данными о регистрациях на интервале больше года с шагом 1 час. На данный момент это 12 мегабайт данных (1,3 Мб в gzip).

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

Город и регион

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

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

Москва - 2,5% ошибок и 579 вариантов написания;
- Санкт-Петербург - 12,6% ошибок и 767 вариантов написания;
- Комсомольск-на-Амуре - более 20% ошибок и сокращений, 75 вариантов.

Неправильная оценка количества сторонников могла привести к неправильному планированию сети штабов и агитационных мероприятий. Пришлось подумать над тем, как пользовательский ввод названия города превратить в стандартное название региона. Не хотелось для такой простой формы использовать механизмы автодополнения по КЛАДРу или ФИАСу. Поэтому мы взяли список из 700 наиболее крупных городов России, добавили список типичных написаний («спб», «н-ск») и сделали нестрогий поиск по ним с ранжированием по расстоянию Левенштейна (это мера разницы между двумя наборами символов).

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

На этом графике видно, как кампания со временем становилась все более региональной. Доля новых регистраций из Москвы и Санкт-Петербурга уменьшилась с 35% до 15%.

SMS и почта

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

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

Мы отправляем большое количество писем по базе из более 700 тысяч email-адресов. Кто-то подписан на новости, кто-то должен получить уведомление о событии. Кроме того, каждый адрес нужно подтвердить по правилам 2-opt-in (это когда в первом письме приходит ссылка, на которую нужно нажать, подтверждая подписку на рассылку). В начале кампании мы пользовались сервисом ActiveCampaign, но он дорогой и невероятно тормозной. Когда база перевалила за 300 тысяч контактов, работать стало невозможно. Поэтому мы написали свой CRM / рассылочный сервис, который позволяет по нужным выборкам формировать рассылки и цепочки писем. Для доставки писем сейчас используется Mailgun.

Очереди отложенных задач

Отправка почты или SMS через API сторонних сервисов - операция, занимающая существенное время. Такие операции нужно выполнять асинхронно, чтобы не замедлять пользовательский интерфейс и не положить все приложение под нагрузкой. Изначально все асинхронные задачи работали через Celery с Redis в качестве брокера. Каждое письмо или SMS-сообщение создавало задачу в очереди Celery, после чего свободный воркер эту задачу обрабатывал. Но такой подход оказался ненадежным и слишком ресурсоемким.

Как-то раз нам прилетело больше 10 тысяч регистраций за час (нет, нас не показали по телевизору, это была кампания «+1»). 10 воркеров Celery не могли с этим справиться, пользователи начали замечать значительную задержку при получении SMS и почты.

После этого случая мы отказались от Celery в пользу простейшей очереди на базе PostgreSQL. Задачи из очереди разбирали «демоны» на питоне, по одному на каждый канал доставки сообщений. Раз в 10 секунд демон брал пачку задач из очереди и одним пакетом отправлял данные в рассылочный API. Группировка задач радикально снизила нагрузку на сервер, а использование самодельной очереди предельно упростило отладку и мониторинг.

Celery оказался слишком сложным инструментом для нашей задачи. Ему требуется вдумчивая настройка и мониторинг через внешние утилиты вроде Flower, которая сама потребляет немало ресурсов. На других проектах мы стараемся использовать более простое решение - RQ + Redis.

Сравнение сложности RQ и Celery из статьи про работу с асинхронными задачами.

Процесс разработки

Как устроен процесс создания сайта «Навальный 20!8» с точки зрения разработчиков? Мы не придерживаемся какой-то одной методологии, а используем подходы из разных систем. Например, менеджеры ставят задачи в Trello со структурой, похожей на канбан-доску, а разработчики применяют отдельные практики экстремального программирования.

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

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

Исходный код хранится в git-репозитории на платформе Bitbucket. Для каждой серьезной новой задачи создается отдельная ветка. Мы не поднимаем staging-сервер для каждой ветки, все они сливаются в develop для запуска на едином тестовом сервере. После тестирования разработчик, ответственный за задачу, делает пулл-реквест в мастер. Тимлид смотрит код и, если все хорошо, запускает деплой. Для больших задач разработчики делают подробные описания того, что нужно проверить и что может пойти не так при деплое.

Деплой организован очень просто. У нас есть инструмент, который реагирует на веб-хук из Bitbucket (или на кнопку из своего интерфейса), забирает код из нужной ветки, копирует его на сервер и запускает там скрипт обновления. Скрипт оформлен в Makefile.

При запуске «make update» происходит обновление зависимостей, миграции, постпроцессинг статических файлов и, если все прошло удачно, перезапуск uwsgi-сервера. Миграции мы стараемся делать так, чтобы они не ломали старый код, поэтому в случае ошибок деплоя все продолжает работать.

Разработка началась 18 сентября 2016 года. С тех пор было 1228 коммитов, 200 пулл-реквестов, деплой более 600 раз запускался в продакшн, а в репозитории было 67 веток (большинство из них сейчас закрыты).

Про дизайн

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

В дизайне IT-продуктов мы всегда руководствуемся двумя основными принципами:

1) Информация для самого «ленивого» и невовлеченного пользователя должна лежать на самом видном месте (так мы, например, определяли первоначальные места блоков и разделов на сайте);

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

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

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

В проекте много сложных схем, которые так и хочется нарисовать, а все найденные с ходу электронные инструменты для рисования схем нас не устраивали. Иногда мы использовали draw.io, но чаще рисовали прямо на бумаге. Самые важные схемы висели на доске проекта. Туда же крепились бумажные «тикеты» с вопросами для обсуждения на встречах.

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

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

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

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

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

Верификация и сбор подписей через IT-систему - это полностью изобретенная нами процедура, поэтому основным методом проверки своих решений мы выбрали тестирование MVP на реальных пользователях системы. Так мы протестировали базовый протокол и первый интерфейс верификации на сотрудниках московского штаба, а потом поехали в три разных города (Санкт-Петербург, Челябинск и Ульяновск), чтобы понаблюдать за реальными пользователями в процессе работы. Для подобных проектов это лучший способ быстро составить список вещей и юзер-кейсов, которые могли забыть или не предусмотреть на этапе проектирования и разработки.

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

Тестирование

Для автоматизированного тестирования использовался RobotFramework. Для покрытия самого критического функционала проекта были написаны приемочные и функциональные тесты, настроен их автоматический запуск. В качестве CI-системы использовался Jenkins.

Важнейшая функция сайта - регистрация пользователей, которая предполагает подтверждение телефона через SMS-код. Для тестирования сообщений с кодами был настроен GSM-модем с тестовой SIM-картой и Asterisk. SMS-код пересылался на почту, откуда он уже был доступен для тестов.

Обнаруженные ошибки добавлялись в Trello в виде задач разработчикам.

Серверная инфраструктура

Сайт «Навальный 20!8» продолжает работать и плавно становится сайтом кампании забастовки избирателей, поэтому информационное эмбарго еще не снято, и рассказ будет коротким. Серверная часть состоит из трех уровней: бэкенд, кэширующие прокси и edge-серверы. Все конфигурации управляются через chef, поэтому сервер с любой ролью может быть быстро поднят на новой виртуалке.

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

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

Edge-серверы занимаются кэшированием статики и ssl-терминацией (дальше трафик идет по VPN-сети). Суть этих серверов - раздать основной объем трафика и защитить остальную инфраструктуру от атак. Это слабые виртуалки с гигабитным каналом в разных дата-центрах. Нагрузка распределяется DNS-балансировкой. Edge-серверы содержат минимум конфигурации и при необходимости легко поднимаются за несколько минут. Максимальный полезный трафик, который был у нас на edge-серверах, - 5 Гбит/с в течение нескольких часов.

Картинки, стили, javascript, json-данные хранятся таким образом, что имя файла включает хеш от содержимого данного файла (например, style.28fa1c7b1761.css), поэтому все эти файлы можно навсегда кэшировать на сервере и в браузере. Основной объем трафика отдается с edge-серверов. Дальше проходят только запросы к контентным страницам, а это примерно в 25 раз меньше данных.

Иногда вместо edge-серверов подключается CloudFlare, но мы стараемся возвращаться к своим серверам, т. к. у CloudFlare не всегда бывает хорошая доступность из России. Отдельные провайдеры, даже самые крупные, регулярно начинают блокировать их ip (следы Роскомнадзора).

Заключение

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

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

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

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

В четвертой главе рассказано про управление проектом, команду, таймлайн и немного про результаты.

Теги: Добавить метки

​Кампания +1. Собираем 1 000 000 подписей

​На то, чтобы собрать 300 000 подписей, необходимых для выдвижения кандидата на президентских выборах в 2018 году, нам потребовалось 4 месяца. Наша новая цель - миллион, и мы запускаем кампанию «+1».

По законам Российской Федерации для регистрации кандидатом в президенты претендент должен предоставить в Центральную избирательную комиссию 300 000 подтвержденных подписей, собрать которые необходимо в очень короткий срок. На сбор отводится всего 40 дней, а в нашем случае - еще меньше, потому что эти 40 дней приходятся на новогодние праздники. По сути, это еще одно искусственное препятствие, созданное властью. Кроме того, подписи должны быть собраны в 40 регионах страны - не более 7500 от каждого субъекта РФ.

Фото: Евгений Фельдман

Чтобы вовремя подать в ЦИК необходимые 300 000, мы должны знать, что во всех регионах, где будут открыты наши штабы, мы можем рассчитывать на 7500 подписей. И что собраны они будут точно в срок и с полным соблюдением процедуры.

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

Алексей Навальный

Фото: Евгений Фельдман

Скорее всего, подписи, поданные штабом Навального, ЦИК будет изучать особенно тщательно - поэтому мы должны максимально застраховаться и собрать намного больше, чем предписано протоколом. Мы собираем не только электронные адреса, но и номера телефонов и краткие анкеты всех, кто готов поддержать выдвижение Алексея Навального. Это делается для того, чтобы мы точно знали, в каких регионах есть наши сторонники и сколько их.

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

Алексей Навальный

Следующая наша цель - миллион подписей, которые гарантируют нам необходимые 300 000 в конце года. Для этого мы запускаем кампанию «+1» и призываем всех, кто уже поставил подпись на сайте, убедить зарегистрироваться еще хотя бы одного человека. А лучше двоих или пятерых - и тогда нужный миллион будет достигнут уже к лету.

Сейчас нам очень нужна ваша помощь. Потратьте, пожалуйста, 10-15 минут своего времени и сагитируйте кого-нибудь из своих друзей, родственников или коллег по работе поставить подпись.

Фото: Евгений Фельдман

Напишите нескольким знакомым письмо или сообщение в социальной сети:
«Привет. Я поставил свою подпись за выдвижение Навального кандидатом. Не мог бы ты тоже поставить? Это будет правильно»

Алексей Навальный

Уже подписавшиеся 385 531 человек - страшная сила. Давайте использовать ее с максимальной пользой. Присоединяйтесь к кампании «+1».

Р азочаровавшийся в блогере функционер рассказал о непростой ситуации в штабе.

В штабе блогера Алексея Навального , который продолжает сбор средств на президентскую кампанию, несмотря на запрет ЦИК и разъяснения Конституционного суда, снова неразбериха. Об управленческом кризисе в протестных рядах пишет на своей странице в Facebook недавний функционер ФБК, правозащитник Виталий Серкуанов . Свой уход из команды Навального Серуканов объяснил «необходимостью самоуважения».

По сведениям Виталия Серкуанова, штаб Навального не в состоянии удовлетворить требования жертвователей средств и обнародовать статистику собранных в регионах подписей. Причина активисту очевидна: для выдвижения блогеру не хватает 250 тысяч голосов, но заручиться необходимым количеством сторонников до дедлайна будет непосильной задачей. Cрок, когда ЦИК должны быть представлены документы для регистрации, заканчивается 31 января 2018 года в 18 часов. Именно поэтому, как отмечает Серуканов, команда Навального меняет тактику по принципу Никколо Макиавелли «Цель оправдывает средства». Несанкционированные митинги 24 декабря планируют как жесткий этап перехода от провала кампании к этапу будущего бойкота выборов.

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

Юрист Илья Ремесло , который провел независимое расследование деятельности ФБК, в комментарии ИА «Политика Сегодня» отметил, что количество разочаровавшихся сторонников Навального увеличивается закономерно.

К этой же категории собеседник агентства относит бывших волонтеров Александра Туровского и Дениса Лебедева . Первый пострадал при обыске в штабе блогера, но Навальный не удосужился упомянуть его имя. Похожая история произошла с Лебедевым тремя годами ранее. Ему сломали ногу в одной из поездок по делам ФБК, но в фонде активисту дали понять, что не собираются заниматься его проблемами.

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

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

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

При сборе подписей в Новосибирске мы каждый лист помещали в мультифору (прозрачный «файл»), на которой маркером записывались ID листа и все служебные пометки. Это подошло для четырех тысяч листов, но не сработает для сотен тысяч. В этот раз мы посчитали использование мультифор ненадежным и неудобным решением.

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

Код листа состоит из 6 символов. Можно использовать цифры и буквы латиницы, имеющие графические аналоги в кириллице (в формах можно писать в любой раскладке). Для удобства добавили разделители: 91−X7−BA.

Этот же идентификатор печатается в виде QR-кода для автоматического распознавания на различных этапах работы. QR-коды победили по надежности и скорости распознавания все другие виды штрихкодов.

Жизнь штабов полна трудностей, поэтому QR-коды тщательно тестировали в различных стрессовых для листов ситуациях…

… и решили, что трех кодов будет достаточно, чтобы обработать любой живой лист.

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

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

Сыч: подготовка к сбору подписей

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

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

Состав Сыча

Бэкенд с RESTful API: Python 3.6, aiohttp, aiohttp_admin, SQLAlchemy.
Базы данных: PostgreSQL, Redis.
Демон уведомлений.
Демон распознавания номеров паспорта.
Демон для сборки аналитики.
Сервис проверки паспорта по его номеру.
Коробочная версия Кладр-API для работы с адресами (PHP 5.6 + MongoDB).

Мы решили сделать для Сыча отдельный бэкенд с RESTful API, потому что планировалось интегрировать его с несколькими сервисами, включая сайт «Навальный 20!8». В качестве хранилища использовали отдельную базу PostgreSQL и Redis - для кэширования. Для управления пользователями подошла библиотека aiohttp_admin, которую мы модифицировали под свои нужды.

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

Взаимодействие с сайтом «Навальный 20!8» велось через API, который защищен токеном и доступен только по локальной сети между виртуальными машинами.

Запись на верификацию

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

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

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

Уведомления

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

SMS-уведомления отправлялись для напоминания о записи за три часа и для информирования о том, что штаб отменил запись. Очередь уведомлений была сделана по тому же принципу, что и на сайте «Навальный 20!8»: таблицы в БД с сообщениями, которые отправлялись группами через почтовые и SMS-шлюзы.

Распознавание паспортных данных

Чтобы оценить работу операторов и определить процент ошибок при вводе данных, хотелось иметь дополнительное распознавание сканов. Надежное автоматическое распознавание сделать было невозможно из-за вариативности паспортов, поэтому рассматривалось два варианта: отсылать сканы в Яндекс.Толоку, чтобы их распознавали ее пользователи, или взять группу волонтеров, которые занимались бы этим в офисе. Но вопрос безопасности персональных данных пресек оба варианта, и мы оставили автоматическое распознавание только для номера паспорта.

Аналитика Сыча

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

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

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

Регионального менеджера мы избавили от лишних подробностей, и на первом экране он видел только самые важные вещи по своей группе штабов: ключевые показатели, рейтинги и проблемные штабы (обозначены тревожным красным). К «проблемным» мы относили штабы с показателями на N% ниже среднего значения, хронически недогруженные (им требовалось дополнительное оповещение) и перегруженные по количеству записей (это означало, что не все люди могут записаться и нужно увеличить количество операторов).

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

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

Всего в аналитике выводилось более 50 показателей. Гибкости SQLAlchemy хватило, чтобы ни разу не перейти на чистый SQL и чтобы код оставался читабельным. Для наиболее трудозатратных показателей сначала сделали кэширование в Redis, но оказалось проще периодически обсчитывать их в бэкграунде и при запросах брать из файла.

Жнец-2018: система для сбора подписей

Параллельно с ходом верификации разрабатывалась система для сбора подписей. За основу была взята архитектура системы, использованной в Новосибирске и умеющей работать с физическими объектами - листами и подписями.

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

Интерфейс оператора

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

1. На момент выборов он должен быть старше 18 лет.
2. Если избирателю 20 или 45 лет, у него должен быть новый паспорт.
3. Паспорт не должен числиться в списке недействительных.

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

Сейчас в базе более 110 миллионов записей (серии и номера паспортов). Для быстрого поиска при небольшом объеме базы и индексов была придумана такая схема: в PostgreSQL создается таблица с миллионом записей, первичным ключом в которой является номер паспорта (от 0 до 999999), а во втором поле записаны все серии недействительных паспортов для этого номера. Для уменьшения объема серии переведены в бинарный формат (по два байта) и сжаты с использованием zlib (просто захотелось). Исходно база занимает около 1 Гб без учета индексов. После обработки получается 260 Мб вместе с индексом. Одна запись проверяется в среднем за 15 мс.

0,6% паспортов людей, проходивших верификацию, нашлись в базе недействительных паспортов. Это значит, что без такой проверки мы бы потратили 12% от лимита недействительных подписей только на данный вид ошибок.

0,88% паспортов нам не подошли, поскольку гражданину исполнилось 20 или 45 лет, но он еще не заменил паспорт. И это еще 18% от лимита недействительных подписей.

В подписном листе 4 колонки, заполняемые оператором: ФИО, год рождения, номер паспорта и адрес постоянной регистрации. Все эти данные проходили через Жнеца для проверки и коррекции возможных ошибок. Например, в полях для имени и отчества работает поиск опечаток:

Для подсказок по именам в API есть метод, который сравнивает значение с большим списком и возвращает три варианта ответа:

Все OK, есть такое имя;
- есть похожее имя (такое-то);
- неизвестное имя (редкое имя или серьезные ошибки в написании).

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

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

Сканирование документов

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

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

Изображение получается на клиентской стороне из HTML 5 Canvas API и отправляется на сервер в виде строки base64, в которой лежит JPEG. С точки зрения фронтенда сканеры могут работать в двух режимах: USB web-камера и стриминг видеопотока с компьютера в локальной подсети. Сыч работает только с USB-камерами, а Жнец-2018 позволяет переключаться между режимами. Оператор сам выбирает, какой сканер использовать.

С выбором видеопотока соседних компьютеров возникла небольшая проблема: столы и сканеры можно двигать, а операторы могут пересаживаться. Мы не знаем, какой сканер окажется рядом с оператором в следующий раз. Пришлось перебирать штабную подсеть и дать оператору возможность выбрать любой из живых сканеров. Но оказалось, что сервер видеотрансляции сканера, хоть и ставят корректные CORS-заголовки (Access-Control-Allow-Origin: *), не отвечают на OPTIONS-запросы. Браузер запрещал ajax-запросы на соседние хосты, из-за чего для поиска не получалось использовать обычный jQuery.ajax(). JSONP-запросы тоже не помогли, поскольку их не получалось отменить программно, а несколько десятков ожидающих запросов полностью блокировали страницу. Решить проблему помогли картинки. Мы добавляли в DOM теги и прописывали им src видеопотока. Если картинка меняла размеры в соответствии с размерами потока, то поток считался живым и показывался оператору.

Отображение видеопотока в браузере заметно нагружает скромные процессоры Raspberry Pi, поэтому нам пришлось сделать «скринсейвер»: после 5 минут бездействия браузер ставит трансляцию на паузу.

Нам важно выбрать актуальную информацию о месте регистрации. На развороте паспорта может быть 6 штампов, но нужен только один. Интерфейс предлагает выбрать его с помощью стрелок на клавиатуре или кликом по нужному штампу на превью.

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

Обработка адресов

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

К адресу регистрации есть большой список юридических требований. Например:

Это должен быть адрес по базе ФИАС (федеральная информационная адресная система);
- для переименованных улиц нужно указывать новые названия, даже если в паспорте было старое;
- законом устанавливается определенный формат иерархии адресных объектов, которые нужно записать (например, нельзя указывать городской район).

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

На сборе подписей в Новосибирске из-за претензий к полю «адрес» были признаны недействительными около 3,5% подписей. И это 70% от лимита, который установлен для подписей за выдвижение кандидата в президенты.

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

Мы стараемся, когда это возможно, не использовать API сторонних сервисов, чтобы не отдавать данные о наших пользователях и чтобы не оказаться в ситуации, когда API внезапно выключат в самый ответственный момент. Работа с адресами - критическая для сбора подписей функция, поэтому нам пришлось сделать свой API к базе ФИАС.

В базе ФИАС пока еще нет достаточно качественных и полных сведений о домах и квартирах, поэтому мы остановились на уровне улиц. В таком виде база со всеми дополнительными построениями весит около 2 ГБ и вполне комфортно живет в виде PostgreSQL. Для импорта использовались модифицированные скрипты из репозитория fias2pgsql .

Для универсальной всероссийской формы ввода адреса нельзя просто сделать поля «город», «улица», «дом», т. к. существует множество разных форматов адресов и типов адресных объектов. Известный пример непривычного формата - Зеленоград, в котором есть дома без названия улицы. Но, поверьте, в масштабах всей страны это довольно тривиальный случай.

После серии экспериментов мы остановились на форме из трех полей:

Субъект РФ - он есть всегда, это самое понятное поле;
- адрес по ФИАС - поле с автодополнением по адресам данного региона внутри ФИАС;
- дом/корпус/квартира - строка, куда данные переписываются точно в соответствии со штампом о постоянной регистрации.

Юристы составили таблицу преобразований адресов, при помощи которой мы приводили адреса ФИАС в формат, соответствующий законодательству о выборах. Чаще всего нужно было исключить один из элементов адреса. Какие-то адреса исключали целиком (гаражные кооперативы, дворовые территории и другие подобные объекты). IT-отдел получал таблицу с правилами, а юридический отдел в ответ получал по 10 примеров на каждый из 44 типов адресов.

После нескольких таких итераций база была готова к работе.

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

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

Решение получилось удобным и быстрым. Один запрос к suggest API выполняется за 15–20 мс, бэкенд спокойно обрабатывает 300 одновременных соединений на не самой мощной виртуалке.

Заполнение подписного листа

Подписи должны вноситься в листы того субъекта российской федерации, к которому принадлежит адрес постоянной регистрации гражданина (или в специальные листы без региона, если регистрации нет). Жнец сообщает оператору, лист какого региона нужно взять, и не дает внести подпись на лист другого региона.

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

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

Мы разработали такие сценарии работы оператора, которые уменьшают вероятность возникновения типичных ошибок. Заверительные надписи листов «домашнего» региона (около 80% подписей будут из региона, в котором находится штаб) заполняются сборщиком заранее, в спокойной обстановке. Для всех блоков листа Жнец показывает, как именно они должны быть заполнены.

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

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

После заполнения всего листа на нем проставляется дата и подпись сборщика. Лист передается на проверку.

Проверка подписей, работа с листами в штабе

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

Отдельно проверяется заверительная запись. Ошибки при заверении особенно опасны, поскольку затрагивают сразу весь лист. Такими ошибками обусловлено происхождение примерно 9% всех недействительных подписей.

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

Все имена и другие данные на изображении являются выдуманными

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

Смайлики и нейрофизиология счастья

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

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

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

Отправка листов

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

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

После сканирования листы упаковывают и отправляют в Москву.

Детали форм

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

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

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

Логистика и физическое хранение листов

Перекладывание бумажек - один из видов деятельности, в котором человечество достигло невероятных успехов. Казалось бы, можно пойти в магазин канцтоваров, купить набор для сбора подписей «Федеральный» и не думать о подробностях. Но есть проблема: все офисные решения стоят слишком дорого. Мы не можем поставить в каждый штаб сканеры документов за несколько десятков тысяч рублей и шкафы с подвесными папками за сто тысяч, поэтому на каждом этапе приходилось что-то изобретать и создавать из подручных материалов.

Немного фактов о физике процесса

Нам нужно сдать 315 тысяч подписей. Для этого, с учетом региональных квот и запаса на различные ошибки, нужно собрать и обработать около 1 миллиона подписей. На каждом листе может быть максимум пять подписей, но в реальности будет где-то 3-4. Это дает нам, грубо говоря, 300 тысяч листов.

Лист бумаги формата А4 имеет площадь 1/16 м².
Плотность обычной офисной бумаги - 80 г/м², каждый лист весит 5 г.
Высота пачки из 500 листов - 4,5 см для чистых листов, более 6 см для заполненных.

Получается, все собранные листы будут весить 1,5 тонны, а сложенные в одну пачку они будут около 36 метров в высоту.

Как все это хранить?

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

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

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

Для быстрого доступа была придумана система индексации физической базы листов. Индекс состоит из нескольких уровней: штаб (ящик), коробка, папка. Адрес папки в архиве выглядит так: 77−1−15. Внутри каждой папки лежит 25 листов (в произвольном порядке).

На левой верхней картинке - коробка на 500 подписных листов в бумажных папках.
На правой картинке - ящик на 2000 листов в подвесных папках.

Получение и сортировка листов

Все листы, приезжающие из регионов, сканируются автоматическим двухсторонним сканером (он уже был в офисе, поэтому не пришлось собирать его самим из LEGO и Arduino). Этот аппарат умеет заливать результат на сервер по SFTP. Там сканы прогоняются через python-скрипт, который ищет QR-коды в стандартных местах, распознает их и привязывает сканы к общей базе данных. Скрипт надежно обрабатывает даже мятые листы.

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

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

Бэкенд

Жнец-2018 сделан на Django со стандартным шаблонизатором и ORM. В качестве базы данных используется PostgreSQL. Служебные части системы - ФИАС, проверка паспортов, работа с данными предварительной регистрации - вынесены в отдельные модули (django app) со своими базами данных.

Физический мир подписей представлен в виде нескольких классов объектов: подписной лист, строка в листе, подпись. У объектов этих классов есть атрибуты, отражающие состояние объекта в реальном мире. Для управления состояниями использован шаблон «конечный автомат» (машина состояний, finite state machine) и библиотека django-fsm. Все переходы между состояниями прописаны в виде FSM-транзакций, внутри которых проводятся необходимые проверки и дополнительные действия с объектом.

Схема состояний выглядит примерно так:

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

Тестирование

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

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

Сбор подписей сильно ограничен по времени, а значительная часть этого времени приходится в этот раз на новогодние праздники. Мы ожидали, что нагрузка на штабы и систему сбора будет неравномерной. Важно было, чтобы система легко справлялась с любым реалистичным потоком подписей. В пиковые моменты ожидалось до 10 тысяч подписей за час. Для обычного веб-сайта это выглядит несерьезно, но в нашем случае такой порядок «посетителей» может создать большую нагрузку на сервер. Это не просто посещения или регистрации: получение каждой подписи предполагает около 50 запросов к серверу и обработку нескольких изображений высокого разрешения.

Нагрузочное тестирование проводилось при помощи Locust . Это простой инструмент, доступный через PyPI. Сценарии описываются в виде кода на питоне, примерно как юнит-тесты в Django:

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

Развертывание проекта организовано так же, как для сайта «Навальный 20!8».
Доступ к веб-приложениям Жнеца возможен только через штабную VPN-сеть.

Мониторинг

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

Zabbix отслеживает состояние всех виртуальных машин проекта.

Elasticsearch собирает логи nginx со всех виртуалок, Kibana показывает это в виде графиков.

В Sentry валятся все ошибки из приложений и с фронтендов. Фронтенды вынесены в отдельную «организацию», чтобы не портили статистику по ошибкам бэкенда. Удобная штука, но заставить Sentry работать при нашей нагрузке было довольно сложно.

Гусь

Это функциональный мониторинг, чем-то похожий на uptime.com , только самодельный. Бэкенд построен на django, очереди сделаны на celery с бэкендом в redis.

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

Если что-то пошло не так, Гусь умеет отправлять письма и SMS или звонить среди ночи и человеческим голосом объяснять ситуацию (для звонков и синтеза речи используется сервис Twillio).

В веб-интерфейсе всегда видно, на каких доменах есть ошибки и как дела у очереди проверок. Каждую минуту делается по 20-25 проверок. Добавить метки