Google AI tűzfal = Országos szerver-elérhetetlenség (Rackforest)

Hálózatok általános

Sziasztok!

Ma (2024-01-18) délelőtt folyamán az összes éttermi rendszer net-hibát kezdett jelezni az egész országban.

Kezdetben "XML feldolgozási hiba", később "forbidden 403" ... azután "timeout". Pl.: DEMO << nálam ez nem jön be, mobilnetről pedig "Az oldal httpS... SSL megbízhatatlan" hibát ír".

Már napokkal ezelőtt is jelezték ügyfelek az éttermek felé, hogy egyes mobilszolgáltatókon keresztül (Yt) nem érhető el egyik másik étterem weboldala. (Ergo a szerver: webetterem.hu + foodora.hu rendelések "átjátszása")

Ma az alábbi választ kaptuk a Rackforest-től:

“Kollégáimtól azt az információt kaptam, hogy a tűzfal a Google kockázatelemző algoritmusát és AI technológiát alkalmazva hoz döntést róla, hogy egy-egy IP címről érkező forgalmat gyanúsnak talál-e vagy sem, és ez alapján dob fel captchát. “

Eddig a több tucatnyi étterem "déli csúcs" időszaki forgalomkiesése milliós nagyságrendű és továbbra sem tudjuk, mi fog így történni.
Egyikük sem éri el a saját weboldalát se a háttér-admin felületet, sem pedig az XML letöltéseket.
(Amit egy Delphi program végez, "Indy" User-Agent-tel.)

Úgy értesültünk, nem mi vagyunk az egyetlen "szerencsések" az ügyben.

  • Van valaki másnak is hasonló tapasztalata?
  • 4975 megtekintés

( zitev v | 2024. 01. 18., cs – 13:16 )

Át kell cuccolni másik szerverparkba.

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Akkor, ha ez rendszeres. Egy eseti hiba miatt szerintem nem kell fejvesztve menekülni. Sajnálatos, mindenkinek kellemetlen. De ha az elmúlt két évben nem volt ilyen, akkor az egyszeri esetet el lehet nézni. Ha egy-két éven belül ismétlődik, akkor nyilván drop.

"A megoldásra kell koncentrálni nem a problémára."

( n.balazs v | 2024. 01. 18., cs – 13:46 )

Egy hálózati architektúra ábrát ha mellékelnél, akkor megköszönném. Nehezen értem, hogy mi köze ehhez a Google AI-nak, tűzfalnak, Rackforestnek.

Tűzfal gyártóról, típusról lehet valamit tudni? Ki üzemelteti? Szerintem az már nem sima tűzfal, inkább IDS/IPS.

hogy egy-egy IP címről érkező forgalmat gyanúsnak talál-e vagy sem, és ez alapján dob fel captchát.

Ez a mondatrész nagyon ködös. Kinek dob fel captchát? A tűzfal üzemeltetőinek?

Ezt a mondatot szolgáltató írta.

Amit tapasztaltam, hogy ha az XML-lekérdező url-t megpróbálom megnyitni egy FireFox-ban, akkor nálam is feldobott egy Capcha-t, azaz választanom kellett 3db hidat a képekről.

De utána ugyanúgy letiltva maradt az itthoni IP címem.

Az egyik gyanúm az, hogy mivel a Delphi program Indy nevű net-komponense nem "Firefox ... " user-agent-et használ, hanem mást, ezért találnak minket gyanúsnak. Volt már 1x ilyen az évek során, ezért például egyes szerverekkel való kommunikációhoz meg kellett hamisítanom a User-agent sort.

Tűzfal gyártóról, típusról lehet valamit tudni? Ki üzemelteti? Szerintem az már nem sima tűzfal, inkább IDS/IPS.

Nem hiszem, hogy erről bármi infót kiadna a Rackforest.

Friss Hír:

 azóta az éttermek 10%-a újra el tudja érni a szervert. Ezek közül 1-nek küldtük el a dinamikus IP címét a szolgáltatónak, a másik kettő "magától".

A RackForest-es cPanel tárhelyeken 2016 óta fut az Imunify360, leegyszerűsítve ez egy ModSec alapú WAF, automatikusan frissülő szabálykészlettel az akutális támadástípusok, CVE-k és OWASP szabályok alapján.
A weboldalon is fel van tüntetve az adott terméknél és blog post is létezik róla:
https://rackforest.com/szolgaltatasok/webtarhely/
https://rackforest.com/2019/06/17/mi-az-az-imunify360/

A funkció a cPanel felületen domainenként ki/be kapcsolható teljes mértékben vagy akár szabályonként állítható a működése.

Amennyiben egy kérés ráfut valamilyen szabályra, a látogatónál egy reCAPTCHA tölt be, ami az esetek nagy részében automatán továbbengedi a forgalmat, ehhez a részhez van köze a Google-nek. Ha a Google is robotnak gondolja a felhasználót, akkor a reCAPTCHA-t kézzel kell megoldani.
 

Attól, hogy cPanel attól még futhat VPS-en vagy akár bérszerveren is, mivel az első az egy szoftver a másik pedig az pedig az erőforrás formája.
Mi is használjuk az Immunify360-at és bármelyik kézzel finomhangolható tűzfalnál jobb, többet véd úgy, hogy közben kevesebb kárt okoz az ügyfeleknek.
Régen CSF-eztünk és vagy nem védett eléggé vagy az ügyfelek zárták ki magukat folyton.
Bár bevallom, szerintem nem voltunk eléggé elmélyülve a CSF-be, de az egy pilótavizsgás cucc, arra az életed kell rátenni, hogy valamire is jó legyen, csak azt senki nem fizeti meg és még akkor se fogja tudni azt amit az Immunify360 pár kattintás után önállóan.

 

www.szerverplex.hu - VPS, Webtárhely, Domain, Szerver Hosting ...

( arpi_esp v | 2024. 01. 18., cs – 13:54 )

nekem bejon a DEMO oldal, de ugy latom ez csak egy webtarhely, nem vps vagy dedikalt szerver:

35.62.139.79.in-addr.arpa    name = cpanel14.rackforest.com.

igy siman lehet rate limit vagy egyeb vedelem ("tuzfal") rajta, mivel ha a ti siteotokat ledosoljak az viszi magaval a szreveren levo tobbi ugyfelet is kulonben.

kerjetek dedikalt szervert, es problem solved. webtarhelyen mashol se fogjak orommel nezni a millios szamu requestet.

kerjetek dedikalt szervert, es problem solved.

Kértünk rá 1 éve árajánlatot. A havi 16000 helyett 86000 lett volna az ára.
(Azt nem tudjuk a párezres havidíjból kitermelni, többet pedig az éttermek 90% nem tud egy weboldalra rászánni.)

De a nagyobb baj az lett volna a költözéssel, hogy változott volna az IP címe minden étterem weboldalának.

2 éve költöztünk a Rackforest-hez, mert nagyon ráfáztunk a korábbi cégre.
A teljes költözés kb 2MFt munkaórát emésztett fel és volt, akinek 2 napra, sőt 1-2 eset, akinél 1 hétre leállt a szolgáltatás, mert nem sikerült a DNS átállítás. (Nem mindenkiét tudom én menedzselni, akkor derült ki, hogy "előző tulajé .. stb"  )

webtarhelyen mashol se fogjak orommel nezni a millios szamu requestet.

Szó sincs ekkor a volumenről!

kb 100 XML REST / óra / étterem + kb 20-200 látogató = átlag 200 / óra / étterem x 16 óra naponta.

Ha értelmes a rackforest rendszere, akkor per user alapon kikapcsolható ez a fals pozitívokat adó védelem.

Ha nem, akkor szívás van. Tényleg érdemes máshova menni. Esetleg felróni, hogy miért változtattak menet közben. Ugye itt változtak a technikai feltételek, amik nem buktak ki az átállás előtt végzett teszteken, mert akkor még nem voltak.

10 perce végre kikapcsolták nálunk ezt a modult.

5 étterem újra eléri a rendszert. A többiek még mindig offline.

Én magam továbbra sem érem el egyik áruházat sem, le vagyok tiltva.

Amit nem értek:

  • Miért tartott 4+ órát kikapcsolni nálunk?
  • Miért nem jelzik előre Pl. egy kör-emaillel, ha ilyen méretű változtatást terveznek bevezetni?
  • Miért nem szakaszosan vezetik be?

Amúgy még mindig a Rackforest volt az összes eddigi tapasztalatunk alapján az egyik leggyorsabban reagáló, és mindent megoldó csapat.
(Amikor az egész szerverparkjukat támadták kívülről, akkor is megoldották pár óra alatt. Más rendszerek napokra / hetekre lehasaltak.)

A helyzet az, hogy a tárhely(et kiszolgáló szerverek) az ő infrastruktúrájuk, nem a tiéd. Ők üzemeltetik, nekik kell megvédeniük. Teljesen alap, hogy van rajta DDOS védelem, IDS/IPS stb. Nyilván nem lehet csak a tárhelyeddel kapcsolatban meghozni ilyen nagyságrendű döntéseket, bármihez nyúlnak, az sok ezer user működését is befolyásolja.

Egy tárhely nem backend rendszer; interaktív userek kiszolgálására való. Mehetsz szolgáltatótól szolgáltatóig, a szerencsédtől és a szolgáltató tűréshatárától függően előbb-utóbb bele fogsz ütközni a korlátokba.

Erre kell egy saját infra, bármilyen minimalista is. Hidd el, nem kifogásokat kell keresni, hogy IP cím változás meg mittudomén, ésszel és jó tervezéssel meg lehet csinálni tisztességesen. Szerezz egy olyan embert pár napra, aki nem csak egy-egy területhez ért, hanem kicsit szélesebben átlátja a dolgokat, és máris leegyszerűsödik minden.

Teljesen egyet kell értsek veled. Mindenben.

Ugyanakkor sajnos nincs arra kapacitásunk, hogy komplett, redundáns szerver-üzemeltetési feladatokat egymagunk ellássunk, ezért is döntöttünk úgy, hogy tárhelyet bérlünk.
(Pedig így le kellett mondanunk olyan lehetőségekről, mint NodeJS, Mqtt, stb.)

Abban sem vagyok biztos, hogy egy "csokiért" egy egyetemista ezt meg tudná tenni, bármennyire is egyszerűnek tűnhet elsőre feldobni egy kész Kubernetes Docker-t.
 (Meglátásom szerint ilyen tudással rendelkező magyar mérnökök ritkák mint a fehér holló illetve közel megfizethetetlenek.)

Ergo erre vannak a webtárhely szolgáltatók, akik 0-24-ben ezt tanulják, ezzel foglalkoznak.
Mert az "egyedi megoldások" sokkal rizikósabbak és drágábbak, mint a szerializáltak.
 (Mert kinek van ideje szombat este 21 órakor egy DDOS támadást hárítani? )

Bár viccnek írtad valószínüleg, de ilyesmire kubernetes kb ágyúval verébre, hacsak nem kell több TB/sec adatot feldolgozni és 0-24 -ben több millió event/sec akkor fölösleges overhead.
Kubernetest jól összerakni nem egyszerű, utána pedig üzemeltetni is kell. Mi AWS-ben toljuk, mégis kell EKS-t frissíteni, és van mit átnézni frissítés előtt hogy vajon menni fog e.

de ilyesmire kubernetes kb ágyúval verébre

Biztos csak azért, mert ezt csinálom melóban, de a játszós szarjaim is az Oracle által adott olcsó managelt k8s-en futnak, ahelyett, hogy az ingyen VM-en futnának.

Egyszerűen olyan tooling van a k8shez (helm, probe-ok, kisfaszom), amit ansible + systemd alapon összehozni oltári szopás szerintem. A helmben gyönyörű, hogy stateful, és ha valamit kipucolok a lokális dolgaim közül, akkor lekaparja a clusterről is - az ansible-ben meg lehet szopakodni a state: absentekkel.

Ha bármi több kell, minthogy a static fájlt feltolom S3-ba (és onnan elérhetővé teszem egy domainen), vagy nagyonesetleg egy ilyen rackhost jellegű shared hosting kiszolgálja a PHP-t, biztos nem VPS-re mennék, ahol csomagokkal + dolgokkal kell szopakodni, hanem managelt k8s-re. Végtelenül egyszerűbb.

Biztos csak azért, mert ezt csinálom melóban..
- gyanús.. :D
Mindennek megvan a helye.
Én egy szóval nem említettem virtuális gépet, de egyébként teljesen megoldható. Valljuk be, nem tudunk sokat az alkalmazásról és bármit ajánlgatni nem szerencsés.
Általában event based szolgáltatásokat építek serverless alapon: SNS,SQS,S3, lambda, Aurora. Konténerezés ha sok pénz van vagy technikailag indokolt, és persze van virtuális gép és rendes vas is, minden felhasználástól és igénytől függ.
Múlt éven építettem olyat ahol 5 millió + üzenet/másodperc csordogált keresztül 24/7 és havonta növekedett x%-ot a forgalom.

OP szempontjából követelmény hogy ők nem managelnek infrastruktúrát mert nincs meg a knowhow és nem ez a prioritás náluk.
Szolgáltatástól függetlenül meg kell tudni tervezni és megvédeni. K8S, vagy serverless, EC2, mindennek van gyenge pontja, előnye, hátránya.

Valószínűleg a "Rackforest" sem látta ezt másként, ezért bízza a tűzfalvédelmet a G. MI-jére.

-- Úristen(!).., személyes és üzleti érdekek védelme.., mind rábízva egy USA székhelyű és érdekű mamutszolgáltatóra. Az európai szerverek, üzleti érdekek védelmére! - Nincs itt értelmes biztonsági cég a védelmi szoftverek, online védelmi rendszerek fejlesztésére? Tudtommal VPN-szolgáltató több is van. Nem lehetne nekik esetleg továbbfejlődni és felnőni egy ilyen feladathoz? (Vagy ha történetesen Európa "védi meg", akkor az még rosszabb lesz mint az USA???)

Hat nem tudom de minek ehhez sajat szerver, a felhoben sokkal olcsobb lenne mivel request alaponfizetnetek es kb lofaszt sem kellene fizetni nemhogy havi 86-ezret. Raadasul amikor nem haznaljak semmire sem vissza is lehet skalazni nullara.

Elore egy API, moge egy function/lambda, amoge meg egy db aztan jovan. Ennyi lekerdezes eseten kb parezer forintrol beszelunk. 

Az érdekelne, hogy pontosan melyik felhő szolgáltatónál és mennyiben lesz maga a "vas", és mennyiben lesz hozzá az üzemeltetés. Pontos számok csak a felhősnél érdekesek, az üzemeltetésnél egy tól-ig bőven jó lesz. :) Mivel van forgalom, meg adatbázis nyugodtan 32GB-os 4-8 cpumagos és kellemes storage-es instance-t nézz, illetve nem árt ha valahova mentés is készül.

kb 100 XML REST / óra / étterem + kb 20-200 látogató = átlag 200 / óra / étterem x 16 óra naponta.

vs

Mivel van forgalom, meg adatbázis nyugodtan 32GB-os 4-8 cpumagos és kellemes storage-es instance-t nézz, illetve nem árt ha valahova mentés is készül.

Ugyanarról beszéltek?

https://iotguru.cloud

Akkor nem VM, hanem valami SaaS, ugyanazok a kérdések, csak pepitában. Szóval mennyi lesz havonta valójában, ki fog hozzá érteni, és ha valami nem jó akkor instant ránézni, ki fogja a meglévő rendszert átalakítani. Most látjuk, hogy ez üzemkiesés mekkora issue, ha a SaaS kiesik, akkor mi lesz?

Hát, én most nem fogok nekiállni kalkulálni, de szerintem ez a forgalom kb. belefér a free tier-be, ha nem fér bele, akkor is havonta ~20-30 dollár.

Ha konkrét példát akarok mondani, akkor egy országos vezető pletykalap online mindene két K8s clusterrel (dev és prod) belefér havi ~300-350 dollárba, forgalomtól függően.

https://iotguru.cloud

Nem te voltál az eredeti felvető. :) Azt nem szoktam szeretni, amikor bedobja valaki, hogy húhát mekkora marhaság, mert töredék pénzből kijön. Mindezt úgy, hogy nincs tényleges ismeretünk a dolgok összetettségéről. A 350USD az 122e/hónap perpill. A topikindító egy 86e/hó díjat is sokall, ha jól értem.

Nem te voltál az eredeti felvető. :) Azt nem szoktam szeretni, amikor bedobja valaki, hogy húhát mekkora marhaság, mert töredék pénzből kijön.

Beidéztem az eredeti elkövető által írt terhelést, 200 req / óra / étterem, ami lófasz se, erre akartál kérdezni egy 32 GB memóriás 4-8 magos valamit felhőben, ami felhőben amúgy értelmezhetetlen, mert akkor rosszul használod.

A 350USD az 122e/hónap perpill. A topikindító egy 86e/hó díjat is sokall, ha jól értem.

A 86 ezer csak a hosting, a 350 USD meg egy komplex rendszer, toronyóra lánccal és auto scaling, meg minden is. Ha jól használod, akkor kurva olcsó a felhő. Ha azzal a kérdéssel nyitsz, hogy jó, de 32 GB memóra, abból már látszik, hogy rosszul fogod meg a témát.

https://iotguru.cloud

Nem fogtam meg. :) Itt korábban VPS-ekről volt szó, és valójában nem a konkrét technikai megvalósítás a lényeg. Szóval komplex rendszer, de rakja össze, ki látja át, ki menedzseli? Itt most egy sima osztott tárhelyes történetről beszélünk, aminek valamilyen SaaS-ra, vagy másik tipp szerint VPS-ekre és valamilyen VPN-es (kliensek felé) megoldásra kéne átváltani. Azért egyik megoldás sem olyan, hogy egy átlagos, vagy annál kicsit jobban felkészült cég simán megugorja, és máris van emberük, aki ezt átlátja. Az "anyagi elköteleződésről" pedig a további történet. Nem egy és nem két topik volt, hogy ebben itthon szintet kéne sokaknak lépnie, hogy az igényekhez igazítja az erőforrásokat.

Hogy ne legyen félreértés, azt simán elfogadom, hogy az SaaS megoldás teljesen jó lesz, és valójában költséghatékony, ahogy a VPN+VPS-es sztorit is meg lehet jól csinálni. Egész más szinten szokott előjönni a mondjuk úgy szűk keresztmetszet.

Az egész topikot kéne elolvasni. Megoldást be lehet dobálni A-tól Z-ig a topiknyitónak, csak kérdés a fogadókészség. Ahogy írtam, az SaaS is lehet tök jó, meg a VPS+VPN is, a csak VPS is lehet, mniden lehet jó. A rendszer és igényeket viszont ismerni kéne azért jobban, ennyi.

milyen VPN van az osztott tarhelyen?

Néhányan felvetették, hogy az osztott tárhelyről át kellene költöznünk egy saját szerverre, ahová telepíteni kellene VPN szervert,

aztán egyenként kellene minden egyes étterem minden egyes gépére VPN klienset telepíteni, hogy azon keresztül tudják kezelni a REST API-t a sima https helyett.

Ez még önmagában nem is annyira rossz ötlet, ha nem számolom azt az iszonyat sok végpont-oldali melót, amit bele kellene ebbe ölni, de az "új szerverre költözés" egyben IP cím változást is jelentene, és az bizony sok negatívummal jár, melyet már korábban kifejtettem.

az a baja, hogy az ettermek sajat domaines weboldalai is ezen vannak ha jol ertettem, es milio domain dns-eben kene atirni a cimet, ami azert baj mert a felehez se tudjak a hozzaferest. ezt a reszet aterzem, koltoztettem mar kb 15 websiteos szervert masik ip-re, honapokig tartott es tobb 100 levelvaltasba mig sikerult mind a 15 domain dns-et atiratni, mert senkinek fingja se volt rola hol kene mit kene :)   itt szemebsultem azzal is, hogy van olyan domain regisztrator is, aki egy idegen (nem az ugyfel domainjerol) email cimrol irt levelben kert ip valtoztatast szo nelkul teljesit...

na de ettől még a weboldalon kívüli szolgáltatást átviheted máshova.

miért érdekes az, hogy az étteremek saját domaines weboldalai hol vannak?

Ő hosztolja nekik? Akkor legyen már ő a felelőse a DNS bejegyzéseknek is. Ha nem így van, az baj, mert bármikor kiránthatják a szolgáltatása alól a DNS bejegyzést mások.

> Ő hosztolja nekik?

hat nekem az jott le az eddigi hszekbol hogy igen

gondolom az ettermi weboldalba van beepitve a rendeles funkcio is, ami ugyanonnan megy.

> Akkor legyen már ő a felelőse a DNS bejegyzéseknek is.

hat ez lenne a cel, de ez eleg ritkan teljesul.

vagy valami sufnicegnel reggeltek ezer eve, ahol nincs webes admin felulet, es az ugyfel kell kerjen minden modositast (bar mint tapasztaltam, van aki leszarja ki keri...)

vagy mar nincs meg a belepesi kod mert elhagytak, nem dolgozik ott a kollegano aki tudta stb, de az esteek nagy reszeben mar azt se tudjak, melyik cegnel regisztraltak a domaint, azt is ugy kell kinyomozni

es vannak ugyfelek akik bizalmatlanok, nem fogjak a dns admint odaadni az it uzemeltetonek vagy web hosting cegnek, mert akkor az kihuzhatja aloluk az egeszet. viszont ahhoz benak hogy beallitsak amit kerunk :)

Ezért írtam, hogy Amazon Route 53, ahol tudsz a háttérben ilyet, hogy a minden is egy "CNAME"-szerű hivatkozás és egy helyen kell átírnod.

Köszönöm, hogy megosztottad velünk!

2 éve a naaaagy költözéskor a RF-hez kérdeztem anno a Deninet-et (mostanra már Rackhost, mert felvásárolták) akinél a legtöbb étterem domain-je van, hogy megoldható-e valami ilyesmi, de azt mondták, hogy nem.

Legközelebb okosabb leszek és előbb itt kérdezek.
(Bár nem ez a szakmám, de hát manapság már érteni kell a fodrászattól az orvosláson át a kazánszerelésig mindenhez. :-D )

az ettermek sajat domaines weboldalai is ezen vannak ha jol ertettem, es milio domain dns-eben kene atirni a cimet, ami azert baj mert a felehez se tudjak a hozzaferest.

Pontosan ez volt a helyzet a 2 évvel ezelőtti költözésnél. És nem "csak" 15 domain-ről van szó.

Arról nem is beszélve, hogy hiába vettem/vetettem le a TTL-t előre alacsony értékre (3600) attól még volt, ahol napok alatt sem állt át.

Ergo több napos kiesés garantálva.

<OFF>

Ebben az országban a domain-ek és DNS-ek körüli ügyintézés egy bicskanyitogatóan felháborító káosz.

Kellene nyitni rá egy külön Topik-ot, de hiába, mert nincs semmi ráhatásunk a domaineket menedzselő hivatalra és cégekre, amíg nincs törvényileg leszabályozva. (Akik pedig ezt megtehetnék, egyáltalán nem értenek hozzá.)

Minden végpontra kell egy picike picityúk (mikrotik), központi oldalra egy nagyobb, vpn-eket előre, otthon össze lehet lőni, és csak ki kell vinni, és rádugni azt a gépet, aminek beszélgetnie kell a szerverrel. Igen, munkás dolog, de van rá gyakorlatilag 7*24-ben működő példa.

Szerintem az van, hogy mindig is fillérekért kaptak mindent, ami meg extraként felmerült, azt OP mindig megoldotta ingyen, hogy a filléreket továbbra is megkapja.

Ezer jó megoldás lenne az eddig itt a HUP-on, étterem témában elhangzott problémákra, de minden megoldás közös akadálya, hogy a havi néhány ezer Ft-ba nem fér bele, és az éttermek "ennél többet nem tudnak kigazdálkodni"...

Ezért csinálják azt nagyobb szolgáltatók, hogy a DNS bejegyzésekben egy (vagy több) proxy IP címe van és ha valakit másik gépre kell költöztetni, akkor csak a proxy szabályokat kell átírni.

Néhány millisec plusz latency, viszont az alkalmazás szerverek terhelhetősége a gyors proxy <-> app szerver requestek és a cache miatt sokkal nagyobb lesz.

Egy Rackforest vagy Hetzner VPS ennél sokkal-sokkal olcsóbb.

86e forintért ezt kapod a Rackforestnél: https://portal.rackforest.com/cart/&step=3

  • 12x XEON Gold CPU vcore (24 vcore-ig bővíthető)
  • 64 GB memória (128GB-ig bővíthető)
  • 240 GB SSD (1600 GB-ig bővíthető)
  • 10 Gbps port (2Gbps garantált)
  • 1 IPv4 IP Cím
  • Előtelepített Linux OS
  • 120 TB havi adatforgalom
  • A VPS a használatba vétel után is rugalmasan bővíthető újratelepítés nélkül!

Szerintem ti ennél kevesebb hardverigénnyel rendelkeztek.

Ez így van, de akkor pont erre való a cloudban mindenféle menedzselt megoldás amúgy, ha nincs házon belül erre kapacitás. Az olcsóbb lesz, mint egy VPS üzemeltetés.

Pontosan. Az a 2022-es árajánlat "ágyúval verébre" tűnt anno. Tartalmazott havi 2 óra mérnöki díjat, Cpanel-t, Imunify360-t, stb.

Azóta biztos feljebb ment az ár. És lehet, hogy a

4x XEON CPU vcore
8GB RAM memória
80GB SSD

is kevés lenne már több tucat étteremhez, hiába "elvileg" csak 200 lekérés per óra. (Nincsenek pontos mérési adataim.)

Mellesleg nem én fizetem a szervert, nem az én webszerverem és nem szeretek más zsebében turkálni.

Ha egy mostani HUNDRED csomag bőven ki tudja szolgálni az igényeket, akkor mégis miért fizetnénk szinte ugyanazért 5x annyit?

De nem erre gondolok. A menedzselt VPS még nem cloud. A cloudban menedzselt szolgáltatást veszel. konténerfuttatást (másodperc alapon számlázva), adatbázist, queue-t, Function-as-a-Service szolgáltatást requestenként számlázva stb.

Lehet, hogy sokkal olcsóbb megoldás lenne neked, mint a csúcsterhelésre méretezett VPS-t venned (amit a hónap 80-90%-ban ki sem használsz, elég lenne a kevesebb), mivel a terhelésed is eléggé dinamikus, nem éppen állandó. Reggel 8-kor és este 11-kor tipikusan kevesebb request lesz, mint délben vagy este 6-kor. Pontosan a te használati esetedre találták ki a cloudot.

Persze, ez architekturálisan egy hatalmas lépcső, amit az alkalmazásodnak meg kell tudnia ugrani, de biztos, hogy ezzel lehetne spórolni.

Ennek az a nagy előnye, hogy egy rendes DDOS-ra vagy egy félrekonfigurálásra a gatyája rámegy.

Ha meg Function-as-a-Service szolgáltatásra fizet elő, az pont ugyanolyan shared hosting DDOS védelemmel, mint amit most használ, csak fancy neve van. Egyetlen különbség a végtelen skálázhatóság. Emiatt nem ugyanazon a szerveren van az adatbázis és a PHP vagy akármilyen alkalmazásszerver. Ergó sokkal nagyobb a latency lesz, főleg, hogy ezek a szolgáltatók tipikusan nem üzemeltetnek infrát Magyarországon.

"az pont ugyanolyan shared hosting DDOS védelemmel, mint amit most használ, csak fancy neve van."

De nem pont ugyanolyan, mert pénzügyileg máshogy számlázódik, pont ez a lényege, ez a fajta rugalmasság/elasztikusság. A megvalósítás mögött valóban gyakorlatilag egy fancy CGI van, csak éppen nem havi fix költséged van.

"A havi 16000 helyett 86000 lett volna az ára."

Az oldalatok alapján a 16k a legkissebb csomagotok fele, a 86k pedig éppen csak kicsit több, mint a legnagyobb csomag. Ti nem a korábbi cégre fáztatok rá, hanem a hozzá nem értésre és a spórolásra, de sajnáljunk mert az egész infra egy nyamvadt cheap shared hostingon üzemel. Eszem megáll

// Happy debugging, suckers
#define true (rand() > 10)

Nem nagyon kellett régi vendég és sajnos magyar ip-ket nem tilthatok. :(

# 79.139.59.17 #98|Hungary|Rackforest ZRT.|Data Center/Web Hosting/Transit||0.59418981481481
# 84.1.34.158 #100|Hungary|Magyar Telekom|<span class="text-muted">Unknown|dsl5401229E.fixip.t-online.hu|1.0719212962963
# 89.251.47.179 #100|Hungary|Pick-Up Ltd.|Fixed Line ISP||0.46578703703704
# 91.219.237.56 #100|Hungary|ServerAstra Kft.|Data Center/Web Hosting/Transit|qeohmonlocbe-dedicated.serverastra.com|1.0947685185185
# 91.219.239.166 #100|Hungary|ServerAstra Kft.|Data Center/Web Hosting/Transit|qeohmonlocbe-dedicated.serverastra.com|1.1815393518519
 

Ha NKI lennék ezekre néznék rá. 

A telekomos az szerintem a miskolci FMC Nefrológiai Központ (legalábbis a threatbook dns listája alapján)

A serverastra az serverasta onnan amúgy is mindig dől (egy idő után meguntam a reportolást de amúgy azok legalább tiltottak utána :))  Na meg ezek Tor exitek úgyhogy nem akkora csoda.

A pickup.hu meg gőzöm nincs mi. (de az is régen a listán van)

( n.balazs v | 2024. 01. 18., cs – 15:32 )

Szerkesztve: 2024. 01. 18., cs – 15:35

Még mindig nem adtál architektúra ábrát, így csak találgatok.

Feltételezett architektúra: Van n darab étterem. A Rackforestnél fut valami osztott tárhelyen valami weblap. Az éttermek ehhez kapcsolódnak, ezzel kommunikálnak valamilyen API-n keresztül (SOAP / REST / XML / JSON whatever). A Rackforest központi tűzfala védi az osztott tárhelyet kiszolgáló gépeket. Ez a tűzfal valamiért kitiltja az éttermeket időnként. Az RF a "a Google kockázatelemző algoritmusát és AI technológiát"-ra hivatkozik. Jól látom?

Ha jól látom, akkor ez az architektúra az alapjainál van elcseszve. Javaslataim:
1. Osztott tárhely helyett dedikált szerver / VPS az RF-nél. Egy "Linux SSD VPS Eight" 5900 Ft+ÁFA/hó üzemeltetés nélkül. RF üzemeltetéssel 47300 Ft+ÁFA/hó.
2. VPN-t kihúzni az éttermek és a dedikált szerver közé. Valami egyszerű SSL VPN megoldás elég 2 irányú SSL-lel. Minden étterem külön tanúsítvánnyal.
3. A VPN-t megvalósító gép lehet a dedikált szerver vagy egy külön VPS is (ez utóbbi a biztonságosabb).

Összefoglalva:
Kellene neked 2 db "Linux SSD VPS Four" (2*3400 Ft+ÁFA/hó), mint VPS koncentrátor és 2 db "Linux SSD VPS Eight" (2*5900 Ft+ÁFA/hó), mint backend szerver. Így lenne redundancia VPS és backend oldalon is (mentések, HA). Ez 18600 Ft+ÁFA/hó. Igaz, hogy neked kellene üzemeltetni vagy megkérsz valakit sör/csokiért, hogy rakja össze és időnként (havonta) nézzen rá (update, upgrade, logok ellenőrzése stb.). Egyetemistáknak, ifjú padavanoknak kitűnő lehetőség a tanulásra.

Esetleg FaaS (function as a service) cloud. Ha ügyesen rakod össze, akkor tényleg havi pár ezer Ft, ahogy golgota fórumtárs is írta.

Szerintem.

Ha azt a sima weblapot nem tudok portolni VPS szerverre maximum 2 munkanap alatt, akkor villám csapjon belém. Komolyan mondom.
Nehogy már a weblap tulajdonosa ne tudja pontosan megmondani, hogy mi kell a weblap működéséhez - OS, app szerver, modulok, 3rd party komponensek stb.

( _Franko_ v | 2024. 01. 18., cs – 15:42 )

Aham, egyik ügyfelemnél volt 09 és 14 között hasonló probléma, gondolom ők is Rackforest-nél vannak, tipikusan REST hívások estek áldozatul, a köcsög REST kliens nem tudott mit kezdeni a CAPTCHA-val. Mire foglalkozni tudtam volna a dologgal, addigra megjavult, gondolom kikapcsolták a védelmet.

https://iotguru.cloud

( uid_16401 | 2024. 01. 18., cs – 16:55 )

Szerkesztve: 2024. 01. 18., cs – 16:57

Használjatok Hostingert! Számlát is adnak és nagyságrendekkel profibb a szolgáltatásuk. Annyi karbantartó levelet, meg “betámadtak de profik vagyunk!” tartalmú levelet kaptam én ezektől, meguntam a szarakodásukat. Most már “eseménymentesek” az éjszakáim.

Itt márpedig fejlesztés lesz, veszünk mindenkinek 10th gen i5-ös workstationt, a pfsense meg majd a core2duon eldöcög még négy évig. "Szerver" fronton ugyanez, de hát 5 éve 250 ezerbe fájt és már nem jó (akkor sem szerver volt hanem egy nyomorult sufni pc). A legszebb az volt amikor telepíthettem a közbe szerzett i7-eseket valami kollégiumba amihez egyébként semmi közöm nem volt (a szopás nem volt a közbe szerzés része valamiért ;))

Ja és a legszebb, hogy ezeket a közbe szerzett vackokat a pályázatok lezárásáig értelmes dolgokra használni nem lehet :)

Van szünetmentes amiért ölnék 2017 óta dobozban ahogy lerakták (biztos jót tesz neki ;))

Magyarország én így szeretlek.

ez mar nagyon OFF itt, de amugy jah, a kozbeszerzesek es az EU-s palyazatok az nagyon mas vilag. ott kezdodik hogy az IT szallito csak a nevet adja hozza, aztan majd ugy a 3.-4. alvallalkozo lesz aki dolgozik is, de mar jo ha a penz 10-edet kapja erte, a tobbit kozbe szerzik. meg aztan le kell koltoztetni az orszagos ceghalozat bp-i szerverfarmjat valami istenhata mogotti tanyara a feszerbe, mert a videkfejlesztesi palyazaton nyertek a penzt es ott kell viritani a gepeket (megtortent eset) stb.

Napok alatt milliós kiesések vs 16 000 forintnál nem lehet többet infrára költeni. Valami nem jó.

<OFF>

Ami nem jó, az a túladóztatott, túlhajtott vendéglátóipar, 27 büntető (pénzbehajtó=skalp) szervezettel a fejük felett, miközben lopós túlbérezett lusta pincérek és szakácsok próbálnak kiszolgálni olyan "Vevő-réteget" az országban, akik 50 forint napimenü áremelés esetén képesek 15 percen át alpári módon ordítani a diszpécserrel...
Vagy baseball ütővel várják a futárt, hogy elvegyék a pizzát...
Hogy az értelmes pizzafutárokat (beállva, részegen, jogsi nélkül) ne is említsem, akik benzint tankolnak a dízelkocsiba.

Az esetek felében havi 3000 forintot is képtelenség behajtani az éttermeken, nemhogy "dedikált prémium" szerverre valót háttérfelügyelettel.

Forgalom != nyereség.
 (Meglepődnél, ha levezetném, mennyi marad nekik egy 3000 forintos rántott hús eladásakor. Nem, nem annyi. Ha leadózzák, akkor nyugodtan oszd el 10-zel, de nem egy helyen veszteséggel árulják és azért vállal munkát külön a tulaj, hogy ki tudja fizetni az alkalmazottakat.)

agyarország, így szeletem.

Most kerültem őszinte hangulatba: akkor nincs rá szükségük valójában. Most akkor kiesik a millió forintos _forgalom_ és megáll a világ, vagy havi 3000Ft sincs. Vannak bajok. Erre próbáltam volt utalni korábban, csak a szakmai vonalba beleragadtak, hogy "az igényekhez kell rendelni az erőforrásokat", és hogy "szintet kell lépni".

3000Ft-ért normális bécsi szeletet már nemnagyon kapsz, az inkább 5000-6000, minden más menüs történet, és "kirántott" hús. Azért egyébként valahogy mégiscsak megéri, ha csinálják.

Ha pedig egy választott osztott tárhelyen vagytok, akkor csendben kell viselni annak a viszontagságait. Már amennyiben vannak, mert azért elég jó dolgokat lehet összehozni, bármennyire is lesajnált.

Na de akkor nincsenek milliós kiesések igazából, hiszen valójában nagyon kicsi a profit. Tehát mondjuk egy napos déli ebédideji állás az valójában párezer forint kiesést jelent profitban. Akkor ne mondd azt, hogy ez annyira fontos rendszer, hogy milliós kiesést jelent egy leállás, mert nem igaz.

Ha meg TÉNYLEG milliós kiesést jelent egy leállás, akkor az étteremnek hajlandónak kell lennie többet költenie, hogy te is megbízhatóbb dolgot tudj nekik szolgáltatni.

Illetve nézd meg azt, hogy felhőszolgáltatóknál, menedzselt szolgáltatásokból, lambda/FaaS, menedzselt DB, menedzselt event queue, mennyibe kerülne ezt megcsinálni, és lehet, hogy olcsóbban jönnél ki, mint a Rackforest.

Igen, az átállás komoly pénzbe kerülne, de valahol meg kell fizetni azt, hogy ne legyen sokmilliós kiesés.

Én nem bíznék olyan infrát másra, ahol tényleg ekkora nagy az anyagi tét.

Nem sok a napi nyereség ezek szerint, mert a napi kiadás magas. De a kiadás az állandó.

Hogy ne legyen veszteség és ne malmozzanak a pékek, pincérek, futárok, ahhoz termelni kell. Tehát van egy bér és terem, infra költség akkor is, amikor áll az egész kóceráj. A milliós soknak tűnik nekem is, de jelentős összeg egy sok éttermes hálózatnál a napi kiadás.

Na de ha veszteséget akarsz minimalizálni, akkor is költened kell. Nincs ebben semmi extra dolog.

Azaz ha elköltesz havi 5 ezer forintot azért, hogy ne bukjál el 50 ezret, akkor már megéri.

Melyik éri meg jobban? Ezer forintot költök csak, de néha bejön egy 50 ezres bukó a fix költségeim miatt, vagy havi 5 ezer forintot költök el, és 100x ritkábban jön elő az 50 ezres bukó?

Melyik éri meg jobban? Ezer forintot költök csak, de néha bejön egy 50 ezres bukó a fix költségeim miatt, vagy havi 5 ezer forintot költök el, és 100x ritkábban jön elő az 50 ezres bukó?

De pont azt írta valaki, hogy a dedikáltakra is ráküldték ugyanezt a tűzfal modult.

És már 1.5 éve nem volt "limit" gond a szerverrel, bírja a mostani vas!

Szóval 5x annyit fizessen egy webprogramozó azért, hogy ugyanúgy megsz****sák?

De nem érted a dolgot. Nem csak a Rackforestből áll a világ - az, hogy ők a dedikált szervert bérlő ügyfelet is megszívatták, az a Rackforest problémája egyedül.

Ők csináltak egy olyan dolgot, ami neked kárt okozott - ilyenkor kell elkezdeni megnézni, hogy hova tovább, mekkora a kockázata annak, hogy maradsz, és megéri-e maradni egy ilyen helyen.

Tárhelyszolgáltató van ezerféle még Európában, akitől vehetsz szolgáltatást.

Amúgy jelenleg a RF neked kárt okozott, miért bízol meg bennük továbbra is?

Az esetek felében havi 3000 forintot is képtelenség behajtani az éttermeken, nemhogy "dedikált prémium" szerverre valót háttérfelügyelettel.

Elso nemfizetes utan le kell vagni oket a szolgaltatasrol, aztan szevasz.

nem egy helyen veszteséggel árulják és azért vállal munkát külön a tulaj, hogy ki tudja fizetni az alkalmazottakat

Akkor tulajdonkeppen a kiesesek novelik a profitot, nem? :)

Elso nemfizetes utan le kell vagni oket a szolgaltatasrol, aztan szevasz.

<OFF>

Biztos, hogy ez a jó megoldás? Magyar jogrendszer, megtörtént eset:

  1. Ügyfél kért egy webáruházat.
  2. Nem fizette ki a fejlesztőt, de milliós forgalmat bonyolított rajta.
  3. Fejlesztő becsukta.
  4. Ügyfél beperelte.
  5. NYERT. A szerencsétlen programozó tönkrement, külföldre menekült.

Egyébként ha egy olyan étteremnél, aki a túlélésért küzd elvágod a bevételi forrását, mennyi esélyed lesz, hogy behajtod rajta a tartozását?

Fejlesztő üzemeltette saját termékeként a saját infrastruktúrán a webáruházat? Mert ha nem és belenyúlt az ügyfél rendszerébe, akkor valóban túllépte a hatáskörét. Ha saját maga üzemeltette és szolgáltatást nyújtott, akkor valami még történt ott, mert ha nem fizet az ügyfél, akkor bizony nem köteles senki szolgáltatni (hacsak nem alapvető közmű, de még akkor is csak speciális esetekben köteles).

https://iotguru.cloud

Biztos, hogy ez a jó megoldás?

Igen. Nyilvan a szerzodesben benne van, hogy addig van szolgaltatas, amig jon a penz.

Egyébként ha egy olyan étteremnél, aki a túlélésért küzd elvágod a bevételi forrását, mennyi esélyed lesz, hogy behajtod rajta a tartozását?

Lelovod az oldalt, masnap a szamladon lesz a penz, ez szinte biztos. Egyebkent biztosan az a jo hozzaallas, hogy teged lehet ugraltatni 24/7, de a fizetes csak opcionalis? Ha holnap te kuzdenel a tulelesert, akkor az etteremtulajok ki fognak segiteni?

> Biztos, hogy ez a jó megoldás? Magyar jogrendszer,

velem is megtortent, ugyfel felmondta a szerzodest, majd az utolso szamlat mar nem fizettek ki, tobb felszolitas ellenere se. a hatarido utan 1 honappal lelottem a weboldalukat. mindjart jott a level az ugyvedjuktol mekkora kart okoztam nekik ezzel stb.

mondjuk en meg visszairtam hogy milyen szerzodest szegtem meg, azt amit 2 honapja felmondtak? inkabb oruljenek hogy jofejsegbol 2 honapig ingyen ment meg a weboldaluk utana nalam...

Most komolyan, mi vagy te, a Vöröskereszt, vagy a Máltai Szeretetszolgálat?

Te egy szolgáltatást adsz, fizessék ki, ha nem fizetik, nincs szolgáltatás. Nem kell jófejnek lenned, az étterem majd talál magának másik szolgáltatót, ha ennyire függ az online rendeléstől.

 

Kihasználnak téged, te meg ide jössz dühöngeni.

Te egy szolgáltatást adsz, fizessék ki, ha nem fizetik, nincs szolgáltatás. Nem kell jófejnek lenned, az étterem majd talál magának másik szolgáltatót, ha ennyire függ az online rendeléstől. Kihasználnak téged, te meg ide jössz dühöngeni.

Az éttermek napról napra élnek. Számold ki, mekkora veszteség, ha 1 napig nyitva tart, fizeti az embereket + fűtésszámlát + hűtőket + romlandó nyersanyagokat, de közben kiesik a bevétel. Mennyi idő azt visszatermelni egy tipikus 5-10%-os "nyereségráta" mellett?

Több étteremnél is megfigyelhető, hogy mára már a 70%-a a rendeléseknek online érkezik.

<OFF>

Tudom, tudom, nehéz elhinni, hogy léteznek olyan emberek, mint én. (INFJ male = 0.5% of population)

(Aki átérzi más problémáját, próbál neki segíteni, ismeri és szereti minden egyes ügyfelét, összebarátkozik velük, akár felkéri egyiküket esküvői tanúnak... )

Mennyivel jobb lenne, ha engem is kizárólag a saját előremenetelem + anyagi hasznom hajtana!

Elvégre kit érdekel, ha az étterem tönkremegy, mégis kit zavar, hogy hány alkalmazottja kerülhet utcára családostul, mert nem tudja tovább fizetni a svájci hitelét?

Jaaaa, hogy ez a személy pont egy olyan megrendelt ételbe fog beleköpni elkeseredettségében, amitől egy szeretett hozzátartozódat elviszi a Covid egy új variánsa? Hát az biztosan csak a véletlen műve! Elvégre karma nem létezik.

</OFF>

Az éttermek napról napra élnek. Számold ki, mekkora veszteség, ha 1 napig nyitva tart, fizeti az embereket + fűtésszámlát + hűtőket + romlandó nyersanyagokat, de közben kiesik a bevétel. Mennyi idő azt visszatermelni egy tipikus 5-10%-os "nyereségráta" mellett?

Számolja ki ő, mi közöd hozzá, hogy mennyi a nyeresége vagy vesztesége. Szolgáltatsz, annak van egy díja, fizesse ki.

Mennyivel jobb lenne, ha engem is kizárólag a saját előremenetelem + anyagi hasznom hajtana!

Faszé' adunk neked ötleteket, megoldásokat és javaslatokat, ingyen, a mi kurva anyánkat, ugye? Kiszámláznánk ezt a kis ömlengést, akkor szerintem kb. félmillióval lógnál nekünk. Ezt ingyen megkaptad, de nem tetszik... eszem-faszom megáll. :D

https://iotguru.cloud

Több étteremnél is megfigyelhető, hogy mára már a 70%-a a rendeléseknek online érkezik.

Ha nekem a bevetelem 70%-ban egy forrasbol szarmazna, akkor nagyon-nagyon odafigyelnek ra, hogy az adott vendornak ne tartozzak.

Elvégre kit érdekel, ha az étterem tönkremegy

Miert, es az kit erdekel, ha te tonkremesz? Elmondom. Teged, a csaladodat meg a barataidat. Kb. ennyi, ezek fontosak. Az etteremtulajdonosok leszarnak teged. Tudod, mibol latszik ez? Hogy nem fizetnek ki, megis dolgoztatnak.

Ha tonkremesz (akar penzugyileg, akar mentalisan, akar az egeszsegedet tekintve), melyik etteremtulaj fog segiteni rajtad?

Offtopic:

Egyik régi főnökömtől tanultam még, hogy ismerősöket, barátokat, kollégákat a következő kategóriákba lehet sorolni (nem az összeset sorolom fel):
...
- üzletfelek
- ismerősök
- álbarátok
- felebarátok
- jóbarátok
...

Eldöntheted, hogy az ügyfeleidet melyik kategóriába sorolod (lehet többe is). Viszont ne lepődj meg, ha kiderül, hogy az álbarátok vannak a legtöbben.

Ha te nem foglalkozol önmagaddal, akkor más nem fog veled.

Az éttermek napról napra élnek.

És ez a te problémád? Nem. Ez az étteremek problémája, ha nem találnak megfelelő piaci rést, amit az ő költségeivel profitáblilisan be tudnak tölteni.

Több étteremnél is megfigyelhető, hogy mára már a 70%-a a rendeléseknek online érkezik.

Na, hát akkor kérhetsz tőlük több pénzt, hiszen függnek tőled. Mi itt a gond? Nem jószolgálati nagykövet vagy, hanem egy olyan szolgáltatást nyújtasz, ami számukra elemi fontosságú. A megfelelő szolgáltatásnyújtáshoz neked is megfelelő szolgáltatást kell igénybe venned, az meg pénzbe kerül.

(Aki átérzi más problémáját, próbál neki segíteni, ismeri és szereti minden egyes ügyfelét, összebarátkozik velük, akár felkéri egyiküket esküvői tanúnak... )

Aztán mégis basznak fizetni, nem? Ők nem a haverjaid, őket nem szeretni kell, belőlük élsz, ők meg belőled. Ez egy gazdasági kapcsolat, aminek megvan az ára.

Elvégre kit érdekel, ha az étterem tönkremegy, mégis kit zavar, hogy hány alkalmazottja kerülhet utcára családostul, mert nem tudja tovább fizetni a svájci hitelét?

Ez az étterem problémája. Ha neki fontos, hogy ne menjen tönkre, fizesse meg a megfelelő minőségű szolgáltatás árát. Nem olyan bonyolult ez. Nem a te feladatod, hogy életben tartsd az éttermeket. Ha nem tudnak gazdaságosan működni, bezárnak. Ha hülye döntéseket hoztak, akkor tanulniuk kell belőle. Abból nem fognak tanulni, hogy te mindig megmented a seggüket és rámegy az egészséged. Illetve de, megtanulják azt, hogy megszívathatnak, mert mindig lesz egy jófej, aki szolgálja őket.

 

Szerk: a hentes sem fogja nekik olcsóbban adni a húst, mert jaj szegény éttermek, mi van, ha bezárnak. A zöldségestől sem kapják meg olcsóbban a zöldségeket, mert szegény étteremesnek az alkalmazottja svájcifrank hitelt vett fel. A vízszolgáltató sem fogja olcsóbban adni a vizet nekik. Miért te lennél a jófej velük? Amikor nekik szar, miért te szívsz? Amikor nekik jó, adnak az osztalékból?

(Aki átérzi más problémáját, próbál neki segíteni, ismeri és szereti minden egyes ügyfelét, összebarátkozik velük, akár felkéri egyiküket esküvői tanúnak... )

 

Ehhez még egy gondolat: az, aki felkér téged tanúnak, az nem ugyanaz, mint aki az ügyfeled. Az ügyfeled az XYZ. Kft, meg AB egyéni vállalkozó stb. Egy jogi entitás, egy vállalkozás. Nem a magánszemély. Nagyon sokan nem tudják elkülöníteni a magánszemélyt attól a vállalkozástól, amit tulajdonol.

A magánszemély akkor sem szűnik meg barátodnak lenni, és felkérheted esküvői tanúnak, hiszen jó ember, jófej, barátja vagy, hogy éppen a vállalkozása megszűnt, ő meg elment dolgozni mondjuk a Pennybe árulfeltöltőnek. Vállalkozott, nem jött be, hát akkor próbálkozik mással. Elmegy buszsofőrnek, elmegy borbélynak, barista lesz valahol, alkalmazott lesz egy multinál stb. Attól még ugyanaz a jóbarátod lesz, csak már nincs éttereme.

A te ügyfeled nem a jóbarátod, hanem az ő vállalkozása, ami jogi személy. Ha ez a vállalkozás bebukik, az nem a világ vége, a barátod attól még ugyanaz marad.

 

Vagy szerinted a barátod és az ő cége egy és ugyanaz?

Nem kell már megint ez az éttermek védése, hogy a működésre nincs pénzük, annyira nem keresnek az étel eladáson... Egyszer (sokszor) már meghallgattuk itt ugyan ezt...

Akinek ennyire nem megy az éttermezés, ha hagyja abba, zárja be.

Te meg ne add fillérekért a munkád arra hivatkozva, hogy szegény ügyfélnek nincs rá több pénze...

Ha a konkurencia otodannyi raforditassal kihozza ~ugyanazt (vagy legalabbis egy "eleg jo" alternativat), akkor az skill issue. Az mar nem meretgazdasagossag, nem szerencse, nem technikai kerdes, hanem kokemeny skill issue.

Ami jo hir, mert azon baromi egyszeru javitani.

( Fisher v | 2024. 01. 18., cs – 17:19 )

Mondjuk ez az éjájos magyarázat nekem olyan, hogy "hámert a telefon átjavíccsa". Na, akkor az biztos szuper.

"A csapatmunka lényege, mindig van kit hibáztatni". Na ez a jó a külső szolgáltatásokkal is. Csak akkor a faxért alkalmazzák, főleg rendes teszt nélkül. Mondjuk teszteljék a saját cuccaikon, vágják ki a rackforest Mancikát az ügyviteli rendszerből. Előbb csak magukat szívassák az ilyennel.

Ma én is berágtam rájuk, de más miatt. Utoljára vittem hozzájuk ügyfelet.

Ha jól értem, akkor egyszercsak gondoltak egyet és elkezdtek kísérletezni a saját ügyfeleik kárára, elemeztetik a tűzfal forgalmát, etetik a Google AI adatbázisát.. nice...

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

( SzakiLaci | 2024. 01. 18., cs – 18:09 )

Annyit még hozzátennék, hogy kb 1 éve, amikor még csak kb 15-25 domain-re volt szükség, azaz kb 10-15 étterem futott az osztott szerveren:

 - folyamatosan eldobott kapcsolatokat az "entry point" = "Belépő folyamatok száma" limit miatt.

(SSD TEN >> SSD FIFTEEN csomag)

A déli csúcsidőben rengeteg bosszús telefont kaptunk, hogy "nem elérhető a weboldal", vagy "nem tudják visszaigazolni a rendelést", mert 5-10-20 másodpercet kell várni az XML REST válaszra 0.5 helyett.

(Ahol mondjuk 1 perc alatt 3-5 rendelést is felvesznek telefonon a diszpécserek, és elvileg a netes átvételnek ennek töredéke kellene legyen, ott ez igen nagy problémákat okozott!)

Amióta SSD HUNDRED van, azóta semmi hasonlót nem tapasztaltunk. Igaz, az elmúlt évben a PHP kódok is optimalizálva lettek a gyorsabb lefutás érdekében.
(aszinkron folyamatok, email küldés kiszervezése, adatbázis műveletek helyett memória-alapú adattárolás a gyakran lekérdezetteknél, stb.)

Lehet, hogy ez egy önálló szervernél egyáltalán nem probléma, de úgy láttuk, hogy egy bivalyerős szerveren fut a tárhelyünk, ahol gyakorlatilag az összes többi ügyfél együttes is csak kb 1% erőforrás igényű statikus oldal.
Szóval gyanítom, hogy egy pici VPS nem is biztos, hogy elég lenne. Még ha nem is raknánk rá kubernet-et vagy dockert, hanem natúrban futna redundancia nélkül, akkor is.

Emellett ma hallottam, hogy egy másik éttermi program-üzemeltetőnek most egy hete kellett új szerverre költöznie, mert a Cloudflare VPS-ük IP-je valamiért feketelistára került. Szóval valóban nincs rá garancia, hogy ha "dedikált vagy", akkor nem járhatsz ugyanúgy pórul.

Mekkora az esély, hogy valamelyik konkurencia ügyeskedik?

Közel nulla. Van jobb dolguk is ennél. (Főleg most, az NTAK miatt ... de az egy külön rém-topik, bele se menjünk!)

Valószínűbb, hogy inkább valamelyik külföldi kormány támadta a szervert, vagy beköltözött és onnan hekkelt más oldalakat.

A bivalyerős szerveren - normális üzemeltetés esetén - korlátozzák az erőforrásokat ügyfelenként. Ergo hiába 32 vcpu, 128 gb ram stb., sose fogod megkapni az összes erőforrást. A versenyhelyzetről nem is beszélve overcommit esetén.

Mérés és a rendszer részletes ismerete nélkül nem érdemes bármit mondani az erőforrás igényekről.

"Lehet, hogy ez egy önálló szervernél egyáltalán nem probléma, de úgy láttuk, hogy egy bivalyerős szerveren fut a tárhelyünk, ahol gyakorlatilag az összes többi ügyfél együttes is csak kb 1% erőforrás igényű statikus oldal"

Nem. Náluk az osztott tárhely per user alapon erősen le van korlátozva CPU időre és RAM-ra. Értem az okot, mindenkinek jusson szelet a tortából. Csak így mindenki weboldala folyamatosan limitálva van. Ha van egy "matek" igényesebb php, lassabban töltődik be.
Csak máshol ez egészséges versenyben van tartva.  Tehát ha unatkozik a szerver, akkor nem limiteli az adott kérés kiszolgálását, hanem full erőforrással mehet neki a teljes szerver, haladjunk tovább. Mivel random futnak be a kérések, mindenkinek jut elég torta szelet. Ha egyszerre fut be sok kérés, elég hw tartalék van, hogy leosztva is olyan gyors maradjon, hogy megmaradjon a "felhasználói élmény".
Egy dologgal szoktak/érdemes azért limitálni: ez a futó php darabszáma per weboldal. Tehát egy sűrűn látogatott / támadott oldal ne tudja lerohasztani a szervert ezernyi kéréssel. Ennek eredményeképp simán van, hogy egy tárhelyet pörgetnek, idővel a limit feletti látogatónak már azt mondja: várj. Míg egy másik oldal ebből semmit nem vesz észre. Annak elfogyott a slot, ennek nem. Érted, tehát nem a CPU, RAM erőforrásokkal matekozik, hanem az élő kapcsolatok számával, php slotokkal.

Aztán ezt lehet monitorozni, hogy ki a mohó és ha pofátlan sok CPU-t eszik, nagyobb csomagra terelni vagy dedikált szervert ajánlani neki esetleg olyan vasra tenni, ahol nem ezred magával van hanem csak 3-an, de ők 3-an kifizetik ugyanazt, mint ott 1000 másik.

Mit nyer az ügyfél? Gyorsan pörög a weboldala és nem veri be a fejét állandóan valami hülye erőforrás limitbe.

Az van, hogy ha jót akarsz, akkor kénytelen vagy korlátozni, persze ez lehet kellően bő, és észszerű. A CPanelnél a CloudLinux LVE megoldás (cgroup alapokon persze, és elég hatékony) az ami erre elég jó. Jellemzően manapság az a probléma, hogy jön a robotizált bármi, és egy oldal tetszőleges szervert bedönt(ene), és ezt nem csak gondolom, hanem látjuk nap mint nap. Ha esetleg a random felhasználó érzi úgy, hogy beküldi a random dolgát black fridayre vagy facebook reklámra, akkor is jöhetnek kellemetlen meglepetések. Amelyik felhasználó megérti a szitut az szó nélkül vált egy kategóriával nagyobb szolgáltatásra, illetve erőforrásos csomagra.

Ha 10-20db PHP folyamatra limitálod az épp elég, hogy döntsön, pláne ha ott fut az SQL (CPanelnél jellemzően ott), bár legalább esélyed van megfogni.

Egy rendesen belőtt weboldal, az rendben lesz. Többek között ezt is meg kéne érteni, hogy a randomcuccot felszórunk ideje elmúlt (bár szerintem sosem volt).

Ráadásul amióta nem kb. 55-65Ft bruttó-bruttó egy kWh, azóta nagyon nem mind1, hogy mennyire hajtják meg a vasat a népek.

( SzakiLaci | 2024. 01. 18., cs – 18:43 )

Mindenkinek nagyon szépen köszönöm még egyszer a hozzászólásokat !

Nagyon szeretem ezt a közösséget, sokat tanulok belőle.

Mint már azt írtam:

 - Egyenlőre visszaállt a régi, működő rend így, hogy ezt a modult kikapcsolták nálunk.

Ha a dedikált / prémium szervereket is érintette a dolog, ahogyan ezt fentebb jelentették,
illetve amúgy sincs rá havi 50-100eFt / 350USD hogy saját szervert üzemeltessünk akkor értelmetlen ezen rágódni sajnos.

Tehát egyenlőre be kell érjük ezzel.
(És nem, nem tudtuk a legutóbb sem megoldani 2 napon belül a költözést, mint azt már korábban írtam.)

> Vendéglátás = 364 nap ügyfélszolgálat napi 16 órában.

Akkor probald ki a taxizast (marmint az IT supportjat), az 0-24/7, kb vasarnap reggel lehet 5-10 percre leallni karbantartani/frissiteni mert amugy folyamatosan mennie kell mindennek. es jellemzoen szombat ejjel fognak felhivni hogy lassu valami stb

( Sixday v | 2024. 01. 18., cs – 20:41 )

Szerkesztve: 2024. 01. 18., cs – 20:43

"Eddig a több tucatnyi étterem "déli csúcs" időszaki forgalomkiesése milliós nagyságrendű és továbbra sem tudjuk, mi fog így történni."

vs

"havi 16000 helyett 86000 lett volna az ára. (Azt nem tudjuk a párezres havidíjból kitermelni, többet pedig az éttermek 90% nem tud egy weboldalra rászánni.)"

Ez valami kandi kamera topic akar lenni? :))))))

Mi ez a marhaság? :)))) pár óra alatt milliós a bevételkiesés és nincs a rendszerre pár tízezer forint havonta?

Hagyjuk már az ilyen szintű baromságokat :)))))))

Komolyan sírok ezen a topikon :))))))

Valaki itt hülyeséget beszél. Vagy nem milliós a bevételkiesés pár óra alatt hanem max 50e forint, vagy van pénz csak senki nem ért semmihez a környéken.

Annyiban hadd védjem picit a topiknyitót, hogy velem is történt hasonló eset.

Sztori: 2018. Magyarország egyik legnagyobb autóalkatrész kereskedelmi és motorjavító cége. Lehalt a webshop. Autószervizek, ügyfelek őrjöngtek szó szerint. Durván számolva percenként 60e Ft-t bukott a cég csak Magyarországon. Külföldi leányokról nem beszélek, mert ők se működtek, ha nem ment a magyar központ. De a cég nem akart 10-50 millió Ft-t beletenni egy normális IT infrába.
2-3 nap állás után összeraktam nekik egy vész-vész tervet, hogy életre keltsem azt a tákolmányt. HW költség volt (2 db használt szerver SSD-kel) 1,7 millió Ft. De iszonyatosan sírtak nekem tulajtól vezetőkön át pénzügyig, hogy milyen sok ez az 1,7 millió Ft. Meg hogy a versenytársak így elviszik az ügyfeleiket.

Ugyanez a sztori megtörtént pár hónappal később a cég levelezésével is. Desktop PC levelezésre. Az "csak" használt szerver hardverben 1,5 millió Ft-ba került. Azon is bukott a cég elég sokat - szinte minden üzleti folyamathoz kellett egy működő 7/24/365 levelező rendszer.

Tanulság: A cégek, tulajdonosok, vezetők mindig akkor kezdenek el sírni, amikor ég a ház. Ilyenkor egy rutinos IT-s vállat rándít és eléjük tolja a korábban írásban jelzett hibákat, kockázatokat. Ha nagyon értetlenek, akkor meg le kell lépni.

Az a bosszantó ezekben, hogy a luxiautójába hetente többet tankol, mint 3-5 évre vetítve a havi TCO-ja egy ilyennek valójában... Hiszen ez eccerű, csak számítógép, csakúgyelindul. Ahol ilyen van, le kell lépni és ennyi: "biztosan megtalálják az igényeinek megfelelő megoldást". A helyzet egyre inkább az, hogy aki nem lépi meg az IT minimumot, az előbb-utóbb lemorzsolódik. Valszin a tulaj(ok) és vezetőség meglesz valahogy, hiszen már minden fillért kipréseltek, csak lesz ott jónéhány dolgozó, akiknek lesznek nehéz napjaik.

Nekik meg külön lehet gratulnálni azért, hogy az elmúlt 15-20 évben nem vagy alig fizették ki az IT munkákat, és jelentős számban léptek külföldre a hazai IT-ben dolgozók, illetve mentek külföldi multihoz. Most pedig ha pánik van/lesz, akkor keserves dolgok jönnek.

( n.balazs v | 2024. 01. 18., cs – 22:34 )

Felmerült bennem egy ötlet a jövőre nézve: Mi lenne, ha Cloudfare-t tennétek az egész elé? Így nem kellene az RF-től elmenni, kisebb eséllyel találná be RF-t direktben DoS / DDoS / network spam. Talán az ingyenes CF is elegendő lenne.

Nem, ha beküldik a DDoS-t, akkor jónapot. A CF megfog neked több 100Gbitet, és meg is szűri, de itthon már 10Gbitet is necces megfogni, a nagyobbak 50-100G-t talán megfognak, de külföld felől nem lesz egyszerű.

Egyébként már CF (vagy más hasonlónál) sok dolog megoldható, akár robotok kirakása, fix https átirányítás ésatöbbi. Szóval lehet valóban jól tűzfalazni a szerveren, de mennyiségi támadás ellen kevés. Az standrad hosztokat simán feloldják (pl. mail, office, mx, smtp, pop3, www, www2, test.... dev), és ha ott van válasz, akkor meglesz a CF mögötti IP, illetve egyéb szervert próbálnak beborítani.

Cloudflare WAF-nál is előfordul, hogy false pozitív eredmény lesz és captcha-t kér vagy blokkol valamit. Tipikus pl. fizetési szolgáltatók és egyéb API kérések esetében ez, az előbbieket lehet IP cím alapján whitelistelni, az utóbbiakat trükkösebb, ha dinamikus IP-ről jönnek. Nálunk is kilóméteres szabálylista van, hogy milyen forgalom mehet át mindenképp.

Van egy Chromium böngészőprofilom, ahol a képek betöltését nem engedélyezem. Minden más mehet (JS, cookie-k), tényleg csak a képeket tiltom. Na, hát a CF minden második oldalon elémrakja, hogy akkor meg kéne nyomkodni a captcha-t és kiválasztani a villanyoszlopokat, vagy ami náluk trend, annyi van már, hogy fene tudja, melyiknek mi a heppje.

 

Ahogy engedélyezem a képeket, egy pillanat alatt rendbejön :D

TheAdam

ezen nincs mit csodalkozni. a botok letoltik az oldalt + js fajlokat, hogy elemezni tudjak. a kepek csak felesleges "maszlag". a cf figyeli ezt, es mivel te is hasonloan viselkedsz, ezert rolad is azt hiszi hogy botvagy.

mi videofajl protectiont csinaltunk igy: hiaba volt meg a foo.mp4 egyedi url-je, ha elott nem "nezte meg" egy adott kepet (nem a sitelogo, hanem valami menuelem volt a trukk), akkor az mp4-re is 403-at kapott.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Cloudflare WAF-nál is előfordul, hogy false pozitív eredmény lesz és captcha-t kér vagy blokkol valamit.

Köszönöm az infót!

Amit nem értek, hogy ha ezek az intelligens szűrők annyira okosra vannak megcsinálva, hogy a bánatban "nem veszik észre", hogy adott napon egy fix helyről 20 másodpercenkénti XML lekérdezés az egy szabvány REST API?

(Ami garantáltan nem fog tudni lekezelni Captcha-t.)

Ez így nonszensz. Teljesen ellehetetlenítik az óriáscégek az alkalmazás-kommunikációt, hogy kényszerítetten mindent a felhőbe tereljenek?

Vagy akkor mégis hogyan lehetne lekérni az adatokat egy saját-tárhelyről egy dinamikusan változó IP-jű étteremből?

Igazából ami leginkább felháborít, hogy miért Google?
Ki kérte / egyezett bele, hogy a privát adataimat, vevő-telefonszámokat, rendeléseket egy gusztustalan adatlopó/áruló óriáscég "analizálja", holott egy privát tárhelyet bérelek és szándékosan nem a Google "kész megoldásait" használjuk, ami felett semmi hatalmunk nincs?

Ki kérte / egyezett bele, hogy a privát adataimat, vevő-telefonszámokat, rendeléseket egy gusztustalan adatlopó/áruló óriáscég "analizálja", holott egy privát tárhelyet bérelek és szándékosan nem a Google "kész megoldásait" használjuk, ami felett semmi hatalmunk nincs?

Szerintem te egyeztél bele és benne van valahol a szerződésben, amit nem olvastál el. :)

https://iotguru.cloud

Szerintem te egyeztél bele és benne van valahol a szerződésben, amit nem olvastál el. :)

Nem a jogi "ÁSZF apróbetűvel belecsempészés" oldalára értettem, mert azt akár havonta változtathatják.

Inkább etikai oldalról tartom nagy gondnak, hogy már az informatikus cégek is inkább beállnak a multik alá sorba, és nem tartják privátnak a privát dolgokat.

(Sajnos az átlagembereknél mára már teljesen megszokottá vált, hogy magas ívben le****ja, hogy ki követi a mobilját, ki mindenki olvassa az Gmail-es / iCloud-os email-jét, stb. De nem gondoltam volna, hogy már a hozzértő, szakmabeliek is ezt teszik.)

Konkrétan tudok olyan éttermi rendszerről, akik 5x gyorsabban tudnak fejleszteni, mert teljes egészében a Google rendszerében teszik, annak infráját használva és természetesen az összes adatot megosztva a céggel.

Inkább etikai oldalról tartom nagy gondnak, hogy már az informatikus cégek is inkább beállnak a multik alá sorba, és nem tartják privátnak a privát dolgokat.

Ez csak egy eszköz abban a kurva nagy harcban, amitől téged megvédenek és amiről vélhetően semmi fogalmad nincs. Ha nem tetszik, menj olyan helyre, ahol nem védenek meg, aztán védd magad, ahogy tudod. A döntés nálad van.

Konkrétan tudok olyan éttermi rendszerről, akik 5x gyorsabban tudnak fejleszteni, mert teljes egészében a Google rendszerében teszik, annak infráját használva és természetesen az összes adatot megosztva a céggel.

És?

https://iotguru.cloud

Nem kell mindig mindenhol rémeket látni.

Az Imunify360 (ami feketén-fehéren olvasható, hogy a szolgáltatás része - hiszen meg kell védeniük a tárhelyeiket) a Google reCAPTCHA-t használja (mint nagyjából a világ fele), ami egyébként mintafelismerésre AI-t használ, és ennyi. És nyilván nem mennek át a privát adataid, vevői kontaktok és rendelésadatok. Nyugodtan elemezz egy ilyen reCAPTCHA hálózati forgalmat, nincs benne semmi egzotikus.

Mellesleg vicces, hogy egy gépi tanulással támogatott algoritmus védi meg a weboldalakat a botoktól azáltal, hogy segít eldönteni, hogy a látogató humán vagy robot..

Javaslom utánaolvasni a "herd immunity" avagy nyájimmunitás kifejezésnek az IT vonatkozásában. A spamszűrésnél és a káros hálózati forgalom elemzésénél kifejezetten jól jön, ha egy nagy adathalmazból tudsz meríteni. Így nem kell egyesével szabályokat alkotni minden egyes helyen külön-külön, bonyolult patternfelismerési algoritmusokat kódolni, a nagy számok törvénye megoldja: amit máshol bejelentettek mint true pozitív, az nálad is minimum gyanús kell legyen.

Nem azt mondom, hogy ez az üdvözítő megoldás, mindenesetre elég jól működik az esetek túlnyomó részében.

Én ezt az egészet nem értem, valaki magyarázza már el.

Egyrészt a cím baromság: mi az, hogy Google AI tűzfal? A recaptcha nem tűzfal. Van a Google-nek tűzfal szolgáltatása, amiről nem tudok?

A másik az, hogy itt backend rendszerekről van szó, akik egy tárhellyel kommunikálnak. Mit keres abban recaptcha? Valaki okos kitalálta, hogy egy REST lekérdezés eredményébe a JSON mellé betesz egy captchát? Vagy a tárhely a hülye, vagy a fejlesztő, de én ilyet még nem láttam. És mellesleg ehhez is mi köze a Google-nek, hogy a szolgáltató mit tesz bele a válaszba?

OP szoftverének kiegészítő termékének (webshop) fejlesztője a szolgáltatónál bérel egy egyszerű shared tárhelyet egy API végpont kiszolgálásához (is), amihez a szolgáltató cPanel-t kínál a menedzselésre; ennek az Imunify360 modulja egy DDOS/IDS/IPS védelmet biztosít, ami a gyanús forgalmak kiszűréséhez Google reCAPTCHA-t használ - és mindez a napokban fals pozitív blokkolást adott OP által Delphi-ben fejlesztett, Indy user-agentből indított kérésekre.

Nem a helyen múlik. Egy wordpress meg drupal is egy sima webtárhelyen fut, és vannak benne olyan végpontok, amik HTML-t szolgálnak ki, más végpontok JPG-t képet adnak, megint máshol RSS csatorna vagy API van, stb. Nyilván csak HTML kiszolgálásakor van értelme captchát adni. Ezért nem értem, hogy miért létezik olyan security termék egyáltalán, ami nem HTML oldalba is beleteszi a captchát. Vagy OP kúrta el, hogy HTML oldalra épített API-t.

Rághatjuk napestig, ugyanaz a vége: ez nem bug, hanem feature. Ott van a szolgáltató oldalán egyértelműen, hogy a tárhely ezt a fentebb megnevezett védelmet használja, ami mellesleg kikapcsolható. Az, hogy korábban működött, sok csillag együttállásának köszönhető, de a lényeg, ha API backend végpontot akarsz ilyen cuccon kiszolgálni, akkor kapcsold ki a védelmet, vagy csinálj rendes fehérlistát.

Ha dedikált szervert használsz ilyen multi-tenant megoldásra, akkor is valami DDOS védelmet illik elétenni, mert különben meg azért jön a panaszkodás, hogy valaki betalált és letérdeltette a vasat. Ott is kell fehérlista, ezt a részét nem lehet megúszni, maximum a nagyságrendek mások.

Igen, ez teljesen logikusnak tűnik. Ezzel együtt, nem elképzelhetetlen, hogy:

  • szarul van integrálva/kialakítva ez a cucc a cpanelben, vagy csak szar a defaultja
  • szarul lett bekonfolva
  • Szar content-typeot ad valójában az api, a kézműves kliens adott esetben simán le fogja szarni, hogy "text/html" van, felparsolja a bodyt, ha működik ja. Ha jól értem, delphi, annak tippre simán kinézem a beépített dolgaiból, hogy maguktól nem foglalkoznak ilyenekkel, a kézműves belehánytam a weboldal kódjába az endpointokat a wordpressben vagy akármiben szintén.

De API végpontra captchát? És ezt így hogy? Annak pont az a lényege, hogy robotok hívják meg! Mit lehet úgy elkúrni, hogy nem HTML oldalba captchát tegyen?

Ugye? Pont ezen akadtunk teljesen és indítottam erről topikot!

Főleg úgy, hogy nem küldtek egy árva mail-t se, hogy "aktiváltunk egy új intelligens (=kísérleti) szűrőt"...
hidakat és kerékpárokat kell összekattintgatni. Jó?

Ráadásul külön van választva az API lekérés az étterem domain-jétől.

Public: www.azetteremneve.hu
API: azetteremneve.webetterem.hu/api/...

Ha én ilyen terméket írnék, akkor a minimum az lenne, hogy pár hétig dry run mode-ban megy, és megtanulja, hogy melyik végponton milyen forgalom megy. Az azért nem valószínű, hogy egyazon endpoint néha webes tartalmat szolgáltat, néha meg nem. De ilyen is lehet, akkor egyéb fejlécek alapján kell bekonfigurálni, hogy mikor hogyan működjön. Kicsit le vagyok maradva, de nem lehet, hogy már a kérés fejlécéből el lehet dönteni, hogy az a kliens milyen tartalmat vár?

De az, hogy valami cucc szó nélkül egy API végponton megsérti a contractot és captcha HTML oldalt kezd szolgáltatni, az hallatlan. Itt valaki nagyon benézett valamit.

Bármi is lehet, de az van, hogy odakinn az interneten kurva nagy vihar van és a szolgáltatók próbálják n+1 különféle - lehetőleg olcsó - módszerrel megvédeni ettől a vihartól az ilyen minden egyes fillért külön-külön megbaszó ügyfeleket is. Nem fogják egyenként megnézni, hogy melyik URL API végpont vagy nem, vagy mi és satöbbi, ha az ügyfél filléreket fizet, a mérnöki óradíj meg ennek sokadik többszöröse. Ráeresztenek valamit közösen az egész fillérbaszó bagázsra, aztán vagy jó vagy nem jó. Ha jó, akkor örül mindenki, ha nem jó, akkor meg lehet mondani, hogy SLA-n belül voltak még így is.

Valahogy mindig a legfillérbaszóbb ügyfél a leghangosabb, amikor baj van, és a leghalkabb, amikor többet kellene fizetni.

https://iotguru.cloud

Én ugyan nem, de legalább nem is üzemeltetek olyan szolgáltatást, amiben az ügyfelek tudta és beleegyezése nélkül kísérletezgetnek 3rd party szolgáltatók átláthatatlan megoldásaival. :) de ez legalább tényleg nevén van nevezve... :)

"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Az van, hogy akinek 15-20e per éve van valamire, vagy mondjuk havonta 5k, az ezt kapja és kész. Egyszerűen őrület van, és mindenképp kellenek a mindenféle megoldások, amivel mindent próbálsz kiszűrni, mert a negatív felkészültségű felhasználók mindent megszívnak. Tonnaszám törögetik a WP-ket, mennek a magyar banki phisingek, az outlook phising (igen, hazai WP-ről), a kliensekről porszívózzák az email és FTP accountokat, gondolom a webeset is. Fantasztikus szintű az IT felkészültségben a lemaradás, illetve adott esetben a szakadék, és állandóan csak a rohanás van a történtek után.

Szerk: Jaés, rendkívül fel vannak általában háborodva, hogy ki mit hogy képzel. Amíg lesz olyan szolgáltató aki ezeket szónélkül tűri, vagy buksisimi van, addig csak görögni fog a hólabda.

Az a baj, hogy nem tudsz sokezer, vagy sok tízezer random juzer érdemben értesíteni. A kb. 10%-uk elolvassa, ennek az 1%-a felháborodik, nem érti, és ha utána bármi, de bármi van, akkor azonnal jön a "már megint csak variálnak, és tönkretesznek" dolog, hiszen ez a legkönnyebb. Amióta minden olyan üzemmódban van, hogy neki mind1, csak azonnal (AZONNAL) működjön, azóta ez mégrosszabb. A másik probléma, hogy weboldal összerakóék, és néha fejlesztőék pedig minden féle random gondolat mentén próbálkoznak, ami működik, de nem szabványos, eleve rossz, és akkor jön a dehát eddig működött dolog. Nagyon nehéz elmagyarázni, hogy persze, mert eddig a kutya nem foglalkozott az RFC-vel meg a biztonsággal.

Soksok próbálkozás után egyre inkább az látszik, hogy az lesz kezelhető, hogy ha csinálsz valamit, és akinek kérdése van annak válaszolsz. Például erre sincs ember... na mind1, már erről leírtam a kellően kiégés közeli véleményem.

Az "indy" agent alapján 10 másodperc volt megtalálni a használt library-t, még legalább ennyi volt az első releváns oldal amin legalább 15 másodpercet görgettem mire eljtutottam a megfejtéshez: IdHTTP1.Request.ContentType := 'application/x-www-form-urlencoded';

Kár szépíteni az igénytelenséget és a mellébeszélést

// Happy debugging, suckers
#define true (rand() > 10)

Még az jutott az eszembe, hogy érdemes lenne megnézni a logokat, hogy milyen kérések estek be, nem megtalálta véletlenül valami script kiddie, és passzírozott be mindenféle olyasmit, amire aztán joggal ugrott a waf. Pl. mert nincs megfelelően szűrve hogy mit enged tovább a frontend. Állítólag előfordult már ilyen.

Feltételezem a szolgáltató nem kísérletezik (nem tudom miért feltételezel ilyet), egyszerűen frissült a cPanel plugin (gondolom én), aminek valahol a mélyén valahol valami változott.

Ráadásul külön van választva az API lekérés az étterem domain-jétől.

Fel van véve fehérlistára az API URL és/vagy a legitim forrás IP tartomány? Ha nem, akkor a döntést rábíztad erre a modulra, annak minden következményével.

Mellesleg vicces, hogy egy gépi tanulással támogatott algoritmus védi meg a weboldalakat a botoktól azáltal, hogy segít eldönteni, hogy a látogató humán vagy robot..

De ugye pont az a gond, hogy egy webtárhelyen nem csak ember által látogatott weboldal lehet, hanem API is, amit robotok fognak hívni MINDIG. Ezeket meg nem kéne védeni robotok elől.

Az a nonszensz, hogy egy filléres, kutya közönséges webhosting-on fut ez a "teljesen szabványos REST API", ami előtt még az egyébként user által kikapcsolható védelem sincs kikapcsolva, hogy ne legyen ilyen gond vele...

Ennek a kezdetektől saját szerveren (az tök mindegy, hogy ez VPS vagy fizikai gép, hogy hosting-ban van vagy az üzemeltető irodájában) kellene működnie, és FQDN-nel kellene elérniük az ügyfeleknek, nem bedrótozott IP címmel. Ráadásul mivel ez az egész filléres manapság, kettő proxy-n keresztül, kettő vagy több backend gépre továbbítva, hogy a leggyakoribb kiesési okok le legyenek fedve. Ráadásul így a DNS változás átfutása, IP cím változása, stb. könnyedén kezelhető lenne.

( n.balazs v | 2024. 01. 19., p – 14:08 )

Ami eszembe jutott még az API végpont védelmére: kliens certificate. Kliens kapcsolódáskor felmutatja a szervernek, ami így fogadja vagy elutasítja a kapcsolatot. WAF-fal is szépen szűrhető. Nem hiszem, hogy ezt ne lehetne beledrótozni a rendszerbe viszonylag gyorsan.

Saját webszervernél Apache / Nginxbe szerintem maximum 1-2 óra alatt megoldható teszteléssel együtt. Cpanellel nem tudom, hogy lehetne ilyet konfigurálni.

( SzakiLaci | 2024. 01. 20., szo – 13:13 )

IdHTTP1.Request.ContentType := 'application/x-www-form-urlencoded';

10 éve stabilan ment, különféle internet-portálokkal folyamatosan kommunikálva. TLS 1.2

Most átírtam a programomban 'text/xml' -re, de vannak ügyfelek, akik évek óta nem frissítették a programot. (Azaz nem fizettek érte.) Szóval ez így csak rész-megoldás.

Nagyon szépen köszönöm azoknak, akik felvetették!

__

info:

Nem WP, hanem natur PHP + JS az oldal, nulláról írva. Pár külső szolgáltatás beintegrálva (levélküldés, Telegram, stb.)

Nincs semmi "vírus" stb lehetőség a beépülésre.

 

Ui.: nem "mélyen hallgatok", hanem ezt ellenőriztem, utánaolvastam, új prg. változatot adtam ki, ami nem kis munka, stb.

próbálom utolérni az összes hozzászólást, és megpróbálok majd mindre válaszolni, de most rohannom kell...

Kockázatelemzés szerint nagyjából igaz: botokat nem érdekli, mert nincs ott olyan framework, amit tudnának törni; annyit meg nem ér, hogy bárki akár a kisujját mozdítsa a feltöréssel.

Amikor majd jön az AI-hacker, na, akkor lesz csúnya világ... :D

https://iotguru.cloud

de vannak ügyfelek, akik évek óta nem frissítették a programot. (Azaz nem fizettek érte.)

WTF???!!! Ez itt az alapvető baj, hogy a tartósan nem fizető ügyfeleket is támogatni akarod. Engedd el őket, ők csak kiadást termelnek, nem bevételt, profitot. Komolyan.

WTF???!!! Ez itt az alapvető baj, hogy a tartósan nem fizető ügyfeleket is támogatni akarod.

Jól esik az aggodalmad, de szerintem valamit félreértettél.

Amire Te reagáltál, az a program frissítés, és nem, azokat nem "támogatom", max ha hívnak, akkor kiszámlázom nekik óradíj alapon.

Ez a topik főként a webes rendelési + API kiszolgáló felületről szól.

Más kis cégnél is futottam már bele, hogy az n-100. verziót is támogatták, mert az "úgy illik, úgy elégedett az ügyfél". Aztán csodálkoztak, hogy az ügyfelek miért nem frissítenek.

Egy normális support díj (exponenciálisan növekvő):
- n. (aktuális verzió): 100 pezeta / óra (minden megkezdett óra díjköteles)
- n-1. verzió: 110 pezeta / óra
- n-2. verzió: 130 pezeta / óra
- n-3. verzió: 180 pezeta / óra
- n-4. verzió: unsupported vagy 300 pezeta / óra

Így elég gyorsan rá lehet szoktatni az ügyfelek a rendszeres frissítésre. Neked is jobb, nekik is jobb. A nagyok (SAP, IBM, Red Hat, Atlassian, Microsoft, ServiceNow stb.) is ezt csinálják. Működik.

Már a +80% és +200% support díj növekedés is elég sokszor meggyőzi az ügyfeleket.

A 10x szorzó meg totál lehúzás. Persze ettől még előfordul a gyakorlatban. Csak OP tudhatja, hogy az ügyfeleinél milyen a verziók eloszlása, mennyire kell őket "meggyőzni" a frissítésről.

Olasz rokon meséli, hogy Olaszországban, az amúgy családunk által kedvelt hawai pizza szitokszó kint. Nem tartozik hozzá az olasz konyhához. Egyik pizzázó ezt úgy adja a turisták tudtára, hogy 9 EURO egy pizza, de a hawai 1000 EURO :)

Utálják az olaszok, de azért van az a pénz, amiért összerakják a kedves vendégnek :)

Hát, hogy mekkora a valódi százalék, azt nem tudom, én dolgoztam együtt pár olasszal, azoknak szemmel látható része képes volt ezen nyenyeregni, nyilván nem meme szinten. Illetve egy de, ő konkrét magas lovas kioktatást tartott, mikor valami kajában nem al dente volt a tészta, Oedig a kaja nem is olasz volt, hanem valami, amit mi bizony fossá főzve eszünk, mert az úgy jó. Sajna nem emlékszem mi volt már, de kb mintha azon nyafogott volna, hogy puha a levestészta.

( gabrielakos v | 2024. 01. 20., szo – 14:14 )

tl-dr: több hozzáértéssel, gondolkodással, előre tervezéssel lehetne ezt az egészet kisebb pénzből sokkal jobban csinálni.
nagyrészt kifogáskeresés és seggfájás ami megy - mint mindenhol ahol technical debt-et kell eltakarítani és/vagy üzleti modellt átalakítani.

Gábriel Ákos

több hozzáértéssel, gondolkodással, előre tervezéssel lehetne ezt az egészet kisebb pénzből sokkal jobban csinálni

Az a konkurencia, lásd: "tudok olyan éttermi rendszerről, akik 5x gyorsabban tudnak fejleszteni, mert teljes egészében a Google rendszerében teszik, annak infráját használva" - https://hup.hu/comment/3015606#comment-3015606

https://iotguru.cloud

( SzakiLaci | 2024. 01. 20., szo – 17:17 )

Némi plusz magyarázat (akit érdekel):

Egy 22 éves projektről beszélünk, amihez 3 éve "csatlakozott" egy plusz felület, mert nagy igény mutatkozott a "saját webáruházra", ami automatizáltan együttműködik a programommal. (Akár még feltét levét/csere szinten is, ami tudtommal az országban amúgy egyedülálló.)

  1. Én adom a programot,
    ami nem "havidíjas", hanem 1x megveszi, és csak akkor frissíti ha nagyon muszáj, vagy számára nagyon kecsegtető új fejlesztés jelenik meg.
     
  2. A webes szakember pedig az online felületet havidíjért. Amibe ügyfelenként belefektet kb 10 hónapnyi munkát előre, hogy beüzemelje (Logo készítés, stb) és ha mázlink van, akkor tartja magát az ügyfél ehhez a minimum kifizetendő összeghez.

Bár nem ez a szakmám, de én azért veszek "részt" a webes részben amennyire tudok, mert anno ígéretet tettem a fejlesztőnek, hogy ha 2-3 év alatt lefejleszti mindazt, amit 10 év alatt összeírtam, akkor cserébe protezsálom az ügyfeleknek és vállalom ingyen a szupportot. (Igen, így utólag tudom, hogy felelőtlen kijelentés volt... már késő!)

A DNS-eket is én menedzselem, mert amúgy is nekem kell a saját ügyfeleimmel egyeztetni a foglalás, díjfizetés, email fiókok, levelező-progi telepítés, beállítások,  stb. kapcsán.

Pénzügyek:

A RF osztott tárhelye havidíján kívül természetesen fizet több más külső szolgáltatónak is.

 (Pl. Van egy mini-VPS csak az adminisztrációhoz + az étel-képek egy másik felhő-szolgáltatóról töltőnek, az email-küldést is jobb volt kiszerveznie, mert a RF IP-je pikkpakk blacklist-elve lett anno, ahogy nőtt az ügyfél-létszám és a kiküldendő levelek száma.)

Szerintem természetes dolog, hogy ami költségeket csak lehet, azt mind minimalizálja, hátha valamikor 5-10 év alatt megtérül az, amit eddig belefektetett munkaórában.

Ha túl sok a szupport, vagy "állítsam be helyettük", vagy 2. alkalommal is oktatni kell, mert elsőre nem vették fel, vagy egyedi kéréseket kell intézni, azokat természetesen kőkeményen kiszámlázom 0.1 munkaóránként.

Azon kevés cégek egyike vagyok, aki nem teszi kötelezővé a havidíjat az éttermi-programom működéséhez, ha már egyszer kifizette = megvette. (Kivéve a bérleti konstrukciósok, de szerencsére azokból kevés van.)

A program-frissítés ára persze növekszik, minél régebben frissített utoljára. És igen, volt néhány olyan ügyfél is, aki soha nem fizetett egy fillért sem évek óta, és amikor most egyszerre kellett volna sokat, inkább váltott egy másik / havidíjas programra,
de a legtöbbjük nagyon szereti az én kis hobbiból indult alkotásomat és semmi pénzért nem cserélné le.

Nem várt események:

Állandóan vannak... már nagyon uncsi. Ez az eset például neki 4.5 óra, nekem 7.5 óra kiesést jelentett.
(Egyszerre hívott az összes ügyfél. Hiába tettem közzé Telegram hírcsatornán.)

Aki vendéglátó-informatikára adja a fejét, számítson rá, hogy az Okt23 vagy Dec24-27 esetleg a Jan01 azon nem szabadnapok. ahogy a többi sem. És van olyan hely, ami reggel 04:50-kor nyit (piacon lángosos) és olyan ami 23:00-kor (éjjeli bár).

A legnagyobb rizikó az újonnan nyitó éttermeknél van. Ha túl sokat kérsz előre, nem téged fog választani, mert a nyitás mellett nem maradt egy vasa sem. Aztán 3 hónap múlva csődbe megy, miközben pont az első 3 hónapban annyi kérdéssel / problémával keresett meg, hogy mással sem tudtál foglalkozni, egyedül vele éjjel nappal.

 

Ui.:

 Tisztában vagyok vele, hogy azzal, hogy ennyire nyíltan megosztok itt megannyi infót, támadásnak teszem ki magamat, de megpróbálom az itt olvasott kritikákat építő jelleggel és humorral felfogni.
Néha nem könnyű, ezért köszönöm a visszafogott megfogalmazásokat!

A 22 év alatt hányszor lett refaktorálva, újragondolva az egész kód/működés/üzleti modell? Mert azért ennyi idő alatt khm. igencsak sokat változott a világ - pláne ezen a területen...

" És igen, volt néhány olyan ügyfél is, aki soha nem fizetett egy fillért sem évek óta, és amikor most egyszerre kellett volna sokat, inkább váltott egy másik / havidíjas programra,"  illetve "A legnagyobb rizikó az újonnan nyitó éttermeknél van. Ha túl sokat kérsz előre, nem téged fog választan" örülj neki. Komolyan. Kevesebb fillérb...ó vevő/ügyfél.

"Aztán 3 hónap múlva csődbe megy, miközben pont az első 3 hónapban annyi kérdéssel / problémával keresett meg, hogy mással sem tudtál foglalkozni, egyedül vele éjjel nappal." - de ha kifizette a 0.1 órás felbontásban kiszámlázott  "vele foglalkozást" pontosan, akkor hol a hiba?

Vagy nincs limit a bevezetés támogatás, illetve babysitting időszakban felhasznált supportra? Lehet, hogy kéne - huszonév alatt azért lehet tudni, hogy mi az időben, amibe bele kell, hogy férjen a bevezetés, vagy legalább felmérés alapján meg kell tudnod mondani, hogy az adott helyen a bevezetés x határidővel y órányi benne foglalt munkaidővel kerül z Ft-ba (részletesen megadva, hogy milyen feladatok férnek bele, és mindaz, ami ezen felül van (CR, extra oktatás, stb.), az idő alapon számlázásra kerül).

Ja, a másik, hogy a supportnál célszerű lenne átgondolni az alkalmankénti minimum idő/díj bevezetését. Mondjuk negyed vagy fél óra. Ezzel a "csak egy rövid kérdés" toszogatások jelentős részét eliminálnád.

A sanyarú valóság, hogy az elmúlt 15-20 év hazai IT problémakörét szépen hozod te is, és az ügyfeleid is. Neki az kell, hogy munkaszüneti napon legyen ügyelet? Hát semmi gond, az ennyi és ennyi pénz, neki az kell, hogy minden  24/7 menjen, hát semmi gond, akkor annak is van egy ára. Ez nem havi 3 000Ft, és valszin nem is 30 000Ft.

"Ez az eset például neki 4.5 óra, nekem 7.5 óra kiesést jelentett."

Ha az infra csak nagyon pici szelete a tiéd, akkor ez ilyen. Ha shared hostingnál vagy, ott mindenféle őrület előfordulhat, és már egy saját VPS-sel (jól beállítva), rendesen rászabva az alkalmazásra nagyságrenddel csökkenti a problémákat.

"Azon kevés cégek egyike vagyok, aki nem teszi kötelezővé a havidíjat az éttermi-programom működéséhez, ha már egyszer kifizette = megvette."

Ez esetben világossá kell tenni, hogy az éttermi program mely részei azok, ami havidíj hiányban nem, vagy AS IS alapon működnek. Onnantól, hogy egyszer megvette, hiszen ez itthon nagyon divat, akkor onnantól NBD szupport van, nincs prioritásuk, és milyen óradíjjal (minden megkezdett órával...) megy a dolog, ésatöbbi. Ha jó a programod, és fontos nekik az üzletmenethez, akkor ki fogják fizetni amit kell, a többi lemorzsolódnak, máshoz se biztos, hogy átmennek. Ha nem vagy hajlandó üzletfejleszteni, és itt szó szerintileg meg kell felelni az új idők kihívásának, akkor ez van. Ezt már többen leírtuk, csak másképp.

Én nem foglak támadni, nem az a típus vagyok. Legfeljebb építő kritikát, megjegyzést fogalmazok meg. Amin aztán lamentálhatsz, hogy hülyeség vagy sem. Én is beszélek olykor hülyeséget, nem ismerhetem a teljes képet.
Én is dolgoztam olyan kis cégnél, aki pékségeknek, cukrászdáknak fejleszt és üzemeltet vállalatirányítási szoftvert, néha weblapot is. Boltokban a pékáruknál is találkozhatsz a kioskukkal. Láttam ott elég érdekes dolgot, buktatókat, technikai és humán erőforrás akadályokat....

Amit nálad problémának, megoldandó kérdésnek látok a most írtak alapján:
22 év tapasztalata van mögötted ezen a piacon. Ez óriási érték szerintem. Mégis egy új ügyfél bevezetése / beüzemelése ugyanolyan sok munkát igényel részedről, mint 5-10-15 évvel ezelőtt. Exponenciálisan csökkennie kellene egy új ügyfél bevezetésére fordítandó időnek egy bizonyos határon belül. Így nem tudsz skálázódni, ügyfélszámot növelni.
Valamit ki kellene találnod, hogy az n. új ügyfél ne vigyen el ilyen sok időt a részedről. Pl: oktatóanyag összerakása, videós tudásbázis stb. Netalán lelkes juniorokat, egyetemistákat alkalmazni, akik elvinnék az L1 supportot telefonon, neten. Nekik is jól jöhetne ez a gyakorlat.

Bevezetés vs új ügyfélszerzés. Ha mindkettőt te viszed (jó, biztos van 1-2 kollégád), akkor ez így időrabló részedről. 1000. alkalommal futod le ugyanazokat a köröket. És ezek a körök nem termelnek érdemi bevételt, profitot. Sajnos.

Szerintem.

Mégvalami. Szerintem amiket írunk ne vedd támadásnak, még ha néha éles is a kritika. Amikor a valóság robogó expresszként jön szembe, akkor azért figyelni nem árt. Arról nagyon le kéne szoktatni a megrendelőket, ügyfeleket, hogy ő problémájukat kvázi ingyen oldod meg, és nem csak neked, úgy mindenhol, mert rendre jön a "dehát ez csak 3 perc", "akkor majd megcsinálja az xy a feléből". Nos semmi gond, akkor majd biztos lesz olyan akinek 3 perc, és olyan is aki a feléből megcsinálja "és tessék", aki pedig kifizeti a valós költséget, illetve hogy ne ingyen dolgozz, az marad és boldogság lesz.

Sajnos amiket felvetsz, azok valójában eredetileg nem műszaki problémák, hanem menedzsment és pénzügyi hiányosságok, amikor ennek okán műszaki problémákká válnak.

Megfelelő bevétel mellett lenne megfelelő műszaki háttérre pénzed (vagy emberre, aki megoldja neked ezt a részt), és akkor a problémák nagy része nem is létezne. De elképesztően kevés pénzt kérsz, azt is jellemzően egyszer, így nem futja mindarra, ami kellene. Ebből lesz a műszaki probléma, hogy hogyan lehet kivágni ezt az erdőt ezzel a heringgel.

Van egy desktop support-os munkatársam, akinek rengeteg maszek melója volt/van, magán és céges egyaránt. Szereti is csinálni, a pénz is jól jön. X év után beszélgettünk, hogy kezd kidőlni, mert minden nap este 8-9 körül ér csak haza és hétvégén is végig fut ide-oda. Kérdezgettem, hogy miért vállal ilyen sok melót. Azt mondja, hogy az átlag magán ügyféltől 500-2000 Ft körül kér, mert sajnálja őket és nincs pénzük, a cégektől meg pár ezer Forintot, mert kicsik és nincs pénzük. Mondtam neki, hogy ez a gond! Azzal, hogy ilyen olcsó, semmibe se nézik a munkáját, mert ugye "azért olcsó, mert nem ér többet", és ennyi pénzért minden kis semmiségért kihívják, mert 500 Ft-ért inkább 3x kifizeti, mint egyszer megtanulja. Meg kell az árat emelni a háromszorosára első lépésben. Az ügyfelek egyharmada marad meg, így egyharmad idejét viszi el, és a pénz nem válrozik. Második lépésben időalapú árra kell váltani, plusz kiszállás. Ezzel még pár ügyfél elveszik, de a pénz jelentősen több lesz.

Részben megfogadta (hosszas őrlődés után), és mostanra valóban kevesebb idejét viszi el a maszek, és pénzénél van, ráadásul aki maradt ügyfele, jobban megbecsüli, valószínű a magasabb árak miatt (valami pszichológia hatás), mert a munkája minősége nem változott, addig is, azóta is kiváló.

Neked is azt javaslom, gondold át az üzleti modellt, és csinálj egy drasztikus váltást (nem szabad apránként, mert félbehagyod, és csak rosszabb lesz minden).

Szerintem:

  • Csak addig üzemeljen a program, amíg ki van fizetve. Az hogy havi díjasan, vagy éves követési díjasan megy, mindegy. Jó ideje (~20 éve?) ügyviteli szoftver téren senki nem áll szóba olyan ügyféllel, akivel nincs érvényes szerződése, nem fizet rendszeresen.
  • Legyen kötelező a program frissítése, ameddig használják. Ne támogasd csak az n. és n-1. verziót, akinek régebbi van, csak helyben használhassa, ne működjenek az egyéb (netes) dolgok. Túl sok munkát ad az összes kiadott verziónak megfelelni, és nagyon gátolja a fejlesztést, komolyabb átalakítást, modernizálást is.
  • A bevezetés ne legyen ingyen. Semennyi ingyen óra ne legyen. Legyen kedvezőbb díja mind a normál munkadíj, és legyen limit a bevezetésre (pl. max. 8 óra, ez alatt tuti mindent át tudsz adni ami az induláshoz kell). Persze csomag ajánlatod lehet, hogy program plusz X óra bevezetés kedvezményesen ennyi vagy annyi, de ne legyen a program árában oktatás és személyre szabás, pláne nem "amennyi az adott helyen szükséges".
  • Megkezdett órát számlázz, és legalább 10e Ft/ó nettó díjjal és ne legyen olyan, hogy "ó ez csak 5 perc volt tényleg, hagyjad". Ez is nagyon kedvező a mai világban, és így tényleg csak olyan dologgal kell foglalkoznod, ami érdemi, nem lustaság az ügyfél részéről.
  • A webes arcnak meg kellene mondanod, hogy elfogyott a barátság keret, mostantól nem lesz ingyenes support tőled a munlájára sem neki, sem az ügyfé felé. Az ő dolga a saját bizniszét sikeressé tenni, nem a Te ingyen munkádon kell jól/jobban járnia.
  • Térj át legalább saját VPS-re a website hosting szolgáltatásról. A potenciális támadások jó részét meg tudod előzni, hogy ha az ügyfelek x509 tanúsítvánnyal tudnak csatlakozni. Ezzel mindjárt az ügyfél szerződést is elősegíted, mert az ügyfél tanúsítvány max. 1 év érvényű legyen (manapság már ez is túl sok), így azt mindenképp frissíteni kell - nem ingyen, csak szerződöttekenk. Ráadásul nem kell IP cím szűréssel foglalkozni (ami ráadásul fix IP nélküli ügyfeleknél rettentő nehéz), elég a magyarországitól eltérő címeket tiltani (a támadások jó része nem magyar címről indul), DDOS védelmet úgy sem te csinálod, hanem a VPS hostign szolgáltató, országon belüli címről meg mindenki saját egyedi tanúsítvánnyal jön.

Az nem jó irány üzletileg, ha az a vonzereje a programodnak, hogy csak egyszeri költség, és utána valószínű semmit nem kell rá költenie az ügyfélnek. Ne ez legyen benne az érték, mert így felkopik az állad apránként, vagy belerokkansz a munkába. Az ügyfelek száma véges, azt kell elérni, hogy egy kezelhető méretű ügyfélkör eltartson, és az új belépők plusz bevételként jelenjenek meg ne szükségből legyenek a bevételi fenntartására vagy lassabb apadására.

A webes emberre meg nem mondok inkább semmit, ha egy új ügyfél beüzemelése (ami pár órás rutin munka kellene legyen a 3. ügyfél után) mindig 10 hónapját veszi igénybe...

A "nincs pénzük" vonalhoz picit megvilágítanám, hogy aki ezt hallja, azt gondoljon már bele ezekbe, hogy "nincs....":

- 1db alkalmazott havonta minimum 300k forintban van mindenestül, és ez minimálbér, nade tudjuk, hogy annak mennyi a realitása, ha érdemi embert akar valaki, ez lehet akár önmaga az ügyvezető rögtön, azaz ha ketten vannak akkor máris szor kettő.

- 1db céges autó, pláne ha valami közepes, akkor perpill havonta minimum 120-160k + áfa, ekkor még nem tankolták meg egyszer sem, és lehet, hogy erősen alábecsültem. Különösen érdekes, amikor az X6-osban csapat az illető, megtörtént...

- 1db iroda havonta 50-100k-tól indul, de az nagyon pici, plusz rezsi

Namármost ezt tessék kérnémszépen rögtön 12-vel felszorozni, az egy évre van. Szóval pontosan mire nincs pénz, amikor egy mondjuk olcsón mért 8-10e forintós óradíj (ha nincs kiszállás, akkor az első óra félóra...) sok lenne?

Szóval ha nincs pénzük, akkor ez van, majd valahogy megoldják.

Aki pedig a "neki arra nincs ideje" dologgal jön, az kb. ugyanez csak pepitában. Ez akkor kivétel, hogy ha villantja mellé, hogy viszont itt egy vagon pénz, annyi amennyi, ha kész menjen a számla. Ez létező egyébként, bár ritka.

Én is pont ezt a munkabéres, autós, irodás példát szoktam mondani amikor bárki ezzel a nincs erre pénz dumával talál meg.
Egy bármilyen pici, pár fős cégnek milliós nagyságrend az alapköltsége. Az csak olcsó kifogás, hogy nincs pár 10 ezer Ft-ja egy olyan dologra, ami egyébként elengedhetetlen a munkájához...

Volt akinek ezt fel kellett vezessem. Egy 100nm körüli irodánál, 5-8 alkalmazottal, hogy akkor ha nekik fontos a NAS (egy akkori Synology + diszkek, semmi izgalmas), akkor az akkori 200-250e nettó mitől sok? "Hát ehhez kell a befektető". Hogymivan... :) Azóta is rágódnak rajta gondolom.

az a szep amikor ezt egy kozepeuropai logisztikai kozpont jatszotta el, 12000 m2-es raktarral irodahazzal stb hogy nincs szaros havi 50k-juk egy berelt vonalra, kozben sokmilliardos forgalmuk van, ja es par perc kieses a telephelyek kozotti vpn-en millios veszteseget okoz :)

Szerencsére a nagyobb ügyfeleknél nem volt ilyen mondjuk úgy releváció jellegű beszélgetés. :) Azt azért hangsúlyozzuk, hogy itt nem arról van szó, hogy amint IT-ra kerül a sor, akkor pénznyomdát is üzembe kell helyezni, hanem a megfelelő ár-érték arányú, és az igényeknek megfelelő történetet lehet (kell) felvázolni. Aztán ismerve az ügyfelet, egészen jól be lehet lőni, hogy mi az ami oda való, vállalható és jó megoldás lesz.

Minden szavad igaz. Üzletileg kiegészíteném.

A motivációs lánc el van baszva. Egyetlen szereplő van motiválva, a pizzéria és ő is csak árral. Az értékesítés első szabálya, hogy aki árral motivál az ár által vész el.

A teljes láncot kell motiválni. Vagyis, szoftverbérlőjét és annak vevőjét is. A szoftverbérlőjének olyan gazdasági és kényelmi előny kell, aminél már nem szempont az ár. Ilyen az is, hogy vevőt viszel neki.  Új alternatív modell lehet az is, ha nem akar fizetni, akkor nem kell, ekkor jutalékot kérsz, de úgy, hogy a pénz egy része vagy egésze rajtad keresztülmegy.

A helyekkel egyeztetve bizonyos feltételekkel a vásárlói ajándékból közös promociót csinálnék. Amit üzletileg elbasz kb mindenki Magyarországon, hogy az értékesített terméket adja ingyen vagy olcsóbban. Ez faszság. Jobb egy pizzás hűtőmágnes, mint egy egy literes kóla ingyen. A kólát még meg sem issza, már elfekejti kitől kapta, így kidobott pénz.  Ha a forgalmazott terméket adod ingyen, azzal bemutatod mennyire értéktelen.

Na ez így elég zanza, könyvet tudnék írni a témáról. Remélem átmegy a lényeg.

“Azon kevés cégek egyike vagyok, aki nem teszi kötelezővé a havidíjat az éttermi-programom működéséhez, ha már egyszer kifizette = megvette. (Kivéve a bérleti konstrukciósok, de szerencsére azokból kevés van.)“

Szoval az uzleti modelled az, hogy a fillerbaszo problemas ugyfeleknek szolgaltatsz, a konkurencianak meg hagyod a normalis cash flowt hozo ugyfeleket. (Amibol van penz google cloudra 5x gyorsabban fejleszteni)

Halvany lila fingom nincs az altalad szolgaltatott approl, de nekem az a benyomasom a kommentjeid alapjan, hogy igy lehet keves penzert beledogleni meloba. A vendeglatos vallalkozok kozott vannak a legnagyobb fillerbaszo feketezok, szoval ha ilyen naivan allsz hozza a sajat erdekeidhez illetve az uzleti modelledhez, az utolso bort is lefogjak rolad huzni.

Erdemes lenne ujragondolni ezt az egesz koncepciot, meg onreflexiot tartani, ha nem akarsz 50-60 kozott hirtelen ledolni a szekrol.

Ne tamadasnak vedd, en is voltam ilyen sztoriban. Es minel tovabb ragadsz ebbe bele, annal nehezebb kilepni, mert normalissa valik (pedig nem az).

( SzakiLaci | 2024. 01. 21., v – 11:13 )

Ismét végigolvasva ezt kb 300 hozzászólást úgy vélem, @ggallo adta meg a választ arra, mit tanácsoljak a webes szakembernek a hasonló problémák elkerülésére: Link

Már korábban is próbáltam őt rábírni, hogy költözzünk dedikált szerverre, ekkor kértem én magam azt az ajánlatot, amit nagyon sokallt.
És akkor még egyet is értettem vele, hogy tényleg nagy ugrás lett volna az akkorihoz képesti 15x-ös ár, de leginkább, (mint azt már írtam) a költözéssel járó munka + esetleges üzemidő-kiesés, ami itt a probléma.

Ha tényleg meg lehet valahogyan oldani, hogy valamiféle ideiglenes IP átirányítással / proxy-val zökkenőmentes legyen átállás, mire letelik 1-2 hét és az összes IP változás átmegy, akkor érdemes lenne belevágni és kifizetni a szakemberek munkabérét.

Az imént kaptam a hírt:

Most, hogy a tűzfalat nekünk átkonfigolták, tegnaptól megjöttek az xss támadások. (Tegnap 400 URL.) 

... és egy másik nagy hibára is fény derült 10 perce:

 - Valamikor véletlenül/tesztelésképpen kikapcsolta a srác az SSL BasicAuth -ot, amivel eddig a progim kommunikált a szerverrel! Azaz sima https-en bármiféle autentikáció nélkül mentek az XML-ek. Lehet, hogy már 1 éve. :-(

(Ilyenkor áldom a saját paranoiámat, hogy anno, amikor a kommunikációs specifikációt kidolgoztam, beletettem egy random-változó biztonsági kulcsot magába az URL-ekbe, amit a fogadó szerver egy képlet alapján enged / eldob !)

<OFF>

Igen, kicsit pipa vagyok a srácra, mert könnyen lehet, hogy ha az XML lekérdezések nem "publikusak" lettek volna, akkor ez az egész eset nem történik meg. De ezt már nem tudhatjuk meg, mert félő lenne visszakapcsolni ezt a tűzfal-modult "tesztképpen".

De őt is teljesen meg tudom érteni, hogy 8+ órás normál munkahely és család mellett nincs ideje napközben még ezzel is foglalkozni, max pár órákat éjjel vagy hétvégén.

</OFF>

Nem tudom hogyan jött ki anno a 15x-ös díj saját VPS-re, mert havi pár ezerért kapsz olyan VPS-t itthon is, ami hozza a shared webhosting teljesítményét lazán. A felhőbe költőzés lényege pont az, hogy nem az otthora vett űrhajót kell előállítani a felhőban, hanem csak annyi erőforrást kibérelni, ami pont elég a feladat végrehajtására (persze a szükséges tartalékkal együtt).

A proxy megoldást saját VPS esetén érdekes megfontolni, nem a shared webhosting-ba kell betenni elsősorban. Én úgy csinálnám, hogy két proxy-t csinálnék két IP-re, mindkettőt adná a a DNS az adott FQDN-re. A kliens mindkét címet eltenné, és azzal a proxy-val beszélne amelyiket eléri. A proxy-k egy vagy több kiszolgálóra továbbítanák a kéréseket. Így ha valamelyik proxy-t mozgatni kell, akkor a kliens a másikkal addig tud beszélni. Ha a tényleges szervert kell mozgatni, akkor meg csak proxy konfig kell, a DNS nem változik.

Persze a shared webhosting-ból költözés is megoldható ilyen elveken, hogy az új szerver felállítása után a shared hosting-ba egy proxy kódot tenni, ami átküldi az új szerverre a kéréseket. Aztán amikor a DNS változik, az új szerverre futnak be közvetlenül ugyan azok a kérések. Amikor már a proxy-n semmi nem fut át, le lehet kapcsolni, mert akkor minden ügyfélnél frissült a DNS.

Azt nem értem, hogyan működött az egész mindenki tudta nélkül hitelesítés nélkül. Ha én írok egy kliens oldalt hitelesítéssel, és a szerver nem kér hitelesítést, akkor minimum a hibanaplóban ez látszik (amit monitorozok, de legalább időnként ránézek), vagy egyenesen nem is működik a kliens, mert megtagadja az adatforgalmazást hitelesítés hiányában.

Ha nincs ideje vele foglalkozni, akkor keressen más hobbit. De ne csináljon pénzért senkinek semmi olyasmit, amire más az üzletét építi. Elképesztően felháborító magyarázat a szar munkara a "főállás és család mellett csak erre marad időm"...

A DNS-RR csak óvatosan... Ha a kliens OS cache-be rakja az 1.2.3.4-et, és az nem elérhető, akkor hiába akar a kliens a másik címhez fordulni, ha az OS nem fogja neki arra feloldalni a nevet. Ha az alkalmazás maga végez névfeloldást, és lekezeli az RR-t, akkor jó _lehet_ a DNS RR. Szerintem...

Az már majdnem csak technikai/megvalósítási részletkérdés, hogy miként oldja ezt meg. Én nem javaslotam a DNS RR-t, mert az nagyon DNS kliens, OS resolver függő, hogy mit ad vissza az app felé. Mindenképp az alkalmazásnak kell kezelnie a két cím közötti váltást, elvégre ő tudja eldönteni, beszél-e vele az egyik meg a másik. Így ismernie kell mind a két címet. Ha ez úgy a legegyszerűbb, hogy két FQDN van 1-1 címmel, amiket az app ismer (ezek az FQDN-ek akár bedrótozottak is lehetnek, mert ugye az app írója szolgáltatja őket), és maga lekéri mindkettőt akár közvetlen DNS kéréssel, nem az OS-en keresztül. Így még a szolgáltatói DNS-ek lassú frissítési gondjai is kapásból ki lennének zárva.

Ha ez megoldott, akkor onnantól egy időben az egyik DNS bejegyzéssel és/vagy a mögötte lévő kiszolgálóval azt csinál amit akar, mert addig az app a másikat fogja használni. Így frissítés, költöztetés, bővítás könnyen megoldható, érdemi szolgáltatás-kiesés nélkül.

> az alkalmazásnak kell kezelnie a két cím közötti váltást, elvégre ő tudja eldönteni, beszél-e vele az egyik meg a másik. Így ismernie kell mind a két címet.

pont igy implementaltuk anno a taxis programot ami a kocsikban futott a tableteken, 2 cimet tudott ami mogott 2 kulon szolgaltatonal levo 2 kulon szerver volt, igy biztositva a redundanciat. az auditon meg lehulyeztek hogy ez igy faszsag, es miert nem 1 clustert epitettunk egy datacenterben ehhez...

A kliens oldlai failover-nek is megvan a létjogosultsága, nem véletlenül írtam, hogy "Ha az alkalmazás maga végez névfeloldást" - általános, böngészővel elért szolgáltatás esetén viszont mindenképp kell a dns-en kívül más is, hogy bármelyik ip-t szólítja meg valaki, az "betaláljon" a kiszolgálóhoz. 

És akkor még egyet is értettem vele, hogy tényleg nagy ugrás lett volna az akkorihoz képesti 15x-ös ár, de leginkább, (mint azt már írtam) a költözéssel járó munka + esetleges üzemidő-kiesés, ami itt a probléma.

Vagy hülyére vesz vagy balfasz. Vagy mind a kettő.

Nekem van pár szolgáltatásom, tucat VPS-en, ami geo-redundáns, három földrészen, kb. 30 vCPU, 120 GB memória, 2,4 TB storage, 120 dollár havonta, bruttó 40 ezer. Teljesen automatizált CI/CD tolja ki rá a változásokat, auto-heal és satöbbi. Felhőben se lenne sokkal drágább, talán 120-160 ezer havonta.

Ehhez van másodpercenként 60-100 API hívás, amit kiszolgál.

https://iotguru.cloud

Konkrétan:

5x Hetzner VPS (2 vCPU, 8 GB RAM, 80 GB storage), 11 USD x 5 = 55 USD

5x Contabo VPS (2 vCPU, 8 GB RAM, 200 GB storage) 7 USD x 5 = 35 USD

3x Contabo VPS (4 vCPU, 16 GB RAM, 400 GB storage) 10 USD x 3 = 30 USD

Régi ügyfél vagyok, nem emeltek (annyira) árakat, de megnéztem mai új ügyfeles árakkal, pont ekkora VPS nincs már mindegyikből, de kb. 130-140 USD körül kijönne ugyanígy, ugyanennyi.

https://iotguru.cloud

“És akkor még egyet is értettem vele, hogy tényleg nagy ugrás lett volna az akkorihoz képesti 15x-ös ár, de leginkább, (mint azt már írtam) a költözéssel járó munka + esetleges üzemidő-kiesés, ami itt a probléma.”
 

Ez vagy a “nem akarok vele dolgozni” bullshit vagy nem ert hozza. Ne komplett szervert bereljetek hanem valami VPS szart vagy containerezzetek be a picsaba az egeszet es ahhoz megfelelo cloud (pl azure container apps - biztos van ennel olcsobb is nekem ez ugrott be eloszor mert gyakran hasznalom)

Ide írom, mert részben passzol.

Ha lett volna időd, összeraktál volna egy monitoringot...mindenre. Pl. az SSL meglétére. A basic auth csekkolására és nem 1 év után derül ki ez. Minden fontos paramétert tudnál monitorozni, akár lefele az éttermek fele is szedhetnél infót és időben értesülnél a bajaikról. Nagios, zabbix, munin, ezek jó dolgok. Utóbbit nagyon szeretem, mert trendeket lehet vele nézni 1 nap...1 év távlatában. Ha romlik a szolgáltatás minősége, vissza lehet nézni, hogy mi változott. Pl. a net packet lossol, belassul, darabos. És mindjárt nem a tárhelyen kergeted a kódot, feleslegesen.

Mikor van időd: ha hatékonyabb vagy, kb amit fent leírtak. Nem kell minden hülyeséggel és hülyével foglalkozni. Spórolj időt, képezd magad, hogy hatékonyabb megoldásokat tudj alkalmazni, jobb technológiákat.

Kb 20 éve IT-zok is. Anno sok hülye feladatom volt, ezekből tanultam a legtöbbet. Akkor belefér az éjszakázás. Család mellett ez már necces. A sok tapasztalattal jobb és jobb munkákat lehet szerezni. Fentebb menni a rang és technológiai létrán. Lentről jöttem, tehát látom a régi vs. új előnyét, hátrányát és nem mindig az újabb a jobb illetve nem mindenhova. Szóval széltében és mélységében is sok mindent át lehet látni. De ehhez idő kell. Nem lehet tökölni minden idiótával.

Tudod, a melók 80%-t az ügyfelek 20%-a adja. Szabad lepattintani a 20%-t és meglepődsz mennyire felszabadulsz és előrébb tudsz lépni. Akár stabilabb szolgáltatást tudsz adni.
Pár ötlet, és nem mind sok pénz kérdése: tartalék net, tartalék tárhely, egyfajta cluster. Ha stabil az infrastruktúra (elosztott, több szolgáltatós), nyugodtan hátradőlhetsz, mert tudod, hogy működik. Nem kell éjszakázni. Ki van adva GYIK, abban minden le van írva, olvassa el a Manci és hagyjon békén élni, fejlődni.

Nézd meg a Lopott idő c. filmet. Egy életed van, ne baxd el minden baromságra. Főleg ha 20 éve nyomod, 40 körüli lehetsz...azért érdemes jobban értékelnek az IDŐ-t.

<OFF>

Nagyon szépen köszönöm ezt a hosszú és tartalmas életbölcseleti útmutatást.

Egyet kell értsek veled, egy profi webes szakembernek így kellene mindezt manapság már csinálnia.

Valószínűleg, ha csak ezzel foglalkozna a srác reggeltől estig, akkor ő is itt tartana. Szeretne ő is fejlődni, de nem tud, nincs rá idő. (Tudok az időbeosztásától a családi ügyein át mindent róla. Én még ennyit sem bírnék teljesíteni, mint ő.)

Úgy vélem, nem nekem, mint alkalmazás-fejlesztőnek a feladatom, hogy ellenőrizzem, hogy a BasicAuth aktív-e. Meg sem fordult mostanáig a fejemben, hogy ez ki lett valamikor kapcsolva. A Delphi Indy komponense csak akkor riaszt / generál exception-t, ha valami gond van. Mivel a lekérések sikerese voltak, így nem is kaphattam volna róla semmilyen napló-riasztást.
(Szerintem nincs is olyan opció benne, hogy "kötelező a basicAuth, és ha lenne, akkor sem biztos, hogy bekapcsoltam a kezdeti fejlesztési fázisban, amikor hibákat kellett volna kiszűrni...)

Mindenesetre már pár éve tervezem lecseréni az Indy-t újabb, modern komponensre, ami tudja a legeslegfrissebb OpenSSL-t (3.1 vagy 3.2?).
Be is van már építve a progimba, az NTAK küldést már ezen keresztül csinálom.
Az egyetlen "hátránya", hogy XP alatt már nem működik, Win7 a minimum neki.
(Bár szerencsére már csak kb 5-10 gép fut XP-n az országban napi szinten.)

Sajnos országos tapasztalatom az, hogy hiába nem ez a DNS / webAuth / net / webserver / JS, PHP  a szakmám, de sokszor nekem jobban kell értenem hozzá, hogy konkrétan rá tudjak mutatni hol, mi lehet a probléma. És az esetek 80%-ban igazam is van.

( SzakiLaci | 2024. 01. 21., v – 11:45 )

<OFF>

Nagyon nagyon elkanyarodtunk a "tűzfal / szerver elérhetetlenségtől" az "éttermi-informatika gazdasági tényezői" felé.

Még egyszer köszönöm az építő jellegű hozzászólásokat, sokat tanulok belőlük.

Annak kapcsán, "hogyan lehet ebből pénzt csinálni", talán sokan nem tudjátok:
 Az állam (NTAK) nemrég kiadott egy ingyenesen letölthető (és amúgy kötelező) komplett éttermi programot, 0-24 órás állami pénzen fenntartott ügyfélszolgálattal támogatva.
0-50MFt nettó forgalom között korlátlan számú eszközön, minden platformon elfut, egy rakat pénztárgép-összeköttetést támogat.

Emellett 3 másik program is van a piacon, amelyek ingyenesek az itt felsorolt 156-ból Link...

Egyébként már 15 éve beborult ez a piac, amikor egy zRt elkezdte hirdetni, hogy "3 hónapig ingyen használhatják" a vendéglők az ő kétbites full bug-os programjukat.
Ebben az országban borítékolva volt, hogy 90%-a tulajoknak ráugrott, mint gyöngytyúk ...
Mondanom sem kell, hogy közel lehetetlen egy már hónapok alatt bevezetett programot lecserélni úgy, hogy "hardverhez kötött". Azaz nem fér a pultban / diszpécsernél 2 gép, amíg az átállás megtörténik.

Példaként egy tegnapi eset:
 - Az egyik pizzázóban lefrissítettem a programot, amitől alapértelmezetté vált egy új opció: "áruk alatt megjelenő mértékegység felsorolás", (hogy ne kelljen külön a mértékegység táblázatra kattintani, azaz kevesebb egérmozgatással, gyorsabban lehet  rendelést felvenni.)
 - Ez az opció 2+ éve benne van a programban, számos hírlevelet, értesítést, blog-bejegyzést írtam már róla és küldtem szét.
 - Mivel logikus és a pincéreknek tetszik, mostantól lett az az "alap", hacsak 2 kattintással nem kapcsolják ki a "fogaskerék gombra" kattintva, 5 centivel arrébb az ablakban.
Következmény:
 - Reszkető hangon hív a (92 éves) tulajdonos, hogy a pincér lányka tegnap óta fel akar mondani ezen "szörnyű változás" okán, mert eddig ez "nem így volt"...

Tehát a gazdasági / nyereségi oldaláról annyit, hogy:

  • Ez a piac szinte teljesen bebetonozódot, mivel
  • senki sem fog programról programra ugrálni, csak a nem-fizető macerás ügyfelek
  • Nem nyílnak új éttermek, és ha igen, az nem fog sok-százezret elsőre kifizetni,
  • főleg, hogy van "ingyenes",
  • sőt, sorra zárnak be a 10-20-50 éve működő helyek is.

Vége. Új területet kell találnom. Esetleg külföldre szánt éttermi programot írni nulláról...

raadasul ma mar 1xubb egy etteremnek felrakni magat a netpincer/wolt rendszerere es megoldott nemcsak a rendeles de meg a kiszallitas is

<OFF>

Éppen ellenkezőleg. Egyik neves portál sem valósította meg a kötelező NTAK adatszolgáltatást!

Azaz ha ezekről a platformokról érkezik rendelés, akkor azt egyenként fel kell vinned kézzel az ingyenes éttermi programba, vagy veszel olyan fizetőset, ami magától "átszipkázza" az adatokat.
(Akárcsak az enyém is. Korábban már írtam, hogy más portál oldalakkal évek óta zavartalanul kommunikál a programom.)

Egyszer volt 10 év alatt gond az Indy lekérésekkel, amikor az akkori netpincér letiltotta a "nem szabványos user-agent-et", mert az enyém "Indy ... " akármi volt, nem pedig "Firefox ...". Persze teljesen szabványos volt, de szerintük nem.
Ezért kényszerűen "meghamisítottam" a User-Agent-et. Onnantól szépen működött újra.
 

Aztán a Delivery Hero konzorcium fevásárolta az egészet, kidobta a weboldalt és bevezette a sajátját, ahonnan többé már nem lehetett lekérdezni adatokat közvetlenül, hanem külön egy webszervert kell ezért fenntartani, ahová ők PUSH-olják a rendeléseket.

Amikor ez a tűzfal-szabályozás életbe lépett, akkor ez a szolgáltatásunk is megszűnt, mert ugyanezen a szerveren fut.
Azaz egyszerre nyíródott ki a "saját weboldal" és a "foodora"-s rendelések átjátszása is. Dupla káosz, dupla veszteség.

Igen, én is tudom, hogy jobb lenne két külön rendszerre rakni a kettőt.
Már sokszor jeleztem a fejlesztőnek, de neki így egyszerűbb, ha minden 1 helyen van...

___

weboldal se kell, sok etteremnek mar csak facebook oldala van manapsag

A saját weboldalnak szintén az a nagy előnye, hogy nem kell egy "külön ember" arra, hogy a rendeléseket manuálisan átpötyögje ami FB-ról jön. Főleg nem a déli csúcsidőben, miközben neki kellene a futárokat is menedzselni.

Megbízható, PC-hez, pénztárgéphez, emberekhez értő becsületes, (nem lópós), időben a munkahelyre beérkező embert megfizethető fizetésért szerinted mennyire könnyű manapság ebben az országban találni? 16 órás műszakra, 364 napra.

Van olyan étterem, ami 5-10 futárral dolgozik egyszerre, percenként jönnek rendelések.
Ha kézi erővel dolgoznák fel, 2-3 diszpécser kellene 1 helyett.

Ha ez ennyire biztos volt, miért nem csinaltad ezt meg te 15,5 évvel ezelőtt?

Mert 1 személyes microvállalkozásként, (akkor 15 éve még főállás mellett) nem volt rá 30 emberem és kb 100 millióm.

Szerinted a becsületes kisboltok és kereskedők miért zártak be amikor melléjük nyitott egy nemzetközi multi és nyitási akcióként x hónapig mindent féláron adtak?

Ez mennyiben releváns abban, hogy most az utolsó pohár sörig kötelező lejelenteni a turisztikai ügynökségnek minden vendéglátós fogyasztást? Tehát nem csak pénzügyi adatokat, hanem pontos termék szintű statisztikát, online, azonnal.

Statisztikára eddig is ott volt a KSH, attól több adat nem kell senkinek normál esetben. Ez így semmi másra nem jó, mint képet kapni arról, melyik terület megy jól, melyik konkrét vendéglátó egységet érdemes "felvásárolni"...

A fő gondot az okozza OP-nak, hogy tavaly bevezették a kötelező NTAK adatszolgáltatást (hogy az állam ennek a területnek is az összes adatához hozzájusson, hogy aztán majd csemegézhessen, kinek a bizniszét érdemes tulajdonos-váltani...), amit különböző módon lehet teljesíteni. Az egyik mód, hogy az állam által biztosított teljes körű, ingyenes éttermi programot használják, ami kapásból tudja az adatküldést, és ez 50 Mft éves forgalomig ingyenesen használható bárkinek (gondolom a fölött is filléres).... Innentől kezdve húzták ki a lábuk alól igazán a talajt, nem a 15 évvel ezelőtti demóverziós kereskedelmi programmal. Csak ott indult a lejtmenet.

Új területet kell találnom. Esetleg külföldre szánt éttermi programot írni nulláról...

Ez egy nagyon fontos gondolat! Ha a piacon akarsz maradni, érdemi bevételt / profitot is akarsz, akkor nincs más lehetőség. A magyar KKV-k egyik óriási rákfenéje, hogy nem tudnak / akarnak / mernek nemzetközi piacra lépni.
Persze el kell döntened, hogy külföld alatt mit értesz - környező országok vagy távolabbi országok is. Nagyon alaposan utána kellene járni, hogy hol milyen jogszabályi kötelezettségek vannak, mennyire kellene ügyfélszolgálatot fenntartanod, milyen nyelvi akadályokat kellene leküzdened stb. Egy rendes üzleti, pénzügyi tervet kellene összeraknod.

Szerintem.