Pašvaldību vēlēšanu IT fiasko: kas nogāja greizi un ko darīt citādi

1. Kas notika un kāpēc izgāzās

Galvenais trūkumsKo atklāja vēlēšanu nakts
Sasteigta nodošanaSistēma ekspluatācijā tika iedota tikai 1 dienu pirms vēlēšanām – nebija laika pilnai slodzes un drošības pārbaudei.
Nepareizs “rate limiter”Drošības slānis bloķēja likumīgus iecirkņu pieprasījumus, radot ķēdes reakciju un “karoties” serveriem.
Centralizēts OCR mezglsBiļetenu attēli (≈ 100 KB × 600–800 tūkst.) gāja uz vienu galveno serveri; bez paralelizētas apstrādes tas sāka smakt pie pīķa slodzes.
Nav rindas/buferēšanasIecirkņu dati “piedzina” backendu, jo netika izmantoti prioritāri job-queue vai message-brokeri (RabbitMQ/Kafka).
Formāls atbalstsIncidentu eskalācija risinājās WhatsApp čatā, nevis ar 24/7 SOC/monitoringu.
Nereāls budžetsPiešķirtie 1,81 M EUR atļāva MVP, bet ne valsts mēroga, kļūmēm noturīgu sistēmu.

2. Nauda: cik bija un cik objektīvi vajadzēja

PozīcijaIzlietots (2025)Adekvāti kritiskai infrastruktūrai
Analīze + dizains≈ 0,18 M0,30 M
Izstrāde (OCR, API, UI)≈ 0,45 M0,90 M
Serveri + glabātuve≈ 0,27 M0,60 M
Drošības/slodzes testi≈ 0,18 M0,30 M
Apmācība + dokumenti≈ 0,18 M0,25 M
24/7 atbalsts(ietilpa kopbudžetā)0,20 M
Vadība + audits≈ 0,27 M0,40 M
Kopā1,81 M EUR≈ 3,5–4,0 M EUR

Tipiska peļņas marža pie valsts iepirkumiem: 15–30 %. Pie 4 M EUR budžeta uzņēmumam (vai konsorcijam) paliktu 0,6–1,0 M EUR pēc algu un infrastruktūras izmaksu segšanas.

3. Tehniskais skats “kā bija” vs. “kā vajadzēja”

KomponentsFaktiski (iespējams)Ieteicamā prakse
DBViena PostgreSQL/SQL Server instance, bez klasterēšanasKlasterēts PostgreSQL vai Oracle RAC + Redis buferis
Failu glabāšanaNFS diskos, nekompresēti JPG/PDFCeph/S3 ar gzip/zip, checksum + verzionēšana
OCRABBYY/Tesseract uz viena 32 vCPU serveraDocker mikropakalpojumi × 10–20 mezgli (auto-scale)
Rate limitingIP-balstīts slieksnisToken-balstīta kvota, adaptīvs uz slodzi
MonitoringSistēmlogi + manuāls WhatsAppPrometheus + Grafana + Alertmanager, SOC komanda
CI/CDManuāla deploy, vēls integrācijas posmsGitLab CI, IaC (Terraform/Ansible), staging + prod vides
TestsIerobežoti JMeter skriptiGatling/JMeter simulējot 1000 iecirkņu, ≥ 2k requests/s

4. Cik laika vajadzēja

5. Galvenā atbildība

LomaPar ko atbildPiezīme
VDAA (Valsts digitālās attīstības aģentūra)Iepirkums, projektu pārraudzība, ekspluatācijas nodošanaKritiski novērtēja slodzes riskus un termiņus par zemu
VARAM (politiskā uzraudzība)Budžets, termiņu kontrole, starpinstitucionālā koordinācijaAkceptēja nodošanu pēdējā brīdī
CVK (Centrālā vēlēšanu komisija)Lietotāja prasības, sistēmas pieņemšanaPieņēma sistēmu bez pilna ģenerālmēģinājuma validācijas
Galvenais līgumizpildītājs (nosaukums publiski slēpts)Izstrāde, testēšana, atbalstsPieļāva arhitektūras un slodzes dizaina nepilnības
Apakšuzņēmēji (OCR, hosting)Specializētie moduļi, datu centrsNoslēgti “melno kastu” līgumi, trūkst caurspīdības

6. Pieci konkrēti padomi nākamajām vēlēšanām

  1. Budžets ≥ 4 M EUR, ar 20 % rezervi neparedzētam infrastruktūras pieaugumam vēlēšanu nedēļā.
  2. Atvērt mikroservisu arhitektūru, balstītu uz Docker + Kubernetes, lai varētu horizontāli mērogot OCR un API mezglus dažu minūšu laikā.
  3. Pilna slodzes simulācija (≥ 2 k pieprasījumi/s) vismaz 60 dienas pirms vēlēšanām; atkārtot pēc katra koda “major” laidiena.
  4. Neatkarīgs drošības audits un “red-team” tests ar DDoS, SQL-injection, identificācijas zādzību scenārijiem.
  5. 24/7 incidentu pārvaldības centrs ar reālu “runbook”: restarti automatizēti, push-paziņojumi iecirkņiem, nevis WhatsApp improvizācija.