Каковы передовые методы отличия производственной среды от других? [closed]
Моя основная область работы - это программирование, и иногда мне приходится выполнять некоторые действия на производственных серверах (при развертывании приложения или настройке чего-либо ...).
Итак, мой вопрос: что нужно сделать, чтобы быть максимально уверенным в том, что я не испортил что-то на производственном сервере, что я намеревался сделать на своей машине / в тестовой среде? Например, очистка базы данных или удаление журналов.
На ум приходят несколько основных вещей, например:
- рабочая консоль открыта ровно столько времени, сколько мне нужно для выполнения моей работы, а затем закрыть ее
- настроить консоль на производственном сервере так, чтобы быть действительно отличным от других - например, красный фон или что-то в этом роде
- наличие каждой команды требует дополнительного подтверждения
Существуют ли какие-либо другие правила , которые помогают оставаться в здравом уме и не портить рабочий сервер ?
Всегда существует тонкая грань между защитой от ошибок и препятствием работе. Хотя я - преданный администратор, наша организация является достаточно небольшой, таким образом, это не практично для реализации всего дополнительного служебного и бюрократизма, что крупным предприятиям нравится должными быть обеспечивать безопасность их производства.
Помимо Ваших правил, у нас также есть следующее:
- никогда не используйте те же учетные данные для теста и производства (т.е. вход в систему, база данных), если Вы не можете позволить себе сжать брандмауэры правильно помещенные правила отбрасывания для частых ошибок, т.е. соединяющийся с тестовым бэкендом от живого frontend, и т.д.
- реализуйте такое большое управление изменениями / управление версиями, как Вы можете, не только на прикладном уровне, но и на уровне ОС также. Здесь мы используем cfengine, но существует много других опций, т.е. марионетка, или даже вырастите свое собственное.
- автоматизируйте все стандартные задачи, т.е. Вы ничего не должны удалять вручную на производстве регулярно
- сохраните актуальную документацию всего, не считайте задачу сделанной, пока она не будет правильно зарегистрирована, объединение Wiki и система отслеживания ошибок. Должен быть "Почему" для каждого изменения и для каждой странности в конфигурации. Я знаю, что это походит на Святой Грааль, но любая документация лучше чем ничего вообще.
Используйте различные пароли: кроме того, что у различных пользователей мог бы быть доступ, Вы не можете войти в систему производственной системной базы данных (и сделать что-то плохо), размышление, что это - база данных тестового сервера, если пароль не является тем же.
Цветовое кодирование: который является также хорошей идеей, потому что трудно отсутствовать. Выберите цвет приглашения командной строки согласно имени хоста и выберите настольный цвет фона для доступа GUI.
-
1
Мои основные методы для того, чтобы сделать это состоят в том, как Вы заявили, изменив цвет фона, изменив расположение, делая это существенно отличающимся к серверу разработки.
Другая вещь, которую можно сделать, изменить пароль на рабочем сервере к чему-то, что необходимо думать собирающийся вход, тот способ, которым Вы сознательны, что Вы входите в систему рабочего сервера.
Другой метод, который я видел используемый в других компаниях, должен на самом деле иметь метод для продвижения работы от разработки до производства, с помощью веб-интерфейса или сценария пакетной обработки, так, чтобы Вы на самом деле не работали над рабочим сервером, но просто способствовали работе, когда это готово.
Одна вещь, которую я видел реализованный, состоит в том, чтобы использовать "посреднический" терминальный сервер между Вашей операционной сетью и Вашей рабочей сетью, таким образом, любые изменения должны быть сделаны (для производственных систем) когда на сессии служб удаленных рабочих столов. Не делая то же с системами тестирования, различие очень, очень ясно.