Agile sysadmin и devops - Как это сделать? [закрыто]

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

Итак, какие инструменты и методы вы используете, чтобы сделать devops в ваших компаниях? Мне особенно интересны такие темы, как управление изменениями, непрерывная интеграция и автоматизация, но не только в этих темах. Пожалуйста, поделитесь своими мыслями. Я с нетерпением жду, чтобы прочитать ваши ответы / мнения :)

• SVN / GIT - контроль версий, очевидно.

• trac / redmine / jira - продажа билетов.

• cobbler - для подготовки сервера базовой операционной системы. Cobbler - продукт, ориентированный на семью Redhat, но я уверен, что есть что-то похожее для Debian / Ubuntu. Точно так же большинство компаний «облачной панели управления», таких как RightScale, предоставят это для вас. Лозунгом здесь является «JEOS» или «просто достаточно операционной системы». Мой маршрут состоит в том, чтобы использовать строку "% packages --nobase" в моих кикстартах, а затем собрать свой конкретный стек с помощью ...

• puppet / chef - для управления конфигурацией и обеспечения согласованности. Здесь есть и другие варианты, более важно, что вы используете один, а не какой. Один трюк, который я нашел особенно важным, - хранить конфиги в той же системе контроля версий, что и разработчики. Это помогает объединить рабочий процесс двух команд и сделать его видимым друг для друга.

• func (или capistrano или cluster-ssh) - для запуска сценария развертывания в кластере. Хитрость заключается в том, чтобы сделать это чем-то, что старшие разработчики могут запустить сами, чтобы как запустить новые вещи, так и внести неизбежные исправления.
  Это действительно ядро ​​разработчиков, позволяющее разработчикам как разрушать, так и исправлять среду. Многие системные администраторы слишком жаждут энергии, чтобы так себя отпустить, или их управление все еще работает на ошибочном представлении, что системные администраторы должны следить за разработчиками (как будто мы можем даже прочитать половину того, что они делают).

• cacti / ganglia / collectd / munin - графики оооочень важны. Это коммерческая ценность метрик с человеческой ценностью простых визуальных эффектов. Сопоставление метки времени изменений кода с меткой времени изменений в графиках чрезвычайно важно для устранения проблем, связанных с ухудшением производительности, и получения реальных фактов о решениях по производительности. Здесь ключевой момент заключается в том, что разработчики должны легко видеть и использовать графики, а их руководство должно ожидать их от них.

• nagios / zabbix / smokeping / etc - мониторинг показателей работы сервера и типа базовой страницы. Снова графики являются ключевыми. Это больше для команды ops.

• gomez / keynote / browsermob - внешний мониторинг полной производительности браузера с учетом сторонних сервисов, CDN и проблем со временем рендеринга. Это больше для команды разработчиков.

Вот сочетание инструментов и методов, сосредоточиться на методах. В частности, изменение мышления стороны "sysadmin" devops с "admin" на "операции". Речь идет о включении разработчиков. Позволяя им делать что-то, позволяя им что-то исправлять, позволяя им видеть реальные факты / метрики / графики о том, что они сделали. И наоборот, разработчики должны учитывать, что они включены, и на самом деле выполняют работу по отслеживанию тенденций производительности, устранению проблем и размышлениям не только о функциях, но и о том, как их развернуть и как они повлияют на работоспособность всей системы / среды. ,

Мы работаем над этим в National Instruments. Вы можете прочитать больше о том, что мы делаем, по адресу http://dev2ops.org/blog/2010/4/27/qa-ernest-mueller-on-bringing-agile-to-operations.html

Сочетание инструментов, которые здесь упоминает cagenut, в основном идет в том направлении, в котором мы движемся здесь.

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

С этого момента начинайте смотреть на приложения и вводите их по одному для решения проблем.

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