Комментарии 51
Ничего не понятно.
От какого момента считается тот день, в течение которого только 14% компаний в состоянии доставить код на прод? От момента, когда ветка полностью протестирована и код смержен? Ну, это смешно.
Чем занимаются те компании, эксплуатация которых не может восстановить сервис в течение часа/дня/недели(?!)? Почему они не выгоняют на мороз таких специалистов после подобных прецедентов?
Может, конечно, мне так с местами работы повезло - но описанные проблемы нигде не были прямо проблемами, консёрны совсем другие.
уточните, пожалуйста, что такое "консёрны"?
по поводу же четырнадцати процентов компаний - вероятно, это процент от числа делегатов, на симпозиуме. если у компании не бывает сбоев, значит она ни чем не занята (в сравнении с другими, внутри отрасли). это не говорит о том, что сбои обязаны быть, но, когда всё без сбоев, контора начинает "экономить на главном", и сбои не заставляют себя дожидаться.
То есть, развивая вашу логику - инфраструктура должна быть достаточно ненадёжна, чтобы менеджмент понимал, за что платит? :)
У меня, знаете, был один знакомый сисадмин, лет на 15 меня старше, приходящий. Так он в ранг правила это возводил - раз в пару месяцев что-нибудь "ломал", а потом приезжал и героически чинил.
Мне такое не близко, сорян. Надо делать хорошо - и уметь объяснять руководству, какой ценой оно сохраняется хорошим.
То есть, развивая вашу логику - инфраструктура должна быть достаточно ненадёжна, чтобы менеджмент понимал, за что платит? :)
это не моя. моя логика - лучший админ (или программист), это тот, которого не видно, а всё работает "как-бы само".
У меня, знаете, был один знакомый сисадмин, лет на 15 меня старше, приходящий. Так он в ранг правила это возводил - раз в пару месяцев что-нибудь "ломал", а потом приезжал и героически чинил.
к сожалению, вынужден заявить: ну и правильно делал.
менеджероориентированные организации по-другому не понимают.
Мне такое не близко, сорян. Надо делать хорошо - и уметь объяснять руководству, какой ценой оно сохраняется хорошим.
желаю успехов. (в вашем возрасте, я уже не был столь наивен. отучили.)
Могу предположить. Считается от момента поднятия pull request. То есть с того момента когда начинает работать CI/CD и до момента когда приложение запущено на проде.
Что значит восстановление за неделю? Это значит что за первые несколько часов откатывается версия или применяется patch/workaround и это НЕ считается полноценным восстановлением, т.к. ожидаемое состояние отличается от реального. А дальше уже идет расследование проблемы, поиск и подготовка решения, снова полный цикл CI/CD и иногда ожидание ближайшего запланированного релиза, а такое уже сплошь и рядом в корпоративной среде.
Всегда можно обойти все процедуры, проверку прав, прогон тестов и наживую пропатчить приложение на проде. Так что если вы считаете только время до фикса, то это не про DevOps это про менеджмент инцидентов.
Почему компании с этим мирятся? Почему не выгоняют на мороз?
Выскажу гипотезу. Если кратко: некого забирать «с мороза» взамен.
Отчет, который в основе оригинальной статьи, основан на масштабном опросе. За 3,5 года в нем приняло участие 150 000 респондентов из более чем 135 стран. По сути он отражает общие усредненные тенденции по индустрии и в какой‑то степени иллюстрирует известный анекдот про среднюю температуру по больнице.
Одна из задач исследователей — как раз обратить внимание на существующие в индустрии вызовы и зоны для роста (без учета отдельных компаний и стран). Тревожная тенденция — рост доли команд с низкой производительностью по всем ключевым метрикам развертывания.
Теперь по вашим вопросам (Я где‑то мог ошибиться — поправьте, пожалуйста, если заметите неточность.)
Речь идет о метриках DORA — например, Lead time for code changes. Разработчикам задавался вопрос: «В среднем, сколько времени у вас уходит с момента коммита кода до его успешного запуска в production?» (On average, how long does it take you to go from code committed to code successfully running in production?).
Отсчет времени идет именно от коммита, включая все последующие стадии: сборку, все виды автоматизированного и, возможно, ручного тестирования, мерж (если он не является самим коммитом в основную ветку), развертывание на различные окружения и успешный запуск на проде.
Еще задавался вопрос: «В среднем, сколько времени у вас или вашей команды уходит на восстановление сервиса после незапланированного сбоя или нарушения работоспособности?» (On average, how long does it take you or your team to restore service from an unplanned outage or service impairment?).
Данные из отчета (Q1 2024) следующие:
менее чем за час — 11% (этот показатель снизился с 17% в Q3 2020 и остается на уровне около 11% с Q3 2022),
от часа до дня — 29%,
от дня до недели — 19%,
больше недели — 41% (эта доля показывает устойчивый рост).
У менее опытных разработчиков показатели восстановления хуже значительно.
С опытом менее 2 лет:
5% — могут восстановить сервис менее чем за час,
67% — тратят на это более недели.
С опытом более 16 лет:
22% — восстановят за час,
9% — будут возиться две недели.
Также нужно учитывать, что не все сбои одинаковы — не все из них катастрофичны, некоторые могут быть и незначительными.
Еще отчет подчеркивает, что тимлиды играют ключевую роль в улучшении метрик — например, стандартизируют инструменты или обучают новичков. Когда этого не происходит, проблемы носят системный характер, и увольнение специалистов их никак не решит.
Мне кажется, что сам термин: восстановление после сбоя, требует расшифровки. Что понимается под сбоем...
Иначе некая глупость возникнет. Скажем у нас для того чтобы при крахе сервиса по нехватке памяти потребуется примерно 5-10 минут. Правка в деплой файле мастер ветки, пуш, выкатка на 4 кластера с выполнением юнит тестов и всякими линерами.
Но если как-то умрёт кластер базы, тут конечно будет дольше, раскатать новый быстро, а вот вкатить туда бекап, время займёт.
Так что я не очень понял, про какие сбои идёт речь?
Я о том же примерно написал, что не все сбои одинаковы. Согласен с вами — степень тяжести можно оценивать по времени, нужном для восстановления сервиса. И говорим мы, конечно, чисто о технической стороне (без учета репутационных и прочих сопутствующих потерь).
Тогда в чём смысл статьи?
Правильно понимаю, время самого простого действия от нажатия enter при команде git push до выкатки сервиса в прод выросло на x%?
Или раскатка систем связанных брокерами, корректностью апи и протобафов, доступностью апстримов, ингрисов и всего вот этого, превращается в многочасовые (а у особенно одарённых и в многодневные) квесты?
Речь не о том, что «самое простое действие от нажатия enter при команде git push» стало дольше. Ключевая метрика, о которой говорится, — Lead time for code changes — измеряет время от момента коммита кода до его успешного запуска в production. Сюда входит вся цепочка: сборка, тестирование, развертывание и т. д., а не только git push.
Для многих (41% в Q1 2024) доставка изменений действительно превращается в «квесты» на месяц. Доля таких команд выросла (в Q3 2020 их было 34%). В то же время сегмент наиболее быстрых команд, у которых этот процесс занимает менее одного дня, остается относительно стабильным (14% в Q1 2024).
Смысл статьи (и отчета, на котором она основана) — показать актуальное состояние DevOps, оценить эффективность доставки ПО, а также выявить факторы, которые на всё влияют.
Отчет предполагает, что одна из причин наблюдаемых трендов — рост сложности проектов, который нивелирует некоторые выгоды от внедрения DevOps. Я не возьмусь делать самостоятельные выводы, так это или нет. Мне показались интересными и само исследование, и оригинальная статья, которая является его обзором.
1) я так и написал, "от нажатия enter при команде git push до выкатки сервиса в прод выросло на x%?" Извиняюсь конечно, если выкатка в прод имеет многозначную трактовку...
В нашем случае от git push до момента факта ответа нового кода из прод окружения минимально достигаемое время: 5 минут. Максимально 10 минут. Зависит от нагрузки на сервере гитлаба. Включает прогон линтера, тестов, нескольких доп проверок...
Естественно речь не может идти о выкатке новой фичи, только минимальные модификации кода или деплой файлов с целью исправления не корректного поведения.
Ибо правки связанные с изменением апи, контрактов, добавлением полей в базу, изменением бизнес-логики - это всё вообще не измеримое по времени. Тут действительно зависит от того кто вносит правки: джун или лид.
Пожалуй я переспрошу. У 41% команд из обзора более чем суточные квесты с выкаткой в прод при правке например одной строки кода (понятной, безопасной, однозначной)???
Самое неприятное что может случиться при релизе, это потеря консистентности или частичная потеря данных. Приложение начинает писать частично некорректные данные и это обнаруживается через часы или дни. Восстановить из бэкапа как есть уже нельзя, потому что потеряются данные добавленные за время пока обнаружили проблему. Без хорошего аудита в БД и готовых инстументов, RTO в неделю и больше вполне реально в таком сценарии.
Логировать все не пробовали? Прямо весь поток изменений в нормальном формате в котором потом можно что-то понять. Это довольно типовое решение, которое позволяет восстановить все.
Логи лучше чем ничего, но это плохое решение. Логи не консистентны: хранилище для логов обычно делается с низкими гарантиями консистентности, при передаче стандартными тулзами возможны потери(файлбит мог не успеть прочитать файл, передача через gelf это udp, в elasticsearch не совпали мапинги сообщение не записалось и тд). Гарантировано писать логи, это сложно, дорого. Второе, если мы пишем все данные в логи, система логирования становится такого же уровня критичности по доступу как БД приложения. К логам обычно имеют доступ большее количество людей, если в БД номера телефонов, светить ими в логах для всех плохая идея.
Нужен аудит, который пишется в одной транзакции с данными.
Из всего могу согласиться только с доступами и аудитами. Да, доступы должны быть как к проду и аудит безопасности проводить надо как на проде.
С остальным все проще чем вам кажется. Врайт онли системы заметно дешевле rw систем. Просто пишем, не заботясь о том насколько эффективно оно читаться будет. В случае факапа расход ресурсов на восстановление не принципиален вообще.
Консистентность тоже делать проще когда не надо думать как данные читать. Пишем диффы с меткой времени и не думаем. Читать это крайне неэффективно, зато писать просто и приятно.
Чтобы далеко не ходить wal mysql это примерно правильного лога для уровня абстракции sql бд. Стоит заранее научиться надежно его хранить и работать с ним.
Проблемы с релизами и возможность их крайне тяжкого влияние на работоспособность системы в целом, это должна быть отдельная песТня.
Вот я ни как и не могу добиться, кто и что понимает под термином сбой!
1) не корректное поведение нового функционала через неделю после релиза?
2) отвал одной ноги у кластера базы
3) резкий рост потребления памяти/проца - постоянный перезапуск подов
4) развал кластера базы
5) внезапный отказ внешнего апи с данными и звонок в 17:00 в пятницу вечером: а не могли бы вы переключиться с mega-api.company.ru на super-api.company.ru
6) внезапное изменение у внешнего апи с данными контракта ответа?
Что такое сбой?
Да, спасибо, стало понятнее.
Пенять на недостаток девопса, суммируя время ревью, сборки, тестов живым человеком, согласований релиза в одну кучу - как-то странно, на мой взгляд. Узким местом может быть CI, который два часа выполняется - а может и загруженность QA, которая сегодня есть, а завтра нет.
В общем, кажется, у меня произошла финтеховская профдеформация - когда полчаса неработоспобности сервиса это повод обсудить работу отдела с CTO, а дальше можно просто начинать вещи паковать :) А места, где не так, кажутся странными.
Пока ваш финтех маленький, можно сколько угодно хвалиться скоростью поднятия сервисов, которые можно пересчитать по пальцам. Поднять ≠ починить, можно и нужно считать время и того и другого, но решение каждой проблемы может достигаться кардинально разными способами.
Хотите быстро подниматься? Держите green/blue деплой и вторую копию базы и кешей через mcrouter, при падении в автоматическом режиме переключаем нагрузку на старую версию и спокойно разбираемся с проблемой, downtime минимальный. Повторюсь на небольших проектах это разумно и оправдано, работает в 99% случаев.
Теперь попробуйте провернуть то же самое через 15 лет, когда у вас уже 50 систем связанных между собой, а количество программистов перевалило за 1000. Из данных в статье я бы сделал вывод что скорость с которой растет сложность разработки обгоняет скорость с которой инструментарий позволяет управлять этой сложностью (что неудивительно, т.к. инструментарий пишут такие же программисты). С учетом многолетнего тренда перевода разработки в Индию и наступающей волне vibe-кодеров вангую что будет только хуже.
По поводу метрики lead time for code changes, у нас в команде есть джуны и мидлы и доверять их коду достаточно сложно, а сеньёры вечно чем-то заняты чтобы досконально проверить всех остальных, времени на контрактное программирование или написание смоков, каких то тестов у них тоже нет. Поэтому неделя у всех кроме сеньёроа от комитета до деплоя на прод выглядит, как мне кажется, вполне нормально.
Спасибо за оригиналы. Действительно, усложнять легко, упрощать сложно. Было бы любопытно выяснить, если ли корреляция между внедрением CI/CD и микросервисов.
Смешались в кучу кони, люди...
С каких вообще пор необходимость выкатить только что написанный код в продакшн стала чем-то хорошим? Нормальный процесс разработки включает в себя следование релизному циклу, да даже хотфиксы редко в тот же день ставятся.
И что это вообще за метрика такая - скорость деплоя? Одно дело - просто поменять айдишку образа и триггернуть CD, другое дело - пилить новые пайплайны\манифесты под какие-то мажорные изменения. В первом случае - это maintenance / professional services, во втором - development. И мы на полном серьёзе тут обсуждаем какую-то общую для этих двух процессов метрику?
Про восстановление сервиса в течение недели - а какой Target RTO в SLA\договоре? У нас есть сервисы, которые могут и дольше валяться. Это ж история про управление рабочими ресурсами, а не про профессионализм. SLA не нарушен - нет проблемы. А если выясняется, что проблема всё же есть - то дело опять же не в девопсе, а в некорректно заданных параметрах SLA.
Описанные в статье проблемы, имхо, куда больше намекают на кризис в качестве управления проектами. Вот отткуда как раз и тайм ту маркет за пару часов, и ллм вместо джунов, и прочие непотребства. А причина - перегретый рынок и огромное количество случайных людей в профессии.
Отчасти соглашусь, но своего мнения высказывать не стану, так как не считаю себя вправе спорить по этому вопросу. Поскольку тема мне очень интересна, я постарался разобраться в отчете (насколько смог) и попробую ответить как бы от имени автора оригинальной статьи. Замечу, что не полностью разделяю его взгляды, да и он сам не выходит за рамки выводов State of CI/CD Report, поэтому и я буду отталкиваться от того же отчета.
Необходимость выкатить только что написанный код в продакшн
Не каждый коммит предназначен для немедленного развертывания. Отчет же, как я понял, стремится к тому, чтобы команды имели возможность безопасно и быстро это делать при необходимости.
Lead time for code changes
Высокие показатели здесь не обязательно означают, что все коммиты идут в прод немедленно, а процесс отлажен и быстр. Хотфиксы, требуют скорости, а эффективные CI/CD пайплайны этому способствуют. Отчет показал, что только 14% разработчиков могут задеплоить код за день, 41% же вообще тратят на это месяц.
Скорость деплоя и ее неоднозначность
В отчете речь идет про Deployment frequency — одну из ключевых метрик DORA. Она измеряет частоту развертывается кода (стр. 21 отчета). При этом метрика никак не оценивает сложность каждого конкретного развертывания (будь то смена ID образа или создание нового пайплайна). Она отражает общую способность команды регулярно поставлять работающий код.
«Пилить новые пайплайны/манифесты»
Сложность подготовки к развертыванию скорее отразится на Lead time for code changes — время, затраченное до того, как изменение будет готово к деплою и запущено. Цель — сделать даже сложные развертывания более управляемыми и менее трудоемкими (за счет автоматизации и стандартизации).
Отчет не смешивает maintenance и development с точки зрения самих задач. Однако результативность процессов доставки ПО действительно оценивается в целом — тут не поспоришь.
Восстановление сервиса в течение недели и SLA/RTO
Вы совершенно правы, что SLA и RTO (Recovery Time Objective) — это бизнес-параметры, которые и определяют допустимое время простоя. Метрика DORA Time to restore service как раз измеряет, сколько времени уходит на восстановление сервиса после незапланированного сбоя (стр. 22).
С точки зрения DORA, это показатель операционной эффективности команды. Даже если SLA позволяет сервису «валяться дольше», способность быстро восстанавливаться — это признак зрелости процессов, качества архитектуры и экспертизы команды.
Действительно, если SLA не нарушен, формально «нет проблемы» с точки зрения контракта. Но с точки зрения конкурентоспособности, удовлетворенности клиентов и репутации бизнеса, длительные простои редко бывают желательны, даже если укладываются в SLA. Исследование стремится улучшить именно фактическую способность быстрого восстановления.
Кризис в качестве управления проектами и другие факторы
Ваше наблюдение о том, что описанные проблемы могут указывать на более глубокие системные недочеты в управлении, перекликается с некоторыми выводами отчета:
подчеркивается «важная роль, которую организации и руководители команд играют в направлении своих команд к более высокой производительности»;
указывается на необходимость «обеспечить, чтобы новые разработчики были лучше знакомы с DevOps в целом, а также с практиками, используемыми в организации»;
отмечается, что некоторые организации не внедряют и не стандартизируют лучшие практики, что приводит к зависимости производительности от индивидуального опыта разработчиков — это тоже можно рассматривать как недостатки в управлении.
только 14% разработчиков могут задеплоить код за день
М, надеюсь, что это неточность перевода. Разработчиков на пушечный выстрел нельзя к деплойменту подпускать, это не их зона ответственности и не их компетенция.
Но "деплой за день" - это странная отсечка, если честно. Приведу пример из жизни, с которым наверняка сталкивались практически все здесь присутствующие.
У нас есть unmockable API - и unmockable он в силу разных причин (трудоемко, нужны данные с реального оборудования, частая смена контракта делает мок бессмысленным). Гипотетический пример - нам нужно, чтобы над нашим оборудованием проехал грузовик, и оно там что-то с него записало. Грузовик ездит раз в неделю. Или в месяц. Тестово гонять грузовик - дорого, столько денег никто не даст. Более того - пустой грузовик гонять бессмысленно, а набивать его нечем (и это ещё дороже).
Вывод - для интеграционного тестирования нужно или ждать, пока грузовик приедет по делу, или тратить миллиарды золота на тестовый заезд, грузчиков и 12 тонн кирпичей.
Сможет ли в таком случае разработчик задеплоить код за сутки? Да, и будет немедленно казнен за скип CI stage.
Снижает ли это Deployment frequency? Безусловно.
Самый главный вопрос - а проблема ли это? Ответ - нет, это всего-навсего специфика продукта, отраженная в том числе в оптимизации затрат на интеграционное тестирование.
Но... а как же метрики? Напрашивается ответ - метрики имеет смысл сравнивать только в динамике, и только для конкретной задачи. Нет ничего удивительного в том, что у криптостартапа, государственного API и прошивки для Вояджер-1 разный тайм ту маркет и разная частота деплоя. И дрифт среднего арифметического по перегретому рынку может означать в том числе и уход с этого самого рынка "быстрорастущих" проектов по причине их массового банкротства.
длительные простои редко бывают желательны, даже если укладываются в SLA
Так SLA как раз и нужен затем, чтобы определить - какие простои допустимы, а какие - нет. Именно SLA определяет, будет ли мы мутить High Availability со всеми сопутствующими оверхедами по стоимости сопровождения и обслуживания, или сделаем docker-compose up на виртуалке и забудем. Как клиент скажет (читай - заплатит), так и сделаем. Удовлетворенность клиентов, репутация и прочее - это бизнес-метрики, а SLA - отражение этих метрик в виде технического задания на разработку.
Есть добрый пример про 29 февраля. Баги, связанные с обработкой этого события наблюдаются не чаще 1 раза в 4 года. Воспроизводить их достаточно просто. Но фикс нужен или прямо сейчас (на прод выкатывать опасно, особенно если баг в прошивке SIP телефона) и спешка ну никак не оправдано.
Важность бага - высокая, приоритет не очень (пример основан на тру стори, фикс был через 2 минуты после обнаружения, выкатили через 3 месяца со следующей плановой прошивкой)
Поскольку тема мне очень интересна, я постарался разобраться в отчете (насколько смог) и попробую ответить как бы от имени автора оригинальной статьи. Замечу, что не полностью разделяю его взгляды
Не следовало вообще делать перевод оригинальной статьи. Можно было сослаться на нее как на источник. Тем более название той статьи неудачное.
Надо было сделать свой материал, на основе State of CI/CD Report, и оригинальной статьи. То что вы сейчас пишите в комментариях, тоже должно было быть в статье.
У вас акценты расставлены неверно. Вы делаете акцент на абсолютных цифрах, хотя важны только изменения по годам.
Вы сразу вбрасываете спорный тезис - "сообщает о том, что DevOps‑инициативы, похоже, зашли в тупик."
Общая структура статьи должна быть примерно такая.
Цель исследования - оценка эффективности внедрения devops за последние годы.
Методы исследования - по косвенным показателям. Используются метрики, без учета дополнительных параметров (например без учета сложности проекта).
Факты - метрики падают за последние годы.
Вопрос - действительно ли это показатель малой эффективности devops, или выбранный метод исследования дает ложные результаты?
Скорость деплоя и ее неоднозначность
Она отражает общую способность команды регулярно поставлять работающий код.
Даже этого не отражает. В отдельных проектах регулярность и частота деплоя не имеют никакого значения, и при внедрении devops они не изменятся. Это не прямой признак. Просто этот показатель должен улучшаться в среднем, по мере расширения использования devops.
Восстановление сервиса в течение недели
Как вариант - devops был прикручен как опция. Упал сервис - ну и ладно, работаем по старинке. Почему не поднимают быстро - потому что не особо-то и нужен.
Равноправные варианты - "devops слишком сложен, поэтому долго восстанавливают", и "devops хоть и есть, но не является необходимым, поэтому не торопятся восстанавливать".
ИТ компании бывают очень разные - у одних релизный цикл эта одна фича или фикс (привет канбан), у других приложение к договору (привет водопад).
А ведь еще сравнительно недавно были времена, когда весь деплой заключался в копировании нескольких файлов на единственный сервер по ssh. Весь мониторинг - в подключении по тому же ssh, чтении единственного лога и наблюдении за метриками top'ом. Да, это было не круто. Но этому можно было за час на пальцах научить любого джуна, и дальше они вполне справлялись с поддержкой.
Современные подходы к инфраструктуре, типа service mesh, пошли по пути добавления новых и новых слоев абстракции. Теперь у вас три экземпляра приложения, каждое в своем поде, каждое - за своим прокси, гейтвей, лоад балансер, собиралка логов, собиралка метрик, физическая машина, на которой это в конечном счете крутится (часто, все так же одна единственная, ведь "мы же не гугл"). И у каждого компонента естественно есть свои логи, свои метрики, своя конфигурация при деплое. Каждый компонент - потенциальная точка отказа. Теперь, для того, чтобы с этим всем справится, нужен отдельный специалист. Джун-программист не просто не сможет выполнять такую работу, он скорее всего даже не сможет коммуницировать с таким специалистов в рамках своих задач. Стало ли как-то лучше глобально? Для супер большиъ проектов - наверное да. Остальные и 10 лет назад, и 20 лет назад тоже как-то работали, вполне нормально. Что точно изменилось - современные практики DevOps создали огромное количество рабочих мест собственно для девопсов. Не вижу в этом ничего плохого.
А ведь еще сравнительно недавно были времена, когда весь деплой заключался в копировании нескольких файлов на единственный сервер по ssh. Весь мониторинг - в подключении по тому же ssh, чтении единственного лога и наблюдении за метриками top'ом.
Конечно же нет. Мониторили Веблоджики всякие с Джейбоссами. И деплоили на них же всякое. И это было не очень. Сейчас лучше.
Вот кстати да. EJB ведь тоже шел путем добавления абстракций и приводил к кратному увеличению сложности системы. Где сейчас EJB?
И да, я не пытался сказать, что сейчас хуже. Я пытался сказать, что в целом позитивный движ как будто свернул немного не туда. Надеюсь, на следующем витке прогресса народ додумается как получить те же преимущества, но без этой сложности.
Многие хорошие технологии развиваются по спирали. Что-то хорошее сделали, потом накручивают фичи и усложняют, а потом приходит новый уровень и на нем снова делают что-то простое и хорошее без всей шелухи прошлой технологии.
хорошее без всей шелухи прошлой технологии.
Хорошо бы если если без шелухи. Так ведь два слоя предыдущих технологий убрали, а три остались.
То, что было приложением в сервере приложений - так приложением в сервере приложений и осталось. Только сервер приложений теперь для каждого приложения персональный. Да еще в персональный контейнер упакован. А пачка контейнеров - в виртуализированный сервер. А пачка виртуальных серверов - размазана по нескольким настоящим железками.
Случаи, когда лишние слои абстракций получается целиком выдрать - довольно редки.
Три экземпляра приложения, гейтвей, лодбеленсер, метрики. В пределах одного bare metal сервера, ну или availability зоны. Такого - процентов 95, наверное. И ничего там сложного нет, минут за 20 всё подымается. Можно даже без всяких там кубернетесов и сервис мешей, в GCP есть Cloud Run для таких сценариев. Мышкой накликал, и оно само попёрло.
У нас в большинстве случаев девопс вообще на деплоях присутствует исключительно для галочки. Ну если вдруг чего не так пойдет. А так - релизные теги у нас забивают менеджеры, а одну циферьку в манифесте поправить кто хошь сможет.
К чему я всё это
Для меня когда-то в молодости ансибль с применением идемпотентных методов стал откровением. Вторым таким же откровением стала immutable инфраструктура. Все эти штуки придуманы не столько для решения технической задачи, сколько для минимизации человеческого фактора. Копипастить бинарь - это круто, конечно, но вспонмите, какого размера у вас были preflight чеклисты для установки всего на свете на этот сервер. Вспомните, как часто у вас всё ломалось после apt-get/emerge/yum/etc, как приходилось грузить ос в рековери и что-то там ковырять. Вспомните про километровые портянки iptables/ufw/ipfw, про забытые открытые порты, про fail2ban, который чаще банил сам себя, чем кого-то злобного со стороны.
Вспомните, как грепали сислоги, как часами накликивали шаблоны в заббиксе (это отдельный вид мазохизма был). Как разные сервисы писали логи в разных форматах и с таймстемпами в разных таймзонах. И как, несмотря на всё это, основной фидбек давали не нотификации, а реальные пользователи по телефону.
В общем, сейчас всё гораздо лучше и гораздо проще.
Эх, вот было время! Заказы принимались в лучшем случае по телефону или по емейл. Отчетность в налоговую сдавалась в бумажном виде. Платежки в банк носились в бумажном виде. Все ходили на работу в офис. Ну и сайт-визитку раскатывал "копьютерщик" копируя файлы по FTP. А потом пришли всемогущие девопсы и поменяли мир под себя, чтобы создать себе ценность. С такими людьми вообще лучше не спорить.
Да, это было не круто.
Как по мне то было еще как круто. Мы могли вдумчиво автоматизировать собственными силами то, что надо и как это надо на нашем конкретном проекте. Сейчас же, все похоже на какой-то рой суетящихся невротиков (т. к. от современных инфраструктур начинается дергаться глаз даже у программистов в коме), гоняющихся за инструментами и сервисами, примерно одинаково избыточными и непонятными, т. к. их дофига.
А ведь еще сравнительно недавно были времена
Причем, далеко не факт, что описанная современная система решает принципиально более сложные пользовательские задачи.
Есть курсы тестировщиков, разработчиков, они конечно почти всегда бесполезны или вредны, но они есть. А вот девопсу никто не учит, нет кафедры devops в вузе, в итоге непойми кто на этих должностях оказывается
A DevOps team includes developers and IT operations working collaboratively throughout the product lifecycle
Under a DevOps model, development and operations teams ... merge into a single team where the engineers work across the entire application lifecycle
отсюда, к примеру
Если появляется отдельная должность DevOps-инженер между разработчиками и администраторами - значит люди не поняли что такое DevOps и зачем он нужен. Справедливости ради следует заметить, что таких (не понявших) процентов 90. А то и 99.
А то что
девопсу никто не учит
это безусловная и печальная правда. Как и то, что во многих случаях и разработке учат так, что лучше бы не учили.
должность DevOps-инженер
в больших проектах нужно выделять отдельные команды девопс инженеров, конечно они должны работать плотно с разработчиками, но просто сказать что разработчики теперь и девопсы это кончится плохо
Если появляется отдельная должность DevOps-инженер между разработчиками и администраторами - значит люди не поняли что такое DevOps и зачем он нужен
Если появляется отдельная должность DevOps-инженер между разработчиками и администраторами
Почему DevOps-инженер "между", а не в дополнение? И о каких администраторах речь?
Автор оригинальной статьи - журналист с опытом 30 лет, написавший более 10.000 статей. И не более того. Просто классический пример про слышу звон ...
Автор оригинальной статьи пишет об IT с тех пор, как CP/M стала самой популярной операционной системой. Мне кажется, если просто сказать «журналист» — на ум может прийти неверная ассоциация.
Кроме того, автор оригинальной статьи ничего не добавил к отчету State of CI/CD Report. Если кажется, что какие‑то высказывания в отчете неверны, то правильнее обратить критику на Continuous Delivery Foundation, а также на организаторов cdCon и Open Source Summit North America за то, что тех пригласили.
Восстановить за час звучит конечно круто, но есть некие сомнения. Если речь за зелёную кнопку, которая в приложении вдруг стала красноватой это одно, а если это залип кеш редиса на одном из кластеров или в прод утёк конфиг дева одного из микросервисов, который от этого взбесился то ж совсем другое. Да банально выковырять что либо из бекапа при базах данных размером с терр это уже не всегда в час укладывается.
Любопытно, но выглядит так, что дисциплина DevOps проходит те же стадии развития, что и сама разработка ПО, наступая на те же грабли. Видимо вскоре появится какой-то аналог DevOps-ООП, DevOps-ФП. Практики Waterfall и Agile в девопсе, Реактивный девопс, распределенный микросервисный девопс, разделение девопсов на фронт-дев-опсов и бэк-дев-опсов и вот это вот всё.
DevOps не умер, нет. Но ему плоховато