1. 재현 방법을 찾아라
•
문제가 발생했을 때, 해당 특정 상황을 재현할 수 있어야 한다. 문제의 답을 내렸다하더라도 그 상황을 재현하지 못한다면 완전히 해결했다고 볼 수 없다.
•
새로운 문제를 해결할 땐, 테스트 케이스를 충분하게 도출하여야 해당 문제를 올바르게 문제를 해결한 코드를 작성할 수 있다.
•
문제를 재현하는 과정의 비용을 낮춰야 한다. 즉 테스트 범위를 좁혀 작은 범위에서 테스트가 가능하게 해야 한다. 범위가 커지는 경우, 테스트 비용이 많이 든다.
2. 문제를 풀기 위한 기술
•
문제를 해결하기 위한 방법을 선택하는 것보다 문제를 정의하는 것이 먼저가 되어야 한다. 소잡는 칼로 닭잡지 말라는 뜻이다.
•
기술을 선택함에 있어서도 맹목적인 끌림을 너무 신봉해서도 안 된다. 새로운 것이 좋은 것이 아니라 적합한 것이 좋은 것이다.
•
우리가 던져야 할 중요한 질문은 “어떤 기술로 문제를 풀었는가?”가 아니라 “이 문제를 풀기 위해서는 어떤 기술이 필요한가?”이다.
3. 서비스 상태에 대한 직감
•
소프트웨어를 배포했다고 끝이 아니다. 자원 사용량과 로그를 살펴보면서 문제가 없는지, 점진적으로 개선시켜나갈 부분을 찾아 개선시킬 수 있어야 한다.
•
소프트웨어를 모니터링하면서 메모리가 더 필요한지, 디스크가 부족하지는 않은지, 오류 로그는 없는지, 자원 분배는 잘 되고 있는지 등을 끊임없이 직감적으로 간파하고 지속해서 개선해나가야 한다.
4. 문제를 외면하지 마라
•
문제가 발생했을 때, 이를 외면하지 마라, 문제해결에 적극적인 태도를 보이자. 문제를 빠르게 해결하는 개발자일수록 문제를 만들어내지 않은 개발자에 가까워질 수 있다.
•
문제를 해결할 때, 도움을 청해야 한다면 역지사지의 마음으로 도움을 청하자. 상대가 도움을 주고싶게끔 충분히 맥락을 제공해서 도움을 받자.
5. 고장률 제로라는 목표의 함정
•
고장률 제로가 아닌 다음 세가지를 서비스의 목표로 삼는 것을 추천한다.
◦
신속한 장애 감지 - 사용자가 알기 전 또는 거의 동시에 능동적으로 고장을 알아차릴 수 있는지
◦
수준 높은 장애의 극복 - 사용자에게 고장에 대한 적절한 피드백을 주고 빠른 시간 안에 문제를 특정하여 수정할 수 있었는지
◦
동일한 유형의 장애가 재발하지 않는 것 - 이전에 발생했던 장애가 다시 발생했는 지 여부
•
이와 같은 목표가 설정된다면 개발자들은 좀 더 빠르게 고장을 감지하기 위한 여러 가지 장치를 하게 될 것이고, 좀 더 수준 높게 고장을 극복할 수 있도록 시스템을 개선해 나갈 것이다.
