장애를 해결하는 방법

  프로그램 개발이 끝났다고 모든것이 끝난게 아니다. 나는 그때부터 시작이라고 생각한다. 끝이없다. 사용자 요구사항은 항상 변한다. 예상치 못한 에러로 인해 장애가 발생하기도한다. 

  장애가 난 경우 미리 대처하면 너무나 좋겠지만, 개발자 또한 사람이기 때문에 실수 한다. 아니, 기계나 프로그램도 사람이 만들기 때문에 실수한다. 때문에 더 중요한 것은 장애가 난 경우 빠르게 대응하는게 더 중요하다.

  사실 장애는 빨리 해결될 수록 좋겠지만, 그러지 못한 경우도 있고 당장 수정하지 않아도 되는 경우도 있다.(물론 빨리 해결하자.)

장애 대응하기

• 알림, 사용자에게 보고 받기 보단, 레포팅 시스템을 구축하자.
• 프로그램 로그를 잘 찍었다고 치자. 로그를 계속 모니터링 하고 있을것인가? 아니다. 알림을 받자.
• 요즘은 Slack이라는 프로그램을 많이 쓴다. Slack은 API가 잘 구축되어 있기 때문에 모니터링 도구로도 많이 사용한다. 에러를 catch하는 경우 slack으로 알림을 보내자.
• 재연, 어떻게 대응할 것인가?
• 중요한게 있다. 그 장애(버그)를 재연해야한다.
• 재연하기 위해서 실제 서비스에 대고 재연할 것인가? 아니다. 위험하다. 때문에 로컬 환경이나 테스트 환경에서 발생한 장애를 빠르게 재연할 수 있는게 중요하다.
• 빠르게 재연이 가능하기 위해서는 환경 구성을 최대한 동일하게 가는게 좋다.
• 로컬환경, 테스트환경, 서비스환경에서 모두 다른 OS 모두 다른 환경 설정값들이라면 이런 설정들 때문에 발생한 장애는 재연하기 힘들다.
• 이 때문이라도 최대한 환경 설정을 동일하게 가는게 좋다.
• 이를 위해 Docker나 vagrant 등을 사용해 동일한 환경설정을 유지하는건 어떨까?
• 수정, 적용하자. 문제없이.
• 레포팅도 잘 받았고, 재연도 빠르게 했다. 장애를 수정하기 위해 코드도 수정했다.
• 그 다음은? 배포를 해야한다. 배포도 굉장히 중요하다.
• 요즘은 MSA가 유행인데 MSA 장점 중 하나로 꼭 나오는게 이 배포 문제다.
• 하나의 소스로 구성된 흔히 말하는 모놀리틱 아키텍처는 여러 개발자(또는 팀)가 하나의 소스를 수정하고 배포하기 때문에 소스가 겹치거나 배포 시기가 겹치는 문제가 생긴다.
• 손배포?
• 개발언어가 자바라고 예를 들어보자. Source.java 파일을 수정했다. Source.class 파일로 컴파일도했다. 배포하자.
• Source.class를 복사해서 서버에 붙여넣기. 성공?
• class 파일이 많아지면??
• 손배포는 엄청 문제가 많다.
• 컴파일도 일일이..
• 배포 파일도 일일이...
• 이러다가 문제가 생긴다. 클래스 파일을 하나 빼먹었다면? 또 다른 장애로 이어진다.
• 자동화하자. 제발
• jenkins 많이 쓰잖아 우리도 좀 쓰자.

URL

• Slack
• Docker
• Vagrant
• Jenkins

  개발자로써 내 개인적인 생각으로는 장애는 창피한게 아니다. 누구나 실수하기 때문이다. 더 중요한건 솔직하게 공유하고 문제를 해결하는 것이다. 어떤 조직이든 공유하는 문화는 굉장히 중요하다고 생각하는데, 장애가 난 경우 창피하다거나, 내가 빨리 아무도 모르게 해결하려다 보면 더 큰 문제로 이어질 수 있다. 한번 할 실수는 다시 안하도록 노력하면 되잖아.

난 맨날 실수한다.