Ch13. 긴급 대응

이번 장에서는 긴급 대응이 필요했던 몇 가지 사례를 소개하고 있다.

 

1. 사례 1 -  사전 테스트

구글은 재난과 긴급 상황에 대한 사전적 테스트 접근법을 취하고 있다. SRE들은 시스템에 장애를 일으킨 후 이로 인해 시스템이 어떻게 실패하는지를 지켜본 다음, 그 현상이 반복해서 발생하지 않도록 신뢰성을 향상시킬 수 있는 변경 사항을 적용한다.

 

대부분의 경우 장애는 계획에 따라 제어가 가능하며 대상 시스템과 그에 의존하는 시스템들은 대체로 예상했던 대로 동작한다. 하지만 예상과 실제 결과가 어긋날 때가 있다.

 

사전 테스트에 포함되지 않은 내용으로 인해 테스트 수행 시 장애가 발생한 경우를 생각해보자. 장애가 발생한 이유가 무엇일까? 아마도 실제 환경에 존재하는 다양한 의존 관계에 대해서 고려하지 못했기 때문일 것이다.

 

이를 해결하기 위해서는 사전 테스트를 꼼꼼하게 작성하는 것도 좋지만 롤백 절차를 완벽하게 테스트하는 것도 좋은 방법이라고 생각한다.

 

2. 사례 2 - 설정 변경

구글의 특정 인프라스트럭처의 설정을 변경/적용했다고 가정해보자. 이 인프라스트럭처는 기본적으로 외부로 노출되는 모든 서비스들과 함께 동작하는 것이고, 변경된 설정은 이런 시스템들에게서 크래시 루프(crash-loop)를 유발했다.

 

구글은 어마어마한 수의 설정을 관리하고 있으며 설정 변경으로 인한 서비스 장애를 원천적으로 차단하기 위해, 변경된 설정으로 인해 뭔가 예상하지 못한 결과나 동작이 발생하지 않음을 확인하기 위한 많은 테스트를 수행하고 있다고 한다. 그렇다면 위 장애는 왜 발생한 것일까?

 

결론적으로 말하자면 위에서 변경한 설정은 그다지 위험하지 않은 것으로 판단하고 느슨하게 카나리 테스트를 수행했기 때문에 발생하였다. 실제로 장애가 발생한 케이스는 카나리 테스트에서 테스트되지 않은 케이스였다. 다음 분기부터 카나리 테스트와 자동화의 개선에 더 높은 우선순위를 두며 전체적으로 테스트 시스템을 개선했다고 한다.

 

3. 장애에 대한 기록을 남기자

무언가를 배우는 데 있어 과거에 있었던 일을 문서로 남기는 것보다 나은 방법은 없다. 기록은 다른 누군가의 실수를 바탕으로 학습을 하는 것이다. 광범위하고 솔직하게 작성하되, 무엇보다 중요한 것은 화두를 던져야 한다는 점이다. 전술적인 면뿐만 아니라 전략적으로도 같은 장애가 다시 재발하지 않도록 하기 위한 실행 요소를 찾아야 한다. 그리고 이 문서를 발행하고 포스트모텀을 진행함으로써 사내의 모든 사람들이 장애를 통해 학습한 내용을 함께 공유할 수 있도록 해야 한다.

 

4. 결론

11~13장에서는 장애를 조치하는 사람은 침착해야하고 필요하다면 다른 사람들에게 도움을 요청할 수 있어야 한다는 내용을 강조한다. 당연한 내용이지만 정말 중요한 내용이라고 생각한다. 

 

그리고 이전에 발생한 장애를 연구하고 이로부터 새로운 것을 학습하는 자세돋 중요하다고 생각한다. 장애는 비슷하지만 조금씩 다른 경우가 많은 것 같다. 따라서 이전에 발생한 장애를 연구하면 새로운 장애도 빠르게 대처가 가능하다고 생각한다.

 

마지막으로 가장 중요한 것은 문서화이다. 이를 통해 장애가 발생했을 때 더 나은 방법으로 장애를 조치하고 시스템을 더욱 견고하게 만들 수 있다고 생각한다.

 

장애를 두려워하지 말고 이를 통해 성장하도록 하자 !