Кто-нибудь использует принципалов управления выпусками для системного администрирования инфраструктуры так же, как это делается для разработки программного обеспечения?
Я занимаюсь системным администрированием более 10 лет, и мне еще предстоит познакомиться с компанией, которая использует принципы управления выпусками для управления серверной инфраструктурой и конфигурацией приложений, как это делается для разработки программного обеспечения. Такие вещи, как экстернализация конфигураций, проверка конфигураций в репозитории с управляемыми версиями и из него, автоматическое развертывание конфигураций в системах, продвижение через соответствующие непродовольственные среды, автоматическое модульное тестирование компонентов и т. Д.
Мне любопытно, какие приложения и процессы используются для управления этими конфигурациями и развертываниями. Также, если создание примечаний к выпуску для развертывания конфигурации - это то, что кто-то делает?
Дополнительный комментарий- Я согласен с тем, что слепая подписка на методологические рамки не делает вашу организацию лучше, и я не об этом прошу. Я пытаюсь выяснить, есть ли определенные концепции, которые можно применить к системному администрированию так же, как они применяются к разработке программного обеспечения. Например, если я хочу внести изменения в конфигурацию системы в продукте, как мне узнать, что то, что я тестировал в разработке, действительно было перемещено в продукт? Я бы сказал, что если бы у вас была система, в которой эта конфигурация была проверена в репозитории, версирована и затем автоматически развернута в системе в продукте, это будет иметь большое значение для обеспечения правильной работы после развертывания в производственной среде.
На самом деле я довольно долго размышляю над этой проблемой. В моей крупной интернет-компании моя работа - внутреннее управление выпусками программного обеспечения, которое работает на наших многочисленных серверах. На самом деле мы проделали довольно много работы, чтобы попытаться применить принципы управления выпусками к инфраструктуре или системному администрированию. Хотя наша система упаковки программного обеспечения доступна для внешнего мира, общие принципы должны быть такими же.
Вот пример: раньше при настройке веб-серверов администратору приходилось не забывать устанавливать vip-адрес в качестве псевдонима на адрес обратной связи, чтобы привести машину в действие. Мы постоянно боролись с заменой машин и упусканием этого важного шага. В результате сервер будет готов к работе, но не сможет обслуживать трафик, потому что vip пометил его как неработающий.
Решение, которое мы использовали, представляло собой программный пакет, который мы интегрировали в наши общие выпуски. У нас есть система шаблонов, которая генерирует настройки для каждой фермы серверов примерно для 600. Затем эти настройки применяются системой упаковки при установке соответствующего программного пакета.
Итак, этот относительно простой пакет, который мы создали, просто взял настройку для каждой фермы и установил ее на системный шлейф. Это полностью устранило проблему того, что системы были случайно помечены VIP-персоналом как неработающие.
Мы применили эту методологию и к другим частям системы. В результате мы постепенно перенесли большую часть конфигурации системы в нашу систему выпуска программного обеспечения. Мы создаем и распространяем выпуски программного обеспечения, которые содержат все необходимые программные пакеты. Эти пакеты, в свою очередь, берут настройки для каждой фермы и применяют их для исправления таких вещей, как адрес обратной связи.
Это остается механизмом достаточно высокого уровня. Существуют и другие системы, обеспечивающие загрузку базовой ОС на сервер и установку учетных записей системных администраторов. Однако, как только вы выйдете за пределы этого уровня, мы очень постараемся перенести всю возможную конфигурацию системы в настройки, которые затем считываются пакетами. Нам очень понравился такой подход к управлению примерно 10 000 серверов.
Это довольно сложный вопрос по ряду причин.
Во-первых, не существует единого способа разработки программного обеспечения. С одной стороны, у вас есть традиционные, похожие на водопад модели, где требования собираются заранее, а программное обеспечение следует очень жесткому, неизменному жизненному циклу до завершения основного выпуска. С другой стороны, у вас есть Agile-модели, где каждую неделю или две может выпускаться новый выпуск. По моему опыту, первое имеет тенденцию отражаться в модели программного обеспечения предприятия (системы ERP и т.п.), тогда как второе имеет тенденцию отражаться в меньших, менее сложных системах (стеки LAMP и т.д.).
Во-вторых, то, что вы можете подписаться на методологическую основу, не означает, что вы должны - взглянуть на корпоративные катастрофы, такие как ITIL и COBIT (по крайней мере, когда компании наивно бросаются на полную реализацию, не задумываясь о том, что они на самом деле делают и почему ). Правильный подход к решению ИТ-проблемы - это выяснить, какой на самом деле будет окупаемость ваших инвестиций при любом потенциальном улучшении процесса, а затем решить, стоит ли его внедрять. Если вы слепы к требованиям своего бизнеса и рабочим процессам людей, помогающих поддерживать его технологии, вы ничего не добьетесь, кроме того, что потратите кучу времени и денег на что-то, потому что вы слышали в блоге какого-то парня, что это было «лучшая практика» для кого-то в их конкретной ситуации в определенный момент времени. Если вы администрируете серверы для компании, которая продает услугу, работающую на большой веб-ферме, состоящей из идентично настроенных серверов, то конфигурация как код принесет гораздо больше преимуществ повторяемости, чем магазин с 100 разнородными серверами отделов и надежное резервное копирование рабочего состояния системы.
Конечно, существует множество магазинов, которые придерживаются этого менталитета, по крайней мере, в той или иной форме. В этом вся причина существования таких проектов, как Puppet, Chef и Cfengine. Что касается того, делают ли они все, о чем вы спрашиваете, это вопрос степени - как и должно быть.
Мы используем Кукольный управлять всеми нашими конфигами. Помимо исторических данных Puppet, мы также проверяем наши конфигурации в SVN.
Я использую Git для разработки программного обеспечения, но я также использую его для всех конфигураций и практически любого текста, версии которого мне нужны. Затем я использую git push или rsync, чтобы перемещать вещи. Я не думаю, что такие вещи часто используются администраторами, потому что (по моему опыту) между людьми в каждой дисциплине не так много перекрестков.