Чтиво на weekend.
Представьте, что вы написали калькулятор, calc.exe. Почему бы не добавить к нему темную тему? Хотя нет, почему тему, пусть будет любое количество тем. Мы их будем хранить в файлах.thm. Важно не запутаться, потому что еще мы хотим настраивать расположение клавиш. Просто переключать вид — простой/научный — это слишком просто. Надо ввести понятие layout. Который хранится в файлах *.lyt.
Так, теперь логично написать редактор layouts, который, разумеется, будет больше первоначального калькулятора. И делать bundles.thm+lyt, и... о да, конечно! Marketplace! Создаем сайт, поиск, free/paid, система обновлений... На чем бы все это писать? Что в этом месяце популярно среди front end?
К этому моменту первоначальная идея о том, что калькулятор нужен для того, чтобы считать, давно забыта. Нас утащила в облака идея ползучего улучшательства.
Конечно, по молодости каждый делал такие ошибки. Но DevOps — это то, что описано выше — только масштабировано на уровень фирмы.
Git, Nexus, Jenkins, Ansible, Octopus, Jira... Я как то писал jobs для Jenkins. Они вызывали скрипты на PowerShell. Но DevOps говорят — нет, это слишком просто! Пусть в самом начале каждой Jenkins job curl вытягивает с Nexus последнюю версию скриптов, и только потом уже ее выполняет. Мы получаем версионирование скриптов! Круто же! Никого не интересует, удобно ли это, важно, что это круто и хитро... Ну вы поняли.
Правда, все это крутилось на Linux, а отлаживать это можно было только вживую, поэтому при отладке (изменив одну строчку в скрипте) мне приходилось делать git add ., git commit и push, делать merge, потом запускать Jenkins job, которая паблишила это в Nexus, и где-то спустя пять минут ручной работы я мог проверить новую версию скрипта. Но мне не привыкать - я работал и на перфокартах c одним прогоном в день.
Но вы никогда не задумывались, что DevOps существуют для того, чтобы облегчать жизнь, а не усложнять? Что если появились инструкции на 40 пунктов и 50 yaml файлов - то значит, что что-то пошло не так? У знакомой три девелопера и три человека в отделе DevOps. Ребята, а вы точно экономите деньги?
Вы никогда не задумывались, что net effect от всех действий DevOps — это перенос файлов из одного места в другое (иногда в несколько мест). То есть команда copy (cp) с рядом условий?
Извините, я забыл про облака. Там Terraform, Chef, файлы их конфигураций, а раз файлы, то снова версионность, Git, Nexus, Jenkins... А вы думали, сколько новому человеку во всю эту кухню вникать? Сорри, я забыл, что это не плохо, а наоборот, хорошо, и называется job security.
Во всем этом обилии технологий забыт главный принцип... KISS... Мне кажетcя, современный DevOps превратился в вещь для себя, самосбывающееся пророчество, которое потребляет все больше и больше ресурсов, раскручиваясь как спираль...
P.S. Наверное, Jenkins надо поместить в Docker а сверху шлифануть Kubernetes...
Комментарии (418)
gleb_l
00.00.0000 00:00+14А прокачка софтскилов, талент-менеджмент, коучинг, оне-ту-оне и корпоративный психолог?
Degibenz
00.00.0000 00:00+85Человек, который написал это – нет понимания что такое DevOps. Просто какой-то поток мыслей
ivankudryavtsev
00.00.0000 00:00+60Скажу, что человек написал чем может стать DevOps, но не чем обязано быть.
rukhi7
00.00.0000 00:00+6Возьмите для примера Жиру. У нас например в проекте даже поле описания тикета редко кто заполняет. То есть из всего разнообразия полей, из 100-тен полей которыми обвешан тикет реально-системно используются 4 или 5 штук (!) остальные хранят какие то епизодические случайные артефакты, по сути мусор!!!
Неужели это не понятно что нормальный живой человек не в состоянии ориентироваться, а тем более поддерживать в актуальном состоянии сотни полей, он их просто будет игнорировать, так зачем же создавать такое богатство?
Надо еще учесть что этот нормальный человек кроме Жиры еще должен код писать в каком то своем енвайронменте на каком то своем языке, Жира вроде бы должна облегчать ему работу, а все идет к тому что ты должен в первую очередь быть специалистом по Жире, наплевать на твою основную предметную область.
Как говорил один юморист:
Как страшно жить! Она не Красная шапочка, а Дура!
От себя добавлю: Статья-Огонь!
saboteur_kiev
00.00.0000 00:00+4Кто-то в джира веде вообще записи для себя, кому-то просто достаточно титла. У кого-то настроена интеграция с битбакетом и дженкинсом, чтобы в тикете автоматом появлялся список билдов и коммитов связанных с этой джирой, и это позволяет автоматом генерировать change notes, например.
Jira - инструмент для менеджеров и тимлидов, чтобы оценивать занятость сотрудников и генерироваьт различные репорты. Степень наполнения в JIRA зависит сугубо от требования менеджеров и тимлидов, а не от девопсов или разработчиков.
ivankudryavtsev
00.00.0000 00:00+2Все зависит от индустрии и практик в ней принятых. Если вам инструмент не подходит, это не значит, что он никому не подходит. Вполне в каком-нибудь DoD могут все 100 полей заполнить и еще 200 кастомных настроить.
FirsofMaxim
00.00.0000 00:00-2Я понял, что с Jira что-то не так, когда узнал, что есть спецы по ней - "жировики" (я бы через "ы" писал).
venanen
00.00.0000 00:00+61Думаю, это было написано не про теорию, а как оно бывает на самом деле. И его полностью поддерживаю - войти в айти у всех на слуху, и довольно часто бывает, что человек без понятия, что он должен делать. А дальше это берет другой и еще сильнее извращает, и что мы имеем на выходе? 7 аналитиков на 3 разработчика, превращение совещаний в цирк с викторинами, всякие а-ля покеры, а ТЗ никто составить не в состоянии. А потом еще на хабре толпа статей в стиле "Как заставить разработчика хорошо кушать" или "как создать атмосферу любви и дружбы в команде с помощью *любое действие*".
auresio
00.00.0000 00:00+2А дальше это берет другой и еще сильнее извращает, и что мы имеем на
выходе? 7 аналитиков на 3 разработчика, превращение совещаний в цирк с
викторинами, всякие а-ля покеры, а ТЗ никто составить не в состоянии.Я не плачу, просто жиза в глаз попала. Сидишь на созвоне и думаешь, как вас таких безграмотных наняли то...а потом понимаешь что после курсов все.
mc2
00.00.0000 00:00-5После курсов? Иногда, даже казалось бы, опытные люди, которые уже лет 10 на плюсах пишут, приходят и спрашивают что такое EINTR в recvfrom. А ты сидишь, смотришь на них, и думаешь, как мрт покажет снимок их мозга..
iroln
00.00.0000 00:00+9Как связаны опыт программирования на C++ и сокеты?
И почему с их мозгом что-то не так? Потому что они не знают что-то, что известно вам или потому что пришли с вопросом вместо того, чтобы загуглить?
mc2
00.00.0000 00:00+3Да, сожалею что не уточнил пару деталей:
1) они пишут и поддерживают клиент-сервер приложение уже 10+ лет
2) сетевое взаимодействие в данном приложении было написано именно данным человеком.
Мне лично было бы стыдно не знать как работает то, что я пишу...
rukhi7
00.00.0000 00:00Как связаны опыт программирования на C++ и сокеты?
Интересный вопрос! С такими вопросами можно дойти до вопроса:
Как связаны опыт программирования на C++ и С (в стандартной библиотеке которого определены сокеты).
Конечно если на С++ писать совершенно не касаясь сетевого взаимодействия, то наверно так можно спросить. Но я не верю что на С++ можно писать никогда не касаясь сетевого взаимодействия.
wunderwaffel
00.00.0000 00:00Привет. Я пишу на с++ профессионально 5 лет. У нас свой 3D движок. OpenGL, Vulkan. И никакого сетевого взаимодействия.
А как у вас с линейной алгеброй, графическими API и теорией света? Не могу себе представить разработчика на с++не знакомого с графическими API.
rukhi7
00.00.0000 00:00Не могу себе представить разработчика на с++не знакомого с графическими API.
Вот именно! Потому что не бывает (практически) компьютеров без монитора, также как без сетевого подключения.
Но 5 лет не такой уж большой срок. К тому же учитывая что статья у вас висит от 2013 года выходит что С++ для вас не основной язык (может даже в таких случаях уместно сказать не родной :). Это все объясняет.
wunderwaffel
00.00.0000 00:00Статья у меня висит со времён студенчества. С++ основной.
Я к тому, что есть разработчики не трогавшие сеть, как и есть не трогавшие Direct X.
rukhi7
00.00.0000 00:00-1У меня вот такая аналогия по этому поводу родилась:
Те кто занимаются Direct X при этом не знают что такое сокеты, это как те кто занимаются квантовой механникой не зная законов Ньютона.
Я ни на что не претендую, но мне так кажется.
mayorovp
00.00.0000 00:00Аналогия некорректная. "Добраться" до квантмеха не зная законов Ньютона и правда затруднительно, но вот заниматься 3D графикой не касаясь сетевого стека можно без проблем.
fancy-apps
00.00.0000 00:00+4да, а потому что во главе контор теперь такие же смузи-менеджеры, поддерживающие любые смузи-инициативы! В итоге все такие классные современные, а на продукт без слез не взглянешь. Я адвайзю много проектов/стартапов и такое везде, к сожалению
JArik
00.00.0000 00:00+1Он не смог написать тесты для своего плагина, потом у него не было дев. окружения для быстрого тестирования. Каждый раз комитил, пушил в гит(интересно может еще и с пулл реквестами? :D), закачивал в Nexus - и думает вот мне тут жизнь усложнили, девопс же это про написал скриптик и в прод.
alemiks
00.00.0000 00:00+10мне приходилось
ничего не понял, вы работали в фирме, в которой применялся девопс, но сами не были девопсом? Как вы оказались на сервере тогда? Если вы и сами девопс, почему бы не предложить улучшения и сделать круто?
У знакомой три девелопера и три человека в отделе DevOps
что это значит? В модели devops нет чисто девелоперов, оно и называется develop + operations. Знакомая просто переименовала админов в девопсы?
Tzimie Автор
00.00.0000 00:00Я был DBA и делал Jenkins jobs для middle junior DBA из другого отдела, в духе выполним этот скрипт на сервере и пришлем результат почтой. Это позволяло им не запрашивать доступ к серверам ради повторяющихся кверей
Таким образом я просто использовал Jenkins не совсем по назначению
saboteur_kiev
00.00.0000 00:00+5То есть не совсем по назначению. Дженкинс это тулза для автоматизации, то что ее начали называть CI тулзой, это произошло уже позже и это не есть ее главное назначение. Просто массовое.
thunderspb
00.00.0000 00:00Ну вообще если копнуть глубже, то женкинс просто шедулер. Набор скриптов, выполняемых последовательно, по какому либо событию. ВременнОму или коммиту. Технически можно реализовать на на условном systemd. Просто без вебморды.
saboteur_kiev
00.00.0000 00:00+2Вот не надо упрощать до просто шедулера.
Это оркестратор, с поддержкой агентов, с внутренним скриптингом, который позволяет оркестрировать эти агенты, с поддержкой внутренних библиотек и плагинов, с хранилищем секретов, с сегрегацией доступа, с поддержкой киллерфичи, которая в других подобных инструментов была внедрена гораздо позже и хуже - я про Jenkinsfile
Да собственно многие вебморду дженкинса могут и не видеть, и отлично им пользоваться.Tzimie Автор
00.00.0000 00:00Главное что он выполняется на другом сервере под другими правами. Поэтому человек может выполнить скрипт, на который у него нет прав в обычной жизни
saboteur_kiev
00.00.0000 00:00выполнять что-то на другом сервере под другими правами вообще задача CD инструмента, если мы говорим про разработку.
Либо оркестратор, если мы говорим про администрирование (chef/ansible/etc), но в этом случае "другие права" обычно подразумевается рут
Дженкинс все-таки больше инструмент разработчика, и изначально был сделан для управления и автоматизации сборок
Ndochp
00.00.0000 00:00А если мы говорим не про разработку а про жизнь отдела поддержки?
Ну там:
сделать бэкап на проде,
обновить новой версией,
прогнать обслуживание SQL (индексы/статистики)
сделать бэкап еще раз,
развернуть второй бэкап на новом месте (и проверили что бэкап живой, и на этом самом месте первая/вторая линия поддержки будут воспроизводить проблемы пользователей от имени этих пользователей и в актуальном окружении)Ну или короткое подмножество — бэкап прода среди дня, развернуть для аналитика поддержки актуальную версию (это когда за день успели столько натворить, что на ночной копии не воспроизведешь)
Естественно ни у аналитиков ни у поддержки почти никаких прав на проде, чисто аудиторский профиль.
Кажется дженкинс как многосерверный шедулер должен хорошо зайти.Tzimie Автор
00.00.0000 00:00Я как раз этим и занимался)
Ndochp
00.00.0000 00:00А я в процессе изучения. Наши админы сказали "а хрен его знает, как так сделать" и пока навтыкали шедулеров на каждом сервере на каждый шаг. (с запасом по времени) вот только мы уже отожрали окно с 23-00 до 08-00, а пересечения раз-два в неделю случаются, когда один не успел, второй стартовал и споткнулся.
Что, дженкинс хорошо должен зайти, или стоит в другое место посмотреть?
iig
00.00.0000 00:00пересечения раз-два в неделю случаются, когда один не успел, второй стартовал и споткнулся
jenkins уметь синхронизация своих job'ов.
saboteur_kiev
00.00.0000 00:00В моем текущем проекте мы используем отдельные продукты для CI и CD. Вдобавок админ дженкинса получается имеет доступ вообще ко всему без всякой сегрегации доступа.
Ndochp
00.00.0000 00:00Вдобавок админ дженкинса получается имеет доступ вообще ко всему без всякой сегрегации доступа.
С одной стороны это напрягает, а с другой, разве нельзя развести через типа прокси и преднастроенные процедуры? Ну, например, дженкинс агент не выполняет произвольный алгоритм на скуле, а пинает скуль агента, который запускает заранее настроенную процедуру, которая работает с повышенными правами.
saboteur_kiev
00.00.0000 00:00+2Тогда проще просто поднять два независимых дженкинса. Настроить один для девелоперских задач, второй для продакшен саппорта. И не мешать их в одну кучу, а то мало ли что где.
Опять таки, девелоперский дженкинс может обрастать плагинами, инструментами и так далее, мало ли где возникнет необходимость или уязвимость.
Для продакшен саппорта предпочитаем иметь как минимум отдельный инстанс, который статичный, с минимальными изменениями.
else2
00.00.0000 00:00+3Вы опровергаете название своей статьи. Вывод почему-то не делаете. Не девопс - опухоль, а безопасники и бизнес-процессы! Почему бы не сделать программу или микросервис, выгружающий данные без jenkins? Это же программирование - вперед! Чтобы понять смысл девопс, прочитайте (хотя бы по-диагонали) книгу «проект Феникс». Девопс нужен, чтобы прогеры могли спокойно прогать, но не лезли шаловливыми ручками в базы, не лажали релизы, не крашили обновлениями продакшн. Чтобы в командах был стабильный процесс, а не согласно положению звезд и настроению жены тимлида.
iig
00.00.0000 00:00Почему бы не сделать программу или микросервис, выгружающий данные без jenkins?
Но зачем делать самодельный аналог jenkins? Можно взять готовый.
domix32
00.00.0000 00:00+2Чтобы не быть как "раковые девопсы", очевидно. Только тру программисты, только версионирование в папочках.
mayorovp
00.00.0000 00:00Потому что нужен совсем не аналог jenkins. Уже на этапе когда скрипты для запуска загружаются из Nexus при помощи curl что-то пошло не так.
PsyHaSTe
00.00.0000 00:00+2что это значит? В модели devops нет чисто девелоперов, оно и называется develop + operations. Знакомая просто переименовала админов в девопсы?
В смысле нету? А как назвать человека который умеет в терраформы/женкинсы/кубернетесы/питон/… но не умеет в скажем джву и раст? А с ним в команде работает человек который умеет в расты, джавы, хаскели, но в гробу видал yml, его получается нанимать ошибка?
else2
00.00.0000 00:00-1Ошибка - это то, что девопсу дают примерно пять минут на выполнение любой задачи. Типа так: «эй боец, сбегай сделай по-быстрому». А языков и диалектов вашего программирования хренова гора. И у каждого прогера свое понимание бэст-практис. А сеньеров не переспорить, к примеру, доказывая, что джава профили нужно выбросить. Девопс бы не против обучиться - постоянно это делает, но прогеры, высокомерно ничего не объясняют - на созвонах же. А тратить снова пять лет в универе, изучая как мэйн-класс объявить и какие зависимости подключить для хелоуворда в ваших ${язык программирования} , который все выкинут как delphi через X-лет не хочется.
CrashLogger
00.00.0000 00:00Ну если вам нужно пять лет в универе для того, чтобы разобраться с тем, что можно нагуглить за полчаса - у меня для вас плохие новости
mc2
00.00.0000 00:00+7Гугление не заменяет опыт. Очень часто те, которые гуглят решение, слабо представляют себе бест практики применения инструмента. Живой пример: джава программист пишет для деплоя скрипт на shell. Он нагуглил какие то операции, и оно даже работает. Однако, спустя время, передав уже готовый деплоя в другие руки, оказывается что скрипт работает очень неадекватно: аргументы нужно задавать только в определенной последовательности, скрипт не расчитан на внезапное прерывание его работы, а так же скрипт требует ручного ввода информации для деплоя (привет человеческому фактору, во всех проблемах). Но это частности. Когда я заглянул в этот скрипт, я пришел в "восторг", т.к. скрипт выглядел набором функций на любую операцию: к примеру стоп/старт/рестарт jvm - это все отдельные функции, несмотря на то, что управляющая "платформа" понимает обращение к данной jvm с параметрами start/stop/restart.
Итого: гугление не заменяет внимательного изучения инструментов, а дьявол прячется в мелочах.
thunderspb
00.00.0000 00:00А если умеет и в жаву и в руби и в си и еще чегото? Тот же голанг. И, да, не синьорский уровень, но, думаю на джуна/мидла вполне можно.
Женкинс пайпланы это груви, тут и ява не далеко. Питон скорее как консольные тулы или просто лень ручками стандартизированные файлы конвертировать.
PsyHaSTe
00.00.0000 00:00-1Если умеет то это не та ситуация которую я рассматриваю. Представьте себе я говорю вот приходит джун без опыта и ..., а в ответ возражение "а вдруг он с опытом приходит??". Ну если с опытом, то уже другая ситуация, её рассматривать не очень интересно)
Я конечно неправильно могу понимать, но для меня девопс это помесь админа и разраба. В том плане, что админ это обычно на мышки драйверы установить. вирусов там вычистить и вот это все, ну сеть может настроить. А девопс — это дженкинсы, пайплайны. вся вот эта муть. Примерно то же, что админство, но с использованием as a code инструментов, ну и шире, что ли. При этом это не полноценный разработчик — ему позволительно не знать про О большое, про структуры данных, как там гц работает, как правильно профилировать приложение,… Он знает питон/го/… на уровне "могу написать скрипт 30 строк", и все. Программист же наоборот — умеет во все эти навыки, но его знания инфраструктуры заканчивается на "умею написать мультистейдж докерфайл который грамотно кэширует слои " и "не храню стейт в приложении". А как оно там деплоится, по каким хттпсам приходит, сколько инстансов где развернуто — слов таких не знает. Просто пишет себе код в подвале и пушит в мастер фиксы, которые автоматически инструментарием настроенным девопсом попадают куда нужно.
Для меня это ключевой способ работы, есть выделенные люди со своей зоной ответственности и они этим занимаются. Совмещать эти две вещи имхо то же что совмещать фронтенд и бекенд разработку — хорошим не заканчивается, пусть этим занимаются выделенные специалисты.
BugM
00.00.0000 00:00+1Вы забываете про админов у которых под контролем сотни/тысячи серверов. Они были до ваших дженкинсов и будут и после них. И автоматизация управления этим хозяйством была до всей этой моды и останется и после нее.
Инструменты могут как угодно меняться, а админы никуда не денутся. Ну может обзовут их еще как-то. Кому какое дело? Лишь бы деньги платили.
cadmi
00.00.0000 00:00+3админ это обычно на мышки драйверы установить. вирусов там вычистить и вот это все, ну сеть может настроить
Вот в этом последние лет 25 и была одна из основны проблем русскоязычного IT - с каких-то щей "админами" стали называть IT technicians, хотя это две совершенно разные профессии :)
В итоге в какой-то момент "админом" стало быть так же "стыдно", как и "тыжпрограммистом" :)
1CUnlimited
00.00.0000 00:00+1Поддерживаю! Все что можно было уложить в один софт рассыпано по куче инструментов. Стирается грань между Вавилоном и Свободой выбора, к чему это привело всем известно
fpinger
00.00.0000 00:00+7Один софт выполняющий много задач какие-то из них будет выполнять не идеально. Одна задача - одна программа.
BugM
00.00.0000 00:00+5Вы код в чем пишете и отлаживаете?
aleksandy
00.00.0000 00:00+1В одном инструменте для разработки программ.
saboteur_kiev
00.00.0000 00:00Ну вот есть софт file and archive manager, можно манаджить файлы и архивы. Очень разнообразно.
izogfif
00.00.0000 00:00+2В одном инструменте для разработки программ.
... который представляет собой текстовый редактор с кучей плагинов.
fpinger
00.00.0000 00:00Я использую для этого не одну программу. И даже IDE используют другие программы: линтеры, git и т.д.
Ilusha
00.00.0000 00:00+20devops сейчас - это попытка множеством инструментов разной степени универсальности реализовать потребности бизнеса, прогнозируя его изменяя в будущем на основе коллективного опыта.
А потребности бизнеса просты: должно работать 365/24/7. С учетом роста экстенсивного и интенсивного как продукта, так и аудитории.
Странно видеть в одном посте сочетание методологии «х..к-х..к и в продакшн» с нападками на фронт, у которого тройка фреймворков не меняется уже 10 лет.
devops, кстати, помогает следовать принципам KISS разработчикам/архитекторам: разделяет сложность через микросервисы, например.
А сложность. Она из накопленного индустрией комплексный опыта.
===
По моему опыту у большинства в среднем сегменте примерно одинаковая инфраструктура. GitHub/gitlab с их ci/cd, выкладка на сервера, препрод, dev-среда с бранчами, бд.
Почему нет универсальных решений с минимальными телодвижениями? Почему так дорого?
vvpoloskin
00.00.0000 00:00+1А потребности бизнеса просты: должно работать 365/24/7
Но ведь это не про devops? Это же про других ребят. И эвердьюпойс это только одна из потребностей.Ilusha
00.00.0000 00:00+3в т.ч. и про devops. Архитектура инфры должна уметь работать в пики, быть устойчивой к ddos, устойчивой к херовым релизам от разрабов. Всякие мониторинги, алертинги, трейсинги и т.д.
365/24/7 - это идеальная цель. Которая стоит определенных денег. Инженеры devops - часть решения.
else2
00.00.0000 00:00+1Опыт 6 лет. Мониторинг не помогает не продолбить дефицит места на дисках, айноды. Не помогает с плохими sql, с не назначенными или заниженными java-хипами. Не помогает недопустить краша ноды. Алертинги - это на пол дня удовольствия тимлида - потом письма отправляются в спам. Будят все равно «клиенты». Трейсинги… типа посмотреть, где сделали плохо уже после того, как выкатили? (А дев, а стейдж?) Вот настоящих автотестов не пробовал. Они бы не давали перевести код между стейджами! То есть девопс их результат не увидит, а программист исправит ошибку сразу. Как откомментил выше - половина проблем идет от безопасников. Вторая половина проблем - от бедности. Пример: нужен кластер кубера(цефа, pgsql, elk итд). Устойчивый. Что делает руководство? Читает бэст практис, мануал. Там написано, к примеру: «минимальное количество нод устойчивого кластера =3». Сколько нод покупают? Правильно, 3. Это будет устойчиво? Нет! Потому что авария одной ноды переводит систему в аварийный режим, и что-то перестает работать. Сколько надо нод? Я бы сказал - больше пяти, и даже 7. Отдельных, одинаковых, ЖИРНЫХ! Это покупает время на отработку отказов. Обычно же как: лишить премии ответственного за обслуживание системы - легко, а себя любимого за жадность в покупке железа - никогда!
Ilusha
00.00.0000 00:00+1Так ведь никто и не говорил про серебряную пулю. Как я уже где-то рядом DevOps - это про культуру совместной работы и совместной ответственности dev’ов и ops’ов.
Вами описанные проблемы как раз и вытекают из плохой развитости коммуникаций. Это нормально. Но дальше мы пойдем в основы agile: процессы нужно постоянно развивать. А это сложная задача.
Не знаю, кто у Вас руководство, почему оно самостоятельно читает гайды, а не слушает квалифицированных специалистов.
WASD1
00.00.0000 00:00Вот настоящих автотестов не пробовал. Они бы не давали перевести код между стейджами!
А чем ваши автотесты, которые вы используете (вы же их используете) не настоящие?
Почему вы часто пропускаете ошибки? Покрытие? Невозможность ингетрационных? Частая выкатка новой функциональности?
arheops
00.00.0000 00:00+3Мне почему-то помогает со всем этим мониторинг.
Место еще только начинает заканчиваться — кто-то уже смотрит в чем дело. Айноды на моей памяти аварийно не заканчивалися уже лет 15.
Плохие SQL увеличивают нагрузку базы данных, срабатывает мониторинг на нетипичную нагрузку и все чинится.
Нормального девопса не будят клиенты ;)
Если у вас есть шанс падения всех нод из-за недостатка общей мощности, вы пишите письмо начальству и показываете его при этом случае. Да, девопс — про предугадывание проблем, а не их хотфикс.
И да, если у вас нет стейджа — вы тоже пишите письмо. Начальство им, конечно, подотреться — но у вас будет история, что вы это писали.
a-postx
00.00.0000 00:00+1Если вас "будят всё равно клиенты", то у вас точно что-то не так с мониторингом. Правильно приготовленная мониторинговая триада позволяет решать 95% проблем в проактивном ключе, вопрос только в выделении ресурсов на это решение. Понятно что бывают редкие пограничные случаи, которые побеспокоят клиента, но это скорее исключения.
shornikov
00.00.0000 00:00+4Потребность бизнеса - бабки приносить. Если это приносит деньги, но вообще не работает - это нормально. А девопс - это потребность программистов. А то и вовсе "шашечки".
domix32
00.00.0000 00:00Кажется это пропорционально размеру бизнеса и задействованных в нём разработчиков. Кому-то хватит и гитхуков, а кому-то надо восемь команд из пяти направлений для двух продуктов менеджить. Где-то автоматизация будет оверкилом, где-то - жесткая необходимость. И тут тоже не сильно принципиально насколько рабочий продукт, если оно в таком виде приносит деньги.
Ilusha
00.00.0000 00:00+1Вы считаете аргументом переход на другой уровень абстракции? Ну, такое.
Не программисты выстраивают инфру. Это делают ops‘ы. Они ей и управляют. Задачи devops - это инфраструктурные задачи на стыке кода и инфры. С перехлестом ответственности.
Когда devops-задач много или их уровень сложности выше квалификации devs появляются devops-инженеры.
Раньте были админы и разрабы. Мир двинулся вперед. Появились всякие хайлоады. Стало сложно.
Бросаться в шизофренические крайности, когда «не работает, но деньги приносит» - это вообще о чем? Зачем?
MadL1me
00.00.0000 00:00+37Мне кажется, вам скорее сильно не повезло. Вы правы, DevOps должны упрощать процессы, забирать у разработчиков всю нудятину по настройке конфигов и деплою их приложения конечным юзерам.
У меня просто была обратная ситуация - во всех местах где я работал, были очень хорошо отлаженны DevOps процессы. Переусложнения не было, проблемы решались по мере их появления, становилось реально проще - мне как разработчику, надо было всего запушить код - и оно само развертывается где нужно, как нужно, на каких нужно серверах, с какими нужно конфигами, интеграцями и пр.
Согласен с вами в том плане, что веб разработка в последнее время сильно переусложняется новыми абстрактными технологиями, но проблема которую вы описали в статье, является проблемой не DevOps, а плохо настроенных процессов компании.Ilusha
00.00.0000 00:00А какими технологиями веб-разработка переусложняется? За последние 10 лет можем видеть только одно: ничего революционно не меняется. Три фреймворка эволюционируют. TS вытеснил конкурентов (чему я рад).
Сейчас в вебе тишь да гладь. Растет только сложность самих интерфейсов.
blind_oracle
00.00.0000 00:00Ну, если не смотреть никуда кроме вуе, реакта и ангуляра - то да. А так какое то добро постоянно велосипедят. То, что оно не сдвигает гегемонов с олимпа - это да, наверное хорошо, значит они достигли эквилибриума плюс минус.
vassabi
00.00.0000 00:00-7DevOps должны упрощать процессы, забирать у разработчиков всю нудятину по настройке конфигов и деплою их приложения конечным юзерам.
главное чтобы это забирание не стало принудительным, и в итоге "работать будем за тебя мы, и кушать за тебя будем мы" (с)
Vladekk
00.00.0000 00:00Согласен. Когда есть девопс и он все настроил, жизнь легче. У нас девопс обучила нас соединятся к кластеру с помощью к9s и стало вообще норм.
SiGGthror
00.00.0000 00:00-3Если не секрет - а научила она вас чтобы что?
carebellum
00.00.0000 00:00+2предположу, что подебажить что-нить изнутри деплоймента
else2
00.00.0000 00:00Кажется, что не с того конца ребята едят колбасу, если дебажат в кластере…
sgjurano
00.00.0000 00:00Всё норм, это один из самых лучших способов понять что происходит с приложением, зачастую это позволяет понять проблему значительно быстрее.
Релиз может быть довольно долгим делом, а для решения проблемы их нужно не меньше двух — включить отладочный режим и добавить метрики/логи в подозрительных местах, а затем выкатить фикс (хорошо ещё если с первого раза получится).
Права нужно ограничивать, тут не спорю, но подход safety first имеет свою цену — очень сильно затрудняется отладка и существенно ухудшаются time to market и developer experience.
SiGGthror
00.00.0000 00:00Схвачу еще минусов, но все-таки задам этот вопрос: а что вы такого хотите найти в кластере, что поможет вам дебажить?
sgjurano
00.00.0000 00:00+1Переменные окружения, сетевая связность, права на файловой системе, число запущенных процессов-потоков и их структура, разделение потребления ресурсов между ними, strace, tcpdump, flame-graph — это из практики.
Отлаживать чёрный ящик всегда сложнее чем белый.
thunderspb
00.00.0000 00:00Если я правильно понял, то научила поднимать кубер локально, что, в целом полезно для понимания как их приложение будет вести себя в виде пода.
isden
00.00.0000 00:00+4забирать у разработчиков всю нудятину по настройке конфигов и деплою их приложения конечным юзерам.
Кмк, когда разработчик не знает/не умеет деплой софта который пишет — это ну такое, не надо так. От этого могут вылезти очень неприятные баги, которые ни девопсы, ни разработчик (в сабжевом кейсе) понять и починить не могут.
izogfif
00.00.0000 00:00+13Кмк, когда разработчик не знает/не умеет деплой софта который пишет — это ну такое, не надо так.
Мне кажется, есть какой-то баланс. Ну не должен заклинатель CSS и повелитель async/await'ов разбираться в horizontal pod autoscaling и настройке request limit'ов в конфигах nginx. Есть же делегация полномочий. Это и с программированием так же: вам предоставляют API, вы его используете. Если оказывается, что на той стороне, где API реализовано, есть какие-то затыки / баги / неоптимизированность, то вам не должно быть нужно плясать с бубном и вставлять sleep'ы или throttler'ы в нужных местах, чтобы на той стороне не сдох какой-то обработчик, который вы случайно за'DDoS'или своими запросами.
isden
00.00.0000 00:00разбираться в horizontal pod autoscaling и настройке request limit'ов в конфигах nginx.
Нет, но должен понимать, в каком окружении работает софт и как с ним взаимодействует. Ну и неплохо бы знать/уметь как минимум как задеплоить тестовый инстанс (для разработки/тестирования).
izogfif
00.00.0000 00:00+1задеплоить тестовый инстанс
Если это частая операция, то ее следует автоматизировать. И предоставить разработчику доступ к API создания instance'а. В сложных системах для создания тестового инстанса нужно выполнить 100500 действий, многие из которых требуют высоких привилегий (создание инстансов / namespace'ов / ролей в AWS и т.п.).
isden
00.00.0000 00:00А может и не частая, и для неё не нужно 100500 действий.
Универсальный ответ мы тут не найдем.
Мой поинт в том, чтодолжен понимать, в каком окружении работает софт и как с ним взаимодействует
Margot_ire
00.00.0000 00:00+4Правильно, должен понимать. Для этого devops готовит окружения схожие с теми в которых ПО будет запускаться у заказчиков. И кроме ночных сборок на автомате даёт разработчикам инструменты для самостоятельного деплоя (проверить что-то перед тем как отдавать в тест). И тут функция devops в том чтобы одновременно обеспечить повторяемую среду запуски и защитить эту среду от непреднамеренной порчи разработчиком максимально не ущемляя разработчика в возможностях.
По крайней мере я придерживаюсь этого в своей практике.
Когда же разработчики разворачивали всё сами это было болью тестирования. Среды разные, настройки везде непойми какие и баги которые могут ввести в тупик. И я не к тому, что разработчики такие сякие и нельзя им позволять настраивать среды, просто одинаково хорошо разработчик не научится и разрабатывать и поддерживать инфраструктуру в кондиции. Те же разработчики поделены на фронтенд и бэкенд, а универсалов не так уж много.
isden
00.00.0000 00:00просто одинаково хорошо разработчик не научится и разрабатывать и поддерживать инфраструктуру в кондиции
Ему и не нужно поддерживать инфраструктуру. Ему нужно понимать что где и как работает и как софт который он пишет со всем этим взаимодействует.
Еще неплохо уметь развернуть тестовую среду у себя локально, но это уже так, мои тараканы (насмотрелся всякого).arheops
00.00.0000 00:00Тут изучаешь всю эту кухню 20+ лет, имеешь MS образование — и все равно местами ну совсем не понимаешь, откуда затык.
Да, разработчик тоже может это сделать. Но откуда он возьмет время на изучения этого всего хотя бы в половину так же хорошо, как DevOps?isden
00.00.0000 00:00Ему и не нужно поддерживать инфраструктуру. Ему нужно понимать что где и как работает и как софт который он пишет со всем этим взаимодействует.
иначе
могут вылезти очень неприятные баги, которые ни девопсы, ни разработчик (в сабжевом кейсе) понять и починить не могут
else2
00.00.0000 00:00+1Не надо так. Это плохие процессы. Инстанс нужно создавать быстро, из любого положения, и чтобы это мог сделать каждый вновь-нанятый разработчик. Иначе теряется кайф разработки, а разработчик получает з/п за ожидание согласования доступов.
izogfif
00.00.0000 00:00+1чтобы это мог сделать каждый вновь-нанятый разработчик
ну то есть то, что я предлагаю:
предоставить разработчику доступ к API создания instance'а
лучше, чем требовать от разработчика
знать/уметь как минимум как задеплоить тестовый инстанс (для разработки/тестирования)
Возможно, здесь под "задеплоить" и я, и isden имеем одно и то же (кнопку нажать / HTTP request с нужным параметром выполнить / скрипт запустить), но я свои комментарии писал исходя из того, что "задеплоить инстанс" это "знать необходимый минимум DevOps-магии и (как минимум) прочитать и понять все скрипты, с помощью которых поднимается и настраивается instance".
Hungryee
00.00.0000 00:00-5Очевидно, вы никогда это в реальности не делали
Во-первых, «тестовый инстанс» запустить - не галочку в списке поставить
Во-вторых, девопс никогда в жизни тебе не позволят сидеть и ковырять то что делают они
saboteur_kiev
00.00.0000 00:00+3Понимаьт что такое существует - обязан. Он же должен планировать архитектуру своего приложения, чтобы оно в таком режиме работать умело.
Не путайте разовую установку и оркестрацию всеми енвайрнментами.
Разработчик не обязан разбираться в настройке и поддержке кластера
Не обязан знать где где PROD NA, PROD EMEA или где DR/COB, REGRESSION
Не обязан ковыряться с бэкапами, деплоем и откатом релиза на кучу компонентов.
но вот развернуть свое приложение, как минимум в выделенном для девелоперов кластере - обязан.
Уметь посмотреть там логи - обязан.
wizard_s
00.00.0000 00:00+1К сожалению, многие разработчики считают иначе, уже надоело биться. И главная проблема - чем больше упрощаешь им жизнь, тем меньше они хотят разбираться, как и на чем их приложение запускается В итоге в пределе доходит до того, что разработчик не знает, что есть логи его же приложения, не понимает, откуда его же приложение берет корневые ssl сертификаты и почему не может в ssl с самоподписанным и т.п. :(. Не нужно доводить все до абсолютизма "разработчик должен писать код и точка, а как его собрать и запустить - не его дело"
PsyHaSTe
00.00.0000 00:00-1И что в этом подходе не так, обьясните пожалуйста? Зачем мне знать каким именно логи. скриптом или ещё чем стдаут попадает в графаны? Какое мне дело до серитфикатов если я запускаю локально на http и в грбу видел всех сертботов и сертификаты вместе взятые?
saboteur_kiev
00.00.0000 00:00+3Так и не важно как логи попадут в графану/кибану или просто в каталог. Важно чтобы разработчик знал где они и мог сам посмотреть.
Про сертификаты - вы удивитесь как много разработчиков не понимает базовых принципов работы сертификатов. А еще берут и хардкодят сертификаты (естетсвенно самосгенеренные по инструкции в гугле) в код, вместо того, чтобы выяснить как это принято делать в проекте, а когда выясняется что их сертификаты не работают, потому что в трастед есть корпоративный CA, опять таки считают себя умнее всех и хардкодят самоподписанное в другое приложение, никого не спрашивая.
Встречал такое.PsyHaSTe
00.00.0000 00:00Так и не важно как логи попадут в графану/кибану или просто в каталог. Важно чтобы разработчик знал где они и мог сам посмотреть.
Ну обычно это сводится к тому, что девопс должен скинуть в чатик или в доке написать "логи смотреть — вот тут мониторинг развернут, заходите пожалуйста по ссылочке (линк)".
Про сертификаты — вы удивитесь как много разработчиков не понимает базовых принципов работы сертификатов. А еще берут и хардкодят сертификаты (естетсвенно самосгенеренные по инструкции в гугле) в код, вместо того, чтобы выяснить как это принято делать в проекте, а когда выясняется что их сертификаты не работают, потому что в трастед есть корпоративный CA, опять таки считают себя умнее всех и хардкодят самоподписанное в другое приложение, никого не спрашивая.
Встречал такое.Ну это странно. Мой подход просто выставить наружу хттп ручки и сказать тем же девопсам "вот это за реверс прокси пожалуйста". Учитывая что никакой программный фреймворк по надежности и количеству фичей не дотягивает до nginx со товарищи то для меня такой подход работает как часы многие годы, и никто пока не жаловался.
domix32
00.00.0000 00:00А вы когда-нибудь пытались сделать деплой софта, чтобы был на винде, линухе / бсд, маке, айосе и андроиде. Ну и в вебе конечно же.
isden
00.00.0000 00:00Фигасе у вас проект, интересно было бы посмотреть на такое.
domix32
00.00.0000 00:00isden
00.00.0000 00:00-1Не то. Я ожидал технических вызовов,
костылейкрасивых технических решений для сборки/деплоя, вот это вот все. А тут компилим исходник на расте (все заморочки уже решены разрабами раста), получаем один бинарник и кучку статики, кладем в один проход. К тому же, ничего нет про андроид/айос.
И для этого нужна команда девопсов за 300кк/наносек?domix32
00.00.0000 00:00Про андроид - вы плохо смотрели. Плюс сама игра относительно простая. Плюс на расте, да. Плюс товарищ джва года всё это дело настраивал .
А теперь возьмите игровую кампанию а ля Плейрикс - пару дефолтных матч3 на двух мобильных системах, на трех платформах социальных сетей, десятке сторов, под каждую по своей интеграции с аналитикой/рекламой. Повезло если на каком-нибудь Unity, но скорее всего какой-нибудь плюсовый движок типа cocos2d или defold. И вы утверждаете, что каждый разраб должен при входе в кампанию разбираться со всем этим зоопарком? Небось ещё сам же протестировать и багов себе же завести. Вот в таком случае и всплывают всякие девопсы, которые отбирают всю головную боль за подготовку деплоев на разные платформы/сторы, разворачивание dev/test окружений, сборочных серваков и прочих дженкинсов, настройку серверов для сбора/обработки аналитики, крашей и прочего. Чтобы всё это дело организовать надо быть либо неспящим суперменом, либо иметь ту самую команду девопсов за 299кк/наносек - получают они обычно поменьше разрабов основного продукта.
isden
00.00.0000 00:00А теперь возьмите игровую кампанию а ля Плейрикс
А вот я и хотел бы посмотреть на что-то такое.
И вы утверждаете, что каждый разраб должен при входе в кампанию разбираться со всем этим зоопарком?
Если разраб непосредственно со всем этим работает — то да, должен быть в курсе как это работает. Можете, конечно, и дальше минусовать, но мое мнение это не изменит. Если разраб не понимает систему, которую сам же и пишет — то он не очень хороший разраб. И я снова повторю — не поддерживать, а понимать что где и как работает и как софт который он пишет со всем этим взаимодействует.
domix32
00.00.0000 00:00А вот я и хотел бы посмотреть на что-то такое.
А что мешает? Устройтесь в любую крупную кампанию. В яндексе помнится жаловались, что нет архитекторов для организации надсистем, например.
Если разраб не понимает систему, которую сам же и пишет — то он не очень хороший разраб
Вот тут есть несколько смешанных понятий - есть продукт, который пишут разработчики, есть девопсы, которые помогают с обработкой кода продукта (сборка, тестирование, деплой), избавляя разработчика от вещей, не связанных с непосредственным функционалом продукта. Сфера деятельности разраба это локальное окружение для разработки и удалённое хранилище кода в местном облаке. Для остального есть девопсы, для которых разраб пишет некоторую доку/скрипт для сборки/поднятия его системы. Что происходит дальше ему знать совершенно не обязательно, если оно ничего не ломает.
isden
00.00.0000 00:00А что мешает? Устройтесь в любую крупную кампанию. В яндексе помнится жаловались, что нет архитекторов для организации надсистем, например.
То, что это не основная моя специализация. Кое-что знаю и умею, конечно. Поэтому и любопытно взглянуть.
есть продукт, который пишут разработчики
Ну продукт же не изолированно в вакууме работает. Эти знания могут повысить эффективность работы софта и уменьшить количество багов.
domix32
00.00.0000 00:00Эти знания могут повысить эффективность работы софта и уменьшить количество багов.
Сильно зависит от софта. Иногда в пределах одного приложения есть куски про которые разные команды особо не знают. Взять тот же гейм дев - есть игровой движок, есть игровые механики, есть UI, есть звуки, есть всякие интеграции-аналитики. По большому счёту большая часть всего этого друг от друга изолирована, если мы говорим за большие проекты. Коммуникация конечно есть между командами так или иначе, но редко это прям до уровня кода доходит. "Мне надо вот это, вот в таком виде - окей, буду слать вот таким способом вот таким механизмом". Как там рисуется UI или каким макаром 3д звук организуется - уже не важно. Особенно если ты сервер пилишь для сетевого взаимодействия клиентов.
thunderspb
00.00.0000 00:00Игры, например) у нас, когдато, игра билдилась на виндовых билдерах, потом автоматом заливалась на иос и андроид.
С софтом такое тоже вполне обыденно. Большинство софта имеет версии под эти платформы. Хотя чтобы из прям одного кода всё это сразу собиралось, в целом, имеет место быть,но зависит от софта скорее, иначе это будет монстроузный проект. Скорее автор коммента умолчал о таких деталях.
isden
00.00.0000 00:00Я хотел посмотреть на какие-то интересные специфические решения для мультиплатформенной сборки и деплоя.
ArchieHabr
00.00.0000 00:00+4Сложные инструменты не появляются просто потому, что Васе Пупкину (или стае Васей Пупкиных) захотелось что-то накодить. Можно смело предположить, что был ряд проблем, которые решать "проще" было сложнее.
Нужно ли применять тот или иной инструмент на каком-то проекте, другой вопрос, качество решения которого зависит от опыта и компетенция девопса.
Разраб тоже может пойти писать REST апи на Си/Раст, потому хочется(в теории), но очевидно что это было бы не рационально при наличии Питона/Го под рукой (в текущих реалиях)
domix32
00.00.0000 00:00Зависит от реалий. Яндекс и одноклассники писали REST на плюсах не забавы ради, хотя PHP в то время "сиял" всеми оттенками красного.
DVegasa
00.00.0000 00:00+1инструменты не появляются просто потому, что Васе Пупкину (или стае Васей Пупкиных) захотелось что-то накодить
А по-моему это как раз таки одна из причин. Помимо resume-driven разработки, может быть просто интересно узнать технологию. А может от незнания, что можно иначе, делали с каким-то новым сложным инструментом, который ещё может быть и хорошо распиарен.
Разраб тоже может пойти писать REST апи на Си/Раст, потому хочется(в теории), но очевидно что это было бы не рационально при наличии Питона/Го под рукой (в текущих реалиях)
Может и нерационально, но что если он знает только Си, а задачу нужно решить?
saboteur_kiev
00.00.0000 00:00+28DevOps пошло из ентерпрайза. А в ентерпрайзе обычно не сидит полтора разработчика, которые пишут калькулятор, а сидит несколько десятков КОМАНД разработчиков, и в каждой команде свой зоопарк, и этот зоопарк развивается, мутирует, эволюционирует, в результате уже сам архитектор не знает где и что.
Поэтому и понадобилась культура, чтобы наконец девелоперы немного задумались как собственно их код запускается, не кусками в юнит тестах, а целиком, и чтобы планировали этот момент. А Опс соответственно понимали какие куски разрабатываются, и к какой команде бежать если проблема с авторизацией.
А девопс инженеры к DevOps культуре вообще никак. Они просто админят инфраструктуру и настраивают автоматизацию SDLC.
И да, для калькулятора девопс не нужен.
Ilusha
00.00.0000 00:00+2Я бы не сказал, что devops-инженеры «просто админят».
И для калькулятора devops может быть нужен. Просто потому, что он не существует в вакууме, а запускается в разных средах.
vvpoloskin
00.00.0000 00:00-1Я бы вообще не сказал, что devops вообще админят в том смысле что отвечают за доступность системы. Они обеспечивают доставку изменений.
BugM
00.00.0000 00:00+1Баш скрипт по крону отлично доставит изменения. Прямо на любой кластер. Вы уверены что это главное?
Berserkr
00.00.0000 00:00+3У вас 20000 серверов в 20 локациях по всему миру. Накидайте в пару предложений архитектуру доставки изменений в крон и что будете делать когда окажется что допустили ошибку и создали форк-бомбу после чего ни на один из 20000 серверов доступа более нет, ну кроме физического или через что-то вроде ipmi
Opaspap
00.00.0000 00:00+2Как и с обычным системным администрированием. Апдейт бомбы случаются, вспомним яндекс диск и плеск.
Вся идея девовпс имхо, в том чтобы автоматизировать процессы, до того как они станут рутиной, и хороший девоп должен понимать какие процессы рутиной не станут никогда.
BugM
00.00.0000 00:00Вы точно Гугл? Там из-за размера много особых решений нужно.
В более типичных случаях у вас десяток серверов хорошо если в паре локаций. Баш скрипта для доставки изменений вам хватит с головой.
PsyHaSTe
00.00.0000 00:00Уверены? А если за каждый день неактуального стейта на любом сервере у вас будут забирать месячную ЗП (с возможностью конечно же уйти в минус и словить необходимость закладывать квартиру чтобы расплатиться)? А то сегодня как раз был прикол где из-за малюсенькой ошибочки команда на десяток человек потеряли 2 миллиона баксов. Точнее их пользователь потерял, но они явно должны будут возместить ущерб.
Все ещё поставите свою голову на заклад что баш скрипты отработают как нужно?
BugM
00.00.0000 00:00+1А если за каждый день неактуального стейта на любом сервере у вас будут забирать месячную ЗП
Где же вы инженеров на такие условия найдете? Могу сказать за себя, уволюсь сразу после того как такие условия озвучат. Или не буду устраиваться.
Гугл так не делает, если что. Там где я работаю так тоже не делают. Продолбать много денег из-за ошибки возможность есть и иногда так и случается. Денег теряется на самом деле много, на порядки больше чем вы описали. Сотни тысяч рублей потерь в сутки это абсолютная ерунда. Большое руководство даже не заметит. На уровне лидов вероятно все останется.
Все ещё поставите свою голову на заклад что баш скрипты отработают как нужно?
Девопсы это такие маги которые делают софт без ошибок? Ну-ну.
PsyHaSTe
00.00.0000 00:00Где же вы инженеров на такие условия найдете? Могу сказать за себя, уволюсь сразу после того как такие условия озвучат. Или не буду устраиваться.
Обычные условия стартапа. Профит разделяют все участники, убытки тоже.
Гугл так не делает, если что. Там где я работаю так тоже не делают. Продолбать много денег из-за ошибки возможность есть и иногда так и случается. Денег теряется на самом деле много, на порядки больше чем вы описали. Сотни тысяч рублей потерь в сутки это абсолютная ерунда. Большое руководство даже не заметит. На уровне лидов вероятно все останется.
Для компании менее десятка человек — более чем заметно.
Девопсы это такие маги которые делают софт без ошибок? Ну-ну.
Инструменты обычно надежнее, чем их отсутствие. Я например если компилятор выдает ошибку в первую очередь думаю что это я накосячил, а не в компиляторе проблема, хотя бывает и последнее.
BugM
00.00.0000 00:00+1Странные у вас стартапы. Я вижу максимум таких которые раза в два недоплачивают и дают вместе этих денег свои фантики. Которые потенциально могут превратиться в миллионы. Но с большей вероятности они превратятся в бумагу. Что бы вы не делали.
В компании менее десятка человек продолбать большие деньги сложно. Там просто нет таких денежных потоков которые потерять можно. Исключения опять могут быть, но это исключения.
А Баш это разве не инструмент? Выглядит как язык программирования. Со своими особенностями, но у кого их нет?
PsyHaSTe
00.00.0000 00:00В компании менее десятка человек продолбать большие деньги сложно. Там просто нет таких денежных потоков которые потерять можно. Исключения опять могут быть, но это исключения.
Видимо, работаю с одними исключениями. Немного даже льстит.
А Баш это разве не инструмент? Выглядит как язык программирования. Со своими особенностями, но у кого их нет?
Язык программирования, и эту свою задачу он выполняет хорошо. А вот любое действие с его помощью уже будет кастомщиной. Чем больше степеней свободы, тем проще ошибиться.
Я пару месяцев назад видел историю команды из 3 человек которые опечатались в названии одной переменной, через 20 минут заметили это и задеплоили фикс, но все равно успели продолбать 150к баксов клиентских денег. Учитывая что они сами себе и разрабы, и фаундеры, и все что угодно, то выплачивать пришлсоь из своего кармана — а откуда ещё, дяди который денег даст за просто так у них не было.
Такие истории неплохо так учат внимательности, и да, лучше учиться на чужих ошибках.
BugM
00.00.0000 00:00Вы начали про бизнес. Бизнес к разработке не имеет примерно никакого отношения. Техностартап делаемый на свои (или кредиты что в общем тоже самое) имеет больше общего с цветочным ларьком чем с написанием софта.
Я про работу за зарплату. Часть этой зарплаты может быть фантиками какими-то. Это возможный вариант.
Всяких смешных ошибок стоимостью миллионы я видел достаточно. Но все NDA.
Бывает, дело житейское. Не понимаю о чем тут переживать? Как у любого хирурга есть свое кладбище, так и у любого разработчика есть свое. Просто у разработчика оно состоит из лежащих сервисов.
PsyHaSTe
00.00.0000 00:00+1То что когда за ошибки начинают платить из своего кармана, а не "тот господит на все уплатит" то сразу что-то начинают больше переживать за качество. Кмк личная доля участия разработчиков в продукте идет ему на пользу. Добавляет доровый уровень скепсиса, стоит ли деплоить в пятницу вечером и идти спать, стоит ли деплоить компонент связанный с деньгами не написав ни одного теста, ну и так далее. В общем, оздоровляет культуру разработческую каким-то чудесным образом.
И с таким отношением люди почему-то склоняются к рабочим инструментам, в частности девопс-стеку, и предпочитают его самописным скриптам.
BugM
00.00.0000 00:00+1Это бизнес. Не разработка. Средний разработчик рискует премией или максимум увольнением. И получает за это зарплату, а не долю в бизнесе. Это справедливо.
Есть промежуточный вариант когда пытаются заинтересовать в бизнесе. Выдавая фантики вместо части зарплаты. Но это как правило работает в одну сторону. Выдают, а не забирают.
Зачем вы хотите сделать всех разработчиков бизнесменами я не понимаю. Разработчикам в среднем это тоже не нужно.
В сверх мелких стартапах как раз со стабильностью и надежностью все плохо. Денег нет, нужны фичи. Не до надежности тут. Надежность слишком дорого стоит.
PsyHaSTe
00.00.0000 00:00В сверх мелких стартапах как раз со стабильностью и надежностью все плохо. Денег нет, нужны фичи. Не до надежности тут. Надежность слишком дорого стоит.
Ну вот челам нужны были фичи, поспешили, лишились полугодовой зарплаты. Следующая ошибка может ещё столько же стоить. А при этом кушать хочется.
Это бизнес. Не разработка. Средний разработчик рискует премией или максимум увольнением. И получает за это зарплату, а не долю в бизнесе. Это справедливо.
Единственный плюс, что вы прямо пишете, что за счет работодателя косячить готовы, а за свой — не очень. Прямота достойна уважения, утверждение — не очень.
BugM
00.00.0000 00:00+2Ну вот челам нужны были фичи, поспешили, лишились полугодовой зарплаты. Следующая ошибка может ещё столько же стоить. А при этом кушать хочется.
При чем тут вообще зарплата? Это типичные риски бизнеса. Цветочный ларек тоже может потерять цветов на миллион из-за ошибки. Это тоже самое.
Все бизнесмены рискуют деньгами и получают прибыть. Но не все люди бизнесмены.
Единственный плюс, что вы прямо пишете, что за счет работодателя косячить готовы, а за свой — не очень. Прямота достойна уважения, утверждение — не очень.
Я честно не бизнесмен. Как и подавляющая часть людей. Я хочу предсказуемую зарплату и не возражаю что на моей работе могут заработать за порядки больше денег. А могут и потерять, в том числе из-за моих ошибок. Всякое бывает. Но заработать бывает чаще, иначе меня давно уволили бы.
У кого риски, у того и прибыль. Это справедливо. Как управлять этими рисками чтобы работники приносили прибыль, а не убытки, на длинной дистанции это дело бизнеса. Кто не справился - разоряется. Кто справился - сильно богатеет. Опять справедливо.
Я всегда поддерживаю уменьшение рисков и знаю типичные методы для этого. Самые типичные это второе мнение и независимое наблюдение. Это как обычно стоит денег, но начиная с некоторого уровня денег под софтом оно начинает окупаться.
И при этом я всегда поддерживаю максимальную свободу. У разработчика должна быть красная кнопка "выкатить вот этот бинарь в прод сейчас". Без тестов и прочего. Прямо немедленно. При этом все должно логироваться и быть наблюдаемо. На следующий день к разработчику должен придти робот и попросить объяснение зачем он это сделал. Если другому человеку из другого отдела объяснение не нравится по любой причине к этому разработчику уже люди приходят поговорить.
iig
00.00.0000 00:00У разработчика должна быть красная кнопка "выкатить вот этот бинарь в прод сейчас". Без тестов и прочего. Прямо немедленно
Не могу даже придумать зачем это может понадобиться. У собственника такая кнопка может быть. Разработчику - оно точно нужно?
BugM
00.00.0000 00:00+1Собственник и катать релизы? Вы это серьезно? Или опять речь про микробизнес из десятка человек где собственник это же один из разработчиков?
3 ночи по времени где основная разработка сидит. На проде внезапно(с) всплыл неприятный баг. Допустим DDOS от соседнего сервиса положил какой-то наш важный сервис. Соседний сервис сделали наши коллеги которым мы в общем доверяем и не защищались от такого прям сразу. Как обычно надо бы но не успели, потом допишем. Деньги теряются со скоростью пару миллионов в час. Коллеги из соседнего сервиса на звонок по телефону не отвечают. У них вообще все хорошо, их мониторинги не загорелись.
Или любой другой баг на проде который вызывает потерю достаточно больших денег чтобы бизнесу было неприятно и при этом достаточно понятный чтобы не собирать с собаками команду из десятка человек глубоко ночью.
Выкатить хотфикс вот прям щас с баном этого соседнего сервиса (или любым другим понятным и простым фиксом текущей ситуации) у себя это разумное поведение. Для этого нужна большая красная кнопка "в прод". Все объяснения утром.
PS: Соседний сервис это конечно же не что-то основополагающее без чего бизнес жить не может, а просто клевая но вообще необязательная фича. Отсутствие которой может и заметят, но на деньгах она не скажется или почти не скажется за сутки ее неработы.
PsyHaSTe
00.00.0000 00:00-1При чем тут вообще зарплата? Это типичные риски бизнеса. Цветочный ларек тоже может потерять цветов на миллион из-за ошибки. Это тоже самое.
Пусть будет не зарплаты, а дохода. Это ведь совсем другое дело?
И при этом я всегда поддерживаю максимальную свободу. У разработчика должна быть красная кнопка "выкатить вот этот бинарь в прод сейчас". Без тестов и прочего. Прямо немедленно.
На мой взгляд непропорциональный уровень рисков и профита. Типа окей, придут люди, окажутся что он зря выкатывал это и не надо было, что дальше? Погрозить пальчиком? Уволить целого разработчика который просто пожмет плечами и пойдет может быть в чуть более плохие но все же сравнимые условия?
Я вот про это ровно и говорю. Задача разработчика не код писать, а использовать свои навыки написания кода для создания хорошего продукта. И выкатка непротестированного хз чего прямо сейчас немедленно обычно весьма противоположоенна вектору качественного продукта. То что ниже сказно про вилдный кейз — иногда нужно реагировать быстро, тем не менее просто сфрмировать общую картину мира и принять решение время всегда есть. Последнее слово должно быть за человеком, который за все добро платит — в том числе и "давайте делайте как считаете нужным только меня не трогайте". Правда, за него решать это не стоит.
Я всю ветку про это и говорю. Когда разработчик начинает персонально отвечать за свою работу он становится куда умнее. И продукт получается куда лучше. Просто наблюдение.
Не всем подходит такое, понимаю. Кто-то любит за счет работодателя экспериментировать, учиться. Кто-то напрямую просто подворовывает. Все люди разные :shrug:
BugM
00.00.0000 00:00+1Пусть будет не зарплаты, а дохода. Это ведь совсем другое дело?
Конечно. Это слово подразумевает участие в бизнесе и разделение и прибыли и убытка бизнеса.
Я всю ветку про это и говорю. Когда разработчик начинает персонально отвечать за свою работу он становится куда умнее. И продукт получается куда лучше. Просто наблюдение.
А прибылью делиться вы естественно не хотите? Ну там команда из 10 человек написала сервис, он взлетел миллионов на 100 долларов. Логично раздать им миллионов по 5 долларов?
Или команда уже существующего сервиса который стабильно приносит миллионов по 100 долларов в месяц должна наверно получать миллионов 50 на всех? Ну раз риски делятся, значит и прибыль делится?
Правда что делать с планово убыточными или безденежными (но очень важными) сервисами непонятно. Есть команда делающая внутреннюю инфраструктуру разработки, например. Ей наверно нужен отдел менеджеров который будет ходить по другим сервисам и уговаривать деньгами поделиться? Чтобы было что делить дальше.
Не всем подходит такое, понимаю. Кто-то любит за счет работодателя экспериментировать, учиться. Кто-то напрямую просто подворовывает. Все люди разные :shrug:
Учиться это нормально. Почему нет? Если сразу есть план учиться чтобы сменить работу, то есть некоторые вопросы. А если просто ради работы тут с расчетом на повышение, то это нормально. В конце концов все мы чему-то учимся. На любом новом месте есть новые штуки, которые мы изучаем за счет работодателя.
Эксперименты за счет работодателя это постоянно. Сейчас даже кнопочку без АБ теста не перекрасит никто. Выкидывается заметная часть работы. Точнее это называется неудачным экспериментом. И это хорошо. Если сработает хотя бы 5 процентов от новых идей это очень круто. А деньги есть, можно тратить.
За воровство увольнение одним днем без вопросов. Уголовное дело зависит от обстоятельств.
И выкатка непротестированного хз чего прямо сейчас немедленно обычно весьма противоположоенна вектору качественного продукта. То что ниже сказно про вилдный кейз — иногда нужно реагировать быстро, тем не менее просто сфрмировать общую картину мира и принять решение время всегда есть. Последнее слово должно быть за человеком, который за все добро платит — в том числе и "давайте делайте как считаете нужным только меня не трогайте". Правда, за него решать это не стоит.
Платит в конечном итоге совет директоров или акционеры. Вы на полном серьезе предлагаете их собирать чтобы принять решение "вот тут хотфикс на десяток строк надо выкатить прямо сейчас. зуб даю сработает."?
Все нормальные фирмы такое делегировали до уровня разработки. Если процесс логируется, наблюдаем и в результате таких случаев не очень много (тут субъективная оценка без вариантов. можно сделать какие-то метрики и думать что с ними дальше делать) и мотивация разработчика в них понятна, то это все неплохо работает.
PsyHaSTe
00.00.0000 00:00А прибылью делиться вы естественно не хотите? Ну там команда из 10 человек написала сервис, он взлетел миллионов на 100 долларов. Логично раздать им миллионов по 5 долларов?
Хочу конечно же. Так оно у нас сейчас и работает.
Все нормальные фирмы такое делегировали до уровня разработки. Если процесс логируется, наблюдаем и в результате таких случаев не очень много (тут субъективная оценка без вариантов. можно сделать какие-то метрики и думать что с ними дальше делать) и мотивация разработчика в них понятна, то это все неплохо работает.
Считаю, что можно лучше
BugM
00.00.0000 00:00Хочу конечно же. Так оно у нас сейчас и работает.
Похвально, но немаштабируемо. Я даже не буду о корпорациях. Это не маштабируется даже на средний бизнес (250 человек примерно).
PsyHaSTe
00.00.0000 00:00А зачем использовать то что хорошо работает для маленькой компании и плохо в средней — в средней? Если когда-нибудь понадобится отмасштабироваться — процессы можно поменять будет.
Я говорю лишь про то, что у разработчика внезапно голова начинает работать лучше, когда он отвечает за свои действия персонально. Ну там как с чиновнками — потратить на ненужную инициативу пару миллиардов не проблема — чужие же. Или с советской классикой — подпирать каким-нибудь сверхсекретным микроскопом за кучу денег дверь — ну а чо, казенный, не развалится.
Считаю такое поведение неправильным.
BugM
00.00.0000 00:00Так и не используют. Везде разработчики работают просто за зарплату. А деньгами рискует бизнес. Используется именно то что хорошо работает.
Схема с участием всех работников даже среднего предприятия в прибыли не работает. Там инвестиции, риски, бизнес. Не нужно оно людям.
В микро своя жизнь. Ничего не имею против, но как и большая часть разработчиков не хочу в таком участвовать.
PsyHaSTe
00.00.0000 00:00Так не спорю же, зачем брать на себя ответственность, когда можно не брать? Это нерационально, а разработчики очень умные и рациональные. Продукт правда страдает, но для человека это явно менее важно чем собственное удобство.
Но технологии развиваются обычно с целью решения бизнесовых задач, где удобство сотрудников может быть инструментальной целью но не более.
Opaspap
00.00.0000 00:00+1Не начинает лучше голова работать, а он начинает перестраховываться, париться по не своему скопу и ныть о неполноте информации от менеджемента. Свалить бизнес на разраба, это больше похоже на несостоятельность менедженмента, чем на заставить его работать лучше. Эта идея миф из какой то книжки.
Ilusha
00.00.0000 00:00Администрировать - это синоним слова «управлять». Devops-инженеры как управляют системами, так и выстраивают их: архитектуру, пишут код, запрашивают у разрабов доработки софта.
saboteur_kiev
00.00.0000 00:00+2В большинстве случае в ентерпрайзе уже все зарегулировано, иногда есть архитектор, который совсем не девопс. И внедрять какие-либо значительные изменения в SDLC процесс - в первую очередь проблемно именно по той причине что технические задачи приоретизируются по минимуму.
А для калькулятора девопс может быть и не нужен, потому что маленькое приложение, которое разрабатывает один-два разработчика, можно скомпилить локально, а в разных средах может протестировать мануальщик-тестировщик.
Я сталкивался с ситуацией, когда разработчик собственное приложение запустить не способен. Вообще. Считает что его задача код и юнит тесты написать, а если скомпилилось, то дальше не его проблема.Tzimie Автор
00.00.0000 00:00+1По последнему абзацу, и как скорость разработки?) Риторический вопрос. Я представляю степень демотивированности этих разработчиков
saboteur_kiev
00.00.0000 00:00Сидят в команде разработчиков, продукт многокомпонентній, что-то пилят в одном из компонентов, запускается софт в опенщифт, куда они себе даже доступ не заказали. В результате для них запуск софта что-то заоблачное, а мотивации разобраться, заказать доступ (все гайды есть), посмотреть в связке - нет. Бегают за логами к саппорту.
Да, таких не слишком много, но на удивление не только джуны, бывают и мидлы. Видимо за выслугу лет.izogfif
00.00.0000 00:00мотивации разобраться, заказать доступ, посмотреть в связке - нет
Значит, их тимлид (или как там надзиратель над программистами называется) не бьет палкой. Потому что нет именно что мотивации.
saboteur_kiev
00.00.0000 00:00А девопс не менеджер, он бить палкой не может по своим полномочиям.
izogfif
00.00.0000 00:00А ему и не надо. Он вообще может не знать, что проблема вообще есть. Это надзиратель должен видеть, что программисты простаивают или выдают результат очень медленно, а дальше уже разбираться, в чем дело.
Ilusha
00.00.0000 00:00А почему архитектор инфры не devops?
saboteur_kiev
00.00.0000 00:00потому что он уже больше ITAO и менеджер, чем технический сотрудник
Ilusha
00.00.0000 00:00Почему он менеджер? Да, у него могут люди в подчинении.
Что такое ITAO я слабо понимаю. Погулил. На первой странице был ваш комментарий, разъясняющий, что это. В общем, не согласен я с тем, что этот нишевый термин можно тащить в диалог.
Архитектуру инфры строит квалификация инженер-devops. Уровень - сеньёр. У него может быть команда в подчинении (лид/менеджер). Он может владеть продуктом - обладать другими квалификациями для этого.
Но, вы возьмете стартап, в котором есть devops - именно он будет выстраивать инфру. А не непонятные названия позиций.
carebellum
00.00.0000 00:00за архитектуру инфры отвечает архитектор инфраструктуры, не сеньер инженер девопс, хотя экспертизы будут пересекаться
Ilusha
00.00.0000 00:00Это вы сейчас лычками разбрасываетесь, а не сутью вопроса.
carebellum
00.00.0000 00:00возможно
я хотел подчеркнуть, что девопс инженер напрямую не будет планировать архитектуру инфры, для этого есть выделенная роль, которая с девопсом пересекается лишь отчасти
saboteur_kiev
00.00.0000 00:00Архитектор проекта входит в число тех людей, которые выбивают под инфраструктуру деньги. Или как минимум аппрувят с пониманием что происходит. И он обязан разбираться в том, надо ли заказывать 100 серверов или надо ли ехать в клауд, и берет на себя ответственность за эти растраты.
Если дать разработчикам в руки возможность просто брать и заказывать себе ресурсы без контроля, они на каждыйкоммитбренч себе индивидуальный кластер поназаказывают
PsyHaSTe
00.00.0000 00:00+2да просто сделайте калькулятор с требованиям 100K RPS пяти девяток доступности, добавьте требование что нагрузка приходит волнами, и нужно с одной стороны не отвалиться в момент когда нагрузка пришла, но и не закупать инфраструктуру рассчитанную на пик которая 80% времени будет простаивать (и.е. автоскейлинг).
А теперь посморим: нужен ли тут девопс или так обойдемся?
VVitaly
00.00.0000 00:00-2Ну а что, "тупые" (в финансовой области) облачные провайдеры вам автоскейлинг и инфраструктуру под него же бесплатно сделают. "Тупые" проггеры (которые не подозревают что нагрузка будет 100K RPS, а тупо "кодят") вам с ядра не более 1 RPS "падучие и с багами" бесплатно напишут (за то с блекджетом, шл...ми и новомодными технологиями), а "блестящие в доспехах devops" с успехом и конечно бесплатно все это "развернут и поддержат"... :-)
Так примерно? А может в консерватории что-то поправить? :-)
thunderspb
00.00.0000 00:00+1Зависит от того как компания понимает что должен делать девопс. Во многих вакансиях, где я проходил собесы, девопс чисто адмни. А когда я спрашивал -- а причём тут девопс, то мне говорили -- а, ну еще следить за дженкинсом, чтоб работал. Речи о написании пайплайнов, стандартизации процессов там не шла. :)
DaneSoul
00.00.0000 00:00+10ИМХО DevOps и все эти навороты — это не плохо и не хорошо — все зависит от задач.
Если у вас сотни разработчиков и сотни тысяч строк кода на куче серверов в разных дата центрах, то у Вас реально сложная задача, и соответственно разумно использовать сложный инструментарий.
Разработка космического корабля и кухонной табуретки несколько отличается. И если у Вас вдруг к табуретке требуется огромная пачка инструкций, чтобы ее собрать, то что-то пошло не так.
Вот в современном IT часто тащат в проекты технологии, потому что это круто и современно, а не потому что реально необходимо. "О, это крутая технология — ее используют FB и Google- нам тоже надо!" Если у Вас продукт сопоставимой сложности как у них, то вероятно действительно надо, но если Вы это все тяните в каждый проект независимо от масштаба, то стоит задуматься!
PS: Пока писал комментарий, выше уже высказали похожую мысль.
ZiggiPop
00.00.0000 00:00Если у вас сотни механиков и выпуск сотен автомобилей в день, то у Вас реально сложная задача, и соответственно разумно использовать конвейеры длинною в милю.
Но нет же, это не православно. Правильный автомобиль должны собирать в сарае два инженера–разработчика, которые перемежают конструирование с кручением гаек разводным ключом.
PsyHaSTe
00.00.0000 00:00Мини-девопс мне кажется есть в любом продукте. Пишем какой-нибудь простенький веб-магазин. Будет у нас сайт, какая-нибудь алгоритмическая часть которая считает что юзеру предложить, какие-нибудь воркеры которые краулят в интернете что-нибудь и скидывают в базку. Хочется иметь infra as a code, возможность в 1 кнопку развернуть все это добро в любом окружении (в т.ч. локальном), чтобы сеть там правильно прописывалась, чтобы что нужно в интренет торчало, что не надо не торчало, чтобы по коммиту в мастер автоматически запускалось обновление инстансов,…
Ничего особенного, никаких диких нагрузок, просто не хочется лазить по RDP на прод и дллки поденять, не хочется лазить по конфигам и вспоминать что там нужно написать, не хочется в файрволл правила прописывать,… Хочется нажать 1 кнопку "сделай хорошо" и чтобы стало хорошо.
Tzimie Автор
00.00.0000 00:00+3Вместо конфигов приходится лазить по ямл файлам
PsyHaSTe
00.00.0000 00:00Окей, хочется 1 раз полазить по конфигам, настроить, и больше не включать голову. Единожды настроенное — работает как задумано. Пока не хочется что-то улучшить, автоскейлинг прикрутить или ещё какую ерунду. Если текущего функционала деплоя хватает — то можно до конца мира ничего не менять, и все будет работать как часы по одной кнопке.
А второй плюс что для этого можно нанять специально нанятого человека, которому я просто говорю "докерфайл лежит вот тут в корне", и на этом мой вклад в инфраструкуру заканчивается — можно сидеть, читать как в новой версии джавы классно гц работает и какие новые удобные каналы сделали, а про всякие порты/сертификаты/… пусть болит голова у кого-то другого.
Tzimie Автор
00.00.0000 00:00Если они это делают один раз, а потом все это все работает автоматом, то чем целый отдел девопс занимается остальное время?
PsyHaSTe
00.00.0000 00:00Ну у нас нет целого отдела, человек занимается другими задачами. Когда появляется что-то на девопс — отвлекается и делает.
А в более-менее больших компаниях просто всегда есть что сделать. Добавить логгирование ещё этой фигни. Перейти с эластика на другую фигню, потому что она меньше жрет памяти и меньше таймаутится. Перейти с сертбота на вот эту штуку потому что 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.Hungryee
00.00.0000 00:00По моему небольшому опыту вот именно эти «переходы с X на Y», что делают девопсы - по большей части наведение шухера без особого выхлопа.
зачем переходить с эластики на что-то другое, если эластика прекрасно делает свое дело? Если делает плохо, то почему изначально не был выбран Y в процессе ресерча?
sgjurano
00.00.0000 00:00+1Как правило переезды происходят из-за изменений условий, приоритетов или из-за выявления в процессе эксплуатации ранее неизвестных фактов о системе.
Вот у нас сейчас компания резко начала вкладываться в безопасность. Теперь все системы (тысячи их, без преувеличения) должны прикрутить аутентификацию и авторизацию, а все потоки данных должны быть зашифрованы, гигантский объём работы.
PsyHaSTe
00.00.0000 00:00+1У меня пока не было девопсов. которые по своей инициативе что-то делали. Как и не было разработчиков, которые забабахивали сервис ну прост потому что почему бы и нет. За каждой задачей стоит тасочка с конкретным бизнес-велью. Иногда плохие девопсы выбирают плохой инструмент, ну да от этого никто не застрахован.
kap1ik
00.00.0000 00:00Даешь DevOps as a Service каждому небольшому проекту! Но пока это разовьётся до вменяемых цен, пройдет еще не один год.
jingvar
00.00.0000 00:00+1Т.е. по высшей логике если нужно на обслуживание 100серверов, 3 человека то на 10 достаточно одного? Если задача не сложная, то цикл авто тестов , и тест на стейдж дев не обязательно? Вместо декларативного повторяемого развёртывания можно ходить фигачить руками?
raamid
00.00.0000 00:00+17Мне в бородатые 90е подарили компат диск который был до верха заполнен скинами к WinAMP. Ничего кроме скинов там небыло даже самого WinAMP. Это я к тому, что описанная автором проблема, а именно улучшательства ради улучшательств действительно существует, но причина не в DevOps, а в природе человека. Графоманство - пожалуй наиболее близкий диагноз.
Если же вернуться конкретно к DevOps, то его просто нужно уметь готовить. Не случайно в каждой первой статье про Докер фотографии контейнеров. На их примере и поясню. Контейнеры - прекрасное средство массовой доставки грузов морским путем. И крайне рациональное. Однако, никому не приходит в голову использовать контейнер (с погрузкой-разгрузкой при помощи крана) для доставки холодильника из супермаркета. Для этого есть другой вид транспорта. Так и с DevOps. Мы имеем дело с обширной группой инструментов под разные виды задач. И если использовать их не по назначению, будет дорого, неудобно и вообще смешно.
Итого, моё ИМХО: графоманство, неадекватные маркетологи, которые пытаются фантазировать потребности клиента и плохое понимание программной инфраструктуры - вот причины описанной автором проблемы, а не DevOps как таковой.
Ilusha
00.00.0000 00:00+1Аналогии нужны чтобы иллюстрировать принцип, делать его понятным. Как только вы пытаетесь на аналогии делать выводы - сразу же попадаете в ловушку.
Контейнеры для перевозки бывают разные (железнодорожные, морские, автомобильные). И если обратите внимание, то у газельки на «спине» - контейнер. Маленький. Т.е. принцип остается тот же. И в devops также.
Сейчас даже для внутренних нужд лучше взять докеркомпосе/миникуб/k3s.
raamid
00.00.0000 00:00+1Согласен, контейнеризация в компьютерах - это более универсальная технология чем контейнеризация в перевозках. Я даже в некоторых хобби проектах использую контейнеры. Однако, я их не сравнивал напрямую. Я сравнивал транспортную систему и DevOps. А контейнеризация - это лишь часть того и другого.
Тут я вижу еще одну, если так можно выразиться "проблему". Все стало доступным. Git, контейнеры, системы оркестрации, СУБД. В 20м веке лицензия на подобное ПО могла стоит десятки тысяч долларов за одно человеко-место. Но случилось прекрасное чудо (я без сарказма) и мир постепенно перешел на открытое ПО. И теперь, выражаясь языком транспортной системы, можно летать за хлебом на самолете.
Хорошо это или плохо? В основном хорошо, поскольку люди получают возможность потестировать крутые технологии на "игрушечных" проектах. Меньше граблей будет когда вырастут.
Ilusha
00.00.0000 00:00«летать за хлебом на самолете». Вот я частично не согласен с такой параллелью.
Скорее «мы изобрели телепорт и используем его как для перемещения на Марс, так и из гостиной к холодильнику за пивом».
Для перемещения на 10 метров достаточно встроенного в часы. До марса - размеров с автомобиль. В основе мы юзаем виртуализацию для решения проблем. И будут это чистые LXC или обернутые в докер, будут ли там компосер/k3s или k8s - это уже дело десятое.
Но, «летать на самолете»: это использовать k8s для лендинга, например.
PsyHaSTe
00.00.0000 00:00+2А что не так с холодильником? Мне кажется тут уже аналогия протекла немного. Без докера можно распространять приложения влезающие в единственный бинарник со всеми зависимостями. Все что сложнее — в разы проще с докером. Питон? джава? голанг? Не надо человеку ничего ставить, думать тессеракт какой версии требуется чтобы скомпилят ьприложение, клиентские библиотеки постгри какой версии качать и где — он пишет docker build. и мультистейдж докер где все написано скачает как нужно, поставит как нужно и будет работать ожидаемым образом. "но ведь можно написать инструкцию" — во-первых, люди их не читают, во-вторых зачем писать инструкцию если можно заставить машину все сделать правильно? Докер это ультимативное решение проблемы УМВР
И не вижу ни малейшго недостатка использовать его даже для приложений магазинов с тремя гет ручками — пусть вся возня с запусками нужных команд, установкой ноды, питона, chezcheme и всего остального будет от меня спрятана — у меня есть docker build и вокруг одни гвозди.
Kozoft
00.00.0000 00:00+1Дженкинс и скрипты в нексусе - это просто ci. Девопс - это когда разраб запушил и забыл. И не один разраб, а несколько сотен в десятках команд.
kt97679
00.00.0000 00:00+2DevOps это методология, по которой разработчики отвечают не только за написание кода, но и за его деплоймент в продашен. Как это делается — отдельный вопрос. Можно сделать хорошо и без лишних сложностей, а можно наворотить не пойми что.
Очень печально, что термин DevOps стал хайповым и лепится сейчас ко всему по делу и без. Нет DevOps инженеров. Есть инженеры, которые владеют DevOps методологией.
cross_join
00.00.0000 00:00+2Разработка и эксплуатация - два разных мира с противоречивыми целями существования.
kt97679
00.00.0000 00:00Так по идее DevOps это как раз попытка найти компромисс между "хочу быстро выкатывать новые фичи" (dev) и "хочу, чтобы все стабильно работало" (ops).
aPiks
00.00.0000 00:00+4Есть предположение, что человек, написавший статью никогда и не видел настоящего прода, когда 50 микросервисов в облаке, у каждого по 10 инстансов, для каждого нужны политики безопасности, политики для деплоя, отката, перезагрузки и тд и тп. Плюс все это надо одновременно мониторить, дебажить и логи собирать. Автор, напиши, как там все это скриптами на шеле делать. Не забудьте, что это это надо на вчера, а не на через 2 года.
klimkinMD
00.00.0000 00:00+19...50 микросервисов в облаке, у каждого по 10 инстансов, для каждого нужны политики безопасности, политики для деплоя, отката, перезагрузки...
Самый цимес, когда в результате всего ЭТОГО заказчик получает новый calc (с VIP темами и лайаутом)
aPiks
00.00.0000 00:00Ну да, гораздо лучше, когда заказчик получает калькулятор без тем и лэйаута, а потом не может его продать, потому что просто калькулятор никому не нужен. И приходится его улучшать, добавлять темы и лэйауты, прикручивать решение формул и т.д., только все это через боль и страдания, потому что изначально думали, что все практики девопс и тд не нужны и это оверинжиниринг и все сделано ручками на скриптах и велосипедах, а теперь скрипты и велосипеды уже не вывозят и надо с нуля все переделывать. Я уже несколько раз сталкивался с таким подходом, когда контракторы делают что-то, думая что они умнее всех...а потом это невозможно нормально поддерживать и развивать, потому что есть действительно оверинжиниринг, а есть есть люди, которые привели по старинке работать, когда системы были в 50 раз проще. Я не спорю, что сейчас очень много всего, что добавляет сложности в проекты, но и сами проекты стали гораздо сложнее. Раньше не было такого, чтоб к тебе одновременно валился трафик с кучи разных устройств, с разных стран, континентов, разных типов пользователей и тд. Не надо было обрабатывать такое количество информации. Не было KYC и тд.
Вот у вас есть заметки на телефоне. Это просто редактор. Но мы не хотим условный Блокнот из виндоус. Мы уже хотим синхронизацию заметок, мы хотим рисовать в блокноте, добавлять изображения, взаимодействовать со стилусом и тд. Мы хотим чтоб это появлялось на разных платформах. И добавлять изображения. И экспорт в соц сети и кучу всего ещё. И мы хотим чтоб это все масштабировалось под миллионы пользователей. И было дёшево разрабатывать, потому что время программиста очень дорогое для бизнеса. Отсюда и появились и все фрейворки, девопсы и прочее. Без этого можно обойтись, но это будет намного дороже и сложнее в поддержке.
MadeByFather
00.00.0000 00:00+3Это просто редактор. Но мы не хотим условный Блокнот из виндоус. Мы уже хотим синхронизацию заметок, мы хотим рисовать в блокноте, добавлять изображения, взаимодействовать со стилусом и тд. Мы хотим чтоб это появлялось на разных платформах. И добавлять изображения. И экспорт в соц сети и кучу всего ещё. И мы хотим чтоб это все масштабировалось под миллионы пользователей.
Нет, мы - пользователи - этого не хотим. Я хочу видеть в заметках простой блокнот, особенно в телефоне.
Захочу синхронизации, рисование и привязку к соц. сетям - найду соотвествующее приложение в сторе
Ilusha
00.00.0000 00:00+1Нет, мы - пользователи, этого хотим. Я не хочу искать - я хочу, чтобы приложения соответствовали современости. А если уж нужен будет просто, то здесь уж можно поискать по соответствующим ключевым словам.
Но я не хочу получить из блокнота WeChat. А кто-то хочет.
Потребности бизнеса исходят из хотелок аудитории этого бизнеса.
aPiks
00.00.0000 00:00+1Если бы вы хотели этого, половины приложений и продуктов не появилось бы или уже давно бы сгинули.
Ndochp
00.00.0000 00:00+1Вот у меня доча хотела видеть в заметках простой блокнот в Хуавее (Хуавей ноут, или как-то так). Настрочила 800+ заметок за 4 года и телефон устарел.
Все, оно из телефона никак не вытаскивается. Обмен с хуавей планшетом через хуавей облако пролюбил все картинки, то есть заметок приехало всего 600, а те что приехали — только текст.
Не над быть сильно простым пользователем, потом больно. Про синхронизацию, обмен, выгрузку, и чем читать эту выгрузку кроме исходного приложения надо думать самому.isden
00.00.0000 00:00Справедливости ради, у хуавей те еще сервисы. Даже банальный перенос данных с одного телефона на другой (по железу они отличаются размером оперативы и камерами) через phone clone потребовал танцы с бубном, занял несколько часов (синк упорно отваливался и не подцеплялся с первого раза), и то не все корректно перенеслось.
cross_join
00.00.0000 00:00+1Ну, вот, опять "девопс ненастоящий". Та же мантра с "ненастоящим аджайлом". Если вокруг в основном все "ненастоящее" - аджайлы со стендапами по часу и без рефакторинга и девопсы, увеличивающие REPL на порядок, то проблема в консерватории.
Ilusha
00.00.0000 00:00Проблема в том, что кто-то решил играть на скрипочке без обучения в этой «консерватории». А потом удивляется, что его талант не ценят.
agile, devops - это инструменты для решения конкретных задач в конкретных условиях. И нужно учиться ими пользоваться.
cross_join
00.00.0000 00:00Вы читали руководство по скраму? Там действительно есть чему обучаться более одного вечера?
Ilusha
00.00.0000 00:00Можно придти в компанию и работать «по скраму» - хватит и 5 минут.
А для того, чтобы успешно внедрять agile в компанию, нужно знать гораздо больше.
ZiggiPop
00.00.0000 00:00+12>я работал и на перфокартах c одним прогоном в день.
А я не работал на перфокартах, но зато помню, как сборка перспективного B2B проекта в рамках IT-отдела крупного промышленного концерна поддерживалась одним человеком, по совместительству его, вероятно, главным разработчиком, и собиралась при помощи батников и неведомой магии, и когда он в одночасье умер, то внезапно проект умер в течение полугода. Казалось бы, при чем тут DevOps?cross_join
00.00.0000 00:00+8Прекрасная иллюстрация маркетинга девопса - проект, оказывается, умер из-за невозможности разобраться в трех скриптах на шелле, а не потому, что кроме главного разработчика никто толком не знал, что, почему и как делает система.
ZiggiPop
00.00.0000 00:00-1>а не потому, что кроме главного разработчика никто толком не знал, что, почему и как делает система.
Так суть DevOps как раз и состоит в том, что в проекте должен быть четкий набор технологий и методологий интеграции и доставки, реализацию которых сможет разобрать любой специалист, владеющий данным набором, а не ворох плохо связанных костылей, подпирающих процесс сборки. Разве не так?saboteur_kiev
00.00.0000 00:00+4Да нет. Просто документация нормальная должна быть на проекте. Даже если это легаси или редко используемые технологии.
А костыли - они везде есть в том или ином виде.thunderspb
00.00.0000 00:00+1Но документация это вообще маст хев всегда.
Я бы сказал, что частично комментарий выше содержит долю истины. Если будут стандарты (стандартизированные скрипты, конфиги, хелмчарты и всякое такое) + адекватная документация, описывающая как этим пользоваться, то и проблемы не будет. А если каждый тим лид из условных 10-20 команд разработчиков сам "какшмагла" будет писать скрипты сборки, деплоя, тестирования, то там никакая документация не поможет.
cross_join
00.00.0000 00:00А разве так? Тогда прошу показать, где в девопсе находятся постановки задач, функциональная архитектура, спецификации, внутренняя и внешняя документации. По минимуму, без проверок требований на полноту и непротиворечивость и разработки методики испытаний.
PsyHaSTe
00.00.0000 00:00+1Случайно "Бородино" не входит в список ваших любых стихов? ПО крайней мере та часть "да, были люди в наше время".
История: сделанную на хоуммейд скриптах и хаках систему после ухода разработчика не смогли поддерживать.
Сделанный вывод: разработчик молодец, а молодежжж нынче не та пошла, даже в паре скриптов разобраться не может.cross_join
00.00.0000 00:00+1Странный вывод: речь шла о причинах "смерти" проекта. Ведь не из-за скриптов же сборки-развертывания, если серьезно.
PsyHaSTe
00.00.0000 00:00Ну, без дополнительных деталей это и правда выглядит странно, но если принять на веру то что там так все и было, то в целом я бы сказал вина на разработчике, ну и тех кто допустил такой бас-фактор в команде (хотя полагаю, что он и был лидом).
А с таким предполжением все логично — кроме сборки на нем мог быть ключевой функционал, который переписывать просто не было времени. А к тому моменту уже инвесторы/ЛПР/… потеряли интерес в проекте и он заглох.
sergeyns
00.00.0000 00:00+1Думаете если бы у них был DevOps, то этого бы не случилось?
PS наверняка случилось бы, только бы померло бы не по причине того, что никто не знал как собрать проект, а то внутри оказалась бы какая-нибудь, например, волшебная СУБД, про которую никто не в зуб ногой, например какая-нибудь Cache (и это даже не из чего-то новомодного, а такая, вполне себе известная в узких кругах :) )
artazar
00.00.0000 00:00+4Прежде, чем писать подобный "вброс", стоит качественно изучить вопрос. Ничего в мире просто так не появляется. Есть причины и последствия. DevOps появился как естественное продолжение ускорения процессов разработки, когда один или несколько релизов в день стало нормой. Когда поддерживать и чинить что-то руками стало дурным тоном. Если рассуждать про этот вопрос всерьез, тогда уж надо брать шире и исследовать тему "почему же весь мир так сильно разгоняет разработку, доставку новых фич, моментальное исправление любых багов, неприятие простоя сервиса в 5 минут", и прочее, и прочее. Смотрите шире. То, что вы описали в статье, это просто плохие практики, с которыми вам не повезло столкнуться.
Berserkr
00.00.0000 00:00+1Вероятно автор стал жертвой последователей карго-культа в чем его винить нельзя кроме того что он продолжает работать в подобных компаниях и ничего не делает что бы ситуацию исправить.
cross_join
00.00.0000 00:00+1>Когда поддерживать и чинить что-то руками стало дурным тоном
Разве девопсы не занимаются ручной поддержкой и починкой своих скриптов, ломающихся ежечасно при изменении одного из 100500 компонентов сборки?
1CUnlimited
00.00.0000 00:00+2Есть причины и последствия. DevOps появился как естественное продолжение ускорения процессов разработки, когда один или несколько релизов в день стало нормой
Поэтому и качество ПО падает - ничего у нас там несколько релизов в день исправление попадет в катойто релиз. При этом не учитывается что автотесты дописывать с такой скоростью никто не будет
VVitaly
00.00.0000 00:00+1"когда один или несколько релизов в день стало нормой" - позвольте поинтересоваться с какой целью и почему? Может разрабы "на гора" и по аджайлу пушат баги каждый релиз? Или может "продвинутый" постановщик задачи "глазами, руками и мозгой" не пошевелил до выдачи "на гора" и по аджайлу разрабам задачу? А... Нет. Это "умный" маркетолог убедил бизнес что "счас все это делают" и мы "побыстрому" сорвем банк... :-)
Tzimie Автор
00.00.0000 00:00Вообще да. Вот у моего банка UI не менялся глобально лет пять. И слава Богу. Но мне почему то кажется, что там все равно выкатывают чтото несколько раз в день. К счастью, я этого не замечаю
Aquahawk
00.00.0000 00:00+6Я тот человек который переложил все ci скрипты и вообще пайплайны jebkins в git. Это сразу, на корню, решило все проблемы вида Вася там что-то делал, оно сломалось, как откатить никто не знает. Nexus там непонятно зачем, но версионирование всего кода, включая ci это правильно.
sshikov
00.00.0000 00:00Nexus там непонятно зачем
Да ровно за тем же самым. Это тоже версионирование, просто немного другое, для другого сорта артефактов.Aquahawk
00.00.0000 00:00ну и зачем он если есть гит? Автор же пишет что сначала гит потом из него в нексус и потом деплой. Или деплой из гита это ооже фу-фу-фу?
sshikov
00.00.0000 00:00+1Затем что хранение и деплой собранных для работы артефактов — это другая задача. Скажем, внешние артефакты (которые хранятся в maven central, или docker registry, или pypi), вы тоже сначала достаете оттуда, складываете в git, а потом из него деплоите?
Обычно люди все-же используют nexus (который если надо умеет прикидываться и и maven, и docker registry, и pypi, npm тоже, ну или какую другую реализацию одного из этих видов репозиториев), чтобы проксировать внешние репозитории.
Если они достаточно параноики — то даже staging репозиторий обычно заводится, чтобы фильтровать вредоносные или уязвимые артефакты. Если у вас этого всего нет (я верю, такие процессы бывают), это не значит, что никому это не нужно. Хотя бы для того, чтобы maven или gradle или sbt или nodejs могли там артефакты при сборке достать — они из гита не умеют, и не должны.
thunderspb
00.00.0000 00:00Возможно там про бинарные файлы? Возможно написаны на го, используются в деплое или какоймто анвлизе. Или бинари тоже в гит?:)
flancer
00.00.0000 00:00+9С учётом взрывного роста населения планеты (только на моем веку увеличилось в два раза) одна из главных задач IT в настоящее время - занять максимальное количество людей каким-нибудь делом. Я не вижу другой отрасли народного хозяйства, в которой бы можно было так эффективно создавать друг другу работу из ничего. А DevOps это просто часть IT.
Ivan22
00.00.0000 00:00+2так это же задача не только ИТ но и например Кинематографа, спорта, туристической отрасли, контент креэйтеров на всех площадках от тв до тиктока, ресторанного бизнеса, парикмахерского, индустрии красоты и т.д, и т.п
Berserkr
00.00.0000 00:00+4Наброс мягко говоря слабый, хотя зерно здравой мысли присутствует относительно количества человек. Учитывая опыт реальных компаний с нормальными процессами где десятки тысяч серверов и сотни-тысячи сервисов и для этого хватает команды из пары десятков человек против компаний где масштабы на порядок меньше и всё значительно проще и при этом в разы больше людей. Но забавно что автору это кажется сложным при условии что вся информация находится в одном месте, посмотреть 50 файлов в одном репозитории значительно проще и быстрее чем найти 50 сервисов на рандомном количестве неизвестных серверов.
" У знакомой три девелопера и три человека в отделе DevOps. " - это вообще ни о чем не говорит, эти три человека вполне могут заниматься и поддержкой инфраструктуры - серверы, сети, приложения, поддержкой аналитиков, да и до кучи еще и архитектурой, а то что делают 3 разработчика вполне себе может требовать десятков, если не сотен серверов - например система аналитики какая-нибудь.
А закончим вообще на том что у тебя один работник уйдет в отпуск, а второй заболеет, что должен будет делать третий в это время? Минимальный размер команды вполне себе понятен и понятны риски и прочее которые это за собой несет - это архитектора можно отправить в отпуск и ничего вообще не случится. А вот огромные команды уже вызывают вопросы к компетенциям самих работников.
Подытожив можно сказать что иногда(часто) методология мутирует в рак, но это связано сугубо с нанимаемыми "специалистами", я три года назад еще предсказывал что из-за большого количества некомпетентных людей которые решили срубить бабла у бизнеса будут проблемы и это таки случилось - медиана для специалистов данного профиля в России в этом году 500 000 среднегодовая ежемесячная зарплата - для тех кто может решить проблемы которые нахуевертили господа после курсов "как стать девопсом за 3 месяца" - очевидно те кто не жадничал и нанимал адекватных людей проблемы не получили, а остальные купили бесценный опыт.
Последний абзац очевидно автора вообще никаким образом не касался даже, а как раз про это могла бы получится прекрасная дискуссия.
Tzimie Автор
00.00.0000 00:00+3Давайте разовьем! Я знаю что надо использовать docker и kubernetes потому что... Потому что это модно и молодежно. Как смузи и ролики.
Правда, они не могут читать файлы для ETL, которые по какому то протоколу выкачиваются, который нормально поддерживает только винда... Но ничего, сделают кучу костылей
dnbstd
00.00.0000 00:00+2Этож какие такие ETL файлы? Apache Nifi и Airflow прекрасно справляются с ETL процессами. И они как раз гибче масштабируются в k8s. А про модно и молодежно, похоже на старую шутку «вы просто не умеете их готовить»
dnbstd
00.00.0000 00:00И я открою страшную тайну есть виндовые контейнеры и ноды к8s на винде)
Tzimie Автор
00.00.0000 00:00Я не очень понимаю в чем проблема, так, брызгами зацепило, узнаю позже в чем проблема
thunderspb
00.00.0000 00:00На счёт контейнеров, в моём примере, не знаю точно, но stackoverflow, вроде, на 80% состоит из виндовых серверов.
Tzimie Автор
00.00.0000 00:00Apache Nifi и Airflow? Отлично, еще два продукта к списку)
dnbstd
00.00.0000 00:00+1Эм это как бы нынче стандарты etl процессов)))
SSukharev
00.00.0000 00:00Airflow - это не ETL, в нем нет ничего, что бы делало его ETL-м. Это workflow management платформа. Пихают везде это говно в качестве ETL, тоже своего рода религия. Dagster и Prefect в разы лучше они хоть как то приближены к задачам ETL-я, могут хотябы данные между узлами передавать.
dnbstd
00.00.0000 00:00Соглашусь, однако используют его зачастую именно для оркестрации ETL. Ну насчет нет ничего, не соглашусь. Как же DAG’и которые добавляют ему гибкости.
SSukharev
00.00.0000 00:00Нормальный etl должен содержать два обязательных уровня - управление загрузкой (оркестровка процесса) и уровень трансформаций, управление загрузкой должны включать в себя в том числе и циклы, обоаботку ошибок , переходы по условию или по набору данных в потоке данных - этого нет. Уровкнь трансформации должны содержать различного рода экстракторы из разных источников и целевые объекты- таргеты, их тоже нет, сами трансформации их в нормальном erl огромное количество под всякие нужды от калькулятора до изменения типа данных, локапы и мержи, этого тоже нет. Есть еще третий слой - слой описаеия метаданных,, он есть не у всех, но этого тоже нет. Взамен всего этого разработчику предлагается наговнокодить это все на питона.
rzerda
00.00.0000 00:00Отторжение непонятного - нормальная ситуация (не в смысле «так и должно быть», а в смысле «встречается сплошь и рядом»).
germn
00.00.0000 00:00+10Почти пародия на всплывающие периодически статьи про программистов: "зачем нам ООП с этими сложными абстракциями, когда можно написать одну простую функцию на коленке, и норм". Забавно, не более. Извините за душноту :)
aamonster
00.00.0000 00:00+6Самое смешное – это когда ты программист, привыкший к ООП и слоям абстракции, и вдруг своими руками пару слоёв абстракции вычищаешь, потому как "не пригодилось", а втрое меньший код легче поддерживать. Да, и такое бывает – но это не повод отказываться от ООП и слоёв абстракции вообще.
teemour
00.00.0000 00:00+1Проблема в чём, в том что отладка неудобная? Ну поколениями отлаживали `printf`ом и как-то жили. Такой феномен
gazkom
00.00.0000 00:00+3Я пишу программы с 1988 г. и с тех пор отлаживал их только в отладчике (интегрированном с редактором, т.н. IDE) с брейкпойнтами и пошаговой отладкой. Могу вас уверить, что это удобнее, чем printf, и "пококления" не отлаживают через printf
aamonster
00.00.0000 00:00+5Иногда сталкиваешься с ситуациями, когда отладчиком не подлезть или он слишком сильно влияет на работу программы...
Ivan22
00.00.0000 00:00+215 лет уже отлаживаю sql процедуры на сотни строк без всяких отладчиков. Никаких особых проблем не испытываю
Tzimie Автор
00.00.0000 00:00+1Я тоже.
dnbstd
00.00.0000 00:00А позвольте поинтересоваться вы эти отлаженные процедуры до сих пор скриптами в базу пишите?
Tzimie Автор
00.00.0000 00:00У меня была на прошлом месте созданная мной для себя jenkins джоба типа 'apply to all servers'. Она шла по списку серверов (около 400, список динамический, синкался с Vmware) и делала sqlcmd -S %server% -E -i script.sql
Скрипты не относились ни к какому продукту так как были DBAшными - rчасто корректировка процедур сидящих в msdb для adaptive index defrag/reorg итд
dnbstd
00.00.0000 00:00Я так понимаю вы предварительно проверяли скрипты на тестовом окружении? И не думали об откатах? Согласен подход рабочий с некоторыми но. Но почему например не развить подход в сторону liquibase , flydb?
Tzimie Автор
00.00.0000 00:00Но вообще такие вещи были не очень критичны. Ну не пройдет index rebuildв один день, в другой нагонит
aamonster
00.00.0000 00:00Я так понимаю, sql вообще не особо заточен на использование отладчика? (Зато у вас REPL есть).
Да и сотни строк – это, откровенно говоря, не дофига. При таком объёме и на C++ профит от дебагера не столь велик.
Ivan22
00.00.0000 00:00+1а больше 3-4 сотен - уже стоит разбивать на несколько.
aamonster
00.00.0000 00:00Безусловно (собственно, даже меньше, обычно пара экранов – более чем).
Но в крестиках даже это не спасает от использования дебагера: обычно ведь не погоняешь функцию саму по себе. Разве что вы сферический адепт TDD в вакууме, который действительно спроектировал всё под юнит-тесты, передавая в каждую функцию всё окружение и сделал моки для всего, что ей может потребоваться.
miksir
00.00.0000 00:00+2Как же любят старички вспоминать про KISS. Но принцип то не о том, что "делай как можно проще", а о том, что использовать и обслуживать механизмы должно быть просто. Сделал пуш, нажал кнопку - раскатилось, нажал другую - откатилось, вот KISS, и вся работа девопсов как раз про это. А то, что там под капотом кнопки десятки технологий - это именно то, что обеспечивает дальнейшую эксплутационную простоту.
outlingo
00.00.0000 00:00+1под капотом кнопки десятки технологий - это именно то, что обеспечивает дальнейшую эксплутационную простоту
Десятки технологий - это то, что обеспечивает эксплуатационный ад.
Макаронный монстр, связанный через костыли, хуки и настройки сделанные мышкой в веб-интерфейсе, с разваливающимися процессами из-за того, что в очередной версии одного из компонентов убрали «устаревшие и ненужные механизмы» на которые девопсы завязали свои пайплайны.
PsyHaSTe
00.00.0000 00:00+1Расскажите как сделать одну кнопку "сделай хорошо" без эксплуатационного ада, пожалуйста.
VVitaly
00.00.0000 00:00Кнопку "сделай хорошо" хорошо сделать не получится никакими существующими или будущими технологиями, это не вопрос технологий. Странно что это нужно кому то объяснять... И люди убеждающие вас что - "счас все будет", сознательные (или нет) мошенники.
PsyHaSTe
00.00.0000 00:00+1Странно, а вот наш девопс нам такую кнопку сделал и мы крайне довольны.
Ndochp
00.00.0000 00:00И вы ее жмете и когда прод упал, и когда пользователи новую фичу просят, и когда старую вернуть хотят и когда денег до зп не хватает?
Наверное эта кнопка пивопровод включает.PsyHaSTe
00.00.0000 00:00-1Вообще сейчас даже кнопки нет, все автоматически уезжает и раскатывается куда нужно. мы как разрабы просто пишем код, девопс пьет смузи и тратит свободное время как ему нравится. Бизнес доволен потому что фичи приезжают быстро и простоев нет. Жаловаться не на что.
gmtd
00.00.0000 00:00+7Как-то пришел на проект в европейскую компанию, которая аутсорсила его индийским разработчикам. Так вот развертывание релиза на dev, staging или prod один облачный сервер занимало сутки и требовало работы 1-2 девопсов
30 строчек yaml кода для GiHub Actions уменьшило время развертывания до 2 минут и сделало ненужной команду девопсов и их менеджеров, за что GiHub Actions и прочим Дженкинсам.
Это я к тому, что DevOps - это просто инструмент. Им можно пользоваться правильно/хорошо, а можно неправильно/плохо. Последнее можно делать со злым умыслом, а можно "по незнанке"/небрежению
Есть девопс инженер, а есть хитрожопый девопс инженер, как и во многих других областях. Программист может два дня делать задачу, которую он же может сделать за 2 часа, если понимает, что его не проконтролируют. Как-то так
gmtd
00.00.0000 00:00+15Вы никогда не задумывались, что net effect от всех действий DevOps - это перенос файлов из одного места в другое (иногда в несколько мест). То есть команда copy (cp) с рядом условий?
Не в контексте, но справедливости ради все эти ваши компьютеры/интернеты/AI/IT это в 99.99% случаев перекладывание информации из одного места/регистра в другое. То есть команда copy (cp) с рядом условий. Фишка именно в условиях.
engin
00.00.0000 00:00Понимаю автора, как посыл в сторону староверов язычников (традиционных скрипт кодеров) заглянуть в будущее и внести свой вклад к приближению с настоящим, строить новые DevOps инструменты...?
korob93
00.00.0000 00:00Сам факт наличия скриптов сборки и развертывания - огромный плюс. А версионирование их - логично, как и версионирование кода. Использование инструментария и машинерии, естественно, зависит от проекта. Где-то и пару строк на bash/powershell достаточно черкануть, и то в качестве документации потомкам, где-то разумно докер образы собирать и разворачивать. Где-то вообще достаточно rsync на боевой сервер (не сильно боевой, конечно, тем не менее бывает и такое). А где-то да, Jenkins агенты спавнятся в облачном кластере кубера, собирают пачки микро сервисов и раскатывают это дело по пачке датацентров. Так что дженкинс, шуршащий в докер контейнере, который крутится в кубера, - не шутка даже ни разу
support917
00.00.0000 00:00+9Новое поколение уже не знает, что можно просто выделить файлы и перетащить мышкой по ФТП - и деплой готов.
Ну ок, еще 1 человек нужен в штат, чтобы поддерживать 1 строку кода, которая открывает порт, через который это приложение увидит свет (все 0 пользователей).
randomsimplenumber
00.00.0000 00:00+2A eсли приложение немного сложнее чем helloworld.php? Если нужно много файлов раскидать на много серверов? А если на некоторых серверах что-то пошло не так?
Можно напилить своих костылей, можно взять готовые;)
>>все 0 пользователей
Для localhost решений не нужон етот ваш девопс, конечно;)
support917
00.00.0000 00:00+12Сейчас реальность такова, что работа нормального (не ряженого) сисадмина в основном заключается в том, чтобы вычистить все эти кластеры и кубернетисы, которые оставили после себя девопсеры и разместить все на 1 сервере, как это было до нашествия.
Я не отрицаю, что у пары процентов проектов действительно есть нужда в репликации, балансе нагрузки, очередях, многопоточности и тп.
iig
00.00.0000 00:00+1работа нормального (не ряженого) сисадмина в основном заключается в том, чтобы вычистить все эти кластеры и кубернетисы
Это задача для системного архитектора. Одмин over-over-qualified детектед. Он наверное и программист заодно, сам всё напишет, и на халявный хостинг по ftp зальет.
JuriM
00.00.0000 00:00+1Такая картина больше подходит стартапам или небольшим конторам, где нет понимания роли айти. Обычно там каждый приходящий админ переделывает все под себя как ему больше нравится.
support917
00.00.0000 00:00+3Крупные компании с их высоконагруженными сервисами - вершина айсборга, там работает небольшой процент людей. Я же пишу про проекты, которые обрабатывают 0-1000 заказов в день, именно там работает среднестатистический админ.
Лет 6 назад девопсеры окучили весь крупный бизнес и начали продавать свои решения и экспертизу микро- и среднему бизнесу. Продавать и куда-то пропадать. А бизнесу надо как-то дальше работать, это реальная проблема по откату назад.
grumbler70
00.00.0000 00:00Ну и вторая проблема, до кучи. Появились толпы "девопсов", которые тупо не знают, как простейшую статическую веб страницу без кубера разместить .
Они это не умеют! И не хотят учиться, для них это видите-ли это "олдскул" и не по феншую.VVitaly
00.00.0000 00:00Они же без докера и простейший софт установить (а тем более сконфигурить) не могут... :-)
dnbstd
00.00.0000 00:00Коллеги то вам как мед "неправильные" девопсы попадались. Правильным - без разницы докер это или не докер. А некоторые даже strace иногда расчехляют. То что пришло поколение после курсов (в основном 2000+ года рождения) которые хотят миллионы и ничего не делать и учится тут я с вами согласен. Не раз собеседуя на таких нарывался.
VVitaly
00.00.0000 00:00Дело не в том "кто попадался", а в пропагандируемой идеологии - "контейнеры наше все и серебряная пуля". В топике как раз и пытаются объяснить что это в принципе не верно...
dnbstd
00.00.0000 00:00-1Ну ради юмора замерь время сколько ты руками раскатываешь что то сродни пускай Apache NIFI и за сколько подымешь в докер компоузе. Я не спорю что контейнеры - не панацея. Но все таки все забывают что контейнеры это просто быстрый и удобный способ доставки и упаковки приложений. Современный аналог нсиса и далее-далее-далее. Так что утверждение автора как и ваше спорно, хоть от части и не лишено смысла.
VVitaly
00.00.0000 00:00А вот "не ради юмора" а для получения максимальной производительности под определенный профиль нагрузки вы сколько будете этот контейнер настраивать? И сколько времени потратите на изучение "тонкостей настройки и особенностей функционирования" всех компонентов данного софта в контейнере?
Так вот время "разворачивания" на фоне всего остального вам будет уже "не интересно"...
Хотя конечно "можно и микроскопом орехи колоть"...
Ну типа микроскопы вот они "под рукой" и недорого, а молоток нужно искать, да и специалисты которые с ним работать умеют не дешевые... :-)
dnbstd
00.00.0000 00:00+3Опять же спорно, большинство контейнеров снабжено хорошей докой, да и докерфайл зачастую хватает почитать. Насчет тонкой настройки - контейнеры не отменяют чтения доки по соответсвующему софту. Принцип х*як х*як в продакшен зависит от специалиста, но никак к применяемой технологии. Будь то вм, iac, контейнеры, ката контейнерс и так далее. Еще раз повторюсь я не сторонник пихания всего в контейнеры, только когда это оправдано. И не сторонник распила монолита, если монолит не реальный Франкенштейн из костылей и велосипедов.
wolfy_str
00.00.0000 00:00+1Почему именно php? почему явно указываете, что это именно PHP или Python в 90% случаев? Можно helloword написать на Java (Kotlin и Scala не в счёт, это подвиды языка Java) или на C++ (Go и Rust соответственно новые подвиды С++ более современные), или на C#. Просто явное указание на php говорит что как бы человек знает только php.
Если говорить про java devops'a он может быть один и пригодиться при развитии тех же скриптов и проектов.
CrzyDocTI
00.00.0000 00:00-2Потому что php стало нарицательным, жаль все забывают почему именно - php был простым как палка и в своё время позволял справляться с задачами где другие не вывозили по производительности, но именно из-за простоты и распространённости бизнес начал пытаться экономить... в итоге сотни тысяч обезьян такую фигню на нём пишут... Вообщем то что на языке удобнее и быстрее всего написать фигню - не делает его плохим, но об этом уже не упоминают.
support917
00.00.0000 00:00PHP в свое время просто показал людям кратчайший путь, как встраивать динамические компоненты в статический HTML (типа как VueJS сейчас) и так первым среди конкурентов принес пользу бизнесу.
Скоро современные NOCODE или LOWCODE приложения тоже обзаведутся своим PHP.
CrzyDocTI
00.00.0000 00:00мб это тоже сыграло свою роль в популярности, но основа все таки другая. аргументы:
1) chatGPT
PHP стал популярным благодаря своей простоте в изучении и использовании, богатой документации и огромному сообществу разработчиков. Он также легко интегрируется с различными базами данных, позволяет быстро написать динамические сайты и открывает много возможностей для создания веб‑приложений. Кроме того, PHP является бесплатным и доступным на большинстве серверов, что делает его привлекательным выбором для многих веб‑разработчиков2) куча ссылок с первой страницы и все об одном - легко посадить любого новичка и получить хоть какой-то результат:
Одной из главных причин, почему PHP лидирует в веб-разработке, является его простота и доступность
Его считают плохим те, кто на нём не пишет, либо, кто столкнулся с некачественным исполнением поставленной задачи. Те разработчики, кто не стремятся изучить документацию языка и не следуют рекомендациям, пишут на нём действительно очень слабо. Это бросает тень на всё сообщество. PHP — язык с низким порогом вхождения. Это одновременно сильная и слабая его сторона
ПС. забавно будет если это тоже заминусуют за "неконструктивное общение" =)zaiats_2k
00.00.0000 00:00+1>стал популярным благодаря {...} огромному сообществу разработчиков.
Аплодирую гепетешечке стоя.
dnbstd
00.00.0000 00:00+4Хм а вы «старое поколение» до сих пор считаете ftp безопасным протоколом?
support917
00.00.0000 00:00Если SFTP - вполне
saboteur_kiev
00.00.0000 00:00+2SFTP вообще не наследник FTP
support917
00.00.0000 00:00-2А FTPS - да. Ваш ход?
saboteur_kiev
00.00.0000 00:00и FTPS страдает, потому что не рассчитан на безопасный обмен секретами.Сейчас в большинстве рекомендаций помечен как obsolete, хотя и передача данных зашифрована.
isden
00.00.0000 00:00Скажу вам по секрету, в некоторых местах еще даже tftp используется. Так что зависит от требований.
Ilusha
00.00.0000 00:00И счастлив, что «это» ушло в прошлое.
Прекрасно, когда одна строчка лежит в гитхабе/etc, по коммиту запускается action, который выполняет скрипт копирования файла на сервер. И секреты лежат в этом гитхабе. И все самодокументированно.
Hadagan
00.00.0000 00:00+2Для понимания девопса написана книга: "Проект феникс". В которой очень хорошо описывается как DevOps влияет на бизнес.
support917
00.00.0000 00:00+1Если от чего-то есть реальная польза, для объяснения этого не надо писать целые книги.
jaroslau
00.00.0000 00:00-1Взять, например, хирургию. Да?
support917
00.00.0000 00:00+2"Как хирургия влияет на тело" - думаю, нет смысла писать такую книгу, все и без нее понятно.
ruslan_sverchkov
00.00.0000 00:00+2Было бы не надо, если бы люди имели мнение только в тех вопросах, в которых они компетентны. В реальности мы почти ничего не знаем, но имеем мнение по любым вопросам от геополитики до вирусологии, а иногда даже транслируем его в этих ваших энторнетах, вызывая такие вот срачи)
punilki
00.00.0000 00:00+19Прочитал, впечатлился.
Пойду удалю свои IaC, буду накликивать инфрастуктуру руками, ведь инфра в облаке должна хранить тепло человеческих рук, а не бездушность пайплайна. Ну и что, что это занимает в 10 раз больше времени и повышает вероятность ошибки.
Еще думаю поудалять весь ci/cd - он нарушает принцип kiss и вносит сложность в доставку. Пусть собирают руками, это не сложно и занимает всего день, вместо 10 мин, зато имеет встроенный тимбилдинг.
Ну и вишенкой думаю, будет отказ от облаков. Оттуда все эти девопсы полезли фантомные. А нужен возврат к корням - серверу под столом секретарши и админам в свитерах.
JuriM
00.00.0000 00:00Да, и весь код хранится на фтп на этом сервере у секретарши. Гит это сложно и непонятно
tommyangelo27
00.00.0000 00:00+12Зачем гит, когда есть:
Новая папка
Новая папка (1)
Новая папка (1) (1)
dev_bak
dev_bak_
dev_bak_20230809
Kirgod
00.00.0000 00:00+1Не забудь удалить вебхуки, если, вдруг, у тебя не так как у автора, и не надо ручками запускать Дженкинс джобу после гит пуша. Ну или в gitlab/github удалить триггеры, пускай все запускается только ручками, не зависимо какой бранч. Автор либо действительно сталкивался с плохой культурой ДевОпса (по его примеру это более вероятно), либо просто не нравится что кто-то тоже зарабатывает не 100 рублей в час. (Сталкивался и с таким)....
uhf
00.00.0000 00:00Проблема DevOps в их силе.
Если всё делать руками, человек рано или поздно устанет от рутины, начнет ныть "сложнаа", однажды потеряет бдительность, допустит ошибку, от которой всё сломается и рухнет, и это вынуждает следовать KISS.
DevOps позволяет относительно легко автоматизировать очень сложные операции. Да, один раз придется попыхтеть, написать скрипт, настроить робота, но потом он работает безотказно. Поэтому про KISS и не вспоминают, пока не нужно будет что-то поменять, или не придет другой DevOps.VVitaly
00.00.0000 00:00+1И работает у нас робот, и горя не знаем... Но вот беда, вдруг сломался, а разобраться почему (у него же 100 составных частей и в каждой мы не разбираемся) не получается... А все стоит без него... :-)
uhf
00.00.0000 00:00-1Робот хотя бы вот он, поддается ремонту и реверсу, а вот если админ внезапно пропадет?
VVitaly
00.00.0000 00:00Ну для нормальной документации по процессам ремонт и реверс инжиниринг обычно не требуется.... :-)
mayorovp
00.00.0000 00:00Ну да, ну да, поддаётся...
Столкнулся недавно с падением пайплайна там где не ждали — на команде agt-get update, которая начала ругаться на некорректные подписи. И всё, никакой возможности отладить: локально всё работает, а единственная доступная информация об образе системы на котором apt-get update падает — это строка CACHED в логах docker build.
И всё, этот образ никак из недр докера не вытащить.
Tzimie Автор
00.00.0000 00:00А если войти интерактивно в консоль?
mayorovp
00.00.0000 00:00В какую консоль? Чтобы войти в консоль интерактивно, нужен контейнер. Чтобы запустить контейнер, нужен образ. А образ хранится где-то внутри кеша Buildkit (даже не в общем хранилище образов докера!), всё что о нём известно — это строка "CACHED" в логах сборки.
uhf
00.00.0000 00:00Я в докере не эксперт, но попробовал. В старой версии докера базовый образ скачивается в общее хранилище. В новой не скачивается, но в лог пишет хэш, по которому его можно стянуть.
mayorovp
00.00.0000 00:00Это при отключенном Buildkit, при включенном он пишет только "CACHED".А, понял про что вы. Так я базовый образ-то себе тоже скачал, на нём баг не воспроизводится. Воспроизводится он только после копирования файлов, причём только в кешированом Buildkit слое.
JackKatch
00.00.0000 00:00Поддерживаю. Всё что может быть понято неправильно именно так и будет понято. И это сейчас везде.
mirwide
00.00.0000 00:00+4Люблю всем напоминать, и в работе и тут на хабре иногда пишу, что любое изменение архитектуры, добавление функционала должно иметь цель. А масштаб измений должен быть соизмерим с пользой которую он приносит.
DevOps, в данном контексте, это обычная разработка. Если в какой-то компании выбираются продукты и решения несоизмеримые с масштабом задач, это не проблема DevOps, это проблема реализации. Конкретной компании, людей которые купились на красивые слова или решают свои задачи, усложняя жизнь другим.
Для сферического коня в вакууме, у версионирования скриптов из примера статьи должен быть заказчик, RFC в котором принято решение делать так. Впрочем, это плохой пример, потому что любой код больше пары строк должен быть в гите или аналоге и версионироваться. А вот какая часть инфраструктуры должна быть как код, это уже спорный вопрос, ответ зависит в первую очередь от ее размера и скорости измений. Когда это 2 железных сервера БД, которые обновляются раз в 3 года, это одно. А когда тысячи ВМ/контейнеров, где за день меняются сотни из них, всё что перечислено в статье не оверхед, этого уже не достаточно.
mgis
00.00.0000 00:00+1Все что нужно знать о DevOps в моей картине мира.
Вот я условный разраб низшего звена который пишет пет-проект. Я знаю, что есть Docker-Compose и мне его достаточно.
А когда будет недостаточно, то мой проект уже принесет достаточно денего чтоб нанять хорошего Devs-Op менеджера. А пока эти времена не наступили, мне хватает просто Docker-а.punilki
00.00.0000 00:00И вы будете абсолютно правы! Во-первых, используя докер, во-вторых нанимая дев-опс инженера, правда, а не менеджера, вам же делать что-то надо, правильно?
Только обычно девопс нужен тогда, когда уже есть команда а то и несколько и которым нужны площадки для разработки и тестирования. По опыту могу сказать, что при должном планировании и квалификации девопс инжененера вы получите:
- решение задач SRE - устойчивость продакшн системы, мониторинг-алертинг (работающие!), снижение затрат на инфрастуктуру и развертывание, улучшение качества услуг клиентам
- решение задач разработки - добавление новых сервисов быстрее и безболезненнее, минимизирован человеческий фактор, ваши сервера переходят из pet-режима (любимец, не трогать иначе боль!) в cattle (жги ломай все равно новые за минуты поднимаются а вся инфа в gitops и видны все изменения).
- ваши инженеры повышают техуровень, осваивая к8с и новые тулзы, с удовольствием тыкают на трейсы и залипают на графики. Они видят результаты работы и изменений и это мотивирует! Нет рутины и у них, они делают свою работу а не ждут пока что-то там настроится и починится из-за случайно перепутанного порядка деплоя.
в итоге это позволяет и вам сосредоточиться на разработке, на вашем бизнесе, а не заниматься инфраструктурой и саппортом инженеров.И это не сферический в вакууме пример, это реальная история, наблюдаемая мной лично и не один раз.
А так можно и кабелеукладчиком в квартире ночник подключать, я думаю, тоже будешь немного разочарован.
geher
00.00.0000 00:00+2Проюлемы этого вашего девопс начались в основном именно тогда, когда его назвали девопсом и стали трубить о нем на каждом углу, поскольку начался массовый девопс ради девопса.
Где просто спецов переименовали по новому, или где все выстраивают квк нужно , а не как модно, там обычно все нормально. А вот где начинаются менедженерские метания в стиле "у всех девопс, а у нас его нет, срочно выстраиваем девопс", там обычно и начинается кошмар. Предельный случай - выстраивание структуры девопса в микроконторе с пллутора разработчиками, пилящими программку для локального использования.
Ilusha
00.00.0000 00:00+1DevOps изначально - это просто культура взаимодействия разрабов и админов.
Появление devops-инженеров - это следствие этого процесса. Синергия девов и опсов родила множество инструментов и подходов для решения задач автоматизии процессов под нагрузкой. И это стало слишком сложным, что потребовало нового класса специалистов.
Для микроконторы есть свои инструменты, а для крупных - свои. Мне повезло: не видел менеджеров, которые думают об инфре. Кмк, вы говорите больше о низкой квалификации подбирающих и внедряющих те или иные инструменты.
kompas_3d
00.00.0000 00:00+1Nero Burning ROM в своё время из-за этого загнулась)
iig
00.00.0000 00:00+2Загнулась она не от переусложненности. Необходимость прожигать CD как то пропала. Да и бесплатные аналоги подьехали.
Возможно, менеджеры как раз и затем сделали суперкомбайн - нет необходимости прожигать диски - пусть хоть плеер будет.
kompas_3d
00.00.0000 00:00Сначала подъехали бесплатные аналоги, которые делали тоже самое, что делала первая версия Nero, а только потом уже пропала необходимость (через несколько лет).
jaroslau
00.00.0000 00:00А меня одного в анамнезе смущает Chef? Он тут даже в тэгах. Я повидал немало всякого, но чтобы что-то в облаках Chef-ом создавали, ещё ни разу.
kpmy
00.00.0000 00:00-1Вы не совсем верно понимаете, изначально задумка была в том, что DevOps это не позиция, а роль одного из разработчиков.
Соответственно, yaml-пайплайны и деплой-скрипты под разные окружения готовит тот, кто лучше всего знает, как запускать своё ПО.
Простой пример, классические админы до сих пор не поняли ценность Service Discovery, продолжают просить мануалы по конфигурированию конкретных инстансов. Ну а раз не поняли, значит не нужно. Очень "классическая" позиция.
Ilusha
00.00.0000 00:00+2Не было такой задумки. DevOps - это было про культуру взаимодействия девов и опсов с определенной общей ответственностью за то, что все работает.
К сожалению, сейчас мало об этом говорят.
Но, да - девы описывают запуск (например в виде докерфайла и прочим), опсы помогают с требованиями к приложению, формой и форматом конфигурации и т.д. Работают сообща на всякими метриками/логами/трейсингами.
fomiash
00.00.0000 00:00Совсем недавно оформил некоторые мысли по этому поводу в небольшую заметку. Определенно, есть смысловое пересечение с этой статьёй.
dnbstd
00.00.0000 00:00Прочел.Отвечу - вы забываете что инженер владеющий практиками DevOps тоже умеет писать код и даже порою не на одном ЯП, но почему то все упорно толкают их именно в сторону ops.
fomiash
00.00.0000 00:00У них сейчас по части Ops работы очень много, по крайней мере часто слышал жалобы, что на вакансии никто не откликается, один работает за троих, а для разработки все-таки важна постоянная практика, а не только знания как писать код (впрочем эти правила тоже видоизменяются со временем).
Так что этому действительно не придал большого значения. Для написания скриптов различных автоматизаций знаний должно хватать как минимум. Дополнительно закрывать задачи разработки - не встречал такого.
dnbstd
00.00.0000 00:00Из моего будничного - давеча написал api утилитку на go для автоматизации получения сетевых доступов. Но есть много и ops задач, согласен. Все больше сталкиваюсь с тем что разработка умеет писать код, но не понимает как работает определенная бд и архитектурные вопросы в целом. Мой любимый пример очереди в redis. Так что коллеги тут монета ребром как говорится.
r3code
00.00.0000 00:00+1Это про как делать не надо пример.
Нормальный проект начинает с MVP для проверки идеи, а по ее подтвержении развивают итеративно.
Сделай хорошо, а не круто.
И многие не понимают, что разработка ПО это такое же производство, тот же завод ,а процесс разработки - внесение изменений, доставки - конвеер. И на разных участках непрерывность поддерживают разные люди.
Можно плитку из цемента самостоятельно делать штучно, а можно тысячами и разные варианты - и ресурсы и проблемы будут разные.
abaz20
00.00.0000 00:00+4Аналогичную картину наблюдаю в QA. Уже лет 10 в разных компаниях, где я работал, все пытаются запилить автоматическое тестирование клиентских приложений, выделяют кучу ресурсов а толку 0. Все критические ошибки находят в итоге пользователи продакшена, т.к. некому было тестировать, все тестировщики занимались написанием автотестов или починкой устаревших.
DeoxyribonucleicAcid
00.00.0000 00:00Видимо автор столкнулся с тем что в большой компании для простой задачи его заставляют делать так как правильно, а не так как быстро. По тексту статьи гиперболизированное сравнение которое можно провести во многих сферах.
sved
00.00.0000 00:00-3Для меня кстати до сих пор немного загадка, что конкретно делают девопсы.
Настроить CI/CD - этим всю жизнь девелоперы занимались. Если приложение нормально написанно, то достаточно в пайплайне тупо дёрнуть пару граделовских тасок с каким нибудь профилем.
Есть предположение, что девопсы настраивают кубернетис и подключают сторонние сервисы, а остальным занимаются админы. Подправьте, кто больше в теме.
Иногда встречаются целые команды которые вообще непонятно чем занимаются.
Так у нас в одной конторе была midleware team. С нашей точки зрения, единственная задача которых была это: задеплоить war-ник и прислать логи. Зачем для этого нужна дополнительная команда - до сих пор не понятно.
Справедливости ради девелоперы тоже часто любят усложнять, особенно неопытные.
saboteur_kiev
00.00.0000 00:00+2Настроить CI/CD - этим всю жизнь девелоперы занимались. Если приложение нормально написанно, то достаточно в пайплайне тупо дёрнуть пару граделовских тасок с каким нибудь профилем.
Когда у вас большой проект, настолько большой, что настройка CI/CD и инфраструктуры под нее занимает полный рабочий день, девелопер уже не сможет этим заниматься параллельно с разработкой.
Ну и под сложные или просто большие проекты появились свои инструменты оркестрации, управления, мониторинга. Ближе всех тут сисадмины, которые собственно и переходят в девопсы.
Таким образом DevOPS - это культура и методология работы в проекте
DevOps инженер - сисадмин, который работает там, где идет разработка продукта.
То есть одна из специализаций сисадминов.Есть же сетевой админ - сисадмин, который работает там, где занимаются коммуникациями (провайдер мобильной, проводной или телефонной и др. связи)
Есть сисадмин какого-нить крупного провайдера, где предоставляют виртуалки или облачные ресурсы, там кластера, датацентры, железки, виртуализация.
Есть сисадмин широкого профиля - который работает там, где надо управлять инфраструктурой не IT компаний. Всякие активдиректории, файловые шары, управление пользователями, возможно виртуальные десктопы, подключение офисов, корпоративные ноутбуки/антивирусы, etcПод этим всем есть еще сисадмины, которые не ушли в специализацию, ибо конкретная позиция не требует много знаний. Хотя там тоже может быть уход аутсорс, когда контора берет на себя обслуживание какой-нибудь компании и предоставляет своих профессиональных админов, которые быстро настраивают надежные и простые (возможно шаблонные) архитектуры.
Про эникейщиков я не говорю.
sved
00.00.0000 00:00Когда у вас большой проект, настолько большой, что настройка CI/CD и инфраструктуры под нее занимает полный рабочий день, девелопер уже не сможет этим заниматься параллельно с разработкой.
Вот это для меня всегда было загадкой. Это до какого состояния надо довести проект чтобы настройка CI занимала целый день. Тут не девопсы нужны, тут нужен Геракл, чтобы вычистить Авдиевы конюшни.
Я видел большие и сложные проекты, но так чтобы надо было целый день настраивать - это нечто.
Если речь идёт про настройку окружения (скажем сервисы для функционального тестирования), то это должно быть автоматизировано и этим занимаются девелоперы (ибо они должны поднимать так же и дев окружение)
Ilusha
00.00.0000 00:00-1«день» для разраба, обмазавшись документацией и стековерфлоу. Пара часов девопсу.
saboteur_kiev
00.00.0000 00:00+1Вот это для меня всегда было загадкой. Это до какого состояния надо довести проект чтобы настройка CI занимала целый день.
Ну вот проект, 10 команд, свыше ста компонентов.
Постоянно появляются новые, декомиссятся старые.
Появляются задачи вроде обновить операционку. Надо согласовать со всеми командами совместимость, обновить дев, проверить что не попадало, обновить уат, обновить прод, для этого возможно нужны дополнительные разрешения, аппрувалы, ибо каждый енвайрнмент - это сотни машин.
Вот уже на неделю-две работы.
mayorovp
00.00.0000 00:00Вот это для меня всегда было загадкой. Это до какого состояния надо довести проект чтобы настройка CI занимала целый день.
Да тут и доводить не надо, недавно я настраивал Sentry на очень небольшом проекте — полтора дня заняло. Просто потому что использовался свой раннер для гитлаба с docker executor на умирающем под нагрузкой HDD, из-за чего каждый тестовый запуск пайплайна обходился в полчаса.
koreychenko
00.00.0000 00:00+1Не, ну можно и так, как автор написал, конечно.
Однако, нормальный девопс-специалист деньги экономит в основном не тем, что автоматизирует деплой. А тем, например, что знает как и где разместить приложение, чтобы это было дешевле. Какие стораджи юзать. Или, например, вот у AWS можно поднять свой контейнер с каким-нить RabbitMQ, а можно использовать готовый SQS, где первый миллион запросов в месяц бесплатно, а потом тупо дешево. Получается дешевле, чем кролика поднимать, но приложение должно это поддерживать. Или опять-таки, девелопер взял бы и арендовал выделенный сервак (потому что это головой понятно). А девопс говорит, а давайте возьмем Spot Instance у AWS - будет дешевле. Но тогда всё приложение должно быть stateless, во-первых, и уметь выключаться за 2 минуты (кажется), во-вторых.
Ну и вот это вот всё. Про умение писать конфиги, которые умеют быстро масштабировать систему в обе стороны это и так понятно.sved
00.00.0000 00:00+1Ну вот так и появляются кривые, неподдерживаемые решения. Задачей выбора сервиса должны занимать либо девелопер, либо архитектор, но уж ни в ком случае не девопс.
но приложение должно это поддерживать
Что должно поддерживать приложение - решает команда разработки на основании запросов пользователей, аналитиков и продуктового менеджера. Подобно тому как они решают эти вопросы на основании запросов клиентов, админы удовлетворяют запросы разработчиков. Клиент, как известно, всегда прав.
Девопс, в общем случае, не обладает необходимым уровнем компетенции чтобы вникать в тонкости применимости того или иного месаджинга в конкретном приложении. Тупое сравнение в лоб - это типичный поверхностный подход. А как там с транзакционостью? Надёжностью? Поддержанием очерёдности? Устранением дупликатов? Хватит ли производительности? Как бакапить? На эти вопросы может ответить только команда, разрабатывающая приложение. Она ещё и исходный код, при необходимости, изучит и необходимые измерения произведёт. Никакой девопс, прочитавший умную статью на хабре, архитектурные решения в продукте принимать не может и не должен.
Кроме того, использование AWS налагает дополнительные сложности как организационного так и технического плана.
Технически это усложняет локальное тестирование. Организационные - это вендор лок. За создание вендор локов вообще надо увольнять ИМХО.
Я вот кстати вообще сомневаюсь, что использование сервисов облака может быть дешевле опенсурсного софта. Непонятно, за счёт чего может быть доступна эта дешевизна. Не будет же Амазон себе в убыток работать? Тут явно какой-просчёт и что-то неучтено. Я как-то сравнивал стоимость транскодинга, используя сервисы амазона и используя ffmpeg внутри EC2. Свой транскодинг выходил в 10 раз дешевле
PsyHaSTe
00.00.0000 00:00Я вот кстати вообще сомневаюсь, что использование сервисов облака может быть дешевле опенсурсного софта. Непонятно, за счёт чего может быть доступна эта дешевизна. Не будет же Амазон себе в убыток работать?
В целом с комментом согласен, но тут явное пердергивание — бизнес это не игра с нулевой суммой.
koreychenko
00.00.0000 00:00А где я написал, что девопс что-то решает? Задача девопса быть в курсе того, что бывает и предлагать команде и бизнесу решение. А поскольку любое решение имеет ограничения их тоже надо озвучить и узнать подходит оно команде или нет.
Сравнивать по цене без SLA не корректно. Например, если тот же условный Amazon гарантирует доступность в 4 девятки после запятой, то расскажите мне пожалуйста как вы такую доступность будете самостоятельно реализовывать? Я не говорю, что это невозможно сделать самостоятельно. Я про то, что с большой вероятностью ваше решение не будет прям-таки сильно дешевле Амазоновского при схожих SLA - физику не обманешь.sved
00.00.0000 00:00Задача девопса быть в курсе того, что бывает и предлагать команде и бизнесу решение
С этим можно согласиться. Правда это касается любой профессии. Если тестер или аналитик что-то предложит, то почему нет?
гарантирует доступность в 4 девятки после запятой
Практика показывает, что эти цифры и яйца выеденного не стоят.
Не знаю сколько знаков Mongo гарантировала, но внезапно её сервисы стали для некоторых пользователей просто недоступны. Включают ли эти дутые цифры банкротство компании? 20-икратный рост цен? Просроченную кредитку? Уничтожение подводного кабеля?
Ещё раз повторюсь: крупная компания и уж тем более госконтора не может себе позволить себе зависеть от одного вендора. Это неоправданный риск, учитывая, что никакой технической необходимости в подобной зависимости нет. Даже если мы пишем на дот-нете.
Что касается доступности, основное положение теории надёжность - надёжность обеспечивается дублированием и современные разработчики прекрасно осведомлены с такими вещами как дублирование, репликация, консенсус и пр.. Если будет поставлена задача, то будет и решение.
Вы слишком драматизируете эти сложности ) Гораздо большие проблемы для девелоперов представляет легаси код и расплывчатые требования, а вовсе не чётко определённые технические требования
VVitaly
00.00.0000 00:00Осталось понять еще что гарантируется за эти 4 девятки, уж точно не работа ваших клиентских сервисов... А если ваши клиентские сервисы гарантируют (по разным причинам не связанным с инфраструктурой Амазон) работу не 4 девятки а только одну к примеру, вы уверены что вам нужно с других сервисов требовать (и платить им за) 4 девятки?
shornikov
00.00.0000 00:00+1Если девопс это автоматзация - непонятно, почему это нужно делать каждый день. Пришел, настроил - ушел. Через полгода задачи бизнеса сменились - еще раз пришел.
А если каждый день - это какое-то подмастерье программиста, для решения побочных задач.
saboteur_kiev
00.00.0000 00:00В небольших проектах так и бывает.
Начинается проект с нуля, под него разворачиваются ресурсы. С ростом проекта обрастают всякими штуками, мониторинг, деплой. Потом проект более-менее устоялся, вышел в продакшен, пару раз обновился - все, девопс уходит в другой проект, или параллельно ведет несколько.
Но есть проекты, которые постоянно меняются, постоянно куча задач. Постоянно все куда-то мигрирует, легаси декомссится, новое появляется и все в рамках одного проекта. Там и команда девопсов может много лет работать и работать.
dim111
00.00.0000 00:00А оно и не нужно. Если у вас один стабильный проект. В этом случае можно нанять человека на контракт на год которы за этот год построит процессы и автоматизирует.
Проблемы начинаются когда ваша компания развивается, пробует новые проекты, меняет код и т.д. Тут нужно для каждого стартапа внутри компании автоматизировать что то новое. А так делают почти что все компании которые генерируют прибыль. Потому что деньги надо куда то вкладывать.
seasadm
00.00.0000 00:00+3Девопс это жэ не человек а культура. Статья тупо против автоматизации по ходу.
support917
00.00.0000 00:00Почему именно культура, а не культ?
seasadm
00.00.0000 00:00+2Потому что культ который вы имеете в виду называется карго. И карго культ он не только про девопс.
fillrate
00.00.0000 00:00Что-то в этом есть. В принципе в программировании это уже давно тенденция, когда простые вещи делают сложно. Тут вина не инструментов, а тех, кто эти инструменты так использует. Почему бы не освоить бюджет по переписыванию монолита на микросервисы, пофиксать старые проблемы и огрести кучу новых. Нанять девопсов что б заменили простейший пайплайн в дженкинсе на что-то более современное, версионное, автоматическое и очень крутое. Отгрести еще кучу проблем и соответственно попросить новый бюджет, который тоже будет потрачен на свистелки-перделки, которые потом потребуют своего бюджета на доработки и поддержку. И когда уже кажется, что вот наконец все устаканилось, то приходит новый девопс/архитектор/менеджер и говорит "'это все старое г%вно мамонта, так уже никто не работает, надо переделать. К тому же знаю я тут один фреймворк/технологию/тулу"... Ну и круговорот бюджета запускается по новой. В конце концов, кто-то же должен использовать этот миллион новых тулов, языков, паттернов и новых решений, которые растут как грибы после дождя.
Так что продолжая аналогию автора с calc.exe, программа потихоньку переходит на блокчейн, работает в многопоточном распределенном бигдата кластере с ML алгоритмами и поддержкой сферических коней в вакууме. Ничело личного, просто бизнес.
dimkus
00.00.0000 00:00У человека написавшего эту статью явно нету понимания для чего DevOps вообще нужен и как строятся CI/CD процессы. Другое дело опыт компаний, в которые приходят типа DevOps инженеры окончившие быстрые курсы и приносят свои костыли, тогда получается не разворотливый франкинштейн.
takblet
00.00.0000 00:00так блт
эээ это что ещё за антиреклама?) только я собираюсь (уже который год)) вкатиться в девопс и тут такое
статьямнение, как дальше жить теперь), вы же понемаити какой охват на хабре, сейчас куча людей прочитает ето и всех девоПСОВ на мороз отправят, хотя всё равно весна уже)
irony_iron
00.00.0000 00:00бизнес готов платить за такой процесс, потому что таким образом программист отделяется от интеллектуальной собственности, невозможно предъявить права на то, что обслуживается 10 людьми с черными ящиками на каждом слое. если бы разработчики торговых алгоритмов знали насколько просто устроена платформа торговли, они бы все были ИП
wolfy_str
00.00.0000 00:00-1А торговый алгоритм всегда приносит прибыль? Вот я что то сомневаюсь что АЛГОРИТМ пусть даже в более чем половины случаев + спред (разница) и коммисия брокеру + деньги за перевод денег. То есть в общем случае число правильных сделок при примерно одинаковых покупках, должно быть более 65%, а то и 70%. Но у меня есть ощущение что рынок не на столько сложен как его рисуют. Оптимальная стратегия для новичка это следовать за успешными трейдерами, просто копировать их стиль и делать так же. Так допустим следовать за большинством не следует, но и следовать за теми у кого сотни миллиардов глупо. Ну то есть в моменте это приносит прибыль, но у кого десятки и сотни млрд долларов они просто не торгуют на бирже, а вкладываются в какой нибудь индекс, зарабатывая 5 - 8% в год (!). Для простого трейдера этой суммы прибыли не хватит даже на месяц. Представьте, нужно накопить 10 тысяч долларов, это уже не просто, что бы потом что, зарабатывать 5% в месяц, то есть 500 долларов? На них не прожить. То есть сумма должна быть в 10 раз выше, либо риск должен быть выше в 10 раз. Оптимально чтобы как то жить нужна сумма 50 тысяч долларов и чуть выше риск 8-10% в месяц, и то это небольшие деньги 4-5 тысяч долларов, можно тихонько торговать. Но это как с инвестиционными квартирами) предлагают вложить 10 млн рублей, что бы зарабатывать в месяц 40 тысяч руб))) ну это смешно, что бы заработать 10 млн. нужно что было жильё у родственников, а если сам столько заработал то не будешь сдавать. Вот у меня нет своей квартиры, и таких молодых людей до 35 лет довольно много. кто ипотеку взял, а кто снимает, кто у родственников. А всякие блогеры ну в меру уважаемые, но они в 100% случаев эти деньги либо с имеющегося бизнеса, либо родственники дали, либо по наследству полученное жильё.
tommyangelo27
00.00.0000 00:008-10% в месяц
Мавроди передаёт привет.
wolfy_str
00.00.0000 00:00это немного можно по 30-40% в месяц но риски слить всё намного выше, да и жить придётся трейдинг +плечи использовать. 8-10% это всего 1 раз поймать рост или падение если играть на понижение. 2-3 сделки в месяц. Остальное время можно посветить работе или отдыху. Я о другом даже для того что бы жить на 5-10% в месяц нужен довольно большой капитал. И тем более уделять несколько часов в неделю на него нужно будет.
support917
00.00.0000 00:00Присоединяюсь, пожалуй это единственная видимая польза от всего этого. Устранение диктаторов инфраструктуры и кодовой базы. Только если есть мутная вода поверх мутной воды, бизнес может развиваться, а молодежь имеет шанс запрыгнуть в профессию с 0 багажа опыта после курсов.
artemlight
00.00.0000 00:00+1Всё с DevOps в порядке. Не нужно путать макро- и микроуровень, и всё станет на свои места.
Если у Вас управление релизным циклом существует только в виде "нескольких команд cp", а в качестве среды выполнения крутится десяток (ну пускай даже сотня) виртуалок, то оно вам и в самом деле не надо.
Большая часть аргументов в статье сводится к тому, что Ваш продукт не очень большой, и оверхеды, вносимые собственными девопсами - существенны. Но это ведь касается не только девопсов - даже обычный найм программистов не масштабирует их производительность линейно при совместной работе над одной задачей.
Но вот есть, например, такой комплайнс - в определенном продукте нужно создавать изолированные среды для каждого заказчика, мультитенант не катит. Говоря проще - провайжнить продукт тысячами отдельных инстансов, и менеджить всё это. Скриптами будем делать, или возьмем всё же готовое?
Опять же, деливери - это всегда контейнеры. Нравится, не нравится - ну вот такое оно, сегодняшнее настоящее. Если привыкли править на проде - будет мешаться, а если выстроены процессы быстрой доставки в этот самый прод - будет помогать обеспечивать SLA.
TL;DR: как и любой другой инструмент, DevOps методологию нужно оценивать не для абстрактного, а конкретно для вашего проекта. Экстраполировать же свои проекты на других - плохое хобби.
Tzimie Автор
00.00.0000 00:00Почему это "всегда контейнеры"?
Есть всякая AWS хрень которая сама по себе похожее...
С другой стороны есть высоконгруженные SQL сервера. Голимое железо на максималках, где даже разница SSD и NMVe существенна, там точно сиквель не в докере)
artemlight
00.00.0000 00:00+2Я думаю, что он там не только в докере, а ещё и в виртуалке поверх этого самого докера.
Уже прошли те времена, когда виртуализация\контейнеризация оказывала какое-то существенное влияние на производительность. У докера оверхеда практически нет, у виртуализации - в пределах погрешности (а применительно к БД иногда и напротив выигрыш бывает - потому что кеширование дисковых операций работает чуть интереснее, чем на bare metal). В любом случае, жертвовать 1% производительности ради потери управляемости - нонсенс, железо стоит значительно дешевле времени людей, которые его обслуживают.
Просто гляньте, как на крупных платформах (GCP, Azure, AWS) работает Managed SQL.
Tzimie Автор
00.00.0000 00:00+1Скажите "нет" смузи и цветным носкам. Хотя бы на время. И подумайте, как в production будет работать always on c availability groups и теснейшей завязкой на кластер windows
Пысы. Я нашел что это делают, но оцените длину инструкции!!! Во про это я и говорю!!!
artemlight
00.00.0000 00:00Так вы сравниваете тёплое с мягким. MSSQL в продакшне - это а) ни разу не мейнстрим, market share MSSQL сервера около 15% всего (пруф), б) MS не планирует развивать это направление, упор идёт на cloud-native \ managed SQL, а onprem не растёт (с учетом инфляции - читай, падает - пруф).
А разгадка проста - нищий рынок труда. Средняя зарплата системного администратора в мск - 52 тысячи рублей (пруф), это меньше 5 долларов в час. И это в 8(!) раз меньше, чем в США (пруф), на чей рынок, собственно, и целятся крупные клауд провайдеры. Так что в среднем по больнице в РФ выгоднее нанять 10 администраторов, а в США - одного девопса и managed сервисы. Это, кстати, более-менее бьётся с моим собственным опытом.И справедливости ради - не всё так однозначно (с). Низкая стоимость фонда оплаты труда разработчиков в РФ позволяет делать недорогие и качественные сервисы. Но формально это экстенсивный путь развития, со всеми свойственными ему ограничениями.
Tzimie Автор
00.00.0000 00:00+1Ну во первых, я MSSQL server DBA. И мест, где он стоит - очень много. Да, сейчас в России идёт переток на Постгре по понятным причинам, но это процесс займет годы.
Что касается зарплат... Я тут в HH нашел зарплату в 30 тыс р.) Но это ничего не значит. Я в Питере не знаю никого, кто бы получал меньше 200к (исключая джуниоров)
Tzimie Автор
00.00.0000 00:00И ещё, в России из AWS всех выгнали, а местные облака ещё в стадии младенчества. Ещё есть китайские облака, но они тоже на порядок отстают от AWS
Так что onprem наше все
artemlight
00.00.0000 00:00Ну Ваш персональный опыт ничего не говорит о рынке труда в целом. А он - очень разный, и работают там люди с совершенно разными скиллами. С тем же успехом я могу рассказывать, что не знаю в bay area никого с доходом меньше, чем 300к в год - к рынку труда в США это будет примерно такое же отношение иметь.
Так что за неимением других цифр придётся верить этим.
В целом уход на онпрем - это движение против шерсти индустрии, сознательное упрощение. С некоторых пор такая история много где происходит - в автомобильной промышленности, например. Наращивание технологического отставания - это крайне грустная история, и она аукнется далеко за пределами ИТ-сферы в целом.
Tzimie Автор
00.00.0000 00:00Ну вот я работал долго в американской компании. Они тоже как то хлебнули смузи и решили уйти в облако. Но посчитали и ужаснулись
Не все в мире web, а когда нет эластичности, и у вас определенное количество серверов должно тупо работать 24/7 то AWS дороже (а с учётом multiAZ - в разы дороже)
Refridgerator
00.00.0000 00:00+1Лучшая статья от автора, несмотря на моё к нему неоднозначное отношение.
Tzimie Автор
00.00.0000 00:00+2Забавно то, что я ее написал в изрядном подпитии. Может мне не стоит писать статьи на трезвую голову?
Refridgerator
00.00.0000 00:00+1Ну, лично я отношусь к алкоголю хорошо. Как и к другим веществам, в том числе и запрещённым. Главное для художника, музыканта, инженера, учёного — это результат. А уж какой ценой этот результат был достигнут — это его личное дело, и никто не вправе осуждать его за это.
alexvvvv
00.00.0000 00:00Госпади. Размышление одного старого программиста о написании одного суперпростого приложения. Ну нет, в таком случае тебе ничего не нужно.
DevOps и весь современный веб это про команды, где человек может поработать месяц или неделю. И ты потом как отследишь логику и последовательность вносимых изменений. Вкинули говна на вентилятор. На хабре новый пиарщик или бизнесмодель создания контента совсем прогнила ?
Все эти подходы - для стандартизации процесса разработки и уменьшения возможности накосячить. Ты попробуй отдай своё почти готовое приложение на выходные разработчику уровня джуна, чтобы он закончил. Без версионирования, дошбордов, версий билдов, тестов и так далее. И доступ ему ещё рутовый на сервера кластера и в само облако...
BorisTheAnimal
00.00.0000 00:00-2Рассуждение либо джуна на мелких проектах либо админа, без maidset разработчика. Тут уже много накидали правильного в комментариях, добавлю еще
Мы получаем версионирование скриптов! Круто же! Никого не интересует, удобно ли это, важно, что это круто и хитро...
Если процессы поставлены правильно, то это будет удобно. Кроме того, чаще всего это продиктовано не тем, что это "круто и хитро", а тем, что это позволяет отслеживать историю изменений, что в свою очередь является требованием безопастности.
Буквально пару месяцев назад сопровождал подписание контракта с клиентом на поставку софта. Крупный банк, контракт на пару миллионов $ каждый год. Так вот версионирование всего, что возможно, включая все скрипты CICD, было одним из обязательных требований.
mayorovp
00.00.0000 00:00Версионирование скриптов делается помещением их в git (или svn). Загружать из курлом — это закат солнца вручную.
BorisTheAnimal
00.00.0000 00:00Я тоже обратил на это внимание и не понял, почему для скриптов нужен Nexus. Но похоже там гита тоже нет.
Загружать из курлом — это закат солнца вручную.
для хранилищ артифактов это нормальное дело. Что для Nexus, что для того же jFrog Artifactory и гугловского Artifact Registry. Они не предназначены для совместное работы или детальной истории изменений, как VC системы - они для хранения билженных версий релизов. И вы можете подтягивать эти артифакты как зависимости к другим проектам. Поэтому нет надобности в git (или svn).
Но почему там именно требуется хранить скрипты в хранилище артифактов - надо смотреть требования, артифакты и в целом их процессы.
Tzimie Автор
00.00.0000 00:00Git там как раз был. Но вместо того чтобы иметь каталог с последней версией скриптов из Гита и использовать их, curl выкачивал скрипты в рабочий каталог Jenkins джобы каждый раз. То есть первой строчкой curl, второй запуск собственно скрипта
Только не спрашивайте почему. Так сказал наш devops.
BorisTheAnimal
00.00.0000 00:00ну возможно и самодурство, но я вам с ходу могу назвать пару вполне легитимных причин такого поведения продиктованными как техническими процессами, так и требованиями локального законодательства(или стандартами индустрии). Надо смотреть и спрашивать.
rebel_scumbag
00.00.0000 00:00-2Девопс - это механик вашей машины. Вам не нужно следить за уровнем масла, давлениям шины, чтобы ездить (
кодить) на ней, даже если вы можете это делать сами. Да, не каждый проект это формула-1 и требует пит-стоп за 10 секунд, но это не означает, что девопс бесполезны. Разница в сложности ремонта жигулей и океанского лайнера как раз и рождает подобную работу.
y9maly
00.00.0000 00:00-2Не знал что такое DevOps, теперь знаю. Мне нравиться. Всегда так делаю, в этом и интерес, иначе превращается в РАБоту
nightvich
00.00.0000 00:00Типичная "ошибка выжевшего". Ну и про DevOps тут нет ни слова, кроме, как самого слова, которое тут не очень уместно.
staticY
00.00.0000 00:00У нас девопсы занимались написанием деплоев, поддержкой и рефакторингом инфры на проде и стейдже, смягчением последствий при всяких падениях и ддосах.
Ну, можно, конечно, самому этим заниматься - но зачем? Почем это раковая опухоль?А иметь разраба, который будет еще знать, как от ддоса отгородиться с помощью возможностей какой-нибудь железяки, которая перед инфрой стоит - это что тогда?
berendiaev
00.00.0000 00:00+2Ну вот лично у меня очень много пессимизма насчёт девопс в целом. Думаю, тенденция ближайшие лет 5 будет в том, что разработчики сами станут строить инфраструктурные решения. Появится для этого какое-нибудь новое название или нет, это уже дело десятое.
Качество девопс-решений, которые я видел за последние годы, в целом довольно низкое. Речи о каком-либо self-service для разработчиков зачастую не идёт. И я вижу причину в том, что девопсы - это чаще всего бывшие опсы, которые в прошлом делали всякую автоматизацию для себя и своих коллег, совершенно не заботясь о 1) надёжности ("сам починю за две секунды если что") и 2) когнитивных затрат на интеграцию ("что я, сам свои скрипты не разберу что ли").
И в итоге получается хуже чем стандартный clickops - например, разрабы сидят и недоумевают, почему нельзя просто взять и обновить какую-нибудь графану - спулил новый контейнер и заменил старый, не? - а оказывается, что для этого надо сделать 5 коммитов в 3 репозитория, по каждому дождаться "обязательного код-ревью" дежурного девопса, плюс ещё выяснится что всё просто так не заработает и девопс должен подшаманить, и в конечном итоге ещё и упадёт раскаточный пайплайн с ошибкой "неизвестная ошибка, обратитесь к системному администратору".
mayorovp
00.00.0000 00:00Только я бы не стал обвинять в этом конкретных девопсов, проблема где-то в сообществе. Существующие готовые решения все имеют какие-то подводные камни, про которые все знают, но вместо решения коллекционируют способы обхода.
Начнём с докера. Это отличное средство для изоляции окружения сборки от внешнего мира, которое прекрасно работает… до тех пор пока вам не требуется что-то из этого окружения. У вас свой репозиторий nuget, npm или кеш пакетов любого дистрибутива linux? Ставьте костыли. Желаете общего решения? Делайте свои базовые образы, со своими пайплайнами для их сборки (не тут ли корень проблемы с графаной?)
Продолжим им же. Есть такая штука как layer cache, которую можно использовать чтобы не загружать пакеты каждый раз. И это работает если все пакеты у вас в одном файле вроде package.json. У вас таких файлов несколько? Ставьте костыли, докер не поддерживает копирование с фильтрацией и сохранением структуры.
Нужны инкрементальные билды, потому что они быстрее? Ставьте костыли.
И это всего лишь один инструмент, костыли нужны каждому.
dnbstd
00.00.0000 00:00"Ближайшие лет 5 будет в том, что разработчики сами станут строить инфраструктурные решения." - По опыту говорю что это будет тот еще цирк, костыли и велосипеды. Потому что большинство(не готов утверждать что все, видел разных) современных разработчиков в инфраструктуре , а тем более архитектуре не смыслят ничего. Встречаются либо - мое дело писать код - а вы ops парьтесь как хотите, либо я использую то что знаю, а то что этот инструмент для этого не предназначен - "так исторически сложилось". Так что я в корне с вами не согласен.
lynxBios
00.00.0000 00:00+1очевидно, что проекту "пишем калькулятор" не нужен никакой девопс. А на проекте, где бежит 10 серверов в каком-нибудь облаке - кто ими заниматься будет ? Бэкенд-разраб?
vsantonov
00.00.0000 00:00Недавно у нас с разработчиком случился такой разговор. Деплоим его сервис в кубер. Я спрашиваю: «А что у тебя с масштабированием и доступностью?». Ответ «а я думал оно само». Почему-то все забывают что вторая часть названия Ops. Именно нам потом эти все калькуляторы расставлять в правильном порядке, чтобы хватило ресурсов, чтобы была доступность и восстановление в случае сбоя. Статья напомнила, как бухгалтеры жалуются что программисты им портят жизнь, они бы давно на счетах все посчитали без всяких этих сложных 1С.
XanderBass
00.00.0000 00:00А сейчас много где такая мешанина. Не, спору нет, некоторые вещи действительно упрощают работу. Та же Jira - отличное средство для управления проектами. А уж гнать на Git вообще грех, особенно если разработка командная. Но в остальном в наше время всё чаще разработка бывает перегружена технологиями. В результате человеку, который только пришёл на проект, порой бывает долго в нём разобраться. Да и вообще приходится тратить вагон времени на постоянное изучение всякого "стильно-модно-молодёжно".
HellWalk
00.00.0000 00:00Работать без CI/CD - тоже самое, что работать без гита. Но видимо не все еще прочувствовали удобство работы с ним (к сожалению во многих компаниях прод продолжают обновлять "ручками", и считают, что это нормально).
А перемудрить и запутать можно на любом проекте и с любым стеком технологий.
Sashki
00.00.0000 00:00Отличная статья. Я работаю на стороне внедрения проектов и у меня мнение про DevOps вот примерно такое же.
dnbstd
00.00.0000 00:00Внедряете руками и на коленке? очень странно звучит.
Sashki
00.00.0000 00:00Ну я надеюсь, что здесь многие внедряют руками, а не ж*пой :) А по поводу коленок. Вы даже не знаете, чем я занимаюсь и что за проекты внедряю. Поэтому ваш вопрос звучит еще более странно, чем мое согласие с автором статьи.
dnbstd
00.00.0000 00:00+1Поясню к чему вопрос, не для желания кого то задеть и повысить чсв. Я много работаю с вендорами и зачастую с разными внедрениями. И за частую все они страдают одной проблемой - отсутствием автоматизации, что бы позволяло ускорить внедрение. Потому ваше согласие со статьей меня удивляет. Готов выслушать ваше мнение по этому поводу.
0xC0CAC01A
Вот да! Есть версия это статьи на английском?
Tzimie Автор
Я могу сделать авторский перевод.
izogfif
Переведите заголовок обратно на английский и загуглите. Найдете вот это.
Habetdin
Этот сайт выглядит как автогенерируемый сборник переводов. Как «русские клоны StackOverflow», только наоборот.
olsowolso
Похоже так и есть - в превью-картинках ко многим статьям текст на русском языке, местами с кусками логотипа хабра. И с ходу я увидел еще одну статью с хабра.
Tzimie Автор
А неплохо перевел...
Miiko
Это, видимо, сарказм - не знаю, на каком языке это написано:
но это явно не английский.
dkuzminov
Версионность статьи про DevOps?
dyadyaSerezha
Чего да. Как проработавший в DevOps лет 5, могу сказать, что без нас вся разработка, QA и деплоймент в продакшен просто встали бы. Ну или делались раз в 50+ медленнее.
noittom
Да, про job security в статье тоже было, да