База знаний Антона Сидорова

База знаний по аналитике, ИТ архитектуре, API. Документирование. Тесты инструментов.

---

Project maintained by daemon110282 Hosted on GitHub Pages — Theme by mattgraham

Инструкции для сопровождения

Инструкции для пользователей

Инструкции для поддержки

• Общие принципы
• FAQ
  • Что делать, если..
  • Как сделать…
• Чек-лист при обращениях

Требования к шаблону инструкции для службы поддержки информационной системы

1. Назначение и цели документа

Шаблон инструкции для службы поддержки (Service Desk / Support) должен обеспечивать единый подход к описанию функциональности информационной системы, диагностике проблем и обработке обращений пользователей.

Инструкция должна позволять специалисту поддержки самостоятельно:

1. Понять назначение функциональности и бизнес-процесса.
2. Определить, с каким типом проблемы обратился пользователь.
3. Проверить состояние операции или бизнес-процесса.
4. Выполнить первичную диагностику проблемы.
5. Определить возможную причину возникновения ошибки.
6. Выполнить предусмотренные действия по устранению проблемы.
7. Определить условия и порядок эскалации обращения на 2-ю или 3-ю линию поддержки.
8. Предоставить пользователю корректную обратную связь. Основной принцип: инструкция должна быть ориентирована не на описание того, как работает система с технической точки зрения, а на то, что должен проверить и сделать специалист поддержки в конкретной ситуации.

2. Функциональные требования к шаблону

Шаблон должен содержать следующие обязательные разделы.

2.1. Общая информация

Поле Описание Обязательность Наименование инструкции Название функциональности или процесса Да Идентификатор Уникальный номер документа Да Информационная система Наименование ИС Да Функциональный модуль Модуль или подсистема Да Версия документа Текущая версия инструкции Да Дата актуализации Дата последнего изменения Да Автор Ответственный за подготовку Да Ответственный за актуальность Владелец функциональности или процесса Да Целевая аудитория L1, L2, L3 Да Связанные документы Ссылки на регламенты, инструкции, API-документацию Нет

2.2. Описание функциональности

Раздел предназначен для краткого понимания специалистом поддержки назначения функциональности.

Содержание:

• Назначение функциональности.
• Бизнес-процесс, который она обеспечивает.
• Категории пользователей, использующих функциональность.
• Условия доступности функциональности.
• Основные ограничения и бизнес-правила.
• Взаимосвязанные системы и сервисы. Рекомендуется дополнить раздел схемой бизнес-процесса или последовательностью основных пользовательских действий.

2.3. Типовые обращения и проблемы

Основной раздел инструкции. Должен содержать перечень типовых проблем, с которыми может обратиться пользователь.

Для каждой проблемы необходимо предусмотреть отдельную карточку. Поле Описание ID проблемы Уникальный идентификатор Наименование Краткое название проблемы Описание обращения Как пользователь описывает проблему Условия возникновения При каких действиях возникает проблема Ожидаемое поведение Как система должна работать Фактическое поведение Что происходит в действительности Критичность Влияние проблемы на пользователя или бизнес-процесс Частота возникновения Единичная, периодическая, массовая Решение Ссылка на соответствующий сценарий диагностики

Примеры типовых обращений:

• Пользователь не может войти в систему.
• Пользователь не видит определенный раздел.
• Не отображается документ.
• Не удается сформировать отчет.
• Не удается отправить документ на подписание.
• Не удается подписать документ электронной подписью.
• Операция завершилась ошибкой.
• Статус операции не обновляется.

2.4. Алгоритм диагностики и устранения проблемы

Для каждой типовой проблемы должен быть описан пошаговый алгоритм действий специалиста поддержки.

Рекомендуемая структура: № Действие специалиста Ожидаемый результат Если результат отрицательный 1 Уточнить у пользователя дату и время возникновения проблемы Получены исходные данные Запросить дополнительные сведения 2 Уточнить идентификатор пользователя Пользователь идентифицирован Проверить данные обращения 3 Проверить наличие необходимых прав доступа Права соответствуют требованиям Направить запрос на проверку полномочий 4 Проверить статус операции в системе Статус соответствует ожидаемому Перейти к следующему шагу диагностики 5 Проверить наличие зарегистрированных ошибок Ошибки отсутствуют Зафиксировать ошибку и выполнить эскалацию

Важно: алгоритм должен описывать не только последовательность действий, но и точки принятия решений.

Для этого рекомендуется использовать блок-схемы с условиями переходов.

2.5. Контрольные точки и диагностические параметры

Раздел должен содержать информацию, которую специалист поддержки может использовать для проверки состояния системы. Параметр Описание Где проверить Примечание ID пользователя Идентификатор пользователя Карточка пользователя / БД Не использовать ФИО как единственный идентификатор ID операции Уникальный идентификатор операции Журнал операций Обязателен для диагностики Дата и время Время возникновения проблемы Логи / обращение С учетом часового пояса Статус операции Текущий статус Интерфейс / БД Сопоставить с жизненным циклом Код ошибки Код системной ошибки Логи / мониторинг При наличии Correlation ID Идентификатор цепочки запросов Логи сервисов Для сквозной диагностики

Следует отдельно указать:

• Какие параметры доступны L1.
• Какие параметры доступны только L2/L3.
• Какие действия запрещены специалисту поддержки.
• Какие данные являются конфиденциальными.

2.6. Справочник ошибок и способов решения

Для распространенных ошибок должен быть предусмотрен отдельный справочник. Код / сообщение ошибки Причина Проверка Способ устранения Линия поддержки Ошибка авторизации Истекла сессия Проверить срок действия сессии Повторная авторизация L1 Недостаточно прав Отсутствуют необходимые полномочия Проверить назначенные роли Передать запрос ответственному за доступ L1/L2 Ошибка подписания Проблема с ЭП или сертификатом Проверить сертификат и статус операции Согласно сценарию диагностики L2 Внутренняя ошибка сервиса Ошибка backend Проверить логи по Correlation ID Эскалация разработчикам L2/L3

Важно предусмотреть возможность нескольких причин возникновения одной и той же ошибки.

2.7. Порядок эскалации

Раздел должен определять условия передачи обращения между линиями поддержки. Уровень Зона ответственности Типовые задачи L1 Первая линия Консультации, проверка пользовательских настроек, базовая диагностика L2 Вторая линия Анализ состояния операций, проверка бизнес-правил, анализ логов, диагностика интеграций L3 Разработка / эксплуатация Анализ программных ошибок, исправление дефектов, устранение инфраструктурных проблем

Дополнительно необходимо определить:

• Условия эскалации.
• Ответственную команду или подразделение.
• Обязательные сведения для передачи обращения.
• Требования к логам и диагностическим материалам.
• SLA обработки обращения.
• Порядок информирования пользователя. Рекомендуется: предусмотреть отдельный чек-лист обязательных данных для эскалации, чтобы исключить передачу обращений без достаточной диагностической информации. 2.8. Шаблоны коммуникации с пользователем Раздел должен содержать готовые формулировки для типовых ситуаций.

Например:

• Запрос дополнительной информации.
• Информирование о необходимости повторить операцию.
• Сообщение о временной недоступности функциональности.
• Информирование о передаче обращения на следующую линию.
• Подтверждение успешного устранения проблемы. Формулировки должны быть понятны пользователю, не содержать внутренних технических подробностей и не раскрывать конфиденциальную информацию.

2.9. Ограничения и меры предосторожности

Необходимо описать действия, которые специалист поддержки не должен выполнять самостоятельно.

Например:

• Изменять статусы операций напрямую в БД.
• Повторно запускать операцию без проверки ее текущего состояния.
• Удалять или изменять документы пользователя.
• Выполнять действия от имени пользователя без предусмотренных полномочий.
• Запрашивать у пользователя пароли, PIN-коды, закрытые ключи или коды подтверждения.
• Передавать персональные данные через незащищенные каналы.

3. Нефункциональные требования к шаблону

ID Требование Критерий приемки NFR-01 Единая структура Все инструкции создаются на основе утвержденного шаблона NFR-02 Понятность Инструкция позволяет L1 выполнять типовые проверки без привлечения разработчиков NFR-03 Однозначность Каждый шаг алгоритма содержит конкретное действие и ожидаемый результат NFR-04 Полнота Для каждой типовой проблемы определены диагностика, решение и условия эскалации NFR-05 Актуальность Указаны версия, дата актуализации и ответственный за документ NFR-06 Прослеживаемость Есть ссылки на связанные бизнес-процессы, регламенты и техническую документацию NFR-07 Безопасность Исключено раскрытие учетных данных, секретов и избыточных персональных данных NFR-08 Удобство поиска Инструкции содержат идентификаторы, ключевые слова и категории проблем NFR-09 Поддерживаемость Изменения функциональности сопровождаются оценкой необходимости обновления инструкции NFR-10 Версионирование Предусмотрена история изменений документа

4. Рекомендуемая структура итогового шаблона

Шаблон инструкции для поддержки

Рекомендуемая структура

1. Паспорт документа: Идентификатор, название, версия, дата, автор, владелец.
2. Назначение функциональности: Бизнес-контекст, участники, условия использования.
3. Схема бизнес-процесса: Основные этапы и взаимодействие с другими системами.
4. Типовые обращения: Каталог пользовательских проблем и симптомов.
5. Алгоритмы диагностики: Пошаговые инструкции, проверки, условия переходов.
6. Справочник ошибок: Коды ошибок, причины, способы устранения.
7. Контрольные точки: Статусы, идентификаторы, журналы, диагностические параметры.
8. Эскалация: Условия передачи на L2/L3, ответственные, SLA.
9. Коммуникация с пользователем: Готовые ответы и шаблоны сообщений.
10. Ограничения и безопасность: Запрещенные действия, требования к работе с данными.
11. История изменений: Версии, даты, авторы и описание изменений.

5. Критерии качества готовой инструкции

Инструкция считается готовой к передаче в поддержку, если выполняются следующие условия:

1. Специалист L1 может определить категорию обращения по описанию пользователя.
2. Для каждой типовой проблемы существует алгоритм первичной диагностики.
3. Алгоритм содержит проверяемые условия и ожидаемые результаты.
4. Для каждого результата диагностики определено следующее действие.
5. Определены случаи, когда проблема не может быть устранена на L1.
6. Для эскалации предусмотрен полный перечень необходимых диагностических данных.
7. Приведены актуальные способы проверки состояния системы.
8. Описаны ограничения и запрещенные действия.
9. Инструкция проверена представителем поддержки на практическом сценарии.
10. Назначен ответственный за актуализацию документа.

6. Дополнительная рекомендация по организации базы знаний

Для крупной ИС рекомендую не создавать одну большую инструкцию на всю систему. Лучше использовать двухуровневую структуру:

Уровень 1 — каталог инструкций по функциональным модулям:

• Авторизация и управление доступом.
• Пользователи и полномочия.
• Документы и электронная подпись.
• Отчеты.
• Операции и денежные средства.
• Интеграции с внешними системами.

Уровень 2 — отдельные инструкции по пользовательским сценариям и проблемам.

Например, для модуля «Документы и электронная подпись»:

• Пользователь не видит документ.
• Документ не отправляется на подписание.
• Ошибка проверки полномочий представителя ЮЛ.
• Ошибка проверки сертификата ЭП.
• Ошибка при подписании документа.
• Документ подписан, но статус не изменился.
• Документ не доставлен контрагенту. Такой подход позволяет независимо актуализировать инструкции и быстрее находить нужный сценарий.

Ключевая рекомендация: единицей документации поддержки лучше считать не функциональность системы, а конкретный пользовательский сценарий или тип проблемы. Это делает базу знаний практическим инструментом обработки обращений, а не дублированием пользовательской или технической документации.