В смешанном парке ошибка — заводить два процесса поддержки, «для Windows» и «для Linux». Процесс должен быть один, а различия систем живут внутри него: в карточке устройства и в наборе проверок после изменений. Иначе вы получаете две очереди заявок, две инвентаризации и знание, которое не переносится между людьми.
Одна карточка устройства
Общие поля для всех машин, плюс несколько специфичных. Общие: ответственный, назначение, сеть, уровень доступа, дата последней проверки подключения.
- Для Windows: редакция (в Home нет встроенного RDP-сервера) и версия.
- Для Linux: дистрибутив, версия, окружение рабочего стола и тип графической сессии.
- Для macOS: версия и отметка о выданных системных разрешениях на запись экрана и управление.
Эти поля не формальность: именно они объясняют, почему на соседних машинах одно и то же решение ведёт себя по-разному. Платформенные особенности разобраны на страницах удалённого стола для Windows, для macOS и для Linux.
Одна процедура заявки
Пользователь не должен знать, к какому специалисту идти, и уж тем более — какая у него операционная система с точки зрения процесса. Форма одна, поля одни: что не работает, с какого момента, что менялось перед этим.
Различия появляются на этапе диагностики, а не приёма. Для Linux в чек-лист диагностики попадает проверка типа сессии, для Windows — редакция и параметры питания, для macOS — системные разрешения.
Тесты после изменений
Обновление системы способно сломать удалённый доступ на любой платформе, но по-разному: на Linux может смениться тип графической сессии, на macOS — сброситься разрешения, на Windows — вернуться настройки питания.
- После крупного обновления проверяйте подключение сразу, а не при следующей необходимости.
- Проверку делайте из внешней сети — локальная не показывает реальную картину.
- Записывайте дату последней успешной проверки в карточку: она отвечает на вопрос «когда это в последний раз точно работало».
Держать это вручную получается примерно до двадцати машин. Дальше нужны статусы и оповещения, одинаковые для всех платформ, — как устроен мониторинг смешанного парка. А если поддержка внешняя, единый процесс упрощает и отчётность: время сессий собирается по клиентам независимо от того, какая на машине система — см. учёт времени поддержки.
Нужны ли отдельные инструкции для пользователей Windows и Linux?
Общая процедура — одна, а шаги с интерфейсом различаются, и их лучше держать отдельными короткими приложениями. Единый документ, где на каждый шаг по два варианта, читается хуже обоих: человек тратит внимание на выбор своей ветки вместо самого действия.
Как считать метрики, если платформы обслуживаются по-разному?
Одинаково, но с разбивкой по платформам. Общее среднее по смешанному парку скрывает именно то, что нужно увидеть: если по одной платформе заявки решаются вдвое дольше, в общей цифре это выглядит как небольшое ухудшение.