Dziesmu svētku biļešu sāga: Pircēju radīto slodzi uz sistēmu varēja paredzēt 10
Slinkums un neprofesionalitāte – divi galvenie iemesli aizgājušās sestdienas neveiksmīgajā XXVI Vispārējo dziesmu un XVI Deju svētku biļešu pārdošanai, kurus sarunā ar “LA” norādīja vairāki eksperti, uzsverot, ka izvēlēts nevis sliktākais, taču lētākais risinājums, kurš turklāt nepilnīgi izstrādāts, pircējiem radot stundām ilgas galvassāpes un ļaujot biļešu pārdošanas procesu pat apiet. Taču eksperti piesauc arī paša pakalpojuma pasūtītāja vainu.
Lielu rezonansi sabiedrībā radīja dienu pēc biļešu pārdošanas sākšanās publicētā IT speciālista Jāņa Koļļa ziņa vietnē “Facebook”, kur viņš samērā vienkārši un īsi aprakstījis, kādu mehānismu izmantojis tirgotājs, kā arī procesu, kādā viņam izdevies apiet izveidoto virtuālo rindu. Zīmīgi, ka viņa ziņu bija pamanījuši arī “Biļešu paradīzes” pārstāvji, otrdien notikušajā preses konferencē uzņēmuma līdzīpašniekam Ērikam Naļivaiko Jāni Kolli nosaucot par huligānu un apvainojot viņu negodprātīgā rīcībā. Kā vēlāk skaidroja J. Kollis, nevienu biļeti viņš beigās nemaz nav nopircis (aicinājis tirgotāju par to pārliecināties pēc viņa IP adreses) un vēlējies vien parādīt izstrādātās sistēmas “caurumus” un tās vieglo apiešanu, turklāt informāciju par to, kā rindu apiet, viņš publicējis dienu pēc tirgošanas sākuma, kad rindu vairs neesot bijis.
Apšauba uzbrukuma ietekmi
Plašākā sarunā ar “LA” J. Kollis atklāja, ka komersanta mehānisms bijis organizēts tā, lai jebkurš klients, kas gaidījis rindā, ik pēc 30 sekundēm “sazinātos” ar komersanta serveri, tādējādi dodot ziņu par to, ka rinda nav beigusies vai tā beidzot izstāvēta. “Saprotu, ka vienu brīdi rindā bija pat miljons cilvēku, kas gan neizklausās reāli, bet, pat ja rindā bija 100 000 cilvēku, viņu radīto slodzi izdalot uz 30 sekundēm, sanāk, ka 1 sekundē notika 3333 rindas pārbaudes. Pēc savas būtības e-veselības sistēmu tas “nokautu” vienā momentā, pēc savas jaudas tas pielīdzināms jau DDoS uzbrukumam, kur no daudz dažādām adresēm veic vienlaicīgus pieprasījumus. Tātad nemaz nevajadzēja nekādu uzbrukumu – jau dabiskā noslodze bija milzīga. Līdz ar to nonākam pie paša galvenā – vai šādas slodzes varēja paredzēt! Varēja un tam bija jābūt gatavam,” sacīja IT speciālists.
Saprotot savu kļūdu, “BP” speciālisti dienas vidū, kad sociālie tīkli jau bija “uzsprāguši” no pircēju neapmierinātības, sazināšanās laiku ar serveri nomainījuši uz 60 sekundēm, tādējādi par divām reizēm atslogojot serveri. J. Kollis to sauc par adekvātu “ātro risinājumu”. Viņš arī norādīja, ka rindu mehānisms pēc būtības nav slikts variants, jo uz vienreizēju notikumu uzņēmumam gādāt jaudīgu sistēmu esot nelietderīgi, taču esot arī dažādi risinājumi, kā nodrošināties, lai šādi starpgadījumi nenotiktu, piemēram, sistēmas izmēģināšana, izmantojot, piemēram, “Microsoft Azure” rīku, ārējo serveru īre u. c. risinājumi.
Tāpat publiski izskanējusi informācija, ka “BP” sistēmai noticis uzbrukums, un šo informāciju apstiprinājis arī Informācijas tehnoloģiju drošības incidentu novēršanas institūcijas “cert.lv” vadītāja vietnieks Varis Teivāns. “Notika saziņa un sadarbība ar “BP”, kuras rezultātā uzņēmums mums nodeva sistēmas žurnāla failus jeb auditācijas pierakstus. Tos analizējot, esam konstatējuši, ka bijusi ārēji ļaunprātīga ietekme, kas jau pārslogotu sistēmu padarījusi vēl nepieejamāku un pārslogotāku,” sacīja V. Teivāns. Arī viņš atzina, ka kopumā tirgotājs nav paredzējis visas situācijas, kuras varēja velties pār sistēmu. Tāpat no “cert.lv” noskaidroju, ka hronoloģiski ļaunprātīga ietekme sākusies jau ap pulksten 11, sistēmas kopējās slodzes kulminācija bija ap 13, bet sistēmas lielākā atteice sākusies pēc pulksten 17.
Sociālajos tīklos daudzi IT speciālisti izteikuši aizdomas par to, ka “BP” speciāli paziņojusi par uzbrukumu, lai tādā veidā samazinātu pieprasījumu nonākšanu līdz serverim un vainu jaudas trūkumā noveltu uz uzbrukumu. Taču “cert.lv” norāda, ka, analizējot žurnālfailus, tiešām konstatēts, ka notikusi ļaunprātīga ārēja ietekme uz sistēmas darbību, kas radījusi papildu slodzi jau tā pārslogotajai sistēmai.
Rīkotāji paļāvušies uz godaprātu
Pārsteidz, ka otrdien notikušajā preses konferencē Ē. Naļivaiko atklāti atzina, ka sistēma bijusi ievainojama. “Protams, ka bija iespēja apiet rindu un redzam, ka cilvēki to arī izmantoja. Jā, bijām gatavi, ejot pa tumšu ielu, satikties ar huligānu bariņu, bet izrādās, ka tam bariņam bija klāt arī tanks (uzbrukums. – Aut.), kam nebijām gatavi. Servera jaudas tika iegādātas. Ko nozīmē pietiekamas jaudas? Salīdzinot ar iepriekšējo sreizi, mēs prognozējām, ka noslodze varētu būt pusotru reizi lielāka. Nedomājām, ka tā būs divas trīs reizes lielāka. Jā, iespējamā slodze bija jāreizina ar 10, 20, 30 reizēm, izanalizēsim,” norādīja “BP” līdzīpašnieks.
Kas pārsteidz vēl vairāk – “BP” vienlaikus spēja apkalpot tikai 1000 pircējus, kas pēc aptaujāto domām ir daudz par maz. Svarīgi gan ņemt vērā, uz ko norāda arī J. Kollis – kāds bijis iepirkums un līgums starp organizatoriem un tirgotāju. Ja līgumā neesot atrunāti specifiski tehniskie risinājumi, nepieciešamās jaudas, tad komersantam grūti ko pārmest.
Preses konferencē Dziesmu un deju svētku izpilddirektore Eva Juhņēviča norādīja, ka “iepirkumā bija sagatavota tehniskā specifikācija, kur pilnībā pateikts, kādu galaproduktu mēs vēlamies saņemt. Jābūt pārbaudītai programmai ar zināmām kompetencēm, taču mums kā rīkotājam jāvērtē nevis tas, kā tās tiks nodrošinātas, bet vai tas tiks nodrošināts. Mēs paļāvāmies, ka, noslēdzot līgumu ar partneri, tiks nodrošinātas visas tehniskās specifikācijas vismaz minimālā apjomā un pretendents spēs pienācīgi reaģēt sarežģījumu gadījumā, turpinot nodrošināt pakalpojumu,” norādīja E. Juhņēviča, liekot domāt, ka nolikums tomēr bijis nepilnvērtīgs un nākotnē no organizatoru puses būtu nepieciešams tehniski sarežģītāks iepirkums.
Cits IT speciālists Didzis Uzuliņš sacīja, ka, rūpīgi plānojot sistēmas slodzes, ir iespējams vienlaikus apkalpot arī miljonus lietotāju. “Ņemsim par piemēru 2004. gadu un “draugiem.lv” palaišanu. Pirmajos mēnešos viņiem viss bremzēja, jo nebija plānojuši tik lielu popularitāti, bet vēlāk viņi bija spējīgi apkalpot vairākus miljonus vienlaicīgo lietotāju. Taču Dziesmu svētku biļešu gadījumā milzīgais pieprasījums bija prognozējams, tādēļ “BP” attieksme ir vērtējama kā nolaidīga. Ja “BP” platforma ir veidota kā monolīta sistēma, tad bez pārbūves veikt optimizāciju būtu pagrūti, bet ne neiespējami. Viens solis būtu nodalīt datubāzi uz atsevišķa servera un biznesa loģiku izvietot uz vairākiem serveriem, kas atrodas aiz slodzi balansējoša “proxy” servera. Turklāt to ir iespējams izdarīt arī uz īslaicīgu periodu un pēc apmeklējuma samazināšanās samazināt arī serveru skaitu. Savukārt, ja sistēmas arhitektūra ir pārdomāta, tad ir pieejamas daudz plašākas iespējas,” sacīja D. Uzuliņš.
Vājajai sistēmai nav attaisnojumu
Aptaujājot dažādas populāras vietnes, noskaidroju, ka, piemēram, VID EDS sistēma vienlaikus varētu apkalpot 4000 – 8000 klientu, “Inbox.lv” – ikdienā vairāk nekā 60 000 lietotāju, bet ekstrēmos gadījumos izturētu arī 120 000 lietotāju. Zināms, ka e-veselības sistēma spēj izturēt 4000 vienlaicīgo pieslēgumu.
Centrālās vēlēšanu komisijas vadītājs Arnis Cimdars nevēlējās atklāt precīzu CVK sistēmas jaudu uz vēlēšanām, bet tā esot ar vairākām nullēm lielāka par “BP” iespēto. Kopumā viņš “LA” atzīst, ka komersantam noteikti jābūt gatavam ekstrēmām situācijām, kuras šajā gadījumā bija viegli paredzamas, taču viņš arī uzskata par nepareizu visu biļešu pārdošanas principu. “Kas pirmais brauc, tas pirmais maļ – neuzskatu, ka šis organizatoru izvēlētais risinājums ir pareizākais. Ne visas biļetes jālaiž brīvā tirgū, ne visas jālozē, bet esošā kārtība ir neveiksmīga jau saknē, jo iedarbojas vēsturiskā iepriekšējo gadu atmiņa, tādējādi cilvēki ir sanervozējušies pirms laika, drūzmējoties pēc biļetēm,” sacīja A. Cimdars, kurš norādīja, ka vēlēšanu pīķa stundās CVK īrē papildu jaudas. “Mūsu mazajai iestādei būtu nesaprātīgi ikdienā turēt lielas jaudas agregātus.”
Savukārt IT uzņēmuma “Soaar” vadītājs Renārs Kadžulis, kura kompānija vēlēšanās nodarbojas ar automātisko balsu skaitīšanu, sacīja, ka minimālais standarts IT jomā ir prognozēt maksimālo noslodzi 10 reizes lielāku. “Ja prognozē miljonu, tad sistēmu minimāli taisa 10 miljoniem. Otrs – jāveic atbilstoši pilotprojekti, ģenerējot arvien vairāk pieprasījumu, tādā veidā konstatējot sistēmas lūzuma punktus. Sistēmas veidošanas laikā vairākkārt jāveic sistēmas noslodzes testi,” sacīja R. Kadžulis.
Ass savā atbildē “LA” bija SIA “Inbokss” (“Inbox.lv”) valdes priekšsēdētājs Andris Griķis. “Var, protams, diskutēt par dažādiem ārējiem ietekmējošajiem faktoriem, taču Dziesmu svētku gadījumā tas nav attaisnojums – bija zināms, ka būs gaidāms milzīgs pieprasījums pēc biļetēm, turklāt, veicot sagatavošanās darbus, varēja un vajadzēja mācīties no iepriekšējo gadu pieredzes. Lai nodrošinātu kvalitatīvu un konkurētspējīgu servisu, nepieciešams ne tikai prognozēt un modelēt iespējamās situācijas, bet arī investēt, lai tās preventīvi atrisinātu. Piemēram, “Inbox.lv” e-pastu apjoms pērn novembrī un decembrī pieauga desmitkārt, jo apsveikumu skaits un īpašo piedāvājumu skaits Ziemassvētku laikā bija krietni lielāks. Jebkuram tehnoloģiju uzņēmumam būtu jāparedz vismaz dubulta rezerve sistēmas noslodzei. Īpaši būtiski, ja tiek piedāvāts maksas serviss. Es nevaru iedomāties, ka šādā situācijā mēs varētu teikt: “Atvainojamies, šogad bija pārāk daudz pieprasījumu, tāpēc mēs nevaram šo situāciju atrisināt,”” sacīja A. Griķis.
Virtuālā rinda pirms tirgošanas sākuma – bez pasūtītāja piekrišanas
Notikušajā preses konferencē “BP” līdzīpašnieks arī atklāja, ka uzņēmums sācis rindu veidot jau no pulksten 10.30, taču tajā pašā laikā sacīja, ka, pienākot plkst. 11, šīs rindas izzudušas un viss sācies no jauna. Pirmkārt, par šādu virtuālo rindu veidošanu pirms biļešu tirgošanas sākuma nemaz nav zinājis pats Latvijas Nacionālais kultūras centrs.
Otrkārt, sociālajos tīklos pēc Ē. Naļivaiko paziņojuma parādījās vairāki ieraksti, kuros cilvēki apliecina, ka rindā stāvējuši ar vairākām ierīcēm, tostarp tādām, ar kurām rindā iestājušies pirms plkst.11. Un tieši ar šīm ierīcēm izdevies izstāvēt virtuālo rindu. LNKC pārstāve Inga Vasiļjeva man atbildēja, ka minētā informācija ir fiksēta un šobrīd centrs no “BP” gaida skaidrojumus.
Fragments no Jāņa Koļļa ieraksta “Facebook”:
https://www.facebook.com/notes/j%C4%81nis-kollis/ok-to-shop/10210347094866970/
Visu tirdzniecību varētu sadalīt divās daļās – tirdzniecība kasēs un tirdzniecība internetā. Jāsaprot, ka tirdzniecība kasēs tāpat notiek caur internetu ar speciālu tirgotājam pielāgotu programmu, tāpēc, ja biļetes beidzās, tad tās beidzās visās kasēs reizē. Galvenā programmas priekšrocība ir, ka tirgotājam nav jāgaida rindā. Taču, neskatoties uz to, daudzās tirdzniecības vietās rinda uz priekšu virzījās ļoti lēni. Taču, tīri profesionāli, mani visvairāk piesaistīja problēmas ar publisko tirdzniecību internetā. Lai novērstu sistēmas pilnīgu atkāršanos, tika ieviests rindas princips un ierobežots vienlaicīgi portālam pieslēgušos lietotāju skaits. Kad tas bija sasniedzis kādu konkrētu vērtību, visi atlikušie tika ievietoti rindā un gaidīja, kad kāds beigs savu darbu portālā. Lai nodrošinātu rindu, uz katra gaidītāja datora, ja atskaita citu funkciju nodrošināšanai nepieciešamos sīkfailus (cookies), tika izvietots arī sīkfails “queue_uid”, kurš saturēja unikālu kodu. Pārlūks reizi 30 sekundēs vērsās pie servera, lai informētu serveri par to, ka klients vēl turpina gaidīt (nav aizvēris pārlūku), un noskaidrotu, vai rinda jau nav pienākusi. Servera pusē pēc šī koda tika skatīts, cik kodu ir priekšā, kuri izveidoti agrāk nekā manējais. Tā vismaz tam vajadzētu strādāt, bet, tā kā servera pusi es neredzu, varu arī kļūdīties. Jau uzreiz ir skaidrs, ka pie šāda mehānisma rindā var iestāties no vairākām iekārtām un vairākiem pārlūkiem. Piemēram, uz mana portatīvā datora ir Google Chrome, Mozilla Firefox, Opera un Internet Explorer. Zinot, ka sīkfaili tiek glabāti katram pārlūkam atsevišķi, es no sava datora varu ieņemt četras vietas rindā. Ja man ir vairāk datoru, tad attiecīgi arī vairāk vietas.
Tālāk sākas pats interesantākais – brīdī, kad rinda tiek izstāvēta, pie klienta tiek novietots sīkfails “ok_to_shop”, kura saturs ir viens vienīgs vieninieks. IT jomas pārstāvji lieliski zina, ka daudzos gadījumos nulle tiek interpretēta kā “False”, bet jebkas, kas lielāks par nulli, un parasti tas ir vieninieks, tiek interpretēts kā “True”. Tātad tiek novietots sīkfails “ok_to_shop” = 1, un tieši šī sīkfaila esamība nosaka to, vai rinda jau izstāvēta, vai arī lietotājam jāturpina gaidīt.
Sīkfailu īpatnība ir tā, ka tie glabājas uz lietotāja datora, tāpēc tehniski nav šķēršļu tos izdzēst, modificēt, vai pievienot jaunus. Tāpēc nolēmu pārbaudīt, vai tiešām piekļuve tiek kontrolēta caur brīvi modificējamu sīkfailu.
Darbības, kuras veicu: 1) izdzēsu visus sīkfailus, kas attiecas uz “BP” mājas lapu; 2) iegāju www.bilesuparadize.lv, notika pārvirzīšana (redirekts) uz www2.bilesuparadize.lv, kur tad arī, pēc visa spriežot, tika kontrolēta rinda; 3) “patvaļīgi” pievienoju iztrūkstošo sīkfailu; 4) no jauna devos uz www.bilesuparadize.lv, un “Jūs neticēsiet, ko es tur ieraudzīju!” Ieraudzīju iespēju iegādāties biļetes. Iegādāties, nestāvot rindu. Visa šī izpēte man aizņēma aptuveni 1 stundu un 15 minūtes. Savukārt sīkfaila uzstādīšanu, ja zinu, kas jāuzstāda, es varu veikt mazāk kā vienā minūtē.
