Галактика в вопросах и ответах

Вопрос наверно глупый, но задам!
Существуют ли методики по переходу/тестированию на новые патчи?
Поделитесь опытом кто как переходит!

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

Ну ет понятно! Вопрос в минимизации негативных последствий установки патчей.
Например:
"За месяц до сдачи индивидуальных сведений перешли на новые патчи, в результате, когда дело дошло до конвертации стажей Гал-ка отказалась стажи конвертировать. Оказывается на новых патчах сломался режим конвертации стажей сотрудников имеющих заместительство. Выяснение этого обстоятельства потребовало 3 дней. В следствие этого возникла вероятность срыва сроков по сдаче ИС (причем сроки для нашего региона отделение ПФ устанавливает отличными от законодательства (им так удобнее), и как правило самые жесткие). В ето время Главбух заметно нервничает. Отчетность конечно сдали вовремя, однако осадок остался. Сейчас Главбух крайне негативно относится к обновлениям Гал-ки."
Может кто-то имеет опыт тестирования патчей, или есть методика по переходу.

Заведите тестовую Галактику и на ней проверяйте обновления...

Тестовую Гал-ку ставим, само тестирование отдаем на откуп пользователям. Понятно, что функционал на 100 % не проверить, но ответственность с себя снимаем, а тестируемые параметры юзеры определяют сами. Как правило тестирование проходит вяло, за 2 года подобной методики выявлен ток 1 случай некритичной ошибки в патчах (криво формировался поток данных для печатной формы).
Я не могу понять - как на практике использовать кучу инфы из тхт-шников, описывающих обновления в Галактике (или это утопия).

VarankDA писал(а):За месяц до сдачи индивидуальных сведений

Стараемся ставить патчи во время "затишья".

VarankDA писал(а):Сейчас Главбух крайне негативно относится к обновлениям Гал-ки

Я сам негативно к этому отношусь! Постоянно какие-то ошибки вылезают - одно лечат, другое ломают.

VarankDA писал(а):тестирование проходит вяло

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

VarankDA писал(а):как на практике использовать кучу инфы из тхт-шников

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

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

Я бы не советовал ставить патчи без крайней на то необходимости менее чем за 2 недели до наступления критичных событий - скажем расчет ЗП, закрытие периода в бухконтуре. Я стараюсь ставить патчи после закрытия ЗП - это 10-12 числа. Следующее окно с 25 по 28. Перед сдачей отчетности лучше прогнать заранее(за месяц) - чтобы найти ошибки функционала и свои ошибки и уж точно в этот период не нужно ставить патчи, без явных на то указаний со стороны ТП. Сейчас в декабре уже нужно наичнать проверку формирования отчетности по НДФЛ - адреса , вычеты и так далее, чтобы успеть иправить свои косяки этим годом и озадачить ТП возникшими проблемами. А да - никогда не ставьте патчи в пятницу, если не планируете работать в субботу и воскресенье.

1. Тестировать самим на тест-базе по самым критичным моментам ( обязательно!).
2. Пересобрать заранее все свои ресурсники ( старайтесь уменьшить число присоединенных отчетов или использованных стандартных фейсов).
3. Как правильно тут опытные люди говорили, ставить только тогда, когда "приспичило" ( функционал, смена законов и пр), ставить всегда после критичных работ ( расчет зп и пр).
4. Читать описания надо, стараясь понять, что из ваших ошибок, пожеланий там учтено( или нет). Но все прочитать - муторно и долго.

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

раньше проверяли, сейчас просто объем слишком большой. не проверяем. разве что иногда узкие места, специфичные для нашего предприятия.
ставим патчи после закрытия числа 10-20, и смотрим что да как. обычно в первую неделю если что-то и есть, вылетает. если можем решить сами, решаем. если критичная ошибка (было один раз), откатились на старый ЕХЕ.
всё проверить невозможно.

VarankDA писал(а):IT-шники не могут классифицировать операции на предмет "критичности",

Айтишники все могут. Зачастую лучше бухгалтеров и других юзеров.
Я уже на двух заводах работал с Галактикой, везде именно IT-шники все и тестили.

savov писал(а):

VarankDA писал(а):IT-шники не могут классифицировать операции на предмет "критичности",

Айтишники все могут. Зачастую лучше бухгалтеров и других юзеров.
Я уже на двух заводах работал с Галактикой, везде именно IT-шники все и тестили.

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

VarankDA писал(а):Предлагаю обсудить следующий тезис:
IT-шники не могут классифицировать операции на предмет "критичности", поэтому тестирование отдаем пользователям, а в качестве протокола, с них запрашиваем анкету с проверенными параметрами!
Результат:
- Наличие документально подтвержденных свидетельств о работоспособности патчей;
- Пользователи более скрупулезно относятся к тестированию, т.к. надо чем-то подтвердить.
Кто нить такой фигней страдал?

Мы так делаем.
Зато потом никто не скажет, ИТ-ки не проверили

Столкнулись с ситуацией когда нас очень просили очень срочно обновиться. Причем совершенно не вовремя. В итоге получили критическую ошибку. Причем откатами к старой версии не решаемую, т.к. уже БД попортилось слишком кривыми ранними патчами. Всё закончилось письмами, служебками, очными ставками и прочей ерундой.
В итоге мы написали руководящий документ по обновлениям, где зафиксировали примерно такой порядок:
1. Заявка от инициатора обновлений (если обновление плановое - инициатор ОИТ)
2. Патчи на копию системы.
3. Распоряжение по проверке. Ключевые пользователи(отделы) указываются поименно с назначением зон ответвенности.
4. Акт о выполнении проверки с подписями проверяющих.
5. Патчи на рабочую систему.

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