IT Support Done Right: A Practical Field Guide

Hầu hết công việc hỗ trợ IT được đánh giá dựa trên tốc độ, nhưng tốc độ không có phương pháp chỉ đẩy vấn đề sang một nơi khác. Một ticket được đóng trong năm phút mà mở lại trong ba ngày tốn kém hơn một ticket mất hai mươi phút nhưng thực sự được sửa chữa. Hướng dẫn này bao gồm những thói quen phân biệt giữa người đóng ticket và người giải quyết vấn đề.

Bắt đầu với một quá trình tiếp nhận thực sự, không phải đoán đoán

Trước khi chạm tới máy tính, yêu cầu người dùng mô tả vấn đề bằng lời của họ, sau đó đặt ba câu hỏi tiếp theo: khi nó bắt đầu, gần đây có gì thay đổi, và nó có xảy ra mỗi lần hay thỉnh thoảng. "Internet của tôi chậm" có thể là DNS resolution, Wi-Fi channel bị bão hòa, NIC lỗi, hoặc trình duyệt với bốn mươi tab mở. Ghi chép chính xác văn bản lỗi nếu có. Ảnh chụp màn hình tốt hơn mô tả — yêu cầu một ảnh trước khi bạn yêu cầu người dùng thử bất cứ điều gì.

Tiếp theo là đừng vội vàng nhảy sang "bạn đã thử khởi động lại chưa." Nó hoạt động thường xuyên đủ để mọi người mặc định sử dụng nó, nhưng nếu bạn bỏ qua quá trình tiếp nhận bạn sẽ bỏ lỡ các mẫu. Nếu ba người trên cùng một switch báo cáo cùng một sự chậm lại trong cùng một giờ, đó là một ticket khác với một laptop có driver tồi.

Tái tạo trước khi bạn sửa chữa

Nếu bạn không thể tái tạo lại một vấn đề, bạn không thể xác nhận rằng bạn đã sửa chữa nó. Yêu cầu người dùng đi qua các bước chính xác trên screen share, hoặc tự làm trên máy của họ nếu các công cụ remote cho phép. Kiểm tra ipconfig /all trên Windows hoặc ip a trên Linux để có sơ bộ mạng hợp lý, xem Event Viewer (eventvwr.msc) để tìm các lỗi ứng dụng và hệ thống xung quanh thời gian được báo cáo, và kiểm tra journalctl -xe --since "1 hour ago" trên các hộp Linux trong cùng một cửa sổ.

Đối với sự cố ứng dụng, hãy lấy số bản dựng chính xác và phiên bản OS. "Nó sụp đổ" không cho bạn biết gì; "Outlook 16.0.17726 sụp đổ khi mở lời mời lịch với tệp đính kèm .ics" cho bạn biết nơi cần tìm. Kiểm tra chéo với các vấn đề đã biết trong ghi chú phát hành của nhà cung cấp trước khi giả định rằng nó là cục bộ.

Phân loại theo tác động, không phải theo ai hét to nhất

Một người dùng bị khóa ngoài email là bất tiện. Một máy chủ tệp dùng chung không thể tiếp cận được cho bốn mươi người là một sự cố. Xây dựng một thang độ nghiêm trọng đơn giản — cái gì đó như P1 để cấu hình ảnh hưởng đến nhiều người dùng hoặc hệ thống quan trọng, P2 để chặn người dùng đơn, P3 để giảm chất lượng nhưng vẫn hoạt động, P4 để yêu cầu mỹ phẩm hoặc tiện lợi — và áp dụng nó một cách nhất quán, ngay cả dưới áp lực từ người quản lý muốn cái của họ trước tiên.

Ghi chép quyết định độ nghiêm trọng trong ticket. Điều này bảo vệ bạn sau này khi ai đó hỏi tại sao P3 của họ ngồi hai ngày trong khi bạn xử lý ba P1.

Sửa chữa nguyên nhân gốc rễ, không phải triệu chứng

Khởi động lại một dịch vụ liên tục sụp đổ chỉ mua thời gian, không phải một giải pháp. Nếu spooler in chết hàng ngày, hãy kiểm tra Get-WinEvent -LogName Application -MaxEvents 50 để tìm lỗi thực tế trước khi khởi động lại nó. Nếu mật khẩu của người dùng liên tục hết hạn một cách bất ngờ, hãy kiểm tra chính sách nhóm được áp dụng cho OU của họ thay vì chỉ đặt lại và tiếp tục.

Khiêu một nhật ký cá nhân về các sửa chữa định kỳ. Nếu bạn thấy mình gõ cùng một lệnh PowerShell hoặc cùng một bản sửa chữa sổ đăng ký ba lần, đó là một dấu hiệu nó nằm trong một kịch bản hoặc một runbook được tài liệu hóa, không trong đầu bạn.

Tài liệu hóa như có người khác sẽ đọc nó

Mỗi giải pháp ticket nên trả lời: nguyên nhân thực tế là gì, bản sửa chữa là gì, và bạn sẽ kiểm tra cái gì trước tiên nếu điều này xảy ra lại. "Đã sửa chữa" là một ghi chú giải pháp không có giá trị cho công nghệ tiếp theo, bao gồm cả bạn trong tương lai sáu tháng kể từ bây giờ không có ký ức về ticket này.

Một ghi chú giải pháp tốt trông giống như: "Nguyên nhân gốc rễ: DHCP scope trên VLAN 20 cạn kiệt, các thiết bị mới nhận được địa chỉ APIPA. Bản sửa chữa: mở rộng scope từ /24 đến /23, tạo dành riêng cho máy in. Xác minh: kiểm tra số lần cho thuê DHCP hàng tháng, ngưỡng cảnh báo được đặt ở 90%." Câu thứ ba đó là câu hầu hết các lỗi bỏ qua, và nó là cái ngăn chặn ticket lặp lại.

Chuyên tiếp với ngữ cảnh, không chỉ một lần chuyển tiếp

Khi một ticket đi đến tier 2 hoặc nhà cung cấp, hãy bao gồm những gì bạn đã loại bỏ. "Đã kiểm tra cáp, hoán đổi cổng, xác nhận cấu hình VLAN, vẫn không có đèn liên kết" tiết kiệm thời gian cho người tiếp theo từ việc làm lại hai mươi phút đầu tiên của bạn. Các cuộc chuyên tiếp mơ hồ như "người dùng nói nó bị hỏng, vui lòng tư vấn" chỉ di chuyển độ trễ thay vì loại bỏ nó.

Đóng vòng lặp với người dùng

Nói với người dùng những gì đã sai bằng ngôn ngữ đơn giản, không chỉ "đã sửa chữa." Mọi người tin tưởng hỗ trợ nhiều hơn khi họ hiểu những gì đã xảy ra, và nó giảm bớt người cùng một người nộp cùng một ticket tháng sau vì họ không nhận ra nó được kết nối.

Nếu bạn muốn đi sâu hơn về phía kỹ thuật của bất kỳ điều gì trong số này — kiến thức cơ bản về mạng, nhật ký sự kiện Windows, hoặc kịch bản các công cụ chẩn đoán của riêng bạn — Korra Studio có các phân đoạn về Networking, Systems, và Scripting đáng để làm việc tiếp theo.