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

역할

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

• 의사 결정자
• 연락처

책임

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

관여

이해 관계자들을 가능한 한 빨리 참여시킴으로써, 당신은 그들이 될 수 있도록 격려할 수 있습니다 이해 당사자 을 클릭합니다. 그렇게 하면 성공에 대한 그들의 헌신이 높아집니다.

• 고객 측면에서는 이 역할에 매일 시스템을 사용하는 작성자가 포함됩니다
• 자체 프로젝트 팀 내에서 이 참여에는 품질 보증을 담당하는 사람도 포함됩니다. 고객의 요구 사항을 더 잘 이해할수록 테스트를 더 잘 계획할 수 있습니다.

통신 경로

• 커뮤니케이션 경로가 지나치게 형식화되어서는 안 되지만, 구체적인 정의를 통해 주요 사용자에게 항상 정보가 제공되므로 최신 정보를 유지해야 합니다. 외부 당사자와의 의사소통에 특히 주의를 기울여야 한다.

프로세스

정의된 프로세스는 개별 프로젝트에 따라 다릅니다. 다시 한 번, 다음 사항을 고려하여 이러한 프로세스를 단순하게 유지하십시오.

• 설계 에이전시 및 타사 소프트웨어 공급업체 등 서드파티와 상호 작용하기 위한 프로세스(및 커뮤니케이션 경로)를 정의합니다.
• 고객은 프로젝트 관리 및 보고 절차 및 도구를 보유한 경우가 많습니다.

추적 도구

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

• 여기서 주목할 점은 정보의 사본을 하나만 보관하고 정보를 공유(따라서 사용 중인 도구에 대한 액세스)하는 것입니다. 이 워크플로우에서는 유지 관리가 쉬워지며 불일치를 방지할 수 있습니다.

범위

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

• 개별 릴리스(반복 릴리스 프로세스를 사용하는 경우 및 고객에게 전달되었는지 내부 테스트 팀에 전달되었는지 여부에 상관없이).
• AEM 프로젝트.
• 타사 소프트웨어, 테스트에 미치는 영향, 조직 문제 등 전체 프로젝트.
• 특정 측면들에 대해, 무엇이 무엇인지를 서술하는 것도 유용할 수 있다 아님 프로젝트의 범위 내에서. 이 아이디어는 필수적인 문제로 제한되어야 하지만 혼란과 잘못된 가정을 방지하는 데 도움이 될 수 있습니다.

보고

보고하려는 정보, 보고 형식, 빈도 및 대상을 명확히 정의합니다.

용어

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

가정

• 수행되는 모든 가정을 정의합니다.

비즈니스:

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

성능:

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

"웹 사이트는 너무 느림 today" - 언제 느림 선별?

"모두" 서서히 멈추다 내 동료가 로그인할 때" - 시스템이 지원할 수 있는 동시 사용자 수

"검색하면 시스템이 서서히 멈추다 " - 어떤 검색 요청이 시스템에 영향을 줍니까?

"시간이 걸린다 세 파일을 다운로드하려면" - 정상적인 네트워크 조건에서 허용되는 다운로드 시간은 얼마입니까?

다음 사항을 설명하는 개별 페이지의 응답 시간:

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

검색 요청에 대한 응답 시간

작성 환경

이 환경은 컨텐츠를 입력하고 업데이트하는 작성자에 의해 사용되므로 다음 작업을 수행해야 합니다.

• 콘텐츠 페이지 및 해당 페이지의 개별 요소를 업데이트할 때 많은 요청을 생성하는 일부 사용자를 위한 기능입니다
• 가능한 한 빨리 콘텐츠를 웹 사이트로 가져올 수 있도록 생산성을 극대화하십시오.

게시 환경

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

• 속도는 여전히 중요하지만 작성자 환경보다 느린 경우가 많습니다

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

  • 콘텐츠가 캐시됨
  • 로드 밸런싱이 적용됨

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

성능 분석의 좋은 시작점은 요청 로그입니다. 여러 정보 중에서 개별 요청의 응답 시간을 볼 수 있습니다. 다음을 참조하십시오 성능 최적화 을 참조하십시오.

HTML 댓글로 응답 시간 모니터링

HTML 주석을 사용하여 각 페이지의 소스 내에 응답 시간 정보를 포함할 수 있습니다.

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

실제 검색의 응답 시간

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

일반 성능에 미치는 영향

• 검색 기능은 콘텐츠의 (잠재적으로 큰) 섹션 또는 특별히 추출된 인덱스를 스캔해야 하므로 최적화되지 않은 경우 전체 시스템의 성능에 영향을 줄 수 있습니다

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

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

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

검색 요청과 그 성능에 대해 수집하는 정보를 사용자 정의하려면 프로젝트 소스 코드에 정보 수집을 포함하는 것이 좋습니다. 를 참조하십시오. 성능 최적화 을 참조하십시오.

작성 환경

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

게시 환경

• 게시 환경은 예측하기 더 어렵기 때문에 타겟 값을 선택해야 합니다. 다시 말하지만, 이는 새 웹 사이트에 대한 현실적인 기대와 함께 현재 웹 사이트의 경험을 기반으로 해야 합니다.
• 특별 이벤트(예: 새로운 인기 콘텐츠를 게시하는 경우)는 기대치를 초과할 수 있습니다. 또는 기능(특정 이벤트 티켓이 판매될 때 언론에 보도되는 것과 같이)도 초과할 수 있습니다.

볼륨

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

용량

• 볼륨을 전달하는 시스템의 기능입니다.
• 각 단계별로 아래 표와 같이 용량과 부피가 다르게 측정된다. 최상의 성능을 얻으려면 각 단계에서 용량이 볼륨과 일치하는지, 모든 단계에서 용량과 볼륨을 모두 공유해야 합니다. 예를 들어, 모든 요청에 대해 서버에서 탐색을 계산하는 대신 클라이언트 컴퓨터에서 탐색을 계산하거나 캐시에 저장할 수 있습니다.

용량 및 볼륨

개발

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

• 개발에 여러 번 반복(sprints)을 사용합니다.

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

• 프로젝트 진행 중 사용 가능한 AEM 버전 업데이트의 최종 결과를 계획합니다.

• 단거리 훈련 중 테스트 및 최적화를 계획합니다.

• 안정화 및 최적화 단계에 대한 계획.

• 추가 릴리스를 위해 계획될 항목의 로그를 만듭니다.

• 파트너 참여 및 인계 계획.

인프라

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

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

• 첫 번째 스프린트 및 초기 구성 준비에 대해 여러 번 반복을 사용합니다.

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

• 여러 부하 테스트를 계획합니다.

• 단거리 훈련 중 테스트 및 최적화를 계획합니다.

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

• 가능한 한 빨리 프로덕션 환경에 배포합니다(운영 팀이 환경을 구축하도록 시스템 설정).

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

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

• 작전으로의 이관 계획.

콘텐츠

• 기본 아키텍처:

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

• 오프라인 페이지 생성이 유용한지 여부를 고려합니다.

• 첫 번째 페이지 및 콘텐츠의 조기 생성을 계획합니다(테스트 및 피드백에 사용).

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

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

• "콘텐츠 번다운" 계획(Go-Live 콘텐츠의 사이트 맵).