Что такое управление конфигурацией
Цикл статей по основам Software Configuration Management
Пролог
Что такое управление конфигурацией в разработке ПО? Зачем оно нужно? Думаю, немногие способны полностью и внятно ответить на этот вопрос. Большинство обычно вспоминает системы контроля версий, которые сами используют. Кто-то упоминает багтрекинг. Кто-то считает вершиной CM отращивание веток в любимой системе контроля версий. А кто-то вообще уходит в сторону и начинает говорить про ITIL и про то, как он записывает в какую-нибудь базу параметры всего софта, который установлен у него в фирме.
Несколько странно и немного досадно наблюдать за этим. Дело в том, что я проработал в SCM в общем сложности около 5 лет, из них 3 года — интегратором в Motorola, на одном из проектов по разработке софта для сотовых телефонов. По ходу дела прочитал кучу материалов по этой теме и получил большой практический опыт — в том числе по работе с одной из мощнейших систем контроля версий IBM Rational ClearCase (см. linkedin в профиле). В итоге в голове сформировалась некоторая целостная картина того, что же это на самом деле — software configuration management.
А потом увидел статью от камрада altern, в которой он начал рассказывать про СМ. Речь у него пошла несколько в другом ключе — о конкретных инструментах и именовании конфигураций. Поэтому, списавшись с ним, чтобы не пересекаться по тематике наших статей, решил написать об основах того, что называется управлением конфигурацией программных средств.
Сейчас у меня уже написан материал примерно на 50 тысяч знаков — это приблизительно 5-7 среднего размера постов для Хабра. И процесс написания продолжается. Я собираюсь выкладывать написанное с небольшой периодичностью сюда и, по мере исчерпания вопросов и обсуждений, постить новые заметки.
Задача — дать обзор того, чем же вообще является CM, какие задачи он решает и какие техники при этом используются. Речь не будет идти о конкретных системах контроля версий или вообще инструментах — этого добра навалом в сети. Задача — показать универсальные для всех инструментов основы.
Что такое CM и зачем он нужен
Управление конфигурацией
Для начала определимся, что такое configuration, ведь это слово выведено в заголовок. Конфигурация – это совокупность версий рабочих продуктов. Ключевые слова – «версий продуктов».
В любом проекте есть рабочие продукты – это может быть маркетинговая документация, требования к конечному продукту, исходные коды, тесты, вспомогательные инструменты. Что считать рабочим продуктом, зависит от проекта (определение будет дано в следующей заметке). Далее, каждый продукт изменяется во времени (в этом ведь смысл разработки), и эти изменения надо как-то учитывать – кто, когда, что именно внёс и зачем он это сделал. Иными словами, учитывать, как появлялись версии продуктов.
Версия – это состояние рабочего продукта, которое может быть восстановлено в любой момент времени независимо от истории изменения.
Соответственно, управление конфигурацией – это управление наборами рабочих продуктов и их версиями. Этот процесс и есть область действия CM.
В англоязычной литературе используется термин Software Configuration Management, сокращенно SCM. Далее для простоты изложения будет использован термин управление конфигурацией и сокращение CM (читается: «сиэм»).
Схема 1. Элементы, их версии и срезы-конфигурации.
CM является одной из базовых практик любой методологии разработки ПО. Достаточно сказать, что в модели SEI CMM/CMMI (Capability Maturity Model Integration) наличие налаженного процесса управления конфигурацией – необходимое условие для получения организацией сертификата CMM/CMMI Level 2.
Замечу, что Level 2 – это самый минимальный, начальный уровень зрелости, согласно модели CMM. Level 1 получает «автоматом» организация, завершившая успешно хотя бы один проект по разработке. Поэтому и наличие CM – это минимальное требование для сертификации. Кстати, на втором уровне необходимо иметь, в числе прочего, налаженный процесс тестирования и управления требованиями. Это говорит о том, что с точки зрения стандарта CMMI, правильный configuration management так же важен, как грамотное тестирование и управление требованиями.
Так в чем же заключается такая ценность CM?
Направления ответственности CM
Управление конфигурацией работает на всех этапах жизненного цикла проекта. Появился рабочий продукт (например, файл с исходниками) – он попадает в поле деятельности CM’а. Продукт начал изменяться (мы пишем функциональность) – значит CM должен предоставить средства для контроля над изменениями и автоматически провести сам контроль, где это требуется. Потребовалось разбить работу на команду разработчиков, а то и на несколько – проектный CM предоставляет правила и инструменты для работы. Есть, что предложить заказчику – тогда CM определяет правила стабилизации продуктов разработки и их выпуска. Надо откатиться на произвольный релиз – опять в работе CM. Понадобились метрики по изменениям или документированные политики – ну, вы поняли, к кому обратиться.
Итак, в первую очередь, CM отвечает за идентификацию рабочих продуктов, т.е. отвечает за определение того, что же будет в дальнейшем контролироваться. В следующей заметке будет подробнее про это рассказано.
Продукты выделили, дальше команда начинает работу. По ходу работы нужно периодически стабилизировать полученные результаты, подводить некоторую черту под наработками, а также определять тот базис, на основе которого будет идти разработка. Это всё также входит в сферу деятельности CM’а.
Кроме того, CM отвечает за то, что в общем случае называется отслеживанием запросов на изменения. Большинству эта область известна как системы отслеживания ошибок. Ведь никакие изменения не должны проходить спонтанно – каждое из них нужно регистрировать и затем правильным образом назначать и отслеживать – вплоть до попадание в конечный продукт. Вот тут опять остается крайним CM. Изменения в продукты вносим, надо их отслеживать – начинает работать контроль версий. Ничто не будет потеряно – CM на страже.
Средства контроля изменений и обеспечения версионности создают условия для распараллеливания разработки в больших командах. Это достигается благодаря тому, что, описав эти средства, мы даем разработчикам документированные процедуры, позволяющие разделять ответственность и ограничивать области деятельности каждого из разработчиков.
Ну и, как всегда, «нельзя контролировать то, что нельзя измерить» — (с) Де Марко. Метрики – о них тоже будет сказано пару слов. Где измерения – там и формализация. Другими словами, всё, что связано с CM, хорошо бы документировать. Об этом тоже вкратце будет упомянуто.
Итак, каковы задачи управления конфигурацией?
Для начала — достаточно. Следующая часть будет посвящено тому, как же определяются продукты и конфигурации, которыми мы будем управлять. Также коснусь вопроса о компонентной разработке, продуктовых линейках и их связи с СМ.
Как внедрить процесс управления конфигурацией (Configuration Management). Часть 1
Одной из проблем в области управления ИТ-услугами является отсутствие организованного процесса управления конфигурацией. Вне зависимости от того, как организовано управление инцидентами, изменениями, проблемами, уровнем обслуживания и стоимостью услуг, отсутствие точных данных о конфигурации может нанести компании значительный ущерб. Чтобы этого не произошло, необходимо уделить достаточно внимания внедрению процесса управления конфигурацией.
Правильная реализация управления конфигурацией поможет не только разрешать инциденты путем определения причины их появления (что сломалось, в чем причина поломки, как ее устранить), но и предотвратить их до момента появления за счет грамотной оценки производимых изменений, а неправильная – потратит ваши деньги впустую.
Архитектура ИТ-услуг даже в небольшой организации может быть достаточно громоздкой и сложной. Отсутствие понимания взаимосвязи между системами и сервисами в рамках этой архитектуры создает неопределенность и риск для компании. Процесс управления конфигурацией позволяет поддерживать порядок при хранении и использовании всего аппаратного и программного обеспечения, а также предоставляемых ИТ-услуг.
Важность управления конфигурацией
Порой старшие менеджеры говорят, что у них нет денег на покупку дорогостоящих систем для управления конфигурацией (CMSs). Но, принимая такое решение, они не получают контроля над всеми расходуемыми средствами, связанными с восстановлением ИТ и бизнес-услуг; над внесением изменений, без контроля последствий их применения и возможных неблагоприятных последствий для бизнеса; над управлением и оптимизацией затрат на ИТ-имущество и управлением релизами без связи с другими процессами.
Но, кроме финансовых затрат, впустую расходуются и другие ресурсы, например человеческие: сотрудники сидят без работы, потому что необходимая им система не функционирует, а проблема лишь в том, что ее своевременно не подключили к их профилю.
А также время, которое вы вынуждены тратить на отчеты для руководства о снижении ключевых бизнес-сервисов, так как изменили систему управления; на объяснение клиентам о задержке устранения инцидента с ИТ-инфраструктурой из-за отсутствия системы CMS; на устранение дефектов релиза из-за плохого управления имуществом.
Добавим к этому компенсацию за время простоя ИТ-услуг, штрафы за просроченные лицензии программного обеспечения, клиентов, работающих в кредит, отток пользователей.
Вывод можно сделать следующий: невозможно осуществлять управление изменением, если оно не подкреплено эффективным управлением конфигурацией. Так же как пытаться предоставить клиентам стабильную сетевую услуг без распределения нагрузки по сети между серверами. И это недостаточно эффективный способ организации ИТ в 2017 году.
С чего стоит начать
В-первую очередь необходимо объяснить цель и смысл использования управления конфигурацией всем заинтересованным сторонам, включая владельцев систем, сетевых инженеров и других. Члены команды управления конфигурацией и специалисты, ответственные за данные, которые она содержит, должны предоставлять точную информацию коллегам, решающим инциденты и планирующим изменения. И наоборот: действия, производимые ИТ-специалистами с другими системами, должны отображаться в CMS или базе данных управления конфигурацией (CMDB). Каждая сторона рабочего процесса должна принимать непосредственное участие в управлении конфигурацией – это путь к достижению успеха, это необходимо знать и понимать каждому.
Чтобы получить желаемый результат, был разработан эффективный метод организации управления конфигурацией, о котором мы сейчас расскажем.
В целом внедрение управления конфигурацией можно разделить на 5 этапов:
Так как управление конфигурацией станет основой для других процессов и предоставления услуг, то для его качественного и эффективного внедрения нужен хороший, подробный план. Как говорится в пословице, «Кто не планирует свою победу, тот планирует чужую», без хорошего плана не будет желаемого результата.
Составление плана
Мы рекомендуем начать планирование управления конфигурацией с наиболее критичных и важных для бизнеса процессов, таких как управление инцидентами и проблемам. Служба технической поддержки всегда загружена заявками от пользователей, и их своевременное исполнение – одна из головных болей руководства. Если вы начнете реализацию проекта именно с этих услуг, это поможет снизить нагрузку и оптимизировать работу специалистов Service Desk и результат заметят другие подразделения компании. Руководство обратит внимание на более быстрое разрешение инцидентов, уменьшение времени простоя, снижение числа неудачных изменений и обеспечит вас поддержкой для дальнейшей реализации.
Условно можно выделить 3 основных элемента (уровня) конфигурации:
Их распределение отображено на представленной ниже диаграмме.
Последовательность – ключ к планированию
При грамотном планировании важна последовательность действий и внимание к мелочам. Например, план может содержать описание способа формирования имен CI. Имя каждой единицы для CMDB должно быть уникально и содержать ключевую информацию, которая помогает ее идентифицировать. Примером может служить такая маска: Тип CI – расположение – служба поддержки. Имя CI «MSserver-Moscow-Level3» говорит оператору Service Desk о том, что Windows Server на московской площадке недоступен и нуждается в технической поддержке третьей группой. Такой уровень информации при регистрации инцидента позволяет сразу предупредить всех пользователей сервера о проблеме, а также назначить тикет именно той группе поддержки, которая за него отвечает, что сокращает время реакции за счет сокращения стадий эскалации.
Это не единственный способ присвоения уникальных имен CI, вы можете называть их даже по именам персонажей любимой книги, главное, чтобы при планировании эта система была заранее прописана в SLA и в процессе работы соблюдалась последовательность.
План конфигурации должен быть масштабируемым
При планировании вы составляете список только критических служб и сервисов, которые необходимы для управления и поддержки предоставления услуг. Затем при расширении зоны охвата управления конфигурации можно просто добавлять новые элементы вашей инфраструктуры – это более простая задача, которую можно осуществить позже. Масштабировать систему можно бесконечно (все зависит от роста вашей компании и набора предоставляемых услуг), но заложить основу необходимо сразу при планировании до начала внедрения.
Управление конфигурацией – это один из кирпичиков эффективного использования ИТ-инфраструктуры компании и качественного предоставления услуг. Если к нему добавить такие процессы, как управление активами и управление мощностями, то вы получите комплексную модель гибкого и рационального использования всех имеющихся в вашем распоряжении ресурсов. О внедрении и эксплуатации этих процессов мы расскажем в следующих материалах нашего блога.
Это все, что касается планирования управления конфигурацией. В следующей статье мы рассмотрим определение, контроль, учет состояния, проверку и аудит. А также покажем, как реализован этот процесс на платформе ServiceNow.
Чтобы прямо сейчас испытать все возможности и преимущества популярной и успешной сервисной платформы ServiceNow, в том числе для управления конфигурацией, вы можете обратиться к специалистам компании «ИТ Гильдия» – официального сертифицированного партнера ServiceNow.
Подписывайтесь на блог компании «ИТ Гильдия» – официального сертифицированного партнера ServiceNow, чтобы следить за новыми статьями, которые позволят вам достигнуть успеха, внедряя платформу.
Принудительное введение в системы управления конфигурациями
Abstract: как заставить себя изучить любую из существующих систем конфигураций и перестать редактировать файлы на сервере руками.
Пост посвящён душевной боли, которую нужно преодолеть. Ещё в посте будет чуть-чуть технического, но большей частью пост посвящён борьбе с самим собой, отложенному вознаграждению и тому, насколько моторная память котролирует вас.
Введение для отшельников, которые не слышали что такое configuration management systems
Уже многие годы (по айтишным меркам — три поколения как) существуют программы, которые позволяют автоматизировать процесс конфигурации серверов. Все эти программы сложные, они вторгаются в святую святых администраторов и заставляют их делать «всё не так, как раньше». Их изучение и интернализация (признание, что «так надо и так правильно») — абсолютный must have в карьере любого системного администратора.
Главная боль любой системы управления конфигурациями
Главная боль состоит в том, что система управления конфигурациями ломает привычную автоматику пальцев. Раньше вы могли поднять веб-сервер за 2 минуты почти не глядя на экран. Теперь вам предлагают потратить на абсолютно те же самые действия минут 15-20 (если вы хорошо знаете систему управления конфигурациями) или даже несколько дней (. ), если вы её изучаете.
Это преступление против личной эффективности. Уменьшить её в десять (0xA) раз — и это они называют прогрессом?
Вне зависимости от всех остальных аргументов, эта мысль будет преследовать вас всё время. Даже спустя годы. Вы не просто нажимаете больше кнопок для того, чтобы сделать то же самое, но и вынуждены делать это медленнее, вы вынуждены ждать компьютер (никогда раньше вам не надо было ждать десятки секунд пока редактор «отредактирует» файл и перезапустит веб-сервер). Хуже, в момент, когда вы пишите примитивную конструкцию в конфиге, вы будете вынуждены бороться с лишними пробелами в DSL’е (специальном птичьем языке программирования, который надо выучить); думать о всякой невероятно сложной посторонней фигне; делать специальные услуги роботам. Отладка будет хуже и отвратительнее — вместо нормального сообщения об ошибке из-за опечатки в конфиге вы будете получать невнятную oversharing простыню вывода на два экрана, чтение которой занимает больше времени, чем «пойти и сделать вручную».
Ещё хуже: часто эти простыни будут касаться не ваших действий, а совершенно несвязных изменений в других местах проекта. И вы будете вынуждены с ними разбираться. Иногда это будут даже баги системы управления конфигурациями и вы будете чинить/обходить баги вместо того, чтобы заниматься своей прямой работой.
Ну как, я «продал» вам эту технологию? Готовы отбиваться всеми силами от попыток внедрить её на рабочем месте?
Перед тем, как мы продолжим говорить про системы управления конфигурациями, я хочу показать на очень иллюстративный пример из психологии зефирный эксперимент. Для тех, кому лениво читать Википедию, пересказ: детям дают зефирку, и говорят, что если они её не съедят за 15 минут, то им дадут вторую (и обе можно будет съесть). Чем старше ребёнок, тем больше вероятность, что он продержится 15 минут. Малыши не могут себя сдержать и съедают зефирку сразу, хотя потом становится обидно. Этот эксперимент проверяет механизм «отложенного удовольствия».
Именно это и предлагают системы управления конфигурациями. Вы тратите пол-часа на операцию, которую вы можете руками сделать за 3 минуты, а потом эту операцию можно выполнять снова и снова (когда нужно) без затраты трёх минут. И главное, без вовлечения головы. Чаще всего эту процедуру делегируют CI-серверу (jenkins, buildbot, etc), и тогда это открывает дверь для первого шажка к волшебной двери по имени CI/CD.
Staging
А этот шажок называется ‘staging’. Копия вашего продакшена, которая ничем не занимается. На которой вы можете посмотреть ответ на вопрос «что будет, если я поменяю версию сервера?» и другие смешные эксперименты, не сломав ваш продакшен.
Безусловно, staging можно сделать и без систем управления конфигурациями. Но кто будет следить за тем, что staging похож на продакшен? Более того, кто будет следить, что после вашего смешного эксперимента стейджинг всё ещё похож на продакшен? Если вы делаете смешной эксперимент на результате предыдущего смешного эксперимента, то возможно, результат будет отличаться от того, что получится потом на продакшене.
Этот вопрос «кто будет следить?» на самом деле с подковыркой. Если у вас не гигантский раздутый штат в котором у вас может быть пара человек, которые следят за staging’ом, то ответ на него «никто». Никто не следит. Что же делать?
Ответ: «до основанья мы разрушим,» и пересоздадим с нуля. Если в этом процессе от человека требуется больше минуты времени, то, разумеется, никто этого делать не будет. Слишком уныло снова и снова делать то же самое ради исправления «смешного эксперимента».
Обычная мысль «Да чего его переподнимать, я сейчас всё назад верну руками, так быстрее». На выходе — смешной эксперимент и результат его исправления, вместо «копии продакшена».
А вот если есть робот, который «пойдёт и всё сделает сам», вот тогда да, никакой проблемы. Пошёл и сделал.
Размножение staging’ов
Если переподнять стейджинг так просто, то почему бы его не поднять в ещё одном экземпляре? Он может быть попроще, в нём не будет какой-то из важных сложных тяжёлых компонент, но нужный кусок, над которым вы работаете прямо сейчас — почему бы и нет?
А ещё он может быть на localhost’е, в виртуалке или контейнере. Что даёт вам практически нулевую латенси при работе (приятно), поддержку оффлайнового режима (полезно). Это потребует чуть-чуть работы с системой управления конфигурациями, но куда меньше, чем может показаться. А дальше — тык-тык и у вас свежий кусок копии продакшена (или даже чего-то специфичного для вашего фичебранча из гита).
Рефакторинг
После того, как у вас есть написанный процесс превращения нескольких серверов в продакшен и вы можете повторять его снова и снова (малыми усилиями), вы вольны начинать менять кусочки этого процесса (на более удобный/правильный/модный процесс) и смотреть что получилось.
Это требует второй части системы управления конфигурациями — валидации серверов. Об этом мы поговорим чуть позже, но пока сфокусируйтесь на простой идее: вы можете попробовать поменять что-то в процессе конфигурации сервера и посмотреть что получится. За бесплатно. (От себя: когда я не уверен, я иногда запускаю 2-3 версии в параллель на разных стейджингах чтобы выбрать лучший).
code review
Рефакторинг и хранение инструкций для системы управления конфигурациями в гите делает возможным проводить code review (если у вас больше одного человека в команде). code review это круто! Во-первых он дисциплинирует не оставлять кривизны. Во-вторых вы учитесь у друг друга как делать лучше. В третьих это увеличивает взаимное знание о проекте и происходящих в нём изменениях. Развивая линию ci/cd, с некоторыми усилиями можно даже видеть результаты прогона предлагаемых изменений на временной инсталляции — и робот может завернуть pull request просто потому, что он «всё ломает» — no human involved.
Тесты
Если у нас есть набор инструкций для системы управления конфигурацией, то мы можем проверить результат. Для этого есть масса интересных решений: testinfra, goss, inspec, serverspec, etc. Фактически, эти тесты позволяют проверить результат применения вашей конфигурации. Например, «на 80ом порту слушают», «в мониторинге появилось 180 чеков», «пользователь Х может залогиниться на сервер» и т.д. Когда у вас появляются такие тесты, то вы можете уже сколько угодно играться с процессом — если тесты проходят, то вы всё сделали правильно. Благодаря этому, вы можете пробовать новое (дерзкое) и не бояться неожиданного (например, «ой, я же не подумал, что включение SSL сломает весь мониторинг»).
Job security
Системы управления конфигурациями напрямую угрожают рабочим местам низкоквалифицированных системных администраторов. Если раньше нам нужно было 20 администраторов, каждый из которых мог управлять 20 серверами, то теперь команда из трёх (чуть-чуть более квалифицированных администраторов) прекрасно может справляться с 400 серверами. На самом деле один тоже может справляться, но 2-3 дают большую компетенцию команде, меньший бас-фактор (концентрацию знаний у единственного человека) и улучшают атмосферу в коллективе благодаря взаимной ответственности за качество работы. И с job security всё просто. Либо вы в списке этих трёх администраторов, либо нет.
На самом деле я чуть-чуть лукавлю и реальность обычно выглядит так: вместо 60 серверов у трёх администраторов у них на руках оказывается 400 (1000? 2000?) серверов, и варианта «нанять ещё 17 администраторов» просто не стоит по бюджетным причинам. Но это особенности растущего рынка и дефицита квалифицированных кадров, а общий аргумент всё равно остаётся: системы управления конфигурациями повышают эффективность труда, и на рынке оказываются более востребованы люди с более высокой эффективностью труда.
Ещё одна программа, которая требует внимания
При всей позитивности необходимости вышесказанного, любая система управления конфигурациями — всего лишь программа. Это означает, что будут баги. В том числе обидные требующие делать неудобно и некрасиво лишь бы обойти баг. Это означает, что очевидные архитектурные фичи не будут реализованы просто потому, что у программистов иное видение направления движения проекта. Это означает, что вместо части документации будет «Документация» (которая находится в каталоге src ). Как любая другая программа, она будет требовать внимания к своему внутреннему миру, уделения себе времени, компетенции (и ещё времени на обучение).
И ещё раз о смене парадигмы
Всё это (включая баги и глубокий внутренний мир) — потребует адаптации мышления под модель, которая диктуется системой управления конфигурации. Управление конфигурациями — крайне инвазивная сущность, которая хочет быть главной во всём, и многие рабочие процессы придётся подстраивать под требования этой программы. Будет множество граничных моментов, когда станет хуже (раньше можно было сделать лучше и проще), будет множество раз, когда будет ощущение выполнения нелепого ритуала вместо нормальной работы.
Но вместе с этим будет и ещё одно ощущение — что стало меньше кнопкодавства и стало больше думания. Вместо «пойти и поменять» будет момент размышления «а правильно ли менять так?», «А почему его вообще надо менять?», будет больше рассуждений об архитектуре (почему на сервере А мы меняем одно значение а на сервере Б другое? Можем ли мы найти что-то общее между этими изменениями и описать это общее как новую сущность?)
Онтология, или 2nd hard problem
Онтологические проблемы будут в полный рост. Размышления над «общим для разных изменений» будут постоянно приводить к появлению новых вещей, а новые вещи требуют имён. Придумывать же имена, как известно, это вторая сложная проблема в IT (первая — инвалидация кеша), и она сложна потому, что придуманное название определяет свойства и ожидания от объекта. И вам придётся каждый раз мучительно придумывать имена. Каждая ошибка — кусок кривизны в архитектуре. Если раньше изменения были «потому что надо поменять», то теперь изменения будут, потому что «так нужно для реализации свойств сепульки». Я старался избегать анекдотических примеров (из жизни), но всё-таки приведу. У меня в одном проекте ушло три недели на то, чтобы придумать имя «системная конфигурация» (для описания той части изменений, которые затрагивают настройки серверов и требуют использования ansible, как противоположность «программной конфигурации», для описания той части, которая не требует вмешательства ансибла). Идея оказалась разумной и помогла разделить невозможно переплетённый комок зависимостей «надо поменять на сервере А но только после того, как пользователь поменяет в интерфейсе Б, но если пользователь поменяет В, то нам А трогать не надо, а если пользователь поменяет Е, то поменяется В и Б, так что нам надо как-то одновременно поменять и конфигурацию сервера, и ту часть, которая ансиблом не конфигурируется». Уф… Давно забытый ужас. Который надо было прочувствовать, продумать и найти имя для отдельной сущности внутри него.
Переезд с фронтира в бэк-офис
Жизнь админа становится всё меньше похожа на жизнь админа. Профессия разделяется на тех, кто пишет конфигурацию и тех, кто её сопровождает (т.е. остаётся на фронтире, наедине с сервером). Таких иногда называют SRE, и в зависимости от критичности проекта в каждый момент времени, это может быть как очень крутая и важная профессия, так и «апгрейженный саппорт».
С чего начать?
Если я вас чуть-чуть мотивировал, но вы не знаете, с чего начать, то начните с поиска системы управления конфигурациями, которая вам по душе. Это Ansible, cfengine, Chef, Juju, Puppet, SaltStack, Quattor, etc. Вероятнее всего, список не полон. Ни одно из этих решений не является хорошим (на мой взгляд), но это лучшее, из того, что у нас есть. Выбор такой системы частично нужно основывать на известных языках программирования (это моё IMHO), ощущении от синтаксиса и жизнеспособности проекта.
После выбора ПО, не стоит бросаться с головой. Читать умные книги по такой системе надо, играться тоже можно до любого уровня сложности, но внедрять стоит очень ограниченно, не теряя контроля над ситуацией. Это означает, что начинать надо с простой автоматизации длительных действий (перепишите свой любимый скрипт деплоя на языке системы управления конфигурацией), попробуйте в него записать хотя бы часть того, что делаете руками.
postscriptum
Одним из интереснейших лайфхаков с системами управления конфигурациями, я считаю лабораторное применение. Когда исследуется новое ПО, то конфигурация этого ПО силами системы управления конфигурациями позволяет «попробовать снова» (если не ясно, делает ли ПО сайд-эффекты по серверу).
Заодно, описание для робота «что делать» отлично подходит на роль эскизного проекта внедрения. Одно время я отлаживал corosync, который не хотел работать в сети с лимитом на unknown unicast/multicast. В ходе отладки мне пришлось несколько десятков раз переподнимать кластер. Когда это делалось ansible’ом, «несколько десятков раз» не стали подвигом, а пришли к чему-то уровня «перезапустить лабораторию».
Ежедневное применение систем управления конфигурациями требует перестройки самых базовых инстинктов работы с серверами, но взамен очень неприятной learning curve даёт на руки не только инструмент для повышения эффективности труда, но и смену модели поведения и мышления на более эффективную. Это очень тяжёлый шаг, но шаг, который нужно обязательно сделать.