Разработка должна ориентироваться на продакшен, всё остальное — чушь

Автор оригинала: Paul Osman
  • Перевод


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

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

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

1. Эксплуатировать свой код должны инженеры.


Разработчики — это главные специалисты по коду, который они пишут, и они должны отвечать за его эксплуатацию в продакшене. В данном контексте под «эксплуатацией» подразумевается деплой, инструментирование и мониторинг кода, а также помощь в разрешении инцидентов, связанных с этим кодом или влияющих на него. Ответственность за эксплуатацию кода стимулирует — она поощряет разработчиков писать поддающийся наблюдению и простой в отладке код, а также связывает их с тем, что на самом деле важно заказчику. Она стимулирует их интересоваться тем, как их код ведёт себя в продакшене. Важно, чтобы инженеры обслуживали код по вызову, это создаёт цикл положительной обратной связи и позволяет проще понять, окупаются ли их попытки писать готовый к продакшену код. Я слышал, что кто-то жалуется на перспективу обслуживания по вызову, поэтому задам только один вопрос: если код не будете обслуживать вы, то кто будет это делать?

Если вы ещё не обслуживаете свой код по вызову, но хотите это делать и можете повлиять на данное решение, то можно поступить следующим образом. Настроить графики PagerDuty (или подобного ему сервиса) для каждой группы инженеров, отвечающих за конкретные службы или части кода. Качественный график содержит 6–8 инженеров. Существует множество вариаций, но обычно используются недельные смены, когда ты неделю запасной на вызове и неделю основной. Настройка алертов — это отдельная тема, которая, вероятно, заслуживает целого поста, но в общем здесь стоит сосредоточиться на том, что влияет на заказчиков (см. Symptom-based alerting); помните, что в конечном итоге за реакцию на алерты отвечаете вы, так что вы можете их изменять.

Рекомендую посмотреть два доклада, касающиеся темы настройки алертов: Лиз Фонг-Джонс говорит о SLO в Cultivating Production Excellence, а Адитья Мукерджи обсуждает техники управления алертами в Warning: This Talk Contains Content Known to the State of California to Reduce Alert Fatigue.

2. Покупка почти всегда лучше создания


Если можно избежать создания чего-то, то это стоит сделать. Код — самый дорогой способ решения задачи, не касающейся основной сферы вашего бизнеса. Для большинства мелких или средних компаний существуют опенсорсные или лучше того — хостинговые решения, решающие широкий спектр стандартных задач. Я имею в виду такие вещи, как хостинг git-репозиториев (Github, Gitlab, Bitbucket, etc), инструменты для наблюдаемости (observability) систем (Honeycomb, Lightstep и т.п.), облачные базы данных (Amazon RDS, Confluent Kafka, и т.п.), системы алертов (PagerDuty, OpsGenie и т.п.), а также целую кучу других стандартных технологий. Это относится и к инфраструктуре — если возможно, не разворачивайте собственные кластеры Kubernetes (примечание: а вам вообще нужен Kubernetes?), не разворачивайте собственные балансировщики нагрузки, если можно использовать Amazon ELB или ALB.

К сожалению, синдром неприятия чужой разработки очень распространён и некоторые компании очень сильно на этом обжигаются. Я видел коллективы, тратящие время и деньги на повторное изобретение компонентов при наличии на рынке более качественных и проверенных опытом альтернатив. Те же самые коллективы почти всегда тратят потом годы на борьбу с накопившимся в результате техническим долгом. Если вы находитесь в такой команде, и у вас есть желание и возможность влиять на изменения, то начинайте по одному откатывать подобные решения. Перенесите свои базы данных в облако, проведите миграцию системы feature flagging в SaaS-инструмент (например, в LaunchDarkly). Продолжайте процесс, пока единственным поддерживаемым вами ПО не станет ПО, обеспечивающее выгоду заказчикам. Вы сильно выиграете от этого.

3. Упростите процесс деплоев


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

Во многих командах существуют графики запрета деплоев (их могут называть code freeze) или применяются политики деплоев типа «Никаких деплоев по пятницам». Из-за таких периодов простоя могут накапливаться изменения, что увеличивает риск аварий.

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

Большое внимание в последнее время привлекла книга Accelerate. Рекомендую прочитать её, если вы ещё этого не сделали. Её авторы также публикуют отчёты State of DevOps, в которых полно тщательно исследованной информации о состоянии различных компаний отрасли. Неудивительно, что две из четырёх ключевых метрик, на которые делается упор в книге, непосредственно связаны с нашей темой (Deploy Frequency, Change Lead Time). Деплои — это пульс вашей компании.

4. Доверяйте людям, которые ближе всего к практической работе


Лучше всего понимают систему те, кто с ней работает. Это относится к любым частям социально-технических систем, в которых все мы участвуем. В случае программных систем уровень рисков эксплуатации лучше всего понимают инженеры, ежедневно выполняющие деплои и обслуживающие по вызову наиболее критичные службы. Существует печальная тенденция — менеджеры обычно переоценивают степень прогресса команд в некоторых переходных процессах, например, при переходе в облако, DevOps, и т.д. Чем выше по цепочке руководства, тем больше эта погрешность оценок. Инженеры, которые выполняют деплои и которым звонят, когда что-то ломается, знают, где закопаны все скелеты и во что нужно вкладывать больше труда. Поэтому они должны быть основными заинтересованными лицами, ответственными за расставление приоритетов технической работы.

Ещё одно проявление этого принципа относится к командам, работающим с платформой или оказывающим технические услуги. Если вы отвечаете за создание некоего общего компонента, используемого в вашей организации (например, системы обмена сообщениями, CI/CD-инфраструктуры, общих библиотек или сервисов) то вас ждёт неприятное открытие: люди, пользующиеся результатом вашей работы, во многих случаях знают о нём больше, чем вы. Они косвенно понимают, как она обслуживает потребителей и знают, какие препятствия и проблемы нужно преодолеть, чтобы заставить систему работать. Прислушивайтесь к ним, чтобы понять, как улучшить UX ваших сервисов и инструментов.

5. Меры QA снижают качество


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

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

Во-вторых, выполняющим QA отделам часто не хватает контекста и времени. В результате они могут начать тестировать «воздействие» вместо «задач». Например, я видел примеры того, как отделы QA тратят время на тестирование того, что при совершении действий с UI что-то происходит в базе данных. Что случится, когда разработчик проведёт рефакторинг этого компонента UI и изменит лежащую в его основе модель данных? Функциональность продолжит работать, однако тесты поломаются. Поскольку в это втянуты два отдела, для исправления потребуется координирование и время. Ещё я видел, как отделы QA препятствовали деплоям из-за непрохождения тестов после добавления в слой CDN кэширования — TTL в 5 секунд ленты новостей может быть даже незаметен пользователю, но способен испортить тесты QA, вызывая необязательные конфликты между разработчиками и инженерами QA.

К счастью, эту проблему решить легко. Вместо специального отдела QA, работающего над ручными и автоматизированными контрольными тестами, выполняемыми в выдуманной QA-среде, нужно направить усилия этой команды на постоянное тестирование в продакшене. Вместо того, чтобы быть шлюзом для деплоев, отдел QA может непрерывно проверять работу продакшена. Кроме того, отделы QA хорошо подходят для ведения проектов хаос-инжиниринга, при которых в продакшен намеренно инъектируются сбои. Инженеры QA могут также работать над повышением надёжности CI/CD-конвейера, чтобы деплои больше не превращались в кошмар.

6. Скучная технология — это отлично.


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

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

При использовании скучной технологии можно положиться на большое сообщество её пользователей. Можете как хотите ругаться, но существует очень мало проблем PHP, с которыми до вас не столкнулся кто-то ещё. Сегодня это, вероятно, справедливо для достаточно широко используемых версий Ruby on Rails. Я часто говорю, что стремлюсь находиться в третьей волне освоения технологий. Первая волна — это организация, находящаяся на переднем крае прогресса. Вторая волна — это люди, готовые на определённый риск. Пропустите вперёд эти две группы, пусть они столкнутся со всеми крупными проблемами, а потом ступайте сами, получая выгоду от всего их наработанного тяжким трудом опыта.

7. Простота всегда выигрывает


Здесь мало что можно сказать, но мы все ведь пишем YAML и JSON вместо XML, а пользуемся HTTP вместо CORBA, RMI, DCOM, XPCOM и т.д. Правда? Аналогично этому, я бы лучше отлаживал проблемы в LAMP-стеке вместо архитектуры микросервисов.

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

8. Среды вне продакшена имеют убывающие доходы


Можно было бы использовать и более прямой заголовок — «Среды вне продакшена — это чушь». Среды типа обкатки (staging) или препродакшена — это абсолютная ложь. В начале проекта они имеют небольшой смысл, но когда он начинает расти, изменения происходят чаще и вы начинаете ощущать инерцию. Кроме того, среды вне продакшена по определению не получают трафика, из-за чего фундаментально отличаются. Количество трудозатрат на поддержку сред вне продакшена нарастает очень быстро. Вам никогда не удастся отдавать приоритету работе вне прода, потому что заказчики не касаются его напрямую. Потом вам придётся выкраивать ресурсы на работу этой среды, собранной из палок и изоленты, чтобы можно было тестировать в ней изменения, лгать себе, притворяясь, что она хотя бы чем-то похожа на продакшен.

9. Всё всегда ломается


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

В этой области может быть полезным хаос-инжиниринг. Инъекции сбоев в продакшен могут повысить уверенность в том, как реагировать на неожиданное поведение системы. Особенно эффективным способом тренировки инженеров по различных ситуациям сбоев могут быть Game Days.

Заключение


Многие из точек зрения, перечисленные в этом посте, кажутся как минимум контринтуитивными, а то и спорными, однако я всё-таки уверен в их истинности. Это не значит, что меня не переубедить, но это маловероятно. Если вы абсолютно согласны или не согласны, то пишите мне в Твиттер. Мне было бы очень любопытно послушать о вашем опыте.



На правах рекламы


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

VDSina.ru хостинг серверов
Серверы в Москве и Амстердаме

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

    +1

    Хорошая статья, хоть перевод и подпортил слегка впечатление.


    Мне довелось как-то работать над одним довольно крупным сервисом по описанным принципам. Не было стейджа и тестеров. Каждый девелопер сам тестировал свои изменения, деплоил сразу на прод и, если что, сам откатывал. Такой подход побуждает более ответственно относиться к тому, что ты написал, тщательно продумавать все корнер кейсы, подкладывать соломинки во все возможные места. И это неплохо работало: частота деплоев на прод — десятки в день, частота откатов — единицы в месяц. Причем последствия ошибок в коде как правило довольно локальны, в отличие от ошибок в настройках инфраструктуры, из-за которых может развалиться вообще все.


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

      –1
      этот подход никогда не будет применяться, например, для банковских сервисов

      да почему же, очень даже применяется

        0

        А как решаются вопросы с ценой ошибки и доступом девелоперов к проду?

          0

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

            0

            Спасибо, ждал этот вопрос)


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

          0
          Каждый девелопер сам тестировал свои изменения, деплоил сразу на прод и, если что, сам откатывал

          Звучит замечательно. Сначала когда-то давно разработчики как-то так и работали. Но как мне кажеСначала то когда-то давно тся, разделение на QA и разработку оно не просто так произошло.


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


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

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

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


            разделение на QA и разработку оно не просто так произошло

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


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

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

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


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

              Мне кажется ответ либо очевиден, как в случае с каким-нибудь сайтом-визиткой или системой учёта рассчётов по ЖКХ, либо учесть всё просто нереально и приходится доверяться интуиции.

          +8

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

            +2

            А ещё готовые решения могут покрывать 90% требований и требовать неожиданно большого количества ресурсов для покрытия последних 10%

            +18

            Тестирование на проде… Тогда логичный следующий шаг — QA не нужен. У нас же есть A/B тестирование! Выкатываем новый функционал на часть пользователей, смотрим что навернулось, чиним, переходим к шагу 1. И вот уже никого не удивляют новости о том, что обновление операционной системы не только привело саму систему в неработоспособное состояние, но заодно и грохнуло часть пользовательских данных.
            Добро пожаловать в дивный новый мир, где нормально не работает ничего и никогда.

              0

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

                0
                Мне довелось поработать в компании, в которой был выделенный отдел QA, который кроме тестирования ещё и релизами/деплоями занимался. Еще был выделенный отдел DevOps. Также я сейчас работаю в компании, в которой используется описанный в статье подход. И я могу сравнить оба варианта. В частном случае, все зависит от продукта и рисков. Но в общем, эффективнее подход, описанный в статье. В случае с QA отделом ПО теоретически может быть стабильнее, но начинается интеграционный ад, когда мержаться несколько веток отделом QA, попытка разрулить конфликты, не понимая, как это лучше сделать, начинают привлекать разработчиков, тратя их время. Релизный цикл катастрофически затягивается, и некоторые фичи выкладываются на прод через месяц, когда все тестирование завершается, ибо QA готово тестировать только всю фичу целиком. Релизы редкие, поскольку QA отдел становится узким горлышком. И задачи намного чаще возвращались в разработку из QA. В случае, когда нет QA и релизит сам разработчик-инженер, релизы маленькие и быстрые, по нескольку раз в день могут быть. В статье правильно написано, что, когда на разработчика накладывается ответственность за релиз и проверку, он более ответственно подходит к реализации и тестированию.
                Хотя продукты в первом случае и во втором были разные, и в первом случае подход был обусловлен определенными историческими причинами, но анализируя это сейчас и применяя описанный подход в первом проекте, я думаю, скорость доставки была бы намного выше, а качество если бы не осталось на том же уровне, то скорее всего бы даже выросло.
                  0

                  У вас совершенно очевидно в первой компании был некорректно построен процесс деплоя.
                  А вот это вот "И задачи намного чаще возвращались в разработку из QA" — это недостаток? Ну т.е. тестировщики нашли баги — какие плохие тестировщики? И вы серьезно считаете, что если их отменить, то качество кода на проде вырастет?
                  Ну и про маленькие релизы от девелоперов это тоже ниоткуда не вытекает. Как разработчик захочет, так и выкатит. Фатал на прод можно вообще микропатчем выложить.

                    0
                    > А вот это вот «И задачи намного чаще возвращались в разработку из QA» — это недостаток? Ну т.е. тестировщики нашли баги — какие плохие тестировщики?

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

                    > И вы серьезно считаете, что если их отменить, то качество кода на проде вырастет?

                    Ну практика показывает, я же не с пустого места считаю)

                    > Ну и про маленькие релизы от девелоперов это тоже ниоткуда не вытекает.

                    Чем меньше конвейер до прода и кол-во звеньев, тем меньше релизный цикл. Если у вас в релизе несколько отделов задействовано, вы автоматически получаете как минимум временные расходы на коммуникацию и синхронизацию.
                      0
                      > У вас совершенно очевидно в первой компании был некорректно построен процесс деплоя.

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

                    А разве так не делает большинство? Пользователь.

                    +11

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


                    Я могу привести кучу инструментов, которые очень, очень, ОЧЕНЬ опасно тестировать на продакшене.
                    Из связанного с деньгами:


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

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

                      +2
                      Мне не хотелось бы с каждым серверным или клиентским релизом быть подопытной мышкой и ждать подлянки в виде плохо протестированных багов.

                      Во-первых, противопоставление короткого цикла поставки и хорошо протестированных багов — это как раз и есть пример "ложной дихотомии". Деплой изменений непосредственно в прод не означает, что они перед этим не должны тестироваться. Ровно как и наличие дева, стейджа и пре-прода с армией тестеров не означает, что тестирование будет сделано хорошо. Об этом сказано в статье в разделе "5. Меры QA снижают качество".


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

                        +4

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


                        В главе 5 автор ставит знак равенства между ручным тестированием и отделом QA. По сути, рисует из QA инженеров манки-тестеров. Хороший QA инженер умеет всё то же самое, что и девелопер. Только фокус его внимания смещён с написания кода приложения на контроль кода приложения и контроль целостности системы (т.к. приложение состоит из разных подсистем).


                        Делает он это здесь:


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

                        и здесь:


                        выполняющим QA отделам часто не хватает контекста и времени. В результате они могут начать тестировать «воздействие» вместо «задач».

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


                        В идеальной вселенной разработчики умеют во все эти этапы и они становятся full stack developer, мастера на все руки. В реальности таких разработчиков, которые через полгода работы в компании не забивают на всё, кроме написания кода, единицы.


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


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

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


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

                          0

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


                          В главе 5 автор ставит знак равенства между ручным тестированием и отделом QA

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


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


                          Хороший QA инженер умеет всё то же самое, что и девелопер

                          Не видел в жизни ни одного QA, который мог бы например, написать Spark-джобу или хотя бы бекенд на Akka Http. Наверное, эти легендарные "Хорошие QA" так же редки, как единороги.


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


                          а потом приходят вялые QA инженеры и всё портят своей тупизной

                          В статье такого нет.


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

                          Опять-таки, такого нигде не утверждается.


                          он целенаправленно ставит себя напротив сообщества с целью показать "вы все дураки, один я Д'Артаньян"

                          Почему вы так решили?


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

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

                            0

                            Я спорю с тезисами статьи, такими как:


                            • Разработка должна ориентироваться на продакшен, всё остальное — чушь
                            • Меры QA снижают качество

                            К остальным тезисы, при "правильном" их прочтении, я претензий не имею


                            Ну если почитать только первое предложение этой главы, то да

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


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

                            Контроль качества: инструменты разработчика, фреймворк для написания тестов, контроль качества тестов и прочее, прочее, прочее.


                            Не видел в жизни ни одного QA, который мог бы например, написать Spark-джобу или хотя бы бекенд на Akka Http. Наверное, эти легендарные "Хорошие QA" так же редки, как единороги.

                            Ну а я видел (не шучу). И видел очень много фронтенд-девелоперов, которые не смогли бы сделать то же, что вы просите. А этот ваш восхитительный бэкендер не смог бы написать <подставить очередную редкую невероятную технологию>. Это пример ложной дихотомии.


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

                            Да, странно требовать. Тем не менее, Developer in testing часто в первую очередь QA-инженер, а потом уже — девелопер.


                            В статье такого нет.

                            Цитирую:
                            "Ещё я видел, как отделы QA препятствовали деплоям из-за непрохождения тестов после добавления в слой CDN кэширования — TTL в 5 секунд ленты новостей может быть даже незаметен пользователю, но способен испортить тесты QA, вызывая необязательные конфликты между разработчиками и инженерами QA"


                            Почему вы так решили?

                            А вы посмотрите на количество комментариев под этой статьёй...


                            Можно либо навязать больше бюрократии и процедур, что приведет к удлинению цикла поставки, либо просто дропнуть стейдж и радоваться жизни.

                            Можно. Но это же как раз пример плохого использования технологии, а не плохой технологии. Отказаться от технологии там, где она не работает — это одно. А другое — говорить, что этот подход — какашка. То ли "исторически так сложилось", то ли лень девелоперов, то ли нет в этом действительно нет необходимости.
                            Как часто даже сейчас я слышу: "ну зачем нам система контроля версий? у нас же простой продукт..." Это всё одного уровня проблема. Лень, непонимание, нежелание учиться на чужих ошибках.

                              0
                              Я спорю с тезисами статьи, такими как:
                              • Разработка должна ориентироваться на продакшен, всё остальное — чушь
                              • Меры QA снижают качество

                              Ну вот да, в этом и дело!


                              • Оригинальная статья называется "Production Oriented Development", про "чушь" — это изобретение переводчика
                              • Глава 5 называется "QA Gates Make Quality Worse", никаких "мер", автор всю главу говорит, что QA не должны стоять как ворота между девелопером и продом, а должны стоять где-то сбоку

                              А вы посмотрите на количество комментариев под этой статьёй...

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

                                0

                                Я прочитал статью сначала в оригинале, а потом в переводе. И я спорю с автором статьи — там, а тут высказываю своё мнение.


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


                                Радикализм в любых технологиях — плохо. Если где-то пишут чудовищно много автотестов, но забивают на ручные проверки — плохо. Если наоборот всё в ручную проверяют, без тестов — плохо.
                                Всё катят на продакшен — так себе идея. Маринуют код месяцами на стейджинге — тоже.
                                Соблюдайте баланс. Не впадайте в крайности. На мой взгляд, автор статьи как раз в крайности и впадает.

                          0

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

                        +2
                        Стейдж — хорошее место для демонстрации изменений заказчику (внешнему или внутреннему) перед выкаткой на прод.
                        «QA не нужны, тесты не нужны, надо быстро выкладывать код, и так же быстро его откатывать» — концепция разработки так себе, она годится разве что для проекта на старте, когда цена ошибки мизерная, или же когда проект еще вообще не стартовал, а только готовится.
                          0
                          концепция разработки так себе, она годится разве что для проекта на старте, когда цена ошибки мизерная, или же когда проект еще вообще не стартовал, а только готовится

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


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

                            0
                            Как раз когда все очень быстро меняется — важно понимать, что могло поломаться или забыли исправить. А такое понимание появляется только из тестов.
                            0

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

                              0
                              То есть разрабы пишут тесты вместо QA?
                              Ну ок, юнит-тестирование — это норм, но тестирование интерфейса? Полагаю, QA справятся лучше с написанием тестов для фронта.
                            +6

                            Подход называется — "бананы дозревают у покупателя"?

                              0

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

                                +1

                                Да, только пользователь фреймворка делает осознанный выбор, надо ли ему накатывать релиз-кандидат или посидеть на стабильной версии. А то и посидеть на прошлой стабильной пока пару сервисных релизов не выкатят. А вот пользователю веб-сервиса этот выбор никто не даёт.

                                  0

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


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

                              +2

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

                                +2

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

                                  0
                                  PagerDuty и пр. возможны скорее только в реалиях США, где работодатель имеет законное право требовать от сотрудников работать все 24 часа все 7 дней в неделю без никаких ограничений и доплат.
                                    +1
                                    ничего нового в статье — один в один все утащено из SRE подхода от Google. К тому же на статьи с таким заголовком у меня уже реакция на уровне спинного мозга — открываем, проматываем, минусуем.
                                      0

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


                                      Да, есть expedite review, есть hard update, но и то, и то — не панацея. Есть версионирование API, но даже с ним деплои планировать и синхронизировать приходится.

                                        +4
                                        1. Эксплуатировать свой код должны инженеры

                                        — не так давно (2017г) software developer из GitLab случайно потер 300Гб данных. Ни на что не намекаю, но все же хочется чтобы сервера админили те кто хорошо понимает что такое бэкапы и в каком они состоянии

                                        2. Покупка почти всегда лучше создания

                                        — новость от 26.11.2020: «Сбой AWS ударил по тысячам онлайн-сервисов». Перестали работать даже пылесосы и «умные» дверные звонки. Сбои бывают у всех, но когда твой бизнес зависит от кого то другого это напрягает

                                        4. Доверяйте людям, которые ближе всего к практической работе

                                        — в итоге в компании вырастет «золушка», которая делает все. Дальше золушка устанет и уйдет или, при дурном воспитании, начнет шантажировать руководство

                                        5. Меры QA снижают качество

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

                                        Дальше читать устал, какая то «тугая» статья или это я «тугой»

                                          0
                                          Как-то у вас все черно-белое.

                                          > — не так давно (2017г) software developer из GitLab случайно потер 300Гб данных

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

                                          > Сбои бывают у всех, но когда твой бизнес зависит от кого то другого это напрягает

                                          Можно подумать, вы всегда пишите свой фреймворк или свою CI/CD с нуля) Иначе это получается крайне дорогая разработка) Важно перед использованием стороннего инструмента провести всесторонний анализ и оценку рисков при его использовании. И уже тогда делать выбор, если выгода перевешивает риски.

                                          > в итоге в компании вырастет «золушка», которая делает все.

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

                                            — автор (как я понял) утверждает обратное

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

                                            профессионалам надо доверять, а не говорить им, как делать свою работу

                                            — в пределе это устранение руководителя от процесса и потеря контроля над ним
                                          +1

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


                                          1. Эксплуатировать свой код должны инженеры
                                            Если проект небольшой — то да, хорошая идея. Если же проект большой, то, к сожалению, это труднореализуемо. Для больших проектов люди придумали разделение труда. Поэтому-то есть product owner'ы, которые выступают теми-самыми-инженерами-которые-эксплутируют-и-хорошо-понимают-всё, и разработчики, QA, DevOps'ы, team lead'ы, PM-ы и т.п., которые по поручению product-owner'а выполняют различные работы. И коммуникации в больших командах можно настроить достаточно неплохо при должном старании.


                                          2. Покупка почти всегда лучше создания
                                            Пример противоположной ситуации. AWS продаёт сервис NAT gateway (что-то типа роутера). Аналогичный сервис можно реализовать на других сервисах и получится дешевле (в 10-100 раз). Единовременные затраты на разработку довольно быстро окупятся.


                                          3. Упростите процесс деплоев
                                            Двумя руками за. Как мне кажется, CI/CD как раз об этом. Должна быть одна кнопка, которая отправляет изменения в продакшн.


                                          4. Доверяйте людям, которые ближе всего к практической работе
                                            Можно и шире сформулировать — "доверяйте профессионалам" :) Если люди непосредственно работают с пользователями, им можно доверять по вопросам UI/UX. Но я бы не стал доверять им архитектуру обработки данных. В этом вопросе лучше доверять другим специалистам.


                                          5. Меры QA снижают качество
                                            Как мне кажется, здесь какая-то подмена терминов. QA — quality assurance — обеспечение качества. Так что получается оксюморон. Видимо, автор имеет в виду какое-то несовершенство процессов QA в его компании.
                                            Ручному тестированию, конечно, нет места в цепочке CI/CD. Все необходимые тесты должны быть автоматизированы.
                                            Идея "тестирования в продакшене" хорошо известна по соответствующему интернет-мему. Как мне кажется, не для всех проектов такая идея подходит. В случае, если product owner считает возможным пожертвовать частью пользователей, и сэкономить на других мерах QA, то это, наверное, его право. Ему, по-видимому, надо будет обосновать это решение перед заинтересованными лицами (stakeholder'ами).


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


                                          7. Простота всегда выигрывает
                                            Ну, история знает и другие примеры. Например, автомобиль Жигули 2101, по-видимому, проще Tesla Model S. Но, как мне кажется, потребители склонны предпочесть что-то более сложное.
                                            Или пример из области баз данных. DynamoDB — попроще чем Postgres. Там даже толком не поддерживается SQL. Но для многих задач архитекторы предпочитают RDBMS.
                                            Видимо, есть какие-то преимущества в сложных решениях...


                                          8. Среды вне продакшена имеют убывающие доходы
                                            Здесь трудно даже понять, что имеется в виду.
                                            Доход по определению приносит только конечный продукт. Это же не значит, что надо уволить отдел бэкенд, т.к. там самые высокие расходы?
                                            staging/dev среды, несмотря на отличие от prod, позволяют


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

                                            • Если бы они не были нужны, никто бы их не делал.
                                              По поводу трафика. (1) можно делать копию prod-базы на регулярной основе (с обфускацией, если это необходимо); (2) во многих случаях можно направлять копию входящих событий на параллельную систему (staging/dev) в какой-либо пропорции 0-100%. Так что вполне можно получить очень близкую к реальности картину.

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


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

                                            Эх, жалко автор статьи забугорного происхождения. Не смотрел он наш фильм «Операция Ы», в котором Никулин говорит Вицину: «Иди на кошках тренируйся».
                                              0

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

                                                0
                                                Понравился тезис: «Не существует готовых систем, подходящих для любой компании или коллектива». Некоторые команды действительно застревают на деталях, а после продакшена оказывается, что лучше сконцентрироваться совсем на другом функционале, а глючный просто закрыть от пользователей.

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

                                                Самое читаемое