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

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

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

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

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

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

Тем не менее, иногда что-то проходит...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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