В настоящее время администрирование гибких систем и DevOps - одни из самых популярных тем в области системного администрирования и операций. Обе эти концепции в основном ориентированы на преодоление разрыва между операциями / системными администраторами и проектами (девелоперы, бизнес и т. д.). Даже если вы никогда не слышали о концепции DevOps, я уверен, что эта тема вас тоже волнует.
Итак, какие инструменты и методы вы используете для достижения цели в своих компаниях? Меня особенно интересуют такие темы, как управление изменениями, непрерывная интеграция и автоматизация, но не только эти темы. Пожалуйста, поделитесь своими мыслями. С нетерпением жду ваших ответов / мнений :)
svn / git - очевидно, контроль версий.
trac / redmine / jira - продажа билетов.
cobbler - для настройки сервера базовой операционной системы. Cobbler - это продукт, ориентированный на семейство Redhat, но я уверен, что для debian / ubuntu есть нечто подобное. Точно так же большинство компаний, занимающихся «облачными панелями управления», таких как RightScale, предоставят вам это. Девизом здесь является «JEOS» или «достаточно операционной системы». Мой путь - использовать строку "% packages --nobase" в моих кикстартах, а затем создать свой конкретный стек с помощью ...
puppet / chef - для управления конфигурацией и обеспечения согласованности. Здесь тоже есть другие варианты, важнее то, что вы используете, чем какой. Один трюк, который я нашел особенно важным, - хранить конфигурации в той же системе контроля версий, что и разработчики. Это помогает объединить рабочий процесс двух команд и сделать его видимым друг для друга.
func (или capistrano, или cluster-ssh) - для запуска сценария развертывания в кластере. Хитрость здесь в том, чтобы сделать это чем-то, что старшие разработчики могут запускать сами, чтобы продвигать новые вещи вживую и вносить неизбежные исправления.
Это действительно суть DevOps, позволяющая разработчикам как ломать, так и исправлять среду. Многие системные администраторы слишком прожорливы, чтобы отпускать подобные вещи, или их руководство все еще работает над ошибочным представлением о том, что системные администраторы должны контролировать разработчиков (как будто мы даже можем прочитать половину того, что они делают).
cacti / ganglia / collectd / munin - графики оооочень важны. Это деловая ценность метрик и человеческая ценность простых визуальных эффектов. Сопоставление метки времени нажатий кода с меткой времени изменений на графиках имеет огромное значение для устранения проблем, связанных с ухудшением производительности, и получения реальных фактов о решениях производительности. Ключевым моментом здесь является то, что графики должны быть удобными для просмотра и использования разработчиками, и их руководство должно ожидать этого от них.
nagios / zabbix / smokeping / etc - мониторинг работы сервера и метрик производительности типа "базовая страница". Снова графики являются ключевыми. Это больше для оперативной части команды.
gomez / keynote / browsermob - внешний мониторинг полной производительности браузера с учетом сторонних сервисов, CDN и проблем со временем рендеринга. Это больше для разработчиков.
Это сочетание инструментов и техник, сосредоточьтесь на методах. В частности, изменение мышления «системного администратора» в DevOps с «администратора» на «операции». Речь идет о включении разработчиков. Позволяя им делать что-то, позволяя им что-то исправлять, позволяя им видеть реальные факты / показатели / графики о том, что они сделали. И наоборот, разработчики должны осознавать, что они включены, и фактически выполнять работу по отслеживанию тенденций производительности, устранению проблем и размышлению не только о функциях, но и о том, как их развернуть и как они повлияют на работоспособность всей системы / среды. .
Мы работаем над этим в National Instruments. Вы можете узнать больше о том, что мы делаем на http://dev2ops.org/blog/2010/4/27/qa-ernest-mueller-on-bringing-agile-to-operations.html
Комбинация инструментов, которые упоминает здесь cagenut, в основном идет в том направлении, в котором мы движемся здесь.
Лучший подход - понять среду, в которой вы работаете. Начните с разговора с разработчиками и менеджерами. Попытайтесь привлечь их к себе и поделиться с ними идеями. Скорее всего, они будут иметь хорошее представление о том, как все работает, и будут ли ваши идеи по внедрению DevOps вызывать какие-либо проблемы.
Оттуда начните просматривать приложения и представляйте их по одному для решения проблем.
Хотя инструменты и методы важны, критический путь лежит в сотрудничестве всей организации. В наши дни ИТ-операции является Деловые операции. Etsy показывает изменения доходов на своих панелях мониторинга, видимые для всех.