A szolgáltatási szerződésben pontosan meg kell határozni a kezelt weboldalakat, a benne foglalt tevékenységeket, a kizárásokat, az incidensek prioritásait, a reakcióidő mérését, a változtatások jóváhagyását, a jelentéseket, a fiókok tulajdonjogát és a megszűnéskori átadás teljes folyamatát.
A WordPress-szervizszerződés a gondoskodás általános ígéretét konkrét terjedelemmé, felelősségekké és kommunikációs szabályokká alakítja. A webhely tulajdonosának tudnia kell, mely frissítések, biztonsági mentések, tesztek, monitorozás és beavatkozások tartoznak bele, ki hagyja jóvá a változtatást, és hogyan kezelik a munkaidőn kívüli incidenst. A szolgáltatónak pedig határokra van szüksége, hogy a sürgős támogatást ne tévesszék össze az új funkciók korlátlan fejlesztésével.
Az SLA, vagyis a szolgáltatási szintről szóló megállapodás mérhető fogalmakat használjon, és különböztesse meg a kérés visszaigazolását, a munka megkezdését, az ideiglenes helyreállítást és a teljes megoldást. A konkrét időket és szankciókat nem lehet univerzálisan meghatározni; ezek a weboldal jelentőségétől, a csapat rendelkezésre állásától és a szolgáltatás árától függenek. A szerződéses és jogi szöveget ellenőrizze képzett szakember, ez a cikk pedig egy tárgyszerű üzleti brief elkészítésében segít.
A szolgáltatás pontos tárgya és a kezelt eszközök listája
A mellékletben vagy a leltárban tüntessen fel minden domaint, WordPress-telepítést, éles és staging környezetet, tárhelyet, sablont, kulcsfontosságú bővítményt és külső integrációt. Minden tételnél jelölje meg a fiók tulajdonosát és a szolgáltató felelősségi szintjét. A WordPress üzemeltetése nem feltétlenül foglalja magában automatikusan a DNS-t, a levelezőszervert, a hirdetési szkripteket vagy a CRM-be való beavatkozást, bár ezek hibája a webes útvonalon jelentkezik.
A szolgáltatási kört ossza fel megelőző feladatokra, incidenskezelési támogatásra, tartalmi munkákra és fejlesztésre. Adja meg a frissítések gyakoriságát, a tesztelés módját, a mentések és visszaállítás ellenőrzését, a monitorozást és a funkcionális teszteket. A kizárásokat ugyanilyen egyértelműen nevezze meg: a harmadik féltől származó licencek, a támadás utáni kiterjedt helyreállítás, a tárhelymigráció vagy az új funkciók külön jóváhagyást igényelhetnek. A homályos „teljes körű üzemeltetés” megfogalmazás eltérő elvárásokat kelt mindkét félben.
Incidensprioritások és értelmes SLA
Határozza meg a szinteket a felhasználókra és az üzletre gyakorolt hatás alapján. Kritikus incidens lehet például az elérhetetlen weboldal, aktív támadás gyanúja vagy a fő értékesítési folyamat működésképtelensége; alacsonyabb prioritású lehet egy kozmetikai hiba, amely nem akadályozza a feladat elvégzését. Minden szinthez adjon meg példákat, a bejelentés csatornáját és azt a személyt, aki jogosult a prioritást megerősíteni. Maga a „sürgős” szó definíció nélkül nem segíti a döntéshozatalt.
Az SLA-nak tartalmaznia kell az üzemidőt, a mérés kezdetét, a reakcióidőt és az eszkaláció módját. A reakció visszaigazolást és első értékelést jelent, nem feltétlenül teljes javítást. A megoldási idő függhet a bővítmény gyártójától, a tárhelytől vagy a hiányzó hozzáférésektől; ezért állapodjanak meg a rendszeres állapotfrissítések és az ideiglenes megoldás szabályáról is. A munkaidőn kívüli rendelkezésre állást kifejezetten meg kell állapodni, személyi erőforrással biztosítani és a kereskedelmi feltételekben figyelembe venni.
- a valós hatásból levezetett prioritás
- külön meghatározott reakció és megoldás
- egyértelmű szolgáltatási idő és eszkaláció
- rendszeres tájékoztatás a nyitott incidens ideje alatt
Módosítások, költségkeret és licencek jóváhagyása
Állapodjon meg arról, mely alacsony kockázatú frissítéseket végezheti el az üzemeltető az átalánydíj keretében, és mely beavatkozásokhoz szükséges írásos jóváhagyás. A jóváhagyási kérelemben szerepeljen az ok, a terjedelem, a várható hatás, az ár vagy a megállapodott keretből felhasznált mennyiség, valamint a visszaállítási terv. Biztonsági javításnál a döntési idő rövidebb lehet, de a szerződésnek rögzítenie kell, ki járhat el, ha a kapcsolattartó nem érhető el.
A licencek tulajdonjogának és megújításuk módjának átláthatónak kell lennie. A cégnek tudnia kell, mely licencek vannak közvetlenül a tulajdonában, melyeket biztosít a szolgáltató a szerződés idejére, és mi szűnik meg működni a szerződés megszűnése után. Az automatikus meghosszabbítás, az árváltozás vagy a támogatás korlátozása nem érheti váratlanul. A fejlesztési igényeket az üzemeltetési karbantartástól elkülönítve tartsa nyilván, hogy a jelentés és a számlázás egyértelműen mutassa, mire használták a kapacitást.
Kommunikációs csatorna és szervizjelentés
Jelöljön ki egy nyilvántartott csatornát a szokásos kérésekhez, és külön módot a kritikus incidensek bejelentésére. A bejelentésnek tartalmaznia kell az URL-t, az időpontot, a megfigyelt viselkedést, az eszközt és az elérhető képernyőfelvételt érzékeny adatok nélkül. Egy telefonhívás elindíthatja a reagálást, de az eredményt rögzíteni kell a közös rendszerben. Az ügyfél és a szolgáltató oldalán is határozzon meg elsődleges és helyettes kapcsolattartót, valamint szabályokat arra, kinek jelenthető biztonsági esemény.
A rendszeres jelentésnek tartalmaznia kell a frissítéseket, teszteket, rendelkezésre állást, a biztonsági mentések állapotát, az incidenseket, a nyitott kockázatokat, a felhasznált fejlesztési kapacitást és a javasolt döntéseket. Egy szám kontextus nélkül nem elég: egy sikertelen mentéshez meg kell adni a hatást és a javító lépést, nem csak egy piros ikont. Egyezzenek meg a jelentés gyakoriságában és formátumában, és a következő időszakot a lezáratlan feladatok áttekintésével kezdjék. Érzékeny naplókat vagy személyes adatokat ne másoljon a szokásos jelentésbe.
Fiókok tulajdonjoga, hozzáférések és biztonsági felelősség
A domaint, a fő tárhelyfiókot, az analitikát és a cégprofilokat a cégnek kell ellenőriznie, vagy szerződésileg és technikailag is megvalósítható átruházással kell rendelkeznie. A szállító saját identitást használ a legkisebb szükséges jogosultságokkal és többfaktoros hitelesítéssel. A jelszavakat nem küldik hagyományos e-mailben, és nem illesztik be a szervizjelentésbe. A szerződésnek meg kell határoznia, ki hagyja jóvá az új fiókot, hogyan vezetik a hozzáférések nyilvántartását, és mikor szüntetik meg a régi identitást.
Ossza fel a felelősséget az alkalmazás, a szerver, a DNS, a tanúsítvány, a mentések, a biztonsági értesítések és a harmadik fél szolgáltatói között. Ha egy incidens a szállító közvetlen kezelésén kívül keletkezik, egyértelműnek kell lennie, hogy ő koordinálja-e a kommunikációt, vagy csak technikai anyagokat biztosít. Személyes adatok esetén a szerepeket és az adatfeldolgozói viszonyokat szakszerű jogi értékelés alapján adja meg. A szolgáltatási szerződés nem helyettesíti a biztonsági szabályzatot, de összhangban kell lennie vele.
A szerződés megszüntetése és a weboldal ellenőrzött átadása
A megállapodásnak tartalmaznia kell a felmondási időt, az együttműködés terjedelmét, az exportformátumot és a folyamatban lévő munkák elszámolásának szabályait. Az átadási csomag általában tartalmazza a leltárt, az aktuális kódot, az adatbázist és a médiafájlokat, a telepítési dokumentációt, a licencek állapotát, az átirányításokat, a biztonsági mentéseket, a nyitott incidenseket és az utolsó tesztek dátumát. A homályos „mindent átadunk” vitát szül; egy konkrét lista lehetővé teszi, hogy mindkét fél megerősítse a teljesítést.
Az új üzemeltetőnek biztonságosan kell átvennie a fiókokat, és tesztelnie kell a telepítést, az űrlapokat, a monitorozást és a visszaállítást. Ezt követően az automatizálások megzavarása nélkül meg kell szüntetni az eredeti szolgáltató identitásait, API-kulcsait és távoli hozzáféréseit. A jelszavakat ne küldje el a listában; használjon biztonságos csatornát, majd cserélje le őket. Adja meg, mennyi ideig őrzi az eredeti szolgáltató a munkapéldányokat, és mikor törlik azokat a szerződéses és szakmailag megítélt kötelezettségek szerint.
- konkrét átadási csomag és határidő
- átvételi teszt új üzemeltetővel
- titkok rotálása és identitások visszavonása
- a munkapéldányok egyeztetett törlése
Gyakori kérdések
Mi a különbség a reakcióidő és a megoldási idő között?
A reakcióidő azt határozza meg, hogy a szolgáltató meddig igazolja vissza a kérést és kezdi meg annak értékelését. A teljes megoldás az októl vagy harmadik féltől függhet, ezért külön meghatározást, állapotfrissítéseket és szükség esetén ideiglenes megoldást igényel.
Tartalmazzon-e a szervizszerződés korlátlan weboldal-módosítást?
Nem szükségszerűen. A megelőző karbantartást, az incidenseket, a tartalmi beavatkozásokat és az új fejlesztést érdemes elkülöníteni. A szerződésnek rögzítenie kell a benne foglalt kapacitást, a többletmunka jóváhagyásának módját és annak üzleti hatását, rejtett elvárások nélkül.
Kinek a tulajdonában legyen a domain és a tárhelyfiók?
A fő irányításnak a cégnél kell lennie, vagy egyértelmű és megvalósítható átadásnak kell léteznie. A szállító saját, arányos hozzáférést használjon, amelyet az együttműködés végén a céges adatok elvesztése nélkül meg lehet szüntetni.
Források és további olvasnivaló
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
