Производственная поддержка охватывает практики и дисциплины поддержки ИТ- систем/приложений, которые в настоящее время используются конечными пользователями . Лицо/группа производственной поддержки отвечает за мониторинг производственных серверов, запланированных заданий, управление инцидентами и получение инцидентов и запросов от конечных пользователей , их анализ и либо предоставление конечному пользователю решения, либо эскалацию его другим ИТ-командам. Эти команды могут включать разработчиков , системных инженеров и администраторов баз данных .
Чтобы понять важность поддержки производства, необходимо принять во внимание несколько факторов.
Из перечисленных выше факторов видно, что способ управления поддержкой производства имеет чрезвычайно важное значение.
Ниже приведены основные шаги производственной поддержки. Эти шаги производственной поддержки находятся в контексте пакетной обработки .
Обычно пакетное задание или группа связанных пакетных заданий (расписание/поток) запускается для выполнения одной или нескольких бизнес-функций. Эти пакетные задания запускаются без присмотра и обычно завершаются без ошибок или проблем. Однако иногда пакетное задание может прерываться/прерываться/аварийно завершаться/отменяться. Может быть несколько причин, по которым задание может аварийно завершиться.
Когда задание аварийно завершается, оно может отправить автоматическое оповещение по электронной почте, пейджеру, тексту. Кроме того, центр обработки данных или операционная группа также активно отслеживают задания. Они также отправляют оповещение по электронной почте, пейджеру, тексту или могут позвонить дежурному лицу, ответственному за восстановление аварийного задания.
Дежурный подтверждает получение электронного письма, пейджера, текстового сообщения или телефонного звонка для прерванной работы. Дежурный также записывает сведения об прерванной работе в систему отслеживания производственных проблем. Иногда прерванная работа автоматически записывает сведения об аварийном завершении работы вместе со списком стандартов работы (журналом работы) в систему отслеживания производственных проблем. Сведения об прерванной работе (список стандартов работы, файлы журнала ошибок и т. д.) доступны в инструменте планировщика производственных задач. Инструмент отслеживания производственных проблем создает номер запроса, и этот номер запроса передается группе поддержки. Этот номер запроса используется для отслеживания хода решения проблемы поддержки производства. Запрос назначается дежурному сотруднику группы поддержки.
В случае критических ошибок производства (например, задание производства находится на критическом пути и, вероятно, задержит выполнение SLA по завершению партии , а ошибка производства влияет на бизнес-данные) всей организации или затронутым группам отправляется электронное письмо, чтобы они знали о проблеме. Им также предоставляется предполагаемое время для устранения ошибки производства.
Дежурный сотрудник службы поддержки производства собирает всю необходимую информацию об ошибке производства. Затем эта информация записывается в инструмент отслеживания ошибок производства с использованием правильного номера запроса на поддержку, назначенного ранее. Все детали, такие как данные, среда, процесс, логика программы, которая дала сбой, используются в расследовании. Пакетное задание производства, используемая программа или любой используемый инструмент/утилита проверяются на предмет возможных ошибок.
Если аналогичная ошибка Production произошла в прошлом, то шаги по разрешению проблемы извлекаются из базы знаний поддержки, и ошибка устраняется с помощью этих шагов. Если это новая ошибка Production, то создаются новые шаги по разрешению ошибки Production, и ошибка Production устраняется. Новые шаги по разрешению ошибки Production записываются в базу знаний для будущего использования. В случае серьезных ошибок Production (критические сбои инфраструктуры или приложений) инициируется телефонная конференция, и все необходимые лица/группы поддержки присоединяются к вызову, и все они работают вместе, чтобы устранить ошибку. Это также называется Управлением инцидентами. Если проблема возникает повторно, то она регистрируется и отслеживается с помощью соответствующих инструментов и процессов, пока не будет решена окончательно. Это также называется Управлением проблемами. Проблема закрывается только после того, как клиент или конечный пользователь соглашается с тем, что проблема решена.
Если ошибка производства произошла из-за ошибок программирования, то создается запрос для команды разработки на исправление ошибок программирования. Проблема выявляется, определяется и выполняется анализ первопричины. Ошибка программирования устраняется с помощью обычного процесса SDLC — анализ/проектирование/программирование/QA/тестирование/выпуск. Новая версия задания/программы производства развертывается и проверяется/валидируется.
Если ошибка производства произошла из-за проблем с зависимостью задания/расписания или проблем с последовательностью, то проводится дальнейший анализ для поиска правильной последовательности/зависимостей. Новая последовательность/зависимости проверяются и подтверждаются в тестовой среде перед развертыванием производства.
Если ошибка производства произошла из-за проблем с инфраструктурой, то конкретная команда по инфраструктуре уведомляется. Затем команда по инфраструктуре реализует постоянное исправление проблемы и контролирует инфраструктуру, чтобы избежать повторения той же ошибки.
Если ошибка производства произошла из-за непредвиденных последствий изменений инфраструктуры, то чаще всего команда по инфраструктуре не может выставить счет за время, потраченное на решение проблемы, по полной ставке. В некоторых случаях часы полностью исключаются из выставления счета.
Система отслеживания ошибок производства используется для периодического обзора всех проблем (ежедневно, еженедельно и ежемесячно), а также создаются отчеты для мониторинга решенных проблем, повторяющихся проблем, ожидающих решения проблем. Отчеты также создаются для управления ИТ/ИС для улучшения и управления производственными заданиями.