Технологические вопросы крупных внедрений
13.05.2016
Организация эксплуатации крупной информационной системы
В статье приводится обзор возможной организации эксплуатации крупной информационной системы, построенной с применением технологической платформы 1С:Предприятие.
Общие вопросы
Эксплуатация крупной информационной системы
Эксплуатация крупной информационной системы - это направление, целью которого является минимизация вероятности возникновения проблем качества работы информационной системы на платформе 1С:Предприятие.
Это отдельный вид деятельности, который невозможно не учитывать, и который гарантированно будет показывать обратную связь:
- если ресурсов выделяется достаточно, то система будет работать качественно;
- если ресурсов выделяется недостаточно, то будут периодические сбои и "пожарные" работы по восстановлению.
Рассмотрим построение эксплуатации крупной информационной системы.
В качестве примера будем рассматривать некоторую систему, в которой одновременно работают от 200 (в ночное время) до 1000 пользователей (днем) онлайн. При этом число реально зарегистрированных пользователей может оказаться значительно больше.
Основной задачей специалистов будет обеспечение непрерывной технологически качественной работы информационной системы с учетом необходимого развития информационной системы для соответствия бизнес-требованиям пользователей.
Технологическое качество
Под технологическим качеством подразумевается:
- доступность системы более 99% процентов времени работы системы;
- неухудшение производительности со временем в процессе эксплуатации;
- неухудшение технологических показателей работы системы (например, загруженность оборудования) в результате обновлений на новые версии;
- отсутствие технологических ошибок при выполнении каких-либо операций в системе;
- стабильный адекватный результат при выполнении каких-либо операций в системе.
Здесь не рассматривается функциональное наполнение или соответствие реальным бизнес процессам пользователей, хотя функциональное наполнение является неотъемлемой частью и одной из основных причин необходимости выполнения периодических обновлений программных продуктов системы.
Задачи
Какие задачи встают перед специалистами, которые хотят обеспечить технологическое качество системы с учетом планов по развитию:
- планирование задач;
- администрирование
- рабочей зоны;
- подготовительной зоны;
- зоны разработки;
- эксплуатация рабочей зоны;
- разработка
- необходимого инструментария;
- доработка существующих механизмов;
- автоматизация повторяющихся задач.
В задачи эксплуатации входят:
- Организация первой линии технической поддержки;
- Разбор и классификация обращений;
- Максимально оперативная реакция на обращения пользователей;
- Взаимодействие с пользователями;
- Трансфер собранной и структурированной информации о проблеме второй линии тех поддержки;
- Организация второй линии технической поддержки;
- Разбор обращений и решение технологических проблем;
- Классификация проблем;
- Тестирование и обновление на новые версии решений без ухудшения качества;
- Дежурство и пожарные работы;
- Внесение критичных исправлений для восстановления работы;
- Аудит доп отчетов и обработок;
- Автоматизация повторяющихся задач.
В задачи администрирования входят:
- Развертывание, конфигурирование и обслуживание оборудования;
- Конфигурирование среды виртуализации;
- Конфигурирование сети;
- Конфигурирование кластера серверов 1С;
- Конфигурирование СУБД;
- Регулярное создание бэкапов, хранение и развертывание бэкапов;
- Обеспечение работы с лицензиями, ключами, сертификатами;
- Обновление программных продуктов;
- Развертывание новых нод;
- Автоматизация повторяющихся задач;
- Настройка мониторинга.
В задачи разработки входят:
- Прием в эксплуатацию новых информационных баз и областей
- Доработка конфигураций до возможности перехода в сервис;
- Разработка аналитических отчетов;
- Расширение статистики;
- Разработка механизмов для развития сервиса;
- Разработка механизмов интеграции.
Планирование
Для планирования задач могут использоваться инструменты:
- Менеджер Сервиса;
- Сервис Деск;
- Центр Контроля Качества;
- Jira;
- Документооборот;
- Confluence;
- Skype;
- и другие.
Зоны системы
Зоны информационной системы:
- Рабочая зона информационной системы;
- Подготовительная зона информационной системы;
- Зона тестирования продукта;
- Зона разработки продукта.
При этом изменения в продукционную зону могут попадать только следующим путем:
- Серверы разработки продукта;
- Серверы тестирования продукта;
- Подготовительные серверы системы;
- Продукционные серверы системы.
Отличия зоны тестирования продукта от подготовительной зоны информационной системы:
- в зоне тестирования продукта тестируется продукт перед выпуском на тестовых данных на основных сценариях работы с этим продуктом;
- в подготовительной зоне тестируется информационная система в сборе в том виде, в котором она будет работать в продуктиве;
- подготовительная зона информационной системы и рабочая зона информационной системы не являются зонами тестирования одного или нескольких продуктов, эти зоны нужны для обеспечения технологического качества работы конкретной информационной системы;
- зону тестирования продукт проходить до выпуска, в том время как в подготовительную зону попадают только выпущенные продукты, имеющие уникальный номер версии, а также дату и время выпуска.
Важно отметить, что в зависимости от того, насколько клиент готов нести затраты на обслуживание системы, зависит то, насколько указанная выше схема "ложится" на реальную систему клиента.
Например, могут рассматриваться варианты совмещения зон.
Вариант 1:
- Рабочая зона;
- Подготовительная и тестовая зона;
- Зона разработки продукта.
Здесь объединяется подготовительная и тестовая зона, при этом качество тестирования непосредственно перед обновлением в продуктиве напрямую зависит от качества соответствия подготовительной зоны рабочей зоне.
При этом зона разработки продукта, например, может вообще отсутствовать, если продукт не изменяется и не разрабатывается специалистами клиента. Т.е. процесс разработки продукта полностью отделен от рабочей информационной системы.
Вариант 2:
- Рабочая зона;
- Подготовительная зона;
- Зона разработки и тестирования.
Такой вариант может применяться в случае, когда доработка продукта носит незначительный характер и практически не изменяет поведение и характеристики продукта. Тем не менее, разработка не происходит в информационной системе в рабочих или подготовительных зонах.
Что не следует делать
Совершенно точно не следует совмещать рабочую зону с подготовительной зоной, т.к. по сути новая версия системы будет "собираться" именно в продуктиве. Такой подход имеет повышенный риск сбоев в результате обновлений.
Не стоит совмещать подготовительную зону и зону разработки. В этом случае появляется риск утечки данных, т.к. доступ к данным пользователей появляется у разработчиков.
Не следует совсем отказываться от использования тестовой и подготовительной зоны, т.к. в этом случае тестирование, отладка, расследование проблем будет происходить на пользователях.
В этом случае страдает бизнес клиента, а от пользователей постоянно поступает негатив. Также стоит отметить, что после каждого такого обновления, нужного бизнесу, без тестирования в тестовой и подготовительной зонах, происходит период нестабильной работы системы, т.к. по сути это и является периодом опытно-промышленной эксплуатации, в котором тестирование происходит на пользователях.
Что имеет смысл сделать
Если рабочая зона имеет типовую организацию и имеет несколько единиц масштабирования, например, по технологии 1cfresh, имеет смысл "разбить" рабочую зону на несколько и обновлять по частям.
Сначала стоит обновить наиболее маленькую часть. Затем, если система после обновления в продуктиве работает без сбоев, имеет смысл приступить к обновлению всей рабочей зоны.
Подготовительную зону имеет смысл развертывать скриптами, которые применяются для целей автоматизации, из бэкапов с рабочей зоны. Таким образом будет гарантироваться, что подготовительная зона максимально приближена к рабочей зоне.
При этом, вы будете уверены, что:
- у вас всегда есть актуальная копия системы (базы данных, настроек) на нужный вам момент времени, и вы совершенно точно в состоянии её развернуть;
- скрипты автоматизации работают без сбоев;
- бэкапы создаются без сбоев и их действительно можно использовать;
- вы периодически тренируете навык восстановления системы "с нуля";
- известно достаточно точное время развертывания и создания единицы масштабирования с нуля.
Стоит продумать возможность перевода оборудования из подготовительной зоны в рабочую на случай непредвиденных аварий.
Имеет смысл также организовать и иметь полный удаленный доступ в рабочую и подготовительную зоны. При этом такой доступ:
- Должен быть только у ограниченного известного круга лиц;
- Максимально защищен.
Удаленного доступа может не быть к зоне разработки и тестирования продукта. Продукт может нести особенную ценность для организации, в т.ч. с точки зрения обеспечения безопасности, а открытие доступа создает риск не только утечки исходного кода, но и открывает дополнительные возможности злоумышленникам в тех системах, где продукт используется. (Не раскрываем эту тему в текущей статье). К тому же как правило нет задачи поддерживать, например, uptime серверов разработки на уровне 99% и выше удаленно, разработчики обычно сами в состоянии это сделать со своих рабочих мест. В некоторых случаях (например, географической удаленности) существует задача обеспечения доступности системы сборки и тестирования, тогда такой доступ может быть организован.
Автоматизация
В случае использования множества серверов в рабочей и подготовительной зонах имеет смысл заранее подготовить шаблоны машин, из которых будут разворачиваться и конфигурироваться типовые единицы масштабирования.
Такие шаблоны в минимальном виде могут быть:
- Шаблон рабочего сервера;
- Шаблон сервера СУБД;
- Шаблон веб сервера.
Но только шаблонов не достаточно для решения задачи быстрого развертывания единиц масштабирования информационной системы. Существенной частью этой задачи является автоматизация.
Особое внимание можно обратить на подготовку следующих "механизмов":
- Скрипты по донастройке сервера до заданных параметров;
- Автоматизация развертывания баз;
- Настройка и применение групповых политик;
- Автоматизация запуска, остановки служб;
- Автоматизация установки Платформы, СУБД;
- Автоматизация развертывания виртуальных машин из шаблонов в заданной конфигурации.
Организация эксплуатации
Регламенты, необходимые для организации процесса эксплуатации:
- Дежурство
- Расписание, которое все видят и знают;
- В каждый момент времени есть один ответственный за максимальную реакцию на входящие критичные заявки;
- Реакция на мониторинг;
- Разбор входящих проблем;
- Разбор задач по автоматизации и доработкам;
- Организация доступов;
- Изменения в рабочей зоне;
-
- План обновлений;
- Check-листы
- По тестированию в тестовой зоне;
- По обновлению и проверке результатов обновления в подготовительной зоне;
- По обновлению в рабочей зоне;
- Журнал всех изменений;
- Организация приемки новых баз и областей;
- Организация приемки дополнительных отчетов и обработок;
- SLA
- c ЦОД;
- с провайдерами;
- для группы эксплуатации.
Ниже приводится схема (рисунок можно открыть в отдельном окне, либо на нее можно нажать левой кнопкой мыши) с принципиальным общим видом организации крупной информационной системы.
Схема не учитывает специфику организации бизнеса конкретного клиента.
Схему можно применять для того, чтобы понять, какие стороны вопроса эксплуатации действительно хорошо проработаны в вашей организации на вашем проекте, а какие стороны вопросы не проработаны совсем (как следствие, возможны риски).
Важно учитывать, что построение эксплуатации крупной информационной системы не возможно без выращивания команды специалистов, которые думают в одном направлении, заинтересованы.
Команда должна понимать одинаково, что команда должна получить от информационной системы в будущем.
Основная ценность - команда, решающая задачи эксплуатации, администрирования и разработки.
Важно учитывать:
- команда смотрит в одном направлении и понимание в целом
- что является наиболее критичным для сервиса
- что является наиболее срочным для сервиса
- что является наиболее важным для сервиса
- нет таких знаний о сервисе, которые известны только одному участнику, и не известны никому более
- такая проблема решается наличием:
- базы знаний;
- журналами изменений;
- check-листами;
- отработкой задач на подготовительном стенде;
- конфигурация нод, серверов, программных продуктов - "типовая", т.е. одинаковая, документированная для данной информационной системы;
- конфигурируются и описываются конкретные единицы масштабирования;
- все изменения отражаются во всех существующих единицах масштабирования;
- исключений либо нет, либо их число постоянно сознательно целенаправленно минимизируется;
- горизонтально сервис масштабируется только типовыми нодами;
- вертикальное масштабирование возможно только в рамках одной ноды до момента, пока не будет достигнут некоторый заранее определенный лимит ресурсов для ноды, затем создается новая единица масштабирования;
- каждый участник команды эксплуатации должен иметь опыт работы на различных задачах
- обновления и тестирования;
- дежурство;
- автоматизации;
- аудита;
- по каждой проблеме обязательно должен быть разбор, в котором решается
- что было сделано не правильно;
- как нужно сделать, чтобы такая проблема не повторилась в будущем;
- все участники эксплуатации должны быть в курсе текущих критичных проблем;
- это решается журналом изменений и еженедельной отчетностью;
- общий чат позволяет решить проблему информированности, когда в таком чате отмечаются:
- пожарные решения проблем;
- обновления или изменения в рабочей зоне;
Под проблемами качества работы системы подразумеваются проблемы работоспособности, устойчивости и производительности системы.
Под изменениями рабочей системы подразумеваются любые изменения программного, аппаратного, организационного или инфраструктурного уровней системы, включая, но не ограничиваясь, следующими изменениями:
- Любые изменения кода конфигурации системы (в том числе связанные с доработками функционала или исправлением ошибок);
- Изменения версии 1С:Предприятия, настроек кластера 1С:Предприятия, настроек рабочих серверов, шлюзов, настроек информационной базы;
- Изменения состава, технических характеристик, настроек оборудования, настроек сети, настроек виртуальных машин, настроек операционной системы;
- Изменения типа СУБД, версии СУБД, настроек СУБД, изменения планов обслуживания;
- Расширение состава операций, выполняемых пользователями системы;
- Значительное (более 10%) увеличение числа пользователей системы;
- Добавление новых единиц масштабирования, информационных баз.
Для учета изменений состояния системы вводится понятие «версия системы». Версией системы называется ее состояние в определенный момент времени. Публикацией версии называется ее запуск в рабочую эксплуатацию.
Версия системы имеет уникальный номер и описание: дату публикации и перечень новых значений всех параметров системы, изменившихся по сравнению с предыдущей версией. Версии системы нумеруются по возрастанию – более поздние версии имеют большие номера.
Версии публикуются в соответствии с календарным планом. Внесение изменений в рабочую систему вне процедуры публикации версии не допускается. Иначе говоря, любые изменения могут быть внесены только в одну из следующих запланированных версий.
Версия по сути описывает совокупное состояние системы, которое имеет смысл сравнивать с другим состоянием, используемым при следующем обновлении.
Основные этапы процедуры публикации новой версии информационной системы:
- Согласование перечня изменений и срока выпуска;
- Разработка новой версии;
- Тестирование новой версии на тестовых стендах и тестовых данных;
- Контроль качества тестовой системы;
- Выпуск;
- Обновление в подготовительной зоне информационной системы;
- Тестирование новое версии в подготовительной зоне на реальных данных;
- Контроль качества системы в подготовительной зоне, контроль качества обновления, времени и ресурсов обновления;
- Обновление рабочей системы;
- Контроль качества рабочей системы.
Для целей обеспечения качества новых версий информационной создается подготовительный стенд. Подготовительный стенд должен соответствовать рабочей системе по следующим параметрам:
- Код конфигураций информационных баз;
- Версия технологической платформы 1С:Предприятия, конфигурация кластера серверов;
- Тип и версия СУБД, конфигурация СУБД;
- Тип и версия ОС на всех серверах, конфигурация виртуальной и аппаратной среды;
- Актуальные пользовательские данные;
- Настройки приложений;
- Настройки серверов (СУБД, Приложений, Веб);
- Скрипты и планы обслуживания;
- Доступы.
Подготовительный стенд должен содержать полную копию рабочих информационных баз на момент начала подготовки перевода на новую версию.
Сотрудники группы эксплуатации проводят на тестовой версии ряд тестов, включая функциональные и нагрузочные (многопользовательские) тесты. Выполняются все тесты, которые выполнялись перед публикацией предыдущей версии. Тесты могут быть доработаны (расширены) по решению группы эксплуатации на основании анализа состава планируемых изменений, а также проблем, возникших в рабочей зоне системы за прошедшее время.
Организация подготовительного стенда информационной системы
Положение подготовительного стенда информационной системы в эксплуатации рабочей системы
- Рабочие серверы информационной системы:
- Запрещена отладка;
- Пользовательские данные;
- Обновление только с использованием check-листов по заранее согласованному плану;
- Настроен мониторинг;
- Доступ только у группы эксплуатации;
- Подготовительные серверы информационной системы:
- Разрешена отладка;
- Пользовательские данные;
- Все изменения фиксируются;
- Контроль обновления и работы на новых версиях продуктов, контроль потребления ресурсов на новых версиях;
- Настроен мониторинг;
- Доступ только у группы эксплуатации;
- Серверы тестирования продукта:
- Разрешена отладка;
- Тестовые данные;
- Изменения вносятся постоянно;
- Настроен мониторинг;
- Доступ у разработчиков
- Серверы разработки продукта:
- Разрешена отладка;
- Тестовые данные;
- Изменения вносятся постоянно;
- Мониторинг может отсутствовать;
- Доступ у разработчиков.
Можно выделить следующие этапы организации подготовительного стенда
- Анализ схемы доступа к внутренним серверам продукционной площадки;
- Выбор схем резервирования инженерных систем;
- Выбор способа синхронизации с рабочей площадкой;
- Анализ требований к оборудованию подготовительной площадки;
- Организация адресации;
- Получение копий виртуальных машин либо конфигурирование машин из шаблонов с кастомизацией, конфигурационных файлов, баз данных с пользовательскими данными;
- Запуск синхронизации с рабочей площадкой (например, готовность автоматического развертывания актуальных бэкапов по команде);
- Организация внесения изменений на подготовительной и рабочей площадке.
Организация автоматического развертывания бэкапов с рабочей системы также позволяет быть уверенными, что бэкапы действительно есть, они собираются, а также могут быть развернуты за определенное время. Кроме того важно, что специалисты группы эксплуатации периодически (по необходимости) восстанавливают из бэкапов подготовительный стенд, таким образом тренируются, что окажется существенным с точки зрения экономии времени в момент возможных пожарных работ в рабочей системе.
Синхронизация с рабочей площадкой должна проходить в автоматическом режиме и не должна отличаться от механики восстановления данных на продукционной системе в случае аварии.
Анализ схемы доступа к внутренним серверам продукционной площадки
Первым обязательным этапом организации подготовительного стенда является анализ схемы доступа к внутренним серверам продукционной площадки. Результатам анализа является документ, включающий в себя:
- Описание сетей рабочей площадки, адресацию;
- Имена серверов рабочей площадки, их адреса;
- Роли серверов;
- ПО, используемое для доступа к серверам;
- Список лиц, имеющих доступ к серверам.
Важным шагом этого этапа является составление описания сетей рабочей площадки, т.к. в подготовительном площадке должна полностью сохраниться адресация. Т.е. сами виртуальные машины не должны знать, где именно они находятся: в рабочей зоне или в подготовительной. Все виртуальные машины должны быть настроены по аналогии с рабочей зоной (может, конечно, меняться фон рабочего стола. Например, для рабочей зоны фон рабочего стола красный с именем ноды и информацией из bginfo, а для подготовительной зоны фон зеленый с именем ноды и информацией bginfo).
Например, в информационной системе можно обеспечить сегментацию на виртуальные сети
и две зоны:
- Рабочая зона;
- Подготовительная зона.
Т.к. настройки адресации на подготовительном стенде остаются полностью такими же, как и в рабочей зоне, отличием от продукционного стенда может служить отсутствие интернета на подготовительном стенде.
Также доступ в интернет с подготовительного стенда следует закрывать, чтобы не было случайных рассылок реальным пользователям о возможных недоступностях, о регламентных работах или о нововведениях в подготовительной зоне сервиса.
Организация рабочего стенда информационной системы
Сheck-list по настройке рабочих серверов в продукционной зоне
http://kb.1c.ru/articleView.jsp?id=88
Организация стенда
При организации рабочей зоны очень важно не получить систему с сотнями тайных связей
Очень важно, чтобы конфигурация рабочей системы была максимально типовой, строилась из очень простых единиц масштабирования с минимизацией связей с другими единицами.
В процессе эксплуатации могут возникать желания доработки и развития системы. Очень важно в процессе таких доработок сознательно стремиться к упрощению существующей конфигурации.
Какие важные ключевые особенности здесь можно выделить:
- быстрое вхождение новых специалистов;
- больше одного человека понимают, как действительно работает тот или иной механизм в системе;
- шаблоны конфигурации типовые, поэтому отклонения в поведении узлов могут быть выявлены гораздо быстрее;
- упрощение автоматизации;
- высокая скорость встраивания новых фич;
- минимизация требований по ресурсам к подготовительному стенду (в виду типизации конфигурации);
- уменьшенный объем тестирования с возможностью более качественного тестирования меньшего множества конфигураций;
- возможность быстрого расширения.
Например, организация рабочей зоны по технологии 1cfresh предполагает нодовую структуру развертывания информационной системы.
Регламенты
Организация внесения изменений на подготовительной и рабочей площадке
Вводится правило: все изменения в рабочую систему вносятся через подготовительную площадку информационной системы.
Сначала изменения попадают на подготовительный стенд, затем на рабочий стенд.
Существует только одно исключение из этого правила: изменения в рабочую систему могут вноситься, минуя подготовительный стенд только в экстренных случаях.
По окончанию аварийных работ в ночное время стенд должен быть синхронизирован с рабочей зоной, чтобы устранить разницу в привнесенных изменениях.
Изменяться состояние подготовительного стенда может следующими способами:
- Развертывание backup-ов;
- Развертывание копий машин;
- С подготовкой check-листов;
- Небольшие изменения без подготовки check-листов, но обязательным записью в журнал регистрации проведенных работ.
Изменяться состояние рабочего стенда может следующими способами:
- По check-листам;
- В случае аварийных работ при недоступности рабочей системы;
- Перенос небольших изменений с подготовительного стенда с записью в журнал регистрации проведенных работ.
Check-лист готовится заранее при выполнении изменений на подготовительном стенде.
Перед применением изменений на рабочей площадке check-листы распечатываются и передаются каждому участнику плановых работ.
Синхронизация участников выполняется оперативно по телефону или чату.
Журнал регистрации проведенных работ – специальный документ, который ведут все участники эксплуатации рабочий и подготовительной системы. В бортовой журнал попадают записи, отражающие все изменения в очень сжатой форме. Цель бортового журнала – в случае аварии быстро определить, кто и когда вносил изменения.
Пример записи в журнале регистрации проведенных работ:
2014-01-01 Администратор1 <admin_petr@1c.ru> +79871234567
* server1c-1
- поправил com connector, выполнив команду из rdp сеанса C:\1C\current\regsvr32 comcntr.dll
---------------------------------------------------------------------------------------------------------------------------------------
Контроль качества работы подготовительного стенда
Во время тестирования разработчики контролируют показатели качества работы системы и сравнивают их с аналогичными показателями, полученными при тестировании предыдущей версии. Если показатели новой версии ухудшились по сравнению с предыдущей версией, то принимается согласованное решение о дальнейших действиях. Ответственные за эксплуатацию информационной системы договариваются либо отложить выпуск до исправления проблем качества, либо опубликовать версию, не смотря на наличие проблем.
После исправления проблемы необходимо провести повторное контрольное тестирование.
Публикация в рабочей зоне
Версия, успешно прошедшая тестирование в подготовительной зоне, публикуется в рабочей системе в соответствии с планом публикации версий и check-листами, которые были подготовлены на подготовительном стенде.
Время выполнения обновления, а также особенности обновления фиксируются и сравниваются с результатами полученными в подготовительной среде.
Отличия в поведении систем в подготовительной и рабочей зонах фиксируются и расследуются с целью устранения.
Версия, не прошедшая процедуру тестирования не может быть опубликована в рабочей зоне.
В случае внесения исправлений в версию, номер версии поднимается.
Контроль качества рабочей системы
Группа эксплуатации ведет постоянный контроль качества рабочей системы. Если какие-либо показатели качества работы текущей версии оказываются хуже, чем у предыдущей версии, то принимается согласованное решение об устранении проблемы. Стороны договариваются либо об отказе использования текущей версии и откате на предыдущую версию, либо о продолжении работы не смотря на существующие проблемы.
Допустимым временем простоя системы при откате на предыдущую версию считается 10 минут.
При выявлении проблем в рабочей системе может быть принято решение о доработке тестов таким образом, чтобы в следующий раз подобная ошибка была выявлена на стадии тестирования.
Для качественного контроля за рабочей системой необходимо настраивать мониторинг.
Методики по настройке мониторинга можно найти в статье "Мониторинг на продукционных серверах"
Также инструкция по настройке мониторинга с помощью Центр Контроля Качества.