KR20110082147A - 일괄 작업을 관리하기 위한 컴퓨터 시스템, 그 방법 및 컴퓨터 프로그램 - Google Patents

Abstract

본 발명은, 일괄 작업(batch job)을 관리하기 위한 컴퓨터 시스템을 제공한다. 상기 컴퓨터 시스템은, 적어도 하나의 작업 서식 파일(job template)을 저장하는 기억부와, 구성 요소의 적어도 하나의 소정의 속성 및 상기 구성 요소와 다른 구성 요소와의 관계를 포함하는 한 세트의 데이터 내의 적어도 하나의 속성 또는 관계를 사용해서, 상기 적어도 하나의 작업 서식 파일에 정의된 조건에 따른 잡 넷(job net) 정의의 작성 또는 갱신, 잡 넷(job net)의 작성 또는 갱신, 또는 잡의 충돌(conflict)의 발견을 실행하는 실행부 - 상기 한 세트의 데이터는 저장소(repository)에 보유되고 있으며, 그리고 구성 요소에 대한 정보를 검출하는 디스커버리에 의해 갱신될 수 있음 - 를 제공한다.

Description

일괄 작업을 관리하기 위한 컴퓨터 시스템, 그 방법 및 컴퓨터 프로그램{COMPUTER SYSTEM, METHOD, AND COMPUTER PROGRAM FOR MANAGING BATCH JOB}

본 발명은, 일괄 작업(batch job)을 관리하기 위한 컴퓨터 시스템 및 그 방법, 그리고 컴퓨터 프로그램에 관한 것이다.

복잡한 시스템, 예를 들면 기업 시스템에서, 수많은 일괄 작업이 처리된다. 일괄 작업을 처리하는데 있어서, 일괄 작업의 관리가 필요하다. 일괄 작업의 관리는, 일괄 작업을 정확하게 설계하고 작성하는 것, 및 일괄 작업을 유지관리(maintenance)하는 것이 포함된다. 일괄 작업을 정확하게 설계하는 것은, 예를 들면, 작업(job) 사이의 전후 관계를 정확하게 설계하는 것, 및 작업 사이에서 리소스의 경합이 발생하지 않도록, 작업을 정확하게 스케쥴하는 것을 포함한다. 일괄 작업을 유지관리하는 것은, 예를 들면, 작업에 관련되는 시스템의 구성 변경이 발생했을 때에, 상기 변경에 대응하도록 일괄 작업의 설정을 변경하는 것이다. 작업에 관련되는 시스템의 구성 변경이란, 작업의 설계에도 영향을 주는 구성 변경이다.

작업(job) 관리 어플리케이션은, 설계된 대로 작업을 실행하는 기능, 및, 에러가 발생했을 경우에, 후속 작업을 지연(suspend)시키고, 관리자에 통지하는 기능을 포함한다. 인터내셔널 비즈니스 머신즈 코포레이션(상표, 이하 IBM)은, 작업 관리 어플리케이션으로서, Tivoli(상표) Workload Scheduler를 판매하고 있다. Tivoli(상표) Workload Scheduler는, 자동화된 작업 스케쥴링을 집중 관리할 수 있기 때문에, 시스템마다 작업 관리가 필요 없으므로, 관리자 부담 및 관리 코스트의 삭감을 도모할 수 있다.

그러나, ITIL(Information Technology Infrastructure Library)(영국 정부 상표)란, IT 서비스 관리(management)를 실현하기 위한 가장 좋은 사례(best practice)를 모아 놓은 것이다. ITIL의 중심은, 서비스 지원(support) 및 서비스 전달(delivery)이다. 서비스 지원의 하나로서 구성 관리가 있다. 구성 관리란, IT 서비스 관리의 관리 대상인 구성 요소(configuration item, 구성 아이템이라고도 한다, 이하 'CI'로 약칭되기도 함)를 인식하고, 구성 요소에 대한 정보를 유지 및 갱신하고, 확인하고, 또한 감사(audit)를 수행하는 프로세스이다. 구성 요소는, 구성 관리의 대상이 되는 자원(리소스)이다. 구성 요소는, 하드웨어 및 소프트웨어를 포함하는 시스템 자원뿐만이 아니라, IT 서비스의 제공에 필요한 설비, IT 서비스의 운영에 관한 규정서(description), 작업 순서 및 구성도 등의 문서(document)류, 하드웨어 또는 소프트웨어의 보수 작업 등의 서비스, 프로세스, 또 인적 자원 등도 포함한다. ITIL의 프레임 워크(framework)에서는, 구성 요소를 관리하기 위해서, 구성 관리 데이터베이스(Configuration Management Database, 이하 'CMDB'로 약칭되기도 함)라고 하는 데이터베이스를 이용해서 일원적(一元的)으로 관리하는 것을 권하고 있다. CMDB는, 구성 요소의 적어도 하나의 소정의 속성 및 다른 구성 요소와의 관계를 기록하는 데이터베이스이다. CMDB의 실장을 통해 갖추게 되는 가장 중요한 능력은, 구성 요소에 대한 정보를 자동적으로 발견하는 능력(디스커버리(Discovery), '자동 검출'이라고도 함) 및 자동적으로 갱신하는 능력('트래킹(tracking)'이라고도 함)이다. CMDB에서는, 구성 요소에 대한 정보를 CMDB에 정확하게 반영시키는 것이 중요하다.

IBM은, CMDB의 구축을 지원하고 CMDB를 기반으로 운용 프로세스를 제어하는 소프트로서, Tivoli Change and Configuration Management Database(이하 Tivoli CCMDB)를 제공하고 있다. Tivoli CCMDB에서 디스커버리 및 트래킹의 상세한 내용은, IBM Redbooks Deployment Guide Series: IBM Tivoli Change and Configuration Management Database Configuration Discovery and Tracking v1.1, 제 41~64페이지, 2006년 11월(하기 비특허문헌 1)을 참고하기 바란다. Tivoli CCMDB에서는, 운용 관리 소프트가 디스커버리 및 트래킹을 실행하도록 실장되어 있다.

Tivoli(상표) CCMDB에서는, 분산 네트워크 환경상의 구성 요소인 서버, 클라이언트, 운영체제(OS), 미들웨어(Web/AP/DBMS/LDAP등), 패키지 소프트, 관리 툴, 네트워크 기기 및 스토리지 기기 등 300종류를 식별하고, 또한 각 구성 요소에 대한 정보, 예를 들면 컴퓨터 구성에 대한 정보, 각 컴퓨터 상에서 동작하는 어플리케이션에 대한 정보, 각 컴퓨터 상에서 접속되는 네트워크 접속 스토리지(NAS) 등의 구성 정보, 네트워크에 직접 접속되는 스토리지 에어리어 네트워크(SAN) 등의 구성 정보를 자동적으로 발견하고 및 갱신할 수 있다. 각 구성 요소에 대한 정보의 수집 방법은 관리 대상에 따라 다르지만, 기본적으로는 CMDB를 관리하는 컴퓨터 시스템이 SSH(Secure SHell) 등을 이용하여 관리용의 원격 인터페이스(remote interface)에 정기적으로 액세스하고, OS 상의 설정 파일 또는 구성 정보를 읽거나, 또는 CMDB를 관리하는 컴퓨터 시스템이 설정 확인 커맨드를 실행하거나 한다. 그 때문에, 관리 대상인 구성 요소에 에이전트 프로그램을 도입할 필요는 없다. 상기의 양식에서 발견되고 갱신된 정보는, IBM이 제창하는 구성 관리 데이터베이스용의 데이터 모델 Common Data Model(이하 CDM)에 근거하여, 2006년의 시점에서, 31종류의 섹션(Computer System, Database, Application, Process 등의 카테고리), 636종류의 클래스(데이터 모델의 기본 단위, 하나 또는 복수의 섹션에 속함), 2609종류의 속성(데이터의 속성 정보, 하나의 클래스에 속함), 7종류의 인터페이스(사용 빈도가 높은 속성의 그룹, 복수의 섹션에 속함), 57종류의 관계(relationship), 및 49종류의 데이터 타입(데이터의 종별)으로 정리된다. CDM의 상세 내용은, IBM REDPAPER(DRAFT version) IBM Tivoli Common Data Model: Guide to best Practices(IBM Form Number REDP-4389-00),제 2~7페이지, 2007년 11월(하기 비특허문헌2)을 참조하기 바란다. 각 구성 요소 및 상기 구성 요소와 다른 구성요소의 관계에 대한 정보는, GUI의 표시 툴, 예를 들면 TADDM 콘솔에 보내진다. 그리고, 각 구성 요소 및 상기 구성 요소와 다른 구성 요소와의 관계는, 개개의 블록 및 상기 블록 간의 링크를 이용하여 시각적으로 표시 장치 상에 표시된다.

비특허문헌1: IBM Redbooks Deployment Guide Series: IBM Tivoli Change and Configuration Management Database Configuration Discovery and Tracking v1.1, 제 41~64페이지, 2006년 11월 비특허문헌2: IBM RED PAPER(DRAFT version) IBM Tivoli Common Data Model: Guide to Best Practices(IBM Form Number REDP-4389-00), 제 2~7페이지, 2007년 11월

복잡한 시스템에서는, 일괄 작업(batch job)의 관리를 수행함에 있어서, 이하와 같은 문제점들이 있다.

복잡한 시스템 구성 등, 작업 설계자가 시스템을 다 파악하지 못하는 경우가 있기 때문에, 작업 간의 전후 관계를 정확하게 설계하는 것은 대단히 어렵다.

일괄 작업에는 업무 작업(operation job)과 인프라 작업(infrastructure job)이 있으며, 완전히 다른 팀의 사람이 각각을 설계하고 있기 때문에, 팀 간에 서로 조율이 필요하고, 작업 간에 리소스의 경합을 피하는 것은 대단히 어렵다.

시스템의 구성 변경이 발생했을 때에 작업 설계자가 항상 있지 않고, 어디를 변경하면 되는지 모르는 경우가 있기 때문에, 시스템의 구성 변경에 대응하여 작업을 변경하는 것이 곤란하다.

본 발명은, 일괄 작업을 관리하기 위한 컴퓨터 시스템을 제공한다. 상기 컴퓨터 시스템은,

적어도 하나의 작업 템플릿을 저장하는 기억부와,

구성 요소의 적어도 하나의 소정의 속성, 및

상기 구성 요소와 다른 구성 요소와의 관계를 포함하는 한 세트의 데이터 내의 적어도 하나의 속성 또는 관계를 사용하여, 상기 적어도 하나의 작업 템플릿에 정의된 조건에 따른 작업 넷 정의(job net definition)의 작성 또는 갱신, 작업 넷의 작성 또는 갱신, 또는 작업의 충돌(conflict)의 발견을 실행하는 실행부 - 여기서, 상기 한 세트의 데이터는 저장소(repository)에 보존되어 있고 구성 요소에 대한 정보를 검출하는 디스커버리(discovery)에 의해 갱신될 수 있음 - 를 포함한다.

본 발명의 하나의 실시 형태에서, 상기 실행부는 상기 한 세트의 데이터 내의 적어도 하나의 속성 또는 관계를 사용하여, 상기 적어도 하나의 작업 템플릿에서 작업 넷 정의를 작성하는 제 1의 작성부(creating unit)를 포함한다. 본 발명의 하나의 실시 형태에서, 상기 한 세트의 데이터는 상기 디스커버리에 의해 갱신된 한 세트의 데이터이다.

본 발명의 하나의 실시 형태에서, 상기 작업 템플릿은 작업의 실행 타입, 작업의 실행 커맨드, 상기 작업 템플릿이 적용되는 구성 요소, 및 작업의 실행의 전제 조건을 포함한다.

본 발명의 하나의 실시 형태에서는, 상기 작업 넷 정의는 작업의 내용, 작업의 실행 순, 및 작업의 실행 스케쥴을 포함한다.

본 발명의 하나의 실시 형태에서, 상기 전제 조건은 구성 요소를 검색하기 위한 조건, 및 상기 구성 요소에 대한 작업의 실행 타입을 포함한다. 상기 디스커버리는 상기 구성 요소를 검색하기 위한 조건에 따라 구성 요소를 특정한다.

본 발명의 하나의 실시 형태에서, 상기 한 세트의 데이터 내의 적어도 하나의 속성 또는 관계를 사용하여, 상기 전제 조건에 기재된 조건에 일치하는 구성 요소를 특정한다.

본 발명의 하나의 실시 형태에서, 상기 제 1의 작성부는 상기 특정된 구성 요소에 다른 작업 템플릿을 관련짓는다.

본 발명의 하나의 실시 형태에서, 상기 제 1의 작성부는 상기 작업 템플릿에, 유저에 의해 정의된 작업 정의를 적용하는 것에 의한 작업 넷 정의를 작성한다.

본 발명의 하나의 실시 형태에서, 상기 작업 정의는 작업의 정의명(job definition name), 작업의 내용, 작업의 실행처(job executor), 작업의 실행 유저, 작업의 개시 스케쥴, 선행 작업, 작업의 실행 예측 시간, 및 작업 템플릿 명을 포함한다.

본 발명의 하나의 실시 형태에서, 상기 작업 템플릿은 구성 요소에 대한 한 세트의 데이터를 취득하기 위한 인수(argument)를 포함한다.

본 발명의 하나의 실시 형태에서는, 상기 한 세트의 데이터 내의 적어도 하나의 속성 또는 관계를 사용하여, 작업 넷 정의로부터 작업 넷을 작성하는 제 2의 작성부를 포함한다.

본 발명의 하나의 실시 형태에서, 상기 작업 넷 정의는 구성 요소에 대한 한 세트의 데이터를 취득하기 위한 인수를 포함한다.

본 발명의 하나의 실시 형태에서, 상기 작업 넷 정의는 로그 유지관리(log maintenance) 작업 넷 정의이며, 상기 인수는 로그 패스(logpath)이고, 상기 로그 패스의 데이터는 상기 한 세트의 데이터에 의해 갱신된다.

본 발명의 하나의 실시 형태에서, 상기 제 2의 작성부는 작업 넷은 상기 작업 넷을 실행하는 시스템에 투입되는 일시, 및 작업 넷 정의에서 정의된 구성 요소에 대한 인수에 대응하는 한 세트의 데이터의 속성 및 관계에 적어도 하나를 상기 작업 넷에 적용한다.

본 발명의 하나의 실시 형태에서, 상기 작업의 충돌은, 제 1의 작업 템플릿의 작업의 실행 커맨드와 관련된 제 1의 구성 요소 및 상기 제 1의 구성 요소와 관계를 가진 제 2의 구성 요소의 적어도 하나를 상기 작업이 이용하는 실행 시간대와, 제 2의 작업 템플릿의 작업의 실행 커맨드와 관련된 제 3의 구성 요소 및 상기 제 3의 구성 요소와 관계를 가진 제 4의 구성 요소의 적어도 하나를 상기 작업이 이용하는 실행 시간대가 겹친다는 것을 포함한다.

본 발명의 하나의 실시 형태에서, 상기 제 2의 구성 요소가 상기 제 1의 구성 요소의 한 세트의 데이터 내의 적어도 하나의 속성 또는 관계를 사용하여 검출되고, 상기 제 4의 구성 요소가 상기 제 3의 구성 요소의 한 세트의 데이터 내의 적어도 하나의 속성 또는 관계를 사용하여 검출된다.

본 발명의 하나의 실시 형태에서, 상기 제 1의 구성 요소의 상기 한 세트의 데이터는 상기 디스커버리에 의해 갱신된 한 세트의 데이터이고, 또한 상기 제 3의 구성 요소의 상기 한 세트의 데이터는 상기 디스커버리에 의해 갱신된 한 세트의 데이터이다.

본 발명의 하나의 실시 형태에서, 상기 작업의 충돌은, 상기 작업 템플릿의 작업의 실행 커맨드와 관련된 제 1의 구성 요소 및 상기 제 1의 구성 요소와 관계를 가진 제 2의 구성 요소의 적어도 하나를 상기 작업이 이용하는 실행 시간대가, 상기 작업을 실행할 수 없는 시간대라는 것을 포함한다.

본 발명의 하나의 실시 형태에서, 상기 제 1의 구성 요소의 상기 한 세트의 데이터 및 상기 제 2의 구성 요소의 상기 한 세트의 데이터는 상기 디스커버리에 의해 갱신된 한 세트의 데이터이다.

본 발명의 하나의 실시 형태에서, 상기 디스커버리는, 상기 작업 넷 정의를 작성하기 직전, 상기 작업 넷을 작성하기 직전, 또는 상기 작업 넷을 실행하는 시스템에 상기 작업 넷을 투입하기 직전에 수행한다.

본 발명의 하나의 실시 형태에서, 상기 작업 넷은 상기 디스커버리를 수행하는 작업을 포함한다.

본 발명은 일괄 작업을 관리하기 위한 방법을 더 제공한다. 상기 방법은, 컴퓨터 시스템에 하기 단계를 실행시키는 단계를 포함한다. 상기 단계는,

적어도 하나의 작업 템플릿에 정의된 구성 요소를 특정하는 단계,

상기 특정된 구성 요소의 적어도 하나의 소정의 속성, 및 상기 구성 요소와 다른 구성 요소와의 관계를 포함하는 한 세트의 데이터 내의 적어도 하나의 속성 또는 관계를 사용하여, 상기 적어도 하나의 작업 템플릿에 정의된 조건에 따른 작업 넷 정의의 작성 또는 갱신, 작업 넷의 작성 또는 갱신, 또는 작업의 충돌의 발견을 실행하는 단계 - 여기서, 상기 한 세트의 데이터는 저장소에 보존되어 있고 및 구성 요소에 대한 정보를 검출하는 디스커버리에 의해 갱신될 수 있음 - 를 포함한다.

본 발명의 하나의 실시 형태에서, 상기 실행하는 단계는 상기 한 세트의 데이터 내의 적어도 하나의 속성 또는 관계를 사용하여, 작업 템플릿에서 작업 넷 정의를 작성하는 단계를 더 포함한다.

본 발명의 하나의 실시 형태에서, 상기 작업 템플릿에서 상기 작업 넷 정의를 작성하는 단계는 상기 한 세트의 데이터 내의 적어도 하나의 속성 또는 관계를 사용하여, 작업 템플릿에 정의되는 작업의 실행의 전제 조건에 기재된 조건에 일치하는 구성 요소를 특정하는 단계를 더 포함한다.

본 발명의 하나의 실시 형태에서, 상기 작업 템플릿에서 상기 작업 넷 정의을 작성하는 단계는 상기 특정된 구성 요소에 다른 작업 템플릿을 관련짓는 단계를 더 포함한다.

본 발명의 하나의 실시 형태에서, 상기 작업 템플릿에서 상기 작업 넷 정의를 작성하는 단계는, 상기 작업 템플릿에, 유저에 의해 정의된 작업 정의를 적용하는 것으로 작업 넷 정의를 작성하는 단계를 포함한다.

본 발명의 하나의 실시 형태에서, 상기 실행하는 단계는, 상기 한 세트의 데이터 내의 적어도 하나의 속성 또는 관계를 사용하여, 작업 넷 정의로부터 작업 넷을 작성하는 단계를 더 포함한다.

본 발명의 하나의 실시 형태에서, 상기 작업 넷 정의로부터 상기 작업 넷을 작성하는 단계는 작업 넷 정의의 하나인 로그 유지관리(log maintenance) 작업 넷 정의에 정의된 로그 패스(logpath)의 데이터를 상기 한 세트의 데이터에 의해 갱신하는 단계를 더 포함한다.

본 발명의 하나의 실시 형태에서, 상기 작업 넷 정의로부터 상기 작업 넷을 작성하는 단계는, 작업 넷이 상기 작업 넷을 실행하는 시스템에 투입되는 일시, 및 작업 넷 정의에서 정의된 구성 요소에 대한 인수에 대응하는 한 세트의 데이터 내의 적어도 하나의 속성 또는 관계를 상기 작업 넷에 적용하는 단계를 더 포함한다.

본 발명의 하나의 실시 형태에서, 상기 작업의 충돌의 발견을 실행하는 것은, 상기 작업의 충돌이, 제 1의 작업 템플릿의 작업의 실행 커맨드와 관련된 제 1의 구성 요소 및 상기 제 1의 구성 요소와 관계를 가진 제 2의 구성 요소의 적어도 하나를 상기 작업이 이용하는 실행 시간대와, 제 2의 작업 템플릿의 작업의 실행 커맨드와 관련된 제 3의 구성 요소 및 상기 제 3의 구성 요소와 관계를 가진 제 4의 구성 요소의 적어도 하나를 상기 작업이 이용하는 실행 시간대가 겹친다는 것을 발견하는 단계를 포함한다.

본 발명의 하나의 실시 형태에서, 상기 발견하는 단계는, 상기 제 2의 구성 요소를 상기 제 1의 구성 요소의 한 세트의 데이터 내의 적어도 하나의 속성 또는 관계를 사용하여 검출하는 단계와, 상기 제 4의 구성 요소를 상기 제 3의 구성 요소의 한 세트의 데이터 내의 적어도 하나의 속성 또는 관계를 사용하여 검출하는 단계를 더 포함한다.

본 발명의 하나의 실시 형태에서, 상기 작업의 충돌의 발견을 실행하는 것은, 상기 작업 템플릿의 작업의 실행 커맨드와 관련된 제 1의 구성 요소 및 상기 제 1의 구성 요소와 관계를 가진 제 2의 구성 요소의 적어도 하나를 상기 작업이 이용하는 실행 시간대가, 상기 작업을 실행할 수 없는 시간대라는 것을 발견하는 단계를 포함한다. 본 발명의 하나의 실시 형태에서, 상기 제 1의 구성 요소의 상기 한 세트의 데이터 및 상기 제 3의 구성 요소의 상기 한 세트의 데이터는 상기 디스커버리에 의해 갱신된 한 세트의 데이터이다.

본 발명의 하나의 실시 형태에서, 상기 방법은, 컴퓨터 시스템에 하기 단계를 실행시키는 단계를 포함한다. 상기 단계는, 상기 작업 넷 정의를 작성하기 직전, 상기 작업 넷을 작성하기 직전, 또는 상기 작업 넷을 실행하는 시스템에 투입되기 직전에 디스커버리를 수행하는 단계를 포함한다.

본 발명은 또, 일괄 작업을 관리하기 위한 방법을 제공한다. 상기 방법은, 컴퓨터 시스템에 하기 단계를 실행시키는 단계를 포함한다. 상기 단계는,

구성 요소의 적어도 하나의 소정의 속성, 및 상기 구성 요소와 다른 구성 요소와의 관계를 포함하는 한 세트의 데이터 저장소에 저장하는 단계와 - 여기서, 상기 한 세트의 데이터는, 구성 요소에 대한 정보를 검출하는 디스커버리에 의해 갱신될 수 있음 -,

작업 템플릿에 정의된 구성 요소를 특정하는 단계와,

상기 특정된 구성 요소에 대한 상기 한 세트의 데이터 내의 적어도 하나의 속성 또는 관계를 사용하여, 상기 작업 템플릿에 정의된 조건에 일치하는 다른 구성 요소를 발견하는 단계와,

상기 발견된 다른 구성 요소에 다른 작업 템플릿을 관련짓는 단계와,

상기 작업 템플릿 및 상기 다른 작업 템플릿을 사용하서, 작업 넷 정의를 작성하는 단계를 포함한다.

본 발명은 또, 일괄 작업을 관리하기 위한 컴퓨터 프로그램을 제공한다. 상기 컴퓨터 프로그램은, 컴퓨터 시스템에, 상기 어느 하나에 기재된 방법의 각 단계를 실행시킨다.

본 발명의 실시 형태에 의하면, 일괄 작업의 관리에 CMDB를 이용하는 것으로, 작업 넷을 자동 작성하는 것, 및 작업의 충돌을 발견하는 것이 가능해진다. 또, 본 발명의 실시 형태에 의하면, 일괄 작업의 관리에 CMDB를 이용하는 것으로, 작업의 재이용성을 높이는 것이 가능해진다.

도 1은 종래 기술로서, CI를 관리하기 위한 CMDB를 포함하는 컴퓨터 시스템의 예를 나타내는 도면이다.
도 2는 종래 기술로서, 구성 관리를 위한 툴의 개요를 나타내는 도면이다.
도 3은 종래 기술로서, CI, CI 인터페이스, 및 관계(usedBy) 인스턴스의 작성을 나타내는 도면이다.
도 4는 종래 기술로서, 데이터 모델, 디스커버리, 인스턴스, CI 인스턴스, 및 관계 모델을 나타내는 도면이다.
도 5는 종래 기술로서, CMDB에서 구성 정보 관리의 도면 예를 나타내는 도면이다.
도 6은 본 발명의 실시 형태인, 작업 넷의 예를 나타내는 도면이다.
도 7은 본 발명의 실시 형태인, 작업 템플릿의 예를 나타내는 도면이다.
도 8은 본 발명의 실시 형태인, 작업 정의의 예를 나타내는 도면이다.
도 9는 본 발명의 실시 형태인, 작업 넷 정의의 예를 나타내는 도면이다.
도 10은 종래 기술로서, 작업 관리 서버의 예를 나타내는 도면이다.
도 11은 본 발명의 실시 형태인, 시스템 전체의 구성도의 예를 나타내는 도면이다.
도 12는 본 발명의 실시 형태인, 작업 관리 서버의 구성도의 예를 나타내는 도면이다.
도 13은 본 발명의 실시 형태인, 작업 넷 정의 및 작업 넷을 작성하는 흐름도이다.
도 14는 본 발명의 실시 형태인, 작업 넷 정의 또는 작업 넷의 갱신을 하는 흐름도이다.
도 15는 본 발명의 실시 형태인, 본 발명의 실시 형태인, 작업의 검증을 하는 흐름도이다.
도 16은 본 발명의 실시 형태인, 작업의 충돌을 발견하는 흐름도이다.
도 17은 본 발명의 실시 형태인, 작업 넷 정의 및 작업 넷의 작성을 나타내는 도면이다.
도 18은 도 17의 실시 형태인, 작업 넷 정의 및 작업 넷을 작성하는 흐름도이다.
도 19는 본 발명의 실시 형태인, 작업 간의 충돌의 발견을 나타내는 도면이다.
도 20은 도 19의 실시 형태인, 작업 간의 충돌을 발견하는 흐름도이다.
도 21은 본 발명의 실시 형태인, 작업의 충돌을 발견하는 실시 형태를 나타내는 도면이다.
도 22는 도 21의 실시 형태인, 작업의 충돌을 발견하는 흐름도이다.
도 23은 본 발명의 실시 형태인, 작업 넷의 갱신을 나타내는 도면이다.
도 24는 도 23의 실시 형태인, 작업 넷을 갱신하는 흐름도이다.
도 25는 본 발명의 실시 형태에서, 컴퓨터 시스템의 예를 나타내는 도면이다.

작업이란, 각 컴퓨터 상에서 실행되는 개개의 정형적인 처리(routine processing)를 말한다.

작업의 관리에서는 작업을 설계하는 단계와, 설계한 작업을 실행하는 단계가 있다.

작업 템플릿이란, 작업 설계의 근원이 되는 템플릿이다. 따라서, 작업 템플릿은, 작업을 설계하는 단계 전에 작업의 설계자에 의해 준비된다. 작업 템플릿은, 예를 들면, 작업의 종류마다 준비된다. 예를 들어, 복수의 오프라인 재구성 작업(Offline Reorg Job)이 있는 경우라도, 그 복수의 오프라인 재구성 작업은 하나의 오프라인 재구성 작업 템플릿을 참조한다. 작업 템플릿은, 예를 들어, 작업 템플릿 식별자(ID), 작업 템플릿을 설명하기 위한 기술(description), 액션 타입, 작업의 실행 커맨드(Action), 작업 템플릿이 적용되는 CI 타입, 전제 조건, 및 영향 플래그를 포함하지만 이것으로 한정되지는 않는다. 작업 템플릿 ID는, 컴퓨터가 작업 템플릿을 식별(identify)하기 위해 부여된 고유의 식별자이다. 작업 템플릿을 설명하기 위한 기술(description)은, 유저가 작업 템플릿을 작성 또는 갱신할 때에 부여한 기술(description)이다. 액션 타입은, 재편성(Reorg), 시작(Start), 중단(Stop) 등의 작업의 실행 커맨드의 종류를 나타낸다. 종류는, 작업의 설계자에 의해 미리 정해진다. 작업의 실행 커맨드는, 예를 들면, 스크립트를 사용해서 기재된다. 작업의 실행 커맨드는, 예를 들면 DB2의 경우는 xxxx, Oracle의 경우 yyyy(DB2 및 Oracle은 모두 등록 상표임)와 같이, 대상이 되는 CI 타입으로 경우를 나누어서 정의된다(하기, 도 17의 작업 템플릿(601)을 참조). 작업 템플릿이 적용되는 CI 타입은, 상기 작업 템플릿의 실행 커맨드를 적용하는 구성 요소의 종류를 기술한다. CI 타입은, 예를 들면, 데이터 베이스(DB) 운영체제(OS), 어플리케이션 서버(AppServ), 웹 서버(WebServ), WebSphere Application Server(WAS)를 포함하지만 이것으로 한정되지는 않는다. 전제 조건은, 작업이 실행될 수 있는 전제 조건이다. 전제 조건은, 구성 요소의 검색 조건, 다른 작업 템플릿을 검색하기 위한 액션 타일을 포함하지만 이것으로 한정되지 않는다. 구성 요소의 검색 조건은, 작업 템플릿이 적용되는 CI타입의 검색 범위를 좁히기 위한 조건을 나타낸다. 다른 작업 템플릿을 검색하기 위한 액션 타입은, 여기에 지정된 액션 타입을 가진 다른 작업 템플릿을 검색하기 위해 사용된다. 구성 요소의 검색 조건에 따라, CMDB 내의 CI 인스턴스의 속성 및 관계에 적어도 하나를 사용하여, 목적으로 하는 구성 요소가 검색된다. 속성은, 예를 들면, CI 타입(예를 들어, DB, OS, AppServ, WebServ, WAS)이다. 관계는, 예를 들면, 어플리케이션 관계(예를 들어, assigns, canConnect, canUse, connectAt, connects, controls, deployedOn, Located, Managed, Owned, provides, runAt, uses, usedBy 등)이다. 영향 플래그(impact flag)는, 소정의 조건이 충족될 지의 여부를 표시한다.

작업 정의란, 작업 넷 정의를 작성하기 위해, 유저에 의해 정의된 작업 템플릿에 부여하는 파라미터의 집합이다. 작업 정의는, 예를 들면, 작업 정의명, 작업 내용, 작업 실행처, 작업 실행 유저, 작업 개시 스케쥴, 선행 작업, 작업의 실행 예측 시각, 및 작업 템플릿을 포함하지만 이것으로 한정되지는 않는다.

작업 정의명은, 컴퓨터가 작업 정의를 식별하기 위해 부여한 고유의 이름이다. 작업 내용은, 작업 내용을 예를 들면 작업의 실행 커맨드 또는 배치 파일의 지정에 의해 기술된다. 작업의 실행 커맨드는, 예를 들면, 스크립트를 사용하여 기재된다. 작업의 실행 커맨드는, 예를 들면, 대상이 되는 CI 타입이 DB2의 경우, DB2의 실행 커맨드(상기 작업 템플릿의 xxxx의 실장 파라미터)가 정의되어 있으며, 대상이 되는 CI 타입이 Oracle의 경우, Oracle의 실장 커맨드(상기 작업 템플릿의 yyyy의 실장 파라미터)가 정의되어 있다. 작업 실행처는, 작업을 실행하는 컴퓨터 또는 시스템을 특정하기 위한 ID를 나타낸다. 작업 실행 유저는, 작업을 실행하는 유저를 나타낸다. 작업 개시 스케쥴은, 작업이 개시되는 스케쥴을 나타낸다. 스케쥴은, 예를 들면, 일 단위, 주 단위, 월 단위, 혹은 연 단위로, 또는 유저에 의해 임의의 단위로 지정될 수 있다. 선행 작업은, 작업 정의에 정의된 상기 작업에 선행하여 실행되는 작업을 나타낸다. 상기 작업은, 선행 작업이 종료하고 나서 실행된다. 작업 실행 예측 시각은, 상기 작업의 실행에 필요한 예측 시간을 나타낸다. 작업 템플릿은, 상기 작업 정의를 적용하는 작업 템플릿 ID를 나타낸다.

작업 넷 정의란, 작업 설계의 성과물로서 작성되는 정의이다. 작업 넷 정의는 상기 작업 템플릿에 상기 작업 정의를 적용하는 것으로 작성된다. 또한, 작업 넷 정의로부터 작업 넷이 작성된다. 작업 넷 정의는, 예를 들면 작업 넷 정의명, 작업 자체, 작업의 실행 순, 및 작업의 실행 스케쥴을 포함하지만 이것으로 한정되는 것은 아니다.

작업 넷 정의명은, 컴퓨터가, 작업 넷 정의를 식별하기 위해 부여된 고유의 이름이다. 작업 자체는, 작업 템플릿에 정의된 작업 내용에 더하여, 작업 실행처, 작업 실행 유저, 작업 실행 예측 시각, 작업 템플릿에 대한 정보를 포함한다. 작업 내용은, 예를 들면, 작업의 실행 커맨드 또는 배치 파일의 지정에 의해 기술된다. 작업의 실행 커맨드는, 예를 들면, 대상이 되는 CI 타입이 DB의 경우, 상기 작업 템플릿 내의 DB2의 실행 커맨드에 상기 작업 정의 내에 DB2의 실장 파라미터를 적용한 것이며, 대상이 되는 CI 타입이 Oracle의 경우, 상기 작업 템플릿 내의 Oracle의 실행 커맨드에 상기 작업 정의 내의 Oracle의 실장 파라미터를 적용한 것이다. 작업 실행처, 및 작업 실행 유저의 특정은, 예를 들면, CI의 인스턴스 명을 특정하는 것으로 수행된다. 작업 자체 또는, 작업끼리의 의존 관계, 작업 넷끼리의 의존 관계를 정의한다.

작업 넷은, 상기 일괄 작업을 실행하기 위해, 작업을 실행하는 시스템에 실제로 투입되는 데이터이다. 투입이란, 작업 넷이 실행되는 것이다. 작업 넷은, 작업 관리 서버가 상기 작업 넷 정의를 읽는 것으로 작성된다. 작업 넷은, 작업 넷 정의를 인스턴스(instance)화 한 것이다. 작업 넷은, 예를 들면 작업의 처리가, 몇 개의 독립한 작업의 그룹으로부터 발생하는 경우, 각 그룹을 작업 넷으로서 구성한다. 상기 서부의 처리는, 예를 들면, 매일의 대체 의뢰이다. 통상, 작업 넷 단위로, 작업의 가동 스케쥴이 설정된다.

본 발명의 실시 형태에서, 일괄 작업을 관리하는 것은, 작업 넷 정의 또는 작업 넷을 작성하는 것, 작업 넷 정의 또는 작업 넷을 갱신하는 것, 또는 작업의 충돌의 발견을 실행하는 것, 혹은 그것들의 조합을 포함한다.

본 발명의 실시 형태에서, 작업의 충돌의 발견은, 작업 간의 충돌을 발견하는 것, 또는 작업의 실행 대상인 구성 요소의 속성 또는 관계 데이터가 작업 템플릿의 전제 조건 혹은 영향 플래그에 반하는 것을 발견하는 것, 혹은 그것들의 조합을 포함한다.

CMDB에 대해서 하기에 설명한다.

이하 CMDB에 관한 기본적인 용어를 하기에 설명한다.

본 발명의 실시 형태에서, 저장소는 적어도 한 세트의 데이터를 저장한다. 상기 한 세트의 데이터는, 구성 요소의 적어도 하나의 소정의 속성 및 다른 구성 요소와의 관계를 나타내는 데이터이다. 상기 한 세트의 데이터는 예를 들면, 하드웨어 구성 요소 또는 소프트웨어 구성 요소를 포함하는 구성 요소의 적어도 하나의 소정의 속성 및 상기 구성 요소와 다른 구성 요소와의 관계를 나타낸 데이터를 포함한다. 상기 저장소는, 예를 들면, CMDB이다. 구성 요소, 및 상기 구성 요소와 다른 구성 요소와의 관계는, 예를 들면, 정적(static) 데이터의 인스턴스 또는 Java(선 마이크로 시스템즈의 상표)의 클래스(class)의 인스턴스(instance)로 실장 될 수 있다. 상기 저장소는, 상기 한 세트의 데이터를 보존하는 것이라면 특별히 한정되지는 않지만, 바람직하게는 실시 형태의 하나는 CMDB를 기록하는 CMDB 기록부이다.

*구성 요소(CI)

CI는 IT 서비스 관리(management)의 대상 범위에 속하는 구성 요소에 대응하는 데이터이며, IT 서비스 관리에서 관리 대상의 기본 단위이다. CI는 예를 들면, 하드 웨어 및 소프트 웨어를 포함하는 시스템 자원, IT 서비스의 제공에 필요한 설비, IT 서비스의 운영에 관한 규정서, 작업 순서서 및 구성도 등의 문서(document) 류, 하드웨어 또는 소프트웨어의 보수 작업 등의 서비스, 프로세스, 및 인적 자원 등을 포함한다. 이후에도 여러 가지 타입의 CI가 CMDB에서 관리되게 된다. 또, 각 CI는 데이터 모델의 인스턴스로서 CMDB 상에서 표현된다.

*구성 관리 데이터베이스(CMDB)

CMDB는, 정보 시스템의 모든 컴포넌트에 관한 정보의 통합된 보관 관리를 수행하는 데이터베이스이다. CMDB는, 각 CI의 적어도 하나의 소정의 속성 및 다른 CI와의 관계를 기록한다. CMDB는 조직이 컴포넌트 간의 관계를 이해하는 것을 지원하고, 그 구성을 관리할 수 있도록 한다. CMDB는 ITI 프레임워크의 구성 관리 프로세스의 핵심이다. CMDB는, 개념적으로는 데이터베이스이지만, 물리적으로는 데이터 베이스 시스템, 표 계산 소프트의 스프레드 시트의 형태를 취할 수 있다. CMDB를 이용하는 것으로, 관리자는 CI 간의 관계를 이해하는 것이 용이하다.

*구성 요소 인스턴스(CI 인스턴스)

CI 인스턴스는, CI에 대응하는 데이터이다. 각 CI 인스턴스는, 데이터 모델의 인스턴스로서 CMDB 상에서 표현된다. 인스턴스의 예는, 정적 데이터의 인스턴스 또는 Java(선 마이크로 시스템즈의 상표)의 클래스의 인스턴스이다. 실장된 Java의 클래스의 인스턴스는, 예를 들면 Java Data Objects(JDO)로 불려지는, Java의 클래스의 인스턴스를 영속화하여 하드 디스크에 보존하는 구조에 의해, CMDB 내에 저장된다. 따라서, 일단 컴퓨터 시스템의 전원을 꺼도, 작성된 Java의 클래스의 인스턴스는 소실되지 않고, 다음에 전원을 투입했을 때에, 기억 장치, 예를 들면 하드 디스크로부터 읽혀져, 메인 메모리 상에서 전개(expand)되어, Java의 프로그램에 의해 변경 혹은 삭제가능한 Java의 클래스의 인스턴트가 된다. 이하에서는, CI가 인스턴스로서 CMDB 내에 실장 되었다고 하고, 설명되는 경우도 있다.

*데이터 모델

데이터 모델은, CI를 정의하기 위한 스킴(scheme)이며, 관리되는 CI와 그것들 CI간의 관계의 일관된 정의를 제공하는 정보 모델이다. 구체적으로는, 데이터 모델은, CI의 소정의 속성 및 다른 CI(제조 장치, 프로세스 등)와의 관계를 정의한다. 데이터 모델의 예로서, IBM이 제창하는 구성 관리 데이터베이스용의 데이터 모델 CDM이 있다. CDM의 실장은 예를 들면, Unified Modeling Language(UML)에 근거하여 수행된다.

*속성(Attributes)

속성은, CI를 관리하는 경우에 있어서, 개개의 CI를 특정하고, CI를 설명한다. 속성으로서, 하기의 것을 떠올릴 수 있지만 이것들로 한정되지는 않는다. CI의 이름(CI의 일반 명칭, 예를 들면, 서버, 클라이언트, 방화벽(firewall)), 제품 번호(ID)(CI가 있는 특정의 실체를 개별로 식별하기 위한 번호이며, 제조 번호, 시리얼 번호 등), 카테고리(CI의 분류, 예를 들면 하드웨어, 소프트웨어, 도큐멘트), 타입(카테고리에서의 분류를 더욱 상술한 CI의 설명), 모델 번호(공급자가 명명한 CI의 모델 번호), 보증 기간(CI의 공급자에 의한 보증 기간), 버전 번호(CI의 버전 번호), 로케이션(CI가 존재하는 장소, 예를 들면 PC의 설치 장소, 소프트웨어 라이브러리, 매체의 보관 장소, 서비스를 제공하고 있는 사이트), 소유 책임자(CI의 관리 책임자의 이름), 책임 개시일(소유 책임자가, 상기 CI의 책임자로 된 날짜), 공급자(CI의 개발원 또는 제공원), 라이선스(라이선스 번호, 라이선스 수 등), 제공일(CI가 조직에 제공된 날짜), 수입일(CI가 조직에 수용된 날짜), 사용 개시일(CI가 사용 개시된 날짜), CI의 상태(현재 상태 , 예를 들면 가동 중, 테스트 중, 고장 중, 혹은 장래 상태, 예를 들면 예정된 CI의 상태), CI 인스턴스의 상태(CI 인스턴스의 유효 또는 무효). 이후에도 IT 서비스 관리에 필요한 속성은 계속되어 정의되어 간다.

*관계(Relation)

관계는 CI 간의 관계를 나타낸다. 관계는 CI와 같이 데이터 모델에서 정의될 수 있다. 관계의 예로서, 공통 데이터 모델(Common Data Model)에서는, as signs, can Connect, can Use, connect At, connects, controls, deployed On, Located, Managed, Owned, provides, run At, uses, used By를 떠올릴 수 있다. 이후에도 IT 서비스 관리에서 필요한 관계가 계속되어 정의된다.

이하 도면을 참조하여, 본 발명의 실시 형태를 설명한다. 본 실시 형태는, 본 발명의 바람직한 형태를 설명하기 위한 것이며, 본 발명의 범위를 여기에서 나타낸 것에 한정하는 의도는 없다는 것을 이해해 주길 바란다. 또, 이하의 도를 통해서, 특별히 다르게 기재되어 있지 않는 한, 동일한 부호는 동일한 대상을 나타낸다.

도 1은, 종래 기술인, CI를 관리하기 위한, CMDB를 포함한 컴퓨터 시스템(100)의 예를 나타낸다.

도 1은 CI의 예로서, 구성 요소 A 및 구성 요소 B를 기재한다. 구성 요소 A 및 B 각각은, 소프트웨어 구성 요소, 하드웨어 구성 요소 중 어느 것이어도 된다. 소프트웨어 구성 요소는, 예를 들면, DB2(상표), Websphere(상표), LINUX, Tomcat, Apache이지만 이것으로 한정되지는 않는다.

컴퓨터 시스템(100)은, 디스커버리부(101), CI 식별부(identifying unit)(102), CI 인스턴스 작성부(103), 속성 및 관계 갱신부(104) 및 CMDB(105)를 포함한다. 디스커버리부, CI 식별부, CI 인스턴스 작성부, 속성 및 관계 갱신부 및 CMDB는, 단독의 컴퓨터 상에 실장되어도 되고, 혹은 복수의 컴퓨터 상에 분산해서 실장되어도 된다. 컴퓨터 시스템(100)은 또, 디스커버리 테이블(106), 모델 테이블(107) 및 관계 테이블(108)을 포함한다. 이것들 테이블은, 단독의 컴퓨터 상에 실장되어도 되고, 혹은 복수의 컴퓨터 상에 분산해서 실장되어도 된다.

또한, 도 1은 TADDM 콘솔의 화면(109)의 예를 나타낸다. 상기 화면은, CI 및 CI 간의 관계를 나타낸다. 또한, 상기 화면에 표시된 CI 및 CI 간의 관계는 한 예이며, 컴퓨터 시스템(100)의 관리 대상인 CI 및 CI 간의 모든 관계를 표시한 것은 아니다.

컴퓨터 시스템(100)은, 그 자신의 관리 대상인 구성 요소를 관리한다. 컴퓨터 시스템(100)의 관리 대상은, 상기 컴퓨터 시스템(100)이 디스커버리 할 수 있는 대상의 구성 요소이다.

디스커버리부(101)는, CMDB의 관리 대상인 CI에 대한 정보의 검출을 실행한다(디스커버(discover) 라고도 함). 상기 CI의 일부는 TADDM 콘솔의 화면(109)에 표시되어 있다. 컴퓨터 시스템(100)은 복수의 디스커버리부(101)를 가지고 있어도 된다. 바람직하게는, 관리 대상은 네트워크를 통해 컴퓨터 시스템에 접속된다. 네트워크는 유선 접속인지 무선 접속인지를 따지지 않는다. 컴퓨터 시스템의 관리자는 검출의 대상을 임의로 설정할 수 있다. 검출의 범위는, 예를 들어, 도메인 명, IP 주소, MAC 주소, 기기의 식별자 혹은 데이터 베이스 명 또는 이것들의 조합에 의해 지정할 수 있다. 관리 대상인 CI가 예를 들면 하드웨어 또는 소프트웨어인 경우, 상기 하드웨어 또는 소프트웨어에 대한 정보가 각각 검출된다. 검출된 정보는, 새로운 CI에 대한 정보, 또는 기존의 CI에 갱신된 속성 혹은 관계의 값일 수 있다. 새로운 CI란, 디스커버리부(101)에 의해 검출되어, CMDB(105) 내에 등록되지 않은 CI이다. 기존의 CI란, 상기 CI의 인스턴스가 CMDB(105) 내에 이미 등록된 CI이다. 디스커버리부(101)는, CI에 대한 정보를, 디스커버리 테이블(106) 내에 저장된 디스커버리 인스턴스(예를 들면 A-Discovery)(도 4, 202)에 따라 검출한다. 어느 디스커버리 인스턴스를 사용할지는, 데이터 모델(도 4, 201) 내의 디스커버리 방법에 지정되어 있다. 디스커버리부(101)는, 검출한, CI에 대한 정보를 CI 식별부(102)로 보낸다.

CI 식별부(102)는, 상기 CI에 대한 정보를 디스커버리부(101)로부터 수신하여, 검출 결과의 처리를 수행한다. CI 식별부(102)는, 상기 CI에 대한 정보가 새로운 CI에 대한 정보인지 또는 기존의 CI의 갱신된 속성 혹은 관계의 값인지를, CMDB(105)를 참조하여 결정한다. 상기 결정은, 예를 들면, CMDB에 저장된 CI의 인스턴스 명을 상기 CI에 대한 정보와 비교하여 수행될 수 있다. 상기 CI에 대한 정보가 새로운 CI의 관한 것이라는 것에 따라, CI 식별부(102)는, 상기 정보를 CI 인스턴스 작성부(103)로 보낸다. 한편 상기 CI에 대한 정보가 기존의 CI의 갱신된 속성 혹은 관계의 값이라는 것에 따라, CI 식별부(102)는, 상기 정보를 속성 및 관계 갱신부(104)로 보낸다.

CI 인스턴스 작성부(103)는, 모델 테이블(107)에 저장된 데이터 모델(도 4, 201), 및 관계 테이블(108)에 저장된 관계 모델(도 4, 204)에 따라, CI에 대한 정보로부터, 상기 CI에 소정의 속성 및 다른 CI와의 관계를 나타내는 한 세트의 데이터를 작성한다. 상기 한 세트의 데이터는 예를 들면, 정적 데이터 인스턴스 또는 Java(선 마이크로 시스템즈의 상표)의 클래스의 인스턴스에서 실장될 수 있다. 상기 한 세트의 데이터의 예는 CI 인스턴스이다. CI 인스턴스의 예를 도 4(203)에 나타낸다. 상기 한 세트의 데이터는 CMDB(105) 내에 저장된다. 또한, 한 세트의 데이터는 CI 인스턴스 내에 속성 및 관계를 가지고 있어도 되고(도 4, 203을 참조), 혹은 CI 인스턴스 내에 속성을 가지고, 그것과는 다른 관계 인스턴스로서 개개에 CMDB(105 내에 저장되어도 된다. 후자의 경우, CI 인스턴스는, 관련하는 관계 인스턴스를 특정하기 위한 링크를 가진다.

속성 및 관계 갱신부(104)는, 디스커버리부(101)와 같이 트래킹을 실현한다. 속성 및 관계 갱신부(104)는, CI가 갱신된 속성 혹은 관계의 값을, CMDB 내에 저장된 상기 CI의 CI 인스턴스에 반영한다. 즉, 상기 CI의 CI 인스턴스의 속성 혹은 관계의 값을 갱신한다. 상기 갱신은, 상기 값을 디스커버리부(101)에 의해 검출된 CI에 대한 정보와 바꾸는 것으로 수행된다. 상기 바꾸는 것은, CI 인스턴스의 속성 혹은 관계의 값의 모든 것을 디스커버리부(101)에 의해 검출된 CI에 대한 정보와 바꾸어도 되고, 혹은 다른 값 만을 바꾸어도 된다.

CMDB(105)는 CI의 CI 인스턴스(도 4, 203)를 저장한다.

디스커버리 테이블(106)은 디스커버리 인스턴스(도 4, 202)를 저장한다. 디스커버리 인스턴스는 디스커버리부(101)에 의해 CI에 대한 정보가 검출될 때에 사용된다. 디스커버리 인스턴스(202)는, 예를 들면, 정적 데이터의 인스턴스 또는 Java(선 마이크로 시스템즈의 상표)의 클래스의 인스턴스에서 실장될 수 있다. 디스커버리 인스턴스는 디스커버리 폴리시(discovery policy) 로도 불린다. 디스커버리 인스턴스(202)는, 디스커버리부(101)가 검색하는 범위, 즉 CI의 검색 범위인 수집 대상(스코프), 수집하는 속성, 및 수집하는 관계를 포함한다(202). 수집 대상은, 예를 들면, 서브 넷 IP 주소, IP 주소의 범위, 개개의 IP 주소, MAC 주소, 기기의 식별자, 호스트 명 혹은 데이터베이스 명 또는 그것들의 조합을 이용하여 지정될 수 있다. 다른 태양으로서, 수집 대상을, 컴퓨터 시스템(100)에 네트워크를 통해서 접속된 스케쥴 관리 데이터베이스(도시하지 않음)로서도 된다. 스케쥴 관리 데이터베이스에는 예를 들면, 기기를 사용하는 프로세스 관리에 관한 데이터가 저장된다. 또한 다른 태양으로서, 수집 대상을, 배치 처리 정의 파일을 저장하는 데이터베이스(도시하지 않음)로서도 된다. 수집 대상이 배치 처리 정의 파일을 저장하는 데이터베이스의 경우, 디스커버리부(101)는 일괄 처리 정의 파일의 내용을 읽는 것으로 검출을 수행한다. 배치 처리 정의 파일에는, 예를 들면 기기를 어느 순으로 사용할 지의 데이터가 저장된다.

모델 테이블(107)은 데이터 모델(도 4, 201)을 저장한다. 데이터 모델은 CI 인스턴스 작성부(103)에 의해 상기 CI의 소정의 속성 및 다른 CI와의 관계를 나타내는 한 세트의 데이터가 작성될 때에 사용된다.

관계 테이블(108)은 관계 모델(도 4, 204)를 저장한다. 관계 모델은, CI 인스턴스 작성부(103)에 의해 상기 CI의 소정의 속성 및 다른 CI와의 관계를 나타내는 한 세트의 데이터가 작성될 때에 사용된다.

도 1에서 디스커버리부(101)는 컴퓨터 시스템(100)과 네트워크를 통해 접속된 관리 대상인 CI에 관한 정보를 검출하고, 구성 요소 A, 및 구성 요소 B 및 그것들 구성 요소의 관계 대한 정보를 검출하는 것을 나타낸다. 다음으로, CI 식별부(102)는, 상기 검출한 정보가 새로운 CI에 대한 것인지에 대해 CMDB(105)를 참조하여 결정한다. 상기 결정에 따라, CI 인스턴스 작성부(103)는, 구성 요소 A의 CI 인스턴스 및 구성 요소B의 CI 인스턴스, 및 그것들 구성 요소의 관계(used By)의 인스턴스를 작성한다. CI 인스턴스 작성부(103)는, 상기 작성한 각 인스턴스를 CMDB(105) 내에 저장한다. 도 1에서는, 구성 요소 B의 CI 인스턴스가, 구성 요소 A의 CI 인스턴스와 used By의 관계에 있다는 것을 나타낸다.

디스커버리부(101)는, 검출한 CI에 대한 정보를 배경으로, 데이터 모델(도 4, 201)에 따라, CI 및 그것들 CI 간의 관계를 작성하고, CMDB(105)에 등록한다. CMDB(105)는 CI의 속성 및 다른 CI와의 관계를 저장한다. 따라서, 시스템 관리자는 CMDB(105)를 이용하여, CI 간의 실제 의존 관계를 추출하는 것이 가능하다.

구성 요소는, 하드웨어 구성 요소, 소프트웨어 구성 요소를 포함하고, 그 조합은 임의이다.

도 2는 종래 기술로서, 구성 관리를 위한 툴의 개요를 나타내는 도면이다.

구성 관리를 위한 툴은, 구성 요소에 대한 정보(이하, 단지'구성 정보'로 일컬어지기도 함)를 자동 수집하는 기능(디스커버리), 구성 정보를 그래픽으로 표시하는 기능(토폴로지) 및 변경 이력, 구성 비교 등의 분석을 수행하는 기능(analytics)을 가진다. 예를 들면, TADDM 서버는, 정보 시스템에 대한 구성 정보를, ssh, SNMP, WMI 등을 사용해서 취득한다. 상기 구성 정보는 예를 들면, 각 정보 시스템의 운영체제의 종류 또는 그 구성, 어플리케이션의 종류 또는 그 구성 값이다. TADDM 서버는, 취득한 정보를 CMDB 내에 CI 인스턴스로서 저장한다. TADDM 서버는 CMDB에 저장한 CI 인스턴스에 근거하여, 관리자의 컴퓨터에 구성 정보, 및 변경 이력 정보를 보낸다. 관리자의 컴퓨터는 상기 정보를 이용하여 구성 정보의 표시 및 변경 이력의 표시를 수행한다.

도 3은, 종래 기술인, CI, CI 인스턴스, 및 관계(usedBy) 인스턴스의 작성을 나타낸다.

구성 요소 A의 CI 인스턴스는, 디스커버리부(도 1, 101)에 의해 검출된 구성 요소 A에 대한 정보로부터, 구성 요소 A의 데이터, 모델을 이용해서 CI 인스턴스 작성부(도 1, 103)에 의해 작성된다. 같은 방법으로, 구성 요소 B의 CI 인스턴스는, 디스커버리부(101)에 의해 검출된 구성 요소 B에 대한 정보로부터, 구성 요소 B의 데이터, 모델을 이용해서 CI 인스턴스 작성부(103)에 의해 작성된다. 구성 요소 A 및 구성 요소 B의 각 데이터 모델은, 모델 테이블(도 1, 107)에 저장된다. CI끼리의 관계, 즉 구성 요소 A와 구성 요소 B와의 관계(usedBy)의 인스턴스는, 디스커버리부(101)에 의해 검출된 구성 요소 A에 대한 정보로부터, 관계 모델에 따라 CI 인스턴스 작성부(103)에 의해 작성된다. 관계 모델은, 관계 테이블(도 1, 108)에 저장된다.

또한, 구성 요소가 예를 들면 구성 요소 B(1), B(2), B(3)인 경우, 구성 요소 B(1), B(2), B(3)에 대한 각 정보가 구성 요소 B의 데이터 모델을 사용하여 인스턴스화 되어, 구성 요소 B(1)의 CI 인스턴스, 구성 요소 B(2)의 CI 인스턴스, 구성 요소 B(3)의 CI 인스턴스가 각각 작성된다. 구성 요소 B(1), B(2), B(3)의 각 CI 인스턴스도 또한, CMDB(도 1, 105) 내에 저장된다.

도 4는 종래 기술로서, 모델 테이블(도 1, 107)내에 저장된 데이터 모델(201), 디스커버리 테이블(도 1, 106) 내에 저장된 디스커버리 인스턴스(202), CMDB(도 1, 105) 내에 저장된 (구성 요소 A의) CI 인스턴스(203) 및 관계 테이블(도 1, 108) 내에 저장된 관계 모델(204)을 나타낸다.

데이터 모델(201)은, CI를 정의하기 위한 스킴이다. 데이터 모델(201)은 예를 들면, 어느 CI의 모델인지를 나타내는 모델명, 모델명에 지정된 CI가 가진 속성을 나타낸 모델 속성, 모델명에 지정된 CI와 다른 CI가 취할 수 있는 관계, 및 모델명에 지정된 CI를 검출하기 위한 디스커버리 인스턴스를 특정하는 디스커버리 방법의 각 기술을 포함한다. 모델 속성은, 예를 들면 IBM이 제창하는 구성 관리 데이터베이스용 데이터 모델 CDM에 규정된 속성에 따라 규정되지만, 이것으로 한정되지는 않는다. CDM에서는, 2006년 시점에서, 2609 종류의 속성이 규정되어 있다. CMDB의 관리자는, 데이터 모델(201)에서 속성을 임의로 지정할 수 있다. 관계는, 예를 들면 상기 CDM에 규정된 관계에 따라 규정되지만 이것으로 한정되지는 않는다. CDM에서는, 2006년의 시점에서, 57종류의 관계가 규정되어 있다. 디스커버리 방법은, 디스커버리 인스턴스명에서 특정될 수 있다. 도 4의 경우 A-Discovery이다.

디스커버리 인스턴스(202)는 데이터 모델(201)의 디스커버리 방법에 의해 특정되는 디스커버리 인스턴스의 이름, 디스커버리부(도 1, 101)에 의해 수집하는 관리 대상(CI)의 수집 대상(스코프), 디스커버리부(101)에 의해 수집하는 관리 대상(CI)의 수집하는 속성 및 수집하는 관계, 및 상기 디스커버리 인스턴스가 액티브인지 혹은 인 액티브인지를 나타내는 상테의 각 기술을 포함한다.

CI 인스턴스(203)는 상기 인스턴스가 어느 CI의 것인지를 특정하기 위한 인스턴스명, 상기 인스턴스가 어느 데이터 모델을 사용해서 작성되었는지를 나타내는 모델명, 데이터 모델에 의해 특정된 각 속성의 속성치, 데이터 모델에 의해 특정된 각 관계의 기술(치(value)), 인스턴스가 액티브인지 혹은 인 액티브인지를 나타내는 상태, 및 상기 CI 인스턴스가 작성된 작성 날짜의 각 기술을 포함한다. CI 인스턴스는 바람직하게는, CI 인스턴스에 특유의 CI 인스턴스 식별자를 포함한다. CI 인스턴스 식별자는, 상기 CI 인스턴스를 다른 CI 인스턴스와 구별할 수 있는 것이면 특별히 한정되지 않지만, 예를 들면 호스트 네임, 시리얼 넘버 혹은 일정의 값인 다른 속성의 조합을 사용할 수 있다. 도 4의 CI 인스턴스(203)는, 구성 요소 A의 CI 인스턴스라는 것; 데이터 모델 A를 사용해서 인스턴스화 된 것; 속성으로 S, T 및 U를 포함하고, 이것들 각각 값을 가진다는 것; 관계로서, M에 의해 사용된다는 것(usedBy: M), E에 접속된다는 것(connectAt: E), 및 H에서 실행한다는 것(runAt: H); CI 인스턴스가 액티브라는 것, 및 상기 CI 인스턴스의 작성 날짜의 데이터를 나타낸다.

관계 모델(204)은 데이터 모델(201)에 의해 특정되는 관계를 정의하기 위한 스킴이다. 관계 모델(204)은, usedBy 등의 관계명, 상기 관계의 대상이 되는 데이터 모델을 특정하기 위한 대상이 되는 데이터 모델, 상기 관계의 설명의 각 기술을 포함한다.

도 5는 종래 기술로서, CMDB에서 구성 정보 관리의 화면 예를 나타낸다. 상기 화면은 GUI에서 표시된다. 상기 표시는 예를 들면 TADDM을 이용하여 수행된다. 도 5에서, 구성 요소는 어플리케이션이다. 어플리케이션 간의 관계는, 실선으로 나타내었다. 또한, 상기 화면 상에서 표시된 어플리케이션 명(각 사의 상표)은, 예시이다.

도 6은, 본 발명의 실시 태양인, 작업 넷의 예를 나타낸다.

상기 예는, 작업 넷_1(301), 작업 넷_2(302), 작업 넷_3(303) 및 작업 넷_4(304)를 나타낸다.

작업 넷_1(301)은, 작업 넷_2(302) 및 작업 넷_3(303)의 선행 작업이다. 작업 넷_2(302)는, 작업 넷_4(304)의 선행 작업이다. 작업 넷_3(303)은, 작업 넷_4(304)의 선행 작업이다.

작업 넷_1(301)은, 4개의 작업(작업(1)~작업(4))을 포함한다. 작업 넷_2(302)는 2개의 작업(작업(5)~작업(6))을 포함한다. 작업 넷_3(303) 및 작업 넷_4(304)는, 1개의 작업(각각, 작업(7), 작업(8))을 포함한다.

작업(1)은, 작업(2) 및 작업(3)과 의존 관계가 있고, 작업(2) 및 작업(3) 각각은, 작업(4)와 의존 관계가 있다. 작업(5)는, 작업(6)과 의존 관계가 있다.

도 7은 본 발명의 실시 태양인, 작업 템플릿의 예를 나타낸다.

(1) 작업 템플릿(311)에 대해, 이하에 설명한다.

작업 템플릿 ID(ID)는 JP00001이다.

작업 템플릿을 설명하기 위한 기술(Description)은, 오프라인 재구성 작업(Offline Reorg Job)이다.

액션 타입(Action Type)은 재구성(Reorg)이다.

작업의 실행 커맨드(Action)는 실제로 실행되는 처리가, 예를 들면 작업 스크립트를 사용해서 기재될 수 있다. 작업 스크립트는, 구성 요소의 속성 또는 관계 데이터를 인수로서 가질 수 있다. 상기 인수는, 예를 들면 작업 템플릿이 사용되는 CI 타입 또는 전제 조건의 값을 사용한다.

작업 템플릿이 사용되는 CI 타입(CI Type to apply)은, 데이터베이스(DB)이다.

전제 조건(Prerequisite)은 구성 요소의 검색 조건(CI Search Condition), 다른 작업 템플릿을 검색하기 위한 액션 타입(Action Type)을 포함한다. 구성 요소의 검색 조건은 모든 유저(All User)이다. 모든 유저란, DB를 사용하고 있는 구성 요소이다. 상기 구성 요소는, DB와, 예를 들면 usedBy DB 라고 하는 관계를 가진다. 마찬가지로, DB는, 상기 구성 요소와, 예를 들면, usedBy Webspere 라고 하는 관계를 가진다. 상기 예에서는, 구성 요소가, 소프트웨어인 Webspere이고, Webspere가 DB를 사용하고 있다.

검색된 구성 요소에 대한 액션 타입은 중단(Stop)이다.

영향 플래그(Impact flag)는, 서비스 중단(Service Stop)이 YES이며, 고부하(High Stress)가 예(YES)이다. 서비스 중단이란, 시스템의 서비스 중단이다. 고부하란 시스템에 대한 높은 부하이다.

(2) 작업 템플릿(312)에 대해, 이하에 설명한다.

작업 템플릿 ID는 JT00002이다.

작업 템플릿을 설명하기 위한 기술은, 어플리케이션 서버 중단(AppServ Stop)이다.

액션 타입은 중단(Stop)이다.

작업의 실행 커맨드는 작업 스크립트를 사용해서 기재될 수 있다.

작업 템플릿이 적용되는 CI 타입은 어플리케이션 서버(AppServ)이다.

전제 조건은 기재되어 있지 않다.

영향 플래그는 서비스 중단이 예(YES)이고, 고부하는 아니오(NO)이다.

도 8은 본 발명의 실시 태양인 작업 장의 예를 나타낸다.

작업 정의(313)는, 작업 정의 명, 작업 내용, 작업 실행처, 작업 실행 유저, 작업 개시 스케쥴, 선행 작업, 작업의 실행 예측 시각, 및 작업 템플릿을 포함한다.

도 9는 본 발명의 실시 태양인 작업 넷 정의 예를 나타낸다. 작업 넷 정의(314)는, 작업 넷 정의명, 작업 자체, 작업의 실행 순, 및 작업의 실행 스케쥴을 포함한다.

작업 자체는 변수를 포함하고, 상기 변수는 작업 넷 정의로부터 작업 넷을 작성 할 때에, CMDB의 최신의 구성 정보로 바꿀 수 있다. 상기 변수로는, 예를 들면, 실행 커맨드에서 %Web1.logpath%와 같이 변수로 되어 있는 파라미터가 사용된다. %Web1.logpath%에서는 Web1라고 하는 ID 및 logpath라고 하는 속성명을 사용해서 CMDB로부터 구성 정보가 취득된다. 그리고, 상기 변수가 CMDB로부터의 구성 정보로 바꿀 수 있다. 작업의 실행 순은, 선행 작업의 내용을 포함한다. 작업의 실행 스케쥴은 상기 작업을 실행하는 스케쥴을 나타낸다. 작업의 실행 스케쥴에는, 예를 들면, 매일 일요일의 19:00와 같은 실행 스케쥴이 정의된다. 상기 작업 스케쥴은, 작업 넷 정의로부터 작업 넷을 작성할 때에 작업 넷이 작업 넷을 실행하는 시스템에 투입되는 실제 날짜, 예를 들면, 2008년 11월 2일(일요일이다)의 19:00로 변환된다.

도 10은 종래 기술로서, 작업 관리 서버의 예를 나타낸다.

작업 관리 서버(401)는, 작업 실행 에이전트(402)에 투입하는 작업을 일원 관리(consolidate management)한다. 작업의 관리자는, 작업 관리 콘솔(406)을 이용해서, 작업의 내용을 확인할 수 있다. 작업 관리 서버(401)는, 작업 실행 스케쥴에 근거하여, 작업 실행 에이전트(402)에 작업 실행 계획 데이터를 투입한다. 작업 실행 에이전트(402)는, 예를 들면, 웹 서버(403), 어플리케이션 서버(404) 및 배치 서버(batch server)(405)를 포함한다. 웹 서버(403), 어플리케이션 서버(404) 및 배치 서버(405)는, 작업의 실행 계획 데이터에 근거하여 작업을 실행한다. 작업 실행 에이전트(402)는 작업 실행의 결과 데이터를 작업 관리 서버(401)로 송신한다. 작업 관리 서버(401)는 작업 실행의 결과 데이터에 의해, 나중에 스케쥴되어 있는 작업의 실행 가부를 제어한다. 작업 관리 서버(401)는, 작업 관리 콘솔(406)의 요구에 따라, 작업 실행의 결과 데이터를 작업 관리 콘솔(406)을 이용해서 작업의 실행 결과를 확인할 수 있다.

종래의 작업 관리 서버(401)에서는, 작업 실행 계획 데이터를 수동으로 작성하고, 작업 간의 충돌에 대해서도 수동으로 대응하고 있다. 또, 작업의 대상인 시스템 구성 변경에 대해서도, 작업의 실행 계획 데이터를 수동으로 변경하고 있다.

도 11은 본 발명의 실시 태양인 시스템 전체의 구성도의 예를 나타낸다.

작업 관리 서버(501)는 CMDB(504) 내에 저장된 CI 인스턴스를 이용하여, 작업의 설계 지원, 작업의 실행을 한다. 작업의 설계 지원은, 작업 넷 정의 또는 작업 넷의 자동 작성, 작업 넷 정의 또는 작업 넷의 자동 갱신을 포함한다. 작업 관리 서버(501)는 또한 CMDB(504) 내에 저장된 CI 인스턴스를 이용하여, 작업 설계의 검증을 수행한다. 작업 설계의 검증은 작업의 충돌의 발견을 포함한다.

작업 관리 서버(501)는, 작업 템플릿을 저장하는 기억부(502)로부터 작업 템플릿을 읽어낸다. 작업 관리 서버(501)는 또, 작업 정의를 저장하는 기억부(도시하지 않음)로부터 작업 정의를 읽어낸다. 작업 정의를 저장하는 기억부는, 작업 템플릿을 저장하는 기억부(502)와 같은 물리적 기억 장치 내에 있어도 된다.

작업 관리 서버(501)는 작업 템플릿에 작업 정의를 적용하고, 작업 넷 정의를 작성한다. 작업 관리 서버(501)는 작업 넷 정의를 작성할 때에, CMDB(504)로부터 CI 인스턴스를 이용하여, 작업 넷 정의의 작성에 사용되는 작업 템플릿으로부터, 상기 작업 넷 정의의 작성에 필요한 구성 요소의 특정을 하는 것이 가능하다. CI 인스턴스는 구성 요소에 대한 속성 및 관계를 포함한다. 작업 관리 서버(501)는 구성 요소에 대해서도 속성 및 관계의 적어도 하나를 이용하여, 작업 템플릿에서 작업 넷 정의를 작성한다. CMDB 내의 CI 인스턴스는, 디스커버리부(507)에 의해 자동적으로 갱신된다. 또한, CI 인스턴스의 갱신은 관리자(508)에 의해 일부 수동으로 설정 또는 갱신되어도 된다. 구성 요소 중에서는, 수동에 의한 설정 또는 갱신이 아니면 안되는 데이터가 있는 경우도 있기 때문이다. 작성된 작업 넷 정의는, 작업 넷 정의 기억부(503)에 저장된다. 작업 관리 서버(501)는, 작업 넷 정의로부터 작업 넷(505)을 작성한다. 작업 관리 서버(501)는, 또, 작업 넷 정의 내에 정의된 인수에, CMDB(504)의 CI 인스턴스에 대한 데이터를 부여하여, 작업 넷 정의로부터 작업 넷(505)을 작성한다.

작업 관리 서버(501)는 작업 넷을 실행하는 시스템(506)에, 상기 작성한 작업 넷(505)을 투입한다.

작업 관리 서버(501)는, 작업 넷 정의를 작성하기 직전, 작업 넷을 작성하기 직전, 또는 상기 시스템(506)에 작업 넷을 투입하기 직전에, 디스커버리부(507)에 대해서, 구성 정보에 대한 디스커버리를 요구할 수 있다. 상기 디스커버리에 의해서, CMDB(504) 내의 CI 인스턴스의 속성 및 관계가 갱신된다.

작업 관리 서버(501)는, 상기 갱신된 CI 인스턴스의 속성 및 관계의 적어도 하나에 근거하여, 작업 넷 정의 또는 작업 넷을 갱신할 수 있다.

작업 관리 서버(501)는, 작업 넷 정의 또는 작업 넷의 작성 또는 갱신할 시에, CI 인스턴스의 속성 및 관계의 적어도 하나를 이용해서, 작업의 충돌을 발견한다.

도 12는 본 발명의 실시 태양인, 작업 관리 서버의 구성도의 예를 나타낸다.

작업 관리 서버(501)는, 실행부(509), CPU(509), 메모리(513), 및 하드 디스크 드라이브 등의 기억부(514)를 포함한다.

실행부(509)는 CMDB(504)에 저장된 CI 인스턴스의 속성 및 관계의 적어도 하나를 사용하여, 적어도 하나의 작업 템플릿에 정의된 조건에 따라 작업 넷의 작성, 갱신, 또는 작업의 충돌의 발견을 실행한다.

실행부(509)는 또한, 제 1의 작성부(510) 및 제 2의 작성부(511)를 포함한다. 제 1의 작성부(510)는 상기 CI 인스턴스의 속성 및 관계의 적어도 하나를 사용하여, 작업 템플릿에서 작업 넷 정의를 작성한다. 제 1의 작성부(510)는 작성된 작업 넷 정의를 작업 넷 정의 기억부(503)에 저장한다. 제 2의 작성부(511)는 상기 CI 인스턴스의 속성 및 관계 중 적어도 하나를 사용하여, 작업 넷 정의로부터 작업 넷(505)을 작성한다.

CPU(509)는 작업 관리 서버(501)로부터의 명령을 수신하여 일괄 작업을 관리하는 방법을 실행한다.

기억부(514)는 작업 템플릿을 저장하는 기억부(502)로부터 읽어낸 작업 템플릿을 기억한다. 기억부(514)는 또한 작업 넷 정의를 저장하는 기억부(503)로부터 읽어낸 작업 넷 정의를 기억한다.

도 13은 본 발명의 실시 형태인, 작업 넷 정의 및 작업 넷을 작성하는 흐름도를 나타낸다.

단계(531)에서, 작업 관리 서버(501)는 작업 넷 정의를 작성하기 위해, 작업의 설계자가 선택한 적어도 하나의 작업 템플릿을 작업 템플릿 기억부(502)로부터 읽어낸다.

단계(532)에서, 작업 관리 서버(501)는 상기 선택된 작업 템플릿이 적용되는 구성 요소와 관계를 가지고 상기 선택된 작업 템플릿의 전제 조건을 만족하는 구성 요소를 검색한다.

단계(533)에서, 작업 관리 서버(501)는 상기 선택된 작업 템플릿에 작업 정의를 적용하여 작업 넷 정의를 작성한다. 또한, 작업 관리 서버(501)는 상기 선택된 작업 템플릿 내에 인수가 정의되어 있는 경우, CMDB(504)에 저장된 CI 인스턴스의 속성 및 관계의 데이터의 적어도 하나를 상기 인수에 부여한다.

단계(534)에서, 작업 관리 서버(501)는 작성된 작업 넷 정의를 작업 넷 정의 기억부(503)에 저장한다.

단계(535)에서, 작업 관리 서버(501)는 작업 넷을 작성하는 명령에 따라, 작업 넷 정의의 재검사를 한다. 이 이유는, 상기 작업 넷 정의가 작성된 후, 소정의 기간을 경과하고 있을 때 CMDB의 CI 인스턴스가 갱신되어 있는 경우가 있기 때문이다. 예를 들면, 상기 갱신에 의해, 작업 템플릿의 전제 조건을 만족하는 구성 요소가 변하는 경우가 생각된다. 따라서, 작업 관리 서버(501)는, 단계(532)의 내용을 반복하고, 필요하면, 작업 넷 정의를 갱신한다.

단계(536)에서, 작업 관리 서버(501)는 상기 작업 넷 정의를 읽어서, 작업 넷을 작성한다. 작업 관리 서버(501)는 상기 읽은 작업 넷 정의 내에 인수가 정의되어 있는 경우, CMDB(504)에 저장된 CI 인스턴스의 속성 및 관계의 데이터의 적어도 하나를 상기 인수에 부여한다.

단계(537)에서, 작업 관리 서버(501)는 작성된 작업 넷을 작업 넷 기억부(도시하지 않음)에 저장한다.

단계(538)에서, 작업 관리 서버(501)는 작업 넷을 상기 작업 넷을 실행하는 시스템에 투입하는 명령에 따라, 작업 넷의 재검사를 한다. 그 이유는, 상기 작업 넷이 작성된 후, 소정의 기간을 경과하고 있을 때 CMDB의 CI 인스턴스가 갱신되어 있는 경우가 있기 때문이다. 예를 들면, 상기 갱신에 의해, 작업 넷 정의에 정의된 인수의 값이 변하는 경우를 고려해 볼 수 있다. 따라서, 작업 관리 서버(501)는, 단계(536)의 내용을 반복하고, 필요하면, 작업 넷을 갱신한다.

단계(539)에서, 작업 관리 서버(501)는 상기 작성된 작업 넷을 실행하는 컴퓨터에 상기 작업 넷을 투입한다.

도 14는 본 발명의 실시 태양인, 작업 넷 정의 또는 작업 넷의 갱신을 하는 흐름도를 나타낸다.

단계(521에서, 작업 관리 서버(501)는 작업 넷 정의를 작성하기 위해, 작업의 설계자가 선택한 적어도 하나의 작업 템플릿을, 작업 템플릿 기억부(502)로부터 읽어낸다. 작업 설계에서, 최초의 작업 템플릿의 선택은, 작업의 설계자가 수행한다. 설계자는 선택한 작업 템플릿에 대한 정보를 컴퓨터 시스템에 부여한다.

단계(522)에서, 작업 관리 서버(501)은 상기 선택된 작업 템플릿이 적용되는 구성 요소와 관계를 가지고 상기 선택된 작업 템플릿의 전제 조건을 만족하는 구성 요소를 검색한다. 상기 검색은, CMDB(504)에 저장된 복수의 CI 인스턴스의 속성 및 관계의 데이터를 검색하는 것으로 수행된다.

단계(523)에서, 작업 관리 서버(501)는 상기 선택된 작업 템플릿에, 작업 정의를 적용하여 작업 넷 정의를 작성한다. 또한, 작업 관리 서버(501)는 상기 선택된 작업 템플릿 내에 인수가 정의되어 있는 경우, CMDB(504)에 저장된 CI 인스턴스의 속성 및 관계의 데이터의 적어도 하나를 상기 인수에 부여한다.

단계(523)에서, 작업 관리 서버(501)는 상기 작업 넷 정의를 읽어, 작업 넷을 작성한다. 작업 관리 서버(501)는 상기 읽은 작업 넷 정의 내에 인수가 정의되어 있는 경우, CMDB(504)에 저장된 CI 인스턴스의 속성 및 관계의 데이터의 적어도 하나를 상기 인수에 부여한다.

단계(525)에서, 작업 관리 서버(501)는 상기 작업을 실행하는 컴퓨터에 상기 작업 넷을 투입한다.

도 15는 본 발명의 실시 태양인, 작업의 검증을 하는 흐름도이다.

단계(541)에서, 작업 관리 서버(501)는 작업 넷 정의를 작성하기 위해, 작업의 설계자가 선택한 적어도 하나의 작업 템플릿을, 작업 템플릿 기억부(502)로부터 읽어낸다.

단계(542)에서, 작업 관리 서버(501)는 상기 선택된 작업 템플릿이 적용되는 구성 요소와 관계를 가지고 상기 선택된 작업 템플릿의 전제 조건을 만족하는 구성 요소를 검색한다.

단계(543)에서, 작업 관리 서버(501)는 상기 선택된 작업 템플릿에, 작업 정의를 적용하여 작업 넷 정의를 작성한다. 또한, 작업 관리 서버(501)는 상기 선택된 작업 템플릿 내에 인수가 정의되어 있는 경우, CMDB(504)에 저장된 CI 인스턴스의 속성 및 관계의 데이터의 적어도 하나를 상기 인수에 부여한다.

단계(544)에서, 작업 관리 서버(501)는 구성 요소에 대한 속성 또는 관계 데이터가 작업 템플릿의 전제 조건 또는 영향 플래그에 반하지 않는지를 알아본다. 그 이유는, 상기 작업 넷 정의가 작성된 후, 소정의 기간을 경과하고 있을 때에 CMDB의 CI 인스턴스가 갱신되었을 경우가 있기 때문이다. 예를 들면 상기 갱신에 의해, 작업 템플릿의 전제 조건을 만족하는 구성 요소가 변하는 경우를 고려해 볼 수 있다. 상기 전제 조건 또는 영향 플래그에 반하는 경우, 단계(545)로 진행한다. 한편, 상기 전제 조건 또는 영향 플래그에 반하지 않는 경우, 단계(546)로 진행한다.

단계(545)에서, 작업 관리 서버(501)은 단계(543)의 내용을 반복한다.

단계(546)에서, 작업 관리 서버(501)는 상기 작업 넷 정의를 읽어, 작업 넷을 작성한다. 작업 관리 서버(501)는 상기 읽은 작업 넷 정의 내에 인수가 정의되어 있는 경우, CMDB(504)에 저장된 CI 인스턴스의 속성 및 관계의 데이터의 적어도 하나를 상기 인수에 부여한다.

단계(547)에서, 작업 관리 서버(501)는 작업 넷을 상기 작업 넷을 실행하는 시스템에 투입하라는 명령에 따라, 구성 요소에 대한 속성 또는 관계 데이터가 작업 템플릿의 전제 조건 또는 영향 플래그에 반하지 않는가 알아본다. 그 이유는, 상기 작업 넷이 작성된 후, 소정의 기간을 경과하고 있을 때에 CMDB의 CI 인스턴스가 갱신되었을 경우가 있기 때문이다. 예를 들면 상기 갱신에 의해, 작업 템플릿의 전제 조건을 만족하는 구성 요소가 변하는 경우가 생각된다. 또, 작업 넷 정의에 인수가 정의되어 있는 경우, CMDB(504)에 저장된 CI 인스턴스의 속성 및 관계의 데이터의 갱신된 적어도 하나를 상기 인수에 부여한다. 상기 전제 조건 또는 영향 플래그에 반하는 경우, 단계(548)로 진행한다. 한편, 상기 전제 조건 또는 영향 플래그에 반하지 않는 경우, 단계(549)로 진행한다.

단계(549)에서, 작업 관리 서버(501)는 상기 작업 넷을 실행하는 컴퓨터에 상기 작업 넷을 투입한다.

도 16은 본 발명의 실시 태양인, 작업의 충돌을 발견하는 흐름도이다.

단계(551)에서, 작업 관리 서버(501)는 작업 넷 정의를 작성하기 위해, 작업의 설계자가 선택한 적어도 하나의 작업 템플릿을, 작업 템플릿 기억부(502)로부터 읽어낸다.

단계(552)에서, 작업 관리 서버(501)는 상기 선택된 작업 템플릿이 적용되는 구성 요소와 관계를 가지고 상기 선택된 작업 템플릿의 전제 조건을 만족하는 구성 요소를 검색한다.

단계(553)에서, 작업 관리 서버(501)는 상기 선택된 작업 템플릿에, 작업 정의를 적용하여, 작업 넷 정의를 작성한다. 또한, 작업 관리 서버(501)는 상기 선택된 작업 템플릿 내에 인수가 정의되어 있는 경우, CMDB(504)에 저장된 CI 인스턴스의 속성 및 관계의 데이터의 적어도 하나를 상기 인수에 부여한다.

단계(554)에서, 작업 관리 서버(501)는 작업의 충돌이 없는지를 검사한다. 작업의 충돌은, 예를 들면, 이하의 태양이 고려될 수 있다.

·제 1의 작업 템플릿의 작업의 실행 커맨드와 관련된 제 1의 구성 요소 및 상기 제 1의 구성 요소와 관계를 가지는 제 2의 구성 요소의 적어도 하나를 상기 작업이 이용하는 실행 시간대와, 제 2의 작업 템플릿의 작업의 실행 커맨드와 관련된 제 3의 구성 요소 및 상기 제 3의 구성 요소와 관계를 가진 제 4의 구성 요소의 적어도 하나를 상기 작업이 이용하는 실행 시간대가 겹치는 것.

·작업 템플릿의 작업의 실행 커맨드와 관련된 제 1의 구성 요소 및 상기 제 1의 구성 요소와 관계를 가지는 제 2의 구성 요소의 적어도 하나를 상기 작업이 이용하는 실행 시간대가 상기 작업을 실행할 수 없는 시간대인 것.

작업에 충돌이 있는 경우, 단계(555)로 진행한다. 한편, 작업에 충돌이 없는 경우, 단계(556)로 진행한다.

단계(555)에서, 작업 간의 충돌이 없도록 작업 넷 정의를 수정한다. 상기 수정을 위해, 상기 선택된 작업 템플릿 내에 인수가 정의되어 있는 경우, CMDB(504)에 저장된 CI 인스턴스의 속성 및 관계의 데이터의 적어도 하나를 상기 인수에 부여한다.

단계(556)에서, 작업 관리 서버(501)는 상기 작업 넷 정의를 읽어, 작업 넷을 작성한다. 작업 관리 서버(501)는, 상기 읽은 작업 넷 정의 내에 인수가 정의되어 있는 경우, CMDB(504)에 저장된 CI 인스턴스의 속성 및 관계의 데이터의 적어도 하나를 상기 인수에 부여한다.

단계(557)에서, 작업 관리 서버(501)는 작업의 충돌이 없는지를 검사한다. 작업에 충돌이 있는 경우, 단계(558)로 진행한다. 한편, 작업에 충돌이 없는 경우, 단계(558)로 진행한다.

단계(558)에서, 작업 간의 충돌이 없도록 작업 넷 정의를 수정한다. 상기 수정을 위해, 상기 선택된 작업 템플릿 내에 인수가 정의되어 있는 경우, CMDB(504)에 저장된 CI 인스턴스의 속성 및 관계의 데이터의 적어도 하나를 상기 인수에 부여한다.

단계(559)에서, 작업 관리 서버(501)는 상기 작성된 작업 넷을 실행하는 컴퓨터에 상기 작업 넷을 투입한다.

도 17은 본 발명의 실행 태양인 작업 넷 정의 및 작업 넷의 작성을 나타낸다.

작업 템플릿(601)은 2개의 작업 템플릿을 가지고 있다. 상기 작업 템플릿은 오프라인 재구성 작업 템플릿 및 Stop AppServ 작업(이하, Stop작업이라고 한다) 템플릿이다.

오프라인 재구성 작업 템플릿의 실행 커맨드는, DB2(상표) 및 오라클(상표)에 대한 실행 커맨드이다. 오프라인 재구성 작업 템플릿의 전제 조건은, 모든 DB 클라이언트가 중단하는 것이다.

CMDB(602)에서는, 구성 요소 DB2(데이터베이스이다) 및 구성 요소 WebSphere Application Server(어플리케이션)(이하, WAS)(1) 및 (2) 각각에 대한 한 세트의 데이터가 저장되어 있다.

구성 요소 DB2의 속성의 하나는 CI 타입이 DB인 경우이다. 또한, 구성 요소 WAS의 속성의 하나는 CI 타입이 AppServ인 경우이다.

구성 요소 DB2의 관계는 usedBy WAS 1 및 usedBy WAS 2이다. 또, 구성 요소 WAS의 관계는 usedBy DB2 client이다.

작업 넷 정의(603)는 상기 2개의 작업 템플릿에서 작성된다. 작업 넷 정의에서는 또한, 예를 들면, 작업의 실행 스케쥴이 정의되어 있다. 작업의 실행 스케쥴은, 예를 들면 매주 일요일의 19:00이다. 작업 넷 정의에서는 또한, 예를 들면, CMDB로부터 취하는 데이터를 위한 인수가 정의되어 있다.

작업 넷(604)은 상기 작업 넷 정의로부터 작성된다. 작업 넷에서는, 상기 작업의 실행 스케쥴이 인스턴스화된다. 상기 작업의 실행 스케쥴은, 예를 들면, 2008년 10월 26일의 19:00이다. 이와 같이, 작업 넷에서는, 작업의 실행 스케쥴이, 작업 넷을 실제로 실행하는 시스템에 투입되는 날짜에 변환되어 있다. 똑같이, 상기 작업 넷에서는, 상기 CMDB로부터 취하는 데이터를 위한 인수에, CMDB로부터의 CI 인스턴스의 속성 및 관계의 적어도 한 세트의 데이터가 부여된다.

도 18은 도 17의 실시 태양인, 작업 넷 정의 및 작업 넷을 작성하는 흐름도를 나타낸다.

단계(611)에서, 작업 관리 서버(501)는 작업 넷 정의를 작성하기 위해, 작업의 설계자가 선택한 적어도 하나의 작업 템플릿(601)을, 작업 템플릿 기억부(502)로부터 읽어낸다. 단계(611)에서, 작업의 설계자가 작업 템플릿 오프라인 재구성 작업을 선택했기 때문에, 작업 관리 서버(501)는 상기 선택된 작업 템플릿을 작업 템플릿을 작업 템플릿 기억부(502)로부터 읽어낸다.

단계(612)에서, 작업 템플릿 오프라인 재구성 작업을, 작업 템플릿 내의 작업 템플릿이 적용되는 CI 타입에 정의된 구성 요소 DB2에 적용한다.

단계(613)에서, 작업 관리 서버(501)는 작업 템플릿 오프라인 재구성 작업의 전제 조건의 검색 조건 ALL DB Client Stopped에서, 구성 요소 DB2를 사용하는 관계 usedBy를 가진 구성 요소를 검색하는 것을 CMDB(602)에 의뢰한다.

단계(614)에서, 작업 관리 서버(501)는 CMDB(602)의 구성 요소 DB2의 CI 인스턴스의 관계 usedBy를 사용하여, 구성 요소 WAS 1 및 WAS 2가 구성 요소 DB2와의 관계에 있다는 것을 알 수 있다. 구성 요소 DB2는, 구성 요소 WAS 1과의 관계가 usedBy WAS 1이다. 구성 요소 DB2는 또, 구성 요소 WAS 2와의 관계가 usedBy WAS 2이다.

단계(615)에서, 작업 관리 서버(501)는 작업 템플릿 오프라인 재구성 작업의 전제 조건의 액션인 중단을, 구성 요소 WAS 1 및 WAS 2에 대해서 실행하기 위해, 작업 템플릿이 적용되는 CI 타입이 AppServ이고 그리고 액션 타입이 Stop인 작업 템플릿을 작업 템플릿 기억부에서 검색한다. 검색의 결과, 작업 템플릿 Stop AppServ 작업이 검색된다.

단계(616)에서, 작업 관리 서버(501)는 검색된 작업 템플릿 Stop AppServ 작업을 구성 요소 WAS 1 및 WAS 2에 대해서 자동적으로 적용한다.

단계(617)에서, 작업 관리 서버(501)는 작업 템플릿 오프라인 재구성 작업 및 작업 템플릿 Stop AppServ 작업에서 작업 넷 정의(603)를 작성한다.

단계(618)에서, 작업 관리 서버(501)는 작업 넷의 작성 명령을 수신한다.

단계(619)는 임의의 단계이며, 단계(619)에서, 작업 관리 서버(501)는 작업 넷의 작성 명령의 수신에 응답하여, 단계(613~617)를 반복하여, 작업 넷 정의를 갱신하여도 된다. 작업 넷 정의가 작성된 후에 소정의 기간을 경과하면, 시스템의 구성 요소도 변경되는 경우가 있기 때문에, 작업 넷 정의의 갱신이 필요해지는 경우가 있기 때문이다. 작업 관리 서버(501)는, 작업 넷 정의의 갱신을 가능하게 하기 위해서, 작업 넷 정의가 작성된 일시를 확인하고, 예를 들면 상기 날짜로부터 24시간을 경과하고 있는 경우에, 디스커버리부에 대해서 구성 요소의 디스커버리를 의뢰한다.

단계(620)에서, 작업 관리 서버(501)는 디스커버리에 의해 작업 넷 정의의 갱신이 필요한 경우, 작업 넷 정의를 갱신한다.

단계(621)에서, 작업 관리 서버(501)는 작업 넷 정의를 읽어서, 작업 넷을 작성한다. 작업 관리 서버(501)는, 상기 읽은 작업 넷 정의 내에 인수가 정의되어 있는 경우, CMDB(504)에 저장된 CI 인스턴스의 속성 및 관계의 데이터의 적어도 하나를 상기 인수에 부여한다. 작업 관리 서버(501)는 또, 작업 넷이 투입되는 실제 일시를 작업 넷 정의에 부여한다.

단계(622)에서, 작업 관리 서버(501)는 작업 넷의 투입 명령을 수신한다.

단계(623)은 임의의 단계이다. 단계(623)에서, 작업 관리 서버(501)는, 작업 넷의 투입 명령의 수신에 응답해서, 단계(619)와 똑같은 내용을 반복한다. 작업 넷이 작성된 후에 소정의 기간을 경과하면, 시스템의 구성 요소도 변경되는 경우가 있기 때문에, 작업 넷의 갱신이 필요해지는 경우가 있기 때문이다. 작업 관리 서버(501)는, 작업 넷의 갱신을 가능하게 하기 위해서, 작업 넷이 작성된 일시를 확인하고, 예를 들면 상기 날짜로부터 24시간을 경과하고 있는 경우에, 디스커버리부에 대해서 구성 요소의 디스커버리를 의뢰한다.

단계(624)에서, 작업 관리 서버(501)는 디스커버리에 의해 작업 넷의 갱신이 필요한 경우, 작업 넷을 갱신한다.

단계(625)에서, 작업 관리 서버(501)는 상기 작성된 작업 넷을 실행하는 컴퓨터에 상기 작업 넷을 투입한다.

도 19는 본 발명의 실시 태양인 작업 간의 충돌을 발견을 나타낸다.

작업 템플릿(701)은 2개의 작업 템플릿을 가지고 있다. 상기 작업 템플릿은 OS 재기동 작업 템플릿 및 바이러스 스캔 작업 템플릿이다.

OS 재기동 작업 템플릿의 영향 플래그는 서비스 중단이라는 것에서, OS 재기동 작업을 실행하면, 시스템의 서비스 중단이라고 하는 영향이 있다는 것을 나타낸다.

바이러스 스캔 작업 템플릿의 영향 플래그가 고부하라는 것으로부터는, 바이러스 스캔 작업을 실행하면, 시스템에 대해서 고부하가 걸리는 것을 나타낸다.

수주 시스템(order receiving system)(702)에서는, CMDB의 구성 정보를 사용해서, 업무 작업과 같은 시간대에 서비스 중단 작업이 할당되는 것을 알았다. 같은 시간대란, 작업 실행의 예상 시간이 겹친다는 것을 말한다. 에러 표시가 되기까지의 과정은 다음과 같다. 작업 관리 서버는, CMDB의 구성 정보를 이용해서, Linux의 CI 인스턴스의 관계(runAt)에서, 구성 요소 DB2를 알 수 있다. 다음으로, 작업 관리 서버는, 구성 요소 DB2의 CI 인스턴스의 관계 usedBy에서, 구성 요소 WAS를 알 수 있다. 마지막으로, 작업 관리 서버는, 구성 요소 WAS의 속성에서 WAS 상에서 가동하고 있는 업무 작업이 있다는 것을 알 수 있다. 따라서, 작업 관리 서버는, OS의 재기동에 의해, 서비스 중단 작업이 적용되면, Linux의 서비스의 중단이 발생한다는 것을 알 수 있다.

발송 시스템(703)에서는, CMDB의 구성 정보를 사용해서, 업무 작업과 같은 시간대에 고부하 작업이 할당된다는 것을 알았다. 같은 시간대란, 작업 실행의 예상 시간이 겹친다는 것을 말한다. 경고 표시가 되기까지의 과정은 다음과 같다. 작업 관리 서버는, CMDB의 구성 정보를 이용해서, Windows(상표)의 CI 인스턴스의 관계(runAt)에서, 구성 요소 SQL을 알 수 있다. 다음으로, 작업 관리 서버는, 구성 요소 SQL의 CI 인스턴스의 관계 usedBy에서, 구성 요소 Tomcat를 알 수 있다. 마지막으로, 작업 관리 서버는, 구성 요소 Tomcat의 속성에서 Tomcat 상에서 가동하고 있는 업무 작업이 있다는 것을 알 수 있다. 따라서, 작업 관리 서버는, 바이러스 스캔에 의해서, Windows에 대해서 고부하가 생기는 것을 알 수 있다.

도 20은 도 19의 실시 태양인 작업 간의 충돌을 발견하는 흐름도를 나타낸다.

이하에서는, 수주 시스템(702)과 발송 시스템(703)에 있어서 각각의 흐름도를 나타낸다.

(1) 수주 시스템(702)

단계(711)에서, 작업 관리 서버(501)는 작업 넷 정의를 작성하기 위해서, 작업의 설계자가 선택한 작업 템플릿 OS 재기동 작업을 작업 템플릿 기억부로부터 읽어낸다.

단계(712)에서, 작업 템플릿 OS 재기동 작업에서 작업 넷 정의 작성을 개시한다.

단계(713)에서, 작업 관리 서버(501)는 작업의 충돌이 없는지를 발견한다. 작업의 충돌이 있는 경우, 단계(714)로 진행한다. 한편, 작업의 충돌이 없는 경우, 작업 관리 서버(501)는 작업 템플릿으로부터 작업 넷 정의를 작성하고, 단계(715)로 진행한다.

단계(714)에서, 작업 관리 서버(501)는 작업의 충돌이 있다는 것을 작업의 설계자에게 알린다. 작업의 설계자는 에러의 표시를 보고, 작업 설계를 계속할지를 결정한다. 대체적으로는, 작업 관리 서버(501)가, 에러를 해소하도록, CMDB의 구성 정보를 이용해서 자동적으로 에러를 해소하고, 작업 넷 정의를 작성하도록 해도 된다.

단계(715)에서, 작업 관리 서버(501)는 작업 넷 정의에서 작업 넷의 작성을 개시한다.

단계(716)에서, 작업 관리 서버(501)는 작업의 충돌이 없는지를 발견한다. 작업의 충돌이 있는 경우, 단계(717)로 진행한다. 한편, 작업의 충돌이 없는 경우, 작업 관리 서버(501)는 작업 넷 정의로부터 작업 넷을 작성하고, 단계(718)로 진행한다.

단계(717)에서, 작업 관리 서버(501)는 작업의 충돌이 있다는 것을 작업의 설계자에게 알린다. 작업의 설계자는 에러의 표시를 보고, 작업 설계를 계속할지를 결정한다. 대체적으로는, 작업 관리 서버(501)가, 에러를 해소하도록, CMDB의 구성 정보를 이용해서 자동적으로 에러를 해소하고, 작업 넷을 작성하도록 해도 된다.

단계(718)에서, 작업 관리 서버는 작성된 작업 넷을 실행하는 컴퓨터에 상기 작업 넷을 투입한다.

(2) 발송 시스템(703)

단계(721)에서, 작업 관리 서버(501)는 작업 넷 정의를 작성하기 위해서, 작업의 설계자가 선택한 작업 템플릿 바이러스 스캔 작업을 작업 템플릿 기억부로부터 읽어낸다.

단계(722)에서, 작업 템플릿 바이러스 스캔 작업에서 작업 넷 정의 작성을 개시한다.

단계(723)에서, 작업 관리 서버(501)는 작업의 충돌이 없는지를 발견한다. 작업의 충돌이 있는 경우, 단계(724)로 진행한다. 한편, 작업의 충돌이 없는 경우, 작업 관리 서버(501)는 작업 템플릿으로부터 작업 넷 정의를 작성하고, 단계(725)로 진행한다.

단계(724)에서, 작업 관리 서버(501)는 작업의 충돌이 있다는 것을 작업의 설계자에게 알린다. 작업의 설계자는 에러의 표시를 보고, 작업 설계를 계속할지를 결정한다. 대체적으로는, 작업 관리 서버(501)가, 에러를 해소하도록, CMDB의 구성 정보를 이용해서 자동적으로 에러를 해소하고, 작업 넷 정의를 작성하도록 해도 된다.

단계(725)에서, 작업 관리 서버(501)는 작업 넷 정의에서 작업 넷의 작성을 개시한다.

단계(726)에서, 작업 관리 서버(501)는 작업의 충돌이 없는지를 발견한다. 작업의 충돌이 있는 경우, 단계(727)로 진행한다. 한편, 작업의 충돌이 없는 경우, 작업 관리 서버(501)는, 작업 넷 정의로부터 작업 넷을 작성하고, 단계(728)로 진행한다.

단계(727)에서, 작업 관리 서버(501)는 작업의 충돌이 있다는 것을 작업의 설계자에게 알린다. 작업의 설계자는 에러의 표시를 보고, 작업 설계를 계속할지를 결정한다. 대체적으로는, 작업 관리 서버(501)가, 에러를 해소하도록, CMDB의 구성 정보를 이용해서 자동적으로 에러를 해소하고, 작업 넷을 작성하도록 해도 된다.

단계(728)에서, 작업 관리 서버는 작성된 작업 넷을 실행하는 컴퓨터에 상기 작업 넷을 투입한다.

도 21은 본 발명의 실시 태양인 작업의 충돌을 발견하는 실시 태양을 나타낸다.

작업 템플릿(731)은 2개의 작업 템플릿을 가지고 있다. 상기 작업 템플릿은 OS 재기동 작업 템플릿 및 바이러스 스캔 작업 템플릿이다.

OS 재기동 작업 템플릿의 영향 플래그는 서비스 중단이라는 것으로부터, OS 재기동 작업을 실행하면, 시스템의 서비스 중단이라고 하는 영향이 있다는 것을 나타낸다.

바이러스 스캔 작업 템플릿의 영향 플래그가 고부하인 것으로부터, 바이러스 스캔 작업을 실행하면, 시스템에 대해서 고부하가 걸리는 것을 나타낸다.

수주 시스템(732)에서는, CMDB의 구성 정보를 사용해서, 온라인 시간대에 서비스 중단 작업이 할당되는 것을 알았다. 같은 시간대란, 작업 실행의 예상 시간이 겹친다는 것을 말한다. 에러 표시가 되기까지의 과정은 다음과 같다. 작업 관리 서버는, CMDB의 구성 정보를 이용해서, Linux의 CI 인스턴스의 관계(runAt)에서, 구성 요소 DB2를 알 수 있다. 다음으로, 작업 관리 서버는, 구성 요소 DB2의 CI 인스턴스의 관계 usedBy에서, 구성 요소 WAS를 알 수 있다. 마지막으로, 작업 관리 서버는, 구성 요소 WAS의 속성 온라인 시간에서 WAS 상에서 온라인 시간대에 가동하고 있는 업무 작업이 있다는 것을 알 수 있다. 따라서, 작업 관리 서버는, OS의 재기동에 의해, 서비스 중단 작업이 적용되면, Linux의 시스템이 재기동한다는 것을 알 수 있다.

수주 시스템(732)에서는, CMDB의 구성 정보를 사용해서, 온라인 시간대에 고부하 작업이 할당된다는 것을 알았다. 같은 시간대란, 작업 실행의 예상 시간이 겹친다는 것을 말한다. 경고 표시가 되기까지의 과정은 다음과 같다. 작업 관리 서버는,구성 요소 수신 시스템의 CI 관계(Including) 및 속성(온라인 시간대)을 이용해서, 바이러스 스캔 작업이 실행되면, 수주 시스템에 대해서 고부하가 발생한다는 것을 알 수 있다. 수신 시스템은, 4개의 구성 요소 Linux, DB2, WebSphere 및 Windows를 포함하지만, 수주 시스템으로서 하나의 구성 요소이다.

도 22는 도 21의 실시 태양인 작업의 충돌을 발견하는 흐름도를 나타낸다.

이하에서는 OS 재기동 작업 템플릿과 바이러스 스캔 작업 템플릿에 있어서 각각의 흐름도를 나타낸다.

(1) OS 재기동 작업 템플릿

단계(741)에서, 작업 관리 서버(501)는 작업 넷 정의를 작성하기 위해서, 작업의 설계자가 선택한 작업 템플릿 OS 재기동 작업을 작업 템플릿 기억부로부터 읽어낸다.

단계(742)에서, 작업 템플릿 OS 재기동 작업에서 작업 넷 정의 작성을 개시한다.

단계(743)에서, 작업 관리 서버(501)는 작업의 충돌이 없는지를 발견한다. 작업의 충돌이 있는 경우, 단계(744)로 진행한다. 한편, 작업의 충돌이 없는 경우, 작업 관리 서버(501)는, 작업 템플릿에서 작업 넷 정의를 작성하고, 단계(745)로 진행한다.

단계(744)에서, 작업 관리 서버(501)는 작업의 충돌이 있다는 것을 작업의 설계자에게 알린다. 작업의 설계자는 에러의 표시를 보고, 작업 설계를 계속할지를 결정한다. 대체적으로는, 작업 관리 서버(501)가, 에러를 해소하도록, CMDB의 구성 정보를 이용해서 자동적으로 에러를 해소하고, 작업 넷 정의를 작성하도록 해도 된다.

단계(745)에서, 작업 관리 서버(501)는 작업 넷 정의에서 작업 넷의 작성을 개시한다.

단계(746)에서, 작업 관리 서버(501)는 작업의 충돌이 없는지를 발견한다.

작업의 충돌이 있는 경우, 단계(747)로 진행한다. 한편, 작업의 충돌이 없는 경우, 작업 관리 서버(501)는, 작업 넷 정의에서 작업 넷을 작성하고, 단계(748)로 진행한다.

단계(747)에서, 작업 관리 서버(501)는 작업의 충돌이 있다는 것을 작업의 설계자에게 알린다. 작업의 설계자는 에러의 표시를 보고, 작업 설계를 계속할지를 결정한다. 대체적으로는, 작업 관리 서버(501)가, 에러를 해소하도록, CMDB의 구성 정보를 이용해서 자동적으로 에러를 해소하고, 작업 넷을 작성하도록 해도 된다.

단계(748)에서, 작업 관리 서버는 작성된 작업 넷을 실행하는 컴퓨터에 상기 작업 넷을 투입한다.

(2)바이러스 스캔 작업 템플릿

단계(751)에서, 작업 관리 서버(501)는 작업 넷 정의를 작성하기 위해서, 작업의 설계자가 선택한 작업 템플릿 바이러스 스캔 작업을 작업 템플릿 기억부로부터 읽어낸다.

단계(752)에서, 작업 템플릿 바이러스 스캔 작업에서 작업 넷 정의 작성을 개시한다.

단계(753)에서, 작업 관리 서버(501)는 작업의 충돌이 없는지를 발견한다. 작업의 충돌이 있는 경우, 단계(754)로 진행한다. 한편, 작업의 충돌이 없는 경우, 작업 관리 서버(501)는 작업 템플릿에서 작업 넷 정의를 작성하고, 단계(755)로 진행한다.

단계(754)에서, 작업 관리 서버(501)는 작업의 충돌이 있다는 것을 작업의 설계자에게 알린다. 작업의 설계자는 에러의 표시를 보고, 작업 설계를 계속할지를 결정한다. 대체적으로는, 작업 관리 서버(501)가, 에러를 해소하도록, CMDB의 구성 정보를 이용해서 자동적으로 에러를 해소하고, 작업 넷 정의를 작성하도록 해도 된다.

단계(755)에서, 작업 관리 서버(501)는 작업 넷 정의에서 작업 넷의 작성을 개시한다.

단계(756)에서, 작업 관리 서버(501)는 작업의 충돌이 없는지를 발견한다. 작업의 충돌이 있는 경우, 단계(757)로 진행한다. 한편, 작업의 충돌이 없는 경우, 작업 관리 서버(501)는, 작업 넷 정의에서 작업 넷을 작성하고, 단계(758)로 진행한다.

단계(757)에서, 작업 관리 서버(501)는 작업의 충돌이 있다는 것을 작업의 설계자에게 알린다. 작업의 설계자는 에러의 표시를 보고, 작업 설계를 계속할지를 결정한다. 대체적으로는, 작업 관리 서버(501)가, 에러를 해소하도록, CMDB의 구성 정보를 이용해서 자동적으로 에러를 해소하고, 작업 넷을 작성하도록 해도 된다.

단계(758)에서, 작업 관리 서버는 작성된 작업 넷을 실행하는 컴퓨터에 상기 작업 넷을 투입한다.

도 23은 본 발명의 실시 태양인, 작업 넷의 갱신을 나타낸다.

작업 관리 서버(801)는 작업 넷의 갱신을 통해서, 작업 설계의 재이용성을 높인다.

작업 템플릿(802)은 로그 유지관리(log maintenance) 작업 템플릿이며, 실행 커맨드에서의 처리는, cat/dev/null>%CllD$.logpath%로 나타내는 디렉토리를 이용한다. 작업 넷 정의(803)는, 로그 메인터넌스 작업 넷 정의이며, 실행 커맨드에서의 처리는, cat/dev/null>%Web1.logpath%로 나타내는 디렉토리를 이용한다. 작업 넷 정의(803)의 상기 디렉토리는 작업 템플릿(802)에서 정의된 디렉토리가 인스턴스화 된 것이다.

작업 관리 서버(801)는 작업 템플릿(802)에서 작업 넷 정의(803)을 작성하는데 있어, %$CllD$에 %Web1을 대입해서 인스턴스화 한다.

작업 관리 서버(801)는 구성 요소Web1(CI 인스턴스명: Web1)의 속성 로그 패스의 값을 CMDB로부터 읽는다. 속성 로그 패스의 값은, logpath=/logs/xxx.log라고 하자. 작업 관리 서버(801)는, CMDB로부터의 속성값 /logs/xxx.log를 작업 넷 정의의 %Web1에 대입하고, 작업 넷(805)를 작성한다.

다음으로, 구성 요소 Web1의 속성 로그 패스의 값이 /logs/xxx.log에서 /logs/yyy.log에 변경되었다고 하자. 디스커버리부는, 디스커버리에 의해 상기 변경을 자동적으로 검출한다. 상기 검출에 의해서, CMDB의 CI 인스턴스의 데이터가 갱신된다. 그리고, 작업 관리 서버(801)는, CMDB 내의 Web1에 대한 CI 인스턴스의 속성값 /logs.yyy.log를 읽어, 상기 속성값을 작업 넷 정의의 %Web1에 대입하고, 작업 넷을 작성한다.

이렇게 해서, 작업 템플릿(802) 및 작업 넷 정의(803)에 인수를 사용하는 것에 의해서, 작업 넷 정의를 변경하지 않고, 로그 파일의 출력처를 CMDB로부터의 정보를 사용해서 변경하는 것이 가능하다.

도 24는 도 23의 실시 태양인, 작업 넷을 갱신하는 흐름도를 나타낸다. 단계(811)에서는, 디스커버리부는, 구성 요소 시스템(806)에 대한 정보를 검출한다. CMDB 시스템(도 1, 10)은, 상기 정보에 근거하여, 구성 요소 시스템에서, 로그 파일의 출력처가 변경된 것을 검출한다.

단계(812)에서, CMDB 시스템은 상기 변경의 검출에 따라 CMDB를 갱신한다. 즉, 구성 요소 시스템의 CI 인스턴스의 속성 로그패스의 값이, /logs/xxx.log에서 /logs/yyy.log로 변경된다.

단계(813)에서, 작업 관리 서버(801)는 로그 유지관리 작업 넷 정의의 인수에, 상기 변경된 값 /logs/yyy.log를 대입한다.

단계(814)에서, 작업 관리 서버(801)는 로그 파일의 출력처로서, 갱신된 출력처를 포함하는 작업 넷을 생성한다, 또는 로그 파일의 출력처로서, 갱신된 출력처를 포함하는 작업 넷에 갱신한다.

단계(815)에서, 작업 관리 서버(801)는 작성된 작업 넷을 실행하는 컴퓨터에 상기 작업 넷을 투입한다.

도 25는 본 발명의 실시 태양에 관계되는 컴퓨터 하드웨어의 블록도를 나타낸다.

본 발명의 실시 태양에 관계되는 컴퓨터 시스템(901)은, CPU(902)와 메인 메모리(903)를 포함하고, 이것들은 버스(904)에 접속된다. CPU(902)는 바람직하게는, 32비트 또는 64비트의 아키텍쳐에 근거한 것이며, 예를 들면, 인텔사의 Xeon(상표) 시리즈, Core(상표) 시리즈, Atom(상표) 시리즈, Pentium(상표) 시리즈, Celeron(상표) 시리즈, AMD사의 Phenom(상표) 시리즈, Athlon(상표) 시리즈, Turion(상표) 시리즈 및 Sempron(상표) 등을 사용할 수 있다. 패스(904)에는, 디스플레이 컨트롤러(905)를 통해서, LCD 모니터 등의 디스플레이(906)가 접속된다. 디스플레이(906)는, 그 컴퓨터 시스템(901) 상에서 동작중의 소프트웨어에 대한 정보를, 적당한 그래픽 인터페이스에서 표시하기 위해 사용된다. 패스(904)에는 또, IDE 또는 SATA 컨트롤러(907)를 통해서, 하드 디스크 또는 실리콘 디스크(908)와, CD-ROM, DVD 또는 Blu-ray드라이브(909)가 접속된다. CD-ROM, DVD 또는 Blu-ray드라이브(909)는, 필요에 따라, CD-ROM, DVD-ROM 또는 BD로부터 프로그램을 하드 디스크 또는 실리콘 디스크(908)에 도입하기 위해 사용된다. 패스(904)에는 또한, 키보드 마우스 컨트롤러(910)를 통해서, 혹은 USB 컨트롤러(도시하지 않음)를 통해서, 키보드(911) 및 마우스(912)가 접속된다.

하드 디스크(908)에는, 운영체제, J2EE 등의 Java 처리 환경을 제공하는 프로그램, CMDB를 위한 운용 관리 프로그램, 그 외 다른 프로그램 및 데이터가, 메인 메모리(903)에 로드 가능한 것으로 기억된다. 운용 관리 프로그램은 바람직하게는, 인터내셔널 비즈니스 머신즈 코포레이션으로부터 제공되는 TADDM(Tivoli(상표) Application Dependency Discovery Manager)을 포함한다.

통신 인터페이스(914)는, 예를 들면 이더넷(상표) 프로토콜에 따르는 것이며, 통신 컨트롤러(913)를 통해서 버스(904)에 접속된다. 통신 인터페이스(914)는, 컴퓨터 시스템(901) 및 통신 회선(915)을 물리적으로 접속하는 역할을 맡고, 컴퓨터 시스템(901)의 운영체제의 통신 기능의 TCP/IP 통신 프로토콜에 대해서, 네트워크 인터페이스 층을 제공한다. 통신 회선은, 유선 LAN 환경, 혹은 예를 들면 IEEE802.1a/b/g/n 등의 무선 LAN 접속 규격에 근거하는 무선 LAN 환경이어도 된다.

또한 컴퓨터 등의 하드웨어를 접속하기 위한 네트워크 접속 장치로서 사용할 수 있는 것으로, 상기의 네트워크 스위치 이외에, 이것으로 없는 것은 아니지만, 라우터, 하드웨어 관리 콘솔 등이 있다. 요점으로는, 네트워크 운용 관리용 프로그램이 도입된 컴퓨터에서의, 소정의 커맨드에 의한 물음에 대해서, 그것에 접속된 컴퓨터의 IP 주소, MAC 주소 등의 구성 정보를 보낼 수 있는 기능을 가진 것이다. 네트워크 스위치 및 루터는, 어드레스 해결 프로토콜(ARP)을 위한, 그것에 접속된 컴퓨터의 IP 주소 및, 그것에 대응하는 MAC 주소의 리스트를 포함하는 ARP 테이블을 포함하고, 소정의 커맨드에 의한 물음에 대해서, ARP 테이블의 내용을 보내는 기능을 가진다. 하드웨어 관리 콘솔은, ARP 테이블보다 자세한, 컴퓨터의 구성 정보를 보낼 수 있다.

컴퓨터에는, 상술한 하드웨어 관리 콘솔이 접속되어 있다. 이것은, 컴퓨터에서, LPAR(가상 논리 구획)에 의해 1대의 컴퓨터를 복수의 구획으로 논리 분할하고, 그 각각의 구획에서, VMware에 의해, Windows(상표), Linux(상표) 등의 서로 다른 OS를 동작시키도록 하는 기능을 가진 것이다. 하드웨어 관리 콘솔에 시스템적으로 묻는 것으로, LPAR VMware에서 동작하고 있는 컴퓨터의 개개의 논리 구획에서의 정보를, 상세하게 얻을 수 있다.

이상, 실시 형태에 근거하여 본 발명을 설명하였는데, 본 실시 형태에 기재된 내용은, 본 발명의 한 예이고, 당업자라면, 본 발명의 기술적 범위를 벗어나지 않고서, 여러 가지의 변형 예를 생각해 낼 수 있다는 것을 알 수 있을 것이다. 예를 들면, CMDB와 그것에 저장된 CI만이 아니라, 다른 형식에 데이터베이스와 CI의 형식을 이용할 수 있다, 또, Java 이외에, C++, C# 등, 네트워크 관리 기능을 가진 API를 불러낼 수 있는 임의의 컴퓨터 개발 환경을 이용할 수 있다.

Claims (25)

1. 일괄 작업(batch job)을 관리하기 위한 컴퓨터 시스템으로서,
   적어도 하나의 작업 템플릿(job template)을 저장하는 기억부와,
   구성 요소(configuration item)의 적어도 하나의 소정의 속성, 및 상기 구성 요소와 다른 구성 요소와의 관계를 포함하는 한 세트의 데이터 내의 적어도 하나의 속성 또는 관계를 사용하여, 상기 적어도 하나의 작업 템플릿에 정의된 조건에 따른 작업 넷 정의(job net definition)의 작성 또는 갱신, 작업 넷의 작성 또는 갱신, 또는 작업의 충돌(conflict)의 발견을 실행하는 실행부 - 상기 한 세트의 데이터는 저장소에 보존되어 있고 구성 요소에 대한 정보를 검출하는 디스커버리에 의해 갱신될 수 있음 - 를 포함하는
   컴퓨터 시스템.
2. 제1항에 있어서, 상기 실행부는 상기 한 세트의 데이터 내의 적어도 하나의 속성 또는 관계를 사용하여, 상기 적어도 하나의 작업 템플릿에서 작업 넷 정의를 작성 또는 갱신하는 제 1의 작성부를 더 포함하는
   컴퓨터 시스템.
3. 제2항에 있어서, 상기 작업 템플릿은 작업의 실행 타입, 작업의 실행 커맨드, 상기 작업 템플릿이 적용되는 구성 요소, 및 작업의 실행의 전제 조건을 포함하는
   컴퓨터 시스템.
4. 제2항에 있어서, 상기 작업 넷 정의는 작업의 내용, 작업의 실행 순, 및 작업의 실행 스케쥴을 포함하는
   컴퓨터 시스템.
5. 제3항에 있어서, 상기 전제 조건은 구성 요소를 검색하기 위한 조건, 및 상기 구성 요소에 대한 작업의 실행 타입을 포함하는
   컴퓨터 시스템.
6. 제5항에 있어서, 상기 제 1의 작성부는 상기 한 세트의 데이터 내의 적어도 하나의 속성 또는 관계를 사용하여, 상기 전제 조건에 기재된 조건에 일치하는 구성 요소를 특정하는
   컴퓨터 시스템.
7. 제6항에 있어서, 상기 제 1의 작성부는 상기 특정된 구성 요소에 다른 작업 템플릿을 관련짓는
   컴퓨터 시스템.
8. 제2항에 있어서, 상기 제 1의 작성부는 상기 작업 템플릿에, 유저에 의해 정의된 작업 정의를 적용하는 것에 의해 작업 넷 정의를 작성하는
   컴퓨터 시스템.
9. 제8항에 있어서, 상기 작업 정의는 작업의 정의명(job definition name), 작업의 내용, 작업의 실행처(job executor), 작업의 실행 유저, 작업의 개시 스케쥴, 선행 작업, 작업의 실행 예측 시간, 및 작업 템플릿명을 포함하는
   컴퓨터 시스템.
10. 제2항에 있어서, 상기 컴퓨터 템플릿은 구성 요소에 대한 한 세트의 데이터를 취득하기 위한 인수(argument)를 포함하는
    컴퓨터 시스템.
11. 제1항에 있어서, 상기 실행부는 상기 한 세트의 데이터 내의 적어도 하나의 속성 또는 관계를 사용하여, 작업 넷 정의로부터 작업 넷을 작성 또는 갱신하는 제 2의 작성부를 더 포함하는
    컴퓨터 시스템.
12. 제11항에 있어서, 상기 작업 넷 정의는 구성 요소에 대한 한 세트의 데이터를 취득하기 위한 인수를 포함하는
    컴퓨터 시스템.
13. 제12항에 있어서, 상기 작업 넷 정의는 로그 유지관리 작업 넷 정의(log manitenance job net definition)이며, 상기 인수는 로그 패스(logpath)이고, 상기 로그 패스의 데이터는 상기 한 세트의 데이터에 의해 갱신되는
    컴퓨터 시스템.
14. 제11항에 있어서, 상기 제 2의 작성부는 작업 넷이 상기 작업 넷을 실행하는 시스템에 투입되는 일시, 및 작업 넷 정의에 있어서 정의된 구성 요소에 대한 인수에 대응하는 한 세트의 데이터의 속성 및 관계 중 적어도 하나를 상기 작업 넷에 적용하는
    컴퓨터 시스템.
15. 제1항에 있어서, 상기 작업의 충돌은 제 1의 작업 템플릿의 작업의 실행 커맨드와 관련된 제 1의 구성 요소 및 상기 제 1의 구성 요소와의 관계를 가진 제 2의 구성 요소의 적어도 하나를 상기 작업이 이용하는 실행 시간대와, 제 2의 작업 템플릿의 작업 실행 커맨드와 관련된 제 3의 구성 요소 및 제 3의 구성 요소와 관계를 가진 제 4의 구성 요소의 적어도 하나를 상기 작업이 이용하는 실행 시간대가 겹치는 것을 포함하는
    컴퓨터 시스템.
16. 제15항에 있어서, 상기 제 2의 구성 요소는 상기 제 1의 구성 요소의 한 세트의 데이터 내의 적어도 하나의 속성 또는 관계를 사용하여 검출되고, 상기 제 4의 구성 요소는 상기 제 3의 구성 요소의 한 세트의 데이터 내의 적어도 하나의 속성 또는 관계를 사용하여 검출되는
    컴퓨터 시스템.
17. 제16항에 있어서, 상기 제 1의 구성 요소의 상기 한 세트의 데이터는 상기 디스커버리에 의해 갱신된 한 세트의 데이터이거나, 상기 제 3의 구성 요소의 상기 한 세트의 데이터는 상기 디스커버리에 의해 갱신된 한 세트의 데이터인
    컴퓨터 시스템.
18. 제1항에 있어서, 상기 작업의 충돌은 상기 작업 템플릿의 작업의 실행 커맨드과 관련된 제 1의 구성 요소 및 상기 제 1의 구성 요소와 관계를 가진 제 2의 구성 요소 중 적어도 하나를 상기 작업이 이용하는 실행 시간대가, 상기 작업을 실행 할 수 없는 시간대라는 것을 포함하는
    컴퓨터 시스템.
19. 제18항에 있어서, 상기 제 1의 구성 요소의 상기 한 세트의 데이터 및 상기 제 2의 구성 요소의 상기 한 세트의 데이터는 상기 디스커버리에 의해 갱신된 한 세트의 데이터인
    컴퓨터 시스템.
20. 제1항에 있어서, 상기 디스커버리는 상기 작업 넷 정의를 작성하기 직전, 상기 작업 넷을 작성하기 직전, 또는 상기 작업 넷을 실행하는 시스템에 상기 작업 넷을 투입하기 직전에 수행되는
    컴퓨터 시스템.
21. 제1항에 있어서, 상기 작업 넷은 상기 디스커버리를 수행하는 작업을 포함하는
    컴퓨터 시스템.
22. 일괄 작업(batch job)을 관리하기 위한 방법으로서,
    적어도 하나의 작업 템플릿(job template)에 정의된 구성 요소(configuration item)를 특정하는 단계와,
    상기 특정된 구성 요소의 적어도 하나의 소정의 속성, 및 상기 구성 요소와 다른 구성 요소와의 관계를 포함하는 한 세트의 데이터 내의 적어도 하나의 속성 또는 관계를 사용하여, 상기 적어도 하나의 작업 템플릿에 정의된 조건에 따른 작업 넷 정의의 작성 또는 갱신, 작업 넷의 작성 또는 갱신, 또는 작업의 충돌의 발견을 실행하는 단계 - 상기 한 세트의 데이터는 저장소에 보존되어 있고 구성 요소에 대한 정보를 검출하는 디스커버리에 의해 갱신될 수 있음 - 를 포함하는
    방법.
23. 제22항에 있어서, 상기 한 세트의 데이터 내의 적어도 하나의 속성 또는 관계를 사용하여, 작업 템플릿으로부터 작업 넷 정의를 작성하는 단계와,
    상기 한 세트의 데이터 내의 적어도 하나의 속성 또는 관계를 사용하여, 작업 넷 정의로부터 작업 넷을 작성하는 단계를 포함하는
    방법.
24. 일괄 작업(batch job)을 관리하기 위한 방법으로서,
    구성 요소(configuration item)의 적어도 하나의 소정의 속성, 및 상기 구성 요소와 다른 구성 요소와의 관계를 포함하는 한 세트의 데이터를 저장소에 저장하는 단계와 - 상기 한 세트의 데이터는 구성 요소에 대한 정보를 검출하는 디스커버리에 의해 갱신될 수 있음 -,
    작업 템플릿(job template)에 정의된 구성 요소를 특정하는 단계와,
    상기 특정된 구성 요소에 대한 상기 한 세트의 데이터 내의 적어도 하나의 속성 또는 관계를 사용하여, 상기 작업 템플릿에 정의된 조건에 일치하는 하나의 구성 요소에, 다른 작업 템플릿을 관련짓는 단계와,
    상기 작업 템플릿 및 상기 다른 작업 템플릿을 사용하여, 작업 넷 정의를 작성하는 단계를 포함하는
    방법.
25. 일괄 작업(batch job)을 관리하기 위한 컴퓨터 프로그램으로서, 컴퓨터 시스템에, 청구항 22 내지 24 중 어느 한 항에 기재의 방법의 각 단계를 실행시키는
    컴퓨터 프로그램.

Images