シグネチャーコレクションシリーズ

1. はじめに、サイト「Bulk 20！8」、コレクションの準備

2. 鉄とネットワーク、ビデオ監視

3. Reaper 2018：署名を収集するシステム

4. プロジェクト管理

はじめに

これは、Alexey Navalnyの地域本部のITインフラストラクチャがどのように配置され、ロシアの大統領候補としての指名をサポートする署名を収集するシステムについての物語です。







また、これは、フリーソフトウェアと低コストのコンポーネントを使用して、小規模チームが全国規模で署名を収集するための複雑なシステムを作成した方法についての物語でもあります。 プロジェクトには複雑な技術的解決策はありませんが、典型的なIT開発経験に基づいて予測できない多くの重要な詳細があります。



便宜上、資料は4つの投稿に分割され、順番に読むのが最適です。



これは技術資料ですが、ここで説明する問題の多くは、現在の政治的背景についての最低限の知識がなければ理解できないため、必要な範囲で説明しています。 何らかの理由で「Navalny」という言葉（これはさらに何度も発生します）や民主的な制度について言及するのが怖い場合は、このテキストを読んではいけません。 コメントでは政治的な問題は議論されません。

キャンペーンの目標

Alexei Navalnyの大統領候補としての登録。

IT部門に割り当てられたタスク

（時系列）：



-候補者の指名に署名する準備ができているすべての人の事前登録。

-ロシア全土の本社ネットワークの維持。

-315千の理想的な署名を収集するためのシステムの作成。

歴史的および政治的背景

議会に参加していない場合、選挙に参加するには署名を収集する必要があります。 これは、「調整されていない」候補者が選挙に参加するのを防ぐために使用される弾幕手順です。



登録拒否の無限の可能性は、収集ルールのレベルで定められています。

• 署名の収集は時間的に厳密に制限されています。
• 法律によれば、必要な署名の数パーセントが結婚に割り当てられています。
• 投票者データは政府機関のみがアクセスできるFMSベースに対応する必要があるため、一方の側で署名を検証することは不可能です。
• グラフロジストは、CECで確認する場合、署名を拒否でき、エラーが発生しても法的責任を負いません。
• 検証スキーム自体は、かなりの割合の誤検知（ 選挙の弾幕としてのベイズの定理の逆説）があると想定しています。

私たちは立法議会の選挙に参加するための署名を集めたときにノボシビルスクですでにこれに直面していました。







ノボシビルスクで署名を収集するために、「フィールド」およびキューブで署名を収集し、コレクターのルートを管理し、すべてのサブスクリプションリストを考慮し、さまざまなチェックの結果に従って署名をランク付けできるReaperシステムを作成しました 。



ノボシビルスクのコレクターは16,000を超える署名を持ち込み、そのうち11 722個を選びました。厳しい選択にも関わらず、選挙委員会のワーキンググループは多くの「無効な署名」を明らかにし、選挙委員会は候補者の登録を拒否しました。 署名が無効になる理由については、 こちらをご覧ください 。



新しいシステムは、署名収集の経験と選挙委員会でのその後の保護を考慮して構築されました。

新しい署名コレクションの機能

大統領候補を指名するための署名を収集するために、さらに厳しい条件が設定されています。



-315,000を超えない署名を渡す必要があります。

-少なくとも30万個の署名が有効であると認識される必要があります。

-1つの地域から7500個以下の署名がカウントされます。

-短い収集期間（12月27日から1月31日まで）には、多くの人が休暇に行く正月休みが長くなります。



以前の経験と新しい要件に基づいて、次の基本原則を採用しました。

本社の全ロシアネットワーク

地域の割り当てにより、たとえば、10の大都市で働くことは不可能でした。 少なくとも40の都市がカバーされている場合、315万の署名を収集できます。 人口の少ない地域では、署名の収集はより困難であるため、実際には、収集を成功させるために、国のほとんどの地域に本部を開設する必要がありました。







収集が正常に完了した時点での署名の数に関する予測は、大都市では署名を希望する人の数が地域の割り当てを大幅に超えることを示しています。 モスクワ（127千人）とピーター（63千人）は画面に収まりませんでした。

本社のみの署名コレクション

自宅で収集するには、数千人のコレクターを雇う必要があります。 有料のコレクター（または、たとえば社会学の学生）と少なくとも一度は働いたことがある人なら誰でも、手順のすべてに同じように敏感であるわけではなく、署名を1つまたは2つ単に「描く」という誘惑に打ち勝つわけではないことを知っています。 不注意な記入は結婚の大部分をもたらし、「署名」の署名は、CECがグラフ学者によるチェックを提供するような一般的な問題です。 州内のグラフ学者の存在と警察へのいくつかの発言の実証的実行でさえ、本部を「ドラフトマン」（私たちがチェックした）から100％救うことができません。 さらに、コレクターは悪意のないだけでなく、「本部を支援する」ために署名を仕上げることができます。



「野外で」収集する場合、ノボシビルスクで行われたように、「 有毒物質収集者 」を確実に導入することを知っていました。 有毒コレクターは、投票者データに意図的に間違いを犯します（たとえば、パスポート番号を1桁に置き換えます）。 彼らの仕事は、選挙委員会が登録を拒否した後、制限を超えて無効な署名の数を増やすことです。 ノボシビルスクでは、有毒なサインをきれいにするために多くの努力を費やしました。 全国的に収集する場合、これは不可能です。



静止した本社でのみ、署名の十分な品質、署名シートの正確な充填条件、およびその安全性を確保することができました。

署名のマルチステップ検証

理想的な署名は、数学的な抽象化です。 署名の実際の収集は複雑で困難なプロセスです。 正直でよく訓練されたコレクターでさえ間違いを犯し、時間の不足に直面して、行政上の圧力と結婚の挑発はさらにあります。



エラーの表示方法に関する多くのデータがあります。 私たちの経験では、完全に正直な方法で収集されたリストには、選挙委員会が無効と認識する署名の約10％があります。



良い署名だけでなく、選挙委員会が受け入れる署名を渡す必要がありました。 このため、いくつかの検証手順とランキングメカニズムが必要でした。どのように不条理と考えても、選挙委員会のチェックに合格する可能性が最も高い署名のみを選択して送信するためです。

各署名のパスポートスキャン

スキャンを行わない場合、署名の品質に関するすべての責任はコレクターにあります。 彼が誤ってまたは意図的にパスポート番号を間違えた場合、私たちは決して知りません。



経験から、パスポートデータをサブスクリプションリストに書き換える際のエラーとデータ入力エラーのみが、快適な条件で、良心的なコレクターによって署名が収集されたとしても、許容される5％の制限を簡単に使い果たすことがわかった



文書をスキャンして、署名の検証の独立したいくつかの段階を実行し、修正することができました。



さらに、私たちの弁護士は、裁判所ですべての署名のために戦う準備をしていました。 前回、拒否された署名の大規模なカテゴリがありました。これについては確かに知っていました。署名はパスポートと一致しますが、古くて完全なエラーデータベースと照合しました 。 単一のデータベースとスキャンの可用性により、弁護士はそのような場合に苦情を準備するプロセスを自動化できます。



もちろん、本部でのみパスポートをスキャンすることは可能でした。そうでなければ、個人データの適切なレベルのセキュリティを確保することは不可能でした。

電子データベースとの同期

署名とサブスクリプションリスト、すべてのステータスと移動を伴うすべての操作は、電子データベースに反映されている必要があります。 署名を収集するシステムは、収集のすべての段階を制御し、エラーを特定する必要がありました。 この方法でのみ、数十万の物理オブジェクトを操作するときに秩序（および安心）を維持できます。

システムの新しいバージョンで行われたこと

• 署名を収集する場所を確保するために、地域本部のネットワークを展開しました。 本社のITインフラストラクチャは、複数の物理サーバー、多数の仮想マシン、70台のルーター、230台のカメラ、189台のワークステーションで構成されています。 内部からは、250人以上が同時にシステムを使用しています。
• 短い集まりで数十万人を本部に連れていくために、私たちは事前にデータを確認するウェブサイト20！8で有権者の登録を始めました。
• エラーの数を減らすために、サブスクリプションシートの記入の正確性を独立して検証できるシステムを作成しました。 このシステムは、複数のWebアプリケーションと2つのプラットフォーム用のモバイルアプリケーションで構成されています。
• システムにデータをアップロードするために、パスポートをスキャンするための一連の機器を収集（および部分的に作成）し、個人データの安全な転送のためのスキームを考え出し、それをすべての本社に実装しました。
• 選挙委員会の観点から住所の形式を正しくするために、FIASデータベースで検索を上げ、弁護士と一緒に、法律のすべての要件を考慮に入れて真剣に調整しました。
• 本社を（部分的に）保護し、裁判所で追加の議論を行うために、24時間体制のビデオ監視および記録システムを確立しました。
• インフラストラクチャ、メカニクスをテストし、データを明確にし、収集のために本部を準備するために、81,750人が通過した有権者の予備検証のための大規模な手順を実施しました。
• 署名用紙の外観、本社の用紙物流システム、および中央本社の物理的な保管とクイックアクセスシステムを開発しました。

Webアプリケーションのコアテクノロジー

主なバックエンド言語： Python。

フロントエンド： JavaScript、jQuery、React、D3.js。

フレームワーク： Django（6個）、aiohttp（1個）。

データベース： PostgreSQL、Redisなど。

全文検索： Sphinx。

HTTPサーバー： Nginx、ワニス。

テスト： Jenkins、Browserstack、RobotFramework、Locust。

監視： Zabbix、Elasticsearch、Kibana、Sentry。

デプロイ： Ansibleおよびその他のツール。

サーバー構成管理： Chef。

パート1：Navalny 20！8のWebサイト

非常に限られた時間で数十万人を本部に連れて行かなければなりませんでした。 これを行うために、キャンペーンの開始日からサポーターの登録を開始しました。 サポーターの募集と登録は、 Navalny 20！8 Webサイトの主要なタスクの1つであるため、登録フォームはほぼすべてのページにあります。



これはすべて、美しい数字のためだけでなく必要であったため、登録されたサポーターがボットではなく実在の人物であることを知って、彼らと連絡を取り、登録されている都市を理解できるようにすることが重要でした（地域ごとのクォータの実装を予測するため）。 したがって、サイトでの登録は非常に複雑で、電話番号の確認が義務付けられていました。 自分自身や他人を欺かないようにするために、アンケート全体に記入して電話番号を確認した潜在的な署名者の潜在的な人だけを記録しました。 そのため、メインページには、100万以上（登録の総数）ではなく、706 513個の「将来の署名」しかありません。



サイト構築の観点から、これはかなり普通の製品です。 このサイトはPython + Django + PostgreSQLで作成されており、標準ORMと標準管理者が使用されています。 1年半の間、サイトはいくつかの更新を経験しました。セクションが追加され、登録フォームの作業が変更され、ページ上のテキストと画像が変更されました。 標準ブロックで補うために設計を複雑にしないようにしたため、一部のセクションは3日でアイデアから立ち上げられました。



訪問者の約半数は、モバイルデバイスから最新のWebサイトにアクセスします。 私たちはサイトをすべての人にとって便利なものにしようとしたため、レイアウトは描画され、320pxから始まる任意の画面幅で正しく表示されるようにレイアウトされました。

本社マップ

訪問者が見る唯一の複雑なインタラクティブ要素は、本部がマークされたロシアの地図です。 本社の数が50を超えると、ヨーロッパの一部にマーカーが近接していたため、マップのナビゲートが困難になりました。 当初、このマップは純粋に装飾的な要素として考えられていましたが、突然機能がいっぱいになったため、キャンペーンの連邦の性質をすでに理解していて、自分の都市を見つけたいだけの人のために、リストモードを作成しました。







マップは、美しく多面的なd3.jsを使用して作成されます。 地図投影のため、標準のGoogleマップやYandex.Mapsを使用するのではなく、独自のスクリプトを作成することにしました。 地球の楕円体を飛行機でスキャンする多くの方法があります 。 メルカトル図法では、オブジェクトは北緯で非常に伸びており、主要な大都市が集中している地域ではより多くのスペースが必要です。 さらに、メルカトル図法では、ロシアはかなり奇妙に見えます。 地理学の教科書でよく知られているアルバース（アルバースシベリア）の円錐投影法を選択しました。





_{健康な人のロシア（アルバースの円錐投影）と喫煙者のロシア（メルカトルの投影）}

コンテンツ管理

このサイトの編集セクションにはほとんど関心がありません。 最小限のカスタマイズで通常のDjango管理パネルを使用します。 開発リソースが限られているため、本当に便利なツールを作成するのに時間を費やすよりも、標準ツールを使用するように複数の管理ユーザーに教える方が有益です。



編集者の生活を簡素化するいくつかの決定は、他のプロジェクトから取られました。 たとえば、クライアント側でテキストを入力するためのツール。 私たちのタイポグラファーは、任意のテキストまたは文字列入力フィールドに簡単に接続できるという点で便利です。 オートタイポグラフィの状態に関する情報（オン/オフ）は、行末に印刷不能文字として保存され、バックエンドに依存しません。



投稿やニュースの複雑なコンテンツを処理するために、他の多くのプロジェクトでも使用されているブロックエディターを使用します。







ブロックにはさまざまなタイプがあり、各プロジェクトには独自のセットがあります。 各ブロックにはコンテンツが含まれ、設定が含まれる場合があります。 ブロックデータはjsonとしてデータベースに保存され、テキストブロック内のマークアップはマークダウン形式で保存されます。



表示のために、ブロックは目的の形式に変換されます：投稿のHTML、インデックス作成のテキスト、Yandex.ZenのRSSまたはXML、モバイルアプリケーションのJSONなど。 したがって、コンテンツのフォーマットがかなり複雑なデバイスであれば、予測可能な結果が得られます。



最初のバージョンはトレバーTreのコードに基づいていました。 その後、トレバーirのスパゲッティcodeの維持が困難になったとき、エディターはReactに書き換えられました。

分析

技術的な観点から最も興味深いのは、サイトの管理パネルです。 そこから登録の流れを見ました。



最初は、分析はかなり原始的でした。つまり、さまざまなタイプの登録数と時間のグラフです。 しかし、地域ごとのダイナミクスを確認し、登録数に対するさまざまなイベントの影響を追跡したいと考えました。 そこで、待望の分析が登場しました。



この画面には、サイトの全ライフの概要、特定の期間のスケジュール、およびこの期間のイベントのリストがあります。 グラフ上のピークを強調表示して、どのイベントがそれを引き起こしたのかを理解することができます。 ほとんどの場合、これはNavalnyのYouTubeチャンネルでの別の調査ビデオの公開です。 署名の最大の増加は、地域の役人の詐欺に関するビデオによってもたらされました。







グラフはd3.jsで作成され、時間と本社によるイベントのフィルタリングは、 Crossfilterライブラリを使用して実装されます。 このソリューションにより、クライアント側は、1時間単位で1年以上の間隔で登録データに登録ブレーキをかけることなく動作できます。 現時点では、これは12メガバイトのデータ（gzipで1.3 MB）です。



登録データベースの重要な指標と前日の成功を含む小さなテキストレポートが、すべてのプロジェクト参加者に毎日自動的に送信されました。

都市と地域

また、ロシアの各地域の署名収集の準備の主な指標が登録されている巨大なテーブルがあります。







この表の数値は、最初は収束したくありませんでした。 都市別の金額は、登録数よりも大幅に少なかった。 サイトでアンケートに記入する際に、人々は予想外に自分の都市の名前を間違えたり、非標準の名前を使用したりすることが判明しました。



-モスクワ-2.5％のエラーと579のスペルバリエーション。

-サンクトペテルブルク-エラーの12.6％と767のスペルバリエーション。

-コムソモリスク・オン・アムール-エラーと略語の20％以上、75のオプション。



サポーターの数の誤った見積もりは、本部のネットワークおよびキャンペーンイベントの誤った計画につながる可能性があります。 都市名のユーザー入力を地域の標準名に変換する方法について考えなければなりませんでした。 このような単純なフォームで、KLADRまたはFIASに基づいた自動補完メカニズムを使用したくありませんでした。 そのため、ロシアの700の大都市のリストを取得し、典型的なスペル（「サンクトペテルブルク」、「n-sk」）のリストを追加し、レーベンシュタイン距離（これは2つの文字セットの違いの尺度）でランク付けして非厳密な検索を行いました。



リストから各都市を、最寄りの本社までの距離に応じて3つのカテゴリのいずれかに割り当てました。本社は市内にあり、本社は近くにあり（都市集積）、本社は遠くにあります。 本社からの距離は、適切なタイミングで到着して署名をする人数を評価する際に考慮されました。 分析では、すべての署名者を個別に考慮し、「利用可能」（確認済みのメール、本部またはその近くの都市に住んでいる）を考慮しました。





このグラフは、時間の経過とともにキャンペーンがどのように地域的になるかを示しています。 モスクワとサンクトペテルブルクからの新規登録の割合は35％から15％に減少しました。

SMSとメール

もう1つの技術的な問題は、SMSと手紙を送信することでした。 ゲートウェイは、特に外国の番号へのメッセージをあまりうまく配信しません。 しかし、最もクリーンで信頼性の高いサポーターのデータベースを取得したかったため、登録フォームの2番目の部分では、SMSを介して電話番号を確認する必要がありました。 信頼性のある送信のために、3つのゲートウェイをローテーションしました。メッセージが配信されなかった場合、再送信はすでに別のゲートウェイを経由していました。 さらに、側で障害が発生した場合、個々のゲートウェイをオフにすることができます。 SMSコードの配信可能性インジケータは、監視されたパラメーターの1つです。







グラフは、ゲートウェイが2回誤動作したことを示しています。 配信されたSMSのシェアは、メッセージ送信キューの障害のため、2月21日と4月17〜18日に急激に減少しました。 また、7月15日に登録フォームのレイアウトを変更しました。これもチャート上で顕著です。



70万を超えるメールアドレスに基づいて多数の手紙を送信します。 誰かがニュースを購読しました。誰かがイベントに関する通知を受け取る必要があります。 さらに、各アドレスは2オプトインルールに従って確認する必要があります（これは、リンクが最初の文字になったときです。リンクをクリックしてニュースレターの購読を確認する必要があります）。 キャンペーンの開始時には、ActiveCampaignサービスを使用しましたが、費用が高く、非常に遅いです。 基地が30万人を超えると、仕事ができなくなりました。 そのため、独自のCRM /メーリングサービスを作成しました。これにより、必要なサンプルに従ってメーリングと会話を作成できます。 Mailgunは現在、手紙の配達に使用されています。

保留中のタスクキュー

サードパーティのサービスのAPIを介してメールまたはSMSを送信することは、時間のかかる操作です。 このような操作は、ユーザーインターフェイスの速度を低下させたり、アプリケーション全体に負荷をかけたりしないように、非同期で実行する必要があります。 当初、非同期タスクはすべて、Redisをブローカーとして使用してCeleryを介して機能していました。 各レターまたはSMSはCeleryキューにタスクを作成し、その後、無料のワーカーがこのタスクを処理しました。 しかし、このアプローチは信頼性が低く、リソース集約型であることが判明しました。







かつて、1時間あたり1万件以上の登録が私たちにやって来ました（いいえ、彼らはテレビで私たちを見せなかった、それは「+1」キャンペーンでした）。 10セロリの労働者はこれに対処できず、ユーザーはSMSとメールの受信が大幅に遅れることに気付き始めました。



この事件の後、私たちは単純なPostgreSQLベースのキューを支持してCeleryを放棄しました。 キューのタスクは、各メッセージ配信チャネルに1つずつ、Pythonの「デーモン」によって分類されました。 10秒に1回、デーモンはキューからタスクのパケットを取得し、1つのパケットでデータをメールAPIに送信しました。 タスクをグループ化するとサーバーの負荷が大幅に削減され、仮設キューを使用するとデバッグと監視が大幅に簡素化されました。



セロリは私たちの仕事には複雑すぎるツールでした。 彼は、Flowerのような外部ユーティリティを介した思慮深い調整と監視が必要であり、それ自体が多くのリソースを消費します。 他のプロジェクトでは、よりシンプルなソリューション-RQ + Redisを使用しようとします。





非同期タスクの操作に関する記事のRQとCeleryの複雑さの比較。

開発プロセス

開発者の観点からサイト「Bulk 20！8」を作成するプロセスはどうですか？ 1つの方法論に固執するのではなく、異なるシステムのアプローチを使用します。 たとえば、マネージャーはかんばんに似た構造でTrelloにタスクを設定し、開発者は極端なプログラミングの個別のプラクティスを使用します。



チームの約半分はモスクワのオフィスにいますが、残りはリモートで働いています。 モスクワの従業員はキャンペーンのチラシに参加して、全体像をよりよく理解するために働かないようにすることができますが、IT部門のタスクについては別途説明します。 定期的な呼び出しにより、誰もがいつでもメインの作業ラインを同期して理解できます。







ほとんどのプロジェクト参加者はフルタイムでそれに取り組んでいますが、一部のタスクは一時的に他のプロジェクトやボランティアから引き付けられた開発者によって行われました。 たとえば、ボランティアのイリヤは、ほぼ完全にメインページの本部マップを作成しました。



ソースコードは、Bitbucketプラットフォームのgitリポジトリに保存されます。 重大な新しいタスクごとに、個別のブランチが作成されます。 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-, , ) — : , , , .



, , . , , .

---

, .



, .



, , .