Devops

Как всем известно, последние несколько лет очень популярно слово “Devops”. Про это пишут большое количество статей, кто-то говорит про культуру, кто-то про задачи бизнеса, кто-то про автоматизацию, сравнивают с Agile, но ясности это не прибавляет. Внесу и я свои пять копеек на этот счет.

По мне так говорить о devops смысла нет вообще — правильнее говорить о том, чтобы хорошо выполнять свою работу, внимательно относиться к другим участникам проекта и развиваться в профессиональном (и других) смыслах.

Когда-то давно, когда серверов было мало, и когда было четкое разделение обязанностей программистов и админов можно было позволить себе выточить из цельной глыбы исходников пакетов дистрибутив мечты с правильно настроенными конфигами, расставленными костылями и собственной архитектурой, не связанной с приложением, которое размещаешь. Разработчикам тестовые сервера не давали т.к. их не было (хорошо если вообще были сборочницы), все работали под виндой, приложение тестировали на собственных как попало настроенных компах, код выкатывали в бинарниках и в общем-то вполне естественно было разделение сфер ответственности: админы админят сервера и деплоят приложение, программистов туда не пускают, чтобы не отломали какой-нибудь костыль, и все ошибки пуляют друг другу. Естественное желание разобраться в проблеме, найти проблему и совместно ее исправить было реализовать нелегко (машинные мощности дорогие, приложение бинарное и сложное), в свою среду разработки программисты никого (тоже по вполне естественным причинам) никого не пускают. Потому и поддерживали стабильность лишь ограничивая сферу своей ответственности. Я, по правде говоря, этих времен почти не застал, т.к. довольно быстро срулил из программирования когда оно перешло из DOS в Windows (и сейчас понимаю, что причины во многом были именно вышеприведенные). Автоматизировать что-то можно было, конечно, но смысла большого не имело, т.к. новые сервера ставились раз в год, их было мало и проще было держать отдельно конфиги/доки по установке (или вообще каждый раз это исследовать этот процесс заново), чем пытаться все это описывать скриптами.

Сейчас же мощности дешевые, сервера можно ставить десятками в день, и появляется естественное желание этот процесс улучшить. Хочется сделать свою работу эффективнее, тратить на нее меньше усилий, поддерживать хорошие отношения со всеми членами команды, и в итоге делать общую работу эффективнее. Повторюсь, это вполне естественное желание здорового человека — заниматься осмысленной деятельностью. Изменились лишь требования, предпосылки к этой осмысленной деятельности. Во многом это выражено в Agile manifesto, который в трех словах говорит: “Давайте жить дружно”.

Из этого вытекает множество направлений деятельности, которые часто называют словом “devops”:

  • Автоматизация развертывания серверов. Когда их десятки-сотни, для нас вытачивать вручную каждый из них — менее эффективно, чем занять этим роботов.
  • Упрощенный деплой. Программисты в общем уже придумали множество инструментов для этого и, наверное, для всех языков. Идея в том, что в идеале это должно занимать времени и внимания меньше, чем развернуть новый сервер. Тратить несколько часов чтобы просто собрать и задеплоить какое-нибудь приложение на Java сейчас становится просто дорого. Естественно, и приложение должно позволять это сделать.
  • CI. Это тоже, пожалуй, придумали программисты некотороые время назад, чтобы проще было собирать бинарник и гонять тесты. Опять таки, приложение должно быть спроектировано, чтобы это поддерживать. Шажок дальше — совместить сборку приложения и деплой на тестовый сервер, на который можно и программистов, например, пустить (напоминаю, теперь мы можем себе этот сервер позволить, а раньше далеко не всегда могли).
  • Сбор и анализ всевозможных метрик и логов в едином месте. Это упрощает нам нахождение причин ошибок с тем, чтобы передать их на исправление правильному человеку.
  • Культура взаимодействия разработчиков и админов. С одной стороны, все вышеприведенное попросту невозможно без нее, а с другой стороны, у нас появилась возможность делать это безопасно для обоих сторон, и это действительно важно.

Иными словами, все это означает работать одной командой и стараться делать свою часть работы как можно лучше.

Где же здесь “devops”? Не знаю, может подскажет кто?

Comments