<사이트 신뢰성 엔지니어링> - 2부 요약

본문 중에서...

Chapter 6. 분산 시스템 모니터링

알럿 호출 방식 철학

• 매번 호출기가 울릴 때마다 긴급한 상황임을 인지하고 그에 대응할 수 있어야 한다. 이러한 긴급 호출은 빈번한 호출로 인한 피로를 느끼지 않도록 하루에 단 몇번 정도만 발생해야 한다.
• 모든 호출은 대응이 가능해야한다.
• 호출은 새로운 문제나 지금까지 보지 못한 사건에 대한 것이어야 한다.
• 호출에 대한 모든 대응은 이성적이어야 한다. 

장기적 모니터링

장애 호출에 대해 이미 정해진 규칙에 의해 대응하는 것은 위험 신호다. 팀의 그 누구도 이런 호출에 대해 자동화를 할 의지가 없다는 것은 팀이 스스로 만든 기술 부채를 해소할 자신이 없다는 것을 암시한다.

한 걸음 더 나아가기

순수한 노력의 힘은 너덜너덜한 시스템을 고가용성을 갖춘 시스템으로 바꿔놓기도 하지만, 이런 방법은 단기간에 걸쳐 진행되고 피로가 쌓이기 쉬우며 팀원 중 몇몇 유능한 사람들에게 의존하게 되는 경향이 있다. 

중요한 것은 개별 장애 호출을 각기 다른 상황으로 보지 않고, 전체적인 장애 호출 수준이 좋은 방향으로 나아가고 있는지, 적절하게 활용이 가능한 시스템인지 팀과 장기적 전망에 보탬이 되는지 여부에 대해 생각해보는 것이다. 

Chapter 9. 모듈화 

돌발적인 복잡성을 최소화하기 위한 시각에서 SRE팀은 다음을 준수해야한다.

• 책임지고 있는 시스템에 있는 돌발적인 복잡성을 야기하는 요소는 과감히 밀쳐낸다.
• 자신이 담당하고 운영 책임을 지고 있는 시스템의 복잡도를 제거하기 위해 노력한다.

내 코드는 절대 포기하지 않을 거야!

엔지니어 역시 사람이고, 자신의 창조물에 감정을 이입하는 경향이 있다. 그래서 소스를 정리하는 거에 대한 반감을 갖는 것은 놀라운 일이 아니다.

"이 코드가 나중에 필요하면 어쩌려고?", "나중에 필요할 때 쉽게 돌릴 수 있도록 주석처리하는건 어때?", "지우지 말고 플래그만 달아두는건 어때? 같은 항의가 있기도 하다. 전부 다 헛소리다. 소스 제어 시스템으로 코드를 되돌릴 수 있기 때문에, 수백줄의 코드가 주석처리되어있는건 코드를 산만하게 만들고 혼란만 가중시킬 뿐이다. 그리고 전혀 실행된 적이 없는 코드나 항상 비활성화 플러그가 설정되어 있는 코드는 마치 시한 폭탄 같은 것이다.

최소한의 API

프랑스 시인 앙투안 드 생텍쥐페리는 "완벽함이란 더 이상 추가할 것이 없을 때가 아니라 더 이상 걷어낼 것이 없을 때 비로소 완성된다"라고 했다. 소비자에게 제공하는 API의 메서드와 매개변수를 줄이면, API는 이해하기 쉬워지고, 그 API를 최대한 잘 만드는 데 더 많은 노력을 들일 수 있다. 그러면 핵심 문제에 집중하고, 훨씬 나은 해결책을 모색할 수 있다.