Dette er også en historie om hvordan et lite team ved hjelp av gratis programvare og rimelige komponenter skapte et komplekst system for innsamling av signaturer i landsomfattende skala. Det er ingen komplekse tekniske løsninger i prosjektet, men det er mange viktige detaljer som ikke kan forutses basert på typisk IT-utviklingserfaring.

For enkelhets skyld er materialet delt inn i fire innlegg, som best leses sekvensielt.

Dette er teknisk materiale, men mange av problemstillingene som diskuteres her er uforståelige uten et minimum av kunnskap om samtidens politiske kontekst, så det dekkes etter behov. Hvis du av en eller annen grunn er redd for ordet "Navalny" (det vil vises flere ganger) eller omtale av demokratiske institusjoner, bare ikke les denne teksten. Politiske spørsmål vil ikke bli diskutert i kommentarfeltet.

Kampanjemål

Registrering av Alexei Navalnyj som presidentkandidat.

Oppgaver tillagt IT-avdelingen

(i kronologisk rekkefølge):

Forhåndspåmelding av alle som er klare til å signere for nominasjonen av vår kandidat;
- Sikre driften av et nettverk av hovedkvarterer i hele Russland;
- Opprettelse av et system for å samle 315 tusen ideelle signaturer.

Historisk og politisk kontekst

Hvis du ikke har et stortingsparti, må du samle underskrifter for å delta i valget. Dette er en beskyttelsesprosedyre som brukes for å hindre "ukoordinerte" kandidater fra å delta i valg.

Uendelige muligheter for avslag på registrering er fastsatt på nivå med innsamlingsregler:

• Innsamlingen av underskrifter er strengt begrenset i tid;
• I følge loven tildeles en liten prosentandel av nødvendig antall underskrifter til ekteskap, det er umulig å sende inn underskrifter med god margin;
• Det er umulig å verifisere signaturer på vår side, siden velgerdata må samsvare med FMS-databasen, som kun offentlige organer har tilgang til;
• Ved kontroll hos den sentrale valgkommisjonen kan en grafolog avvise enhver signatur og bærer ikke juridisk ansvar i tilfelle feil;
• Selve verifikasjonsordningen forutsetter at det vil være en betydelig prosentandel falske positiver (paradokset til Bayes' teorem som valgbarriere).

Vi har allerede møtt dette i Novosibirsk, da vi samlet inn underskrifter for å delta i valget til den lovgivende forsamling.

For å samle signaturer i Novosibirsk opprettet vi Reaper-systemet, som var fokusert på å samle signaturer "i felten" og på kuber, administrerte rutene til samlere, tok hensyn til alle signaturark og gjorde det mulig å rangere signaturer basert på resultatene av ulike sjekker.

Samlere i Novosibirsk brakte mer enn 16 tusen underskrifter, hvorfra vi valgte og sendte inn de beste 11 722. Til tross for det strenge utvalget identifiserte arbeidsgruppen til valgkommisjonen mange "ugyldige signaturer", og valgkommisjonen nektet å registrere kandidatene. Les mer om de absurde årsakene til at signaturer blir ugyldige.

Det nye systemet ble bygget under hensyntagen til den akkumulerte erfaringen med å samle underskrifter og deres påfølgende beskyttelse i valgkommisjonen.

Funksjoner i den nye signatursamlingen

Det er etablert enda strengere vilkår for å samle underskrifter for å nominere en presidentkandidat:

Ikke mer enn 315 tusen signaturer kreves;
- Minst 300 tusen signaturer må anerkjennes som gyldige;
- Ikke mer enn 7500 underskrifter fra én region telles;
– Den korte henteperioden (fra 27. desember til 31. januar) faller sammen med den lange nyttårsferien, da mange reiser på ferie.

Med hensyn til tidligere erfaring og nye krav har vi tatt i bruk følgende grunnleggende prinsipper.

All-russisk nettverk av hovedkvarter

På grunn av regionkvoter var det umulig å jobbe i for eksempel de ti største byene. 315 tusen underskrifter kunne samles inn hvis minst 40 byer ble dekket. I tynt befolkede regioner er det vanskeligere å samle underskrifter, så i praksis, for vellykket innsamling, var det nødvendig å åpne hovedkvarter i de fleste regioner i landet.

Prognosen for antall underskrifter på tidspunktet for vellykket gjennomføring av innsamlingen viser at i store byer vil antallet personer som er villige til å signere betydelig overstige regionale kvoter. Moskva (127 tusen) og St. Petersburg (63 tusen) passet ikke på skjermen.

Innsamling av underskrifter kun ved hovedkvarteret

Vi måtte ansette flere tusen plukkere for å samle dør til dør. Alle som noen gang har jobbet med betalte samlere (eller for eksempel sosiologistudenter) vet at ikke alle er like følsomme for prosedyren, og ikke alle overvinner fristelsen til å bare "tegne" en signatur eller to. Uforsiktig utfylling fører til en stor prosentandel av defekter, og å "tegne" underskrifter er et så vanlig problem at den sentrale valgkommisjonen sørger for en sjekk av en grafolog. Selv tilstedeværelsen av en grafolog i staben og den demonstrative utførelsen av flere uttalelser til politiet kan ikke 100 % kvitte seg med hovedkvarteret for "tegnere" (vi sjekket). I tillegg kan samleren legge til signaturer ikke bare av ondsinnet hensikt, men også tvert imot for å "hjelpe hovedkvarteret."

Vi visste at når vi samler «i felten», ville vi definitivt bli introdusert for «giftige samlere», slik tilfellet var i Novosibirsk. Giftige samlere gjør bevisst feil i velgerdata (for eksempel endrer de ett siffer i et passnummer). Deres oppgave er å øke antallet ugyldige signaturer over grensen hvoretter valgkommisjonen nekter registrering. Novosibirsk brukte mye krefter på å rydde opp i giftige signaturer. Dette er umulig å gjøre ved innsamling i hele landet.

Bare i stasjonære hovedkvarter var det mulig å sikre tilstrekkelig kvalitet på signaturer, betingelser for nøyaktig utfylling av signaturark og deres sikkerhet.

Flertrinns signaturverifisering

Ideelle signaturer er en matematisk abstraksjon. Selve innsamlingen av underskrifter er en kompleks og vanskelig prosess. Selv ærlige og veltrente montører gjør feil, og under forhold med mangel på tid, administrativt press og provokasjoner vil det være enda flere mangler.

Vi har mye data om hvordan feil oppstår. Vår erfaring er at i underskriftsark samlet på en helt ærlig måte, vil det være omtrent 10 % av underskriftene som valgkommisjonen anerkjenner som ugyldige.

Vi måtte levere ikke bare gode underskrifter, men underskrifter som valgkommisjonen ville akseptere. Dette krevde flere stadier av verifisering og en rangeringsmekanisme – for å velge ut og sende inn kun de signaturene som mest sannsynlig ville bestå valgkommisjonens kontroller, uansett hvor absurde vi måtte vurdere dem.

Passskanning for hver signatur

Uten skanning ligger alt ansvar for kvaliteten på signaturen hos innsamleren. Om han ved et uhell eller med vilje gjorde en feil i passnummeret, får vi aldri vite.

Av erfaring har vi funnet ut at bare feil ved omskriving av passdata til signaturarket og datainntastingsfeil lett uttømmer den tillatte grensen på 5 %, selv om underskrifter samles inn under komfortable forhold og av samvittighetsfulle samlere.

Ved å ha en skanning av dokumentet kunne vi utføre flere uavhengige stadier av verifisering av signaturen og foreta korrigeringer.

I tillegg forberedte våre advokater seg på å kjempe for hver underskrift i retten. Forrige gang var det en stor kategori av avviste signaturer, som vi visste med sikkerhet: Signaturen tilsvarte passet, men vi sjekket den mot en utdatert og feilfylt database. En enhetlig database og tilgjengeligheten av skanninger vil tillate advokater å automatisere prosessen med å forberede klager i slike saker.

Selvfølgelig var det mulig å skanne et pass kun ved hovedkvarteret, ellers ville det være umulig å sikre et tilstrekkelig sikkerhetsnivå for personopplysninger.

Synkronisering med elektronisk database

Alle operasjoner med signaturer og signaturark, alle statuser og bevegelser måtte reflekteres i den elektroniske databasen. Signaturinnsamlingssystemet måtte overvåke alle stadier av innsamlingen og identifisere feil. Dette er den eneste måten vi kan opprettholde orden (og sjelefred) når vi arbeider med hundretusenvis av fysiske objekter.

Hva er gjort i den nye versjonen av systemet

• For at vi skal ha et sted å samle underskrifter, har vi distribuert et nettverk av regionale hovedkvarterer. IT-infrastrukturen til hovedkvarteret består av flere fysiske servere, en rekke virtuelle maskiner, 70 rutere, 230 kameraer og 189 komplette arbeidsstasjoner. Mer enn 250 personer bruker systemet internt samtidig.
• For å bringe flere hundre tusen mennesker til hovedkvarteret i løpet av en kort innsamlingsperiode, begynte vi å registrere velgere på forhånd på 20!8-nettsiden, hvor de forhåndsbekreftet dataene sine.
• For å redusere antall feil har vi laget et system som tillater uavhengig verifisering av riktigheten av å fylle ut abonnementsarket. Systemet består av flere nettapplikasjoner og en mobilapplikasjon for to plattformer.
• For å laste inn data i systemet, satte vi sammen (og produserte delvis) et sett med utstyr for skanning av pass, tenkte ut et opplegg for sikker overføring av personopplysninger og implementerte det ved alle hovedkvarterer.
• For å sikre at formateringen av adressen var riktig fra valgkommisjonens synspunkt, startet vi et søk i FIAS-databasen og sammen med advokater fikset vi seriøst med den for å ta hensyn til alle lovens krav.
• For å (delvis) sikre hovedkvarteret vårt og ha ytterligere argumenter i domstolene, har vi etablert et 24-timers videoovervåkings- og opptakssystem.
• For å teste infrastrukturen, mekanikken, klargjøre data og forberede hovedkvarteret for innsamling, gjennomførte vi en stor prosedyre for foreløpig verifisering av velgere, som 81 750 personer gikk gjennom.
• Vi utviklet utseendet til abonnementsarket, et system for logistikk av ark ved hovedkvarteret, samt et system med fysisk lagring og rask tilgang for det sentrale hovedkvarteret.

Kjerneteknologier i våre nettapplikasjoner

Hovedspråk for backend: Python.
Frontend: JavaScript, jQuery, React, D3.js.
Rammer: Django (6 stk), aiohttp (1 stk).
Database: PostgreSQL, Redis og andre.
Fulltekstsøk: Sfinks.
HTTP-server: Nginx, lakk.
Testing: Jenkins, Browserstack, RobotFramework, Locust.
Overvåkning: Zabbix, Elasticsearch, Kibana, Sentry.
Utplassere: Ansible og andre verktøy.
Serverkonfigurasjonsadministrasjon: Kokk.

Del én: Navalnyj 20!8-nettstedet

Vi måtte bringe flere hundre tusen mennesker til hovedkvarteret i løpet av en svært begrenset periode. For å gjøre dette begynte vi å registrere støttespillere akkurat den dagen kampanjen startet. Å rekruttere og registrere støttespillere er en av hovedoppgavene til nettstedet til Navalny 20!8, så det er et registreringsskjema på nesten hver side.

Siden alt dette er nødvendig ikke bare for vakre talls skyld, var det viktig for oss å vite at de registrerte supporterne er ekte mennesker, ikke roboter, for å kunne opprettholde kontakten med dem og forstå hvilken by de er registrert i (i for å forutsi oppfyllelse av kvoter etter region). Registrering på nettstedet var derfor ganske komplisert og krevde bekreftelse av telefonnummeret. For ikke å lure oss selv og andre, inkluderte vi kun personer som fylte ut hele skjemaet og bekreftet telefonnummeret sitt som potensielle underskrivere. Derfor, på hovedsiden, i stedet for mer enn en million (totalt antall registreringer), har vi nå bare 706 513 "fremtidige signaturer".

Fra et nettstedbyggingssynspunkt er dette et ganske vanlig produkt. Siden er laget i Python + Django + PostgreSQL, ved hjelp av en standard ORM og et standard adminpanel. I løpet av halvannet år gjennomgikk siden flere oppdateringer: seksjoner ble lagt til, driften av registreringsskjemaet endret, tekster og bilder på sidene endret. Vi prøvde å ikke komplisere designet slik at vi kunne layoute med standardblokker, takket være at noen seksjoner gikk fra idé til lansering på tre dager.

Omtrent halvparten av besøkende på et moderne nettsted kommer fra mobile enheter. Vi prøvde å gjøre nettstedet praktisk for alle, så oppsettene ble tegnet og lagt ut for korrekt visning på alle skjermbredder, fra 320px.

Hovedkvarter kart

Det eneste komplekse interaktive elementet som besøkende ser er et kart over Russland med hovedkvarter merket på. Da antallet hovedkvarterer passerte 50, ble det vanskelig å navigere på kartet på grunn av den nære plasseringen av markørene i den europeiske delen av landet. Opprinnelig ble kartet tenkt som et rent dekorativt element, men plutselig ble det fylt med funksjonalitet, så for de som allerede satte pris på den føderale karakteren til kampanjen og bare vil finne byen sin, opprettet vi en listemodus.

Kartet er laget ved hjelp av det fantastiske og allsidige d3.js-biblioteket. Vi bestemte oss for å skrive vårt eget skript i stedet for å bruke standard Google Maps eller Yandex.Maps på grunn av kartprojeksjonen. Det er mange måter å lage en utvikling av jordens ellipsoide på et fly. I Mercator-projeksjonen er objekter sterkt strukket på nordlige breddegrader, og vi trenger mer plass i de områdene hvor de største store byene er konsentrert. I tillegg, i Mercator-projeksjonen, ser Russland ganske merkelig ut. Vi valgte Albers-Sibir kjegleprojeksjonen, som er mer kjent fra geografi lærebøker.

Russland til en sunn person (Albers konisk projeksjon) og Russland til en røyker (Mercator-projeksjon)

Filbehandling

Den redaksjonelle delen av nettstedet er ikke særlig interessant. Det vanlige Django-adminpanelet brukes med minimal tilpasning. Med begrensede utviklingsressurser er det mer lønnsomt å lære flere admin-brukere å bruke et standardverktøy enn å bruke tid på å lage et virkelig praktisk.

Noen løsninger som gjør livet til redaktøren enklere ble hentet fra andre prosjekter. For eksempel et verktøy for typografi av tekster på klientsiden. Typografien vår er praktisk fordi den enkelt kobles til et hvilket som helst tekst- eller strenginndatafelt. Informasjon om tilstanden til autotypografi (på/av) lagres som et ikke-utskriftstegn på slutten av linjen og er ikke avhengig av backend på noen måte.

For å jobbe med komplekst innhold i innlegg og nyheter bruker vi en blokkredigerer, som også brukes i mange andre prosjekter:

Det finnes forskjellige typer blokker, hvert prosjekt har sitt eget sett. Hver blokk inneholder innhold og kan inneholde innstillinger. Blokkdataene lagres i databasen i form av json, og markeringen inne i tekstblokken lagres i markdown-format.

For visning konverteres blokker til det nødvendige formatet: HTML for et innlegg, tekst for indeksering, RSS eller XML for Yandex.Zen, JSON for en mobilapplikasjon, og så videre. På denne måten får vi forutsigbare resultater på alle enheter med ganske kompleks innholdsformatering.

Den første versjonen var basert på Sir Trevor-koden. Senere, da Sir Trevors spaghettikode ble vanskelig å vedlikeholde, ble redaktøren skrevet om i React.

Analytics

Det mest interessante fra et teknisk synspunkt skjer i administrasjonsområdet på nettstedet. Derfra så vi på strømmen av registreringer.

Til å begynne med var analyse ganske primitiv: grafer over antall registreringer av ulike typer over tid. Men vi ønsket å se dynamikken etter region og spore effekten av ulike hendelser på antall registreringer. Slik så den etterlengtede analysen ut:


Denne skjermen inneholder sammendragsinformasjon for hele nettstedets levetid, en tidsplan for en bestemt periode og en liste over hendelser for denne perioden. Du kan markere en topp på diagrammet og prøve å forstå hvilken hendelse som forårsaket den. Oftest er dette publiseringen av en annen video med en undersøkelse på Navalnys YouTube-kanal. Den største økningen i underskrifter kom fra videoer om intrigene til regionale tjenestemenn.

Diagrammet er laget i d3.js, og hendelsesfiltrering etter tid og hovedkvarter er implementert ved hjelp av Crossfilter-biblioteket. Denne løsningen lar deg operere på klientsiden uten grensesnittforsinkelser med registreringsdata over et intervall på mer enn ett år i intervaller på 1 time. Foreløpig er dette 12 megabyte med data (1,3 MB i gzip).

En liten tekstrapport med nøkkelindikatorer for registreringsgrunnlaget og suksesser for forrige dag ble automatisk sendt ut daglig til alle prosjektdeltakere.

By og region

Vi har også en stor tabell der hovedindikatorene for forberedelse til innsamling av signaturer er oppført for hver region i Russland:

Tallene i denne tabellen ønsket ikke å konvergere med det første. Totalen etter by var betydelig mindre enn antall registreringer. Det viste seg at når folk fyller ut et spørreskjema på nettstedet, gjør folk uventet ofte feil i navnet på byen eller bruker ikke-standardnavn:

Moskva - 2,5 % feil og 579 stavevariasjoner;
- St. Petersburg - 12,6 % feil og 767 stavevariasjoner;
- Komsomolsk-on-Amur - mer enn 20% feil og forkortelser, 75 alternativer.

Et feil estimat av antall støttespillere kan føre til feil planlegging av nettverket av hovedkvarter og kampanjearrangementer. Jeg måtte tenke på hvordan jeg kunne gjøre brukerinndata for et bynavn til et standard regionnavn. For et så enkelt skjema ønsket jeg ikke å bruke autofullføringsmekanismer i henhold til KLADR eller FIAS. Derfor tok vi en liste over de 700 største byene i Russland, la til en liste over typiske stavemåter ("spb", "n-sk") og gjorde et løst søk på dem, rangerte dem etter Levenshtein-avstand (dette er et mål på forskjellen mellom to sett med tegn).

Vi klassifiserte hver by på listen i en av tre kategorier basert på avstanden til nærmeste hovedkvarter: hovedkvarteret er i byen, hovedkvarteret er nært (bymessig agglomerasjon), hovedkvarteret er langt unna. Avstanden fra hovedkvarteret ble tatt i betraktning ved estimering av antall personer som ville ankomme og signere til rett tid. I analysene telte vi hver for seg alle underskrivere og "tilgjengelige" (bekreftet e-post, bor i byen med hovedkvarter eller i nærheten).

Denne grafen viser hvordan kampanjen ble stadig mer regional over tid. Andelen nyregistreringer fra Moskva og St. Petersburg gikk ned fra 35 % til 15 %.

SMS og mail

En annen teknisk vanskelighet var å sende SMS og brev. Gatewayer leverer ikke meldinger særlig godt, spesielt til utenlandske numre. Men vi ønsket den reneste og mest autentiske base av supportere, så den andre delen av registreringsskjemaet krevde bekreftelse av telefonnummer via SMS. For pålitelig sending roterte vi tre gatewayer: Hvis meldingen ikke ble levert, ble den sendt igjen gjennom en annen gateway. I tillegg kan individuelle gatewayer slås av i tilfelle feil på deres side. Leveringshastigheter for SMS-koder er en av parametrene som overvåkes:

Grafen viser at gatewayene sviktet to ganger. Andelen leverte SMS falt betydelig 21. februar og 17.-18. april på grunn av feil i meldingskøen. Og 15. juli endret vi layout på registreringsskjemaet, dette merkes også på grafen.

Vi sender et stort antall brev til en database med mer enn 700 tusen e-postadresser. Noen abonnerer på nyhetene, noen bør motta et varsel om arrangementet. I tillegg må hver adresse bekreftes i henhold til 2-opt-in-reglene (dette er når den første bokstaven inneholder en lenke som du må klikke for å bekrefte abonnementet på nyhetsbrevet). I begynnelsen av kampanjen brukte vi ActiveCampaign-tjenesten, men den var dyr og utrolig treg. Da databasen oversteg 300 tusen kontakter, ble det umulig å jobbe. Derfor skrev vi vår egen CRM / posttjeneste, som lar deg lage e-postlister og brevkjeder basert på de nødvendige prøvene. Mailgun brukes for tiden til å levere brev.

Utsatte oppgavekøer

Å sende e-post eller SMS gjennom API-en til tredjepartstjenester er en operasjon som tar betydelig tid. Slike operasjoner bør utføres asynkront for ikke å bremse brukergrensesnittet eller sette hele applikasjonen under belastning. I utgangspunktet fungerte alle asynkrone oppgaver gjennom Celery med Redis som megler. Hver e-post eller SMS-melding opprettet en oppgave i Selleri-køen, hvoretter en ledig arbeider behandlet denne oppgaven. Men denne tilnærmingen viste seg å være upålitelig og for ressurskrevende.

En gang mottok vi mer enn 10 tusen registreringer på en time (nei, vi ble ikke vist på TV, det var en "+1"-kampanje). 10 Selleriarbeidere kunne ikke takle dette, brukere begynte å legge merke til en betydelig forsinkelse i mottak av SMS og post.

Etter denne hendelsen forlot vi Celery til fordel for en enkel kø basert på PostgreSQL. Oppgaver fra køen ble sortert etter "demoner" i Python, en for hver meldingsleveringskanal. En gang hvert 10. sekund tok daemonen en gruppe oppgaver fra køen og sendte dataene i én batch til e-post-API. Gruppering av oppgaver reduserte belastningen på serveren radikalt, og bruk av en hjemmelaget kø gjorde feilsøking og overvåking ekstremt enkelt.

Selleri viste seg å være et for komplekst verktøy for vår oppgave. Det krever gjennomtenkt konfigurasjon og overvåking gjennom eksterne verktøy som Flower, som i seg selv bruker mye ressurser. På andre prosjekter prøver vi å bruke en enklere løsning - RQ + Redis.

Sammenligning av kompleksiteten til RQ og Selleri fra en artikkel om arbeid med asynkrone oppgaver.

Utviklingsprosess

Hvordan fungerer prosessen med å lage Navalny 20!8-nettstedet fra utviklerens synspunkt? Vi følger ikke en enkelt metodikk, men bruker tilnærminger fra forskjellige systemer. For eksempel setter ledere oppgaver i Trello med en struktur som ligner på et Kanban-brett, og utviklere bruker individuelle praksiser for ekstrem programmering.

Omtrent halvparten av teamet er lokalisert på Moskva-kontoret, og resten jobber eksternt. Moskva-ansatte kan delta på kampanjemøter for ikke å jobbe med å forstå helhetsbildet bedre, men vi diskuterer oppgavene til IT-avdelingen separat. Regelmessige samtaler lar alle synkronisere og forstå hovedretningen for arbeidet i hvert øyeblikk.

De fleste av prosjektdeltakerne jobber med det på heltid, men noen oppgaver ble utført av utviklere midlertidig hentet inn fra andre prosjekter, eller til og med av frivillige. For eksempel opprettet frivillig Ilya nesten fullstendig et kart over hovedkvarteret for hovedsiden.

Kildekoden er lagret i et git-lager på Bitbucket-plattformen. En egen gren opprettes for hver nye større oppgave. Vi lager ikke en oppsamlingsserver for hver gren; de er alle slått sammen til utvikling for å kjøre på en enkelt testserver. Etter testing sender utvikleren som er ansvarlig for oppgaven en pull-forespørsel til masteren. Teamlederen ser på koden og, hvis alt er bra, starter distribusjonen. For store oppgaver skriver utviklere detaljerte beskrivelser av hva som må sjekkes og hva som kan gå galt under utrulling.

Utplasseringen er veldig enkelt organisert. Vi har et verktøy som svarer på en webhook fra Bitbucket (eller en knapp fra grensesnittet), tar koden fra ønsket gren, kopierer den til serveren og kjører oppdateringsskriptet der. Skriptet er formatert i en Makefile.

Når du kjører "gjør oppdatering", oppdateres avhengigheter, migreringer utføres, statiske filer etterbehandles, og hvis alt gikk bra, startes uwsgi-serveren på nytt. Vi prøver å gjøre migreringer slik at de ikke bryter den gamle koden, så i tilfelle distribusjonsfeil fortsetter alt å fungere.

Utviklingen startet 18. september 2016. Siden den gang har det vært 1228 commits, 200 pull-forespørsler, distribusjonen har blitt presset i produksjon over 600 ganger, og det har vært 67 filialer i depotet (de fleste av dem er nå stengt).

Om design

I prosjektteamet jobbet kun to personer konstant med designet (en art director med produktfunksjon og en designer), mens begge var aktivt involvert i andre kampanjeprosjekter. Derfor var tilnærmingen til design ekstremt utilitaristisk.

I utformingen av IT-produkter styres vi alltid av to grunnleggende prinsipper:

1) Informasjon for den mest "late" og uinvolverte brukeren bør være på det mest synlige stedet (slik har vi for eksempel bestemt de første stedene for blokker og seksjoner på nettstedet);

2) Jo færre personer som bruker sluttproduktet, jo mindre prøver vi å dekorere det (vi sparer utviklingsressurser) og jo mer innsats kan vi tillate hver bruker (det er ofte mer effektivt å lære opp flere personer enn å kaste bort tid på å implementere nye funksjoner som vil spare brukerinnsats eller vil redde deg fra feil).

Det er derfor våre interne systemer med lite brukere streber etter å se ut som en wireframe som kommer til live, og alt en kampanjesupporter møter er en del av den generelle visuelle kommunikasjonen, strengt underlagt bedriftens stil og sunn fornuft.

Et IT-system for innsamling av signaturer er et svært komplekst flerkomponentprosjekt med begrensede ressurser, så hoveddelen av designernes arbeid ble gjort på papir, i møter og i Google Docs, og ikke i en grafisk editor (i vårt tilfelle, Skisse).

Det er mange komplekse diagrammer i prosjektet som du bare vil tegne, og alle de elektroniske verktøyene for å tegne diagrammer som vi fant på stedet passet ikke oss. Noen ganger brukte vi draw.io, men oftere tegnet vi direkte på papir. De viktigste diagrammene hang på prosjektstyret. Papirbilletter med spørsmål til diskusjon på møter var også vedlagt der.

Vi samlet prototyper fra papirdiagrammer og manus avtalt med advokater på marvelapp.com for igjen å sjekke logikken og forsikre oss om at ingenting ble glemt. Først etter dette ble layoutene overført til utvikling.

Avhengig av oppgaven ble det brukt ulike forsknings- og designmetoder. Så før vi gjorde den etterlengtede analysen, gjennomførte vi en serie intervjuer med alle potensielle brukere av systemet (fra stabssjefen til personen som sender utsendelsene), og basert på deres ønsker, var vi i stand til å sette sammen en veldig enkelt grensesnitt, som i lang tid fungerte som et kampanjedashbord.

På den ene siden så vi strømmen av påmeldinger, kunne se hendelsene som påvirker den, og finne ut hvordan supporterne våre er fordelt på tvers av byene. Vi samlet også rangeringer av byer etter antall underskrivere (dette tillot oss å overvåke effektiviteten til hovedkvarteret og fortalte oss om vi hadde valgt de riktige byene for å åpne nytt hovedkvarter) og tabellanalyse.

For verifikasjonsgrensesnittene og selve innsamlingen av signaturer var hastigheten på operatørens arbeid en absolutt prioritet. Innsamlingen skjer under forhold med akutt tidspress, så vi prøvde å spare hvert sekund og samtidig redusere antall potensielle brukerfeil.

I følge våre beregninger, med det eksisterende antallet hovedkvarterer og underlagt en kontinuerlig strøm av mennesker, skulle hver samler ikke ha tatt mer enn 6 minutter per person - fra "hei" til fullføringen av innsamlingsprosedyren.

Verifisering og innsamling av signaturer gjennom et IT-system er en prosedyre som er fullstendig oppfunnet av oss, så vi valgte MVP-testing på reelle brukere av systemet som hovedmetode for å teste løsningene våre. Så vi testet den grunnleggende protokollen og det første verifiseringsgrensesnittet på ansatte i Moskva-hovedkvarteret, og dro deretter til tre forskjellige byer (St. Petersburg, Chelyabinsk og Ulyanovsk) for å observere ekte brukere i arbeidet. For slike prosjekter er dette den beste måten å raskt lage en liste over ting og brukertilfeller som kan ha blitt glemt eller ikke forutsett på design- og utviklingsstadiet.

Etter å ha gjort mindre endringer i grensesnittet, ble verifisering lansert ved alle kampanjehovedkvarterer. Som et resultat klarte vi å redusere behandlingstiden for ett spørreskjema til halvannet til to minutter per person.

Testing

RobotFramework ble brukt til automatisert testing. For å dekke den mest kritiske funksjonaliteten til prosjektet, ble aksept- og funksjonstester skrevet og deres automatiske lansering konfigurert. Jenkins ble brukt som et CI-system.

Den viktigste funksjonen til siden er brukerregistrering, som innebærer telefonbekreftelse via SMS-kode. For å teste meldinger med koder ble det konfigurert et GSM-modem med test-SIM-kort og Asterisk. SMS-koden ble sendt til posten, hvorfra den allerede var tilgjengelig for testing.

Oppdagede feil ble lagt til Trello som oppgaver for utviklere.

Serverinfrastruktur

Nettstedet Navalnyj 20!8 fortsetter å fungere og blir gradvis stedet for velgerstreikkampanjen, så informasjonsforbudet er ennå ikke opphevet, og historien blir kort. Serverdelen består av tre nivåer: backend, caching proxyer og edge-servere. Alle konfigurasjoner administreres gjennom kokk, så en server med hvilken som helst rolle kan raskt installeres på en ny virtuell maskin.

Backend kjører en database og applikasjonsforekomster, hver applikasjon på sin egen virtuelle maskin og med sin egen IP. Alle servere finnes i flere kopier, og databasen replikeres i master-slave-modus til en annen maskin.

Proxyserveren har installert Varnish, som cacher forespørsler til bestemte adresser og ulike URL-avhengige begrensninger. Hvis backend svikter, kan nettstedet fungere på ubestemt tid fra en proxy-server; bare brukerregistreringsmekanismen vil bryte.

Edge-servere utfører statisk caching og SSL-terminering (da går trafikken gjennom VPN-nettverket). Essensen av disse serverne er å distribuere hoveddelen av trafikken og beskytte resten av infrastrukturen mot angrep. Dette er svake virtuelle maskiner med gigabit-kanal i forskjellige datasentre. Lasten fordeles ved DNS-balansering. Edge-servere inneholder et minimum av konfigurasjon og kan om nødvendig enkelt installeres på noen få minutter. Den maksimale nyttige trafikken vi hadde på edge-servere var 5 Gbps i flere timer.

Bilder, stiler, javascript, json-data lagres på en slik måte at filnavnet inkluderer en hash av innholdet i denne filen (for eksempel style.28fa1c7b1761.css), slik at alle disse filene kan bufres for alltid på serveren og i nettleseren. Mesteparten av trafikken sendes fra edge-servere. Da går bare forespørsler til innholdssider gjennom, og dette er omtrent 25 ganger mindre data.

Noen ganger er CloudFlare tilkoblet i stedet for edge-servere, men vi prøver å gå tilbake til våre servere, siden CloudFlare ikke alltid har god tilgjengelighet fra Russland. Noen leverandører, selv de største, begynner regelmessig å blokkere IP-en deres (spor av Roskomnadzor).

Konklusjon

Å samle signaturer i tradisjonell stil (uten et spesielt IT-system, med papir, penn og Excel-tabeller) er som å fly en ballong til månen: ja, hvis du tar nok ballonger, kan du til og med ta av og gjemme deg i skyene, men fortsatt å komme til mål på denne måten er fysisk umulig.

For å samle inn slike underskrifter som valgkommisjonen ville bli tvunget til å akseptere selv fra en uønsket kandidat, begynte vi å lage denne komplekse infrastrukturen. I dette kapittelet snakket vi om oppgaven som er lagt foran oss og forberedelsene til å løse den.

Det neste kapittelet snakker om valg og konfigurering av hovedkvarterets nettverksutstyr, utvikling av din egen dokumentskanner og organisering av videoovervåking av hovedkvarterets lokaler.

Det tredje kapittelet vil beskrive prosessen med å lage søknader for innsamling av signaturer og alt knyttet til arbeid med fysiske signaturark.

Fjerde kapittel snakker om prosjektledelse, teamet, tidslinjen og litt om resultatene.

Tags: Legg til tagger

De første dagene etter lanseringen av kampanjen er veldig vanskelige, veldig fulle av aktuelle oppgaver. Og selv om vi alltid har vært (og vil være) tilhengere av maksimal publisitet i arbeidet vårt, bør vi ikke forvente superdetaljerte rapporter akkurat nå. Likevel må jeg si noen få ord.

Hva skjer nå.
Det hele er veldig enkelt: i løpet av et år må vi samle 400-500 tusen underskrifter over hele landet (for å velge 300 tusen av dem, med betingelsen: minst 7500 hver i 40 regioner) innen et par uker etter Nyttårs mas. For at det i det minste skal være en teoretisk sjanse for å gjøre dette, må vi nå bygge om hele infrastrukturen:
- slik at disse 400-500 tusen personene melder seg på hos oss gjennom nettsiden, som vil gi alle data på forhånd og lover å registrere seg på D-dagen;
- opprette regionalt hovedkvarter, rekruttere og lære opp folk som vil utarbeide signaturark og på D-dagen vil kunne superraskt samle underskrifter fra de 7500 støttespillerne som har meldt seg på databasen; – slik at det er penger til hele dette regionale nettverket, til å leie lokaler og betale ansatte, til advokater og til å tiltrekke seg nye støttespillere; Det omtrentlige anslaget gir et budsjett i området 150-200 millioner rubler (vi vil publisere budsjettet snart).

Vi begynte å løse disse problemene i forgårs. På den ene siden ser det ut til å være svært vellykket. I løpet av de to første dagene – på bare 48 timer – registrerte vi kampanjen på nettsiden over 22 300 mennesker(dette er mer enn 7% av minimum påkrevd 300 tusen), og tiltrakk donasjoner i beløpet over 5 millioner rubler(dette er mer enn 3 % av minimumskravet på 150 millioner). Det virker som om du ekstrapolerer, viser det seg at om et par måneder vil alle mål være nådd.

Men du forstår godt at du ikke kan ekstrapolere. Hver neste person og rubel vil være vanskeligere (og dette er helt normalt); det er mye arbeid som skal gjøres. Det var nettopp for å forstå dette at vi lanserte kampanjen nøyaktig et år før starten på den "offisielle" underskriftsinnsamlingen.

Hva gjør hovedkvarteret nå?
Derfor utarbeider hovedkvarteret nå en struktur som skal sikre løsningen av oppgavene vår kampanje står overfor. Forbereder svar på tusen spørsmål:
- hvordan det regionale hovedkvarteret vil bli opprettet, hvor, i hvilken rekkefølge, hvem vil lede dem,
- hvilket propagandamateriell vil de frivillige motta (og allerede mer enn 6100 mennesker ikke bare lovet kandidat Navalnyj sin signatur til støtte for nominasjonen, men lovet også å investere sin frivillige innsats i kampanjen) for å bruke dette materialet til å agitere de "ubestemte",
- hvordan vi vil sikre sikkerheten til hovedkvarteret, frivillige, samlere og selve signaturene;
- hvilke arrangementer vil vi holde i Moskva og i regionene...
Og så videre. Listen er nesten uendelig. Her har vi nettopp skrevet ut en liste over områder i styret – for hvert av disse områdene vil det være målsetting, ansvarlige personer, en strategi og en plan for konkrete aktiviteter – dette er allerede skummelt. Men vi skal klare det, ikke for første gang.

Hvilke spørsmål stiller de oss?
Det vanligste og mest populære spørsmålet er "hvordan hjelpe"?
Det er lett å hjelpe. Se listen over mål ovenfor.
- lover å signere
- Send penger
- sørg for at det er flere signaturer.

Det er det siste vi skal konsentrere oss om i nær fremtid. Tross alt ber vi om en underskrift til støtte for nominasjonen - ikke engang til støtte for kandidaten Navalnyj selv, men til støtte for faktumet om hans deltakelse i valget: for å gjøre presidentvalget konkurransedyktig for første gang i 20 år. Det er ikke bare Navalnyjs støttespillere som kan overtales til å signere en slik signatur; Ideen om at reell konkurranse er nødvendig i valg deles av det overveldende flertallet av russerne (vi gjennomførte en undersøkelse om dette, vi vil også publisere dataene).
Derfor vil vi snart gi frivillige og støttespillere verktøyene til å gå til familie/venner/kolleger - selv om de er skeptiske - og overbevise dem om at de fortsatt vil ha nytte av å signere for Navalnyjs nominasjon (selv om de selv skal stemme på Putin).

Vel, de stiller også mange spørsmål om programmet og andre ting. Kandidaten selv svarer strålende på alle disse spørsmålene; jeg har ikke noe spesielt å legge til her.

Daddies, hvor vi melder inn supportere fra forskjellige deler av det enorme Russland

Hva skriver folk til oss om?
Mange ting. Vi leser alle bokstavene; Vi vil definitivt svare på alt som krever svar.
Den mest hyggelige og søte typen brev er bokstavene "Jeg, Vasya Ivanov, er advokat, jeg bor i Izhevsk, gi meg beskjed når hovedkvarteret vårt åpner - jeg kommer for å hjelpe." Vi tar imot alle slike brev med takk og legger dem i spesielle mapper (se bildet). Og når vi åpner et hovedkvarter i Izhevsk, vil vi skrive til Vasya Ivanov og invitere ham til å hjelpe.

Og de skriver også: "Jeg, Petya Zaitsev, er programmerer, jeg har så mange timer i uken for deg." Og vi legger også disse bokstavene i spesielle mapper. Og vi vil også invitere alle til å hjelpe. Skriv brev, vi leser!

Vel, det viktigste: ha litt tålmodighet. Du har sett listen over veibeskrivelser. Denne elefanten må spises i deler. Vi har et år med arbeid foran oss. Du kan ikke åpne 50 regionale hovedkvarterer på en dag, lage en hel serie med propagandamateriale, holde et hackathon for programmerere og sette opp et propagandatelefonsenter - selv om du selvfølgelig virkelig ønsker å gjøre alt dette så raskt som mulig. Vi vil bevege oss steg for steg, måned for måned, etter en gjennomtenkt plan, innenfor rammen av hvilken alt skal skje i tide. Og etter hvert vil alle som meldte seg frivillig få en reell mulighet til å hjelpe og bidra til

«For nå er dette en PR-historie»

Opposisjonsisten Alexey har samlet inn 300 tusen underskrifter som kreves for å registrere hans kandidatur til det russiske presidentvalget i 2018. Vil han nå få delta i valget?

I henhold til loven "Om valg av presidenten for den russiske føderasjonen" (nr. 19 - føderal lov av 10. januar 2003), må en selvnominert kandidat (dvs. en kandidat som ikke er nominert fra et politisk parti) gi den sentrale valgkommisjonen minst 300 tusen underskrifter av velgere, og hver region bør ikke stå for mer enn 7500 av dem. Teknologisk fullførte Navalnyj oppgaven - han kunngjorde at han allerede hadde samlet 335 782 underskrifter i ikke mindre enn 40 regioner i landet. De har imidlertid ingen rettskraft.

"Signaturer samlet inn før nominasjon og før åpning av en valgkonto er ikke gyldige," fortalte Andrei Buzin, en ekspert innen valglovgivning, oss. La oss forklare. I henhold til samme lov "Om presidentvalg" skjer nominasjonen av en kandidat senest 20 dager fra datoen for offisiell publisering av beslutningen om å utlyse valg. For nå er de planlagt til årsdagen for annekteringen av Krim, 18. mars 2018.

I følge grunnloven vil imidlertid presidentvalget offisielt bli innkalt av føderasjonsrådet tidligst 100 dager og senest 90 dager før avstemningsdagen, det vil si i desember i år. Følgelig vil Alexei Navalnyj offisielt kunne nominere sitt kandidatur til presidentvalget og begynne å samle underskrifter først i desember. Hvis en politiker leverer inn nominasjonsdokumenter samme dag som Forbundsrådet utlyser valg, vil han ha fra 55 til 45 dager på å samle underskrifter. Hvis han samler inn det nødvendige beløpet innen denne perioden, vil den sentrale valgkommisjonen kontrollere deres autentisitet og avgjøre registrering som kandidat.

Navalnyj er selv klar over at signaturene som samles inn nå ikke kan brukes ved innsending av dokumenter til CEC. På nettstedet hans skrev han at for å "samle inn den nødvendige mengden raskt og effektivt i time X," er hver signatur en e-post, telefonnummer og et kort spørreskjema til en potensiell velger.

Det er imidlertid for tidlig å snakke om å registrere Navalnyj som kandidat. Spørsmålet om han i det hele tatt vil være i stand til å nominere sitt kandidatur til presidentvalget er fortsatt uavklart. Etter dommen i ny rettssak av Kirovles-saken, befant opposisjonisten seg i en rettsgaffel. På den ene siden? han ble dømt til fengsel, som betyr at han ved lov ikke har rett til å delta i valg. På den annen side har han fortsatt mulighet til å utfordre denne lovens bestemmelse i forfatningsdomstolen.

Lederen for Senter for økonomiske og politiske reformer, Nikolai Mironov, mener at Navalnyj samlet inn underskrifter for å vise sin politiske tyngde, og at han er i stand til å gjøre dette i fremtiden.

"Dette er en måte å presse på," sa MK statsviteren. – Jeg tenker at dette er et signal til ulike sosiale grupper om å støtte ham, og til ulike sponsorer. Men vi vet ikke noe om kvaliteten på disse signaturene.» Eksperten bemerket at en godt promotert politiker kan samle 300 tusen underskrifter, men dette er veldig vanskelig. "Så lenge denne historien er utenfor valgprosessen, er den for PR," sier statsviteren. – Når selve underskriftene skal samles inn, vil alt avhenge av valgkommisjonene. På et tidspunkt kan han bli avskåret, men så vidt jeg forstår er det ikke noe ferdig scenario for Navalnyjs deltakelse i valget.»

Funksjonæren, skuffet over bloggeren, snakket om den vanskelige situasjonen ved hovedkvarteret.

På bloggerens hovedkvarter Alexei Navalnyj, som fortsetter å samle inn midler til presidentkampanjen, til tross for forbudet fra den sentrale valgkommisjonen og avklaringer fra forfatningsdomstolen, er det igjen forvirring. En fersk FBK-funksjonær og menneskerettighetsaktivist skriver på sin Facebook-side om ledelseskrisen i protestrekkene Vitaly Serkuanov. Serukanov forklarte sin avgang fra Navalnyjs team som "behovet for selvrespekt."

I følge Vitaly Serkuanov er ikke Navalnyjs hovedkvarter i stand til å tilfredsstille kravene fra fondsgivere og publisere statistikk over signaturer samlet inn i regionene. Årsaken til aktivisten er åpenbar: bloggeren mangler 250 tusen stemmer for å bli nominert, men å få det nødvendige antallet støttespillere innen fristen vil være en umulig oppgave. Fristen for å sende inn dokumenter til CEC for registrering går ut 31. januar 2018 kl. 18:00. Det er derfor, som Serukanov bemerker, Navalnyjs team endrer taktikk i henhold til prinsippet Niccolo Machiavelli"Målet rettferdiggjør midlene". Uautoriserte samlinger 24. desember er planlagt som en tøff fase i overgangen fra kampanjens fiasko til stadiet av en fremtidig boikott av valget.

"Volkov (Navalnys stabssjef) kom ikke med noe nytt bortsett fra å unngå å svare på spørsmål om årsakene til feilen i kampanjen, først og fremst taktiske, gjennom et hav av interneringer, arrestasjoner og negativ publisitet. Vekk massenes sympati, slå tilbake med administrative arrestasjoner, mens vanlige deltakere vil få straffedommer», skriver Serukanov.

Advokat Ilya Craft, som gjennomførte en uavhengig undersøkelse av aktivitetene til FBK, i en kommentar Nyhetsbyrået "Politics Today" bemerket at antallet skuffede Navalnyj-supportere naturligvis øker.

Etatens samtalepartner plasserer tidligere frivillige i denne kategorien Alexander Turovsky Og Denis Lebedev. Den første ble skadet under et søk i bloggerens hovedkvarter, men Navalnyj brydde seg ikke om å nevne navnet hans. En lignende historie skjedde med Lebedev tre år tidligere. Benet hans ble brukket på en av turene hans på FBK-virksomhet, men fondet gjorde det klart for aktivisten at de ikke kom til å håndtere problemene hans.

Remeslo er sikker på at Navalnyjs hovedkvarter forstår godt at de ikke vil kunne redegjøre for donasjonene som er brukt og samle inn det nødvendige antallet underskrifter.

"Det er egentlig ingen støtte. Denne situasjonen viser at de ikke kan organisere grunnleggende arbeid, fordi disse menneskene aldri har jobbet noe sted eller tjent penger gjennom ærlig arbeid. Verken Volkov eller Navalnyj. Det er derfor de er tiltrukket av hverandre. Hvis de hadde den nødvendige støtten, ville folk strømme inn uten stans. Vi samlet inn disse signaturene selv om Volkov og Navalnyj var helt talentløse, men siden de også er talentløse og det ikke er noe støttenivå, så får vi det vi får,» kommenterte Remeslo.