Vaš proces tunela lahko deluje, medtem ko je zaščitena povezava neuporabna, in spletna stran, ki odpove, ni dokaz, da se je tunel zlomil. Ko ena sonda zastopa vse druge, politika ponovnega zagona znova zažene napačno komponento in temu reče avtomatizacija. Vsaka kontrola spodaj poimenuje sloj, ki ga opazuje, dejanje, ki ga sproži njena napaka, in dokaz, da je dejanje delovalo. Zadnji korak spremeni celoten nabor v stran, ki ji lahko nekdo sledi ob treh zjutraj.

Korak 1: poimenujte sloj, ki ga opazuje vsaka kontrola

Preden katero od njih napišete, vprašajte, kaj lahko vsaka sonda v resnici vidi. Živost dokazuje, da demon teče, rokovanje ali seznam partnerjev dokazuje, da razmerje obstaja, usmerjena zahteva dokazuje dostavo, poizvedba pa dokazuje razrešitev. Odpovedo natanko v tem vrstnem redu in nobena ne implicira naslednje. Zelena kontrola procesa poleg mrtvega tunela je običajen primer, ne protislovje.

Zapišite štiri kontrole v tem vrstnem redu, z natančnim ukazom in pričakovanim izhodom za vsako. Sondo, katere pričakovanega izhoda ne morete navesti, bo vsak operater, ki vidi alarm, prebral drugače. Postavite isti seznam v besedilo alarma, ne le v runbook, da bo oseba, zbujena ponoči, srečala sloj pred simptomom. Vsak ukaz naj bo pripravljen za kopiranje na gostitelju, ki ga izvaja.

Nato dodajte kontrolo aplikacije kot peto, ločeno postavko. Stran, katere storitev računov ne deluje, ne opravičuje ponovnega zagona tunela.

Korak 2: povežite vsako napako z enim dejanjem

Za vsako kontrolo se odločite, kaj se znova zažene, kaj ostane blokirano in kaj pokliče človeka. Napaka sloja tunela lahko opraviči ponovni zagon tunela; napaka razreševalnika kaže na integracijo DNS na odjemalcu; napaka aplikacijskega sloja se skoraj nikoli ne sme dotakniti tunela.

Povejte, česa napaka ne sme storiti, ker so nevarne privzete vrednosti tiste, ki dovoljujejo. Nezdravo stanje nikoli ne sme postati dovoljenje za neposreden promet aplikacije, saj rezervna pot, ki tiho obide tunel, odvzame razlog za obstoj tunela. Zožite tudi dejanja: ponovni zagon skupne komponente zato, ker je en cilj počasen, spremeni lokalno težavo v težavo celotne flote. Prav tako uniči dokaz, ki ste ga potrebovali za iskanje vzroka.

Korak 3: ohranite sonde neškodljive in poceni

Uporabite majhne zahteve samo za branje: statični vir, zdravstveno končno točko, ki poroča o svoji odvisnosti, ali povezavo TCP z vrati, ki jih nadzorujete. Izogibajte se poverilnicam, zasebnemu brskanju in vsemu, kar v vsakem intervalu spremeni stanje, ker je sonda, ki piše, obremenitveni test po urniku.

Zabeležite cilj, pričakovanje poti in časovno omejitev za vsako sondo. Pričakovanje poti je polje, ki ga ljudje izpustijo, in prav ono loči napako tunela od napake usmerjanja, ko alarm pozneje berete. Izpeljite interval in prag napake iz časa obnovitve, ki ga obljubljate, in držite časovno omejitev krajšo od intervala. Sonda, ki še teče, ko se začne naslednja, poroča o eni napaki dvakrat in je videti kot utripanje.

Korak 4: zlomite vsak sloj in glejte, ali prava sonda postane rdeča

Ustavite proces tunela in potrdite, da kontrola procesa odpove, medtem ko lahko DNS še odgovarja iz predpomnilnika. Spremenite pot in potrdite, da usmerjena zahteva odpove, medtem ko proces in rokovanje ostaneta zdrava. Zlomite samo DNS in potrdite, da kontrola aplikacije poroča o razrešitvi, ne o napaki tunela. Če se dve sondi vedno premikata skupaj, imate manj kontrol, kot mislite.

Preizkusite smer obnovitve z isto disciplino. Ko obnovite sloj, bi se morala sonda počistiti brez ročnega ponovnega zagona, sproženo dejanje pa ne bi smelo pustiti nobenega obhoda. Opazujte en cel cikel, preden zaupate zelenemu stanju, ker sonda, ki se počisti samo ročno, skriva zlomljeno pot obnovitve.

Korak 5: postavite runbook tja, kamor kaže alarm

Ena stran s petimi vrsticami nosi celotno zasnovo: sloj, ukaz, pričakovani rezultat, dejanje ob napaki, lastnik. Dodajte vrstico za vsako sondo o tem, česa namenoma ne preizkuša. Prav ta vrstica prepreči naslednji osebi, da bi dodala šesto kontrolo, ki meri vse in ne razlikuje ničesar. Povežite stran iz besedila alarma, sicer je med incidentom nihče ne bo odprl.

V namestitvah v vsebnike krmili pogoj odvisnosti zagon in nič drugega. Vrstni red zagona in pogoj zdravja v Compose dokumentacija opisuje, kako pripravljenost določa vrstni red zagona storitev; nič od tega pozneje ne uveljavlja izhodne politike in nič od tega ne odpove zaprto, ko tunel pade. Trajno uveljavljanje potrebuje lastno politiko in lastno sondo, napisani na isti strani.

Runbook je končan, ko se pravi sloj obnovi, ne da bi kdo nedosegljivo spletno mesto bral kot zlomljen tunel. To preizkuša dokument, ne tunela.

Sorodni članki