Рекомендации по процессу обновления системы DIRECTUM у крупных заказчиков

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

Подготовка к работам по обновлению

«Кто приготовился к бою, тот его наполовину выиграл». (М. де Сервантес)

1. Соберите команду обновления

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

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

2. Внимательно и тщательно сами ознакомьтесь с документацией с изменениями и требованиям к ПО на новой версии и донесите информацию до заказчика

У крупных заказчиков большой парк клиентских машин и серверов и чаще всего на них установлены разные версии программных продуктов.

Заострите внимание на требованиях к аппаратному и программному обеспечению новой версии.

3. Проработайте вопрос модификации системы во время работ по подготовке пакета конвертации

В системах крупных заказчиков, как правило, модификация системы ведется и после окончания проекта внедрения, и также после окончания проекта внедрения на серверах заказчика остается и развернутый тестовый ландшафт (или специалисты заказчика сами разворачивают), на котором ведется реализация и тестирование модификаций.

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

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

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

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

4. Проработайте план распространения клиентского ПО на рабочие места пользователей

В рамках составления плана обновления клиентских мест проработайте вопрос гарантии распространения клиентского ПО на новой версии. Чем больше пользователей в системе, тем больше вероятность, что ПО стандартными средствами не распространится.

Сборка пакета конвертации

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

5. Составьте список нестандартных объектов SQL со списком прав доступа к ним

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

6. Проанализируйте скрипт переиндексации

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

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

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

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

Тестирование

«Не верь – проверь!» – девиз тестировщика.

7. Проводите тестирование сконвертированной (тестовой) базы консультантами

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

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

8. Не бойтесь отходить от тест-планов во время тестирования

Часто для тестирования сложных бизнес-процессов пишутся тест-планы, которые покрывают лишь стандартный набор действий пользователя. Большая часть пользователей отходит от стандартного набора действий, вот здесь и есть большая вероятность получить неприятную «картину».

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

9. Проводите нагрузочное тестирование системы

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

Документирование этапов обновления

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

10. Фиксируйте длительность основных операций во время подготовки пакета конвертации и тестовой конвертации

Во время конвертации базы логи утилиты конвертации пишутся в файл STConverter.log с фиксацией времени начала и окончания этапа. Для определения сроков рабочей конвертации необходимо фиксировать и анализировать время выполнения операций во время подготовки пакета конвертации и тестовой конвертации.

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

11. Составьте подробный план работ во время проведения рабочей конвертации

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

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

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

Репетиция продуктивного обновления

«75 процентов того, что делается на репетиции, обычно не входит в спектакль». (К.С. Станиславский)

12. Репетируйте!

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

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

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

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

Проведение продуктивной конвертации и поддержка тестирования после продуктивного обновления

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

Homo sum, humani nihil a me alienum puto (лат.) – у всех участников команды обновления могут случиться форс-мажорные ситуации, чтобы в процессе конвертации не образовалось узких мест по причине отсутствия специалиста, чьи работы не может выполнить никто другой, необходимо обеспечить взаимозаменяемость основных специалистов, как со стороны команды обновления, так и со стороны заказчика.

15. Проработайте вопрос оперативного оповещения участников команды обновления

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

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

При выборе инструмента оповещения нужно руководствоваться критериями:

• Количество участников команды.

Пример: если вы решили, что почта – отличный инструмент оперативного оповещения участников, но у некоторых почтовых серверов есть ограничение по количеству участников в рассылке.

• Доступность инструмента всем участникам команды.

Пример: вы решили, что отличным инструментом может стать приложение VoIP-телефонии, поддерживающее и возможность совершения звонков, и возможность передавать текстовые сообщения, в том числе создавать общие беседы со всеми членами команды (взамен тем же сотовым телефонам), то есть вероятность, что у некоторых участников до сих пор может не быть безлимитного интернета и/или телефона, удовлетворяющего характеристикам приложения.

• Надежность инструмента и пр.

16. Проводите оповещение руководства заказчика о ходе конвертации

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

17. Привлекайте на продуктивную конвертацию и поддержку ОПЭ специалистов службы поддержки DIRECTUM

Как правило, конвертация обычно проводится в выходные или праздничные дни, а самый напряженный период после обновления – первая неделя ОПЭ. В этот период находятся все ранее не обнаруженные тестировщиками замечания к работе системы на новой версии.

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

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

18. Проводите мониторинг системы после обновления

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

В чем заключается мониторинг? Нужно следить за состоянием основных показателей серверов, в т.ч. сервера СУБД: счетчики, длительность основных операций, также нужно мониторить логи клиентских частей по объему в них зафиксированных ошибок до проведения конвертации и после проведения.

Для анализа требуется статистика как минимум 2 типовых дней работы в системе.