Jūsu tuneļa process var darboties, kamēr aizsargātais savienojums ir nederīgs, un neveiksmīga tīmekļa lapa nav pierādījums, ka tunelis ir salūzis. Kad viena pārbaude pārstāv visas pārējās, restarta politika restartē nepareizo komponentu un nosauc to par automatizāciju. Katra pārbaude zemāk nosauc slāni, ko tā novēro, darbību, ko izraisa tās neveiksme, un pierādījumu, ka darbība nostrādāja. Pēdējais solis pārvērš visu kopumu lapā, kurai kāds var sekot trijos naktī.

1. solis: nosauciet slāni, ko novēro katra pārbaude

Pirms rakstāt jebkuru no tām, pajautājiet, ko katra pārbaude patiešām var redzēt. Dzīvotspēja pierāda, ka dēmons darbojas, rokasspiediens vai vienaudžu saraksts pierāda, ka attiecības pastāv, maršrutēts pieprasījums pierāda piegādi, un meklēšana pierāda atrisinājumu. Tās neizdodas tieši šajā secībā, un neviena no tām nenozīmē nākamo. Zaļa procesa pārbaude blakus mirušam tunelim ir normāls gadījums, nevis pretruna.

Pierakstiet četras pārbaudes šajā secībā, ar precīzu komandu un gaidīto izvadi katrai. Pārbaudi, kuras gaidīto izvadi jūs nevarat nosaukt, katrs operators, kas redz trauksmi, lasīs citādi. Ievietojiet to pašu sarakstu trauksmes tekstā, ne tikai rokasgrāmatā, lai naktī pamodinātais cilvēks slāni satiktu pirms simptoma. Turiet katru komandu gatavu kopēšanai tajā saimnieknodē, kas to izpilda.

Pēc tam pievienojiet lietotnes pārbaudi kā piekto, atsevišķo punktu. Lapa, kuras konta pakalpojums ir izslēgts, neattaisno tuneļa restartu.

2. solis: saistiet katru neveiksmi ar vienu darbību

Katrai pārbaudei izlemiet, kas tiek restartēts, kas paliek bloķēts un kas izsauc cilvēku. Tuneļa slāņa neveiksme var attaisnot tuneļa restartu; atrisinātāja neveiksme norāda uz DNS integrāciju klientā; lietotnes slāņa neveiksmei gandrīz nekad nevajadzētu skart tuneli.

Pasakiet, ko neveiksme nedrīkst darīt, jo bīstamās noklusējuma vērtības ir atļaujošās. Neveselīgs statuss nekad nedrīkst kļūt par atļauju tiešai lietotnes plūsmai, jo rezerves ceļš, kas klusi apiet tuneli, atņem tuneļa pastāvēšanas iemeslu. Sašauriniet arī darbības: koplietota komponenta restarts tāpēc, ka viens galamērķis ir lēns, pārvērš vietēju problēmu problēmā visai flotei. Tas arī iznīcina pierādījumu, kas bija vajadzīgs cēloņa atrašanai.

3. solis: turiet pārbaudes nekaitīgas un lētas

Izmantojiet mazus, tikai lasīšanas pieprasījumus: statisku resursu, veselības galapunktu, kas ziņo par savu atkarību, vai TCP savienojumu ar portu, kuru jūs kontrolējat. Izvairieties no akreditācijas datiem, privātās pārlūkošanas un visa, kas maina stāvokli katrā intervālā, jo pārbaude, kas raksta, ir slodzes tests pēc grafika.

Reģistrējiet galamērķi, maršruta gaidas un taimautu katrai pārbaudei. Maršruta gaidas ir lauks, ko cilvēki izlaiž, un tieši tas atdala tuneļa neveiksmi no maršrutēšanas kļūdas, kad vēlāk lasāt trauksmi. Atvasiniet intervālu un neveiksmes slieksni no solītā atjaunošanas laika un turiet taimautu īsāku par intervālu. Pārbaude, kas joprojām darbojas, kad sākas nākamā, ziņo par vienu neveiksmi divreiz un izskatās kā mirgošana.

4. solis: salauziet katru slāni un vērojiet, vai pareizā pārbaude kļūst sarkana

Apturiet tuneļa procesu un apstipriniet, ka procesa pārbaude neizdodas, kamēr DNS vēl var atbildēt no kešatmiņas. Nomainiet maršrutu un apstipriniet, ka maršrutētais pieprasījums neizdodas, kamēr process un rokasspiediens paliek veseli. Salauziet tikai DNS un apstipriniet, ka lietotnes pārbaude ziņo par atrisinājumu, nevis tuneļa kļūdu. Ja divas pārbaudes vienmēr kustas kopā, jums ir mazāk pārbaužu, nekā domājat.

Pārbaudiet atjaunošanas virzienu ar to pašu disciplīnu. Pēc slāņa atjaunošanas pārbaudei vajadzētu izzust bez manuāla restarta, un iedarbinātajai darbībai nevajadzētu atstāt nekādu apiešanas ceļu. Novērojiet vienu pilnu ciklu, pirms uzticaties zaļajam stāvoklim, jo pārbaude, kas izzūd tikai ar roku, slēpj salauztu atjaunošanas ceļu.

5. solis: novietojiet rokasgrāmatu tur, kur rāda trauksme

Viena lapa ar piecām rindām nes visu dizainu: slānis, komanda, gaidītais rezultāts, darbība neveiksmes gadījumā, īpašnieks. Pievienojiet rindu katrai pārbaudei par to, ko tā apzināti nepārbauda. Tieši šī rinda neļauj nākamajam cilvēkam pievienot sesto pārbaudi, kas mēra visu un neko neatšķir. Sasaistiet lapu no trauksmes teksta, citādi neviens to neatvērs, kamēr incidents ir aktīvs.

Konteinera izvietojumos atkarības nosacījums veido palaišanu un neko citu. Compose palaišanas secība un veselības nosacījums dokumentācija apraksta, kā gatavība nosaka secību, kādā pakalpojumi tiek palaisti; nekas no tā pēc tam nepiemēro izejas politiku, un nekas no tā neizdodas slēgti, kad tunelis krīt. Nepārtrauktai izpildei vajadzīga sava politika un sava pārbaude, rakstītas tajā pašā lapā.

Rokasgrāmata ir pabeigta, kad pareizais slānis atjaunojas un neviens nepieejamu vietni nelasa kā salauztu tuneli. Tas pārbauda dokumentu, nevis tuneli.

Saistītie raksti