Webshopot üzemeltetsz. Valaki éppen most fizet. A pénztár elromlott. A vásárló hibaüzenetet kap. A vásárló elmegy. Éppen elveszítettél egy eladást.
Üzemeltetési vezérlőpult nélkül a hibát csak holnap találnád meg, amikor átnézed a napi riportot.
Üzemeltetési vezérlőpulttal az üzemeltetési csapat másodperceken belül észreveszi a hibát. Azonnal javítja. A vásárló újra próbálkozik. Az eladás sikerül.
A lassú észlelés költsége: óránként és hibánként több száz dollár.
Az üzemeltetési vezérlőpultok valós időben kapják el a problémákat, nem órákkal vagy napokkal később.
Az üzemeltetési vezérlőpultok feladata
Az üzemeltetési vezérlőpultok a rendszerek egészségét és az aktív műveleteket figyelik.
Elérhető a weboldal? Működnek a pénztári folyamatok? Válaszolnak a fizetési szolgáltatók? Megy az e-mail-küldés? Sikeresek az API-hívások?
Az üzemeltetési vezérlőpult nem a bevételről vagy az üzleti mutatókról szól. A rendszer egészségéről.
Valós idejű adat követelménye
Az üzemeltetési vezérlőpultnak valós időben vagy közel valós időben kell frissülnie (egy percen belül).
A késleltetett adat haszontalan. Ha a vezérlőpult óránként frissül, lemaradsz a frissítések között bekövetkező kiesésekről.
A valós idejű követelmény azt jelenti: az üzemeltetési vezérlőpult drága felépíteni és fenntartani. Csak kritikus rendszerekre használd.
Mit figyelj az üzemeltetési vezérlőpulton
A rendszer elérhetősége
Válaszol a weboldal? Zöld, ha elérhető, piros, ha nem.
Válaszidő
Milyen gyors a weboldal? Zöld, ha két másodperc alatt van, sárga, ha két és öt másodperc között, piros, ha öt másodperc felett.
Hibaarány
A kérések hány százaléka ad hibát? Zöld, ha 0,1% alatt, sárga, ha 0,1% és 0,5% között, piros, ha 0,5% felett.
Aktív tranzakciók
Hány tranzakció zajlik éppen. Viszonyításul. Önmagában nem jó vagy rossz.
Folyamatban lévő konverziós tölcsér
Hány látogató van a pénztár egyes lépéseiben éppen most. Bármelyik lépésnél a lemorzsolódás vizsgálatot indít.
API-teljesítmény
A külső integrációk válaszideje. Fizetési szolgáltató, e-mail-szolgáltatás, szállítási API.
Adatbázis-teljesítmény
Lekérdezések válaszideje, a kapcsolatkészlet állapota.
Valós példa: webshop üzemeltetési vezérlőpultja
Felső rész (rendszer egészsége)
Weboldal állapota: ELÉRHETŐ (zöld). Válaszidő: 1,2 másodperc (zöld). Hibaarány: 0,08% (zöld). Aktív felhasználók: 423. Folyamatban lévő tranzakciók: 17.
Középső rész (pénztári tölcsér)
Kosár megtekintése: 127 felhasználó. Pénztár indítása: 89 felhasználó (70% konverzió a kosárból). Szállítási adatok: 72 felhasználó (81% konverzió). Fizetési adatok: 68 felhasználó (94% konverzió). Rendelés visszaigazolása: 64 felhasználó (94% konverzió). Lemorzsolódás a szállítási adatoknál: 17 felhasználó (várjunk, ez a szokásosnál több, vizsgáld meg).
Alsó rész (integrációk)
Fizetési szolgáltató: 800 ms alatt válaszol (zöld). E-mail-szolgáltatás: 99,8% kézbesítés (zöld). Szállítási díjkalkulátor: 1200 ms alatt válaszol (sárga, kicsit lassú).
Azonnali teendő
A lemorzsolódás a szállítási adatoknál a szokásosnál magasabb. Vizsgáld meg, hogy a szállítási kalkulátor lassúsága okozza-e a megszakításokat.
Riasztási rendszer
Az üzemeltetési vezérlőpultnak riasztást kell kiváltania, ha a mutatók pirosra váltanak.
Azonnal riassz az üzemeltetési csapatnak. Ne e-mailben, mert azt elnézhetik. SMS-ben, csapatchaten vagy személyhívón, ami félbeszakítja a munkát.
A küszöbök legyenek szigorúak. Nem kellenek téves riasztások. De jobb egy téves riasztás és egy elkapott valódi probléma, mint hogy lemaradj a problémákról.
Példa küszöbök: a weboldal 30 másodpercig nem elérhető = riasztás. A hibaarány 5 percig 1% felett = riasztás. A válaszidő 10 percig 5 másodperc felett = riasztás. A fizetési szolgáltató nem válaszol = azonnali riasztás.
Az ügyeleti beosztás
Az olyan rendszereknél, amelyek elég kritikusak ahhoz, hogy üzemeltetési vezérlőpult kelljen hozzájuk, ügyeleti beosztás is kell.
Valaki a nap 24 órájában felelős a figyelésért. Ha éjjel 3-kor riasztás jön, az ügyeletes felébred, és megjavítja a problémát.
Az ügyelet drága. De a leállás drágább.
Csak a kritikus rendszereket tedd az ügyelettel támogatott üzemeltetési vezérlőpultra.
Mit NE figyelj
Ne figyelj üzleti mutatókat az üzemeltetési vezérlőpulton. A bevétel, a konverziók, a forgalmi trendek üzleti vezérlőpultra valók, nem üzemeltetésire.
Az üzleti és az üzemeltetési keverése összezavarja a célt. Az üzemeltetés a rendszer egészségéről szól. Az üzleti az üzlet egészségéről.
Külön vezérlőpult külön célokra.
Vezérlőpult és riasztások
Az üzemeltetési vezérlőpulttal proaktívan figyelhetsz. Nézd meg a vezérlőpultot, mielőtt a hiba kritikussá válik.
A riasztásokkal reaktívan reagálsz. A hiba bekövetkezik, a riasztás szól, te javítod.
Mindkettő kell. A vezérlőpult a proaktív figyelésre. A riasztások a reaktív reagálásra, amikor senki nem nézi a vezérlőpultot.
Incidenskezelési forgatókönyvek
Ha riasztás szól, mi történik utána? Az üzemeltetési csapatnak minden riasztástípushoz legyen forgatókönyve.
Weboldal-leállás riasztás: indítsd újra a webszervert. Ha még mindig nem megy, kapcsolj át a tartalékra. Ha még mindig nem megy, eszkaláld a vezető mérnöknek. Fizetési szolgáltató leállása riasztás: válts a tartalék szolgáltatóra. Értesítsd az ügyfeleket a lehetséges késésről. Figyeld, amíg a fő szolgáltató helyre nem áll. Lassú adatbázis riasztás: ellenőrizd a kapcsolatkészletet. Ha tele van, növeld. Nézd meg a lekérdezésnaplót. Állítsd le a lassú lekérdezéseket. Figyeld.
A forgatókönyvek megelőzik a pánikot. A világos lépések megelőzik a hibákat.
Gyakran ismételt kérdések
Milyen gyakran nézzük az üzemeltetési vezérlőpultot?
Folyamatosan munkaidőben. Egy ember mindig figyeli. Munkaidőn kívül az ügyeletes figyeli. A nem kritikus rendszereket óránként ellenőrizd. A kritikus rendszereknél (fizetésfeldolgozás, pénztár) folyamatos a figyelés. Határozd meg, melyek a kritikus rendszerek: azok, ahol egy óra leállás jelentős bevételbe kerül. Minden mást óránként elég ellenőrizni. A WEMASY weboldalépítőjével ezt közvetlenül a weboldaladon is beállíthatod.
Mekkora válaszidő elfogadható?
Webshop pénztárnál: két másodperc alatt. Marketingoldalnál: három másodperc alatt. Belső admin eszközöknél: öt másodperc alatt. Ennél lassabban romlik a konverzió vagy a felhasználói élmény. A felhasználó szemszögéből mérj, ne a szerver szemszögéből. Ha a felhasználó késést érzékel, az túl lassú.
Hogyan kerüljük el a riasztási fáradtságot?
Szigorú küszöbökkel. Csak akkor riassz, ha valódi a probléma. Ha naponta tíz riasztást kapsz, és kilenc téves, az emberek nem figyelnek rá. Jobb napi két riasztás, amelyek mind valódiak. Hangold agresszíven a küszöböket. Ha a riasztás szól, de nem sürgős, emeld a küszöböt. A riasztási fáradtság megöli a reakciókészséget.
Legyen az üzemeltetési vezérlőpult mobilról is elérhető?
Igen. Az ügyeletesnek bárhonnan meg kell tudnia nézni. Gondoskodj róla, hogy telefonon is működjön. Az ügyeletes lehet, hogy nincs az asztalánál. Optimalizáld mobilra. Nagy érintési felületek. Egyszerű elrendezés. Gyors betöltés 4G-n is.
Hogyan követjük az üzemeltetési állapotot időben?
Naplózz minden mutatót. Bár az üzemeltetési vezérlőpult valós idejű, őrizd meg az előzményeket. Hetente nézd át: milyen gyakran voltunk leállva, mennyire voltunk lassúak, mik voltak a leggyakoribb hibák. Az előzményekkel azonosíthatod a rendszerszintű gondokat. Példa: ha hetente három fizetési szolgáltatói időtúllépés van, vizsgáld a fizetési szolgáltatót. Ne csak a riasztási küszöböt módosítsd.
Mi van, ha az ügyeletes nem tudja, hogyan javítsa meg a problémát?
Legyen eszkalációs útvonal. Az ügyeletes az első reagáló. Ha öt percen belül nem tudja megjavítani, eszkalálja a vezető mérnöknek. A vezető mérnök a második szint. Ha egyikük sem tudja megjavítani, eszkalálja a szállítói támogatásnak vagy a vezérigazgatónak. A forgatókönyvek minden riasztástípushoz rögzítsék az eszkalációs útvonalat.