1.1 가설기반 문제해결
성능 문제를 해결하기 위해서는 현상을 수집하고 그것을 기반으로 가설을 수립하며 이것을 검증하는 과정을 반복함으로써 해결될 수 있다.
해결해야 할 문제가 발생하면 먼저 현상/Fact를 수집한다. 각종 현상들 로그 기록들 혹은 테스트결과들은 모두 팩트로 정리될 수 있다. 팩트는 가능한 풍부하고 정확해야 문제 해결을 빠르게할 수 있다.
그 다음에는 수집된 팩트를 기반으로 가설을 수립한다. 의미 있는 가설 수립을 위해서는 튜너의경험과 지식이 요구된다. 가설을 최종적으로 해결해야 할 문제의 원인을 해결하거나 해결에 도움이 되어야 한다. 검증되어도 문제를 풀어가는데 도움이 않되는 가설은 검증할 필요가 없다.
주의)가설은 팩트가 아니다 즉 검증되기 전까지는 가설일 뿐이다. 만약 관리자나 고객에게 가설이 팩트 처럼 전달된다면 튜닝은 엉뚱한 방향으로 진행되거나 큰 위협에 빠질 수 있다. 즉 튜너는 문제해결 능력을 심각하게 의심받게 된다.
검증은 가설로부터 추정되는 이미 발생한 다른 현상을 찾아내거나 재현함으로써 가능하다. 검증은 문제 해결에서 가장 시간이 많이 소요되며 가설 수립과 마찬가지로 경험과 지식이 필요하다. 하나의 가설로부터 추정될 수 있는 현상들은 여러 가지일 수 있으며 이러한 현상을 많이 생각해 낼수록 검증 시간은 단축될 수 있다.
검증된 가설은 새로운 팩트로 편입된다. 가설이 FACT로 확정되면 이를 기반한 새로운 현상들도 유추될 수 있으며, 새로운 가설 수립을 위한 Input으로 활용된다.
이렇게 현상/팩트->가설->검증을 반복해 감으로써 최종적으로 문제의 근본원인을 찾아간다.
1.2 RR다이어그램
그런데 해결해야 할 문제가 한가지가 아닌 경우가 많고 포괄적인 경우에는 근본 원인 또한 한가지가 아니고 여러 가지가 존재할 수 있다. 이때는 모든 문제를 해결하였는지를 증명할 필요가발생하게 되는데 이때 사용하는 툴이 RR(Reason and Result)다이어그램이다 RR다이어그램은 원인과 결과의 주종관계를 도식화하는 것이다.
먼저 REASON과 RESULT은 증명된 가설에서 도출된다. 예를 들어 “IIOP 통신 때문에 CPU사용량이 높다”라면 “IIOP 통신”는 REASON이되고 “CPU 사용량이 높다” 라는 것은 RESULT가 된다.
검증된 가설들이 RR다이어그램으로 도식화되고 나면 그 다음에는 수집된 다른 현상들을 RR다이어그램에 추가하여 주종관계를 연결한다.
RR다이어그램에서 “결과 A” 처럼 어떠한 결과는 다른 결과를 유도하는 원인으로써 역할을 할수도 있다. 그래서 모든 현상들은 원인으로부터 유도되어야 한다.
그런데 “현상D”처럼 어떠한 REASON도 연결되지 않은 RESULT가 존재하는 경우가 있는데 그것은 아직 해결하지 못한 문제가 존재한다는 것을 의미한다. 더 많은 노력을 통해 “원인 Y”를 찾아야 한다.
RR다이어그램은 복잡한 문제의 현상과 결과들에 대한 상관관계들을 도식화 함으로써 이해당사자들이 문제의 원인과 결과를 쉽게 공유할 수 있게 한다.
