운영·4 분
장애 리뷰 전에 읽어야 할 네 쪽짜리 글
쿡이 쓴 건 의료 현장 이야기입니다. 그런데 프로덕션 시스템을 운영해본 사람이라면 18개 항목을 전부 곧바로 알아봅니다.
출처
How Complex Systems Fail
Richard I. Cook, MD · Cognitive Technologies Laboratory, University of Chicago · 1998
원문 읽기이 자료의 저자는 AslanWay가 아닙니다. 아래 요약은 원문 내용을 정리한 것이고, 이어지는 해설은 저희 의견이며 저자의 동의를 받은 것이 아닙니다.
이 자료의 주장
환자 안전을 연구하던 의사 리처드 쿡이 복잡계가 어떻게 실패하는지를 18개의 짧은 관찰로 정리했습니다. 네 쪽짜리 글인데, 한 번 읽어보면 왜 소프트웨어 운영 분야의 필독 문서가 되었는지 바로 이해됩니다.
관찰들은 서로 맞물립니다. 복잡계는 본질적으로 위험하고, 그래서 두텁게 방어됩니다. 그 방어가 작동하기 때문에 대형 사고는 여러 실패가 동시에 겹쳐야 일어납니다. 단일 지점 고장만으로는 부족합니다. 그리고 모든 복잡계는 언제나 여러 개의 잠재 결함을 안은 채로, 그럼에도 잘 돌아갑니다.
근본 원인 분석이 오해를 부르는 이유
쿡은 실패에 분리 가능한 단일 원인이란 없다고 말합니다. 방어를 뚫으려면 여러 요인이 함께 작용해야 하기 때문입니다. 근본 원인을 하나 지목하는 것은 '어디서 그만 볼지'를 정하는 결정이고, 대개 사회적으로 편한 지점에서 멈춥니다.
사후 편향이 리뷰를 왜곡한다는 지적도 합니다. 결과를 알고 나면 그것을 가리키던 신호가 명백해 보이고, 그 신호를 다른 수많은 신호 사이에서 놓친 운영자는 태만해 보입니다.
저희는 이걸 이렇게 씁니다
- 리뷰의 질문을 '무엇이 잘못됐나'에서 '그때는 왜 이게 합리적으로 보였나'로 바꿔보십시오. 훨씬 쓸모 있는 답이 나오고, 방어적인 답은 줄어듭니다.
- 운영자가 안전을 상시로 '만들어내고 있다'는 쿡의 지적은, 온콜을 간접비로 취급하면 안 되는 이유입니다. 시스템이 대개 버텨주는 건 변동성을 흡수하는 사람들이 있기 때문입니다.
- 피크가 끝난 뒤가 아니라 피크 전에 장애를 리허설하는 이유가 여기 있습니다. 한 번도 작동시켜본 적 없는 방어는 방어가 아니라 가정입니다.