Меня зовут Екатерина, я возглавляю департамент информационных систем в Иркутской нефтяной компании. Сегодня я расскажу вам, как мы навели порядок в процессе выпуска обновлений в наших информационных базах.
Мой доклад будет построен следующим образом.
- Сначала я расскажу о компании, в которой я работаю.
- Затем - о нашей собственной разработке – о системе, которую мы назвали Service Desk.
- Потом мы с вами поговорим непосредственно о формировании релиза.
- После этого будет несколько слов о результатах внедрения.
- И в конце расскажу о перспективах развития нашей системы.
О компании
Иркутская нефтяная компания – одна из крупнейших независимых нефтегазодобывающих компаний в России.
- Она насчитывает более 8000 сотрудников, и по прогнозам через пять лет нас будет уже не менее 15 тысяч.
- Деятельность компании представлена в Восточной Сибири. Это – Иркутская область, республика Саха, Якутия, а также Красноярский край.
- Количество информационных баз, используемых в режиме промышленной эксплуатации, исчисляется десятками. В них работает более 1000 пользователей, и это число постоянно растет. Также есть крупные базы на платформе 1С, которые включают в себя несколько функциональных блоков.
Задача моего департамента – обеспечить сопровождение и развитие существующих систем, а также внедрить новые информационные системы.
В департаменте информационных систем есть три отдела:
- отдел сопровождения, который является первой линией поддержки пользователей;
- отдел внедрения информационных систем – в нем работают консультанты;
- и отдел разработки, в котором трудятся сами программисты, которых в народе называют «кодерами».
Система Service Desk
Ни для кого не секрет, что базы периодически нужно обновлять. Какие-то базы обновляются чаще, какие-то – реже, но в целом такое событие, как выпуск релиза, для нашей компании весьма частое явление. Раньше разработчики тратили кучу времени на сбор релизов, установку, потом на сбор исправительных релизов, так как «что-то лишнее зацепили» или наоборот «не обновили какой-то нужный объект».
Теперь механизм управления релизами реализован в нашей системе «Service Desk». Но обо всём по порядку!
В далёком 2014-м году проблем с релизами у нас не было, компания была намного меньше и баз было не более 5.
Но в какой-то момент мы осознали потребность упорядочить процесс работы с обращениями пользователей в рамках сопровождения этих баз.
И тогда у нас возникла идея быстренько накидать функционал, который позволил бы пользователям регистрировать свои обращения, отслеживать их статус, а нам в порядке очередности обрабатывать эти обращения.
В пустой конфигурации на платформе 1С мы быстренько накидали требуемый функционал, который состоял из одного документа «Обращение» и назвали систему «Service Desk».
Система быстро стала популярной в компании, и с тех пор её функционал нами расширялся и совершенствовался.
На данный момент в этой системе реализован механизм управления релизов.
Если не вдаваться глубоко в детали, механизм создания релиза следующий:
- Сначала в систему «Service Desk» поступает обращение от пользователя по вопросам работы в той или иной системе.
- Если вопрос на 1-ой линии не решился и выявлена необходимость внесения изменений в алгоритмы работы системы, то вопрос передаётся на вторую линию для формирования постановки задачи на разработку и, собственно, самой разработки. На этом этапе создаётся документ «Доработка».
- В конечном итоге доработки объединяются в релиз, который устанавливается на рабочую базу.
Формирование релиза
Расскажу о процессе формирования релиза более подробно.
Документ «Обращение» – очень простой, в нем нет ничего сложного:
- его основной реквизит – это «Статус»;
- и главное поле «Описание обращения» – здесь простым человеческим языком написано то, что хочет пользователь.
Прежде чем перейти к следующему документу «Доработка» я немного расскажу о структуре баз и хранилищ конфигураций в нашей компании.
У каждой информационной системы есть два хранилища. Мы их называем «Тестовое» и «Релизное».
- К тестовому хранилищу подключены тестовые базы консультантов и разработчиков. Разработчики вносят изменения в конфигурации в свои базы, а консультанты тестируют работу программистов.
- Затем в процессе подготовки обновления разработчики помещают изменения из своих тестовых баз в свои так называемые релизные базы. Каждый разработчик имеют свою базу для каждой системы, и все эти базы подключены к релизному хранилищу.
- В итоге в релизном хранилище оказываются доработки всех разработчиков для установки релиза.
- Сама рабочая база также подключена к релизному хранилищу и обновляется непосредственно из релизного хранилища, в котором происходит окончательный сбор релиза.
Также хочу заметить, что наша система Service Desk содержит информацию о конфигурациях систем. Она берет эту информацию непосредственно из тестовых хранилищ, так как в тестовых хранилищах есть абсолютно все изменения, которые разработчики вносят в систему – даже те, которые еще не планируются к установке на рабочую базу.
Перейдем к документу «Доработка». Этот документ намного более функционален, чем документ «Обращение», и создается на его основании.
- Изначально документ «Доработка» создается в статусе «Зарегистрировано», и с ним начинают работать консультанты по внедрению информационной системы. В результате на вкладке «Описание» формируется описание задачи непосредственно на техническом языке для разработчика.
- После того как консультант поставил задачу разработчику, он отправляет документ «Доработка» в статус «В разработке», и тогда уже исполнителем по доработке становится непосредственно программист. Разработчик вносит изменения в свою тестовую базу и помещает их в тестовое хранилище. Как я говорила ранее, структура тестового хранилища выгружается в систему Service Desk.
- В процессе своей работы программист на вкладке «Измененные объекты» галочками отмечает те объекты конфигурации, которые он изменил в процессе доработки. Это некий организационный момент – разработчик должен вручную поставить эти галочки. Кроме галочек он может указать комментарий – например, в какую процедуру или функцию вносились изменения, а также любую другую информацию.
- А также есть правило – когда разработчик вносит в конфигурацию изменения кода, он обязательно комментирует, и комментарий содержит номер доработки, в рамках которого происходит изменение, и также автора, который внес эти изменения.
- И при помещении в тестовое хранилище измененных объектов также в комментарии обязательно указывается номер доработки. Вся эта информация значительно облегчает сбор релизов в дальнейшем. Сейчас я скажу, как.
- После того, как разработчик внес изменения в конфигурацию, он передает доработку в тестирование консультанту.
- Вообще с документом «Доработка» по очереди работают консультант и программист, гоняя его по разным статусам – «В уточнении», «В тестировании», снова «В разработке». Чаще всего документ принимает статус «В разработке» несколько раз, и каждый раз при изменении объектов разработчик дозаполняет вкладку «Измененные объекты» новыми объектами, которые он меняет. Таким образом, доработка хранит в себе всю информацию об измененных объектах конфигурации в ходе ее выполнения.
Перекидывание доработки между статусами происходит до тех пор, пока консультант не примет изменения и у него не останется замечаний к разработчику. После того, как это происходит, консультант должен заполнить вкладку «Информация о релизе».
Вкладка «Информация о релизе» содержит три раздела:
- «Описание релиза» – здесь содержится информация для пользователей на простом человеческом пользовательском языке о том, что изменилось в системе
- «Список адресов» – это адреса пользователей, которые получат информацию об обновлении.
- «Изменяемые инструкции» – здесь консультант вносит изменения в файлы инструкций, которые необходимо обновить после того, как изменения будут установлены на рабочую базу.
После того, как консультант заполнит всю необходимую информацию о доработке, он переводит доработку в статус «К помещению в рабочую базу».
Как только доработка попала в этот статус, исполнителем по ней снова становится разработчик. Но он не работает дальше с документом «Доработка» до тех пор, пока эта доработка не попадет в документ «Релиз».
Таким образом, мы с вами подошли к главному документу моего сегодняшнего доклада – документу «Релиз».
В зависимости от типа релиза он появляется разными способами:
- плановый релиз создается автоматически регламентным заданием по расписанию;
- другие виды релизов формируются консультантами.
Что нужно заполнить в релизе? Минимальные данные – это плановая дата установки релиза и набор тех доработок, которые должны войти в этот релиз (из числа доработок в статусе «К помещению в рабочую базу»). Все остальные вкладки, которые есть в этом документе, заполняются автоматически на основании тех данных, которые имеются во включенных в этот релиз «Доработок». Например, вкладка «Информация о релизе» формируется из описаний релиза в «Доработках» – это информация, которая будет в рассылке при установке релиза.
После того как документ «Релиз» переходит в статус «Согласован», разработчики начинают работать каждый со своей доработкой – переносить изменения по ним в релизное хранилище.
Используя вкладку «Измененные объекты», разработчики должны перенести в релизные базы те изменения, которые должны войти в релиз. Каждый разработчик переносит изменения только по выполненным им доработкам. Так как все релизные базы подключены к одному релизному хранилищу, изменения в общие объекты программистам приходится вносить по очереди.
На вкладке «Измененные объекты» есть вся информация об измененных объектах всех доработок, которые вошли в документ «Релиз». Эта вкладка имеет два представления.
Первое представление, которое вы видите на экране (со снятой галочкой «По доработкам») – это представление, которое показывает изменения в разрезе структуры конфигурации:
- Здесь есть столбец «К установке», где содержатся номера доработок, которые вошли в этот релиз.
- Также здесь есть столбец «Не устанавливать». Здесь фигурируют те доработки, которые не должны попасть в релиз, но по которым на данный момент в системе есть изменения конфигурации именно в части этого объекта. Они подсвечены розовым цветом, и разработчик, когда помещает изменения в свою релизную базу, должен обратить внимание, что эти объекты конфигурации нельзя полностью заменить, их нужно проанализировать, вычленить из них те изменения, которые сделаны в рамках этой доработки, и внести только их. Те объекты, которые не подсвечены розовым, разработчик может полностью заменять.
Это представление удобно использовать для тех релизов, в которых принимал участие только один разработчик. Оно удобно в этом случае.
Второй вид (при установленной галке «По доработкам») удобно использовать, если в релизе принимали участие несколько разработчиков – когда идет обновление баз, где много функциональных блоков.
Это представление помогает разработчику перенести изменения только по своим доработкам, абстрагируясь от изменений, сделанных его коллегами – т.е. каждый разработчик вносит изменения только по своим доработкам.
Т.к. все базы прикреплены к одному релизному хранилищу, то разработчики вносят эти изменения последовательно:
- После того, как разработчик внес изменения в релизную базу, он переводит доработку в статус «В релизном хранилище».
- Только после того, как все доработки перешли в этот статус, документ «Релиз» переходит в статус «Готов к установке».
- Затем строго по расписанию, которое было указано в документе, происходит обновление из релизного хранилища рабочей базы. Оно происходит в одной транзакции – в один момент документ «Релиз» переходит в статус «Установлен», и все доработки, которые в него включены, а также обращения, на основании которых созданы эти доработки, переходят в статус «Выполнено». Происходит автоматическое обновление инструкций для пользователей. И автоматически происходит рассылка с информацией об обновлении.
Эффекты от внедрения
Что мы получили благодаря реализованному механизму?
Возможно, для небольшой компании, где два разработчика и пять информационных баз, это все неактуально – у них никаких проблем с учетом обновлений нет. Но в рамках «Иркутской нефтяной компании» нам этот механизм очень сильно помог.
- Раньше у нас каждый раз после выпуска планового релиза, особенно на крупных базах, просто валом несколько дней подряд шли срочные релизы, потому что обязательно где-то кто-то что-то зацепил, либо наоборот, не обновил какой-то нужный объект. И в итоге на рабочие базы попадала либо непротестированная функциональность, либо туда не попадало что-то нужное. Был большой негатив со стороны пользователей, и выпуск исправительных релизов – даже в обеденное время – только усиливал этот негатив. А благодаря этому механизму мы практически свели к нулю установку исправительных релизов.
- Также мы получили удобный инструмент сборки релизов, который подскажет разработчику – какие объекты ему нужно обновлять полностью, а какие с осторожностью, так как они также были изменены его коллегами.
- Несмотря на то, что разработчикам и консультантам приходится вносить много данных в документ «Доработка», количество трудозатрат на подготовку релизов у нас снизилось. Это произошло за счет того, что значительно снизилось именно количество этих исправительных срочных релизов, что дало огромный выигрыш по трудозатратам сотрудников на подготовку обновлений в целом – сама длительность сборки релиза не сильно изменилась.
- Руководители отдела разработки и внедрения получили инструмент для контроля дисциплины своих сотрудников.
- В частности, начальник отдела внедрения может контролировать, как консультанты обновляют инструкции, как они качественно оповещают об изменениях пользователей – всех ли пользователей они оповещают об этом.
- Руководитель отдела разработки имеет механизм, который дает ему возможность в случае возникновения каких-то ошибок разобраться, почему это произошло, кто допустил ошибку. Он может контролировать исполнительскую дисциплину в плане заполнения данных в документе «Доработка».
- Теперь у нас нет проблем с актуальностью инструкций. Инструкции актуальны всегда, они обновляются вместе с релизом – поэтому проблем о том, кто и когда обновит инструкцию – чуть раньше или позже – у нас никогда не возникает.
- Также мы ушли от ручной установки релиза. Раньше у нас разработчики не спали, ночью обновляли вручную базы, утром консультанты первым делом должны были как можно быстрее отправить уведомления пользователям об установке релиза и обновить все инструкции. Если вдруг кто-то отвлекся, забыл, проспал – недовольство в наш адрес было обеспечено. Сейчас мы готовимся к обновлениям заблаговременно, в рабочее время. Ночью все спокойно спят. Этот процесс упорядочен.
Перспективы развития
В описанной мною функциональности меня устраивает практически все, за исключением одного – разработчикам приходится ручками вручную отмечать измененные объекты, которые он помещает в хранилище конфигурации в документах «Доработка» системы Service Desk. Это своего рода «двойной ввод». Но пока мы не решили, что с этим можно сделать. Мы бы хотели, чтобы:
- при помещении разработчиком изменений в хранилище – информация об определенных объектах, которые он туда помещает, приходила бы в систему Service Desk;
- так как разработчик при помещении в хранилище указывает в комментарии номер доработки, хотелось бы, чтобы в этой доработке все эти объекты автоматически отмечались на вкладке «Измененные объекты»;
- при этом если есть добавленные объекты, сначала обновлялась информация о конфигурации тестового хранилища в Service Desk, а потом также отмечались все измененные или добавленные объекты.
Тогда бы мы ушли от риска того, что набор действительно измененных объектов конфигурацию и тот набор объектов, который отмечен в «Доработке» разработчиком, не совпадают. Такое, к сожалению, бывает. Человеческий фактор пока остается.
Главное – хотелось бы, чтобы эта процедура инициировалась на стороне конфигуратора при помещении объекта в хранилище, а не из системы Service Desk. Повторюсь, что мы пока решения этому не нашли.
Если вдруг у кого-то будут какие-то идеи на этот счет – поделитесь, пожалуйста, я буду очень признательна!
У меня все. Спасибо за внимание!
Вопросы
- При обновлении релиза иногда требуется не только внесение изменений в конфигурацию, но и обновление данных – добавили реквизит, поменяли тип, нужно перенести данных. Это должно произойти в момент выкатки новой конфигурации. Включены ли в вашу процедуру каким-либо образом еще и изменения данных помимо изменений инструкций и кода?
- В самом механизме этого нет. У нас есть механизм, который позволяет не устанавливать обращение в статус «Выполнено» и информировать консультанта с помощью определенных настроек о том, что конфигурация обновилась, и в нее нужно внести какие-то данные. Т.е. эти настройки консультант сам для себя заранее формирует, чтобы система ему потом об этом напомнила.
- Получается, что консультант это сделает уже с утра, когда пользователи могут начать работать с неверными данными?
- Такое бывает нечасто, и консультанты про это сами знают. Если что-то нужно сделать действительно быстро – бывает, что консультант может это делать ночью или рано утром, когда еще пользователей нет.
- Какое количество у вас разработчиков и как часто вы выпускаете релизы?
- У нас шесть разработчиков, пять из них – разработчики 1С. По поводу количества релизов – мы стараемся сократить количество релизов, мы их пытаемся упорядочить. И раз в две недели выпускаем плановый релиз. Это получается достаточно крупный, тяжелый релиз. Но у нас бывают проектные релизы, которые мы устанавливаем тоже по регламентам – по понедельникам, например. И, к сожалению, бывают срочные релизы – когда нужно исправить какую-то ошибку в системе, либо пользователю эта функциональность нужна срочно.
- Экстренные релизы вы тоже заносите в систему и отражаете (если сломалось, и нужно обновить прямо сейчас)?
- Да, срочные релизы мы также проводим через эту систему. Обычно мы стараемся, конечно, дотянуть время, например, до обеда – пока меньше пользователей будет работать. И также планируем установку релиза – готовим его заранее за пару часов, и он устанавливается в обед автоматически.
- Каким образом вы тестируете релиз? Как вы проверяете работоспособность при сборке?
- Тестирование релизов происходит консультантами, они свою базу обновляют из тестового хранилища. И, соответственно, тестируют в ней функциональность вручную. Автоматического тестирования у нас пока нет.
- А каким образом осуществляется приемка функциональности? Есть задача, ее выполняют разработчики, дальше эта функциональность принимается. В какой момент это происходит?
- Консультант принимает функциональность от разработчика. Если у него нет никаких замечаний, его полностью устраивает реализация, он переводит доработку в статус «К помещению в рабочую базу». Тем самым он подтверждает готовность функциональности для промышленной базы.
- Это происходит уже в релизном хранилище?
- Консультант делает это в системе Service Desk, и только после этого доработка попадает в документ «Релиз», и только потом ее переносят уже сами разработчики – тот, кто ее разрабатывал – в релизное хранилище.
- Как происходит работа с документацией (с инструкциями)? Как они доставляются до конечных пользователей? И ведется ли версионирование?
- Да, версионирование инструкций ведется. Сами инструкции также находятся в системе Service Desk – все находится в одном месте. И когда консультант во вкладке «Подготовка к релизу» указывает текущий раздел инструкции и прикрепляет к нему вордовский файл, содержанием которого должна замениться инструкция при обновлении. И таким образом инструкция в момент установки релиза становится свежей.
- А как она к пользователю попадает?
- Пользователь заходит в систему, и там есть все инструкции. Мы инструкции не рассылаем пользователям. Пользователям мы просто рассылаем краткое уведомление о том, что изменилось в системе и что работает теперь по-другому. А детальные инструкции находятся в Service Desk – все пользователи знают, где они находятся, и ими пользуются.
- Вы думали как-то поделиться с сообществом эти практиками? Или это останется вашим внутренним достижением?
- Мы думали об этом – нужно ли это кому-то, кроме нас, у всех своя специфика. Возможно.
- Насколько часто вы выпускаете релизы?
- Конечно, одна неделя на другую не похожа, но в среднем 5-6 релизов в неделю вполне может быть.
- Тогда рассматривали ли вы вопрос внедрения практик DevOps?
- Я знаю, что сейчас есть различные механизмы, системы, которыми можно пользоваться, но сейчас мы пользуемся этим механизмом – он разработан под нас, нам с ним удобно, и пока что мы от него отказываться не хотим. Возможно, в дальнейшем – жизнь не стоит на месте, и мы перейдем на что-то более современное.
- Просто по поводу того, что вы сказали – ручной ввод информации по измененным объектам конфигурации – дело в том, что когда разработчик помещает в хранилище свои изменения – по этим изменениям можно сформировать отчет. А отчет в текстовом формате можно сохранить и распарсить и те же изменения получить в вашу систему.
- Да, отчет мы тоже формируем. Но у нас именно в чем удобство – в том, что мы можем посмотреть, для чего это изменение было сделано – у нас оно привязано непосредственно к доработке и к обращению пользователя. Мы можем отследить, кто это запросил.
- Но вы говорите, что когда разработчик помещает свои изменения в хранилище, он помечает их номером задачи. Соответственно, когда вы формируете отчет по измененным объектам конфигурации в хранилище, там же можно их сформировать по номеру задачи. Таким образом автоматизировать ввод изменений в вашу систему.
- Просто в конфигураторе нет возможности запустить событие при помещении в хранилище.
- Но вы же можете эти изменения регламентными заданиями выгружать – если вы будете рассматривать для себя практику DevOps, там это можно организовать.
- Спасибо большое за совет.
- Если я правильно понял, у вас у каждого разработчика есть своя тестовая база, в которой он ведет разработку, а потом изменения закидывает в тестовое хранилище. А у вас бывают ситуации, когда двое разработчиков работают над одним и тем же объектом и первый разработчик закидывает свои изменения сегодня, а второй – завтра, и когда второй разработчик закидывает изменения, он стирает изменения первого?
- Если первый вносил изменения, он захватил объект, и его изменять никто не может в тестовом хранилище. После того, как он его доработал, он его помещает в тестовое хранилище, и там уже есть все изменения. И второй разработчик при захвате уже получает объект с изменениями. Конечно, теоретически может быть, что он нечаянно сотрет изменения другого разработчика. Но у нас в хранилище вся информация сохраняется, и потом, в случае возникновения каких-то проблем, мы можем это отследить, найти, скорректировать действия разработчика.
- У нас проблема, что когда второй разработчик захватывает объект и получает изменения, он закидывает свою версию и модуль объекта меняется.
- Именно поэтому мы требуем от разработчиков, чтобы их тестовые базы были подключены к этому хранилищу и чтобы они обновляли их оттуда, не отключали от хранилища, не вносили туда изменения и потом хранилище не обновляли своими конфигурациями.
- Ваши релизы устанавливаются многим клиентам? Или все доработки делаются под одного клиента?
- Нет, релиз привязан к информационной базе. Есть базы, где очень много функциональных блоков – часть из них между собой связана. И когда мы формируем релиз, туда входят все доработки, которые относятся к этой информационной базе. Там много заказчиков и разработчиков работают над этим релизом. Т.е. релиз не для одного заказчика – релиз для базы.
- У вас в задаче была закладка «Описание для релиза». Это творческое описание, которое может отличаться от описания задачи, потому что мы туда добавляем какие-то слова для пользователя. Кто занимается этими красивыми описаниями?
- Описания вносит консультант, который понимает, что именно дорабатывается, он сам ставит задачу разработчику. И задача консультанта – как можно более понятно пользователю сформировать это описание.
****************
Данная статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART EVENT 2019.
