Комментарии 47
Хорошая статья, хоть перевод и подпортил слегка впечатление.
Мне довелось как-то работать над одним довольно крупным сервисом по описанным принципам. Не было стейджа и тестеров. Каждый девелопер сам тестировал свои изменения, деплоил сразу на прод и, если что, сам откатывал. Такой подход побуждает более ответственно относиться к тому, что ты написал, тщательно продумавать все корнер кейсы, подкладывать соломинки во все возможные места. И это неплохо работало: частота деплоев на прод — десятки в день, частота откатов — единицы в месяц. Причем последствия ошибок в коде как правило довольно локальны, в отличие от ошибок в настройках инфраструктуры, из-за которых может развалиться вообще все.
Понятно, что этот подход никогда не будет применяться, например, для банковских сервисов. Там цена ошибки велика, и доступ всех девелоперов и тестеров к проду сам по себе является риском.
этот подход никогда не будет применяться, например, для банковских сервисов
да почему же, очень даже применяется
А как решаются вопросы с ценой ошибки и доступом девелоперов к проду?
В Нигерии, про которую я когда-то писал статью — никак =)
У меня вот был случай, когда из-за напутанной циферки компанию успели нагреть на тысячу долларов (для Нигерии большая сумма), выводя больше кешбека чем можно было. Ну фигли поделать. Списали убытки и дальше продолжили в том же духе.
Спасибо, ждал этот вопрос)
Так девелоперы к проду прямого отношения и не имеют. Они могут в рамках девопс подхода создавать пулл-реквесты в репозиторий с хелм чартами, а там уже если их аппрувят, то новая сборка из репозитория с контейнерами, которые выпекла CI, выкатится в поды. Эти реквесты аппрувят девопс-инженеры.
Каждый девелопер сам тестировал свои изменения, деплоил сразу на прод и, если что, сам откатывал
Звучит замечательно. Сначала когда-то давно разработчики как-то так и работали. Но как мне кажеСначала то когда-то давно тся, разделение на QA и разработку оно не просто так произошло.
Ведь для реализации подхода, описанного автором нужно убрать QA и заменить их разработчиками, которые умеют хорошо тестировать на проде. Такие разработчики стоят дорого. И построение среды, в которой тестирование на проде не убьёт прод — тоже стоит очень недёшево.
Наверное в каких-то случаях такой подход окупается. Но подозреваю, что далеко не всегда.
Ведь для реализации подхода, описанного автором нужно убрать QA и заменить их разработчиками, которые умеют хорошо тестировать на проде.
Идея не в том, что разработчики становятся на полставки QA и начинают тестировать код на проде :) Идея в том, что разработчики пишут тесты, которые прогоняются на CI перед каждым деплоем.
разделение на QA и разработку оно не просто так произошло
Ручное тестирование само по себе может закрыть далеко не все классы потенциальных багов, тем более если оно проводится в фейковом окружении. Частично эти же классы багов можно закрыть юнит-тестами, интеграционными тестами и автоматизированными тестами интерфейса.
А дальше бизнес просто считает, насколько важны эти классы ошибок для него, и что выгоднее в перспективе: ручной тестер или напрягать девелоперов на автоматизацию.
Идея в том, что разработчики пишут тесты, которые прогоняются на CI перед каждым деплоем.
Тесты с помощью CI прогоняются на проде, я же правильно понял? Обычный разработчик такие тесты писать не сможет, специалисты, которые могут разрабатывать и тестировать — стоят дорого.
А дальше бизнес просто считает, насколько важны эти классы ошибок для него, и что выгоднее в перспективе: ручной тестер или напрягать девелоперов на автоматизацию.
Мне кажется ответ либо очевиден, как в случае с каким-нибудь сайтом-визиткой или системой учёта рассчётов по ЖКХ, либо учесть всё просто нереально и приходится доверяться интуиции.
Дополню:
Покупка готового решения стоит не только денег, но и кода. При покупке готовых решений часто недооценивается работа по их интеграции. Более дорогое решение может оказаться выгоднее за счет упрощения кода для его использования. И напротив, некоторые решения (даже дорогие) интегрируются столь сложно, что написание с нуля дешевле интеграции. Слепой выбор решений по их цене и популярности зачастую приводит к тому, что код-клей для использования чужих компонентов составит большую и самую дорогую в разработке часть системы.
Тестирование на проде… Тогда логичный следующий шаг — QA не нужен. У нас же есть A/B тестирование! Выкатываем новый функционал на часть пользователей, смотрим что навернулось, чиним, переходим к шагу 1. И вот уже никого не удивляют новости о том, что обновление операционной системы не только привело саму систему в неработоспособное состояние, но заодно и грохнуло часть пользовательских данных.
Добро пожаловать в дивный новый мир, где нормально не работает ничего и никогда.
Хотя продукты в первом случае и во втором были разные, и в первом случае подход был обусловлен определенными историческими причинами, но анализируя это сейчас и применяя описанный подход в первом проекте, я думаю, скорость доставки была бы намного выше, а качество если бы не осталось на том же уровне, то скорее всего бы даже выросло.
У вас совершенно очевидно в первой компании был некорректно построен процесс деплоя.
А вот это вот "И задачи намного чаще возвращались в разработку из QA" — это недостаток? Ну т.е. тестировщики нашли баги — какие плохие тестировщики? И вы серьезно считаете, что если их отменить, то качество кода на проде вырастет?
Ну и про маленькие релизы от девелоперов это тоже ниоткуда не вытекает. Как разработчик захочет, так и выкатит. Фатал на прод можно вообще микропатчем выложить.
Конечно недостаток. Если у вас на производстве процент брака очень высокий, такое производство может стать убыточным. Лучше, если большую часть багов находят и исправляют разработчики на этапе разработки. Чем больше ответственности за свой код чувствует разработчик, тем качественнее он проводит тестирование, не надеясь, что все баги найдет QA, а он, если что, потом их исправит. Также у QA не всегда может быть контекст, и чтобы его получить, тратится доп. время на коммуникацию, что опять затягивает релизный цикл.
> И вы серьезно считаете, что если их отменить, то качество кода на проде вырастет?
Ну практика показывает, я же не с пустого места считаю)
> Ну и про маленькие релизы от девелоперов это тоже ниоткуда не вытекает.
Чем меньше конвейер до прода и кол-во звеньев, тем меньше релизный цикл. Если у вас в релизе несколько отделов задействовано, вы автоматически получаете как минимум временные расходы на коммуникацию и синхронизацию.
Наверное, вы правы. В первом случае релизили QA, и делали они кумулятивные релизы с несколькими фичами, поскольку так ручное тестирование можно было делать сразу для нескольких фичей (иначе было еще дольше). А во втором — свою фичу тестировал и релизил каждый разработчик самостоятельно, если надо, привлекал кого-то из смежных команд. Поэтому с QA отделом только так, и никак иначе.
А разве так не делает большинство? Пользователь.
Чтобы не впадать в ложную дихотомию, хочется спросить приверженцев такого подхода: а какого рода ПО вы выпускаете?
Мне не хотелось бы с каждым серверным или клиентским релизом быть подопытной мышкой и ждать подлянки в виде плохо протестированных багов.
Я могу привести кучу инструментов, которые очень, очень, ОЧЕНЬ опасно тестировать на продакшене.
Из связанного с деньгами:
- банковское ПО
- платёжные гейты и вообще системы по приёму платежей
- трейдерские системы
- бухгалтерия
Из связанного со здоровьем: - медицинские системы
Компоненты систем безопасности (например, механизм выдачи разрешений и т.п.)
Транспорт, энергетика… да куча областей, где ошибки в продакшене выльются не только в крупные финансовые потери, но и в риск здоровью людей.
Меня удивляет, что автор предлагает использовать скучные технологии, но, почему-то, отработанные схемы выпуска ПО считает недостаточно скучной?
Мне не хотелось бы с каждым серверным или клиентским релизом быть подопытной мышкой и ждать подлянки в виде плохо протестированных багов.
Во-первых, противопоставление короткого цикла поставки и хорошо протестированных багов — это как раз и есть пример "ложной дихотомии". Деплой изменений непосредственно в прод не означает, что они перед этим не должны тестироваться. Ровно как и наличие дева, стейджа и пре-прода с армией тестеров не означает, что тестирование будет сделано хорошо. Об этом сказано в статье в разделе "5. Меры QA снижают качество".
Во-вторых, чего бы вам не хотелось больше: один раз наступить на баг, описать его в саппорт и больше никогда с ним не столкнуться, или наступать на один и тот же известный (и уже давно пофикшеный в коде) баг регулярно, потому что у сервиса длительный цикл поставки?
Каждый этап контроля качества ПО — планирование, написание, код ревью, тестирование в нескольких средах, выпуск, мониторинг и поддержка — выстраданы поколениями разработчиков и тестировщиков. За разные этапы, если есть средства и бюджет, отвечают разные люди. Это конвейер.
В главе 5 автор ставит знак равенства между ручным тестированием и отделом QA. По сути, рисует из QA инженеров манки-тестеров. Хороший QA инженер умеет всё то же самое, что и девелопер. Только фокус его внимания смещён с написания кода приложения на контроль кода приложения и контроль целостности системы (т.к. приложение состоит из разных подсистем).
Делает он это здесь:
если вы деплоите легко и часто выпускаете небольшие изменения, то никакой отдел QA не сможет справиться с тестированием каждого деплоя и неизбежно будет мешать деплоить.
и здесь:
выполняющим QA отделам часто не хватает контекста и времени. В результате они могут начать тестировать «воздействие» вместо «задач».
Нельзя с одной стороны, писать про офигенно крутых разработчиков, которые без проблем рефакторят UI компоненты и (предполагается) делают это совершенно без ошибок, а потом приходят вялые QA инженеры и всё портят своей тупизной, т.к. не способны разобраться, почему падают их тесты (именно это и показано в примере).
В идеальной вселенной разработчики умеют во все эти этапы и они становятся full stack developer, мастера на все руки. В реальности таких разработчиков, которые через полгода работы в компании не забивают на всё, кроме написания кода, единицы.
Предметную дискуссию вести с автором статьи сложно. Во-первых, его нет на сайте. Во-вторых, он целенаправленно ставит себя напротив сообщества с целью показать "вы все дураки, один я Д'Артаньян".
один раз наступить на баг, описать его в саппорт и больше никогда с ним не столкнуться, или наступать на один и тот же известный (и уже давно пофикшеный в коде) баг регулярно, потому что у сервиса длительный цикл поставки?
Наличие staging, dev-окружения, релизов, QA инженеров и т.п. никак не говорит о том, что у сервиса длительный цикл доставки. Вопрос исключительно в том, как быстро фиксят проблему и насколько важен фикс именно этой проблем для проекта.
Автор, опять же, считает, что все эти меры — это усложнение. Лично я считаю, что планирование и правильная архитектура мер и сред выполнения дают гораздо больше пользы, чем отказ от них.
Мне кажется, вы здесь больше спорите с мыслями в своей голове, чем с обсуждаемой статьей.
В главе 5 автор ставит знак равенства между ручным тестированием и отделом QA
Ну если почитать только первое предложение этой главы, то да. Но если осилить хотя бы второе — там уже про ручной запуск автотестов, например.
Если отказаться от ручного тестирования специально обученными людьми, а автотесты запускать на CI, чем конкретно должен заниматься отдел QA? Писать тесты вместо девелоперов?
Хороший QA инженер умеет всё то же самое, что и девелопер
Не видел в жизни ни одного QA, который мог бы например, написать Spark-джобу или хотя бы бекенд на Akka Http. Наверное, эти легендарные "Хорошие QA" так же редки, как единороги.
Если говорить серьезно, очень странно требовать от QA тех же умений, что и от девелопера. Это разные специальности для решения разных задач.
а потом приходят вялые QA инженеры и всё портят своей тупизной
В статье такого нет.
В идеальной вселенной разработчики умеют во все эти этапы
Опять-таки, такого нигде не утверждается.
он целенаправленно ставит себя напротив сообщества с целью показать "вы все дураки, один я Д'Артаньян"
Почему вы так решили?
Наличие staging, dev-окружения, релизов, QA инженеров и т.п. никак не говорит о том, что у сервиса длительный цикл доставки
Ну да, довольно часто встречаются такие проекты, где стейдж вроде как есть для галки, но по факту туда никто не смотрит, и все изменения транзитом попадают в прод. Можно либо навязать больше бюрократии и процедур, что приведет к удлинению цикла поставки, либо просто дропнуть стейдж и радоваться жизни. Бизнес решает, что ему важнее.
Я спорю с тезисами статьи, такими как:
- Разработка должна ориентироваться на продакшен, всё остальное — чушь
- Меры QA снижают качество
К остальным тезисы, при "правильном" их прочтении, я претензий не имею
Ну если почитать только первое предложение этой главы, то да
так зачем он начинает за здравие, а кончает за упокой? Зачем такой провокационный заголовок и тезис, если оказывается, что в одном конкретном примере плохо было выстроено тестирование и выпуск приложения? Зачем это?
Если отказаться от ручного тестирования специально обученными людьми, а автотесты запускать на CI, чем конкретно должен заниматься отдел QA?
Контроль качества: инструменты разработчика, фреймворк для написания тестов, контроль качества тестов и прочее, прочее, прочее.
Не видел в жизни ни одного QA, который мог бы например, написать Spark-джобу или хотя бы бекенд на Akka Http. Наверное, эти легендарные "Хорошие QA" так же редки, как единороги.
Ну а я видел (не шучу). И видел очень много фронтенд-девелоперов, которые не смогли бы сделать то же, что вы просите. А этот ваш восхитительный бэкендер не смог бы написать <подставить очередную редкую невероятную технологию>. Это пример ложной дихотомии.
Если говорить серьезно, очень странно требовать от QA тех же умений, что и от девелопера. Это разные специальности для решения разных задач.
Да, странно требовать. Тем не менее, Developer in testing часто в первую очередь QA-инженер, а потом уже — девелопер.
В статье такого нет.
Цитирую:
"Ещё я видел, как отделы QA препятствовали деплоям из-за непрохождения тестов после добавления в слой CDN кэширования — TTL в 5 секунд ленты новостей может быть даже незаметен пользователю, но способен испортить тесты QA, вызывая необязательные конфликты между разработчиками и инженерами QA"
Почему вы так решили?
А вы посмотрите на количество комментариев под этой статьёй...
Можно либо навязать больше бюрократии и процедур, что приведет к удлинению цикла поставки, либо просто дропнуть стейдж и радоваться жизни.
Можно. Но это же как раз пример плохого использования технологии, а не плохой технологии. Отказаться от технологии там, где она не работает — это одно. А другое — говорить, что этот подход — какашка. То ли "исторически так сложилось", то ли лень девелоперов, то ли нет в этом действительно нет необходимости.
Как часто даже сейчас я слышу: "ну зачем нам система контроля версий? у нас же простой продукт..." Это всё одного уровня проблема. Лень, непонимание, нежелание учиться на чужих ошибках.
Я спорю с тезисами статьи, такими как:
- Разработка должна ориентироваться на продакшен, всё остальное — чушь
- Меры QA снижают качество
Ну вот да, в этом и дело!
- Оригинальная статья называется "Production Oriented Development", про "чушь" — это изобретение переводчика
- Глава 5 называется "QA Gates Make Quality Worse", никаких "мер", автор всю главу говорит, что QA не должны стоять как ворота между девелопером и продом, а должны стоять где-то сбоку
А вы посмотрите на количество комментариев под этой статьёй...
Ну да, люди клюнули на чуть провокационный заголовок, а потом тригернулись на какие-то рандомные словосочетания из статьи — вот откуда такие комментарии. Большая часть возмущающихся (как и вы в первом комментарии) решила, что он призывает нифига не тестить и сразу в прод. А статья вообще-то про максимальную автоматизацию и сокращение релизного цикла, про то, что мониторинг так же важен или даже важнее qa, что стейдж в принципе никогда не может быть равен проду и т.п.
Я прочитал статью сначала в оригинале, а потом в переводе. И я спорю с автором статьи — там, а тут высказываю своё мнение.
Провокационный заголовок — половина смысла в этой статье. Вводите больше автоматизации, будьте смелее, пишите код лучше, ничего не бойтесь.
Радикализм в любых технологиях — плохо. Если где-то пишут чудовищно много автотестов, но забивают на ручные проверки — плохо. Если наоборот всё в ручную проверяют, без тестов — плохо.
Всё катят на продакшен — так себе идея. Маринуют код месяцами на стейджинге — тоже.
Соблюдайте баланс. Не впадайте в крайности. На мой взгляд, автор статьи как раз в крайности и впадает.
Я за разделение сред в таком по, как раз работаю в данной сфере. Кроме тестирования есть еще этап юридического согласования. И ошибки это не только исправление а большие денежные риски.
«QA не нужны, тесты не нужны, надо быстро выкладывать код, и так же быстро его откатывать» — концепция разработки так себе, она годится разве что для проекта на старте, когда цена ошибки мизерная, или же когда проект еще вообще не стартовал, а только готовится.
концепция разработки так себе, она годится разве что для проекта на старте, когда цена ошибки мизерная, или же когда проект еще вообще не стартовал, а только готовится
Вообще, ровно наоборот. На ранней стадии проекта фичи резко появляются и исчезают, API очень быстро меняется и так далее. Писать на это тесты — слишком большой оверхед и потеря гибкости. Тут как раз ручное тестирование решает.
Когда проект уже устаканился, проще автоматизировать тесты — это и надежнее, чем гонять вручную по одним и тем же кейсам изо дня в день, и заодно позволяет сократить время поставки.
Ну в статье не написано, что тесты не нужны. Скорее наоборот, там про автоматизацию ручных тестов.
Подход называется — "бананы дозревают у покупателя"?
Ничего удивительного. Таким подходом сейчас пользуются примерно все от операционных систем до игр, в том числе и языки программирования, фреймворки и IDE — для всего этого публикуются альфа-, бета-версии, релиз-кандидаты, превью, найтли, снепшоты. Зачем по-вашему? Если что-то делается для людей, желание услышать фидбек от этих людей как можно раньше — это нормально.
Да, только пользователь фреймворка делает осознанный выбор, надо ли ему накатывать релиз-кандидат или посидеть на стабильной версии. А то и посидеть на прошлой стабильной пока пару сервисных релизов не выкатят. А вот пользователю веб-сервиса этот выбор никто не даёт.
Ну вот например сейчас сбер переходит на новый интерфейс, и там есть опция переключиться на старый. До этого, видимо, была опция "заценить новый интерфейс". Это довольно типовая практика для крупных веб-сервисов.
Мелкие веб-сервисы тоже наверно бы так делали, но поддерживать несколько версий в рабочем состоянии — это сильно дороже, чем только одну актуальную. Готов ли будет пользователь заплатить за возможность такого выбора? Возможно, те, кто пытался так делать, просто отсеялись естественным отбором.
Атомные реакторы, ракеты и беспилотные автомобили так делать наверное не стоит. Но для подавляющего большинства продуктов всё изложенное очень даже хорошо и правильно. Как известно, быстро поднятое упавшим не считается ;) Поэтому лучше учиться быстро поднимать, чем никогда не ронять — последнее куда дороже, а бизнесу обычно нужно подешевле и побыстрее.
Предложенные автором методы можно применять там где цена ошибки и репутационных потерь меньше затрат на разворачивание тестовой среды и QA-отдела.
То что подходит овощной палатке у дома, не приемлимо для нормальной сети магазинов.
Конечно когда ты монополист, ты можешь позволить себе скатиться на уровень овощной палатки — ежикам никуда не деться подводной лодки с кактусами.
Банки, медицина, космос. Да достаточно включить в уравнение мобильное приложение, цепляющееся к одному из сервисов. Выкатка которого будет занимать пару дней из-за ревью, да и после выкатки фактическое обновление аппов хотя бы у 80% пользователей может неделю занять...
Да, есть expedite review, есть hard update, но и то, и то — не панацея. Есть версионирование API, но даже с ним деплои планировать и синхронизировать приходится.
1. Эксплуатировать свой код должны инженеры
— не так давно (2017г) software developer из GitLab случайно потер 300Гб данных. Ни на что не намекаю, но все же хочется чтобы сервера админили те кто хорошо понимает что такое бэкапы и в каком они состоянии
2. Покупка почти всегда лучше создания
— новость от 26.11.2020: «Сбой AWS ударил по тысячам онлайн-сервисов». Перестали работать даже пылесосы и «умные» дверные звонки. Сбои бывают у всех, но когда твой бизнес зависит от кого то другого это напрягает
4. Доверяйте людям, которые ближе всего к практической работе
— в итоге в компании вырастет «золушка», которая делает все. Дальше золушка устанет и уйдет или, при дурном воспитании, начнет шантажировать руководство
5. Меры QA снижают качество
— инженеры, тестировщики. А где аналитик который собственно и заявил необходимость нового функционала? Да и сама проблема возникла у автора из-за того что чуть раньше он потребовал все сразу хреначить в продакшн мелкими деплоями
Дальше читать устал, какая то «тугая» статья или это я «тугой»
> — не так давно (2017г) software developer из GitLab случайно потер 300Гб данных
Эксплуатация кода и эксплуатация инфраструктуры, на котором этот код эксплуатируется — это разные области, и, конечно, за эксплуатацию инфраструктуры должны отвечать не разработчики.
> Сбои бывают у всех, но когда твой бизнес зависит от кого то другого это напрягает
Можно подумать, вы всегда пишите свой фреймворк или свою CI/CD с нуля) Иначе это получается крайне дорогая разработка) Важно перед использованием стороннего инструмента провести всесторонний анализ и оценку рисков при его использовании. И уже тогда делать выбор, если выгода перевешивает риски.
> в итоге в компании вырастет «золушка», которая делает все.
Там написано про то, что профессионалам надо доверять, а не говорить им, как делать свою работу. А если автоматически считать так, как вы, то зона ответственности ваших разработчиков так и останется на уровне написания кода по готовым ТЗ, не понимая, как этот код будет работать и что надо сделать, чтобы код превратился в полноценный продукт как можно быстрее и начал приносить пользу не только пользователям, но и бизнесу.
Эксплуатация кода и эксплуатация инфраструктуры, на котором этот код эксплуатируется — это разные области
— автор (как я понял) утверждает обратное
Можно подумать, вы всегда пишите свой фреймворк или свою CI/CD с нуля— в статье речь шла об инфраструктуре, а не о фреймворках. И даже тот же AWS упомянули
профессионалам надо доверять, а не говорить им, как делать свою работу
— в пределе это устранение руководителя от процесса и потеря контроля над ним
Довольно спорные утверждения, как мне кажется.
Эксплуатировать свой код должны инженеры
Если проект небольшой — то да, хорошая идея. Если же проект большой, то, к сожалению, это труднореализуемо. Для больших проектов люди придумали разделение труда. Поэтому-то есть product owner'ы, которые выступают теми-самыми-инженерами-которые-эксплутируют-и-хорошо-понимают-всё, и разработчики, QA, DevOps'ы, team lead'ы, PM-ы и т.п., которые по поручению product-owner'а выполняют различные работы. И коммуникации в больших командах можно настроить достаточно неплохо при должном старании.
Покупка почти всегда лучше создания
Пример противоположной ситуации. AWS продаёт сервис NAT gateway (что-то типа роутера). Аналогичный сервис можно реализовать на других сервисах и получится дешевле (в 10-100 раз). Единовременные затраты на разработку довольно быстро окупятся.
Упростите процесс деплоев
Двумя руками за. Как мне кажется, CI/CD как раз об этом. Должна быть одна кнопка, которая отправляет изменения в продакшн.
Доверяйте людям, которые ближе всего к практической работе
Можно и шире сформулировать — "доверяйте профессионалам" :) Если люди непосредственно работают с пользователями, им можно доверять по вопросам UI/UX. Но я бы не стал доверять им архитектуру обработки данных. В этом вопросе лучше доверять другим специалистам.
Меры QA снижают качество
Как мне кажется, здесь какая-то подмена терминов. QA — quality assurance — обеспечение качества. Так что получается оксюморон. Видимо, автор имеет в виду какое-то несовершенство процессов QA в его компании.
Ручному тестированию, конечно, нет места в цепочке CI/CD. Все необходимые тесты должны быть автоматизированы.
Идея "тестирования в продакшене" хорошо известна по соответствующему интернет-мему. Как мне кажется, не для всех проектов такая идея подходит. В случае, если product owner считает возможным пожертвовать частью пользователей, и сэкономить на других мерах QA, то это, наверное, его право. Ему, по-видимому, надо будет обосновать это решение перед заинтересованными лицами (stakeholder'ами).
Скучная технология — это отлично
Идти по проторённой дороге — это отличный способ снижения рисков. Если такая дорога есть — туда, вероятно, и надо идти большинству. Все грабли разложены в известных местах, остаётся только их аккуратно обходить.
Но, как говорится, кто не рискует, тот не пьёт шампанского. Если суть разработки как раз заключается в изменении этой проторённой дороги, поиске новых путей, то такой совет не очень подойдёт. Некоторые стартапы, изобретая свой велосипед, достигли впечатляющих результатов.
Простота всегда выигрывает
Ну, история знает и другие примеры. Например, автомобиль Жигули 2101, по-видимому, проще Tesla Model S. Но, как мне кажется, потребители склонны предпочесть что-то более сложное.
Или пример из области баз данных. DynamoDB — попроще чем Postgres. Там даже толком не поддерживается SQL. Но для многих задач архитекторы предпочитают RDBMS.
Видимо, есть какие-то преимущества в сложных решениях...
Среды вне продакшена имеют убывающие доходы
Здесь трудно даже понять, что имеется в виду.
Доход по определению приносит только конечный продукт. Это же не значит, что надо уволить отдел бэкенд, т.к. там самые высокие расходы?
staging/dev среды, несмотря на отличие от prod, позволяют
- проводить отладку в условиях, приближенных к prod,
- обнаруживать массу проблем без риска потери пользователей,
- свободно экспериментировать с новыми фичами,
- …
Если бы они не были нужны, никто бы их не делал.
По поводу трафика. (1) можно делать копию prod-базы на регулярной основе (с обфускацией, если это необходимо); (2) во многих случаях можно направлять копию входящих событий на параллельную систему (staging/dev) в какой-либо пропорции 0-100%. Так что вполне можно получить очень близкую к реальности картину.
Всё всегда ломается
С этим, пожалуй, соглашусь. Несмотря на то, что есть вещи, которые работают очень надёжно, мы всё-таки должны иметь планы и стратегии реакции на всевозможные отказы.
Вместо того, чтобы быть шлюзом для деплоев, отдел QA может непрерывно проверять работу продакшена.
Эх, жалко автор статьи забугорного происхождения. Не смотрел он наш фильм «Операция Ы», в котором Никулин говорит Вицину: «Иди на кошках тренируйся».
Софт везде разный, разные тех требования, безопасность, разный масштаб, разный размер команд, разные методологии, разные архитектуры.
А в статье — херак херак и в продакшен.
Разработка должна ориентироваться на продакшен, всё остальное — чушь