팀이 비용을 설계할 수 있도록 지원

비용 최적화는 Well-Architected Framework의 기반입니다. 초기 결정 지점에서 환경에 포함된 문제를 해결하기에 너무 늦고 경제적이지 않은 경우, 개발자와 엔지니어링 팀이 사후에 워크로드를 최적화할 필요가 없도록 방지합니다.

비용을 설계할 수 있는 역량을 갖춘 팀은 신속하게 반복하고 시간이 지남에 따라 학습할 수 있으므로 모범 사례가 일상적인 작업에 포함되도록 할 수 있습니다. 다음 사례를 통해 팀은 비용을 설계할 수 있습니다.

• 가시성을 확보하고 도구를 사용하여 일관성 있는 보고, 측정 및 책임을 촉진함으로써 투명성을 증진하고 촉진합니다.

• 올바른 작업을 수행할 때 긍정적인 인센티브를 만들어 올바른 유형의 작업을 증진합니다(예: 최적화를 강조하는 관리자 메일 우선 적용).

• 민첩성을 유지하면서 제어 정책을 수립합니다(예: 크기를 초과한 리소스를 파악하고 해결하는 프로세스 마련, 업무 외 시간에 비프로덕션 리소스를 끌 수 있는 옵트아웃 정책).

다음은 비용 최적화 행동을 유도하는 데 도움이 되는 몇 가지 아이디어입니다.

• 인센티브 – 여기에는 결과에 기반한 리더십의 긍정적인 커뮤니케이션뿐만 아니라 지표의 시각화 및 게임화가 포함됩니다. 리더십은 팀이 효율성과 절약의 중요성을 이해하도록 장려하고 개발자와 엔지니어가 의사 결정의 비용 영향을 고려하도록 도와줍니다. 또한 비효율성을 방지할 수 있는 방법을 제공합니다.

• 사용자에 대한 비용 차지백 – 차지백은 비즈니스 사용자가 IT 효율성에 주의를 기울일 수 있는 인센티브를 제공합니다. 이로 인해 IT는 비용 센터가 아닌 비즈니스에서 사용하고 비용을 지불하는 리소스로 취급됩니다.

• 프로세스 장애물 제거 – 때때로 개발자와 엔지니어가 최적화를 수행하는 것을 제한하는 장애물이 있습니다. 예를 들어 환경에 대한 변화가 있는 경우 변경 검토 프로세스를 거치도록 요구하는 정책이 시행될 수 있습니다. 이는 적절한 크기 조정과 탄력성을 촉진하기 위한 이니셔티브에 방해가 됩니다. 이러한 정책을 수정하면 최적화 노력을 간소화할 수 있습니다.

• 민첩한 작업 방법 – 설계 반복 주기에 비용을 지표로 포함하면 더 낮은 비용으로 동일하거나 더 나은 결과를 제공할 수 있는 조직의 역량이 시간이 지남에 따라 향상됩니다.

• 교육 및 온보딩 – 개인은 일반적으로 알고 있는 도구와 기술을 사용하여 문제를 해결합니다. 이는 효율성을 극대화하기 위한 최신 사례를 통합하는 교육 및 온보딩을 통해 해결할 수 있습니다(예: 서버리스 아키텍처 사용, Amazon Cloudfront를 사용하여 컴퓨팅 수요 감소).

다음 접근 방식도 효과적일 수 있지만 주의해서 구현하지 않으면 민첩성에 위험이 발생할 수 있습니다.

• 경영진 지원/압박 – 모범 사례에 대한 지원은 직원 만족도에 긍정적인 영향을 미치므로 비용에 압박을 가하는 것보다 더 선호됩니다. 비용 압박으로 인해 비효율성을 숨기기 위한 인센티브를 형성하고 예산 제한으로 이어져 민첩성과 혁신에 대한 능력이 상실될 수 있습니다.

• 아키텍처 검토 – 일반적으로 아키텍처 검토(또는 선택적 검토)와 필수 검토 사이에는 적절한 균형이 있습니다. 과도한 필수 검토로 인해 병목 현상이 발생할 수 있습니다. 각 조직이 정의한 경계에 따라 고수익 및 고비용 프로젝트를 검토해야 될 수 있습니다.

• 오케스트레이션 제어 – 프로젝트와 리소스에 대한 승인 워크플로는 재정과 예산을 보호하기 위해 민첩성과 혁신에 위험을 야기합니다. 제어와 민첩성의 균형을 유지하는 한 가지 방법은 수익 창출 서비스에 대한 비용 관리 권한을 적게(또는 아예 없이) 부여하는 것입니다. 이러한 서비스에 대한 고급 지표를 보유하면 균형을 유지할 수 있습니다.