SLA ar "15 minūšu reaģēšanas laiku" izklausās pēc mārketinga saukļa, kamēr neesat patiešām izanalizējis, kam jānotiek šo 15 minūšu laikā. Tās nav 15 minūtes drudžainas improvizācijas — ja tā būtu, šādu solījumu nemaz nevarētu dot ar pārliecību. Tās ir 15 minūtes, kuru laikā izpilda lēmumus, kas pieņemti jau ilgi pirms brīdinājuma.
Pirmo 15 minūšu anatomija
Labi organizēta reaģēšana uz incidentu katru reizi seko aptuveni vienam un tam pašam scenārijam, neatkarīgi no tā, kas īsti salūza:
- Nostrādā brīdinājums — ideālā gadījumā balstoties uz agrīnu indikatoru (skatiet mūsu rakstu par metrikām, kas patiešām paredz incidentus), nevis tikai jau notiekošu dīkstāvi.
- Triāža: vai vaina tiešām ir datubāzē? Pārsteidzoši liela daļa "datubāzes incidentu" patiesībā rodas augšpus tās — savienojumu noplūde lietojumprogrammā, nekontrolēts pakešu uzdevums, tīkla nodalīšanās. Pirmās minūtes tiek veltītas tam, lai apstiprinātu, kur problēma tiešām atrodas, nevis to pieņemtu par pašsaprotamu.
- Stabilizē, vēl nediagnosticē. Ja nekontrolēts vaicājums patērē visus pieejamos savienojumus, to pārtrauc. Ja primārajam serverim jāveic pārslēgšanās (failover), to izdara. Pirmo minūšu mērķis ir iegūt laiku un apturēt problēmas saasināšanos — pilna cēloņa analīze notiek pēc tam, kad sistēma ir stabilizēta, nevis pirms tam.
- Sazinies agri, pat ja informācija vēl nav pilnīga. Ja par incidentu ieinteresētās puses uzzina no saviem lietotājiem, tas ir sliktāk nekā uzzināt no jums pašiem ar ziņu "mēs zinām, strādājam pie tā, nākamais atjauninājums pēc 10 minūtēm".
- Sāc cēloņa noskaidrošanu, tiklīdz tiešais risks ir savaldīts — izmantojot žurnālus, metrikas un vaicājumu vēsturi, kas tiešām ir pieejama un noderīga, jo monitorings jau bija ieviests pirms incidenta sākuma.
Nekas no tā nedarbojas bez garlaicīgās daļas, kas paveikta iepriekš: vides, kas jau ir dokumentētas, piekļuves, kas jau ir izsniegta un pārbaudīta (nevis "izdomāsim, kuram ir pareizie piekļuves dati, jau incidenta laikā"), un darbības instrukcijām (runbook), kas atspoguļo sistēmu tādu, kāda tā ir šodien — nevis tādu, kāda tā bija konfigurēta pirms gada.
Kāpēc darbības instrukcijas uzvar varonību
Komanda, kurai incidenta laikā problēma jāizpēta no nulles, vienmēr strādā lēnāk nekā komanda, kas izpilda zināmu procedūru — pat ja tā ir laba komanda. Darbības instrukcijas (runbook) vērtība nav tajā, ka tā aptver visus iespējamos atteices veidus; tā ir tajā, ka tā pilnībā aptver biežākos, tāpēc pirmās 15 minūtes tiek pavadītas, rīkojoties, nevis izdomājot, ko darīt. No komandas, kas netērē laiku tiem 80% incidentu, kuri gan ir aprakstīti, iegūst arī tas retais atteices gadījums, kas nav aprakstīts nevienā instrukcijā.
Kam jābūt patiesam, pirms brīdinājums vispār nostrādā
- Monitorings, kas parāda patiesos agrīnos problēmu indikatorus, nevis tikai CPU un atmiņas noslodzi.
- Piekļuve un piekļuves dati, kas regulāri tiek pārbaudīti, nevis pieņemti kā joprojām derīgi.
- Darbības instrukcijas, kas tiek pārskatītas un atjaunotas līdz ar vides izmaiņām — instrukcija infrastruktūrai, kuras vairs nav, ir sliktāka par tās neesamību vispār.
- Skaidra atbildība, lai jautājums "kurš faktiski vada šo incidentu" pats par sevi neaizņemtu pirmās piecas minūtes.
Reaģēšanas laika apņemšanās patiesībā ir apņemšanās iepriekš paveikt visu šo darbu. 15 minūtes ir tikai brīdis, kad tas kļūst redzams.
Galvenās atziņas
- Labas reaģēšanas uz incidentu pirmās minūtes ir par stabilizāciju, nevis diagnostiku — cēloņa noskaidrošana notiek pēc tam.
- Darbības instrukcijas un iepriekš pārbaudīta piekļuve ir tas, kas ātru reaģēšanu padara atkārtojamu, nevis atkarīgu no veiksmes.
- Reaģēšanas laika SLA ir rādītājs tam, cik daudz sagatavošanās darba paveikts pirms incidenta, nevis solījums par to, cik ātri cilvēki spēj domāt spiediena apstākļos.