Navalny a marqué 300 000 signatures virtuelles pour l'investiture présidentielle

Selon la loi russe, c'est le nombre de signatures qu'un candidat au poste de président russe doit soumettre à la CEC.

Evgeny Feldman / navalny.feldman.photo

Opposant Alexeï Navalny a annoncé sur son site Internet avoir recueilli 300 000 (plus précisément 335 782) signatures virtuelles pour sa nomination en tant que candidat à la présidence de la Russie aux élections de 2018.

Selon la loi russe, il s'agit du nombre de signatures que le demandeur doit soumettre à la CEC. « De plus, dans un délai très court (40 jours, inscription technique comprise). De plus, en "hors saison" - la période de collecte tombe pendant les vacances du Nouvel An. De plus, les signatures doivent être recueillies dans au moins 40 régions du pays. C'est en fait un autre obstacle à la participation aux élections », écrit Navalny.

Selon Vedomosti, afin de surmonter cette barrière, l'opposant en décembre 2016 a annoncé une collecte de « futures de signature » ​​afin de recueillir rapidement 300 000 signatures « idéales » au bon moment. Chacune des signatures virtuelles est un e-mail, un numéro de téléphone confirmé et un bref profil d'une personne qui a promis de mettre une vraie signature pour Navalny. « Ces candidats que le Kremlin veut voir aux élections, et ils prendront le papier découpé comme signature, nous le voyons plus d'une fois. Nos signatures seront examinées au microscope », écrit l'opposant.

Cependant, il se peut qu'il n'y ait pas assez de signatures : pas plus de 7 500 signatures d'une région peuvent être soumises à la CEC, note Navalny. Dès lors, « pour réduire les risques de rejet dans une région particulière », Navalny a décidé de récolter non pas 300 000, mais 1 million de signatures. En plus de l'assurance, c'est un bon événement de campagne, ainsi qu'un moyen d'attirer des volontaires et de rappeler aux autorités leur réel soutien, écrit Navalny.

Tel que rapporté par Yugopolis, qu'il va participer aux élections présidentielles en Russie en 2018. Il a eu la chance de se présenter après que la Cour suprême a annulé l'affaire Kirovles.

Navalny a été reçu après que la Cour suprême de Russie a annulé son verdict dans l'affaire Kirovles.

À l'été 2013, Alexey Navalny et Peter Ofitserov ont été condamnés à cinq et quatre ans de prison dans l'affaire Kirovles. En quelques jours, pour une raison inconnue, les termes réels ont été remplacés par des termes conditionnels.

C'est aussi l'histoire de la façon dont, à l'aide de logiciels gratuits et de composants peu coûteux, une petite équipe a créé un système complexe de collecte de signatures dans tout le pays. Il n'y a pas de solutions techniques complexes dans le projet, mais il y a de nombreux détails importants qui ne peuvent pas être prévus sur la base d'une expérience typique de développement informatique.

Pour plus de commodité, le matériel est divisé en quatre messages, qu'il est préférable de lire dans l'ordre.

Il s'agit de matériel technique, mais bon nombre des problèmes abordés ici sont incompréhensibles sans une connaissance minimale du contexte politique moderne, de sorte qu'il est correctement décrit. Si pour une quelconque raison vous êtes intimidé par le mot « Navalny » (il apparaîtra plusieurs fois) ou la mention d'institutions démocratiques, ne lisez tout simplement pas ce texte. Les questions politiques ne seront pas abordées dans les commentaires.

Objectif de la campagne

Enregistrement d'Alexei Navalny comme candidat à la présidentielle.

Tâches confiées au service informatique

(en ordre chronologique):

Pré-inscription de tous ceux qui sont prêts à signer pour la nomination de notre candidat ;
- Assurer le fonctionnement d'un réseau de sièges sociaux dans toute la Russie ;
- Création d'un système de collecte de 315 mille signatures idéales.

Contexte historique et politique

Si vous n'avez pas de parti parlementaire, vous devez collecter des signatures pour participer aux élections. Il s'agit d'une procédure de barrage utilisée pour écarter les candidats « non coordonnés » des élections.

Des possibilités infinies de refus d'inscription sont prévues au niveau des règles de collecte :

• La collecte des signatures est strictement limitée dans le temps ;
• Selon la loi, un petit pourcentage du nombre requis de signatures est alloué pour le mariage ; les signatures ne peuvent pas être soumises avec une bonne marge ;
• Il est impossible de vérifier les signatures de votre côté, puisque les données des électeurs doivent correspondre à la base de données FMS, à laquelle seuls les organes de l'État ont accès ;
• Le graphologue, lors du contrôle au CEC, peut refuser toute signature et n'assume aucune responsabilité légale en cas d'erreur ;
• Le schéma de vérification lui-même suppose qu'il y aura un pourcentage important de faux positifs (le paradoxe du théorème de Bayes comme barrière électorale).

Nous avons déjà rencontré cela à Novossibirsk, lors de la collecte de signatures pour la participation aux élections à l'Assemblée législative.

Pour collecter des signatures à Novossibirsk, nous avons créé le système Reaper, qui se concentrait sur la collecte de signatures "sur le terrain" et sur des cubes, gérait les itinéraires des collecteurs, prenait en compte toutes les listes d'abonnement et permettait de classer les signatures en fonction des résultats de divers chèques.

Les collecteurs de Novossibirsk ont ​​apporté plus de 16 000 signatures, dont nous avons sélectionné et remis les 11 722 meilleures. Malgré une sélection rigoureuse, le groupe de travail de la commission électorale a révélé de nombreuses "signatures invalides", et la commission électorale a refusé d'enregistrer les candidats. En savoir plus sur les raisons absurdes pour lesquelles les signatures sont invalidées.

Le nouveau système a été construit en tenant compte de l'expérience accumulée en matière de collecte de signatures et de leur protection ultérieure au sein de la commission électorale.

Caractéristiques de la nouvelle collection de signatures

Des conditions encore plus strictes ont été établies pour la collecte de signatures pour la nomination d'un candidat à la présidentielle :

Il est nécessaire de ne pas soumettre plus de 315 000 signatures;
- Au moins 300 mille signatures doivent être valides ;
- Pas plus de 7 500 signatures sont comptées pour une région ;
- Pour une courte période de collecte (du 27 décembre au 31 janvier), il y a de longues vacances du Nouvel An, où beaucoup partent en vacances.

Sur la base de l'expérience antérieure et des nouvelles exigences, nous avons adopté les principes de base suivants.

Réseau de sièges sociaux dans toute la Russie

En raison des quotas régionaux, il était impossible de travailler dans, disons, dix plus grandes villes. 315 000 signatures pourraient être recueillies si au moins 40 villes étaient couvertes. Dans les régions peu peuplées, la collecte de signatures est plus difficile, donc en pratique, pour une collecte réussie, il a fallu ouvrir des sièges sociaux dans la plupart des régions du pays.

La prévision du nombre de signatures au moment de la réussite de la collecte montre que dans les grandes villes le nombre de ceux qui souhaitent signer dépasserait largement les quotas régionaux. Moscou (127 000) et Saint-Pétersbourg (63 000) ne tenaient pas à l'écran.

Collecte des signatures uniquement au siège

Pour collecter à domicile, il faudrait embaucher plusieurs milliers de collectionneurs. Quiconque a déjà travaillé avec des collectionneurs rémunérés (ou, par exemple, des étudiants en sociologie) sait que tous ne sont pas également sensibles à la procédure et que tout le monde ne surmonte pas la tentation de simplement « dessiner » une signature ou deux. Un remplissage imprudent entraîne un pourcentage élevé de rejets, et le « dessin » des signatures est un problème si répandu que la CEC prévoit un contrôle par un graphologue. Même la présence d'un graphologue en l'état et l'exécution exemplaire de plusieurs déclarations à la police ne peuvent soulager à 100 % le siège des « dessinateurs » (nous avons vérifié). De plus, le collecteur peut ajouter des signatures non seulement par intention malveillante, mais, à l'inverse, pour « aider le siège social ».

Nous savions que lors de la collecte "sur le terrain", nous introduisions certainement des "collecteurs toxiques", comme c'était le cas à Novossibirsk. Les collectionneurs de produits toxiques commettent délibérément des erreurs dans les données des électeurs (par exemple, remplacez un chiffre dans le numéro de passeport). Leur tâche est d'augmenter le nombre de signatures invalides au-dessus de la limite, après quoi la commission électorale refuse de s'inscrire. À Novossibirsk, ils ont déployé beaucoup d'efforts pour nettoyer les signatures toxiques. Lorsqu'ils sont collectés dans tout le pays, cela n'est pas possible.

Ce n'est que dans les quartiers généraux fixes qu'il a été possible d'assurer une qualité suffisante des signatures, les conditions d'un remplissage précis des listes de signatures et leur sécurité.

Vérification de signature en plusieurs étapes

Les signatures idéales sont une abstraction mathématique. La collecte réelle des signatures est un processus difficile et difficile. Même les collectionneurs honnêtes et bien entraînés font des erreurs, et dans des conditions de contraintes de temps, de pression administrative et de provocations, il y aura encore plus de mariages.

Nous avons beaucoup de données sur la façon dont les erreurs apparaissent. D'après notre expérience, il y aura environ 10% de signatures dans les listes de signatures collectées de manière tout à fait honnête, ce que la commission électorale reconnaît comme non valide.

Nous devions soumettre non seulement de bonnes signatures, mais des signatures qui seraient acceptées par la commission électorale. Cela a nécessité plusieurs étapes de vérification et un mécanisme de classement - afin de sélectionner et de soumettre uniquement les signatures les plus susceptibles de passer les contrôles de la commission électorale, aussi absurdes que nous puissions les penser.

Scan de passeport pour chaque signature

Sans scan, toute la responsabilité de la qualité de la signature incombe au collectionneur. S'il a accidentellement ou délibérément fait une erreur dans le numéro de passeport, nous ne le saurons jamais.

Par expérience, nous avons découvert que seules les erreurs de réécriture des données du passeport dans la liste d'abonnement et les erreurs de saisie des données épuisent facilement la limite autorisée de 5 %, même si les signatures sont recueillies dans des conditions confortables et par des collectionneurs consciencieux.

Disposant d'un document scanné, nous pourrions effectuer plusieurs étapes indépendantes de vérification de la signature et apporter des corrections.

De plus, nos avocats se préparaient à se battre pour chaque signature devant les tribunaux. La dernière fois, il y avait une grande catégorie de signatures rejetées, dont nous étions sûrs : la signature correspond au passeport, mais nous l'avons vérifiée par rapport à une base de données obsolète et pleine d'erreurs. Une base de données unique et la disponibilité d'analyses permettraient aux avocats d'automatiser le processus de préparation des plaintes dans de tels cas.

Bien entendu, il n'était possible de scanner un passeport qu'au siège, faute de quoi il serait impossible d'assurer un niveau de sécurité suffisant des données personnelles.

Synchronisation avec la base de données électronique

Toutes les opérations avec signatures et listes d'abonnement, tous les statuts et mouvements devaient être reflétés dans une base de données électronique. Le système de collecte des signatures était censé contrôler toutes les étapes de la collecte et identifier les erreurs. Ce n'est qu'ainsi que nous maintiendrons l'ordre (et la tranquillité d'esprit) lorsque nous travaillons avec des centaines de milliers d'objets physiques.

Ce qui a été fait dans la nouvelle version du système

• Afin d'avoir un lieu de collecte de signatures, nous avons déployé un réseau de directions régionales. L'infrastructure informatique du siège social se compose de plusieurs serveurs physiques, de plusieurs ordinateurs virtuels, de 70 routeurs, de 230 caméras et de 189 postes de travail complets. Plus de 250 personnes utilisent le système de l'intérieur en même temps.
• Afin d'avoir le temps d'amener plusieurs centaines de milliers de personnes au siège dans une courte période de rassemblement, nous avons commencé à enregistrer les électeurs sur le site 20!8 à l'avance, où ils ont préalablement confirmé leurs données.
• Pour réduire le nombre d'erreurs, nous avons créé un système qui permet des contrôles indépendants sur l'exactitude du remplissage de la liste d'abonnement. Le système se compose de plusieurs applications Web et d'une application mobile pour deux plateformes.
• Pour télécharger les données dans le système, nous avons assemblé (et partiellement fabriqué) un ensemble d'équipements de numérisation des passeports, pensé un schéma de transfert sécurisé des données personnelles et l'avons mis en œuvre dans tous les sièges sociaux.
• Pour que le formatage de l'adresse soit correct du point de vue de la commission électorale, nous avons augmenté la recherche dans la base de données FIAS et, avec des avocats, l'avons sérieusement bricolée afin de prendre en compte toutes les exigences de la loi.
• Pour sécuriser (partiellement) le siège et disposer d'arguments supplémentaires devant les tribunaux, nous avons mis en place un système de vidéosurveillance et d'enregistrement 24h/24.
• Afin de tester l'infrastructure, la mécanique, clarifier les données et préparer le siège pour le rassemblement, nous avons effectué une vaste procédure de vérification préalable des électeurs, par laquelle 81 750 personnes sont passées.
• Nous avons développé l'apparence de la liste d'abonnement, un système logistique pour les listes au siège, ainsi qu'un système de stockage physique et d'accès rapide pour le siège central.

Les principales technologies de nos applications web

Langue principale du backend : Python.
L'extrémité avant: JavaScript, jQuery, React, D3.js.
Cadres : Django (6 pièces), aiohttp (1 pièce).
Base de données: PostgreSQL, Redis et autres.
Recherche en texte intégral: Sphinx.
Serveur HTTP : Nginx, Vernis.
Essai: Jenkins, Browserstack, RobotFramework, Locust.
Surveillance: Zabbix, Elasticsearch, Kibana, Sentry.
Déployer: Ansible et autres outils.
Gestion de la configuration du serveur : Chef.

Première partie : le site « Navalny 20 ! 8 »

Nous avons dû faire venir plusieurs centaines de milliers de personnes au siège dans un laps de temps très limité. Pour ce faire, nous avons commencé à enregistrer des supporters dès le jour du lancement de la campagne. Le recrutement et l'inscription des supporters est l'une des tâches principales du site Web Navalny 20! 8, il y a donc un formulaire d'inscription sur presque chaque page.

Étant donné que tout cela est nécessaire non seulement pour le plaisir des beaux chiffres, il était important pour nous de savoir que les supporters enregistrés sont de vraies personnes, pas des bots, pour pouvoir rester en contact avec eux et comprendre dans quelle ville ils sont enregistrés ( afin de prédire l'accomplissement des quotas par région). Par conséquent, l'inscription sur le site était assez difficile et avec la confirmation obligatoire du numéro de téléphone. Afin de ne pas nous tromper nous-mêmes et les autres, nous n'avons enregistré que les personnes ayant rempli l'intégralité du questionnaire et confirmé leur numéro de téléphone en tant que signataires potentiels. Ainsi, au lieu de plus d'un million (le nombre total d'inscriptions) sur la page d'accueil, nous n'avons plus que 706 513 « futures signatures ».

Du point de vue de la construction du site, il s'agit d'un produit assez ordinaire. Le site est réalisé en Python + Django + PostgreSQL, en utilisant un ORM standard et un panneau d'administration standard. Depuis un an et demi, le site a connu plusieurs mises à jour : des rubriques ont été ajoutées, le formulaire d'inscription a changé, les textes et images des pages ont changé. Nous avons essayé de ne pas trop compliquer la conception afin qu'il soit possible de composer des blocs de construction, de sorte que certaines sections soient passées de l'idée au lancement en trois jours.

Sur tout site moderne, environ la moitié des visiteurs proviennent d'appareils mobiles. Nous avons essayé de rendre le site pratique pour tout le monde, donc les mises en page ont été dessinées et composées pour un affichage correct sur n'importe quelle largeur d'écran, à partir de 320px.

Plan du siège

Le seul élément interactif complexe que les visiteurs voient est la carte de la Russie avec le quartier général marqué dessus. Lorsque le nombre de quartiers généraux a dépassé les 50, il est devenu difficile de naviguer sur la carte en raison de la proximité des repères dans la partie européenne du pays. Au départ, la carte a été conçue comme un élément purement décoratif, mais du coup elle s'est remplie de fonctionnalités, donc pour ceux qui ont déjà apprécié le caractère fédéral de la campagne et veulent juste trouver leur ville, nous avons fait un mode liste.

La carte est réalisée à l'aide de l'excellente et polyvalente bibliothèque d3.js. Nous avons décidé d'écrire notre propre script et de ne pas utiliser Google Maps ou Yandex.Maps standard en raison de la projection cartographique. Il existe de nombreuses façons de dérouler l'ellipsoïde de la Terre dans un avion. Dans la projection de Mercator, les objets sont fortement étirés aux latitudes septentrionales, et nous avons besoin de plus d'espace dans les zones où se concentrent les principales grandes villes. De plus, la Russie semble assez étrange dans la projection de Mercator. Nous avons choisi la projection conique d'Albers-Sibérie, plus familière dans les manuels de géographie.

Russie d'une personne saine (projection conique d'Albers) et Russie d'un fumeur (projection de Mercator)

Gestion de contenu

La partie éditoriale du site présente peu d'intérêt. Le panneau d'administration Django habituel est utilisé avec une personnalisation minimale. Avec des ressources de développement limitées, il est plus rentable d'apprendre à plusieurs utilisateurs administrateurs à utiliser un outil standard que de passer du temps à en créer un vraiment pratique.

Certaines solutions qui facilitent la vie de l'éditeur sont issues d'autres projets. Par exemple, un outil de typographie côté client. Notre typographe est pratique car il se connecte facilement à n'importe quel champ de saisie de texte ou de ligne. Les informations sur l'état de l'autotypographie (activée / désactivée) sont stockées sous forme de caractère non imprimable à la fin de la ligne et ne dépendent en aucun cas du backend.

Pour travailler avec le contenu complexe des articles et des nouvelles, nous utilisons un éditeur de blocs, qui est également utilisé sur de nombreux autres projets :

Il existe différents types de blocs, chaque projet a son propre ensemble. Chaque bloc contient du contenu et peut contenir des paramètres. Les données du bloc sont stockées dans la base de données en tant que json et le balisage à l'intérieur du bloc de texte est stocké au format de démarque.

Pour l'affichage, les blocs sont convertis au format requis : HTML pour une publication, texte pour l'indexation, RSS ou XML pour Yandex Zen, JSON pour une application mobile, etc. Ainsi, nous obtenons un résultat prévisible sur n'importe quel appareil avec un formatage de contenu assez complexe.

La première version était basée sur le code de Sir Trevor. Plus tard, lorsqu'il est devenu difficile de maintenir le code spaghetti de Sir Trevor, l'éditeur a été réécrit en React.

Analytique

D'un point de vue technique, la chose la plus intéressante se passe dans le panneau d'administration du site. De là, nous avons regardé le flux des inscriptions.

Au début, l'analytique était plutôt primitive : des graphiques du nombre d'enregistrements de différents types en fonction du temps. Mais nous voulions voir la dynamique par région et suivre l'impact de divers événements sur le nombre d'inscriptions. Voici comment les analyses tant attendues sont apparues :


Cet écran contient des informations récapitulatives pour toute la durée de vie du site, un graphique pour une certaine période et une liste d'événements pour cette période. Vous pouvez sélectionner une sorte de pic sur le graphique et essayer de comprendre quel événement l'a causé. Le plus souvent, il s'agit de la publication d'une autre vidéo de l'enquête sur la chaîne YouTube de Navalny. La plus forte augmentation des signatures a été donnée par des vidéos sur les machinations des responsables régionaux.

Le graphe est réalisé sur d3.js, et le filtrage des événements par heure et siège est implémenté à l'aide de la bibliothèque Crossfilter. Cette solution permet côté client, sans frein d'interface, de fonctionner avec des données d'enregistrement sur un intervalle de plus d'un an par pas de 1 heure. Pour le moment, il s'agit de 12 mégaoctets de données (1,3 Mo en gzip).

Un petit rapport texte avec les indicateurs clés de la base d'inscription et le succès de la veille était automatiquement envoyé chaque jour à tous les participants au projet.

Ville et région

Nous avons également un immense tableau, où les principaux indicateurs de préparation à la collecte de signatures sont énoncés pour chaque région de Russie :

Les chiffres de ce tableau ne voulaient pas converger dans un premier temps. Le montant par ville était nettement inférieur au nombre d'inscriptions. Il s'est avéré qu'en remplissant un questionnaire sur le site, les gens commettent souvent de manière inattendue des erreurs dans le nom de leur ville ou utilisent des noms non standard :

Moscou - 2,5% d'erreurs et 579 orthographes ;
- Saint-Pétersbourg - 12,6% d'erreurs et 767 orthographes ;
- Komsomolsk-on-Amur - plus de 20% d'erreurs et d'abréviations, 75 options.

Une estimation incorrecte du nombre de supporters pourrait conduire à une mauvaise planification du réseau des sièges sociaux et des événements de campagne. J'ai dû réfléchir à la façon de transformer l'entrée utilisateur du nom de la ville en nom standard de la région. Je ne voulais pas utiliser les mécanismes de saisie semi-automatique KLADR ou FIAS pour un formulaire aussi simple. Par conséquent, nous avons pris une liste de 700 des plus grandes villes de Russie, ajouté une liste d'orthographes typiques ("spb", "n-sk") et effectué une recherche approximative pour les classer par distance de Levenshtein (il s'agit d'une mesure de la différence entre deux jeux de caractères).

Nous avons attribué à chaque ville de la liste l'une des trois catégories en fonction de la distance au siège le plus proche : le siège est dans la ville, le siège est proche (agglomération), le siège est éloigné. L'éloignement du siège a été pris en compte pour évaluer le nombre de personnes qui arriveraient au bon moment et apposeraient leur signature. Dans l'analyse, nous avons compté séparément tous les signataires et « disponibles » (courrier confirmé, habite dans une ville avec siège social ou à proximité).

Ce graphique montre comment la campagne est devenue plus régionale au fil du temps. La part des nouvelles immatriculations en provenance de Moscou et de Saint-Pétersbourg est passée de 35 % à 15 %.

SMS et courrier

Une autre difficulté technique était l'envoi de SMS et de lettres. Les passerelles ne sont pas très efficaces pour transmettre des messages, en particulier vers des numéros d'outre-mer. Mais nous voulions obtenir la base de supporters la plus propre et la plus fiable, donc la deuxième partie du formulaire d'inscription nécessitait de confirmer le numéro de téléphone par SMS. Pour un envoi fiable, nous avons alterné trois passerelles : si le message n'était pas remis, le ré-envoi passait par une autre passerelle. De plus, les passerelles individuelles pourraient être désactivées en cas de défaillance de leur côté. Les indicateurs de délivrabilité des codes SMS font partie des paramètres qui ont été surveillés :

Le graphique montre que les passerelles ont échoué deux fois. La part des SMS livrés a chuté de façon spectaculaire le 21 février et les 17 et 18 avril en raison de défaillances dans la file d'attente d'envoi des messages. Et le 15 juillet, nous avons changé la mise en page du formulaire d'inscription, cela se remarque également sur la carte.

Nous envoyons un grand nombre de lettres à une base de données de plus de 700 000 adresses e-mail. Quelqu'un est abonné aux nouvelles, quelqu'un doit être averti de l'événement. De plus, chaque adresse doit être confirmée selon les règles du 2-opt-in (c'est lorsqu'un lien vient dans la première lettre, sur lequel il faut cliquer pour confirmer l'inscription à la newsletter). Au début de la campagne, nous avons utilisé le service ActiveCampaign, mais c'est cher et incroyablement lent. Lorsque la base a dépassé les 300 000 contacts, il est devenu impossible de travailler. Par conséquent, nous avons écrit notre propre service CRM / mailing, ce qui nous permet de former des mailings et des chaînes de lettres en fonction des sélections requises. Mailgun est maintenant utilisé pour livrer des lettres.

Files d'attente de tâches différées

L'envoi de mail ou de SMS via des API tierces est une opération chronophage. Cela doit être fait de manière asynchrone pour éviter de ralentir l'interface utilisateur ou de mettre toute l'application sous charge. Initialement, toutes les tâches asynchrones fonctionnaient via Celery avec Redis en tant que courtier. Chaque lettre ou message SMS créait une tâche dans la file d'attente Celery, après quoi le travailleur libre traitait cette tâche. Mais cette approche s'est avérée peu fiable et trop gourmande en ressources.

Une fois que nous avons reçu plus de 10 mille inscriptions par heure (non, nous n'avons pas été diffusés à la télévision, c'était la campagne +1). 10 Les employés du céleri ne pouvaient pas faire face à cela, les utilisateurs ont commencé à remarquer un retard important dans la réception des SMS et du courrier.

Après ce cas, nous avons abandonné Celery au profit de la file d'attente basée sur PostgreSQL la plus simple. Les tâches de la file d'attente ont été analysées par des "démons" en python, un pour chaque canal de livraison de message. Une fois toutes les 10 secondes, le démon prenait un tas de tâches de la file d'attente et envoyait les données à l'API de mailing en un seul lot. Le regroupement des tâches a considérablement réduit la charge sur le serveur et l'utilisation d'une file d'attente maison a rendu le débogage et la surveillance extrêmement faciles.

Le céleri s'est avéré être un outil trop complexe pour notre tâche. Cela nécessite une configuration et une surveillance réfléchies via des utilitaires externes comme Flower, qui lui-même consomme beaucoup de ressources. Sur d'autres projets, nous essayons d'utiliser une solution plus simple - RQ + Redis.

Comparaison de la complexité de RQ et Celery de l'article sur le travail avec des tâches asynchrones.

Processus de développement

Comment s'organise le processus de création d'un site « Navalny 20 ! 8 » du point de vue des développeurs ? Nous n'adhérons à aucune méthodologie, mais utilisons des approches de différents systèmes. Par exemple, les gestionnaires définissent des tâches dans Trello avec une structure similaire à un tableau kanban, et les développeurs appliquent des pratiques de programmation extrêmes distinctes.

Environ la moitié de l'équipe est basée au bureau de Moscou, tandis que le reste travaille à distance. Les employés de Moscou peuvent participer aux briefings de campagne afin de ne pas mieux travailler pour comprendre la situation dans son ensemble, mais nous discutons séparément des tâches du service informatique. Des appels réguliers permettent à chacun de se synchroniser et de comprendre l'orientation principale du travail à tout moment.

La plupart des participants au projet y travaillent à temps plein, mais certaines tâches ont été effectuées par des développeurs temporairement embauchés par d'autres projets, voire par des bénévoles. Par exemple, le volontaire Ilya a presque entièrement fait une carte du siège pour la page principale.

Le code source est stocké dans un référentiel git sur la plateforme Bitbucket. Une branche distincte est créée pour chaque nouvelle tâche majeure. Nous ne configurons pas de serveur intermédiaire pour chaque branche, ils fusionnent tous en développement pour s'exécuter sur un seul serveur de test. Après les tests, le développeur responsable de la tâche fait une pull request au maître. Le chef d'équipe examine le code et, si tout va bien, démarre le déploiement. Pour les tâches volumineuses, les développeurs décrivent en détail ce qui doit être vérifié et ce qui peut mal tourner lors du déploiement.

Le déploiement est très simple. Nous avons un outil qui répond à un webhook de Bitbucket (ou à un bouton de son interface), prend le code de la branche souhaitée, le copie sur le serveur et y exécute le script de mise à jour. Le script est formaté dans le Makefile.

Lorsque vous lancez "make update", les dépendances, migrations, post-traitements des fichiers statiques sont mis à jour et, si tout s'est bien passé, le serveur uwsgi est redémarré. Nous essayons de faire des migrations pour qu'elles ne cassent pas l'ancien code, donc en cas d'erreurs de déploiement, tout continue de fonctionner.

Le développement a commencé le 18 septembre 2016. Depuis lors, il y a eu 1 228 commits, 200 pull request, déployés plus de 600 fois en production, et il y avait 67 branches dans le référentiel (la plupart sont maintenant fermées).

À propos de la conception

Dans l'équipe de projet, seules deux personnes ont travaillé en permanence sur le design (un directeur artistique avec une fonction produit et un designer), tandis que les deux sont activement impliqués dans d'autres projets de campagne. Par conséquent, l'approche de conception était extrêmement utilitaire.

Dans la conception de produits informatiques, nous sommes toujours guidés par deux grands principes :

1) Les informations destinées à l'utilisateur le plus "paresseux" et non impliqué doivent se trouver à l'endroit le plus visible (par exemple, nous avons déterminé les emplacements initiaux des blocs et des sections sur le site);

2) Moins de personnes utiliseront le produit final, moins nous essayons de le décorer (nous économisons des ressources de développement) et plus nous pouvons permettre d'efforts de saisie pour chaque utilisateur (il est souvent plus efficace de former plusieurs personnes que de passer du temps à introduire de nouveaux fonctionnalités qui économiseront les efforts de l'utilisateur ou vous éviteront des erreurs).

Par conséquent, nos systèmes back-end peu utilisateurs ont tendance à ressembler à un wyframe * vivant, et tout ce qu'un partisan de la campagne rencontre fait partie de la communication visuelle globale, obéissant strictement à l'identité de l'entreprise et au bon sens.

Un système informatique de collecte de signatures est un projet très complexe, multi-composants avec des ressources limitées, donc la plupart du travail des concepteurs s'est déroulé sur papier, dans les réunions et dans les docks Google, et non dans un éditeur graphique (dans notre cas, Sketch) .

Il y a beaucoup de schémas complexes dans le projet que nous voulons juste dessiner, et tous les outils électroniques que nous avons trouvés en déplacement pour dessiner des schémas ne nous convenaient pas. Parfois nous utilisions draw.io, mais le plus souvent nous dessinions directement sur papier. Les diagrammes les plus importants étaient accrochés au tableau du projet. Des "tickets" papier étaient également joints avec des questions à débattre lors des réunions.

A partir de schémas papier et de scripts convenus avec des avocats, nous avons assemblé des prototypes sur marvelapp.com afin de vérifier une nouvelle fois la logique et de s'assurer que rien n'a été oublié. Ce n'est qu'après cela que les mises en page ont été transférées au développement.

Différentes méthodes de recherche et de conception ont été utilisées en fonction de la tâche. Ainsi, avant de faire les analyses tant attendues, nous avons mené une série d'entretiens avec tous les utilisateurs potentiels du système (du chef de cabinet à la personne qui envoie les listes de diffusion) et en fonction de leurs souhaits, nous avons pu constituer un très interface simple qui a longtemps servi de tableau de bord de campagne.

Sur une page, nous avons vu le flux des inscriptions, avons pu voir les événements qui l'influencent et découvrir comment nos supporters sont répartis dans les villes. Nous avons également collecté des notes de ville par le nombre de signataires (cela nous a permis de surveiller l'efficacité du siège et nous a dit si nous avions choisi les bonnes villes pour l'ouverture de nouveau siège) et des analyses tabulaires.

Pour les interfaces de vérification et la collecte des signatures elle-même, la rapidité de l'opérateur était une priorité absolue. La collecte a lieu dans un environnement limité dans le temps, nous avons donc essayé d'économiser chaque seconde et en même temps de réduire le nombre d'erreurs potentielles de l'utilisateur.

Selon nos calculs, avec le nombre de sièges sociaux existant et soumis à un flux continu de personnes, chaque collecteur n'aurait pas dû passer plus de 6 minutes par personne - du « bonjour » à la fin de la procédure de collecte.

La vérification et la collecte de signatures via un système informatique est une procédure entièrement inventée par nous, c'est pourquoi nous avons choisi le test MVP sur de vrais utilisateurs du système comme méthode principale de vérification de nos solutions. Nous avons donc testé le protocole de base et la première interface de vérification sur des employés du siège de Moscou, puis nous nous sommes rendus dans trois villes différentes (Saint-Pétersbourg, Tcheliabinsk et Oulianovsk) pour observer de vrais utilisateurs dans le processus. Pour de tels projets, c'est le meilleur moyen de compiler rapidement une liste d'éléments et de cas d'utilisateurs qui auraient pu être oubliés ou non prévus au stade de la conception et du développement.

Après avoir apporté de petites modifications à l'interface, la vérification a été lancée dans tous les quartiers généraux de la campagne. En conséquence, nous avons réussi à réduire le temps de traitement d'un questionnaire à une minute et demie à deux minutes par personne.

Essai

RobotFramework a été utilisé pour les tests automatisés. Pour couvrir les fonctionnalités les plus critiques du projet, des tests d'acceptation et fonctionnels ont été rédigés, et leur lancement automatique a été configuré. Jenkins a été utilisé comme système CI.

La fonction la plus importante du site est l'enregistrement de l'utilisateur, qui consiste à confirmer le téléphone via un code SMS. Pour tester les messages avec codes, un modem GSM avec une carte SIM de test et Asterisk a été configuré. Le code SMS a été envoyé par courrier, d'où il était déjà disponible pour des tests.

Les bogues trouvés ont été ajoutés à Trello en tant que tâches de développement.

Infrastructure de serveur

Le site Navalny 20!8 continue de fonctionner et devient progressivement le lieu de la campagne de grève des électeurs, donc l'embargo sur l'information n'est pas encore levé, et l'histoire sera courte. Le côté serveur se compose de trois niveaux : le backend, les proxys de mise en cache et les serveurs de périphérie. Toutes les configurations sont gérées via chef, de sorte qu'un serveur avec n'importe quel rôle peut être rapidement mis en place sur une nouvelle machine virtuelle.

Le backend exécute une base de données et des instances d'application, chaque application sur sa propre machine virtuelle et avec sa propre adresse IP. Tous les serveurs existent dans plusieurs instances, et la base de données est répliquée en mode maître-esclave sur une autre machine.

Varnish est installé sur le serveur proxy, qui met en cache les demandes vers des adresses spécifiques et diverses restrictions dépendantes des URL. Si le backend échoue, le site peut fonctionner indéfiniment à partir du serveur proxy, seul le mécanisme d'enregistrement de l'utilisateur se brisera.

Les serveurs Edge sont engagés dans la mise en cache statique et la terminaison SSL (le trafic supplémentaire passe par le réseau VPN). L'essence de ces serveurs est de répartir l'essentiel du trafic et de protéger le reste de l'infrastructure des attaques. Ce sont des machines virtuelles faibles avec un canal gigabit dans différents centres de données. La charge est répartie par équilibrage DNS. Les serveurs Edge sont limités à un minimum de configuration et peuvent être facilement activés si nécessaire en quelques minutes. Le trafic maximum utilisable que nous avions sur les serveurs de périphérie était de 5 Gbps pendant plusieurs heures.

Les images, les styles, le javascript, les données json sont stockés de manière à ce que le nom du fichier inclue un hachage du contenu de ce fichier (par exemple, style.28fa1c7b1761.css), de sorte que tous ces fichiers peuvent être mis en cache de manière permanente sur le serveur et dans le navigateur. La majeure partie du trafic est envoyée depuis les serveurs de périphérie. De plus, seules les demandes de pages de contenu passent, et cela représente environ 25 fois moins de données.

Parfois, CloudFlare se connecte à la place des serveurs de périphérie, mais nous essayons de revenir sur nos serveurs, car CloudFlare n'a pas toujours une bonne disponibilité depuis la Russie. Certains fournisseurs, même les plus gros, commencent régulièrement à bloquer leur ip (traces de Roskomnadzor).

Conclusion

Recueillir des signatures dans le style traditionnel (sans système informatique particulier, avec papier, stylo et tableaux dans Excel) c'est comme voler en ballon vers la lune : oui, si vous prenez suffisamment de ballons, vous pouvez même décoller et vous cacher dans les nuages , mais atteindre le but de cette manière est physiquement impossible.

Afin de recueillir de telles signatures que la commission électorale devrait accepter même d'un candidat indésirable, nous avons commencé à créer cette infrastructure complexe. Dans ce chapitre, nous avons parlé de la tâche elle-même, qui nous est confiée, et de la préparation de sa solution.

Le chapitre suivant traite du choix et de la configuration des équipements du réseau du siège, du développement de votre propre scanner de documents et de l'organisation de la vidéosurveillance des locaux du siège.

Le troisième chapitre décrira le processus de création d'applications de collecte de signatures et tout ce qui concerne le travail avec des listes d'abonnement physiques.

Le quatrième chapitre parle de la gestion du projet, de l'équipe, du calendrier et un peu sur les résultats.

Balises : ajouter des balises

Campagne +1. Collecter 1 000 000 de signatures

Il nous a fallu 4 mois pour récolter les 300 000 signatures nécessaires pour désigner un candidat à l'élection présidentielle de 2018. Notre nouvel objectif est le million et nous lançons la campagne +1.

Selon les lois de la Fédération de Russie, pour s'inscrire en tant que candidat à la présidence, un demandeur doit soumettre 300 000 signatures confirmées à la Commission électorale centrale, qui doivent être recueillies dans un délai très court. La collecte ne prend que 40 jours, et dans notre cas - encore moins, car ces 40 jours tombent les vacances du Nouvel An. En fait, il s'agit d'un autre obstacle artificiel créé par les autorités. En outre, les signatures doivent être recueillies dans 40 régions du pays - pas plus de 7 500 de chaque entité constitutive de la Fédération de Russie.

Photo : Evgeny Feldman

Afin de soumettre les 300 000 requis à la CEC à temps, il faut savoir que dans toutes les régions où notre siège social sera ouvert, nous pouvons compter sur 7 500 signatures. Et qu'ils seront récupérés à temps et dans le plein respect de la procédure.

Nous l'avons vu plus d'une fois de la part des candidats que le Kremlin veut voir aux élections, et ils prendront le papier découpé comme signature. Nos signatures seront vues au microscope

Alexeï Navalny

Photo : Evgeny Feldman

Très probablement, la CEC étudiera les signatures soumises par le quartier général de Navalny avec une attention particulière - par conséquent, nous devons nous assurer autant que possible et collecter beaucoup plus que ce qui est prescrit par le protocole. Nous collectons non seulement les adresses e-mail, mais aussi les numéros de téléphone et de courts questionnaires de tous ceux qui sont prêts à soutenir la nomination d'Alexei Navalny. Ceci est fait pour que nous sachions exactement dans quelles régions il y a nos partisans et combien ils sont.

Il y a une mer de gens autour de vous qui veulent soutenir un candidat indépendant de l'opposition. Au moins pour des raisons de concurrence dans les élections. Même les Zaputins soutiennent le concours, ils veulent voir des candidats indépendants dans leurs bulletins

Alexeï Navalny

Notre prochain objectif est le million de signatures, ce qui nous garantira les 300 000 dont nous avons besoin à la fin de l'année. Pour ce faire, nous lançons une campagne « +1 » et appelons toutes les personnes déjà inscrites sur le site à convaincre au moins une personne supplémentaire de s'inscrire. Mieux que deux ou cinq, et puis le million requis sera atteint d'ici l'été.

Maintenant, nous avons vraiment besoin de votre aide. Veuillez consacrer 10 à 15 minutes de votre temps et persuader un de vos amis, parents ou collègues de travail de signer.

Photo : Evgeny Feldman

Écrivez une lettre ou un message à quelques connaissances sur un réseau social :
"Hey. J'ai apposé ma signature pour la nomination de Navalny comme candidat. Pourriez-vous le mettre aussi ? Ce sera juste"

Alexeï Navalny

Les 385 531 personnes déjà signées sont une force terrible. Profitons-en au maximum. Rejoignez la campagne +1.

Le fonctionnaire, déçu par le blogueur, a évoqué la situation difficile au siège.

Au siège du blogueur Alexeï Navalny, qui continue de récolter des fonds pour la campagne présidentielle, malgré l'interdiction de la CEC et les clarifications de la Cour constitutionnelle, là encore la confusion. Un récent fonctionnaire de FBK, militant des droits de l'homme, écrit sur la crise managériale dans les rangs de la protestation sur sa page Facebook Vitaly Serkuanov... Serukanov a expliqué son départ de l'équipe de Navalny par "le besoin de respect de soi".

Selon Vitaly Serkuanov, le siège de Navalny n'est pas en mesure de répondre aux demandes des donateurs de fonds et de publier les statistiques des signatures recueillies dans les régions. La raison de l'activiste est évidente : le blogueur manque de 250 000 voix pour nommer, mais obtenir le nombre nécessaire de partisans avant la date limite sera une tâche écrasante. La date limite pour la CEC de soumettre les documents pour l'inscription se termine le 31 janvier 2018 à 18h00. C'est pourquoi, comme le note Serukanov, l'équipe de Navalny change de tactique selon le principe Niccolo Machiavel"Fin justifie les moyens". Les rassemblements non autorisés du 24 décembre sont prévus comme une étape difficile dans la transition de l'échec de la campagne à l'étape d'un futur boycott des élections.

«Volkov (le chef du quartier général de Navalny) n'a rien proposé de nouveau, sauf à travers une mer de détentions, d'arrestations et de résonances négatives, pour éviter de répondre aux questions sur les raisons de l'échec de la campagne, principalement tactiques. Suscitez la sympathie des masses, ripostez avec des arrestations administratives, tandis que les participants ordinaires recevront des condamnations pénales », écrit Serukanov.

Avocat Artisanat d'Ilya, qui a mené une enquête indépendante sur les activités de FBK, dans un commentaire Agence de presse "La politique aujourd'hui" a noté que le nombre de partisans désabusés de Navalny augmente naturellement.

L'interlocuteur de l'agence comprend d'anciens bénévoles de la même catégorie. Alexandre Turovsky et Denis Lebedev... Le premier a été blessé lors d'une perquisition au siège du blogueur, mais Navalny n'a pas pris la peine de citer son nom. Une histoire similaire s'est produite avec Lebedev trois ans plus tôt. Il a eu une jambe cassée lors d'un des voyages sur les affaires de FBK, mais le fonds a fait comprendre à l'activiste qu'ils n'allaient pas s'occuper de ses problèmes.

Craft est sûr que le quartier général de Navalny est bien conscient qu'il ne sera pas en mesure de rendre compte des dons dépensés et de recueillir le nombre requis de signatures.

« Il n'y a vraiment pas de soutien. Cette situation montre qu'ils ne peuvent organiser le travail élémentaire, car ces personnes n'ont jamais travaillé nulle part et ne gagnaient pas d'argent par un travail honnête. Ni Volkov ni Navalny. Par conséquent, ils sont attirés l'un par l'autre. S'ils avaient eu le niveau de soutien nécessaire, alors les gens seraient tombés sans s'arrêter. Nous collections ces signatures, même si Volkov et Navalny n'avaient aucun talent, mais comme ils sont également médiocres et qu'il n'y a pas de niveau de soutien, nous obtenons ce que nous obtenons », a commenté Craft.

La liste d'abonnement est le document principal de notre système. La première chose que vous voulez faire pour travailler avec une grande collection d'objets est de leur attribuer un identifiant unique afin d'associer chaque objet à un enregistrement dans la base de données. Mais la forme de la liste de signature est très strictement énoncée dans la loi, toute violation de celle-ci est une raison pour rejeter toutes les signatures du candidat en général. Sur la feuille, qui est soumise à la commission électorale, aucune marque ni aucun symbole inutiles ne sont autorisés.

Lors de la collecte des signatures à Novossibirsk, nous avons placé chaque feuille dans un multifor (« fichier » transparent), sur lequel l'ID de la feuille et toutes les notes de service ont été écrits avec un marqueur. Cela a fonctionné pour quatre mille feuilles, mais ne fonctionnera pas pour des centaines de milliers. Cette fois, nous avons trouvé que l'utilisation de multiformes était une solution peu fiable et peu pratique.

Les avocats ont inventé une méthode qui nous a permis d'identifier chaque feuille et de ne pas violer la forme de la feuille de signature. La loi ne dit rien sur la taille physique de la liste d'abonnement. Cela nous a permis de concevoir la feuille de manière à ce que les codes d'identification soient appliqués sur sa partie supérieure, et soient simplement découpés avant d'être soumis à la commission électorale.

Le code feuille est composé de 6 caractères. Vous pouvez utiliser des chiffres et des lettres de l'alphabet latin, qui ont des analogues graphiques dans l'alphabet cyrillique (sous des formes que vous pouvez écrire dans n'importe quelle disposition). Pour plus de commodité, ajout de séparateurs : 91-X7-BA.

Un même identifiant est imprimé sous la forme d'un QR code pour une reconnaissance automatique à différentes étapes du travail. Les codes QR ont surpassé tous les autres types de codes-barres en termes de fiabilité et de vitesse de reconnaissance.

La vie du siège social est pleine de difficultés, c'est pourquoi les codes QR ont été minutieusement testés dans diverses situations stressantes pour les feuilles ...

... et a décidé que trois codes suffiraient pour traiter n'importe quelle feuille vivante.

Les avocats et les concepteurs ont travaillé dur pour que la mise en page soit conforme à la loi et au bon sens. Le nombre de signatures sur la feuille a été testé séparément. Peu de signatures - trop de feuilles, beaucoup de gribouillages inutiles (données du collecteur et du syndic), plus d'erreurs dans l'inscription de la certification. Beaucoup de signatures - il n'est pas pratique de saisir les données des électeurs, il y a plus d'erreurs dans les lignes de signature. Après avoir expérimenté des prototypes, ils ont opté pour cinq signatures.

Chaque feuille (plus précisément l'identifiant de la feuille) est créée dans la base de données, après quoi elle peut être imprimée sur du papier A4. Mais vous ne pouvez pas simplement récupérer et imprimer une feuille sur l'imprimante la plus proche. Selon la loi, la production des listes de signatures doit être payée à partir du compte électoral du candidat. Ils sont généralement fabriqués par un entrepreneur externe. Par conséquent, nous avons rendu le côté technique aussi convivial et flexible que possible. Les feuilles sont soit imprimées directement à partir du navigateur, soit préenregistrées dans un fichier PDF de plusieurs pages qui peut être transféré à l'entrepreneur de n'importe quelle manière pratique.

Chouette : préparation à la collecte de signatures

La collecte des signatures physiques pour les listes de souscription ne peut commencer qu'après la désignation d'un candidat et l'ouverture d'un compte électoral spécial. La loi donne très peu de temps pour cela. Il était important pour nous de faire un maximum d'opérations en amont afin de déboguer tous les processus et après l'annonce officielle des élections pour accélérer le travail au maximum. Pour une vérification préalable des données de nos supporters, pour la formation du siège et pour tester les mécanismes de collecte, nous avons lancé une procédure de vérification.

La vérification est une version bêta de la collecte de signature : dans un vrai siège social, avec le même équipement, avec les mêmes contrôles stricts des documents, mais sans saisir la signature sur une feuille de papier. Pour travailler avec les données des personnes vérifiées, l'application Sych a été développée.

Composition de chouette

Backend API RESTful : Python 3.6, aiohttp, aiohttp_admin, SQLAlchemy.
Bases de données : PostgreSQL, Redis.
Démon de notifications.
Démon de reconnaissance du numéro de passeport.
Démon pour la construction d'analyses.
Service de contrôle d'un passeport par son numéro.
Version boîte de Cladr-API pour travailler avec des adresses (PHP 5.6 + MongoDB).

Nous avons décidé de faire un backend séparé pour Sych avec une API RESTful, car il était prévu de l'intégrer à plusieurs services, dont le site Navalny 20! 8. Une base de données PostgreSQL distincte et Redis pour la mise en cache ont été utilisés comme stockage. Pour gérer les utilisateurs, la bibliothèque aiohttp_admin est apparue, que nous avons modifiée pour répondre à nos besoins.

L'interface interne de l'opérateur est une forme étape par étape de numérisation d'un passeport et de saisie de données personnelles. En raison du grand nombre d'états possibles, cette forme a été écrite en React.

L'interaction avec le site Navalny 20!8 s'est effectuée via l'API, qui est protégée par un token et n'est accessible que sur le réseau local entre les machines virtuelles.

Inscription pour vérification

Afin de répartir uniformément la charge sur le siège social dans le temps, ils ont créé un enregistrement pour vérification. Après s'être inscrite sur le site, une personne a eu accès à l'interface d'enregistrement, où elle a choisi un siège et une heure convenables.

Pour contrôler la charge de travail, gérer les dossiers et le calendrier, nous avons développé une interface distincte disponible pour le responsable régional et le coordinateur du siège :

Si une urgence se produit au siège, le coordinateur peut annuler massivement les futurs enregistrements pour vérification. Cependant, il ne peut pas le faire seul - il doit demander le code de confirmation d'annulation au responsable régional. Nous avons dû utiliser cette option plusieurs fois.

Notifications

Un système de notification de branchement a été mis en place dans Sycha. Le signataire aurait dû recevoir des notifications par courrier lorsqu'il s'est inscrit pour vérification, a raté l'enregistrement, une semaine après l'annulation de l'enregistrement, après une vérification réussie, après l'annulation de l'enregistrement par le siège et dans plusieurs autres cas.

Des notifications par SMS ont été envoyées pour rappeler le rendez-vous trois heures à l'avance et pour informer que le siège avait annulé le rendez-vous. La file d'attente des notifications s'est faite selon le même principe que sur le site Navalny 20!8 : des tableaux dans la base de données avec des messages qui ont été envoyés en groupe via des passerelles mail et SMS.

Reconnaissance des données du passeport

Pour évaluer le travail des opérateurs et déterminer le pourcentage d'erreurs lors de la saisie des données, j'ai souhaité disposer d'une reconnaissance de scan supplémentaire. Il était impossible de faire une reconnaissance automatique fiable en raison de la variabilité des passeports, donc deux options ont été envisagées : envoyer des scans à Yandex.Toloka afin qu'ils puissent être reconnus par ses utilisateurs, ou prendre un groupe de volontaires pour le faire au bureau. Mais la question de la sécurité des données personnelles a arrêté les deux options et nous n'avons laissé la reconnaissance automatique que pour le numéro de passeport.

Sych Analytics

Au cours de la vérification, nous avons non seulement clarifié et vérifié notre base de partisans, mais nous avons également testé le travail du siège, des infrastructures, des équipements et des mécanismes de collecte de signatures. Pour surveiller le processus et le corriger, nous avons créé une analyse simple.

Puisqu'il existe trois niveaux de gestion des processus à l'administration centrale - les coordonnateurs de l'administration centrale (responsables du travail d'une administration centrale), les gestionnaires régionaux (surveillant un groupe d'administrations centrales dans plusieurs régions) et la direction de l'administration centrale fédérale (surveillant tout et tout le monde) - le système regroupé les données de différentes manières pour chaque catégorie d'utilisateurs.

Nous avons montré la plupart des détails au coordinateur du siège. Il a vu les statistiques de tous les opérateurs et la dynamique des indicateurs clés et a pu prendre des décisions de gestion en fonction de celles-ci : affecter plus ou moins d'opérateurs, augmenter la notification, modifier l'horaire de travail le week-end, licencier ou rééduquer les employés qui se trompent souvent, etc. .

Nous avons épargné au responsable régional des détails inutiles et, sur le premier écran, il n'a vu que les éléments les plus importants de son groupe de sièges sociaux : les indicateurs clés, les évaluations et les problèmes de siège social (marqués d'un rouge alarmant). Nous avons classé les sièges sociaux à « problème » avec N % en dessous de la moyenne, chroniquement sous-utilisés (ils avaient besoin d'une notification supplémentaire) et surchargés en termes de nombre d'entrées (cela signifiait que toutes les personnes ne pouvaient pas s'inscrire et que le nombre d'opérateurs devait être augmenté ).

Pour mieux comprendre le problème détecté, le responsable régional peut facilement afficher des statistiques détaillées pour chaque siège et voir toutes les données disponibles pour le coordinateur.

Il était important que le siège fédéral ait immédiatement une vue d'ensemble. Nous avons donc collecté les mesures clés de la campagne sur un seul écran et créé un tableau récapitulatif pour toutes les villes où la vérification a lieu. Dans le tableau, vous pouvez sélectionner le siège qui vous intéresse pour afficher l'ensemble complet des données le concernant.

Au total, plus de 50 indicateurs ont été affichés dans les analyses. SQLAlchemy était suffisamment flexible pour ne jamais passer au SQL pur et pour garder le code lisible. Pour les indicateurs les plus laborieux, nous avons d'abord fait la mise en cache dans Redis, mais il s'est avéré plus facile de les calculer périodiquement en arrière-plan et, sur demande, de les extraire du fichier.

Reaper-2018 : un système de collecte de signatures

Parallèlement au processus de vérification, un système de collecte de signatures a été développé. L'architecture du système utilisé à Novossibirsk et capable de travailler avec des objets physiques - feuilles et signatures - a été prise comme base.

Du côté du backend, Reaper-2018 est l'héritier de l'ancien Reaper, mais il a reçu l'interface opérateur du système de vérification. Certains écrans ont été améliorés après analyse des retours sur le travail de Sych. De plus, des interfaces ont été ajoutées pour plusieurs niveaux de validation des données et pour contrôler le mouvement des feuilles.

Interface opérateur

Dans le processus d'obtention d'une signature, l'opérateur doit scanner le passeport de l'électeur, remplir un questionnaire (en tenant compte du fait que l'adresse indiquée dans le cachet d'enregistrement peut ne pas du tout être écrite dans le format requis) et saisir les données sur l'abonnement liste, en suivant les instructions du système. Mais d'abord, nous devons vérifier si l'électeur remplit trois conditions clés :

1. Au moment de l'élection, il doit être âgé de plus de 18 ans.
2. Si l'électeur a 20 ou 45 ans, il doit avoir un nouveau passeport.
3. Le passeport ne doit pas être répertorié comme invalide.

Vérifier la base de données des passeports invalides est une opération simple, mais elle a aussi ses propres subtilités. La base est diffusée par le ministère de l'Intérieur sur son site Internet. Auparavant, avant les élections, pour une raison quelconque, ils ont désactivé la possibilité de télécharger cette base de données, nous avons donc commencé à télécharger la version actuelle de la base de données quotidiennement à l'avance (n'oubliez pas de la désactiver).

Désormais, la base de données contient plus de 110 millions d'entrées (séries et numéros de passeports). Pour une recherche rapide avec une petite base de données et des index, le schéma suivant a été inventé : une table avec un million d'enregistrements est créée dans PostgreSQL, la clé primaire dans laquelle se trouve le numéro de passeport (de 0 à 999999), et le deuxième champ contient tous la série des passeports invalides pour ce numéro. Pour réduire la taille de la série, ils ont été convertis au format binaire (deux octets chacun) et compressés à l'aide de zlib (je voulais juste). Initialement, la base de données prend environ 1 Go hors index. Après traitement, 260 Mo sont obtenus avec l'index. Un enregistrement est vérifié en moyenne en 15 ms.

0,6% des passeports des personnes en cours de vérification ont été trouvés dans la base de données des passeports invalides. Cela signifie que sans un tel contrôle, nous aurions dépensé 12% de la limite de signatures invalides uniquement sur ce type d'erreur.

0,88% des passeports ne nous convenaient pas, car le citoyen a 20 ou 45 ans, mais il n'a pas encore remplacé le passeport. Et c'est encore 18% de la limite de signature invalide.

Il y a 4 colonnes dans la liste d'abonnement, remplies par l'opérateur : nom complet, année de naissance, numéro de passeport et adresse d'enregistrement permanent. Toutes ces données ont été transmises au Reaper pour vérifier et corriger d'éventuelles erreurs. Par exemple, dans les champs du nom et du patronyme, la recherche de fautes de frappe fonctionne :

Pour les conseils de nom, l'API dispose d'une méthode qui compare une valeur à une grande liste et renvoie trois options :

Tout va bien, il y a un tel nom ;
- il existe un nom similaire (tel ou tel) ;
- nom inconnu (nom rare ou fautes d'orthographe graves).

Une histoire distincte est la lettre "ё". Il existe des passeports dans lesquels il est utilisé, mais dans la plupart des cas, il est remplacé par "e", nous affichons donc un avertissement s'il y a "e" dans certains champs des données du passeport.

Le système ne corrige rien par lui-même, il informe seulement. L'exploitant et les inspecteurs doivent prêter attention à de tels cas et prendre la bonne décision.

Numérisation de documents

Pour obtenir des images de documents, nous utilisons des scanners de notre propre production, et en tant que poste opérateur - Raspberry Pi. Ceci est décrit en détail dans le deuxième chapitre.

Cette image n'est pas un scan d'un passeport, mais est collectée dans un éditeur graphique à partir de données aléatoires.

L'image est reçue côté client de l'API HTML 5 Canvas et envoyée au serveur sous forme de chaîne base64 contenant un JPEG. Du point de vue frontal, les scanners peuvent fonctionner selon deux modes : caméra Web USB et streaming vidéo depuis un ordinateur sur un sous-réseau local. Owl ne fonctionne qu'avec les caméras USB et Reaper 2018 vous permet de basculer entre les modes. L'opérateur choisit lui-même le scanner à utiliser.

Il y avait un petit problème avec le choix du flux vidéo des ordinateurs voisins : les tables et les scanners peuvent être déplacés, et les opérateurs peuvent changer de siège. Nous ne savons pas quel scanner sera à côté de l'opérateur la prochaine fois. Je devais parcourir le sous-réseau du siège et donner à l'opérateur la possibilité de choisir l'un des scanners en direct. Mais il s'est avéré que le serveur de diffusion vidéo du scanner, bien qu'il ait défini les en-têtes CORS corrects (Access-Control-Allow-Origin : *), ne répondait pas aux requêtes OPTIONS. Le navigateur interdisait les requêtes ajax aux hôtes voisins, ce qui rendait impossible l'utilisation de jQuery.ajax () standard pour les recherches. Les demandes JSONP n'ont pas non plus aidé, car elles ne pouvaient pas être annulées par programmation, et plusieurs dizaines de demandes en attente ont complètement bloqué la page. Les photos ont aidé à résoudre le problème. Nous avons ajouté des balises au DOM et leur avons attribué le src du flux vidéo. Si l'image était redimensionnée en fonction de la taille du flux, alors le flux était considéré comme vivant et montré à l'opérateur.

L'affichage du flux vidéo dans le navigateur charge considérablement les modestes processeurs Raspberry Pi, nous avons donc dû faire un « économiseur d'écran » : après 5 minutes d'inactivité, le navigateur met la diffusion en pause.

Il est important pour nous de sélectionner des informations à jour sur le lieu d'enregistrement. Il peut y avoir 6 tampons sur une feuille de passeport, mais un seul est nécessaire. L'interface propose de le sélectionner à l'aide des flèches du clavier ou en cliquant sur le tampon souhaité sur l'aperçu.

Il n'y a peut-être pas encore d'inscription. Ces électeurs sont enregistrés sur une liste de signature distincte avec une région et une adresse vides, et l'analyse d'inscription est ignorée.

Adresses de traitement

La partie la plus difficile pour remplir une liste d'inscription est l'adresse de l'électeur. Plus de la moitié des erreurs qui invalident la signature sont liées à l'adresse.

Il existe une longue liste d'exigences légales pour l'adresse d'enregistrement. Par exemple:

Il doit s'agir d'une adresse selon la base FIAS (système d'adressage d'information fédéral) ;
- pour les rues renommées, vous devez indiquer les nouveaux noms, même si l'ancien figurait dans le passeport ;
- la loi établit un certain format pour la hiérarchie des objets d'adresse qui doivent être enregistrés (par exemple, une zone urbaine ne peut pas être indiquée).

Ce ne sont que des points de base, mais il y a aussi beaucoup de petites choses, dont la liste s'est reconstituée à chaque interaction avec la commission électorale. Le non-respect des exigences, même mineures, est une raison pour laquelle la commission électorale n'accepte pas la signature.

Lors de la collecte des signatures à Novossibirsk, environ 3,5% des signatures ont été invalidées en raison de réclamations contre le champ « adresse ». Et c'est 70 % de la limite qui est fixée pour les signatures pour la nomination d'un candidat à la présidentielle.

Afin de répondre à toutes les exigences, nous devons passer chaque adresse à travers un ordinateur afin de former le format correct et indiquer au collecteur, jusqu'à un symbole, ce qu'il doit inscrire dans la liste d'abonnement.

Dans la mesure du possible, nous essayons de ne pas utiliser l'API de services tiers, afin de ne pas donner de données sur nos utilisateurs et de ne pas être dans une situation où l'API est soudainement désactivée au moment le plus crucial. Travailler avec des adresses est une fonction critique pour la collecte de signatures, nous avons donc dû créer notre propre API pour la base de données FIAS.

La base de données FIAS ne contient pas encore suffisamment d'informations complètes et de haute qualité sur les maisons et les appartements, nous nous sommes donc arrêtés au niveau de la rue. Sous cette forme, la base de données avec toutes les constructions supplémentaires pèse environ 2 Go et vit assez confortablement sous la forme de PostgreSQL. Des scripts modifiés du référentiel fias2pgsql ont été utilisés pour l'importation.

Pour la forme universelle de saisie d'adresse entièrement russe, vous ne pouvez pas simplement créer les champs "ville", "rue", "maison", car il existe de nombreux formats d'adresse et types d'objets d'adresse différents. Un exemple bien connu d'un format inhabituel est Zelenograd, qui a des maisons sans nom de rue. Mais, croyez-moi, à l'échelle nationale, c'est un cas assez trivial.

Après une série d'expérimentations, nous avons opté pour un formulaire à trois champs :

Le sujet de la Fédération de Russie est toujours là, c'est le domaine le plus compréhensible ;
- Adresse FIAS - un champ avec saisie semi-automatique aux adresses de la région donnée au sein de FIAS ;
- maison / immeuble / appartement - une ligne où les données sont copiées exactement conformément au cachet d'enregistrement permanent.

Les avocats ont établi un tableau de conversions d'adresses, à l'aide duquel nous avons mis les adresses FIAS dans un format correspondant à la législation électorale. Le plus souvent, il était nécessaire d'exclure l'un des éléments d'adresse. Certaines adresses ont été entièrement exclues (coopératives de garage, cours et autres objets similaires). Le service informatique a reçu un tableau de règles et le service juridique a reçu 10 exemples de réponse pour chacun des 44 types d'adresses.

Après plusieurs de ces itérations, la base de données était prête à fonctionner.

La partie technique de la tâche consistait à organiser une recherche pratique et rapide avec saisie semi-automatique, qui supportera une charge de 1 million de requêtes par jour. Sphinx a été utilisé comme moteur de recherche. La demande est débarrassée des caractères inutiles et transmise à Sphinx, et elle renvoie les adresses complètes des objets, en les classant selon les règles spécifiées.

Sphinx indexe un champ d'adresse XML. Ce format de stockage s'est avéré pratique dans la mesure où toutes les métadonnées peuvent être cachées dans des attributs XML, que Sphinx n'utilise pas pour la recherche, mais conserve en mémoire et renvoie les résultats sans accès supplémentaire à la base de données. Quelque part sur le frontend, ces attributs sont utilisés pour former une jolie barre d'adresse.

La solution s'est avérée pratique et rapide. Une requête à l'API de suggestion est terminée en 15 à 20 ms, le backend gère silencieusement 300 connexions simultanées sur une machine virtuelle pas très puissante.

Remplir la liste d'abonnement

Les signatures doivent être inscrites sur les feuilles de l'entité constitutive de la Fédération de Russie à laquelle appartient l'adresse d'inscription permanente du citoyen (ou sur des feuilles spéciales sans région, s'il n'y a pas d'inscription). La faucheuse indique à l'opérateur quelle feuille de région prendre, et ne permet pas d'inscrire la signature sur la feuille d'une autre région.

Imaginez que vous vouliez résoudre un tel problème sans ordinateur, en collectant des signatures dans une gare, où il y aura beaucoup de gens de différentes régions et il n'y aura pas de classeur avec des feuilles blanches triées par région. Dans environ un tiers des passeports, le tampon d'enregistrement ne contient pas le nom de la région, et les passants ne connaissent pas les règles du jeu et peuvent facilement confondre quelque chose. Cela semble être la source d'un grand nombre d'erreurs, ce qui est inacceptable sous la limite légale de 5%.

Remplir la liste d'abonnement est une procédure complexe et responsable. La feuille contient des lignes de signatures, l'attestation du collectionneur et la signature du syndic. Tous ces blocs doivent être complétés conformément à des exigences formelles strictes. A chaque étape du remplissage, des erreurs sont possibles qui peuvent rendre invalide toute la feuille ou une partie des signatures.

Nous avons développé des scénarios pour le travail de l'opérateur qui réduisent la probabilité d'erreurs courantes. Les inscriptions confirmatives sur les feuilles de la région « d'origine » (environ 80 % des signatures proviendront de la région où est situé le siège) sont remplies au préalable par le collecteur, dans le calme. Pour tous les blocs de la feuille, le Reaper montre exactement comment ils doivent être remplis.

L'interface de remplissage simule une véritable liste d'abonnement, qui se trouve actuellement sur la table devant l'opérateur. Sont affichés les lignes occupées, les colonnes à remplir, le numéro de feuille, les grandes données à saisir.

Pour une ligne remplie, l'opérateur doit indiquer son statut (il n'est pas toujours possible de remplir la ligne avec succès du premier coup). Chaque correction et suppression doit correspondre à une note du collecteur sur la fiche et au statut correspondant dans la base de données.

Après avoir rempli l'intégralité de la fiche, la date et la signature du collecteur y sont apposées. La fiche est soumise pour vérification.

Vérification des signatures, travail avec feuilles au siège

A la fin de chaque journée de travail, toutes les feuilles avec signatures vont au contrôle, qui a lieu tard le soir ou la nuit (nos sièges sociaux sont petits, il n'y a tout simplement pas de place pour mener tous les processus en parallèle). Le vérificateur (il est le confident du candidat) parcourt chaque feuille et chaque signature, la compare avec des fragments de pages de passeport numérisées, vérifie tous les éléments significatifs par rapport à la liste de contrôle. Si des erreurs sont trouvées, cela est noté dans une interface spéciale.

Le dossier de certification est vérifié séparément. Les erreurs de vérification sont particulièrement dangereuses, car elles affectent la feuille entière à la fois. Ces erreurs représentent environ 9 % de toutes les signatures invalides.

Certaines erreurs peuvent être corrigées, mais seul le collecteur peut apporter des corrections aux lignes de signature, et il n'est pas au siège le soir / la nuit, donc toutes les informations nécessaires à la correction sont transmises sous forme électronique. Pour comprendre le contexte, vous devez voir tout ce qui s'est passé avec la ligne plus tôt. C'est ainsi qu'est apparue une « conversation » entre l'inspecteur, l'opérateur et l'avocat.

Tous les noms et autres données de l'image sont fictifs.

Si les erreurs semblent fatales ou s'il y a des doutes, la fiche est envoyée à un avocat. Si les signatures ne contiennent pas d'erreurs ou que toutes les corrections ont déjà été apportées, le vérificateur signe la personne habilitée et envoie la feuille pour envoi au siège central.

Les émojis et la neurophysiologie du bonheur

Pour sélectionner rapidement et précisément l'état de la chaîne cochée, nous avons utilisé des boutons sous forme d'émoticônes. Il y a des raisons neurophysiologiques profondes à cela. Le système visuel du cerveau contient d'anciens mécanismes de bas niveau qui répondent à certaines images. Le système visuel répond le plus rapidement aux segments de lignes droites d'orientations différentes, car les lignes sont facilement détectées par le cortex visuel primaire. Le cortex visuel secondaire reconnaît des formes géométriques simples (cela doit être appris) et un contour du visage. De plus, non seulement un visage est reconnu, mais des expressions faciales de base. C'est-à-dire des émoticônes. Comme la reconnaissance en ligne droite, il s'agit d'une capacité innée. Grâce à ce système de bas niveau, les émoticônes sont reconnues beaucoup plus rapidement et avec plus de précision que le texte.

Les icônes sous forme d'émoticônes correspondent bien à la signification des statuts que le réviseur peut attribuer aux signatures : « bon », « il y a des problèmes », « mauvais ». Il y avait quelques doutes avec l'émoticône « montrer un avocat », mais nous nous en sommes occupés.

Il existe également une opinion selon laquelle les émoticônes humanisent l'interface et améliorent ainsi légèrement la vie de l'opérateur. Ceci est important car les opérateurs devaient passer de longues heures à travailler avec notre système et ne pas perdre leur vigilance.

Envoi de feuilles

Les feuilles finies sont envoyées au siège central chaque jour. Il peut y avoir plusieurs feuilles, plusieurs centaines. Nous voulons savoir exactement quelles feuilles sont prêtes et ont quitté le siège, mais les enregistrer manuellement est long et peu fiable. Une application mobile a été écrite pour prendre en compte les feuilles envoyées.

Il dispose d'un mode qui permet de scanner rapidement les codes de centaines de fiches et informe s'ils tentent d'envoyer une fiche par erreur, alors qu'il n'a pas encore franchi toutes les étapes de traitement au siège. Il faut 1 à 2 secondes pour numériser une feuille.

Après numérisation, les feuilles sont emballées et envoyées à Moscou.

Détails du formulaire

Toutes les données du passeport sont saisies et affichées dans la police à espacement fixe Source Code Pro Regular. Il est facile de distinguer le zéro de la lettre "O", et les caractères sont assez similaires à ceux couramment utilisés dans les passeports modernes.

Tous les formulaires sont conçus de manière à ce que les onglets puissent être basculés entre les champs et les boutons principaux. Le focus d'entrée est sur le champ requis non seulement lors du chargement de la page, mais également après la fermeture du message d'erreur. Les boîtes de dialogue modales capturent le focus afin que la commutation ne se produise qu'entre leurs commandes.

Tous les boutons, lorsqu'ils sont enfoncés, quelque chose de durable se produit, le montrent avec toute leur apparence. Les champs de saisie sont désactivés au moment de l'envoi des données. En cas d'erreurs, des explications détaillées s'affichent.

Logistique et stockage physique des feuilles

Le brassage de morceaux de papier est l'une des activités dans lesquelles l'humanité a obtenu un succès incroyable. Il semblerait que vous puissiez aller dans une papeterie, acheter un ensemble de signatures "fédérales" et ne pas penser aux détails. Mais il y a un problème : toutes les solutions bureautiques sont trop chères. Nous ne pouvons pas livrer des scanners de documents pour plusieurs dizaines de milliers de roubles et des armoires avec des dossiers suspendus pour cent mille à chaque siège, donc à chaque étape, nous avons dû inventer et créer quelque chose à partir de matériaux de récupération.

Quelques faits sur la physique du processus

Nous devons soumettre 315 000 signatures. Pour ce faire, compte tenu des quotas régionaux et d'une marge d'erreurs diverses, il est nécessaire de collecter et de traiter environ 1 million de signatures. Chaque feuille peut avoir un maximum de cinq signatures, mais en réalité il y en aura quelque part 3-4. Cela nous donne, grosso modo, 300 mille feuilles.

Une feuille de papier A4 a une superficie de 1/16 m².
La densité du papier de bureau ordinaire est de 80 g/m², chaque feuille pèse 5 g.
La hauteur d'un paquet de 500 feuilles est de 4,5 cm pour les feuilles vierges, de plus de 6 cm pour les pleines.

Il s'avère que toutes les feuilles collectées pèseront 1,5 tonne et qu'une fois pliées en un seul paquet, elles mesureront environ 36 mètres de haut.

Comment stocker tout cela ?

Les listes de signatures sont imprimées, remplies de signatures, vérifiées, certifiées et envoyées quotidiennement au siège central. Un siège envoie plusieurs centaines de feuilles par jour, donc à ce stade, il ne devrait pas y avoir de problème.

Le plaisir commence au siège central. Là, vous devez organiser un système de stockage qui facilitera l'acceptation des feuilles du siège régional et leur utilisation jusqu'à la fin de la collecte. Une fois la collecte terminée, les feuilles doivent être regroupées par région et cousues dans des dossiers pour la commission électorale.

Nous ne pouvons pas simplement plier les feuilles en paquets sans fin, car les avocats peuvent à tout moment vouloir retirer une partie des feuilles en fonction d'un certain échantillon. Vous devez savoir exactement où se trouve chaque feuille, pour pouvoir la sortir et la rendre rapidement.

Pour un accès rapide, un système d'indexation de la base de données physique des fiches a été inventé. L'index se compose de plusieurs niveaux : siège social (boîte), boîte, dossier. L'adresse du dossier dans l'archive ressemble à ceci : 77-1-15. Chaque dossier contient 25 feuilles (sans ordre particulier).

L'image en haut à gauche montre une boîte de 500 feuilles de signature dans des dossiers papier.
Sur la photo de droite, un tiroir de 2000 feuilles dans des dossiers suspendus.

Récupérer et trier les feuilles

Toutes les feuilles provenant des régions sont numérisées par un scanner recto-verso automatique (il était déjà dans le bureau, il n'y avait donc pas besoin de l'assembler nous-mêmes à partir de LEGO et d'Arduino). Cet appareil est capable de télécharger le résultat sur le serveur via SFTP. Là, les scans sont exécutés via un script python qui recherche les codes QR dans des endroits standard, les reconnaît et relie les scans à une base de données commune. Le script gère de manière fiable même les feuilles froissées.

Après numérisation, les feuilles passent au tri. Chaque feuille est numérisée à l'aide d'une application mobile (mode tri). Il trouve la feuille dans le système, change son statut en "arrivé au siège central" et affiche les coordonnées du dossier dans lequel la feuille doit être placée. L'opérateur confirme qu'il a mis la feuille dans le dossier spécifié (clôt la transaction).

Les feuilles d'une région sont placées dans un dossier de manière séquentielle tant qu'il y a de l'espace dedans, de sorte que l'ensemble du processus est très rapide.

Back-end

Reaper 2018 est fabriqué à Django avec des modèles standard et ORM. PostgreSQL est utilisé comme base de données. Les parties de service du système - FIAS, vérification des passeports, utilisation des données de pré-enregistrement - sont déplacées dans des modules séparés (application Django) avec leurs propres bases de données.

Le monde physique des signatures se présente sous la forme de plusieurs classes d'objets : une liste d'abonnement, une ligne dans une feuille, une signature. Les objets de ces classes ont des attributs qui reflètent l'état de l'objet dans le monde réel. Pour gérer les états, le modèle "machine à états finis" et la bibliothèque django-fsm sont utilisés. Toutes les transitions entre les états sont écrites sous la forme de transactions FSM, dans lesquelles les contrôles nécessaires et les actions supplémentaires avec l'objet sont effectués.

Le diagramme d'état ressemble à ceci :

La position de la feuille dans l'espace est déterminée par l'état des lignes qu'elle contient. S'il y a des lignes qu'un avocat doit vérifier, la feuille reçoit le statut « à un avocat ». Dès que l'avocat a pris la feuille et saisi son code dans l'interface de vérification, la feuille obtient le statut « chez l'avocat ». Ainsi, nous connaissons toujours la position exacte de toutes les feuilles et comprenons leur devenir immédiat.

Essai

Le système de collecte de signatures a trop d'états différents et de transitions entre eux pour être vérifié manuellement. Pour automatiser les contrôles, tous les scripts liés au travail des opérateurs et validateurs sont couverts de tests côté django.

Il est inutile de regarder un système de collecte d'un million de signatures lorsque ces signatures manquent. Pour remplir la base de données, des scripts ont été écrits pour initialiser l'état typique de la base de données pendant le processus de collecte, afin que vous puissiez regarder le système rempli de quelque chose de similaire à des données réelles.

La collecte des signatures est très limitée dans le temps, et une partie importante de ce temps tombe cette fois-ci sur les vacances du Nouvel An. Nous nous attendions à ce que la charge de travail du siège et du système de collecte soit inégale. Il était important que le système puisse facilement gérer n'importe quel flux de signature réaliste. Aux heures de pointe, jusqu'à 10 000 signatures étaient attendues par heure. Pour un site Web ordinaire, cela semble frivole, mais dans notre cas, cet ordre de « visiteurs » peut créer une charge importante sur le serveur. Il ne s'agit pas seulement de visites ou d'inscriptions : l'obtention de chaque signature implique environ 50 requêtes serveur et le traitement de plusieurs images haute résolution.

Les tests de charge ont été effectués à l'aide de Locust. C'est un outil simple disponible via PyPI. Les scripts sont décrits en code python, un peu comme les tests unitaires dans Django :

Les tests peuvent être exécutés via l'interface Web, qui affiche des graphiques du taux de demande, du nombre de clients et du temps de réponse du serveur.

Le déploiement du projet est organisé de la même manière que pour le site « Navalny 20 ! 8 ».
Les applications Web de Reaper ne sont accessibles que via le VPN du siège.

Surveillance

Nous utilisons divers outils pour surveiller les serveurs et les applications impliqués dans le système de collecte de signatures.

Zabbix surveille l'état de toutes les machines virtuelles d'un projet.

Elasticsearch collecte les logs nginx de toutes les machines virtuelles, Kibana le montre sous forme de graphiques.

Sentry contient tous les bogues des applications et des frontends. Les frontends ont été déplacés vers une "organisation" distincte afin de ne pas gâcher les statistiques sur les erreurs du backend. Une chose pratique, mais faire travailler Sentry sous notre charge était assez difficile.

OIE

Il s'agit d'une surveillance fonctionnelle, un peu similaire à uptime.com, uniquement faite maison. Le backend est construit sur django, les files d'attente sont faites sur le céleri avec un backend dans redis.

Les domaines de projet sont ajoutés à Goose. Pour chaque domaine, les adresses à surveiller, l'intervalle de contrôle et le type de contrôle sont indiqués. Vous pouvez vérifier le certificat, le contenu, les en-têtes HTTP, les redirections, etc.

En cas de problème, Gus sait envoyer des lettres et SMS ou appeler au milieu de la nuit et expliquer la situation avec une voix humaine (pour les appels et la synthèse vocale, le service Twillio est utilisé).

L'interface Web indique toujours quels domaines ont des erreurs et comment se porte la file d'attente de vérification. Chaque minute, 20 à 25 contrôles sont effectués. Ajouter des balises