Az Office 365 teljesítményének beállítása alapkonfigurációk és korábbi teljesítményadatok használatával

Létezik néhány egyszerű módszer az Office 365 és cége közötti kapcsolat teljesítményének ellenőrzésére, amellyel meghatározható a kapcsolat hozzávetőleges alapértéke. Ha ismeri az ügyfélszámítógépek kapcsolatának korábbi teljesítményét, könnyebben és korábban felderítheti, azonosíthatja és előre jelezheti a problémákat.

Ha nem foglalkozik rendszeresen teljesítményproblémákkal, ebből a cikkből segítséget kaphat néhány gyakori kérdés megfogalmazásához, például hogy honnan tudható, hogy az észlelt probléma a teljesítménnyel függ össze, és nem Office 365-ös szolgáltatási incidens? Hogyan lehet tervezni a jó teljesítményt hosszú távon? Hogyan figyelhető a teljesítmény? Ha munkatársai vagy ügyfelei gyenge teljesítményt tapasztalnak az Office 365 használata közben, és felmerül Önben a fenti kérdések egyike vagy másika, akkor olvasson tovább.

Fontos : Jelenleg is teljesítményprobléma áll fenn ügyfele és az Office 365 között? Kövesse a Teljesítményhiba-elhárítási terv az Office 365-höz című cikk lépéseit.

Tudnivalók az Office 365 teljesítményéről

Az Office 365 egy, a Microsoft üzemeltette, nagy kapacitású, dedikált hálózaton működik, amelyet szigorúan monitorozunk nemcsak automatikusan, hanem emberek közreműködésével is. Az Office 365-felhő karbantartásának egyik részfeladata a házon belüli teljesítményhangolás és áramvonalasítás, ahol erre mód van. Mivel az Office 365-felhő ügyfeleinek az interneten keresztül kell csatlakozniuk a rendszerhez, folyamatos erőfeszítéseket teszünk azért, hogy az Office 365-ös szolgáltatások közötti teljesítményt is finomhangoljuk. A felhőben a teljesítménybeli fejlesztések gyakorlatilag soha nem állnak le, ezért rengeteg tapasztalatot szereztünk abban, hogy miként őrizhetjük meg a felhő jó állapotát és sebességét. Ha Ön esetleg teljesítményproblémát tapasztal az Office 365-tel a működési helyén, nem célszerű mindjárt egy ügyfélszolgálati üggyel kezdeni a megoldást, vagy arra várni. Ehelyett „belülről kifelé” Önnek érdemes megkezdeni a probléma kivizsgálását. Kezdje tehát belülről, a saját hálózatánál, és onnan haladjon kifelé, az Office 365 irányába. Mielőtt ügyfélszolgálati ügyet indítana az Office 365 ügyfélszolgálatánál, önállóan is gyűjthet adatokat, és elvégezhet néhány műveletet, amellyel feltárhatja, esetenként meg is oldhatja a problémát.

Fontos : Tartsa szem előtt a kapacitástervezési szempontokat és az Office 365-re vonatkozó korlátozásokat. Ezek az információk előnyt jelentenek, amikor teljesítményproblémát próbál megoldani. Íme egy hivatkozás az Office 365 platformszolgáltatások leírására. Ez egy központi weblap, ahol megtalálható az Office 365 összes szolgáltatásának hivatkozása. A hivatkozásokra kattintva megtekintheti a megfelelő szolgáltatásleírást. Ez azt jelenti, hogy ha meg szeretné tekinteni a SharePoint Online alapbeállítás szerinti korlátait, akkor a SharePoint Online szolgáltatásleírásának hivatkozására kell kattintania, és meg kell keresnie a határokról és korlátokról szóló szakaszt.

A hibaelhárítási műveletekbe feltétlenül abban a tudatban vágjon bele, hogy a teljesítmény egy csúszóskála, nem egy idealizált érték elérését és állandó fenntartását jelenti (ha így gondolja, akkor az alkalmilag nagy sávszélességet igénylő műveletek, például a nagyszámú felhasználó felvétele a rendszerbe, vagy egy nagyobb mennyiségű adat áttelepítése igen megterhelő lehet – ez esetben okvetlenül számítson a teljesítmény romlására). Kialakíthat, sőt ki is kell alakítania egy durva képet a teljesítménycélokról, de a teljesítményt számtalan változó alakítja, ezért az változhat. Ez a teljesítmény természetéhez tartozik.

a teljesítménnyel kapcsolatos hibaelhárítás nem meghatározott célok elérését és végtelen időre szóló fenntartását jelenti, hanem a meglévő tevékenységek javítását az összes változó figyelembevételével.

Rendben, akkor lássuk, hogyan fest egy teljesítményprobléma

Először azt kell megállapítania, hogy a tapasztalt jelenség csakugyan teljesítményprobléma-e, és nem szolgáltatási incidens. A teljesítményprobléma nem azonos az Office 365-beli szolgáltatási incidenssel. A kettő között az alábbiak szerint tehet különbséget.

Ha az Office 365 szolgáltatásban hiba lép fel, az szolgáltatási incidens. Az Office 365 Felügyeleti központ Jelenlegi üzemállapot lapján vörös és sárga ikonok láthatók, és előfordulhat, hogy az ügyfélszámítógépek teljesítménye is csökken, amikor az Office 365-höz csatlakoznak. Ha például a Jelenlegi üzemállapot lapon vörös ikon és a Vizsgálat alatt megjegyzés áll az Exchange mellett, akkor valószínűleg szervezete dolgozói is jelentik Önnek telefonon, hogy az Exchange Online-hoz csatlakozó e-mail fiókjaik gyenge teljesítményt mutatnak. Ebben az esetben okkal feltételezheti, hogy az Exchange Online teljesítménye szolgáltatáson belüli problémák miatt romlott.

Az Office 365 Állapotjelző irányítópultja, amelyen az összes munkaterhelés zölden látható, kivéve az Exchange-t, ahol a Szolgáltatás visszaállítva felirat jelenik meg.

Ezen a ponton, Ön mint az Office 365 rendszergazdája ellenőrizze a Jelenlegi üzemállapot lapot, majd A részletek és előzmények megtekintése lapot is, mégpedig rendszeresen, hogy naprakész információi legyenek arról, hogy milyen karbantartást végzünk a rendszeren. A Jelenlegi üzemállapot irányítópultot azért készítettük, hogy tájékoztassuk a szolgáltatás módosításairól és esetleges hibáiról azokat, akiket illet. Az üzemállapot előzményeibe rendszergazdák által rendszergazdáknak írt megjegyzések és magyarázatok célja az, hogy ki-ki felmérhesse a probléma hatását, és nyomon követhesse a folyamatban lévő munkát.

Az Office 365 Állapotjelző irányítópultja, amely tudatja, hogy az Exchange Online szolgáltatás vissza lett állítva, és ismerteti ennek okát.

A teljesítményproblémák nem szolgáltatási incidensek, bár az incidensek is okozhatnak teljesítményromlást. A teljesítményproblémák az alábbiakról ismerhetők fel:

  • A teljesítményprobléma előfordulása független attól, hogy milyen jelentés látható az Office 365 Felügyeleti központ Jelenlegi üzemállapot lapján a szolgáltatás állapotáról.

  • Az általában viszonylag zökkenőmentesen elvégezhető műveletek végrehajtása hosszú időt vesz igénybe, vagy egyáltalán nem sikerül.

  • A probléma megismételhető, vagy legalábbis tudható, hogy bizonyos lépéssorozat megtétele esetén bekövetkezik.

  • Ha a probléma nem folyamatos is, mégis mutat valamiféle mintát, például tudható, hogy délelőtt 10:00 óráig telefonálnak azok a felhasználók, akik nem tudnak stabilan hozzáférni az Office 365-höz, és a hívások száma körülbelül délig csillapodik.

Ez valószínűleg Önnek is ismerősnek tűnik, túlságosan is ismerősnek. Miután felismerte, hogy teljesítményproblémáról van szó, felmerül a kérdés, „mi a következő teendő?” A cikk hátralévő része pontosan ennek eldöntéséhez nyújt segítséget.

A teljesítményprobléma meghatározása és tesztelése

A teljesítményproblémák gyakran hosszabb idő alatt alakulnak ki, ezért nem mindig egyszerű a tényleges probléma meghatározása. Az eredményes munka érdekében szükség van egy világos problémameghatározásra, a probléma kontextusának jó körülírására, majd kiváló, ismételhető tesztelési lépések létrehozására. Ellenkező esetben, önhibáján kívül, vesztésre lehet ítélve. Miért? Az alábbiakban néhány példát olvashat olyan problémameghatározásokra, amelyek nem nyújtanak elegendő információt:

  • Amikor korábban a postaládáról a naptárra váltottam, észre sem vettem, most meg elmehetek kávézni közben. Vissza lehetne állítani a korábbi állapotot?

  • A fájlok feltöltése a SharePoint Online-ra egy örökkévalóságig tart. Miért ilyen lassú délután, amikor máskor elég gyors? Nem lehet akkor is ugyanolyan gyors?

A fenti problémameghatározások több komoly kihívást jelentenek. Konkrétabban, sok-sok többértelműséggel kell szembenézni, például:

  • Nem világos, hogy a postaládáról a naptárra váltás korábban milyen teljesítményt mutatott.

  • Amikor a felhasználó azt mondja, hogy „nem lehet akkor is ugyanolyan gyors?”, akkor mit jelent az, hogy gyors?

  • Meddig tart az „örökkévalóság”? Néhány másodpercig, percekig, vagy a felhasználó elmehetett közben ebédelni, és a művelet csak a visszatérte után tíz perccel fejeződött be?

Mindezek az állítások nincsenek tekintettel arra, hogy a rendszergazda és a hibaelhárító személy sok részletet nem tudhat meg az ilyen problémameghatározásokból. Például, hogy mikor kezdődött a probléma. A felhasználó otthonról dolgozik-e, és a lassú váltást csak az otthoni hálózaton tapasztalja. A felhasználó futtat-e sok RAM-ot igénylő alkalmazásokat párhuzamosan a helyi gépén, vagy régebbi operációs rendszert használ-e, esetleg kihagyta a legutóbbi frissítéseket.

Amikor a felhasználók teljesítményproblémát jelentenek be, rengeteg információt kell gyűjteni. Az ilyen információgyűjtés egy eljárás része, amelyet a probléma hatóköre felmérésének, azaz kivizsgálásának nevezhetünk. Az alábbiakban egy egyszerű hatókör-felmérési listát találhat, amelynek segítségével információt gyűjthet a teljesítményproblémáról. A lista nem törekszik a teljességre, de kiindulásul szolgálhat egy saját lista létrehozására:

  • Melyik napon és körülbelül milyen időben történt a probléma?

  • Milyen típusú ügyfélszámítógépet használt a felhasználó, és az hogyan csatlakozik a vállalati hálózathoz (VPN-, vezetékes vagy vezeték nélküli kapcsolattal)?

  • A felhasználó távolról dolgozott, vagy a munkahelyén?

  • A felhasználó megpróbálkozott-e ugyanazokkal a műveletekkel egy másik számítógépen, ha igen, ugyanazt a viselkedést tapasztalta-e?

  • Haladjon végig a problémát előidéző lépéseken, és írja le az elvégzett műveleteket.

  • Mennyire lassú a teljesítmény, másodpercben vagy percben mérhető?

  • A világ mely pontján tartózkodik a felhasználó?

A fenti kérdések némelyike kézenfekvőbb, mint a többi. A legtöbben megértik, hogy a hibaelhárító személynek szüksége van a pontos lépésekre ahhoz, hogy reprodukálja a problémát. Különben hogyan lehetne rögzíteni, hogy mi a hiba, és hogyan lehetne tesztelni, hogy megoldódott-e? Kevésbé magától értetődnek az olyan kérdések, hogy „Melyik napon és körülbelül milyen időben történt a probléma?” vagy „A világ mely pontján tartózkodik a felhasználó?” – ezeket az információkat párban lehet használni. Attól függően, hogy mikor dolgozott a felhasználó, néhány óra időeltérés azt jelentheti, hogy már éppen karbantartás zajlott a cég hálózatának egy részén. Ha például cége hibrid telepítéssel rendelkezik, például hibrid SharePoint Search szolgáltatással, amely képes lekérdezni a SharePoint Online és egy helyszíni SharePoint Server 2013-as példány keresési indexeit is, a helyszíni farmban frissítések lehettek folyamatban. Ha cége kizárólag felhőszolgáltatásokat használ, a rendszer-karbantartási munkálatok hálózati eszközök hozzáadására vagy eltávolítására, vállalati szintű frissítések telepítésére, illetve DNS-módosításokra vagy más alapvető infrastrukturális változásokra is kiterjedhet.

Teljesítményproblémák elhárításakor a helyzet kicsit olyan, mint egy bűnügyi helyszínelés, a hibaelhárítást végző személynek pontosnak és figyelmesnek kell lennie, ha a bizonyítékok alapján bármilyen következtetésre szeretne jutni. Ehhez a bizonyítékok összegyűjtése után helyesen kell meghatároznia a problémát. A problémameghatározásnak tartalmaznia kell a számítógép környezetére, a felhasználói környezetre, a probléma jelentkezésének időpontjára és a teljesítményprobléma előidézéséhez vezető pontos lépésekre vonatkozó információkat. Ez kell legyen, kezdetben és később is, az elsődleges szempont. Amikor a probléma megoldásán fáradozva ismét végighalad a problémameghatározáson, a lépések alapján tesztelnie és igazolnia kell, hogy a megtett intézkedések megoldották a problémát. Ez elengedhetetlenül fontos annak megállapításához, hogy a munka sikerrel járt-e.

Tudja, milyen volt a teljesítmény a régi szép időkben?

Szerencsétlen esetben ezt senki sem tudja. Senki nem tud számokat mondani. Ez azt jelenti, hogy senki sem tud választ adni arra az egyszerű kérdésre, hogy „körülbelül hány másodpercig tartott egy postaláda megnyitása az Office 365-ben?”, vagy „mennyi ideig tartott akkor, amikor a vezetőség Lync Online-értekezlet tartott?”, ami sok cégnél bevett gyakorlat.

Amik hiányoznak, azok a teljesítmény alapértékei.

Az alapértékek kontextusba helyezik a teljesítményt. Ezeket cége igényeitől függően felveheti alkalomszerűen vagy rendszeresen. Ha nagyobb cégről van szó, akkor lehet, hogy az üzemeltetési részleg foglalkozik az alapértékek felvételével a helyszíni környezetben. Ha például Ön telepíti a javításokat az összes Exchange-kiszolgálóra a hónap első hétfőjén és a SharePoint-kiszolgálókra a hónap harmadik hétfőjén, az üzemeltetési részleg valószínűleg lefuttat egy teendőlistát vagy forgatókönyvet annak igazolására, hogy a kritikus funkciók működőképesek. Így például a postaládát megnyitva és a Küldés/fogadás gombra kattintva ellenőrizhetik, hogy frissülnek-e a mappák, vagy a SharePointban tallózással megnyithatják a kezdőlapot, a vállalati keresőlapra lépve futtathatnak egy keresést, hogy érkeznek-e találatok.

Ha az alkalmazások az Office 365-ben futnak, a legalapvetőbb alapértékek, amelyeket felvehet, mutathatják azt az időtartamot (ezredmásodpercben), amíg a hálózat egyik ügyfélszámítógépe eléri a kilépési pontot, vagyis azt a pontot, ahol a gép elhagyja a hálózatot, és kapcsolatba lép az Office 365-tel. Íme néhány hasznos alapérték, amelyet célszerű megvizsgálni és rögzíteni:

  • Azonosítsa az ügyfélszámítógép és a kilépési pont közötti eszközöket, például a proxykiszolgálót.

    • Azért kell ismernie az eszközöket, hogy a felmerülő teljesítményproblémákat kontextusba (IP-címek, eszköztípusok stb.) tudja helyezni.

    • A proxykiszolgálók jellemző kilépési pontok, ezért ellenőrizheti a webböngészőt, hogy ha használ proxykiszolgálót, melyik az.

    • Vannak független gyártók által fejlesztett eszközök, amelyek képesek felderíteni és feltérképezni a hálózatot, de a legpontosabb képet úgy kaphat az eszközökről, ha beszél a hálózatkezelő csapat egyik tagjával.

  • Azonosítsa az internetszolgáltatót, jegyezze fel a kapcsolattartási adataikat, és kérdezze meg, hány áramkör, mekkora sávszélesség áll cége rendelkezésére.

  • A cégén belül azonosítsa az ügyfélszámítógép és a kilépési pont közötti eszközök erőforrásait, vagy azonosítsa azt a kapcsolattartót, akihez vészhelyzet esetén a hálózati problémákkal fordulhat.

Íme néhány alapérték, amelyet a megfelelő céleszközökkel készített egyszerű tesztekkel kiszámíthat:

  • Az ügyfélszámítógép és a kilépési pont közötti út időtartama ezredmásodpercben

  • A kilépési pont és az Office 365 közötti út időtartama ezredmásodpercben

  • Az Office 365 URL-címeit böngészés közben feloldó kiszolgáló földrajzi helye

  • Az internetszolgáltató DNS-feloldási műveleteinek sebessége ezredmásodpercben, a csomagok érkezésének inkonzisztenciája (hálózati vibrálás), a feltöltési és letöltési sebesség ezredmásodpercben

Ha nem tudja pontosan, hogyan végezheti el ezeket a lépéseket, ebben a cikkben később részletesebb ismertetőt találhat.

Mit nevezünk alapértéknek?

Amikor rosszra fordulnak a dolgok, a hatás látható, de a korábbi teljesítményadatok ismerete nélkül nem lehet képet alkotni arról, hogy mennyire lett rosszabb a helyzet, és mikor. Alapértékek nélkül tehát hiányzik a megoldókulcs a rejtvényhez: a kirakós játék dobozán látható teljes kép. A teljesítményproblémák elhárításához szükség van egy összehasonlítási alapra. Az egyszerű teljesítménybeli alapértékek felvétele nem túl bonyolult feladat. Ezek ütemezett felvételével meg lehet bízni például az üzemeltetési részleget. Tegyük fel például, hogy az alábbi kapcsolatszerkezettel rendelkezik:

Egy alaphálózatot bemutató ábra, amelyen az ügyfél, a proxy és az Office 365 felhő látható.

Ez azt jelenti, hogy a hálózatkezelő csapattól megtudta, hogy a cég egy proxykiszolgálón keresztül kapcsolódik az internethez, és ez a proxykiszolgáló kezeli az ügyfélgépről a felhő felé küldött összes kérést. Ebben az esetben érdemes vázlatos rajzot készíteni a kapcsolatról, és berajzolni az összes közbenső eszközt. Azután tüntesse fel azokat az eszközöket, amelyekkel tesztelhető a teljesítmény az ügyfélgép, a kilépési pont (ahol elhagyja a hálózatot és kilép az internetre) és az Office 365-felhő között.

Ügyfélből, proxyból és felhőből álló alaphálózat, eszközjavaslatok (PSPing, TraceTCP) és hálózati nyomkövetések.

A lehetőségeket az Egyszerű és a Speciális kategóriába soroltuk aszerint, hogy mekkora szakértelem kell a teljesítményadatok megkereséséhez. A hálózati nyomkövetés rengeteg időt vesz igénybe a parancssori eszközök, például a PsPing és a TraceTCP futtatásához képest. Ezt a két parancssori eszközt azért választottuk, mert nem használnak ICMP-csomagokat, amelyeket az Office 365 letiltana, és mert ezredmásodpercben adják meg az ügyfélszámítógép vagy (ha van hozzáférése) a proxykiszolgáló és az Office 365 között megtett út időtartamát. Az egyik számítógépről a másikra történő ugrások mindegyikéhez tartozik egy időérték, ami az alapértékek szempontjából jó hír! Ugyanennyire fontos, hogy ezek a parancssori eszközök lehetővé teszik a portszám hozzáfűzését a parancshoz. Ez azért hasznos, mert az Office 365 a 443-as porton keresztül kommunikál, és ugyanezt a portot használja az SSL és a TLS protokoll is. Előfordulhat azonban, hogy más, független gyártók eszközei jobb megoldást kínálnak az adott helyzetben. A Microsoft nem támogatja az összes ilyen eszközt, ezért ha valamilyen okból a PsPing és a TraceTCP nem működne, futtasson hálózati nyomkövetést például a Netmon eszközzel.

Az alapértékeket gyűjtheti a munkaidő előtt, majd a legnagyobb eszközhasználat idején, végül munkaidő után. Ez esetben a művelet végén az alábbihoz hasonló mappaszerkezet alakul ki:

A teljesítményadatok mappákba rendezésének egy módját bemutató ábra

Egy elnevezési konvenciót is választania kell a fájlokhoz. Néhány példa:

  • 2015_febr_09_9deCET_TeljAlapérték_Netmon_Ügyfélgép-KilépésiPont_Normális

  • 2015_jan_10_3duCET_TeljAlapérték_PsPing_Ügyfélgép-O365_ProxytMegkerülve_LASSÚ

  • 2015_febr_08_2duCET_TeljAlapérték_GYENGETelj

  • 2015_febr_08_8-30deCET_TeljAlapérték_JÓTelj

Számtalan egyéb módszer létezik erre, de a <dateTime><what's happening in the test> formátum jó kiindulási alap. Ha a fenti módszereket szorgalmasan követi, nagy hasznára lehetnek, ha később hibaelhárításra kerül a sor. Akkor ugyanis elmondhatja, például, hogy február 8-án két hálózati nyomkövetést végzett, az egyik jó, a másik gyenge teljesítményt mutatott, így ezeket össze lehet hasonlítani. Ez rendkívül hasznos a hibaelhárításhoz.

A korábbi alapértékeket módszeresen kell tárolnia. A fenti példában az egyszerű módszerek három parancssori kimenetet adtak vissza, és az eredményeket képernyőképen tároltuk, de lehet, hogy eredményként hálózati rögzítési fájlok keletkeznek. Használja az Ön számára legjobb módszert. Mentse a korábbi alapértékeket, és vegye elő őket, ha az online szolgáltatások viselkedésében változásokat tapasztal.

Miért célszerű próbaüzem alatt teljesítményadatokat gyűjteni?

Az alapértékek gyűjtését legjobb az Office 365 próbaüzemében elkezdeni. Telephelyéhez tartozhat több ezer vagy több százezer felhasználó, vagy csak öt, de még kevés felhasználó esetén is végezhet teszteket a teljesítmény ingadozásának mérésére. Egy nagyvállalat esetén egy reprezentatív minta, amely az Office 365 próbaüzemében részt vevő néhány száz felhasználóra terjed ki, kivetíthető több ezer felhasználóra, és már előre tudható, hogy az esetleges problémák hol jelentkezhetnek, még mielőtt jelentkeznének.

Egy kis vállalat esetén, ahol a rendszerbe való felvétel azt jelenti, hogy minden felhasználó egy időben használja a szolgáltatást, és nincs is próbaüzem, azért célszerű teljesítményméréseket végezni, hogy legyen milyen adatokat bemutatni annak a személynek, aki esetleg majd egy gyenge teljesítmény hibaelhárításán dolgozni fog. Ha például egyszer csak azt veszi észre, hogy hirtelen tengernyi szabadideje támad egy közepes méretű rajz feltöltésekor, holott ez korábban pillanatok alatt lezajlott.

Hogyan gyűjthetők össze az alapértékek?

Minden hibaelhárítási tervben legalább az alábbi tényezőket azonosítani kell:

  • Melyik ügyfélgépet használta a felhasználó (a számítógép vagy eszköz típusa, IP-címe és a problémát okozó műveletek)

  • Földrajzilag hol helyezkedik el az ügyfélgép (például a felhasználó virtuális magánhálózattal kapcsolódik-e a cég hálózatához, távolról dolgozik vagy a céges intraneten)

  • Milyen kilépési pontot használ az ügyfélgép a hálózatról (a kilépési pont az a pont, ahol a forgalom elhagyja a céget az internetszolgáltató vagy az internet felé)

A hálózat elrendezését megkérdezheti a hálózati rendszergazdától. Ha kisméretű hálózatról van szó, vizsgálja meg az internethez kapcsolódó eszközöket, és hívja fel az internetszolgáltatót, ha bármilyen kérdése van az elrendezéssel kapcsolatban. Készítsen rajzot a végleges elrendezésről, és használja.

Ezt a szakaszt az egyszerű parancssori eszközökre, illetve módszerekre és a speciálisabb eszközök lehetőségeire bontottuk. Először az egyszerű módszerekkel foglalkozunk. Ha azonban éppen most küzd teljesítményproblémákkal, ugorjon a speciális módszerekre, és próbálja ki a teljesítményhibák elhárítására készített minta akciótervünket.

Egyszerű módszerek

Az alábbi egyszerű módszerekkel az a célunk, hogy bemutassuk, miként vehet fel, értelmezhet és tárolhat megfelelően egyszerű teljesítménybeli alapértékeket hosszabb időn keresztül, hogy képet alkothasson az Office 365 teljesítményéről. Íme a korábban megismert igen egyszerű diagram:

Ügyfélből, proxyból és felhőből álló alaphálózat, eszközjavaslatok (PSPing, TraceTCP) és hálózati nyomkövetések.

Megjegyzések: 

  • A képernyőképen a TraceTCP szerepel, mert nagyon hasznos eszköz: megmutatja (ezredmásodpercben), hogy mennyi ideig tart egy kérés feldolgozása, és hogy a kérés hány hálózati ugrással, azaz hány, számítógépek közötti kapcsolaton keresztül jut célba. A TraceTCP megadja az ugrásokhoz használt kiszolgálók nevét is, ami hasznos lehet a Microsoft Office 365 hibaelhárításával foglalkozó ügyfélszolgálati munkatárs számára.

  • A TraceTCP-parancsok rendkívül egyszerűek lehetnek, mint például az alábbi is:

  • tracetcp.exe outlook.office365.com:443

  • Ne felejtse el beírni a parancsba a portszámot!

  • TraceTCP ingyen letölthető, de működése a Wincapre támaszkodik. A Wincap eszközt a Netmon is használja és telepíti. A speciális módszereket ismertető szakaszban mi is használjuk majd a Netmont.

Ha több telephelye van, akkor az egyes helyeken lévő ügyfélgépekről külön adathalmazt kell vezetni. Ez a teszt a késést méri. Ebben az esetben ez egy olyan számérték, amely az ügyfélgép által az Office 365-nek küldött kérés és az Office 365 által erre adott válasz közötti időmennyiséget írja le. A tesztelés a telephely hálózatán egy ügyfélgépről indul ki, és a hálózaton belül a kilépési pontig, rajta keresztül az internetig, végül az Office 365-ig, majd onnan vissza, az ügyfélgépig tartó út időtartamát méri.

A kilépési ponttal, a fenti esetben a proxykiszolgálóval, többféleképpen lehet foglalkozni. Követheti az utat az 1-estől a 2-esig, majd a 2-estől a 3-asig, és a kapott értékeket összeadva megkaphatja a hálózat pereméig tartó út időtartamát ezredmásodpercben. Vagy beállíthatja a kapcsolatot úgy, hogy megkerülje a proxykiszolgálót az Office 365-ös címekig. Egy tűzfallal, fordított proxykiszolgálóval vagy a kettő valamilyen kombinációjával ellátott nagyobb hálózatban valószínűleg kivételeket kell beállítania a proxykiszolgálón, amely rengeteg URL forgalmát ereszti át. Az Office 365 által használt végpontok listáját megtalálhatja Az Office 365 URL-címei és IP-címtartományai című témakörben. Ha hitelesítési proxyt használ, kezdje az alábbiak kivételeinek tesztelésével:

  • 80-as és 443-as port

  • TCP- és HTTPs-forgalom

  • Az alábbi URL-ek felé kimenő kapcsolatok:

  • *.microsoftonline.com

  • *.microsoftonline-p.com

  • *.sharepoint.com

  • *.outlook.com

  • *.lync.com

  • osub.microsoft.com

Minden felhasználónak engedélyezni kell, hogy ezeket a címeket mindenféle proxykiszolgáló közbeiktatása vagy hitelesítés nélkül elérjék. Kisebb hálózaton ezeket a címeket vegye fel a proxymegkerülési listára a böngészőben.

Ehhez az Internet Explorerben kattintson az Eszközök > Internetbeállítások > Kapcsolatok > Helyi hálózati beállítások > Speciális gombra. A Speciális gombra kattintva megnyíló párbeszédpanelen megtalálható a proxykiszolgáló címe és portszáma is. Lehet, hogy a Speciális gomb aktiválásához előbb be kell jelölnie a Proxykiszolgáló használata a helyi hálózaton jelölőnégyzetet. Ügyeljen arra, hogy a Proxy figyelmen kívül hagyása helyi címeknél jelölőnégyzet be legyen jelölve. A Speciális gombra kattintva megjelenő mezőbe beírhatja a kivételeket. A fenti, helyettesítő karakterekkel megadott URL-eket pontosvesszővel válassza el egymástól, például így:

*.microsoftonline.com; *.sharepoint.com

A proxy megkerülése után a ping vagy a PsPing eszközt közvetlenül az Office 365-ös URL-eken használhatja. A következő tesztlépés az outlook.office365.com pingelése lesz. Ha a PsPing eszközt használja (vagy más olyan segédprogramot, amely lehetővé teszi a portszám megadását a parancsban), küldjön PsPing parancsot a portal.microsoftonline.com:443 címre, és megkapja az átlagos visszaérési időt ezredmásodpercben.

visszaérési idő az a számérték, amely megmutatja, mennyi ideig tart, amíg egy számítógép HTTP-kérést küld egy kiszolgálónak, például az outlook.office365.com-nak, és választ kap a kiszolgálótól, amely nyugtázza, hogy azonosította a kérést küldő gépet. A visszaérési időt gyakran az angol RTT (a.m. round trip time) rövidítés jelöli. Ennek viszonylag rövid időmennyiségnek kell lennie.

A tesztet a PSPing eszközzel vagy más olyan segédprogrammal végezze, amely nem használ ICMP-csomagokat, azokat ugyanis az Office 365 letiltja.

A PsPing használata az átlagos visszaérési idő ezredmásodpercben való mérésére közvetlenül egy Office 365-ös URL-címen

  1. Az alábbi lépésekkel futtasson rendszergazda jogú parancssort:

    1. Kattintson a Start gombra.

    2. Keresés megkezdése mezőbe írja be a cmd karaktereket, és nyomja le a CTRL+SHIFT+ENTER billentyűkombinációt.

    3. Ha megjelenik a Felhasználói fiókok felügyelete párbeszédpanel, erősítse meg, hogy a megjelenített műveletet szeretné futtatni, és kattintson a Folytatás gombra.

  2. Lépjen abba a mappába, amelyben az eszköz (jelen esetben a PsPing) telepítve van, és tesztelje az alábbi Office 365-ös URL-címeket:

    • psping portal.office.com:443

    • psping microsoft-my.sharepoint.com:443

    • psping outlook.office365.com:443

    • psping www.yammer.com:443

      A microsoft-my.sharepoint.com 443-as portjához küldött PSPing parancs

A 443-as portszámot feltétlenül adja meg. Ne feledje, hogy az Office 365 titkosított csatornán keresztül működik. Ha a PsPinget portszám nélkül használja, a kérés sikertelen lesz. Miután a rövid listán szereplő összes címet pingelte, nézze meg az ezredmásodpercben mért átlagidőt (a kimenet „Average” értéke). Ez az, amit keresett!

Az ügyféltől a proxyhoz küldött PSPing parancsot bemutató ábra 2,8 ezredmásodperces üzenetváltási idővel

Ha még nem jártas a proxymegkerülésben, és szívesebben végzi el lépésenként a műveletet, előbb meg kell állapítania a proxykiszolgáló nevét. Az Internet Explorerben kattintson az Eszközök > Internetbeállítások > Kapcsolatok > Helyi hálózati beállítások > Speciális gombra. A proxykiszolgáló a Speciális gombra kattintva megnyíló párbeszédpanelen látható. Az alábbi művelettel a parancssorból pingelje ezt a proxykiszolgálót:

A proxykiszolgáló pingelése és a visszaérési érték (RTT) mérése ezredmásodpercben az 1-es és 2-es eszköz között

  1. Az alábbi lépésekkel futtasson rendszergazda jogú parancssort:

    1. Kattintson a Start gombra.

    2. Keresés megkezdése mezőbe írja be a cmd karaktereket, és nyomja le a CTRL+SHIFT+ENTER billentyűkombinációt.

    3. Ha megjelenik a Felhasználói fiókok felügyelete párbeszédpanel, erősítse meg, hogy a megjelenített műveletet szeretné futtatni, és kattintson a Folytatás gombra.

  2. Írja be a ping <a böngésző által használt proxykiszolgáló neve vagy IP-címe> parancsot, és nyomja le az ENTER billentyűt. Ha a PsPing vagy valamilyen más eszköz van telepítve, használhatja azt is.

    A parancs az alábbi példák egyikére fog hasonlítani:

    • ping miproxynk.mitartomanyunk.iparag.ceg.com

    • ping 155.55.121.55

    • ping miproxynk

    • ping miproxynk.mitartomanyunk.iparag.ceg.com:80

    • psping 155.55.121.55:80

    • psping miproxynk:80

  3. Amikor a nyomkövetés már nem küld több tesztcsomagot, megjelenik egy kis összefoglalás, amelyben megtalálható az átlagidő értéke ezredmásodpercben, és pontosan ezt kerestük. Készítsen képernyőképet a parancsablakról, és saját elnevezési konvenciója szerint mentse. Ezen a ponton az is segíthet, ha az értéket felviszi a diagramra.

Lehet, hogy kora reggel már futtatott egy nyomkövetést, és az ügyfélgép gyorsan eljut a proxykiszolgálóhoz (vagy más típusú kilépési ponthoz, amely az internetre vezet). Ez esetben a kapott értékek az alábbiakhoz hasonlók lehetnek:

Az ügyfél és a proxy közötti 2,8 ezredmásodperces üzenetváltási időt mutató ábra

Ha a szóban forgó ügyfélgép azon néhány kiváltságos gép egyike, amelynek hozzáférése van a proxykiszolgálóhoz (vagy a kilépési ponthoz), futtathatja a teszt következő fázisát: távolról csatlakozzon ehhez a számítógéphez, és futtassa róla a PsPing parancsot az egyik Office 365-ös URL-en a parancssorból. Ha nincs hozzáférése ehhez a számítógéphez, kérheti a hálózatkezelők segítségét a következő fázishoz, és tőlük megkaphatja a pontos értékeket. Ha ez nem lehetséges, futtassa a PsPing parancsot a kérdéses Office 365-ös URL-címen, és hasonlítsa össze azzal az időértékkel, amelyet a PsPing vagy a Ping eszköz adott vissza a proxykiszolgáló esetében.

Ha például az ügyfélgép és az Office 365-ös URL közötti út 51,84 ezredmásodpercig tartott, az ügyfélgép és a proxykiszolgáló (vagy kilépési pont) közötti út pedig 2,8 ezredmásodpercig, akkor a kilépési ponttól az Office 365-ig 49,04 ezredmásodperccel kell számolni. Hasonlóképpen ha a PsPing eszközzel 12,25 ezredmásodpercet mért csúcsidőben az ügyfélgép és a proxykiszolgáló között, és 62,01 ezredmásodpercet az ügyfélgép és az Office 365-ös URL között, akkor a proxykiszolgáló (kilépési pont) és az Office 365-ös URL közötti út időtartama átlagosan 49,76 ezredmásodperc.

Ez az ábra a pingelést illusztrálja ezredmásodpercben az ügyféltől a proxyig, és az ügyféltől az Office 365-ig, így az értékek kivonhatók egymásból

A hibaelhárítás szempontjából már ezen alapértékek megőrzéséből is érdekes dolgok derülhetnek ki. Ha például úgy találja, hogy általában 40–59 ezredmásodperc késés van a proxykiszolgáló (vagy kilépési pont) és az Office 365-ös URL között, míg az ügyfélgép és a proxy (vagy kilépési pont) között a késés kb. 3–7 ezredmásodperc (az adott napszakban tapasztalt hálózati forgalomtól függően), akkor minden bizonnyal észre fogja venni, hogy valami nem tökéletes, ha az ügyfélgép és a proxy (kilépési pont) közötti utolsó három alapérték 45 ezredmásodperces késést mutat.

Speciális módszerek

Ha igazán tudni szeretné, hogy mi történik az internetes kérésekkel az Office 365 eléréséig, meg kell ismerkednie a hálózati nyomkövetéssel. A nyomkövetéshez tetszőleges eszközt használhat (HTTPWatch, Netmon, Message Analyzer, Wireshark, Fiddler, Developer Dashboard), ha az képes a hálózati forgalmat rögzíteni és szűrni. Ebben a szakaszban látni fogja, hogy a probléma minél teljesebb felmérése érdekében célszerű több ilyen eszközt futtatni. Teszteléskor némelyik eszköz saját jogon proxyként is működik. A Teljesítményhiba-elhárítási terv az Office 365-höz című cikkben használt eszközök közé tartoznak a következők: Netmon 3.4, HTTPWatch és WireShark.

A teljesítményre vonatkozó alapértékek felvétele az egyszerűbb része ennek a módszernek, és sok lépése megegyezik a teljesítményproblémák elhárításakor elvégzendőkkel. A teljesítménybeli alapértékek előállításának speciálisabb módszerei megkövetelik hálózati nyomkövetési naplók készítését és tárolását. A cikkben a legtöbb példához a SharePoint Online szolgáltatást használjuk, de alakítson ki egy listát azokból a gyakori műveletekből az előfizetett Office 365-ös szolgáltatások között, amelyeket tesztelni és rögzíteni szeretne. Az alábbiakban példát találhat az alapértékek felvételére:

  • Alapértéklista a SharePoint Online-hoz – 1. lépés: Tallózással nyissa meg a SharePoint Online kezdőlapját, és futtasson hálózati nyomkövetést. Mentse az eredményt.

  • Alapértéklista a SharePoint Online-hoz – 2. lépés: A vállalati keresőn keresztül keressen rá egy kifejezésre (például cége nevére), és futtasson hálózati nyomkövetést. Mentse az eredményt.

  • Alapértéklista a SharePoint Online-hoz – 3. lépés: Töltsön fel egy nagyméretű fájlt a SharePoint Online egyik dokumentumtárába, és futtasson hálózati nyomkövetést. Mentse az eredményt.

  • Alapértéklista a SharePoint Online-hoz – 4. lépés: Tallózással nyissa meg a OneDrive-webhely kezdőlapját, és futtasson hálózati nyomkövetést. Mentse az eredményt.

A listának tartalmaznia kell azokat a legfontosabb általános műveleteket, amelyeket a felhasználók a SharePoint Online-on futtatnak. Figyelje meg, hogy az utolsó lépés, a OneDrive Vállalati verzió elérésének követése, összehasonlítási alapot teremt a SharePoint Online kezdőlapjának és a OneDrive Vállalati verzió kezdőlapjának betöltése között (az előbbit a cégek gyakran testre szabják, míg az utóbbit csak ritkán). Ez a teszt nagyon alapvető, amikor a SharePoint Online-webhely betöltésének lassúságáról van szó. A különbségről készült rekordot beépítheti a tesztelés folyamatába.

Ha éppen egy teljesítményprobléma kellős közepén van, akkor jó tudni, hogy ezek a lépések jó részt megegyeznek az alapértékek felvételének lépéseivel. A hálózati nyomkövetések kritikus fontosságúak, ezért a következőkben azzal foglalkozunk, hogy miként állíthatók elő a fontos nyomkövetési naplók.

A teljesítményprobléma megragadásához, most, készítenie kell egy nyomkövetési naplót abban az időben, amikor a teljesítményprobléma tapasztalható. Kéznél kell lennie a naplóadatok összegyűjtésére szolgáló megfelelő eszközöknek, és szüksége lesz egy akciótervre, azaz olyan elvégzendő hibaelhárítási műveletekre, amelyekkel a lehető legjobb információkat gyűjtheti be. Mindenekelőtt rögzítse a teszt dátumát és időpontját, hogy a fájlokat egy, az időpontokat feltüntető mappába menthesse. Ezután magukra a problémát előidéző lépésekre figyeljen. Ezek azok a lépések, amelyeket a teszteléskor használni fog. Ne felejtse el az alapokat: ha a probléma csak az Outlookkal áll fenn, feltétlenül rögzítse, hogy a problematikus működés csak egyetlen Office 365-ös szolgáltatást érint. A probléma hatókörének szűkítése segítséget nyújthat abban, hogy a megoldható dolgokra összpontosítsa a figyelmét.

Lásd még

Az Office 365-végpontok kezelése

Ismeretek bővítése
Oktatóanyagok megismerése
Új szolgáltatások listájának lekérése
Részvétel az Office Insider programban

Hasznos volt az információ?

Köszönjük a visszajelzését!

Köszönjük visszajelzését. Jobbnak látjuk, ha az Office egyik támogatási szakemberéhez irányítjuk.

×