Как стать автором
Обновить

Комментарии 422

Вот да! Есть версия это статьи на английском?

Я могу сделать авторский перевод.

Переведите заголовок обратно на английский и загуглите. Найдете вот это.

Этот сайт выглядит как автогенерируемый сборник переводов. Как «русские клоны StackOverflow», только наоборот.

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

А неплохо перевел...

Это, видимо, сарказм - не знаю, на каком языке это написано:

Although there is no why the subject, the path will be any number topics.

но это явно не английский.

Вот да! Есть версия это статьи на английском?

Версионность статьи про DevOps?

Чего да. Как проработавший в DevOps лет 5, могу сказать, что без нас вся разработка, QA и деплоймент в продакшен просто встали бы. Ну или делались раз в 50+ медленнее.

Да, про job security в статье тоже было, да

А прокачка софтскилов, талент-менеджмент, коучинг, оне-ту-оне и корпоративный психолог?

последний просто необходим после всего первого

Человек, который написал это – нет понимания что такое DevOps. Просто какой-то поток мыслей

Возьмите для примера Жиру. У нас например в проекте даже поле описания тикета редко кто заполняет. То есть из всего разнообразия полей, из 100-тен полей которыми обвешан тикет реально-системно используются 4 или 5 штук (!) остальные хранят какие то епизодические случайные артефакты, по сути мусор!!!

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

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

Как говорил один юморист:

Как страшно жить! Она не Красная шапочка, а Дура!

От себя добавлю: Статья-Огонь!

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

Jira - инструмент для менеджеров и тимлидов, чтобы оценивать занятость сотрудников и генерироваьт различные репорты. Степень наполнения в JIRA зависит сугубо от требования менеджеров и тимлидов, а не от девопсов или разработчиков.

Все зависит от индустрии и практик в ней принятых. Если вам инструмент не подходит, это не значит, что он никому не подходит. Вполне в каком-нибудь DoD могут все 100 полей заполнить и еще 200 кастомных настроить.

Я понял, что с Jira что-то не так, когда узнал, что есть спецы по ней - "жировики" (я бы через "ы" писал).

Настоящий девопс еще нигде не был построен.

НЛО прилетело и опубликовало эту надпись здесь

Внимание, доказано несуществование чайника Рассела.

Как и Agile

Думаю, это было написано не про теорию, а как оно бывает на самом деле. И его полностью поддерживаю - войти в айти у всех на слуху, и довольно часто бывает, что человек без понятия, что он должен делать. А дальше это берет другой и еще сильнее извращает, и что мы имеем на выходе? 7 аналитиков на 3 разработчика, превращение совещаний в цирк с викторинами, всякие а-ля покеры, а ТЗ никто составить не в состоянии. А потом еще на хабре толпа статей в стиле "Как заставить разработчика хорошо кушать" или "как создать атмосферу любви и дружбы в команде с помощью *любое действие*".

А дальше это берет другой и еще сильнее извращает, и что мы имеем на
выходе? 7 аналитиков на 3 разработчика, превращение совещаний в цирк с
викторинами, всякие а-ля покеры, а ТЗ никто составить не в состоянии.

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

После курсов? Иногда, даже казалось бы, опытные люди, которые уже лет 10 на плюсах пишут, приходят и спрашивают что такое EINTR в recvfrom. А ты сидишь, смотришь на них, и думаешь, как мрт покажет снимок их мозга..

Как связаны опыт программирования на C++ и сокеты?

И почему с их мозгом что-то не так? Потому что они не знают что-то, что известно вам или потому что пришли с вопросом вместо того, чтобы загуглить?

Да, сожалею что не уточнил пару деталей:

1) они пишут и поддерживают клиент-сервер приложение уже 10+ лет

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

Мне лично было бы стыдно не знать как работает то, что я пишу...

Как связаны опыт программирования на C++ и сокеты?

Интересный вопрос! С такими вопросами можно дойти до вопроса:

Как связаны опыт программирования на C++ и С (в стандартной библиотеке которого определены сокеты).

Конечно если на С++ писать совершенно не касаясь сетевого взаимодействия, то наверно так можно спросить. Но я не верю что на С++ можно писать никогда не касаясь сетевого взаимодействия.

Привет. Я пишу на с++ профессионально 5 лет. У нас свой 3D движок. OpenGL, Vulkan. И никакого сетевого взаимодействия.

А как у вас с линейной алгеброй, графическими API и теорией света? Не могу себе представить разработчика на с++не знакомого с графическими API.

Не могу себе представить разработчика на с++не знакомого с графическими API.

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

Но 5 лет не такой уж большой срок. К тому же учитывая что статья у вас висит от 2013 года выходит что С++ для вас не основной язык (может даже в таких случаях уместно сказать не родной :). Это все объясняет.

Статья у меня висит со времён студенчества. С++ основной.

Я к тому, что есть разработчики не трогавшие сеть, как и есть не трогавшие Direct X.

У меня вот такая аналогия по этому поводу родилась:

Те кто занимаются Direct X при этом не знают что такое сокеты, это как те кто занимаются квантовой механникой не зная законов Ньютона.

Я ни на что не претендую, но мне так кажется.

Аналогия некорректная. "Добраться" до квантмеха не зная законов Ньютона и правда затруднительно, но вот заниматься 3D графикой не касаясь сетевого стека можно без проблем.

Давно известно что любая аналогия не (совсем) корректна.

Но я же написал что это мое личное, это мне так кажется.

Может смысл аналогии был бы понятнее если бы мы рассматривали знание С++ без знания С.

Насколько полноценным может быть знание С++ без знания С?

Зависит от того, что понимать под словами "без знания Си". Потому что среди тех вещей, которые объединяет понятие "знание Си", есть куча тех, которые нафиг не сдались пишущему на плюсах.

что такое EINTR в recvfrom?

сделайте пожалуйста мрт мозга и скиньте егоюзеру mc2. Он очень интересуется

EINTR  Приём данных был прерван сигналом, а данные ещё не были доступны; смотрите signal(7).


man recvfrom

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

Браво! Смузи менеджеры и смузи инициативы забрал в копилку

А что такое DevOps? Спросите это у 5 разных людей на DevOpsConf ;)

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

Он не смог написать тесты для своего плагина, потом у него не было дев. окружения для быстрого тестирования. Каждый раз комитил, пушил в гит(интересно может еще и с пулл реквестами? :D), закачивал в Nexus - и думает вот мне тут жизнь усложнили, девопс же это про написал скриптик и в прод.

НЛО прилетело и опубликовало эту надпись здесь

Я был DBA и делал Jenkins jobs для middle junior DBA из другого отдела, в духе выполним этот скрипт на сервере и пришлем результат почтой. Это позволяло им не запрашивать доступ к серверам ради повторяющихся кверей

Таким образом я просто использовал Jenkins не совсем по назначению

То есть не совсем по назначению. Дженкинс это тулза для автоматизации, то что ее начали называть CI тулзой, это произошло уже позже и это не есть ее главное назначение. Просто массовое.

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

Вот не надо упрощать до просто шедулера.

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

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

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

выполнять что-то на другом сервере под другими правами вообще задача CD инструмента, если мы говорим про разработку.
Либо оркестратор, если мы говорим про администрирование (chef/ansible/etc), но в этом случае "другие права" обычно подразумевается рут

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

А если мы говорим не про разработку а про жизнь отдела поддержки?
Ну там:
сделать бэкап на проде,
обновить новой версией,
прогнать обслуживание SQL (индексы/статистики)
сделать бэкап еще раз,
развернуть второй бэкап на новом месте (и проверили что бэкап живой, и на этом самом месте первая/вторая линия поддержки будут воспроизводить проблемы пользователей от имени этих пользователей и в актуальном окружении)


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


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

Я как раз этим и занимался)

А я в процессе изучения. Наши админы сказали "а хрен его знает, как так сделать" и пока навтыкали шедулеров на каждом сервере на каждый шаг. (с запасом по времени) вот только мы уже отожрали окно с 23-00 до 08-00, а пересечения раз-два в неделю случаются, когда один не успел, второй стартовал и споткнулся.
Что, дженкинс хорошо должен зайти, или стоит в другое место посмотреть?

пересечения раз-два в неделю случаются, когда один не успел, второй стартовал и споткнулся

jenkins уметь синхронизация своих job'ов.

В моем текущем проекте мы используем отдельные продукты для CI и CD. Вдобавок админ дженкинса получается имеет доступ вообще ко всему без всякой сегрегации доступа.

Вдобавок админ дженкинса получается имеет доступ вообще ко всему без всякой сегрегации доступа.

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

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

Ну да, логично, спасибо.

Вы опровергаете название своей статьи. Вывод почему-то не делаете. Не девопс - опухоль, а безопасники и бизнес-процессы! Почему бы не сделать программу или микросервис, выгружающий данные без jenkins? Это же программирование - вперед! Чтобы понять смысл девопс, прочитайте (хотя бы по-диагонали) книгу «проект Феникс». Девопс нужен, чтобы прогеры могли спокойно прогать, но не лезли шаловливыми ручками в базы, не лажали релизы, не крашили обновлениями продакшн. Чтобы в командах был стабильный процесс, а не согласно положению звезд и настроению жены тимлида.

Почему бы не сделать программу или микросервис, выгружающий данные без jenkins?

Но зачем делать самодельный аналог jenkins? Можно взять готовый.

Чтобы не быть как "раковые девопсы", очевидно. Только тру программисты, только версионирование в папочках.

Потому что нужен совсем не аналог jenkins. Уже на этапе когда скрипты для запуска загружаются из Nexus при помощи curl что-то пошло не так.

Знакомая просто переименовала админов в девопсы?

Да.

что это значит? В модели devops нет чисто девелоперов, оно и называется develop + operations. Знакомая просто переименовала админов в девопсы?

В смысле нету? А как назвать человека который умеет в терраформы/женкинсы/кубернетесы/питон/… но не умеет в скажем джву и раст? А с ним в команде работает человек который умеет в расты, джавы, хаскели, но в гробу видал yml, его получается нанимать ошибка?

Ошибка - это то, что девопсу дают примерно пять минут на выполнение любой задачи. Типа так: «эй боец, сбегай сделай по-быстрому». А языков и диалектов вашего программирования хренова гора. И у каждого прогера свое понимание бэст-практис. А сеньеров не переспорить, к примеру, доказывая, что джава профили нужно выбросить. Девопс бы не против обучиться - постоянно это делает, но прогеры, высокомерно ничего не объясняют - на созвонах же. А тратить снова пять лет в универе, изучая как мэйн-класс объявить и какие зависимости подключить для хелоуворда в ваших ${язык программирования} , который все выкинут как delphi через X-лет не хочется.

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

Гугление не заменяет опыт. Очень часто те, которые гуглят решение, слабо представляют себе бест практики применения инструмента. Живой пример: джава программист пишет для деплоя скрипт на shell. Он нагуглил какие то операции, и оно даже работает. Однако, спустя время, передав уже готовый деплоя в другие руки, оказывается что скрипт работает очень неадекватно: аргументы нужно задавать только в определенной последовательности, скрипт не расчитан на внезапное прерывание его работы, а так же скрипт требует ручного ввода информации для деплоя (привет человеческому фактору, во всех проблемах). Но это частности. Когда я заглянул в этот скрипт, я пришел в "восторг", т.к. скрипт выглядел набором функций на любую операцию: к примеру стоп/старт/рестарт jvm - это все отдельные функции, несмотря на то, что управляющая "платформа" понимает обращение к данной jvm с параметрами start/stop/restart.

Итого: гугление не заменяет внимательного изучения инструментов, а дьявол прячется в мелочах.

А если умеет и в жаву и в руби и в си и еще чегото? Тот же голанг. И, да, не синьорский уровень, но, думаю на джуна/мидла вполне можно.

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

Если умеет то это не та ситуация которую я рассматриваю. Представьте себе я говорю вот приходит джун без опыта и ..., а в ответ возражение "а вдруг он с опытом приходит??". Ну если с опытом, то уже другая ситуация, её рассматривать не очень интересно)


Я конечно неправильно могу понимать, но для меня девопс это помесь админа и разраба. В том плане, что админ это обычно на мышки драйверы установить. вирусов там вычистить и вот это все, ну сеть может настроить. А девопс — это дженкинсы, пайплайны. вся вот эта муть. Примерно то же, что админство, но с использованием as a code инструментов, ну и шире, что ли. При этом это не полноценный разработчик — ему позволительно не знать про О большое, про структуры данных, как там гц работает, как правильно профилировать приложение,… Он знает питон/го/… на уровне "могу написать скрипт 30 строк", и все. Программист же наоборот — умеет во все эти навыки, но его знания инфраструктуры заканчивается на "умею написать мультистейдж докерфайл который грамотно кэширует слои " и "не храню стейт в приложении". А как оно там деплоится, по каким хттпсам приходит, сколько инстансов где развернуто — слов таких не знает. Просто пишет себе код в подвале и пушит в мастер фиксы, которые автоматически инструментарием настроенным девопсом попадают куда нужно.


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

Вы забываете про админов у которых под контролем сотни/тысячи серверов. Они были до ваших дженкинсов и будут и после них. И автоматизация управления этим хозяйством была до всей этой моды и останется и после нее.

Инструменты могут как угодно меняться, а админы никуда не денутся. Ну может обзовут их еще как-то. Кому какое дело? Лишь бы деньги платили.

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

Вот в этом последние лет 25 и была одна из основны проблем русскоязычного IT - с каких-то щей "админами" стали называть IT technicians, хотя это две совершенно разные профессии :)

В итоге в какой-то момент "админом" стало быть так же "стыдно", как и "тыжпрограммистом" :)

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

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

В одном инструменте для разработки программ.

Ну вот есть софт file and archive manager, можно манаджить файлы и архивы. Очень разнообразно.

В одном инструменте для разработки программ.

... который представляет собой текстовый редактор с кучей плагинов.

Я использую для этого не одну программу. И даже IDE используют другие программы: линтеры, git и т.д.

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

А потребности бизнеса просты: должно работать 365/24/7. С учетом роста экстенсивного и интенсивного как продукта, так и аудитории.

Странно видеть в одном посте сочетание методологии «х..к-х..к и в продакшн» с нападками на фронт, у которого тройка фреймворков не меняется уже 10 лет.

devops, кстати, помогает следовать принципам KISS разработчикам/архитекторам: разделяет сложность через микросервисы, например.

А сложность. Она из накопленного индустрией комплексный опыта.

===

По моему опыту у большинства в среднем сегменте примерно одинаковая инфраструктура. GitHub/gitlab с их ci/cd, выкладка на сервера, препрод, dev-среда с бранчами, бд.

Почему нет универсальных решений с минимальными телодвижениями? Почему так дорого?

А потребности бизнеса просты: должно работать 365/24/7
Но ведь это не про devops? Это же про других ребят. И эвердьюпойс это только одна из потребностей.

в т.ч. и про devops. Архитектура инфры должна уметь работать в пики, быть устойчивой к ddos, устойчивой к херовым релизам от разрабов. Всякие мониторинги, алертинги, трейсинги и т.д.

365/24/7 - это идеальная цель. Которая стоит определенных денег. Инженеры devops - часть решения.

Опыт 6 лет. Мониторинг не помогает не продолбить дефицит места на дисках, айноды. Не помогает с плохими sql, с не назначенными или заниженными java-хипами. Не помогает недопустить краша ноды. Алертинги - это на пол дня удовольствия тимлида - потом письма отправляются в спам. Будят все равно «клиенты». Трейсинги… типа посмотреть, где сделали плохо уже после того, как выкатили? (А дев, а стейдж?) Вот настоящих автотестов не пробовал. Они бы не давали перевести код между стейджами! То есть девопс их результат не увидит, а программист исправит ошибку сразу. Как откомментил выше - половина проблем идет от безопасников. Вторая половина проблем - от бедности. Пример: нужен кластер кубера(цефа, pgsql, elk итд). Устойчивый. Что делает руководство? Читает бэст практис, мануал. Там написано, к примеру: «минимальное количество нод устойчивого кластера =3». Сколько нод покупают? Правильно, 3. Это будет устойчиво? Нет! Потому что авария одной ноды переводит систему в аварийный режим, и что-то перестает работать. Сколько надо нод? Я бы сказал - больше пяти, и даже 7. Отдельных, одинаковых, ЖИРНЫХ! Это покупает время на отработку отказов. Обычно же как: лишить премии ответственного за обслуживание системы - легко, а себя любимого за жадность в покупке железа - никогда!

Так ведь никто и не говорил про серебряную пулю. Как я уже где-то рядом DevOps - это про культуру совместной работы и совместной ответственности dev’ов и ops’ов.

Вами описанные проблемы как раз и вытекают из плохой развитости коммуникаций. Это нормально. Но дальше мы пойдем в основы agile: процессы нужно постоянно развивать. А это сложная задача.

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

Вот настоящих автотестов не пробовал. Они бы не давали перевести код между стейджами! 

А чем ваши автотесты, которые вы используете (вы же их используете) не настоящие?
Почему вы часто пропускаете ошибки? Покрытие? Невозможность ингетрационных? Частая выкатка новой функциональности?


Мне почему-то помогает со всем этим мониторинг.
Место еще только начинает заканчиваться — кто-то уже смотрит в чем дело. Айноды на моей памяти аварийно не заканчивалися уже лет 15.
Плохие SQL увеличивают нагрузку базы данных, срабатывает мониторинг на нетипичную нагрузку и все чинится.
Нормального девопса не будят клиенты ;)
Если у вас есть шанс падения всех нод из-за недостатка общей мощности, вы пишите письмо начальству и показываете его при этом случае. Да, девопс — про предугадывание проблем, а не их хотфикс.
И да, если у вас нет стейджа — вы тоже пишите письмо. Начальство им, конечно, подотреться — но у вас будет история, что вы это писали.

А как вы вычленяете "нетипичную нагрузку"?

Записываю типичную и считаю отклонение.
Если много позитивов, увеличиваю разницу.

Если вас "будят всё равно клиенты", то у вас точно что-то не так с мониторингом. Правильно приготовленная мониторинговая триада позволяет решать 95% проблем в проактивном ключе, вопрос только в выделении ресурсов на это решение. Понятно что бывают редкие пограничные случаи, которые побеспокоят клиента, но это скорее исключения.

Потребность бизнеса - бабки приносить. Если это приносит деньги, но вообще не работает - это нормально. А девопс - это потребность программистов. А то и вовсе "шашечки".

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

Вы считаете аргументом переход на другой уровень абстракции? Ну, такое.

Не программисты выстраивают инфру. Это делают ops‘ы. Они ей и управляют. Задачи devops - это инфраструктурные задачи на стыке кода и инфры. С перехлестом ответственности.

Когда devops-задач много или их уровень сложности выше квалификации devs появляются devops-инженеры.

Раньте были админы и разрабы. Мир двинулся вперед. Появились всякие хайлоады. Стало сложно.

Бросаться в шизофренические крайности, когда «не работает, но деньги приносит» - это вообще о чем? Зачем?

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

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

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

А какими технологиями веб-разработка переусложняется? За последние 10 лет можем видеть только одно: ничего революционно не меняется. Три фреймворка эволюционируют. TS вытеснил конкурентов (чему я рад).

Сейчас в вебе тишь да гладь. Растет только сложность самих интерфейсов.

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

Ситуация сейчас такая же, как и в других языках, вот и всё.

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

главное чтобы это забирание не стало принудительным, и в итоге "работать будем за тебя мы, и кушать за тебя будем мы" (с)

Согласен. Когда есть девопс и он все настроил, жизнь легче. У нас девопс обучила нас соединятся к кластеру с помощью к9s и стало вообще норм.

Если не секрет - а научила она вас чтобы что?

предположу, что подебажить что-нить изнутри деплоймента

Кажется, что не с того конца ребята едят колбасу, если дебажат в кластере…

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

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

Права нужно ограничивать, тут не спорю, но подход safety first имеет свою цену — очень сильно затрудняется отладка и существенно ухудшаются time to market и developer experience.

Схвачу еще минусов, но все-таки задам этот вопрос: а что вы такого хотите найти в кластере, что поможет вам дебажить?

Переменные окружения, сетевая связность, права на файловой системе, число запущенных процессов-потоков и их структура, разделение потребления ресурсов между ними, strace, tcpdump, flame-graph — это из практики.

Отлаживать чёрный ящик всегда сложнее чем белый.

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

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

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

Кмк, когда разработчик не знает/не умеет деплой софта который пишет — это ну такое, не надо так.

Мне кажется, есть какой-то баланс. Ну не должен заклинатель CSS и повелитель async/await'ов разбираться в horizontal pod autoscaling и настройке request limit'ов в конфигах nginx. Есть же делегация полномочий. Это и с программированием так же: вам предоставляют API, вы его используете. Если оказывается, что на той стороне, где API реализовано, есть какие-то затыки / баги / неоптимизированность, то вам не должно быть нужно плясать с бубном и вставлять sleep'ы или throttler'ы в нужных местах, чтобы на той стороне не сдох какой-то обработчик, который вы случайно за'DDoS'или своими запросами.

разбираться в horizontal pod autoscaling и настройке request limit'ов в конфигах nginx.

Нет, но должен понимать, в каком окружении работает софт и как с ним взаимодействует. Ну и неплохо бы знать/уметь как минимум как задеплоить тестовый инстанс (для разработки/тестирования).

задеплоить тестовый инстанс

Если это частая операция, то ее следует автоматизировать. И предоставить разработчику доступ к API создания instance'а. В сложных системах для создания тестового инстанса нужно выполнить 100500 действий, многие из которых требуют высоких привилегий (создание инстансов / namespace'ов / ролей в AWS и т.п.).

А может и не частая, и для неё не нужно 100500 действий.
Универсальный ответ мы тут не найдем.
Мой поинт в том, что


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

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

По крайней мере я придерживаюсь этого в своей практике.

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

просто одинаково хорошо разработчик не научится и разрабатывать и поддерживать инфраструктуру в кондиции

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

Тут изучаешь всю эту кухню 20+ лет, имеешь MS образование — и все равно местами ну совсем не понимаешь, откуда затык.
Да, разработчик тоже может это сделать. Но откуда он возьмет время на изучения этого всего хотя бы в половину так же хорошо, как DevOps?

Ему и не нужно поддерживать инфраструктуру. Ему нужно понимать что где и как работает и как софт который он пишет со всем этим взаимодействует.

иначе


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

Ну в общем мы говорим похоже об одном и том же. )

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

чтобы это мог сделать каждый вновь-нанятый разработчик

ну то есть то, что я предлагаю:

предоставить разработчику доступ к API создания instance'а

лучше, чем требовать от разработчика

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

Возможно, здесь под "задеплоить" и я, и isden имеем одно и то же (кнопку нажать / HTTP request с нужным параметром выполнить / скрипт запустить), но я свои комментарии писал исходя из того, что "задеплоить инстанс" это "знать необходимый минимум DevOps-магии и (как минимум) прочитать и понять все скрипты, с помощью которых поднимается и настраивается instance".

Очевидно, вы никогда это в реальности не делали

Во-первых, «тестовый инстанс» запустить - не галочку в списке поставить

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

Очевидно, у вас не очень хорошо получается ставить диагноз по посту на хабре.

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

Не путайте разовую установку и оркестрацию всеми енвайрнментами.
Разработчик не обязан разбираться в настройке и поддержке кластера
Не обязан знать где где PROD NA, PROD EMEA или где DR/COB, REGRESSION
Не обязан ковыряться с бэкапами, деплоем и откатом релиза на кучу компонентов.

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

К сожалению, многие разработчики считают иначе, уже надоело биться. И главная проблема - чем больше упрощаешь им жизнь, тем меньше они хотят разбираться, как и на чем их приложение запускается В итоге в пределе доходит до того, что разработчик не знает, что есть логи его же приложения, не понимает, откуда его же приложение берет корневые ssl сертификаты и почему не может в ssl с самоподписанным и т.п. :(. Не нужно доводить все до абсолютизма "разработчик должен писать код и точка, а как его собрать и запустить - не его дело"

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

Так и не важно как логи попадут в графану/кибану или просто в каталог. Важно чтобы разработчик знал где они и мог сам посмотреть.

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

Так и не важно как логи попадут в графану/кибану или просто в каталог. Важно чтобы разработчик знал где они и мог сам посмотреть.

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


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

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

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

Фигасе у вас проект, интересно было бы посмотреть на такое.

Да вон хотя бы тот же Zemeroth от @ozkriffвозьмите.

Не то. Я ожидал технических вызовов, костылейкрасивых технических решений для сборки/деплоя, вот это вот все. А тут компилим исходник на расте (все заморочки уже решены разрабами раста), получаем один бинарник и кучку статики, кладем в один проход. К тому же, ничего нет про андроид/айос.
И для этого нужна команда девопсов за 300кк/наносек?

Про андроид - вы плохо смотрели. Плюс сама игра относительно простая. Плюс на расте, да. Плюс товарищ джва года всё это дело настраивал .

А теперь возьмите игровую кампанию а ля Плейрикс - пару дефолтных матч3 на двух мобильных системах, на трех платформах социальных сетей, десятке сторов, под каждую по своей интеграции с аналитикой/рекламой. Повезло если на каком-нибудь Unity, но скорее всего какой-нибудь плюсовый движок типа cocos2d или defold. И вы утверждаете, что каждый разраб должен при входе в кампанию разбираться со всем этим зоопарком? Небось ещё сам же протестировать и багов себе же завести. Вот в таком случае и всплывают всякие девопсы, которые отбирают всю головную боль за подготовку деплоев на разные платформы/сторы, разворачивание dev/test окружений, сборочных серваков и прочих дженкинсов, настройку серверов для сбора/обработки аналитики, крашей и прочего. Чтобы всё это дело организовать надо быть либо неспящим суперменом, либо иметь ту самую команду девопсов за 299кк/наносек - получают они обычно поменьше разрабов основного продукта.

А теперь возьмите игровую кампанию а ля Плейрикс

А вот я и хотел бы посмотреть на что-то такое.


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

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

А вот я и хотел бы посмотреть на что-то такое.

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

Если разраб не понимает систему, которую сам же и пишет — то он не очень хороший разраб

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

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

То, что это не основная моя специализация. Кое-что знаю и умею, конечно. Поэтому и любопытно взглянуть.


есть продукт, который пишут разработчики

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

 Эти знания могут повысить эффективность работы софта и уменьшить количество багов.

Сильно зависит от софта. Иногда в пределах одного приложения есть куски про которые разные команды особо не знают. Взять тот же гейм дев - есть игровой движок, есть игровые механики, есть UI, есть звуки, есть всякие интеграции-аналитики. По большому счёту большая часть всего этого друг от друга изолирована, если мы говорим за большие проекты. Коммуникация конечно есть между командами так или иначе, но редко это прям до уровня кода доходит. "Мне надо вот это, вот в таком виде - окей, буду слать вот таким способом вот таким механизмом". Как там рисуется UI или каким макаром 3д звук организуется - уже не важно. Особенно если ты сервер пилишь для сетевого взаимодействия клиентов.

Сильно зависит от софта.

В принципе согласен, такое вполне может быть.

Игры, например) у нас, когдато, игра билдилась на виндовых билдерах, потом автоматом заливалась на иос и андроид.

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

Я хотел посмотреть на какие-то интересные специфические решения для мультиплатформенной сборки и деплоя.

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

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

Разраб тоже может пойти писать REST апи на Си/Раст, потому хочется(в теории), но очевидно что это было бы не рационально при наличии Питона/Го под рукой (в текущих реалиях)

Зависит от реалий. Яндекс и одноклассники писали REST на плюсах не забавы ради, хотя PHP в то время "сиял" всеми оттенками красного.

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

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

Разраб тоже может пойти писать REST апи на Си/Раст, потому хочется(в теории), но очевидно что это было бы не рационально при наличии Питона/Го под рукой (в текущих реалиях)

Может и нерационально, но что если он знает только Си, а задачу нужно решить?

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

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

А девопс инженеры к DevOps культуре вообще никак. Они просто админят инфраструктуру и настраивают автоматизацию SDLC.

И да, для калькулятора девопс не нужен.

Я бы не сказал, что devops-инженеры «просто админят».

И для калькулятора devops может быть нужен. Просто потому, что он не существует в вакууме, а запускается в разных средах.

Я бы вообще не сказал, что devops вообще админят в том смысле что отвечают за доступность системы. Они обеспечивают доставку изменений.

Баш скрипт по крону отлично доставит изменения. Прямо на любой кластер. Вы уверены что это главное?

У вас 20000 серверов в 20 локациях по всему миру. Накидайте в пару предложений архитектуру доставки изменений в крон и что будете делать когда окажется что допустили ошибку и создали форк-бомбу после чего ни на один из 20000 серверов доступа более нет, ну кроме физического или через что-то вроде ipmi

Как и с обычным системным администрированием. Апдейт бомбы случаются, вспомним яндекс диск и плеск.

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

Вы точно Гугл? Там из-за размера много особых решений нужно.

В более типичных случаях у вас десяток серверов хорошо если в паре локаций. Баш скрипта для доставки изменений вам хватит с головой.

Уверены? А если за каждый день неактуального стейта на любом сервере у вас будут забирать месячную ЗП (с возможностью конечно же уйти в минус и словить необходимость закладывать квартиру чтобы расплатиться)? А то сегодня как раз был прикол где из-за малюсенькой ошибочки команда на десяток человек потеряли 2 миллиона баксов. Точнее их пользователь потерял, но они явно должны будут возместить ущерб.


Все ещё поставите свою голову на заклад что баш скрипты отработают как нужно?

А если за каждый день неактуального стейта на любом сервере у вас будут забирать месячную ЗП

Где же вы инженеров на такие условия найдете? Могу сказать за себя, уволюсь сразу после того как такие условия озвучат. Или не буду устраиваться.

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

Все ещё поставите свою голову на заклад что баш скрипты отработают как нужно?

Девопсы это такие маги которые делают софт без ошибок? Ну-ну.

Где же вы инженеров на такие условия найдете? Могу сказать за себя, уволюсь сразу после того как такие условия озвучат. Или не буду устраиваться.

Обычные условия стартапа. Профит разделяют все участники, убытки тоже.


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

Для компании менее десятка человек — более чем заметно.


Девопсы это такие маги которые делают софт без ошибок? Ну-ну.

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

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

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

А Баш это разве не инструмент? Выглядит как язык программирования. Со своими особенностями, но у кого их нет?

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

Видимо, работаю с одними исключениями. Немного даже льстит.


А Баш это разве не инструмент? Выглядит как язык программирования. Со своими особенностями, но у кого их нет?

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


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


Такие истории неплохо так учат внимательности, и да, лучше учиться на чужих ошибках.

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

Я про работу за зарплату. Часть этой зарплаты может быть фантиками какими-то. Это возможный вариант.

Всяких смешных ошибок стоимостью миллионы я видел достаточно. Но все NDA.

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

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


И с таким отношением люди почему-то склоняются к рабочим инструментам, в частности девопс-стеку, и предпочитают его самописным скриптам.

Это бизнес. Не разработка. Средний разработчик рискует премией или максимум увольнением. И получает за это зарплату, а не долю в бизнесе. Это справедливо.

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

Зачем вы хотите сделать всех разработчиков бизнесменами я не понимаю. Разработчикам в среднем это тоже не нужно.

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

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

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


Это бизнес. Не разработка. Средний разработчик рискует премией или максимум увольнением. И получает за это зарплату, а не долю в бизнесе. Это справедливо.

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

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

При чем тут вообще зарплата? Это типичные риски бизнеса. Цветочный ларек тоже может потерять цветов на миллион из-за ошибки. Это тоже самое.

Все бизнесмены рискуют деньгами и получают прибыть. Но не все люди бизнесмены.

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

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

У кого риски, у того и прибыль. Это справедливо. Как управлять этими рисками чтобы работники приносили прибыль, а не убытки, на длинной дистанции это дело бизнеса. Кто не справился - разоряется. Кто справился - сильно богатеет. Опять справедливо.

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

И при этом я всегда поддерживаю максимальную свободу. У разработчика должна быть красная кнопка "выкатить вот этот бинарь в прод сейчас". Без тестов и прочего. Прямо немедленно. При этом все должно логироваться и быть наблюдаемо. На следующий день к разработчику должен придти робот и попросить объяснение зачем он это сделал. Если другому человеку из другого отдела объяснение не нравится по любой причине к этому разработчику уже люди приходят поговорить.

У разработчика должна быть красная кнопка "выкатить вот этот бинарь в прод сейчас". Без тестов и прочего. Прямо немедленно

Не могу даже придумать зачем это может понадобиться. У собственника такая кнопка может быть. Разработчику - оно точно нужно?

Собственник и катать релизы? Вы это серьезно? Или опять речь про микробизнес из десятка человек где собственник это же один из разработчиков?

3 ночи по времени где основная разработка сидит. На проде внезапно(с) всплыл неприятный баг. Допустим DDOS от соседнего сервиса положил какой-то наш важный сервис. Соседний сервис сделали наши коллеги которым мы в общем доверяем и не защищались от такого прям сразу. Как обычно надо бы но не успели, потом допишем. Деньги теряются со скоростью пару миллионов в час. Коллеги из соседнего сервиса на звонок по телефону не отвечают. У них вообще все хорошо, их мониторинги не загорелись.

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

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

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

При чем тут вообще зарплата? Это типичные риски бизнеса. Цветочный ларек тоже может потерять цветов на миллион из-за ошибки. Это тоже самое.

Пусть будет не зарплаты, а дохода. Это ведь совсем другое дело?


И при этом я всегда поддерживаю максимальную свободу. У разработчика должна быть красная кнопка "выкатить вот этот бинарь в прод сейчас". Без тестов и прочего. Прямо немедленно.

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


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


Я всю ветку про это и говорю. Когда разработчик начинает персонально отвечать за свою работу он становится куда умнее. И продукт получается куда лучше. Просто наблюдение.


Не всем подходит такое, понимаю. Кто-то любит за счет работодателя экспериментировать, учиться. Кто-то напрямую просто подворовывает. Все люди разные :shrug:

Пусть будет не зарплаты, а дохода. Это ведь совсем другое дело?

Конечно. Это слово подразумевает участие в бизнесе и разделение и прибыли и убытка бизнеса.

Я всю ветку про это и говорю. Когда разработчик начинает персонально отвечать за свою работу он становится куда умнее. И продукт получается куда лучше. Просто наблюдение.

А прибылью делиться вы естественно не хотите? Ну там команда из 10 человек написала сервис, он взлетел миллионов на 100 долларов. Логично раздать им миллионов по 5 долларов?

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

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

Не всем подходит такое, понимаю. Кто-то любит за счет работодателя экспериментировать, учиться. Кто-то напрямую просто подворовывает. Все люди разные :shrug:

Учиться это нормально. Почему нет? Если сразу есть план учиться чтобы сменить работу, то есть некоторые вопросы. А если просто ради работы тут с расчетом на повышение, то это нормально. В конце концов все мы чему-то учимся. На любом новом месте есть новые штуки, которые мы изучаем за счет работодателя.

Эксперименты за счет работодателя это постоянно. Сейчас даже кнопочку без АБ теста не перекрасит никто. Выкидывается заметная часть работы. Точнее это называется неудачным экспериментом. И это хорошо. Если сработает хотя бы 5 процентов от новых идей это очень круто. А деньги есть, можно тратить.

За воровство увольнение одним днем без вопросов. Уголовное дело зависит от обстоятельств.

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

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

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

А прибылью делиться вы естественно не хотите? Ну там команда из 10 человек написала сервис, он взлетел миллионов на 100 долларов. Логично раздать им миллионов по 5 долларов?

Хочу конечно же. Так оно у нас сейчас и работает.


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

Считаю, что можно лучше

Хочу конечно же. Так оно у нас сейчас и работает.

Похвально, но немаштабируемо. Я даже не буду о корпорациях. Это не маштабируется даже на средний бизнес (250 человек примерно).

А зачем использовать то что хорошо работает для маленькой компании и плохо в средней — в средней? Если когда-нибудь понадобится отмасштабироваться — процессы можно поменять будет.


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


Считаю такое поведение неправильным.

Так и не используют. Везде разработчики работают просто за зарплату. А деньгами рискует бизнес. Используется именно то что хорошо работает.

Схема с участием всех работников даже среднего предприятия в прибыли не работает. Там инвестиции, риски, бизнес. Не нужно оно людям.

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

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


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

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

Бывает так, что если фанатеть по качеству, то релиз не случается вовсе.

Баш то зачем? Есть же ансибл! :)))

Администрировать - это синоним слова «управлять». Devops-инженеры как управляют системами, так и выстраивают их: архитектуру, пишут код, запрашивают у разрабов доработки софта.

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

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

По последнему абзацу, и как скорость разработки?) Риторический вопрос. Я представляю степень демотивированности этих разработчиков

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

мотивации разобраться, заказать доступ, посмотреть в связке - нет

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

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

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

А почему архитектор инфры не devops?

потому что он уже больше ITAO и менеджер, чем технический сотрудник

Почему он менеджер? Да, у него могут люди в подчинении.

Что такое ITAO я слабо понимаю. Погулил. На первой странице был ваш комментарий, разъясняющий, что это. В общем, не согласен я с тем, что этот нишевый термин можно тащить в диалог.

Архитектуру инфры строит квалификация инженер-devops. Уровень - сеньёр. У него может быть команда в подчинении (лид/менеджер). Он может владеть продуктом - обладать другими квалификациями для этого.

Но, вы возьмете стартап, в котором есть devops - именно он будет выстраивать инфру. А не непонятные названия позиций.

за архитектуру инфры отвечает архитектор инфраструктуры, не сеньер инженер девопс, хотя экспертизы будут пересекаться

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

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

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

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

да просто сделайте калькулятор с требованиям 100K RPS пяти девяток доступности, добавьте требование что нагрузка приходит волнами, и нужно с одной стороны не отвалиться в момент когда нагрузка пришла, но и не закупать инфраструктуру рассчитанную на пик которая 80% времени будет простаивать (и.е. автоскейлинг).


А теперь посморим: нужен ли тут девопс или так обойдемся?

Ну а что, "тупые" (в финансовой области) облачные провайдеры вам автоскейлинг и инфраструктуру под него же бесплатно сделают. "Тупые" проггеры (которые не подозревают что нагрузка будет 100K RPS, а тупо "кодят") вам с ядра не более 1 RPS "падучие и с багами" бесплатно напишут (за то с блекджетом, шл...ми и новомодными технологиями), а "блестящие в доспехах devops" с успехом и конечно бесплатно все это "развернут и поддержат"... :-)
Так примерно? А может в консерватории что-то поправить? :-)

Зависит от того как компания понимает что должен делать девопс. Во многих вакансиях, где я проходил собесы, девопс чисто адмни. А когда я спрашивал -- а причём тут девопс, то мне говорили -- а, ну еще следить за дженкинсом, чтоб работал. Речи о написании пайплайнов, стандартизации процессов там не шла. :)

ИМХО DevOps и все эти навороты — это не плохо и не хорошо — все зависит от задач.
Если у вас сотни разработчиков и сотни тысяч строк кода на куче серверов в разных дата центрах, то у Вас реально сложная задача, и соответственно разумно использовать сложный инструментарий.
Разработка космического корабля и кухонной табуретки несколько отличается. И если у Вас вдруг к табуретке требуется огромная пачка инструкций, чтобы ее собрать, то что-то пошло не так.
Вот в современном IT часто тащат в проекты технологии, потому что это круто и современно, а не потому что реально необходимо. "О, это крутая технология — ее используют FB и Google- нам тоже надо!" Если у Вас продукт сопоставимой сложности как у них, то вероятно действительно надо, но если Вы это все тяните в каждый проект независимо от масштаба, то стоит задуматься!
PS: Пока писал комментарий, выше уже высказали похожую мысль.

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

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

Мини-девопс мне кажется есть в любом продукте. Пишем какой-нибудь простенький веб-магазин. Будет у нас сайт, какая-нибудь алгоритмическая часть которая считает что юзеру предложить, какие-нибудь воркеры которые краулят в интернете что-нибудь и скидывают в базку. Хочется иметь infra as a code, возможность в 1 кнопку развернуть все это добро в любом окружении (в т.ч. локальном), чтобы сеть там правильно прописывалась, чтобы что нужно в интренет торчало, что не надо не торчало, чтобы по коммиту в мастер автоматически запускалось обновление инстансов,…


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

Вместо конфигов приходится лазить по ямл файлам

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


А второй плюс что для этого можно нанять специально нанятого человека, которому я просто говорю "докерфайл лежит вот тут в корне", и на этом мой вклад в инфраструкуру заканчивается — можно сидеть, читать как в новой версии джавы классно гц работает и какие новые удобные каналы сделали, а про всякие порты/сертификаты/… пусть болит голова у кого-то другого.

Если они это делают один раз, а потом все это все работает автоматом, то чем целый отдел девопс занимается остальное время?

Ну у нас нет целого отдела, человек занимается другими задачами. Когда появляется что-то на девопс — отвлекается и делает.

А в более-менее больших компаниях просто всегда есть что сделать. Добавить логгирование ещё этой фигни. Перейти с эластика на другую фигню, потому что она меньше жрет памяти и меньше таймаутится. Перейти с сертбота на вот эту штуку потому что X,Y,Z. Добаить балансировку вот этого сервиса потому что один инстанс перестал справляться с нагрузкой,…

Хорошая статья на тему: danluu.com/sounds-easy

Основной поинт из нее который хотел выделить:

Businesses should keep adding engineers to work on optimization until the cost of adding an engineer equals the revenue gain plus the cost savings at the margin. This is often many more engineers than people realize.

And that's just performance. Features also matter: when I talk to engineers working on basically any product at any company, they'll often find that there are seemingly trivial individual features that can add integer percentage points to revenue. Just as with performance, people underestimate how many engineers you can add to a product before engineers stop paying for themselves.

По моему небольшому опыту вот именно эти «переходы с X на Y», что делают девопсы - по большей части наведение шухера без особого выхлопа.

зачем переходить с эластики на что-то другое, если эластика прекрасно делает свое дело? Если делает плохо, то почему изначально не был выбран Y в процессе ресерча?

Как правило переезды происходят из-за изменений условий, приоритетов или из-за выявления в процессе эксплуатации ранее неизвестных фактов о системе.

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

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

Даешь DevOps as a Service каждому небольшому проекту! Но пока это разовьётся до вменяемых цен, пройдет еще не один год.

Т.е. по высшей логике если нужно на обслуживание 100серверов, 3 человека то на 10 достаточно одного? Если задача не сложная, то цикл авто тестов , и тест на стейдж дев не обязательно? Вместо декларативного повторяемого развёртывания можно ходить фигачить руками?

Мне в бородатые 90е подарили компат диск который был до верха заполнен скинами к WinAMP. Ничего кроме скинов там небыло даже самого WinAMP. Это я к тому, что описанная автором проблема, а именно улучшательства ради улучшательств действительно существует, но причина не в DevOps, а в природе человека. Графоманство - пожалуй наиболее близкий диагноз.

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

Итого, моё ИМХО: графоманство, неадекватные маркетологи, которые пытаются фантазировать потребности клиента и плохое понимание программной инфраструктуры - вот причины описанной автором проблемы, а не DevOps как таковой.

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

Контейнеры для перевозки бывают разные (железнодорожные, морские, автомобильные). И если обратите внимание, то у газельки на «спине» - контейнер. Маленький. Т.е. принцип остается тот же. И в devops также.

Сейчас даже для внутренних нужд лучше взять докеркомпосе/миникуб/k3s.

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

Тут я вижу еще одну, если так можно выразиться "проблему". Все стало доступным. Git, контейнеры, системы оркестрации, СУБД. В 20м веке лицензия на подобное ПО могла стоит десятки тысяч долларов за одно человеко-место. Но случилось прекрасное чудо (я без сарказма) и мир постепенно перешел на открытое ПО. И теперь, выражаясь языком транспортной системы, можно летать за хлебом на самолете.

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

«летать за хлебом на самолете». Вот я частично не согласен с такой параллелью.

Скорее «мы изобрели телепорт и используем его как для перемещения на Марс, так и из гостиной к холодильнику за пивом».

Для перемещения на 10 метров достаточно встроенного в часы. До марса - размеров с автомобиль. В основе мы юзаем виртуализацию для решения проблем. И будут это чистые LXC или обернутые в докер, будут ли там компосер/k3s или k8s - это уже дело десятое.

Но, «летать на самолете»: это использовать k8s для лендинга, например.

А что не так с холодильником? Мне кажется тут уже аналогия протекла немного. Без докера можно распространять приложения влезающие в единственный бинарник со всеми зависимостями. Все что сложнее — в разы проще с докером. Питон? джава? голанг? Не надо человеку ничего ставить, думать тессеракт какой версии требуется чтобы скомпилят ьприложение, клиентские библиотеки постгри какой версии качать и где — он пишет docker build. и мультистейдж докер где все написано скачает как нужно, поставит как нужно и будет работать ожидаемым образом. "но ведь можно написать инструкцию" — во-первых, люди их не читают, во-вторых зачем писать инструкцию если можно заставить машину все сделать правильно? Докер это ультимативное решение проблемы УМВР


image


И не вижу ни малейшго недостатка использовать его даже для приложений магазинов с тремя гет ручками — пусть вся возня с запусками нужных команд, установкой ноды, питона, chezcheme и всего остального будет от меня спрятана — у меня есть docker build и вокруг одни гвозди.

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

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


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

Разработка и эксплуатация - два разных мира с противоречивыми целями существования.

Так по идее DevOps это как раз попытка найти компромисс между "хочу быстро выкатывать новые фичи" (dev) и "хочу, чтобы все стабильно работало" (ops).

Именно. DevOps изначально - это перехлёст ответствености.

Перевод с французского. Внизу надпись "комп выключен".
Перевод с французского. Внизу надпись "комп выключен".

Есть предположение, что человек, написавший статью никогда и не видел настоящего прода, когда 50 микросервисов в облаке, у каждого по 10 инстансов, для каждого нужны политики безопасности, политики для деплоя, отката, перезагрузки и тд и тп. Плюс все это надо одновременно мониторить, дебажить и логи собирать. Автор, напиши, как там все это скриптами на шеле делать. Не забудьте, что это это надо на вчера, а не на через 2 года.

...50 микросервисов в облаке, у каждого по 10 инстансов, для каждого нужны политики безопасности, политики для деплоя, отката, перезагрузки...

Самый цимес, когда в результате всего ЭТОГО заказчик получает новый calc (с VIP темами и лайаутом)

Заказчик деньги платит, ему виднее :)

Его просто залечили

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

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

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

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

Захочу синхронизации, рисование и привязку к соц. сетям - найду соотвествующее приложение в сторе

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

Но я не хочу получить из блокнота WeChat. А кто-то хочет.

Потребности бизнеса исходят из хотелок аудитории этого бизнеса.

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

Вот у меня доча хотела видеть в заметках простой блокнот в Хуавее (Хуавей ноут, или как-то так). Настрочила 800+ заметок за 4 года и телефон устарел.
Все, оно из телефона никак не вытаскивается. Обмен с хуавей планшетом через хуавей облако пролюбил все картинки, то есть заметок приехало всего 600, а те что приехали — только текст.
Не над быть сильно простым пользователем, потом больно. Про синхронизацию, обмен, выгрузку, и чем читать эту выгрузку кроме исходного приложения надо думать самому.

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

Ну, вот, опять "девопс ненастоящий". Та же мантра с "ненастоящим аджайлом". Если вокруг в основном все "ненастоящее" - аджайлы со стендапами по часу и без рефакторинга и девопсы, увеличивающие REPL на порядок, то проблема в консерватории.

Проблема в том, что кто-то решил играть на скрипочке без обучения в этой «консерватории». А потом удивляется, что его талант не ценят.

agile, devops - это инструменты для решения конкретных задач в конкретных условиях. И нужно учиться ими пользоваться.

Вы читали руководство по скраму? Там действительно есть чему обучаться более одного вечера?

Можно придти в компанию и работать «по скраму» - хватит и 5 минут.

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

>я работал и на перфокартах c одним прогоном в день.

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

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

>а не потому, что кроме главного разработчика никто толком не знал, что, почему и как делает система.

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

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

Но документация это вообще маст хев всегда.

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

А разве так? Тогда прошу показать, где в девопсе находятся постановки задач, функциональная архитектура, спецификации, внутренняя и внешняя документации. По минимуму, без проверок требований на полноту и непротиворечивость и разработки методики испытаний.

Случайно "Бородино" не входит в список ваших любых стихов? ПО крайней мере та часть "да, были люди в наше время".


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

Странный вывод: речь шла о причинах "смерти" проекта. Ведь не из-за скриптов же сборки-развертывания, если серьезно.

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


А с таким предполжением все логично — кроме сборки на нем мог быть ключевой функционал, который переписывать просто не было времени. А к тому моменту уже инвесторы/ЛПР/… потеряли интерес в проекте и он заглох.

Думаете если бы у них был DevOps, то этого бы не случилось?

PS наверняка случилось бы, только бы померло бы не по причине того, что никто не знал как собрать проект, а то внутри оказалась бы какая-нибудь, например, волшебная СУБД, про которую никто не в зуб ногой, например какая-нибудь Cache (и это даже не из чего-то новомодного, а такая, вполне себе известная в узких кругах :) )

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

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

>Когда поддерживать и чинить что-то руками стало дурным тоном

Разве девопсы не занимаются ручной поддержкой и починкой своих скриптов, ломающихся ежечасно при изменении одного из 100500 компонентов сборки?

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

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

"когда один или несколько релизов в день стало нормой" - позвольте поинтересоваться с какой целью и почему? Может разрабы "на гора" и по аджайлу пушат баги каждый релиз? Или может "продвинутый" постановщик задачи "глазами, руками и мозгой" не пошевелил до выдачи "на гора" и по аджайлу разрабам задачу? А... Нет. Это "умный" маркетолог убедил бизнес что "счас все это делают" и мы "побыстрому" сорвем банк... :-)

Вообще да. Вот у моего банка UI не менялся глобально лет пять. И слава Богу. Но мне почему то кажется, что там все равно выкатывают чтото несколько раз в день. К счастью, я этого не замечаю

Я тот человек который переложил все ci скрипты и вообще пайплайны jebkins в git. Это сразу, на корню, решило все проблемы вида Вася там что-то делал, оно сломалось, как откатить никто не знает. Nexus там непонятно зачем, но версионирование всего кода, включая ci это правильно.

Nexus там непонятно зачем
Да ровно за тем же самым. Это тоже версионирование, просто немного другое, для другого сорта артефактов.

ну и зачем он если есть гит? Автор же пишет что сначала гит потом из него в нексус и потом деплой. Или деплой из гита это ооже фу-фу-фу?

Затем что хранение и деплой собранных для работы артефактов — это другая задача. Скажем, внешние артефакты (которые хранятся в maven central, или docker registry, или pypi), вы тоже сначала достаете оттуда, складываете в git, а потом из него деплоите?


Обычно люди все-же используют nexus (который если надо умеет прикидываться и и maven, и docker registry, и pypi, npm тоже, ну или какую другую реализацию одного из этих видов репозиториев), чтобы проксировать внешние репозитории.


Если они достаточно параноики — то даже staging репозиторий обычно заводится, чтобы фильтровать вредоносные или уязвимые артефакты. Если у вас этого всего нет (я верю, такие процессы бывают), это не значит, что никому это не нужно. Хотя бы для того, чтобы maven или gradle или sbt или nodejs могли там артефакты при сборке достать — они из гита не умеют, и не должны.

Возможно там про бинарные файлы? Возможно написаны на го, используются в деплое или какоймто анвлизе. Или бинари тоже в гит?:)

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

так это же задача не только ИТ но и например Кинематографа, спорта, туристической отрасли, контент креэйтеров на всех площадках от тв до тиктока, ресторанного бизнеса, парикмахерского, индустрии красоты и т.д, и т.п

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

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

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

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

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

Давайте разовьем! Я знаю что надо использовать docker и kubernetes потому что... Потому что это модно и молодежно. Как смузи и ролики.

Правда, они не могут читать файлы для ETL, которые по какому то протоколу выкачиваются, который нормально поддерживает только винда... Но ничего, сделают кучу костылей

Этож какие такие ETL файлы? Apache Nifi и Airflow прекрасно справляются с ETL процессами. И они как раз гибче масштабируются в k8s. А про модно и молодежно, похоже на старую шутку «вы просто не умеете их готовить»

И я открою страшную тайну есть виндовые контейнеры и ноды к8s на винде)

Я не очень понимаю в чем проблема, так, брызгами зацепило, узнаю позже в чем проблема

На счёт контейнеров, в моём примере, не знаю точно, но stackoverflow, вроде, на 80% состоит из виндовых серверов.

Apache Nifi и Airflow? Отлично, еще два продукта к списку)

Эм это как бы нынче стандарты etl процессов)))

Airflow - это не ETL, в нем нет ничего, что бы делало его ETL-м. Это workflow management платформа. Пихают везде это говно в качестве ETL, тоже своего рода религия. Dagster и Prefect в разы лучше они хоть как то приближены к задачам ETL-я, могут хотябы данные между узлами передавать.

Соглашусь, однако используют его зачастую именно для оркестрации ETL. Ну насчет нет ничего, не соглашусь. Как же DAG’и которые добавляют ему гибкости.

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

Отторжение непонятного - нормальная ситуация (не в смысле «так и должно быть», а в смысле «встречается сплошь и рядом»).

Почти пародия на всплывающие периодически статьи про программистов: "зачем нам ООП с этими сложными абстракциями, когда можно написать одну простую функцию на коленке, и норм". Забавно, не более. Извините за душноту :)

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