Просто о сложном: что за зверь такой DevOps?
Очень часто я слышу вокруг себя разговоры о непонимании новой постмодернистской сущности-роли в ИТ, которую на Западе окрестили как DevOps. Хуже того, я имел неосторожность однажды вскользь написать на эту тему в своем могучем бложике, и с тех пор наблюдаю косяки поисковых переходов вопрошающих, заточенных под это новомодное слово-термин.
Посему сегодня решил остановиться отдельно на непонятном многим феномене DevOps и чудесах высокоуровневой кооперации (в данном случае сфере ПО). В итоге получилась своего рода landing page для всех тех, кто не врубается в чрезвычайно полезную сущность DevOps. Единственное замечание перед тем, как подкат безжалостно засосет вас — я сделал акцент на медийном формате подачи, то есть собрал воедино пару видео-лекций об этой профессии, а также выложил парочку симпатичных презенташек по теме. Впрочем, перед этим дам и свое, предельно простое объяснение этой новомодной сущности буквально на пальцах.
Понеслось.
Свой среди чужих, чужой среди своих
Сначала совсем краткое и отчасти формальное определение.
DevOps (акроним от англ. development и operations) — это методология разработки ПО, сфокусированная не предельно активном взаимодействии и интеграции программистов, тестировщиков и админов, синхронизировано обслуживающих общий для них сервис/продукт. Главная цель этого — создание единого цикла взаимозависимости разработки, эксплуатации и деплоя программного обеспечения, дабы в конечном счете помогать организациям (сервисам, стартапам) быстрее и безболезненней создавать и обновлять их программные продукты и сервисы, эксплуатируемые в режиме реального времени или «в продакшен».
Теперь чуть проще — если сводить всё к мемам, то главный разрыв, который стремится преодолеть эта новая интегрирующая всё методология, это типичная головная боль больших и распределенных коллективов разработчиков — «проблема не на моей стороне»:
Я всегда могу понять конкретного разработчика, который в силу сильной специализации и загрузки частенько видит лишь свою локальную зону ответственности, а посему не хочет лезть в чужую, как ему кажется, вотчину (в сущности, принцип инкапсуляции кода и трудовых обязанностей ещё больше провоцирует такие ситуации).
Но с точки зрения системы эта же ситуация «разумного эгоизма» маленького-человека-на-местах выглядит примерно так:
Таким образом, в больших коллективах должен быть кто-то, кто уполномочен взять на себя ответственность в случае возникающих межстыковых косяков на любом этапе обновления или эксплуатации системы. И даже более того, могущий создать последовательную и логичную проактивную систему по налаживанию взаимодействия всех участников разработки-тестирования-внедрения-эксплуатации большой системы-сервиса, дабы на будущее свести подобные баги на нет.
Графически в наиболее общем виде этот подход будет выглядеть примерно так:
В предельно идеальном случае (к которому есть смысл стремиться даже в нашем убогом не идеальном мире) это будет выглядеть примерно так (см. ниже):
Таким образом, ещё раз подчеркиваю — DevOps это не просто некий универсальный или начитанный админ, который по маленьку шарит на всех участках работы, но, прежде всего — это методология, некий стандартизированный производственный цикл-подход.
Внедрение этой методологии добавляет ещё один абстрактный уровень управления компании (синхронизации и координации над всеми участками разработки вашей большой команды). Да, вначале это создает какбэ ненужные напряги и возмущение на местах, но в перспективе это приносит бОльшую стабильность и контроль, что при разработке сложных работающих систем просто бесценно, лишая режима аврала и регулярных завалов в самый неподходящий момент.
Проектирование DevOps, запуск и поддержание — это кропотливая ежедневная работа. В качестве бонуса вы не только сможете молниеносно разрешать проблемы типа «подземный стук» с помощью DevOps-спецназа, но, ещё раз акцентирую на этом внимание — посредством правильно встроенной и заранее продуманной методологии сможете создать мощный профилактический барьер на пути возникновения подобных авральных багов, проблем взаимодействия в коллективе и факапов.
Таким образом, суммируя: Девопс — это методология отношения к инфраструктуре как коду. Программеры и тестировщики — это «девы», а админы — это «чистые опсы». Собирая все вместе: ДевОпс — это когда программист (Дев) очень сильно вовлечен в процесс эксплуатации системы (Опс). Например, когда отельные участники команды разработки систематически занимаются/участвуют в деплое приложения, настройке окружения, анализируют логи и т.д., кроме того активно работая в качестве суппорта на этапе локализации проблемы, постепенно приобретая целостное видение работы системы.
По своему опыту, в реальной жизни человек-DevOps это чаще всего такой продвинутый админ (иногда бывший программист или всё наоборот), который одновременно в курсе особенностей устройства продукта и всех ролей в коллективе, и «кому до всего есть дело». Конечно, человек для подобной роли нужен не только более технически квалифицированный. Но также и неравнодушный к самому продукту, дотошный и умеющий договариваться/объяснять, который хочет и может вникать во все подозрительные шевеления кода и непонятные взбрыки серверов, особенно, если делать это придется в нерабочее время, ликвидируя результаты чужих косяков.
Конечная цель — создание предельно адаптивной и бесшовной архитектуры разработки-сопровождения продакшен-системы. Задача DevOps«а — понимать и видеть систему как единое целое, и действовать, соответственно, исходя из некоторых синергетических интересов общего. Если можно так сравнить, подобно тому как есть «полевые командиры», DevOps это своего рода полевые архитекторы.
Медиа-приложения к метологии DevOps
Окей, хватит моей теоретической подводки, я попытался максимально просто рассказать, что и для чего Devops нужен. Кому интересны детали, вот, собственно, обещанные выше дополнительные медийные материалы.
Сначала две забавные презентации от одного автора, которые можно пощелкать для более широкого понимания тех основ, которые я изложил выше:
Ниже также выкладываю свежее подробное видео (русский язык), которое по идее должно поставить точку в понимании «как это работает в реальной жизни». Рекомендую его посмотреть всем, кого эта тема реально интересует:
Что мы там увидим:
В своем видео-докладе Дмитрий Никонов (ВИАкод) расскажет о работе DevOps в контексте надежности разрабатываемых систем. На реальных примерах мы вместе обсудим наиболее часто встречаемые и наиболее серьезные проблемы, которые разработчики, админы и ДевОпсы совершают практически на каждом проекте. Также в презентации будет показано, как и в каких случаях нужно применять диагностическую инструментацию кода и другие инструменты разработки и администрации, чтобы сделать счастливыми пользователей, службы поддержки продукта и ИТ-администраторов.
У меня плеер от Microsoft работает паршиво, поэтому кому-то будет удобней скачать это видео себе на винт по этой прямой ссылке (200Mb, 53 минут) для спокойного просмотра в режиме оффлайн.
В заключение внешняя ссылка на дельную статью для последующего размышления тех разработчиков, кто любит думать о своем будущем: How «DevOps» is Killing the Developer.
~
Ключевики для нелюдей: методология внедрения DevOps, а также про то, кто такие девопсы и зачем они вообще нужны. Кто такие и для чего нужен devOp — это основная статья, которая приводит примеры, практики и паттерны их внедрения и использования, также применения и администрирования в стиле DevOps для синхронизации разных участков разработки (безопасность, надежность, гибкость и практичность этой системы и методологии). Роль организации и объединения больших коллективов благодаря девопам и их слугам системным администраторам (обсудим в чем их главное отличие, а также причем здесь Agile и Промышленный DevOps).
