보안

MTTR이 소프트웨어 안정성 및 보안 측정에 적합하지 않은 이유와 대안

Michael Hill | CSO 2022.12.19
평균 해결 시간(Mean Time to Resolve, MTTR)은 복잡한 소프트웨어 시스템의 안정성 또는 보안을 측정하는 데 적절한 지표가 아니며, 더 신뢰할 수 있는 다른 방법으로 대체해야 한다는 주장이 제기됐다.

보안 업체 버리카(Verica)는 최근 발표한 연례 보고서 ‘버리카 오픈 인시던트 데이터베이스(Verica Open Incident Database: VOID)’에서 MTTR을 사용해 소프트웨어 네트워크 장애 및 중단을 측정하는 방법은 적절하지 않다고 말했다. 기간 데이터의 분포와 그런 시스템의 장애가 장기간에 걸쳐 균일하게 발생하지 않기 때문이다. 보고서 집필팀은 SRE(Site Reliability Engineering)팀이 MTTR을 주요 지표에서 없애고 SLO(Service Level Objective), 사고 후 데이터 검토를 비롯한 다른 전략을 모색해야 한다고 강조했다.
 
ⓒ Getty Images Bank


“MTTR 지표는 시스템 안정성을 보여주지 않는다”

버리카의 보고서 집필팀은 “MTTR은 제조 기업에서 장애가 발생한 물리적 구성요소 또는 장비를 수리하는 데 필요한 평균 시간을 측정하기 위해 처음 만들어졌다. 당시 장비는 지금보다 단순했고 예측할 수 있는 동작에 따라 마모가 발생했으므로 어느 정도 표준적이고 일관적인 MTTR 추정이 가능했다. 시간이 지나면서 MTTR이 소프트웨어 시스템으로 확장되면서 소프트웨어 업체는 이를 시스템 안정성과 팀 민첩성/효과를 알려주는 지표로 받아들였다”라고 설명했다.

버리카 연구원들은 MTTR이 복잡한 소프트웨어 시스템을 위한 적절한 지표가 아니라면서 “물리적 제조 장비 문제와는 달리 각 장애가 본질적으로 다르다. 현대 소프트웨어 시스템 운영자는 시스템 안정성을 개선하기 위해 지속적으로 투자하지만, 예상하지 못한 이례적인 장애에 직면한다”라고 말했다.

버리카 책임 연구원 코트니 내쉬는 CSO와의 인터뷰에서 “MTTR은 성격상 단순하게 요약할 수 없는 골치 아프고 급작스러운 상황들을 명확하고 구체적으로 이해하는 것처럼 보이게 해주므로 매력적이다. 그러나 MTTR의 기반 데이터는 변동성이 너무 커서 시스템 안정성의 척도로 사용하기에 적합하지 않다. 또한 사고는 관련된 사람과 팀의 수, 스트레스 수준, 해결하기 위해 필요한 기술 및 조직적 요소, 그 결과로 팀이 배운 것과 같은 여러 측면에서 사안마다 매우 다른데 MTTR은 이 부분에 대해서는 거의 알려주는 게 없다. 기술적 상황이 같더라도 사고에 대응하는 사람, 이들이 아는 것과 모르는 것, 이들의 위험 성향과 내부 압력에 따라 매우 다양한 양상으로 진행될 수 있다”라고 덧붙였다.

보고서 집필팀은 구글의 선임 사이트 신뢰성 엔지니어 스테판 다비도비치가 발표한 ‘SRE의 사고 지표: MTTR과 그 친구들에 대한 비판적인 평가(Incident Metrics in SRE: Critically Evaluating MTTR and Friends)’에 나온 연구 결과를 기반으로 MTTR 안정성을 테스트하기 위한 2가지 실험을 수행했다. 실험 결과, 샘플 크기(가령 총 사고 수)와 무관하게 사고 기간을 10% 줄여도 계산된 MTTR에서 안정적인 감소가 일어나지 않았다면서 “기간 데이터의 극심한 변동성이 MTTR의 변화 계산에 얼마나 큰 영향을 미치는지도 결과에서 볼 수 있다”라고 설명했다.


MTTR 지표의 대안

보고서는 애초부터 하나의 평균화된 수치는 복잡한 소프트웨어 시스템의 안정성을 측정하는 용도로 적절하지 않았다면서 “신뢰할 수 없는 MTTR이 어떤 지표를 제시하든 시스템에서 일어난 일을 제대로 파악하기 위해서는 사고를 조사해야 한다”라고 지적했다. 

MTTR을 대체하는 것은 어느 한 척도를 다른 것으로 바꾸는 간단한 과정이 아니라 사고방식의 변화다. 내쉬는 “초기 데브옵스가 기술 못지않게 문화의 변화에 중점을 둔 것과 마찬가지로, 데이터 기반의 의사 결정을 수용하고 사람들이 필요할 때 필요한 곳에서 변화를 실행할 역량을 부여하는 기업은 유용하지 않은 지표를 인식하고 적절히 대응할 수 있을 것”이라고 말했다.

버리카의 보고서는 MTTR 대신 고려할 만한 지표로 다음을 제시했다. 대부분은 사고 분석 기반의 지표다.
 
  • SLO/고객 피드백 : SLO는 사용자에게 충분한 서비스를 제공하고 이를 위해 필요한 안정성에 투자하겠다는 서비스 제공업체의 약속이다. SLO는 기술 시스템 지표를 비즈니스 목표와 정렬해서 안정성에 대한 더 유용한 프레임으로 만든다. 그러나 SLO 역시 과거만 본다는 점, 알려진 위험에 대한 정보를 포함하지 않는다는 점, 그리고 SLO에 영향을 미치지 않는 준사고(near miss)를 포착하지 않는다는 점을 포함하여 MTTR과 동일한 약점을 가질 수 있다.
  • 사회기술적 사고 데이터 : 보고서에 따르면, 현대의 복잡한 시스템은 사회기술적(Sociotechnical)이고 코드, 기계, 그리고 이를 만들고 유지하는 사람으로 구성된다. 그러나 팀은 기술적인 데이터만 수집해서 시스템을 파악하려는 경향이 있다. 하지만 “사회기술적 데이터의 대표적인 출처는 루라 맥과이어 박사가 연구한 조정 비용(Costs of Coordination) 개념이다.” 이런 데이터 유형에는 사고에 관여한 사람들의 수, 사용된 툴, 고유한 팀, 동시 이벤트가 포함된다. 보고서는 “이와 같은 종류의 데이터를 수집하기 전까지는 기업이 사고에 실질적으로 어떻게 대응하고 있는지 알 수 없다”라고 주장했다.
  • 사고 후 검토 데이터 : 기업에서 사고 분석의 효과를 평가하는 또 다른 방법은 사고 후 검토 정보의 참여, 공유, 보급 수준을 추적하는 것이다. 보고서에 따르면, 여기에는 사고 논평을 읽은 사람의 수, 사고 후 검토 회의에 자발적으로 참여한 사람의 수 등이 포함될 수 있다.
  • 준사고 : 버리카는 준사고와 실제 사고를 통해 배우는 것에 우선순위를 부여하는 것이 소프트웨어 업계의 또 다른 새로운 관행이라고 주장했다. 이어 “준사고에 집중하면 지식의 빈틈, 맞지 않는 심성 모형을 비롯한 조직 및 기술적 사각지대를 더 깊이 이해할 수 있다”라고 말했다. 그러나 어떤 경우가 준사고에 해당하는지 결정하는 것은 어렵다. 버리카가 제공한 예시 시나리오는 다음과 같다. “시스템 X가 다운됐지만 그 사이 시스템 Y가 캐시된 콘텐츠 또는 일반적인 콘텐츠를 제공한 덕분에 사용자들은 이를 인지하지 못했다. 이것은 사고인가? 백업이 실패하기 시작했지만 팀은 한달 동안 인지하지 못했고 고객 역시 알아차리지 못했다. 이것은 사고인가?”

내쉬는 “하루아침에 이뤄지는 변화는 아니다. 기여 요인과 해결책을 구상할 때 사람들의 역할에 대해 솔직해지는 것이 중요하다. 간단하게 들리지만 시간이 걸리는 과정이며, 이것이 더 나은 지표를 구축하는 구체적인 활동”이라고 덧붙였다.
editor@itworld.co.kr

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

발행인 : 박형미 | 편집인 : 박재곤 | 청소년보호책임자 : 한정규
| 사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.