Comments 422
Вот да! Есть версия это статьи на английском?
Я могу сделать авторский перевод.
Переведите заголовок обратно на английский и загуглите. Найдете вот это.
Вот да! Есть версия это статьи на английском?
Версионность статьи про DevOps?
Чего да. Как проработавший в DevOps лет 5, могу сказать, что без нас вся разработка, QA и деплоймент в продакшен просто встали бы. Ну или делались раз в 50+ медленнее.
А прокачка софтскилов, талент-менеджмент, коучинг, оне-ту-оне и корпоративный психолог?
Человек, который написал это – нет понимания что такое DevOps. Просто какой-то поток мыслей
Скажу, что человек написал чем может стать DevOps, но не чем обязано быть.
Возьмите для примера Жиру. У нас например в проекте даже поле описания тикета редко кто заполняет. То есть из всего разнообразия полей, из 100-тен полей которыми обвешан тикет реально-системно используются 4 или 5 штук (!) остальные хранят какие то епизодические случайные артефакты, по сути мусор!!!
Неужели это не понятно что нормальный живой человек не в состоянии ориентироваться, а тем более поддерживать в актуальном состоянии сотни полей, он их просто будет игнорировать, так зачем же создавать такое богатство?
Надо еще учесть что этот нормальный человек кроме Жиры еще должен код писать в каком то своем енвайронменте на каком то своем языке, Жира вроде бы должна облегчать ему работу, а все идет к тому что ты должен в первую очередь быть специалистом по Жире, наплевать на твою основную предметную область.
Как говорил один юморист:
Как страшно жить! Она не Красная шапочка, а Дура!
От себя добавлю: Статья-Огонь!
Кто-то в джира веде вообще записи для себя, кому-то просто достаточно титла. У кого-то настроена интеграция с битбакетом и дженкинсом, чтобы в тикете автоматом появлялся список билдов и коммитов связанных с этой джирой, и это позволяет автоматом генерировать change notes, например.
Jira - инструмент для менеджеров и тимлидов, чтобы оценивать занятость сотрудников и генерироваьт различные репорты. Степень наполнения в JIRA зависит сугубо от требования менеджеров и тимлидов, а не от девопсов или разработчиков.
Все зависит от индустрии и практик в ней принятых. Если вам инструмент не подходит, это не значит, что он никому не подходит. Вполне в каком-нибудь DoD могут все 100 полей заполнить и еще 200 кастомных настроить.
Я понял, что с Jira что-то не так, когда узнал, что есть спецы по ней - "жировики" (я бы через "ы" писал).
Настоящий девопс еще нигде не был построен.
Думаю, это было написано не про теорию, а как оно бывает на самом деле. И его полностью поддерживаю - войти в айти у всех на слуху, и довольно часто бывает, что человек без понятия, что он должен делать. А дальше это берет другой и еще сильнее извращает, и что мы имеем на выходе? 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?
да, а потому что во главе контор теперь такие же смузи-менеджеры, поддерживающие любые смузи-инициативы! В итоге все такие классные современные, а на продукт без слез не взглянешь. Я адвайзю много проектов/стартапов и такое везде, к сожалению
А что такое DevOps? Спросите это у 5 разных людей на DevOpsConf ;)
Он не смог написать тесты для своего плагина, потом у него не было дев. окружения для быстрого тестирования. Каждый раз комитил, пушил в гит(интересно может еще и с пулл реквестами? :D), закачивал в Nexus - и думает вот мне тут жизнь усложнили, девопс же это про написал скриптик и в прод.
Я был DBA и делал Jenkins jobs для middle junior DBA из другого отдела, в духе выполним этот скрипт на сервере и пришлем результат почтой. Это позволяло им не запрашивать доступ к серверам ради повторяющихся кверей
Таким образом я просто использовал Jenkins не совсем по назначению
То есть не совсем по назначению. Дженкинс это тулза для автоматизации, то что ее начали называть CI тулзой, это произошло уже позже и это не есть ее главное назначение. Просто массовое.
Ну вообще если копнуть глубже, то женкинс просто шедулер. Набор скриптов, выполняемых последовательно, по какому либо событию. ВременнОму или коммиту. Технически можно реализовать на на условном systemd. Просто без вебморды.
Вот не надо упрощать до просто шедулера.
Это оркестратор, с поддержкой агентов, с внутренним скриптингом, который позволяет оркестрировать эти агенты, с поддержкой внутренних библиотек и плагинов, с хранилищем секретов, с сегрегацией доступа, с поддержкой киллерфичи, которая в других подобных инструментов была внедрена гораздо позже и хуже - я про Jenkinsfile
Да собственно многие вебморду дженкинса могут и не видеть, и отлично им пользоваться.
Главное что он выполняется на другом сервере под другими правами. Поэтому человек может выполнить скрипт, на который у него нет прав в обычной жизни
выполнять что-то на другом сервере под другими правами вообще задача CD инструмента, если мы говорим про разработку.
Либо оркестратор, если мы говорим про администрирование (chef/ansible/etc), но в этом случае "другие права" обычно подразумевается рут
Дженкинс все-таки больше инструмент разработчика, и изначально был сделан для управления и автоматизации сборок
А если мы говорим не про разработку а про жизнь отдела поддержки?
Ну там:
сделать бэкап на проде,
обновить новой версией,
прогнать обслуживание SQL (индексы/статистики)
сделать бэкап еще раз,
развернуть второй бэкап на новом месте (и проверили что бэкап живой, и на этом самом месте первая/вторая линия поддержки будут воспроизводить проблемы пользователей от имени этих пользователей и в актуальном окружении)
Ну или короткое подмножество — бэкап прода среди дня, развернуть для аналитика поддержки актуальную версию (это когда за день успели столько натворить, что на ночной копии не воспроизведешь)
Естественно ни у аналитиков ни у поддержки почти никаких прав на проде, чисто аудиторский профиль.
Кажется дженкинс как многосерверный шедулер должен хорошо зайти.
Я как раз этим и занимался)
А я в процессе изучения. Наши админы сказали "а хрен его знает, как так сделать" и пока навтыкали шедулеров на каждом сервере на каждый шаг. (с запасом по времени) вот только мы уже отожрали окно с 23-00 до 08-00, а пересечения раз-два в неделю случаются, когда один не успел, второй стартовал и споткнулся.
Что, дженкинс хорошо должен зайти, или стоит в другое место посмотреть?
В моем текущем проекте мы используем отдельные продукты для CI и CD. Вдобавок админ дженкинса получается имеет доступ вообще ко всему без всякой сегрегации доступа.
Вдобавок админ дженкинса получается имеет доступ вообще ко всему без всякой сегрегации доступа.
С одной стороны это напрягает, а с другой, разве нельзя развести через типа прокси и преднастроенные процедуры? Ну, например, дженкинс агент не выполняет произвольный алгоритм на скуле, а пинает скуль агента, который запускает заранее настроенную процедуру, которая работает с повышенными правами.
Тогда проще просто поднять два независимых дженкинса. Настроить один для девелоперских задач, второй для продакшен саппорта. И не мешать их в одну кучу, а то мало ли что где.
Опять таки, девелоперский дженкинс может обрастать плагинами, инструментами и так далее, мало ли где возникнет необходимость или уязвимость.
Для продакшен саппорта предпочитаем иметь как минимум отдельный инстанс, который статичный, с минимальными изменениями.
Вы опровергаете название своей статьи. Вывод почему-то не делаете. Не девопс - опухоль, а безопасники и бизнес-процессы! Почему бы не сделать программу или микросервис, выгружающий данные без jenkins? Это же программирование - вперед! Чтобы понять смысл девопс, прочитайте (хотя бы по-диагонали) книгу «проект Феникс». Девопс нужен, чтобы прогеры могли спокойно прогать, но не лезли шаловливыми ручками в базы, не лажали релизы, не крашили обновлениями продакшн. Чтобы в командах был стабильный процесс, а не согласно положению звезд и настроению жены тимлида.
Знакомая просто переименовала админов в девопсы?
Да.
что это значит? В модели devops нет чисто девелоперов, оно и называется develop + operations. Знакомая просто переименовала админов в девопсы?
В смысле нету? А как назвать человека который умеет в терраформы/женкинсы/кубернетесы/питон/… но не умеет в скажем джву и раст? А с ним в команде работает человек который умеет в расты, джавы, хаскели, но в гробу видал yml, его получается нанимать ошибка?
Ошибка - это то, что девопсу дают примерно пять минут на выполнение любой задачи. Типа так: «эй боец, сбегай сделай по-быстрому». А языков и диалектов вашего программирования хренова гора. И у каждого прогера свое понимание бэст-практис. А сеньеров не переспорить, к примеру, доказывая, что джава профили нужно выбросить. Девопс бы не против обучиться - постоянно это делает, но прогеры, высокомерно ничего не объясняют - на созвонах же. А тратить снова пять лет в универе, изучая как мэйн-класс объявить и какие зависимости подключить для хелоуворда в ваших ${язык программирования} , который все выкинут как delphi через X-лет не хочется.
Ну если вам нужно пять лет в универе для того, чтобы разобраться с тем, что можно нагуглить за полчаса - у меня для вас плохие новости
Гугление не заменяет опыт. Очень часто те, которые гуглят решение, слабо представляют себе бест практики применения инструмента. Живой пример: джава программист пишет для деплоя скрипт на shell. Он нагуглил какие то операции, и оно даже работает. Однако, спустя время, передав уже готовый деплоя в другие руки, оказывается что скрипт работает очень неадекватно: аргументы нужно задавать только в определенной последовательности, скрипт не расчитан на внезапное прерывание его работы, а так же скрипт требует ручного ввода информации для деплоя (привет человеческому фактору, во всех проблемах). Но это частности. Когда я заглянул в этот скрипт, я пришел в "восторг", т.к. скрипт выглядел набором функций на любую операцию: к примеру стоп/старт/рестарт jvm - это все отдельные функции, несмотря на то, что управляющая "платформа" понимает обращение к данной jvm с параметрами start/stop/restart.
Итого: гугление не заменяет внимательного изучения инструментов, а дьявол прячется в мелочах.
А если умеет и в жаву и в руби и в си и еще чегото? Тот же голанг. И, да, не синьорский уровень, но, думаю на джуна/мидла вполне можно.
Женкинс пайпланы это груви, тут и ява не далеко. Питон скорее как консольные тулы или просто лень ручками стандартизированные файлы конвертировать.
Если умеет то это не та ситуация которую я рассматриваю. Представьте себе я говорю вот приходит джун без опыта и ..., а в ответ возражение "а вдруг он с опытом приходит??". Ну если с опытом, то уже другая ситуация, её рассматривать не очень интересно)
Я конечно неправильно могу понимать, но для меня девопс это помесь админа и разраба. В том плане, что админ это обычно на мышки драйверы установить. вирусов там вычистить и вот это все, ну сеть может настроить. А девопс — это дженкинсы, пайплайны. вся вот эта муть. Примерно то же, что админство, но с использованием as a code инструментов, ну и шире, что ли. При этом это не полноценный разработчик — ему позволительно не знать про О большое, про структуры данных, как там гц работает, как правильно профилировать приложение,… Он знает питон/го/… на уровне "могу написать скрипт 30 строк", и все. Программист же наоборот — умеет во все эти навыки, но его знания инфраструктуры заканчивается на "умею написать мультистейдж докерфайл который грамотно кэширует слои " и "не храню стейт в приложении". А как оно там деплоится, по каким хттпсам приходит, сколько инстансов где развернуто — слов таких не знает. Просто пишет себе код в подвале и пушит в мастер фиксы, которые автоматически инструментарием настроенным девопсом попадают куда нужно.
Для меня это ключевой способ работы, есть выделенные люди со своей зоной ответственности и они этим занимаются. Совмещать эти две вещи имхо то же что совмещать фронтенд и бекенд разработку — хорошим не заканчивается, пусть этим занимаются выделенные специалисты.
Вы забываете про админов у которых под контролем сотни/тысячи серверов. Они были до ваших дженкинсов и будут и после них. И автоматизация управления этим хозяйством была до всей этой моды и останется и после нее.
Инструменты могут как угодно меняться, а админы никуда не денутся. Ну может обзовут их еще как-то. Кому какое дело? Лишь бы деньги платили.
админ это обычно на мышки драйверы установить. вирусов там вычистить и вот это все, ну сеть может настроить
Вот в этом последние лет 25 и была одна из основны проблем русскоязычного IT - с каких-то щей "админами" стали называть IT technicians, хотя это две совершенно разные профессии :)
В итоге в какой-то момент "админом" стало быть так же "стыдно", как и "тыжпрограммистом" :)
Поддерживаю! Все что можно было уложить в один софт рассыпано по куче инструментов. Стирается грань между Вавилоном и Свободой выбора, к чему это привело всем известно
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% проблем в проактивном ключе, вопрос только в выделении ресурсов на это решение. Понятно что бывают редкие пограничные случаи, которые побеспокоят клиента, но это скорее исключения.
del
Потребность бизнеса - бабки приносить. Если это приносит деньги, но вообще не работает - это нормально. А девопс - это потребность программистов. А то и вовсе "шашечки".
Кажется это пропорционально размеру бизнеса и задействованных в нём разработчиков. Кому-то хватит и гитхуков, а кому-то надо восемь команд из пяти направлений для двух продуктов менеджить. Где-то автоматизация будет оверкилом, где-то - жесткая необходимость. И тут тоже не сильно принципиально насколько рабочий продукт, если оно в таком виде приносит деньги.
Вы считаете аргументом переход на другой уровень абстракции? Ну, такое.
Не программисты выстраивают инфру. Это делают ops‘ы. Они ей и управляют. Задачи devops - это инфраструктурные задачи на стыке кода и инфры. С перехлестом ответственности.
Когда devops-задач много или их уровень сложности выше квалификации devs появляются devops-инженеры.
Раньте были админы и разрабы. Мир двинулся вперед. Появились всякие хайлоады. Стало сложно.
Бросаться в шизофренические крайности, когда «не работает, но деньги приносит» - это вообще о чем? Зачем?
Мне кажется, вам скорее сильно не повезло. Вы правы, DevOps должны упрощать процессы, забирать у разработчиков всю нудятину по настройке конфигов и деплою их приложения конечным юзерам.
У меня просто была обратная ситуация - во всех местах где я работал, были очень хорошо отлаженны DevOps процессы. Переусложнения не было, проблемы решались по мере их появления, становилось реально проще - мне как разработчику, надо было всего запушить код - и оно само развертывается где нужно, как нужно, на каких нужно серверах, с какими нужно конфигами, интеграцями и пр.
Согласен с вами в том плане, что веб разработка в последнее время сильно переусложняется новыми абстрактными технологиями, но проблема которую вы описали в статье, является проблемой не DevOps, а плохо настроенных процессов компании.
А какими технологиями веб-разработка переусложняется? За последние 10 лет можем видеть только одно: ничего революционно не меняется. Три фреймворка эволюционируют. TS вытеснил конкурентов (чему я рад).
Сейчас в вебе тишь да гладь. Растет только сложность самих интерфейсов.
DevOps должны упрощать процессы, забирать у разработчиков всю нудятину по настройке конфигов и деплою их приложения конечным юзерам.
главное чтобы это забирание не стало принудительным, и в итоге "работать будем за тебя мы, и кушать за тебя будем мы" (с)
Согласен. Когда есть девопс и он все настроил, жизнь легче. У нас девопс обучила нас соединятся к кластеру с помощью к9s и стало вообще норм.
Если не секрет - а научила она вас чтобы что?
предположу, что подебажить что-нить изнутри деплоймента
Кажется, что не с того конца ребята едят колбасу, если дебажат в кластере…
Всё норм, это один из самых лучших способов понять что происходит с приложением, зачастую это позволяет понять проблему значительно быстрее.
Релиз может быть довольно долгим делом, а для решения проблемы их нужно не меньше двух — включить отладочный режим и добавить метрики/логи в подозрительных местах, а затем выкатить фикс (хорошо ещё если с первого раза получится).
Права нужно ограничивать, тут не спорю, но подход safety first имеет свою цену — очень сильно затрудняется отладка и существенно ухудшаются time to market и developer experience.
Если я правильно понял, то научила поднимать кубер локально, что, в целом полезно для понимания как их приложение будет вести себя в виде пода.
забирать у разработчиков всю нудятину по настройке конфигов и деплою их приложения конечным юзерам.
Кмк, когда разработчик не знает/не умеет деплой софта который пишет — это ну такое, не надо так. От этого могут вылезти очень неприятные баги, которые ни девопсы, ни разработчик (в сабжевом кейсе) понять и починить не могут.
Кмк, когда разработчик не знает/не умеет деплой софта который пишет — это ну такое, не надо так.
Мне кажется, есть какой-то баланс. Ну не должен заклинатель 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 со товарищи то для меня такой подход работает как часы многие годы, и никто пока не жаловался.
А вы когда-нибудь пытались сделать деплой софта, чтобы был на винде, линухе / бсд, маке, айосе и андроиде. Ну и в вебе конечно же.
Фигасе у вас проект, интересно было бы посмотреть на такое.
Не то. Я ожидал технических вызовов, костылейкрасивых технических решений для сборки/деплоя, вот это вот все. А тут компилим исходник на расте (все заморочки уже решены разрабами раста), получаем один бинарник и кучку статики, кладем в один проход. К тому же, ничего нет про андроид/айос.
И для этого нужна команда девопсов за 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. и мультистейдж докер где все написано скачает как нужно, поставит как нужно и будет работать ожидаемым образом. "но ведь можно написать инструкцию" — во-первых, люди их не читают, во-вторых зачем писать инструкцию если можно заставить машину все сделать правильно? Докер это ультимативное решение проблемы УМВР
И не вижу ни малейшго недостатка использовать его даже для приложений магазинов с тремя гет ручками — пусть вся возня с запусками нужных команд, установкой ноды, питона, chezcheme и всего остального будет от меня спрятана — у меня есть docker build и вокруг одни гвозди.
капец хабр чудит
Дженкинс и скрипты в нексусе - это просто ci. Девопс - это когда разраб запушил и забыл. И не один разраб, а несколько сотен в десятках команд.
DevOps это методология, по которой разработчики отвечают не только за написание кода, но и за его деплоймент в продашен. Как это делается — отдельный вопрос. Можно сделать хорошо и без лишних сложностей, а можно наворотить не пойми что.
Очень печально, что термин DevOps стал хайповым и лепится сейчас ко всему по делу и без. Нет DevOps инженеров. Есть инженеры, которые владеют DevOps методологией.
Есть предположение, что человек, написавший статью никогда и не видел настоящего прода, когда 50 микросервисов в облаке, у каждого по 10 инстансов, для каждого нужны политики безопасности, политики для деплоя, отката, перезагрузки и тд и тп. Плюс все это надо одновременно мониторить, дебажить и логи собирать. Автор, напиши, как там все это скриптами на шеле делать. Не забудьте, что это это надо на вчера, а не на через 2 года.
...50 микросервисов в облаке, у каждого по 10 инстансов, для каждого нужны политики безопасности, политики для деплоя, отката, перезагрузки...
Самый цимес, когда в результате всего ЭТОГО заказчик получает новый calc (с VIP темами и лайаутом)
Заказчик деньги платит, ему виднее :)
Ну да, гораздо лучше, когда заказчик получает калькулятор без тем и лэйаута, а потом не может его продать, потому что просто калькулятор никому не нужен. И приходится его улучшать, добавлять темы и лэйауты, прикручивать решение формул и т.д., только все это через боль и страдания, потому что изначально думали, что все практики девопс и тд не нужны и это оверинжиниринг и все сделано ручками на скриптах и велосипедах, а теперь скрипты и велосипеды уже не вывозят и надо с нуля все переделывать. Я уже несколько раз сталкивался с таким подходом, когда контракторы делают что-то, думая что они умнее всех...а потом это невозможно нормально поддерживать и развивать, потому что есть действительно оверинжиниринг, а есть есть люди, которые привели по старинке работать, когда системы были в 50 раз проще. Я не спорю, что сейчас очень много всего, что добавляет сложности в проекты, но и сами проекты стали гораздо сложнее. Раньше не было такого, чтоб к тебе одновременно валился трафик с кучи разных устройств, с разных стран, континентов, разных типов пользователей и тд. Не надо было обрабатывать такое количество информации. Не было KYC и тд.
Вот у вас есть заметки на телефоне. Это просто редактор. Но мы не хотим условный Блокнот из виндоус. Мы уже хотим синхронизацию заметок, мы хотим рисовать в блокноте, добавлять изображения, взаимодействовать со стилусом и тд. Мы хотим чтоб это появлялось на разных платформах. И добавлять изображения. И экспорт в соц сети и кучу всего ещё. И мы хотим чтоб это все масштабировалось под миллионы пользователей. И было дёшево разрабатывать, потому что время программиста очень дорогое для бизнеса. Отсюда и появились и все фрейворки, девопсы и прочее. Без этого можно обойтись, но это будет намного дороже и сложнее в поддержке.
Это просто редактор. Но мы не хотим условный Блокнот из виндоус. Мы уже хотим синхронизацию заметок, мы хотим рисовать в блокноте, добавлять изображения, взаимодействовать со стилусом и тд. Мы хотим чтоб это появлялось на разных платформах. И добавлять изображения. И экспорт в соц сети и кучу всего ещё. И мы хотим чтоб это все масштабировалось под миллионы пользователей.
Нет, мы - пользователи - этого не хотим. Я хочу видеть в заметках простой блокнот, особенно в телефоне.
Захочу синхронизации, рисование и привязку к соц. сетям - найду соотвествующее приложение в сторе
Нет, мы - пользователи, этого хотим. Я не хочу искать - я хочу, чтобы приложения соответствовали современости. А если уж нужен будет просто, то здесь уж можно поискать по соответствующим ключевым словам.
Но я не хочу получить из блокнота WeChat. А кто-то хочет.
Потребности бизнеса исходят из хотелок аудитории этого бизнеса.
Если бы вы хотели этого, половины приложений и продуктов не появилось бы или уже давно бы сгинули.
Вот у меня доча хотела видеть в заметках простой блокнот в Хуавее (Хуавей ноут, или как-то так). Настрочила 800+ заметок за 4 года и телефон устарел.
Все, оно из телефона никак не вытаскивается. Обмен с хуавей планшетом через хуавей облако пролюбил все картинки, то есть заметок приехало всего 600, а те что приехали — только текст.
Не над быть сильно простым пользователем, потом больно. Про синхронизацию, обмен, выгрузку, и чем читать эту выгрузку кроме исходного приложения надо думать самому.
Справедливости ради, у хуавей те еще сервисы. Даже банальный перенос данных с одного телефона на другой (по железу они отличаются размером оперативы и камерами) через phone clone потребовал танцы с бубном, занял несколько часов (синк упорно отваливался и не подцеплялся с первого раза), и то не все корректно перенеслось.
Ну, вот, опять "девопс ненастоящий". Та же мантра с "ненастоящим аджайлом". Если вокруг в основном все "ненастоящее" - аджайлы со стендапами по часу и без рефакторинга и девопсы, увеличивающие REPL на порядок, то проблема в консерватории.
>я работал и на перфокартах c одним прогоном в день.
А я не работал на перфокартах, но зато помню, как сборка перспективного B2B проекта в рамках IT-отдела крупного промышленного концерна поддерживалась одним человеком, по совместительству его, вероятно, главным разработчиком, и собиралась при помощи батников и неведомой магии, и когда он в одночасье умер, то внезапно проект умер в течение полугода. Казалось бы, при чем тут DevOps?
Прекрасная иллюстрация маркетинга девопса - проект, оказывается, умер из-за невозможности разобраться в трех скриптах на шелле, а не потому, что кроме главного разработчика никто толком не знал, что, почему и как делает система.
>а не потому, что кроме главного разработчика никто толком не знал, что, почему и как делает система.
Так суть DevOps как раз и состоит в том, что в проекте должен быть четкий набор технологий и методологий интеграции и доставки, реализацию которых сможет разобрать любой специалист, владеющий данным набором, а не ворох плохо связанных костылей, подпирающих процесс сборки. Разве не так?
Да нет. Просто документация нормальная должна быть на проекте. Даже если это легаси или редко используемые технологии.
А костыли - они везде есть в том или ином виде.
Но документация это вообще маст хев всегда.
Я бы сказал, что частично комментарий выше содержит долю истины. Если будут стандарты (стандартизированные скрипты, конфиги, хелмчарты и всякое такое) + адекватная документация, описывающая как этим пользоваться, то и проблемы не будет. А если каждый тим лид из условных 10-20 команд разработчиков сам "какшмагла" будет писать скрипты сборки, деплоя, тестирования, то там никакая документация не поможет.
А разве так? Тогда прошу показать, где в девопсе находятся постановки задач, функциональная архитектура, спецификации, внутренняя и внешняя документации. По минимуму, без проверок требований на полноту и непротиворечивость и разработки методики испытаний.
Случайно "Бородино" не входит в список ваших любых стихов? ПО крайней мере та часть "да, были люди в наше время".
История: сделанную на хоуммейд скриптах и хаках систему после ухода разработчика не смогли поддерживать.
Сделанный вывод: разработчик молодец, а молодежжж нынче не та пошла, даже в паре скриптов разобраться не может.
Странный вывод: речь шла о причинах "смерти" проекта. Ведь не из-за скриптов же сборки-развертывания, если серьезно.
Ну, без дополнительных деталей это и правда выглядит странно, но если принять на веру то что там так все и было, то в целом я бы сказал вина на разработчике, ну и тех кто допустил такой бас-фактор в команде (хотя полагаю, что он и был лидом).
А с таким предполжением все логично — кроме сборки на нем мог быть ключевой функционал, который переписывать просто не было времени. А к тому моменту уже инвесторы/ЛПР/… потеряли интерес в проекте и он заглох.
Думаете если бы у них был DevOps, то этого бы не случилось?
PS наверняка случилось бы, только бы померло бы не по причине того, что никто не знал как собрать проект, а то внутри оказалась бы какая-нибудь, например, волшебная СУБД, про которую никто не в зуб ногой, например какая-нибудь Cache (и это даже не из чего-то новомодного, а такая, вполне себе известная в узких кругах :) )
Прежде, чем писать подобный "вброс", стоит качественно изучить вопрос. Ничего в мире просто так не появляется. Есть причины и последствия. DevOps появился как естественное продолжение ускорения процессов разработки, когда один или несколько релизов в день стало нормой. Когда поддерживать и чинить что-то руками стало дурным тоном. Если рассуждать про этот вопрос всерьез, тогда уж надо брать шире и исследовать тему "почему же весь мир так сильно разгоняет разработку, доставку новых фич, моментальное исправление любых багов, неприятие простоя сервиса в 5 минут", и прочее, и прочее. Смотрите шире. То, что вы описали в статье, это просто плохие практики, с которыми вам не повезло столкнуться.
Вероятно автор стал жертвой последователей карго-культа в чем его винить нельзя кроме того что он продолжает работать в подобных компаниях и ничего не делает что бы ситуацию исправить.
>Когда поддерживать и чинить что-то руками стало дурным тоном
Разве девопсы не занимаются ручной поддержкой и починкой своих скриптов, ломающихся ежечасно при изменении одного из 100500 компонентов сборки?
Есть причины и последствия. DevOps появился как естественное продолжение ускорения процессов разработки, когда один или несколько релизов в день стало нормой
Поэтому и качество ПО падает - ничего у нас там несколько релизов в день исправление попадет в катойто релиз. При этом не учитывается что автотесты дописывать с такой скоростью никто не будет
"когда один или несколько релизов в день стало нормой" - позвольте поинтересоваться с какой целью и почему? Может разрабы "на гора" и по аджайлу пушат баги каждый релиз? Или может "продвинутый" постановщик задачи "глазами, руками и мозгой" не пошевелил до выдачи "на гора" и по аджайлу разрабам задачу? А... Нет. Это "умный" маркетолог убедил бизнес что "счас все это делают" и мы "побыстрому" сорвем банк... :-)
Я тот человек который переложил все 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 на винде)
Apache Nifi и Airflow? Отлично, еще два продукта к списку)
Эм это как бы нынче стандарты etl процессов)))
Airflow - это не ETL, в нем нет ничего, что бы делало его ETL-м. Это workflow management платформа. Пихают везде это говно в качестве ETL, тоже своего рода религия. Dagster и Prefect в разы лучше они хоть как то приближены к задачам ETL-я, могут хотябы данные между узлами передавать.
Соглашусь, однако используют его зачастую именно для оркестрации ETL. Ну насчет нет ничего, не соглашусь. Как же DAG’и которые добавляют ему гибкости.
Нормальный etl должен содержать два обязательных уровня - управление загрузкой (оркестровка процесса) и уровень трансформаций, управление загрузкой должны включать в себя в том числе и циклы, обоаботку ошибок , переходы по условию или по набору данных в потоке данных - этого нет. Уровкнь трансформации должны содержать различного рода экстракторы из разных источников и целевые объекты- таргеты, их тоже нет, сами трансформации их в нормальном erl огромное количество под всякие нужды от калькулятора до изменения типа данных, локапы и мержи, этого тоже нет. Есть еще третий слой - слой описаеия метаданных,, он есть не у всех, но этого тоже нет. Взамен всего этого разработчику предлагается наговнокодить это все на питона.
Отторжение непонятного - нормальная ситуация (не в смысле «так и должно быть», а в смысле «встречается сплошь и рядом»).
Почти пародия на всплывающие периодически статьи про программистов: "зачем нам ООП с этими сложными абстракциями, когда можно написать одну простую функцию на коленке, и норм". Забавно, не более. Извините за душноту :)
Проблема в чём, в том что отладка неудобная? Ну поколениями отлаживали `printf`ом и как-то жили. Такой феномен
Я пишу программы с 1988 г. и с тех пор отлаживал их только в отладчике (интегрированном с редактором, т.н. IDE) с брейкпойнтами и пошаговой отладкой. Могу вас уверить, что это удобнее, чем printf, и "пококления" не отлаживают через printf
Иногда сталкиваешься с ситуациями, когда отладчиком не подлезть или он слишком сильно влияет на работу программы...
15 лет уже отлаживаю sql процедуры на сотни строк без всяких отладчиков. Никаких особых проблем не испытываю
Я тоже.
А позвольте поинтересоваться вы эти отлаженные процедуры до сих пор скриптами в базу пишите?
У меня была на прошлом месте созданная мной для себя jenkins джоба типа 'apply to all servers'. Она шла по списку серверов (около 400, список динамический, синкался с Vmware) и делала sqlcmd -S %server% -E -i script.sql
Скрипты не относились ни к какому продукту так как были DBAшными - rчасто корректировка процедур сидящих в msdb для adaptive index defrag/reorg итд
Я так понимаю, sql вообще не особо заточен на использование отладчика? (Зато у вас REPL есть).
Да и сотни строк – это, откровенно говоря, не дофига. При таком объёме и на C++ профит от дебагера не столь велик.
а больше 3-4 сотен - уже стоит разбивать на несколько.
Безусловно (собственно, даже меньше, обычно пара экранов – более чем).
Но в крестиках даже это не спасает от использования дебагера: обычно ведь не погоняешь функцию саму по себе. Разве что вы сферический адепт TDD в вакууме, который действительно спроектировал всё под юнит-тесты, передавая в каждую функцию всё окружение и сделал моки для всего, что ей может потребоваться.
Как же любят старички вспоминать про KISS. Но принцип то не о том, что "делай как можно проще", а о том, что использовать и обслуживать механизмы должно быть просто. Сделал пуш, нажал кнопку - раскатилось, нажал другую - откатилось, вот KISS, и вся работа девопсов как раз про это. А то, что там под капотом кнопки десятки технологий - это именно то, что обеспечивает дальнейшую эксплутационную простоту.
под капотом кнопки десятки технологий - это именно то, что обеспечивает дальнейшую эксплутационную простоту
Десятки технологий - это то, что обеспечивает эксплуатационный ад.
Макаронный монстр, связанный через костыли, хуки и настройки сделанные мышкой в веб-интерфейсе, с разваливающимися процессами из-за того, что в очередной версии одного из компонентов убрали «устаревшие и ненужные механизмы» на которые девопсы завязали свои пайплайны.
Расскажите как сделать одну кнопку "сделай хорошо" без эксплуатационного ада, пожалуйста.
Кнопку "сделай хорошо" хорошо сделать не получится никакими существующими или будущими технологиями, это не вопрос технологий. Странно что это нужно кому то объяснять... И люди убеждающие вас что - "счас все будет", сознательные (или нет) мошенники.
Как-то пришел на проект в европейскую компанию, которая аутсорсила его индийским разработчикам. Так вот развертывание релиза на dev, staging или prod один облачный сервер занимало сутки и требовало работы 1-2 девопсов
30 строчек yaml кода для GiHub Actions уменьшило время развертывания до 2 минут и сделало ненужной команду девопсов и их менеджеров, за что GiHub Actions и прочим Дженкинсам.
Это я к тому, что DevOps - это просто инструмент. Им можно пользоваться правильно/хорошо, а можно неправильно/плохо. Последнее можно делать со злым умыслом, а можно "по незнанке"/небрежению
Есть девопс инженер, а есть хитрожопый девопс инженер, как и во многих других областях. Программист может два дня делать задачу, которую он же может сделать за 2 часа, если понимает, что его не проконтролируют. Как-то так
Вы никогда не задумывались, что net effect от всех действий DevOps - это перенос файлов из одного места в другое (иногда в несколько мест). То есть команда copy (cp) с рядом условий?
Не в контексте, но справедливости ради все эти ваши компьютеры/интернеты/AI/IT это в 99.99% случаев перекладывание информации из одного места/регистра в другое. То есть команда copy (cp) с рядом условий. Фишка именно в условиях.
Понимаю автора, как посыл в сторону староверов язычников (традиционных скрипт кодеров) заглянуть в будущее и внести свой вклад к приближению с настоящим, строить новые DevOps инструменты...?
Сам факт наличия скриптов сборки и развертывания - огромный плюс. А версионирование их - логично, как и версионирование кода. Использование инструментария и машинерии, естественно, зависит от проекта. Где-то и пару строк на bash/powershell достаточно черкануть, и то в качестве документации потомкам, где-то разумно докер образы собирать и разворачивать. Где-то вообще достаточно rsync на боевой сервер (не сильно боевой, конечно, тем не менее бывает и такое). А где-то да, Jenkins агенты спавнятся в облачном кластере кубера, собирают пачки микро сервисов и раскатывают это дело по пачке датацентров. Так что дженкинс, шуршащий в докер контейнере, который крутится в кубера, - не шутка даже ни разу
Новое поколение уже не знает, что можно просто выделить файлы и перетащить мышкой по ФТП - и деплой готов.
Ну ок, еще 1 человек нужен в штат, чтобы поддерживать 1 строку кода, которая открывает порт, через который это приложение увидит свет (все 0 пользователей).
A eсли приложение немного сложнее чем helloworld.php? Если нужно много файлов раскидать на много серверов? А если на некоторых серверах что-то пошло не так?
Можно напилить своих костылей, можно взять готовые;)
>>все 0 пользователей
Для localhost решений не нужон етот ваш девопс, конечно;)
Сейчас реальность такова, что работа нормального (не ряженого) сисадмина в основном заключается в том, чтобы вычистить все эти кластеры и кубернетисы, которые оставили после себя девопсеры и разместить все на 1 сервере, как это было до нашествия.
Я не отрицаю, что у пары процентов проектов действительно есть нужда в репликации, балансе нагрузки, очередях, многопоточности и тп.
работа нормального (не ряженого) сисадмина в основном заключается в том, чтобы вычистить все эти кластеры и кубернетисы
Это задача для системного архитектора. Одмин over-over-qualified детектед. Он наверное и программист заодно, сам всё напишет, и на халявный хостинг по ftp зальет.
Такая картина больше подходит стартапам или небольшим конторам, где нет понимания роли айти. Обычно там каждый приходящий админ переделывает все под себя как ему больше нравится.
Крупные компании с их высоконагруженными сервисами - вершина айсборга, там работает небольшой процент людей. Я же пишу про проекты, которые обрабатывают 0-1000 заказов в день, именно там работает среднестатистический админ.
Лет 6 назад девопсеры окучили весь крупный бизнес и начали продавать свои решения и экспертизу микро- и среднему бизнесу. Продавать и куда-то пропадать. А бизнесу надо как-то дальше работать, это реальная проблема по откату назад.
Ну и вторая проблема, до кучи. Появились толпы "девопсов", которые тупо не знают, как простейшую статическую веб страницу без кубера разместить .
Они это не умеют! И не хотят учиться, для них это видите-ли это "олдскул" и не по феншую.
Они же без докера и простейший софт установить (а тем более сконфигурить) не могут... :-)
Коллеги то вам как мед "неправильные" девопсы попадались. Правильным - без разницы докер это или не докер. А некоторые даже strace иногда расчехляют. То что пришло поколение после курсов (в основном 2000+ года рождения) которые хотят миллионы и ничего не делать и учится тут я с вами согласен. Не раз собеседуя на таких нарывался.
Дело не в том "кто попадался", а в пропагандируемой идеологии - "контейнеры наше все и серебряная пуля". В топике как раз и пытаются объяснить что это в принципе не верно...
Ну ради юмора замерь время сколько ты руками раскатываешь что то сродни пускай Apache NIFI и за сколько подымешь в докер компоузе. Я не спорю что контейнеры - не панацея. Но все таки все забывают что контейнеры это просто быстрый и удобный способ доставки и упаковки приложений. Современный аналог нсиса и далее-далее-далее. Так что утверждение автора как и ваше спорно, хоть от части и не лишено смысла.
А вот "не ради юмора" а для получения максимальной производительности под определенный профиль нагрузки вы сколько будете этот контейнер настраивать? И сколько времени потратите на изучение "тонкостей настройки и особенностей функционирования" всех компонентов данного софта в контейнере?
Так вот время "разворачивания" на фоне всего остального вам будет уже "не интересно"...
Хотя конечно "можно и микроскопом орехи колоть"...
Ну типа микроскопы вот они "под рукой" и недорого, а молоток нужно искать, да и специалисты которые с ним работать умеют не дешевые... :-)
Опять же спорно, большинство контейнеров снабжено хорошей докой, да и докерфайл зачастую хватает почитать. Насчет тонкой настройки - контейнеры не отменяют чтения доки по соответсвующему софту. Принцип х*як х*як в продакшен зависит от специалиста, но никак к применяемой технологии. Будь то вм, iac, контейнеры, ката контейнерс и так далее. Еще раз повторюсь я не сторонник пихания всего в контейнеры, только когда это оправдано. И не сторонник распила монолита, если монолит не реальный Франкенштейн из костылей и велосипедов.
Почему именно php? почему явно указываете, что это именно PHP или Python в 90% случаев? Можно helloword написать на Java (Kotlin и Scala не в счёт, это подвиды языка Java) или на C++ (Go и Rust соответственно новые подвиды С++ более современные), или на C#. Просто явное указание на php говорит что как бы человек знает только php.
Если говорить про java devops'a он может быть один и пригодиться при развитии тех же скриптов и проектов.
Потому что php стало нарицательным, жаль все забывают почему именно - php был простым как палка и в своё время позволял справляться с задачами где другие не вывозили по производительности, но именно из-за простоты и распространённости бизнес начал пытаться экономить... в итоге сотни тысяч обезьян такую фигню на нём пишут... Вообщем то что на языке удобнее и быстрее всего написать фигню - не делает его плохим, но об этом уже не упоминают.
PHP в свое время просто показал людям кратчайший путь, как встраивать динамические компоненты в статический HTML (типа как VueJS сейчас) и так первым среди конкурентов принес пользу бизнесу.
Скоро современные NOCODE или LOWCODE приложения тоже обзаведутся своим PHP.
мб это тоже сыграло свою роль в популярности, но основа все таки другая. аргументы:
1) chatGPT
PHP стал популярным благодаря своей простоте в изучении и использовании, богатой документации и огромному сообществу разработчиков. Он также легко интегрируется с различными базами данных, позволяет быстро написать динамические сайты и открывает много возможностей для создания веб‑приложений. Кроме того, PHP является бесплатным и доступным на большинстве серверов, что делает его привлекательным выбором для многих веб‑разработчиков
2) куча ссылок с первой страницы и все об одном - легко посадить любого новичка и получить хоть какой-то результат:
Одной из главных причин, почему PHP лидирует в веб-разработке, является его простота и доступность
Его считают плохим те, кто на нём не пишет, либо, кто столкнулся с некачественным исполнением поставленной задачи. Те разработчики, кто не стремятся изучить документацию языка и не следуют рекомендациям, пишут на нём действительно очень слабо. Это бросает тень на всё сообщество. PHP — язык с низким порогом вхождения. Это одновременно сильная и слабая его сторона
ПС. забавно будет если это тоже заминусуют за "неконструктивное общение" =)
Хм а вы «старое поколение» до сих пор считаете ftp безопасным протоколом?
И счастлив, что «это» ушло в прошлое.
Прекрасно, когда одна строчка лежит в гитхабе/etc, по коммиту запускается action, который выполняет скрипт копирования файла на сервер. И секреты лежат в этом гитхабе. И все самодокументированно.
Для понимания девопса написана книга: "Проект феникс". В которой очень хорошо описывается как DevOps влияет на бизнес.
Если от чего-то есть реальная польза, для объяснения этого не надо писать целые книги.
Взять, например, хирургию. Да?
Ну если вам других источников не хватило :)
Было бы не надо, если бы люди имели мнение только в тех вопросах, в которых они компетентны. В реальности мы почти ничего не знаем, но имеем мнение по любым вопросам от геополитики до вирусологии, а иногда даже транслируем его в этих ваших энторнетах, вызывая такие вот срачи)
Прочитал, впечатлился.
Пойду удалю свои IaC, буду накликивать инфрастуктуру руками, ведь инфра в облаке должна хранить тепло человеческих рук, а не бездушность пайплайна. Ну и что, что это занимает в 10 раз больше времени и повышает вероятность ошибки.
Еще думаю поудалять весь ci/cd - он нарушает принцип kiss и вносит сложность в доставку. Пусть собирают руками, это не сложно и занимает всего день, вместо 10 мин, зато имеет встроенный тимбилдинг.
Ну и вишенкой думаю, будет отказ от облаков. Оттуда все эти девопсы полезли фантомные. А нужен возврат к корням - серверу под столом секретарши и админам в свитерах.
Да, и весь код хранится на фтп на этом сервере у секретарши. Гит это сложно и непонятно
Не забудь удалить вебхуки, если, вдруг, у тебя не так как у автора, и не надо ручками запускать Дженкинс джобу после гит пуша. Ну или в gitlab/github удалить триггеры, пускай все запускается только ручками, не зависимо какой бранч. Автор либо действительно сталкивался с плохой культурой ДевОпса (по его примеру это более вероятно), либо просто не нравится что кто-то тоже зарабатывает не 100 рублей в час. (Сталкивался и с таким)....
Проблема DevOps в их силе.
Если всё делать руками, человек рано или поздно устанет от рутины, начнет ныть "сложнаа", однажды потеряет бдительность, допустит ошибку, от которой всё сломается и рухнет, и это вынуждает следовать KISS.
DevOps позволяет относительно легко автоматизировать очень сложные операции. Да, один раз придется попыхтеть, написать скрипт, настроить робота, но потом он работает безотказно. Поэтому про KISS и не вспоминают, пока не нужно будет что-то поменять, или не придет другой DevOps.
И работает у нас робот, и горя не знаем... Но вот беда, вдруг сломался, а разобраться почему (у него же 100 составных частей и в каждой мы не разбираемся) не получается... А все стоит без него... :-)
Робот хотя бы вот он, поддается ремонту и реверсу, а вот если админ внезапно пропадет?
Ну для нормальной документации по процессам ремонт и реверс инжиниринг обычно не требуется.... :-)
Ну да, ну да, поддаётся...
Столкнулся недавно с падением пайплайна там где не ждали — на команде agt-get update, которая начала ругаться на некорректные подписи. И всё, никакой возможности отладить: локально всё работает, а единственная доступная информация об образе системы на котором apt-get update падает — это строка CACHED в логах docker build.
И всё, этот образ никак из недр докера не вытащить.
А если войти интерактивно в консоль?
В какую консоль? Чтобы войти в консоль интерактивно, нужен контейнер. Чтобы запустить контейнер, нужен образ. А образ хранится где-то внутри кеша Buildkit (даже не в общем хранилище образов докера!), всё что о нём известно — это строка "CACHED" в логах сборки.
Поддерживаю. Всё что может быть понято неправильно именно так и будет понято. И это сейчас везде.
Люблю всем напоминать, и в работе и тут на хабре иногда пишу, что любое изменение архитектуры, добавление функционала должно иметь цель. А масштаб измений должен быть соизмерим с пользой которую он приносит.
DevOps, в данном контексте, это обычная разработка. Если в какой-то компании выбираются продукты и решения несоизмеримые с масштабом задач, это не проблема DevOps, это проблема реализации. Конкретной компании, людей которые купились на красивые слова или решают свои задачи, усложняя жизнь другим.
Для сферического коня в вакууме, у версионирования скриптов из примера статьи должен быть заказчик, RFC в котором принято решение делать так. Впрочем, это плохой пример, потому что любой код больше пары строк должен быть в гите или аналоге и версионироваться. А вот какая часть инфраструктуры должна быть как код, это уже спорный вопрос, ответ зависит в первую очередь от ее размера и скорости измений. Когда это 2 железных сервера БД, которые обновляются раз в 3 года, это одно. А когда тысячи ВМ/контейнеров, где за день меняются сотни из них, всё что перечислено в статье не оверхед, этого уже не достаточно.
Все что нужно знать о DevOps в моей картине мира.
Вот я условный разраб низшего звена который пишет пет-проект. Я знаю, что есть Docker-Compose и мне его достаточно.
А когда будет недостаточно, то мой проект уже принесет достаточно денего чтоб нанять хорошего Devs-Op менеджера. А пока эти времена не наступили, мне хватает просто Docker-а.
И вы будете абсолютно правы! Во-первых, используя докер, во-вторых нанимая дев-опс инженера, правда, а не менеджера, вам же делать что-то надо, правильно?
Только обычно девопс нужен тогда, когда уже есть команда а то и несколько и которым нужны площадки для разработки и тестирования. По опыту могу сказать, что при должном планировании и квалификации девопс инжененера вы получите:
- решение задач SRE - устойчивость продакшн системы, мониторинг-алертинг (работающие!), снижение затрат на инфрастуктуру и развертывание, улучшение качества услуг клиентам
- решение задач разработки - добавление новых сервисов быстрее и безболезненнее, минимизирован человеческий фактор, ваши сервера переходят из pet-режима (любимец, не трогать иначе боль!) в cattle (жги ломай все равно новые за минуты поднимаются а вся инфа в gitops и видны все изменения).
- ваши инженеры повышают техуровень, осваивая к8с и новые тулзы, с удовольствием тыкают на трейсы и залипают на графики. Они видят результаты работы и изменений и это мотивирует! Нет рутины и у них, они делают свою работу а не ждут пока что-то там настроится и починится из-за случайно перепутанного порядка деплоя.
в итоге это позволяет и вам сосредоточиться на разработке, на вашем бизнесе, а не заниматься инфраструктурой и саппортом инженеров.
И это не сферический в вакууме пример, это реальная история, наблюдаемая мной лично и не один раз.
А так можно и кабелеукладчиком в квартире ночник подключать, я думаю, тоже будешь немного разочарован.
Проюлемы этого вашего девопс начались в основном именно тогда, когда его назвали девопсом и стали трубить о нем на каждом углу, поскольку начался массовый девопс ради девопса.
Где просто спецов переименовали по новому, или где все выстраивают квк нужно , а не как модно, там обычно все нормально. А вот где начинаются менедженерские метания в стиле "у всех девопс, а у нас его нет, срочно выстраиваем девопс", там обычно и начинается кошмар. Предельный случай - выстраивание структуры девопса в микроконторе с пллутора разработчиками, пилящими программку для локального использования.
DevOps изначально - это просто культура взаимодействия разрабов и админов.
Появление devops-инженеров - это следствие этого процесса. Синергия девов и опсов родила множество инструментов и подходов для решения задач автоматизии процессов под нагрузкой. И это стало слишком сложным, что потребовало нового класса специалистов.
Для микроконторы есть свои инструменты, а для крупных - свои. Мне повезло: не видел менеджеров, которые думают об инфре. Кмк, вы говорите больше о низкой квалификации подбирающих и внедряющих те или иные инструменты.
Nero Burning ROM в своё время из-за этого загнулась)
а что там? Не пользовался и статей не вижу чёт, но в 2000х была на слуху
Загнулась она не от переусложненности. Необходимость прожигать CD как то пропала. Да и бесплатные аналоги подьехали.
Возможно, менеджеры как раз и затем сделали суперкомбайн - нет необходимости прожигать диски - пусть хоть плеер будет.
А меня одного в анамнезе смущает Chef? Он тут даже в тэгах. Я повидал немало всякого, но чтобы что-то в облаках Chef-ом создавали, ещё ни разу.
Вы не совсем верно понимаете, изначально задумка была в том, что DevOps это не позиция, а роль одного из разработчиков.
Соответственно, yaml-пайплайны и деплой-скрипты под разные окружения готовит тот, кто лучше всего знает, как запускать своё ПО.
Простой пример, классические админы до сих пор не поняли ценность Service Discovery, продолжают просить мануалы по конфигурированию конкретных инстансов. Ну а раз не поняли, значит не нужно. Очень "классическая" позиция.
Не было такой задумки. DevOps - это было про культуру взаимодействия девов и опсов с определенной общей ответственностью за то, что все работает.
К сожалению, сейчас мало об этом говорят.
Но, да - девы описывают запуск (например в виде докерфайла и прочим), опсы помогают с требованиями к приложению, формой и форматом конфигурации и т.д. Работают сообща на всякими метриками/логами/трейсингами.
Совсем недавно оформил некоторые мысли по этому поводу в небольшую заметку. Определенно, есть смысловое пересечение с этой статьёй.
Прочел.Отвечу - вы забываете что инженер владеющий практиками DevOps тоже умеет писать код и даже порою не на одном ЯП, но почему то все упорно толкают их именно в сторону ops.
У них сейчас по части Ops работы очень много, по крайней мере часто слышал жалобы, что на вакансии никто не откликается, один работает за троих, а для разработки все-таки важна постоянная практика, а не только знания как писать код (впрочем эти правила тоже видоизменяются со временем).
Так что этому действительно не придал большого значения. Для написания скриптов различных автоматизаций знаний должно хватать как минимум. Дополнительно закрывать задачи разработки - не встречал такого.
Из моего будничного - давеча написал api утилитку на go для автоматизации получения сетевых доступов. Но есть много и ops задач, согласен. Все больше сталкиваюсь с тем что разработка умеет писать код, но не понимает как работает определенная бд и архитектурные вопросы в целом. Мой любимый пример очереди в redis. Так что коллеги тут монета ребром как говорится.
Я бы сказал Devops в его текущем состоянии.
Это про как делать не надо пример.
Нормальный проект начинает с MVP для проверки идеи, а по ее подтвержении развивают итеративно.
Сделай хорошо, а не круто.
И многие не понимают, что разработка ПО это такое же производство, тот же завод ,а процесс разработки - внесение изменений, доставки - конвеер. И на разных участках непрерывность поддерживают разные люди.
Можно плитку из цемента самостоятельно делать штучно, а можно тысячами и разные варианты - и ресурсы и проблемы будут разные.
Аналогичную картину наблюдаю в QA. Уже лет 10 в разных компаниях, где я работал, все пытаются запилить автоматическое тестирование клиентских приложений, выделяют кучу ресурсов а толку 0. Все критические ошибки находят в итоге пользователи продакшена, т.к. некому было тестировать, все тестировщики занимались написанием автотестов или починкой устаревших.
Видимо автор столкнулся с тем что в большой компании для простой задачи его заставляют делать так как правильно, а не так как быстро. По тексту статьи гиперболизированное сравнение которое можно провести во многих сферах.
Для меня кстати до сих пор немного загадка, что конкретно делают девопсы.
Настроить CI/CD - этим всю жизнь девелоперы занимались. Если приложение нормально написанно, то достаточно в пайплайне тупо дёрнуть пару граделовских тасок с каким нибудь профилем.
Есть предположение, что девопсы настраивают кубернетис и подключают сторонние сервисы, а остальным занимаются админы. Подправьте, кто больше в теме.
Иногда встречаются целые команды которые вообще непонятно чем занимаются.
Так у нас в одной конторе была midleware team. С нашей точки зрения, единственная задача которых была это: задеплоить war-ник и прислать логи. Зачем для этого нужна дополнительная команда - до сих пор не понятно.
Справедливости ради девелоперы тоже часто любят усложнять, особенно неопытные.
Настроить CI/CD - этим всю жизнь девелоперы занимались. Если приложение нормально написанно, то достаточно в пайплайне тупо дёрнуть пару граделовских тасок с каким нибудь профилем.
Когда у вас большой проект, настолько большой, что настройка CI/CD и инфраструктуры под нее занимает полный рабочий день, девелопер уже не сможет этим заниматься параллельно с разработкой.
Ну и под сложные или просто большие проекты появились свои инструменты оркестрации, управления, мониторинга. Ближе всех тут сисадмины, которые собственно и переходят в девопсы.
Таким образом DevOPS - это культура и методология работы в проекте
DevOps инженер - сисадмин, который работает там, где идет разработка продукта.
То есть одна из специализаций сисадминов.
Есть же сетевой админ - сисадмин, который работает там, где занимаются коммуникациями (провайдер мобильной, проводной или телефонной и др. связи)
Есть сисадмин какого-нить крупного провайдера, где предоставляют виртуалки или облачные ресурсы, там кластера, датацентры, железки, виртуализация.
Есть сисадмин широкого профиля - который работает там, где надо управлять инфраструктурой не IT компаний. Всякие активдиректории, файловые шары, управление пользователями, возможно виртуальные десктопы, подключение офисов, корпоративные ноутбуки/антивирусы, etc
Под этим всем есть еще сисадмины, которые не ушли в специализацию, ибо конкретная позиция не требует много знаний. Хотя там тоже может быть уход аутсорс, когда контора берет на себя обслуживание какой-нибудь компании и предоставляет своих профессиональных админов, которые быстро настраивают надежные и простые (возможно шаблонные) архитектуры.
Про эникейщиков я не говорю.
Когда у вас большой проект, настолько большой, что настройка CI/CD и инфраструктуры под нее занимает полный рабочий день, девелопер уже не сможет этим заниматься параллельно с разработкой.
Вот это для меня всегда было загадкой. Это до какого состояния надо довести проект чтобы настройка CI занимала целый день. Тут не девопсы нужны, тут нужен Геракл, чтобы вычистить Авдиевы конюшни.
Я видел большие и сложные проекты, но так чтобы надо было целый день настраивать - это нечто.
Если речь идёт про настройку окружения (скажем сервисы для функционального тестирования), то это должно быть автоматизировано и этим занимаются девелоперы (ибо они должны поднимать так же и дев окружение)
«день» для разраба, обмазавшись документацией и стековерфлоу. Пара часов девопсу.
Вот это для меня всегда было загадкой. Это до какого состояния надо довести проект чтобы настройка CI занимала целый день.
Ну вот проект, 10 команд, свыше ста компонентов.
Постоянно появляются новые, декомиссятся старые.
Появляются задачи вроде обновить операционку. Надо согласовать со всеми командами совместимость, обновить дев, проверить что не попадало, обновить уат, обновить прод, для этого возможно нужны дополнительные разрешения, аппрувалы, ибо каждый енвайрнмент - это сотни машин.
Вот уже на неделю-две работы.
Вот это для меня всегда было загадкой. Это до какого состояния надо довести проект чтобы настройка CI занимала целый день.
Да тут и доводить не надо, недавно я настраивал Sentry на очень небольшом проекте — полтора дня заняло. Просто потому что использовался свой раннер для гитлаба с docker executor на умирающем под нагрузкой HDD, из-за чего каждый тестовый запуск пайплайна обходился в полчаса.
Не, ну можно и так, как автор написал, конечно.
Однако, нормальный девопс-специалист деньги экономит в основном не тем, что автоматизирует деплой. А тем, например, что знает как и где разместить приложение, чтобы это было дешевле. Какие стораджи юзать. Или, например, вот у AWS можно поднять свой контейнер с каким-нить RabbitMQ, а можно использовать готовый SQS, где первый миллион запросов в месяц бесплатно, а потом тупо дешево. Получается дешевле, чем кролика поднимать, но приложение должно это поддерживать. Или опять-таки, девелопер взял бы и арендовал выделенный сервак (потому что это головой понятно). А девопс говорит, а давайте возьмем Spot Instance у AWS - будет дешевле. Но тогда всё приложение должно быть stateless, во-первых, и уметь выключаться за 2 минуты (кажется), во-вторых.
Ну и вот это вот всё. Про умение писать конфиги, которые умеют быстро масштабировать систему в обе стороны это и так понятно.
Ну вот так и появляются кривые, неподдерживаемые решения. Задачей выбора сервиса должны занимать либо девелопер, либо архитектор, но уж ни в ком случае не девопс.
но приложение должно это поддерживать
Что должно поддерживать приложение - решает команда разработки на основании запросов пользователей, аналитиков и продуктового менеджера. Подобно тому как они решают эти вопросы на основании запросов клиентов, админы удовлетворяют запросы разработчиков. Клиент, как известно, всегда прав.
Девопс, в общем случае, не обладает необходимым уровнем компетенции чтобы вникать в тонкости применимости того или иного месаджинга в конкретном приложении. Тупое сравнение в лоб - это типичный поверхностный подход. А как там с транзакционостью? Надёжностью? Поддержанием очерёдности? Устранением дупликатов? Хватит ли производительности? Как бакапить? На эти вопросы может ответить только команда, разрабатывающая приложение. Она ещё и исходный код, при необходимости, изучит и необходимые измерения произведёт. Никакой девопс, прочитавший умную статью на хабре, архитектурные решения в продукте принимать не может и не должен.
Кроме того, использование AWS налагает дополнительные сложности как организационного так и технического плана.
Технически это усложняет локальное тестирование. Организационные - это вендор лок. За создание вендор локов вообще надо увольнять ИМХО.
Я вот кстати вообще сомневаюсь, что использование сервисов облака может быть дешевле опенсурсного софта. Непонятно, за счёт чего может быть доступна эта дешевизна. Не будет же Амазон себе в убыток работать? Тут явно какой-просчёт и что-то неучтено. Я как-то сравнивал стоимость транскодинга, используя сервисы амазона и используя ffmpeg внутри EC2. Свой транскодинг выходил в 10 раз дешевле
Я вот кстати вообще сомневаюсь, что использование сервисов облака может быть дешевле опенсурсного софта. Непонятно, за счёт чего может быть доступна эта дешевизна. Не будет же Амазон себе в убыток работать?
В целом с комментом согласен, но тут явное пердергивание — бизнес это не игра с нулевой суммой.
А где я написал, что девопс что-то решает? Задача девопса быть в курсе того, что бывает и предлагать команде и бизнесу решение. А поскольку любое решение имеет ограничения их тоже надо озвучить и узнать подходит оно команде или нет.
Сравнивать по цене без SLA не корректно. Например, если тот же условный Amazon гарантирует доступность в 4 девятки после запятой, то расскажите мне пожалуйста как вы такую доступность будете самостоятельно реализовывать? Я не говорю, что это невозможно сделать самостоятельно. Я про то, что с большой вероятностью ваше решение не будет прям-таки сильно дешевле Амазоновского при схожих SLA - физику не обманешь.
Задача девопса быть в курсе того, что бывает и предлагать команде и бизнесу решение
С этим можно согласиться. Правда это касается любой профессии. Если тестер или аналитик что-то предложит, то почему нет?
гарантирует доступность в 4 девятки после запятой
Практика показывает, что эти цифры и яйца выеденного не стоят.
Не знаю сколько знаков Mongo гарантировала, но внезапно её сервисы стали для некоторых пользователей просто недоступны. Включают ли эти дутые цифры банкротство компании? 20-икратный рост цен? Просроченную кредитку? Уничтожение подводного кабеля?
Ещё раз повторюсь: крупная компания и уж тем более госконтора не может себе позволить себе зависеть от одного вендора. Это неоправданный риск, учитывая, что никакой технической необходимости в подобной зависимости нет. Даже если мы пишем на дот-нете.
Что касается доступности, основное положение теории надёжность - надёжность обеспечивается дублированием и современные разработчики прекрасно осведомлены с такими вещами как дублирование, репликация, консенсус и пр.. Если будет поставлена задача, то будет и решение.
Вы слишком драматизируете эти сложности ) Гораздо большие проблемы для девелоперов представляет легаси код и расплывчатые требования, а вовсе не чётко определённые технические требования
Осталось понять еще что гарантируется за эти 4 девятки, уж точно не работа ваших клиентских сервисов... А если ваши клиентские сервисы гарантируют (по разным причинам не связанным с инфраструктурой Амазон) работу не 4 девятки а только одну к примеру, вы уверены что вам нужно с других сервисов требовать (и платить им за) 4 девятки?
Если девопс это автоматзация - непонятно, почему это нужно делать каждый день. Пришел, настроил - ушел. Через полгода задачи бизнеса сменились - еще раз пришел.
А если каждый день - это какое-то подмастерье программиста, для решения побочных задач.
В небольших проектах так и бывает.
Начинается проект с нуля, под него разворачиваются ресурсы. С ростом проекта обрастают всякими штуками, мониторинг, деплой. Потом проект более-менее устоялся, вышел в продакшен, пару раз обновился - все, девопс уходит в другой проект, или параллельно ведет несколько.
Но есть проекты, которые постоянно меняются, постоянно куча задач. Постоянно все куда-то мигрирует, легаси декомссится, новое появляется и все в рамках одного проекта. Там и команда девопсов может много лет работать и работать.
А оно и не нужно. Если у вас один стабильный проект. В этом случае можно нанять человека на контракт на год которы за этот год построит процессы и автоматизирует.
Проблемы начинаются когда ваша компания развивается, пробует новые проекты, меняет код и т.д. Тут нужно для каждого стартапа внутри компании автоматизировать что то новое. А так делают почти что все компании которые генерируют прибыль. Потому что деньги надо куда то вкладывать.
Девопс это жэ не человек а культура. Статья тупо против автоматизации по ходу.
Что-то в этом есть. В принципе в программировании это уже давно тенденция, когда простые вещи делают сложно. Тут вина не инструментов, а тех, кто эти инструменты так использует. Почему бы не освоить бюджет по переписыванию монолита на микросервисы, пофиксать старые проблемы и огрести кучу новых. Нанять девопсов что б заменили простейший пайплайн в дженкинсе на что-то более современное, версионное, автоматическое и очень крутое. Отгрести еще кучу проблем и соответственно попросить новый бюджет, который тоже будет потрачен на свистелки-перделки, которые потом потребуют своего бюджета на доработки и поддержку. И когда уже кажется, что вот наконец все устаканилось, то приходит новый девопс/архитектор/менеджер и говорит "'это все старое г%вно мамонта, так уже никто не работает, надо переделать. К тому же знаю я тут один фреймворк/технологию/тулу"... Ну и круговорот бюджета запускается по новой. В конце концов, кто-то же должен использовать этот миллион новых тулов, языков, паттернов и новых решений, которые растут как грибы после дождя.
Так что продолжая аналогию автора с calc.exe, программа потихоньку переходит на блокчейн, работает в многопоточном распределенном бигдата кластере с ML алгоритмами и поддержкой сферических коней в вакууме. Ничело личного, просто бизнес.
У человека написавшего эту статью явно нету понимания для чего DevOps вообще нужен и как строятся CI/CD процессы. Другое дело опыт компаний, в которые приходят типа DevOps инженеры окончившие быстрые курсы и приносят свои костыли, тогда получается не разворотливый франкинштейн.
так блт
эээ это что ещё за антиреклама?) только я собираюсь (уже который год)) вкатиться в девопс и тут такое статья мнение, как дальше жить теперь), вы же понемаити какой охват на хабре, сейчас куча людей прочитает ето и всех девоПСОВ на мороз отправят, хотя всё равно весна уже)
бизнес готов платить за такой процесс, потому что таким образом программист отделяется от интеллектуальной собственности, невозможно предъявить права на то, что обслуживается 10 людьми с черными ящиками на каждом слое. если бы разработчики торговых алгоритмов знали насколько просто устроена платформа торговли, они бы все были ИП
А торговый алгоритм всегда приносит прибыль? Вот я что то сомневаюсь что АЛГОРИТМ пусть даже в более чем половины случаев + спред (разница) и коммисия брокеру + деньги за перевод денег. То есть в общем случае число правильных сделок при примерно одинаковых покупках, должно быть более 65%, а то и 70%. Но у меня есть ощущение что рынок не на столько сложен как его рисуют. Оптимальная стратегия для новичка это следовать за успешными трейдерами, просто копировать их стиль и делать так же. Так допустим следовать за большинством не следует, но и следовать за теми у кого сотни миллиардов глупо. Ну то есть в моменте это приносит прибыль, но у кого десятки и сотни млрд долларов они просто не торгуют на бирже, а вкладываются в какой нибудь индекс, зарабатывая 5 - 8% в год (!). Для простого трейдера этой суммы прибыли не хватит даже на месяц. Представьте, нужно накопить 10 тысяч долларов, это уже не просто, что бы потом что, зарабатывать 5% в месяц, то есть 500 долларов? На них не прожить. То есть сумма должна быть в 10 раз выше, либо риск должен быть выше в 10 раз. Оптимально чтобы как то жить нужна сумма 50 тысяч долларов и чуть выше риск 8-10% в месяц, и то это небольшие деньги 4-5 тысяч долларов, можно тихонько торговать. Но это как с инвестиционными квартирами) предлагают вложить 10 млн рублей, что бы зарабатывать в месяц 40 тысяч руб))) ну это смешно, что бы заработать 10 млн. нужно что было жильё у родственников, а если сам столько заработал то не будешь сдавать. Вот у меня нет своей квартиры, и таких молодых людей до 35 лет довольно много. кто ипотеку взял, а кто снимает, кто у родственников. А всякие блогеры ну в меру уважаемые, но они в 100% случаев эти деньги либо с имеющегося бизнеса, либо родственники дали, либо по наследству полученное жильё.
8-10% в месяц
Мавроди передаёт привет.
это немного можно по 30-40% в месяц но риски слить всё намного выше, да и жить придётся трейдинг +плечи использовать. 8-10% это всего 1 раз поймать рост или падение если играть на понижение. 2-3 сделки в месяц. Остальное время можно посветить работе или отдыху. Я о другом даже для того что бы жить на 5-10% в месяц нужен довольно большой капитал. И тем более уделять несколько часов в неделю на него нужно будет.
Присоединяюсь, пожалуй это единственная видимая польза от всего этого. Устранение диктаторов инфраструктуры и кодовой базы. Только если есть мутная вода поверх мутной воды, бизнес может развиваться, а молодежь имеет шанс запрыгнуть в профессию с 0 багажа опыта после курсов.
Всё с DevOps в порядке. Не нужно путать макро- и микроуровень, и всё станет на свои места.
Если у Вас управление релизным циклом существует только в виде "нескольких команд cp", а в качестве среды выполнения крутится десяток (ну пускай даже сотня) виртуалок, то оно вам и в самом деле не надо.
Большая часть аргументов в статье сводится к тому, что Ваш продукт не очень большой, и оверхеды, вносимые собственными девопсами - существенны. Но это ведь касается не только девопсов - даже обычный найм программистов не масштабирует их производительность линейно при совместной работе над одной задачей.
Но вот есть, например, такой комплайнс - в определенном продукте нужно создавать изолированные среды для каждого заказчика, мультитенант не катит. Говоря проще - провайжнить продукт тысячами отдельных инстансов, и менеджить всё это. Скриптами будем делать, или возьмем всё же готовое?
Опять же, деливери - это всегда контейнеры. Нравится, не нравится - ну вот такое оно, сегодняшнее настоящее. Если привыкли править на проде - будет мешаться, а если выстроены процессы быстрой доставки в этот самый прод - будет помогать обеспечивать SLA.
TL;DR: как и любой другой инструмент, DevOps методологию нужно оценивать не для абстрактного, а конкретно для вашего проекта. Экстраполировать же свои проекты на других - плохое хобби.
Почему это "всегда контейнеры"?
Есть всякая AWS хрень которая сама по себе похожее...
С другой стороны есть высоконгруженные SQL сервера. Голимое железо на максималках, где даже разница SSD и NMVe существенна, там точно сиквель не в докере)
Я думаю, что он там не только в докере, а ещё и в виртуалке поверх этого самого докера.
Уже прошли те времена, когда виртуализация\контейнеризация оказывала какое-то существенное влияние на производительность. У докера оверхеда практически нет, у виртуализации - в пределах погрешности (а применительно к БД иногда и напротив выигрыш бывает - потому что кеширование дисковых операций работает чуть интереснее, чем на bare metal). В любом случае, жертвовать 1% производительности ради потери управляемости - нонсенс, железо стоит значительно дешевле времени людей, которые его обслуживают.
Просто гляньте, как на крупных платформах (GCP, Azure, AWS) работает Managed SQL.
Скажите "нет" смузи и цветным носкам. Хотя бы на время. И подумайте, как в production будет работать always on c availability groups и теснейшей завязкой на кластер windows
Пысы. Я нашел что это делают, но оцените длину инструкции!!! Во про это я и говорю!!!
Так вы сравниваете тёплое с мягким. MSSQL в продакшне - это а) ни разу не мейнстрим, market share MSSQL сервера около 15% всего (пруф), б) MS не планирует развивать это направление, упор идёт на cloud-native \ managed SQL, а onprem не растёт (с учетом инфляции - читай, падает - пруф).
А разгадка проста - нищий рынок труда. Средняя зарплата системного администратора в мск - 52 тысячи рублей (пруф), это меньше 5 долларов в час. И это в 8(!) раз меньше, чем в США (пруф), на чей рынок, собственно, и целятся крупные клауд провайдеры. Так что в среднем по больнице в РФ выгоднее нанять 10 администраторов, а в США - одного девопса и managed сервисы. Это, кстати, более-менее бьётся с моим собственным опытом.
И справедливости ради - не всё так однозначно (с). Низкая стоимость фонда оплаты труда разработчиков в РФ позволяет делать недорогие и качественные сервисы. Но формально это экстенсивный путь развития, со всеми свойственными ему ограничениями.
Ну во первых, я MSSQL server DBA. И мест, где он стоит - очень много. Да, сейчас в России идёт переток на Постгре по понятным причинам, но это процесс займет годы.
Что касается зарплат... Я тут в HH нашел зарплату в 30 тыс р.) Но это ничего не значит. Я в Питере не знаю никого, кто бы получал меньше 200к (исключая джуниоров)
И ещё, в России из AWS всех выгнали, а местные облака ещё в стадии младенчества. Ещё есть китайские облака, но они тоже на порядок отстают от AWS
Так что onprem наше все
Ну Ваш персональный опыт ничего не говорит о рынке труда в целом. А он - очень разный, и работают там люди с совершенно разными скиллами. С тем же успехом я могу рассказывать, что не знаю в bay area никого с доходом меньше, чем 300к в год - к рынку труда в США это будет примерно такое же отношение иметь.
Так что за неимением других цифр придётся верить этим.
В целом уход на онпрем - это движение против шерсти индустрии, сознательное упрощение. С некоторых пор такая история много где происходит - в автомобильной промышленности, например. Наращивание технологического отставания - это крайне грустная история, и она аукнется далеко за пределами ИТ-сферы в целом.
Лучшая статья от автора, несмотря на моё к нему неоднозначное отношение.
Госпади. Размышление одного старого программиста о написании одного суперпростого приложения. Ну нет, в таком случае тебе ничего не нужно.
DevOps и весь современный веб это про команды, где человек может поработать месяц или неделю. И ты потом как отследишь логику и последовательность вносимых изменений. Вкинули говна на вентилятор. На хабре новый пиарщик или бизнесмодель создания контента совсем прогнила ?
Все эти подходы - для стандартизации процесса разработки и уменьшения возможности накосячить. Ты попробуй отдай своё почти готовое приложение на выходные разработчику уровня джуна, чтобы он закончил. Без версионирования, дошбордов, версий билдов, тестов и так далее. И доступ ему ещё рутовый на сервера кластера и в само облако...
Рассуждение либо джуна на мелких проектах либо админа, без maidset разработчика. Тут уже много накидали правильного в комментариях, добавлю еще
Мы получаем версионирование скриптов! Круто же! Никого не интересует, удобно ли это, важно, что это круто и хитро...
Если процессы поставлены правильно, то это будет удобно. Кроме того, чаще всего это продиктовано не тем, что это "круто и хитро", а тем, что это позволяет отслеживать историю изменений, что в свою очередь является требованием безопастности.
Буквально пару месяцев назад сопровождал подписание контракта с клиентом на поставку софта. Крупный банк, контракт на пару миллионов $ каждый год. Так вот версионирование всего, что возможно, включая все скрипты CICD, было одним из обязательных требований.
Версионирование скриптов делается помещением их в git (или svn). Загружать из курлом — это закат солнца вручную.
Я тоже обратил на это внимание и не понял, почему для скриптов нужен Nexus. Но похоже там гита тоже нет.
Загружать из курлом — это закат солнца вручную.
для хранилищ артифактов это нормальное дело. Что для Nexus, что для того же jFrog Artifactory и гугловского Artifact Registry. Они не предназначены для совместное работы или детальной истории изменений, как VC системы - они для хранения билженных версий релизов. И вы можете подтягивать эти артифакты как зависимости к другим проектам. Поэтому нет надобности в git (или svn).
Но почему там именно требуется хранить скрипты в хранилище артифактов - надо смотреть требования, артифакты и в целом их процессы.
Девопс - это механик вашей машины. Вам не нужно следить за уровнем масла, давлениям шины, чтобы ездить (кодить) на ней, даже если вы можете это делать сами. Да, не каждый проект это формула-1 и требует пит-стоп за 10 секунд, но это не означает, что девопс бесполезны. Разница в сложности ремонта жигулей и океанского лайнера как раз и рождает подобную работу.
Не знал что такое DevOps, теперь знаю. Мне нравиться. Всегда так делаю, в этом и интерес, иначе превращается в РАБоту
Типичная "ошибка выжевшего". Ну и про DevOps тут нет ни слова, кроме, как самого слова, которое тут не очень уместно.
У нас девопсы занимались написанием деплоев, поддержкой и рефакторингом инфры на проде и стейдже, смягчением последствий при всяких падениях и ддосах.
Ну, можно, конечно, самому этим заниматься - но зачем? Почем это раковая опухоль?
А иметь разраба, который будет еще знать, как от ддоса отгородиться с помощью возможностей какой-нибудь железяки, которая перед инфрой стоит - это что тогда?
Ну вот лично у меня очень много пессимизма насчёт девопс в целом. Думаю, тенденция ближайшие лет 5 будет в том, что разработчики сами станут строить инфраструктурные решения. Появится для этого какое-нибудь новое название или нет, это уже дело десятое.
Качество девопс-решений, которые я видел за последние годы, в целом довольно низкое. Речи о каком-либо self-service для разработчиков зачастую не идёт. И я вижу причину в том, что девопсы - это чаще всего бывшие опсы, которые в прошлом делали всякую автоматизацию для себя и своих коллег, совершенно не заботясь о 1) надёжности ("сам починю за две секунды если что") и 2) когнитивных затрат на интеграцию ("что я, сам свои скрипты не разберу что ли").
И в итоге получается хуже чем стандартный clickops - например, разрабы сидят и недоумевают, почему нельзя просто взять и обновить какую-нибудь графану - спулил новый контейнер и заменил старый, не? - а оказывается, что для этого надо сделать 5 коммитов в 3 репозитория, по каждому дождаться "обязательного код-ревью" дежурного девопса, плюс ещё выяснится что всё просто так не заработает и девопс должен подшаманить, и в конечном итоге ещё и упадёт раскаточный пайплайн с ошибкой "неизвестная ошибка, обратитесь к системному администратору".
Только я бы не стал обвинять в этом конкретных девопсов, проблема где-то в сообществе. Существующие готовые решения все имеют какие-то подводные камни, про которые все знают, но вместо решения коллекционируют способы обхода.
Начнём с докера. Это отличное средство для изоляции окружения сборки от внешнего мира, которое прекрасно работает… до тех пор пока вам не требуется что-то из этого окружения. У вас свой репозиторий nuget, npm или кеш пакетов любого дистрибутива linux? Ставьте костыли. Желаете общего решения? Делайте свои базовые образы, со своими пайплайнами для их сборки (не тут ли корень проблемы с графаной?)
Продолжим им же. Есть такая штука как layer cache, которую можно использовать чтобы не загружать пакеты каждый раз. И это работает если все пакеты у вас в одном файле вроде package.json. У вас таких файлов несколько? Ставьте костыли, докер не поддерживает копирование с фильтрацией и сохранением структуры.
Нужны инкрементальные билды, потому что они быстрее? Ставьте костыли.
И это всего лишь один инструмент, костыли нужны каждому.
"Ближайшие лет 5 будет в том, что разработчики сами станут строить инфраструктурные решения." - По опыту говорю что это будет тот еще цирк, костыли и велосипеды. Потому что большинство(не готов утверждать что все, видел разных) современных разработчиков в инфраструктуре , а тем более архитектуре не смыслят ничего. Встречаются либо - мое дело писать код - а вы ops парьтесь как хотите, либо я использую то что знаю, а то что этот инструмент для этого не предназначен - "так исторически сложилось". Так что я в корне с вами не согласен.
очевидно, что проекту "пишем калькулятор" не нужен никакой девопс. А на проекте, где бежит 10 серверов в каком-нибудь облаке - кто ими заниматься будет ? Бэкенд-разраб?
Недавно у нас с разработчиком случился такой разговор. Деплоим его сервис в кубер. Я спрашиваю: «А что у тебя с масштабированием и доступностью?». Ответ «а я думал оно само». Почему-то все забывают что вторая часть названия Ops. Именно нам потом эти все калькуляторы расставлять в правильном порядке, чтобы хватило ресурсов, чтобы была доступность и восстановление в случае сбоя. Статья напомнила, как бухгалтеры жалуются что программисты им портят жизнь, они бы давно на счетах все посчитали без всяких этих сложных 1С.
А сейчас много где такая мешанина. Не, спору нет, некоторые вещи действительно упрощают работу. Та же Jira - отличное средство для управления проектами. А уж гнать на Git вообще грех, особенно если разработка командная. Но в остальном в наше время всё чаще разработка бывает перегружена технологиями. В результате человеку, который только пришёл на проект, порой бывает долго в нём разобраться. Да и вообще приходится тратить вагон времени на постоянное изучение всякого "стильно-модно-молодёжно".
Работать без CI/CD - тоже самое, что работать без гита. Но видимо не все еще прочувствовали удобство работы с ним (к сожалению во многих компаниях прод продолжают обновлять "ручками", и считают, что это нормально).
А перемудрить и запутать можно на любом проекте и с любым стеком технологий.
Отличная статья. Я работаю на стороне внедрения проектов и у меня мнение про DevOps вот примерно такое же.
Внедряете руками и на коленке? очень странно звучит.
Ну я надеюсь, что здесь многие внедряют руками, а не ж*пой :) А по поводу коленок. Вы даже не знаете, чем я занимаюсь и что за проекты внедряю. Поэтому ваш вопрос звучит еще более странно, чем мое согласие с автором статьи.
Поясню к чему вопрос, не для желания кого то задеть и повысить чсв. Я много работаю с вендорами и зачастую с разными внедрениями. И за частую все они страдают одной проблемой - отсутствием автоматизации, что бы позволяло ускорить внедрение. Потому ваше согласие со статьей меня удивляет. Готов выслушать ваше мнение по этому поводу.
Знаешь, большинство требований, они же не девопсами сделаны. Они от родительской корпорации и процесса вливания в неё. То, что они проходят до конечного инженера через девопсов - это особенности распространения политик в конкретной корпорации.
То есть те же требования прогонять код через хранилище артифактов (ух, как меня это бесит) - это требование по фиксированию кода на приложении и воспроизводимости его для прода.
Для дева это, слава богу, не является необходимым.
Да, инфраструктурщикам (нам) тяжело, мы в результате пользуемся бэкдорами чтобы таскать что-то на инстанс. Но это, опять-таки, не хотелка левой пятки девопсов, это требования по безопасности. Клиент требует чтобы доступ к инстансу был аудированный, значит протоколы обычного доступа будут закрывать, причём с самого верха.
Мнение: DevOps — это раковая опухоль