Почему workaround — тупиковый путь
Типичная ситуация: в модуле расчета себестоимости баг при работе с многоуровневыми спецификациями. Система некорректно считает затраты, бухгалтерия получает неправильные цифры.
Стандартное решение интегратора: пишем кастомную процедуру, которая пересчитывает все после стандартного расчета. Казалось бы починили. Но дальше начинается цепная реакция проблем.
Конфликт с обновлениями. Через год Oracle выпускает новую версию модуля с исправленным расчетом. Обновились — кастомизация конфликтует с новой логикой. Либо переписывайте workaround, либо откажитесь от обновления. Видел проект, где застряли на старой версии только из-за того, что workaround для расчета НДС не дружил с новыми модулями.
Потеря знаний. Разработчик уходит из проекта. Новая команда смотрит на процедуру: зачем она? Документации нет (конечно нет). Удалять страшно — вдруг что-то критичное. Код живет как черный ящик, который все боятся трогать.
Усложнение архитектуры. К одному workaround добавляются другие для других багов. Постепенно большая часть кода в БД превращается в компенсацию косяков Oracle, а не реализацию бизнес-логики.
В проекте горнодобывающей компании мы столкнулись именно с этим багом. Вместо workaround пошли в Oracle Support. Получили официальный патч через 3 недели. Патч устранил проблему на уровне платформы, не добавил кастомного кода, работает до сих пор после трех обновлений Oracle.
Когда стоит идти в Oracle Support
Обращайтесь в Support, если столкнулись с багом в стандартной функциональности — проблема воспроизводится на чистой установке, критична для бизнеса и повторяется стабильно.
Не тратьте время на обращение, если проблема в вашем кастомном коде, неправильной настройке модуля или одноразовой проблеме. Oracle не будет отлаживать ваши разработки.
От бага до патча: как это работает
Воспроизведение проблемы
Oracle Support не примет запрос «у нас что-то глючит». Им нужен четкий тестовый кейс: что делали, что ожидали, что получили. Причем воспроизводимый — не «иногда бывает», а «делаю раз-два-три и вот ошибка».
Воспроизводите баг на тестовой среде с минимальной конфигурацией. Это исключит влияние ваших кастомизаций. Видел случай, когда баг не воспроизводился у Oracle, потому что клиент выслал логи с production, где было 50 кастомных модулей. Потеряли месяц.
Создание обращения
Заходите в My Oracle Support, создаете Service Request (SR). Ключевой момент — Severity (уровень критичности). Не завышайте его без оснований:
Однажды видел, как команда поставила Severity2 на баг в отчете, который формируется раз в квартал. Oracle понизил уровень, обращение обрабатывали две недели вместо суток.
Опишите проблему четко: что делали, что ожидали, что получили, как воспроизвести. Пишите по делу, без эмоций. Инженер должен понять проблему без дополнительных вопросов.
Работа с инженером
Инженер запросит дополнительные логи и результаты диагностики. Отвечайте сразу и полно. Задержали ответ на день — обращение висит неделю. Видел проекты, где на один баг переписывались два месяца, потому что отвечали через раз.
Если Oracle подтверждает баг, создается Bug ID — уникальный номер. По нему отслеживаете статус исправления и получаете патч когда он будет готов. Заносите Bug ID в документацию — коллега через полгода столкнется с той же проблемой и сразу найдет готовый патч.
Тестирование патча
Скачали патч, прочитали инструкцию, применили на тестовой среде. Никогда не ставьте патч сразу в production — он может исправить один баг, но сломать что-то другое. Видел это десятки раз. Тестировать нужно и функциональность связанных модулей, в них могут появиться проблемы.
Типы патчей Oracle
One-off Patch исправляет конкретный баг. Минимальный риск. Применяйте, когда нужно быстрое решение критической проблемы.
Cumulative Patch (CPU) — накопительный патч с сотнями исправлений и обновлений безопасности. Oracle выпускает ежеквартально. Требует тщательного тестирования.
Малоизвестный инструмент: Flagged Files
Большинство Oracle-специалистов не используют Flagged Files. Многие вообще не знают про него. А он многократно упрощает жизнь при установке патчей.
Что это: Механизм маркировки файлов Oracle, которые вы изменяли. При анализе патча Oracle проверяет помеченные файлы и предупреждает, если патч затронет ваши изменения.
В чем ценность:
Без Flagged Files узнаете о конфликте патча с вашими кастомизациями после установки, когда что-то уже сломалось. С Flagged Files узнаете до установки. Можете сделать резервную копию, спланировать повторное применение изменений, оценить риски.
Реальный кейс:
На одном из проектов мы кастомизировали форму ввода платежей — добавили проверки для соответствия требованиям регулятора. Через полгода Oracle выпустил патч с исправлениями в том же модуле.
Благодаря Flagged Files мы до установки узнали, что патч перепишет нашу кастомизацию. Сделали резервную копию, установили патч, повторно применили изменения. Без этого инструмента обнаружили бы конфликт после установки, когда форма перестала бы работать и платежи встали.
Стратегия применения патчей
Security патчи — немедленно. Oracle публикует описание уязвимостей безопасности. Если ваша версия затронута — применяйте после минимального тестирования (1-2 дня). Хакеры читают те же описания уязвимостей. Как только Oracle опубликовал проблему — начинается гонка.
Патчи для критических багов — после базового тестирования. Если баг блокирует критические операции (не можете закрыть финансовый период, встала отгрузка), риск задержки выше риска от патча. Применяйте после 2-3 дней проверки.
Плановые патчи — ежеквартально или раз в полгода. Регулярное применение держит систему в актуальном состоянии без накопления технического долга. Тестируйте 2-3 недели, применяйте в запланированное окно.
Выводы
Работа с Oracle Support вместо написания workaround — инвестиция в долгосрочную стабильность системы. Официальные патчи устраняют проблему на уровне платформы, работают с будущими версиями Oracle, не добавляют технический долг в вашу базу кастомизаций.
Используйте Flagged Files для контроля влияния патчей на кастомизации. Этот инструмент превращает установку патчей из лотереи «а вдруг что-то сломается» в предсказуемый процесс.
Oracle Support — ваш партнер в поддержании качества системы, а не бюрократическое препятствие. Не бойтесь обращаться за патчами. Это правильный путь.
