IT-инфраструктура штабов Навального и сбор подписей: подготовка к сбору, сайт «Навальный 20!8»
Введение
Это рассказ о том, как устроена IT-инфраструктура региональных штабов Алексея Навального и система для сбора подписей в поддержку его выдвижения кандидатом в президенты России.
Еще это рассказ о том, как при помощи свободного ПО и недорогих комплектующих небольшая команда создала сложную систему сбора подписей в масштабах целой страны. В проекте нет сложных технических решений, но есть множество важных мелочей, которые невозможно предусмотреть на основе типичного опыта 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 и стандартная админка. За полтора года сайт пережил несколько обновлений: добавлялись разделы, менялась работа формы регистрации, менялись тексты и изображения на страницах. Мы старались не усложнять дизайн, чтобы можно было верстать стандартными блоками, благодаря чему некоторые разделы проходили путь от идеи до запуска за три дня.
На любой современный сайт примерно половина посетителей заходит с мобильных устройств. Мы старались сделать сайт удобным для всех, поэтому макеты рисовались и верстались для корректного отображения на любой ширине экрана, начиная от 320 px.
Карта штабов
Единственный сложный интерактивный элемент, который видят посетители, — карта России с отмеченными на ней штабами. Когда количество штабов перевалило за 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-системы, с бумагой, ручкой и таблицами в экселе) — это как лететь на воздушном шарике на Луну: да, если взять достаточно много шариков, даже получится взлететь и скрыться в облаках, но добраться до цели таким способом физически невозможно.
Чтобы собрать такие подписи, которые избирком вынужден будет принять даже у нежелательного кандидата, мы и стали делать эту сложную инфраструктуру. В этой главе мы рассказали о самой задаче, поставленной перед нами, и о подготовке к ее решению.
В следующей главе, которая будет опубликована завтра утром, рассказывается про выбор и настройку оборудования штабной сети, разработку собственного сканера документов и организацию видеонаблюдения за помещениями штабов.
В третьей главе будет описан процесс создания приложений для сбора подписей и все, что касается работы с физическими подписными листами.
В четвертой главе рассказано про управление проектом, команду, таймлайн и немного про результаты.
