Новые методологии и сопротивление мозга. DevOps.

А где же у вас тестировщики ? :) Так то да, не плохо. Деплоить виртуалки можно и тераформом/пакером (про инструментарий не буду дискутировать), а как проверить его, приложения, работоспособность ?

А так Вы тут как раз DevOps и описали, пропустив стадию тестирования.

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

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

Бизнес-модель вкратце:

1. Есть какое-то очень простое действие, не требующее ни материальных, ни особых умственных затрат. Например, администрирование серверов.

2. Объявляем это действие аццки сложным, непонятным, немасштабируемым, нетранклюкируемым и затрудняющим промайлинг и апрейтинг (т.е. нагло врём и придумываем на ходу новояз). Тут ещё помогут тупые обезьяны из вендузятных эникеев и менеджеры.

3. Для решения этих придуманных проблем выкатываем «энтерпрайзную систему деплоймента и промайлинга с высоким апрейтингом». Сопровождаем это хайпом, организуем какую-нибудь конференцию со смузи и маффинами, устанавливаем аццкий ценник на топовое предложение, чтобы все подумали что это круто.

4. PROFIT

Есть какое-то очень простое действие, не требующее ни материальных, ни особых умственных затрат. Например, администрирование серверов.

Да-да, вот вы как нарешаете без умственных затрат палками копалками, так глянешь на это.. и пойдешь бизнес модель создавать.

Открываешь код вашей deploy-системы и показываешь человеку с реальным опытом разработки на этом языке программирования. Потом считаешь количество facepalm-ов на строку кода.

Тут два момента, во-первых почему вы не признаете наш опыт программирования. Т.е. если мы покажем senior-питонисту то, полагаю, да, он сделает ряд замечаний. Но второй момент - какое дело бизнессу до его замечаний, если требования бизнеса выполнены, а потребители счастливы. Т.е. это не конкретный разговор. Конкретный - когда приходит заказчик, ставит требование, мол у нас 400 сервисов и их нужно деплоить за минуту. А мы ему говорим - извини, друг, но не выйдет. Вот тогда возникает конкретная ситуация когда надо привлекать «общественность» и решать этот спор, или в пользу «послабления» требований или в сторону переработки/рефакторинга кода деплоя. Но таких ситуаций у нет, к счастью.) (Если чего - мы простые штуки деплоим еще быстрее, а сервисов у нас больше 400 ;) ).

^ вот это девопс

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

Да-да, вот вы как нарешаете без умственных затрат палками копалками, так глянешь на это..

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

и пойдешь бизнес модель создавать.

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

На это и расчёт.

Вообще, первыми эту бизнес-модель прочухал вовсе не сугубо IT-шный народ, а околобухгалтерский и околоERPшный. Видимо нынче качество «админов» таки скатилось до уровня понимания компьютеров бухгалтерами или менеджерами.

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

Тут два момента, во-первых почему вы не признаете наш опыт программирования.

Потому что у команды админов нет опыта программирования. У них есть опыт написания скриптов.

Вот тогда возникает конкретная ситуация

тогда будет уже поздно

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

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

Так что через пару лет проще все выкинуть и переписать.

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

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

Доморощенные автоматизированные монстры которые так любят создавать админы, повисают на разработке мертвым грузом, который ни подвинуть, ни поменять.

Повиснуть может только задача в jira. А если таких примеров в jira нет, то всё хорошо.

Я не вижу причин, почему админ не может сделать хорошую и правильную архитектуру для данной задачи.

Потому что у него нет опыта в создании архитектуры приложения.

90% админов при переходе с bash-скриптов на python, например, продолжают писать bash-скрипты, только в другом синтаксисе. 99,9% админов никогда не пишут unit-тесты.

Пару лет назад на devops-митапе в Москве один гений делился своим использованием ansible, так и там умудрился создать playbook из одного task, который выполнял 3-страничный bash-скрипт.

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

Да я не спорю, если смогли найти человека-оркестра - флаг им в руки. Главное чтоб спец был нормальный и платили ему нормально, а не как обычно у нас бывает - работай за двоих, а получай дай бог чтоб за одного

Я надеюсь ты согласен со мной, что рассуждать о проблемах нужно по конкретным признакам, и главные критерии - неспособность выполнить какие-то требования и/или явные убытки(простой системы из за фиговой выкладки, например). Всё остальные теоретические соображения хороши в баре, тут на лоре, но вряд ли в реальной работе.

Что касается наших админов, то как минимум трое - профессиональные разработчики в прошлом. В целом в компании культура такая, что все it-отделы активно программируют для своих задач. И большинство наших middle/senior админов пришли к нам «зелёными» сколько-то лет тому назад, соотв. они всегда писали код и за ними всегда следили, как они это делают.

целом в компании культура такая, что все it-отделы активно программируют для своих задач.

забавное у тебя «нет потребности в devops»

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

Фи! Это ты в 2017 нам, «классическим админам», рассказываешь про «новую» тему DevOps?! «всегда на волне»?! Чувак, до тебя либо волна дошла очень поздно, либо в вашей деревне интернет лагает... Мы (лично я), классические админы, просто смотрим на технологию или либо юзаем ее, потому что она уже созрела (и «не будет просить кушать»), либо уже зарулили ее куда подальше. Времени уже прошло столько, что уже понятно, что из DevOps софта можно использовать ничего не сломав, а что надо выкинуть в урну.

Вот блин, пост откровения...

Я всю вашу дискуссию не читал, но хочу налить воды на одну из ваших мельниц. Ты говоришь, админы не умеют программить, а пишут bash скрипты? Знаешь, будучи админом (с некоторыми знаниями C), я с тобой соглашусь и еще добавлю, что это правильно. Более того, программеры плохо админять, т.к. мало писать скрипты и конфигурять сервисы. Точно также, как хороший программер знает шаблоны программирования, админ знает шаблоны администрирования, и я свято верю, что эти шаблоны часто противоречат друг другу. Аминь.

чуть выше ответ и тебе тоже.

Пару лет назад на devops-митапе в Москве один гений делился своим использованием ansible, так и там умудрился создать playbook из одного task, который выполнял 3-страничный bash-скрипт.

3 страницы, может, и перебор, но bash - наше все. Его знают все. Ansible, puppet и прочие CMS приходят и уходят, с них мигрируют, их заменяют. А на bash'e будет писать любой линуксовый админ, включая нуба. Хорошо ansible, а был бы puppet или chef? Прикажете всей команде ruby учить? Это же бред собачий. Я понимаю, если вы facebook и вы особенные, но в банальных условиях не надо усложнять. Возьми молоток и забей гвоздь.

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

И на самом деле цель devops-инструментов и процессов (подхода infrastructure as a code и т.п.) не в том чтобы заавтоматизировать всё до чего руки дотягиваются, а создать возможность для того чтобы разработчики и админы могли обмениваться мнениями и оперативно решать смежные проблемы.

Да, так это преподносится. Только я на практике не видел хорошего review даже между админами, а совместное обсуждение с программерами всегда являлось неотъемлемой частью даже до появления devops. Мой лично опыт.

Это как новомодное понятие «нанотехнологии» в микроэлектронике и в физике твёрдого тела: оказывается исследователи полупроводников 50 лет занимались тем, для чего не было названия, и вот оно появилось - можно вздохнуть с облегчением и порадоваться за успехи и достижения данной отрасли технологий и знаний. «Devops» под названием «нано» во всей красе.

devops - это не когда админы учатся программировать а программеры админить

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

только я на практике не видел хорошего review даже между админами

так откуда он у вас возьмется если вы на bash только пишете :)

все эти нелюбимые тобой ansible, puppet и т.п. как раз и создают возможность такого ревью и со стороны админов и со стороны разработчиков, выкидывая и тех и тех в общую область «программирования на yaml» (а не ruby и не python), где можно абстрагироваться от деталей и специфики

все эти нелюбимые тобой ansible, puppet и т.п.

Откуда такой вывод? Я знаю и то, и то. У меня разное отношения к этим двум вещам.

как раз и создают возможность такого ревью и со стороны админов

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

программирования на yaml

yaml - это python, а puppet - это ERB. ... о блин, они же там heira добавляли. дада, еще один костыль. забыл уже. только там начинаются проблемы с variable scope, кажется. нафиг-нафиг. еще один костыль.

где можно абстрагироваться от деталей и специфики

блаблаблабла. маркетинговый бред. имхо.

потому что в трехуровневой системе абстракций паппета (которую я напишу) ты ноги поломаешь, пока сделаешь там review.

а уж сколько можно наломать в баше если не придерживаться хоть какого-то code-style

кто тебя заставляет пятиуровневые абстракции то плодить

yaml - это python, а puppet - это ERB. давай, будем точнее с мат. частью?

несущественная деталь

yaml конечно приятнее для чтения но суть одна, это уже не полный язык программирования а выжимка, задокументированная и унифицированная

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

Вот все хотят нас как-то подколоть, хотя я согласен, заслужил, сам же начал не очень корректно.)

Это нормальная практика людям что-то менять в жизни, а большим компаниям поддерживать такие движения. Как правило человеческие ресурсы в нехватке и тут и там, а уставший специалист бывает хуже ненанятого. В итоге у нас можно перейти в новое направление с сохранением своей зарплаты(т.е. как бы перейти на позицию junior-a с зарплатой senior-а, т.к. компания человека уже хорошо знает и предполагает что он быстро вырастет). Но в моей команде таких нет, тем реябатам около 35, в а админстве они около 7 лет. Сменили т.к. просто надоело(один писал провайдерский биллинг на перле, второй банковский софт на deplhi, третий базу данных на си).

так ты изначально в лагере программеров? тогда понятно разночтение, твоя любовь к классам и абстракциям.

кто тебя заставляет пятиуровневые абстракции то плодить

Достаточно банальные задачи с его помощь решаются достаточно сложно и выливается это в то, что для review очень плохо годится.

а выжимка, задокументированная и унифицированная

Когда-то давно я приводил тот же аргумент. До того, как реализовал проект.

сделать в недрах его bash, куда не ступала нога человека

Нога программера, слава богу туда не ступала. А любой админ там все легко сделает руками. И тестирование проведет.

найти класс который отвечает за нужное тебе приложение и прислать патч, который админу достаточно будет заапрувить.

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

И не надо бежать к админу и просить его что-то сделать

Надо, Федя! Надо!

Лично подколоть не хочу. Ситуации не знаю. Объемов не знаю. Пишу общие соображения ради дискуссии на форуме.

Сменили т.к. просто надоело... «Это нормальная практика людям что-то менять в жизни»

Как бы так сказать, чтобы объяснить. Не люблю я вот это «надоело». Нормально что-то менять в жизни? Я знаю тех, кто из айти пошли в строители. По человеческим меркам нормально. По айтишным меркам, профессиональным, для бизнеса? Уже задумаешься.

Эти люди (которые програмили на делфи, а теперь админят) читают книги (не статьи на хабре) про best practicies of administration? Cloud services? Сами что-то пишут? Чаще всего они не читают. Они сначала писали на делфи по статьям в инете, потом по статьям в инете учатся конфигурять системы. Это не то.

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

так ты изначально в лагере программеров? тогда понятно разночтение, твоя любовь к классам и абстракциям.

я изначально посередине, на два фронта работаю

А любой админ там все легко сделает руками. И тестирование проведет.

Это миф. Либо у тебя скрипты не делают и 10 процентов того что может делать puppet/ansible и т.п. либо их никто кроме тебя не читал.

Админ лучше тебя (программера) знает, о конфигурации, как и когда ее можно менять. Твой патч и его ревью - это один из признаков избыточного и неэффективного воркфлой.

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

В openstack например за счет запихивания всего в yaml, команда из 5 senior infra engineers поддерживает инфраструктуру проекта на 6000 контрибьюторов. Хочешь добавить тест к репозиторию - присылаешь патч в yaml, хочешь поменять админа проекта - патч в yaml, хочешь поменять расписание выгрузки артефакта - в yaml. И т.д. и т.п.

я изначально посередине, на два фронта работаю

Значит, программер. Понял, отстал.

Либо у тебя скрипты не делают и 10 процентов того что может делать puppet/ansible и т.п.

Я не пойму, почему ты всевремя утверждаешь, что у меня нет config managment system... Есть. И bash скрипты есть.

Админ лучше знает, поэтому он аппрувит

Нееет))) Не потому что он «аппрувит»)) Потому что он это в первую очередь пишет и тестирует.)

подобный workflow позволяет не «расходовать» знания админа на выполнение банальных действий ... или объясняет что и как нужно сделать, чтобы ему принесли в следующий раз уже кореектный коммит.

Если это простой workflow, то я балерина.

команда из 5 senior infra engineers

Я иногда вижу объявления о найме, где берут еще одного человека. Читаю описание инфраструктуры и понимаю, почему им нужен еще один. 5 seniors infra engineers - это дохрена. И то, что я знаю об OpenStack говорит мне, что вы никогда не идете простым путем. Хотя я, конечно, выражаю вам респект за большой (видимо) и сложный (по очевидным причинам) проект.

6000 контрибьюторов.

Это колличество программеров, которым вы даете что-то менять при помощи патчей?:) WoW! Скорее всего эти 5 админов только и делают, что разгребают чужие комиты и обучают программеров, как и что менять. Wow))) Ладно, мне на сегодня хватит поразительных историй. Я откланиваюсь.

Нееет))) Не потому что он «аппрувит»))

потому и поэтому - это два разных слова если что

Как бы так сказать, чтобы объяснить. Не люблю я вот это «надоело». Нормально что-то менять в жизни? Я знаю тех, кто из айти пошли в строители. По человеческим меркам нормально. По айтишным меркам, профессиональным, для бизнеса? Уже задумаешься.

Я считаю в IT есть базис знаний общий для всех(админы, разработчики, DBA, сетевики, тестировщики) и пласт актуальных знаний в примерно 3 года. Таким образом за 10-12 лет можно спокойно стать дважды senior-ом и это нормально, вызывать каких-то преждевременных сомнений в человеке не должно.

ок, принимается. поэтому я на сегодня заканчиваю.

Я с этим полностью не согласен. Надеюсь, мне удалось объяснить, что я хотел сказать про подходы и общий способ мышления. Это определяет, как спец использует свои знания. Из-за этого каждый спец (DBA, админ, программер) будет решать задачи по-разному.

Я считаю в IT есть базис знаний общий для всех

Я верю в призвание. Торвальдс написал бы ядро, думая также, как и ты? Нет, не написал бы...:(

Не знаю, нет наверное. Я прекрасно понимаю, что есть супер-увлеченные специалисты, которые всю задачу стараются понять до мельчайших тонкостей, но их единицы. Я такими людьми восхищаюсь. Однако «в обычных» задачах, не факт что они прям лучше других. Я имею ввиду, что что бы задебажить какую-нибудь сишную прогу, надо а) Почитать её логи б) Посмотреть в strace если логи не помогли с) Взять в руки gdb/gcore. И gdb своего рода предел, далее уже не нужно быть kernel-хакером чаще всего. Аналогично с «советами программистам и perf-утилитами», не нужно быть kernel-хакером, что бы сделать правильные выводы посмотрев на то, как оно работает с системной точки зрения. Аналогично не нужно знать все параметри tcp-стека, что бы правильно настроить сеть.

Бизнесу то что нужно? 1) Минимум простоя. 2) Чтоб по задачам в тикет системе принимались адекватные решения. 3) Они выходили в продакшен за приемлимое время. Всё это приходит с 3-5 летним опытом, а 80% задач очевидны с самого начала и вопрос только в временных затратах.

Це не адміны. Це эникейщики

Не оптимально. Тестировщик тратит время на деплой, да и на содержание инфраструктуры, и кто знает какой там configuration drift %)

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

По науке DevOps - это не человек, а принцип. Принцип ничего админить не должен. И по этой же науке за наличие в компании должности DevOps engineer надо больно бить. Что не мешает плодиться подобным вакансиям как грибам.

Так вот, когда DevOps воспринимают как должность, это скорее всего будет автоматизация деплоя и ci-инфраструктуры. Но может быть и всё остальное, от управления тикет-системой до release engineering и архитектуры системы, зависит от ситуации. В общем это «все что не хотят или не умеют делать разработчики, а делать надо».

Если DevOps это принцип, то кто его по науке должен реализовывать?

Организация.

Это не один человек пришел, наняли на работу и стал делать DevOps, а то как устроена в целом разработка, инфраструктура и иерархия в компании.

Как, например, поделены команды: по функциям (программисты, админы, дизайнеры..) или по проектам. Какие возможности у этих команд. Может ли автор кода посмотреть в real-time логи работы своего кода в проде или ему их доставляют почтой через третьи руки от суппорта через админов и QA. И т.д и т.п.