중복 신고와 대규모 장애

티켓 목록에서 줄을 고르고 “Multiple report”를 누르십시오. 이 단추는 두 줄부터 쓸 수 있습니다.

창이 먼저 묻습니다. “Which ticket stays?” 가장 오래된 티켓이 미리 골라져 있습니다. 기한이 두 번째 시도가 아니라 요청자의 첫 접촉부터 흐르게 하기 위해서입니다. 다른 것을 골라도 됩니다.

그 아래에 두 번호와 함께 방향이 적혀 있습니다. “#11 will be closed and moved into #10.” 그래서 누르기 전에 어느 티켓이 남는지 분명합니다.

모두 함께 갑니다. 두 번째 신고의 댓글과 첨부 파일과 설명이 옮겨 갑니다. 설명은 원래 티켓의 댓글이 되며 원래 작성자와 날짜를 그대로 지닙니다. 창이 미리 개수를 알려 줍니다.

기록된 시간은 복사되지 않고 옮겨집니다. 그러지 않으면 같은 작업 시간이 티켓 두 개에 놓여 두 번 청구됩니다.

두 번째 신고는 지워지지 않습니다. 닫힌 뒤로는 원래 티켓을 가리키며 그 번호도 그대로 유효합니다.

요청자에게 따로 메일이 가지는 않습니다. 요청자는 원래 티켓에 있고 거기서 모두 봅니다. 닫힌 신고에는 원래 티켓을 알리는 댓글이 남아 있어 읽을 수 있습니다.

되돌리기는 없습니다. 그래서 “Merge”를 누르기 전에 모든 것이 창에 적혀 있습니다.

실행한 뒤에는 두 티켓의 이력에 누가 언제 무엇을 병합했는지 남습니다.

요청자의 메일함에는 예전 티켓 번호가 들어 있습니다. 신고 두 건이 병합되었다는 것은 모른 채 갖고 있는 메일에 답장합니다.

그 답장은 원래 티켓에 도착합니다. 시스템이 닫힌 신고가 지닌 표시를 따라갑니다.

그래서 병합된 신고를 결코 지우지 않습니다. 그것이 없으면 표시도 없고 답장은 아무 데도 도착하지 못합니다.

예전 신고에 참여했던 사람은 원래 티켓에도 쓸 수 있습니다. 확인은 메일이 가리키는 티켓에서 이루어집니다.

서로 다른 사람의 티켓을 고르면 창이 그것을 함께 가져가지 않습니다. 누르기 전에 제외된 줄과 그 이유를 하나씩 알려 줍니다.

이유는 이렇게 적혀 있습니다. “Different requester — this is an incident, not a multiple report.” 대신 어디로 가야 하는지도 함께 알려 줍니다.

이 기능 전체에서 가장 중요한 안전장치입니다. 서른 명이 낸 신고 서른 건을 병합하면 스물아홉 명이 자기 티켓을 잃고 다시는 아무 소식도 듣지 못합니다.

요청자가 누구인지는 먼저 티켓의 이메일 주소로 정해집니다. 주소가 없으면 “User” 칸에 적힌 외부 이름으로 정하며, 같은 이름은 같은 사람으로 칩니다. 그것도 아니면 티켓을 만든 계정이 요청자입니다.

그래서 전화 접수에도 이 안전장치가 적용됩니다. 담당자가 전화 두 통을 접수하면 두 티켓 모두 그 사람이 만든 것입니다. 그래도 전화한 사람이 다르면 다른 사람으로 남습니다. 이름이 칸에 들어 있기 때문입니다.

한쪽에서 요청자를 확인할 수 없어도 거부됩니다. 알 수 없다는 것은 같은 사람이라는 뜻이 아닙니다.

같은 상자에 다른 이유도 나옵니다. 대규모 장애 티켓은 병합할 수 없습니다. 닫힌 원래 티켓은 더 받지 않습니다. 그리고 이미 자기 신고를 거느린 신고는 함께 가지 않습니다. 그래야 사슬이 생기지 않습니다.

파일 서버가 멈추면 스무 명이 신고합니다. 이 신고는 저마다 자기 요청자를 가진 별개의 사안입니다. 여기서 병합은 잘못된 방법입니다. 열아홉 명이 자기 티켓을 잃기 때문입니다.

신고를 고르고 “Group into incident”를 누르십시오. 창이 세 가지 길을 보여 줍니다. 이미 열려 있는 대규모 장애 티켓에 붙이거나, 고른 티켓 하나를 대규모 장애 티켓으로 삼거나, 제목을 새로 붙여 대규모 장애 티켓을 만듭니다.

팀에 이미 열린 대규모 장애 티켓이 있으면 그 길이 미리 골라져 있습니다. 더 흔한 경우이기 때문입니다. 장애는 이미 알려져 있고 신고만 계속 들어오는 상황입니다.

연결된 티켓은 저마다 요청자와 상태와 자기 기한을 그대로 지닙니다. 사라지는 것은 없습니다. 대규모 장애 티켓은 답변만 묶습니다.

한 대규모 장애 티켓의 모든 신고는 같은 팀에 속해야 합니다. 장애가 두 팀에 걸치면 팀마다 자기 대규모 장애 티켓을 만듭니다. 그러지 않으면 한 팀이 해결했다고 다른 팀의 대기열이 비워집니다.

늦게 들어온 신고는 개별 티켓에서도 붙일 수 있습니다. 팀에 열린 대규모 장애 티켓이 있으면 위쪽에 안내가 나타나고 “Assign”과 “Not related” 단추가 함께 나옵니다. 시스템이 스스로 붙이는 일은 결코 없습니다. 잘못 붙은 티켓은 자기와 상관없는 해결 내용을 받고 그대로 닫혀 버리기 때문입니다.

대규모 장애 티켓에는 신고가 몇 건 붙어 있는지 적혀 있습니다. 연결된 티켓은 반대로 자기 대규모 장애 티켓의 번호를 목록과 오른쪽 카드에 달고 있습니다.

“Resolve incident”는 대규모 장애 티켓을 닫고 모든 신고에 한꺼번에 답합니다. 해결 내용은 필수입니다. 그것이 이 기능의 전부이며, 영향을 받은 모두에게 가기 때문입니다.

연결된 모든 티켓이 그 글을 공개 댓글로 받고 고른 상태로 바뀌며, 요청자마다 자기 앞으로 온 메일을 받습니다. 단체 메일은 보내지 않습니다. 그러면 영향을 받은 모두의 주소가 드러나기 때문입니다.

끝나면 티켓 몇 개가 닫혔고 요청자 몇 명에게 알렸는지 알려 줍니다. 두 숫자를 따로 적습니다. 닿을 수 있는 주소가 없는 티켓은 댓글과 상태는 받지만 메일은 받지 못하기 때문입니다.

그사이에 직접 답하고 닫은 티켓은 건드리지 않습니다. 두 번 닫히지도 않고 다시 쓰이지도 않습니다.

열린 신고가 붙어 있는 동안에는 보통의 상태 변경으로 대규모 장애 티켓을 닫을 수 없습니다. 그러지 않으면 스무 명이 조용히 답을 받지 못한 채 남습니다.

창과 대규모 장애 티켓 모두에 “Also show as a banner on the sign-in page” 선택 칸이 있습니다. 이것으로 사람들이 티켓을 하나 더 쓰기 전에 장애를 알게 됩니다.

배너는 로그인 화면에, 그리고 로그인한 뒤 시스템 안에 나타납니다. “Known incident”과 대규모 장애 티켓의 제목을 보여 주므로, 그 제목은 고객이 읽는 글입니다.

공지가 여러 개 켜져 있으면 위아래로 놓입니다. 토요일로 공지한 점검이 오늘의 장애를 밀어내지 않고, 그 반대도 마찬가지입니다.

그래도 누군가 새 티켓을 만들면 자동 회신이 그 대규모 장애를 알립니다. 이미 연결된 티켓에도, 그 팀의 모든 새 티켓에도 해당하며, 대규모 장애 티켓이 열려 있고 공지되어 있는 동안 그렇습니다. 이 기능에는 메일 발송이 필요합니다.

대규모 장애를 해결하면 배너는 저절로 사라집니다. 다시 끄는 것을 기억할 필요가 없습니다.

“Maintenance and incident notices” 페이지에서 지금 어떤 대규모 장애가 배너로 나가고 있는지 볼 수 있습니다. 그 페이지의 스위치는 계획된 점검에 속하며 대규모 장애에는 적용되지 않습니다.