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

역할

역할을 명확하게 정의해야 하며 프로젝트에 참여하는 모든 사람이 해당 역할을 알고 있어야 합니다. 또한 다음 사항을 강조하는 것이 좋습니다.

• 의사 결정자
• 담당자

책임

• 각 역할에 대해 프로젝트와 관련된 책임을 명확하게 정의하면 혼란을 방지하는 데 도움이 됩니다.

참여

관심 있는 당사자를 가능한 한 빨리 참여시키면 해당 당사자가 프로젝트의 이해 당사자 ​가 되도록 장려할 수 있습니다. 그러면 프로젝트를 성공적으로 완수하기 위한 참여 의지가 높아집니다.

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

커뮤니케이션 경로

• 커뮤니케이션 경로를 지나치게 공식화해서는 안 되지만, 구체적인 정의를 통해 주요 인물이 항상 정보를 얻고 프로젝트의 최신 진행 상태를 파악할 수 있도록 해야 합니다. 외부 당사자와 커뮤니케이션할 때는 특별한 주의를 기울여야 합니다.

프로세스

정의된 프로세스는 개별 프로젝트에 따라 달라집니다. 다음 사항을 고려하면서 해당 프로세스를 단순하게 유지하십시오.

• 디자인 기관, 서드파티 소프트웨어 공급업체 등 서드파티와의 상호 작용을 위한 프로세스(및 커뮤니케이션 경로)를 정의합니다.
• 종종 고객은 프로젝트 관리 및 보고 절차와 도구를 자체적으로 가지고 있습니다.

추적 도구

프로젝트의 버그, 작업 및 기타 측면에 대한 정보를 추적하는 데 사용할 수 있는 도구가 많이 있습니다. 자세한 내용은 사용 가능한 도구 개요를 참조하십시오.

• 여기서 주목해야 할 핵심은 정보 사본을 하나만 보관하고 해당 정보(사용 중인 도구에 대한 액세스 포함)를 공유하는 것입니다. 이 워크플로는 유지 관리를 용이하게 하고 불일치를 방지하는 데 도움이 됩니다.

범위

프로젝트에서 다양한 수준에 맞춰 다루어야 할 내용을 명확하게 정의합니다.

• 개별 릴리스(반복적인 릴리스 프로세스를 사용하고 릴리스 제공 대상이 고객이든, 내부 테스트 팀이든 상관없이 적용되는 경우)
• AEM 프로젝트
• 서드파티 소프트웨어, 테스트에 미치는 영향, 조직적인 문제 및 기타 여러 사항이 포함된 전체 프로젝트
• 특정 측면에서는 프로젝트 범위에 포함되지 않는 사항을 명시하는 것도 유용할 수 있습니다. 이러한 아이디어는 혼란과 잘못된 가정을 방지하는 데 도움이 되지만, 필수적인 문제에만 국한되어야 합니다.

보고

보고할 정보, 보고 형태, 보고 빈도, 보고 대상을 명확하게 정의합니다.

용어

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

가정

• 가정할 사항을 정의합니다.

비즈니스:

• 주요 비즈니스 목표를 측정하는 데 사용됩니다.
• 비즈니스/시나리오에 적합한 KPI를 선택하는 것이 중요합니다. KPI가 무엇인지, KPI를 어떻게 측정하고 사용하는지, KPI를 누가 사용하는지를 명확하게 정의해야 합니다.

성능:

• 시스템 성능을 측정하는 방법을 정의합니다.
• 몇 가지 예로는 페이지 로드 시간, 서버 응답 시간, 데이터베이스 쿼리 성능이 있습니다.

“오늘 웹 사이트가 너무 느립니다.” - 어떤 경우여야 느리다 ​라고 할 수 있습니까?

“동료가 로그인하는 순간 모든 것이 멈춥니다.” - 시스템에서 지원할 수 있는 동시 사용자 수는 몇 명입니까?

“검색하는 순간 시스템이 멈춥니다.” - 시스템에 영향을 미치고 있는 검색 요청은 무엇입니까?

“파일을 다운로드하는 데 시간이 너무 오래 걸립니다.” - 정상적인 네트워크 상태에서 허용되는 다운로드 시간은 얼마입니까?

다음을 고려한 개별 페이지의 응답 시간

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

검색 요청에 대한 응답 시간

작성자 환경

이 환경은 작성자가 콘텐츠를 입력하고 업데이트하는 데 사용되므로 다음과 같아야 합니다.

• 콘텐츠 페이지와 해당 페이지의 개별 요소를 업데이트할 때 많은 수의 요청을 생성하는 소수 사용자의 요구를 충족해야 합니다.
• 콘텐츠를 웹 사이트에 게시하는 생산성을 극대화하기 위해 가능한 한 빠르게 작동해야 합니다.

게시 환경

이 환경에는 사용자에게 제공하는 콘텐츠가 포함되어 있습니다.

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

• 추가적인 성능 향상 메커니즘이 종종 적용됩니다.

  • 콘텐츠가 캐시됩니다.
  • 부하 분산이 적용됩니다.

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는 검색 요청에 대한 응답 시간을 모니터링하는 데 사용할 수 있습니다. 자세한 내용은 성능 최적화를 참조하십시오.

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

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

작성자 환경

• 일반적으로 동시 사용자 수를 정확하게 추정할 수 있습니다. 전체 작성자 수는 알 수 있지만, 모두가 동시에 활성 상태인 것은 아닐 것입니다.

게시 환경

• 게시 환경은 예측하기가 더 어렵기 때문에 목표 값을 선택해야 합니다. 즉, 현재 웹 사이트에 대한 경험과 새 웹 사이트에 대한 현실적인 기대치를 기반으로 해야 합니다.
• 특별 이벤트(예: 새로운 인기 콘텐츠를 게시하는 경우)가 발생하면 (특정 이벤트 티켓이 판매될 때 언론에 보도되는 경우처럼) 기대치를 넘어서거나 성능을 초과할 수도 있습니다.

볼륨

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

용량

• 시스템에서 해당 볼륨을 전달하는 능력입니다.
• 아래 표에 나와 있듯이 단계마다 용량과 볼륨이 서로 다르게 측정됩니다. 최상의 성능을 얻으려면 각 단계의 용량이 볼륨과 일치하고 모든 단계에서 용량과 볼륨이 공유되어야 합니다. 예를 들어 요청이 발생할 때마다 탐색을 서버에서 계산하는 대신 클라이언트 컴퓨터에서 계산하거나 캐시에 넣을 수도 있습니다.

용량 및 볼륨

개발

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

• 개발을 위해 여러 번의 반복(스프린트)을 사용합니다.

  • 첫 번째 스프린트는 첫 번째 전체 개발 주기에 해당합니다.
  • 첫 번째 스프린트는 테스트 환경에 대한 첫 번째 배포로 이어집니다.
  • 모든 스프린트에는 실행 가능한 결과가 있습니다.
  • 각 스프린트에서 고객 승인(피드백이 포함된 최소한의 구조화된 테스트)을 받습니다.

• 프로젝트 진행 중에 사용 가능한 AEM 버전을 업데이트할 가능성에 대비한 계획을 수립합니다.

• 스프린트 동안 테스트와 최적화를 계획합니다.

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

• 향후 릴리스를 위해 계획해야 할 항목에 대한 로그를 작성합니다.

• 파트너 참여 및 인수인계를 계획합니다.

인프라

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

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

• 여러 번의 반복을 사용합니다. 첫 번째 스프린트와 초기 구성을 위해 다음 사항을 준비합니다.

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

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

• 스프린트 동안 테스트와 최적화를 계획합니다.

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

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

• 가능한 한 빨리 명명된 사용자와 정의된 역할을 사용합니다.

• 교육(예: 관리자 교육)을 계획합니다.

• 운영 팀으로의 인수인계를 계획합니다.

콘텐츠

• 기본 아키텍처는 다음과 같습니다.

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

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

• 테스트와 피드백에 사용할 첫 번째 페이지와 콘텐츠를 조기에 만들 계획을 수립합니다.

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

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

• '콘텐츠 번다운'(Go-Live 콘텐츠에 대한 사이트맵)을 계획합니다.