Pull to refresh

Comments 124

(высовываясь из-за асбестовой плиты) а, так вот о чём была предыдущая статья.


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

Да, но должна быть разумная грань, как делить обязанности и не скатиться в кучу специализаций, футболящих мяч друг другу, а в целом не отвечающих за продукт как таковой. Лет 20 назад работал в компании, где по неумению поделили обязанности небольшой команды на 1) разработчик базы данных 2) разработчик бекэнд логики 3) разработчик фронта и где запрещено было лезть в песочницу другого. Более сложной и неэффективной команды в жизни не видел. Эффективны команды, где люди «T-shaped», умеют всего понемногу и в чём-то умеют лучше других. Если про того же девопса говорить, то девопс не умеющий делать билды и мониторить базу — никакой не девопс, а обычный «админ». У девопса должно быть больше ДЕВа, чем ОПСа.
Ну тогда должны быть отдельно девупсы, отдельно сетевики, отдельно инфраструктурщики, а не всё в 1, у тебя в любом случае будет больше ОПСа, просто потому что он никуда не делся.
Ну в современных реалиях, когда многие «в облаках», зачём нужен отдельный сетевик, когда из сетевого максимум, что надо уметь — это (в случае AWS) изредка VPC / Route53 / файрволы поковырять? Это уже именно задача девопса такими вещами заниматься на большинстве типовых проектов. Так же и в других областях. Много всяких вещей нынче берёт на себя условный «хостинг» или технологический стек, типа контейнеризации и т.п. Потому и исчезли в большинстве «эффективных» контор всякие билд инженеры, ибо не нужно оно, а именно девопс и должен всё уметь или по крайней мере организовать процесс, что бы девелоперы деливерили свой софт в потребляемом девопсом виде.
Если у вас пакеты теряется между виртуалками в облаках, то это тоже надо найти, обосновать и предъявить оператору «облака».
это случай из практики? на моей практике в AWS любая «сетевая» магия оказывалась кривыми руками, а не теряющимися пакетами
Вы давно смотрели сетевую статистику по интерфейсам?
честно говоря не помню когда смотрел последний раз, ибо продукту важнее KPI выполнения запросов и на практике эти KPI если и просаживаются, то не из-за сети, по крайней мере на моём относительно небольшом трафике. Как оно на террабитах — не знаю.
это еще хорошо что облака кому-то можно юзать. А ведь некоторым это запрещено регулятором.
Я понимаю боль автора, так как сам являюсь девопсом. Девопс не должен быть прежде всего девом или опсом. Девопс это практика, культура в конце концов.
У всех девопсов разные навыки и сильные стороны кто-то в прошлом был дба админом, кто-то сис. администратором, разработчиком итд итп.
угу
меня тут недавно чел из ИТ (системщики, вари, и прочие центосы)
а научи ка ты меня bgp и vxlan по быстрому, а то в моих вакансиях начали появляться эти буковки
посмотрел — действительно начали появлятся
стало интересно кого они находят

П.С. я не считаю что эти технологии сложные, вовсе нет, вполне по силам/времени сетевику мидлу или на базовом уровне синьору околосетевику
П.П.С еще одно интересное наблюдение — эти технологии — необслуживаемые, те неспецу туда лезть просто не нужно так как и так работает
но это не повод, что их должен настраивать девупс, а не профильный сетевик.
так я и про то же
в них несетевку даже на show делать нечего
такая работа раз с сто лет появляется в большинстве типовых проектах. держать под неё отдельного сетевика, или проще азам поднатаскать девопса за месяц?
нет не проще, там азов более 600 rfc…
ок, но для таких задач проще раз в год привлечь консультанта извне, чем держать дорогую штатную единицу, простаивающую 99% времени.
да, но этого не делают, а зовут девупса Пашу и говорят — у тебя 12 часов я жду.
так сетевеку все равно в итоге позвонят за кратную стоимость
или начинаются костыли в виде 30 nginx куче хапрокси и ингрессов в истио

Если devops поставили задачу, где реально нужен «bgp и vxlan», а он сделал «костыли в виде 30 nginx куче хапрокси и ингрессов в истио» то проблема в квалификации devops. Если devops не знает, что тут нужен «vxlan», то менеджер не знает этого тем более.


С другой стороны, если devops скажет, что тут нужен vxlan и что он его сделает за месяц, а консультант за 2 часа, то тут даже хомяк правильное решение примет.

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

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

а кто виноват, что менеджер решил сэкономить? девупс?

А кто менеджеру сказал, что он экономит? Откуда ему знать, что devops такую задачу решить не может? Вот если бы devops (да и разработчики) говорили — «я такое делать не умею, будет провал», то жить было бы намного проще.

Обычно говорят, и даже "невозможно", но "вы же профессионал — подумайте и сделайте"ю С другой стороны "не умею" ещё не означает "будет провал".

но "вы же профессионал — подумайте и сделайте"ю

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

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

отлично сваливаем с больной головы на здоровую


Либо не способен донести свою точку зрения и повлиять на решения.

есть такое, но проблема более общая… И была описана в статье [«Красная» корпоративная культура — главная проблема российского бизнеса (Часть 1)] (https://habr.com/ru/post/483876/) (внезапно! сюрприз! у нее другой автор, не тот же, что и настоящей статьи, но со схожими мыслями)

зависит от количества портов
если их у вас 30-100 то да можно и позвать
если 3-5 и больше тысяч портов то консультант будет жить на сайте (за стоимость инсайт*4)
а если непривидикошка еще и нестабильный энвайромент (не в смысле стабильности а в смысле непрерывных изменений) — то и несколько

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

причем — видел объяву где только они (собственно оно и стало прообразом моего изначального сообщения) — без дополнительных технологий (IP, routing, switching, ...)

иногда складывается впечатление что роботы сидят не на первичном отсеве резюме а на составлении требований к вакансиям
Что нового? Всем этим админы и так занимались.
Вот что опсов теперь код в прод писать заставили — это проблема.
не проблема, а решение, что бы сделать работу непонятных админов прозрачной и повторяемой другими людьми.
Работа непонятных админов понятнее не стала хотя бы потому, что большинству разработчиков это к чёрту не уперлось (а кому было интересно — и так общались с админами и им всё охотно рассказывали).
Теперь просто Ops-ам не платят за Ops-работу, а требуют фичей в проде от них — к повышению стабильности сервисов это не ведет.

И работу опсам найти почти невозможно стало — либо работай по 12 часов в день (6 занимаешься продом, 6 кодишь, потому что ты не разработчик и кодишь намного медленнее), либо работай за копейки 24/7 в мелкой конторе.

Вот и весь результат «девопсизации» на практике. Разделение труда не зря придумывали, мне кажется.
речь про других опсов, которые придут потом и по гиту всегда могут посмотреть, чем занимался предыдущий опс и что конкретно и как он делал
Это не девопс, это называется SRE и успешно существует (пусть даже и без красивой аббревиатуры) уже лет 20. Более того, есть очень мало компаний, где «девопс внедрили», при этом для опсов всё обстоит так же прекрасно, как вы только что описали.
На практике намного чаще те самые «девопсы» (уж простите за неправильное использование этого слова в данном случае, но это не я такой, меня заставили) внедряют всякую никому неизвестную новую финтифлюшку ничего не документируя, а через год убегают на следующее место работы. А старый отдел опсов сидит где-то рядом и в поте лица пишет продовый сервис, сжигая в топке свой многолетний полезный опыт, потому что они теперь разработчики по должности и каждый квартал с них спрашивают, как с разработчиков.
Согласен, терминология тут плавает. Но 20 лет назад это был некий магический баш и магические заклинания в консоли, что превращало админа в полубога, а сейчас это некие industry standard технологии с прозрачным кодом, которые может и должен читать, а то и писать более менее продвинутый девелопер, в результате часть работы смещается со стороны опсов в девелопмент, тем самым ответственность распределяется по команде и делает команду соучастниками жизненного цикла продукта, что в целом повышает выживаемость продукта начиная от условий экспуатации и заканчивая упрощением кадрового вопроса.
> а сейчас это некие industry standard технологии с прозрачным кодом, которые может и должен читать, а то и писать более менее продвинутый девелопер
Бха-ха-ха-ха.
Все эти «индастри стандарты» на практике в каждой отдельно взятой компании настолько переписаны и переделаны, что никакого универсального опыта нет и быть не может.
Крупные технические компании уже плюнули на это и все до единой написали свои «куберы», например.

> Но 20 лет назад это был некий магический баш и магические заклинания в консоли, что превращало админа в полубога
20 лет назад уже был cfengine (и работал не менее прекрасно, чем сейчас). Teamcity появился в 2006 и идея CI/CD к тому моменту уже не была свежей и новомодной. Контейнеры были (jail в bsd, чруты с обвязками в линуксах) — разве что не было чего-то вроде registry (но были аналоги для локальных нужд). Пакеты и вовсе появились <я не настолько старый> знает когда, и сервисы отлично ими деплоились и 20 лет назад, и сейчас.
Было бы желание. Мы вот пакетами лет 15 деплоились — и ничего, не померли. CD был всегда, сколько я помню, CI лет 15-20 назад стал полностью автоматическим (хотя автоматику многие выключали и каждый раз нажимали кнопку, наблюдая за процессом).

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

> и заканчивая упрощением кадрового вопроса.
Это единственное, что реально решает девопс в текущем его виде у нас на рынке. Правда, сотрудники почему-то выгорать стали намного быстрее и синяки у всех черные под глазами — но кому какое дело, правда?
Я про крупняков с несколькими датацентрами и не говорю, там отдельная история. В остальных же случаях скила по условному ансибл/терраформ/докерфайл достаточно, что бы вся команда на 90% понимала как оно живёт в лайве и снижает магию вопроса эксплуатации.
> и снижает магию вопроса эксплуатации.
Главный вопрос — зачем?
Ответьте на него, а потом рассказывайте про прекрасную реальность, в которой ничего никогда не ломается, сеть не тормозит, рейды не разваливаются (а виртуалки в чужой инфре не уходят в кому с невнятными симптомами) и в сервисы на лету никто никогда не лезет руками.

Есть DevOps как по книжке — там всё хорошо и прекрасно. Но на практике это сказочный единорог, с которым вы в реальной жизни не столкнетесь, особенно если вы опс.

Потому что конечная цель «девопсизации» на местах — сэкономить на персонале и выжать последние соки из сотрудников. А в книжках всё чудесно, да. Только никто о качестве не думает — оно вроде как само работает, запас прочности сейчас у всех систем огромный.
Реального «книжного» DevOps я тоже не видел. На моей практике эта тема про IaaC, CI/CD, централизованый и прозрачный мониторинг и логирование всего и вся, а как результат — перенос части головняка с опсов на девов, т.е. повышение ответственности за то, что они деливерят. Убирание границы между эксплуатацией и разработкой, тем самым решение главной отмазки девов «а у меня всё работает» и решение ситуации, описаной в статье, когда все проблемы становятся проблемами эксплуатации. Одно это резко увеличивает качество продукта. Ну и да, всё это местами весьма неудобно для тех разработчиков, кто не привык думать о том, как оно эксплуатируется.

Ну и вопрос «наследственности» тоже очень важен. Уход «незаменяемых» людей всегда болезненен. А если вся их работа в репозитории, то всё становится в разы проще.
> когда все проблемы становятся проблемами эксплуатации
Угу. Теперь все проблемы эксплуатации становятся проблемами разработчиков, ведь эксплуатацию уволили ещё в самом начале. Если из этих опсов кто-то остался кодить дальше — повезло, он что-то может починить (через маты, потому что теперь он без премии за закрытые таски будет сидеть), а если нет — то ой, до первой серьёзной проблемы.

> Одно это резко увеличивает качество продукта
Качество продуктов увеличилось только и только потому, что технологии стали намного стабильнее, сервера — быстрее, а железо на практике — надежнее и холоднее.
Весь тот *здец, который сейчас пишут, на серверах и линуксе 2010 тупо не работал бы, падая раз в несколько часов целиком, унося с собой всю железку в кому, watchdog-и жрали бы больше ресурсов, чем сами сервисы.
Отдельный софт вообще перестал сам по себе падать (его systemd перезапустит, если что), а контейнеры регулярно перезапускаются с флашем, не давая накопиться проблемам — вот и весь секрет «стабильности». Влияет и то, что монолитных огромных сервисов стало меньше — но при чём здесь devops?
А код отдельные люди плохо писали и тогда, и сейчас. И банальные ошибки делали и тогда, и сейчас. И разработчик, который полночи чинил прод, а утром пришел к 10 утра делать таски делает таких ошибок ещё больше.

А всё, про что вы пишете — «IaaC, CI/CD, централизованый и прозрачный мониторинг и логирование всего и вся» — это часть SRE как раз и существует достаточно долго. Хоть это и часть девопс-культуры, но далеко не решающая. В SRE наоборот эксплуатация возведена в абсолют и любой разработчик может прозрачно в это погрузиться (если пожелает). И SRE погружены в разработку — но не пишут бизнес-код.
Ну не только. Современный стек позволяет кардинально проще решать вопросы тестирования, относительно легко разворачивая новые билды на части живого трафика причём, что важно, без участия каждый раз эксплуатации. Ответственность за поставку живых контейнеров стала ответственностью девов, ранее же прилетал какой-то собранный пакет, который в лайве и не факт, что вообще взлетит. Да, и инструментарий стал на много лучше с точки зрения fool-proof, но это лишь инструментарий, его надо ещё применить и внедрить, что и стало ответсвенностью девопсов.
Вы вот сейчас teamcity 2006-2007 года описали опять и её тогдашних конкурентов.
И контейнеры были в 2005м. Собирать посложнее было (хотя для сборки были те же sh-ники, один в один повторяющие то, что сейчас пишут в докер-файлах) и деплоить было чуть менее удобно — слоёв не было. А у сишников вообще была статическая сборка со всеми либами внутри бинаря (привет, «главное преимущество Go»), в системе только libc нужен был и порт свободный правильно выбрать.

> Ответственность за поставку живых контейнеров стала ответственность
Ага, осталось только понять — кому они их поставляют.
Проблема была не со сборкой, а с запуском, сейчас оно сильно проще и именно это и изменило картину мира и упростило многие вопросы, в том числе вопросы ответственности девов за то, что там такое насобиралось.
Да не было никаких проблем с запуском. Все эти проблемы люди придумывали сами себе и потом с ними сидели со своими «git pull и запустить 10 скриптов руками — это деплой!»

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

Говно за забор перекидывали только отдельные люди — и перекидывать они его не перестали. Только они теперь не на админов ноют, а на облака, которые плохо работают.
Нихрена не поменялось.
Ну а забыли уже про список software requirements на сервере? От какой-нибудь конкретной версии PHP/mysql и заканчивая конкретным php.ini, в результате невозможностью запустить на этом же сервере что-то другое с другой версией. Что приводило с простаивающим 90% времени серверам. Сейчас же вообще неважно (почти), что там за софт в контейнере и это не головная боль опсов, если контейнер конечно прилично себя ведёт. А всё это часть комплексного вопроса, который и делал сложным разворачивание с нуля полного стека для тестирования, что приводило в очень долгому жизненному циклу и в конечном итоге влияло на цикл релиза продукта в худшую сторону.
> конкретной версии PHP
Зависимости пакетов на что людям даны?

> mysql
Стоит на отдельных серверах, которые управляются отдельной автоматикой, вообще не обсуждается. И для дева тоже.

> php.ini,
Прекрасно деплоится пакетом service-name-config

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

> А всё это часть комплексного вопроса, который и делал сложным разворачивание с нуля полного стека для тестирования
Стек для тестирования поднимался ops-ами рядом с продом в необходимых масштабах и полностью повторял прод.

И всё это при условии, что использовались пакеты, а не чруты — тогда вообще не было отличий от того, что вы наблюдаете сейчас.

> Что приводило с простаивающим 90% времени серверам
Ну а теперь сервера загружены на 110% и постоянно что-то где-то тормозит и стреляет.
Сервера были загружены ровно настолько, насколько позволяли бюджеты. И инструменты для размазывания виртуалок по кластеру на свободные ноды тоже были (и я даже свою пытался написать в company-wide — оказалось, что там уже штук 10 было запущено). И openstack уже выглядывал из будущего RHEV-ом и эвкалиптом, чтобы разработчики не думали о железе.

Что вы пытаетесь рассказать нового и чудесного, с чем я не сталкивался до того, как в наш мир ставшее паразитным слово «devops»? Ничего нового с точки зрения технологий или конкретных практик в девопсе нет — это всё почти полностью повторяет SRE-культуру. А сама методология у нас была извращена и обращена на пользу работодателю — хотя упрощать жизнь она должна как раз техническим специалистам.
Весь девопс — он в том, чтобы у админов и разрабов чатик был один на всех. Всё. Вы внедрили девопс, поздравляю. А остальное — просто технологии, которые можно внедрять силами админов-девопсов-разрабов-когоугодно-хотьCTO.
Я ведь не говорю, что раньше нельзя этого было делать. Я говорю про то, что теперь это может делать и делает на много более широкий круг людей, а не пара магов, потому что оно стало всё на много проще, извините за тупую аналогию, переместилось с 3-4 уровня OSI на 5-6. В результате изменился жизненный цикл релизов в сторону убыстрения. Вплоть до «книжного» девопса у тех, кто тянет технические требования к процессу.
Что приводило с простаивающим 90% времени серверам

сервера никуда не делись. От того, что они теперь у провайдера — Вы за простаивающие сервера не перестали платить. Просто Вы теперь платите х2-х3 )))) С другой стороны — если облако правильно использовать — можно экономить. Речь именно про короткоживущие тестовые среды и про ситуации, когда нужно много ресурсов и еще вчера (например, готовимся к "черной пятнице"). С другой стороны, контейнеры ничего нового не придумали — раньше можно было точно так же деплоиться виртуалками в омозоне. Ну, ок — деплой будет не 5 минут, а 15 — но кого это волнует на самом деле? А гипер-оптимизация ресурсов с помощью контейнеризации ведет к дополнительным технологическим проблемам. Вроде такого. Неудивительно, что сейчас активно развивается направление "легковесных виртуалок"


Ну а забыли уже про список software requirements на сервере? От какой-нибудь конкретной версии PHP/mysql и заканчивая конкретным php.ini,

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

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

на вагранте сидели, жалоб не было.


А главное их легко поднять любому деву

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


Ну деплой типичных контейнеров секунды, а не 5 минут.

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

> весело будет маководам
Маководам и на интеле весело, когда вся инфраструктура — ipv6-only. Контейнер-то они запускают, а сходить он никуда не может.
мне кажется тут скорость деплоя зависит от образа и его веса. при высокой скорости диска и сетки даже не доходя до 10 сек.
Допустим образ питона на базе alpine.
>Но при этом внутри каждого из контейнеров точно так же может быть помойка из различных версий и точно так же надо решать ситуацию с конфликтом зависимостей

Совершенно верно, но всё это теперь является проблемой разработчика, а не опса :)
но всё это теперь является проблемой разработчика

с одной оговоркой — проблемой лида или девопса ) потому что совершенно не факт, что обычный миддл справится с проблемой. Хотя что я говорю — конечно справится, как же можно сомневаться, ну, выкинет эти зависимости и напишет свою библиотеку )))

Кстати да, я на этот minikvm тоже смотрю недоумленно и не понимаю, почему все ещё на него не едут. Отличная вещь, которая позволяет собрать statefull+stateless вещи в одном облаке на одной технологии и не жрёт ресурсов, как openstack.
почему все ещё на него не едут

потому что не стабилизировалось еще ?

А его не нужно стабилизировать, я же не зря его minikvm назвал — это вполне себе стабильный давно известный KVM, из которого выкинули всё, что не требуется для запуска linux-сервера.

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

Но помнить про него надо — полезная штука.
Просто Вы теперь платите нет х2-х3, а x50 минимум. Говорим только о серьезном продакшене.
Современный стек позволяет кардинально проще решать вопросы тестирования

и да, и нет. Действительно тесты сейчас стали писать чаще на код. И даже хорошие тесты. Но не всегда. Потому что цифирка 100% в coverage НИЧЕГО не означает. И не дает гарантий, что ваш продукт не завалится в продакшене.


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

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

Прочитал тред и пришёл к выводу, что у вас, джентельмены, травмы разные. Я вот тоже никогда не видел увольнения/переквалификации ops и найма на замену т.н. «devops»-инженеров/разработчиков. Почти всегда этот «devops» строился параллельно имеющейся службе эксплуатации ибо она была не в состоянии эксплуатировать, а те, кому это мешало, были не в состоянии эту службу починить из-за страха или блокирующего менеджера где-то наверху.


Опять же, посыл «это ваше программирование меня не волнует, дайте мне sendmail настраивать до потери сознания» я тоже разделить не могу, потому что постоянно бьюсь головой о разработчиков с таким же по сути посылом «эта ваша эксплуатация меня не волнует, я код написал/образ собрал, дальше давайте сами». В ИТ эксплуатируется в основном код, и основная цель кода — быть эксплуатируемым, ибо просто лёжа в VCS он никакой пользы не доставляет. DevOps призван как раз это «с моей стороны пули вылетели» чинить, не отменяя при этом специализацию.


А то, что на самом деле происходит вместо этого — так в первый раз, что ли. Раньше был такой же без головы внедряемый agile, сейчас вот ML в мониторинге, ещё скоро observability подъедет в Россию. Про последний прямо предвкушаю, как удивительно его будут реализовывать на местах.

Ну почему ж сразу sendmail. Поднять кубер/openstack, ELK, sentry возможно, настроить автоматику наливки dom0, автоматизировать/максимально упростить добавление мониторингов, графиков и прочего, ревьювить код (хотя бы вместе с разрабом, вопрошая «а что ты тут понаписал и зачем») и архитектуру, и даже кодить что-то для инфраструктуры по своему собственному ТЗ — это всё Ops.

Писать код для новых фич в бизнес-сервисе — это НЕ Ops. Ops-ы плохо пишут код по чужим ТЗ, они этому не учились и это сложно. Потому что для самого себя ты рисуешь ТЗ исходя из своих возможностей.
Бизнес код писать это перебор конечно, но вот ставить ТЗ разрабам для решения больных вопросов эксплуатации (монолит там какой допилить для мастштабируемости в конктетном месте и т.п.) — это реалии жизни. В этом плане статья автора удивляет, что он мальчик для битья. Роль девопса на много шире, он должен ставить процессы и влиять на них, что бы получать эксплуатируемый продукт.
> но вот ставить ТЗ разрабам для решения больных вопросов эксплуатации — это реалии жизни.

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

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

А что значит починить мониторинг? Вот у тебя есть кластер, при любом наплыве клиентов там LA под 100%, и базы так же, запросы написаны через ORM. потому что по другому разрабы не могут, 2 пользака запросили большой обьём данных и всё встало раком, а доп 4000 баксов на инфру никто не даст, и что делать? Выключить мониторинг?
слать мониторинг тому, кто отвечает либо за 4000 баксов, либо за найм персонала, способного подлечить запросы :)
Отвечаешь ты, ты ведь девупс 1 на 20-30 разрабов, как сейчас модно. Ведь как ты ранее писал — всё просто легко и шикарно понятно.
А денег нет — ты ведь девупс найди выход, прод же не умирает совсем, значит не будем ресурсы добавлять.

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

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

Руководство вправе ожидать, что я знаю, когда совсем лежит, а не когда LA там 100%. Поэтому я в какой-то момент пошёл и выключил везде все алерты на нагрузку CPU, сети и диска как недостаточно специфичные.

LA не может быть в %, только дробное число :)
Очень грубо, не более числа ядер CPU в системе.
> Очень грубо, не более числа ядер CPU в системе.
Это как-то уж ну очень грубо. Прямо матом =)

LA, который не превышает количество ядер CPU в системе обычно означает, что всем процессам хватает процессора и никто его никогда не ждёт. Или сервер, из под которого резко вынули хранилище (не локальное, само собой) и количество процессов, работавших с этим стораджом, совпало с количеством ядер =)
это понятно, но писать 70 из 60 тоже не все поймут.
> Человек, который пишет бизнес-код и имеет опыт его непосредственной эксплуатации, бесценен ибо редок.
Ничего бесценного в таких людях нет, судя по зарплатам. Получают процентов на 10-20 больше разве что.
Намного важнее ценится манагерский скилл — языком поговорить, ТЗ расписать, от коллег чего-то добиться — вот он может зарплату и на три помножить. А ops-опыт на зарплату не влияет.

> так может сначала мониторинг починить?
А тут мы и приходим к вопросу, который я задал уже раз 30 — кто во всей этой схеме фундаментально чинит проблемы, которые приводят к загоранию мониторинга? Разработчику за это не платят никогда и он идёт по пути наименьшего сопротивления — чинит проверку, делает костыль или просто тушит надоедливую проверку.
А моргающие триггеры — это как раз нормально, иначе у тебя либо сервис на локалхосте, который мониторится с локалхоста, либо у тебя нет никакого мониторинга и ты не в курсе реальных проблем.
Ну по хорошему на такую ситуацию техдир должен реагировать, если конечно оно влияет на бизнес и приводит к упущенной прибыли. Если не влияет, то наверное гасить мониторинг, ибо толку от него…
Чаще всего именно CTO произносит историческую фразу «пусть эти бородатые дармоеды либо код сервисов пишут, либо валят на все четыре стороны отсюда», с которой всё и начинается. А упущенная прибыль будет когда-нибудь потом.

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

Ну если только деньгами измерять, то лучше веществами торговать, чо уж там. Нефтью, например, или газом.


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


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

Тм более как говорят техдиры с большой з\п — технологии и тд не их проблемы, их задача делать волевые решения и находить виновных, наказал — молодей вот премия за волевые решения. Решения приводят к проблемам, но это плохие девупсы и кодеры, а он хороший, решение то волевое принял.
Если в компании поиск виновных — самоцель, то надо валить из такой компании, а не притягивать её как доказательство ущербности профессии.

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

> Ну если только деньгами измерять, то лучше веществами торговать, чо уж там. Нефтью, например, или газом.
Чтобы нефтью или газом торговать — учиться надо было другому. И связи иметь. Да и не все торговать умеют, опять же.

> А моргающие триггеры — нихрена не нормально.
Моргающие триггеры — это нормальная история и от неё не избавишься. В большом проде постоянно что-то меняется и что-то с каждым релизом может сломаться. Не говоря уже о том, что сеть может кончиться когда угодно и где угодно. Чинить моргающие триггеры нужно, само собой — они не просто так возникают.
Я говорю о том, что «дежурный разработчик» будет чинить не проблему, а именно лампочку в мониторинге — порестартит что-то, лимиты поменяет или вообще выключит проверку, а до проблемы докапываться не будет — ему нужно свои таски по разработке доделать. Если вообще будет что-то делать, а не просто увидит, что лампочка погасла и можно дальше заниматься таском (вот только из контекста он уже выпал и время потерял).
Дежурный разработчик / OCP должен действовать по написанному и согласованному процессу, а не вот это. Если в процессе написано «рестартнуть и забить», то вопрос к адекватности процесса в компании / возможности его поменять / проще свалить в адекватную компанию.
О, это я вам адекватную компанию описываю. Не лучшую — но точно адекватную.
Есть места, где всё ещё хуже.

> должен действовать по написанному и согласованному процессу,
Зачем в это место сажать людей с высокой зарплатой, если этим может заниматься стажер-ops? Чтобы разрабы выгорали быстрее?

Зачем вы ставите дежурными таких людей?

Лично я никого никуда не ставлю =)
Но на вопрос ответить могу — других нет. Всем платят за фичи в проде, так что подежурить должны все, чтобы никому обидно не было — специально никто не согласится.

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

Вы привыкайте.
С ростом событий в системе растет число необычных событий, которые приводят к алертам и проблемам.
А нормальные алерты — повод переписать логику алертов.
:)
ну ну, сколько раз мы приходили к клиентам, у которых кто-то настроил лет 5 назад chef/puppet и теперь они сидят на древности, потому что в руби никто не умеет за те копейки в 100-130к.
Сколько кубспреев 2017 года стоит без обновлений, потому что хрен его знает как обновить без смерти прода.
Или «ааа спасите у нас монга в кубере и кассандра» — и потом ты радуешь людей потерей данных за 5-10 часов.
но да всё просто и легко.
мой поинт не в том, что работа стала проще и более безмозглой. мой поинт в том в том, что эта работа стала более прозрачной для таких вот людей извне.
Чем проще? мы недавно делали 1 проект переделку прода, 1 роль на nginx+лендинги это 200 мать его файлов, 200 файлов, зависимости в которых друг от друга. помимо этого заменить это просто было нельзя, потому что оно зависело ещё от 1 роли на уже на лоадбалансинг между 2 дц, и там ещё 350 файлов…
Просто не реально просто и легко, открыл и всё понятно.
А ещё прикольнее тераформ на 15-20к строк, это вообще проще некуда.
дык я эт и не утверждал
ты утверждал что стало прозрачнее, но это не так совсем, более того, зачастую даже стало менее прозрачно, т.к. зависимости может сеньор понять, а мидл и джун — нет.
Ну раньше клиент приходит с «глючащим сервером» и на раскапывай пол дня, что там да как установлено. Теперь же хоть «исходники сервера» есть шанс получить, пусть и пятилетней давности.
да, теперь 2 недели чтобы разобрать роли, зависимости и проблемы.
зачастую проще вообще с нуля всё писать, и переносить всё в 0, что опять же 2-3 недели, но раньше было существенно меньше сервисов ненужных, а сейчас зачастую только nginx это 30-50 контейнеров.
переписать всегда проще по документации / исходникам, чем по чёрному ящику
переписать всегда проще по документации / исходникам, чем по чёрному ящику

по спецификации — да


по документации — нет (она может быть неполной, неточной и прочее), но наличие доки лучше, чем ее отсутствие (по крайней можно восстановить часть процессов)


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

ещё веселее когда код есть, но он уже не применяется, и в зависмостях в 1 из 200 файлов маскируется, и вот сиди думай… а такие часто, особенно когда ролей тьма и их сотни
У меня в одном только файле 200к сток. Акстись. Я про проект весь вообще молчу. И это всего лишь несколько сервисов в AWS. И я до сих пор не понимаю чем python например хуже терраформа
Ко мне вот приходили и просили «ispmanager в докере» поднять *sigh*
Я им намекнул немножечко, куда идти, но кто-то им в итоге это сделал, хым.
но кто-то им в итоге это сделал

ну, клиент же всегда прав (!!!!), даже когда он неправ (!!!!!!)

Сколько кубспреев 2017 года стоит без обновлений, потому что хрен его знает как обновить без смерти прода.

хуже. Через 1 год этот кубспрей превращается в тыкву, т.к. сертификаты протухли. Хотя… наверное, на свежих установках эту проблему решили (зато есть куча других)

Это было задолго до хайпа devops. CFEngine в 93 появился, puppet в 2005. Использовались админами вполне. Но почему-то теперь во время хайпа, считается что админы внезапно перестали это делать, а придут девопсы (которых не существует, на самом деле придут админы) и внезапно внедрят инфраструктуру как код, они и 20 лет назад это делали.

Это делали единицы в единичных компаниях и от случая к случаю для отдельных операций, а не для _каждой_. Задачу «быть способным поднять всю инфраструктуру из скрипта» массово начали ставить лишь лет 7 назад, хоть конечно всё это и раньше можно было делать. Но массовым это стало по мере «стандартизации» инструментов и с появлением нормальной не наколенной оркестрации.

Я и не говорю, что старые инструменты были лучше или такие-же. Я про ваши тезисы:


  • "речь про других опсов, которые придут потом и по гиту всегда могут посмотреть, чем занимался предыдущий опс и что конкретно и как он делал"
  • "что бы сделать работу непонятных админов прозрачной и повторяемой другими людьми"
    • имеется в виду devops: "На моей практике эта тема про IaaC, CI/CD, централизованый и прозрачный мониторинг"

Все это было, до хайпа devops. И говорить что это нам devops принес инфраструктуру как код или CI/CD, а "непонятные" админы раньше бегали и все руками настраивали на мой взгляд неверно.


Теперь "непонятных" админов называют devops, и по моему субъективному опыту мало кто из разработчиков поймет, что там в репозитории описания инфраструктуры творится. Разработчиков бы с docker подружить уже победа, а говорить о всяких ansible, puppet, bolt, chef, salt, terraform, pulumiи т.д. вообще не приходится. Понятны и прозрачны ли будут разработчику все твои yaml для kubernetes, helm чарты, mutating webhook на golang, правила для prometheus? Я так не думаю.


Да даже для другого опса это может стать проблемой, когда нет документации к этому коду, или он вообще не знаком с этим. Например работал он все время на ansible и docker swarm, пришел в другую компанию, а там puppet, pulumi и kubernetes, и весь код на puppet dsl или typescript — для него это будет темный лес, поэтому про прозрачность это очень условное утверждение.

Добавлю, что задача "Задачу «быть способным поднять всю инфраструктуру из скрипта» массово начали ставить лишь лет 7 назад" не так уж необходима, как нам ее продают. Для начала — чтобы что-то описать в виде IaC это самое нужно иметь в каком-то описываемом виде. И зачастую быстрее руками что-то поднять и проверить как оно работает, а потом уже переносить в IaC с дополнительной проверкой того, что то, что мы описали на самом деле то, что мы хотели. Только в каких-то вырожденных и простейших примерах можно менять сам IaC и получать ожидаемый результат (либо будет очень много экспериментов).
Вторая история заключается в том, что IaC нужно поддерживать в актуальном состоянии. Скажем, написали вы год назад код на терраформе для поднятия в яндексе тестового стенда. Ну, надо было показать заказчику. Условная трудоемкость неделя (чтоб красиво каталось, без ошибок, надежно). Год вообще не трогали. Вопрос — сможете ли раскатать тестовый стенд сейчас? Очень вряд ли — начиная от того, что поменялось почти наверняка АПИ самого яндекса и кончая тем, что версии терраформа и провайдеров тоже поехали. А на словах было красиво, да.
Поэтому можно попросту описать критерии применимости IaC: это в первую очередь большие масштабы (когда речь идет о сотнях и более однотипных узлов, это точно не про шаурмячную у Васяна), необходимость часто разворачивать однотипные окружения (тестовые, разработческие и пр.), возможность поддерживать это в актуальном состоянии (выделяем время и бюджет на это).

Еще одна статья где автор по неясной причине отождествляет свой опыт с мировым, если у автора есть проблемы напишите лучше в статье как их решали (если решали) чем просто посылать лучи ненависти в разные стороны

свой опыт с мировым

Мы вроде как в России и обсуждаем проблемы России? Нет?


Хотя интересный и любопытный факт — зарубежом ТОЖЕ говорят о проблемах карго-культа внедрения agile/devops/гибких практик, переработках, криво поставленных задачах, низком качестве кода и пр. пр. пр.


Смотрите прекрасный доклад Valarie

проблемы есть везде, и у Valarie возможно тоже, но виновата методика или ее реализация в конкретной конторе?
методология работает, когда под неё перестраивают бизнес процессы, и добавляется новая роль sre\devops\devsecops, но добавляется новая роль, а не убирается 5 старых и садится 1 человек на обязанности 5.
ну так это как раз таки особенности реализации в отдельно взятой конторе, ибо сам девопс не заключается в том, чтобы взвалить обязанности 5 человек на одного
открываем hh или хабр карьера и смотрим, что это уже не отдельно взятая контора
там мы сможем увидеть что devops применяется не в отдельно взятой конторе, тут вы правы, при этом в каждой вакансии под этим словом имеется ввиду очень разный круг задач, и далеко не везде это обязанности 5 человек в лице одного, например если для позиции devops-инженера требуется знание java, то очень даже понятно зачем, однако это не значит что devops-инженер будет еще и java-разработчиком
виновата методика или ее реализация в конкретной конторе?

Это, знаете ли, политический вопрос в духе — а плохой ли коммунизм или его попросту криво построили в отдельно взятом государстве? Потому что даже в том случае, если Вы найдете примеры "успешного девопса" (а вот попробуйте — только не рекламные буклеты), то запросто может оказаться, что в таких компаниях просто не считают деньги на айти и тогда вопрос эффективности вложенных средств… не стоит.

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

Понятно что именно?

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

«не работал только болтал ходил. Постоянно хвастался, умничал»
статья то же самое, много бессмысленной воды
Мне кажется, что люди забывают для чего девопсы нужны. Мы же спасаем зарработчиков от самих себя. Мы же помогаем разработчикам и бизнесу встретиться, а не как в море кароблям… Dev + Ops
Например сегодня человек написал аналог discp на скале, так как ему нужно было из s3 to hdfs кидать.
Или ещё один умник в Airflow DAG запустив pip install

Все так, все верно. Но это можно обобщить. В любой отрасли так, есть умные начальники и не очень подчиненные. И начальники "конечно" не виноваты в случае провала… не буду рассказывать почему. В американских компаниях это в основном не в таких зашкварных формах, но тоже есть. Как минимум у них все начальство подряд не лезет в процессы на уровне конечных команд и не делится "идеями".


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


Вообще чем дальше, тем все обростает все больше и больше уровнями абстракции. Сначала ОС на железяке, потом на нее какой-то Proxmox-Openstack, потом наверх виртуалки, потом Кубернетис, потом Докеры… а необходимость в знаниях Линукса никуда особо не делись, нужно же ведь понимать и знать. Сложно понять, как оно джунам сейчас, по ходу мрак-мрачный. Все ускоряется, на документацию времени нет, читаешь очень поверхностные ридми и погнали в прод.

Only those users with full accounts are able to leave comments. Log in, please.