9 és fél évig voltam köztisztviselő és vettem részt közbeszerzésekben (központosítottban is) a kiírói oldalról. Most a másik oldalon üzemelek (versenyszféra), a webfejlesztői piac egyik (kvázi) ismert szereplője, (kvázi) webes videó szakértő vagyok. Úgy érzem, hogy érdekes lehet az én véleményem is e tárgyban.
Nézzük először a tervet, aminek a címében szerepel a "szakmai megalapozás" kifejezés, tehát nemcsak egy ötletelésről van szó. Alapvetően három videós feladatot határoznak meg:
A szokásos adatok (cím, lead, kulcszavak, stb.) mellett feltöltéskor az anyagokat átvezetik egy hangfelismerő rendszeren, így rendelkezésre áll a törzsszöveg, az is kereshető. Ez unikum a magyar weben és jó ötletnek tartom.
Helyes a megállapítás, miszerint az elterjedt alkalmazásokon felül ne kelljen újabb alkalmazásokat telepíteni, tehát a legelterjedtebb böngészőket és a Flasht kell támogatni.
Javasolják, hogy a médiaszerver az Adobe Flash Media Server legyen, elsősorban élő közvetítés céljára. Ennél olcsóbb megbízható megoldás nincs, az a megállapítás viszont, hogy ez jól skálázható és kiemelkedő terhelés mellett is megbízhatóan működik, sántít. Kérdezzétek meg a Ustream-es vagy Jázmin-os srácokat. Sajnos nincs olyan médiaszerver termék a piacon, ami a dobozból kivéve képes bármilyen terhelésre skálázódni, megbízhatóan. Ehhez szakemberek kellenek és mágia.
A javaslat kifejezetten megemlíti az FMS 2-es verzióját: óhatatlanul felmerül a gyanú, hogy valakikre méretezett tervről van szó? Ugyan az FMS 3 viszonylag új dolog, így meg tudom érteni a félelmet, de verziószámokat betonozni egy tervbe nem szerencsés, hiszen nem lehet tudni, hogy mikor kerül megvalósításra. Itt viszont úgy tűnik tudták.
A rendszert két részre osztják, egy publikus (mindenki látja) és egy zárt részre. A bonyolultabb ügyek (pl. élő közvetítés) csak a zárt részen állnak rendelkezésre. Ez jó, mert kisebb és jól tervezhető terhelésre kell ezeket az amúgy igen drága dolgokat megvalósítani.
A terv óriási hibája, minden oldalról, hogy nem tartalmaz becsléseket a várható terhelésre, látogatottságra vonatkozóan. Semmilyen webes terméket sem lehet létrehozni enélkül. Olyan rendszer nincs, ami bármilyen terhelésre skálázódik, éppen ez a következő évek nagy kihívása és a cloud computing lényege. A terhelés nemcsak a felhasznált szervertermékek és hardverek számát határozza meg, hanem a teljes kódot.
A publikus rész várható látogatottsága nehezebben tervezhető, de lehet sejteni, hogy nem fogja elérni egy közepes hazai magazin látogatottságát. Nyugodtan kijelenthető, hogy a napi 50e unique látogatást nem fogja meghaladni, a videós részé pedig ennél kevesebb lesz, hiszen ez a szám már összemérhető a legnépszerűbb hazai videómegosztó, az Indavideo látogatottságával.
A zárt rész látogatottsága ehhez képest drasztikusan kevesebb és jól tervezhető. Feltételezem, hogy eddig is voltak fogalmaik a kormány sajtótájékoztatóin jelenlévő újságírók jellemző számáról. A Maróy Ákos részére küldött MEH válaszból kiderül, hogy a webes rendszerrel már nemcsak a 30-40 budapesti politikai újságíró munkáját segítik, hanem több száz vidéki újságíróét is. Ebből arra lehet következtetni, hogy a zárt rendszerre tervezhető maximális látogatottság 1000 fő, és erre kell a (live) médiaszervert méretezni.
A levél később túloz ezzel a számmal kapcsolatban és megemlíti, hogy "Az újságírók számára hasznos szolgáltatásokat ... élő követítés ... akkor lehet zavartalanul biztosítani, ha a rendszer elérést egyelőre a több száz médiumra és az ott dolgozó több ezer újságíróra koncentráljuk".
Nyilván nincs hazánkban több ezer olyan újságíró, aki élőben követné a kormány sajtótájékoztatóit. Valóban több ezer újságírónk van több száz médiumnál, de hogy az Index sportrovata élőben inná a kormányszóvivő szavait, azt erősen kétlem. Az pedig még hihetetlenebb, hogy az összes Index-es újságíró egyszerre nézné a közvetítést Uj Péterrel az élen.
Innentől kezdve ebből a két doksiból próbálok okoskodni: rendszerköltségek és eszközök listája.
A korábbi sajtóból és fenti becsült terhelési adatok ismeretében már gondolom mindenki számára világos, hogy a megvásárolt eszközök (vasak, szoftverek, kapcsolódó szolgáltatások) számát és körét felültervezték. Tudok a kormányzati szabályról, hogy a biztonságos blabla üzemeltetéshez mindent legalább duplikálni kell, de még ezen felül is igaz a pazarlás.
Az pedig teljesen horror, hogy a tesztüzemhez ugyanakkora infrastruktúra kellene, mint az eredeti. Ugyanmár. A tesztüzemet a fejlesztő saját parkján kell végezni, hiszen amúgy is valamin, azaz ott fejlesztik ki a cuccot. Eleve alapvető, hogy a fejlesztő rendelkezzen a szükséges licencekkel a fejlesztéshez. Csak indokolt, igen ritka esetben kell a fejlesztő részére licencet vásárolni. Nézzük részletesen:
Az Adobe Premiere Pro licencekkel egyet tudok érteni, kiváló videóvágó szoftver, profi anyagokat lehet vele készíteni. Kettőt vettek, nem sok, elég.
Adobe Flash Media Server 2.0: oké, 2-est vettek, a hármashoz képest szinte ugyanannyiba kerül, ez a része nem gáz. 1000 néző kiszolgálásához kettő darabra szükség lehet, abszolút indokolható. De minek négy? Annak az esélye, hogy kettő egyszerre száll el igen csekély. Egy harmadik példány a meghibásodás esetére elegendő lett volna. Ez magával vonja azt is, hogy kevesebb vas kell háromhoz mint négyhez. A pazarlás mértéke itt összesen kb. nettó 7 millió Ft.
Beszédfelismerő szerver: hogy ebből minek kettő, azt nem értem. Hiába áll le, a weboldalak attól még ugyanúgy üzemelnek tovább, mindössze a videó teljes szövege lesz később olvasható/kereshető, ha a megszerelték az elromlott eszközt. Ez a néhány perc, esetleg néhány óra kiesés simán tolerálható. A pazarlás mértéke itt összesen kb. 3 millió Ft.
MySQL adatbázis-kezelő: a már ismertetett terheléshez (és annál jóval nagyobbhoz is) bőven elegendő az ingyenes változat. A gyári támogatásra semmi szükség, hanem egy 24 órás MySQL szakértői szolgálat rendelkezésre állása kell, ha valami baj van, módosítás kell vagy csak kérdezni szeretnének. Ezt úgy hívják, hogy DBA és mindenképpen hazai szakembergárda kell, akit akár a helyszínre is lehet rántani. A pazarlás mértéke itt kb. 17 millió Ft, a szakértői támogatás pedig "szakértői konzultáció + projektmenedzsment-támogatás" címen benne van a projektben. Azt pedig végképp nem értem, hogy mihez kell 14 (!!!) darab MySQL szerver. Egy darab (illetve duplikált) nagy MySQL szerverrel és izmos dedikált vassal el lehet a feladatot látni, nem várható nagyobb terhelés.
Terheléselosztó: szükség van rá, mert mindegyik funkciót legalább két szerver látja el (pl. az egyik az "éles", a másik a "tartalék"). Azonban egyik funkcióhoz sem kell 5 szervernél több, így a puccos, sokat tudó elosztókra semmi szükség, ingyenes eszközökkel (pl. pound, haproxy, nginx) megoldható az ügy, csak vas kell hozzá. Három nem kell, kettő elég (éles + tartalék). Pazarlás: kb. 4 millió Ft.
Menedzsment szerver (2 darab!). Mit menedzselnek ezekkel? Esetleg kell egy vas, ami figyeli, hogy a többi komponens megy-e, de ehhez a legkisebb vacak szerver elegendő és kettő meg pláne nem kell belőle, mert meghibásodás esetén akár egy munkaállomásról is ellátható a feladat. A pazarlás itt kb. 2.5 millió Ft.
Backup szerver (2 darab): egy darab elegendő lenne. Ha leáll, akkor is megjavítható pár óra alatt, illetve ez idő alatt mondjuk az S3-ra is mehet az adat, olcsón. Kb. 2.5 milliós pazarlás feltételezhető.
EVA storage: a HP EVA egy igen nagy teljesítményű tárhely megoldás, amire szükség van, de gyanítom, hogy hazánkban csak a leges-legnagyobb webes rendszereknek van hasonló, a kormányszóvivő viszont meg sem közelíti ezeket. Az EVA-ra szánt 11 millió Ft helyett sokkal jobb lenne egy sima Linux-os megoldás, olcsóbb vassal, egyedi fejlesztéssel, S3 (vagy hasonló) backup-pal kiegészítve. Ez megoldható lett volna a feléből, ide beírok 5.5 milliót pazarlásnak.
A megvásárolt eszközök és a hozzájuk közvetlenül kapcsolódó szolgáltatások körében a fentiek alapján kb. 41.5 milliós pazarlást látok, ami sok, de a 200 millióhoz képest nem. Nade a szolgáltatások: itt lehet a legjobban elszállni és belemenni a zavarosba, ez a lényeg, nem az, hogy hány szerver van!
Biztonsági rendszerek tervezése és kialakítás: semmi extrára nincs szükség, a webes rendszerek biztonsága pedig alapvetően a webes alkalmazás kódján múlik. A tűzfal és egyebek is fontosak, de semmi különleges dologra nincs szükség, így a 2.6 millió Ft-ot túlzónak találom, százas nagyságrendű munkaórára nincs szükség. Nem vagyok szakértő ebben a témában, de 50%-os, azaz 1.3 milliós pazarlást valószínűsítek.
Infrastruktúra és hálózat fizikai tervezése: összesen 8 millió Ft! Azt a pár szervert nem köti össze olyan grandiózus hálózat, és a szoftverkomponensek összeállítása, a system architect meló ellátása sem többszáz munkaóra. Itt óriási a pazarlás, 2 millió Ft-nál semmiképpen sem tartom többre a feladatot, legalább 6 millió Ft kifizetése indokolatlan. Még a legnagyobb hazai weboldalak hasonló feladatai sem kerültek ennyibe, ez pedig messze van azoktól.
Szervereszközök telepítése és konfigurálása: ez nem kis meló, 2 millió Ft annyira nem is drága érte, ezért hagyjuk.
Rendszerintegráció: 13 millió Ft. Mi az a rendszerintegráció? Ez egy olyan bullshit fogalom, aminek itt semmi, de semmi értelme. Egy új rendszert fejlesztenek ki, nem meglévő cuccokat integrálnak össze. Milyen meglévő kormányzati rendszert kapcsoltak ehhez? Ennyiért? A teljes 13 milliós összeget pazarlásnak minősítem.
Szerverek rendszertámogatása: kell támogatás a szerverekhez, 2 millióért ez nem is drága, persze kérdés, hogy mennyi ideig adják a támogatást. Hagyjuk.
A szolgáltatásoknál tehát összesen kb. 20 millióra nézek furcsán, illetve ne feledjük, hogy a megvásárolt eszközöknél is a közvetlenül kapcsolódó szolgáltatások miatt lett nagy az összeg.
Óriási, 83 milliós tételről van szó. Gyakorlatilag ez lenne a "fejlesztés". A benne lévő tételek egy valós webes fejlesztés folyamataival köszönőviszonyban sem vannak, fogalmam sincs, hogy például mi a webfejlesztésben a "paraméterezés" vagy a "rendszerbevezetéshez kapcsolódó folyamatkialakítás". Értem, hogy a központosított közbeszerzés miatt be kellett szuszakolni a valós folyamatokat ilyen idétlen nevű semmikbe, ezért ezt nem is kritizálnám tovább. Két részre osztható a 83 millió:
Kábé ismerem a piac árait és hasonló rendszereket nem szoktak 57 millióból készíteni, sőt, 20 millió fölött sem. Sőt-sőt, az átlag 10 millió alatt van. Szóval húzzunk ide be egy egészséges, 50%-os, azaz 28 milliós pazarlást.
A támogatás jó dolog, nagyon kell, de havi 2 millióért kicsit sokallom. Legyen ő is inkább a fele, 13 milliót pazaroltunk. Tehát a fejlesztéssel együtt 41 milliót.
Mindent együttvéve kb. (41 + 20 + 41) nettó 102 millió Ft-nak nem látom az értelmét a nettó 171 millióból, azaz szerintem nettó 69 millióból fejlesztéssel, hardvervásárlással, szoftver licencek beszerzésével, 1 év támogatással meg lehetett volna oldani a dolgot.
Sőt, picit még ez is sok... én ennyire sem adtam volna ajánlatot. Persze az is igaz, hogy néhány feltétellel és tervezési tétellel nem értek egyet és másképp oldottam volna meg.
A videó menüpont alatt látható egy kis részlet abból, hogy milyen videóarchívummal rendelkezik az oldal. A kritikám műszaki jellegű:
A videólejátszó arcpirító. Ez ugyanis a Flash fejlesztőkörnyezet videólejátszó "demója", pár perc alatt lehet vele összerakni 10 sornál kevesebb kódból, 0 (zéró!) grafikai munkával egy alap lejátszót. A komoly Flash-es videólejátszók ezekből a "demó" komponensekből egy gramm kódot sem tartalmaznak, de az Adobe sem azokhoz készítette ezt, hanem tanuláshoz és tűzoltó jellegű férceléshez. A fejlesztői költsége ennek maximum 20 perc.
A lejátszott videófájlok FLV formátumúak, a legalapabb Sorenson h263 videó kódolással, 320x200 felbontásban, 25 fps, átlag 400 kbps-en. 2008-ban ilyet már egyszerűen nem szabad, sőt már 2007 végén is látszott, hogy nem ez az út. Tessék legalább VP6-os kódolást használni (pár száz USD a szoftver hozzá), hogy jobb minőséget kapjunk vagy sokkal kisebb fájlméretet. H264-ről már nem is merek álmodni, netán egyszerre több médiaformátumról, hogy mobil eszközökön is élvezhessem a kormány nyilatkozatait.
Először meg kellett volna fizetni egy szakértő(csapat)ot, valamelyik ismert hazai webes műhelyből, hogy ugyan már tervezzék meg a dolgot és határozzák meg az alapvető infrastruktúrát (system architect meló + egy kis interface plan). Ez még kormányzati árakon sem érte volna el az értékhatárt, egy-két-három millióból megvan.
Aztán kommunikálni a civil szféra felé, hogy itt a terv, ezt és ezt szeretnénk csinálni, nézzétek milyen jól van összeállítva. Ez javította volna a kormányzat megítélését, legalábbis a szakmán belül.
Utána lehet megvalósítani.
Központosított közbeszerzésben lebonyolítani egy ilyen speciális feladatot egyébként nem kicsit homályos ügy. A központosított közbeszerzés lényege az, hogy az ismétlődő és az államigazgatás nagy részét érintő beszerzéseket egyszerűsítsék. Ne kelljen minden egyes intézménynek ugyanazokat a köröket lefutnia, mert a "rendes" közbeszerzés időigényes és sok papírmunkával jár. Például számítógépre mindegyiknek szüksége van, a beszerzés menete ugyanaz, csak a kért paraméterek térnek el.
Az is elv volt, hogy a központosított jellegből adódó nagyobb volumen miatt olcsóbb legyen a beszerzés, de sajnos ez nem teljesül, a piacinál drágább ("kormányzati") árak az informatikai közbeszerzéseknél itt is jelen vannak. Könnyen belátható, hogy a kormányszóvivő.hu beszerzése egyedi ügy, nem központosított eljárásra való.
A hozzászólásokban arra is várok tippeket, hogy a Synergon mely ismert magyar webes szolgáltatásokat, netán videós szolgáltatásokat fejlesztette.
iMect means internet, media and other cool things. iMect is a small company near lake Velence, Hungary. We’ve a big footer on every page where you can discover what we do and what happens with us.
Az iMect jelentése: internet, média és egyéb király dolgok. Egy kis cég vagyunk közel a Velencei-tóhoz. Minden oldalon van egy nagy lábléc, ahol felfedezheted, hogy mivel foglalkozunk.