환경을 재현 할 수 없을 때 테스트하고 최적화하는 방법은 무엇입니까?

과거에는 다양한 환경에서 일했습니다. 데스크톱 앱, 게임, 내장 된 물건, 웹 서비스, 명령 줄 작업, 웹 사이트, 데이터베이스보고 등 이러한 모든 환경은 동일한 특성을 공유했습니다. 복잡성, 크기에 상관없이 항상 내 컴퓨터 또는 테스트 할 개발 환경에서 응용 프로그램의 하위 집합 또는 슬라이스를 가질 수있었습니다.

오늘은 그렇지 않습니다. 오늘날 저는 확장성에 중점을 둔 환경에 처해 있습니다. 환경을 재생산하는 것은 엄청나게 많은 비용이 든다. 환경 조각을 가져가는 것은 타당하지만 (일부 조각은 시뮬레이션하거나 수행하지 않는 단일 인스턴스 모드에서 사용해야 함) 동시성 및로드를 모호하게하여 목적을 무효화합니다. 실제 시스템이 발생합니다. 작은 "테스트"시스템조차도 결함이 있습니다. 노드가 2 개 있고 노드가 64 개인 경우 상황이 다르게 작동합니다.

중요한 문제에 대한 단계 2와 3을 효과적으로 수행 할 수 없기 때문에 최적화 (측정, 무언가 시도, 정확성 확인, 차이 측정, 반복)에 대한 나의 일반적인 접근 방식은 실제로 작동하지 않습니다. 하중). 이 시나리오는 독특 해 보이지는 않습니다. 이런 종류의 환경에서 이런 종류의 작업을 수행하는 일반적인 방법은 무엇입니까?

몇 가지 관련 질문이 있습니다.

• 이 질문은 (상대적으로) 쉽게 에뮬레이트 할 수있는 하드웨어 (예 : 스펙트럼 분석기)를 사용할 수없는 것과 관련이 있습니다.
• 이 질문은 프로덕션 환경에만 존재하는 버그를 추적하는 데 도움이되지만 다른 종류의 활동에는 도움이됩니다.

실제로 힘든 일이지만, 필적 할만한 많은 상황에서 그것은 주로 조직의 문제라고 확신합니다. 유일하게 실행 가능한 접근 방식은 아마도 "단 하나의 탄알"이 아니라 결합 된 측정 값의 혼합 일 것입니다. 시도해 볼 수있는 것들 :

• 로깅 : 주석에 이미 쓴 것처럼 과도한 시간 및 리소스 로깅 (일부 프로파일 링)은 실제 병목 현상을 식별하는 데 도움이 될 수 있습니다. 대체 구현이 더 잘 작동하는지는 알 수 없지만 응용 프로그램의 완전히 잘못된 부분을 최적화하지 않는 것이 좋습니다.

• 많은 사전 계획을 통해 철저히 테스트 할 수있는 대상을 테스트하십시오. 물론 일마다 생산이 달라 지지만 모든 것은 아닙니다 . 다른 구현의 정확성은 종종 미리 점검 할 수 있습니다. 구현이 제대로 확장된다면 다른 질문입니다. 그러나 계획은 많은 도움이 될 수 있습니다. 테스트 환경이 해결할 수있는 문제와 그렇지 않은 문제에 대해 열심히 생각하십시오. 언뜻보기에는 "미리 테스트 할 수 없다"고 생각하는 것이 거의 있지만, 두 번 생각하면 더 많은 가능성이 있습니다.

• 팀으로 일하십시오. 새로운 접근법이나 아이디어를 시도 할 때는 적어도 한 명의 다른 팀원과상의하십시오. 다른 알고리즘을 구현할 때는 코드 검사 및 QA를 요구하십시오. 미리 피할 수있는 버그와 문제가 많을수록 프로덕션 환경에서 해결해야 할 심각한 문제가 줄어 듭니다.

• 사전에 모든 것을 테스트 할 수 없으므로 프로덕션 환경에서 문제가 발생할 것으로 예상하십시오. 따라서 새로운 코드를 프로덕션 환경에 도입 할 때 정말 좋은 대체 전략을 준비하십시오. 새 코드가 이전 솔루션보다 느리게 작동하거나 충돌 위험이있는 경우 이전 버전으로 최대한 빨리 변경해야합니다. 프로덕션 데이터가 손상 될 위험이있는 경우 적절한 백업 / 복구가 있는지 확인하십시오. 또한 시스템에 유효성 검사 메커니즘을 추가하여 이러한 오류를 감지해야합니다.

• 프로젝트 일지나 솔루션 로그를 진지하게 보관하십시오. 매일 당신은 환경에 대한 새로운 것을 발견하고, 성공 스토리와 실패 스토리를 적어 둡니다. 같은 실패를 두 번하지 마십시오.

따라서 요점은 시도해 볼 수없는 경우 최선의 선택은 보수적이고 고전적인 선행 계획 및 QA 기술입니다.

실제 환경을 재현 할 수없는 경우 불편한 현실은 사용자가 무엇을하든 충분히 테스트되지 않은 것입니다.

그래서 어떻게 할 수 있습니까?

프로세스, 서버 클러스터 또는 데이터베이스 볼륨을 0, 1, 무한대 규칙 으로 테스트해야하는지 여부에 관계없이 확장해야하는 모든 것 하여 잠재적 병목 / 제한이 IO, CPU, CPU로드, 인터 공정 통신 등

이 검사가 끝나면 어떤 종류의 테스트가 영향을 받는지 알아야합니다. 단위 테스트 인 경우 이는 전통적으로 개발자와 함께합니다. 통합 / 시스템 테스트 인 경우 추가 전문 지식이나 더 나은 도구를 지원할 수있는 다른 팀과의 접촉점이있을 수 있습니다.

툴에 관해 말하면, 개발자가 개발 환경에서 가능한 것 이상으로 시스템을로드 테스트하는 것은 실제로는 아닙니다. 이것은 테스트 부서 나 다른 제 3 자에게 푸시되어야합니다.

물론 방 안에있는 코끼리는 시스템이 항상 예측 가능한 방식으로 확장되는 것은 아닙니다!

이전에는 수십억 개의 행이있는 은행 데이터베이스의 DBA였으며 입력 볼륨이 주어진 상태에서 쿼리가 유휴 데이터베이스에 걸리는 시간을 일반적으로 예측할 수있는 실행 계획으로 무장했습니다. 그러나 이러한 볼륨이 특정 크기에 도달하면 쿼리 / 데이터베이스를 조정하지 않으면 실행 계획이 변경되고 성능이 빠르게 저하됩니다.

실험을 제안합니다.

로깅은 병목 현상을 발견합니다. 그런 다음 일부 시스템 또는 특정 확률로 또는 제한된 기간 동안 모든 시스템에서 대체 구현을 시도 할 수 있습니다. 그런 다음 로그를 다시 비교하여 개선 사항을 확인하십시오.

이론과 동일한 측정 측정주기이지만, 가설을 프로덕션에서 실행해야하기 때문에 설정하는 데 비용이 더 많이 들며, 볼륨에 따라 프로덕션에서 중요한 데이터를받는 것도 느려질 수 있습니다.