IT Support Done Right: A Practical Field Guide

대부분의 IT 지원 업무는 속도로 평가받지만, 방법이 없는 속도는 같은 문제를 다른 곳으로 옮길 뿐입니다. 5분 만에 종료했다가 3일 후 다시 열리는 티켓이 실제로 해결되기까지 20분이 걸리는 티켓보다 비용이 더 많이 듭니다. 이 가이드는 티켓을 종료하는 사람과 문제를 해결하는 사람을 구분하는 습관을 다룹니다.

추측이 아닌 실제 인테이크부터 시작하세요

머신에 손을 대기 전에 사용자에게 자신의 말로 문제를 설명하도록 한 다음, 세 가지 추가 질문을 하세요: 언제 시작되었는지, 최근에 변경된 것이 무엇인지, 매번 발생하는지 아니면 간헐적인지. "인터넷이 느립니다"는 DNS 해석 문제, 포화된 Wi-Fi 채널, 손상된 NIC, 또는 탭 40개가 열려 있는 브라우저를 의미할 수 있습니다. 정확한 오류 메시지 텍스트가 있으면 기록하세요. 스크린샷은 설명보다 항상 낫습니다 — 사용자에게 무엇이든 시도해 달라고 요청하기 전에 먼저 스크린샷을 요청하세요.

"재시작을 시도해 봤나요"로 바로 건너뛰는 충동을 참으세요. 자주 작동하기 때문에 사람들이 기본값으로 설정하지만, 인테이크를 건너뛰면 패턴을 놓칩니다. 같은 스위치의 3명이 같은 시간에 같은 느림을 보고하면, 그것은 나쁜 드라이버가 있는 한 대의 노트북과는 다른 티켓입니다.

수정하기 전에 재현하세요

문제를 재현할 수 없으면 수정했다는 것을 확인할 수 없습니다. 사용자에게 화면 공유에서 정확한 단계를 걷도록 요청하거나, 원격 도구가 허용하면 자신의 머신에서 직접 수행하세요. Windows에서 ipconfig /all을 확인하거나 Linux에서 ip a를 확인하여 기본 네트워크 정상 여부를 확인하고, Event Viewer(eventvwr.msc)에서 보고된 시간 주변의 애플리케이션 및 시스템 오류를 살피고, Linux 박스에서 journalctl -xe --since "1 hour ago"를 확인하여 같은 시간대를 확인하세요.

애플리케이션 충돌의 경우 정확한 빌드 번호와 OS 버전을 가져오세요. "충돌했습니다"는 아무것도 알려주지 않습니다. "Outlook 16.0.17726이 .ics 첨부 파일이 있는 일정 초대를 열 때 충돌합니다"는 어디를 봐야 할지 알려줍니다. 로컬 문제라고 가정하기 전에 공급업체 릴리스 노트의 알려진 문제와 비교하세요.

가장 큰 소리를 내는 사람이 아닌 영향으로 분류하세요

한 명의 사용자가 이메일에서 잠긴 것은 불편합니다. 40명이 공유 파일 서버에 도달할 수 없는 것은 중단입니다. 간단한 심각도 척도를 세우세요 — P1은 여러 사용자나 중요한 시스템에 영향을 주는 중단, P2는 단일 사용자 차단기, P3는 기능하지만 성능 저하, P4는 화면 또는 편의 요청 같은 것 — 매니저가 자신의 것을 먼저 원할 때의 압박감을 받더라도 일관되게 적용하세요.

심각도 결정을 티켓 자체에 기록하세요. 이것은 나중에 누군가가 P3가 2일 동안 앉아 있는데 3개의 P1을 처리한 이유를 물을 때 당신을 보호합니다.

증상이 아닌 근본 원인을 해결하세요

계속 충돌하는 서비스를 다시 시작하는 것은 시간을 버는 것이지 해결책이 아닙니다. 인쇄 스풀러가 매일 중단되면, 다시 시작하기 전에 Get-WinEvent -LogName Application -MaxEvents 50에서 실제 오류를 확인하세요. 사용자의 암호가 예기치 않게 계속 만료되면, 그냥 리셋하고 넘어가는 것보다 OU에 적용된 그룹 정책을 확인하세요.

반복되는 수정에 대한 개인 로그를 유지하세요. 같은 PowerShell 명령이나 같은 레지스트리 수정을 3번 입력하는 것을 발견하면, 그것은 당신의 머릿속에 있지 않고 스크립트나 문서화된 runbook에 있어야 한다는 신호입니다.

다른 사람이 읽을 것처럼 문서화하세요

모든 티켓 해결은 다음을 답해야 합니다: 실제 원인이 무엇이었는지, 수정이 무엇이었는지, 이것이 다시 발생하면 먼저 무엇을 확인할 것인지. "해결됨"이 해결 노트는 다음 기술자에게, 6개월 후 이 티켓에 대한 기억이 없는 미래의 당신에게 무가치합니다.

좋은 해결 노트는 다음과 같습니다: "근본 원인: VLAN 20의 DHCP 범위 고갈, 새 장치가 APIPA 주소를 받음. 수정: 범위를 /24에서 /23으로 확장, 프린터에 대한 예약 추가. 검증: 매월 DHCP 리스 개수 확인, 90%에서 경고 임계값 설정." 세 번째 문장은 대부분의 기술자가 건너뛰는 것이고, 반복 티켓을 방지하는 것입니다.

단순 전달이 아닌 맥락과 함께 에스컬레이션하세요

티켓이 2계층이나 공급업체로 갈 때, 이미 배제한 것을 포함하세요. "케이블 확인, 포트 교체, VLAN 구성 확인, 여전히 링크 라이트 없음"은 다음 사람이 처음 20분을 다시 하는 것을 저장합니다. "사용자가 깨졌다고 하며, 조언을 부탁드립니다"같은 모호한 에스컬레이션은 제거하지 않고 지연만 옮깁니다.

사용자와 루프를 종료하세요

사용자에게 "해결됨"이 아니라 평문으로 무엇이 잘못되었는지 말하세요. 무슨 일이 일어났는지 이해할 때 사람들은 지원을 더 신뢰하고, 같은 사람이 다음 달에 같은 티켓을 제출하지 않습니다. 왜냐하면 그들은 그것이 연결되어 있다는 것을 깨닫지 못하기 때문입니다.

이 중 기술적 측면에 더 깊이 들어가고 싶다면 — 네트워킹 기초, Windows 이벤트 로그, 또는 자신만의 진단 도구 스크립팅 — Korra Studio는 다음으로 진행할 가치가 있는 네트워킹, 시스템, 스크립팅 세그먼트를 가지고 있습니다.