We’ve determined that a subset of Domain Controller infrastructure is unresponsive, resulting in user connection time outs. We’re applying steps to mitigate the issue. More details can be found in the admin center published under EX172491.
— Microsoft 365 Status (@MSFT365Status) January 24, 2019
- A hozzászóláshoz be kell jelentkezni
- 5238 megtekintés
Hozzászólások
Egyre többen anyázzák. Ismerek olyan céget, ahol már mérhető a kiesés okozta kár.
- A hozzászóláshoz be kell jelentkezni
Mert ez on premise eseten vagy random barminel nem fordulhat elo ugye...
Amugy worksforme :D
- A hozzászóláshoz be kell jelentkezni
A kiesések száma inkább szomszéd Pistikére utal, mint üzemeltető, nem egy ilyen gigacégre.
- A hozzászóláshoz be kell jelentkezni
Ez egy szolgáltatás. Az onpremise meg nem az. Alma-körte.
--
arch,ubuntu,windows,libreelec,omnirom,microg
zbook/elitebook/rpi3/motog4_athene
- A hozzászóláshoz be kell jelentkezni
Az onprem pont olyan mérhető, meghatározható szolgáltatás, mint a cloud base.
Bár ezt általában képtelenek megugrani.
- A hozzászóláshoz be kell jelentkezni
Nálunk nem.
- A hozzászóláshoz be kell jelentkezni
Tedd szépen hozzé, hogy elvileg.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Nagios megy/nem megy alapú mérés számít...? :-)
- A hozzászóláshoz be kell jelentkezni
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ő.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Értettem a smile-t :)
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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)
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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?)
- A hozzászóláshoz be kell jelentkezni
- 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)
- A hozzászóláshoz be kell jelentkezni
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. :)
- A hozzászóláshoz be kell jelentkezni
Lehet :D De azért mert az NLB egy raklap szemét azért nem az admin a felelős :D
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
..."a cloud-análvonaton nincsen fék..." :)
--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség
- A hozzászóláshoz be kell jelentkezni
Ez majdnem olyan szellemes, mint freeoli :-)
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
aki Microsoft-terméket használ, az meg is érdemli.
----------------------------------
szélsőségesen idealista, fősodratú hozzászólás
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Nalam a nap folyaman tobbszor is disconnectelt az Outlook. Mellettem ulo kollegamnal meg minden jo volt.
- A hozzászóláshoz be kell jelentkezni
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 hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Marketing in action.
- A hozzászóláshoz be kell jelentkezni
Office 356(ish)
--
"You can hide a semi truck in 300 lines of code"
- A hozzászóláshoz be kell jelentkezni