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ūkums | Ko atklāja vēlēšanu nakts |
---|---|
Sasteigta nodošana | Sistē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 mezgls | Biļ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ēšanas | Iecirkņu dati “piedzina” backendu, jo netika izmantoti prioritāri job-queue vai message-brokeri (RabbitMQ/Kafka). |
Formāls atbalsts | Incidentu eskalācija risinājās WhatsApp čatā, nevis ar 24/7 SOC/monitoringu. |
Nereāls budžets | Piešķ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īcija | Izlietots (2025) | Adekvāti kritiskai infrastruktūrai |
---|---|---|
Analīze + dizains | ≈ 0,18 M | 0,30 M |
Izstrāde (OCR, API, UI) | ≈ 0,45 M | 0,90 M |
Serveri + glabātuve | ≈ 0,27 M | 0,60 M |
Drošības/slodzes testi | ≈ 0,18 M | 0,30 M |
Apmācība + dokumenti | ≈ 0,18 M | 0,25 M |
24/7 atbalsts | (ietilpa kopbudžetā) | 0,20 M |
Vadība + audits | ≈ 0,27 M | 0,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”
Komponents | Faktiski (iespējams) | Ieteicamā prakse |
---|---|---|
DB | Viena PostgreSQL/SQL Server instance, bez klasterēšanas | Klasterēts PostgreSQL vai Oracle RAC + Redis buferis |
Failu glabāšana | NFS diskos, nekompresēti JPG/PDF | Ceph/S3 ar gzip/zip, checksum + verzionēšana |
OCR | ABBYY/Tesseract uz viena 32 vCPU servera | Docker mikropakalpojumi × 10–20 mezgli (auto-scale) |
Rate limiting | IP-balstīts slieksnis | Token-balstīta kvota, adaptīvs uz slodzi |
Monitoring | Sistēmlogi + manuāls WhatsApp | Prometheus + Grafana + Alertmanager, SOC komanda |
CI/CD | Manuāla deploy, vēls integrācijas posms | GitLab CI, IaC (Terraform/Ansible), staging + prod vides |
Tests | Ierobežoti JMeter skripti | Gatling/JMeter simulējot 1000 iecirkņu, ≥ 2k requests/s |
4. Cik laika vajadzēja
- Minimāli uzticams grafiks: 8–12 mēneši
- 1–2 mēn. analīze
- 4 mēn. izstrāde
- 2 mēn. integrācija + slodzes/drošības testi
- 1 mēn. ģenerālmēģinājumi, apmācība
- Latvijā reālā izstrāde praktiski “saspiesta” <6 mēnešos, ar nodošanu dienu pirms vēlēšanām.
5. Galvenā atbildība
Loma | Par ko atbild | Piezīme |
---|---|---|
VDAA (Valsts digitālās attīstības aģentūra) | Iepirkums, projektu pārraudzība, ekspluatācijas nodošana | Kritiski novērtēja slodzes riskus un termiņus par zemu |
VARAM (politiskā uzraudzība) | Budžets, termiņu kontrole, starpinstitucionālā koordinācija | Akceptēja nodošanu pēdējā brīdī |
CVK (Centrālā vēlēšanu komisija) | Lietotāja prasības, sistēmas pieņemšana | Pieņēma sistēmu bez pilna ģenerālmēģinājuma validācijas |
Galvenais līgumizpildītājs (nosaukums publiski slēpts) | Izstrāde, testēšana, atbalsts | Pieļāva arhitektūras un slodzes dizaina nepilnības |
Apakšuzņēmēji (OCR, hosting) | Specializētie moduļi, datu centrs | Noslēgti “melno kastu” līgumi, trūkst caurspīdības |
6. Pieci konkrēti padomi nākamajām vēlēšanām
- Budžets ≥ 4 M EUR, ar 20 % rezervi neparedzētam infrastruktūras pieaugumam vēlēšanu nedēļā.
- 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ā.
- 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.
- Neatkarīgs drošības audits un “red-team” tests ar DDoS, SQL-injection, identificācijas zādzību scenārijiem.
- 24/7 incidentu pārvaldības centrs ar reālu “runbook”: restarti automatizēti, push-paziņojumi iecirkņiem, nevis WhatsApp improvizācija.