가동시간은 잊어버리세요. 낮은 MTTR은 IT의 새로운 '5 9'입니다.

정전은 비용이 많이 듭니다. 그것이 궁극적으로 공격의 결과인지, 소프트웨어나 하드웨어의 오류인지는 그다지 중요하지 않습니다. 현대 디지털 경제의 API와 웹 앱에 대한 의존도가 높아짐에 따라 분당 다운타임 비용은 증가하고 있습니다.

어떤 사람들에게는 그 비용이 엄청날 수도 있습니다. Amazon은 2013년에 40분간의 다운타임으로 264만 달러의 손실을 본 것으로 추산됩니다 . 계산하기 싫은 사람들을 위해 말씀드리자면 , 초당 1,100달러입니다. 그것이 무섭다고 생각된다면 같은 해에 5분의 다운타임으로 인해 분당 109,000달러의 손실을 본 Google을 생각해보세요. (또는 초당 1,816.67달러) 총 545,000달러에 달합니다. 5분 동안. 기술적으로, 그게 그들이 겪은 전부라면, 그게 바로 IT가 달성해야 할 자랑스러운 "5 9"입니다.

정전은 얼마나 자주 발생합니까? 분명히 너무 자주 그런 것 같아요. 이걸 본 적이 없다면 pingdom의 실시간 서비스 중단 지도를 한번 보세요. 이는 70만 명이 넘는 글로벌 사용자로부터 수집한 데이터를 기반으로 구축되었습니다. 이 기괴하게도 흥미로운 지도는 지난 1시간 동안 전 세계에서 발생한 정전을 표시합니다. 정전을 나타내는 밝은 섬광은 멋진 표현이며, 사용자에게 큰 반향을 불러일으킵니다.

즉, 원치 않는 것을 의미합니다.

디지털 경제는 이런 문제를 더욱 악화시킨다. 올해 초 Amazon의 S3가 중단되어 많은 고객의 앱과 웹사이트가 다운되었습니다 . 하지만 이 문제를 퍼블릭 클라우드 제공업체의 탓으로 돌리지 말고, builtwith.com 사이트 를 잠깐 살펴보시면 그런 믿음은 금세 사라질 것입니다. 다른 사람의 가동 시간에 대한 종속성을 고려한다면 CDN과 API를 활용하는 사이트의 비율은 놀라울 정도로 높을 수 있습니다. 적어도 하나의 외부 API나 서비스에 의존 하지 않는 사이트를 찾는 것은 어렵고, 외부 서비스가 다운되면 회사도 다운되므로 다운타임 가능성이 커집니다.

기본적으로 IT는 100% 가용성을 달성하는 것이 불가능하기 때문에 "5 9"로 결정했습니다. 오늘날 경제가 디지털 영역으로 전환되면서 초당 비용이 엄청나게 급증함에 따라 가장 중요한 것은 다운타임을 최소화하는 것 입니다. 다시 말해, 평균 해결 시간(MTTR)이 짧은 목표를 설정하는 것은 가동 중지 시간을 없애려고 노력하는 것보다 마찬가지로 중요합니다. 어쩌면 더 중요할 수도 있습니다.

Puppet Labs의 2016년 DevOps 보고서 에서 "고성과 조직"의 주요 측정 기준 중 하나는 MTTR입니다. 이는 서비스 사고(예: 계획되지 않은 중단 또는 서비스 장애)가 발생했을 때 서비스를 복구하는 데 걸리는 시간으로 정의됩니다. 성과가 가장 높은 조직(보고서 평가 기준)은 1시간도 채 걸리지 않지만 , 중간 및 성과가 낮은 조직은 "하루도 채 걸리지 않습니다". 보고서는 "다시 말해" "고성과자는 저성과자보다 MTTR이 24배 더 빨랐다"고 언급합니다.

서비스 사고가 발생하는지 여부에 대한 질문이 아니라는 점에 유의하세요. 서비스 사고가 발생할 때입니다. 사고는 발생할 것이라는 가정이 있으므로, 해결 시간을 최소화하는 것이 핵심입니다. IHS가 2016년에 실시한 조사에 따르면 "평균적으로 조사 응답자는 매달 5회의 가동 중지 이벤트를 경험하고, 매달 27시간의 가동 중지로 인해" 중간 규모의 조직은 평균 1달러의 비용이 들고, 대규모 조직은 최대 6,000만 달러의 비용이 든다고 합니다.

Murphy의 법칙이 여전히 Moore와 Conway를 지배한다고 가정하면 답은 불가피한 가동 중지와 관련된 시간(및 비용)을 줄이기 위해 MTTR을 최소화하려는 것입니다.

즉, 가시성이 중요하고 모니터링이 필요하다는 뜻입니다. 감시가 정말 많고 많아요. 하지만 웹사이트나 웹앱, API뿐만 아니라 전체 스택을 모니터링 해야 합니다. 네트워크부터 앱 서비스, 그리고 애플리케이션 자체까지. 모든 사람이 다 하는 일은 아니며, 할 때도 일관성이 없는 듯합니다.

2017년 xMatters|Atlassian DevOps Maturity 설문 조사를 생각해 보세요. 이 설문 조사에서 응답자의 50%가 대응하기 전에 "운영 부서에서 주요 사고를 선언할 때까지 기다린다"고 밝혔습니다. 놀랍게도 1/3의 회사가 "고객으로부터 서비스 중단에 대해 알게 됩니다."

디지털 경제에서는 1초가 중요합니다. 비용이 들기 때문만 아니라 미래의 수익에 부정적인 영향을 미치기 때문이기도 합니다. 브랜드 가치와 고객 신뢰도가 떨어지면 구매와 사용자가 줄어들고, 결국 성장이 침체됩니다. 그것은 조직이 가야 할 방향이 아닙니다.

모니터링은 정전을 일으키는 문제를 감지하는 첫 번째 단계입니다. 하지만 모니터링만으로는 MTTR에 도움이 되지 않습니다. 의사소통이 그렇습니다. 관련 이해 관계자들에게 최대한 빨리 알리고, 문제 해결에 필요한 정보를 제공하면 문제 해결 시간을 단축하는 데 도움이 됩니다. 즉, DevOps의 4대 핵심 요소 중 하나인 공유가 MTTR을 개선하는 데 중요하다는 의미입니다. 아직 기업 수준에서 DevOps의 다른 측면을 받아들이지 않더라도 공유는 최상위 이니셔티브로 승격하는 것을 고려해야 합니다. ChatOps, 이메일, 모바일 앱, 동적으로 업데이트되는 위키 페이지를 통해 모니터링을 통해 수집한 정보를 조직 전체에 널리 공유하는 것이 필수적입니다.

스위치나 서버에서 문제가 발생하는 것은 무해해 보일 수 있지만, 방치하면 중요한 앱에 필요한 서비스의 절반이 중단될 수도 있습니다. Viavi가 실시한 2017년 네트워크 현황 연구에 따르면 , 네트워크 및 시스템 관리자의 65%가 애플리케이션 문제를 해결할 때 "문제가 네트워크, 시스템 또는 앱 중 어느 것에 의해 발생하는지 판별하는 것"을 가장 큰 과제로 꼽았습니다. 이러한 과제를 해결하는 한 가지 방법은 가시성을 높이고 풀스택 모니터링을 강화하는 것입니다. 이를 통해 근본 원인을 찾아내는 담당자가 데이터 경로에 있는 모든 구성 요소 의 상태와 상태에 대한 정보를 최대한 많이 얻을 수 있습니다.

가시성은 IT의 미래에 있어서 핵심입니다. 그렇지 않으면 정전이 발생하기 전에 이를 해결하는 데 필요한 수준의 자동화를 달성할 수 없습니다. 가시성이 없다면 MTTR을 의미 있게 줄일 수 없습니다. 이것이 없다면 우리는 지속 가능한 속도로 사업을 성장시킬 수 없습니다.

보안과 마찬가지로 가시성도 IT를 발전시키는 전략 스택에서 최우선 순위가 되어야 합니다. 중단은 발생할 수 있으며, 조직이 브랜드와 최종 이익에 최소한의 피해만 입히고 빠르고 효율적으로 복구할 수 있게 해주는 것은 가시성입니다.