Какъв вид предпазни мерки използвате, за да избегнете случайно извършване на неволни промени във вашата производствена среда?

Най-директният отговор е: „Недей така“.

контрол на източника. нищо като връщане назад, когато нещата са непоправими. Също така разликата може да ви помогне да възпроизведете промените в други производствени системи.

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

Запазваме предишните производствени версии за резервни версии в случай на проблеми.

Ако нещата се повредят (което не трябва да се случва често с подходяща процедура за тестване и управлявани версии), тогава можем или да върнем обратно, или да поправим актуална корекция. Често, когато нещата са повредени на живо и корекцията е малка, можем да коригираме актуално, след което да преместим корекцията за тестване, за да направим правилен тест.

Независимо от това, понякога нещата се получават...

позволявайте достъп за запис само на определени акаунти, така че трябва да влезете по друг начин, за да направите промяна

на уеб сървър, има две структури на директории, които се отразяват една на друга, едната, в която само един ID може да пише, другата промеждутъчна директория, всеки може да пише.

на сървър на база данни, има една производствена база данни, където само един ID може да пише, има етапна база данни, където всеки може да пише. базовата база данни може да има нощно архивиране, възстановено към нея.

ОБАЧЕ, ако имате грешна заявка или някакъв проблем с ресурсите във вашата етапна система, ресурсите ще бъдат изтеглени от производството и машината може да увисне.

За уеб сървъри и сървъри за приложения бих се опитал да копирам средата на ново място (но в същата среда) и ще накарам засегнатите хора да възпроизведат поведение върху копието. Това поне ще ви даде известно ниво на отделяне от случайно прецакване със 100% от вашите клиенти.

За сървъри на бази данни бих конфигурирал потребителски акаунти в производствената система, за да им дам права само за четене.

Акаунти само за четене/гости. Сериозно. Това е същата причина, поради която не винаги влизате като root или администратор.

Това е трудно нещо и върви с територията на „без сценична среда“.

По много причини е най-добре да имате специален (дубликат) на PROD, който можете да използвате за етапно внедряване на... и за отстраняване на грешки, но знам, че понякога, когато започвате, това не работи толкова бързо или старателно, както бихме искали.

Едно нещо, което видях да работи, е използването на VM: освен средата за отстраняване на грешки, можете да създадете mini-PROD във VM и да го използвате за отстраняване на грешки. Това може да не е практично предвид вида на приложението, което разработвате, така че допълнителни подробности в тази област биха били полезни.

Що се отнася до избягването на промени в PROD по време на отстраняване на грешки: има ли причина да трябва да промените нещо, за да улесните отстраняването на грешки? Ако е така, може би си струва да потърсите решение по друг начин.

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

Ако не сте запознати с концепциите на системите за контрол на версиите, бих ви посъветвал да направите малко проучване. Те са концептуално сложни, но невероятно полезни и мощни. Статията в Уикипедия е добро място за начало: http://en.wikipedia.org/wiki/Revision_control

Съжалявам, трябва да имате сценична среда. Това няма как да се заобиколи. Ако това означава, че трябва да извадите размера на вашите набори от данни, тогава това е, което трябва да направите. Използвайте VMware и VMware конвертор, за да импортирате производствените системи по време на периоди на спад, ако ги имате (това е многочасов процес, така че може би не е практично).

Има определен клас проблеми, които не можете да разрешите, без да имате пълен достъп до производствени DB (или копие), производителността е един от тях. Но наистина трябва да изградите среда за етап, дори ако е на нечия настолна машина с намален набор от данни.

Като оставим това настрана, трябваше да живея живота си с няколко от тях в миналото и наистина не можете да направите нищо, освен много резервни копия. Всяка промяна, която правите, трябва да бъде предшествана от инкрементално архивиране. По този начин, ако сте fubar'd нещо, сумата, която сте загубили не е значителна. SQL сървърът може да прави диференциални архиви, които ограничават количеството дисково пространство, използвано за архивиране. Oracle също може.

В случай, че наистина нямате друг избор и е вероятно ситуацията да е хронична... помислете за добавяне на някакъв начин към данните на приложението (файлове или база данни), за да маркирате набор от данни като „моля боже, не променяйте действително активно производствено състояние с тези данни“, комбинирано с изхвърляния на данни в критични позиции в процес, когато този флаг е активиран, може да сте в състояние да упражнявате по-голямата част от производствената логика, без действително да се действа върху данните.