IO 기능: ITIL/COBIT 기반 관리 프로세스 - 표준화 -> 합리화

  • 아티클
이 페이지의 내용

소개 소개
요구 사항: 운영, 최적화 및 변경 프로세스 요구 사항: 운영, 최적화 및 변경 프로세스

소개

인프라 최적화 모델에서 강조하는 모든 작업에 대해 최적의 방법 프로세스를 정의해야 얻어지는 이점과 성능이 극대화됩니다. 다음 표에는 ITIL/COBIT 기반 관리 프로세스의 합리화 수준으로 이동함에 따른 상위 과제, 해당 솔루션 및 이점이 나열되어 있습니다.

과제

솔루션

이점

업무상 과제

SLA가 비공식이거나 암시적임

비공식 구성 관리가 기본 빌드 검사 목록과 스프레드시트로 구성됨

IT 과제

릴리스 관리가 비공식적임

프로젝트

IT 운영 전반에 걸쳐 서비스 수준 관리 구현

최적의 릴리스 관리 방법 구현

네트워크 및 시스템 관리 프로세스 최적화

최적의 작업 예약 방법 구현

업무상 이점

사전 대처 방식의 IT 운영이 문제를 조기에 해결하여 사용자 생산성 저하를 방지함

IT 이점

자동화된 서비스와 도구로 인해 여유 리소스가 늘어나 새로운 서비스를 구현하거나 기존 서비스를 최적화할 수 있음

공식 SLA가 IT의 신뢰성을 높여 IT와 비즈니스를 연결해 줌

합리화 수준의 최적화를 달성하려면 사고 관리, 문제 관리, 사용자 지원, 구성 관리 및 변경 관리 등에 대한 절차가 조직에 정의되어 있어야 합니다.

요구 사항: 운영, 최적화 및 변경 프로세스

대상

서비스 수준 관리, 릴리스 관리, 시스템 관리, 네트워크 관리, 작업 예약 등에 대한 프로세스가 마련되어 있지 않으면 이 절을 읽어야 합니다.

개요

인프라 최적화는 제품과 기술의 범위를 넘어섭니다. 작업자와 프로세스는 조직 IT 서비스 성숙도의 큰 부분을 구성합니다. 많은 표준과 최적의 방법을 수행하는 조직에서 IT 서비스 관리의 일부로 작업자 및 프로세스 영역을 다룹니다. MOF(Microsoft Operations Framework)는 ITIL(IT Infrastructure Library) 및 COBIT(Control Objectives for Information and related Technology) 표준에 포함된 지식 중 많은 부분을 적용하여 Microsoft 고객이 실제로 사용하고 달성할 수 있게 만듭니다.

1단계: 평가

운영 관리에 속한 평가 단계의 목표는 조직의 현재 기능과 문제를 평가하는 것입니다. 운영 평가 프로세스를 지원하기 위해 Microsoft는 MOF(Microsoft Operations Framework) SMA(Service Management Assessment)를 MOF Continuous Improvement Roadmap의 일부로 개발했으며 MOF Self-Assessment Tool이라는 약식 온라인 버전도 개발했습니다.

그림 16. MOF Continuous Improvement 수명 주기

그림 16. MOF Continuous Improvement 수명 주기

MOF Service Management Assessment는 작업자 및 IT 서비스 관리 프로세스의 성능 향상과 비즈니스 가치를 개선하는 기술 사용에 중점을 둡니다. SMA의 결과로 생성된 모든 권장 사항은 비즈니스 가치에서 자세히 설명되고 정당화되며 개선 사항이 구현됨에 따라 특정 핵심 성과 지표로 진행률을 모니터링하기 위해 지원되는 자세한 서비스 개선 로드맵이 제공됩니다.

2단계: 식별

MOF Service Management Assessment의 결과는 식별 단계의 기초를 이룹니다. 평가를 통해 IT 운영의 잠재적 개선이 필요한 여러 영역이 노출되는 경우가 있습니다. 식별 단계에서는 이러한 결과를 고려하고 비즈니스 요구를 기반으로 개선 프로젝트의 우선 순위를 지정합니다. 이 우선 순위 지정을 돕기 위한 도구와 작업 지원이 MOF Continuous Improvement Roadmap에 포함되어 있습니다.

3단계: 평가 및 계획

운영 개선을 위한 평가 및 계획 단계는 개선을 위해 식별되어 우선 순위가 지정된 영역에 의존합니다. MOF SIP(Service Improvement Program) 지침을 통해 이 단계를 수행할 수 있습니다. SIP는 특정 MOF/ITIL 프로세스 개선 및 서비스 개선 지침의 2가지 주요 중점 영역으로 나뉩니다. 이 지침은 사용자가 특정 문제 지점을 확인하는 도구를 통해 전달되어 완화에 중점을 둔 개선 지침을 제공하며 핵심 성과 지표로 프로세스 개선을 측정하기 위해 지원됩니다.   

합리화 수준으로 이동 시 권장되는 프로세스

이 절의 권장 사항은 표준화 수준에서 발견한 일반 문제와 합리화 수준에서 모색한 개선 영역을 기반으로 합니다. 이들은 권장 사항일 뿐이며 특정 조직이나 업계에서는 다를 수도 있습니다.

표준화 수준으로 인해 IT 운영과 인프라(변경 관리, 구성 관리 및 릴리스 관리와 같은 프로세스가 표준화되어 예측할 수 있는 환경 포함)를 관리하고 모니터링하기 위한 도구의 사용이 늘어나더라도 주요 영역에는 개선의 여지가 있습니다. 서비스 수준 관리는 비공식이거나 암시적인 서비스 수준 계약(SLA)으로 이루어지는 원시적인 상태입니다. 구성 관리는 비공식이고 대개 기본 빌드 검사 목록과 스프레드시트로 이루어져 있으며 릴리스 관리는 잘 정의되어 있지 않고 정확성이 결여되어 있습니다.

합리화 인프라는 데스크톱과 서버 관리에 관련된 비용이 가장 낮은 수준이고 프로세스와 정책이 최적화되어 비즈니스 지원 및 확장에서 큰 역할을 하기 시작하는 곳입니다. 보안에 대한 사전 대처가 매우 뛰어나며 위협 및 문제에 대해 신속하고 용이하게 대처합니다. 무접촉 배포의 사용은 비용, 배포 시간 및 기술 단점을 최소화하는 데 도움이 됩니다. 이미지 수가 최소한으로 유지되고 데스크톱 관리 프로세스의 관여도가 매우 낮습니다. 이러한 고객은 분명한 하드웨어 및 소프트웨어 인벤토리를 갖추고 필요한 라이선스와 컴퓨터만 구입합니다. 보안은 데스크톱에서 서버, 방화벽, 엑스트라넷에 이르는 엄격한 정책과 통제를 통해 매우 예방적으로 유지됩니다.

Microsoft는 IT 운영을 정의하고 개선하기 위한 반복 모델로 MOF(Microsoft Operations Framework를 제공합니다. MOF는 서비스 관리 기능(SMF)을 IT 조직 내의 논리적 운영 기능으로 정의합니다. SMF는 변경, 운영, 지원 및 최적화의 4가지 넓은 영역 또는 4분면으로 분류됩니다. 본 가이드에서는 다음과 같이 표준화 수준의 최적화를 달성한 조직에서 대개 발견되는 영역에 중점을 둡니다.

  • 서비스 수준 관리

  • 릴리스 관리

  • 시스템 관리

  • 네트워크 관리

  • 작업 예약

조직에 따라 이러한 서비스 관리 기능의 개선 사항이 운영 효율성과 개선에 가장 큰 영향을 미칠 수도 있고 미치지 않을 수도 있습니다. 가급적 전체 서비스 관리 평가를 수행하거나 최소한 온라인 자체 평가를 수행하여 프로세스나 서비스 개선이 필요한 가장 중요한 영역을 파악할 것을 권장합니다.

서비스 수준 관리

서비스 수준 관리(SLM)는 비즈니스 요구에 IT 서비스 전달을 맞추는 중요한 프로세스로, 다른 SMF가 합당한 비용으로 비즈니스 요구 사항과 일치하는 IT 솔루션을 제공할 수 있게 해 주는 비즈니스 인터페이스를 제공합니다. SLM의 기본 목표는 IT 서비스를 성공적으로 전달, 유지 관리 및 개선하는 것입니다.

SLM은 정의, 계약, 운영 평가 및 검토 프로세스를 통해 IT 서비스를 정렬하고 관리하는 데 사용됩니다. SLM의 범위에는 조직의 IT 서비스를 정의하고 SLA를 설정하는 것이 포함됩니다. SLA 이행은 기본 계약(UC)과 운영 수준 계약(OLA)을 내부 또는 외부 서비스 전달에 사용하여 보장됩니다. 서비스 수준 관리를 비즈니스에 도입한다고 해서 전달된 서비스 수준이 즉시 개선되는 것은 아닙니다. SLA는 장기적으로 진행되는 작업입니다. 처음에는 서비스가 거의 바뀌지 않을 가능성이 높지만 시간이 지나면서 대상이 충족되고 초과됨에 따라 개선됩니다.

조직에서 서비스 수준 관리를 구현하려면 먼저 IT가 조직의 고객에 제공하는 서비스를 평가하고 해당 서비스에 대해 현재 마련되어 있는 기존 서비스 계약을 판단해야 합니다. 이 평가를 거치면 IT 서비스 부서에서 전달해야 할 서비스의 전체 범위를 인식할 수 있는데, 이때 처음으로 이러한 범위가 인식되는 경우도 있습니다. 그런 다음 이 연습을 통해 얻은 정보를 사용하여 조직에서 서비스 수준 관리 프로세스의 전체 이점을 개발하고 구현할 수 있습니다.

서비스 수준 관리를 구현하려면 IT 조직에서 제공하는 서비스를 완전히 이해해야 합니다. 서비스 수준 관리를 구현하는 단계는 다음과 같습니다.

  • 서비스 카탈로그 만들기

  • SLA 개발

  • 모니터링 및 보고

  • 정기 서비스 수준 검토 수행

SLA는 서비스 카탈로그에 문서화된 서비스의 요구 사항 및 우선 순위, SLA 조정 하에 지정된 요구 사항, 계약 기준에 대한 서비스 모니터링, 서비스 수행 수준에서 장애를 강조 표시하고 제거하기 위한 정보 보고 및 검토 등에 따라 개발됩니다.

4단계: 배포(서비스 수준 관리)

설정 작업

설정 작업은 서비스 수준 관리 프로젝트를 시작할 때 수행되는 일련의 평가 단계입니다. 이러한 준비 단계는 회사에서 서비스 수준 관리에 대한 요구가 있는지와 서비스 수준 관리를 구현할 리소스를 가지고 있는지 판단하는 데 도움이 됩니다. 이 프로세스의 일부로 IT 부서는 기존 서비스와 관리 작업의 스냅샷을 찍어 비즈니스 기준을 설정합니다. 최종 단계는 이전 단계에서 수집한 정보를 분석하고 그 결과를 사용하여 비즈니스 이익을 극대화하도록 서비스 수준 관리의 구현 계획을 세우는 것입니다.

서비스 카탈로그 만들기

서비스 카탈로그는 현재 제공되고 있는 서비스를 모두 나열하고 서비스 특성을 요약하며 서비스 사용자를 설명하고 지속적인 유지 관리를 책임지고 있는 담당자를 자세히 알려 줍니다.

서비스는 비즈니스 조직의 인지에 의해 정의됩니다. 예를 들어 전자 메일과 인쇄는 서비스를 최종 사용자에게 전달하는 데 필요한 서비스 구성 요소 수와 관계없이 서비스가 될 수 있습니다.

서비스 카탈로그 정식화는 공식 승인된 레코드를 만드는 중요한 단계입니다. 서비스 카탈로그를 조직 내의 공식 레코드로 만들면 해당 카탈로그가 변경 제어 하에 놓이는데, 이는 레코드가 유지 관리되고 정확한 경우에만 가치를 지니기 때문에 중요합니다.

많은 방법으로 서비스 카탈로그를 정식화할 수 있습니다. 가장 적합한 방법을 결정할 때는 서비스 카탈로그의 확인, 보고 및 사용 방법을 고려하십시오. 서비스 카탈로그는 하나의 구성 요소(서비스 카탈로그)나 해당 서비스로 저장되어 구성 관리 데이터베이스(CMDB)에 속할 수 있습니다. Microsoft Excel이나 Microsoft Access와 같은 Microsoft 응용 프로그램을 사용하여 서비스와 세부 정보(예: 구성 요소, 효과, 우선 순위, SLA 및 SLO)를 기록할 수 있습니다. 선택한 도구를 사용하여 서비스 카탈로그를 CMDB에 넣을 수 있으면 서비스 카탈로그에 있는 정보를 CMDB에 있는 구성 항목(CI)과 통합하여 가치를 추가할 수 있습니다. 그런 다음 이를 통해 변경 관리 SMF, 사고 관리 SMF 및 CMDB를 사용하는 다른 모든 SMF에 가치를 추가할 수 있습니다.

서비스 수준 계약(SLA) 개발

SLA는 IT 서비스 공급자와 소비자/사용자 커뮤니티 간의 계약입니다. SLA에서는 서비스 수준에 대한 고객/사용자 요구 사항을 정식화하고 모든 참여 당사자의 책임을 정의합니다.

SLA를 만드는 단계는 다음과 같습니다.

  • SLA 유형을 정의합니다. 예를 들어 내부, 외부, 운영 수준 또는 다중 서비스 수준 계약입니까?

  • SLA를 정의합니다. 예를 들어 가용성, 대응성 및 성능, 무결성 및 정확성, 보안 등의 평가 가능한 사항을 포함하여 전달할 서비스 수준을 정의합니다.

  • SLA를 조정하고 동의합니다. 예를 들어 동의한 사항을 회사와 IT 부서에 합당한 비용으로 전달할 수 있는지 판단합니다.

  • SLA를 문서화합니다. 예를 들어 작성 시 동의한 사항과 관련 당사자를 기록합니다.

SLA, OLA 및 UC 내용 조정

타사 서비스 공급자와 체결하여 SLA 서비스 결과물의 기반이 된 법적 구속력을 지닌 계약인 기본 계약(UC)과 SLA 요구 사항을 지원하는 내부 계약인 운영 수준 계약(OLA)은 SLA 내용과 일치하는 서비스 메트릭을 가져야 합니다.

서비스 수준 모니터링

서비스 수준 관리를 달성하려면 동의를 하고 IT 서비스 실적을 모니터링 및 보고하며 서비스 수준과 비즈니스 요구 및 비용 간의 균형을 맞추는 적절한 조치를 취하는 등의 주기가 지속적으로 순환되어야 합니다.

동의를 거쳐 SLA가 마련된 경우 유효한 서비스 수준 관리의 다음 단계는 서비스 수준 목표(SLO)에서 지정한 기준에 대해 서비스 성능을 모니터링하는 것입니다. 다양한 방법으로 서비스 수준 관리를 모니터링할 수 있지만 주된 관심사는 SLA를 위반하거나 SLA 위반에 근접하는 기준이 있느냐 하는 것입니다.

서비스 수준 계약 검토

SLA 검토는 4가지 MOF 운영 관리 검토(OMR) 중 하나로, 주요 관리 검사점이며 지정한 간격(SLA에서 문서화됨)으로 발생합니다. 이 검토는 SLA 목표에 대해 성능을 평가하고 SLA 운영을 검토할 기회를 회사와 IT 부서에 주기 위한 것입니다. SLA 검토는 상위 관리를 검토 프로세스에 포함시켜서 회사와 IT 부서가 모두 향후에 내려질 모든 서비스 전달 관련 결정에 참여하고 통신을 할 수 있도록 합니다.

릴리스 관리

릴리스 관리 서비스 관리 기능(SMF)은 변경 사항을 정보 기술(IT) 환경에 배포하는 작업을 담당합니다. 하나 이상의 변경 사항이 개발 및 테스트되어 배포 릴리스로 패키지화된 후에는 릴리스 관리가 해당 변경 사항 도입과 릴리스 관리를 담당합니다. 릴리스 관리는 변경 사항을 하나의 릴리스로 결합하여 함께 배포함으로써 변경 사항의 효율적인 도입에도 기여합니다.

릴리스 관리 프로세스의 목표는 중단을 최소화하는 방식으로 모든 변경 사항이 실제 IT 업무 환경에 성공적으로 배포되도록 하는 것입니다. 따라서 릴리스 관리는 다음을 담당합니다.

  • CAB(Change Advisory Board)와 협력하여 변경 사항을 실제 업무 환경에 배포하는 데 무엇보다 중요한 설계, 계획 및 접근 방식인 릴리스 전략 추진

  • 릴리스 기준(릴리스 품질, 릴리스 패키지, 실제 업무 환경 준비성, 교육/훈련 및 지원 계획, 롤아웃 및 백아웃 계획, 위험 관리 계획)을 기반으로 각 릴리스의 준비성 판단

릴리스 관리는 다음과 같습니다.

  • 실제 업무 환경에 배포할 모든 변경 사항에 패키지화된 릴리스를 제공하고 변경 관리를 통해 승인된 변경 사항만 배포합니다.

  • 변경 사항을 승인하고 릴리스 프로세스가 진행되는 동안 해당 변경 사항을 추적하기 위한 변경 관리를 필요로 합니다.

  • 변경이 이루어질 때 해당 변경 사항이 구성 관리에 보고되어 CMDB에 입력될 수 있도록 합니다.

  • 새 릴리스의 개발 단계에서 유효한 테스트 환경을 구축하고 확인하기 위한 구성 관리 정보를 필요로 합니다.

  • 변경 사항이 IT 환경이 미치는 영향을 평가하고 릴리스 패키지에 한정적인 저장소를 제공하기 위한 구성 관리를 필요로 합니다.

4단계: 배포(릴리스 관리)

릴리스 계획

릴리스 프로세스의 첫 번째 단계는 릴리스를 실제 업무 환경에 성공적으로 배포하는 데 필요한 작업과 리소스를 식별하기 위한 계획을 만드는 것입니다. 여기에는 수행해야 할 작업, 완료해야 할 시기(시간 척도), 다른 작업과 비교해서 부여된 우선 순위 등을 결정하는 것이 포함됩니다. 이러한 문제가 완전히 이해되면 릴리스 관리자가 세부 작업 계획을 작성하고 프로젝트에 적절한 리소스를 할당할 수 있습니다. 릴리스 관리에서 릴리스 관리자는 변경 관리를 통해 승인된 각 RFC의 릴리스(프로젝트) 계획을 작성하는 역할을 담당합니다.

릴리스 구축

릴리스 계획에 대한 동의가 이루어지면 릴리스 팀원이 릴리스를 실제 업무 환경에 배포하는 데 필요한 프로세스, 도구 및 기술을 식별하여 개발합니다. 대부분의 릴리스(모든 릴리스가 아님)를 실제 업무 환경에 수동으로 배포할 수 있지만 동일한 작업을 수행하는 데 사용할 수 있는 도구와 기술이 많이 있습니다. 시간과 리소스를 가장 잘 활용하려면 릴리스 팀에서 배포 프로세스를 최대한 많이 자동화하는 데 사용할 수 있는 도구와 기술을 식별해야 합니다.

릴리스 메커니즘이 선택되면 릴리스 팀에서 선택한 메커니즘을 사용하여 릴리스를 실제 업무 환경에 배포하거나 실제 업무 환경에서 제거하는 데 필요한 프로세스, 도구 및 기술이 포함된 릴리스 패키지를 만듭니다.

일부 리소스의 경우 릴리스 패키지가 문서화된 설치 및 제거 절차 집합으로만 이루어져 있을 수도 있습니다.

완성된 패키지는 랩 환경 테스트를 통해 릴리스 팀에 실제 업무 환경에서 사용할 경우 제대로 작동할 것이라는 확신을 주어야 합니다. 테스트가 성공적으로 완료되면 릴리스 및 릴리스 패키지 콘텐츠가 변경 관리의 제어 하에 놓입니다.

수락 테스트

지금까지 수행된 테스트의 목표는 릴리스 및 릴리스 패키지가 개발 환경 내에서 제대로 작동하는지 확인하는 것이었습니다. 수락 테스트를 통해 개발자와 업무 담당자는 실제 업무 환경과 유사한 환경에서 릴리스 및 릴리스 패키지의 상호 작동 방식을 확인할 수 있습니다. 어떤 경우에는 파일럿 테스트를 거쳐야 조직 전반의 변경 사항 배포를 진행하는 데 필요한 확신이 듭니다.

시뮬레이트된 실제 업무 환경에서의 테스트를 통해 릴리스 팀에서 릴리스의 올바른 작동을 확신한다고 해서 조건이 상당히 다를 수 있는 실제 업무 환경에서도 해당 릴리스가 잘 작동한다고 보장되는 것은 아닙니다. 따라서 실제 업무 환경에서 제어된 테스트를 다수 수행하여 릴리스가 예상과 일치하는지 확인해야 합니다. 실제 업무 환경에서의 릴리스 파일럿 테스트는 해당 환경에 많은 위험을 전달하므로 릴리스 패키지에 포함된 복구 절차가 테스트 환경에서 입증된 경우에만 수행해야 합니다.

릴리스 준비

파일럿 및 수락 테스트가 완료된 후 수행해야 할 다음 단계는 실제 업무 환경을 릴리스에 맞게 준비하고 준비 프로세스를 두루 거치며 수행할 작업(릴리스 준비성 검토로 이동 또는 추가 작업을 위해 변경 소유자나 릴리스 관리자에게 릴리스 반환)에 동의하는 것입니다.

릴리스 관리자, 변경 관리자 및 변경 소유자는 릴리스 준비성 검토 회의의 기본 참가자입니다. 그러나 릴리스 특성과 크기에 따라 테스트 팀, 서비스 부서 및 사용자 커뮤니티와 같은 다른 이해 관련 그룹의 담당자가 포함될 수도 있습니다.

릴리스가 랩 환경과 실제 업무 환경 모두의 많은 테스트를 통과하지 못해도 배포를 진행하는 데 별다른 지장이 없을 수 있습니다. 실제 업무 환경과 밀접한 관계가 있어도 업무상 어쩔 수 없이 릴리스를 배포해야 하는 많은 이유가 있을 수 있습니다.

예를 들어 B2B 상거래 사이트에서 하나의 기능(예: 자동 서명)이 작동하지 않을 수 있습니다. 이 기능을 제거하고 수동 해결 방법을 사용하는 것이 습니다. 따라서 팀에서 이 기능 없이 진행하도록 선택할 수 있습니다.

테스트를 통해 얻은 경험과 교훈(개발된 해결 방법 포함)이 선별되어 문서화됩니다. 테스트가 진행되는 동안 사용자 커뮤니티나 서비스 수준에 영향을 미치는 사안이 선택되면 배포하기 전에 서비스 부서 담당자와 해결 방법 및 예상 문제에 대해 논의하고 서비스 부서에서 해당 해결 방법을 사용할 수 있는지 확인해야 합니다. 릴리스가 계획한 대로 작동하도록 만들기 위해 추가 RFC를 발의해야 할 수 있습니다. 어떤 경우든지 결정 사항과 기타 지원 정보로 변경 로그를 업데이트해야 합니다.

릴리스 배포

릴리스를 실제 업무 환경에 배포하는 프로세스는 릴리스 유형 및 특성과 선택한 릴리스 메커니즘에 따라 다릅니다. 하지만 모든 경우에 릴리스 관리자에게 상태 보고서와 해당하는 경우 배포 진행률을 추적하고 모니터링하는 데 사용되는 도구 및 기술을 제공해야 합니다. 배포가 진행되는 동안 IT 구성 요소가 변경되면 그에 따라 CMDB에서 해당 변경 사항을 모델링하는 구성 항목과 관계도 변경해야 합니다.

릴리스가 배포되면 릴리스 관리자는 추가 배포를 진행하기 전에 해당 릴리스가 제대로 작동하는지 확인합니다. 기술 지원 담당자가 많은 도구와 기술을 사용하여 확인할 수 있는 릴리스도 있고 릴리스 관리자가 서비스 부서에 요청하여 개별 사용자의 피드백과 의견을 받아야 하는 릴리스도 있습니다.

릴리스가 예상한 대로 작동하지 못하거나 배포하는 동안 심각한 문제가 발생하면 문제의 근본 원인을 식별하고 진단하는 데 도움이 되는 문제 관리가 필요할 수 있습니다. 적합한 수정 또는 해결 방법을 찾을 수 있으면 해당 사항과 이를 실제 업무 환경에 배포하기 위해 생성된 변경 요청을 문서화해야 합니다. 찾을 수 없으면 백아웃 절차를 사용하여 릴리스를 해당 환경에서 제거하는 것이 적합할 수 있습니다.

릴리스 배포 단계가 완료되면 릴리스 프로세스에서 결과와 릴리스 지원 시 제기된 해결 방법이나 RFC에 대한 정보가 기록되었는지 확인해야 합니다. 릴리스를 백아웃해야 할 경우에도 이 결정을 지원하는 정보를 포함하여 해당 사항을 기록해야 합니다.

시스템 관리

시스템 관리 기능은 보안 관리, 서비스 모니터링 및 제어, 작업 일정 계획, 네트워크 관리, 디렉터리 서비스 관리, 인쇄 및 출력 관리, 스토리지 관리 등을 수행합니다. 이 기능을 설계, 개발 및 구현하는 방법은 조직의 크기와 구조에 따라 결정됩니다. 대규모 조직에는 명확하게 정의된 모델이 있는 반면 소규모 조직에는 시스템의 상태와 운영 기능을 유지 관리하기 위해 기능이 통합되어 있을 가능성이 높습니다.

시스템 관리 SMF의 목표는 하루하루 기준으로 컴퓨팅 환경을 관리하는 것입니다. 여기에는 실제 업무 환경 내에서 다양한 요소에 대한 운영 지원을 관리하고 제공하는 것이 포함됩니다.

시스템 관리 기능은 중앙 하드웨어와 분산 하드웨어가 모두 포함된 컴퓨팅 환경을 지원하여 관리 서비스를 제공하는 역할을 담당합니다.

시스템 관리 기능이 구현 및 관리를 직접 담당하고 있지 않은 다른 SMF의 기능 관리에 대한 지원을 제공할 수도 있습니다. 이러한 지원에는 다음이 포함됩니다.

  • 서비스 모니터링 및 제어 기능을 위한 첫 번째 수준의 성능 및 용량 모니터링

  • 계정 관리의 일상적인 기능 관리(계정 추가, 삭제 또는 이동 포함) 디렉터리 서비스 관리 및 보안 관리를 위한 리소스(예: 프린터 및 보안 액세스 권한) 조회

  • 인쇄 및 출력 관리를 위해 인쇄된 보고서와 출력을 생산하는 데 사용되는 리소스의 관리

  • 중요한 데이터를 백업하고 복원하는 데 필요한 관리 작업

  • 파일, 폴더 및 프린터를 포함하여 데이터와 공유 네트워크 리소스를 보호하기 위한 보안 정책 적용

4단계: 배포(시스템 관리)

중앙 집중식 관리 모델 구현

중앙 집중식 모델에서 운영과 지원 기능은 모두 또는 대부분 중앙의 단일 사이트나 다중 사이트에 위치합니다. 로컬 영역, 광역, 분산 및 클라이언트 서버 컴퓨팅과 해당 지원 네트워크가 성숙해짐에 따라 점점 더 많은 조직에서 설치된 리소스, 응용 프로그램 및 솔루션에 대한 지원을 비약적으로 중앙 집중화했습니다.

원격 사이트와 지사에 대한 대역폭은 가용 범위가 더욱 넓어지고 경제적으로 더욱 여유로워졌습니다. 지사 컴퓨팅을 지원하는 기본 기술(전송 프로토콜, 원격 액세스 도구, 무헤드 서버 등)은 더 이상 각 지사마다 별개의 자체 지원 담당자를 둘 필요가 없을 정도까지 개선되었습니다. 따라서 회사에서 점점 원격 사이트나 지사에 분산된 시스템의 가용성, 안정성, 일상적인 지원 및 관리를 유지 관리하는 데 필요한 기본 지원 기능을 중앙 집중화할 수 있습니다.

중앙 집중식 관리에서는 대개 관리 중인 컴퓨팅 시스템과 리소스가 모두 또는 대부분 중앙에 위치한다고 간주합니다. 이것이 점점 진실이 되어가고 있지만 특정 솔루션(즉, 사용자 지정 응용 프로그램, 특수 데이터베이스 등)이 회사 데이터 센터에 중앙 집중화되는 대신 원격 지사나 사이트에 분산되는 경우도 계속해서 존재합니다. 일부 응용 프로그램과 데이터베이스의 이러한 분산이 관리 모델에 대해 중앙 집중식 접근 방식을 취하지 못하게 하는 것은 아닙니다.

중앙 집중식/원격 관리 모델 구현

중앙 집중식/원격 관리 모델은 완전한 중앙 집중식 모델의 이점을 대부분 달성합니다. 대부분의 관리가 계속해서 중앙 위치(예: 중앙 데이터 센터)에서 수행되므로 관리 기능을 실행하는 데 필요한 제어 및 리소스 통합이 가장 좋은 상태로 유지됩니다.

그러나 적어도 최소한의 지역화된 관리가 존재하고 원격 데이터 센터 환경을 유지 관리해야 한다는 요구 사항이 있기 때문에 일부 제어 및 리소스 통합은 포기됩니다. 분산 시스템의 개선 시스템 유지 관리 요구 사항에는 반드시 컴퓨터를 다시 부팅하고 테이프 백업과 저장 의무를 수행해야 하는 시스템 업데이트가 포함될 수 있습니다. 관리 중인 응용 프로그램이나 특정 시스템에 따라 추가 로컬 사이트 관리 요구 사항이 있을 수 있으므로 기술 응용 프로그램을 기반으로 필요한 특정 책무를 판단해야 합니다.

중앙 집중식/원격 관리 모델은 중앙 위치에 모든 주요 관리 제어가 남아 있는 원격 위치에 분산된 시스템을 설명합니다. 앞서 설명한 바와 같이 이제 서버 또는 저장 장치를 수용하려면 원격 위치나 지역에 데이터 센터가 존재해야 합니다. 즉, 이제 실제 공장, 바닥 공간, 전력, 배선, HV/AC 및 보안 구성 요소를 포함한 데이터 센터 인프라 비용이 발생합니다.

이 모델이 더 이상 실용적이지 않은 정도(더 이상 서비스 수준 계약을 충족하지 않는 정도)나 더 이상 비용 대비 효과가 높지 않은 정도까지 기술 응용 프로그램이 발전하면 분산 관리 모델로 이동해야 합니다. 분산 관리 모델에서 컴퓨팅 리소스와 인력 리소스는 물리적으로 원격 위치에 있습니다. 이 모델은 다음 절에서 설명합니다.

중앙 집중식/위임 관리 모델

이 모델은 중앙 집중식/원격 관리 모델의 장점을 모든 고유 기능 및 이점과 함께 받아들이려고 하지만 분산 관리 모델의 일부 이점도 실현합니다. 이러한 이점은 관리 작업과 책무의 비교적 작은 특수 하위 집합을 로컬 지사와 원격 사이트에 강제로 밀어 넣어 달성됩니다.

중앙 집중식 모델과 마찬가지로 기본 관리 기능과 관리 인력이 회사(중앙) 데이터 센터에 상주하고 모든 관리 방향과 제어가 이 위치에서 비롯됩니다. 중앙 리소스가 계속해서 데이터 센터 기반의 중앙 네트워크 서버와 서비스를 관리하는데, 이러한 중앙 리소스는 가능하고 합당하며 해당하는 경우 계속해서 네트워크를 통해 서비스를 원격으로 관리합니다.

특정 서비스, 서버 및 리소스를 분산해야 하는 특정 상황에서는 일부 관리 작업이 지역 또는 원격 위치에서 수행되도록 하는 것이 현명하고 더욱 효율적일 수도 있습니다. 이것은 매우 구체적인 권한을 원격 위치 리소스에 위임하여 수행됩니다. "매우 구체적인 권한"은 원격 관리자가 분리된 특정 작업을 수행할 수 있게 해 주는 관리 권한과 액세스의 작은 하위 집합을 의미합니다.

분산 관리 모델 구현

다른 모델과는 달리 분산 관리는 원격 사이트나 지사에 있는 전체 지원 리소스에 의존합니다. 원격 사이트에 있는 리소스가 해당 사이트에 분산된 시스템의 상태, 가용성 및 안정성을 유지 관리하는 데 필요한 기본 지원 기능(중요해도 마찬가지임)을 수행합니다.

원격 위치에 분산된 시스템을 유지 관리하도록 만드는 비즈니스 원동력이 계속해서 존재할 수 있습니다. 이러한 원동력 중 일부는 성능, 확장성, 특정 응용 프로그램 유형, 중앙 솔루션을 지원하는 네트워크 대역폭의 비용 또는 가용성 등과 관련될 수 있습니다.

컴퓨팅 리소스와 인력 리소스는 원격 사무실과 지역 사이트에 완전히 분산됩니다. 따라서 특정 기술 응용 프로그램의 경우 조직에서 훨씬 더 나은 로컬 사이트 성능을 실현할 수 있습니다.

중앙 집중식 데이터 센터 모델의 분산 관리 구현

여기에서 ""24/7 지원 체제(Follow-the-sun)" 모델이라고 하는 다섯 번째 시스템 관리 모델은 "분산 관리-중앙 집중식 데이터 센터" 모델(둘 이상)이라고도 합니다.

이 상황에서 "24/7 지원 체제"는 닫히는 사무실도 있고 열리는 사무실도 있으므로 이 지원에 대한 책무를 전 세계의 다른 지역으로 이전하여 지원을 전 세계적으로 매일 24시간 일주일 내내 제공하는 것을 의미합니다.

이 모델은 다소 특이하며 앞서 설명한 4가지 기본 모델만큼 널리 구현되지는 않습니다. 그러나 이 모델을 해당 조직에 구현하려고 했거나 현재 구현을 시도하고 있는 회사들이 있습니다.

네트워크 관리

네트워크 관리 서비스 관리 기능은 컴퓨터 시스템과 공유 주변 장치 간의 통신에 사용되는 인프라 구성 요소인 운영 네트워크에 중점을 둡니다. 가장 기본적인 수준의 IT 인프라이며 네트워크 설비가 없으면 인프라는 없고 그저 개별 컴퓨터를 모아 놓은 것에 불과합니다.

네트워크 관리 SMF의 목표는 하루하루 기준으로 네트워크 환경을 관리하기 위한 프로세스의 확고한 기반을 제공하고 참조하는 것입니다. 여기에는 실제 업무 환경 내에서 다양한 요소에 대한 운영 지원을 관리하고 제공하는 것이 포함됩니다. SMF의 목표에는 기존 네트워크 설비를 확장하기 위한 계획 및 배포 서비스와 네트워크 환경의 문제를 해결하고 장애를 복구하기 위한 지원 서비스를 제공하는 것이 포함됩니다. 네트워크 관리 SMF의 효과적인 구현을 통해 IT 조직에서 기대할 수 있는 사항은 다음과 같습니다.

  • 네트워크 인프라 배포 개선

  • 문제 해결 프로세스 및 관련 사고 관리 프로세스 개선

  • 네트워크 안정성 제고

  • IT 솔루션 및 서비스의 가용성 향상

일반 네트워크는 케이블, 라우터, 스위치, 허브, 실제 서버 및 기타 구성 요소를 포함한 하드웨어와 하드 구성 요소가 활용되는 방식을 제어하는 소프트웨어나 구성 요소로 이루어져 있습니다. OSI(Open Systems Interconnection)에 설명된 네트워킹 모델에서 일반 IT 인프라는 모든 서비스에 사용되는 스택 맨 아래의 기본 구성 요소에서 맨 위의 특수 응용 프로그램에 이르는 계층에 구성됩니다.

OSI 스택을 구성하는 계층은 다음과 같습니다(위에서 아래로).

  1. 응용 프로그램

  2. 프레젠테이션

  3. 세션

  4. 전송

  5. 네트워크

  6. 링크(데이터 링크)

  7. 물리적

네트워크 관리는 대개 스택의 처음 3개 계층(대부분이 하드웨어로 이루어져 있음)과 관련됩니다. 전송 수준에서 네트워크 관리와 시스템 관리 사이에 중복되는 부분이 약간 있는데, 여기에는 한 지점에서 다른 지점으로 데이터를 전송할 수 있게 해 주는 링크 및 네트워킹 프로토콜이 포함됩니다. MOF 관점에서 볼 때 DNS, WINS 및 DHCP와 같은 서비스의 관리는 모든 기능을 갖춘 IT 서비스에 대한 기본적인 이름 확인 서비스를 제공합니다. 조직에 따라서는 이러한 핵심 서비스가 네트워크 서비스 기능으로 포함될 수도 있습니다. DNS, WINS 및 DHCP가 서버에서 실행되므로 네트워크 관리 SMF로 관리되는 하드웨어 구성 요소 사이에 네트워크 서버가 포함되기도 합니다.

4단계: 배포(네트워크 관리)

네트워크 유지 관리

네트워크 인프라 운영은 주로 성능 모니터링, 예상 기준에 따른 성능 평가, 성능이 급격히 저하된 경우 문제를 해결하기 위한 작업 항목 생성 등에 관한 문제입니다. 네트워크 내의 하드웨어 구성 요소 중 대부분은 장애 간 평균 시간에 대한 제조업체 명세와 기타 성능 기준 내에서 실제 유지 관리나 개입 없이 제대로 작동해야 합니다. MOF 용량 관리 SMF는 네트워크 설계팀에서 네트워크 성능을 최적화하는 데 도움이 되는 용량 계획에 대한 자세한 정보를 제공합니다.

그러나 네트워크의 서버 기반 구성 요소에 정기적으로 관심을 기울여야 합니다. 이러한 구성 요소에는 정기 백업(해당하는 경우)과 스토리지 관리 SMF에 따른 스토리지 및 용량 요구 사항 평가가 필요합니다.

네트워크 지원

네트워크 지원은 지원 4분면, 특히 사고 관리 SMF 및 문제 관리 SMF에 속한 작업과 밀접하게 연관되어 있습니다. 사고 관리 SMF에 설명된 사고 해결 프로세스를 통해 IT 네트워킹 전문가는 네트워크 오류를 수정하고 해결 방법을 개발하며 임박한 네트워크 문제를 방지하거나 완화합니다. 일반 사고 해결 프로세스는 사고 관리 SMF 지침 문서에서 설명하지만 네트워크별 문제 해결 프로세스는 다음 절에서 제공합니다.

작업 예약

작업 예약 서비스 관리 기능(SMF)은 시스템 리소스 사용은 최대화하고 온라인 사용자에 미치는 영향은 최소화하기 위해 미리 결정된 시간에 규정된 순서대로 데이터가 효율적으로 처리되도록 하는 것에 관계가 있습니다. 배치 프로세스는 백그라운드에서 최종 사용자의 상호 작용 없이 순차적으로 실행되는 데이터베이스와의 시스템 상호 작용입니다. 배치 프로세스 실행은 자동화될 수도 있고 수동으로 시작될 수도 있습니다. 배치는 일반적으로 업무 시간이 지난 후 사용자와 시스템 간의 상호 작용이 적을 때 실행됩니다.

리소스 사용량이 많으면서 오래 실행되는 반복 프로세스인 경향이 있으므로 배치를 실행하려면 대개 자체 아키텍처가 있어야 합니다. 프로세스에는 일반적으로 데이터베이스에서 대량의 데이터를 읽고 데이터를 처리한 다음 결과를 데이터베이스에 반환하는 것이 포함됩니다. 이 프로세스는 스크립트 실행을 통해 수행됩니다.

조직에서 실행하는 배치 작업 유형에는 다음이 포함됩니다.

  • 재무 관리 보고서

  • 마케팅 보고서

  • 공급망 관리 보고서

  • 인벤토리 보고서

  • 구매서 보고서

  • 고객 계정 처리(월간 계정 대금 청구 등)

  • 시스템 및 응용 프로그램 데이터 자동 백업

  • 시스템 처리 요약 및 용량 계획 보고서

4단계: 배포(작업 예약)

배치 아키텍처

배치 아키텍처는 배치 처리를 효과적으로 관리하는 데 사용되는 프로세스와 구성 요소로 이루어져 있습니다. 배치 아키텍처의 목적은 작업량이 많지 않은 기간 동안 배치를 실행하여 처리를 최적화(시스템 리소스의 응답 시간 및 활용률 개선)하는 것입니다. 아키텍처는 용량 관리자가 인터페이스를 손쉽게 사용할 수 있고 표준 및 중앙 집중식 접근 방식을 통해 예약, 모니터링, 제어 및 오류 수정을 일괄 처리하도록 허용해야 합니다. 아키텍처는 조직의 향후 요구를 충족하기 위해 확장성이 높아야 합니다. 또한 가용성이 높고 가동 중지 시간이 최소이며 일반적으로 배치 작업과 동시에 수행되는 온라인 작업에 미치는 영향을 최소화해야 합니다. 일부 조직에서 업무상 중요한 배치 작업이 모두 완료되도록 하기 위해 이벤트 서버와 같은 백업 구성 요소를 마련하도록 결정할 수 있습니다.

배치 아키텍처의 기본 구성 요소에는 관리 서버, 용량 데이터베이스(CDB), 모니터, 프린터, 응용 프로그램 서버, 데이터베이스 등이 있습니다. 관리 서버에 연결된 모니터 외에도 각 응용 프로그램 서버에 모니터가 있어야 로컬 배치 처리 작업을 볼 수 있으며 이 경우 로컬 수준에서의 오류 분석도 용이해집니다.

배치 처리

예약된 배치 실행에 대해 논의하기 전에 먼저 배치 프로세스의 계층 구조와 배치 스크립트의 내용을 이해하면 유익합니다. 배치 실행은 되풀이해서 실행하도록 예약된 여러 독립 배치 작업으로 이루어져 있습니다. 대규모 조직에서는 처리에 필요한 리소스에 따라 하루 종일 여러 배치 실행을 실행할 수 있습니다. 각 배치 작업은 작업 실행의 특정 활동을 제어하는 여러 배치 작업 단계로 이루어져 있습니다.

조직에서는 대개 많은 배치 작업을 처리합니다. 각 작업의 실행 방식을 일관성 있게 유지하려면 각 작업에 필요한 표준화된 코드가 포함된 배치 작업 골격(Skeleton)을 고안하고 해당 골격 내의 지정된 영역에 작업별 정보를 입력해야 합니다. 골격은 각 작업 스크립트의 내용과 구조를 표준화하여 개발 및 유지 관리 요구 사항을 용이하게 하는 역할도 합니다. 예를 들어 실행되는 모든 스크립트의 코드에 성공하거나 실패한 배치 작업 실행 알림과 트랜잭션 데이터 보관 및 삭제 등의 모든 표준화된 작업 유형을 포함해야 합니다.

예약된 배치 실행은 미리 정의된 배치 기간(Window) 동안, 대개 시스템의 사용자 작업이 최소일 때 예약 도구로 시작됩니다. 예약 도구 프로그래밍이 완료된 후에는 도구로 복구할 수 없는 오류가 발생한 경우를 제외하고 배치 실행 중에 용량 관리자 상호 작용이 필요하지 않아야 합니다.

예약 도구는 모든 배치 실행을 시작합니다. 실행이 예약한 대로 시작되지 않으면 실행이 중단되고 오류가 오류 로그에 기록됩니다. 일부 예약 도구에는 배치 실행을 다시 시작하는 기능이 있습니다. 초기화에 성공하면 첫 번째 배치 작업이 실행됩니다. 스케줄러는 배치 처리를 수행할 대상으로 지정된 응용 프로그램 서버 각각에서 작업 실행을 관리합니다. 작업 실행 중에 발생한 오류가 없으면 성공한 작업 완료가 배치 로그에 기록되고 다음 작업이 실행되며 이하 동일한 방식으로 진행됩니다.

배치 작업 실행 중에 오류가 발생하면 해당 작업 처리가 중지되고 오류가 오류 로그로 전송됩니다. 배치 작업의 실제 실행은 작업이 실행되지 않는 이유가 될 수 있는 많은 입력에 좌우됩니다. 예를 들어 다음 입력이 필요할 수 있습니다.

  • 실제 작업 데이터의 가용성

  • 대기 중인 작업이 종속된 작업의 완료

  • 작업을 실행할 리소스의 가용성

  • 작업 우선 순위 및 배치 기간

작업 처리 중에 CPU 또는 디스크 공간 용량이 배치 작업을 처리하는 응용 프로그램 서버의 임계값을 초과하는 등의 경우가 발생하면 경고가 생성될 수도 있습니다. 경고가 생성되더라도 배치 작업이 완료되지만 향후 작업 처리 장애로 이어질 수 있으므로 용량 관리자가 최대한 빨리 모든 경고를 해결해야 합니다. 오류로 인해 작업이 중지된 경우 일부 예약 도구는 문제를 자동으로 해결하고 처리 중지 시 실행되고 있었던 작업 단계 초기부터 작업을 처리하기 시작합니다. 복구는 중단된 작업을 처음부터 다시 시작하지 않아도 되므로 매우 긴 배치 작업을 처리할 때 유용합니다. 복구가 불가능하면 작업을 다시 시작해야 합니다.

예약 도구로 실패한 작업을 다시 시작하거나 복구할 수 없는 경우 또는 특정 인스턴스에서 다시 시작하거나 복구할 수 없는 경우에는 복구 관리자가 다시 시작하거나 복구하는 절차를 수동으로 시작해야 합니다.

작업 예약 활동

용량 관리자 상호 작용이 최소한도로 유지되도록 배치 아키텍처를 구성하는 것이 가장 좋습니다. 그러나 다음을 포함하여 용량 관리자가 일상적으로 수행해야 하는 작업이 여전히 많이 있습니다.

  • 모니터링

  • 분석

  • 조정

  • 구현

  • 이벤트 관리

  • 필요 시 요청 처리

  • 예약 변경

  • 시스템 백업

  • 보관

  • 감사

  • 용량 관리자 로그 입력

  • 보고

이러한 활동은 각각 작업 예약 프로세스의 필수 부분입니다. 모니터링, 분석, 조정 및 구현 활동은 반복 프로세스를 형성합니다. 프로세스에 대한 입력에는 리소스 활용률, 배치 아키텍처 모니터링 시 비교되는 OLA 임계값 등이 있습니다. 이들은 아키텍처의 성능과 활용률을 최적화하는 것을 목표로 하는 지속적인 활동입니다. 나머지 활동은 이벤트, 요청 또는 요구 사항에 대한 대처로 수행됩니다.

문서화 및 교육/훈련

모든 정책과 절차는 용량 관리자가 일상 운영 지침으로 참조할 수 있도록 명확하게 문서화해야 합니다. 문서화에 포함해야 하는 정보는 다음과 같습니다.

  • 배치 실행 시작 및 중지 절차

  • 작업 우선 순위 변경 절차

  • 경고 및 오류 처리 절차

  • 일반 오류 처리 절차

  • 오류 원인 분석 절차

  • 오류 에스컬레이션 절차

  • RFC 제출 절차

  • 용량 관리자의 로그에 작업을 문서화하는 절차

  • 모니터링 대상 및 시기에 대한 절차

  • 필요 시 요청 처리 절차(필요 시 요청 검토, 테스트 및 실행 포함)

적절한 교육/훈련 없이는 용량 관리자가 본 문서에서 설명한 작업을 수행할 수 없습니다. 적절한 교육/훈련을 실시해야 용량 관리자가 시기 적절하게 대처하여 처리 오류를 수정할 수 있습니다. 사용 가능한 경우 용량 관리자는 조직에서 활용하는 예약 도구에 대한 공급업체 교육/훈련에 참석해야 합니다.

추가 정보

자세한 내용을 보려면 Microsoft Operations Framework 웹 사이트를 방문하십시오.

Microsoft IT 부서에서 MOF(Microsoft Operations Framework)를 사용하는 방법과 최적의 IT 서비스 관리 방법을 보려면 https://www.microsoft.com/technet/itshowcase/content/mofmmppt.mspx를 방문하십시오.

체크포인트: 운영, 최적화 및 변경 프로세스

요구 사항

 

IT 운영 전반에 걸쳐 서비스 수준 관리를 구현했습니다.

 

최적의 릴리스 관리 방법을 구현했습니다.

 

네트워크 및 시스템 관리 프로세스를 최적화했습니다.

 

최적의 작업 예약 방법을 구현했습니다.

위에 나열된 단계를 완료했으면 해당 조직에서 핵심 인프라 최적화 모델의 운영, 최적화 및 변경 프로세스에 대한 합리화 수준의 최소 요구 사항을 충족한 것입니다. Microsoft Operations Framework에 있는 운영 관리에 대한 추가 최적의 방법 리소스 지침을 따르도록 권장합니다.