검사 목록 - 추가 참조 the-checklist-further-reference

역할

이러한 정보는 명확히 정의되어야 하며 프로젝트에 관련된 모든 사람에게 알려져야 합니다. 또한 다음을 강조 표시하는 것이 좋습니다.

• 의사 결정권자
• 연락처

책임

• 각 역할에 대해 프로젝트와 관련된 책임에 대한 명확한 정의를 통해 혼동을 방지할 수 있습니다.

참여

가능한 한 빨리 관심 있는 사람들을 참여시킴으로써, 여러분은 그들이 되도록 격려할 수 있다 이해 그 프로젝트에서, 그들의 성공에 대한 헌신을 증가시킨다.

• 고객 측면에는 작성자가 포함되어 있으며, 작성자는 매일 시스템과 작업해야 합니다.
• 프로젝트 팀 내에 품질 보증을 담당하는 사람도 포함됩니다. 고객의 요구 사항을 더 잘 이해할수록 테스트를 계획할 수 있습니다.

통신 경로

• 이러한 내용을 과도하게 형식화해서는 안 되지만, 특정 정의는 주요 사람에게 항상 정보를 제공하고 따라서 최신 정보를 유지할 수 있도록 해야 합니다. 외부 당사자와의 소통에 특별한 관심을 기울여야 한다.

프로세스

정의할 프로세스는 개별 프로젝트에 따라 다릅니다. 다음 사항을 고려하여 이러한 간단한 작업을 다시 시도하십시오.

• 타사와 상호 작용할 프로세스(및 통신 경로) 정의 예: 디자인 에이전시 및 기타 소프트웨어 공급업체
• 고객은 종종 고유한 프로젝트 관리 및 보고 절차 및 도구를 갖게 됩니다.

추적 도구

버그, 작업 및 프로젝트의 다른 측면에 대한 정보를 추적하는 데 사용할 수 있는 다양한 도구가 있습니다. 잠재적 도구 개요 자세한 내용

• 여기에서 주목해야 할 핵심 사항은 정보의 한 복사본만 유지하고 정보를 공유하여 사용 중인 도구에 대한 액세스(따라서)하는 것입니다. 이를 통해 유지 관리가 용이하고 불일치를 방지할 수 있습니다.

범위

다양한 수준에서 프로젝트에 의해 다루어야 하는 사항을 명확히 정의합니다.

• 개별 릴리스(반복 릴리스 프로세스가 사용되는 경우 고객에게 제공되는지 내부 테스트 팀에 제공되는지 여부에 상관없이)입니다.
• AEM 프로젝트.
• 전체 프로젝트; 타사 소프트웨어, 테스트에 미치는 영향, 조직 문제 및 기타 여러 가지 사항을 포함합니다.
• 특정 측면에서는 또한 무엇이 무엇인지를 말하는 데 유용할 수 있습니다 not 프로젝트의 범위 내에서 이것은 필수적인 문제로 제한되어야 하지만, 혼동 및 잘못된 가정을 방지하는 데 도움이 될 수 있습니다.

보고

보고할 정보, 어떤 형태, 얼마나 자주, 누구에게 대해 명확히 정의하십시오.

용어

• 사용할 약어 및/또는 고객별 용어를 정의합니다.

가정

• 발생할 가정을 정의합니다.

상업:

• 주요 비즈니스 목표를 측정하는 데 사용됩니다.
• 비즈니스/시나리오에 적합한 KPI를 정의, 측정 방법, 사용 방법 및 누구에 따라 정확하게 선택하는 것이 중요합니다.

공연:

• 시스템의 성능을 측정하는 방법을 정의합니다.
• 페이지 로드 시간, 서버 응답 시간 및 데이터베이스 쿼리 성능이 일부 예제에 해당됩니다.

"저희 웹사이트 너무 느림 오늘" - 언제 이 느린 속도 자격이 있습니까?

"모든 것" 멈추기 위해 분쇄하다 동료가 " - 시스템에서 지원할 수 있는 동시 사용자는 몇 명입니까?

"내가 검색하면, 멈추기 위해 분쇄하다 " - 어떤 종류의 검색 요청이 시스템에 영향을 줍니까?

"시간이 걸리는데 나이 파일을 다운로드하려면" - 일반적인 네트워크 조건에서 다운로드 시간은 어떻게 됩니까?

개별 페이지에 대한 응답 시간 을 고려하여 다음을 고려합니다.

• 작성 환경의 응답 시간
• 게시 환경의 응답 시간

검색 요청에 대한 응답 시간

작성 환경

이 환경은 컨텐츠 입력 및 업데이트 작성자가 사용하므로 다음을 수행해야 합니다.

• 콘텐츠 페이지를 업데이트할 때 높은 수의 요청을 생성하는 소수의 사용자를 대상으로 하며, 해당 페이지의 개별 요소를 제공합니다
• 최대한 빨리 컨텐츠를 웹 사이트로 가져올 수 있도록 생산성을 극대화하십시오

게시 환경

이 환경에는 사용자가 사용할 수 있는 컨텐츠가 포함되어 있습니다.

• 속도는 여전히 중요하지만, 작성 환경보다 속도가 느리는 경우도 종종 있습니다

• 추가 성능 향상 메커니즘이 적용되는 경우가 많습니다.

  • 컨텐츠가 캐시됩니다
  • 로드 밸런싱이 적용됨

AEM request.log를 사용하여 응답 시간 모니터링

성능 분석을 위한 좋은 시작점은 요청 로그입니다. 다른 정보 중에서 이 정보를 사용하여 개별 요청의 응답 시간을 볼 수 있습니다. 자세한 내용은 성능 최적화 자세한 내용

HTML 주석을 사용하여 응답 시간 모니터링

*HTML comments* can be used to include response time information within the source of each page:

</body> </html>v <-- Page took 58 milliseconds to be rendered by the server --> Response times for search requests

실제 검색의 응답 시간

• 빠른 검색 기능은 웹 사이트의 품질 목표입니다

일반 성능에 미치는 영향

• 검색 함수는 컨텐츠의 섹션이나 특별히 추출된 인덱스를 스캔해야 하므로 최적화되지 않은 경우 전체 시스템의 성능에 영향을 줄 수 있습니다

AEM request.log를 사용하여 검색 응답 시간 모니터링

request.log를 사용하여 검색 요청에 대한 응답 시간을 모니터링할 수 있습니다. 참조 성능 최적화 자세한 내용

검색 응답 시간을 측정하기 위한 프로그램 메커니즘

검색 요청 및 해당 성능에 대해 수집하는 정보를 사용자 지정하려면 프로젝트 소스 코드에 정보 수집을 포함하는 것이 좋습니다. 참조 성능 최적화 자세한 내용

작성 환경

• 일반적으로 동시 사용자 수를 정확하게 예측할 수 있습니다. 모두 동시에 활성화되지는 않지만, 총 몇 명의 작성자가 있는지 알 수 있습니다.

게시 환경

• 이것은 예측하기 더 어렵기 때문에 목표 값을 선택해야 합니다. 이는 새 웹 사이트에 대한 현실적인 기대와 함께 현재 웹 사이트의 경험을 기반으로 해야 합니다.
• 특별 이벤트(예: 새롭고 매우 인기 있는 컨텐츠를 게시할 때)는 기대치를 초과할 수 있으며 심지어 기능(특정 이벤트에 대한 티켓이 판매에 제공될 때 언론에 가끔 보고됨)도 초과할 수 있습니다.

볼륨

• 시스템에서 처리 및 전달되는 출력의 양입니다.

용량

• 볼륨을 전달하는 시스템의 기능입니다.
• 각 단계에서 용량 및 볼륨은 아래 표에 표시된 대로 다르게 측정됩니다. 최상의 성능을 위해 각 단계에서 용량이 볼륨과 일치하는지, 용량과 볼륨이 모든 단계에서 공유되는지 확인하십시오. 예를 들어, 모든 요청에 대해 서버에서 탐색하는 대신 클라이언트 컴퓨터에서 탐색을 계산하거나 캐시에 저장할 수 있습니다.

용량 및 볼륨

개발

• 먼저 기본 아키텍처를 정의합니다.

• 개발에 여러 반복(단거리) 사용:

  • 첫 번째 스프린트는 첫 번째 전체 개발 주기와 같습니다.
  • 첫 번째 스프린트는 테스트 환경에 첫 번째 배포를 생성합니다.
  • 모든 스프린트에는 충분한 결과가 있다.
  • 각 스프린트는 고객 사인오프를 받습니다(피드백이 있는 구조화된 테스트의 최소).

• 프로젝트 중에 사용 가능한 AEM 버전 업데이트에 대한 이벤트를 계획합니다.

• 인쇄 기간 동안 테스트 및 최적화를 계획합니다.

• 안정화 및 최적화 단계 계획

• 추가 릴리스에 대해 계획할 항목 로그를 만듭니다.

• 파트너 참여 및 핸드오버 계획

인프라

• 먼저 기본 아키텍처를 정의합니다.

  • 성능 요구 사항을 정의합니다.
  • 성능 목표를 정의합니다(즉, 기대를 명확하게 정의).
  • 하드웨어 및 인프라 아키텍처 정의 크기 조정을 포함합니다.
  • 배포를 정의합니다.

• 여러 반복 사용 첫 번째 스프린트 및 초기 구성의 경우:

  • 개발 환경.
  • 개발 프로세스.
  • 테스트 환경.
  • 배포 프로세스(구성 관리 포함)

• 여러 로드 테스트를 계획합니다.

• 인쇄 기간 동안 테스트 및 최적화를 계획합니다.

• 안정화 및 최적화 단계를 계획합니다.

• 가능한 한 빨리 프로덕션 환경에 배포합니다(작업 팀이 경험을 얻기 위해 시스템을 설정하도록 함).

• 가능한 한 빨리 명명된 사용자를 사용하고 정의된 역할을 사용하십시오.

• 교육 계획(예: 관리자 교육).

• 작업에 대한 핸드오버 계획.

콘텐츠

• 기본 아키텍처:

  • 컨텐츠 계층 구조를 제어합니다.
  • 컨텐츠 개념을 정의하는 데 도움이 됩니다.
  • MSM 사용 및 레이아웃을 정의합니다.
  • 역할, 그룹, 워크플로우 및 권한을 정의합니다.

• 오프라인 페이지 만들기가 유용한지 여부를 고려하십시오.

• 첫 번째 페이지 및 컨텐츠를 미리 만들 계획(테스트 및 피드백에서 사용).

• 기존 컨텐츠 마이그레이션을 계획합니다.

• 리팩터링 후 "스프린트 내 마이그레이션"을 계획합니다.

• "컨텐츠 번다운"(go-live 컨텐츠에 대한 사이트 맵)을 계획합니다.