Управление Конфигурацией. Обеспечивает Ли Полная Автоматизация Более Высокую Рентабельность Инвестиций В Небольших Масштабах?

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

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

Теоретическое преимущество автоматического развертывания и управления конфигурацией заключается в том, что код можно развертывать и тестировать быстрее, а услуги предоставляются более надежно за счет автоматизации проблемы человеческих ошибок. Будущие обновления базовой ОС (например, CentOS 6 -> CentOS 7) будут лучше/быстрее, и в долгосрочной перспективе вышеуказанные преимущества перевешивают первоначальные более крупные инвестиции в программную автоматизацию развертываний с использованием системы управления конфигурацией?

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

#автоматизация #управление конфигурацией

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

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

Переделка стоит дорого, и были проведены некоторые исследования для количественной оценки ее стоимости. Вы можете прочитать об этом в этом техническом документе - https://devops-research.com/roi/

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

Тема автоматизации ручных задач также исследовалась в Отчет о состоянии DevOps выпускается каждый год, начиная с 2013 года. Большинство из них доступны по адресу https://devops-research.com/research.html также (за исключением 2013 г.). В каждом отчете оно упоминалось как важнейший фактор достижения совершенства в высокопроизводительных организациях любого размера. Существует множество причин и объяснений, которые можно использовать в качестве доказательства в вашем случае.

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

Скажем, например, у вас есть веб-сервер, на котором размещено ваше приложение и все соответствующие конфигурации. Затем вы регистрируете его как Amazon AMI, чтобы можно было развернуть несколько копий (скажем, одну для разработки, одну для тестирования и одну для производства). Вы его развертываете, и благодаря тому, как работает AWS, вам даже не нужно менять IP-адреса вручную.

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

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

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

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

Так почему бы не потратить несколько дней и не написать простой конвейер развертывания с помощью Ansible или Puppet и не поместить его в git? С этого момента любые изменения конфигурации выполняются всего лишь одним нажатием кнопки, и вам редко придется беспокоиться о возникновении подобного инцидента.

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

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

• Как изменится ваш рабочий процесс, если вы сможете делать X так часто, как захотите, с незначительными затратами и за очень короткое время?
  • Для модульных тестов это означает, что ошибки обнаруживаются гораздо раньше — вы можете тестировать все несколько раз в день вместо того, чтобы отправлять что-то в отдел контроля качества раз в неделю. Обработка итераций становится на порядки короче.
  • Для инфраструктуры это означает, что создание кратковременной тестовой среды или проверка концепции не являются событием, равно как и масштабирование, равно как и замена неработоспособного экземпляра. LoE близок к нулю.
• Как меняется ваш рабочий процесс, когда вы думаете об автоматизации как части вашего процесса?
  • Для модульных тестов это означает, что вы разрабатываете свой код по-другому, чтобы облегчить автоматизацию, что (часто) приводит к более качественному и чистому коду.
  • Что касается инфраструктуры, это побуждает вас разработать стандартный план того, как вы собираетесь автоматизировать работу — когда разрабатывается новый сервис, вы знаете, какие вопросы вам нужно задать по этому поводу.
  • Разработчики также начинают менять способы разработки, думая о сохранении состояния без сохранения состояния, плавном завершении работы, быстром перезапуске, о том, как обрабатывается конфигурация, о сохранении настраиваемых путей к файлам журналов или данных, думая о том, к каким путям пользователю приложения нужен доступ и какой доступ ему нужен. , и т. д.

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