2014.02.19

돈 낭비 IT 프로젝트 5가지

Zeus Kerravala | Network World
지난 5년 동안 기업에서는 다른 어떤 직위보다도 CIO의 역할이 크게 변모했다. 과거 CIO의 성공은 데이터에 달려있었지만 이제는 비즈니스적인 지표로 측정된다.

오늘날의 CIO는 IT를 더욱 전략적으로 고려하고 비용을 낮추거나 생산성을 향상시키거나 이 두 가지를 이상적으로 달성할 수 있는 프로젝트에 초점을 맞춰야 한다.

하지만 많은 IT 프로젝트들이 시간과 돈을 낭비하고 있다. 전 세계적인 추세는 아니지만 높은 가치가 있을 것같은 많은 IT 프로젝트들이 실제로는 그렇지 못하다. 그래서 여기 예산을 낭비하는 IT 프로젝트들을 모아보았다.

과도한 대역폭 제공 또는 추가
네트워크에 크게 의존하는 애플리케이션의 성능을 관리하는 것은 항상 쉬운 일이 아니다. 애플리케이션 성능이 떨어질 경우, 대역폭을 늘리기 십상이다. 합리적인 것처럼 보이기도 한다.

하지만 실제로 대역폭은 문제되는 경우는 거의 없으며, 결과적으로 비용이 더 높은 네트워크에도 같은 성능 문제가 발생한다. 대역폭을 늘리는 대신에 네트워크 관리자는 트래픽을 분석하고 대역폭을 많이 사용하는 애플리케이션을 위해 네트워크를 최적화해야 한다.

장애 관리 툴에 대한 투자
서류상으로는 장애 관리(Fault Management)에 투자하는 것이 타당하다. 네트워크 장치, 서버, 보안 제품, 기타 인프라를 배치하고 장치들이 언제 동작하는지 알고 싶을 것이다.

하지만 실제로는 오늘날의 네트워크 구성은 불필요한 부분이 많아 장치 하나를 잃는다고 해서 애플리케이션 성능에 큰 영향을 끼치지는 않는다. 또한 대부분의 장애 관리 툴은 물리적인 인프라를 모니터링 하도록 개발됐기 때문에 가상 자원에 있어서 큰 맹점이 있다.

IT 부서들은 "너무 오랫동안 너무 잘못된" 것을 근절해 사용자를 걱정시키는 "브라운 아웃(Brown Out)" 문제를 해결해야 한다.

IT 부서의 총동원령, '일부'에만 집중
필자가 IT 책임자에게 새로운 계획을 거론할 때, 대부분은 상위 5개 또는 10개의 애플리케이션에 집중하는 것으로 보이며, 대부분의 직원이 사용하는 애플리케이션에 집중하는 것은 개념상으로 어느 정도 타당하다고 볼 수 있다.

하지만 IT 책임자는 모든 애플리케이션을 모니터링하고 사용량을 비즈니스적 결과와 결부시켜 최적의 사례를 구성해야 한다.

예를 들어, 지사의 성공은 링크드인(LinkedIn), 세일즈포스닷컴(Salesforce.com), 트위터(Twitter)을 잘 활용해 달성할 수도 있다. 전체적으로 이런 애플리케이션들은 상위 10개 애플리케이션이 아니며 그 사용량 또한 미미할 수 있다.

IT 부서가 애플리케이션을 모니터링하고 일관된 성공을 구체적인 사용 패턴에 결부시킬 수 있다면 알려지지 않은 최적의 사례를 발견하고 사용자 전체에 적용할 수 있을 것이다.

측정을 위한 MTTR을 위한 시간 할애
ZK 리서치(ZK Research)의 연구에 따르면 문제 해결에 있어서 몇 가지 흥미로운 점이 발견된다. 우선 문제의 75%는 실제로 IT 부서 대신에 최종 사용자가 규명하고 있다.

또한 문제 해결에 소요되는 시간의 90%는 실제로 문제를 찾는데 사용되고 있다. 이 때문에 필자는 애플리케이션과 네트워크를 분리해 정확한 문제를 찾아낼 수 있는 툴들을 선호한다.

이런 방법은 IT 팀 사이에서 문제를 서로 미루는 현상을 최소화해 IT가 더욱 신속하게 문제 해결을 시작할 수 있다. MTTR을 줄이고 싶다면 고치는 것보다는 규명하는 것에 집중해 시간을 적극적으로 활용하면 된다.

후행적 용량 관리
대부분의 조직은 사전에 서버, 스토리지, 네트워크 등의 용량을 늘리는 법이 없다. 오해하지 말기를 바란다.

대부분의 기업이 선제적으로 미리 준비하기 위해 노력한다는 것은 잘 알고 있다. 하지만 점층적인 가시성 없는 '선제적'은 문제의 최초 조짐에 대한 반응을 의미하는 경우가 많으며, 이미 때가 늦은 경우도 많다.

대신 IT 부서들은 기준선을 수립하고 애플리케이션이 정상적인 상태와 어떻게 달라지는지 모니터링 하는 방법을 파악해 문제가 발생하기 전에 예측해야 한다.

예를 들어, 기준선을 수립해 비즈니스용 애플리케이션의 '정상' 성능을 파악할 수 있다. 4개월 동안 매월 애플리케이션의 성능이 약간씩 저하될 수는 있다. 사용자들은 아무도 불평하고 있지 않지만 이런 추세는 분명하며, 아무런 조치도 취하지 않으면 언젠가는 사용자들이 문제를 겪게 될 것이다. 이를 기초로 IT는 인프라를 적절히 변경해 사용자들이 영향을 받지 않도록 할 수 있다.

더 많은 것들이 가상화, 클라우드화, 모바일화 되면서 IT 환경은 더욱 복잡해지고 있다. 이제는 IT가 네트워크를 운영하고 활용하는 방식을 새롭게 해 필요한 가시성을 제공함으로써 중요하지 않은 곳에 돈을 낭비하지 않으면서 필요한 문제에 초점을 맞출 수 있도록 해야 할 때다. editor@itworld.co.kr



2014.02.19

돈 낭비 IT 프로젝트 5가지

Zeus Kerravala | Network World
지난 5년 동안 기업에서는 다른 어떤 직위보다도 CIO의 역할이 크게 변모했다. 과거 CIO의 성공은 데이터에 달려있었지만 이제는 비즈니스적인 지표로 측정된다.

오늘날의 CIO는 IT를 더욱 전략적으로 고려하고 비용을 낮추거나 생산성을 향상시키거나 이 두 가지를 이상적으로 달성할 수 있는 프로젝트에 초점을 맞춰야 한다.

하지만 많은 IT 프로젝트들이 시간과 돈을 낭비하고 있다. 전 세계적인 추세는 아니지만 높은 가치가 있을 것같은 많은 IT 프로젝트들이 실제로는 그렇지 못하다. 그래서 여기 예산을 낭비하는 IT 프로젝트들을 모아보았다.

과도한 대역폭 제공 또는 추가
네트워크에 크게 의존하는 애플리케이션의 성능을 관리하는 것은 항상 쉬운 일이 아니다. 애플리케이션 성능이 떨어질 경우, 대역폭을 늘리기 십상이다. 합리적인 것처럼 보이기도 한다.

하지만 실제로 대역폭은 문제되는 경우는 거의 없으며, 결과적으로 비용이 더 높은 네트워크에도 같은 성능 문제가 발생한다. 대역폭을 늘리는 대신에 네트워크 관리자는 트래픽을 분석하고 대역폭을 많이 사용하는 애플리케이션을 위해 네트워크를 최적화해야 한다.

장애 관리 툴에 대한 투자
서류상으로는 장애 관리(Fault Management)에 투자하는 것이 타당하다. 네트워크 장치, 서버, 보안 제품, 기타 인프라를 배치하고 장치들이 언제 동작하는지 알고 싶을 것이다.

하지만 실제로는 오늘날의 네트워크 구성은 불필요한 부분이 많아 장치 하나를 잃는다고 해서 애플리케이션 성능에 큰 영향을 끼치지는 않는다. 또한 대부분의 장애 관리 툴은 물리적인 인프라를 모니터링 하도록 개발됐기 때문에 가상 자원에 있어서 큰 맹점이 있다.

IT 부서들은 "너무 오랫동안 너무 잘못된" 것을 근절해 사용자를 걱정시키는 "브라운 아웃(Brown Out)" 문제를 해결해야 한다.

IT 부서의 총동원령, '일부'에만 집중
필자가 IT 책임자에게 새로운 계획을 거론할 때, 대부분은 상위 5개 또는 10개의 애플리케이션에 집중하는 것으로 보이며, 대부분의 직원이 사용하는 애플리케이션에 집중하는 것은 개념상으로 어느 정도 타당하다고 볼 수 있다.

하지만 IT 책임자는 모든 애플리케이션을 모니터링하고 사용량을 비즈니스적 결과와 결부시켜 최적의 사례를 구성해야 한다.

예를 들어, 지사의 성공은 링크드인(LinkedIn), 세일즈포스닷컴(Salesforce.com), 트위터(Twitter)을 잘 활용해 달성할 수도 있다. 전체적으로 이런 애플리케이션들은 상위 10개 애플리케이션이 아니며 그 사용량 또한 미미할 수 있다.

IT 부서가 애플리케이션을 모니터링하고 일관된 성공을 구체적인 사용 패턴에 결부시킬 수 있다면 알려지지 않은 최적의 사례를 발견하고 사용자 전체에 적용할 수 있을 것이다.

측정을 위한 MTTR을 위한 시간 할애
ZK 리서치(ZK Research)의 연구에 따르면 문제 해결에 있어서 몇 가지 흥미로운 점이 발견된다. 우선 문제의 75%는 실제로 IT 부서 대신에 최종 사용자가 규명하고 있다.

또한 문제 해결에 소요되는 시간의 90%는 실제로 문제를 찾는데 사용되고 있다. 이 때문에 필자는 애플리케이션과 네트워크를 분리해 정확한 문제를 찾아낼 수 있는 툴들을 선호한다.

이런 방법은 IT 팀 사이에서 문제를 서로 미루는 현상을 최소화해 IT가 더욱 신속하게 문제 해결을 시작할 수 있다. MTTR을 줄이고 싶다면 고치는 것보다는 규명하는 것에 집중해 시간을 적극적으로 활용하면 된다.

후행적 용량 관리
대부분의 조직은 사전에 서버, 스토리지, 네트워크 등의 용량을 늘리는 법이 없다. 오해하지 말기를 바란다.

대부분의 기업이 선제적으로 미리 준비하기 위해 노력한다는 것은 잘 알고 있다. 하지만 점층적인 가시성 없는 '선제적'은 문제의 최초 조짐에 대한 반응을 의미하는 경우가 많으며, 이미 때가 늦은 경우도 많다.

대신 IT 부서들은 기준선을 수립하고 애플리케이션이 정상적인 상태와 어떻게 달라지는지 모니터링 하는 방법을 파악해 문제가 발생하기 전에 예측해야 한다.

예를 들어, 기준선을 수립해 비즈니스용 애플리케이션의 '정상' 성능을 파악할 수 있다. 4개월 동안 매월 애플리케이션의 성능이 약간씩 저하될 수는 있다. 사용자들은 아무도 불평하고 있지 않지만 이런 추세는 분명하며, 아무런 조치도 취하지 않으면 언젠가는 사용자들이 문제를 겪게 될 것이다. 이를 기초로 IT는 인프라를 적절히 변경해 사용자들이 영향을 받지 않도록 할 수 있다.

더 많은 것들이 가상화, 클라우드화, 모바일화 되면서 IT 환경은 더욱 복잡해지고 있다. 이제는 IT가 네트워크를 운영하고 활용하는 방식을 새롭게 해 필요한 가시성을 제공함으로써 중요하지 않은 곳에 돈을 낭비하지 않으면서 필요한 문제에 초점을 맞출 수 있도록 해야 할 때다. editor@itworld.co.kr

X