О DevOps и «снежинках»

В сегодняшнем IT трудно сделать шаг, чтобы не услышать разговоры о DevOps. DevOps — это горячая новая тема в отрасли, сменившая разговоры об облаке, и, судя по тому, что говорят люди, можно подумать, что традиционное системное администрирование уже мертво и похоронено.

Для начала необходимо поговорить о том, что мы подразумеваем под DevOps. Это может вызывать путаницу, поскольку, как и с понятием «облако», более старый термин нередко присваивается для обозначения чего-то иного или, в лучшем случае, связанного с тем, что уже существовало. Традиционный DevOps представлял собой слияние ролей разработчика и операционного специалиста. С 1960-х по 1990-е годы это был стандартный способ эксплуатации систем. В том мире люди, писавшие программное обеспечение, как правило, были теми же, кто его развёртывал и сопровождал. Отсюда и слияние «developer» (разработчик) и «operations» (эксплуатация) — полустандартного термина для обозначения роли системного администратора. Эти роли не разделялись широко вплоть до появления «IT-отдела» в 1990-х и 2000-х годах. С тех пор возврат к слиянию этих двух ролей начал набирать популярность снова — прежде всего из-за того, как они могут вместе работать с большой ценностью во многих современных ситуациях с размещаемыми веб-приложениями.

То, о чём сегодня говорят как о DevOps, — это зачастую не строгое слияние разработчиков и операционного персонала, а модификация операционного персонала с гораздо большим акцентом на написание кода не для самого приложения, а для определения инфраструктур приложений в виде кода как естественного продолжения облачных архитектур. Поначалу это может казаться довольно запутанным. Важно отметить, что традиционный DevOps — это не то, что обычно происходит сегодня; вместо него появился новый «ненастоящий» DevOps, при котором разработчики остаются разработчиками, а эксплуатация остаётся эксплуатацией, но операционная деятельность эволюционировала в новую «тяжёлую с точки зрения кода» роль, которая по-прежнему сосредоточена на управлении серверами, выполняющими код, предоставленный разработчиками.

Существенно то, что сегодня роль системного администратора начала разделяться на две связанные, но существенно различающиеся роли, одну из которых большинство отрасли сегодня неправильно называет DevOps (большинство отрасли слишком молодо, чтобы помнить, когда DevOps был нормой, а не исключением и уж точно не чем-то новым и необычным). Я называю эти два аспекта роли системного администратора подходом DevOps и подходом «снежинки».

Я использую термин «снежинка» применительно к традиционным архитектурам систем, потому что каждый отдельный сервер можно рассматривать как «уникальную снежинку». Все они разные, по крайней мере постольку, поскольку ими не управляют таким образом, чтобы поддерживать их идентичность. Это не означает, что они все должны быть уникальными, — просто они сохраняют возможность таковыми быть. В традиционных средах системный администратор входит на каждый сервер индивидуально для работы с ним. Определённый объём скриптинга обычен для упрощения задач администрирования, но в своей основе роль предполагает много времени на работу с отдельными системами.

Упрощение администрирования архитектур «снежинок» нередко включает попытки минимизировать различия между системами разумными способами. Как правило, это начинается с таких вещей, как выбор единой стандартной операционной системы и версии (Windows 2012 R2 или Red Hat Enterprise Linux 7), а не допущение, чтобы каждая серверная установка использовала отличную ОС или версию. Эта стандартизация может казаться базовой, но многие организации лишены её даже сегодня.

Следующим шагом обычно является создание стандартной методологии развёртывания или эталонного образа (gold master image), используемого для создания всех систем, так чтобы базовая операционная система и все базовые пакеты — зачастую включая пользовательские настройки системы, пакеты мониторинга, пакеты безопасности, конфигурацию аутентификации и аналогичные модификации — были стандартными и развёртывались единообразно. Это обеспечивает общую отправную точку для всех систем с целью минимизации расхождений. Но технически такой подход лишь гарантирует стандартную отправную точку, и со временем расхождение в конфигурации неизбежно.

Помимо этих шагов, среды «снежинок» обычно используют специальные, заказные административные скрипты или инструменты управления для поддержания определённой стандартизации между системами с течением времени. Чем больше общего между системами, тем легче их обслуживать и устранять неполадки, и тем меньше знаний требуется от административного персонала. Большая стандартизация означает меньше сюрпризов, меньше неизвестных и значительно лучшие возможности тестирования.

В среде с одним системным администратором, хорошими практиками и инструментарием среды «снежинок» могут достигать высокой степени стандартизации. Но в средах со многими системными администраторами, особенно поддерживаемых круглосуточно из многих регионов, и с большим количеством систем стандартизация, даже при очень усердных практиках, может стать очень сложной. И это ещё до того, как мы затронем очевидные проблемы, связанные с тем, что на системах, выполняющих различные роли, требуются разные пакеты и, возможно, разные версии пакетов.

Подход DevOps органично вырастает из модели облачной архитектуры. Облачная архитектура спроектирована вокруг автоматически создаваемых и автоматически уничтожаемых, в целом идентичных систем (по крайней мере в группах), управляемых через программный интерфейс или API. Эта модель, совершенно очевидно, предрасполагает к центральному управлению через систему управления, а не через ручные усилия системного администратора. Ручное администрирование фактически невозможно и совершенно непрактично в рамках этой модели. Отдельные системы не являются уникальными, как в модели «снежинки», и любое расхождение создаст серьёзные проблемы.

Идея, возникшая в мире облачных архитектур, состоит в том, что системная архитектура должна определяться централизованно «в виде кода», а не на самих серверах. Поначалу это звучит запутанно, но обретает большой смысл, когда мы рассматриваем это глубже. Для поддержки этой модели начал появляться новый тип инструментов управления системами, который ещё не обрёл по-настоящему стандартного названия, но часто называется инструментом автоматизации систем, фреймворком DevOps, инструментом IT-автоматизации или просто инструментом «инфраструктуры как кода». Общие наборы инструментов в этой области включают Puppet, Chef, CFEngine и SaltStack.

Идея, лежащая в основе этих наборов инструментов автоматизации, состоит в том, что центральный сервис используется для управления и контроля всех систем. Этот центральный орган управляет отдельными серверами посредством кодовых описаний того, как система должна выглядеть и вести себя. В мире Chef они называются «рецептами» — для красоты, но аналогия работает хорошо. Код каждой системы может включать такую информацию, как список пакетов и версий пакетов, которые должны быть установлены, какие конфигурации системы следует изменить, и файлы, которые нужно скопировать на машину. Во многих случаях решения об этих развёртываниях или модификациях обрабатываются с помощью потенциально сложной логики — отсюда необходимость в реальном коде, а не в чём-то более простом, например в разметке или шаблонах. Затем системы группируются по ролям и управляются как группы. Роль «веб-сервера» может предписывать набору систем установить Apache и PHP и настроить память с минимальным использованием свопа. Роль «SQL Server» может установить MS SQL Server и специальные инструменты резервного копирования, используемые только для этого приложения, и настроить память под пул машин SQL Server. Это лишь примеры. Как правило, в организации существует множество ролей, некоторые из которых могут быть общими, например «веб-сервер», а другие — более специфичными для поддержки конкретных приложений. Роли обычно можно накладывать друг на друга, так что система может быть одновременно «веб-сервером» и «java-сервером», получая комбинированные потребности обоих.

Эти стандартные определения означают, что системы, как только им присваивается та или иная роль, могут «собирать себя» автоматически. Новая система может быть создана по запросу администратора, или система мониторинга производительности может решить, что для роли требуется дополнительная мощность, и автоматически создать новые экземпляры серверов без какого-либо участия человека. В момент запроса системы — человеком или автоматически — назначается роль, и система посредством фреймворка автоматизации превращается в полностью настроенный и актуальный «узел». Никакого вмешательства человека-администратора не требуется. Процесс быстрый, простой и, что самое важное, полностью воспроизводимый.

Определение систем в виде кода влечёт за собой некоторые неочевидные последствия. Одно из них — резервные копии полных систем больше не нужны. Зачем создавать резервную копию системы, которую можно воссоздать с минимальными усилиями почти мгновенно? Локальные данные из систем баз данных необходимо резервировать, но только данные базы данных, а не всю систему. Это может значительно снизить нагрузку на инфраструктуры резервного копирования и сделать процессы восстановления быстрее и надёжнее.

Объём документации, необходимой для систем, уже определённых в коде, минимален. В средах «снежинок» системному администратору необходимо поддерживать документацию для каждого хоста и обновлять её вручную. Это крайне трудоёмко и чревато ошибками. Системы, определённые посредством центрального кода, требуют минимальной или вообще никакой документации, и документация может вестись на уровне группы, а не отдельного узла.

Тестирование систем, определённых в коде, тоже легко осуществить. Можно создать систему по коду, протестировать её и знать, что при переносе этого определения в production производственная система будет создана воспроизводимо — точно так же, как в тестировании. В средах «снежинок» очень распространены практики тестирования, которые пытаются это сделать, но делают это вручную и склонны к небрежности и неточной воспроизводимости — очень часто политические соображения диктуют, что быстрее имитировать воспроизводимость, чем реально к ней стремиться. Системы, определённые кодом, обходят эти проблемы, делая тестирование значительно более ценным.

Помимо необходимости определить количество узлов в каждой роли, система может автоматически перепровизировать всю архитектуру с нуля. Восстановление после катастрофы или развёртывание вторичного сайта может быть выполнено очень быстро и легко. Также крайне легко переходить между локально размещёнными системами и удалённо размещёнными системами, в том числе у таких компаний, как Amazon, Microsoft, IBM, Rackspace и других.

Конечно, в мире DevOps использование облачных архитектур имеет большую ценность для обеспечения максимального уровня автоматизации, но для использования этих типов инструментов облачные архитектуры не обязательны. И, конечно, кодовая архитектура может применяться частично, в то время как ручное администрирование также может быть реализовано — гибридный подход, — но это редко рекомендуется для отдельных систем. Как правило, гораздо лучше иметь две среды: одну, управляемую как «снежинки», и одну, управляемую в стиле DevOps, когда оба подхода обязательны. Это даёт значительно лучшую гибридизацию. Я видел, как это прекрасно работало в корпоративной среде с десятками тысяч «снежинок» — каждая очень уникальна, — но с выделенной средой из десятков тысяч узлов, управляемых в стиле DevOps, потому что все узлы должны быть идентичными и взаимозаменяемыми с использованием одной из двух возможных конфигураций. Гибридизация оказалась весьма эффективной.

Однако подход DevOps тоже имеет существенные оговорки. Наборы навыков, необходимые для управления системой таким способом, значительно превосходят требуемые для традиционного системного администрирования, поскольку как минимум все знания традиционного системного администрирования по-прежнему нужны, плюс необходимы глубокие знания программирования — как правило, современных языков, таких как Python и Ruby, — а также знание конкретных рассматриваемых фреймворков. Это расширенное требование к базе знаний означает, что практики DevOps не только редки, но и дороги. Это также означает, что университетское образование, уже далеко не полностью готовящее ни системных администраторов, ни разработчиков к профессиональному миру, теперь ещё дальше от подготовки выпускников к работе в модели DevOps.

Системные администраторы, работающие в каждом из этих двух лагерей, склонны считать, что все системы должны вписываться в их собственную модель. Новые практики DevOps нередко полагают, что системы-«снежинки» являются устаревшими и нуждаются в обновлении. Традиционные администраторы «снежинок» склонны считать движение «инфраструктуры как кода» глупым, переполненным излишними накладными расходами, чрезмерно сложным и очень нишевым.

Реальность такова, что оба подхода имеют огромные достоинства и оба останутся чрезвычайно жизнеспособными. Оба имеют смысл для совершенно разных рабочих нагрузок, и в крупных организациях, я подозреваю, оба будут часто применяться в той или иной форме гибридизации. На рынке МСБ, где обычно лишь небольшое количество серверов, нет масштабирования для обоснования облачных архитектур и высокое разнообразие систем, я подозреваю, что DevOps останется почти неопределённо долгое время за пределами нормы, поскольку накладные расходы и дополнительные навыки, необходимые для его функционирования, непрактичны или даже невозможны для приобретения. Более крупные организации должны смотреть на свои рабочие нагрузки. Многие традиционные рабочие нагрузки и большая часть традиционного программного обеспечения не вполне подходит для подхода DevOps, особенно облачной автоматизации, и потребует либо гибридизации, либо непрактично высокого объёма кодирования для каждой системы, делающего модель DevOps невозможной для обоснования. Но рабочие нагрузки, построенные на веб-архитектурах или способные горизонтально масштабироваться очень хорошо, выиграют от модели DevOps в масштабе. Это может применяться как к крупным корпоративным компаниям, так и к меньшим компаниям, вероятно производящим размещаемые приложения для внешнего использования.

Это различие в подходах означает, что, например, в США большинство компаний страны по-прежнему будет сосредоточено на модели управления «снежинками», тогда как некоторые компании на восточном побережье могут эффективно оценить модель DevOps и начать двигаться в этом направлении. Но на западном побережье, где более современные архитектуры и значительно больший акцент на размещаемых приложениях и приложениях для внешнего использования являются движущими экономическими факторами, DevOps уже переходит от новинки к зрелой, устоявшейся норме. Подходы DevOps и «снежинки», вероятно, останутся сильно разграниченными по регионам — точно так же, как IT в целом видит, как разные наборы навыков мигрируют в разные регионы. Не было бы удивительно увидеть, как DevOps начинает укрепляться на таких рынках, как Остин, где традиционные IT показывали довольно слабые результаты.

Ни один из подходов не лучше и не хуже другого — это два разных подхода, обслуживающих два совершенно разных способа провизионирования систем и две принципиально разные потребности этих систем. Однако с ростом облачных архитектур и модели DevOps крайне важно, чтобы существующие системные администраторы понимали, что означает модель DevOps и когда она применима, чтобы они могли правильно оценить свои собственные рабочие нагрузки и уникальные потребности. Значительная часть традиционного мира системного администрирования «снежинок» будет со временем мигрировать к модели DevOps. Мы ещё очень далеки от достижения устойчивого состояния в отрасли в отношении баланса этих двух моделей.

Первоначально опубликовано в блоге StorageCraft.