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

Но ведь такое на системах, превышающих определённый порог сложности, работать реально не будет. Рано или поздно после наката обновления на продуктиве возникнет ошибка, которая не воспроизводится в тесте (либо воспроизводимость ограничена в виду очень длительного цикла предшествующих ошибке действий, - ну например процедуры закрытия периодов в какихнить ERP-системах). Делать постоянно копии продуктива в quality-системе, где программист с отладчиком будет резвиться, это всёравно доступ к продуктивным данным.

Т.е. программист на продуктивных данных так или иначе трассировать чтото будет, а значит к данным может подлезть.
Как вариант, нужно иметь на продуктиве чтото вроде отладчика на борту, но с сеансовым порядком доступа. Т.е. "санкционируемую отладку с доступом к таблице а и б на срок до завтра". Вплоть до выдачи временных (сеансовых) потабличных и построчных разграничений на уровне СУБД. Ну и контроль и учёт на бумаге - получил сеанс доступа, распишись, подшей в дело.

Тогда при решении обычных задач программисты могут толктись в dev- и test-системах, но если какойто швах, то садись в продуктив в изолированную среду разработки-отладки, получай сеанс под роспись, и куролесь.

Dimitry SibiryakovПри этом разработчикам отсылается багреп с логом и стэком ошибки. Этого достаточно для её устранения. Если нет - опять же всё идёт исключительно через админа продакшена, который по инструкциям разработчиков собирает для них недостающую информацию. Непосредственного доступа разработчиков не требуется.
Подход опятьже работает только если ошибка надёжно воспроизводится на тестовом ландшафте. А я говорю о практических случаях, когда бизнес-логика системы сложная, данных продуктивных очень много, гденить на 100500ом обороте цикла вылетает именно на продуктивном ландшафте.
Если админ не владеет навыками трассировки-отладки, то он тут далеко не помощник. Либо будет много итераций "инструкций разработчиков", и перепирательств в стиле "где ты грёб, там я и раскидывал". Что обычно затягивает сроки устранения, особенно если традиционно процедуры в продуктиве лимитированы по времени (последний день отчётного периода).

Как ни крути, но без эпизодического доступа каких либо программистов в продуктив, не обойтись.