운영 안정성 문제의 핵심 – 가용성

리뷰는 후속 요약 및 개선 사항을 기반으로 작성되었습니다. 그렇다면 안정성 문제를 어떻게 찾고 측정할 수 있을까요? 그렇다면 오늘의 주인공인 가용성을 끌어내야 합니다.

가용성은 비즈니스 안정성을 평가하는 중요한 지표입니다. 데이터 정량화 및 기준 설정을 통해 비즈니스의 주기적인 문제를 발견하고 이를 통해 보다 목표화된 방식으로 서비스 품질을 향상시킬 수 있습니다.

그렇다면 사용성이란 무엇일까요? 가용성은 특정 시간 간격 내에서 기능적 개인이 사용할 수 있는 총 시간의 비율을 나타냅니다. 즉, 일정 기간 내에 시스템이 정상적으로 작동할 수 있는 확률이나 비율을 말합니다. 현재 우리의 인터넷 사업의 대부분은 '실시간'과 '온라인', 즉 실시간 온라인 시스템이다. 대부분의 비즈니스에서 위에서 언급한 지정 시간은 7*24시간이어야 합니다.

사용성 결과는 종종 소수점이나 백분율을 사용하여 표현됩니다. 우리는 일반적으로 소수점 이하 연속되는 9의 수에 해당하는 9라는 숫자를 사용합니다. 예를 들어, "Five Nines"는 지정된 기간 내에 시스템의 가용성이 0.99999(또는 99.999%)임을 의미합니다.

예를 들어 시스템은 1일, 즉 24시간 등 지정된 기간 내에 작동합니다. 동시에 모니터링 단위는 분, 즉 1440분입니다. 우리가 모니터링한 1440분 동안 시스템은 1430분 동안 정상적으로 실행되었습니다. 그런 다음 지정된 기간 내에 시스템 가용성은 1430/1440≒0.99306(99.306%)입니다. 이것이 우리가 종종 두 개의 9라고 부르는 것입니다.

그러면 99.306%의 값은 일반적으로 사용 가능한 가용성 상태의 시스템 비율을 나타내고, 1~99.306%에서 얻은 0.694%의 값은 시스템이 처리할 수 없는 비가용성 상태의 비율을 나타냅니다. 예외. 간단히 공식으로 나열하면 다음과 같습니다.

비즈니스가 온라인에 있는 총 시간 = 비즈니스의 정상적인 이용 가능 시간 + 비즈니스의 비정상적인 비가용 시간

한 단계 더 나아가 유용성은 다음을 의미합니다.

가용성 = 비즈니스의 일반적인 가용성 시간 / 비즈니스가 온라인에 있는 총 시간

사용성이 무엇인지 이해하고, 사용성을 확립하는 방법에 대해 이야기해 보겠습니다. 유용성을 확립하는 방법에는 여러 가지가 있으며 몇 가지 일반적인 방법이 있습니다.

다이얼 테스트 방식은 각 사업의 애플리케이션, 기능, 모듈을 기준으로 각 사업의 운영 상태가 정상인지를 주기적으로 테스트하는 방식이다.

예: 우리 회사에는 A라는 모듈이 있습니다. 그런 다음 사용자 행동을 시뮬레이션하여 정기적으로(예: 5분에 한 번씩) 이 모듈의 실행 상태를 샘플링합니다. 모듈이 정상적으로 실행되면 가용성으로 기록되고, 비정상적으로 실행되면 비가용성으로 기록됩니다. 일정 기간(예: 1일) 내에 누적된 가용성 상태의 비율이 이 모듈의 가용성입니다.

그럼 비즈니스나 모듈의 정상 여부는 어떻게 판단하나요? 웹 형태의 비즈니스를 예로 들어보겠습니다. 해당 서비스의 홈페이지, 카테고리 페이지, 콘텐츠 페이지의 주요 내용을 확인할 수 있습니다. 일반적으로 지정된 페이지의 Head, Body, Bottom의 지정된 필드나 키워드를 일치시킬 수 있습니다. 지정된 필드나 필드 또는 키워드 그룹이 일치할 수 있으면 정상이고, 그렇지 않으면 비정상입니다. 스크립트, Nagios, Zabbix 및 기타 도구를 사용하여 비즈니스에 대한 주기적인 테스트를 구현할 수 있습니다.

이 방법의 장점과 단점은 분명합니다. 이 방법의 장점은 구현하기가 덜 어렵고 사용자 행동을 시뮬레이션하여 측정할 수 있으며 실제 비즈니스 상황과 더 일관성을 가질 수 있다는 것입니다. 그러나 이러한 주기적인 샘플링 방법을 통해서는 샘플링 샘플이 부족하거나 편향되는 문제가 있습니다. 예를 들어, 다이얼 테스트는 5분마다 수행되며, 결함이 발생하고 이 5분 이내에 수리되면 다이얼 테스트 방법으로는 이러한 오류를 포착하기가 어렵습니다.

로그 분석 방식은 각 업체의 애플리케이션, 기능, 모듈 로그를 분석하여 가용성을 확보하는 방식입니다.

예: 우리 회사에 A라는 모듈이 있는데, 이 모듈의 1시간 로그가 주기적으로(예: 한 시간에 한 번) 분석됩니다. 로그 수준과 구별되는 정상적인 요청의 비율은 지난 시간 동안 이 모듈의 가용성입니다. 웹 유형의 비즈니스를 예로 들면, 로그에서 2XX 및 5XX 상태에 대한 통계 및 분석을 수행할 수 있습니다. 2XX는 가용성을 의미하고 5XX는 비가용성을 의미한다는 것을 이해할 수 있습니다. (3XX, 4XX는 실제 사업상황을 토대로 분석 참여 여부를 고려할 수 있습니다)

이 방법은 다이얼 테스트 방법에서 샘플링 샘플이 부족하거나 편향되는 문제를 분명히 해결하지만 실제 비즈니스 영향 지수가 크게 다를 수 있는 상황도 있습니다. 예를 들어 지난 1시간 동안의 오류는 모두 1분 이내에 발생했고 나머지 59분의 업무는 정상이었습니다. 분명히 이러한 방식으로 얻은 가용성과 실제 비즈니스 상황 사이에는 일정한 차이가 있습니다. 그렇다면 이 편차를 해결하는 방법은 무엇입니까? 로그분석 임계값 방식이 등장했습니다.

로그 분석 임계값 방식은 로그 분석 방식을 기반으로 상태 임계값 판단을 추가한 가용성 계획 방식입니다.

예: 우리 회사에는 A라는 모듈이 있습니다. 로그 분석을 통해 정상적인 상황에서 이 모듈에 대한 요청 횟수가 분당 약 100,000회라는 것을 알았습니다. 그러면 임계값을 10회로 설정할 수 있습니다. 이 10번이 의미하는 바는 1분 안에 1만분의 1 미만의 오류가 발생할 수 있다는 것입니다. 1분 이내에 발생한 오류 개수가 10개 미만인 경우 지난 1분 동안의 상태를 정상으로 간주하여 Availability로 표시합니다. 1분 이내에 오류가 10개 이상 발생하면 지난 1분 동안의 상태를 비정상으로 간주하여 사용 불가로 표시합니다. 마지막으로 가용성 상태의 비율이 이 모듈의 가용성으로 계산됩니다. 물론 이 기준점은 기업의 실제 상황에 따라 조정될 필요가 있습니다.

이 방법은 다이얼 테스트 방법의 샘플 편차와 로그 분석 방법의 실제 비즈니스 영향 간의 단절 문제를 효과적으로 해결하고 좋은 균형을 달성합니다.

또 다른 질문이 있습니다. 사업체가 세 개의 모듈 A, B, C로 구성된 경우 모듈의 가용성을 통해 사업의 가용성을 어떻게 계산합니까? 간단한 방법은 가장 많은 3개 모듈의 가용성 평균을 사용하는 것입니다. 하지만 사업 목표에는 문제가 있다. 그런 다음 이를 비즈니스 목표에 맞춰 가중 평균 방법을 사용할 수 있습니다. 예를 들어, 모듈 A가 비즈니스에 더 중요한 경우 가용성을 계산할 때 모듈 A에 더 많은 가중치를 부여합니다. 모듈 C는 비즈니스에 대한 우회 시스템이므로 가용성을 계산할 때 모듈 C의 가중치를 줄일 수 있습니다. 비유하자면, 우리가 도출하는 가용성은 비즈니스 및 비즈니스 목표에 최대한 근접할 수 있습니다.

또한 Keynote 및 Borui와 같은 타사 테스트 플랫폼의 노드를 사용하여 비즈니스에 대한 보다 광범위한 테스트를 수행하여 샘플 수집의 정확성을 높이고 편차를 줄일 수도 있습니다. 물론, 결과는 제3자 플랫폼과 링크의 안정성에 의해 제한됩니다
클라이언트가 있는 기업의 경우 클라이언트의 주요 경로에 대한 관리를 수행한 후, 사용자의 관리 로그를 서버로 중앙 집중화하여 중앙 집중적으로 분석할 수 있습니다. 이 방법은 가장 현실적인 사용자 상태를 반영할 수 있지만, 상대적으로 구현 비용이 높고 로그 업로드가 지연되는 등의 문제도 있습니다.

위에 쓰여진 것보다 가용성을 계산하는 방법이 훨씬 적고, 모든 문제와 문제점을 해결할 수 있는 단일 방법은 없습니다. 비용, 수입, 시간 등의 관점에서 귀하의 비즈니스 또는 팀에 가장 적합한 방법을 하나 이상 선택하고 이를 활용하여 귀하의 비즈니스의 서비스 품질을 지속적으로 향상시켜 보세요.

위 내용은 운영 안정성 문제의 핵심 – 가용성의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!