준비 기준 정의
배포 계획 및 관리에는 각 활동에 가장 적합한 다양한 고유한 활동 및 역할이 포함됩니다. 이 문서에서는 중요한 역할을 식별하고 앱을 분류하는 방법을 알아내는 방법을 설명합니다.
역할 및 담당자 파악
계획할 때 배포를 수행해야 하는 역할과 해당 역할을 채워야 하는 역할을 파악하는 것이 좋습니다. 다양한 역할은 배포의 다양한 단계에서 활성화됩니다. organization 크기와 복잡성에 따라 일부 역할은 동일한 사람이 채울 수 있습니다. 그러나 배포에 대한 모든 작업을 감독할 설정된 프로세스 관리자를 두는 것이 가장 좋습니다.
프로세스 관리자
프로세스 관리자는 업데이트 배포 프로세스를 주도하고 프로세스를 앞으로 푸시하거나 필요한 경우 중지할 권한이 있습니다. 또한 이러한 활동을 구성하는 책임도 있습니다.
호환성 워크스트림 | 배포 | 기능 및 현대화 |
---|---|---|
애플리케이션 우선 순위 할당 | 인프라 요구 사항 검토 | 인프라 변경 확인 |
애플리케이션 평가 | 요구 사항에 대한 인프라 유효성 검사 | 구성 변경 확인 |
디바이스 평가 | 인프라 업데이트 계획 만들기 | 기능 제안 만들기 |
수정 작업에 대한 보고서를 수집하고, 오류를 에스컬레이션하고, 환경이 파일럿 배포 및 광범위한 배포를 위한 준비가 되었는지 여부를 결정하는 것은 프로세스 관리자의 역할입니다.
이 표에서는 책임, 관련 기술 및 필요한 배포 단계를 사용하여 다른 역할의 한 보기를 스케치합니다.
역할 | 책임 | 기술 | 활성 단계 |
---|---|---|---|
프로세스 관리자 | 프로세스를 종단 간 관리합니다. 는 입력 및 출력이 캡처되도록 합니다. 는 활동이 진행되도록 합니다. | IT 서비스 관리 | 계획, 준비, 파일럿 배포, 광범위한 배포 |
애플리케이션 소유자 | 애플리케이션 테스트 계획을 정의합니다. 사용자 동의 테스터 할당; 애플리케이션 인증 | 중요하고 중요한 애플리케이션에 대한 지식 | 계획, 준비, 파일럿 배포 |
애플리케이션 개발자 | 앱이 현재 Windows 버전과 호환되도록 개발되었는지 확인 | 애플리케이션 개발; 애플리케이션 수정 | 계획, 준비 |
최종 사용자 컴퓨팅 | 일반적으로 업그레이드 도구가 Windows와 호환되도록 하는 인프라 엔지니어 또는 배포 엔지니어를 포함한 그룹 | 운영 체제 미설치 배포; 인프라 관리; 애플리케이션 배달; 업데이트 관리 | 계획, 준비, 파일럿 배포, 광범위한 배포 |
작업 | 현재 Windows 버전에 대한 지원을 사용할 수 있는지 확인합니다. 사용자 통신 및 롤백을 포함하여 배포 후 지원을 제공합니다. | 플랫폼 보안 | 준비, 파일럿 배포, 광범위한 배포 |
보안 | 보안 기준 및 도구 검토 및 승인 | 플랫폼 보안 | 준비, 파일럿 배포 |
이해 관계자 | 업데이트의 영향을 받는 그룹(예: 재무 책임자, 최종 사용자 서비스 또는 변경 관리) | 사업부 또는 부서의 주요 의사 결정자 | 계획, 파일럿 배포, 광범위한 배포 |
등급 앱에 대한 조건 설정
사용자 환경의 일부 앱은 핵심 비즈니스 활동의 기본 사항입니다. 다른 앱은 작업자가 자신의 역할을 수행하는 데 도움이 되지만 비즈니스 운영에는 중요하지 않습니다. 사용자 환경에서 앱 인벤토리 및 평가를 시작하기 전에 앱을 분류하기 위한 몇 가지 기준을 설정한 다음 각각에 대한 우선 순위를 결정해야 합니다. 이 프로세스는 업데이트를 배포하는 가장 좋은 방법과 발생할 수 있는 문제를 resolve 방법을 이해하는 데 도움이 됩니다.
준비 단계에서는 지금 정의한 조건을 organization 모든 앱에 적용합니다.
제안된 분류 체계는 다음과 같습니다.
분류 | 정의 |
---|---|
위험 | 핵심 비즈니스 활동 및 프로세스를 처리하는 가장 중요한 애플리케이션입니다. 이러한 애플리케이션을 사용할 수 없는 경우 비즈니스 또는 사업부가 전혀 작동하지 않습니다. |
중요 | 개별 직원이 생산성을 지원해야 하는 애플리케이션. 여기서 가동 중지 시간은 개별 사용자에게 영향을 주지만 비즈니스에 미치는 영향은 최소화합니다. |
중요하지 않음 | 이러한 앱을 한동안 사용할 수 없는 경우 비즈니스에 영향을 주지 않습니다. |
애플리케이션을 분류한 후에는 각 분류가 우선 순위 및 심각도 측면에서 organization 의미하는 바에 동의해야 합니다. 이 활동은 적절한 수준의 긴급도로 문제를 심사할 수 있도록 하는 데 도움이 됩니다. 각 앱에 시간 기반 우선 순위를 할당해야 합니다.
다음은 우선 순위 등급 시스템의 예입니다. 세부 정보는 organization 따라 달라질 수 있습니다.
Priority | 정의 |
---|---|
1 | 식별된 모든 문제 또는 위험을 가능한 한 빨리 조사하고 해결해야 합니다. |
2 | 영업일 기준 2일 이내에 위험 및 문제 조사를 시작하고 현재 배포 주기 동안 해결합니다. |
3 | 영업일 기준 10일 이내에 위험 및 문제 조사를 시작합니다. 현재 배포 주기 내에서 모두 수정할 필요는 없습니다. 그러나 모든 문제는 다음 배포 주기가 끝날 때까지 수정해야 합니다. |
4 | 영업일 기준 20일 이내에 위험 및 문제 조사를 시작합니다. 현재 또는 향후 개발 주기에서 수정할 수 있습니다. |
우선 순위와 관련이 있지만 고유한 것은 심각도의 개념입니다. 앱의 문제가 배포 주기에 영향을 주어야 한다고 생각하는 방식에 따라 심각도 순위도 정의해야 합니다.
예를 들면 다음과 같습니다.
심각도 | 효과 |
---|---|
1 | 작업 중단 또는 수익 손실 |
2 | 사업부의 생산성 손실 |
3 | 개별 사용자의 생산성 손실 |
4 | 사용자에게 미치는 영향 최소화 |
예: 대형 금융 회사
제안된 체계를 사용하여 금융 회사는 다음과 같이 앱을 분류할 수 있습니다.
앱 | 분류 |
---|---|
신용 처리 앱 | 위험 |
최전방 고객 서비스 앱 | 위험 |
PDF 뷰어 | 중요 |
이미지 처리 앱 | 중요하지 않음 |
또한 다음과 같은 심각도 및 우선 순위 순위와 이 분류를 결합할 수 있습니다.
분류 | 심각도 | Priority | 응답 |
---|---|---|---|
위험 | 1 또는 2 | 1 또는 2 | 1의 경우 해결될 때까지 배포를 중지합니다. 2의 경우 영향을 받는 디바이스 또는 사용자에 대해서만 배포를 중지합니다. |
중요 | 3 또는 4 | 3 또는 4 | 3의 경우 해결 방법 지침이 있는 한 영향을 받는 디바이스의 경우에도 배포를 계속합니다. |
중요하지 않음 | 4 | 4 | 모든 디바이스에 대한 배포를 계속합니다. |