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

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

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

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

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

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

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

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

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

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

Задачи

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

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

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

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

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

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

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

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

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

Зоны системы

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

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

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

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

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

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

Вариант 1:

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

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

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

Вариант 2:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Дежурство
  • Расписание, которое все видят и знают;
  • В каждый момент времени есть один ответственный за максимальную реакцию на входящие критичные заявки;
  • Реакция на мониторинг;
• Разбор входящих проблем;
• Разбор задач по автоматизации и доработкам;
• Организация доступов;
• Изменения в рабочей зоне;
• • План обновлений;
  • Check-листы
    • По тестированию в тестовой зоне;
    • По обновлению и проверке результатов обновления в подготовительной зоне;
    • По обновлению в рабочей зоне;
  • Журнал всех изменений;
• Организация приемки новых баз и областей;
• Организация приемки дополнительных отчетов и обработок;
• SLA
  • c ЦОД;
  • с провайдерами;
  • для группы эксплуатации.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Рабочие серверы информационной системы:
  • Запрещена отладка;
  • Пользовательские данные;
  • Обновление только с использованием check-листов по заранее согласованному плану;
  • Настроен мониторинг;
  • Доступ только у  группы эксплуатации;
• Подготовительные серверы информационной системы:
  • Разрешена отладка;
  • Пользовательские данные;
  • Все изменения фиксируются;
  • Контроль обновления и работы на новых версиях продуктов, контроль потребления ресурсов на новых версиях;
  • Настроен мониторинг;
  • Доступ только у группы эксплуатации;
• Серверы тестирования продукта:
  • Разрешена отладка;
  • Тестовые данные;
  • Изменения вносятся постоянно;
  • Настроен мониторинг;
  • Доступ у разработчиков
• Серверы разработки продукта:
  • Разрешена отладка;
  • Тестовые данные;
  • Изменения вносятся постоянно;
  • Мониторинг может отсутствовать;
  • Доступ у разработчиков.

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

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

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

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

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

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

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

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

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

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

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

Организация стенда

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

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

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

Регламенты

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

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

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

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

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

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

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

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

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

  * server1c-1

---------------------------------------------------------------------------------------------------------------------------------------

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

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

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

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

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

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

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

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

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