모든 것은 궁극적으로 실패하게 된다.

 - Michael Nygard
 - 블로그 : http://www.michaelnygard.com/blog

Michael Nygard는 2008년에 Jolt 생산성 상을 탄 Release It! Design and Deploy Production-Ready Software (Pragmatic Bookshelf)를 썼다. 그의 다른 서적들은 http://www.michaelnygard.com/blog 에서 찾아볼 수 있다.









하드웨어는 오류가 잘 발생하기 때문에 보통 중복해서 설치합니다. 이는 개개의 하드웨어 실패를 견디도록 하게 하지만, 어떤 주어진 시간에 적어도 하나의 실패가 존재한다는 가능성을 증가시킵니다.

소프트웨어도 오류를 잘 발생합니다. 애플리케이션은 소프트웨어로 만들어졌으며, 따라서 실패에 취약합니다. 애플리케이션이 실패했을 때에 알려주는 모니터링을 설치하지만, 그러한 모니터링 역시 더 많은 소프트웨어로 이루어져 있으며, 따라서 오류에 취약합니다.

사람은 실수를 만들며 우리 역시 오류를 잘 발생시킵니다. 따라서 활동, 진단, 절차 등을 자동화시킵니다. 자동화는 위임에 대한 오류의 가능성을 없앨 수 있지만, 누락에 대한 오류의 가능성을 증가시킵니다. 어떠한 자동화된 시스템도 사람이 할 수 있는 동일한 범위의 상황에 대처할 수 없습니다.

따라서, 자동화에 대한 모니터링을 추가합니다. 소프트웨어가 점점 많아질수록 실패에 대한 가능성이 더 많아집니다.

네트워크는 하드웨어와 소프트웨어, 그리고 매우 긴 전선으로 만들어집니다. 따라서, 네트워크도 오류를 잘 발생합니다. 심지어 네트워크가 동작하더라도 모든 실용적인 목적으로 만들어진 거대한 네트워크의 상태 공간은 무한하기 때문에 예상할 수 없습니다. 개별 컴포넌트들은 정해진 방식으로 동작할 수 있지만, 여전히 근본적으로 혼란스런 행위를 만들어냅니다.

어떤 한 종류의 실패를 처리하기 위해 채택하는 모든 안전 체계는 새로운 실패 상태를 만들어냅니다. 애플리케이션을 실패한 서버에서 건강한 서버로 이동하기 위한 클러스터링 소프트웨어를 추가하지만, 이제 클러스터의 네트워크가 난조를 보이는 “분할 두뇌 증상” 이라는 위험에 직면해 있습니다.
스리마일 섬 사고 의 원인은 압력 경감 값에 의해 발생되었다는 것을 기억할 필요가 있습니다. – 안전 체계는 초과 압력 실패에 대한 특정 유형을 방지하기 위함이었습니다.

그렇다면, 시스템에서 실패 확률에 직면한 상태에서 실패에 대해 어떤 것을 할 수 있을까요?

무엇이건 간에 시스템은 다양한 실패 상태를 가질 수 있다는 것을 받아들여야 합니다. 그러한 불가피성을 부인한다면, 실패를 통제하고 끌어안을 수 있는 능력을 상실하게 됩니다. 일단 실패가 발생한다는 것을 받아들이면, 특정 실패에 대한 시스템의 반응을 설계할 수 있는 능력이 생깁니다. 자동차 설계자가 범퍼 – 처음에 실패함으로써 승객을 보호하도록 고안된 영역 - 를 고안했듯이 피해를 끌어안고 나머지 시스템을 보호하는 안전 실패 상태를 만들 수 있습니다.

만일 실패 상태를 설계하지 않는다면, 어떠한 예상치 못한 것이 – 보통은 위험한 – 발생할 수 있다는 사실을 알게 됩니다.


원문 : 모든 아키텍트가 알아야 하는 97가지 사실 - Everything will ultimately fail