Управление выпусками для инфраструктуры [закрыто]
Использует ли кто-нибудь принципалов управления выпусками для системного администрирования инфраструктуры так же, как это делается для разработки программного обеспечения?
Я занимаюсь системным администрированием более 10 лет, и мне еще предстоит познакомиться с компанией, которая использует принципы управления выпусками для управления серверной инфраструктурой и конфигурацией приложений, как это делается для разработки программного обеспечения. Такие вещи, как экстернализация конфигураций, проверка конфигураций в репозитории с управляемыми версиями и из него, автоматическое развертывание конфигураций в системах, продвижение через соответствующие непродовольственные среды, автоматическое модульное тестирование компонентов и т. Д.
Мне любопытны приложения и процессы кто угодно использует для управления этими конфигурациями и развертываниями. Кроме того, если создание примечаний к выпуску для развертывания конфигурации - это то, что делают все?
Дополнительный комментарий - Я согласен с тем, что слепая подписка на методологические рамки не делает вашу организацию лучше, и это не так. о чем я спрашиваю. Я пытаюсь выяснить, есть ли определенные концепции, которые могут применяться к системному администрированию так же, как они применяются к разработке программного обеспечения. Например, если я хочу внести изменения в конфигурацию системы в продукте, как мне узнать, что то, что я тестировал в разработке, действительно было перемещено в продукт? Я бы сказал, что если бы у вас была система, в которой эта конфигурация была проверена в репозитории, версирована и затем автоматически развернута в системе в продукте, это будет иметь большое значение для обеспечения правильной работы после развертывания в производственной среде.
Я на самом деле провожу довольно мало времени, думая об этой проблеме. В моей крупной интернет-компании мое задание является внутренним управлением версиями программного обеспечения, которое работает на наших многих серверах. Мы на самом деле сделали довольно большую работу, чтобы попытаться применить принципы управления версиями к инфраструктуре или системному администрированию. В то время как наше программное обеспечение, упаковочная система доступна внешнему миру, общие принципы, должно быть тем же.
Вот пример: это раньше было, что, когда веб-серверы были настроены, администратор должен был не забыть устанавливать адрес VIP как псевдоним на петлевом адресе, приносить машину во вращение. Мы постоянно боролись с выгружаемыми машинами и этот важный пропускаемый шаг. Результатом был бы сервер, находящийся там готовый пойти, но не могущий служить трафику, потому что VIP отметили его как вниз.
Решением, которое мы использовали, был пакет программного обеспечения, который мы интегрировали в наши широкие прокаты. У нас есть система шаблонной обработки, которая генерирует сервер определенные для фермы настройки для каждой приблизительно из 600 ферм. Те настройки затем применяются упаковочной системой, когда пакет программного обеспечения соответствия установлен.
Так, этот относительно простой пакет, который мы создали просто, взял установку на ферму и установил ее на системной обратной петле. Это полностью устранило проблему систем, случайно отмечаемых как вниз VIP.
Мы применили эту методологию к другим частям системы также. Результаты состояли в том, что мы постепенно перемещали большую часть конфигурации системы в нашу систему релиза программного обеспечения. Мы создаем и распределяем релизы программного обеспечения, которые содержат все необходимые пакеты программного обеспечения. Те пакеты в свою очередь берут настройки на ферму и применяют их для согласовывания вещей как петлевой адрес.
Это остается довольно высокоуровневым механизмом. Существуют другие системы, которые гарантируют, что основная ОС загружается на сервере и что учетные записи пользователей системного администратора установлены. Однако, после того как Вы получаете кроме того уровень, мы пытаемся очень трудно переместить всю возможную конфигурацию системы в настройки, которые затем читаются пакетами. Мы были очень довольны этим подходом для того, чтобы управлять приблизительно 10 000 серверов.
Это - своего рода загруженный вопрос по ряду причин.
Во-первых, нет никакого способа разработать программное обеспечение. С одной стороны, у Вас есть традиционные, подобные водопаду модели, где требования собраны заранее, и программное обеспечение следует за очень твердым, неизменным жизненным циклом до завершения главной версии. С другой стороны, у Вас есть модели Agile, где мог бы быть новый выпуск каждую неделю или два. По моему опыту, первый склонен быть отраженным в модели программного обеспечения предприятия (ERP-системы и т.п.), где последний склонен быть отраженным в меньших, менее сложных системах (стопки ЛАМПЫ и т.д).
Во-вторых, просто потому что можно подписаться на методологическую платформу, не означает, что Вы должны - смотреть на аварии предприятия как ITIL и COBIT (по крайней мере, когда компании мчатся наивно в реализацию целого пожирателя ресурсов, не рассматривая то, что они на самом деле делают и почему). Правильный способ приблизиться к проблеме IT состоит в том, чтобы выяснить то, чем Ваш доход от инвестиций на самом деле будет для любого потенциального усовершенствования процесса, и затем определите, реализовать ли его. Если Вы являетесь слепыми к требованиям Вашего бизнеса и рабочим процессам людей, помогающих поддерживать его технологию, Вы собираетесь ничего не выполнить помимо траты тонны времени и денег на чем-то, потому что Вы слышали на блоге некоторого парня, что это была "лучшая практика" для кого-то в их конкретной ситуации в какой-то момент вовремя. Если Вы администрируете серверы для компании, которая продает услугу, которая работает на большой веб-ферме тождественно настроенных серверов, там будут намного большими преимуществами воспроизводимости для конфигурации поскольку код, чем магазин с 100 неоднородными серверами отдела и надежными резервными копиями рабочего состояния системы.
Несомненно, хотя, существует много магазинов там, которые подписываются на этот менталитет, по крайней мере, в некоторой форме. Это - вся причина, что проекты как Марионетка, Шеф-повар и Cfengine существуют. Относительно того, делают ли они все, которое Вы справляетесь, это - вопрос градуса - как это должно быть.
Мы используем Марионетку для управления всеми нашими конфигурациями. Вдобавок к историческим данным Марионетки мы также проверяем наши конфигурации в SVN.
Я использую Мерзавца в целях разработки программного обеспечения, но я также использую его для всех конфигураций и практически чего-либо текст, из которого я должен сохранить версии. Затем я или использую нажатие мерзавца или rsync для перемещения материала. Я не думаю, что такого рода вещь используется администраторами очень, потому что нет, так очень пересекают (по моему опыту), между людьми в каждой дисциплине.