Регламент эксплуатации информационной системы

Технологические вопросы крупных внедрений13.05.2016

Вводится в действие 01 июля 2022 года

1. ОБЩИЕ ПОЛОЖЕНИЯ

1.1. Настоящий регламент (далее-Регламент) определяет перечень и порядок предоставления услуг сопровождения программных продуктов и поддержки пользователей при наличии действующего Договора, заключенного между Заказчиком и ООО «Мегаскоп».

1.2. Перечень программных продуктов системы 1С:Предприятие, пользователем которых является Заказчик, определяется в Договоре.

1.3. В рамках Договора оказываются услуги, определенные в разделе 3 Регламента, если иное не указано в Договоре.

1.4. Услуги оказываются при наличии у Заказчика действующего договора ИТС. Подробнее см. https://portal.1c.ru/support/.

2. ТЕРМИНЫ И ОПРЕДЕЛЕНИЯ

В рамках Регламента термины и определения используются в следующем значении:

Заказчик – Предприниматель или юридическое лицо, у которого на момент обращения заключен Договор с Исполнителем.

Исполнитель –ООО «Мегаскоп», официальный партнер фирмы 1С, ИНН/КПП 4025071917/402501001.

Договор – Договор оказания услуг сопровождения программных продуктов и поддержки пользователей, заключенный между Заказчиком и Исполнителем.

Уполномоченный представитель Заказчика / Представитель Заказчика – Должностное лицо Заказчика, которое в соответствии с Договором имеет право представлять интересы Заказчика, подготавливать и направлять запросы на предоставление услуг, осуществлять приемку оказанных услуг, а также делегировать описанные выше полномочия пользователям Заказчика.

Линия поддержки пользователей / Линия поддержки – Единая точка приема обращений Заказчика.

Регламентированные работы/услуги – Согласованный перечень и объем регулярных работ по техническому сопровождению программных продуктов и сервисов.

Тип запроса – Категория, которая используется линией поддержки при расставлении приоритетов в обработке запросов. Выделяются типы запросов: Инцидент, Запрос на оказание услуг, Запрос на изменение, Прочие.

Запрос на оказание услуг – Запрос, поступающий от представителя Заказчика на оказание услуг по Договору.

Запрос на изменение – Предложение на реализацию изменения. Запрос на изменение включает в себя детали предложенного изменения и может быть записан в бумажном или электронном виде.

Инцидент – Незапланированное прерывание или снижение качества работоспособности программного продукта/системы критически влияющее на выполнение пользователями Заказчика регулярных операций и/или качество поставляемых результатов (выходов) процессов Заказчика.

Время реакции на запрос – Время до первого контакта сотрудника Исполнителя с уполномоченным представителем или пользователем Заказчика с учетом рабочего графика Исполнителя, если иное не определено Договором.

Продолжительность услуги – Объём единичной услуги, потреблённой Заказчиком.

3. ПЕРЕЧЕНЬ УСЛУГ

3.1. В соответствии с настоящим Регламентом Исполнитель оказывает Заказчику услуги из состава, указанного в Приложении 1. Перечень услуг сопровождения программных продуктов 1С:Предприятие и поддержки пользователей.

3.2. Перечень услуг, оказываемых конкретному Заказчику, их объем и особый порядок оказания определяется в Договоре с Заказчиком.

3.3. Услуги разработки, администрирования и управления конфигурациями Заказчика не оказываются в соответствии с настоящим Регламентом, а предоставляются по дополнительным соглашениям с Исполнителем.

4. ПОРЯДОК ОКАЗАНИЯ УСЛУГ

4.1. Основанием для оказания услуг являются согласованные в Договоре регламентированные работы и/или Запросы на оказание услуги, поступающие Исполнителю от уполномоченных представителей и/или пользователей Заказчика.

4.2. Запросы принимаются Исполнителем по следующим каналам Линии поддержки:

4.3. Услуги оказываются по рабочим дням Исполнителя, которые соответствуют производственному календарю РФ с 8:30 до 17:30 МСК.

4.4. Допускается оказание услуг вне рабочего времени, установленного в пп. 4.3. Регламента, по согласованию со специалистом Исполнителя, который оказывает услуги. Продолжительность услуги, оказанной вне рабочего времени, рассчитывается в соответствии с  пп. 5.2. Регламента с применением повышающего коэффициента 1,5.

4.5. Услуги оказываются удаленно с использованием сервиса 1С-Коннект.

4.6. Выезд на территорию Заказчика осуществляется по согласованию в соответствии с условиями, указанными в Договоре.

5. ПРОДОЛЖИТЕЛЬНОСТЬ УСЛУГИ

5.1. Продолжительность услуги рассчитывается, исходя из времени, которое специалисты Исполнителя затратили на оказание услуги. Продолжительность услуги при удалённой работе учитывается автоматизированными средствами Исполнителя по правилам, изложенным в пп. 5.2. Регламента.

5.2. Продолжительность услуги при удалённой работе.

Общие вопросы

Эксплуатация крупной информационной системы

Это отдельный вид деятельности, который невозможно не учитывать, и который гарантированно будет показывать обратную связь:

• если ресурсов выделяется достаточно, то система будет работать качественно;
• если ресурсов выделяется недостаточно, то будут периодические сбои и “пожарные” работы по восстановлению.

В качестве примера будем рассматривать некоторую систему, в которой одновременно работают от 200 (в ночное время) до 1000 пользователей (днем) онлайн. При этом число реально зарегистрированных пользователей может оказаться значительно больше.

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

Технологическое качество

Под технологическим качеством подразумевается

• доступность системы более 99% процентов времени работы системы;
• неухудшение производительности со временем в процессе эксплуатации;
• неухудшение технологических показателей работы системы (например, загруженность оборудования) в результате обновлений на новые версии;
• отсутствие технологических ошибок при выполнении каких-либо операций в системе;
• стабильный адекватный результат при выполнении каких-либо операций в системе.

Задачи

Какие задачи встают перед специалистами

• планирование задач;
• администрирование
  рабочей зоны;
  подготовительной зоны;
  зоны разработки;
• рабочей зоны;
• подготовительной зоны;
• зоны разработки;
• эксплуатация рабочей зоны;
• разработка
  необходимого инструментария;
  доработка существующих механизмов;
  автоматизация повторяющихся задач.
• необходимого инструментария;
• доработка существующих механизмов;
• автоматизация повторяющихся задач.

В задачи эксплуатации входят:

• Организация первой линии технической поддержки;
  Разбор и классификация обращений;
  Максимально оперативная реакция на обращения пользователей;
  Взаимодействие с пользователями;
  Трансфер собранной и структурированной информации о проблеме второй линии тех поддержки;
• Разбор и классификация обращений;
• Максимально оперативная реакция на обращения пользователей;
• Взаимодействие с пользователями;
• Трансфер собранной и структурированной информации о проблеме второй линии тех поддержки;
• Организация второй линии технической поддержки;
  Разбор обращений и решение технологических проблем;
  Классификация проблем;
• Разбор обращений и решение технологических проблем;
• Классификация проблем;
• Тестирование и обновление на новые версии решений без ухудшения качества;
• Дежурство и пожарные работы;
  Внесение критичных исправлений для восстановления работы;
• Внесение критичных исправлений для восстановления работы;
• Аудит доп отчетов и обработок;
• Автоматизация повторяющихся задач.

В задачи администрирования входят:

• Развертывание, конфигурирование и обслуживание оборудования;
• Конфигурирование среды виртуализации;
• Конфигурирование сети;
• Конфигурирование кластера серверов 1С;
• Конфигурирование СУБД;
• Регулярное создание бэкапов, хранение и развертывание бэкапов;
• Обеспечение работы с лицензиями, ключами, сертификатами;
• Обновление программных продуктов;
• Развертывание новых нод;
• Автоматизация повторяющихся задач;
• Настройка мониторинга.

В задачи разработки входят:

• Прием в эксплуатацию новых информационных баз и областей
  Доработка конфигураций до возможности перехода в сервис;
• Доработка конфигураций до возможности перехода в сервис;
• Разработка аналитических отчетов;
• Расширение статистики;
• Разработка механизмов для развития сервиса;
• Разработка механизмов интеграции.

Планирование

Для планирования задач могут использоваться инструменты

• Менеджер Сервиса;
• Сервис Деск;
• Центр Контроля Качества;
• Jira;
• Документооборот;
• Confluence;
• Skype;
• и другие.

Зоны системы

Зоны информационной системы:

• Рабочая зона информационной системы;
• Подготовительная зона информационной системы;
• Зона тестирования продукта;
• Зона разработки продукта.

• Серверы разработки продукта;
• Серверы тестирования продукта;
• Подготовительные серверы системы;
• Продукционные серверы системы.

Отличия зоны тестирования продукта от подготовительной зоны информационной системы:

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

Важно отметить, что в зависимости от того, насколько клиент готов нести затраты на обслуживание системы, зависит то, насколько указанная выше схема “ложится” на реальную систему клиента.

• Рабочая зона;
• Подготовительная и тестовая зона;
• Зона разработки продукта.

Здесь объединяется подготовительная и тестовая зона, при этом качество тестирования непосредственно перед обновлением в продуктиве напрямую зависит от качества соответствия подготовительной зоны рабочей зоне.

При этом зона разработки продукта, например, может вообще отсутствовать, если продукт не изменяется и не разрабатывается специалистами клиента. Т.е. процесс разработки продукта полностью отделен от рабочей информационной системы.

• Рабочая зона;
• Подготовительная зона;
• Зона разработки и тестирования.

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

Что не следует делать

Совершенно точно не следует совмещать рабочую зону с подготовительной зоной, т.к. по сути новая версия системы будет “собираться” именно в продуктиве. Такой подход имеет повышенный риск сбоев в результате обновлений.

Не стоит совмещать подготовительную зону и зону разработки. В этом случае появляется риск утечки данных, т.к. доступ к данным пользователей появляется у разработчиков.

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

В этом случае страдает бизнес клиента, а от пользователей постоянно поступает негатив. Также стоит отметить, что после каждого такого обновления, нужного бизнесу, без тестирования в тестовой и подготовительной зонах, происходит период нестабильной работы системы, т.к. по сути это и является периодом опытно-промышленной эксплуатации, в котором тестирование происходит на пользователях.

Что имеет смысл сделать

Сначала стоит обновить наиболее маленькую часть. Затем, если система после обновления в продуктиве работает без сбоев, имеет смысл приступить к обновлению всей рабочей зоны.

Подготовительную зону имеет смысл развертывать скриптами, которые применяются для целей автоматизации, из бэкапов с рабочей зоны. Таким образом будет гарантироваться, что подготовительная зона максимально приближена к рабочей зоне.

• у вас всегда есть актуальная копия системы (базы данных, настроек) на нужный вам момент времени, и вы совершенно точно в состоянии её развернуть;
• скрипты автоматизации работают без сбоев;
• бэкапы создаются без сбоев и их действительно можно использовать;
• вы периодически тренируете навык восстановления системы “с нуля”;
• известно достаточно точное время развертывания и создания единицы масштабирования с нуля.

Имеет смысл также организовать и иметь полный удаленный доступ в рабочую и подготовительную зоны. При этом такой доступ:

• Должен быть только у ограниченного известного круга лиц;
• Максимально защищен.

Удаленного доступа может не быть к зоне разработки и тестирования продукта. Продукт может нести особенную ценность для организации, в т.ч. с точки зрения обеспечения безопасности, а открытие доступа создает риск не только утечки исходного кода, но и открывает дополнительные возможности злоумышленникам в тех системах, где продукт используется. (Не раскрываем эту тему в текущей статье). К тому же как правило нет задачи поддерживать, например, uptime серверов разработки на уровне 99% и выше удаленно, разработчики обычно сами в состоянии это сделать со своих рабочих мест. В некоторых случаях (например, географической удаленности) существует задача обеспечения доступности системы сборки и тестирования, тогда такой доступ может быть организован.

Автоматизация

Такие шаблоны в минимальном виде могут быть:

• Шаблон рабочего сервера;
• Шаблон сервера СУБД;
• Шаблон веб сервера.

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

Особое внимание можно обратить на подготовку следующих “механизмов”:

• Скрипты по донастройке сервера до заданных параметров;
• Автоматизация развертывания баз;
• Настройка и применение групповых политик;
• Автоматизация запуска, остановки служб;
• Автоматизация установки Платформы, СУБД;
• Автоматизация развертывания виртуальных машин из шаблонов в заданной конфигурации.

Регламент сопровождения

Регламент определяет взаимодействие сторон в процессе оказания услуг технической поддержки Клиентов Банка, использующих конфигурации системы «1С:Предприятие» для прямого обмена с банками по технологии DirectBank. Применяется сразу после начала обслуживания Клиента в Банке при условии, что система Банка имеет сертификат «1С:Совместимо» по технологии DirectBank.

Перечень терминов и сокращений

1.1. Стороны и их функции

1.2. Система ведения запросов клиентов в банке

Регистрация и сопровождение запросов полученных от клиентов, обрабатывается на 1-м уровне поддержки банка. При необходимости запрос направляется с первого уровня на второй уровень поддержки в банке.

Запросы, требующие компетенции разработчика ПО «1С», при необходимости Банк может направить на форум по вопросам разработки и организации приямого обмена информацией клиентов с банком с использованием технологии DirectBank.

Для участия в конференции нужно:

1. Клиент осуществляет обращение в службу технической поддержки Банка по каналу, указанному банком на веб-странице своего сайта в Интернет.

2. Сотрудник 1 уровня ТП принимает запрос и регистрирует его в системе регистрации запросов Банка.

3. Сотрудником 1 уровня ТП анализируется запрос. Сотрудник 1 уровня ТП может:

• самостоятельно ответить Клиенту на его вопрос;
• передать вопрос на 2 уровень ТП — разработчикам шлюза ДиректБанк в банке;

Если вопрос Клиента относится к компетенции службы технической поддержки пользователей «1С», то сотрудник 1 уровня поддержки сообщает Клиенту о проведенной экспертизе и предлагает Клиенту обратиться на ЛК «1С». Зарегистрированным легальным пользователям программ «1С» регламент обращения известен.

В качестве дополнительной информации сотрудник ТП Банка может проинформировать Клиента о данных, требуемых для регистрации запроса на ЛК «1С»:

• программный продукт (типовая конфигурация), номер версии и регистрационный номер программы;
• вариант использования типовой конфигурации;
• версия «1С:Предприятия 8» (например, 8.3.6.2100) и вариант использования;
• операционная система Клиента;
• контактная информация Клиента. (ФИО, эл. адрес, телефон);
• название Банка, в котором обслуживается Клиент по прямому обмену;
• номер (регистрации) обращения в Банк;
• текст вопроса Клиента;
• текст, полученный от Банка по результатам расследования ошибки и обоснованием, что ошибка не на стороне Банка.

Специалист ЛК «1С» регистрирует вопрос клиента, проводит его анализ и в случае, если решение вопроса находится в компетенции ЛК «1С», самостоятельно информирует Клиента, отправив письмо на адрес, указанный в запросе.

Если же решение вопроса находится в компетенции Банка и запрос на ЛК «1С» выставлен ошибочно, сотрудник ЛК «1С» возвращает запрос Клиенту с результатами исследования ошибки и рекомендацией снова обратиться в Банк.

Для повышения качества поддержки пользователей, фирма «1С» с 12 декабря 2016 года расширяет техническую поддержку по сервису «1С:ДиректБанк». Поддержка пользователей осуществляется с 7.00 до 20.00 в рабочие дни и с 9.00 до 18.00 в выходные или праздничные дни по московскому времени. Обращаться в Центр поддержки пользователей можно по следующим каналам:

• 1С-Коннект, услуги «1С:ДиректБанк: Поддержка клиентов» и «1С:ДиректБанк: Поддержка партнеров»;
• по телефону: 8 (800) 333-93-13;

Информация о сервисе на диске ИТС размещена на портале ИТС.

Регламенты

Организация внесения изменений на подготовительной и рабочей площадке

все изменения в рабочую систему вносятся через подготовительную площадку

Сначала изменения попадают на подготовительный стенд, затем на рабочий стенд.

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

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

Изменяться состояние подготовительного стенда может следующими способами:

• Развертывание backup-ов;
• Развертывание копий машин;
• С подготовкой check-листов;
• Небольшие изменения без подготовки check-листов, но обязательным записью в журнал регистрации проведенных работ.

• По check-листам;
• В случае аварийных работ при недоступности рабочей системы;
• Перенос небольших изменений с подготовительного стенда с записью в журнал регистрации проведенных работ.

Перед применением изменений на рабочей площадке check-листы распечатываются и передаются каждому участнику плановых работ.

Журнал регистрации проведенных работ – специальный документ, который ведут все участники эксплуатации рабочий и подготовительной системы. В бортовой журнал попадают записи, отражающие все изменения в очень сжатой форме. Цель бортового журнала – в случае аварии быстро определить, кто и когда вносил изменения.

Пример записи в журнале регистрации проведенных работ:

Контроль качества работы подготовительного стенда

После исправления проблемы необходимо провести повторное контрольное тестирование.

Публикация в рабочей зоне

Время выполнения обновления, а также особенности обновления фиксируются и сравниваются с результатами полученными в подготовительной среде.

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

Контроль качества рабочей системы

Допустимым временем простоя системы при откате на предыдущую версию считается 10 минут.

Для качественного контроля за рабочей системой необходимо настраивать мониторинг.

“Мониторинг на продукционных серверах”

Также инструкция по настройке мониторинга с помощью Центр Контроля Качества.

Организация эксплуатации

Регламенты, необходимые для организации процесса эксплуатации:

Ниже приводится схема (рисунок можно открыть в отдельном окне, либо на нее можно нажать левой кнопкой мыши) с принципиальным общим видом организации крупной информационной системы.

Схему можно применять для того, чтобы понять, какие стороны вопроса эксплуатации действительно хорошо проработаны в вашей организации на вашем проекте, а какие стороны вопросы не проработаны совсем (как следствие, возможны риски).

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

Основная ценность – команда, решающая задачи эксплуатации, администрирования и разработки.

Под проблемами качества работы системы подразумеваются проблемы работоспособности, устойчивости и производительности системы.

Под изменениями рабочей системы подразумеваются любые изменения программного, аппаратного, организационного или инфраструктурного уровней системы, включая, но не ограничиваясь, следующими изменениями:

• Любые изменения кода конфигурации системы (в том числе связанные с доработками функционала или исправлением ошибок);
• Изменения версии 1С:Предприятия, настроек кластера 1С:Предприятия, настроек рабочих серверов, шлюзов, настроек информационной базы;
• Изменения состава, технических характеристик, настроек оборудования, настроек сети, настроек виртуальных машин, настроек операционной системы;
• Изменения типа СУБД, версии СУБД, настроек СУБД, изменения планов обслуживания;
• Расширение состава операций, выполняемых пользователями системы;
• Значительное (более 10%) увеличение числа пользователей системы;
• Добавление новых единиц масштабирования, информационных баз.

Для учета изменений состояния системы вводится понятие «версия системы». Версией системы называется ее состояние в определенный момент времени. Публикацией версии называется ее запуск в рабочую эксплуатацию.

Версии публикуются в соответствии с календарным планом. Внесение изменений в рабочую систему вне процедуры публикации версии не допускается. Иначе говоря, любые изменения могут быть внесены только в одну из следующих запланированных версий.

Основные этапы процедуры публикации новой версии информационной системы:

• Согласование перечня изменений и срока выпуска;
• Разработка новой версии;
• Тестирование новой версии на тестовых стендах и тестовых данных;
• Контроль качества тестовой системы;
• Выпуск;
• Обновление в подготовительной зоне информационной системы;
• Тестирование новое версии в подготовительной зоне на реальных данных;
• Контроль качества системы в подготовительной зоне, контроль качества обновления, времени и ресурсов обновления;
• Обновление рабочей системы;
• Контроль качества рабочей системы.

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

• Код конфигураций информационных баз;
• Версия технологической платформы 1С:Предприятия, конфигурация кластера серверов;
• Тип и версия СУБД, конфигурация СУБД;
• Тип и версия ОС на всех серверах, конфигурация виртуальной и аппаратной среды;
• Актуальные пользовательские данные;
• Настройки приложений;
• Настройки серверов (СУБД, Приложений, Веб);
• Скрипты и планы обслуживания;
• Доступы.

Подготовительный стенд должен содержать полную копию рабочих информационных баз на момент начала подготовки перевода на новую версию.

Организация подготовительного стенда информационной системы

Положение подготовительного стенда информационной системы в эксплуатации рабочей системы

Можно выделить следующие этапы организации подготовительного стенда

• Анализ схемы доступа к внутренним серверам продукционной площадки;
• Выбор схем резервирования инженерных систем;
• Выбор способа синхронизации с рабочей площадкой;
• Анализ требований к оборудованию подготовительной площадки;
• Организация адресации;
• Получение копий виртуальных машин либо конфигурирование машин из шаблонов с кастомизацией, конфигурационных файлов, баз данных с пользовательскими данными;
• Запуск синхронизации с рабочей площадкой (например, готовность автоматического развертывания актуальных бэкапов по команде);
• Организация внесения изменений на подготовительной и рабочей площадке.

Организация автоматического развертывания бэкапов с рабочей системы также позволяет быть уверенными, что бэкапы действительно есть, они собираются, а также могут быть развернуты за определенное время. Кроме того важно, что специалисты группы эксплуатации периодически (по необходимости) восстанавливают из бэкапов подготовительный стенд, таким образом тренируются, что окажется существенным с точки зрения экономии времени в момент возможных пожарных работ в рабочей системе.

Анализ схемы доступа к внутренним серверам продукционной площадки

• Описание сетей рабочей площадки, адресацию;
• Имена серверов рабочей площадки, их адреса;
• Роли серверов;
• ПО, используемое для доступа к серверам;
• Список лиц, имеющих доступ к серверам.

Например, в информационной системе можно обеспечить сегментацию на виртуальные сети

• Управления;
• 1C;
• SQL;

• Рабочая зона;
• Подготовительная зона.

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

Организация рабочего стенда информационной системы

Сheck-list по настройке рабочих серверов в продукционной зоне

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

Какие важные ключевые особенности здесь можно выделить:

• быстрое вхождение новых специалистов;
• больше одного человека понимают, как действительно работает тот или иной механизм в системе;
• шаблоны конфигурации типовые, поэтому отклонения в поведении узлов могут быть выявлены гораздо быстрее;
• упрощение автоматизации;
• высокая скорость встраивания новых фич;
• минимизация требований по ресурсам к подготовительному стенду (в виду типизации конфигурации);
• уменьшенный объем тестирования с возможностью более качественного тестирования меньшего множества конфигураций;
• возможность быстрого расширения.