혹시 ITSM이라는 것을 들어본 적이 있습니까?
만약 여러분이 IT회사에 다니고 있다면 특히 대기업에 다니고 있다면 대부분 ITSM이란 것을 들어보거나 겪어 본적이 있을 것입니다.
또한 대기업 IT회사를 다니길 희망하는 분이 있다면 ITSM이라는 것을 한 번쯤 짚어보고 넘어가면 참 좋을 것 같습니다 :)
한때 약 4년동안 ITSM을 담당했던 경험을 되짚어보면서 간략히 정리해 보겠습니다.
무엇보다 제가 직접 경험해 본 것을 기반으로 정리하는 것이므로 최신 내용은 아니고 한 3~4년전 내용이라고 생각하시면 되지만
큰 그림을 이해하는 데는 무리가 없을 것이라 판단됩니다.
ITSM이란?
ITSM을 풀어쓰면 IT Servise Management 의 약자입니다. 즉 IT 서비스 관리입니다.
하핫 알고보면 별거 아닙니다. 그냥 그럴듯하게 ITSM이라고 하면 뭔가 있어보이는 그런 것이죠 ㅋ
IT 서비스를 어떻게하면 잘 할 수 있을까? 에 대한 고민을 하자는 이야기입니다.
"뭐야? 고민하기 싫은데?"
걱정하지 마세요 그래서 ITIL 이라는 것이 있습니다.
ITIL은 IT서비스 관리를 어떻게 해야지 좋을까에 대한 고민을 이미 훌륭하신 누군가들이 고민하고 정리해둔 훌륭한한 베스트 프랙티스 모음집인데요.
현재는 ITIL v3가 중점일텐데 4~5년 전에는 ITIL v2였습니다. 실제로 큰 핵심은 v2나 v3나 동일하다고 봅니다.
결론은 ITIL에 의거하여 ITSM체계를 얼마나 잘 갖춰졌느냐가 IT서비스 관리를 잘 하고 있느냐 못하고 있느냐의 판단 기준이 된 것입니다.
그래서 이런 기준으로 인증심사도 있습니다.
ISO 20000 이란 것인데요.
대부분의 대기업이나 관공서등이 이 인증을 많이 받아놓았습니다. 이 인증을 받으면 대외적으로 IT 서비스 관리 체계가 잘 잡혀있다는 것을
증명하는 것이니까요.
그럼 이제 ITSM을 통해 어떻게 서비스를 관리하는지 볼까요?
서비스 딜리버리
일단 IT서비스를 한다는 이야기는 그 서비스를 받는 주체가 있기 마련입니다.
바로 고객입니다.
그럼 고객과 서비스 계약을 해야겠지요?
그 계약서가 SLA 입니다.
Servise Level Agreement 라는 것인데요. 말 그대로 서비스 수준 계약서입니다.
SLA는 이런 내용이 들어가겠죠.
예로 그룹웨어 서비스를 제공한다고 합시다
"그룹웨어 서비스 가용성이 99%이상을 달성해야 한다. 만약 가용성이 떨어지면 패널티 얼마를 물겠다"
말그대로 그룹웨어 접속이 몇일 안되면 SLA위반이 되는 것입니다.
따라서 SLA를 잘 지키기 위해서 이 서비스 수준을 정의하고 잘 관리를 해야 합니다.
이것을 SLM 이라고 합니다. 눈치 채셨겠지만 서비스 레벨 관리 입니다. ㅋ
그래서 SLM은 보통 시스템으로 구축해 두고 각 SLA항목들을 지표로 잘 만들어서 관리를 하고
매년 고객과 협의하에 갱신하거나 유지하게 됩니다.
그렇다면 서비스 레벨을 유지하기 위해서 여러가지 관리체계가 필요하겠지요.
그래서 ITIL v2에서는(v3도 큰 차이는 없습니다) 재무관리, 가용성관리, 용량관리, IT서비스 연속성 관리를 통해
SLM을 지원하도록 되어 있습니다.
재무관리야 돈일테구요,
가용성과 용량 그리고 IT서비스 연속성 관리는 아무래도 서로 연관이 되어있습니다.
이를 ITIL v2에서는 서비스 딜리버리로 칭하고 있습니다.
고객의 요구사항에 맞춰 IT서비스의 내역 및 수준을 정의하고(SLA) 이를 관리하는 것이 핵심입니다.
서비스 서포트
자 그럼 SLM을 통해 SLA를 잘 관리하기 위해서는
실제로 IT서비스를 운영을 잘 해야 할 것입니다.
어떻게 서비스를 지원할 것이냐에 대한 부분이 v2에서는 서비스 서포트 영역이 됩니다.
역시 간단히 정리해 보겠습니다.
일단 IT자원을 어딘가 모아야될 필요가 있습니다.
인력,기기,소스 등 이 모든 것을 CI 즉 구성요소라고 하는데 이를 저장하는 DB가
CMDB라 불리우며 이를 관리하는 것을 형상관리라 합니다.
하지만 상황에 따라 형상관리를 프로그램 소스에 한정되서만 관리하는 경우도 많습니다.
자 그리고 서비스를 지원하려면 가장 먼저 떠오르는게 무엇인가요?
"여보세요?"
그렇습니다. 바로 콜 센터인데요. ITSM에서도 서비스 데스크라는 기능조직이 있습니다.
서비스데스크는 SPOC(Single Poing of Contact) 라고 해서 단일접점을 제공하고 고객의 직접 응대를 담당합니다.
여기서 단일접점이란 고객이 번호하나만 알면 된다는 뜻이기도 합니다.
그럼 서비스데스크 운영요원들은(1선이라고 합니다) 관련 내용을 접수해야겠지요.
고객의 요청이나 장애접수등을 하게되는데요. 이를 인시던트라 합니다.
즉 인시던트 관리를 해야되는데요. 인시던트 관리의 핵심은 가장 빠른 시간 내에 해결하는데 목적이 있습니다.
보통 이미 사전에 쌓인 지식DB등을 통해서 임시방편을 통해서라도 빨리 해결하는데 그 목적이 있습니다.
특히 장애같은 경우.. 그 중에서도 긴급장애 같은 경우는 별도로 프로세스를 마련해서 빨리 대응할 필요성이 있습니다.
또 자주 접수되는 인시던트나 해결책이 보이지 않는 인시던트는 말그대로 문제가 됩니다.
이는 문제관리로 넘어가게 됩니다. 보통 2선에서 처리를 하겠죠 아무래도 1선요원은 전문지식이 2선요원보다는 떨어질테니까요~(인시던트의 경우도 전문지식이 필요하면 그 처리를 1선에서 2선으로 이관하도록 되어있습니다)
문제관리는 인시던트관리에 비해 시간에 쫒기지 않습니다.
문제발생을 최소화 하기위해 근보적인 원인을 찾아야 되는 프로세스가 되겠습니다.
그리고 인시던트나 문제를 해결하기 위해 필연적으로 변경이 뒤따르게 됩니다.
IT서비스관리니 아무래도 소스에 대한 변경이 필요할 수 있겠죠?
그래서 당연히 변경관리가 필요합니다.
그냥 맘대로 변경하는 것이 아니라 엄연히 정해진 변경관리 프로세스를 통해 변경을 수행해야 합니다.
CAB(변경자문위원회), CRB(변경검토위원회)등을 둬서 변경에 대한 승인과 투명성을 증가시키고
적절한 통제로 영향을 최소화시킵니다.
그리고 마지막으로 변경을 다했으면 릴리즈를 해야겠죠.
그래서 릴리즈관리가 들어갑니다.
그리고 서비스 서포트영역 전체는 시스템으로 구현이 되어있습니다.
어때요? 잘 생각해보면 ITSM이라는 것이 그렇게 어려운 개념은 아닙니다.
하지만 IT서비스를 하는데 필요한 요소가 잘 정의되있다는 것을 알 수 있고
한번쯤 시간을 내서 ITSM체계에 대해 공부를 한다면 IT서비스를 운영하는데 큰 도움이 될지도 모릅니다.
정리하면 아래 그림 하나로 설명이 됩니다. (V2 기준입니다)
다음 포스팅에서는 ITSM의 허와 실에 대해 다뤄보겠습니다 ^^
변화에 대하여 : http://blog.naver.com/zacra/120197623910
UI/UX에 대한 쉬운 이해 : http://blog.naver.com/zacra/120197578988
C구조대의 더 많은 정보, 글, 사진은 아래 자밥 스튜디오 페이지에서도 볼 수 있어요 ^^
http://www.facebook.com/zabobstudio