Joinc Wiki: 인터넷 서비스 품질향상을 위한 고찰

Facebook Joinc 그룹 Joinc QA 사이트

현재위치 : 미니사이트>QOS>Service>Service_Management_HowTo

joinc는 Firefox와 chrome에서 테스트 했습니다. IE에서는 테이블이 깨지거나 이미지가 보이지 않을 수 있습니다. 특히 구글 Docs이미지의 경우 엑박처리될 수 있습니다.

인터넷이 대중화 되고, 다루어야할 데이터의 양이 늘어나게 되자, 인터넷 서비스 역시 구조적으로 복잡해지게 되었다. 단일 서버에서 몇개의 어플리케이션을 조합한 다음, 서비스를 하는 가내수공업식 웹 서비스를 보는건 매우 어려운일이 되었다. 예컨데, 조그마한 웹서비스라고 하더라도, 몇대의 Web front ends와 몇대의 Data Storage가 분리되어서 구성이 된다.

몇개의 서버와 네트워크 장비들로 인터넷 서비스가 구성되면서, 서비스 품질에 영향을 끼치는 요소들도 늘어나게 된다. 단일 서버에 APM만으로 운영되는 웹서비스라면, 품질에 영향을 미치는 요소를 비교적 정확하게 정의하고, 이들을 집중적으로 관리할 수 있었다. 문제점도 빨리 찾을 수 있었으며, 해결역시 비교적 수월했다. 최악의 경우 시스템을 리붓시키는 정도로 문제를 해결할 수 있다. 리붓한다고 해봤자. 10분 정도 시간이 걸릴까.

하지만 안타깝게도, 지금은 더 많은 부분들에 대해서 신경을 써야 한다. 시스템의 규모가 커짐에 따라 서비스 애플리케이션도 덩달아 복잡해진다. 예컨데, 예전에는 APM으로 서비스 했던게, 이제는 Ruby On Rails 와 같은 프레임워크와 WAS를 활용하는 쪽으로 진화를 했다. 당연히 신경써야 할 것들도 늘어날 수 밖에 없다. 여기에 로드밸런싱이 제대로 이루어지는지 확인해야 하며, 내/외부 네트워크 상황도 확인해야 한다. 더 많은 시스템에 대한 자원들을 주시해야 하고, 각 변화가 서비스에 어떠한 영향을 미치는지에 대한 보고서도 작성해야 한다.

여기에서는 인터넷 서비스의 품질향상을 위해 필요한 행위들에 대해서 알아볼 것이다.

일반적인 인터넷 서비스 아키텍처에서의 품질

다음은 쉽게 구성해서 사용할 수 있는 서비스 아키텍쳐다.

인터넷 서비스 아키텍쳐 1

서비스 관문인 switch 밑에, Web Front ends 서버가 놓이고, 그 밑에 데이터를 저장하는 Storage Server가 놓이는 매우 일반적인 구성이다. switch는 Load balancing 의 기능을 하게 될 것이다. 서비스 도메인 별로 데이터가 놓이는 포털 서비스나 하나의 Global Data Storage 에서 데이터를 읽어오고 이를 서비스하는 플랫폼기반의 서비스의 경우, 이보다 복잡한 형태를 띄겠지만 큰 규모에서의 구성은 비슷할 것이라 생각된다.

Component failure 와 Service failure

우선 failure 의 변화에 대해서 생각해보도록 하자. 기존의 단일 서버 & 단일 서비스환경에서는 Component failure 가 곧 Service failure 였다. 서비스의 소프트웨어적인 구성요소인 APM중 하나에 문제가 생겼다면, 이것은 Service failure로 직결이 된다. 하드웨어 문제도 마찬가지일 것이다.

그러나 지금의 인터넷 아키텍쳐에서는 Component failure가 Service failure로 직결되지 않는다. Web Front ends 서버중 하나가 죽는다고 하더라도, 서비스에는 문제가 없도록 구성이 되기 때문이다. Data Storage 서비스 역시 마찬가지다. Data 플랫폼 형식으로 구성이 되고 replication(복제)가 되어 있는 경우가 대부분이므로, 하나의 서버에 문제가 생긴다고 하더라도 서비스문제로 확대되지는 않는다.

그러나 Component failure는 Service failure를 발생시킬 확률을 높이며, 쌓일 수록 확률이 높아지기 때문에, 문제가 확대되기 전에 Component failure 를 인지하고 문제를 해결할 수 있어야 한다. 또한 Service failure에 직접적인 원인을 제공하는 Component failure에 대해서는 특별히 관리할 수 있어야 할 것이다.

이러한 활동을 하는 이유는 물론 서비스의 품질을 높이기 위함인데, 최종적으로는 TTD 와 TTR 을 낮은 수준에서 유지하기 위함이다.

Reduce Time to Detection

줄여서 TTD라고 불리운다. 문제가 생기는걸 감지하는데 걸리는 시간을 의미한다. 당연하지만 시간을 최소화 하는게 중요하다.

TTD는 component failure 와 Service failure 에 약간은 다르게 적용될 것이다. Service failure 의 경우에는 아무래도 Component failure 보다 TTD를 더 보수적으로 잡을 필요가 있을 것이기 때문이다.

우선 문제를 Detection하는 시스템을 구축하는게 우선일 것이다. 문제의 Detection은 SNMP, ICMP, 기타 Agent 방식의 각종 측정툴들을 이용한다. 이들 정보는 일정시간을 간격으로 수집되게 되고, 임계치를 초과 했을 경우 문제를, Event 를 발생시키게 된다. 이들 수집서버의 주기적 수집 특성으로 polling server 라고 부르기도 한다.

SNMP, ICMP를 통한 데이터 수집은 해당 프로토콜을 지원하는 툴을 사용하면 되겠지만, 기타 정보의 수집은 Target Host에 Agent를 설치하고 RPC나 SSH를 이용해서 실행하고 결과를 수집하는 방식을 사용해야 할 것이다. 이러한 시스템을 만드는건 간단한 일이 아니다. 직접 만드는 것보다는 zenoss, zabbix와 같은 잘 만들어진 시스템을 도입하는 걸 고려해봄직 하다.

Time to Repair

줄여서 TTR이라고 부르기도 한다. 문제를 해결하는데 걸리는 시간을 의미한다. 역시 시간을 짧게 하는게 중요할 것이다. TTR을 줄이는 것은 경험과 경험의 축적이 중요한 요소가 될 것이다. 이를 위해서는 이력관리 시스템, 문제추적 시스템등이 구축이 되어야 할 것이다.

개인적으로 TTD와 TTR을 줄이기 위해서 zenoss와 wiki를 사용했다. zenoss를 이용해서 RAW 데이터 - 측정 데이터 및 Event -를 수집하고, Event가 발생하면 이를 wiki로 전송해서 trac 형식으로 관리하는 방식이다. 데이터 공유를 위한 key는 Event ID로 하면 될것이다. zenoss에서 Event ID로 Event를 발생하면, Event ID를 이름으로 하는 wiki 페이지를 생성하는 식이다.

Event의 처리는 trac와 비슷하게 Ticket을 발행/처리 형식으로 했다. 이렇게 하면, 이벤트의 생성에서 추적까지를 history로 남길 수 있으며, 문제가 발생했을 때 - 대부분 발생했던 문제가 다시 발생한다 - 더 빠르게, 원인을 파악해서 해결하고 대책을 수립할 수 있을 것이다.

wiki를 활용할 경우 또다른 장점을 가질 수 있는데, macro를 이용해서 쉽게 기능을 확장시킬 수 있다는 점이다. 예를들어보자. QOS 시스템에서는 보고서는 매우 중요하다. 이 보고서에는 이벤트 보고서 뿐만 아니라, 각 시스템과 서비스의 품질 보고서까지를 포함한다.

zenoss는 RRD에 데이터를 저장하는데, RRD 데이터를 읽어와서 그래프를 만들어주는 간단한 macro를 만들어서 쉽게 품질 보고서를 작성하게 만들었다. 이 보고서는 그 자체가 모니터링 툴이 되기도 한다. 위키페이지 특유의 확장성을 이용해서, 측정, 보고서, 이벤트를 모두 보여주는 Dash 보드를 구현할 수 있을 것이다. 아래는 현재 구축해서 사용하는 wiki Dash board중 일부분으로 수집된 성능 정보를 보여주는 부분만을 캡춰했다.

응답시간

서비스 응답시간의 측정은 위에 언급된 툴들을 이용하면 얻어낼 수 있을 것이다. 그러나 응답시간을 분석해서 단축시키는 것은 쉬운일이 아닐 것이다. 여기에는 인터넷 서비스를 위한 플랫폼 아키텍쳐에서부터의 고민이 필요하다.

웹서비스의 일반적인 구성은 인터넷 서비스 아키텍쳐 1을 따를 것이다. 이 방식은 무난하기는 하지만 잘못된 요청을 구분할 수 없으므로, 잘못된 요청의 처리에 따른 자원낭비가 심해질 수 있다는 문제가 생길 수 있다.

이러한 문제가 발생하는지 확인하기 위해서, 잘못된 요청의 통계정보를 유지할 필요가 있다. 이 정보는 각 서비스의 로그를 수집하는 방식으로 유지할 수 있을 것이다. 만약 잘못된 요청이 많아서 이에 따른 자원낭비가 발생한다면, 인터넷 서비스 아키텍쳐의 변경을 고려해 봐야 할 것이다.

고려할 수 있는 아키텍쳐로 Qurum아키텍쳐가 있다. 이것은 서버군 앞에 Qurum 시스템을 두어서 요청을 분석 후, 잘못된 요청은 Drop 시키는 방식으로 이루어진다. 또한 Load Control 도 할 수 있을 것이다. 단점은 아키텍쳐 1에 비해서 복잡하다는 점이다.

Quorum 아키텍쳐

Qurum 아키텍쳐는 은 아키텍쳐 1에서 Switch와 Metadata Service Server 중간에 Qurum 시스템을 둠으로써 구성할 수 있을 것이다.

문제를 줄이는 방법들

서비스문제를 없애는 것은 불가능 하다. 그러나 가능한 회피할 수 있는 방법이 있을 것이다. 혹은 발생한 문제가 서비스에 충격을 주기전에 해결하는 방법을 찾을 수 있을 것이다.

각 컴포넌트의 약점을 숨길 수 있는 디자인
컴포넌트의 문제가 다른 컴포넌트의 문제로 전이되지 않는 구조
컴포넌트의 문제가 유저서비스에 직접적인 영향을 끼치지 않는 구조
TTD 를 단축하는 시스템의 구축
TTR 을 단축하는 시스템의 구축

아래는 컴포넌트의 문제가 생겨서 해결될때까지의 과정 즉, 문제발생, 문제의 인지, 문제의 진단, 해결이 되기까지를 보여주고 있다.

시스템은 정상운영상태에서 시작한다. 운용도중 소프트웨어버그, 하드웨어의 문제등으로 컴포넌트 fault가 발생한다. 하지만 모든 컴포넌트 fault가 QOS에 심각한 영향을 미치는건 아니다. 예를 들어 웹서비스가 플랫폼기반이고, 플랫폼이 replication을 고려해서 설계되었다면, 플랫폼을 이루는 시스템자체가 작동되지 않는 상황이더라도, 서비스 자체의 품질이 떨어지지는 않을 것이다.

해서 컴포넌트 문제는 심각한 문제와 그렇지 않은 문제로 나눌 수 있을 것이다. 이들 발생된 문제는 Event 형태로 발생이 되고, Event 대기열에 들어가서 시스템관리자의 진단을 기다리게 된다. 시스템관리자는 문제를 진단한후 해결방법을 찾아서, 문제를 해결하게 된다.

QOS는 두가지 방향으로 진행될 것이다. 문제가 발생하지 않도록 디자인 하는 것과 위의 사이클의 거리를 줄이는것 프로세스를 구축하는 (TTD, TTR을 단축하는)것이다.

정확성테스트

컴포넌트들이 배치되기 전에, 올바로 작동을 하는지 충분한 테스트를 거쳐야 한다. 가능하면 실제 운용환경과 비슷한 구조로 테트 환경을 구축하고 이 위에서 테스트가 이루어질 수 있도록 해야 할 것이다.
stress 테스트

네트워크 혹은 프로그램을 이용해서, 서비스 프로세스를 반복적으로 수행하도록 한다. 이러한 테스트는 특히 메모리 누수, CPU 독점과 같은 장시간 서비스에서 발생할 수 있는 컴포넌트 failure를 미리 경험할 수 있게 해준다.
fault injection and load testing
configuration checking
proactive restart

하드웨어 혹은 컴포넌트 소프트웨어의 restarting 테스트를 수행한다. 소프트웨어의 리스타는 장시간 서비스시 발생할 수 있는 메모리 누수, CPU 독점, 사소한 실수의 누적에 의한 중대한 문제의 예방을 위한 좋은 방법이다. 원할한 restarting는 TTR을 줄여준다.
모니터링 테스트

아마도 당신은 나름대로의 모니터링 환경을 구축하고 있을 것이다. 컴포넌트의 문제들이 제대로 모니터링 되는지 테스트하도록 한다. 이것은 TTD와 TTR을 줄여준다.

모니터링 시스템

TTD와 TTR을 단축시키기 위한 핵심 시스템이다. 이에 대한 내용은 wiki와 zenoss를 이용한 모니터링 시스템 구축문서를 참고하기 바란다.

뇌자극 QA 뇌자극 에러 및 수정목록 총 페이지 수 : 3224 전체 함수/용어사전 구글검색방법 구글 맞춤검색	Facebook Joinc 그룹 Joinc QA 사이트 현재위치 : 미니사이트>QOS>Service>Service_Management_HowTo Tweet joinc는 Firefox와 chrome에서 테스트 했습니다. IE에서는 테이블이 깨지거나 이미지가 보이지 않을 수 있습니다. 특히 구글 Docs이미지의 경우 엑박처리될 수 있습니다. Replace original file Rename if it already exist 인터넷이 대중화 되고, 다루어야할 데이터의 양이 늘어나게 되자, 인터넷 서비스 역시 구조적으로 복잡해지게 되었다. 단일 서버에서 몇개의 어플리케이션을 조합한 다음, 서비스를 하는 가내수공업식 웹 서비스를 보는건 매우 어려운일이 되었다. 예컨데, 조그마한 웹서비스라고 하더라도, 몇대의 Web front ends와 몇대의 Data Storage가 분리되어서 구성이 된다. 몇개의 서버와 네트워크 장비들로 인터넷 서비스가 구성되면서, 서비스 품질에 영향을 끼치는 요소들도 늘어나게 된다. 단일 서버에 APM만으로 운영되는 웹서비스라면, 품질에 영향을 미치는 요소를 비교적 정확하게 정의하고, 이들을 집중적으로 관리할 수 있었다. 문제점도 빨리 찾을 수 있었으며, 해결역시 비교적 수월했다. 최악의 경우 시스템을 리붓시키는 정도로 문제를 해결할 수 있다. 리붓한다고 해봤자. 10분 정도 시간이 걸릴까. 하지만 안타깝게도, 지금은 더 많은 부분들에 대해서 신경을 써야 한다. 시스템의 규모가 커짐에 따라 서비스 애플리케이션도 덩달아 복잡해진다. 예컨데, 예전에는 APM으로 서비스 했던게, 이제는 Ruby On Rails 와 같은 프레임워크와 WAS를 활용하는 쪽으로 진화를 했다. 당연히 신경써야 할 것들도 늘어날 수 밖에 없다. 여기에 로드밸런싱이 제대로 이루어지는지 확인해야 하며, 내/외부 네트워크 상황도 확인해야 한다. 더 많은 시스템에 대한 자원들을 주시해야 하고, 각 변화가 서비스에 어떠한 영향을 미치는지에 대한 보고서도 작성해야 한다. 여기에서는 인터넷 서비스의 품질향상을 위해 필요한 행위들에 대해서 알아볼 것이다. 일반적인 인터넷 서비스 아키텍처에서의 품질 다음은 쉽게 구성해서 사용할 수 있는 서비스 아키텍쳐다. 인터넷 서비스 아키텍쳐 1 서비스 관문인 switch 밑에, Web Front ends 서버가 놓이고, 그 밑에 데이터를 저장하는 Storage Server가 놓이는 매우 일반적인 구성이다. switch는 Load balancing 의 기능을 하게 될 것이다. 서비스 도메인 별로 데이터가 놓이는 포털 서비스나 하나의 Global Data Storage 에서 데이터를 읽어오고 이를 서비스하는 플랫폼기반의 서비스의 경우, 이보다 복잡한 형태를 띄겠지만 큰 규모에서의 구성은 비슷할 것이라 생각된다. Component failure 와 Service failure 우선 failure 의 변화에 대해서 생각해보도록 하자. 기존의 단일 서버 & 단일 서비스환경에서는 Component failure 가 곧 Service failure 였다. 서비스의 소프트웨어적인 구성요소인 APM중 하나에 문제가 생겼다면, 이것은 Service failure로 직결이 된다. 하드웨어 문제도 마찬가지일 것이다. 그러나 지금의 인터넷 아키텍쳐에서는 Component failure가 Service failure로 직결되지 않는다. Web Front ends 서버중 하나가 죽는다고 하더라도, 서비스에는 문제가 없도록 구성이 되기 때문이다. Data Storage 서비스 역시 마찬가지다. Data 플랫폼 형식으로 구성이 되고 replication(복제)가 되어 있는 경우가 대부분이므로, 하나의 서버에 문제가 생긴다고 하더라도 서비스문제로 확대되지는 않는다. 그러나 Component failure는 Service failure를 발생시킬 확률을 높이며, 쌓일 수록 확률이 높아지기 때문에, 문제가 확대되기 전에 Component failure 를 인지하고 문제를 해결할 수 있어야 한다. 또한 Service failure에 직접적인 원인을 제공하는 Component failure에 대해서는 특별히 관리할 수 있어야 할 것이다. 이러한 활동을 하는 이유는 물론 서비스의 품질을 높이기 위함인데, 최종적으로는 TTD 와 TTR 을 낮은 수준에서 유지하기 위함이다. Reduce Time to Detection 줄여서 TTD라고 불리운다. 문제가 생기는걸 감지하는데 걸리는 시간을 의미한다. 당연하지만 시간을 최소화 하는게 중요하다. TTD는 component failure 와 Service failure 에 약간은 다르게 적용될 것이다. Service failure 의 경우에는 아무래도 Component failure 보다 TTD를 더 보수적으로 잡을 필요가 있을 것이기 때문이다. 우선 문제를 Detection하는 시스템을 구축하는게 우선일 것이다. 문제의 Detection은 SNMP, ICMP, 기타 Agent 방식의 각종 측정툴들을 이용한다. 이들 정보는 일정시간을 간격으로 수집되게 되고, 임계치를 초과 했을 경우 문제를, Event 를 발생시키게 된다. 이들 수집서버의 주기적 수집 특성으로 polling server 라고 부르기도 한다. SNMP, ICMP를 통한 데이터 수집은 해당 프로토콜을 지원하는 툴을 사용하면 되겠지만, 기타 정보의 수집은 Target Host에 Agent를 설치하고 RPC나 SSH를 이용해서 실행하고 결과를 수집하는 방식을 사용해야 할 것이다. 이러한 시스템을 만드는건 간단한 일이 아니다. 직접 만드는 것보다는 zenoss, zabbix와 같은 잘 만들어진 시스템을 도입하는 걸 고려해봄직 하다. Time to Repair 줄여서 TTR이라고 부르기도 한다. 문제를 해결하는데 걸리는 시간을 의미한다. 역시 시간을 짧게 하는게 중요할 것이다. TTR을 줄이는 것은 경험과 경험의 축적이 중요한 요소가 될 것이다. 이를 위해서는 이력관리 시스템, 문제추적 시스템등이 구축이 되어야 할 것이다. 개인적으로 TTD와 TTR을 줄이기 위해서 zenoss와 wiki를 사용했다. zenoss를 이용해서 RAW 데이터 - 측정 데이터 및 Event -를 수집하고, Event가 발생하면 이를 wiki로 전송해서 trac 형식으로 관리하는 방식이다. 데이터 공유를 위한 key는 Event ID로 하면 될것이다. zenoss에서 Event ID로 Event를 발생하면, Event ID를 이름으로 하는 wiki 페이지를 생성하는 식이다. Event의 처리는 trac와 비슷하게 Ticket을 발행/처리 형식으로 했다. 이렇게 하면, 이벤트의 생성에서 추적까지를 history로 남길 수 있으며, 문제가 발생했을 때 - 대부분 발생했던 문제가 다시 발생한다 - 더 빠르게, 원인을 파악해서 해결하고 대책을 수립할 수 있을 것이다. wiki를 활용할 경우 또다른 장점을 가질 수 있는데, macro를 이용해서 쉽게 기능을 확장시킬 수 있다는 점이다. 예를들어보자. QOS 시스템에서는 보고서는 매우 중요하다. 이 보고서에는 이벤트 보고서 뿐만 아니라, 각 시스템과 서비스의 품질 보고서까지를 포함한다. zenoss는 RRD에 데이터를 저장하는데, RRD 데이터를 읽어와서 그래프를 만들어주는 간단한 macro를 만들어서 쉽게 품질 보고서를 작성하게 만들었다. 이 보고서는 그 자체가 모니터링 툴이 되기도 한다. 위키페이지 특유의 확장성을 이용해서, 측정, 보고서, 이벤트를 모두 보여주는 Dash 보드를 구현할 수 있을 것이다. 아래는 현재 구축해서 사용하는 wiki Dash board중 일부분으로 수집된 성능 정보를 보여주는 부분만을 캡춰했다. 응답시간 서비스 응답시간의 측정은 위에 언급된 툴들을 이용하면 얻어낼 수 있을 것이다. 그러나 응답시간을 분석해서 단축시키는 것은 쉬운일이 아닐 것이다. 여기에는 인터넷 서비스를 위한 플랫폼 아키텍쳐에서부터의 고민이 필요하다. 웹서비스의 일반적인 구성은 인터넷 서비스 아키텍쳐 1을 따를 것이다. 이 방식은 무난하기는 하지만 잘못된 요청을 구분할 수 없으므로, 잘못된 요청의 처리에 따른 자원낭비가 심해질 수 있다는 문제가 생길 수 있다. 이러한 문제가 발생하는지 확인하기 위해서, 잘못된 요청의 통계정보를 유지할 필요가 있다. 이 정보는 각 서비스의 로그를 수집하는 방식으로 유지할 수 있을 것이다. 만약 잘못된 요청이 많아서 이에 따른 자원낭비가 발생한다면, 인터넷 서비스 아키텍쳐의 변경을 고려해 봐야 할 것이다. 고려할 수 있는 아키텍쳐로 Qurum아키텍쳐가 있다. 이것은 서버군 앞에 Qurum 시스템을 두어서 요청을 분석 후, 잘못된 요청은 Drop 시키는 방식으로 이루어진다. 또한 Load Control 도 할 수 있을 것이다. 단점은 아키텍쳐 1에 비해서 복잡하다는 점이다. Quorum 아키텍쳐 Qurum 아키텍쳐는 은 아키텍쳐 1에서 Switch와 Metadata Service Server 중간에 Qurum 시스템을 둠으로써 구성할 수 있을 것이다. 문제를 줄이는 방법들 서비스문제를 없애는 것은 불가능 하다. 그러나 가능한 회피할 수 있는 방법이 있을 것이다. 혹은 발생한 문제가 서비스에 충격을 주기전에 해결하는 방법을 찾을 수 있을 것이다. 각 컴포넌트의 약점을 숨길 수 있는 디자인 컴포넌트의 문제가 다른 컴포넌트의 문제로 전이되지 않는 구조 컴포넌트의 문제가 유저서비스에 직접적인 영향을 끼치지 않는 구조 TTD 를 단축하는 시스템의 구축 TTR 을 단축하는 시스템의 구축 아래는 컴포넌트의 문제가 생겨서 해결될때까지의 과정 즉, 문제발생, 문제의 인지, 문제의 진단, 해결이 되기까지를 보여주고 있다. 시스템은 정상운영상태에서 시작한다. 운용도중 소프트웨어버그, 하드웨어의 문제등으로 컴포넌트 fault가 발생한다. 하지만 모든 컴포넌트 fault가 QOS에 심각한 영향을 미치는건 아니다. 예를 들어 웹서비스가 플랫폼기반이고, 플랫폼이 replication을 고려해서 설계되었다면, 플랫폼을 이루는 시스템자체가 작동되지 않는 상황이더라도, 서비스 자체의 품질이 떨어지지는 않을 것이다. 해서 컴포넌트 문제는 심각한 문제와 그렇지 않은 문제로 나눌 수 있을 것이다. 이들 발생된 문제는 Event 형태로 발생이 되고, Event 대기열에 들어가서 시스템관리자의 진단을 기다리게 된다. 시스템관리자는 문제를 진단한후 해결방법을 찾아서, 문제를 해결하게 된다. QOS는 두가지 방향으로 진행될 것이다. 문제가 발생하지 않도록 디자인 하는 것과 위의 사이클의 거리를 줄이는것 프로세스를 구축하는 (TTD, TTR을 단축하는)것이다. 정확성테스트 컴포넌트들이 배치되기 전에, 올바로 작동을 하는지 충분한 테스트를 거쳐야 한다. 가능하면 실제 운용환경과 비슷한 구조로 테트 환경을 구축하고 이 위에서 테스트가 이루어질 수 있도록 해야 할 것이다. stress 테스트 네트워크 혹은 프로그램을 이용해서, 서비스 프로세스를 반복적으로 수행하도록 한다. 이러한 테스트는 특히 메모리 누수, CPU 독점과 같은 장시간 서비스에서 발생할 수 있는 컴포넌트 failure를 미리 경험할 수 있게 해준다. fault injection and load testing configuration checking proactive restart 하드웨어 혹은 컴포넌트 소프트웨어의 restarting 테스트를 수행한다. 소프트웨어의 리스타는 장시간 서비스시 발생할 수 있는 메모리 누수, CPU 독점, 사소한 실수의 누적에 의한 중대한 문제의 예방을 위한 좋은 방법이다. 원할한 restarting는 TTR을 줄여준다. 모니터링 테스트 아마도 당신은 나름대로의 모니터링 환경을 구축하고 있을 것이다. 컴포넌트의 문제들이 제대로 모니터링 되는지 테스트하도록 한다. 이것은 TTD와 TTR을 줄여준다. 모니터링 시스템 TTD와 TTR을 단축시키기 위한 핵심 시스템이다. 이에 대한 내용은 wiki와 zenoss를 이용한 모니터링 시스템 구축문서를 참고하기 바란다.