실제 사용자와의 첫 접촉에서 살아남는 앱은 없습니다. 사람들이 사용하기 시작하면 오류가 발생합니다.
따라서 일단 프로덕션 단계에 들어가면 대부분의 앱은 오류를 추적하고 보고하는 방법을 갖게 됩니다. exception_notification을 사용하여 간단하게 진행하거나 Honeybadger 또는 Raygun과 같은 웹 앱을 사용할 수 있습니다.
그러나 곧, 똑같은 몇 가지 예외를 계속해서 보게 될 것입니다. 의존하는 웹 서비스가 완전히 안정적이지 않을 수 있습니다. 또는 사이트를 사용하는 사람들이 이메일을 잘못 입력하여 메시지가 전혀 전달되지 않습니다. 예외는 예외적이어야 하며 예상치 못한 것이어야 합니다. 하지만 하루에 30번씩 오류가 발생한다면 얼마나 예상치 못한 오류가 될까요?
보고하고 무시하는 것보다 이러한 문제를 해결하는 더 좋은 방법이 있습니다. 대부분의 시끄러운 예외는 몇 가지 기본 범주에 속합니다. 그리고 이러한 각 범주에 대해 패턴을 사용하여 노이즈를 줄이는 동시에 사용자를 더 행복하게 만들 수 있습니다.
네트워크가 다운되었습니다!
단독으로 작동하는 앱은 거의 없습니다. 대부분 다른 앱과 통신합니다. 그러나 Geolocation API가 다운되거나 ec2에 문제가 생기면 아무 것도 할 수 없는 수천 가지 예외가 스팸 메일을 받고 싶지 않습니다.
신뢰할 수 없는 서비스를 처리할 때 서킷 브레이커 패턴을 사용해 보세요. , Michael Nygard의 Release It:
<블록 인용>회로 차단기의 기본 아이디어는 매우 간단합니다. 오류를 모니터링하는 회로 차단기 개체에서 보호된 함수 호출을 래핑합니다. 장애가 특정 임계값에 도달하면 회로 차단기가 트립되고 회로 차단기에 대한 모든 추가 호출은 보호 호출이 전혀 이루어지지 않고 오류와 함께 반환됩니다.
따라서 서비스가 다운되면 연결 시도가 자동으로 중지됩니다. 해당 기능 없이 계속 진행합니다. 스스로 복구할 수도 있으므로 일정 시간이 지나면 앱이 자동으로 서비스를 다시 확인합니다.
회로 차단기 패턴은 계단식 오류를 방지하도록 설계되었지만 예외 알림을 제한하는 데 사용할 수도 있습니다. 이 패턴을 사용하면 트립이 발생하고 복구에 실패할 때만 알림을 받으면 됩니다. 수천 개의 예외를 몇 개로 바꿀 수 있습니다. 그래도 너무 많으면 차단기에 몇 번 연속으로 실패한 후에만 보고하도록 지시할 수 있습니다. (또는 더 안정적이고 다른 서비스를 찾아보세요!)
이 패턴을 사용하면 작업이 필요하지만 사용자에게 더 나은 경험을 제공하기도 합니다. 하드 오류 페이지 대신 이 기능이 현재 작동하지 않으며 나중에 다시 시도해야 한다는 메시지가 표시됩니다. 적시에 제공되는 더 나은 정보입니다.
gmaaaail.com이 의도한 것이 아님이 밝혀졌습니다.
내가 많이 본 또 다른 종류의 예외는 잘못된 사용자 데이터에서 비롯됩니다.
예를 들어, 누군가가 가입할 때 이메일을 오타했다고 가정해 보겠습니다. 그들은 "justinweiss@gmail.com"이라고 말했지만 "justinweiss@gmail.com"을 의미했습니다. 첫 번째는 이론적으로 유효한 이메일 주소일 수 있지만 보내는 모든 이메일은 반송됩니다. 그리고 이메일 제공업체에서 이러한 반송에 대한 알림을 받습니다.
이 알림은 소음일 뿐입니다.
대신 양면 접근 방식을 취하십시오. 잘못된 데이터를 미리 방지하고 기능을 비활성화하고 나중에 실패하면 사용자에게 알립니다.
이메일의 경우 새 사용자가 등록할 때 "gmail.com" 및 "yahoo.com"과 같은 맞춤법을 검사하기 위해 mailcheck-js gem을 사용했습니다.
{% img img-responsive /images/posts/email-spellcheck.gif 477 451 오, 멋지군요. %}
그런 다음 나중에 이메일이 계속 반송되면 해당 사용자에게 보내는 이메일을 끕니다.
누군가에 대해 기능을 끄면 해당 기능이 비활성화되어 있고 이를 수정하는 방법도 알려야 합니다. 사이트 상단의 배너는 일반적으로 좋은 답변입니다. "최근 몇 개의 이메일을 보낼 수 없어서 이메일 보내기를 해제했습니다. 이메일 주소를 업데이트하려면 여기를 클릭하세요. 그러면 바로 다시 켭니다.”
더 나은 데이터를 얻을 수 있으며 사용자의 이메일이 그냥 텅 비어 있는 것이 아닙니다. 당신이 방금 무시했던 오류보다 훨씬 낫습니다.
404 및 라우팅 오류
사이트의 깨진 링크나 자산에 대해 알고 싶을 것입니다. 하지만 그런 것들은 예외 추적기에 속하지 않습니다.
이러한 오류 및 기타 "반쯤 예상되는 오류"의 경우 일괄 처리하여 한 번에 처리하십시오. 발생 시 알림을 받을 필요가 없습니다. 밀기가 아니라 당기기를 원합니다.
RoutingErrors 및 404s와 같은 것은 Google 웹마스터 도구와 같은 것으로 처리할 수 있습니다. 이 도구는 404를 발생시키는 Google에 대해 Google이 알고 있는 페이지를 표시합니다. 또는 링크 검사기와 같은 것을 실행하여 시험판 프로세스의 일부로 사이트의 링크를 확인할 수 있습니다.
예외는 실행 가능해야 합니다.
예외 이메일을 받는 경우는 거의 없습니다. 오류 추적기에 노이즈가 너무 많으면 실제 문제를 즉시 확인하고 수정할 수 없습니다.
보이는 예외에 대해 당황하기보다 짜증이 난다면 소음 문제가 있는 것입니다. 여기에 있는 패턴을 사용하여 노이즈를 줄이고 사용자에게 동시에 더 나은 경험을 제공하세요.
나는 내가 가장 자주 본 몇 가지 시끄러운 예외 범주에 대해 이야기했습니다. 그러나 나는 그들 모두를 보지 못했다고 확신합니다. 앱에서 어떤 예외가 가장 짜증나나요? 이 범주 중 하나에 해당합니까, 아니면 새로운 범주를 정의합니까? 그들이 하루에 수백 번씩 당신을 괴롭히지 않도록 하려면 어떻게 해야 합니까?