Tervezett leállások, karbantartások időzítése

Flame

Valóban fantasztikus időzítés, végülis mikor máskor tegye lehetetlenné a legnagyobb ügyfelei működését a Simple, mint az egyik legforgalmasabb napon.

https://www.mavcsoport.hu/mavinform/simplepay-karbantartas-miatt-szomba…

  • 532 megtekintés

( andrej_ v | 2023. 08. 19., szo – 13:09 )

Dehát akkor mindenki szabadságon van és nincs forgalom... Egyébként meg kell venni 2-3 nappal előre a jegyet, és még egy kis kedvezményt is kapsz, bár nem annyit mint korábban.

Egyébként meg kell venni 2-3 nappal előre a jegyet, és még egy kis kedvezményt is kapsz

Lehet, nem ugyanarrol beszelnuk, de ha az 5%-os kedvezmenyre gondolsz, azt nekem jovairja az app akkor is, ha a peronon veszem meg, 1 perccel az indulas elott. 

Jobban jarnek, ha elore megvennem a jegyeket, ha tudom, hogy az adott napon bemegyek az irodaba?

Azt is vedd figyelembe, hogy az IC jegy az utazás napján megváltva jóval drágább, mint az utazás napja előtt.

Az IC-helyjegy elővételben – azaz a vonatindulás napját megelőző napig megváltva – egységesen 650 Ft, az utazás napján megváltva pedig 990 Ft lesz.

Mostanában csak IC volt, abban sem volt sok köszönet (az elhíresült Citadellát sikerült kifogni visszafelé, odafelé pedig simán eladták a nem IC szintű szlovén kocsiba a helyet IC-nek). Azt tudtam csak, hogy visszavették az online kedvezményt, és az IC jegy aznapi drágítása azért meglepett na. Azaz 5% szerintem csak 24+ órával előre kéne járjon, bár itthon eleve problémás a vonatok telítettségének előrejelzése, illetve ha láthatóan már 1 héttel előre televan, akkor sem tudnak/akarnak további kocsival erősíteni. A hanyatló német vasútnál az ICE-ken telítettség alapján áraznak, na mintha sűrűn járnék azzal :), és mellette látod, hogy mekkora a telítetség. Úgy vannak durván teli vonatok, hogy 8 kocsi alatt nemnagyon van IC, a forgalmas viszonylatokon 12-16 kocsi egy szerelvény, és sűrűn járnak.

Ha kellően sokat jársz be per hónap, illetve vonatozol más miatt, akkor vármegyebérlet. Az más kérdés, hogy pont ez pakolt oda a MÁV-nak az összes bajára még pluszban.

( arpi_esp v | 2023. 08. 19., szo – 14:16 )

vannak olyan rendszerek, amiket barmikor is karbantartod valakinek nem lesz jo. amig egy taxis ceg infrajat uzemeltettem is ez volt, se munkaidobe se hajnalba (repterre sietok) se ejjel (bulizok) se hetvegen se semmikor nem lehetett leallni... nemhogy orakra de percekre se. a penzugyi szolgaltatok is ilyenek, 24/7-be hasznalja valaki, nincs uresjarat...

Ismerem a helyzetet. Dolgoztam kritikus helyen, ahol 10-100-1000 ügyfélnél jóval több volt érintett egy leállással és nem lehetett "elsumákolni". Minden incidens után a "szőnyeg szélén" kezdtünk. Rosszabb esetben mehettünk a bíróságra vallomást tenni.

Azért nem mindegy, hogy egy ilyen leállás miért következik be. Hardver szinten már régóta kiforrott technológiák vannak. Szoftver szinten is vannak már megoldások, amikkel lehet javítani az SLA-t. Persze ha a cég / sdm / architect / fejlesztő balfasz, akkor nincs mit tenni.

Mindazonáltal hozzátartozik a képhez:
- Ki fizeti a révész?
- Mi van a szerződésekben leírva?
- Jó-e az, ha valami IT szolgáltatás ennyire épít kizárólagosan egy külső, másik IT szolgáltatásra? Miért nincs a Simple-nek versenytársa? Ha van, akkor miért nem "piacképes" a MÁV, BKK, xyz számára?

> Szoftver szinten is vannak már megoldások

vannak, de azert elofordulhatnak olyan esetek, foleg penzugyi vilagban, amikor jobb leallni es ugy csinalni pl. egy DB migraciot, mint menet kozben... nem veletlen all le az osszes bank is evente akar tobb napra is karbantartas/fejlesztes cimszoval.

de valahol olvastam hogy ez a mai eleg varatlan es hirtelen jott dolog volt, nem egy jo elore tervezett muvelet, szoval itt lehet valami most felfedezett hibat akarnak eltussolni/fixelni karbantartas urugyen. erre utalhat az is hogy visszautalgatasokrol irnak...

> Mi van a szerződésekben leírva?

nem tudom, de biztos van benne valamennyi ora evente karbantartasra, csak hogy az ugyfel ilyenkor ne kotberezhessen

> Miért nincs a Simple-nek versenytársa?

van, pl. a Barion, eleg sok szolgaltato azt hasznalja a Simple helyett mar. de a CIB-nek is van a simple-hez hasonloja, bar az kb minden honapban all valamiert, egyik ugyfelunk reven mindig kapom rola elore az ertesiteseket.

> "piacképes" a MÁV, BKK számára

lol. ezek miota mukodnek piaci alapokon?

gondolom az OTP cucca a "NER-kompatibilis" ezert azt KELL hasznalni es pont...

barion elég drága, kivéve ha nem adsz oda nekik minden adatot, gondolom ez ilyen cégeknél nem játszik.

Amúgy a MÁV körülnézhetne külföldön is, eu-ban van ezer másik provider amit egyszerű implementálni, árban sem drágább, vagy olcsóbb mint a simple. Már csak azért, hogy legyen backup ilyen esetekre.

Web, Domain, Tárhely

Csak a szokásos lemezt tudom feltenni, hogy egyrészt erre nem, vagy kevés pénzt szánnak, ha úgy tetszik alacsonyan húzzák meg az elvárásokat. Ezek persze elméletben óriásiak, egy percet sem állhat meg. Aztán amikor felvezeted, hogy jó akkor kétrendszer, alkalmazás szinten kellene kezelni azért dolgokat, mindenből legyen teljes áthidalás stbstb, akkor hirtelen máris megszakad a kommunikáció. Talán a VMWare fault tolerance története esetén nem kell alkalmazás szinten sokat erölködni, de azért oda mondjuk két DC közé kéne egy valami erős link, és a frissítés kérdéskörét nem fogja megoldani.

Technika mai, illetve jópár éves, állása szerint ott járunk, hogy legkevésbé a hardware lesz a problémád, mint a szerver vagy switchek, pláne ha valamilyen épkézláb clustert lehet összerakni. Nagyobb probléma lesz valamilyen DoS, hálózati kapcsolati hiba, alkalmazásbeli probléma, szoftver frissítéssel járó őrület, ténylegesen szünetmentes áramellátás és klímatizálás. Aztán külön ráfordítást jelent, hogy jó akkor nézzük meg, hogy az egyik site "eltűnése" esetén mi történik, valójában mennyi idő az átállás, és milyen lesz a visszaállás... Valamikor jártamban keltemben szerintem pont ilyennel szorgoskodtak az esti órákban az egyik hazai DC-ben. Hogy mennyire voltak bajok nyilván nem tudom megítélni, de talán nem volt teljesen sima a dolog. A lényeg minden esetre az, hogy legalább 3-4 ember dugta ott össze a buksit, és valszin sokórán át tette amit kell.

A legyen tesztrendszer jó gondolat, de megint ott járunk, hogy ráfordítás kérdése.

A Simple jellemzően a hazai piacon "versenyez", ami pici. Néhány hazai banknak van virtual pos megoldása, de azok nem olyan átfogóak, mint a simple. Ha a mindenféle EU-ban működő kártyaelfogadó szolgáltatókat megnézed, akik nem feltétlenül bankok, akkor jóval szélesebb a választék. A vevői oldalba is gondolj bele, hogy a randomhely alsóban lévő szolgáltató kártyás fizető képernyőjére nem biztos, hogy a hazai közönség szivesen megad bármilyen adatot.

Miért nincs a Simple-nek versenytársa? Ha van, akkor miért nem "piacképes" a MÁV, BKK, xyz számára?

Van versenytarsa, meg dolgoztam is az egyiknel. :)

Nagyon sok mas cegnek az egeszen kicsitol az egeszen nagyig piackepesek voltak a Simple-alternativak, de a MAV-hoz hasonlo meretu cegeknel senki nem vasarol listaaron, gondolom volt egy tender, amit a Simple OTP nyert meg. (Amikor en mar jegyeket vettem az Elviran, meg gondolatban sem letezett a Simple) Gondolom az van, hogy a MAV alapbol az OTP-nel bankol, es ekkora forgalommal ki tudtak olyan kedvezmenyeket alkudni, amit mashol nem.

Egy lehetseges megoldas persze az lenne, hogy az Lrtv.-be, vagy legalabbis a kozlekedesi szektor vegrahajtasi rendeletebe (161/2019., talan?) bele kell irni egy olyasmi kiegeszitest, hogy a "szolgaltato koteles ket fuggetlen fizetesi szolgaltatoval szerzodni az uzletmenet-folytonossag biztositasa erdekeben". 

A népet mindenképp az elővétel felé kéne tolni

Nagyon nem értek egyet. Nem kellene ilyen téren eljutni oda, ahol pl: a német vasút van. Az össze-vissza árazás teljesen felkavar egy nem időponthoz kötött utazót. Aki meg időpontra megy pl: munkahely miatt, annak teljesen mindegy az ár, csak érjen oda időben.

A MÁV már most is csinál hasonló faszságot. Zónázó vonatok Bp vonzáskörzetében. Járnak fél óránként napközben. Az utas megveszi a jegyet mondjuk reggel a Bp-XY viszonylatra 17:05-s indulással. Viszont hamarabb végez a dolgával Bp-n és eléri a 16:33-s vonatot is (2 perccel indulás előtt). Ha ő felszáll a 16:33-s vonatra, akkor megbüntetik.
Ilyenkor kétféle szabályos protokoll van:
- Várja meg a 17:05-s vonatot, amire a jegye szól. Ez nyilván fél óra bukó, normális ember ilyet nem csinál.
- Váltsa vissza a jegyét és váltson újat. Sok sikert hozzá már a vonatra felszállva és utazva... A jegyvizsgáló érkezése előtt.

Aki munkába megy vonattal az vesz ott is bérletet, vagy jó rá a környéki jegy, és valszin nem ICE-vel csapatja, bár előfordulhat. Tervezni kell, nem összevissza csapatni, ez ilyen. A kapacitások sehol sem végtelenek, csak az elvárások. Az más kérdés, hogy a MÁV-nál azért van hova növelni a kapacitást.

Amit írsz, az egy dolog, viszont az ilyen dolgokra egy vasút nem tud felkészülni. Azzal tudna segíteni, hogy a pályaudvaron valami bevásárlást, online melót, bármi ilyesmit elintéz és aztán hussan. Egyébként ha eleve menettérti (ezt imádom :) ) jegyet vesz, akkor lehet, hogy nincs benne a korlát. Visszaváltani online csak előző nap lehet indítani, viszont egy mezei személyvonatra "áttevésnek" kéne működnie az alkalmazásból. Akár későbbre, akár korábbra, persze nem korlátlanul.

Aki munkába megy vonattal az vesz ott is bérletet, vagy jó rá a környéki jegy

Vagy igen, vagy nem. Nalam pl. ~12 napi bejaras utan erne meg a legolcsobb berlet, vagy meg tobb, ha varmegyeberletet vennek.

szerk: Illetve az kimaradt, hogy a berlet konkret vonalra szol, nalunk meg valamiert felvaltva ket utvonalon kozlekedik a vonat, amiert termeszetesen a kevesbe jofej kaller azonnal sivalkodni kezd, hogy a berlet a masik vonalra szol. Ilyen gond nincs a jeggyel, mert arra veszek jegyet, ami eppen jon.

Igaz, hogy tavaly nyári a történet - akkor vettem utoljára MÁV jegyet és bérletet is:
- bérlet, volt BKK-s bérletem is volt 14200 Ft
- jegy, van BKK-s bérletem is, MÁV app-ban vásárolva menettérti kerül most 2*475 = 950 Ft - ez mostani, friss adat, szerintem tavaly is ugyanennyi lehetett

Azaz kb. 15. utazás után olcsóbb a bérlet. Tudom, megyebérlet esetén már a 11. alkalomtól olcsóbb a bérlet.

Annyit javítanék a korábban általam írtan, hogy most nézve a jegy.mav.hu oldalon nem írja, hogy vonathoz kötött lenne a jegy. Viszont a MÁV appban nem ír erről semmit. Most tesztből - hogy épp mi megy / nem megy - meg nem akarok jegyet venni.

A kapacitások sehol sem végtelenek, csak az elvárások. Az más kérdés, hogy a MÁV-nál azért van hova növelni a kapacitást.

A MÁV 40-30-20-10-0 éve is ugyanolyan pocsék szolgáltatást nyújt. Kevés ilyen tróger céget láttam, mint ők. De ez már egy másik téma...

Pont a bp-i elővárosi forgalomban nagyságrendi kapacitásfejlesztés volt, lásd az emeletes KISS-ek (40db), és a Flirt (106db), és az esztergombi, fehérvári, érd/dunújvárosi vonalak felújítását. Az megint egy újabb kérdés, hogy ez is relatív kevés, és vannak irányok, ahol hát elég erős tere van a fejlődésnek. Pont az elővárosi óriási kapacitás bővülést a nyugati déli alagutat (előkészítést) leállították, a déli körvasútnál megy a hiszti, a lajosmizsei vonalnál kitalták hogy "ha elkerüli a várost a vonat az jó lesz neki". Ugye még emlékszünk,hogy a HÉV-eket azért szervezték ki a MÁV-hoz, mert majd ott mekkora jóság lehetőségek lesznek úniós pénzre új járműállományra. Csak jelezném, hogy ha most ma azonnal rendelsz egy engedélyezett, gyártásban lévő típust, akkor 3-5 év között várható, hogy az első darab megérkezik belőle, majd fél éve, mire megkapja a hatósági vizsgát.

Ezzel az egésszel 2 probléma van:
- Sok a duma, sok az ígéret, sok a terv.
- Aki egyszer már megégette magát a MÁV-val, őt nagyon nehéz lesz visszacsábítani.

A MÁV teljes vezetésének az elmúlt ~35 évből és a politikusoknak nyilvános bocsánatkérést kellene élőben felolvasniuk 365 napon keresztül tévében, rádióban, majd szeppukut (harakirit) kellene elkövetniük. Ezután talán megbocsátana egy időre a szenvedő utasközönség.
A bizalmat sokkal könnyebb eljátszani, mint elnyerni.

Megjegyzem, hogy a Volánbusz füle mögött is van vaj bőven.

Ezeket én tudom ám nagyon jól. Pontosan olyanok vagyunk, akik nagyon sokáig kitartottak a tömegközlekedés, főleg távolsági fronton, mellett, aztán mindenféle mókázásaik feltették az autóra a pontot. Ez 6 éve volt. A szürnyű az, hogy ha itthon éppen vonatozásra kerül a sor, akkor rendszeresen futunk bele valami őrületbe, és nem a késést jelenti, hanem valami fantasztikumba. Például volt már, hogy az IC kocsira szóló helyjegyre közölte a kalaúz, hogy jahát az a kocsi elment az előző vonattal... WTFBA...G... ezek a reakciós IC kocsik ilyenek, gondolnak egyet, és elmennek az előző vonattal, majd a következő vonatban nincs IC kocsi, amire eladták a jegyeket. Ez nem vicc, konkrétan a feleségemmel történt meg pár éve, már "autós" korszakunkban. Ő nyilván nem vetet fel erről jegyzőkönyvet, és kéri vissza az IC pótjegy árát a leszállás után, hogy esetleg például mi a túró volt ez.

A Volánbusz csodálatos tevékenységéből két fénypont maradt meg, ismétlem, hogy 6-9 évvel ezelőtti dolgok, nem tegnapiak. Az egyik, hogy valami elképesztően haladó gondolat okán a Bp - Távoliváros vonalra bepakoltak egy mentesítőt buszt félútig, ahova egyébként van vonat is bőségesen. Na ezt a mentesítőbuszt úgy szedtünk össze az autópálya kivezetőn, mert csöppet lerohadt. A másik az volt amikor gyerekekkel jötttünk haza, még kicsik voltak, és jött a szép Mercedesz busz. Nohát szállunk fel, hogy ez már Európa, itt kérnémszépen minden van, térugrás volt. Nos ebben a frenetikus technológiai fejlettségű buszban lehalt a fűtés, illetve gyenge volt. Végülis a buszban hüvös volt, de nem volt vészes. Nade a fentebbi közbülső nagyvárosban leszállítottak minket, hogy ez így nem jó ám, jön a mentesítő busz. Nos abban nemhogy fűtés nem volt, de a -5 fokot szél süvített be a 256-os ikarus minden résén, és helyén befelé, mindezt brutál ködben 80-as tempóval az 1-es országúton. Teljesen agybeteg dolgok.

Most viszont már nagyon jó lesz nekünk, mert lett kérnémszépen a MÁV-nak (ami már hála a jó Istennek összevont a Volánnal) járműstratégiája. Pénz nincs, de kérnémszépen már szépen le van írva, hogy mi minden kéne. A jobb helyeken nem papírokat gyártanak, hanem ami olyan, azt lecserélik, és ha valami erősebb darabszámú, akkor azért átgondolják... ennyi.

A közlekedési szakértő szerint ideje lenne, hogy a közlekedési szolgáltatók "végre kellő eréllyel lepjenek fel a piacot szinte monopóliumként uraló OTP-vel szemben.

Mi sem egyszerűbb. Integrálni kell a Google Pay, Apple Pay, Barion, PayPal és több más fizetési szolgáltatót is és kész. Nem kéne a SimplePaytől mint SPOF-tól függni.

Az alkalmazáson belüli fizetésre nem tudom mennyire alkalmas, illetve mennyire szednek jutalékot. A német, cseh, osztrák vasút trióból szerintem mindegyik appjában a külön kártyás fizetés ajánlja, legalábbis, amikor vettem jegyet ajánlotta.

Valójában a Simplepaynek illene megoldania, hogy tényleg csak pár perces kimaradással upgrade-eljenek, és eleve legyenek erősen redundásak, ha már ennyire alapszolgáltatássá váltak.

Az alkalmazáson belüli fizetésre nem tudom mennyire alkalmas

Egyszer probald ki, nagyon kenyelmes. Sokkal inkabb, mint a MAV-fele fizetesi elmeny, amikor a usernek hatrafele ciganykerekezve kell tuzkarikakon atugralnia, mire megkapja a jegyet, mindenfele szuletesi datumokat, szamlazasi cimeket, stb. megadva.

Egy idealis vilagban ugy nezne ki a folyamat, hogy a user ranyom az Apple Pay gombra, es a vegen kijon a jegy. Google Pay-t nem hasznalok, de gondolom ugyanez. 

illetve mennyire szednek jutalékot

Szerintem ez leginkabb a card processortol fugg, mert az Apple Pay flow-ban lenyegeben annyi tortenik, hogy amikor azzal fizetsz, akkor az adja a tokent a kartyaelfogadonak, nem a MAV adatbazisa.

Valójában a Simplepaynek illene megoldania, hogy tényleg csak pár perces kimaradással upgrade-eljenek, és eleve legyenek erősen redundásak, ha már ennyire alapszolgáltatássá váltak.

Ezzel egyetertek, de fuggetlen az Apple Pay kerdestol, hiszen a Simple is implementalhatna az Apple Pay-t.

Személy szerint én egyik helyen se mentek kártya adatot, tokent, bármit, inkább megadom ahányszor kell. Minden esetre valszin az lenne az ideális, hogy applepay, googlepay, mondjuk a simple, és még egy valami független adná a fizetést. Akkor aztán nincs olyan, hogy nemmegy, és elnézést jujjmitörtént. Ha a Simplepayen megy át a googlepay vagy applepay, akkor a topikos esetben nem leszünk előbbre.

A doksit nezve alkalmazasban is implementalni kell

A gyakorlatban ez sokszor ugy nez ki, hogy feljon egy embedded browser ablak, amiben egy db Apple Pay gomb van. Gyakorlatilag ugyanugy mukodik, ahogy a hagyomanyos, kartyaszam-beiros gateway-re iranyit az app, csak itt nem kell kartyaszamot beirni – meg az appot sem kell modositani.

es ha mar itt vannak, berakhatnak, hogy a jegyet lementse a walletbe.

+1, ez nagyon hianyzik.

( joco01 v | 2023. 08. 19., szo – 15:23 )

Nem is az a durva, hogy leállás van, hanem hogy milyen következményei lehetnek: többször fizetsz (amit majd ők valahogy kivizsgálnak) és nincs jegyed (vegyél másikat).

Minden adatbázisokkal kapcsolatos tananyag első leckéje, hogy ha Alice ad Bobnak 100 forintot, akkor tranzakcióban kell csinálni, nehogy az legyen, hogy a pénz eltűnik vagy megduplázódik. Szóval gratulálok az idiótáknak, akik ezt a rendszert csinálták.

És minden adatbázisokkal kapcsolatos tananyag második leckéje, hogy nincs olyan, hogy a rendszer egyszerre elérhető, konzisztens és partícionálható. Főleg, hogy itt legalább 5 rendszer beszélget egymással:

  • a kereskedő
  • a bankkártyatársaság
  • a fizetési szolgáltató
  • a bank
  • a klíring szolgáltató

Az eventual consistency azt jelenti, hogy ha nem történik írás a rendzerbe, egyszer majd valamikor konzisztens állapotba kerül mindenki. Viszont egy ilyen szolgáltatásnál nem feltételezheted, hogy nem történik írás a rendszerbe X ideig (ha ezt meg ki akarod kényszeríteni, az pont a leállás esete).

Amúgy félreérted, hogy mit jelent az eventual consistency.

Nem a teljes rendszerre vonatkozik, hanem egy-egy adatobjektumra.

Wikipedia szerint: "if no new updates are made to a given data item"

Egy jegyet az ember egyszer vesz meg és egyszer fizet ki, tehát nem lenne egy agysebészet megoldani ezt.

Vagy szerinted lehetetlen a feladat?

Ez kicsit ilyen executive summary, mert azért itt elég sok adatbázis művelet, netán tranzakció történik, és közben mindenféle http adatcserékkel van az egész megspékelve. Gondold el, hogy akár az is bennevan, hogy sikeres volt a tranzkaciód, de aztán erről már nem értesül a jegyárus app, aztán ha sietsz, akkor ez elég problémás. Elvileg van ilyen API visszaellenőrzése a tranzakciónak, szóval elméletben van védelem, de ha hosszabb a kiesés, akkor ez elég necces lehet.

Nem erről van szó, hanem arról, hogy amikor létrejön bármelyik alkalmazás, akkor hol húzzák meg a költséghatárát annak, hogy milyen problémákat kell kizárni, vagy minimalizálni. Ha sikerült implementálni az elméletet, akkor lehetőség szerint minnél jobban tesztelni kell. Fontos, hogy lehetőség szerint, mert olyan szintű összetettség van lehet egy ilyen történetben, hogy gondos tesztelés után, illetve remélhetőleg közben, derülnek ki dolgok.

Node mit jelent a 100% correctness? Felmentek a felhőbe, bízva benne, vagy van saját privátfelhő infra minimum két távoli DC-ben úgy hogy kellően failover az IP elérhetőség? Egyáltalán, hogy ha mondjuk Kazahsztán nincs elérés, akkor az probléma? Mindíg fel lehet tenni, egy következő kérdést, hogy "na és az még megy akkor is ha"? Szóval ez sosem ilyen, hogy törekszünk, vagy ott van és tesztelve van, vagy hát elvben készültünk, rá, de végülis nem volt büdzsé. Nem mellesleg minnél több dolgot védenél ki, annál több hibalehetőséget építesz be. Kiváló példa egy redundáns tápegység belső PDU -ja, ami vált a két táp között, vagy vezérli a működést. Ebben végülis elég sokan megbíznak, de ha nem, akkor jön valami cluster jellegű történet, meg storage...

Ha a felhőben bízol, akkor valójában másvalaki számítógépeiben bízol, hogy végülis lesz majd valami. Egyébként a felhőszolgálatók sem garantálják egy VPS jellegűnél, tudom mostmár instance van for instance, hogy az XY-A site lemegy, akkor ZY-B site-on piffpuff felépül. Volt már naaaaagy szolgáltatónál tanusítvány para, de láttunk olyat aki szó szerint elfüstölt (emergency cloud migration...), bár lehet ők nem kimondott felhőszolgáltatók. Azt is láttuk már, hogy nagy ISP failover megoldás pont a failovertől került végtelenciklusba, hiszen megszünt egy link, de nem átállt, hanem pánikszerűen keresni kezdte valszin.

Ekkor jön az, hogy alkalmazás szinten kellene valami megoldást találni, loadbalance és társai, amire megint vannak felhő jellegű megoldások, mert azt csak úgy magunknak tényleg necces megoldani.

Speciel a Kazahsztáni elérés issue velünk előfordult egyszer az iroda VPN-nél, de hát ott pingvinezni tudtunk, aztán szerencsére az ISP-k egész gyorsan megoldották, mert az ISP-k BGP hírdetése körül volt valami.

Nehogy félreérts, valszin tök jól megcsináljátok, meg törekedtek, de látni kell, hogy valahol mindíg lesz egy limitáció.  A rendelkezésre növelésével együtt exponenciálisan nő a bonyolultság, amihez ember kell majd, hogy átlássa, és helyreállítsa. Lehet jobban megéri néha 5 percet megállni, mint a "világ összes pénzét" beleölni a kivédésébe. Abban biztos vagyok, hogy van az a szint, ahol a valódi 100%-os SLA a minimum, de akkor 360 fokban nyílik ki a buxa.

Tévúton jársz, a megoldásnak semmi köze a hálózatok kialakításához meg a felhőhöz, hanem ez egy szoftveres probléma. Kulcsszavak: eventual consistency, idempotency, message queue.

A jegyrendelő oldalra kell generálni egy random számot, ami globálisan unique (adatbázissal elérhető). Amikor az ember megnyomja a rendelés gombot, evvel az ID-val mentjük a jegyrendelést. Állapota fizetésre vár. Ha az ember többször megnyomja a gombot, nem fog többször létrejönni a rendelés, mivel az oldalon unique ID van.

(Itt kikacsintás treynek, ez egy lehetséges megoldása a problémának, hogy többször küldődik be egy comment. De amúgy ezt JS oldalon is meg lehet oldani 99%-os biztonsággal, ha klikk után letiltjuk a beküldés gombot.)

Aztán át kell küldeni a felhasználót a fizetés oldalra. Ha az nem jön be, nem baj: a rendelés megvan, fizetésre váró állapotban, tehát akár többször is meg lehet nyomni a gombot, hogy na most ezt ki akarjuk fizetni. (Még akár alternatív fizetési módot is fel lehet kínálni, pl. bemész a Keletibe.)

Tegyük fel, hogy sikerült kifizetni, de nem jött vissza erről az üzenet, tehát még mindig fizetésre vár az állapot. Ha a felhasználó megint fizetni próbál, a fizetési rendszernek tudnia kell, hogy ilyen ID-val már lett fizetve, megint nem kell, rögtön visszaadjuk, hogy sikeres a fizetés.

De valahogy garantálni kell, hogy a jegyrendelő rendszernek visszaszólunk előbb vagy utóbb. Ezt mi message queue-val szoktuk megoldani. A fizetési rendszerben el kell indítani egy üzenetet, ami a jegyrendelő rendszernek szól, hogy megvolt a fizetés. Ez majd addig próbálkozik, amíg egyszer csak sikerül. Ennek a fogadó oldala is legyen idempotens, tehát egy üzenetet csak egyszer fogadunk el, és a jegy státuszát megvettre állítjuk. De úgy is meg lehet oldani, ha a jegyrendelő rendszer pollozza a fizetési rendszert.

Lehet emellé reconciliation folyamatokat is tenni, de ha a queue rendszer megbízható, akkor nem kell. Egy jegyvásárlásnak elég egyszerű az állapotgépe, nem kell egyszerre két oldalról módosítani, tehát nem nehéz az eventual consistency elérése. Ha meg akarjuk engedni a jegy törlését, módosítását, akkor persze bonyolódik.

Egy ilyen rendszerben nem baj, ha egy-két komponens kiesik valamennyi időre, amíg a persistent storage nem sérül (és azt is lehet javítani több DC-vel). Előbb vagy utóbb végigmegy az állapotgép, és kizárt, hogy egy rendelés többször jön létre vagy többször kerül kifizetésre. És ráadásul a felhasználót is lehet értelmesen tájékoztatni arról, hogy épp mi a státusz.

( persicsb | 2023. 08. 19., szo – 16:53 )

Ez nem a MÁV sara, hanem a SimplePay-é, a BudapestGO-nál sem lehet fizetni. 

> hogy keptelenek

inkabb azt mondanam, hogy uzletileg nem eri meg nekik. a MAV-nal akkor is fox jegyet venni ha nem megy a simple, csak maskor vagy mashol, nekik tokmind1. a pici webshopoknak meg tobbe kerulne egy masik szolgaltato havi alapdija + az implementacio mint amit evek alatt okozna veszetseget a kieses.

Az alapdíj alatt érthető például az integráció fejlesztésének költsége, ennek folyamatos utánkövetése, a fizetési problémák miatt beérkező panaszok kezelése, követése, ehhez az ügyfélszolgálat felkészítése. Amit akkor is meg kell tenni a kereskedő oldaláról, ha 0 tranzakciója van.

Nem tudhatjuk, hogy milyen szerződése van egy ekkora partnernek a SimplePay-jel, és a SimplePay milyen SLA-t vállal. Nem feltétlenül éri meg támogatni (ügyfélszolgálattal stb). több fizetési szolgáltatót. Persze, jó lenne, ha ezek integrálva lennének, és felhasználói oldalról nézve ez teljesen indokoltnak is tűnik, a kérdés az, te mennyivel vagy hajlandó többet fizetni ezért a szolgáltatásért?

Ezt ugy lehet megoldani, hogy nem kozvetlenul a card processorral kell szerzodni, hanem egy payment gateway-jel, aki aztan ott terheli be a kartyat, ahol akarja tudja. :)

Ilyen ertelemben a Simple kakukktojas, persze, mert ok is payment gateway, de tudtommal az OTP mellett nincs fallback.

( theadam | 2023. 08. 19., szo – 21:33 )

A Teletálnál kiválaszthatom, hogy Barion-nal vagy CIB-bel akarok-e online fizetni. Az más kérdés, hogy náluk meg, ha valamelyik megfagy és nem küld vissza állapotot, bebukom az online fizetést és törölni + újra kell rendelni a termékeket. De az alapötlet ott jó, hogy két szolgáltató is ott van, lehet választani, ha OFF az egyik, elméletileg ott a másik.

 

Ezesetben is célszerű lenne egy backup:D bár gondolom ennek ára van.

TheAdam

( wladek1 | 2023. 08. 20., v – 09:00 )

Volt részem az élményben, meg szerencse, hogy vissza tudtam rohanni a kasszahoz a peronrol. 

Error: nmcli terminated by signal Félbeszakítás (2)