Меня, конечно, в первую очередь заинтересовало слово DevOps, потому что в последнее время меня часто так обзывают. Что это такое, все понимают по-разному. Те, кто это слово придумал, говорят, что это, мол, такой способ работы в программистских конторах, когда программисты (Devs-developers) и админы (Ops-operations) работают в одной команде и ставят перед собой одни и те же цели. Те, кто этим словом пользуется, считают, что DevOpsы — это такие админы, которые помогают работать программистам. Бизнесмены надеются, что с помощью DevOps смогут заставить программистов выполнять функции админов, а самих админов можно будет уволить, сэкономив деньги. Программисты и админы думают так же, но с противоположными чувствами. Я надеялся из этой книги побольше узнать о реальном смысле новомодного подхода к админской работе, но книга оказалась вообще ни о чем. Беллетризованный бизнес-тренинг — с Важными Принципами, с Тремя Путями и прочей лапшой на ушах. Но зато эта книжка — хороший повод позанудствовать о том, что вот в наше-то время все было лучше, а сейчас все испортили. Попробую рассказать о том, что я сам думаю о своей работе.
В последние 10-15 лет в индустрии разработки программ произошло несколько настоящих революций и еще несколько леворюций, которые на революции не тянут, но шуму производят много. Чтобы понять, что такое DevOps, надо вспомнить некоторые из них.
Первая леворюция называлась Agile — гибкая разработка. Те, кто писал программы в старые добрые восьмидесятые, помнят, как это делалось. Сначала отдел постановки задач совместно с заказчиком писал техническое задание, в котором описывалось, как должна работать будущая программа. Потом проектировали систему — составляли список модулей и их функций, рисовали внешний вид форм для ввода данных и отчетов для их вывода. Потом начиналось собственно программирование. Потом шел длинный этап отладки программы, а заканчивалось все самым сложным — сдачей продукта заказчику. Казалось бы, все хорошо и все довольны, но для того, чтобы так работать, нужно заранее понимать, какой результат нам нужен, ради чего все затеяли. В девяностые наступил капитализм. Клиент всегда прав, сказали заказчики. Вместо того, чтобы заранее подумать, что им нужно, они постоянно меняли свои требования и вообще, хотели получить волшебную красную кнопку, на которую стоит лишь нажать, и все будет хорошо. Программистам пришлось приспосабливаться. Они придумали итеративный способ разработки, когда в ходе работы полученные результаты демонстрировали заказчикам, а те либо принимали их, либо воротили нос. Во втором случае работу переделывали и показывали снова. Объемы ненужной работы выросли, а денег программисты получали все столько же. Поэтому в начале века они придумали еще более хитрый способ, называющийся гибкая методология, или Agile software development. Смысл ее заключался в том, чтобы уменьшить объемы таких переделок. Результаты работы показывали заказчикам регулярно, чуть ли не каждую неделю, и уточняли: это вас устраивает? А это? А вот так? В результате и заказчики выясняли для себя, а что же им, собственно, было нужно, и программисты обходились без больших переделок. Но для этого пришлось изменить рабочие процессы так, чтобы в любой момент была готовая к демонстрации самая свежая версия программы. Для этого потребовалось максимально автоматизировать процесс сборки, тестирования и развертывания системы, исключив из него людей.
Еще одна леворюция называется «контейнеры». Началась она еще в 1982 году, когда в операционной системе FreeBSD появилась технология, называющаяся "jails", "тюрьмы". Смысл ее в том, что работающей программе выделялся какой-то ограниченный набор ресурсов, за который она никак не могла выбраться — она не могла читать никакие файлы, кроме нужных ей для работы, не видела другие программы, работающие по соседству, у нее был свой список пользователей, ни один из которых не имел никаких прав за пределами этой программы, был свой IP-адрес, словом, у программы создавалось впечатление, будто она работает одна на отдельном компьютере, хотя таких псевдокомпьютеров-контейнеров на одном сервере могли быть сотни. Эта технология тихо использовалась в FreeBSD двадцать лет, а потом о ней пронюхали менеджеры и начали рекламировать, как решение всех проблем. Ее доработали, расширили и сейчас контейнеры представляются как этакие виртуальные серверы, которые почти мгновенно можно создать в любом количестве. А если так, то получается, что нет необходимости холить и лелеять свои сервера, как это десятилетиями делали системные администраторы, следя за всеми доступными параметрами. Хороший опытный сисадмин, проснувшись утром и посмотрев в окно, мог предсказать, какие сегодня будут проблемы и на каких серверах. Опыт работы делал админов незаменимыми, но зачем бизнесу незаменимые люди? Ему нужны люди, которых можно так же легко и просто создать, как контейнеры. Где-то в 2012 году была придумана эффектная фраза: «Серверы не должны быть вашими домашними любимцами, они должны быть рабочим скотом». То бишь, если вашему серверу поплохело, его нужно не лечить, а заменить. В случае серверов-контейнеров это делалось легко и быстро. Здесь менеджеры сделали большую ошибку. Их сбило с толку, что с точки зрения программы контейнеры являются виртуальными серверами, и они решили, что контейнеры — замена дорогих и капризных железных серверов. И по сей день они все еще не понимают, что если посмотреть с другой стороны, контейнеры — не серверы, а всего лишь способ запускать программы изолированно друг от друга. Чтобы их запускать, все равно нужны аппаратные серверы, их все равно нужно администрировать.
Для того, чтобы это довольно очевидное противоречие не лезло в глаза, была придумана третья леворюция — так называемые облачные сервисы. Картинкой с облачком на диаграммах традиционно обозначается интернет. Поэтому облачный сервис — всего лишь способ не решать какую-то задачу самостоятельно, а заплатить компании в интернете, умеющей ее решать. В нашем случае в облако спихивают функции системных администраторов по обслуживанию системы: мониторинг, планирование развития, резервное копирование и восстановление, разработка архитектуры и т. п.
На самом-то деле в каждой из этих трех леворюций есть рациональное зерно. Скажем, у облачных сервисов есть большой плюс — возможность изменять объем ресурсов, выделенных каждому клиенту, в зависимости от его, клиента, меняющихся потребностей. Ну, скажем, есть у меня блог. В обычной ситуации он требует для работы совсем чуть-чуть процессорного времени и оперативной памяти. А вот если я бы мог написать умную и интересную статью, ее захотели бы прочитать тысячи посетителей, и потребность в вычислительных ресурсах сразу вырастет. Облачный сервис может на этот рост отреагировать и передать мне часть ресурсов, которые освободились у других авторов, пишущих не так интересно, как я. Или посмотрим на контейнеры. Это идеальное средство для тестирования программ — едва ли не впервые администраторы могут предоставить тестировщикам возможность получить среду, идентичную той, в которой живет основной рабочий сервер. А вот в рабочей системе их полезность ограничена. Дело в том, что контейнеры, как я сказал, это процессы. А суть рабочей системы, ее смысл существования чаще всего заключается не в процессах, а в данных, работу с которыми контейнеры облегчить не могут. Короче говоря, смысл в этих технических решениях есть. А вот в леворюциях он хотя и тоже есть, но совершенно другой — избавиться от расходов на часть квалифицированных сотрудников и переложить их обязанности на других. А вот в итоге, боюсь, ситуация станет хуже. Гибкая разработка приводит к тому, что разрабатываемые системы потеряют цельность. Их части не будут уже спроектированы в расчете на взаимодействие по заранее продуманной схеме, они будут подогнаны на коленке под меняющиеся требования. Внедрение контейнеров лишь отвлекает от важнейшей проблемы обработки и хранения больших объемов данных. Облачные сервисы позволяют снять с себя ответственность за поддержку системы, но эту ответственность никто другой на себя не возьмет, в том числе и сотрудники облачных сервисов. А количество квалифицированных людей, способных эти системы поддерживать, будет уменьшаться, потому что рабочих мест для сисадминов станет меньше. Получается, что в ближайшие годы стабильность IT-систем будет снижаться. Не летайте самолетами Аэрофлота :)
No comments:
Post a Comment