장애보고

#출처

 

engineering.linecorp.com/ko/blog/line-failure-reporting-and-follow-up-process-culture/

 

장애 처리 프로세스

장애 처리 프로세스는 상황에 따라 조금씩 차이가 있을 수 있지만 LINE 내 모든 서비스에서 기본적으로 사용할 수 있는 가이드를 마련해 놓았는데요. 장애 처리 프로세스는 다음과 같이 크게 5단계로 나눠 볼 수 있습니다. 

 

장애 탐지

장애는 모니터링 도구의 알람이나 관계 부서 혹은 사용자의 보고를 통해서 탐지하게 됩니다. 보통은 해당 서비스의 개발자나 운영 담당자가 모니터링 알람을 직접 받지만, 특별한 서비스의 경우에는 24시간 감시 팀이 있고 그들이 기본적으로 도구을 사용해 감시하다가 알람이 오면 장애 내용을 서비스 담당자에게 알려주기도 합니다. 장애가 발생하면 LINE 내 서비스 담당자들이 먼저 감지하는 경우가 대다수지만, LINE의 설정 화면 중에서 구석진 곳에 위치한 설정과 같이 사용자가 많이 사용하지 않는 기능이나, 발견하기 힘든 보안 이슈인 경우에는 외부의 보고를 통해서 뒤늦게 발견하는 경우도 있습니다. 

현재 운영하고 있는 장애 모니터링 도구로는 자동으로 메일을 발송해 주는 알람 시스템, 자동으로 메시지를 보내주는 감시 봇, 장애를 발견한 사내 임직원이 이를 알릴 수 있는 슬랙 채널, 외부에서 보고할 수 있도록 온라인에 준비해 놓은 LINE CS form 등이 있습니다. 

 

장애 전파

장애를 탐지하게 되면 장애가 발생한 원인을 파악함과 동시에 관련된 부서로 장애 내용을 전파합니다. 장애의 범위가 작은 경우에는 관련된 부서에만 전파하지만 장애의 범위가 크면(예를 들어 LINE 메시징 서비스가 불안정하다든지) LINE Works나 Slack 등 별도로 준비된 커뮤니케이션 채널을 통해서 장애 내용을 광범위한 대상에게 공유합니다. 

장애 전파는 장애 해결 못지 않게 상당히 중요합니다. 관련된 부서에서 당황하지 않고 같이 대응할 수 있고, 영향을 받는 회사들이 장애 내용을 전달받아 필요한 대응을 할 수 있기 때문에 항상 강조하고 있습니다. 그러나 실제로 장애에 부딪히면 자체적으로 해결해 보려고 애쓰느라 장애 대응 상황에 대한 전파가 잘 이루어지지 않는 경우가 종종 있습니다. 장애 전파만 잘 이루어져도 장애 해결에 대해 다른 부서의 도움을 받거나, 장애에 영향을 받는 쪽에서 준비된 대응을 실시해 장애의 영향 범위를 줄이는 효과를 얻을 수도 있기 때문에 해결 만큼이나 중요하게 생각해야 합니다.

좀 더 장애가 잘 전파될 수 있도록 개선하는 프로젝트도 있는데요. 예를 들어 봇 프로그램에 명령을 내리면 장애 범위에 따라서 전파될 부서와 커뮤니케이션 채널을 선택해서 적당히 준비된 메시지와 함께 전파해 주거나 장애 관리 웹 사이트에 자동으로 등록해 주는 것과 같은 일을 시도하는 프로젝트입니다.

 

장애 해결

장애 전파와 동시에 장애가 지속되거나 확산되는 것을 막기 위해 노력합니다. 이때 중요한 것 중에 하나가 장애를 전파하는 사람과 장애를 해결하는 사람이 가능하면 나누어져 있어야 한다는 것인데요. 장애의 원인을 파악하고 분석하는 작업과 장애를 전파하는 작업 모두를 한 사람이 하는 것이 꽤 힘들고 장애 지속 시간을 길어지게 만들기 때문입니다. 위에서도 언급했듯이 장애 전파도 장애 해결 못지않게 중요하기 때문에 이와 같이 가이드하고 있습니다.

다음은 장애를 빨리 해결하기 위해서 많이 사용하는 방법입니다.

• 롤백
  보통 장애가 지속되거나 또는 확산되는 것을 얼른 막기 위해 선택하는 방법이 롤백입니다. 이때 롤백 가능 여부를 빠르게 판단하는 것이 필요한데요. 이게 쉽지 않은 부분입니다. 릴리스된 내용에 데이터 스키마 변경이 포함되어 있는 경우는 롤백이 어렵거나 롤백 시 더 큰 문제를 초래하는 경우도 있을 수 있기 때문입니다. 시니어라고 해도 대규모 프로젝트에서는 모든 릴리스 내용을 파악하고 있기가 쉽지 않기 때문에 판단이 어렵습니다. 이런 경우를 대비해서 만약 롤백이 불가능하다고 생각되는 경우에는 PR(Pull Request)에 다음과 같은 라벨을 붙이도록 가이드하고 있습니다. 

• 서버 재기동
  특별히 배포가 없었는데 순간적으로 유입된 트래픽이 많거나, 코드에 성능 문제가 있어서 서버의 스레드나 네트워크 등의 리소스가 부족해져 동작할 수 없게 된 경우에 주로 사용하는 방법입니다. 임시방편이기 때문에 다시 비슷한 상황에 처하면 문제가 재발할 수 있습니다. 장비를 증설하거나 핫픽스를 준비하는 것이 좋습니다.
• 장비 증설
  트래픽이 예상보다 많이 유입된 경우에 필요한 대응책입니다. 이 방법은 사전에 장비 증설이 쉬운 구조를 만들어 놓지 않으면 안됩니다. 코드나 설정 파일을 수동으로 수정해서 배포해야 증설이 되도록 만들었다면, 증설하다가 다른 장애가 다시 발생하기도 하기 때문입니다. 미리 여분의 장비를 받아놓고 바로 투입 가능한 상태로 유지하면서, 증설이 필요한 경우 드래그 앤드 드롭 등의 간편한 방법으로 증설이 되도록 만들어 두는 것이 좋습니다. 최근에는 클라우드 서비스에서 제공하는 오토스케일링 기능을 사용하면 쉽게 자동 대응이 되기도 합니다. 
• 핫픽스 배포
  롤백이나 재기동으로 해결하기 쉽지 않아 문제를 수정한 버전을 배포하는 방법입니다. 롤백과 재기동이 쉽지 않은 클라이언트에서 문제가 발생했을 때 많이 사용하는 방법이며, 서버의 경우에도 롤백이 어렵다고 판단되거나 일시적인 장애라서 롤백까지는 필요 없는 경우에 이 방법을 사용합니다.

장애 대응을 하면서 매우 중요하다고 느꼈던 점 중 하나는 웹서비스가 아니라 Android나 iOS 앱과 같은 네이티브 앱을 개발할 때는 가능하면 서버에서 제어할 수 있도록 만드는 것이 좋다는 점입니다. 네이티브 앱은 배포하는 데에 상대적으로 시간이 오래 걸리기 때문에(특히 iOS는 리뷰를 거쳐야 배포가 가능하기 때문에) 문제가 되는 기능을 켜거나 끌 수 있도록 준비해두면 장애에 빨리 대응할 수 있습니다.

 

장애 보고

장애 대응이 어느 정도 완료되면 위키 페이지를 통해 제공하고 있는 장애 보고서 템플릿을 이용해서 장애 보고서를 작성합니다. 장애 보고서 작성을 위한 가이드 동영상도 제공하고 있어서 처음 해보는 사람도 쉽게 보고서를 생성할 수 있고, 그 동안 많은 장애 보고서 예제가 쌓여왔기 때문에 그것들을 참고하면 기본적인 내용은 쉽게 채워 넣을 수 있습니다. 

장애 보고서 템플릿의 내용은 대략 다음과 같습니다.

• 요약: 장애 상황에 대해 간략히 설명한다.
• 장애 탐지 시간: 장애가 최초 탐지된 시간을 명시한다.
• 영향받은 서비스: 장애에 영향받은 서비스를 명시한다.
• 장애 원인: 장애가 발생한 원인을 설명한다.
• 타임라인과 해결 과정: 장애가 최초 발생한 시점부터 주요 진행 과정을 순서대로 설명한다. 어떻게 대응했는지 자세한 설명을 덧붙인다.
• 해결 과정과 예방책: 장애를 어떻게 해결했는지, 어떤 예방 조치를 취해야 하는지 자세하게 설명한다. Jira 티켓 정보도 포함한다.
• 관련 문서 및 추가 정보(선택 사항): 필요하면 기타 정보를 추가한다.

장애 보고서를 작성하고 나면 1차로 이메일 공유를 합니다. 1차 이메일 발송은 가능하면 장애가 발생한 당일에 발송하는 것을 원칙으로 하고 있으며, 이때 공유해야 하는 부서는 서비스마다 다를 수 있습니다. 장애 등급은 크게 5단계로 나누어져 있고, 가이드 문서에 장애 등급에 따라 공유해야 하는 대상이 기술되어 있습니다.

그런데 초기 대응 때 장애 원인과 해결 과정, 예방책은 바로 채워 넣기가 어려울 수 있습니다. 원인을 분석하고 예방책을 만드는 것은 시간이 많이 드는 단계입니다. 때로는 원인 분석에만 몇 주가 걸리기도 하는데요. 사용하고 있는 기술의 깊은(core) 부분까지 유심히 들여다 봐야 되는 경우가 있기 때문입니다. 백엔드의 경우 Java의 GC(Garbage Collector), thread dump, memory heap dump를 깊게 파봐야 할 때도 있고, 프론트엔드는 JavaScript 엔진 코드를, 클라이언트는 Android나 iOS가 제공하는 여러 라이브러리의 코드를 직접 봐야 하는 경우도 있습니다. 이런 내용을 처음부터 파악해서 채워 넣기는 쉽지 않기 때문에, TBD(To Be Determined)로 남겨둔 채로 1차 이메일 공유를 해도 좋습니다.