Figyeld a felhasználó számára látható funkciót, adj hozzá elegendő erőforrás- és alkalmazásbizonyítékot a diagnózishoz, és csak olyan feltételekre riassz, amelyek időben történő emberi beavatkozást igényelnek. Minden riasztáshoz rendelj felelőst, első lépést és eszkalációt. Az incidens alatt hangold össze a mérséklést, védd a bizonyítékokat, és a tényleges felhasználói útvonalon keresztül ellenőrizd a helyreállást.
Kezdd a fontos funkcióval
Egy szerver pingre adott válasza nem bizonyítja, hogy az alkalmazása működik. Válassz egy reprezentatív, ártalmatlan felhasználói útvonalat, például egy nyilvános oldal lekérését vagy egy ellenőrzött tesztvégpont elérését. Határozd meg, mit jelent a siker, és kerüld az olyan szintetikus ellenőrzéseket, amelyek minden futás során valódi rendeléseket hoznak létre, tartalmat tesznek közzé vagy ügyfélértesítéseket küldenek.
Figyeld megfelelő külső nézőpontból is, nem csak az alkalmazáson belülről. A külső megfigyelés felfedhet olyan hozzáférési vagy útvonalválasztási problémákat, amelyeket a szerver nem lát. A belső mérések megmagyarázhatják, miért hibázott az útvonal. Tartsd mindkét nézetet a funkcióhoz kapcsolva, ahelyett hogy csak azért gyűjtenél nagy irányítópultot, mert minden metrika elérhető.
Válassz diagnosztikai értékkel bíró jeleket
A Google SRE útmutatása a késleltetést, a forgalmat, a hibákat és a telítettséget emeli ki hasznos jelekként a felhasználóknak szóló rendszereknél. Használd őket a viselkedés leírására: válaszidő, kérésmennyiség, sikertelen kérések és a korlátozott erőforrásokra nehezedő nyomás. Válassz az alkalmazáshoz illő méréseket, ahelyett hogy feltételeznéd, hogy egyetlen metrikadefiníció működik egy webhely, egy átviteli szolgáltatás és egy háttérfeldolgozó számára.
Válaszd külön a sikeres és sikertelen kérések viselkedését, ahol ez számít, és vizsgáld a lassú farokeredményeket, ne csak az átlagokat. Adj hozzá memórianyomást, lemezterületet, várakozási sor mélységét vagy alkalmazásspecifikus korlátokat, amikor ezek magyarázzák a szolgáltatást. Egy magas CPU érték normális lehet hasznos batch munka közben; a felhasználó számára látható hatás dönti el, hogy szükség van-e azonnali beavatkozásra.
Adj minden riasztáshoz műveletet és felelőst
Egy riasztásnak meg kell adnia az érintett funkciót, a megfigyelt feltételt és a hasznos első ellenőrzést. A telepítés előtt rendelj hozzá felelőst és eszkalációs útvonalat. Különböztesd meg az azonnali megszakítást igénylő feltételeket az ütemezett felülvizsgálatra alkalmas tételektől. Az ismétlődő alacsony értékű riasztások arra tanítják az üzemeltetőket, hogy figyelmen kívül hagyják a rendszert, és megnehezítik a fontos jelek felismerését.
Egy kis riasztásfelülvizsgálattal szüntesd meg a kétértelműséget. Ez a szemléltető táblázat lehetséges monitorozási döntéseket ír le, nem SwissOctet támogatási lefedettséget vagy elérhetőségi kötelezettségvállalást. A küszöbértékeket az alkalmazás tényleges alapvonalához kell tesztelni. Adj hozzá helyreállítási feltételt, hogy az üzemeltető tudja, mikor szűnt meg a riasztás, és mit kell még ellenőrizni.
| Megfigyelt feltétel | Hasznos válasz | Belefoglalandó kontextus |
|---|---|---|
| A reprezentatív felhasználói útvonal meghiúsul | Mérd fel a hatást és mérsékeld | Érintett végpont, időtartam és legutóbbi változás |
| A lemez közeledik egy tervezett korláthoz | Vizsgáld felül a növekedést és a megőrzést | Mennyiség, növekedési ütem és biztonságos tartalék |
| A biztonsági mentés ellenőrzése meghiúsul | Védd a helyreállítási útvonalat | Feladat, utolsó használható pont és hiba |
| A késleltetés nő egy kiadás alatt | Vizsgáld meg vagy állítsd vissza a változtatást | Alapvonal, kiadás ideje és érintett kérések |
Készíts elő egy kis incidensstruktúrát
Egy válaszfolyamatnak nyomás alatt is érthetőnek kell lennie. Nevezz meg egy koordinátort, valakit, aki a technikai munkát végzi, és valakit, aki a frissítésekért felel, amikor az incidens elég nagy ahhoz, hogy külön szerepekre legyen szükség. Egy kis projekt összevonhatja a szerepeket, de még így is profitál egy világos döntési pontból. A szolgáltatás meghibásodása előtt egyezzetek meg egy kommunikációs csatornában.
A Google incidenskezelési anyaga a koordinációt és a mérséklésre összpontosító megközelítést hangsúlyozza. Alkalmazd ezt a projekthez illő léptékben: állapítsd meg a hatást, válassz biztonságos műveleteket, és kerüld el, hogy több üzemeltető egymásnak ellentmondó változtatásokat végezzen. Jegyezz fel egy idővonalat és a döntéseket. A tökéletes magyarázat keresése nem késleltethet egy biztonságos intézkedést, amely helyreállítja az érintett funkciót.
Járj végig egy konkrét degradációt
Képzeld el, hogy egy webhely lelassul egy kiadás után. Egy külső ellenőrzés megnövekedett befejezési időt mutat, míg a belső mérések alkalmazáshibákat és növekvő adatbázis-munkát jeleznek. A koordinátor behatárolt incidenst hirdet, védi a bizonyítékokat, és egy személyt jelöl ki a kiadás és az alapvonal összehasonlítására. Egy másik előkészíti a tesztelt visszaállítási útvonalat, ahelyett hogy nem kapcsolódó infrastruktúra-változtatásokat végezne.
Ha a visszaállítás biztonságos az alkalmazás adatállapota szempontjából, használd, és figyeld meg az eredményt. Ha nem biztonságos, válassz egy szűkebb, a működési terv által támogatott mérséklést. Dokumentáld, mi változott és mikor. Egy nagyobb VPS vagy port később megfontolható lehet, de az azonnali döntésnek a bizonyítékokra kell irányulnia, ahelyett hogy az infrastruktúra méretét feltételezné okként.
Védd a bizonyítékokat és ellenőrizd a helyreállást
A működési naplók és incidensjegyzetek címeket, azonosítókat és ügyféladatokat tartalmazhatnak. Gyűjtsd össze, amire a vizsgálatnak szüksége van, korlátozd a hozzáférést, és tartsd távol a hitelesítő adatokat vagy privát rendelési tokeneket a megosztott jelentésektől. Gyanított biztonsági incidens esetén őrizd meg a megfelelő bizonyítékokat, és kövesd a projekt válaszszabályzatát, ahelyett hogy sietős takarítással megsemmisítenéd az információkat.
A NIST incidenskezelési útmutatása a válaszlépéseket a szélesebb kiberbiztonsági kockázatkezelésbe helyezi. A helyreállítás magában foglalja a szándékolt funkció ellenőrzését és az incidens lehetővé tevő feltétel megoldását. A válasz lezárása előtt teszteld a felhasználói útvonalat, vizsgáld felül az erőforrások viselkedését és ellenőrizd a háttérmunkát. Egy megszűnt riasztás vagy újraindított folyamat önmagában nem bizonyítja a hasznos szolgáltatás teljes visszatérését.
Alakítsd az incidenst mérhető fejlődéssé
Írj rövid értékelést a hatásról, az idővonalról, a hozzájáruló feltételekről és a megtett intézkedésekről. Összpontosíts az ellenőrizhető változtatásokra: javíts egy ellenőrzést, javíts ki egy jogosultságot, gyakorolj visszaállítást vagy adj hozzá egy hiányzó helyreállítási függőséget. Rendelj felelősöket és teljesítési kritériumokat. Kerüld a homályos szándékok hosszú listáját, amelyekről senki sem tudja később megerősíteni, hogy megvalósultak.
A SwissOctet-n történő telepítéskor a monitorozást és a válaszlépéseket az alkalmazás működésének részeként tervezd meg, elkülönítve a választott hardvertől és bármely megerősített kezelési megállapodástól. A katalógus nem bizonyít személyzettel ellátott incidenscsapatot vagy folyamatos támogatási időt. Döntsd el, ki kapja a riasztásokat, ki tud cselekedni, és mit fednek a tényleges szolgáltatási feltételek, mielőtt egy éles környezetre támaszkodnál.
Az Ön gyakorlati ellenőrzőlistája.
- Figyelj meg egy ártalmatlan, reprezentatív felhasználói útvonalat.
- Válassz olyan jeleket, amelyek megmagyarázzák az alkalmazás viselkedését.
- Adj a riasztásokhoz műveletet, felelőst és helyreállítási feltételt.
- Egyezzetek meg a koordinációról és az eszkalációról az incidens előtt.
- Védd a bizonyítékokat és ellenőrizd a teljes helyreállást.
- Rendelj tesztelhető fejlesztéseket az értékelés után.
A fontos részletek.
Elég a szerver üzemidejének monitorozása?+
Nem. Egy elérhető gép működtethet hibás alkalmazást. Figyeld a felhasználók által használt funkciót, és adj hozzá erőforrás-bizonyítékokat a hibák diagnosztizálásához.
Minden metrikaküszöbnek azonnal riasztania kell valakit?+
Nem. Az azonnali megszakításokat az időben történő figyelmet igénylő, cselekvésre alkalmas feltételeknek tartsd fenn. Az alacsonyabb prioritású munkát egy világos felelőssel rendelkező felülvizsgálati folyamatba irányítsd.
Mikor van vége egy incidensnek?+
Miután az érintett funkciót és a releváns háttérmunkát ellenőrizték, az azonnali kockázatokat kezelték, és a nyomon követési intézkedéseket rögzítették. Egy folyamat újraindítása önmagában nem elegendő.
Menjen a forráshoz.
Ezek a hivatkozások támogatják az útmutató műszaki fogalmait. Kövesse az aktuális dokumentációt, mielőtt éles rendszert módosítana.
- Google SRE: Elosztott rendszerek monitorozása sre.google
- Google SRE munkafüzet: Incidenskezelés sre.google
- NIST SP 800-61 Rev. 3: Incidenskezelés csrc.nist.gov
Szerkesztői útmutatás: SwissOctet. A példák tájékoztató jellegűek. A szolgáltatási specifikációkat, az elérhető opciókat és a szerződéses feltételeket külön kell ellenőrizni.