Pull to refresh

Comments 75

Десять лет назад? Например СVS уже 27 лет, а git — 12.

Речь про то, что 10 лет назад все это было ощутимо менее распространено. А сегодня в GitHub даже школьники pet-проекты заливают.

Возможно мы в разных мирах живем, но когда я начинал работать (примерно 12 лет назад) за неумение пользоваться svn уже били по пальцам.

А мы 10 лет назад еще сидели на Microsoft Visual Source Safe 6.0, там даже параллельной работы с файлом не было — взял в работу, значит заблокировал файл от изменения другими пользователями.

А Вы сомневались во множественности миров? В моём мире и 12 лет назад, и сегодня VCS не нужны никому, кроме меня.
Да что удивляться, возьмите стройку. Бригада ух из США собрала здание церкви за неделю. Бригада ох из очень средней азии делает тот же объём за полтора-два месяца. Почему? У первых есть типовой техпроцесс и дорогой, но эффективный инструментарий, который экономит ещё более дорогое время работника. НО: у нас все работают как бригада ох, и не работают, как бригада ух. Скорее всего, потому, что доступные на рынке труда работники убьют или пропьют дорогой инструмент, и толку не будет. Поэтому есть, что есть.
Вот вам и иные миры...

Вопрос не в знании, что такое source control. Вопрос в решении его применимости. 10 лет назад многие, например, считали, что это только для больших команд. Так и с девопсом. Уже многие понимают, о чем это, но считают, что это только для какого-нибудь Гугла, а мы по-старинке, сисадминим. Ну вот через 10 лет никому по-старинке в голову не придет.

Ну да, но был уже раскачаный SVN. Даже под винду уже существовали удобные тулы, типа Туртойз. Ну и CVS уже был де факто стандартом. А под винду было много платных систем.

ClearCase — это 1992. В 98ом году он умел все тоже что и гит (и мне так кажется был даже более удобным). Но мерж в мастер был медленными очень. По часу. Чекины в свою песочницу тоже. Может по этому народ Version Control ограниченно использовал. Часто дело просто в хардваре.

Недавно сформулировал для себя такое определение:


SysOps — это про настройку оборудования, чтобы оно работало правильно и быстро. А DevOps — это про настройку разработчиков, чтобы они работало правильно и быстро.


Полностью подписываюсь под словами Баруха и Александра. Самое сложное — переломить сознание людей. Заставить их сотрудничать и не тянуть одеяло на себя. А инструменты — дело наживное.

DevOps — не разработчиков, а систему в целом разработчики -> разработка -> тестирование -> релиз и так далее.
SysOps — про настройку и поддержку инфраструктуры (железо, сети, ОС, СХД, СУБД, application-сервера, доступы,… список длинный), в которой работают программы, разрабатываемые программистами. DevOps — про то, что эти две группы должны работать с одними и теми же инструментами и рабочими процессами, т.о. стирая грань между ними.

Ну вот я уже несколько лет вокруг этого кручусь. Что получил в итоге? Инструменты есть, а DevOps'а нет! Почему? Потому, что инструменты должны быть не как цель, а как следствие стремления людей что-то улучшить. Улучшить глобально. Найти общий язык всех со всеми. Понять что таки нужно на самом деле и сделать это.


Инструменты — всего лишь инструменты. Без правильно настроенных на нужный результат людей это так и останется мёртвым грузом.


И камень с мёртвой точки у меня начал смещаться именно когда я понял, что DevOps это про людей и именно про людей. Если правильно нашёл заинтересованных, корректно подал им мысль что и как можно улучшить, порекомендовал полезные решения, помог их реализовать, и т.д. и т.п… Внезапно всё раз — и побежало. И начали появляться решения, эти решения начали использоваться пошол DevOps.


А то, что вы описали — скорее таки SysOps. Да Он тоже нужен. Но это в целом очень другая относительно разработки компетенция. И грамотный сисадмин с классическими подходами тут может оказаться гораздо ценнее.


Сисадмин не должен программировать сложные системы. Программист не должен тюнить СХД. Один человек не в состоянии иметь глубокую компетенцию везде. Иначе будет беда.


А вот взаимодействие этих гатегорий людей ради конкретного результата — вот это уже ближе к DevOps. Но таки людей.

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

В целом про eagel или scrum можно сказать точно так же. Разница лишь в том, что они старше и люди уже чётко договорились что конкретно под этим следует понимать. А с DevOps общественность ещё в поиске. Просто начало формироваться видение, что те-же производственные задачи можно решать ещё одним способом, который меньше полагается на договорённости и человеческий фактор, а больше на автоматизацию и алгоритмически прописанные правила.


Но пока опыт у всех разный. Общий знаменатель ещё не подведён. Потому и получается такой аморфный шум. Для меня тоже ещё много белых пятен в этом. Потому и стараюсь попасть на конференции по этому вопросу, чтобы иметь возможность пообщаться с людьми имеющими свой, альтернативный опыт.

А с DevOps общественность ещё в поиске.

Вот оно и странно. Мне всегда казалось, что обычно сначала придумывают содержание, а потом под это дело новый термин. Тут термин есть, но значение не определено. С таким же успехом можно говорить «Пыщ-пыщ». Подразумевать, что это означает «всё хорошее, без всего плохого». Мы внедрили «Пыщ-пыщ», показатели улучшились на 2%.
Зато можно продавать книжки, организовывать конференции…

Вы так говорите, как-будто это что-то плохое. Вы как сами развиваете профессиональные знания? Не книжками, и не конференциями?

Содержание вполне себе придумано. Внедрять его оказалось непросто (потому что оно не про технологию). Вот и происходят шатания.
Термин есть, значение определено, но реальность вносит в это значение свои коррективы.

Так происходит практически со всеми дисциплинами, они разработаны ровно настолько, насколько они разработаны. Для разработки нужна коммуникация, нужны статьи, конференции. Кто-то знает больше, кто-то меньше.

Вон есть термин Физика, Физика говорит, что она изучает мир, но ничего о нем не знает. А еще есть люди, которые про торсионные поля пишут и тоже это Физикой называют.

А DevOps это вообще практика, тут надо пробовать и переделывать и так бесконечно. Тоже самое происходит во всех областях жизни — абсолютного знания — нет.

взаимодействие людей измеряется качеством и скоростью релизов.

Еще несколько месяцев назад термин DevOps был мне совершенно неизвестен, а теперь как минимум один заголовок первой страницы хабра его содержит. Вот оно какое — чувство приближающейся старости!
Ничего страшного, пройдёт ещё лет 5-10 и вместо DevOps придумают что-нибудь ещё.

Магистр кибернетики (как в Польше сейчас)

Хорошо, если 5-10 лет, а не 5-10 дней, как обычно…
Не знаю на счет старости, мне 28 и для меня это выглядит как маркетинговые понты. Какой-то модный тренд, который не дает четкого понятия, какие у человека должны быть компетенции, чем он конкретно должен заниматься и в какой области. Звучит как специалист по всему, а специалист по всему — это специалист по ничему.

BTW, помню слушал подкаст с linkmeup, касающийся автоматизации работы сетевых инженеров с помощью ансиблов/питонов, там участвовали Наташа Самойленко, был еще один CCIE из Cisco TAC (может и больше, но один точно был), был сотрудник амазона и, кажется, eucariot. И кроме вопросов а-ля «а нужно ли сетевому инженегру писать скрипты» всплыл вопрос про devops. Говорилось о том, что встречается довольно большое количество вакансий «девопс». Так вот, на сколько я понял из подкаста, они вот тоже не очень уверены, что это точно такое, короче, пропорции условны, а границы размыты.

P.S. а может я просто быдло и не понимаю визионерских тенденций.
Вы вернули мне ощущение целостности реальности, потому что последний месяц я в панике наблюдаю за этим devops-трендом с полным ощущением себя больным какой-то формой дислексии, не позволяющей понять: откуда это взялось, что это такое и почему вокруг этого столько шума? Я вижу статьи, где DevOps используется как какое-то укоренившееся понятие, с которым каждый сталкивается каждый день в IT-обиходе и мне стыдно просто спросить «что это мать вашу такое, почему и зачем оно, а главное — как оно вдруг захватило все окружающее пространство?!»
Спасибо вам, я хоть вижу, что не один такой.
что это мать вашу такое

Сочетание культуры, знаний и скиллзов.


почему и зачем оно

Чтобы выпускать более качественный софт чаще.


как оно вдруг захватило все окружающее пространство?

Когда некоторые продукты начинают получать преимущество над конкурентами, из-за того, что они выше качеством, и выпускаются чаще, конкуренты перенимают практику. Получается снежный ком, который достаточно быстро захватывает все окружающее пространство.

У меня возникло стойкое ощущение, что вы сами не понимаете, что это такое, но хотите быть в тренде, потому что все так делают. Вся эта возня новомодными смузи-специалистами напоминает мне эксперимент с обезьянами, бананом и струёй воды — кто-то авторитетный запустил этот загадочный девопс в массы, а остальные уже фантазируют на тему, что это такое, делая вид что знают, потому что так принято.

У меня возникло стойкое ощущение, что бы переходите на личности, называя "смузи-специалистом", и сравнивая с обезьяной. Напрасно вы это, чести это вам не делает.

Ни в коем разе по обоим пунктам. "Смузи-специалистами" я именую высосанные со скуки из пальца профессии, а ни в коем разе не вас или кого-то ещё. Прошу извинить, если неверно выразился и дал повод так подумать. В эксперименте с обезьянами суть не в обезьянах, а в социальной модели привития бессмысленных традиций и порядков.

ДевОпс это не профессия, это практика. Высосана она из пальца не от скуки, а в поисках конкурентного преимущества. Если компания может релизить чаще и качественней за счет сноса очередного барьера на пути кода от разработчика к клиенту, эта компания будет зарабатывать больше денег. Скука тут совсем непричем.

Не согласен, фрагментация и разбухание персонала в моем понимании бесконечно далеки от идеалов оптимизации процесса и не убирают барьеры, а создают новые. Бюрократизация ещё никогда не приводила к повышению эффективности. А уж тем качества, что вкладываются в понятие девопс в комментариях к этой статье и вовсе удивляют — это же портрет обычного многостаночника, админа в маленькой компании, который и картриджи меняет, и сети администрирует и код пишет.

Ну смотрите.
Вариант А. Команда пилит продукт. На выходе получает war-ник. И отдает его команде эксплуатации, с набором инструкций, как деплоить. Всё, свою часть они сделали, все счастливы, все довольны. У второй команды свой цикл, свои правила, свои особенности. Проблемы с деплоем решает только вторая команда, пока не докажет первой, где ее косяк.

Вариант Б. Команда пилит продукт, и в том числе деплоит (и все остальное, что требуется для доставки продукта клиентам). Все проблемы, в том числе проблемы с деплоем, решает команда, одна команда. Очевидно, у команды должен быть нужный скилл по эксплуатации.

На ваш взгляд, в каком варианте в общем случае будет больше проблем? В каком варианте будет в среднем быстрее доставка?

DevOps — это просто ответ на потребность бизнеса, быстрее и качественнее релизиться. Один продукт — одна команда — один тимлидер, у которого достаточно ответственности и полномочий за весь жизненный цикл продукта.
Звучит просто великолепно — два в одном, меньше персонала, меньше головной боли по менеджменту, за это даже можно доплатить. Но почему-то мне, прочитав ваше сообщение, очень хочется добавить «а давайте они еще и продажами будут занимать, сопровождением и юридическими вопросами?»

Не давайте. Продажи и юридические вопросы — не инженерные практики. Сопроводжение, на определенном уровне — вполне себе, и внезапно, дежурные инженеры им таки занимаются.

Вы знаете, программирование и администрирование друг от друга столь же далеки, как и оба вместе от продаж. Сегрегация на разработчиков и инженеров всегда была, есть и будет есть. Все универсалы таковыми становятся поневоле, но настоящие профи — они или сильные программисты, или крутые админы, или сосредоточенные руководители-бюрократы (эти, конечно, часто получаются из предыдущих двух с непременной утратой навыка по мере погружения в административную работу)

Ну вот тут всякие Гуглы с Нетфликсами с вами не согласны. Ни в вопросе насколько близки программирование и администрирование, ни в вопросе есть ли, и должна ли быть сегрегация на разработчиков и админов.

программирование и администрирование друг от друга столь же далеки, как и оба вместе от продаж

Программирование и администрирование, действительно, имеют не пересекающиеся области знаний.
Примерно так же, как условный бэкэнд и условный фронтэнд. Но прямо сейчас, мало кто скажет, давайте для развития одного продукта создадим две команды, одна — бэкэнд, вторая — фронтэнд. Для большинства уже очевидно, должна быть одна команда — с бэкэнд- и фронтэнд-скиллами.
Такая же история с программированием/администрированием. Постепенно приходит понимание, что в команде должны быть люди, которые ближе к инфраструктуре.

И примерно также, как бэкэндщики/фронтэндщики должны быть в какой-то степени взаимозаменяемы. Также и разработчики/админы, должны быть в команде в какой-то степени взаимозаменяемы. Это не означает, что любой теперь сможет с нуля playbook написать. (точно так же как не означает, что любой бэкэндщик сможет с нуля страницу сверстать). Но поправить мелкие баги/изменить конфигурацию в playbook'е — вполне может любой.

На DevOps нужно смотреть через призму развития продукта. Чтобы продукт развивался быстрее и лучше конкурентов, нужно, чтобы все критически важные умения были в команде. Например, аналитика клиентского поведения, для вас важна, но не критична — можно отдать аналитику соседней сервисной команде, отвечающей за аналитику в целом. Например, мониторинг ключевых метрик вашего приложения в онлайн для вас очень критичен, тогда мониторинг должен быть полностью у вашей команды. А мониторинг вам нужен потому что вы хотите очень оперативно реагировать на изменения нагрузки, значит вам нужны люди в команде, знакомые с инфраструктурой не понаслышке.
Здесь нет противоречений. Разработка DevOps командой обходится дороже, чем классическая, т.к. разработчиков нужно тупо больше. Также за счёт их многостаночности у таких разработчиков ещё и выше аппетиты. Но если эта технология даёт конкуретное преимущество и окупает затраты, в ней есть смысл.
DevOps — это практика и методология производства цифровых продуктов и платформ. Это не человек, не команда и не инструмент. Практика живая и постоянно развивающаяся засчет глобального коммьюнити.

Коллеги, я часто сравниваю свою способность объяснить, что такое DevOps c объяснением человеку из Саудовской Аравии какой смазкой надо смазывать лыжи при -5 для бега на лыжах свободным стилем.

Вы скорее всего не пробовали и судите о DevOps исходя из своего прошлого опыта, а он, конечно, не совсем накладывается на ваш опыт или наоборот полностью накладывается и вам кажется, что ничего нового.

Если вам действительно важно узнать, что такое DevOps, то рекомендую посмотреть мой доклад www.youtube.com/watch?v=eIV5D1HSmKI и прочитать книгу www.amazon.com/DevOps-Handbook-World-Class-Reliability-Organizations/dp/1942788002

В моем докладе вы узнаете зачем нужен DevOps, а из книги вы сможете взять содержание практики.
Дело не в опыте, а в том, что сущность DevOps описывают так, как будто это какой-нибудь MLM, бизнес-тренинги или секта. Посмотрите видео, почитайте книгу — слов и философии там много, а смысла мало.

Хотите, я в нескольких предложениях всё это опишу? Да пожалуйста, вот 4 предложения:

1. (Зачем это надо) В условиях высокой конкуренции преимущество получают компании, которые способны как можно быстрее выкатывать релизы в ответ на запросы заказчика.

2. (Чем плох существующий порядок) Существование отдельных команд разработки и внедрения приводит к появлению имеющего значение временного лага как при внедрении, так и при обратной связи.

3. (Что предлагается) Совмещение функций вышеуказанных команд в одной команде позволит уменьшить временной лаг между разработкой и внедрением.

4. (Каким образом) Несмотря на то, что совмещение нескольких функций в одном человеке обычно снижает эффективность его труда, развитие современных инструментов разработки [список инструментов] позволяет это автоматизировать, делая труд разработчиков более эффективным.

Всё остальное — вода и философия.
Ну вот вы не смотрели видео, книгу не читали, а говорите. В Америке так принято вести дела, что все делают через продажу и обращение к социальной коммуникации. Поэтому невозможно читать их бизнес-книги. Просто сделайте на это скидку и попробуйте разобраться. Вот про что я говорю.
Вы правы, я не смотрел видео, не читал книгу, и не собираюсь этого делать. Меня не устраивают предлагаемые вами варианты получения информации: посмотреть часовое видео (со звуком) у меня нет никакой возможности, а книгу вы предлагаете купить в зарубежном магазине.

> В Америке так принято вести дела, что все делают через продажу и обращение к социальной коммуникации. Поэтому невозможно читать их бизнес-книги. Просто сделайте на это скидку и попробуйте разобраться. Вот про что я говорю.

Теперь понятно, почему при прочтении информации о DevOps у меня складывается ощущение разводки в стиле сетевого маркетинга в его негативном смысле.

Поэтому я прошу вас не отправлять меня читать книги, от которых меня будет воротить, а в 5-10 предложениях описать своими словами, что вы понимаете под DevOps, для русскоязычной аудитории с учётом нашего менталитета.

Ну отлично же всё написали. Лучше DevOps в четырех предложениях, пожалуй и не опишешь.
Дальше начинаются скучные будни. Как совместить нескольких функций в одном человеке с минимальным снижением эффективности его труда, какие инструменты, и как позволяют это автоматизировать, и как сделать так, чтобы человек это захотел.

DevOps — это не человек

не получается, потому что на хх.ру написано: «требуется DevOps с 30 и более летним стажем, зарплата такая-то»
то есть бизнес ищет человека.
Это временное заблуждение, еще пару лет и пройдет.
Создаётся ощущение слова «Ку!» из фильма «Кин Дза Дза». Открываешь статью с заголовком «DevOps пыщ-пыщ!», а там просто про контейнеры. Наверное я тоже в этом ничего не понимаю.

Если игнорировать культурые и поведенческие аспекты ДевОпса, то получается просто про контейнеры, да. Да чего уж, просто про Дженкинс может получиться.

помню слушал подкаст с linkmeup, касающийся автоматизации работы сетевых инженеров
Так вот, на сколько я понял из подкаста, они вот тоже не очень уверены, что это точно такое
ничего странного, сетевые инженеры и не должны разбираться в задачах devops'ов, имхо.

Просто сейчас такая модная тенденция пошла и любой сисадмин localhost, который видел в глаза ansible и раз в жизни запустивший docker считает себя devops инженером и требует соответствующую зп. А когда ты приглашаешь их на собеседование и начинаешь общаться, то становится страшно (из личного опыта), ибо знаний у них как у сисадмина localhost :)
Что должен знать настоящий devops?
Как по мне

  1. Уверенная база системного администратора, хотя бы middle
  2. Хорошо разбираться в git и различных workflow. Т.е. этот человек должен уметь построить workflow и объяснить команде почему и зачем стоит его использовать. Поэтому знание git на базовом уровне clone/pull/push будет недостаточно. Знание других vcs будет плюсом.
  3. Реальный опыт использование контейнеров. Docker Swarm/kubernetes/Mesos. А так же четкое представление отличия контейнеризации от виртаулизации. Понимание, когда следует использовать 1е, а когда 2е, какие преимущества и недостатки у каждой из систем.
  4. Реальный опыт построения CI/CD. Опыт работы с Jenkins/Gitlab CI/TC/etc
  5. Хороший опыт работы с облачными провайдерами — Amazone/GCP/Azure. Как минимум базовый набор сервисов.
  6. Хороший опыт в написании скриптов на python/ruby. Отличное знание bash подразумевается по дефолту. Базовое знание одного из яп — java/c/c++/c# будет плюсом.
  7. Хороший опыт работы с SCM. Хотя бы с ansible. Опыт работы с chef/saltstack/puppet будет плюсом
  8. Опыт написания тестов. Хотя бы на базовом уровне.
  9. Опыт профилирование и отладки приложений. Знание top и т.п. утилит это конечно хорошо, но их явно недостаточно. Поэтому человек, который будет знать и иметь опыт работы с perf/gdb/strace будет иметь преимущества
  10. Уверенное понимание жизненного цикла разработки ПО. Знание и опыт работы по одной из методологий — Scrum/Agile/Kanban будет плюсом.
  11. Опыт работы с Jira/Confluence/Redmine будет плюсом.


  12. Я бы отбирал кандидатов примерно по такому списку.
Так вот ты какой, современный Шива многорукий.
То, что вы описали — требования к команде разработки/развёртывания. Нет, я не спорю, что тот же разработчик должен понимать принципы работы среды, в которую и будет установлено его приложение, но написание скриптов? Сисадминство на уровне middle? Кстати, а что это за чудо-уровень? Я вот умею развёртывать продукты ibm websphere(далеко не все), но в жизни не трогал docker, это какой уровень?
И да, если это то что называют DevOps — ну удачи в поисках. Не, думаю такие люди существуют. Где-то один на пару десятков в профессии.
Нет, я не спорю, что тот же разработчик должен понимать принципы работы среды, в которую и будет установлено его приложение, но написание скриптов?
не совсем понял, а причем тут разработчик к скриптам? Ведь речь шла о devops инженере.

Сисадминство на уровне middle?
как минимум, лучше конечно senior

Кстати, а что это за чудо-уровень?
в каждой компании есть своя градация, поэтому middle из бухгалтерской конторки на 10 рабочих мест и middle с яндекса будут абсолютно разными по уровням. Думаю это очевидно.

Я вот умею развёртывать продукты ibm websphere(далеко не все), но в жизни не трогал docker, это какой уровень?
если вы будете работать на проекте, где не используются докер, но активно используется websphere, то не все ли равно как вас будут называть? :) Насчет градаций см выше

И да, если это то что называют DevOps — ну удачи в поисках.
я их как бы и не ищу, сам работаю devops инженером ;)

Ну и все выше сказанное это мое имхо, а не истина в последней инстанции.
не совсем понял, а причем тут разработчик к скриптам? Ведь речь шла о devops инженере.

Моя вина, после чтения списка была уверенность, что бОльшая часть пунктов относится именно к разработчикам. Перечитал, понял что ошибся.
в каждой компании есть своя градация, поэтому middle из бухгалтерской конторки на 10 рабочих мест и middle с яндекса будут абсолютно разными по уровням. Думаю это очевидно.

Мысль понял. Но тогда предполагается дополнительный человек с уровнем знаний используемых систем/железа повыше. То есть сисадмин дополнительно к DevOps'у.
Ну и все выше сказанное это мое имхо, а не истина в последней инстанции.

аналогично :)
Мидл это мидл, синьор это синьор, в конторке из 10 человек не бывает мидлов, бывают технические специалисты, которые решают какие-то проблемы за 5 копеек денег, потому что в таких конторах к ИТ относятся по остаточному принципу.
Сегодня, учитывая количество технологий, их сложность и «наслаиваемость» трудно найти мидла, тем более реального синьора. А синьору, который умеет все то, что вы там написали про гиты/скрамы/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 его софт будет глючить. И да я подхожу под все выше описаные пункты, и да нас очень мало и зарплата у нас соответствующая :)
А если разрабатываются тяжелые сервисы под Windows да еще и без контейнеров и не на Java, да деплоится все автоматически, но с бюрократией видимо никакого DevOps не будет, да?

Я вот тоже не понимаю что это такое и главное чем оно отличается от того что мы уже лет двадцать делаем? Автоматизированная сборка и деплой? Есть. Девелопер решает когда и что пойдет в прод? Есть. Команда эксплуатации? Нет, не видел.

Ну так что такое 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) дальше речь об устойчивости и надёжности
если "то как всё работает" содержится в голове
у единственного человека (или даже нескольких)


  • бизнес очень рискует.
    Собьёт ли его машина
    или у него просто плохое настроение…
    Последствия могут быть непредсказуемы
Говорил раньше и повторю сейчас — всё это любовь DevOps это русские ПМы (и прочий отдел маркетинга) придумали, чтобы денег не платить сисадмина не нанимать. Как в 1997м кричали — «А-а-а-а, Windows NT это просто — любой студент может её админить», в результате имеем отдельную уважаемую и дорого оплачиваемую профессию — MSCE и что характерно *никсовые сервера не устарели и не вымерли массово.
Мозги у админов и программистов работают по разному. Поэтому у них разный круг ответственности и должностные полномочия.
Программист хочет чтобы его код работал, а сисадмин хочет, чтобы работал код, но ещё сервер (облако) (на этом месте программесту стало скучно и он пошёл кодить дальше), свичи, бекап, мониторинг и ещё много чего.
Почему никому не приходит в голову такой чудесный тянитолкай как DevPM — программист менеджер проектов или DevSales — программист менеджер по продажам — можно тоже пару штатных единиц сэкономить.
Почему никому не приходит в голову такой чудесный тянитолкай как DevPM — программист менеджер проектов или DevSales — программист менеджер по продажам — можно тоже пару штатных единиц сэкономить.

Потому что DevOps это не об экономии штатых единиц.

Если вы задумаетесь, то сможете сами ответить себе на вопрос — это именно об экономии штатных единиц и ни о чём другом.
Точка зрения менеджера на cost cutting. А devops — это магнитола «средненькое радио и посредственный магнитофон в одном корпусе».

Еще раз, это не об экономии штатых единиц. Это о более частых и качественных релизах. Не cost cutting ни разу.

А может по другому всё.
Когда я заканчивал учебу на программиста (где учили и word и pascal и сети) и устраивался на первую работу, тогда для большинства людей слова программист, вебмастер, системный администратор и системный блок означали одно и тоже. Вебмастер делал всё. Дизайн, вёрстка, код.
Но время шло и с развитием веба вебмастер начал делится на дизайнера, разработчика… Сис. админ на эникейщика, сетевого инженера и т.д.
Я к тому, что возможно сейчас только сформировывается некий пласт обязанностей и знаний, который ещё сильно пересекается с другими областями и поэтому у него нету своей четкой позиции. Но со временем, отделившись, будет называться DevOps.
Очень тонкая иллюстрация: во-первых, ремень надет криво, во-вторых, DEV и OPS будут крутиться в разные стороны. Обычно так и получается, когда «внедряют дивапс».

Это наверное потому, что это иллюстрация, а не техническая диаграмма. Но это не точно.

Sign up to leave a comment.