VPN 상태 확인과 애플리케이션 상태 확인을 분리하세요

터널 프로세스가 실행 중이어도 보호된 연결은 사용할 수 없을 수 있고, 실패하는 웹 페이지는 터널이 끊겼다는 증거가 아닙니다. 하나의 프로브가 모두를 대표하면 재시작 정책은 잘못된 구성 요소를 재시작하고 그것을 자동화라고 부릅니다. 아래의 각 확인은 관찰하는 계층, 실패가 트리거하는 동작, 그 동작이 통했다는 증거를 밝힙니다. 마지막 단계는 이 전체를 새벽 세 시에 누군가 따라갈 수 있는 페이지로 바꿉니다.

단계 1: 각 확인이 관찰하는 계층을 밝히세요

그중 하나를 쓰기 전에 각 프로브가 실제로 무엇을 볼 수 있는지 물으세요. 생존성은 데몬이 살아 있음을, 핸드셰이크나 피어 목록은 관계가 존재함을, 라우팅된 요청은 전달을, 조회는 이름 해석을 증명합니다. 그것들은 바로 그 순서로 실패하며 어느 것도 다음을 함의하지 않습니다. 초록색 프로세스 확인이죽은 터널 옆에 있는 것은 정상적인 경우이지 모순이 아닙니다.

네 가지 확인을 그 순서로 적고, 각각의 정확한 명령과 예상 출력을 함께 두세요. 예상 출력을 말할 수 없는 프로브는 경보를 보는 모든 운영자가 다르게 읽게 됩니다. 같은 목록을 런북에만 두지 말고 경보 문구에도 넣어, 밤에 깨어난 사람이 증상보다 먼저 계층을 만나게 하세요. 모든 명령은 실행하는 호스트에서 복사할 수 있는 상태로 두세요.

그다음 애플리케이션 확인을 다섯 번째, 별도 항목으로 추가하세요. 계정 서비스가 죽은 페이지는 터널 재시작을 정당화하지 않습니다.

단계 2: 각 실패를 하나의 동작에 연결하세요

각 확인마다 무엇이 재시작되고, 무엇이 차단된 채 남고, 무엇이 사람을 부를지 정하세요. 터널 계층의 실패는 터널 재시작을 정당화할 수 있고, 리졸버 실패는 클라이언트의 DNS 통합을 가리키며, 애플리케이션 계층의 실패는 터널을 거의 건드리지 않아야 합니다.

위험한 기본값은 허용하는 쪽이므로 실패가 해서는 안 되는 일을 적으세요. 불건강한 상태가 직접 애플리케이션 트래픽의 허가가 되어서는 결코 안 되며, 터널을 조용히 우회하는 폴백은 터널이 존재하는 이유를 없애기 때문입니다. 동작도 좁히세요. 한 목적지가 느리다고 공유 구성 요소를 재시작하면 국소 문제가 전체 플릿의 문제가 되며, 원인을 찾는 데 필요한 증거도 파괴합니다.

단계 3: 프로브를 무해하고 저렴하게 유지하세요

작은 읽기 전용 요청(정적 리소스, 자신의 의존성을 보고하는 상태 엔드포인트, 직접 제어하는 포트로의 TCP 연결)을 사용하고, 자격 증명이나 시크릿 브라우징, 매 주기마다 상태를 바꾸는 것은 피하세요. 쓰는 프로브는 일정에 따라 도는 부하 테스트입니다.

각 프로브의 목적지, 경로 기대값, 타임아웃을 기록하세요. 경로 기대값은 사람들이 빠뜨리는 필드이며, 나중에 경보를 읽을 때 터널 실패와 라우팅 오류를 구분하는 것이 바로 이것입니다. 간격과 실패 임계값은 약속한 복구 시간에서 도출하고, 타임아웃은 간격보다 짧게 유지하세요. 다음 프로브가 시작될 때 아직 도는 프로브는 한 번의 실패를 두 번 보고해 흔들림처럼 보입니다.

단계 4: 각 계층을 끊고 올바른 프로브가 빨개지는지 보세요

터널 프로세스를 멈추고 DNS가 아직 캐시에서 응답할 수 있을 때 프로세스 확인이 실패하는지 확인하세요. 경로를 바꾸고 프로세스와 핸드셰이크가 건강한 채로 라우팅된 요청이 실패하는지 확인하세요. DNS만 끊고 애플리케이션 확인이 터널 오류 대신 해석을 보고하는지 확인하세요. 두 프로브가 늘 함께 움직인다면 생각보다 확인이 적습니다.

같은 규율로 복구 방향을 시험하세요. 계층을 되돌린 뒤 프로브는 수동 재시작 없이 풀려야 하고, 발동한 동작은 어떤 우회도 남기지 않아야 합니다. 초록 상태를 믿기 전에 한 주기를 온전히 보는 것은 손으로만 풀리는 프로브가 끊긴 복구 경로를 숨기기 때문입니다.

단계 5: 런북을 경보가 가리키는 곳에 두세요

다섯 줄짜리 한 페이지가 계층, 명령, 예상 결과, 실패 시 동작, 소유자라는 설계 전체를 담습니다. 각 프로브에 대해 의도적으로 시험하지 않는 것을 한 줄로 덧붙이세요. 그 한 줄이 다음 사람이 모든 것을 재고 아무것도 구분하지 않는 여섯 번째 확인을 추가하는 것을 막습니다. 경보 문구에서 페이지를 링크하지 않으면 사고가 진행되는 동안 아무도 열지 않습니다.

컨테이너 배포에서 의존 조건은 시작 순서를 형성할 뿐 그 이상이 아닙니다.Compose 시작 순서와 상태 조건 문서는 준비 상태가 서비스 시작 순서를 어떻게 정하는지 설명하며, 그중 어느 것도 이후에 이그레스 정책을 강제하지 않고 터널이 끊길 때 닫힌 채로 실패하지도 않습니다. 지속적인 강제에는 자체 정책과 자체 프로브가 필요하며, 같은 페이지에 적어야 합니다.

런북은 올바른 계층이 복구되고 아무도 사용할 수 없는 웹사이트를 끊긴 터널로 읽지 않을 때 완성됩니다. 그것은 터널이 아니라 문서를 시험합니다.