Separeu les comprovacions de salut de la VPN de les de l’aplicació
Un procés de túnel pot estar en marxa mentre la connexió protegida és inservible, i la ruta protegida, el DNS i la destinació poden fallar per separat. Feu que cada comprovació anomeni la seva capa i l’acció que desencadena.
El vostre procés de túnel pot estar en marxa mentre la connexió protegida és inservible, i una pàgina web que falla no és prova que el túnel s’hagi trencat. Quan una sola sonda representa totes les altres, una política de reinici reinicia el component equivocat i ho anomena automatització. Cada comprovació d’aquí sota anomena la capa que observa, l’acció que desencadena el seu fracàs i l’evidència que l’acció ha funcionat. L’últim pas converteix tot el conjunt en una pàgina que algú pot seguir a les tres de la matinada.
Pas 1: anomeneu la capa que observa cada comprovació
Pregunteu què pot veure realment cada sonda abans d’escriure’n cap. La vivacitat demostra que el dimoni està en marxa, l’encaixada de mans o la llista de parells demostra que la relació existeix, una petició encaminada demostra el lliurament i una consulta demostra la resolució. Fallen exactament en aquest ordre i cap no implica la següent. Una comprovació de procés verda al costat d’un túnel mort és el cas normal, no una contradicció.
Escriviu les quatre comprovacions en aquest ordre, amb l’ordre exacta i la sortida esperada per a cadascuna. Una sonda la sortida esperada de la qual no podeu enunciar la llegirà de manera diferent cada operador que vegi l’alerta. Poseu la mateixa llista al text de l’alerta, no només al manual, perquè la persona despertada de nit trobi la capa abans del símptoma. Mantingueu cada ordre a punt per copiar i enganxar a l’amfitrió que l’executa.
Després afegiu la comprovació de l’aplicació com a cinquè element, separat. Una pàgina el servei de comptes de la qual està caigut no justifica reiniciar el túnel.
Pas 2: lligueu cada fracàs a una sola acció
Per a cada comprovació, decidiu què es reinicia, què queda bloquejat i què avisa una persona. Un fracàs de la capa de túnel pot justificar reiniciar el túnel; un fracàs del resolutor apunta a la integració de DNS al client; un fracàs de la capa d’aplicació gairebé no hauria de tocar mai el túnel.
Digueu què no ha de fer un fracàs, perquè els valors per defecte perillosos són els permissius. Un estat no saludable no s’ha de convertir mai en permís per al trànsit directe de l’aplicació, ja que una via alternativa que evita el túnel en silenci elimina la raó per la qual el túnel existeix. Estrebeu també les accions: reiniciar un component compartit perquè una destinació és lenta converteix un problema local en un problema de tota la flota. També destrueix l’evidència que necessitàveu per trobar la causa.
Pas 3: manteniu les sondes innòcues i barates
Feu servir peticions petites i només de lectura: un recurs estàtic, un punt de salut que informi de la seva pròpia dependència o una connexió TCP a un port que controleu. Eviteu credencials, la navegació privada i qualsevol cosa que modifiqui l’estat a cada interval, perquè una sonda que escriu és una prova de càrrega programada.
Enregistreu la destinació, l’expectativa de ruta i el temps d’espera de cada sonda. L’expectativa de ruta és el camp que la gent omet, i és el que separa un fracàs del túnel d’un error d’encaminament quan llegiu l’alerta més tard. Deriveu l’interval i el llindar de fracàs del temps de recuperació que prometeu, i manteniu el temps d’espera més curt que l’interval. Una sonda que encara s’executa quan comença la següent informa d’un fracàs dues vegades i sembla un parpelleig.
Pas 4: trenqueu cada capa i mireu si la sonda correcta es posa vermella
Atureu el procés del túnel i confirmeu que la comprovació del procés falla mentre el DNS encara pot respondre des de la memòria cau. Canvieu una ruta i confirmeu que la petició encaminada falla mentre el procés i l’encaixada de mans es mantenen saludables. Trenqueu només el DNS i confirmeu que la comprovació de l’aplicació informa de resolució en lloc d’un error de túnel. Si dues sondes es mouen sempre juntes, teniu menys comprovacions del que penseu.
Proveu la direcció de recuperació amb la mateixa disciplina. Després de restaurar la capa, la sonda hauria de netejar-se sense un reinici manual, i l’acció que s’ha disparat no hauria de deixar cap desviament darrere. Observeu un cicle complet abans de confiar en l’estat verd, perquè una sonda que només es neteja a mà amaga un camí de recuperació trencat.
Pas 5: poseu el manual on apunta l’alerta
Una pàgina amb cinc files porta tot el disseny: capa, ordre, resultat esperat, acció en cas de fracàs, propietari. Afegiu una línia per sonda sobre què no prova deliberadament. Aquesta línia és el que impedeix que la següent persona afegeixi una sisena comprovació que ho mesura tot i no en distingeix res. Enllaceu la pàgina des del text de l’alerta, o ningú no l’obrirà mentre la incidència és viva.
En desplegaments de contenidors, una condició de dependència dona forma a l’arrencada i a res més. Ordre d’arrencada i condició de salut de Compose documentació descriu com la disponibilitat determina l’ordre en què arrenquen els serveis; res d’això no aplica cap política de sortida després, i res d’això no falla tancat quan el túnel cau. L’aplicació contínua necessita la seva pròpia política i la seva pròpia sonda, escrites a la mateixa pàgina.
El manual està acabat quan la capa correcta es recupera sense que ningú llegeixi un lloc web no disponible com un túnel trencat. Això posa a prova el document, no el túnel.