Navalny Headquarters IT Infrastructure and Signature Collection：2018 Reaper

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

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

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

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

4. プロジェクト管理

これは、Navalnyの本社のITインフラストラクチャに関する資料の3番目の部分です。 前の章では、Navalny 20！8 Webサイトの開発、本社のネットワークの構成 、ドキュメントスキャナーの製造について説明しました。



この章では、大統領候補としてNavalnyを指名するための署名を収集するシステムの作成について説明します。 作業の段階と結果のソリューションが説明されています。 署名シートを物理的に保管するシステムについて説明します。

シート、QRコード、およびそれらの操作方法

サブスクリプションリストは、システムのメインドキュメントです。 オブジェクトの大規模なコレクションを操作するために最初に行うことは、オブジェクトに一意の識別子を割り当てて、各オブジェクトをデータベース内のレコードに関連付けることです。 ただし、署名シートの形式は法律で非常に厳密に規定されています。これに違反すると、一般的にすべての候補者の署名が拒否されます。 選挙委員会に提出されるシートでは、追加のマークや記号は許可されていません。



ノボシビルスクで署名を収集するとき、各シートをマルチフォラ（透明な「ファイル」）に配置し、シートIDとすべての公式ノートをマーカーで記録しました。 これは4,000枚のシートで機能しましたが、数十万枚では機能しません。 今回は、multiforの使用を信頼性が低く不快なソリューションと見なしました。







弁護士は、各シートを識別し、署名シートのフォームを壊さない方法を考案しました。 法律は、署名用紙の物理的なサイズについては何も述べていません。 これにより、上部に識別コードが適用されるようにシートを設計し、選挙委員会に提出する前に切断することができました。



シートコードは6文字で構成されています。 キリル文字のグラフィックアナログを持つラテンアルファベットの数字と文字を使用できます（任意のレイアウトでフォームに書き込むことができます）。 便宜上、91-X7-BAのディバイダーを追加しました。



同じ識別子がQRコードの形式で印刷され、さまざまな作業段階で自動認識されます。 QRコードは、信頼性と認識速度の点で他のすべてのタイプのバーコードを獲得しました。







本部の生活は困難に満ちているため、QRコードはシートのさまざまなストレスの多い状況で慎重にテストされました...







...そして、ライブシートを処理するには3つのコードで十分であると判断しました。







弁護士とデザイナーは、レイアウトが法律と常識の両方に準拠するように努力しました。 シート上の署名の数を個別にテストしました。 署名が少ない-シートが多すぎる、不要な落書き（コレクターとプロキシのデータ）が多い、認証ラベルのエラーが多い。 多くの署名-投票者データを入力するのは不便で、署名行に多くのエラーがあります。 プロトタイプを試した後、5つの署名に決めました。



各シート（より正確には、シート識別子）がデータベースに作成された後、A4用紙に印刷できます。 ただし、シートを取り込んで、最も近いプリンターで印刷することはできません。 法律により、署名用紙の作成は候補者の選挙口座から支払わなければなりません。 通常、それらは外部の請負業者によって作成されます。 そのため、技術面を可能な限り使いやすく、柔軟にしました。 シートは、ブラウザから直接印刷されるか、以前に複数ページのPDFファイルに保存され、任意の便利な方法で請負業者に転送できます。

フクロウ：署名の収集の準備

サブスクリプションリスト内の物理署名の収集は、候補者の指名と特別選挙アカウントの開設後にのみ開始できます。 法律はこれにほとんど時間を割いていません。 すべてのプロセスをデバッグし、選挙の公式発表後できるだけ早く作業をスピードアップするために、できるだけ多くの操作を事前に行うことが重要でした。 サポーターのデータを事前に検証し、スタッフを訓練し、収集メカニズムをテストするために、検証手順を開始しました。



検証は、署名のコレクションのベータ版です。実際の本社では、同じ機器を使用し、同じ厳密なドキュメントチェックを行いますが、紙に署名をしません。 検証済みの人々のデータを処理するために、Owlアプリケーションが開発されました。

フクロウの構成

RESTful APIバックエンド：Python 3.6、aiohttp、aiohttp_admin、SQLAlchemy。

データベース：PostgreSQL、Redis。

通知デーモン。

パスポート番号認識デーモン。

分析を構築するデーモン。

番号によるパスポート検証サービス。

アドレスを操作するためのボックス版のKladre-API （PHP 5.6 + MongoDB）。



Navalny 20！8 Webサイトを含むいくつかのサービスと統合する予定だったため、RESTful APIを使用してOwlの別のバックエンドを作成することにしました。 別個のPostgreSQLおよびRedisデータベースがキャッシュ用のストレージとして使用されました。 ユーザーを管理するために、aiohttp_adminライブラリが登場しました。これはニーズに合わせて変更しました。



オペレーターの内部インターフェースは、パスポートをスキャンして個人データを入力する段階的な形式です。 多数の状態が考えられるため、このフォームはReactで作成されました。



サイト「Navalny 20！8」との対話は、トークンによって保護され、仮想マシン間のローカルネットワーク上でのみアクセス可能なAPIを介して実行されました。

検証記録

本社の負荷を時間内に均等に分散するために、検証のための記録を作成しました。 サイトに登録した後、人は録音インターフェースにアクセスし、そこで便利な本部と時間を選択しました。







ワークロードを制御し、記録とスケジュールを管理するために、地域のマネージャーと本社のコーディネーターが利用できる別のインターフェイスを開発しました。







本社で緊急事態が発生した場合、コーディネーターは今後の確認エントリを大幅にキャンセルできます。 ただし、彼は自分でこれを行うことはできません。地域マネージャーにキャンセル確認コードを要求する必要があります。 このオプションを繰り返し使用する必要がありました。

通知

Sychaでは、分岐通知システムが実装されました。 署名者は、確認のためにサインアップしたとき、記録を取り消したとき、記録の取り消しの1週間後、確認が成功した後、本部による記録の取り消しの後、および他のいくつかの場合に、メールで通知を受け取ることになっていた。







SMS通知は、3時間後に記録を思い出させ、本部が記録をキャンセルしたことを通知するために送信されました。 通知キューは、Navalny 20！8 Webサイトと同じ原理に従って作成されました：データベース内のテーブル。グループはメールおよびSMSゲートウェイ経由でメッセージを送信します。

パスポート認証

オペレーターの作業を評価し、データ入力中のエラーの割合を判断するために、スキャンをさらに認識したかったのです。 パスポートは多様であるため、信頼できる自動認識を行うことは不可能であったため、ユーザーが認識できるようにスキャンをYandex.Tolkaに送信するか、オフィスでこれを行うボランティアのグループに参加するという2つのオプションが検討されました。 しかし、個人データのセキュリティの問題により両方の選択肢が妨げられ、パスポート番号のみの自動認識を残しました。

フクロウ分析

検証中に、サポーターの基盤を明確にして確認しただけでなく、本社、インフラストラクチャ、機器、署名収集の仕組みの作業もテストしました。 プロセスを観察して調整するために、単純な分析を行いました。



本社には3つのレベルのプロセス管理（本社コーディネーター（1つの本社の作業を担当））、地域マネージャー（複数の地域の本社グループを監視）、および連邦本社管理（すべておよび全員を監視）があるため、システムはさまざまな方法でデータをグループ化しましたユーザーのカテゴリごと。



詳細のほとんどを本部のコーディネーターに見せました。 彼はすべてのオペレーターの統計と主要な指標のダイナミクスを見て、それらに基づいて管理上の決定を下すことができました：オペレーターのセットアップ、アラートの強化、週末の仕事のスケジュールの変更、よく間違える従業員の解雇または再教育など。







地域マネージャーを不必要な詳細から保護し、最初の画面で、彼は本部のグループで最も重要なものだけを見ました：主要な指標、格付け、問題本部（警告赤で示されています）。 「問題のある」ものは、​​平均よりもN％低い本社に分類され、慢性的に負荷が低く（追加の通知が必要）、レコードの数で過負荷になりました（つまり、すべての人がサインアップできるわけではなく、オペレーターの数を増やす必要がありました）。





検出された問題をより適切に処理するために、地域マネージャーは各本社の詳細な統計を簡単に確認し、コーディネーターが利用できるすべてのデータを確認できます。



連邦政府本部がすぐに全体像を見ることが重要だったため、1つの画面でキャンペーンの主要な指標を収集し、検証が行われているすべての都市のピボットテーブルを作成しました。 テーブルで、目的の本社を選択して、その上にあるデータの完全なセットを表示できます。







分析では、合計で50を超えるインジケーターが表示されました。 SQLAlchemyの柔軟性は、純粋なSQLに決して切り替えず、コードを読みやすくするのに十分でした。 最も労働集約的なインジケーターの場合、キャッシュは最初にRedisで行われましたが、バックグラウンドで定期的に計算し、必要に応じてファイルから取得する方が簡単であることがわかりました。

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

検証プロセスと並行して、署名を収集するシステムが開発されました。 基礎は、ノボシビルスクで使用され、物理オブジェクト（シートおよび署名）を操作できるシステムのアーキテクチャに基づいています。



バックエンド側から見ると、Reaper 2018は古いReaperの後継者ですが、検証システムからオペレーターインターフェイスを受け取りました。 Owlの作業に関するフィードバックを分析した後、いくつかの画面が完成しました。 さらに、いくつかのレベルのデータ検証およびシートの移動を制御するためのインターフェイスが追加されました。

オペレーターインターフェース

署名を取得するプロセスでは、オペレーターは投票者のパスポートをスキャンし、アンケートに記入する必要があります（登録スタンプに示されている住所が間違った形式で書かれている場合）。システムの指示に従って、サブスクリプションシートにデータを入力します。 ただし、まず、投票者が次の3つの重要な条件を満たしているかどうかを確認する必要があります。



1.選挙の時点で、彼は18歳以上でなければなりません。

2.投票者が20歳または45歳の場合、新しいパスポートが必要です。

3.パスポートは無効としてリストされるべきではありません。



無効なパスポートのデータベースをチェックするのは簡単な操作ですが、独自の微妙な点もあります。 この基地は、内務省がそのウェブサイトで配布しています。 選挙の前に、何らかの理由でこのデータベースをアンロードする機能をオフにしたため、データベースの現在のバージョンを毎日ダウンロードし始めました（忘れずにオフにしてください）。



現在、データベースには1億1,000万件を超えるレコード（シリーズおよびパスポート番号）があります。 小さなデータベースとインデックスをすばやく検索するために、次のスキームが発明されました：PostgreSQLは、100万レコードのテーブルを作成します。その主キーはパスポート番号（0〜999999）であり、2番目のフィールドにはこの番号の一連の無効なパスポートがすべて含まれます。 シリーズのボリュームを減らすために、バイナリ形式（各2バイト）に変換され、zlibを使用して圧縮されました（ちょうどしたかったです）。 最初、データベースはインデックスを除くと約1 GBを占有します。 処理後、インデックスとともに260 MBが取得されます。 1つのレコードは、平均で15ミリ秒チェックされます。

検証に合格した人のパスポートの0.6％は、無効なパスポートのデータベースで見つかりました。 これは、このような検証がなければ、このタイプのエラーに対してのみ無効な署名の制限の12％を費やしていたことを意味します。



市民は20歳または45歳であったため、パスポートの0.88％は私たちに適していませんでしたが、パスポートをまだ交換していませんでした。 そして、これは無効な署名の制限の別の18％です。

サブスクリプションシートには、オペレーターが記入した4つの列があります。氏名、生年月日、パスポート番号、および永久登録の住所です。 このデータはすべて、Reaperを通過して、考えられるエラーを検証および修正します。 たとえば、名前と愛称のフィールドでは、タイプミスの検索が機能します。







名前のヒントとして、APIには値を大きなリストと比較し、3つの回答オプションを返すメソッドがあります。



-すべてがOKです、そのような名前があります。

-同様の名前（など）があります。

-不明な名前（まれな名前または重大なスペルミス）。



別の話は、文字「」です。 使用されるパスポートはありますが、ほとんどの場合、「e」に置き換えられます。そのため、一部のパスポートデータフィールドに「e」がある場合は警告を発行します。



システムはそれ自体を修正せず、通知するだけです。 オペレーターとレビュアーは、そのような場合に注意を払い、正しい決定を下すべきです。

文書スキャン

ドキュメントの画像を取得するには、独自のスキャナーを使用し、Raspberry Piをオペレーターステーションとして使用します。 これについては、 第2章で詳しく説明します。





_{この画像はパスポートのスキャンではありませんが、ランダムデータからグラフィカルエディターで収集されます。}



画像はクライアント側でHTML 5 Canvas APIから取得され、JPEGが存在するbase64文字列としてサーバーに送信されます。 フロントエンドの観点から、スキャナーはUSB Webカメラとコンピューターからローカルサブネットへのストリーミングビデオの2つのモードで動作できます。 OwlはUSBカメラでのみ機能し、Reaper-2018ではモードを切り替えることができます。 オペレーターは、使用するスキャナーを選択します。



近隣のコンピューターのビデオストリームを選択すると、小さな問題が発生しました。テーブルとスキャナーを移動でき、オペレーターを移植できます。 次回オペレーターの隣にどのスキャナーが配置されるかはわかりません。 私は本社のサブネットを整理し、オペレーターにライブスキャナーのいずれかを選択する機会を与えなければなりませんでした。 しかし、スキャナーのビデオブロードキャストサーバーは、正しいCORSヘッダー（Access-Control-Allow-Origin：*）を設定しているにもかかわらず、OPTIONSリクエストに応答しなかったことが判明しました。 ブラウザーは、隣接ホストへのajax要求を禁止したため、通常のjQuery.ajax（）を使用して検索することはできませんでした。 JSONPリクエストは、プログラムでキャンセルできず、数十の保留中のリクエストがページを完全にブロックしたため、役に立たなかった。 写真は問題の解決に役立ちました。 DOMにタグを追加し、ビデオストリームのsrcを割り当てました。 ストリームのサイズに応じて画像のサイズが変更された場合、ストリームはライブと見なされ、オペレーターに表示されました。



ブラウザでビデオストリームを表示すると、控えめなRaspberry Piプロセッサが顕著にロードされるため、「スクリーンセーバー」を作成する必要がありました。5分間操作しないと、ブラウザはブロードキャストを一時停止します。



登録場所に関する最新情報を選択することが重要です。 パスポートのスプレッドには6つのスタンプがありますが、必要なのは1つだけです。 インターフェイスでは、キーボードの矢印を使用するか、プレビューで目的のスタンプをクリックして選択できます。







それでも登録はできません。 このような有権者は、空の地域と住所を含む別のサブスクリプションシートに記録され、登録登録はスキップされます。

アドレス処理

サブスクリプションシートの記入で最も難しい部分は、投票者の住所です。 署名を無効にするエラーの半分以上は、アドレスに関連しています。



登録住所の法的要件の大きなリストがあります。 例：



-FIASデータベース（連邦情報住所システム）に基づく住所でなければなりません。

-名前が変更された通りの場合、パスポートが古い場合でも、新しい名前を指定する必要があります。

-法律は、記録する必要がある住所オブジェクトの階層に特定の形式を確立しています（たとえば、都市部を指定することはできません）。



これらは基本的な点にすぎませんが、多くの些細なこともあり、そのリストは選挙委員会との各やり取りの間に補充されました。 わずかな要件でさえ遵守しないことは、選挙委員会が署名を受け入れない理由です。

ノボシビルスクの署名の収集では、「住所」フィールドの主張により、署名の約3.5％が無効であると宣言されました。 そして、これは大統領候補者の指名のための署名に設定された制限の70％です。

すべての要件を満たすために、正しい形式を形成し、コレクターにシンボルの正確さで、サブスクリプションリストに入力する内容を示すために、コンピューターですべてのアドレスを実行する必要があります。



可能な限り、サードパーティのサービスのAPIを使用しないようにして、ユーザーに関するデータを提供しないようにし、最も重要な瞬間にAPIが突然シャットダウンするような状況にならないようにします。 アドレスの操作は署名を収集するための重要な機能であるため、FIASデータベース用の独自のAPIを作成する必要がありました。



FIASデータベースにはまだ家やアパートに関する十分な高品質で完全な情報がないため、通りのレベルで停止しました。 この形式では、すべての追加ビルドを含むデータベースの重量は約2 GBであり、PostgreSQLの形式で非常に快適に動作します。 インポートには、 fias2pgsqlリポジトリから変更されたスクリプトが使用されました 。



住所を入力する万国共通の形式の場合、住所の形式や住所オブジェクトの種類が多いため、フィールドを「都市」、「通り」、「家」だけにすることはできません。 珍しい形式の有名な例はゼレノグラードで、通りの名前のない家があります。 しかし、私を信じて、全国でこれはかなり些細なケースです。



一連の実験の後、3つのフィールドの形式に落ち着きました。



-ロシア連邦の主題-彼は常にそこにいます。これは最も理解しやすい分野です。

-FIASアドレス-FIAS内のこの地域のアドレスで自動補完されるフィールド。

-家/建物/アパート-データが永久登録スタンプに従って正確にコピーされる行。







弁護士は住所の変換表を作成し、その助けを借りて、選挙に関する法律に準拠した形式でFIASの住所を提出しました。 ほとんどの場合、住所要素の1つを除外する必要がありました。 一部の住所は完全に除外されました（ガレージ協同組合、中庭、およびその他の同様のオブジェクト）。 IT部門はルールが記載されたテーブルを受け取り、法務部門は44種類の住所のそれぞれについて10の例を受け取りました。







このような繰り返しを数回行った後、ベースの作業準備が整いました。



タスクの技術的な部分は、1日あたり100万件のクエリの負荷に耐えることができる自動補完機能を備えた便利で迅速な検索を整理することでした。 Sphinxは検索エンジンとして使用されました。 要求から不要な文字が削除され、Sphinxに転送され、指定されたルールに従ってランク付けされたオブジェクトの完全なアドレスが返されます。



Sphinxは、XML形式で記述された住所フィールドにインデックスを付けます。 このストレージ形式は、Sphinxが検索に使用しないXML属性ですべてのメタデータを非表示にできるという点で便利であることが判明しましたが、データベースに追加アクセスせずにメモリに保持し、結果を返します。 フロントエンドのどこかで、これらの属性は美しいアドレスバーを形成するために使用されます。





ソリューションは便利で迅速でした。 サジェストAPIへの1つのリクエストは15〜20ミリ秒で実行され、バックエンドはそれほど強力ではない仮想マシンで300の同時接続を静かに処理します。

サブスクリプションシートに記入する

署名は、市民の永久登録の住所が属するロシア連邦の主題のシートに入力する必要があります（または、登録がない場合は地域のない特別なシートに入力する必要があります）。 刈り取り機は、オペレーターにどの領域のどのシートを取るかを伝え、別の領域のシートに署名することを許可しません。

コンピューターなしでこのような問題を解決し、さまざまな地域から多くの人々が集まり、地域ごとに並べられた空のシートのあるファイルキャビネットがないステーションで署名を収集するとします。 約3分の1のパスポートでは、登録スタンプに地域の名前が含まれておらず、ランダムな通行人はゲームのルールを知らず、何かを簡単に混乱させる可能性があります。 これは多数のエラーの発生源のように見えますが、法定限度である5％では許容できません。

サブスクリプションシートの記入は複雑で責任のある手順です。 シートには、署名の行、コレクターの認証ラベル、受託者の署名があります。 これらのブロックはすべて、厳格な正式な要件に従って記入する必要があります。 記入の各段階でエラーが発生し、シート全体または署名の一部が無効になる可能性があります。



典型的なエラーの可能性を減らすオペレーターシナリオを開発しました。 「ホーム」地域のシートの認証ラベル（署名の約80％は本社のある地域からのものです）は、落ち着いた雰囲気の中でコレクターによって事前に記入されています。 シートのすべてのブロックについて、Reaperはそれらがどのくらい正確に記入されるべきかを示します。





充填インターフェイスは、実際のサブスクリプションシートをシミュレートします。これは現在、オペレーターの前のテーブルにあります。 使用中の行、記入用の列、シート番号、大-入力用のデータを表示します。



塗りつぶされた行の場合、オペレーターはそのステータスを示す必要があります（最初に行を正常に入力できるとは限りません）。 各修正と削除は、シート上のコレクターからのメモと、データベース内の対応するステータスに対応する必要があります。



シート全体に記入した後、コレクターの日付と署名が貼り付けられます。 シートは検証のために送信されます。

署名の検証、本社でのシートの使用

各営業日の終わりに、署名付きのすべてのシートは検証の対象となります。検証は夜遅くまたは夜に行われます（本社は小さく、すべてのプロセスを並行して実行する場所はありません）。 審査官（候補者の認定代理人）は、各シートと各署名を見て、パスポートのスキャンされたページの断片と比較し、すべての重要な要素のチェックリストをチェックします。 エラーが検出された場合、これは特別なインターフェースに表示されます。

検証レコードは個別にチェックされます。 認定エラーは、シート全体に一度に影響するため、特に危険です。 これらのエラーは、すべての無効な署名の約9％の原因を説明しています。

一部のエラーは修正できますが、署名者が修正できるのはコレクターのみであり、夕方/夜間は本部にいないため、修正に必要なすべての情報は電子形式で送信されます。コンテキストを理解するには、前の行で発生したすべてを確認する必要があります。そのため、レビュアー、オペレーター、弁護士の間には「チャット」がありました。_{画像内のすべての名前およびその他のデータは架空のものであり}、エラーが致命的であるか疑わしい場合、シートは弁護士に送られます。署名にエラーが含まれていない場合、またはすべての修正が既に行われている場合、検査官は受託者の署名を入れ、中央本社に送信するシートを送信します。

絵文字と幸福の神経生理学

チェックされた文字列のステータスを迅速かつエラーなしで選択するために、絵文字の形のボタンを使用しました。深い神経生理学的原因があります。脳の視覚系には、特定の画像に反応する古代の低レベルのメカニズムがあります。視覚システムは、さまざまな方向の直線のセグメントに最もすばやく反応します。これは、線が一次視覚野によって簡単に検出されるためです。二次視覚野では、単純な幾何学的形状（これを学習する必要があります）と顔のパターンが認識されます。さらに、認識されるのは顔だけではなく、主要な表情です。つまり、絵文字。直線認識のように、それは生来の能力です。このような低レベルのシステムのおかげで、絵文字はテキストよりもはるかに高速かつ正確に認識されます。





絵文字の形のアイコンは、審査官が署名を割り当てることができるステータスの意味によく対応しています：「良い」、「問題がある」、「悪い」。「弁護士に見せてください」の絵文字には疑問がありましたが、私たちはそれに対処しました。



絵文字はインターフェイスを人間化するため、オペレーターの寿命がわずかに向上するという意見がまだあります。これは重要です オペレーターは私たちのシステムを長時間使用しなければならず、警戒心を失うことはありませんでした。

シートを送信する

完成したシートは、毎日本部に送られます。シートは多数、数百になります。どのシートが準備ができて本社を離れたかを正確に知りたいのですが、手動で登録するのは長くて信頼性がありません。送信されたシートを記録するモバイルアプリケーションが作成されています。







本部の処理ステップをすべて通過していないときに誤ってシートを送信しようとした場合、数百枚のシートとレポートのコードをすばやくスキャンできるモードがあります。1枚のシートをスキャンするには1〜2秒かかります。



スキャン後、シートはパッケージ化され、モスクワに送られます。

フォームの詳細

すべてのパスポートデータは、等幅フォントSource Code Pro Regularで入力および表示されます。その中で、ゼロは文字「O」と区別しやすく、文字は現代のパスポートで一般的に使用される文字と非常に似ています。



すべてのフォームは、フィールドとメインボタンの間でタブを切り替えることができるように作成されています。入力フォーカスは、ページをロードするときだけでなく、エラーメッセージを閉じた後でも目的のフィールドにあります。モーダルダイアログはフォーカスをキャプチャするため、コントロール間でのみ切り替えが行われます。







すべてのボタンは、押されると、長持ちするもので、外観がすべて表示されます。入力フィールドは、データ送信中は無効です。エラーの場合、詳細な説明が表示されます。

シートの物流と物理的保管

紙片の移動は、人類が信じられないほどの成功を収めた活動の1つです。文房具店に行って、署名を収集するためのセット「Federal」を購入し、詳細については考えないように思えます。しかし、問題があります。すべてのオフィスソリューションは高価すぎます。数万ルーブルのドキュメントのスキャナーと、10万の吊りフォルダーを備えたキャビネットを各本社に届けることができないため、各段階で即興の素材から何かを発明し、作成する必要がありました。

プロセスの物理学に関するいくつかの事実

315千の署名を渡す必要があります。これを行うには、地域のクォータとさまざまなエラーのマージンを考慮して、約100万の署名を収集して処理する必要があります。各シートには最大5つの署名を含めることができますが、実際には約3〜4になります。これにより、およそ30万枚のシートが得られます。



A4用紙の面積は1/16m²です。

通常のオフィス用紙の密度は80 g /m²で、各シートの重量は5 gです

。500枚のスタックは、空白のシートで4.5 cm、充填済みのシートで6 cm以上です。



収集されたすべてのシートの重量は1.5トンで、1つのパックに折りたたまれると、高さは約36メートルになります。

これをすべて保存する方法は？

署名シートが印刷され、署名が記入され、チェック、認証され、中央本社に毎日送信されます。 1つの本社が1日に数百枚のシートを送信するため、この段階で問題は発生しません。



最も興味深いのは、中央本社から始まります。そこでは、地域の本部からシートを取り出して、収集の最後までそれらを操作しやすくするようなストレージシステムを編成する必要があります。収集が完了したら、シートを地域ごとにグループ化し、選挙委員会のフォルダーに縫い付ける必要があります。



弁護士はいつでも特定のサンプルに応じてシートの一部を削除したい場合があるため、シートを無限に束ねることはできません。シートをすばやく取得して戻すには、各シートの正確な位置を知る必要があります。



すばやくアクセスするために、シートの物理的なベースにインデックスを付けるシステムが発明されました。インデックスは、本部（ボックス）、ボックス、フォルダーのいくつかのレベルで構成されています。アーカイブ内のフォルダアドレスは、77-1-15のようになります。各フォルダー内には25枚のシートがあります（ランダムな順序）。





<sub>左上の写真には、紙のフォルダーにある500枚の署名シートのボックスがあります。

右側の写真は、吊りフォルダーにある2000枚の引き出しです。</sub>

シートの取得と並べ替え

地域から送られてくるすべてのシートは、自動両面スキャナーでスキャンされます（彼はすでにオフィスにいたので、レゴとArduinoから自分で収集する必要はありませんでした）。このデバイスは、SFTPを介して結果をサーバーにアップロードできます。そこで、スキャンはPythonスクリプトを介して実行され、標準の場所でQRコードを検索し、認識して、スキャンを共通データベースに添付します。このスクリプトは、しわになったシートでも確実に処理します。







スキャン後、シートがソートされます。各シートは、モバイルアプリケーション（ソートモード）を使用してスキャンされます。システム内でシートを検出し、ステータスを「中央本社に来ました」に変更し、シートを配置する必要があるフォルダーの座標を表示します。オペレーターは、指定されたフォルダーにシートを入れたことを確認します（トランザクションを閉じます）。







1つのリージョンのシートは、スペースが空いている間にフォルダーに順番に配置されるため、プロセス全体が非常に迅速に行われます。

バックエンド

2018 Reaperは、標準テンプレートエンジンとORMを使用してDjangoで作成されています。データベースはPostgreSQLです。システムのサービス部分-FIAS、パスポート検証、事前登録データの操作-は、独自のデータベースを備えた別個のモジュール（djangoアプリ）に配置されます。



署名の物理的な世界は、サブスクリプションシート、シート内の行、署名というオブジェクトのいくつかのクラスの形式で表示されます。これらのクラスのオブジェクトには、実世界のオブジェクトの状態を反映する属性があります。状態管理のために、「有限状態マシン」テンプレート（状態マシン、有限状態マシン）およびdjango-fsmライブラリーが使用されました。状態間のすべての遷移はFSMトランザクションの形式で登録され、その中で必要なチェックとオブジェクトの追加アクションが実行されます。



状態図は次のようになります。







空間内のシートの位置は、シートに含まれる行の状態によって決まります。弁護士が確認すべき行がある場合、シートは「弁護士」のステータスを受け取ります。弁護士がシートを受け取り、検証インターフェイスにコードを入力するとすぐに、シートは「弁護士から」というステータスを受け取ります。したがって、我々は常にすべてのシートの正確な位置を知っており、それらの即時の運命を理解しています。

テスト中

署名収集システムにはさまざまな状態と遷移があり、それらを手動で確認することはできません。チェックを自動化するために、オペレーターと検証者の作業に関連するすべてのスクリプトは、django側のテストでカバーされます。



これらの署名がない場合、100万個の署名を収集するシステムを調べることは無意味です。データベースを満たすために、収集プロセス中にデータベースの一般的な状態を初期化するスクリプトが作成されたため、実際のデータに似たもので満たされたシステムを見ることができます。



署名の収集は非常に限られた時間であり、この時間の大部分は正月休みになります。本社と収集システムの負荷が不均一になると予想していました。システムが署名の現実的なストリームに簡単に対処できることが重要でした。ピーク時には、1時間あたり最大10,000の署名が予想されていました。通常のWebサイトの場合、これは深刻に見えませんが、この場合、「訪問者」のこの順序はサーバーに大きな負荷をかける可能性があります。これは単なる訪問または登録ではありません。各署名の受信には、サーバーへの約50件の要求と、いくつかの高解像度画像の処理が含まれます。



負荷テストはLocustで行われました。。これは、PyPIから入手できるシンプルなツールです。スクリプトは、Djangoの単体テストによく似たpythonコードとして記述されています。







テストは、リクエストの速度、クライアント数、サーバー応答時間のグラフを表示するWebインターフェースを介して実行できます。







プロジェクトの展開は、サイト「Bulk 20！8」と同じ方法で編成されます。

Reaper Webアプリケーションは、本社のVPNを介してのみアクセスできます。

モニタリング

さまざまなツールを使用して、署名収集システムに関係するサーバーとアプリケーションを監視します。



Zabbixは、プロジェクト内のすべての仮想マシンのステータスを監視します。



Elasticsearchはすべての仮想マシンからnginxログを収集します。Kibanaはこれをグラフで示します。Sentryでは、アプリケーションおよびフロントエンドからのすべてのエラーがふらつきます。フロントエンドは別の「組織」に配置されるため、バックエンドエラーの統計情報が損なわれることはありません。便利なことですが、Sentryを負荷の下で動作させることは非常に困難でした。

ガチョウ

これは機能的な監視であり、uptime.comに似たもので、自家製です。バックエンドはdjangoで構築され、キューはセロリで作成され、バックエンドはredisで作成されます。



プロジェクトドメインがGooseに追加されます。各ドメインについて、監視するアドレス、検証の間隔、および検証の種類が示されます。証明書、コンテンツ、HTTPヘッダー、リダイレクト、およびその他の有用なものを確認できます。



何か問題が発生した場合、Gusは深夜に手紙やSMSを送信したり、電話をかけたり、人間の声で状況を説明したりできます（通話と音声合成にTwillioサービスを使用）。



Webインターフェースには、どのドメインにエラーがあり、チェックのキューがどのように機能するかが常に表示されます。毎分、20〜25のチェックが行われます。







Gusでも、モバイルアプリケーションからボットネットを介した分散監視があります。アプリケーションは、監視するアドレスのリストを受信し、それらをチェックして（応答ステータスと指定されたコンテンツの存在）、結果をサーバーに送信します。このような監視は、Roskomnadzorロックと攻撃を受けているサーバーの状態を監視するのに便利です。

---

次の最終章では、IT部門のプロジェクト管理について説明します。