Какие меры предосторожности вы используете, чтобы избежать случайного внесения непреднамеренных изменений в производственную среду?

Question

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

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

---

EDIT:

Приложение представляет собой очень сложное вертикальное веб-приложение B2B. Здесь много данных. В некоторых таблицах около 100 миллионов записей.

---

EDIT:

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

---

EDIT:

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

Основными проблемами являются база данных и данные в файловой системе.

Кстати, я консультант в этой компании, а не фактический работник.

Answer 1

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

Answer 2

Самый прямой ответ: «Не делай этого».

Answer 3

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

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

Answer 4

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

Мы сохраняем предыдущие производственные выпуски для резервирования в случае проблем.

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

Независимо от того, иногда вещи проходят ...

Answer 5

Только для чтения / Гостевые учетные записи. Шутки в сторону. По той же причине вы не всегда можете войти в систему как root или Администратор.

Answer 6

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

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

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

ОДНАКО, если у вас неверный запрос или какая-то задержка ресурсов в вашей промежуточной системе, ресурсы будут извлечены из производства, и машина может зависнуть.

Answer 7

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

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

Кроме того, мне пришлось прожить свою жизнь с некоторыми из них в прошлом, и действительно, вы ничего не можете сделать, кроме множества резервных копий. Каждому внесенному вами изменению должно предшествовать добавочное резервное копирование. Таким образом, если вы что-то fubar'd, сумма, которую вы потеряли, не является существенным. Сервер SQL может создавать дифференциальные резервные копии, которые ограничивают объем дискового пространства, используемого для резервных копий. Oracle тоже может.

Answer 8

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

Если вы не знакомы с концепциями систем контроля версий, я бы посоветовал вам провести небольшое исследование. Они концептуально сложны, но невероятно полезны и мощны. Статья в Википедии - хорошее место для начала: http://en.wikipedia.org/wiki/Revision_control

Answer 9

Это сложная вещь, и она связана с территорией "без постановочной среды".

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

Одна вещь, которую я видел в работе, - это использование виртуальных машин: кроме среды отладки, вы можете создать мини-PROD в виртуальной машине и использовать ее для отладки. Это может быть непрактичным, учитывая тип разрабатываемого вами приложения, поэтому дополнительные сведения в этой области могут быть полезны.

Что касается предотвращения изменений в PROD во время отладки: есть ли причина, по которой вам нужно что-то изменить, чтобы облегчить отладку? Если это так, возможно, стоит поискать решение другим путем.

Answer 10

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