Operations
먼저 Windows 11 배포에 대한 운영 준비를 결정해 보겠습니다. 여기에는 다음 단계에서 닫아야 하는 간격을 식별하는 것이 포함됩니다. 다음은 이 영역에서 준비 상태를 평가하는 데 권장되는 작업 및 결과물 목록입니다.
| 업무 | 결과물 |
|---|---|
| - 운영 준비 조건을 정의합니다. - 배포 링/단계를 정의합니다. - [선택 사항] PoC(개념 증명)를 정의합니다. - 담당자에게 역할을 식별하고 할당합니다. - 디바이스에 대한 서비스 채널을 정의합니다. - 하드웨어 새로 고침 계획. - 디바이스 업데이트 전략을 정의합니다. - 피드백 루프를 디자인합니다. - 간격을 식별합니다. |
• 운영 준비 조건 테이블 • 배포 계획(필요한 수의 배포 단계 또는 링, 날짜 및 디바이스 업그레이드 전략 포함) • [선택 사항] PoC에서 수행할 디바이스 및 테스트 목록 • 작업에 대한 역할 및 책임 또는 RACI 테이블 • 기본값이 아닌 서비스 채널이 필요한 디바이스 목록 • 하드웨어 새로 고침 계획 • 문서화된 피드백 프로세스 • 운영 격차 목록 |
운영 준비 상태 기준 정의
Windows 11 기능 업데이트를 배포할 때 새로운 운영 문제가 발생하지 않는지 확인해야 합니다. 또한 인시던트가 발생하는 경우 필요한 설명서와 프로세스를 사용할 수 있는지 확인해야 합니다. 이를 위해 운영 및 지원 팀과 협력하여 허용 가능한 추세를 정의하고 업데이트해야 하는 문서 또는 프로세스를 식별합니다.
- 호출 추세: Windows 11 기능 업데이트와 관련된 호출의 증가율이 어느 정도 수용 가능하거나 지원할 수 있을지를 정의합니다.
- 인시던트 추세: 허용되거나 지원될 수 있는 Windows 11 관련된 지원을 요청하는 인시던트 티켓의 증가율을 정의합니다.
- 지원 설명서: 업데이트가 필요한 지원 설명서를 식별합니다. Windows 11 기능 업데이트의 일부로 새 인프라 도구 또는 구성을 지원하는 데 집중합니다.
- 프로세스 변경: Windows 11 기능 업데이트의 결과로 변경될 프로세스를 식별합니다.
메모
권장 결과물:
이러한 운영 준비 조건을 테이블과 같은 공유를 허용하는 형식으로 문서화합니다.
배포 링 또는 단계 정의
서비스 관리 모델에서는 대표적인 디바이스 그룹에 업데이트를 롤아웃하는 효과적인 방법이 필요합니다. 많은 조직에서 링 기반 배포가 잘 작동한다는 것을 발견했습니다. Windows 클라이언트의 배포 링은 대부분의 조직이 이전의 주요 수정 업그레이드를 위해 생성된 배포 그룹과 같습니다. 디바이스를 배포 타임라인 또는 단계로 구분하는 방법일 뿐입니다.
최상위 수준에서 각 링은 특정 업데이트를 동시에 수신하는 사용자 또는 디바이스 그룹으로 구성됩니다. 각 링에 대해 포함할 디바이스, 기능 업데이트 제공을 시작할 시기 및 설치할 최종 기한을 정의합니다. 사용자에게 자신의 일정에 따라 업데이트를 설치할 수 있는 기능을 제공할 수도 있습니다.
배포에 사용해야 하는 링의 수 또는 단계를 통해 얼마나 빨리 이동해야 하는지에 대한 명확한 규칙은 없습니다. 다음과 같은 가능한 방법을 고려합니다.
- 위험 기반 접근 방식: 먼저 몇 가지 테스트 디바이스에 배포한 다음, 소규모 얼리 어답터 그룹, 다양한 사업부를 나타내는 더 큰 사용자 그룹을 배포한 후 나머지 자산(First-Fast-Broad 접근 방식)에 배포합니다.
- 중요 업무용 디바이스의 가동 중지 시간 0개: 다른 모든 디바이스 후에 업데이트를 수신하는 중요 업무용 디바이스를 자체 링에 배치합니다.
- 대규모 조직 관리: 대규모 조직이 있는 경우 지리적 위치에 따라 링에 디바이스를 할당하는 것을 고려할 수 있습니다. 또는 기술 지원팀 리소스를 더 많이 사용할 수 있도록 링 크기에 따라 할당합니다.
기존 First-Fast-Broad 모델을 계획하는 방법은 다음과 같습니다.
- 첫 번째 링에는 일반적으로 대부분의 비즈니스 영역, 비즈니스 애플리케이션 및 지리적 위치의 단면을 나타내는 디바이스/사용자(종종 IT 전문가 또는 기술에 정통한 사용자)가 포함됩니다. 여기서 성공적인 테스트 결과를 통해 대부분의 비즈니스 영역이 성공적으로 업데이트될 수 있다는 확신을 얻을 수 있습니다.
- 빠른 링에는 더 많은 비즈니스 영역을 나타내는 더 넓은 범위의 디바이스/사용자가 포함됩니다.
- 마지막으로 광범위 링은 조직의 나머지 부분에 배포하는 것을 의미합니다.
팁 (조언)
First 링 전에 테스트 링을 울리는 것도 흔한 일입니다. 테스트 링에는 일반적으로 IT 관리 그룹의 디바이스 및 사용자가 포함됩니다. 프로덕션 환경에서 배포가 작동하는 방식의 유효성을 검사하는 데 자주 사용됩니다(프로덕션 개념 증명 또는 파일럿 단계로 간주).
귀사의 비즈니스 요구 사항을 고려하여 조직에 적합한 링을 도입하세요.
메모
권장 결과물:
이상적으로는 각 단계에 필요한 배포 단계 수 또는 링 및 잠재적인 날짜를 기준으로 배포 계획을 문서화하는 것이 좋습니다.
(선택 사항) PoC(개념 증명) 정의
프로덕션 환경에 기능 업데이트를 배포하기 전에 선택적 PoC(개념 증명)를 수행하도록 결정할 수 있습니다. PoC 또는 제한된 파일럿은 일반적으로 랩 환경에서 수행되는 선택적 단계입니다. 이는 공식 First 배포 링에서 운영 중인, 보다 대표적인 사용자/기기 샘플보다 앞서 진행됩니다.
PoC는 제한된 수의 IT 관리자 테스트 디바이스에 Windows 11 다운로드하고 설치하는 것만큼 간단할 수 있습니다. 이를 통해 Windows 11 새로운 기능을 검토하고 몇 가지 중요한 비즈니스 앱의 유효성을 검사할 수 있습니다. 또한 배포 도구를 사용하여 업데이트를 배포하여 인프라 및 배포 프로세스가 Windows 11 준비가 되는지 확인하는 데 사용할 수 있습니다.
일부 PoC 디바이스를 Windows 참가자 프로그램 비즈니스용 등록하여 새 Windows 기능이 출시되기 전에 미리 볼 수 있도록 하는 것이 좋습니다.
메모
권장 결과물:
PoC를 수행할지 여부를 결정합니다. 그렇다면 테스트할 기능과 디바이스를 문서화합니다.
담당자에게 역할 및 책임 식별 및 할당
업데이트 배포 준비의 중요한 부분은 프로세스의 다양한 작업을 지원할 담당자가 있다는 것입니다. 팀 구성원의 일반적인 역할과 책임 및 다양한 수준의 참여에 대한 프레임워크를 검토해 보겠습니다.
주 역할은 프로세스 관리자입니다. 이 역할은 프로세스를 계속 추진하고, 필요한 경우 중지할 수 있는 권한을 제공합니다. 사용자의 책임, 기술 및 활성 상태의 단계는 다음 표에 설명되어 있으며, 할당해야 하는 다른 역할 및 책임은 다음과 같습니다.
| 역할 | 책무 | 기술 | 활성 단계 |
|---|---|---|---|
| 프로세스 관리자 | 프로세스 종단 간 관리; 입력 및 출력이 캡처되는지 확인합니다. 활동 진행률 확인 | IT 서비스 관리 | 계획, 준비, 파일럿 배포, 광범위한 배포 |
| 애플리케이션 소유자 | 애플리케이션 테스트 계획 정의; 사용자 승인 테스터 할당; 애플리케이션 인증 | 중요하고 중요한 애플리케이션에 대한 지식 | 계획, 준비, 파일럿 테스트 배포 |
| 애플리케이션 개발자 | 앱이 현재 Windows 버전과 호환되도록 개발되었는지 확인 | 애플리케이션 개발; 애플리케이션 수정 | 계획, 준비 |
| 최종 사용자 컴퓨팅 | 업그레이드 도구가 Windows 호환되는지 확인합니다. 일반적으로 인프라 엔지니어 또는 배포 엔지니어를 포함한 그룹 | 베어 메탈 배포; 인프라 관리; 애플리케이션 배포; 업데이트 관리 | 계획, 준비, 파일럿 배포, 광범위한 배포 |
| Operations | 현재 Windows 버전에 대한 지원을 사용할 수 있는지 확인합니다. 사용자 통신 및 롤백을 포함하여 배포 후 지원 제공 | 앱 및 시스템 문제 해결 | 준비, 파일럿 배포, 광범위한 배포 |
| 보안 | 보안 기준 및 도구 검토 및 승인 | 플랫폼 보안 | 준비, 시범 배포 |
| ID 소유자 | 사용자 및 디바이스에 대한 조직 ID 전략 검토 | ID 관리 | 계획, 준비 |
| 이해관계자 | 변경 내용이 해당 사업부에 부정적인 영향을 주지 않도록 합니다. 재무 책임자, 최종 사용자 서비스 또는 변경 관리와 같은 업데이트의 영향을 받는 그룹 | 사업부 또는 부서의 주요 의사 결정자 | 계획, 파일럿 배포, 광범위한 배포 |
각 역할에 대한 활성 단계에는 다양한 수준의 참여가 필요한 작업이 포함될 수 있습니다. 이 기대치를 설정하려면 RACI 모델을 사용하는 것이 좋습니다.
- 책임: 특정 작업을 완료할 책임이 있는 개인 또는 팀
- 책임: 전체 결과의 성공 또는 실패를 담당하는 단일 개인
- 상담: 의사 결정을 내리거나 조치를 취하기 전에 입력 및 전문 지식이 필요한 개인 또는 그룹
- 정보: 작업 또는 결정의 진행 상황에 대해 계속 알려야 하지만 실행에 직접 관여하지 않는 사람
프로세스 관리자는 배포의 전반적인 성공에 대한 책임을 지고 배포의 모든 작업을 구성합니다. 여기에는 이 단계의 특정 작업 및 다음 작업에 자신의 기술을 기반으로 책임 있고, 상담되고, 정보를 제공한 사람을 할당하는 것이 포함됩니다. Excel RACI 매트릭스 템플릿을 사용하거나 직접 만드는 방법을 배우고 이 계획 단계 전체에서 완료해 보세요.
예를 들어 이 프로세스의 작업 샘플에 대한 RACI 행렬은 다음과 같습니다.
| 단계 | 과업 | 프로세스 관리자 | 최종 사용자 컴퓨팅 | 애플리케이션 소유자 | Operations | 보안 |
|---|---|---|---|---|---|---|
| Plan | 담당자에게 역할을 정의하고 할당합니다. | 책임을 지는, 책임 있는 | 관련자 | 관련자 | 관련자 | 관련자 |
| Plan | 작업 프로세스를 업데이트하는 방법을 간략하게 설명합니다. | 책임을 지는 | 관련자 | 관련자 | 책임형 | 관련자 |
| 준비 | 인프라 변경 내용을 검토합니다. | 책임을 지는 | 책임형 | 관련자 | 관련자 | 관련자 |
| 준비 | 작업 변경 내용을 구현하고 테스트합니다. | 책임을 지는 | 중심 인물 | 관련자 | 책임형 | 관련자 |
| Deploy | 실패한 앱을 수정합니다. | 책임을 지는 | 관련자 | 책임형 | 관련자 | 관련자 |
| Deploy | Microsoft Entra ID 문제를 해결합니다. | 책임을 지는 | 관련자 | 관련자 | 관련자 | 책임형 |
이 모듈과 다음 학습 모듈의 끝에서 업데이트 배포의 각 단계에서 다루는 모든 작업의 목록을 찾을 수 있습니다.
메모
권장 결과물:
이 시점에서 대부분의 작업 및 영역에 대한 역할 및 책임 차트 및/또는 RACI 테이블이 있어야 합니다.
디바이스에 대한 서비스 채널 정의
서비스 채널을 사용하면 조직에서 환경 전체에 업데이트를 적용할 빈도를 결정할 수 있습니다. 예를 들어 가능한 한 빨리 테스트에 사용하는 디바이스에 업데이트를 적용하도록 선택할 수 있습니다. 반면 특수 기능에 사용되는 장치는 나중에 업데이트를 받을 수 있습니다. Windows 서비스 채널은 다음과 같이 정의됩니다.
| 서비스 채널 | 설명 |
|---|---|
| Windows 참가자 프로그램 | 이 서비스 채널을 사용하여 중요한 애플리케이션, 최종 사용자 환경, 보안 상태 등의 잠재적 호환성 문제를 테스트할 수 있습니다. 또한 이 서비스 채널을 사용하면 새 기능 업데이트를 공개적으로 사용할 수 있기 전에 탐색하고 테스트할 수 있습니다. Windows 참가자 프로그램 디바이스를 몇 개 이상 등록하는 것이 좋습니다. |
| GA(일반 공급) 채널(권장) | 관리되는 디바이스의 기본값으로 이 서비스 채널을 사용합니다. 누적 업데이트 형식으로 한 달에 한 번 보안 및 품질 업데이트를 받습니다. 누적 업데이트에도 새로운 기능이 도입될 수 있습니다. 중요한 문제에 대한 선택적 비보안 업데이트 및 대역 외 업데이트도 이 채널을 통해 사용할 수 있습니다. 새로운 버전의 Windows 11 매년 하반기에 출시됩니다. 이 버전을 기능 업데이트라고 합니다. 여기에는 새로운 기능과 모든 이전 품질 업데이트가 포함됩니다. Windows 11 Enterprise 및 Education 버전의 경우 각 버전은 초기 릴리스 날짜로부터 36개월 동안 서비스됩니다. Windows 11 Professional의 경우 각 버전은 24개월 동안 서비스됩니다. |
| 장기 서비스 채널(LTSC) | 이 서비스 채널은 결제 시스템 또는 의료 시스템과 같은 특수 기능에 사용되는 디바이스를 위한 것입니다. 이러한 디바이스는 LTSC 버전의 Windows 11 사용하고 품질 업데이트만 수신하여 디바이스가 기능적이고 안전하게 유지되도록 합니다.
Windows 11 Enterprise LTSC 2024는 5년간의 지원을 받고 Windows 11 IoT Enterprise LTSC 2024는 10년 지원을 받습니다. 새 LTSC 릴리스는 약 3년마다 발생합니다. 이 서비스 채널은 Windows Enterprise 버전만 사용할 수 있습니다. LTSC를 선택하면 애플리케이션의 지원 가능성에 영향을 미칠 수 있습니다. 한 가지 예는 Microsoft 365 앱. |
메모
권장 결과물:
권장되는 일반 공급 채널 이외의 서비스 채널이 필요한 디바이스 목록을 만듭니다.
하드웨어 새로 고침 계획
Windows 11 하드웨어 새로 고침 계획에 영향을 미칠 수 있는 특정 하드웨어 요구 사항 있습니다. 기존 하드웨어 중 일부는 Windows 11 호환되지 않으므로 일반 새로 고침 주기가 일반적으로 허용하는 것보다 일찍 교체해야 할 수 있습니다.
필요한 디바이스 교체의 범위는 배포 방법 선택에 영향을 줍니다. 예를 들어 대부분의 디바이스가 호환되는 경우 디바이스 교환 프로그램이 아닌 Windows 11 현재 위치 업그레이드를 고려할 가능성이 높습니다.
새 하드웨어를 선택할 때, 사용자들이 생체 인식을 활용한 비즈니스용 Windows Hello 같은 기능이나 Copilot+ PC가 필요한 Recall 기능을 사용하고 싶어 할지 여부를 고려하세요. 또한 에너지 효율이 높은 디바이스를 고려할 수도 있습니다.
메모
권장 결과물:
현재 하드웨어 새로 고침 주기의 위치를 검토하고 새 계획을 수립해야 하는지 여부를 결정합니다.
디바이스 업데이트 전략 정의
조직에 Windows 11 성공적으로 배포하려면 업데이트를 수행하는 방법을 정의하는 것이 중요합니다. 현재 위치 업그레이드, 디바이스 교체 또는 이미지 다시 설치를 수행하시겠습니까?
현장 업그레이드는 단계별 Feature Updates를 Windows Autopatch를 사용하거나 System Center Configuration Manager 작업 순서를 통해 배포하여 수행할 수 있습니다.
새 디바이스는 Windows Autopilot 또는 Windows Autopilot 디바이스 준비를 사용하여 빌드할 수 있습니다. 또는 배달 전에 하드웨어 공급업체에 구성하도록 태스크를 수행할 수도 있습니다.
조직의 요구 사항 및 디바이스 준비에 따라 이러한 접근 방식의 조합을 채택할 가능성이 높습니다.
메모
권장 결과물:
사용하려는 업그레이드 전략 또는 전략을 결정합니다. 배포 계획에서 정보를 캡처합니다.
피드백 루프 디자인
새 버전의 Windows 배포할 때는 운영 직원, 최종 사용자 및 주요 이해 관계자를 포함하여 다양한 역할의 피드백 검토를 포함하는 것이 중요합니다. 이 피드백을 수집하는 방법과 이를 사용하여 의사 결정을 지원하는 방법을 결정합니다. 피드백 방법의 예로는 전자 메일 설문 조사, 프로젝트 모임, 웹 양식, 사용자 포커스 그룹 및 사용자 그룹 챔피언 등이 있습니다.
메모
권장 결과물:
기존 또는 제안된 피드백 프로세스를 문서화합니다.
차이점 파악
업데이트를 성공적으로 배포하기 위해 해결해야 하는 간격 또는 문제를 식별합니다. 예를 들어 기술 지원팀 엔지니어는 업데이트를 지원하기 위해 더 많은 교육이 필요합니까?
여전히 도움이 필요한 권장 작업 또는 결과물이 있나요?
메모
권장 결과물:
다음 준비 단계에서 남은 간격을 문서화하고 해결하도록 계획합니다.
| 업무 | 결과물 |
|---|---|
| - 운영 준비 조건을 정의합니다. - 배포 링/단계를 정의합니다. - [선택 사항] PoC(개념 증명)를 정의합니다. - 담당자에게 역할을 식별하고 할당합니다. - 디바이스에 대한 서비스 채널을 정의합니다. - 하드웨어 새로 고침 계획. - 디바이스 업데이트 전략을 정의합니다. - 피드백 루프를 디자인합니다. - 간격을 식별합니다. |
• 운영 준비 조건 테이블 • 배포 계획(필요한 수의 배포 단계 또는 링, 날짜 및 디바이스 업그레이드 전략 포함) • [선택 사항] PoC에서 수행할 디바이스 및 테스트 목록 • 작업에 대한 역할 및 책임 또는 RACI 테이블 • 기본값이 아닌 서비스 채널이 필요한 디바이스 목록 • 하드웨어 새로 고침 계획 • 문서화된 피드백 프로세스 • 운영 격차 목록 |