Назад | Перейти на главную страницу

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

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

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

На ум приходят несколько основных вещей, например:

Есть ли другие правила что поможет оставаться в здравом уме и не испортить производственный сервер?

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

Помимо ваших правил, у нас также есть следующее:

  • никогда не используйте одни и те же учетные данные для тестирования и производства (то есть для входа в систему, базы данных), если вы не можете позволить себе ужесточить брандмауэры, правильно установите правила удаления для типичных ошибок, то есть подключения к тестовой серверной части из живого интерфейса и т. д.
  • реализовать как можно больше управления изменениями / контроля версий не только на уровне приложения, но и на уровне ОС. Здесь мы используем cfengine, но есть много других вариантов, например, марионеточный или даже собственный.
  • автоматизировать все рутинные задачи, то есть вам не нужно регулярно ничего удалять вручную на производстве
  • постоянно обновляйте документацию по всему, не считайте задачу выполненной, пока она не будет должным образом задокументирована, объедините вики и систему отслеживания ошибок. Для каждого изменения и каждой странности в конфигурации должно быть «Почему». Я знаю, что это звучит как Святой Грааль, но любая документация лучше, чем ничего.

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

Цветовое кодирование: это тоже хорошая идея, потому что ее трудно пропустить. Задайте цвет приглашения командной строки в соответствии с именем хоста и установите цвет фона рабочего стола для доступа к графическому интерфейсу.

Мои основные методы для этого, как вы сказали, заключаются в изменении цвета фона, изменении макета, что значительно отличает его от сервера разработки.

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

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

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

Здесь действительно может помочь правильное управление версиями (не только VCS, но и правильная маркировка).

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