Одвојите провере здравља VPN-а од провера здравља апликације

Ваш процес тунела може да ради док је заштићена веза неупотребљива, а страница која не успева није доказ да се тунел покварио. Када једна провера заступа све остале, политика поновног покретања поново покреће погрешну компоненту и то назива аутоматизацијом. Свака провера испод наводи слој који посматра, радњу коју њен неуспех покреће и доказ да је радња функционисала. Последњи корак претвара цео скуп у страницу коју неко може да прати у три сата ујутру.

Корак 1: наведите слој који свака провера посматра

Питајте шта свака провера заиста види пре него што напишете било коју од њих. Живост доказује да демон ради, руковање или листа партнера доказује да веза постоји, рутирани захтев доказује испоруку, а претрага доказује резолуцију. Оне отказују тачно тим редом и ниједна не подразумева следећу. Зелена провера процеса поред мртвог тунела је нормалан случај, а не противречност.

Запишите четири провере тим редом, са тачном командом и очекиваним излазом за сваку. Проверу чији очекивани излаз не можете да наведете сваки оператер који види аларм прочитаће другачије. Ставите исту листу у текст аларма, не само у упутство, да би особа пробуђена ноћу срела слој пре симптома. Држите сваку команду спремном за копирање на домаћину који је извршава.

Затим додајте проверу апликације као пету, одвојену ставку. Страница чија је услуга налога пала не оправдава поновно покретање тунела.

Корак 2: повежите сваки неуспех са једном радњом

За сваку проверу одлучите шта се поново покреће, шта остаје блокирано и шта позива човека. Неуспех слоја тунела може да оправда поновно покретање тунела; неуспех резолвера упућује на DNS интеграцију на клијенту; неуспех слоја апликације скоро никада не треба да дотакне тунел.

Реците шта неуспех не сме да уради, јер су опасне подразумеване вредности оне које дозвољавају. Несходно стање никада не сме да постане дозвола за директан саобраћај апликације, јер резервни пут који тихо заобилази тунел уклања разлог постојања тунела. Сузите и радње: поновно покретање дељене компоненте зато што је једно одредиште споро претвара локални проблем у проблем целе флоте. То такође уништава доказ који вам је био потребан да пронађете узрок.

Корак 3: држите провере безопасним и јефтиним

Користите мале захтеве само за читање: статички ресурс, здравствену крајњу тачку која извештава о сопственој зависности или TCP везу ка порту који контролишете. Избегавајте акредитиве, приватно прегледање и све што мења стање у сваком интервалу, јер провера која пише је тест оптерећења по распореду.

Забележите одредиште, очекивање руте и временско ограничење за сваку проверу. Очекивање руте је поље које људи изостављају, и оно је то што раздваја неуспех тунела од грешке у рутирању када касније читате аларм. Изведите интервал и праг неуспеха из времена опоравка које обећавате и држите ограничење краће од интервала. Провера која још ради када следећа почне извештава о једном неуспеху два пута и изгледа као треперење.

Корак 4: сломите сваки слој и гледајте да ли исправна провера постаје црвена

Зауставите процес тунела и потврдите да провера процеса отказује док DNS можда још одговара из кеша. Промените руту и потврдите да рутирани захтев отказује док процес и руковање остају здрави. Сломите само DNS и потврдите да провера апликације извештава о резолуцији, а не о грешци тунела. Ако се две провере увек крећу заједно, имате мање провера него што мислите.

Тестирајте правац опоравка истом дисциплином. Пошто вратите слој, провера би требало да се очисти без ручног поновног покретања, а покренута радња не би требало да остави никакво заобилажење. Посматрајте један пун циклус пре него што поверујете зеленом стању, јер провера која се чисти само ручно крије покварен пут опоравка.

Корак 5: ставите упутство тамо где аларм показује

Једна страница са пет редова носи цео дизајн: слој, команда, очекивани резултат, радња при неуспеху, власник. Додајте ред за сваку проверу о томе шта намерно не тестира. Управо тај ред спречава следећу особу да дода шесту проверу која мери све и не разликује ништа. Повежите страницу из текста аларма, иначе је нико неће отворити док траје инцидент.

У контејнерским распоређивањима, услов зависности обликује покретање и ништа друго. Редослед покретања и здравствено стање у Compose-у документација описује како припремљеност одређује редослед којим услуге почињу; ништа од тога после не спроводи излазну политику и ништа од тога не отказује затворено када тунел падне. Непрекидно спровођење захтева сопствену политику и сопствену проверу, написане на истој страници.

Упутство је готово када се прави слој опорави без тога да неко чита недоступан сајт као покварен тунел. То тестира документ, а не тунел.