Hirdetés

Hozzászólok Aktív témák

  • bambano

    titán

    nem stressz-tesztelni kell őket, hanem kitiltani.
    nem hiszem, hogy egy banknak joga lenne stressz tesztelni egy felhő szolgáltatót, különös tekintettel arra, hogy mi lesz a többi ügyféllel, amíg tesztelnek.

    Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

  • Zigur

    senior tag

    Úgy gondolom, ez csak a felelősség elkenésére jó.
    Nem kötelező egy cég számára sem a felhőbe költözni, fenn lehet tartani saját infrastruktúrát is, de gondolom az több pénzbe kerülne a bank számára, és ha valami gond adódik, nem tudnak mutogatni valaki másra.

  • Dißnäëß

    addikt

    válasz bambano #1 üzenetére

    A többi ügyfelet ez nem érinti, egy bank ha a közel teljes stack-el felhôbe megy, az VPC lesz, azaz a megvett erôforrások dedikálva lesznek számára, párszáz procimag, pár tucat tera ram, storage dettó, egyszóval nem fog kockáztatni, hogy totál shared-ben legyen.

    Lesznek a teljes landscape-nek elemei, amik horizontálisan skálázódhatnak terhelés függvényében, és nem kell fizetnie érte, míg nem használja ôket, de jellemzôen ezek meg nem mission-critical cumók, tehát mondjuk nem az Oracle-t fogja oldalra kiskálázni, hanem a frontendjeit pl, vagy middleware, backend dolgokból ezt-azt (na nem a COBOL-ra gondolok), és a treshold mindenképpen úgy van beállítva, hogy van egy "piros vonal", ami alá nem tud menni az egész megoldás mérete (lefele), ergo az nonstop rendelkezésére áll, mint kapacitás, és dedikáltan neki szól.

    Ha van kis eszük, hibrid megoldásokkal élnek mindenhol szinte (kivéve kulcsfontosságú pontokat, pl. az Oracle cluster lábai), így nem igazán érheti ôket durva meglepi.

    A stressz teszt nem jog kérdése, hanem a felhôben megvett infrastruktúrát, amire becsült nekik xy beszállítójuk vagy tanácsadójuk, egyszerûen jól meghajtják púpra és megnézik, hogyan viselkedik.

    Szerzôdésüktôl függôen ezen rendszerek telepítése és üzemeltetése ritkán van magánál a felhôs cégnél (okkal, persze az fogja a kezüket), így vagy maguk rakják össze, vagy külsôst bíznak meg ezzel, akinek már van ebben iparági tapasztalata.

    A felhôszolgáltatónál ez az egész vállvonós, ô csak elad X erôforrást, jellemzôen dedikáltat (ilyen célra pláne), ott nem lesz gond, illetve ha a beszállító és/vagy IT javaslatára úgy döntenek, hogy legyen a landscape egy része spot instance-en mondjuk, mert rohadt olcsó, ott meg PET-elhetnek, vagy lesz kakaó, vagy nem.. de jogilag nem ütköznek semmibe.

    Ami történhet, hogy EGYÉB, spot instance-eket vevô ügyfelek beszophatják, mert lelövi az ô instance-eiket a host, amikor a dedikáltra megvett VM-eknek erôforrást kell allokálnia. Ez meg szintén vállvonós a felhôsnek, ugyanis a spot instance jogilag és technikailag így van megoldva, hogy csak ha van szabad hely, akkor fut adott host-on, de ha az púpra járatódik, lelövi azt a hypervisor és átmozgatja másikra. Ezt meg az ügyfél is tudja és tisztában van vele.

    Nem lesz gondja egyiknek sem a skálázódással. Meghajtják a rendszereket, sokkal inkább tervezésbôl adódó sebességlimit várható (kevés sávszél hálózaton, lassuló hibrid storage, kevés sávszél SAN-on, alulméretezett host-ok), emiatt meg szintén nem aggódik a felhôszolgáltató, mindenki amit kér, azt adja neki.

    Amúgy egyetértek, szántsák be mindet.. amikor egy ország teljes pénzügye, oktatása, elektromoshálózata, bármilyen egyéb infrastruktúrája költözik felhôbe az IT részlegével, az az ország onnantól egyetlen jenki gombnyomására lekapcsolható mindenrôl és kvázi meghalt. Nem kell drón, meg letámadni, meg semmi.

    A felhô kontroll, nettó függôség és rengeteg államközeli, állami szerepeket ellátó cég szempontjából szimplán nemzetbiztonsági kockázat.

    Legalábbis a publikus verziók és virtual private cloud-ok egyaránt, beleértve mondjuk egy onprem Outpost-ot is.

    A tényleges privát felhôk, melyek classic onprem módon vannak 1 vagy több geolokációra redundánsan letéve és AWS/Azure/GCP-t hírbôl sem ismernek, más tészta. A felhô technológiát és képességet is jelent, nem csak helyszínt, hogy "ott valahol", tehát egy zárt, jól védett privát felhô piszok jó cucc tud lenni, ugyanúgy élve az összes CI/CD, konténerizációs, SDDC stb. goodie-val, mint a publikus felhôk, sôt, nonkritikus részeket kitehetnek publikus felhôbe, pl. frontend réteg, vagy annak 3/4-e, hadd skálázódgasson ott, míg a privát felhô oldalon az infráját majdnem púpra lehet járatni (~70-80%), nincs parlagon hagyott hardver erôforrás (ami egyébként aranyáron van).

    Nincs gond a felhôvel MINDADDIG, míg úgy van design-olva a landscape, hogy nem függ a szolgáltatás egésze (tehát 1 vagy több kulcsfontosságú része) a publikus felhô szolgáltatótól. Bank, Paks, közlekedés, vasút, elektromos hálózat, vízgázvillany, NAV, hírközlés, stb.. esetén CSAK úgy lenne szabad csinálni a felhôzést, hogy vagy maguknak építenek ezek privátot, vagy létrehoz vki egy országon belüli felhôs céget és abba berámolja ôket (azért itt már lenne mérethatékonyság), na erre viszont se akarat (egyelôre), se kompetencia, pedig lenne értelme.

    Na meg nem kéne a CxO-knak a sales-esektôl feléjük áramló kenôpénzt elfogadni, de mivel ennek nem mindig tudnak ellenállni, megy dalolva mindenki a publikus felhôbe. Amíg mûxik, nincs gond vele, igazából maga a felhôs infra és az odavezetô utak rendelkezésre állása determinálja, a (geo)politikai vonzatáról meg hallgat mindenki mélyen, a helyi politikus vagy nem ismeri fel ennek veszélyeit, vagy belobbizta nála magát szintén valaki, hogy ugyanmár, nem lesz gond abból, ha ezentúl a teljes infrád felett mások rendelkeznek, mert náluk a "piros gomb", hiszen barátok vagyunk évtizedek óta..

    Legalább lenne egy európai felhôs cég.. de nem. GCP, AWS, Azure, amik a kontrollon felül még masszív lock-in-eket is jelentenek az egyre egyedibbé váló megoldásaikkal, melyek ma még "áhh semmiség, az Aurora egy Postgre, az Amazon Linux meg egy RedHat".. aztán 10 év múlva oda forkolódik el és nô úgy össze a felhôvel a saját cuccuk, hogy ha lejönnél róla és Aurora-ról kéne Opensource Postgre-re visszaállni, vért hugyozol vagy nettó lehetetlenség, a Linux esetében meg dettó, és mindez nem maga a kernel miatt, mert az közel ugyanaz mindnél kb, hanem a körítés, integrációk, automatizációk, ... Na ezeket, amik kényelmét megszokja az IT-s managga a felhôben, ha majd borul a bili és onprem kell felépíteni, se csapat, se skill, se semmi rá, ... ugyanúgy vérthugyozós.

    A legtöbb IT nagyvezérnek halvány lilája sincs arról, hogyan kell egy felhôt JÓL kihasználni (fôleg költségcsökkentés miatt ugye), hogy amikor esetleg ott kell hagyni, ne legyen az vért hugyozós.De legyünk ôszinték, tojnak erre is magasan. Bemennek felhôbe, nagy gázsi (bér + juttatások) felvesz + vastag boríték asztal alatt (felhôstôl), aztán ha gebasz van, max kirúgják, akkor meg úgy küldik el, hogy komoly távozási csomag és szarik bele mi lesz utána, megvan a balatoni kecó, az n+1-edik lakás, ház, vagyon, stb....

    Mi meg kis naivan elszakmázgatunk itt, hogy minek van értelme és minek nincs... :U

    Gondolkodom, mi legyen az aláírásom..

  • bambano

    titán

    válasz Dißnäëß #3 üzenetére

    ilyen hosszan megindokolt tévedést se olvastam még... :P
    tehát ha én bérelek egy komolyabb erőforrást az azúrban, nekem csinál az ms külön bérelt vonalat? külön edge routert? külön switcheket? nem csak a procimag terhelődik, hanem az összes hálózati eszköz is a stressz teszt indítójától a felhőt nyújtó vasakig.

    szerk: és akkor még arról nem is beszéltünk, hogy a stressz teszteknek igen gyakran az a vége, hogy kihullik valami csontváz. hogy az a párhuzamos betáp mégsem annyira párhuzamos. és ha megstressz-tesztelig, hogy lenyomják a féloldali betápot, és nem az következik, hogy átterhel a másik fél oldalra, hanem felborul, akkor mi van? vagy hogy tesztelik le, hogy mit csinál a felhő, ha hálózati hiba van? vagy csinálnak hálózati hibát, amitől azok, akik nem fizettek elő minden csomagopcióra, felborulnak, vagy azt hiszik, hogy minden jó, legyakják a routert, a melegtartalék megfejreáll, mint a jancsiszög.

    hülye ötlet.
    én láttam már "stressz tesztet", hogy mi van, ha fontos cégnél fontos routert kikapcsolunk. volt minden telephelyen isdn backup. a 60%-a nem jött fel.

    [ Szerkesztve ]

    Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

  • anulu

    félisten

    válasz Dißnäëß #3 üzenetére

    "A többi ügyfelet ez nem érinti, egy bank ha a közel teljes stack-el felhôbe megy, az VPC lesz, azaz a megvett erôforrások dedikálva lesznek számára, párszáz procimag, pár tucat tera ram, storage dettó, egyszóval nem fog kockáztatni, hogy totál shared-ben legyen."

    vagy nem... MS-nél még a legnagyobb kliensek (globálisan 100e+ user, felfoghatatlan pénzmozgás) sem kapnak SaaS-en dedikált cuccot (EXO, MOSS, OneDrive). ugyanazt a shared infrát használják, amit a 10 fős Zabhegyező Bt.

    "Jelenleg a cloud nem más mint a sales által elhazudott és eladott utópia, egy ígéret, csalánba csomagolt mézesmadzag, amit az üzemeltetés f@$zával vernek" | Feel the power! Intel Core i7 | iPhone 11Pro 256GB | iPad Pro 2017 64GB | XBOX ONE X

  • anulu

    félisten

    válasz bambano #4 üzenetére

    "én láttam már "stressz tesztet", hogy mi van, ha fontos cégnél fontos routert kikapcsolunk. volt minden telephelyen isdn backup. a 60%-a nem jött fel."

    a poén az, hogy nagy cégeknél is a fél éves/éves kötelező DR teszt sem más, mint egy hetekig előkészített maximum HA tesztnek nevezhető valami.

    "Jelenleg a cloud nem más mint a sales által elhazudott és eladott utópia, egy ígéret, csalánba csomagolt mézesmadzag, amit az üzemeltetés f@$zával vernek" | Feel the power! Intel Core i7 | iPhone 11Pro 256GB | iPad Pro 2017 64GB | XBOX ONE X

  • bambano

    titán

    válasz anulu #6 üzenetére

    ezen a poénon az ottani főnök nem röhögött, amikor egy nagyobb projekt akadt meg emiatt... én mondjuk igen, de ez az én természetem része :P

    Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

  • vicze1

    nagyúr

    Victoria Saporta, BoE executive director
    "Our current thinking is that the most effective ... approach to managing these risks from critical third party services providers is through a combination of minimum resilience standards aimed directly at critical third parties ... coupled with resilience testing of these critical thirdparties,"

    Tehát valaki akinek halvány lila fogalma sincs az informatikáról daracentetekről, és hogy milyen redundancia és terhelhetőség van egy szerverszolgáltatóknál, az böffentet valami orbitális hülyeséget és ebből hírt csináltak. :(

    Amazon EC2 load test policy
    Azure load test policy

    Tehát olyasmiről beszél ami ipari norma és alap követelmény.

    "Szerintük a legjobb megoldás a kockázatok kezelésére a minimum rugalmassági szabványok bevezetése lenne, stressztesztekkel egybekötve."
    Ezt hívják úgy hogy lost in translataion. (Bár lehet hogy van aki máshogy hívná...)

    Mondjuk egyesek reakciója gondolkodás helyett még sötétebb. :(

  • Dißnäëß

    addikt

    válasz anulu #5 üzenetére

    Mindketten MS-ről beszéltek, én AWS-ről, szerintem nem ismeri egyikőtök sem a cloud-ot olyan mélyen, hogy tudjátok, mit beszéltek, vagy azt nem tudjátok, hogy én mit beszélek :D vagy nem egyazon asztalnál pókerezünk éppen.. :D ;)

    Nyugodjatok meg, hogy "vannak még csodák".
    A SaaS meg dedikált így egy mondatban érzed... [...] .. de .. még ecseteled is.. :D

    AWS-nél minden csak szerződés (és pénz) kérdése, mert náluk tudnak megfelelő kaliber fölött olyan egyedi SaaS szerződést adni, ami alatt az infra kőkomolyan odadedikálva Neked. De ismétlem, szó nincs SaaS-ról, mikor egy bank felhőbe megy, nem fogja a teljes irdatlan IT-ját SaaS-ként venni lol. A nagyja saját megoldás lesz PaaS szinten, amit pedig nem tud, vagy hozzávenne új feature-ként, pl. analitika, stb, az SaaS, de lehet az O365 is, meg bármi egyéb, ami eszébe jut, de a core kemény rendszerekkel nem fog szarozni, hogy csak úgy levesz egy "dobozos" SaaS megoldást majd egy OTP a polcról és örül, hogy lám, a hitel- meg folyószámla nyilvántartó rendszerei detökjóújak lettek, pont a saját szájíze szerint, aztán ember legyen a bolygón, aki a meglévő rendszereket hozzáintegrálja az újhoz egy átmeneti periódusra + többéves migrációra..

    Én szóba sem hoztam a SaaS-t, PaaS végig ... :U Illetve szatellit rendszerekben még lehet SaaS erre-arra, de a landscape nagyja PaaS, és ez lehet olyan dedikált cumó, ami alatt nincs más ügyfél, meg semmi himihumi, hülye lenne nem így kérni, a bank meg kaliber (hacsak nem valamelyik lepukkant sarki Coop jellegű takszöv).

    MS felhő egyébként össze sem hasonlítható az AWS-el, utóbbi lényegesen stabilabb.

    bambano: AWS DirectConnect 25ms Bp-Milánó, MINDIG, időjárástól függetlenül, jóreggelt, mondjuk ezt nem Kispista Kft. szokta az ügyfeles kislány és az AWS közé kihúzni, hanem ICT cégek, bankok, biztosítók, egyszóval, nagyágyúk. És igen, csinálnak dedikált vonalat, és az összes hálózati eszköz elbírja a teljes lánc mentén a forgalmat, hozhatom a kávét ? Mesélhetek még. :D Milyen kérdés ez, hogy mi hogy bírja-e a forgalmat ? Ezzel foglalkozni sem kell, mert a "hülye" felhőszolgáltató még ezt is skálázza úgy, hogy észre sem veszed, a háttérben (tekintettel arra, hogy minden triplán HA + agyonrommá biztosítva, meg többhónapos, többlépcsős előkészület, 1 éves csak a tervezés, meg ilyen apróságok, bőven van projekt roadmap mentén rákészülni a bővítésre, a köztes lépcsők, külső szolgáltatók, MPLS-t adók szintén, Te csak annyit mondasz, hogy kérsz mondjuk 40Gbitet A és B pont között, a többit intézik, hogy mire szerződés szerint ki kell épülnie a kapcsolatnak, amögött lesz kakaó is). Ami sávszélt Te megveszel egy DirectConnect-re, azt csurig terhelheted és cibálhatod, bírni fogja end-to-end minden, nyugodt lehetsz. Ez a lényege, erről szól, ha Te ezt nem tudod púpra használni, nem adják el Neked, mert nem veszed meg, na szóval érted.

    Említett hálózati eszközkiesés demonstrálására n+1 opció van, pláne egy felhőben, ki lehet magát a DirectConnect-et is lőni, meg a köztes kapcsolatokat is, vagy fogsz és default konfigot adsz egy tűzfalnak ( = minden lezár), vagy a loadbalancer egyik lábát lelövöd, vagy még n+1 módszer, ez így wtf, kihívás, vagy mi ? Jó kis teszt lehetett amit Te láttál :D remélem nem voltál benne, az nem HA meg DR, amikor összerakunk valamit, de nem teszteljük végig a lánc szinte minden sarokpontját. Ki kell alóla rúgni a szék mikor melyik lábát, mindezt nyilván tesztkörnyezeten, ami az élessel identikus (kapacitásban nem feltétlenül, de architektúrában teljesen), és mivel a konténer orchestrator (és még a VMWare is alatta) template-ekből dolgozik, ott nincs az, hogy az IT-s azt mondja, tesztrendszer = éles rendszer, aztán ami a teszten ment, élesen mégsem úgy viselkedik, mert kiderült, hogy ja, bocs, tényleg nem egyforma egészen a két környezet..., hanem itt IGEN, EGYFORMA a kettő, nincs user error egy automatizált deployment-ben (jó esetben ;] ), ha meg a konfigok szarok, az már teszten kiderül..

    Az ilyen giga kaliberű projekteket általában külsősre bízza amúgy mindenki, aki teheti. Csak úgy egyedül ritkán vállalják be, a vendor meg nem lesz olyan hülye, hogy elkúrja az ilyeneket, hogy egy PREPROD mondjuk a PROD-tól jelentősen eltér, vagy bármi hasonló kreténség (ami inkonzisztenciát hoz a képletbe és kész a baj, amiről írtál), mert különben nagyon elverik őket.

    Betáp kérdés nemtéma, amikor egyetlen AWS region-ben több availability zone-ról beszélünk és kereszbe van 3 AZ egymásnak drótozva, de azért ne gondolja senki, hogy fricceknél az AWS által bérelt vagy üzemeltetett DC-kben betáp gondok vannak, ez egy csoffadt kis Victor Hugo-n magyarisztánban lehet, még divat, de szálljatok le a földre, itt nem fillérbaszó megoldásról beszélünk. Mikor anno T-Systems-ben külföldön voltam, egy "kisebb" DC-jében, az is önmagában (1 DC-ről beszélünk) 2 baszom épület volt, 2 külön áramszolgáltatótól betáp (fizikailag!) + az emeleti szint fűtött, kézmelegen tartott (!), mozdony méretű dízelmotorokkal megtámogatva, amiből volt emlékeim szerint épületenként 6 darab és ezekből 4 elég, hogy elvigye az adott szárnyat max kapacitás esetén is 1 hétig. És ez volt ööö ... 2009-2010 körül. Miiii a baj a táppal ? :D Ott szörnyülködtünk a szervizfolyosón az irdatlan motorok között mászkálva a "túravezetővel", hogy te jóóóó ééég, ez mekkora overkill, de sajnos vagy sem, indokolt, tekintettel arra, milyen durva kötbérek kötik őt ügyfelek ezrei által.

    Toljatok le pár durvább projektet többszázmilkó EUR nagyságrendben felhőben, utána beszélünk. Nem szeretném, ha bárki utánunk következő csak az amatőr tanulságot vonná le az egészből, hogy "hát ezt mindig mindenki így vagy úgy, de elbassza", csak mert kevesen láttak életükben TÉNYLEG jó, penge megoldást, megfelelő méretben.

    És akkor ez csak a technológia, hogy kereskedelmi szinten mik mennek, uh, külön A4-es oldalak, ha le kéne írni, a ki miért felel, milyen az együttműködés, licenszek, kedvezmények, ilyen-olyan deal-ek, holvagyunk itt már attól, hogy egy mezei user-nek, amit Ti is láttok ezekből a szolgáltatásokból, mi jár ? (Nagyon messze).

    @anulu: pénzforgalomra tojnak, lehet a világ összes vagyonát mozgató Warren Buffet cége is, a felhőszolgáltatókat az mozgatja, mennyit hagysz ott náluk, és van az a pénz - mint mindenhol a világban - amiért elkezd korpásodni a hajuk, letolják a gatyót, és egyedit adnak.

    Nem az ügyfél pénzforgalma számít, vagy tőzsdei mérete, vagy piaci kapitalizációja, stb.. náluk nem ez a kaliber meg VIP ügyfél, aki filléreket hagy ott, közben milliárdos cég, hanem aki sokat hagy ott, és attól még lehet egy "garázscég" is.. az a lényeg, hogy szarrágóskodik-e az IT részlege a felhőszolgáltatóval, vagy belátja saját igényei mentén, hogy itt zsebbe kell nyúlni, na akkor hajlandó moccanni a felhőszolgáltató is, és egyedi ajánlatok elérhetők, amik mentén - nyilván - egyedi megoldások születnek, meg mindenféle hibridek, el nem tudja földi halandó képzelni, aki nincs így ezekben benne, milyen csavart sztorik vannak.. (De amúgy szvsz ilyet az MS is tud, de velük nincs tapasztalatom, de nem hülyék, kell a biznic, ölik egymást az újabb üzletekért).

    Higyjétek el nekem, mert nem nyakig, fejbúbig benne vagyok egy elképesztően durva projektben: jó a felhő (!!). Az egyetlen gondom nekem vele, a "kinél van a gyeplő" kérdése, ez viszont rohadt nagy gond. Én kisember gondolok egyet és vagy szemet hunyok efelett, vagy nem, vagy letojom, vagy nem. A multik meg úgy gondolkodnak, hogy geopolitikától kezdve jogon át (hogy a legegyszerűbbet, GDPR-t mondjam), mindenféle megfelelőséget, stb. figyelembe vesznek és mérlegelnek, és ha a képletben az jön ki, hogy nem várható, hogy holnap az amerikai elnöknek elborul az agya és le akarna minket egy gombnyomással kapcsolni, akkor bizony bevonulnak a felhőbe akkor is, ha egy magamfajta mondjuk a haját tépi erre, mert hülye elveim vannak. :D Neeeem a gépek, meg a sávszélek, meg a latency-k meg ezek miatt, ezekre komolyan, van megoldás többnyire szinte mindig. Hanem tudjátok, a kiszolgáltatottság. A távolság még nem teszi nálam kiszolgáltatottá a történetet, fogok egy gluster-t, egy ceph-et, elosztott fájlrendszert, aminek 1-2 lábát Londonba, 1-2 lábát Malajziába, 1-2 lábát kishazánkban mondjuk nálam otthon a digi kapcsolatomon, 1000-es Digin ráér felcsorogni, amúgy meg jónapot.. aztán ha valamit lekapcsolnak, mert hirtelen nemkedvelt háborús zóna lettünk, vagy jön a MadMax, vagy tudomisén, akkor még mindig megvan mindenem a többiek által + önmagában az onprem-emen is a marék HDD-n.. csak mondtam valami nagyon hülye példát..

    Messzire mentünk. :) Ne ekézzétek a felhőt. Illetve nyugodtan, van pár disznóság bennük, törekednek a behúzottakat egyre inkább ott tartani (lock-in), én nem csipázom, de ha már muszáj, és megtehetitek, akkor érdemes átpillantanotok a sárgákhoz is..

    Gondolkodom, mi legyen az aláírásom..

  • bambano

    titán

    válasz Dißnäëß #9 üzenetére

    értem.
    tehát minden triplán.
    meg agyonbiztosítva.
    meg ha.
    meg projekt roadmap.
    meg minden van.

    írod ezt egy olyan topicban, ahol a vezércikk arról szól, hogy a bankok nem hiszik el, hogy a felhő rendelkezésre áll.
    ebből csak azt a következtetést lehet levonni, hogy az egész triplán roadmap egy hajítófát se ért. mert ha ért volna, akkor a hírek nem lennének tele a folyton megboruló felhőkkel és a bankoknak nem jutott volna eszébe, hogy a szerződésben ígértek teljesítését ellenőrizni kellene, hanem mindenki kávézgatna békésen.

    most attól tekintsünk el, hogy egy bank számára egy pont-pont kapcsolat hasznossága eléggé alacsony. a dzsordzsban sem az a kérdés, hogy az erste központi szerverterme meg az usákok felhője között tudnak-e produkálni átvitelt, hanem az a kérdés, hogy azon a geográfiai területen, ahol a dzsordzs felhasználók netbankolni akarnak (=európa), ott lesz-e rendes hozzáférés.

    meg az is eszembe jutott üres óráimban, hogy oké, letesztelték, hogy cloud. vagyis lesz egy dokument, hogy egy adott időpillanatban jó volt a cucc. és utána? mert ez azt is jelenti, hogy bármilyen változtatás történik a cloudban, megint tesztelni kell.

    Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

  • vicze1

    nagyúr

    válasz bambano #10 üzenetére

    "a bankok nem hiszik el, hogy a felhő rendelkezésre áll."
    Továbbra is egy technológiailag tudatlan személy kijelentéséről van szó...

    Ebből azt a következtetést lehet levonni, hogy te minden nemű utána járás és teljes tudatlansággal fikázol valami élből. Te se tudod, hogy miért és ezek a tények.

    Nagyon durva az a hülyeség ami belőled folyik ezzel kapcsolatban. :(

  • bambano

    titán

    válasz vicze1 #11 üzenetére

    felhívnám a figyelmet, hogy a cikket, aminek a topicjában irkálod a tévedéseidet, nem én írtam. még csak nem is én fordítottam.
    az állítást, hogy a bankok nem hiszik el, hogy a felhő rendelkezésre áll, én FELIDÉZTEM vagy ISMÉTELTEM (oké, lehet, hogy IDÉZTEM), nem pedig kitaláltam.
    ezt neked észre kellett volna venni, ha megpróbáltál volna érdemben hozzászólni. de nem vetted észre, így a durva hülyeség belőled folyik, nem belőlem.

    Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

  • vicze1

    nagyúr

    válasz bambano #12 üzenetére

    Tehát ahelyett hogy ellenőriznéd valaminek a valóságtartalmát nyilván azt is elhiszed, hogy a Föld lapos nem mert valaki leírta?

    Esetleg az hogy konkrétan beidéztem a valós forrást, és belinkeltem a cloud platformok erre vonatkozó policy-ját talán egy csöppet több tartalommal bír mint a te tartalom nélküli fröcsögésed...

    [ Szerkesztve ]

  • bambano

    titán

    válasz vicze1 #13 üzenetére

    hagyjuk.

    [ Szerkesztve ]

    Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

  • vicze1

    nagyúr

    válasz bambano #14 üzenetére

    Értem hagyjuk a tényeket és éljünk a te fantázia világodban, hogy tudj fikázni.

    "nem hiszem, hogy egy banknak joga lenne stressz tesztelni egy felhő szolgáltatót"
    Továbbra is hitben élsz mert ez kényelmesebb, helyett hogy tennél 1db Google keresést, és kiderülne, hogy a szolgáltatók feltételiben benne van hogy ezt nyugodtan megteheted minden nem mű jelzés nélkül, mert a rendszereik nem esnek hanyat ha megfújod őket.
    Kérdés hogy vajon a saját rendszereidből indulsz ki ilyenkor?

    [ Szerkesztve ]

  • bambano

    titán

    válasz vicze1 #15 üzenetére

    na jó, akkor ne hagyjuk.
    a cikk arról szól, hogy hiába írtak le a felhő szolgáltatók egy csomó mindent, hiába szerveztek meg egy csomó workflow-t, mégis úgy tapasztalják a bankok, hogy a felhős rendszerek nem elég megbízhatóak.
    ezt nem én találtam ki, ez van a cikkben.
    tehát hiába linkelgeted az ígéreteket, jól láthatóan nem teljesültek.
    ezt nem én mondtam, a cikkben van leírva. most tekintsünk el attól, hogy az elmúlt időszakban sorozatosan jöttek elő a cloud bugok, (meg más is, mint pl. exchange...).
    ezeket nem én találom ki, nem én gyártom a hírt, hanem hivatkozom rájuk.

    de nyugodtan toljátok a cloud reklámot, én ráérek.

    Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

  • bambano

    titán

    válasz vicze1 #15 üzenetére

    egyébként te elolvastad, amit linkeltél?
    merthogy a második linked pontosan az ellenkezőjét írja, mint amit te:
    idézem az amazon ec2 teszt policyjét:
    "Volumetric network-based DDoS simulations are explicitly prohibited from the Amazon EC2 platform and are not covered by this policy."
    és ha elolvasod a linkelt policyt, benne van, hogy csak korlátozott feltételekkel tesztelheted az ec2-t.

    Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

  • vicze1

    nagyúr

    válasz bambano #16 üzenetére

    Tehát most egy hírben leírt valótlanságokra fogsz szünet nélkül hivatkozni? :U Ezzel fog eltelni a takarózás?
    Mármint ezek a dolgokat soha senki nem állította konkrétan. Csak hát valóság nem támasztja alá a konteód, így nyilván nem nézel utána.

    Exchange bug nem érintette semmilyen formában az Exchange Online-t de ne zavarjon... Megint levegőbe fröcsögés tudatlanságból.

    #17 bambano: Oh, nem lehet le DDoS-olni őket az mindjárt más egyből szar az egész, mert hát a te on-prem-ed röhögve túlélni az DDoS-t nyilván... DDoS az nem stressz teszt semmilyen formában.

  • bambano

    titán

    válasz vicze1 #18 üzenetére

    egy hírben???
    te most ébredtél fel a hibernálásodból?
    "Exchange bug nem érintette semmilyen formában az Exchange Online-t de ne zavarjon...": a meg más is szókapcsolatot olvastad?
    az elmúlt időszakban legritkábban kéthetente jött hír egy-egy orbitális ms szoftver vagy ms + amazon + google cloud bugról.
    tehát vagy az van, hogy:
    1. a média folyamatosan hazudik, mindegyik, állandóan, nem csak ebben az egy cikkben
    2. vagy mégiscsak az van, amit emlegettem, hogy a nagy cégek biztonsági protokolljai hajítófát se érnek.

    az én cuccom eddig rendben működött. majd ha gondom lesz a támadásokkal, akkor szerződök ddos védelemre. mert azt is lehet, nem kell hozzá felhőbe költözni.

    Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

  • bambano

    titán

    válasz Dißnäëß #9 üzenetére

    "ha a képletben az jön ki, hogy nem várható, hogy holnap az amerikai elnöknek elborul az agya és le akarna minket egy gombnyomással kapcsolni, akkor bizony bevonulnak a felhőbe": éppen tegnap ment a téma a telexen [link] , azt írták, hogy saját vezérkari főnöke is félt attól, hogy elborul trump agya. ez alapján az outsiderek igen megalapozott döntéseket tudnak hozni...

    Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

  • vicze1

    nagyúr

    válasz bambano #19 üzenetére

    Aha értem csak a mondataid "és" előtti része kamuzás?

    Pont mint ez:
    "+ amazon + google cloud bugról."
    Nyugodtan linkelgetheted ezeket a bugokat, csak ami nincs azt nem lehet...

    1. Az IT Cafe elég sok esetben több mint ferdít, ahogy most is.
    2. A software bug továbbra is egy mindenhol létező dolog és független a szolgáltatás lokációjától.

    LOL, mint "ISP" egy alap DDoS védelmed sincs. Nem rossz... Látom fő a biztosság, majd csinálunk valamit ha összeomlott jó filozófia.

  • bambano

    titán

    válasz vicze1 #21 üzenetére

    "1. Az IT Cafe elég sok esetben több mint ferdít, ahogy most is.": rendben, megértettem, szerinted a rendszerek jók, a média meg hazudik.

    "LOL, mint "ISP" egy alap DDoS védelmed sincs. Nem rossz... ": lol, tehát ha nincs szerződésem ddos védelemre, akkor szerinted nincs is ddos védelmem?

    Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Hozzászólok Aktív témák

Hirdetés