Comments 75
Десять лет назад? Например СVS уже 27 лет, а git — 12.
Возможно мы в разных мирах живем, но когда я начинал работать (примерно 12 лет назад) за неумение пользоваться svn уже били по пальцам.
А мы 10 лет назад еще сидели на Microsoft Visual Source Safe 6.0, там даже параллельной работы с файлом не было — взял в работу, значит заблокировал файл от изменения другими пользователями.
А Вы сомневались во множественности миров? В моём мире и 12 лет назад, и сегодня VCS не нужны никому, кроме меня.
Да что удивляться, возьмите стройку. Бригада ух из США собрала здание церкви за неделю. Бригада ох из очень средней азии делает тот же объём за полтора-два месяца. Почему? У первых есть типовой техпроцесс и дорогой, но эффективный инструментарий, который экономит ещё более дорогое время работника. НО: у нас все работают как бригада ох, и не работают, как бригада ух. Скорее всего, потому, что доступные на рынке труда работники убьют или пропьют дорогой инструмент, и толку не будет. Поэтому есть, что есть.
Вот вам и иные миры...
Вопрос не в знании, что такое source control. Вопрос в решении его применимости. 10 лет назад многие, например, считали, что это только для больших команд. Так и с девопсом. Уже многие понимают, о чем это, но считают, что это только для какого-нибудь Гугла, а мы по-старинке, сисадминим. Ну вот через 10 лет никому по-старинке в голову не придет.
Недавно сформулировал для себя такое определение:
SysOps — это про настройку оборудования, чтобы оно работало правильно и быстро. А DevOps — это про настройку разработчиков, чтобы они работало правильно и быстро.
Полностью подписываюсь под словами Баруха и Александра. Самое сложное — переломить сознание людей. Заставить их сотрудничать и не тянуть одеяло на себя. А инструменты — дело наживное.
Ну вот я уже несколько лет вокруг этого кручусь. Что получил в итоге? Инструменты есть, а DevOps'а нет! Почему? Потому, что инструменты должны быть не как цель, а как следствие стремления людей что-то улучшить. Улучшить глобально. Найти общий язык всех со всеми. Понять что таки нужно на самом деле и сделать это.
Инструменты — всего лишь инструменты. Без правильно настроенных на нужный результат людей это так и останется мёртвым грузом.
И камень с мёртвой точки у меня начал смещаться именно когда я понял, что DevOps это про людей и именно про людей. Если правильно нашёл заинтересованных, корректно подал им мысль что и как можно улучшить, порекомендовал полезные решения, помог их реализовать, и т.д. и т.п… Внезапно всё раз — и побежало. И начали появляться решения, эти решения начали использоваться пошол DevOps.
А то, что вы описали — скорее таки SysOps. Да Он тоже нужен. Но это в целом очень другая относительно разработки компетенция. И грамотный сисадмин с классическими подходами тут может оказаться гораздо ценнее.
Сисадмин не должен программировать сложные системы. Программист не должен тюнить СХД. Один человек не в состоянии иметь глубокую компетенцию везде. Иначе будет беда.
А вот взаимодействие этих гатегорий людей ради конкретного результата — вот это уже ближе к DevOps. Но таки людей.
В целом про eagel или scrum можно сказать точно так же. Разница лишь в том, что они старше и люди уже чётко договорились что конкретно под этим следует понимать. А с DevOps общественность ещё в поиске. Просто начало формироваться видение, что те-же производственные задачи можно решать ещё одним способом, который меньше полагается на договорённости и человеческий фактор, а больше на автоматизацию и алгоритмически прописанные правила.
Но пока опыт у всех разный. Общий знаменатель ещё не подведён. Потому и получается такой аморфный шум. Для меня тоже ещё много белых пятен в этом. Потому и стараюсь попасть на конференции по этому вопросу, чтобы иметь возможность пообщаться с людьми имеющими свой, альтернативный опыт.
А с DevOps общественность ещё в поиске.
Вот оно и странно. Мне всегда казалось, что обычно сначала придумывают содержание, а потом под это дело новый термин. Тут термин есть, но значение не определено. С таким же успехом можно говорить «Пыщ-пыщ». Подразумевать, что это означает «всё хорошее, без всего плохого». Мы внедрили «Пыщ-пыщ», показатели улучшились на 2%.
Содержание вполне себе придумано. Внедрять его оказалось непросто (потому что оно не про технологию). Вот и происходят шатания.
Термин есть, значение определено, но реальность вносит в это значение свои коррективы.
Вон есть термин Физика, Физика говорит, что она изучает мир, но ничего о нем не знает. А еще есть люди, которые про торсионные поля пишут и тоже это Физикой называют.
А DevOps это вообще практика, тут надо пробовать и переделывать и так бесконечно. Тоже самое происходит во всех областях жизни — абсолютного знания — нет.
взаимодействие людей измеряется качеством и скоростью релизов.
BTW, помню слушал подкаст с linkmeup, касающийся автоматизации работы сетевых инженеров с помощью ансиблов/питонов, там участвовали Наташа Самойленко, был еще один CCIE из Cisco TAC (может и больше, но один точно был), был сотрудник амазона и, кажется, eucariot. И кроме вопросов а-ля «а нужно ли сетевому инженегру писать скрипты» всплыл вопрос про devops. Говорилось о том, что встречается довольно большое количество вакансий «девопс». Так вот, на сколько я понял из подкаста, они вот тоже не очень уверены, что это точно такое, короче, пропорции условны, а границы размыты.
P.S. а может я просто быдло и не понимаю визионерских тенденций.
Спасибо вам, я хоть вижу, что не один такой.
что это мать вашу такое
Сочетание культуры, знаний и скиллзов.
почему и зачем оно
Чтобы выпускать более качественный софт чаще.
как оно вдруг захватило все окружающее пространство?
Когда некоторые продукты начинают получать преимущество над конкурентами, из-за того, что они выше качеством, и выпускаются чаще, конкуренты перенимают практику. Получается снежный ком, который достаточно быстро захватывает все окружающее пространство.
У меня возникло стойкое ощущение, что вы сами не понимаете, что это такое, но хотите быть в тренде, потому что все так делают. Вся эта возня новомодными смузи-специалистами напоминает мне эксперимент с обезьянами, бананом и струёй воды — кто-то авторитетный запустил этот загадочный девопс в массы, а остальные уже фантазируют на тему, что это такое, делая вид что знают, потому что так принято.
У меня возникло стойкое ощущение, что бы переходите на личности, называя "смузи-специалистом", и сравнивая с обезьяной. Напрасно вы это, чести это вам не делает.
Ни в коем разе по обоим пунктам. "Смузи-специалистами" я именую высосанные со скуки из пальца профессии, а ни в коем разе не вас или кого-то ещё. Прошу извинить, если неверно выразился и дал повод так подумать. В эксперименте с обезьянами суть не в обезьянах, а в социальной модели привития бессмысленных традиций и порядков.
ДевОпс это не профессия, это практика. Высосана она из пальца не от скуки, а в поисках конкурентного преимущества. Если компания может релизить чаще и качественней за счет сноса очередного барьера на пути кода от разработчика к клиенту, эта компания будет зарабатывать больше денег. Скука тут совсем непричем.
Не согласен, фрагментация и разбухание персонала в моем понимании бесконечно далеки от идеалов оптимизации процесса и не убирают барьеры, а создают новые. Бюрократизация ещё никогда не приводила к повышению эффективности. А уж тем качества, что вкладываются в понятие девопс в комментариях к этой статье и вовсе удивляют — это же портрет обычного многостаночника, админа в маленькой компании, который и картриджи меняет, и сети администрирует и код пишет.
Вариант А. Команда пилит продукт. На выходе получает war-ник. И отдает его команде эксплуатации, с набором инструкций, как деплоить. Всё, свою часть они сделали, все счастливы, все довольны. У второй команды свой цикл, свои правила, свои особенности. Проблемы с деплоем решает только вторая команда, пока не докажет первой, где ее косяк.
Вариант Б. Команда пилит продукт, и в том числе деплоит (и все остальное, что требуется для доставки продукта клиентам). Все проблемы, в том числе проблемы с деплоем, решает команда, одна команда. Очевидно, у команды должен быть нужный скилл по эксплуатации.
На ваш взгляд, в каком варианте в общем случае будет больше проблем? В каком варианте будет в среднем быстрее доставка?
DevOps — это просто ответ на потребность бизнеса, быстрее и качественнее релизиться. Один продукт — одна команда — один тимлидер, у которого достаточно ответственности и полномочий за весь жизненный цикл продукта.
Не давайте. Продажи и юридические вопросы — не инженерные практики. Сопроводжение, на определенном уровне — вполне себе, и внезапно, дежурные инженеры им таки занимаются.
Ну вот тут всякие Гуглы с Нетфликсами с вами не согласны. Ни в вопросе насколько близки программирование и администрирование, ни в вопросе есть ли, и должна ли быть сегрегация на разработчиков и админов.
программирование и администрирование друг от друга столь же далеки, как и оба вместе от продаж
Программирование и администрирование, действительно, имеют не пересекающиеся области знаний.
Примерно так же, как условный бэкэнд и условный фронтэнд. Но прямо сейчас, мало кто скажет, давайте для развития одного продукта создадим две команды, одна — бэкэнд, вторая — фронтэнд. Для большинства уже очевидно, должна быть одна команда — с бэкэнд- и фронтэнд-скиллами.
Такая же история с программированием/администрированием. Постепенно приходит понимание, что в команде должны быть люди, которые ближе к инфраструктуре.
И примерно также, как бэкэндщики/фронтэндщики должны быть в какой-то степени взаимозаменяемы. Также и разработчики/админы, должны быть в команде в какой-то степени взаимозаменяемы. Это не означает, что любой теперь сможет с нуля playbook написать. (точно так же как не означает, что любой бэкэндщик сможет с нуля страницу сверстать). Но поправить мелкие баги/изменить конфигурацию в playbook'е — вполне может любой.
На DevOps нужно смотреть через призму развития продукта. Чтобы продукт развивался быстрее и лучше конкурентов, нужно, чтобы все критически важные умения были в команде. Например, аналитика клиентского поведения, для вас важна, но не критична — можно отдать аналитику соседней сервисной команде, отвечающей за аналитику в целом. Например, мониторинг ключевых метрик вашего приложения в онлайн для вас очень критичен, тогда мониторинг должен быть полностью у вашей команды. А мониторинг вам нужен потому что вы хотите очень оперативно реагировать на изменения нагрузки, значит вам нужны люди в команде, знакомые с инфраструктурой не понаслышке.
Коллеги, я часто сравниваю свою способность объяснить, что такое DevOps c объяснением человеку из Саудовской Аравии какой смазкой надо смазывать лыжи при -5 для бега на лыжах свободным стилем.
Вы скорее всего не пробовали и судите о DevOps исходя из своего прошлого опыта, а он, конечно, не совсем накладывается на ваш опыт или наоборот полностью накладывается и вам кажется, что ничего нового.
Если вам действительно важно узнать, что такое DevOps, то рекомендую посмотреть мой доклад www.youtube.com/watch?v=eIV5D1HSmKI и прочитать книгу www.amazon.com/DevOps-Handbook-World-Class-Reliability-Organizations/dp/1942788002
В моем докладе вы узнаете зачем нужен DevOps, а из книги вы сможете взять содержание практики.
Хотите, я в нескольких предложениях всё это опишу? Да пожалуйста, вот 4 предложения:
1. (Зачем это надо) В условиях высокой конкуренции преимущество получают компании, которые способны как можно быстрее выкатывать релизы в ответ на запросы заказчика.
2. (Чем плох существующий порядок) Существование отдельных команд разработки и внедрения приводит к появлению имеющего значение временного лага как при внедрении, так и при обратной связи.
3. (Что предлагается) Совмещение функций вышеуказанных команд в одной команде позволит уменьшить временной лаг между разработкой и внедрением.
4. (Каким образом) Несмотря на то, что совмещение нескольких функций в одном человеке обычно снижает эффективность его труда, развитие современных инструментов разработки [список инструментов] позволяет это автоматизировать, делая труд разработчиков более эффективным.
Всё остальное — вода и философия.
> В Америке так принято вести дела, что все делают через продажу и обращение к социальной коммуникации. Поэтому невозможно читать их бизнес-книги. Просто сделайте на это скидку и попробуйте разобраться. Вот про что я говорю.
Теперь понятно, почему при прочтении информации о DevOps у меня складывается ощущение разводки в стиле сетевого маркетинга в его негативном смысле.
Поэтому я прошу вас не отправлять меня читать книги, от которых меня будет воротить, а в 5-10 предложениях описать своими словами, что вы понимаете под DevOps, для русскоязычной аудитории с учётом нашего менталитета.
Ну отлично же всё написали. Лучше DevOps в четырех предложениях, пожалуй и не опишешь.
Дальше начинаются скучные будни. Как совместить нескольких функций в одном человеке с минимальным снижением эффективности его труда, какие инструменты, и как позволяют это автоматизировать, и как сделать так, чтобы человек это захотел.
DevOps — это не человек
не получается, потому что на хх.ру написано: «требуется DevOps с 30 и более летним стажем, зарплата такая-то»
то есть бизнес ищет человека.
помню слушал подкаст с linkmeup, касающийся автоматизации работы сетевых инженеров
Так вот, на сколько я понял из подкаста, они вот тоже не очень уверены, что это точно такоеничего странного, сетевые инженеры и не должны разбираться в задачах devops'ов, имхо.
Просто сейчас такая модная тенденция пошла и любой сисадмин localhost, который видел в глаза ansible и раз в жизни запустивший docker считает себя devops инженером и требует соответствующую зп. А когда ты приглашаешь их на собеседование и начинаешь общаться, то становится страшно (из личного опыта), ибо знаний у них как у сисадмина localhost :)
- Уверенная база системного администратора, хотя бы middle
- Хорошо разбираться в git и различных workflow. Т.е. этот человек должен уметь построить workflow и объяснить команде почему и зачем стоит его использовать. Поэтому знание git на базовом уровне clone/pull/push будет недостаточно. Знание других vcs будет плюсом.
- Реальный опыт использование контейнеров. Docker Swarm/kubernetes/Mesos. А так же четкое представление отличия контейнеризации от виртаулизации. Понимание, когда следует использовать 1е, а когда 2е, какие преимущества и недостатки у каждой из систем.
- Реальный опыт построения CI/CD. Опыт работы с Jenkins/Gitlab CI/TC/etc
- Хороший опыт работы с облачными провайдерами — Amazone/GCP/Azure. Как минимум базовый набор сервисов.
- Хороший опыт в написании скриптов на python/ruby. Отличное знание bash подразумевается по дефолту. Базовое знание одного из яп — java/c/c++/c# будет плюсом.
- Хороший опыт работы с SCM. Хотя бы с ansible. Опыт работы с chef/saltstack/puppet будет плюсом
- Опыт написания тестов. Хотя бы на базовом уровне.
- Опыт профилирование и отладки приложений. Знание top и т.п. утилит это конечно хорошо, но их явно недостаточно. Поэтому человек, который будет знать и иметь опыт работы с perf/gdb/strace будет иметь преимущества
- Уверенное понимание жизненного цикла разработки ПО. Знание и опыт работы по одной из методологий — Scrum/Agile/Kanban будет плюсом.
- Опыт работы с Jira/Confluence/Redmine будет плюсом.
Я бы отбирал кандидатов примерно по такому списку.
То, что вы описали — требования к команде разработки/развёртывания. Нет, я не спорю, что тот же разработчик должен понимать принципы работы среды, в которую и будет установлено его приложение, но написание скриптов? Сисадминство на уровне middle? Кстати, а что это за чудо-уровень? Я вот умею развёртывать продукты ibm websphere(далеко не все), но в жизни не трогал docker, это какой уровень?
И да, если это то что называют DevOps — ну удачи в поисках. Не, думаю такие люди существуют. Где-то один на пару десятков в профессии.
Нет, я не спорю, что тот же разработчик должен понимать принципы работы среды, в которую и будет установлено его приложение, но написание скриптов?не совсем понял, а причем тут разработчик к скриптам? Ведь речь шла о devops инженере.
Сисадминство на уровне middle?как минимум, лучше конечно senior
Кстати, а что это за чудо-уровень?в каждой компании есть своя градация, поэтому middle из бухгалтерской конторки на 10 рабочих мест и middle с яндекса будут абсолютно разными по уровням. Думаю это очевидно.
Я вот умею развёртывать продукты ibm websphere(далеко не все), но в жизни не трогал docker, это какой уровень?если вы будете работать на проекте, где не используются докер, но активно используется websphere, то не все ли равно как вас будут называть? :) Насчет градаций см выше
И да, если это то что называют DevOps — ну удачи в поисках.я их как бы и не ищу, сам работаю devops инженером ;)
Ну и все выше сказанное это мое имхо, а не истина в последней инстанции.
не совсем понял, а причем тут разработчик к скриптам? Ведь речь шла о devops инженере.
Моя вина, после чтения списка была уверенность, что бОльшая часть пунктов относится именно к разработчикам. Перечитал, понял что ошибся.
в каждой компании есть своя градация, поэтому middle из бухгалтерской конторки на 10 рабочих мест и middle с яндекса будут абсолютно разными по уровням. Думаю это очевидно.
Мысль понял. Но тогда предполагается дополнительный человек с уровнем знаний используемых систем/железа повыше. То есть сисадмин дополнительно к DevOps'у.
Ну и все выше сказанное это мое имхо, а не истина в последней инстанции.
аналогично :)
Сегодня, учитывая количество технологий, их сложность и «наслаиваемость» трудно найти мидла, тем более реального синьора. А синьору, который умеет все то, что вы там написали про гиты/скрамы/c-плюс-плюсы, можно поручить решение проблемы перенаселения земли, он и с ней справится.
Я так и вижу мидла, который шарит в сетях хотя бы на уровне между ccna и ccnp (в достаточно большой организации по-любому как ccnp), достойно разбирается хотя бы в одной среде виртуализации, достойно разбирается в одной классической платформе ОС (Windows или *nix), достойно разбирается в хранении данных (сюда СХД, резервное копирование, SAN, если это FC, то как минимум FC фундаменталс нужно знать, brocade cli и всякое там) и так, между делом, изучил остальной список из 10 пунктов. ОК. И я забыл про всякие «незначительные» мелочи вроде служб каталогов, систем мониторинга, и прочей сопутствующей мишуры.
Мидл это мидл, синьор это синьор, в конторке из 10 человек не бывает мидлов, бывают технические специалистыну начать с того, что в трудовой вообще нет понятия devops и всяких новомодных рангов junior/middle. Я лишь привел для примера.
достойно разбирается в хранении данных (сюда СХД, резервное копирование, SAN, если это FC, то как минимум FC фундаменталс нужно знать, brocade cli и всякое там)Devops не занимается железом. Я например работаю только с aws стеком и я очень далек от всех проблем с железом, слава богу, в свое время нахлебался 5 лет с hetzner :)
И как правило devops не занимается сетью на серьезном уровне. Слабо себе представляю devops'а, который будет настраивать BGP и MPLS, по ходу дела делая код ревью :) Либо это будет уже netops
И я забыл про всякие «незначительные» мелочи вроде служб каталогов, систем мониторинга, и прочей сопутствующей мишуры.это все входит в обязанности сисадмина.
Или тогда конкретизируйте понятие сисадмина в вашем понимании. А то у кого то человек, который админит один сервер и меняет мышки и картриджи, тоже считается сисадмином :)
То, что вы описали — требования к команде разработки/развёртывания
Вот эта команда — devops и есть.
Так вот ты какой, современный Шива многорукий.
ну почему, я вот окончил универ по специальности b.sc. computer science, параллельно работая сисадмином в среднего размера компании, периодически работая на проектах в команде DevOps'ов, 5 лет стажа, сертификат LPIC-2. Это и есть уровень middle. Я прекрасно умею дебажить код, хотя это и не моя основная задача, как и было сказано выше в статье DevOps это культура общения, когда программист будет слушать сисадмина как исправить ошибку в коде, а сисад подправит ulimit -n в системе, потому что дев знает что с меньшим ulimit его софт будет глючить. И да я подхожу под все выше описаные пункты, и да нас очень мало и зарплата у нас соответствующая :)
Я вот тоже не понимаю что это такое и главное чем оно отличается от того что мы уже лет двадцать делаем? Автоматизированная сборка и деплой? Есть. Девелопер решает когда и что пойдет в прод? Есть. Команда эксплуатации? Нет, не видел.
Ну так что такое DevOps? Я прочел все коментарии. Вода и ничего кроме. Общие слова про «изменение культуры», «новый подход» и прочий белый шум.
То, что вы описали выше это обычный build engineer.
То, что вы описали выше это обычный build engineer.build engineer не использует даже половину из того списка, имхо. Много билд инженеров вы видели, которые настраивают и поддерживают системы мониторинга и профилирования приложений? Я вот таких не встречал, но я не исключаю, что все может быть
А если разрабатываются тяжелые сервисы под Windows да еще и без контейнеров и не на Java, да деплоится все автоматически, но с бюрократией видимо никакого DevOps не будет, да?devops никак не завязан на ОС/архитектуру/ЯП.
и главное чем оно отличается от того что мы уже лет двадцать делаем?я вот тоже не знаю, кто такие мы и что вы там уже лет двадцать делаете
Честно говоря — все кого видел именно этим и занимались. Иначе зачем они вообще?
> devops никак не завязан на ОС/архитектуру/ЯП.
Это было к «3. Реальный опыт использование контейнеров. » и далее.
>…
Мы — это все мы. Сообщество программистов и админов. Термин DevOps появился из ниоткуда. Всегда (с 60х годов точно :) ) программисты и админы в программерских конторах (или конторах с большой долей IT, как банки например) работали совместно. Может что-то изменилось и в волшебном мире вэб разработки есть какие-то отдельные админы, которые могут принимать решения поставить новую версию in-house software или нет, но в моем мире их нет. Решение за программистом, разрешение за бюрократами.
Честно говоря — все кого видел именно этим и занимались. Иначе зачем они вообще?само название build как бы говорит само за себя, имхо. Возможно тут проблема в том, что у нас любят вешать на одного человека обязанности 10, а платить как одному. В крупных компаниях такого, как правило, нет. По крайней мере из личного опыта.
программисты и админы в программерских конторах (или конторах с большой долей IT, как банки например) работали совместно.и много по вашему эникейщик из банка взаимодействует с программистом? Или тот же местный(филиальный) админ?
Может что-то изменилось и в волшебном мире вэб разработки есть какие-то отдельные админы, которые могут принимать решения поставить новую версию in-house software или нет, но в моем мире их нет. Решение за программистом,не всегда. 7 лет работал админом в веб разработке. Так вот у нас маркаперы не знали как установить/запустить gulp, как настроить фотошоп и т.п. вещи, запустить и что то поменять в том же денвере это вообще было из области фантастики. Про всякие докеры/вагранты вообще молчу.
8. Опыт написания тестов. Хотя бы на базовом уровне.
— это уже особенности ваших личных компетенций
или размера вашей нынешней конторы.
У меня в конторе из 50 человек
были:
- целый отдел тестирования,
- 7 опсов
и
- 2 девопса.
В вашем случае получается 2в1
это уже особенности ваших личных компетенций или размера вашей нынешней конторы.возможно. В свое время я использовал php framework Codeception для написания простеньких acceptance тестов, которые запускались после деплоя. Не вижу в этом ничего выдающегося или сверх сложного. А тестировщики у нас занимались немного другим.
1) DevOps возникает там,
где нужно поддерживать крупную,
но при этом хорошо масштабируемую
инфраструктуру — тысячи серверов и сетевых устройств
2) Слово "поддержка" подразумевает затраты.
Если используют нестандартные инструменты
(самописные bash, а то и PERL скрипты)
затраты на (развитие, изменение, масштабирование)
могут быть непредсказуемыми
3) дальше речь об устойчивости и надёжности
если "то как всё работает" содержится в голове
у единственного человека (или даже нескольких)
- бизнес очень рискует.
Собьёт ли его машина
или у него просто плохое настроение…
Последствия могут быть непредсказуемы
Мозги у админов и программистов работают по разному. Поэтому у них разный круг ответственности и должностные полномочия.
Программист хочет чтобы его код работал, а сисадмин хочет, чтобы работал код, но ещё сервер (облако) (на этом месте программесту стало скучно и он пошёл кодить дальше), свичи, бекап, мониторинг и ещё много чего.
Почему никому не приходит в голову такой чудесный тянитолкай как DevPM — программист менеджер проектов или DevSales — программист менеджер по продажам — можно тоже пару штатных единиц сэкономить.
Почему никому не приходит в голову такой чудесный тянитолкай как DevPM — программист менеджер проектов или DevSales — программист менеджер по продажам — можно тоже пару штатных единиц сэкономить.
Потому что DevOps это не об экономии штатых единиц.
Точка зрения менеджера на cost cutting. А devops — это магнитола «средненькое радио и посредственный магнитофон в одном корпусе».
Когда я заканчивал учебу на программиста (где учили и word и pascal и сети) и устраивался на первую работу, тогда для большинства людей слова программист, вебмастер, системный администратор и системный блок означали одно и тоже. Вебмастер делал всё. Дизайн, вёрстка, код.
Но время шло и с развитием веба вебмастер начал делится на дизайнера, разработчика… Сис. админ на эникейщика, сетевого инженера и т.д.
Я к тому, что возможно сейчас только сформировывается некий пласт обязанностей и знаний, который ещё сильно пересекается с другими областями и поэтому у него нету своей четкой позиции. Но со временем, отделившись, будет называться DevOps.
DevOps сейчас — как version control десять лет назад, скоро все там будем