3 года спустя
Прошло уже больше 3 лет, после того как я опубликовал в этом блоге первую статью Что такое DevOps?. За это время многое изменилось: изменилась индустрия, изменилось отношение людей к технологиям и подходам, изменились тренды :) Но все же я продолжаю слышать споры о том “что такое devops?”. Также на интервью кандидаты иногда задают вопрос “что значит devops для вашей компании?” или “как устроен devops у вас?”.
Далее я поделюсь тем, как изменилось мое отношение за это время к devops и другим модным терминам.
Мое отношение к Buzzwords
Многие в IT спекулируют на модных трендах типа big data, agile, cloud, machine learning. Devops - не исключение.
Конечно раздражает, когда используют такие абстрактные понятия при первой же возможности, но если ты впервые узнаешь о каких-то практиках через этот buzzword, то это очень круто!
Все мы знаем, что до появления этих buzzwords, все уже было описано в классической литературе.
Например ключевая идея Devops была описана еще в 1982 году Э.Демингом в книге “Quality, Productivity, and Competitive Position” (позже она была переименована в “Out of the Crisis”): в этой книге он предложил знаменитых 14 принципов управления. Один из принципов звучит “Break down barriers between departments”, что полностью покрывает основную идею devops-a.
Но к сожалению в мире IT редко кто интересуется классической литературой, написанной 30-40 лет назад.
Из-за этого при появлении нового модного тренда многие превозносят его в понятие истины (первой инстанции). Именно поэтому и появляется 2 лагеря:
- люди, которые понимают, что это очередной buzzword
- люди, которые свято верят, что devops (подставь сюда любое слово) - это философия, набор тулов, практик, определенный mindset, etc.
Обычно через некоторое время люди из лагеря #2 переходят в лагерь #1 (те которые считают что это просто баззворд), разобравшись немного в теории и доменной области, и после этого они обычно начинают скептически относится к людям, которые продолжают верить в божественный devops, спущенный к нам смертным с небес да бы улучшить процессы и производительность команд в компании.
Я прошел такой же путь из лагеря 2 в лагерь 1 =)
Вначале когда я работал в QA департаменте - я вообще не знал о существовании многих практик. И если бы не серия статей Paul Duvall-а о devops-e 23 августа 2012 года (первая статья вообще имеет название “Agile DevOps” - bullshit bingo yeah ), прочитанная мной в октябре 2013, то я бы и дальше продолжал писать никому ненужные фреймворки на Selenium и вряд ли бы узнал в ближайшее время о:
- configuration management
- monitoring/alerting
- binary repository manager
- idempotency
- immutable infrastructure
- operating-system-level virtualization
- high availability
- distributed systems
Постепенно углубляясь и изучая новые практики, инструменты, я стал лучше понимать запросы бизнеса, запросы команд разработки и важность доставки новых фич и изменений конечному пользователю.
Многие могут сказать, что и без всяких статей о девопсах знали о этих практиках - верно, это не исключено, но в компании где я работал на тот момент были только департамент dev и qa, где большинство разработчиков сами не знали об этих практиках и инструментах.
Вывод
Коллеги будьте терпимы друг к другу, не спорьте на бессмысленные темы, уважайте труды классиков, а главное делитесь знаниями с окружающими :)