Európa-szerte többen panaszkodnak Office 365 kimaradásra

 ( trey | 2019. január 24., csütörtök - 16:26 )

A Microsoft vizsgálja a problémát:

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Egyre többen anyázzák. Ismerek olyan céget, ahol már mérhető a kiesés okozta kár.

Mert ez on premise eseten vagy random barminel nem fordulhat elo ugye...

Amugy worksforme :D

A kiesések száma inkább szomszéd Pistikére utal, mint üzemeltető, nem egy ilyen gigacégre.

Ez egy szolgáltatás. Az onpremise meg nem az. Alma-körte.

--
arch,ubuntu,windows,libreelec,omnirom,microg
zbook/elitebook/rpi3/motog4_athene

Az onprem pont olyan mérhető, meghatározható szolgáltatás, mint a cloud base.
Bár ezt általában képtelenek megugrani.

Nálunk nem.

Tedd szépen hozzé, hogy elvileg.

Tegye fel a kezét (és írjon róla), aki látott működő és valós SLA / OLA-ban rögzített rendelkezésre állás mérést, onprem-ben.

Nagios megy/nem megy alapú mérés számít...? :-)

Mi van akkor ha a nagios (s/n)em megy? Meg attól, hogy a nagios éppen eléri az adott szervereket, szolgáltatásokat attól nem biztos, hogy a cég minden telephelyén elérhető.

Nem véletlenül volt ott a smile. :)

Attól, hogy a node-d nem éri el, még működhet HA-ban a szolgáltatás, illetve ha el is éri, még nem biztos, hogy az end user számára is helyesen működik.
Ebből kell aggregált adat, ami figyelembe veszi a szolgáltatási időn kívüli kieséseket.

No,ilyet még nem láttam sehol on-premben.

Értettem a smile-t :)

A Nagios-os megoldást nem poénból hoztam fel - adott szolgáltatást nyújtó (kevés kivétellel failover/HA megoldással működő) eszközök rendelkezésre állásának a figyelése/riportolása volt Nagios-szal összerakva - természetesen nem check_tcp használatával :-)

A Nagios azt mérte, hogy az adott infrastruktúra-elem az idő hány %-ában adja az elvárt választ a managment-hálózatból nézve. A "nincs adat" (mert nem működött a mérés) Nagios esetében is elkülöníthető a "nem működik a szolgáltatás" jellegű mért/monitorozott adattól. A "nincs adat" intervallum természetesen minden mért szolgáltatás SLA-jelentésében megjelölésre került, de a szolgáltatás _mért_ rendelkezésre állását nem befolyásolta, hiszen az a nettó (méréssel lefedett) időre vonatkoztatva került kiszámításra.

Jól kell definiálni mérést, mint tevékenységet, ide értve a kapott adatsorok kiértékelését/értelmezését is. Ha az lett volna a mérési feladat, hogy garantáltan 7x24-ről készüljön SLA-jelentés adott szolgáltatáshalmazról, akkor a "hogyan mérjük"-re nem egy darab Nagios lett volna a válasz.

Persze minden definíció kérdése, de számomra

hogy az adott infrastruktúra-elem az idő hány %-ában adja az elvárt választ a managment-hálózatból nézve

irreleváns szokott lenni, ugyanis az, hogy a management-hálózatból nézve minden rendben van, még nem feltételezi azt, hogy minden rendben van. Persze arra nagyon is jó, hogy ellehessen indulni valamilyen irányba a hibafeltárásával kapcsolatban.

Itt a figyelt/mért szolgáltatásoknak a rendelkezésre állását (a szolgáltatást nyújtó fél részéről) ez tökéletesen lefedte. Így lett definiálva a "mit mérünk?" kérdésre a válasz.

Miért, Microsoft felhőben ez (jól) működik?

Szeptemberi Azure elhasaláskor az volt a szitu, hogy maga a monitorozó is leállt a szolgáltatásokkal együtt (amikor leállt minden, nehogy megsüljenek a szerverek vacsorára).
Emlékeim szerint korábban is volt már olyan (O365 esetén), hogy a kontrol panel szerint minden rendben volt, de valójában mégsem.

Lassan több leállásról és problémáról hallani, mint ami egy normálisan üzemeltetett helyi infrastruktúrában elő szokott fordulni. Az persze egy jó kérdés, Microsoft felhő esetén X(e) maximuma mennyi, ahol X(e) azt mutatja, hogy "e" felhasználó mennyi szolgáltatás kiesésben részesül, az értéket az összes felhasználón nézve. (sarkítva: ha egy évben minden nap lenne leállás, de minden egyes nap a leállás csak egyetlen felhasználót érintene, akkor az globálisan nem lenne rossz arány)

Nem, gyakorlatilag.

Ha volt kiesés az nem az exchange miatt volt és minden esetben meghirdetett leállás volt. Ha lenne több önálló telephelyünk és minden virtualizálva akkor nem fordulna ilyen elő és persze nem másnak szolgáltatunk, hanem csak magunknak, ehhez is méreteztük.

A SPoF lehetőségét minden szempontból kizáró rendszer kell hozzá, ami azért a "minden szempontból" kitétel okán elég cinkes... (Van-e például a LAN-nal egyenértékű wifi, amire a kliensek automatikusan átállnak a LAN kiesése esetén?)

- gurulós szék: fel sem kell állni, átgurul olyan aljzathoz, ahol van LAN ;-)
a LAN másik szolgáltatásnak tekintendő, mint a levelezés, egy hozzáférési pont kiesése jó eséllyel nem érint mindenkit

- szűken levelezésre nézve: kézbe veszi a telefonját, ami vagy wifi, vagy mobilnet alapon éri el a levelezést

- van olyan lehetőség, hogy a Wifit kapcsolja le a gép, ha vezetéken lóg, a fordított innentől kezdve kvázi kézenfekvő és adott (ha switch hal le, akkor automatikusan átállhatnak a kliensek, ha részleges halál van, akkor vagy gépet kell kihúzni aljzatból, vagy kábeleket a switchből).

- ugyanez felhő esetén is kérdéses, sőt: a tartalék internet kérdése kritikusabb (kellő sávszélesség legyen ott is, valóban redundáns legyen az útvonal - ne csak az első elosztóig legyen másik kapcsolat)

Van, és van az az szituáció, ahol az ember a volt kollégáját akarná kiigazitani, de mégsem teszi, mert jó arcnak tartja. :)

Lehet :D De azért mert az NLB egy raklap szemét azért nem az admin a felelős :D

Oké de megint egy 8 rack-es infrát hasonlítunk a világ legnagyobb IT cégéhez és annak über ultimate gigafasza global replcated follow the sun rendszeréhez és az a szomorú, hogy nagyon is összemérhető a kettő míg nagyon nem szabadna.

Az egyikkel kapcsolatban tudod a hiba leheltségeket determinálni míg a másiknál nem, az egyik gondjaira építhetsz terveket a másikra hívogathatod az indiaiakat.

A LAN meg hasonló hülyeségek nem ide tartoznak mert az a kliens gondja nem a core rendszeré.

Az O365-öt és minden hasonló szintű szolgáltatót mindenkinek csak ajánlani tudom és leginkább micro, kis és középvállalatoknak mert nagyon sok nagyon komplex és drága gondtól relatív olcsón szabadulnak meg. Az a nagy baj, hogy pont a legnagyobbakat húzták be és azoknak igen nagy kiesés lehet, ha nem megy a levelezés pár órára.

A megoldás unortodox: arra kell törekedni, hogy a lehető legtöbb folyamat offline is elvégezhető legyen. Egy rakás dolgot online-osítanak, amit nem volna muszáj, bőven elég lenne helyben molyolni, aztán nap végén "commit"-tolni.

Persze ehhez ki kellene dolgozni az elosztott verziókezelést, amit az átlaguser is meg tud érteni :-). Nem egyszerű feladat, de előbb meglenne, mint a megbízható felhő :-P

Tetszik az unortodox megoldás, de a nap végi commitokkal igen nagy a valószínűsége a conflict-ok miatti túlórázás. :)
Egyébként meg szerintem az átlagjúzert kéne döntés elé állítani: vagy megtanulja rendesen használni a számítógépet, vagy menjen vissza a balettba ugrálni.

Megszoktak hogy megy, ha esne kelne, nem sirnanak emiatt. Ennyi. A problema inkabb hogy semmi nem jelezte hanem az user. Na ez vicc es nem Enterspajz.

Aki 1800km-re akarja tárolni a leveleit és a szolgáltatásait, ismeretlen helyen és módon, annak ezzel számolnia kell. Sla ide vagy oda.

Mert egy saját magad üzemeltetett (és horror áron vett) infrában sosem lehet üzemzavar... Tudod jól, hogy amint elkezded kizárni vagy csökkenteni a leállás okozó témákat exponenciálisan növekednek a költségek.

HU adatok Ausztriában és legalább egy másik európai DC-ben replikálva vannak.

Az, hogy hogyan itt található:
Http://www.microsoftvolumelicensing.com/Downloader.aspx?DocumentId=14668

Nem akarom védeni a MS-ot, mert kóklerek, de mindennek megvan a hátránya. Ezek a felhős megoldások nagyobb rendelkezésre állási idővel bírnak, sokkal kevesebb valószínűséggel törnek el, mint a helyi szerveres megoldás. Cserébe viszont ha mégis bibi van (elérhetetlen szerver, belassulás, adatvesztés), sokkal több embert érint.

Nyilván, aki úgy gondolja, hogy jobban tudja csinálni (mert lehet is), az üzemeltesse helyileg.


No keyboard detected... Press F1 to run the SETUP

A cloud nem vár, a sorompó áll
és a cloud outsource, ha beindul, nincs megállás
A clud nem vár, elindult már
és a cloud outsourceból, nincs kiszállás

..."a cloud-análvonaton nincsen fék..." :)

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

Ez majdnem olyan szellemes, mint freeoli :-)

Akkor nem véletlenül anyáztam ma, hogy nem vagy csak keservesen mennek el a levelek.
Persze ezeknél a jóképességűeknél a status oldal szerint minden jól működik:
https://portal.office.com/servicestatus

aki Microsoft-terméket használ, az meg is érdemli.

----------------------------------
szélsőségesen idealista, fősodratú hozzászólás

Nálam gond nélkül működött egész nap. Elég masszív Outlook és OneDrive használatot folytattam egész nap, szóval feltűnt volna ha valami gáz lenne.

--

A térkép szerint London volt megütve, itthon meg főleg Ausztriában vannak a fiókok (közelebb van), a GDPR oldalon tudod megnézni a lehetséges adatközpontokat. (Nekem konkrétan osztrák címre old fel az MX is, a GDPR oldal szerint az adataim Európában vannak tárolva.)
--
https://naszta.hu

Nalam a nap folyaman tobbszor is disconnectelt az Outlook. Mellettem ulo kollegamnal meg minden jo volt.

Dejó.....
Céges migráció, de nem ám akármilyen, domain migráció, office365 tárhelyek közti migráció, win7->win10 migráció és emellett új pc-k is. Ugyan mi mehet tönkre (én mondtam, hogy akármi), eddig 3 hét alatt 8db pc-t sikerült kicserélni a 200ból és amiatt is morognak, az admin rendszerekhez sehol se férek hozzá. Nyílt nethez nem férünk hozzá és tegnap mindenki az office miatt basztatott. Ha lett volna netem akkor észre vettem volna , hogy nem lokális a gubanc, még jó, hogy csak szerződéses vagyok, ugyh ha nem csinálok semmit akkor is fizetnek :)

A nagy kiszervezésbe mindig az a duma, hogy nagy üzleti kockázat meg, hogy lassan reagálnak a helyi rendszergazdák stb.. Neee! Van kollégám akit két napja folyamatosan ledobál amúgy is sokszor érthetetlenül lassú szóval nem egy főnyeremény. De hát nagy az üzleti kockázat a lokális fájlszerverekkel. Ez meg vajon mi? A ticketjeidet kb le se szarják.

Marketing in action.

Office 356(ish)

--

"You can hide a semi truck in 300 lines of code"