A teljesítmény finomhangolásának Office 365 alaptervek és teljesítményelőzmények használatával

A Office 365 és a vállalat közötti kapcsolati teljesítmény ellenőrzésének néhány egyszerű módja lehetővé teszi a kapcsolat alapkonfigurációjának kialakítását. Az ügyfélszámítógép-kapcsolatok teljesítményelőzményeinek ismerete segíthet a felmerülő problémák korai észlelésében, a problémák azonosításában és előrejelzésében.

Ha nincs hozzászokva a teljesítményproblémákhoz, ez a cikk segít megfontolni néhány gyakori kérdést. Honnan tudja, hogy a tapasztalt probléma teljesítménybeli probléma, nem pedig Office 365 szolgáltatási incidens? Hogyan tervezhet jó teljesítményt, hosszú távon? Hogyan lehet szemmel tartani a teljesítményt? Ha csapata vagy ügyfelei lassú teljesítményt tapasztalnak a Office 365 használata során, és kíváncsi ezekre a kérdésekre, olvasson tovább.

Fontos

Jelenleg teljesítményproblémája van az ügyfél és a Office 365 között? Kövesse az Office 365 teljesítményével kapcsolatos hibaelhárítási tervben ismertetett lépéseket.

Valami, amit tudnia kell Office 365 teljesítményről

Office 365 egy nagy kapacitású, dedikált Microsoft-hálózaton belül található, amelyet az automatizálás és a valós személyek figyelnek. A Office 365 felhő karbantartásának része a teljesítmény finomhangolása és ahol lehetséges, a streamelés. Mivel a Office 365 felhő ügyfeleinek az interneten keresztül kell csatlakozniuk, folyamatosan törekszünk arra, hogy finomhangoljuk Office 365 szolgáltatások teljesítményét is.

A teljesítménybeli fejlesztések soha nem állnak meg igazán a felhőben, így a felhő kifogástalan állapotának és gyors állapotának megőrzésével sem járnak együtt. Ha teljesítményproblémája van a helyről a Office 365 való csatlakozáskor, a legjobb, ha nem egy támogatási esettel kezd, vagy nem vár. Ehelyett érdemes "belülről" kezdenie a probléma kivizsgálását. Vagyis kezdje a hálózatán belül, és lépjen ki a Office 365. Mielőtt megnyit egy esetet az ügyfélszolgálatnál, adatokat gyűjthet, és műveleteket végezhet, amelyek feltárják és megoldhatják a problémát.

Fontos

Vegye figyelembe a kapacitástervezést és a Office 365 korlátait. Ez az információ a teljesítményprobléma megoldásakor a görbe élére kerül. Íme egy hivatkozás a Microsoft 365 és Office 365 szolgáltatás leírására. Ez egy központi központ, és az Office 365 által kínált összes szolgáltatás rendelkezik egy hivatkozással, amely innen a saját szolgáltatásleírásaikra vezet. Ez azt jelenti, hogy ha meg kell tekintenie például a SharePoint Online standard korlátait, kattintson a SharePoint Online szolgáltatás leírása elemre, és keresse meg a SharePoint Online korlátai szakaszt.

Győződjön meg arról, hogy a hibaelhárítás során tisztában van azzal, hogy a teljesítmény csúszós léptékű. Nem arról van szó, hogy egy idealizált értéket érünk el, és folyamatosan fenntartjuk azt. Az olyan nagy sávszélességű feladatok, mint a nagy számú felhasználó beszállása vagy a nagy adatmigrálások elvégzése stresszesek lesznek, ezért tervezze meg a teljesítményre gyakorolt hatásokat. A teljesítménycélokról hozzávetőleges képet kell adnia, de számos változó játszik szerepet a teljesítményben, így a teljesítmény változó.

A teljesítménnyel kapcsolatos hibaelhárítás nem az adott célok eléréséről és a számok határozatlan időre történő fenntartásáról szól, hanem a meglévő tevékenységek fejlesztéséről, az összes változó figyelembe véve.

Oké, hogyan néz ki egy teljesítményprobam?

Először győződjön meg arról, hogy a tapasztalt problémák valóban teljesítményproblémák, és nem szolgáltatási incidensek. A teljesítményproblémák eltérnek a Office 365 szolgáltatáseseményeitől. Így lehet megkülönböztetni őket egymástól.

Szolgáltatási incidensek akkor fordulnak elő, ha a Office 365 szolgáltatásban problémák lépnek fel. A Microsoft 365 Felügyeleti központ Aktuális állapot területén piros vagy sárga ikonok jelenhetnek meg. Azt tapasztalhatja, hogy a Office 365 csatlakozó ügyfélszámítógépek teljesítménye lassú. Ha például az Aktuális állapot egy piros ikont jelent, és a Vizsgálat az Exchange mellett látható, akkor a szervezet azon tagjaitól is kaphat hívásokat, akik arra panaszkodnak, hogy a Exchange Online használó ügyfélpostaládák lassúak. Ebben az esetben ésszerű azt feltételezni, hogy a Exchange Online teljesítménye szolgáltatásproblémák áldozata volt.

Ekkor a Office 365 rendszergazdájának ellenőriznie kell az Aktuális állapotot, majd gyakran meg kell tekintenie a részleteket és az előzményeket, hogy naprakészen tarthassa a rendszer karbantartását. Az Aktuális állapot irányítópulton frissítheti a szolgáltatás módosításait és problémáit. Az állapotelőzményekbe írt megjegyzések és magyarázatok, a rendszergazda és a rendszergazda, segítenek felmérni, és folyamatosan közzétenni a folyamatban lévő munkát.

A teljesítményproblémák nem szolgáltatási incidensek, annak ellenére, hogy az incidensek lassú teljesítményt okozhatnak. A teljesítményproblémák a következőképpen néznek ki:

• Teljesítményproblémák lépnek fel, függetlenül attól, hogy mit jelent a felügyeleti központ A szolgáltatás aktuális állapota .

• A folyamathoz használt viselkedés végrehajtása hosszú időt vesz igénybe, vagy soha nem fejeződik be.

• A problémát replikálhatja is, vagy tudja, hogy a probléma akkor fordul elő, ha a megfelelő lépéseket hajtja végre.

• Ha a probléma időszakos, akkor is előfordulhat minta. Tudja például, hogy reggel 10:00-ig olyan felhasználók hívásai lesznek, akik nem mindig férnek hozzá Office 365. A hívások dél körül érnek véget.

Ez a lista valószínűleg ismerősnek hangzik; talán túl ismerős. Ha már tudja, hogy teljesítményproblémáról van szó, a kérdés a következő lesz: "Mi a következő lépés?" A cikk további része segít pontosan meghatározni ezt.

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

A teljesítményproblémák gyakran idővel jelentkeznek, ezért nehéz lehet meghatározni a tényleges problémát. Hozzon létre egy jó problémaleírást, amely jó képet ad a probléma kontextusáról, majd ismételhető tesztelési lépéseket kell végrehajtania. Íme néhány példa azokra a problémákra vonatkozó utasításokra, amelyek nem biztosítanak elegendő információt:

• A Beérkezett üzenetek mappáról a naptárra váltás korábban olyan dolog volt, amit nem vettem észre, és most kávészünet van. Meg tudod tenni, hogy úgy viselkedjen, mint régen?

• A fájlok SharePoint Online-ba való feltöltése örökké tart. Miért lassú délután, de máskor gyors? Nem lehet gyors?

A fenti problémameghívók számos nagy kihívást jelentenek. Pontosabban, túl sok kétértelműséget kell kezelni. Például:

• Nem világos, hogyan váltott a Beérkezett üzenetek és a Naptár között a laptopon való működéshez.

• Amikor a felhasználó azt mondja: "Nem lehet csak gyors", mi a "gyors"?

• Mennyi ideig tart az "örökké"? Ez több másodperc? Vagy sok percet? Vagy a felhasználó ebédelhet, és a művelet 10 perccel a visszatérés után befejeződik?

A rendszergazda és a hibaelhárító nem tudhatja meg a probléma részleteit az ilyen általános utasításokból. Nem tudják például, hogy mikor jelentkezett a probléma. Előfordulhat, hogy a hibaelhárító nem tudja, hogy a felhasználó otthonról dolgozik, és csak az otthoni hálózatán tapasztal lassú váltást. Vagy azt, hogy a felhasználó más, RAM-igényes alkalmazásokat futtat a helyi ügyfélen. Előfordulhat, hogy a rendszergazdák nem tudják, hogy a felhasználó régebbi operációs rendszert futtat, vagy nem futtatta a legutóbbi frissítéseket.

Amikor a felhasználók teljesítményproblémát jelentenek, sok információt kell összegyűjteni. Az információk lekérését és rögzítését a probléma hatókörkezelésének nevezzük. Íme egy alapszintű hatókörkezelési lista, a segítségével adatokat gyűjthet a teljesítményproblémákról. Ez a lista nem teljes, de érdemes elkezdeni:

• Mikor jelentkezett a probléma, és milyen időpontban történt a nap vagy az éjszaka?

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

• Távolról dolgozott, vagy az irodában volt?

• Próbálkozott ugyanezekkel a műveletekkel egy másik számítógépen, és ugyanezt a viselkedést látta?

• Haladjon végig a problémákat okozó lépéseken, hogy megírhassa a végrehajtott műveleteket.

• Mennyire lassú másodpercek vagy percek alatt a teljesítmény?

• Hol van a világon?

Néhány ilyen kérdés nyilvánvalóbb, mint mások. A legtöbben tisztában lesznek azzal, hogy a hibaelhárítónak pontosan meg kell tennie a szükséges lépéseket a probléma reprodukálásához. Végül is, hogyan rögzítheti még a hibát, és hogyan tesztelheti, hogy a probléma megoldódott-e? Kevésbé nyilvánvalóak az olyan dolgok, mint a "Milyen dátum és idő látta a problémát?", és "Hol található a világon?", a tandemben használható információk. Attól függően, hogy a felhasználó mikor dolgozott, néhány óra eltérés azt jelentheti, hogy a karbantartás már folyamatban van a vállalati hálózat egyes részein. A vállalatnak például van egy hibrid implementációja, például egy hibrid SharePoint Search, amely le tudja kérdezni a sharepoint online és a helyszíni SharePoint Server 2013-példány keresési indexeit, előfordulhat, hogy a helyszíni farmon frissítések vannak folyamatban. Ha a vállalata a felhőben van, a rendszerkarbantartás magában foglalhatja a hálózati hardverek hozzáadását vagy eltávolítását, a vállalati szintű frissítések telepítését, a DNS vagy más alapvető infrastruktúra módosítását.

Teljesítményproblémák elhárításakor ez egy kicsit olyan, mint egy bűnügyi helyszín, pontosnak és figyelmesnek kell lennie ahhoz, hogy következtetéseket vonjon le a bizonyítékokból. Ehhez egy jó problémaleírást kell kapnia a bizonyítékok összegyűjtésével. Tartalmaznia kell a számítógép környezetét, a felhasználó környezetét, a probléma kezdetének időpontját, valamint a teljesítményproblémát feltáró pontos lépéseket. Ennek a problémaleírásnak a jegyzetei legfelső oldalának kell lennie, és meg kell maradnia. Miután a megoldáson végzett munka után ismét végiglépked a problémaleíráson, lépéseket tesz annak tesztelésére és bizonyítására, hogy a végrehajtott műveletek megoldották-e a problémát. Ez kritikus fontosságú annak ismerete szempontjából, hogy a munka, ott, befejezve.

Tudja, milyen volt a teljesítmény, amikor jó volt?

Ha szerencsétlen vagy, senki sem tudja. Senkinek sem voltak számai. Ez azt jelenti, hogy senki sem tud válaszolni az egyszerű kérdésre: "Hány másodpercig tartott a Beérkezett üzenetek mappa létrehozása a Office 365?", vagy "Mennyi ideig tartott, amíg a vezetők Lync Online-értekezletet folytattak?", ami sok vállalatnál gyakori forgatókönyv.

Mi hiányzik a teljesítmény alapkonfigurációjából?

Az alaptervek kontextust biztosítanak a teljesítményhez. Az alapkonfigurációt időnként gyakran kell elvégeznie a vállalat igényeitől függően. Ha Ön nagyobb vállalat, előfordulhat, hogy az üzemeltetési csapat már figyelembe veszi a helyszíni környezet alapterveit. Ha például a hónap első hétfőjén az összes Exchange-kiszolgálót, a harmadik hétfőn pedig az összes SharePoint-kiszolgálót javítja, akkor az üzemeltetési csapat valószínűleg rendelkezik a javítást követően futtatott feladatok és forgatókönyvek listájával, amelyek bizonyítják, hogy a kritikus funkciók működőképesek. Nyissa meg például a Beérkezett üzenetek mappát, kattintson a Küldés/fogadás gombra, és győződjön meg arról, hogy a mappák frissülnek, vagy a SharePointban a webhely főoldalát böngészi, a vállalati keresés lapra lép, és végrehajt egy keresést, amely eredményeket ad vissza.

Ha az alkalmazások Office 365 vannak, a legalapvetőbb alapkonfigurációk közül néhányat mérhet a hálózaton belüli ügyfélszámítógéptől a kimenő forgalomig vagy a hálózati kilépési pontig eltelt időt (ezredmásodpercben), illetve azt a pontot, ahol elhagyja a hálózatot, és kimegy a Office 365. Íme néhány hasznos alapkonfiguráció, amelyeket megvizsgálhat és rögzíthet:

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

  • Ismernie kell az eszközöket, hogy a felmerülő teljesítményproblémák kontextusa (IP-címek, eszköz típusa, stb.) legyen.

  • A proxykiszolgálók gyakori kimenő pontok, így ellenőrizheti a webböngészőben, hogy melyik proxykiszolgálót használja, ha van ilyen.

  • Vannak olyan külső eszközök, amelyek képesek felderíteni és leképezni a hálózatot, de az eszközök megismerésének legbiztonságosabb módja, ha megkéri a hálózati csapat egy tagját.

• Azonosítsa az internetszolgáltatót, jegyezze fel a kapcsolattartási adatait, és kérdezze meg, hogy hány kapcsolatcsoportnak mekkora sávszélessége van.

• A vállalaton belül azonosítsa az ügyfél és a kilépési pont közötti eszközök erőforrásait, vagy egy vészhelyzeti kapcsolattartót, amellyel hálózatkezelési problémákról beszélhet.

Íme néhány alapkonfiguráció, amelyeket az eszközökkel végzett egyszerű teszteléssel kiszámíthat:

• Az ügyfélszámítógéptől a kilépési pontig eltelt idő ezredmásodpercben

• A kilépési pont és a Office 365 közötti idő ezredmásodpercben

• A tallózáskor Office 365 URL-címeit feloldó kiszolgáló világának helye

• Az isp DNS-feloldásának sebessége ezredmásodpercben, inkonzisztenciák a csomagérkezésben (hálózati jitter), feltöltési és letöltési idő ezredmásodpercben

Ha nem tudja, hogyan hajthatja végre ezeket a lépéseket, ebben a cikkben részletesebben is olvashat.

Mi az az alapkonfiguráció?

Tudni fogja, hogy milyen hatással jár, ha rosszra fordulnak, de ha nem ismeri az előzmény teljesítményadatait, nem lehet kontextust adni arról, hogy milyen rosszak lettek, és mikor. Tehát alapkonfiguráció nélkül hiányzik a kulcs nyom a puzzle megoldásához: a kép a puzzle dobozán. A teljesítménnyel kapcsolatos hibaelhárításhoz összehasonlítási pontra van szükség. Az egyszerű teljesítménykonfigurációkat nem nehéz elvégezni. Az üzemeltetési csapat feladata, hogy ezeket ütemezés szerint hajtsa végre. Tegyük fel például, hogy a kapcsolat a következőképpen néz ki:

Ez azt jelenti, hogy ellenőrizte a hálózati csapatát, és megtudta, hogy egy proxykiszolgálón keresztül elhagyja a vállalatot az internetre, és ez a proxy kezeli az ügyfélszámítógép által a felhőbe küldött összes kérést. Ebben az esetben meg kell rajzolnia a kapcsolat egyszerűsített verzióját, amely felsorolja az összes beavatkozó eszközt. Most szúrjon be eszközöket, amelyekkel tesztelheti a teljesítményt az ügyfél, a kimenőforgalom-pont (ahol elhagyja a hálózatot az internetre) és a Office 365 felhő között.

A beállítások egyszerűként és speciálisként jelennek meg, mivel a teljesítményadatok megkereséséhez szükséges szakértelem szükséges. A hálózati nyomkövetés sok 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 a Office 365 blokkol, és mivel ezredmásodpercben megadnak egy időt az ügyfélszámítógép vagy a proxykiszolgáló elhagyásához (ha van hozzáférése), és megérkeznek a Office 365. Minden egyes ugrás az egyik számítógépről a másikra időértékkel végződik, és ez nagyszerű az alapkonfigurációkhoz! Akárcsak fontos, ezek a parancssori eszközök lehetővé teszik a portszám hozzáadását a parancshoz, ez azért hasznos, mert Office 365 a 443-as porton keresztül kommunikál, amely a Secure Sockets Layer és a Transport Layer Security (SSL és TLS) által használt port. Más külső eszközök azonban jobb megoldást jelenthetnek az Ön helyzetére. A Microsoft nem támogatja ezeket az eszközöket, ezért ha valamilyen okból nem tudja működésbe léptetni a PsPinget és a TraceTCP-t, lépjen tovább egy hálózati nyomkövetésre egy olyan eszközzel, mint a Netmon.

Az alapkonfigurációt munkaidő előtt, nagy igénybevétel esetén, majd munkaidő után is elvégezheti. Ez azt jelenti, hogy a mappastruktúra a végén egy kicsit így néz ki:

A fájlok elnevezési konvencióját is meg kell adnia. Néhány példa:

• Feb_09_2015_9amPST_PerfBaseline_Netmon_ClientToEgress_Normal

• Jan_10_2015_3pmCST_PerfBaseline_PsPing_ClientToO365_bypassProxy_SLOW

• Feb_08_2015_2pmEST_PerfBaseline_BADPerf

• Feb_08_2015_8-30amEST_PerfBaseline_GoodPerf

Ennek számos különböző módja van, de a dateTime><formátum< használata, ami a tesztben> történik, jó kiindulópont. Ha szorgalmasan kezeli ezt a problémát, az sokat segít, ha később megpróbál hibaelhárítást végezni. Később azt fogja mondani, hogy "február 8-án két nyomra bukkantam, az egyik jó teljesítményt mutatott, az egyik rosszat mutatott, így összehasonlíthatjuk őket". Ez hasznos a hibaelhárításhoz.

A korábbi alapkonfigurációk megőrzéséhez szervezett módon kell rendelkeznie. Ebben a példában az egyszerű metódusok három parancssori kimenetet hoztak létre, és az eredményeket képernyőképekként gyűjtöttük össze, de előfordulhat, hogy ehelyett hálózati rögzítési fájlokkal rendelkezik. Használja az Önnek legmegfelelőbb módszert. Tárolja a korábbi alapterveket, és hivatkozzon rájuk olyan helyeken, ahol változásokat tapasztal a online szolgáltatások viselkedésében.

Miért érdemes teljesítményadatokat gyűjteni próbaüzem közben?

Nincs jobb idő az alapkonfigurációk elkészítésére, mint a Office 365 szolgáltatás próbaüzeme során. Előfordulhat, hogy az irodája több ezer felhasználóval, több százezerrel vagy öttel rendelkezik, de még néhány felhasználó esetén is elvégezhet teszteket a teljesítmény ingadozásának mérésére. Egy nagyvállalat esetében egy több száz felhasználóból álló reprezentatív minta, amely Office 365 próbaüzembe lép, kifelé több ezerre vetítheti, hogy tudja, hol merülhetnek fel problémák, mielőtt bekövetkeznének.

Egy kisvállalat esetében, ahol a beszállás azt jelenti, hogy minden felhasználó egyszerre jár a szolgáltatásba, és nincs próbaüzem, tartsa meg a teljesítménymutatókat, hogy azok az adatok jelenjenek meg, akiknek esetleg egy rosszul teljesítő művelet hibaelhárítására van szükség. Ha például azt veszi észre, hogy hirtelen körbesétálhat az épület körül, amíg feltölt egy közepes méretű ábrát, ahol korábban gyorsan előfordult.

Alaptervek gyűjtése

Az összes hibaelhárítási tervhez legalább az alábbi elemeket kell azonosítania:

• A használt ügyfélszámítógép (a számítógép vagy eszköz típusa, egy IP-cím és a problémát okozó műveletek)

• Az ügyfélszámítógép helye a világon (például hogy ez a felhasználó VPN-kapcsolaton keresztül csatlakozik-e a hálózathoz, távolról dolgozik vagy a vállalati intraneten)

• Az ügyfélszámítógép által a hálózatról használt kimenő forgalmi pont (az a pont, ahol a forgalom elhagyja a vállalatot egy internetszolgáltató vagy az internet számára)

A hálózat elrendezését a hálózati rendszergazdától tudja meg. Ha kis hálózattal rendelkezik, tekintse meg az internethez csatlakozó eszközöket, és hívja fel az internetszolgáltatót, ha kérdése van az elrendezéssel kapcsolatban. Hozzon létre egy ábrát a referencia végleges elrendezéséről.

Ez a szakasz egyszerű parancssori eszközökre és metódusokra, valamint speciálisabb eszközökre van felosztva. Először az egyszerű módszerekkel foglalkozunk. Ha azonban jelenleg teljesítményproblémája van, ugorjon a speciális módszerekre, és próbálja ki a teljesítmény-hibaelhárítási minta cselekvési tervet.

Egyszerű metódusok

Ezeknek az egyszerű módszereknek a célja, hogy megtanulja az egyszerű teljesítménybeli alapkonfigurációk időbeli értelmezését és megfelelő tárolását, hogy értesüljön Office 365 teljesítményről. Az alábbi egyszerű diagram egyszerű, ahogy azt korábban is láthatta:

Megjegyzés:

A TraceTCP azért jelenik meg ebben a képernyőképen, mert ezredmásodpercben mutatja be, hogy mennyi ideig tart egy kérés feldolgozása, és hány hálózati ugrást vagy kapcsolatot használ az egyik számítógépről a másikra, hogy a kérés elérje a célhelyet. A TraceTCP az ugrások során használt kiszolgálók nevét is megadhatja, ami hasznos lehet egy Microsoft Office 365 hibaelhárító számára a támogatásban. > A TraceTCP-parancsok nagyon egyszerűek lehetnek, például: >tracetcp.exe outlook.office365.com:443> Ne felejtse el belefoglalni a portszámot a parancsba! >A TraceTCP egy ingyenes letöltés, de a Wincapre támaszkodik. A Wincap egy olyan eszköz, amelyet a Netmon is használ és telepít. A Speciális metódusok szakaszban a Netmonot is használjuk.

Ha több irodája is van, az ügyféltől származó adatokat is meg kell őriznie mindegyik helyen. Ez a teszt a késést méri, amely ebben az esetben egy számérték, amely azt az időtartamot írja le, amellyel egy ügyfél kérést küld a Office 365, és Office 365 válaszol a kérésre. A tesztelés egy ügyfélszámítógép tartományából származik, és a hálózaton belülről, egy kimenő ponton keresztül, az interneten keresztül a Office 365 és vissza irányuló körbejárás mérésére szolgál.

Többféleképpen is kezelhető a kimenő forgalom, ebben az esetben a proxykiszolgáló. A nyomkövetést 1 és 2, majd 2 és 3 között végezheti el, majd ezredmásodpercben adja hozzá a számokat, hogy a hálózat széléhez érhesse a végső összeget. Vagy úgy is konfigurálhatja a kapcsolatot, hogy megkerülje a proxyt Office 365 címekhez. Egy tűzfallal, fordított proxyval vagy a kettő valamilyen kombinációjával rendelkező nagyobb hálózatban előfordulhat, hogy kivételeket kell tennie a proxykiszolgálón, amely lehetővé teszi a forgalom áthaladását sok URL-cím esetében. A Office 365 által használt végpontok listájáért lásd: Office 365 URL-címek és IP-címtartományok. Ha hitelesítési proxyval rendelkezik, először tesztelje a következő kivételeket:

• 80-at és 443-at

• TCP és HTTP-k

• A következő URL-címek bármelyikére kimenő kapcsolatok:

• *.microsoftonline.com

• *.microsoftonline-p.com

• *.sharepoint.com

• *.outlook.com

• *.lync.com

• osub.microsoft.com

Minden felhasználónak engedélyeznie kell, hogy proxyinterferencia vagy hitelesítés nélkül érje el ezeket a címeket. Kisebb hálózat esetén ezeket a böngészőben kell hozzáadnia a proxy megkerülő listájához.

Az Internet Explorerben a proxy megkerülési listájához való hozzáadásához lépjen az Eszközök>Internetbeállítások>Kapcsolatok>LAN-beállítások>Speciális területre. A speciális lapon található a proxykiszolgáló és a proxykiszolgáló portja is. Előfordulhat, hogy a Speciális gomb eléréséhez a Proxykiszolgáló használata a lan-hoz jelölőnégyzetre kell kattintania. Győződjön meg arról, hogy a Proxykiszolgáló megkerülése a helyi címekhez jelölőnégyzet be van jelölve. Ha a Speciális gombra kattint, megjelenik egy szövegmező, amelyben kivételeket adhat meg. A fent felsorolt helyettesítő karakteres URL-címeket pontosvesszőkkel válassza el egymástól, például:

*.microsoftonline.com; *.sharepoint.com

Miután megkerülte a proxyt, képesnek kell lennie a ping vagy a PsPing használatára közvetlenül egy Office 365 URL-címen. A következő lépés a pingelési outlook.office365.com tesztelése lesz. Vagy ha a PsPing vagy más olyan eszközt használ, amely lehetővé teszi, hogy portszámot adjon meg a parancsnak, a PsPing a portal.microsoftonline.com:443 az átlagos utazási idő ezredmásodpercben való megtekintéséhez.

A körutazási idő (RTT) egy számérték, amely azt méri, hogy mennyi ideig tart egy HTTP-kérés küldése egy kiszolgálónak, például outlook.office365.com, és olyan választ kap, amely nyugtázza, hogy a kiszolgáló tudja, hogy ön tette. Ezt a rövidítést néha RTT-nek is nevezik. Ennek viszonylag rövid időnek kell lennie.

A teszt elvégzéséhez PSPing vagy más olyan eszközt kell használnia, amely nem használja az Office 365 által blokkolt ICMP-csomagokat.

A PsPing használata a teljes utazási idő ezredmásodpercben történő lekéréséhez közvetlenül egy Office 365 URL-címről

1. Futtasson rendszergazda jogú parancssort az alábbi lépések végrehajtásával:

2. Kattintson a Start gombra.

3. A Keresés indítása mezőbe írja be a cmd parancsot, majd nyomja le a CTRL+SHIFT+ENTER billentyűkombinációt.

4. Ha megjelenik a Felhasználói fiókok felügyelete párbeszédpanel, győződjön meg arról, hogy a megjelenő művelet a kívánt, majd kattintson a Folytatás gombra.

5. Lépjen arra a mappára, ahová az eszköz (ebben az esetben a PsPing) telepítve van, és tesztelje ezeket a Office 365 URL-címeket:

• psping admin.microsoft.com:443

• psping microsoft-my.sharepoint.com:443

• psping outlook.office365.com:443

• psping www.yammer.com:443

  

Ügyeljen arra, hogy a 443-at adja meg. Ne feledje, hogy Office 365 titkosított csatornán működik. Ha a PsPing paramétert a portszám nélkül teszi meg, a kérés sikertelen lesz. Miután pingelte a rövid listát, keresse meg az Átlagos idő ezredmásodpercben (ms) értékeket. Ezt szeretné rögzíteni!

Ha nem ismeri a proxy megkerülését, és inkább lépésről lépésre halad, először ki kell derítenie a proxykiszolgáló nevét. Az Internet Explorerben válassza az Eszközök>Internetbeállítások>Kapcsolatok>LAN-beállítások>Speciális lehetőséget. A Speciális lapon láthatja a proxykiszolgálót a listában. Pingelje a proxykiszolgálót egy parancssorban a következő feladat végrehajtásával:

A proxykiszolgáló pingelése és a körutazás értékének lekérése ezredmásodpercben az 1–2. fázishoz

1. Futtasson rendszergazda jogú parancssort az alábbi lépések végrehajtásával:

2. Kattintson a Start gombra.

3. A Keresés indítása mezőbe írja be a cmd parancsot, majd nyomja le a CTRL+SHIFT+ENTER billentyűkombinációt.

4. Ha megjelenik a Felhasználói fiókok felügyelete párbeszédpanel, győződjön meg arról, hogy a megjelenő művelet a kívánt, majd kattintson a Folytatás gombra.

5. Írja be, hogy pingelje <a böngésző által használt proxykiszolgáló nevét vagy a proxykiszolgáló> IP-címét, majd nyomja le az ENTER billentyűt. Ha telepítve van a PsPing vagy más eszköz, választhat, hogy ezt az eszközt használja.

   A parancs az alábbi példákhoz hasonlóan nézhet ki:

• ping ourproxy.ourdomain.industry.business.com

• ping 155.55.121.55

• ping a miproxy

• psping ourproxy.ourdomain.industry.business.com:80

• psping 155.55.121.55:80

• psping ourproxy:80

3. Ha a nyomkövetés nem küld tesztcsomagokat, kap egy kis összegzést, amely egy átlagot listáz ezredmásodpercben, és ez az az érték, amelyet keres. Készítsen képernyőképet a kérdésről, és mentse az elnevezési konvencióval. Ezen a ponton az is segíthet, hogy a diagramot kitöltse az értékkel.

Lehet, hogy kora reggel nyomkövetést végzett, és az ügyfél gyorsan elérheti a proxyt (vagy bármilyen kimenő kiszolgálót, amely kilép az internetre). Ebben az esetben a számok a következőképpen nézhetnek ki:

Ha az ügyfélszámítógép azon kiválasztott kevesek közé tartozik, amelyek hozzáférnek a proxykiszolgálóhoz (vagy a kimenő forgalomhoz), a teszt következő szakaszát futtathatja úgy, hogy távolról csatlakozik az adott számítógéphez, és onnan futtatja a PsPing parancssort egy Office 365 URL-címre. Ha nem fér hozzá a számítógéphez, a következő lépésben segítségért forduljon a hálózati erőforrásokhoz, és így pontos számokat kapjon. Ha ez nem lehetséges, vegyen fel egy PsPing-et a szóban forgó Office 365 URL-címhez, és hasonlítsa össze a proxykiszolgáló psping vagy pingelési idejével.

Ha például 51,84 ezredmásodperc van az ügyféltől a Office 365 URL-címig, és 2,8 ezredmásodperc van az ügyféltől a proxyig (vagy kilépési pontig), akkor 49,04 ezredmásodperc van a kimenő forgalomtól a Office 365. Hasonlóképpen, ha a psPing értéke 12,25 ezredmásodperc az ügyféltől a proxyig a nap magasságában, és 62,01 ezredmásodperc az ügyféltől az Office 365 URL-címig, akkor az Office 365 URL-címre irányuló proxykimenet átlagos értéke 49,76 ezredmásodperc.

A hibaelhárítás szempontjából érdekesnek tűnhet, ha nem tartja meg ezeket az alapterveket. Ha például azt tapasztalja, hogy általában körülbelül 40 ezredmásodperc és 59 ezredmásodperc közötti késés van a proxy vagy a kimenő forgalom pontjától a Office 365 URL-címig, és az ügyfél és a proxy közötti vagy kimenő pont késése körülbelül 3 ezredmásodperctől 7 ezredmásodpercig (attól függően, hogy mennyi hálózati forgalmat lát az adott nap folyamán), akkor biztosan tudni fogja, hogy valami problémás, ha az utolsó három ügyfél–proxy vagy kimenő forgalom alapkonfigurációi megjelennek késése 45 ezredmásodperc.

Speciális metódusok

Ha valóban tudni szeretné, mi történik a Office 365 felé irányuló internetes kéréseivel, ismernie kell a hálózati nyomkövetéseket. Nem számít, hogy milyen eszközöket szeretne használni ezekhez a nyomkövetésekhez, a HTTPWatch, a Netmon, az Üzenetelemző, a Wireshark, a Fiddler, a fejlesztői irányítópult eszköz vagy bármely más eszköz mindaddig, amíg az eszköz képes rögzíteni és szűrni a hálózati forgalmat. Ebben a szakaszban láthatja, hogy érdemes több eszközt futtatni, hogy teljesebb képet kapjon a problémáról. A tesztelés során ezen eszközök némelyike saját jogán proxyként is működik. A Office 365 teljesítményével kapcsolatos hibaelhárítási terv című társcikkben használt eszközök közé tartozik a Netmon 3.4, a HTTPWatch vagy a WireShark.

Ennek a módszernek az egyszerű része a teljesítménykonfiguráció használata, és számos lépés ugyanaz, mint a teljesítményproblémák elhárítása során. Az alapkonfigurációk teljesítménybeli létrehozásának fejlettebb módszereihez hálózati nyomkövetéseket kell készítenie és tárolnia. A jelen cikkben szereplő példák többsége a SharePoint Online-t használja, de a teszteléshez és rögzítéshez előfizetett Office 365 szolgáltatások gyakori műveleteinek listáját kell kidolgoznia. Íme egy alapkonfigurációs példa:

• Az SPO alapkonfigurációs listája – ** 1. lépés: ** Tallózzon az SPO webhely kezdőlapján, és végezzen hálózati nyomkövetést. Mentse a nyomkövetést.

• Az SPO alapkonfigurációs listája – 2. lépés: Keressen egy kifejezést (például a vállalat nevét) a Vállalati keresésen keresztül, és végezzen hálózati nyomkövetést. Mentse a nyomkövetést.

• SPO alapkonfigurációs listája – 3. lépés: Töltsön fel egy nagy fájlt egy SharePoint Online-dokumentumtárba, és végezzen hálózati nyomkövetést. Mentse a nyomkövetést.

• Az SPO alapkonfigurációs listája – 4. lépés: Tallózással keresse meg a OneDrive webhely kezdőlapját, és végezzen hálózati nyomkövetést. Mentse a nyomkövetést.

Ennek a listának tartalmaznia kell a felhasználók által a SharePoint Online-on végrehajtott legfontosabb gyakori műveleteket. Figyelje meg, hogy az utolsó lépés a OneDrive Vállalati verzió nyomon követéséhez a SharePoint Online kezdőlapjának terhelése (amelyet gyakran vállalatok szabnak testre) és OneDrive Vállalati verzió kezdőlap terhelésének összehasonlításában, amely ritkán van testre szabva. Ez egy alapszintű teszt, ha egy SharePoint Online-webhely lassan töltődik be. Ezt a különbséget rögzítheti a tesztelésben.

Ha teljesítményproblémát tapasztal, a lépések nagy része megegyezik az alapkonfigurációval. A hálózati nyomkövetések kritikus fontosságúak lesznek, ezért a következő lépésben a fontos nyomkövetések követését fogjuk kezelni.

A teljesítményproblémák megoldásához most nyomkövetést kell követnie a teljesítményprobadukta észlelése során. Rendelkeznie kell a megfelelő eszközökkel a naplók gyűjtéséhez, és szüksége van egy művelettervre, azaz a hibaelhárítási műveletek listájára, hogy a lehető legjobb információkat gyűjtse össze. Az első teendő a teszt dátumának és időpontjának rögzítése, hogy a fájlok az időzítést tükröző mappába legyenek mentve. Ezután szűkítse le a probléma lépéseit. Pontosan ezeket a lépéseket fogja használni a teszteléshez. Ne felejtse el az alapokat: ha a probléma csak az Outlookkal kapcsolatos, jegyezze fel, hogy a probléma viselkedése csak egy Office 365 szolgáltatásban fordul elő. Ha leszűkíti a probléma hatókörét, azzal segíthet, hogy a megoldható dolgokra összpontosítson.

Lásd még

Az Office 365-végpontok kezelése