COST10-BP01 워크로드 검토 프로세스 개발
워크로드 검토 기준과 프로세스를 정의하는 프로세스를 개발합니다. 검토 작업에는 잠재적 이점이 반영되어야 합니다. 예를 들어 핵심 워크로드와 비용이 청구 금액의 10%보다 많은 워크로드는 분기별로 검토하고, 비용이 청구 금액의 10%보다 적은 워크로드는 연 1회 검토할 수 있습니다.
이 모범 사례를 정립하지 않을 경우 노출되는 위험의 수준: 높음
구현 가이드
항상 가장 비용 효율적인 워크로드를 유지하려면 워크로드를 정기적으로 검토하여 새로운 서비스, 기능 및 구성 요소를 구현할 기회가 있는지 확인해야 합니다. 전반적인 비용 절감을 실현하려면 검토 프로세스가 잠재적인 절감액에 비례해야 합니다. 예를 들어 전체 지출의 50%를 차지하는 워크로드는 전체 지출의 5%를 차지하는 워크로드보다 더 정기적으로, 더 철저히 검토되어야 합니다. 외부 요인 또는 변동성 고려. 워크로드가 특정 지역 또는 시장 부문에 서비스를 제공하고 있고 해당 영역의 변화가 예측되는 경우에는 자주 검토하여 비용을 절감할 수 있습니다. 검토에서 고려할 또 다른 요인은 변경 구현에 들어가는 노력입니다. 변경 사항을 테스트하고 검증하는 데 상당한 비용이 발생한다면 검토 빈도를 줄여야 합니다.
오래된 레거시 구성 요소 및 리소스를 유지 관리하는 데 드는 장기적인 비용과 여기에 새로운 기능을 구현할 수 없다는 점을 고려하십시오. 현재의 테스트 및 검증 비용이 제안된 이점을 상회할 수 있습니다. 그러나 시간이 지남에 따라 워크로드와 현재 기술 간의 격차가 증가하면 변경 비용이 크게 증가하여 비용이 훨씬 높아질 수 있습니다. 예를 들어 새로운 프로그래밍 언어로 이동하는 비용은 현재로서 비용 효율적이지 않을 수 있습니다. 하지만 5년 안에는 해당 언어에 숙련된 인력을 구하는 비용이 증가할 수 있으며, 워크로드 증가로 인해 더 큰 시스템을 새로운 언어로 전환하는 데 이전보다 더 많은 노력이 필요하게 될 것입니다.
워크로드를 구성 요소로 나누고 구성 요소의 비용을 할당한 다음(추정치로 충분함) 각 구성 요소 옆에 요인(예: 작업에 들어가는 노력 및 외부 시장 요인)을 나열하십시오. 이러한 지표를 사용하여 각 워크로드에 대한 검토 빈도를 결정합니다. 예를 들어 높은 비용, 낮은 변경 노력 및 높은 외부 요인으로 분류되는 웹 서버의 경우 검토 빈도가 높을 수 있습니다. 중앙 데이터베이스는 중간 비용, 높은 변화 노력, 낮은 외부 요인으로 분류되므로 검토 빈도는 중간일 수 있습니다.
구현 단계
-
검토 빈도 정의: 워크로드 및 해당 구성 요소를 검토해야 하는 빈도를 정의합니다. 이는 여러 가지 요소를 조합한 것으로 조직 내 워크로드마다 다를 수 있으며 워크로드의 구성 요소마다 다를 수 있습니다. 일반적인 요인으로는 수익 또는 브랜드 측면에서 측정한 조직에 대한 중요성, 워크로드의 총 실행 비용(운영 및 리소스 비용 포함), 워크로드의 복잡성, 변경 실행 용이성, 소프트웨어 라이선스 계약, 변경으로 인해 징벌적 라이선스에 의한 라이선스 비용이 크게 증가하는지 여부 등이 있습니다. 기능적 또는 기술적으로 구성 요소를 정의할 수 있습니다(예: 웹 서버 및 데이터베이스, 컴퓨팅 및 스토리지 리소스). 요인을 적절히 절충하고 워크로드와 해당 구성 요소에 대한 기간을 정하십시오. 18개월마다 전체 워크로드를 검토하고, 6개월마다 웹 서버를 검토하고, 12개월마다 데이터베이스를 검토하고, 6개월마다 컴퓨팅 및 단기 스토리지를 검토하고, 12개월마다 장기 스토리지를 검토하기로 결정할 수 있습니다.
-
검토 완전성 정의: 워크로드 또는 워크로드 구성 요소를 검토하는 데 얼마나 많은 노력이 드는지 정의합니다. 검토 빈도와 마찬가지로 여러 가지 요소를 비교 검토하여 절충해야 합니다. 데이터베이스 구성 요소 분석에 1주를 할애하고 스토리지 검토에 4시간을 할애할 수 있습니다.
리소스
관련 문서:
