일반적인 클라우드 운영 모델 검토 및 비교

운영 모델은 현재 요구 사항 및 제약 조건에 따라 지원하는 비즈니스에 고유하고 구체적입니다. 그러나 운영 모델은 눈송이않습니다. 고객 운영 모델에는 몇 가지 일반적인 패턴이 있습니다. 이 문서에서는 가장 일반적인 네 가지 패턴을 간략하게 설명합니다.

운영 모델 비교

다음 이미지는 가장 복잡한(분산)에서 가장 복잡한(전역 작업)에 이르기까지 복잡성 범위에 따라 일반적인 운영 모델을 매핑합니다. 다음 표에서는 몇 가지 다른 특성의 상대 값을 기준으로 동일한 운영 모델을 비교합니다.

우선 순위 또는 범위

클라우드 운영 모델은 주로 다음 두 가지 요인에 의해 구동됩니다.

• 전략적 우선 순위 또는 동기
• 관리할 포트폴리오의 범위

• 전략적 우선 순위 또는 동기: 각 운영 모델은 클라우드 채택대한 일반적인 전략적 동기를 제공합니다. 그러나 일부 운영 모델은 특정 동기를 간소화합니다.

• 포트폴리오 범위: 포트폴리오 범위는 특정 운영 모델 디자인에서 지원하는 가장 큰 범위를 식별합니다. 예를 들어 중앙 집중식 작업은 몇 개의 랜딩 존을 위해 설계되었습니다. 그러나 운영 모델 결정으로 조직에 운영 위험이 발생할 수 있습니다. 운영 위험은 대규모 복잡한 포트폴리오를 관리하려고 할 때 발생합니다. 이러한 포트폴리오에는 랜딩 존 설계에 많은 랜딩 존 또는 가변적인 복잡성이 필요할 수 있습니다.

책임 조정

많은 팀과 개인이 다양한 기능을 지원해야 합니다. 그러나 각 공통 운영 모델은 의사 결정 결과에 대한 최종 책임을 한 팀 또는 개인에게 할당합니다. 이 방법은 운영 모델의 자금 지원 방법과 각 함수에 대해 제공되는 지원 수준에 영향을 줍니다.

Azure에서 운영 모델 구현 가속화

운영 모델정의에서 설명한 대로 클라우드 채택 프레임워크의 각 방법론은 운영 모델을 개발하기 위한 구조화된 경로를 제공합니다. 이러한 방법론을 통해 클라우드 운영 모델 채택의 차이에서 비롯된 방해를 극복하는 데 도움이 될 수 있습니다.

다음 표에서는 운영 모델 구현을 가속화하는 방법을 간략하게 설명합니다.

탈중앙화 작업

작업은 항상 복잡합니다. 작업 범위를 하나의 워크로드 또는 작은 워크로드 컬렉션으로 제한하는 경우 복잡성을 제어합니다. 분산형 작업은 일반적인 운영 모델 중 가장 복잡하지 않습니다. 이러한 형태의 작업에서 모든 워크로드는 전용 워크로드 팀에서 독립적으로 작동합니다.

• 우선 순위: 팀은 여러 워크로드에서 중앙 집중식 제어 또는 표준화에 대한 혁신을 측정합니다.
• 고유한 이점: 설계, 구축 및 운영을 완전히 통제함으로써 워크로드 및 비즈니스 팀의 혁신 속도를 극대화합니다.
• 고유한 단점: 워크로드 간 표준화 감소, 공유 서비스를 통한 규모의 경제, 일관된 거버넌스 중앙 집중식 규정 준수 노력.
• 위험: 이 접근 방식은 워크로드 포트폴리오를 관리할 때 위험을 초래합니다. 워크로드 팀에는 중앙 IT 기능 전용 특수 팀이 있을 수 있습니다. 이 운영 모델은 일부 조직, 특히 타사 규정 준수 요구 사항을 따라야 하는 회사에서 위험 수준이 높은 옵션으로 간주됩니다.
• 지침: 분산된 작업은 워크로드 수준 결정으로 제한됩니다. Microsoft Azure Well-Architected Framework는 해당 범위 내에서 내린 결정을 지원합니다. 클라우드 채택 프레임워크 내의 프로세스 및 지침은 분산된 작업에 필요하지 않은 오버헤드를 추가할 수 있습니다.

탈중앙화 작업의 장점

• 비용 관리: 운영 비용은 단일 사업부에 쉽게 매핑됩니다. 워크로드별 작업은 더 큰 워크로드 최적화를 지원합니다.
• 책임: 일반적으로 이러한 형태의 작업은 오버헤드를 최소화하기 위해 자동화에 크게 의존합니다. 책임은 릴리스 관리를 위해 DevOps 및 파이프라인에 중점을 두는 경향이 있습니다. 이 유형의 작업은 개발 중에 더 빠른 배포와 짧은 피드백 주기를 지원합니다.
• 표준화: 소스 코드 및 배포 파이프라인을 사용하여 릴리스에서 릴리스로 환경을 표준화합니다.
• 운영 지원: 운영에 영향을 미치는 결정은 해당 워크로드의 요구 사항과 운영 결정을 간소화하는 데만 초점을 맞춥니다. DevOps 커뮤니티의 구성원은 운영 범위가 더 엄격하기 때문에 운영 지원이 가장 순수한 형태의 작업이라고 말합니다.
• 전문 지식: DevOps 및 개발 팀은 이러한 접근 방식을 통해 가장 많은 권한을 부여하고 시장 변화를 주도하는 데 가장 적은 저항을 경험합니다.
• 랜딩 존 디자인: 특정 운영 이점이 없습니다.
• 기본 유틸리티: 특정 운영 이점이 없습니다.
• 의무 분리: 구체적인 운영 이점은 없습니다.

탈중앙화 작업의 단점

• 비용 관리: 엔터프라이즈 비용을 계산하기가 더 어렵습니다. 중앙 집중식 거버넌스 팀이 없으면 균일한 비용 제어 또는 최적화를 구현하기가 더 어려워집니다. 각 워크로드에 배포된 자산 및 인력 배정이 중복될 수 있으므로 대규모로 이 모델은 비용이 많이 들 수 있습니다.
• 책임: 중앙 집중식 지원이 없다는 것은 워크로드 팀이 거버넌스, 보안, 운영 및 변경 관리를 전적으로 담당한다는 것을 의미합니다. 이러한 작업이 코드 검토 및 릴리스 파이프라인에서 자동화되지 않은 경우 지원 부족이 문제가 됩니다.
• 표준화: 워크로드 포트폴리오 전반의 표준화는 가변적이고 일관성이 없습니다.
• 운영 지원: 여러 워크로드에서 모범 사례를 개발할 때 규모의 효율성이 자주 간과됩니다.
• 전문 지식: 팀 구성원은 애플리케이션 디자인 및 구성 내에서 거버넌스, 보안, 운영 및 변경 관리에 대해 현명하고 윤리적인 결정을 내릴 책임이 더 큽니다. 필요한 전문 지식을 향상하려면 Microsoft Azure Well-Architected 검토 및 Azure Well-Architected Framework를 자주 참조하세요.
• 랜딩 존 디자인: 랜딩 존은 워크로드별로 지정되지 않으며 이 접근 방식에서는 고려되지 않습니다.
• 기초 유틸리티: 워크로드 간에 공유되는 기초 서비스가 거의 없으므로 규모 효율성이 감소합니다.
• 업무 분리: DevOps 및 개발 팀에 대한 요구 사항이 높아짐에 따라 해당 팀의 높은 권한 사용량이 증가합니다. 업무를 분리해야 하는 경우 이 방법을 사용하기 위해 DevOps 성숙도에 막대한 투자를 해야 할 수 있습니다.

중앙 집중식 작업

중앙 집중식 작업

안정적인 상태 환경에서는 개별 워크로드의 아키텍처 또는 고유한 운영 요구 사항에 집중할 필요가 없습니다. 중앙 운영은 주로 안정적인 상태 워크로드로 구성된 기술 환경에 대한 표준인 경향이 있습니다. 안정적인 상태 운영의 예로는 상용 COTS 애플리케이션이나 릴리스 주기가 느린 잘 확립된 맞춤형 애플리케이션 등이 있습니다. 정기적인 업데이트 및 패치에 의해 변경 속도가 좌우되는 경우 운영 중앙 집중화가 포트폴리오를 관리하는 효과적인 방법이 될 수 있습니다.

• 우선 순위: 우선 순위는 혁신에 대한 중앙 제어이며, 최신 클라우드 운영으로의 문화적 전환보다 기존 운영 프로세스를 측정합니다.
• 고유한 이점: 중앙 집중화는 규모의 경제, 최고의 컨트롤 및 표준화된 운영을 도입하고 클라우드 환경에서 가장 잘 작동합니다. 이러한 환경에서는 클라우드 작업을 기존 작업 및 프로세스에 통합하기 위한 특정 구성이 필요합니다. 중앙 집중화는 아키텍처 복잡성 및 규정 준수 요구 사항이 적은 수백 개의 워크로드 포트폴리오에서 가장 유리합니다.
• 단점: 대규모 워크로드 포트폴리오의 요구에 맞게 스케일링하면 프로덕션 워크로드에 대한 운영 결정을 내리는 중앙 집중식 팀에 상당한 부담을 줄 수 있습니다. 기술 자산이 1,000개 이상의 VM, 애플리케이션 또는 데이터 원본을 초과할 것으로 예상되는 경우 18~24개월 내에 엔터프라이즈 모델을 고려할 수 있습니다.
• 위험: 이 방법은 중앙 집중화를 더 적은 수의 구독(종종 하나의 프로덕션 구독)으로 제한합니다. 클라우드 여정이 진행된 후에 리팩터링할 때 상당한 위험이 수반되며 도입 계획을 방해할 수 있습니다. 재작업을 방지하려면 세분화, 환경 경계, ID 도구 및 기타 기본 요소에 집중해 보세요.
• 지침: "작게 시작하여 확장하는" 개발 속도에 맞춰진 Azure 랜딩 존 구현 옵션은 탄탄한 시작점을 만듭니다. 이러한 옵션을 사용하여 채택 노력을 가속화할 수 있습니다. 그러나 성공하려면 허용 가능한 위험 허용 범위 내에서 조기 채택 노력을 안내하는 명확한 정책을 수립합니다. 관리 및 운영 방법론은 운영 성숙도를 높여 병렬로 작업을 진행하는 프로세스를 만드는 데 도움이 됩니다. 이러한 단계를 수행하면 작업이 성숙함에 따라 위험 증가를 허용하기 전에 완료해야 하는 단계 게이트 역할을 합니다.

중앙 집중식 작업의 이점

• 비용 관리: 여러 워크로드에서 공유 서비스를 중앙 집중화하면 규모의 경제가 생성되고 중복된 작업이 제거됩니다. 중앙 팀은 엔터프라이즈 수준 크기 조정 및 크기 조정 최적화를 통해 비용 절감을 신속하게 구현할 수 있습니다.
• 책임: 중앙 집중식 전문 지식 및 표준화로 인해 안정성이 향상되고 운영 성능이 향상되며 변경 관련 중단이 최소화될 수 있습니다. 이 접근 방식은 워크로드 중심 팀에 대한 광범위한 기술 부담을 줄입니다.
• 표준화: 일반적으로 중복된 시스템 또는 작업이 적기 때문에 중앙 집중식 모델에서 표준화 및 작업 비용이 가장 낮습니다.
• 운영 지원: 복잡성을 줄이고 작업을 중앙 집중화하면 소규모 IT 팀이 작업을 더 쉽게 지원할 수 있습니다.
• 전문 지식: 지원 팀을 중앙 집중화하면 보안, 위험, 거버넌스 및 운영 전문가가 비즈니스에 중요한 의사 결정을 내릴 수 있습니다.
• 랜딩 존 디자인: 중앙 IT는 랜딩 존 및 구독 수를 최소화하여 복잡성을 줄입니다. 랜딩 존 디자인은 이전 데이터 센터 디자인을 모방하여 전환 시간을 줄이는 경향이 있습니다. 채택이 진행됨에 따라 공유 리소스가 별도의 구독 또는 플랫폼 기반으로 이동될 수 있습니다.
• 기본 유틸리티: 기존 데이터 센터 디자인을 클라우드로 전달하면 온-프레미스 도구 및 작업을 모방하는 기본 공유 서비스가 생성됩니다. 온-프레미스 작업이 기본 운영 모델인 경우 장점이 될 수 있지만 몇 가지 단점을 주의해야 합니다. 온-프레미스 운영은 전환 시간을 줄이고, 규모의 경제를 활용하며, 온-프레미스와 클라우드 호스팅 워크로드 간의 일관된 운영 프로세스를 지원합니다. 이 방법을 사용하면 단기적인 복잡성과 노력을 줄이고 소규모 팀이 학습 곡선을 줄여 클라우드 운영을 지원할 수 있습니다.
• 의무 분리: 중앙 운영에서 의무 분리는 분명합니다. 중앙 IT는 프로덕션 환경을 제어하고 다른 팀의 상승된 권한에 대한 필요성을 줄입니다. 이 방법은 상승된 권한을 가진 계정 수를 제한하여 위반을 줄입니다.

중앙 집중식 작업의 단점

• 비용 관리: 중앙 팀은 워크로드 수준에서 영향을 미치는 최적화를 생성하기 위해 워크로드 아키텍처를 항상 이해하지 못합니다. 이러한 이해 부족으로 인해 잘 조정된 워크로드 작업에서 발생하는 비용 절감의 양이 제한됩니다. 워크로드 아키텍처를 완전히 이해하지 못하는 것은 중앙 집중식 비용 최적화에 영향을 줄 수 있으며, 이는 잘 설계된 워크로드의 성능, 규모 및 기타 핵심 요소에 영향을 줄 수 있습니다. 높은 프로필 워크로드에 엔터프라이즈 차원의 비용 변경을 적용하기 전에 중앙 IT 팀은 Microsoft Azure Well-Architected 검토를 이해하고 완료해야 합니다.
• 책임: 프로덕션 지원 및 액세스를 중앙 집중화하면 소수의 사람에게 높은 운영 부담이 발생하며 각 개인에 대한 부담이 커지게 됩니다. 이러한 개인에 대한 압박으로 인해 배포된 워크로드에 대한 심층 검토를 수행해야 하므로 자세한 보안 거버넌스 및 규정 준수 요구 사항을 준수하는지 확인합니다.
• 표준화: 중앙 IT 접근 방식을 사용하면 중앙 IT 직원의 선형 크기 조정 없이는 표준화를 확장하기가 어렵습니다.
• 운영 지원: 이 방법의 가장 큰 단점은 혁신을 측정하는 상당한 규모 및 변화와 관련이 있습니다.
• 전문 지식: 개발자 및 DevOps 전문가는 이러한 유형의 환경에서 저평가되거나 너무 제한될 위험이 있습니다.
• 랜딩 존 디자인: 데이터 센터 디자인은 클라우드와 항상 관련이 없는 이전 접근 방식의 제약 조건을 기반으로 합니다. 이 방법을 따르면 환경 세분화를 재고하고 혁신 기회를 강화할 수 있는 기회가 줄어듭니다. 랜딩 존 세분화가 부족하면 보안 위반의 잠재적 영향이 커지고, 거버넌스와 규정 준수의 복잡성이 증가하며, 클라우드 도입 과정에서 장애물이 될 수 있습니다. 위의 위험 섹션을 참조하세요.
• 기초 유틸리티: 디지털 전환 중에 클라우드가 기본 운영 모델이 될 수 있습니다. 온-프레미스 운영을 위해 빌드된 중앙 도구는 운영을 현대화하고 운영 효율성을 높일 기회를 줄입니다. 채택 프로세스 초기에 작업을 현대화하지 않도록 선택하는 것도 옵션입니다. 클라우드 채택 과정에서 플랫폼 기반 구독을 만들어 현대화를 달성할 수 있습니다. 이러한 노력은 고급 계획 없이 복잡하고 비용이 많이 들며 시간이 많이 걸릴 수 있습니다.
• 업무 분리: 중앙 운영은 일반적으로 두 경로 중 하나를 따르며 둘 다 혁신을 방해할 수 있습니다.
  • 옵션 1: 중앙 IT 외부의 팀에는 프로덕션을 모방하는 개발 환경에 대한 제한된 액세스 권한이 부여됩니다. 이 옵션은 실험을 방해합니다.
  • 옵션 2: Teams는 지원되지 않는 환경에서 개발하고 테스트합니다. 이 옵션은 배포 프로세스를 방해하고 배포 후 통합 테스트를 느리게 합니다.

엔터프라이즈 운영

엔터프라이즈 작업은 모든 클라우드 작업에 대해 제안된 대상 상태입니다. 엔터프라이즈 운영은 의사 결정과 책임을 간소화하여 제어 및 혁신에 대한 필요성의 균형을 유지합니다. 중앙 IT 부서는 더 지원적인 클라우드 우수성 센터(클라우드 센터 오브 엑설런스, CCoE) 팀으로 대체되며, 이는 용량을 관리하는 팀을 지원합니다. CCoE 팀은 작업을 제어하거나 제한하는 것과는 달리 워크로드 팀의 의사 결정에 대한 책임을 묻습니다. 워크로드 팀은 잘 정의된 가드레일 내에서 혁신을 추진하도록 더 많은 힘과 더 많은 책임을 부여받습니다.

• 우선 순위: 우선 순위는 기술 결정의 민주화입니다. 기술 의사 결정의 민주화는 이전에 중앙 IT 부서에서 보유했던 책임을 워크로드 팀으로 전환합니다. 이러한 우선 순위 변경을 제공하기 위해 의사 결정은 사람이 실행하는 검토 프로세스에 덜 의존하게 됩니다. 이 방법은 클라우드 네이티브 도구를 사용하여 자동화된 검토, 거버넌스 및 적용을 지원합니다.
• 고유한 이점: 환경 세분화 및 의무 분리를 통해 제어와 혁신 간의 균형을 맞출 수 있습니다. 중앙 집중식 작업은 향상된 규정 준수 및 안정적인 상태 작업이 필요한 워크로드를 유지 관리하거나 더 큰 보안 위험을 나타냅니다. 반대로, 이 방법은 더 큰 혁신이 필요한 워크로드 및 환경에 대한 중앙 집중식 제어를 줄이는 것을 지원합니다. 더 큰 포트폴리오는 제어와 혁신 사이의 균형에 어려움을 겪을 수 있습니다. 이러한 유연성을 통해 운영 문제를 줄여 수천 개의 워크로드를 더 쉽게 확장할 수 있습니다.
• 고유한 단점: 온-프레미스에서 작동하는 작업이 엔터프라이즈 클라우드 운영에서 제대로 작동하지 않을 수 있습니다. 이 작업 접근 방식에는 여러 가지 면에서 변경이 필요합니다. 통제와 책임의 문화적 변화는 종종 가장 큰 도전입니다. 문화적 변화에 따른 운영 변화는 구현, 성숙 및 안정화를 위해 시간과 노력을 기울여야 합니다. 안정적인 워크로드에서는 아키텍처 변화가 필요할 수 있으며, 문화적, 운영적, 아키텍처적 변화를 지원하고 강화하기 위해 도구의 변화가 필요할 수 있습니다. 이러한 변화에는 기본 클라우드 공급자에 대한 약정이 필요할 수 있습니다. 이러한 변경 전에 수행된 채택 작업에는 일반적인 리팩터링 노력을 넘어서는 상당한 재작업이 필요할 수 있습니다.
• 위험: 이 방법을 사용하려면 변경 전략에 대한 경영진의 의지가 필요합니다. 또한 학습 곡선을 극복하고 필요한 변경을 제공하기 위해 기술 팀의 노력이 필요합니다. 비즈니스, CCoE, 중앙 IT 및 워크로드 팀 간의 장기적인 협력이 있어야만 장기적인 이점을 얻을 수 있습니다.
• 지침: Azure 랜딩 존 옵션은 엔터프라이즈 규모정의됩니다. 이러한 옵션은 Azure에서 클라우드 네이티브 도구를 사용하여 기술 변화가 어떻게 실행되는지를 보여주는 참조 구현을 제공합니다. 엔터프라이즈 규모 접근 방식은 이러한 구현을 최대한 활용하는 데 필요한 운영 및 문화적 변화를 통해 팀을 안내합니다. 동일한 접근 방식은 채택 전략 및 규정 준수 제약 조건을 충족하도록 환경을 구성하도록 참조 아키텍처를 조정할 수 있습니다. 엔터프라이즈 규모를 구현할 때 거버넌스 및 관리 방법론을 통해 프로세스를 정의할 수 있습니다. 이러한 프로세스는 운영 요구 사항에 맞게 규정 준수 및 운영 기능을 확장할 수 있습니다.

엔터프라이즈 운영의 이점

• 비용 관리: 중앙 팀은 포트폴리오 간 최적화를 수행하고 개별 워크로드 팀에게 심층적인 워크로드 최적화를 책임지게 합니다. 워크로드 중심 팀은 의사 결정을 내릴 수 있는 권한을 부여하고 이러한 결정이 부정적인 비용 영향을 미칠 때 명확성을 제공합니다. 중앙 및 워크로드 팀은 적절한 수준에서 비용 결정에 대한 책임을 공유합니다.
• 책임: 중앙 팀은 클라우드 네이티브 도구를 사용하여 가드레일을 정의, 적용 및 자동화합니다. 워크로드 팀의 노력은 CCoE 자동화 및 사례를 통해 가속화됩니다. 워크로드 팀은 혁신을 주도하고 이러한 가드레일 내에서 결정을 내릴 수 있습니다.
• 표준화: 중앙 집중식 가드레일 및 기본 서비스는 모든 환경에서 일관성을 만듭니다.
• 운영 지원: 중앙 집중식 작업 지원이 필요한 워크로드는 안정 상태 제어가 있는 환경으로 분할됩니다. 업무 분할 및 분리를 통해 워크로드 팀은 자체 전용 환경에서 운영 지원을 책임지도록 할 수 있습니다. 자동화된 클라우드 네이티브 도구는 중앙 집중식 운영 지원을 통해 모든 환경에 대한 최소 작업 기준을 보장합니다.
• 전문 지식: 보안, 위험, 거버넌스 및 운영과 같은 핵심 서비스를 중앙 집중화하면 적절한 중앙 전문 지식이 보장됩니다. 명확한 프로세스 및 가드레일은 워크로드 팀이 보다 자세한 결정을 내릴 수 있도록 교육하고 권한을 부여합니다. 이러한 결정은 기술 규모로 직원을 선형적으로 확장할 필요 없이 중앙 집중식 전문가의 효과를 확장합니다.
• 랜딩 존 디자인: 랜딩 존 디자인은 포트폴리오의 요구를 복제하여 명확한 보안, 거버넌스 및 책임 경계를 만듭니다. 이러한 경계는 클라우드에서 워크로드를 운영하는 데 필요합니다. 분할 방법은 이전 데이터 센터 디자인에서 만든 제약 조건과 유사하지 않습니다. 엔터프라이즈 운영에서 랜딩 존 디자인은 덜 복잡하여 셀프 서비스 수요에 대한 더 빠른 확장과 장벽 감소를 가능하게 합니다.
• 기초 유틸리티: 기초 유틸리티는 플랫폼 기반으로 알려진 별도의 중앙 제어 구독에서 운영됩니다. 그런 다음 중앙 도구는 유틸리티 서비스로 각 랜딩 존으로 전달됩니다. 랜딩 존에서 기본 유틸리티를 분리하면 일관성과 규모의 경제성이 극대화됩니다. 또한 이러한 유틸리티는 중앙에서 관리되는 책임과 워크로드 수준 책임 간에 명확한 차이점을 만듭니다.
• 의무 분리: 기본 유틸리티와 랜딩 존 사이의 의무 분리는 운영 접근 방식의 가장 큰 장점 중 하나입니다. 클라우드 네이티브 도구 및 프로세스는 중앙 집중식 팀과 워크로드 팀 간의 액세스 및 적절한 제어 균형을 지원합니다. 이 방법은 랜딩 존 세그먼트에서 호스트되는 개별 랜딩 존 및 워크로드의 요구 사항을 기반으로 합니다.

엔터프라이즈 작업의 단점

• 비용 관리: 중앙 팀은 랜딩 존 내에서 프로덕션을 변경하기 위해 워크로드 팀에 더 의존합니다. 이러한 변화로 인해 잠재적인 예산 초과와 실제 지출의 올바른 크기 조정 속도가 느려질 위험이 있습니다. 비용 놀라움을 방지하려면 비용 제어 프로세스, 명확한 예산, 자동화된 제어 및 정기적인 검토가 조기에 있어야 합니다.
• 책임: 엔터프라이즈 운영에는 더 큰 문화 및 운영 요구 사항이 필요합니다. 이러한 요구 사항은 중앙 및 워크로드 팀 간의 책임과 책임에 대한 명확성을 보장합니다.
• 기존의 변경 관리 프로세스나 변경 자문 위원회(CAB)는 이 운영 모델에 필요한 속도와 균형을 유지하지 못할 수 있습니다. 이러한 프로세스는 클라우드 채택을 안전하게 확장하는 프로세스 및 절차를 자동화하는 데 반영됩니다.
• 변화에 대한 헌신의 부족은 먼저 협상과 책임의 정렬에서 구체화됩니다. 책임의 변화에 부합하지 못하는 것은 단기 클라우드 채택 작업 중에 중앙 IT 운영 모델이 필요할 수 있음을 나타냅니다.
• 표준화: 중앙 집중식 가드레일 또는 자동화에 대한 투자 부족으로 인해 표준화에 대한 위험이 발생하므로 수동 검토 프로세스를 통해 극복하기가 더 어렵습니다. 랜딩 존의 워크로드와 공유 서비스 간의 운영 종속성은 더 큰 위험을 초래합니다. 이와 같은 위험은 업그레이드 주기 또는 향후 버전으로의 전환 시 표준화된 기본 유틸리티 사용과 관련해 발생할 수 있습니다. 플랫폼 기반 수정 중에 지원되는 모든 랜딩 존과 호스팅하는 워크로드에 개선되거나 자동화된 테스트가 필요합니다.
• 운영 지원: 자동화 및 중앙 집중식 운영을 통해 제공되는 운영 기준은 낮은 영향 또는 낮은 중요도의 워크로드에 충분할 수 있습니다. 그러나 워크로드 팀 또는 다른 형태의 전용 작업은 복잡하거나 중요도가 높은 워크로드에 필요할 수 있습니다. 그렇다면 사업부가 이러한 형태의 고급 운영에 운영 비용을 제공하도록 요구하는 운영 예산의 변화가 발생할 수 있습니다. 운영 비용에 대한 단독 책임을 유지하기 위해 중앙 IT가 필요한 경우 엔터프라이즈 운영을 구현하기가 어려울 수 있습니다.
• 전문 지식: 중앙 IT 팀 구성원은 수동 프로세스를 통해 이전에 전달된 중앙 제어 자동화에 대한 전문 지식을 개발해야 할 수 있습니다. 또한 이러한 팀은 환경을 정의하고 분기, 병합 및 배포 파이프라인을 이해하는 코드로서의 인프라 접근 방식에 대한 숙련도를 개발할 수 있습니다. 최소한 플랫폼 자동화 팀은 클라우드 센터 우수 또는 중앙 운영 팀의 결정을 이해하기 위해 의사 결정 기술이 필요할 수 있습니다. 워크로드 팀은 의사 결정을 제어하는 제어 및 프로세스와 관련된 더 많은 지식을 개발해야 할 수 있습니다.
• 랜딩 존 디자인: 랜딩 존 디자인은 기본 유틸리티에 따라 달라집니다. 워크로드 팀은 디자인의 내용과 포함할 수 없는 사항을 이해해야 합니다. 이러한 이해는 노력, 오류 또는 충돌의 중복을 방지하는 데 도움이 될 수 있습니다. 유연성을 만들기 위해 랜딩 존 디자인에 예외 프로세스를 고려할 수 있습니다.
• 기본 유틸리티: 기본 유틸리티를 중앙 집중화하는 데 시간이 걸립니다. 이러한 유틸리티는 결국 옵션을 고려하고 다양한 채택 계획을 충족하도록 확장할 수 있는 솔루션을 개발합니다. 초기 채택 작업의 지연이 발생할 수 있습니다. 지연은 과정의 후반에 가속 및 장애물 회피로 인해 장기적으로 상쇄될 수 있습니다.
• 의무 분리: 명확한 업무 분리를 보장하려면 성숙한 ID 관리 프로세스가 필요합니다. 사용자, 그룹 및 온보딩과 오프보딩 활동의 적절한 정렬과 관련된 유지 관리 작업이 더 필요할 수 있습니다. 상승된 권한을 통해 Just-In-Time 액세스를 수용하기 위해 새 프로세스를 채택해야 할 수 있습니다.

분산 작업

분산 작업

기존 운영 모델이 너무 많이 스며들어 전체 조직이 새 운영 모델로 전환할 수 없습니다. 다른 사용자의 경우 글로벌 운영 및 다양한 규정 준수 요구 사항으로 인해 특정 사업부에서 변경을 수행할 수 없습니다. 이 경우 분산 작업 접근 방식이 필요할 수 있습니다. 이 방법은 앞에서 언급한 운영 모델 중 하나 이상을 통합해야 하므로 가장 복잡합니다.

권장되지는 않지만 일부 조직에서는 이 작업 접근 방식이 필요할 수 있습니다. 이 접근 방식은 주로 서로 다른 사업부의 느슨한 컬렉션, 다양한 고객 세그먼트 기반 또는 지역 운영이 있는 조직과 관련이 있습니다.

• 우선 순위: 여러 기존 운영 모델을 통합합니다.
• 전체 조직을 앞에서 언급한 운영 모델 중 하나로 이동하는 데 중점을 둔 전환 상태입니다.
• 조직이 너무 크거나 복잡해서 단일 운영 모델에 맞추기 어려울 때의 장기적인 운영 접근 방식입니다.
• 고유한 이점: 각 사업부의 일반적인 운영 모델 요소를 통합합니다. 이 방법은 일관된 반복 가능한 프로세스를 사용하여 작업을 완성하는 데 도움이 되는 운영 단위를 계층 구조로 그룹화하는 차량을 만듭니다.
• 고유한 단점: 여러 운영 모델에서 일관성 및 표준화는 장기간 유지 관리하기 어렵습니다. 이러한 운영 방식을 사용하려면 포트폴리오에 대한 깊은 인식과 기술 포트폴리오의 다양한 세그먼트가 작동하는 방식에 대한 깊은 인식이 필요합니다.
• 위험: 기본 운영 모델에 대한 헌신이 부족하면 팀 간에 혼란이 발생할 수 있습니다. 단일 운영 모델에 맞출 방법이 없는 경우 이 운영 모델을 사용합니다.
• 지침: 비즈니스 정렬 문서에 설명된 접근 방식을 사용하는 포트폴리오에 대한 철저한 검토로 시작합니다. 국가 운영 모델(분산형, 중앙 집중식 또는 엔터프라이즈)으로 포트폴리오를 그룹화합니다.
• 운영 모델 그룹을 반영하는 관리 그룹 계층 구조를 개발합니다. 이 배열에는 워크로드 클러스터를 가장 적게 사용되는 버킷부터 가장 일반적으로 사용되는 버킷으로 매핑하는 지역, 사업부 또는 기타 기준에 따른 조직 패턴이 포함됩니다.
• 워크로드의 운영 모델에 대한 조율을 평가하여 시작할 가장 관련성이 높은 운영 모델 클러스터를 찾습니다. 노드 및 관리 그룹 계층 구조 아래의 모든 워크로드에 대한 운영 모델에 매핑되는 지침을 따릅니다.
• 거버넌스 및 관리 방법론을 사용하여 계층의 다양한 지점에서 필요한 운영 관리 사례를 포함하여 일반적인 회사 정책을 찾습니다. 공통 Azure 정책을 적용하여 공유 회사 정책을 자동화합니다.
• 다양한 배포를 사용하여 Azure 정책을 테스트할 때, 관리 그룹 계층 구조에서 더 높은 위치로 이동하려고 시도하십시오. 정책은 많은 워크로드에 적용할 수 있으며, 공통점과 고유한 작업 요구 사항을 찾을 수 있습니다.
• 시간이 지남에 따라 이 방법은 다양한 운영 모델에서 확장되는 모델을 정의하는 데 도움이 될 수 있습니다. 이 방법은 일반적인 정책 및 절차 집합을 통해 팀을 통합할 수도 있습니다.

이 방법의 장점과 단점은 의도적으로 비어 있습니다. 포트폴리오의 비즈니스 정렬을 완료한 후 위의 주요 운영 모델 섹션에서 장점과 단점에 대한 명확성을 확인하세요.

다음 단계

운영 모델과 관련된 용어를 알아봅니다. 이 용어는 운영 모델이 기업 계획의 더 큰 테마에 어떻게 부합하는지 이해하는 데 도움이 됩니다.

랜딩 존이 클라우드 채택 환경의 기본 구성 요소인 방법을 알아봅니다.