장애는 고통스럽지만, 성장의 기회다
어느 회사, 어떤 서비스를 만들던 간에 장애가 없을 수는 없다.
장애가 없다는 말은 그만큼 서비스의 배포가 느리다는 의미이기도 하다.
(또는, 장애가 없다는 말은 그만큼 서비스의 사용자가 적다는 의미이기도 하다…)
엔지니어에게는 장애가 발생하면 Red Alert이지만서도, 거기서 배우는 것이 많다.
- 딥 다이브를 통해 서비스의 구조를 더 잘 이해할 수 있음
- 장애가 발생한 시점의 서비스의 상태를 더 잘 이해할 수 있음
- 어떤 곳이 취약한 지점인지 파악할 수 있음
- 다음 장애를 예방할 수 있는 방법을 생각해볼 수 있음
물론, 골치아픈 것은 사실이다…
이러한 장애를 통해 성장할 수 있는 기회를 잘 활용하면, 더 나은 엔지니어가 될 수 있다.
다만, 다양한 장애 상황은 다양한 대응 방법이 있다는 것을 의미하므로,
어떤 장애가 발생했을 때 어떻게 대응해야 하는지에 대한 기본적인 흐름을 만들어 두면 좋을 것 같다.
그리고 이런 장애 대응을 기록해두면 경험이 쌓여서
다음 장애가 발생했을 때, 더 빠르고 정확하게 대응할 수 있을 것이다.
아래는 장애가 발생했을 때, 어떻게 대응해야 하는지에 대한 기본적인 흐름이다.
(이 흐름은 내가 생각하는 흐름이므로, 다른 사람들은 다른 흐름을 가질 수 있다)
배포 후 발생한 장애를 대하는 방법
1. 배포 시점에 변경된 기능이 무엇인지 부터 살펴본다
- 배포 버전에 포함된 Commit 부터 살펴보기
- 배포 버전에 변경된 라이브러리 버전이 있는지 살펴보기
- 이 때, 문제를 분석하면서 해당 문제점과 연관된 라이브러리가 있는지 다시 생각해보기
- ex) 배포 후 Celery + SQS에서 SQS message 소모가 현저히 줄어든 것을 확인함
- 문제는 검색 키워드를 입력해도 위 내용이 찾아지지 않음. 그러므로 의존성 변경이 발생한 경우, 각 라이브러리 변경 점을 확인한 뒤, 직접 repository 들어가서 issue를 검색해보자
2. 배포 시점의 기능을 롤백한 후 다시 비교하면서 살펴본다
- 우선 발생한 장애를 빠르게 해결하는 것이 중요. 장애가 지속되고 유지될 경우, 고객에게 발생하는 피해가 누적됨을 의미
3. 다각도로 생각해본다
- 사용하는 라이브러리, 프레임워크의 설정 이슈인지 체크한다
- 작성한 로직의 성능 이슈가 있는지 체크한다
- 어떤 부분이 정상 / 비정상 상황에서 차이가 있었는지 살펴본다
- ex) SQS + Celery 부분에서 문제가 생긴 경우, SQS에서의 설정 이슈로 Producing이 느려진 것은 아닌지 체크, Celery의 Worker가 Consuming 하는 부분에서 느린 것은 아닌지 체크해야 한다
4. 여러 설정에 대한 Workaround test를 로컬 또는 테스트 환경에서 수행한다
- 안되면 운영 환경에서라도 사용량 적은 시간대에 적용해보는 방법도 있다
5. 동료 엔지니어들과 토의하면서 생각의 확장을 한다
- 서로가 잘 보는 부분이 확실히 있으므로, 포스트모템을 하면서 원인 파악과 문제 해결에 더 빠르고 정확하게 접근할 수 있다
- 내가 천재라서 혼자 다 할 수 있다? → 너무 오만한 생각
There is no silver bullet
항상 통용되는 해결 방법은 없다.
위 방법을 통해 장애를 해결할 수 있을 수도 있고,
그렇지 않을 수도 있다.
없어요. 있었으면 쐈음.
그러므로, 장애가 발생했을 때는 최대한 머리를 말랑말랑하게
급할 수록 여유를 갖고 생각의 전환을 하는 것이 필요하다.
ASAP은 맞지만, 멘탈만은 최대한 차분히.
그리고 동료들에게 도움을 요청하는 것도 중요하다.
나는 경험이 없을지언정, 동료들은 다른 경험에서 얻은 지식을 가지고 있을 수 있기 때문이다.
또한, 내가 생각하지 못한 부분을 동료가 생각해줄 수도 있기 때문이다.
장애가 발생했을 때는 동료들과 함께 토의하면서 해결 방법을 찾아보자.