Подписаться
Читать в телеграм
В чем состоят основные проблемы бизнеса в части разработки продуктов?
Какие профиты дает автоматизация тестирования ПО?
Как Банк «Союз» ускорил Time-to-Market при разработке интеграционной шины для своего кредитного конвейера?
С точки зрения современной банковской сферы вывод продукта на рынок — критический фактор, определяющий успех или же провал предприятия. Потребитель не будет ждать полгода или год, пока компания сможет удовлетворить его потребности в определенном банковском сервисе, тратя время на подготовку ИТ-мощностей, планирование стратегии и проведение ручных тестов. Поэтому одним из векторов цифрового развития становятся технологии быстрых изменений, способные поддержать вывод нового продукта на рынок безболезненно, эффективно и без задержек во времени.
От месяца к месяцу объем кода в продуктах растет: без отлаженных автоматизированных процессов команда вынуждена тратить время на ручные сборки и накат обновлений, на изнурительное ручное тестирование, исправление багов, запуск и поддержку обновлений. Вместе с тем растут и затраты компании, а в продукт начинают проникать блокирующие или критические ошибки. Команда теряет мотивацию, качество исполнения серьезно падает, а бизнес не выполняет обязательства в срок и теряет репутацию.
Именно поэтому уменьшение Time-to-Market как комплекс инициатив по внедрению методологий, процессов и инструментов автоматизации тестирования (QA), непрерывного развертывания и интеграции (CI/CD), DevOps — это ключевой ориентир для компаний, находящихся в разных весовых категориях, но в одном конкурентном поле с молодыми финтех-стартапами, умеющими действовать стремительно.
Почему автоматизация так важна и чем грозит ее отсутствие
В цикле разработки программного обеспечения, особенно когда речь идет о стабильной работе непростых банковских систем, автоматизированное тестирование или DevOps нельзя назвать главнейшей частью. Бизнес часто отказывается от вложений, пытаясь сэкономить на процессах, ценность которых ему неясна.
Однако, чтобы убедиться в важности этого этапа, компании достаточно задаться вопросом: а действительно ли наши системы достаточно хороши и наши разработчики выпускают все продукты в срок и с нужным качеством? Ну, а ее ИТ-специалисты пусть ответят, есть ли у них проблемы в коммуникациях с бизнесом. Вряд ли найдутся те, кто не признает, что время от времени страдает из-за сорванных сроков и допущенных ошибок. Простои по 3 часа после релиза, откаты на предыдущие версии 1–3 раза в год, перенос сроков выпуска обновления раз в 2–4 месяца и критические ошибки на выходе с потерями в миллионы рублей уже становятся обыденной практикой для многих компаний.
К сожалению, даже если ИТ-отдел осознает важность изменений, многие «традиционные» компании не принимают доказательства этого, не учитывают скорость возврата инвестиций от автоматизации.
Поэтому сейчас мы попробуем разобраться в трех ключевых проблемах бизнеса в отношении разработки продуктов и дадим несколько советов по их решению.
Долго
Рутина, повторяющиеся операции и отсутствие четко регулируемых процессов — первопричины срыва сроков.
Смоделируем ситуацию с небольшим упрощением.
На заметку
На старте проекта автоматизации всё не будет так просто. Расходы первые 2 месяца будут только расти: придется одновременно поддерживать старый процесс внесения изменений для бизнеса и внедрять новый, автоматизируя наиболее трудозатратные операции. Но уже через 4–6 месяцев инвестиции обычно окупаются.
Как бороться с проблемой? Необходимо выявить наиболее длительные по времени задачи, чтобы сравнить трудозатраты на ручной и автоматизированный процессы. К примеру, простая автоматизация сборки и автоматизация регрессионного тестирования могут уменьшить ФОТ (фонд оплаты труда) проекта на величину до 10%. А автоматизация подготовки тестовых данных — до 12%. График 1.
Дорого
Чем позже обнаруживается баг, тем дороже стоит его исправление.
Давайте рассмотрим ситуацию.
Вариант 1. Разработчик написал код, в котором нашли критичную ошибку только через одну-две недели (см. диалог выше). Разработчик уже работает над другой задачей. Пытаясь понять, что он делал в старой задаче и почему реализовал код именно так, он потратит какое-то время. Уже проведенное тестирование придется повторить после исправления ошибки.
Вариант 2. Разработчик к вечеру написал код, который нажатием нескольких кнопок был отправлен на автоматически развернувшееся виртуальное тестирование. По коду ночью «прошлись» автотесты, а уже утром команда получает полный отчет по всем багам. Работает принцип «сломал — почини».
Почему подобная простейшая оптимизация даст значительный эффект?
Причин несколько:
- Разработчик все еще работает над той же частью программного кода, он еще не забыл, что делал месяц назад, ему не нужно переключаться между контекстами, и корректировки он вносит буквально «на лету».
- Ветки кода не успели размножиться на последующие релизы, поэтому не придется исправлять один и тот же баг сразу в нескольких местах.
- Другие разработчики не вносят изменения в этот содержащий ошибки программный код.
- Тестировщик еще не успел потратить время на долгое регрессионное тестирование, которое придется повторять после исправления найденной ошибки.
Итог: экономия ФОТа за счет исключения ручного труда и соблюдение таймлайна проекта.
Простои по 3 часа после релиза, откаты на предыдущие версии 1-3 раза в год, перенос сроков выпуска обновления раз в 2-4 месяца и критические ошибки на выходе с потерями в миллионы рублей уже становятся обыденной практикой для многих компаний.
Неидеально
Приведем два простых примера из отраслей fintech и e-commerce, начавших буквально срастаться в эпоху развития маркетплейсов и экосистем.
В конце мая этого года в работе систем эквайринга и авторизации «Райффайзенбанка» возникли серьезные проблемы: платежи клиентов банка по дебетовым картам не уходили конечному получателю, а средства клиентов оставались заблокированными. В результате стало невозможно проводить операции.
А интернет-магазин «Связной» из-за сбоя в программном обеспечении в течение 15 минут продавал смартфоны по заниженным ценам: например, iPhone 8 с объемом памяти 64 ГБ можно было заказать примерно за 6000 рублей.
Почему происходят такие инциденты? Ответ кроется, как это ни парадоксально, в следующем вопросе: какое подразделение (исключая маркетинг) работает с перегрузками и в выходные перед самым выходом продукта на рынок? Это отдел, ответственный за тестирование. Он пытается всеми силами выдержать сроки, поставленные бизнесом. Любые задержки на предыдущих стадиях катастрофически сжимают сроки на финальный этап — тестирование.
А ведь именно полноценное и детальное тестирование поможет вовремя выявить недочеты и скорректировать их. Как результат, продукт нередко выходит на рынок с ошибками, а компания теряет клиентов, деньги и репутацию.
Как бороться с проблемой, если у вас система, в которой все процессы ручные и очень трудно что-то быстро поменять? Мы предлагаем это делать, используя аудит и выстраивание процессов. Идти шаг за шагом от первого быстрого результата (например, внедрения автоматической сборки и развертывания приложений) к полной автоматизации процессов с систематическим внедрением вендорских инструментов, с работой с автоматизацией и нагрузкой, средами, стендами, тестовыми данными и т.д.
Важно осознавать, что только наличие квалифицированных экспертов (как в штате, так и на подряде) станет гарантией результата. Опыт показывает, что в проектах разработки ПО некачественный подбор персонала с невысокой зарплатой «убивает» проект. Ни один DevOps-архитектор от подрядчика, будь он хоть чемпионом-автоматизатором, не разглядит все тонкости без грамотных разработчиков продукта, менеджеров проектов и тест-менеджеров со стороны заказчика.
18 апреля 2019 года интернет-магазин «Cвязной» из-за сбоя в программном обеспечении в течение 15 минут продавал смартфоны по заниженным ценам: например, iPhone 8 с объемом памяти 64 гб можно было заказать примерно за 6000 рублей.
Continuous Integration (CI)
Практика разработки программного обеспечения, которая заключается в постоянном слиянии рабочих копий в общую основную ветвь разработки (до нескольких раз в день) и выполнении частых автоматизированных сборок проекта для скорейшего выявления потенциальных дефектов и решения интеграционных проблем.
Ускорение Time-to-Market на примере кредитного сервиса «Банка СОЮЗ»
Факт заключается в том, что отлаженное тестирование напрямую влияет на основные бизнес-процессы. Конечная же прибыль зависит от вовлеченности команды, которая непосредственно связана с качеством конечного продукта и оперативностью запуска сервиса. Логика очевидна, верно? В случае с автоматизацией процессов даже одной системы «Банк СОЮЗ» получил на выходе многократное уменьшение Time-to-Market по сравнению с ручными тестами.
Как все начиналось? Каким образом изменения претворялись в жизнь? Опорной точкой стал постулат о том, что непрерывное обслуживание кредитных сервисов крупного современного банка невозможно без высокой степени автоматизации. Поэтому основной задачей был запуск кредитного конвейера. В свою очередь, его «двигателем» стала интеграционная шина — новое программное обеспечение, призванное оптимизировать работу большого количества платформ и приложений. Оно было разработано нами для бесперебойного взаимодействия внутренних систем банка с его клиентами.
Наша команда сделала выбор в пользу подхода Continuous Integration (CI). Он сводился к автоматизации сборки, установки и тестирования функциональности интеграционной шины. Это было сделано для максимально быстрого выявления потенциальных недочетов и решения интеграционных проблем. Стоит учесть, что благодаря непрерывному формированию онлайн-копий банковских систем (интернет-банка, базы данных клиентов и системы обработки кредитных заявок) тестирование и доработка функциональности шины проводились независимо от работ в других частях конвейера.
Процесс создания и обработки кредитных онлайн-заявок включает много этапов: формирование заявки, проверку паспорта и запрос данных о клиенте, построение графика платежей, подтверждение заявки… Запуск шины был призван реализовать по меньшей мере 400 таких сценариев. Ранее доработки любого из внешних приложений требовали большого количества ресурсов для корректировки работ внутренних систем и последующей перепроверки. Однако после внедрения интеграционной шины сервисы «разбились» на единые службы. Что это дало? Значительное облегчение внедрения в конвейер изменений. Например, единую задачу обработки заявки на кредит стало возможно расщеплять на подзадачи («проверить данные, внесенные клиентом», «получить данные по истории выплат по кредитам», «рассчитать кредитный рейтинг», «отобразить баланс счета» и т.д.).
Таким образом, при выявлении ошибок в работе всего комплекса изменения вносились в отдельные части шины, далее автоматически запускались проверки и в параллели постепенно пополнялся стек автоматизированных тестов.
Шина не имеет графических интерфейсов: поскольку ее автоматизация не требует значительных расходов на дальнейшую поддержку, она окупается в десятки раз быстрее. Уже на этапе разработки решения автоматические тесты каждого из сервисов шины проводились за 3 часа. Для сравнения, ранее это требовало 400–600 часов ручного тестирования. Кроме того, полная автоматизация тестирования многократно ускорила проверку обновлений. Такая оптимизация позволила подготовить конвейер к релизу на 3 месяца раньше и избежать неэффективного использования ресурсов.
В проектах разработки ПО некачественный подбор персонала с невысокой зарплатой «убивает» проект. Ни один devops-архитектор от подрядчика, будь он хоть чемпионом-автоматизатором, не разглядит все тонкости без грамотных разработчиков продукта, менеджеров проектов и тест-менеджеров со стороны заказчика.
Ускорение Time-to-Market — сайт интернет-магазина «М.Видео»
Компания «М.Видео» регулярно обновляет элементы пользовательского интерфейса, постоянно инициирует новые акции и расширяет ассортимент, своевременно отвечая на запросы рынка. Ниже мы расскажем о том, как ритейлер обеспечил высокую скорость разработки.
Несколько лет назад разработка шла по водопадной модели, когда один этап следовал за другим, а результаты работы отдавались в тестирование через 2–3 месяца, когда цена ошибки была уже слишком высока.
«М.Видео» совместно с нами претворила в жизнь ряд изменений, которые помогли не только ускорить разработку нового функционала, но и позволили в разы улучшить качество. В первую очередь был увеличен объем покрытия регресса функционала сайта тестами, за счет чего заметно повысилось качество работы интернет-магазина. Затем было автоматизировано количество ручного труда разработчиков и администраторов за счет автоматизации сборки и раскатки изменений. Разработку изменений стали параллельно выполнять несколько команд по методологии Agile.
Но приемочное тестирование изменений существенно замедляло выпуск новых релизов ПО для сайта, и в компании приняли решение автоматизировать рутинные операции тестирования, а также использовать те же самые автотесты на ранней стадии разработки. Так была создана специализированная платформа автотестов.
Помимо этого, был выстроен оптимальный процесс разработки и тестирования, когда после каждого локального изменения запускаются автотесты на смоук или регресс функционала сайта.
Такой подход позволил разработчикам практически сразу выявлять и исправлять дефекты в обновляемой системе, не дожидаясь финального приемочного тестирования. Все эти меры снизили количество ошибок в функционировании интернет-магазина и уменьшили время вывода изменений на продуктив на 30%.
Выгода от автоматизации процесса тестирования
При создании продукта в условиях неоптимально выстроенных процессов высок риск релиза с серьезными недочетами и излишними временными тратами. В результате бизнес несет дополнительные расходы из-за оплаты неэффективного труда персонала, из-за срыва дедлайнов и «растягивания» процессов, из-за корректировки критических или блокирующих ошибок.
Баги могут вызвать не только точечные проблемы. Последствия могут быть весьма ощутимыми: продажа товара с огромными скидками из-за сбоя, остановка работы части функционала личного кабинета из-за непредвиденной нагрузки, неработающие элементы интерфейса в системе, которую одновременно используют большое количество сотрудников... В масштабах бизнеса не бывает маленьких ошибок, все они так или иначе ведут к потере ресурсов и лояльности пользователей. Автоматизация нацелена как раз на ускорение процессов и исключение риска «человеческих» ошибок, сделанных по невнимательности или в спешке.
Кстати, некоторые виды работ едва ли осуществимы усилиями одной команды. Иногда для решения задачи с горящими сроками требуется на несколько дней профессионал с узкой специализацией (например, ModBus, Clojure или Erlang). Именно поэтому мы все чаще наблюдаем, как ИТ-подразделения крупных компаний переходят от работы с подрядчиками (у которых как раз есть такая экспертиза) к глубокому партнерству, интеграции команд с обменом опытом и смартсорсингу.
Советы для перехода на автотесты
01
Используйте подрядчиков, не бойтесь прибегать к их помощи для автоматизации процессов — это разгрузит ваших специалистов. При этом не советую экономить, отдавая одну систему в руки большого количества разных подрядчиков. Слабая интеграция команд способна нанести намного больший вред, чем высокая ставка за человеко-день.
02
Не допускайте конфликта интересов. У каждого своя роль, и, например, ведущий разработчик не должен отвечать за конечное тестирование, на эти задачи должен быть выделен тест-менеджер. В противном случае это может нанести значительный ущерб процессам.
03
Помните об экономическом эффекте оптимизации: ручные, монотонные и часто повторяющиеся операции однозначно следует автоматизировать.
04
Уходите от водопадных моделей там, где это можно сделать, и учитесь работать по Agile- спринтам, разделяя работу команд.
05
Внедряйте метрики, позволяющие командам видеть свой прогресс.
06
Внедряя методологии уменьшения Time-to-Market (QA/CI/CD/DevOps), не забывайте материально мотивировать всех участников процесса по результатам достижения вех проекта.
07
Анализируйте процессы, в которых имеются временные простои и проблемы с качеством. Внимательно отслеживайте статистику по ошибкам и причинам их возникновения, не допуская их повторения в будущем.
08
Боритесь с узкими местами. К примеру, поищите решение распространенной проблемы — объединения всех веток кода в релизную в последний день перед началом приемочного тестирования. Это даст значительный эффект, измеряемый в снижении количества ошибок и уменьшении трудозатрат.
09
Не стремитесь сразу «стать ИТ-компанией» и уменьшать Time-to-Market на всех проектах. Начните с жизненно важного: обследуйте процессы, обозначьте ожидания и границы проекта, соберите команду экспертов и оцените план по срокам, рискам и стоимости.
Итак, резюмируя, можно сказать, что бизнесу и ИТ стоит опираться на следующие постулаты:
- Чем меньше автоматизации и больше рутины, тем выше риск ошибок и длиннее сроки выполнения задачи.
- Чем позже будет выявлен баг, тем дороже обойдется его исправление.
- Чем меньше степень погружения подрядчиков в бизнес-процессы и задачи друг друга, чем больше подразделений задействовано в проекте, тем сложнее привести проект к успеху без недочетов и срыва сроков.
Мы видим, как год за годом ИТ-специалисты «обрастают» большей экспертизой и учатся общаться с бизнесом: аргументируют необходимость выделения бюджета на процессы автоматизации, подтверждают ценность принятия того или иного нововведения, используя расчеты ROI. В случае с автоматизацией тестирования выгода для компании заключается в улучшении взаимодействия команд, а для конечных потребителей — в получении качественного продукта в требуемые сроки.
Александр Алексеев
Эксперт Центра программных решений компании «Инфосистемы Джет».
Комментарий
Я не согласен с тем, что Time-to-Market является угрозой для ИБ. Практики, влияющие на ускорение вывода продукта на рынок, так или иначе улучшают безопасность как цифрового продукта, так и компании. Исключение ― планомерное игнорирование ИБ и отсутствие подобной экспертизы при проработке архитектур процессов автоматизации.
Стратегия развития CI/CD предполагает переход от закрытого контура к открытому, то есть применение облачных технологий и вендорских PaaS-решений. Грубо говоря, это унификация и глобализация процессов DevOps. Причем переход на открытые контуры сам по себе предполагает наличие защищенных механизмов, поэтому происходит трансформация в DevSecOps с применением следующих подходов:
- защищенное хранилище ключей и авторизационных данных (vault);
- защищенное хранилище артефактов (nexus, artifactory);
- защищенное хранилище docker-образов (registry);
- хранилище «золотых» копий;
- автоматизированный контроль состояний сред;
- автоматизированное ИБ-тестирование кода приложений (статический анализ, пентесты).
Технологии автоматизации помогают участникам процесса разработки и эксплуатации, в том числе и ИБ-специалистам. К сожалению, по моему опыту, сотрудники департаментов ИБ зачастую обособлены от процессов разработки и эксплуатации систем и не желают принимать участие в современных подходах автоматизации, предпочитая появляться на поздних этапах реализации CI/CD. Уверен, что их своевременное участие в проектировании CI/CD-процессов позволило бы сделать продукт более безопасным.
Переход к концепции Everything as Code ― будущее не только DevOps, но и всех ИТ-систем, а также в целом ИТ-подразделений в компании. Она предполагает, что хранилище исходного кода (git) является единым источником всех знаний и компетенций обо всех процессах разработки и эксплуатации ПО. Опираясь на это базовое знание, мы выстраиваем наши процессы. В git описаны среды разработки, тестирования, продлайк, прод и процессы автоматизации, то есть весь стек практик IaaS, PaaS, SaaS. Там же хранятся все компоненты приложений и кодовая база. Все необходимое находится под рукой разработчика и элегантно защищается с помощью шифрования. И это работает!
Пример из практики, подтверждающий, что автоматизация помогает ИБ, — это запрет системным администраторам вносить изменения на серверы любыми способами, кроме использования систем управления конфигурациями (ansible, chef, puppet). В каждый момент времени сотрудник ИБ может не только посмотреть состояние любого сервера по исходному коду систем управления, но и применить эти конфигурации для проверки или отката состояния сервера до требуемого. При этом особенности git предоставляют сотруднику ИБ информацию об авторе, времени и цели внесения тех или иных изменений. Это открывает невероятные возможности.
Игорь Фадеев
Эксперт Центра программных решений компании «Инфосистемы Джет».
Комментарий
Проблемы автоматизации разработки ПО с точки зрения ИБ:
- Злонамеренное использование авторизационных данных. Дело в том, что любые автоматизированные процессы (пайплайны) внутри себя хранят авторизационные данные. Злоумышленники, получив доступ к этим данным, могут использовать их в своих интересах либо модифицировать код пайплайна так, чтобы он сам стал представлять угрозу.
- Инженеры пренебрегают вопросами безопасности ради сокращения Т2М. Концепция «Time-to-market» предполагает постоянное сокращение времени реакции компаний на запросы рынка. На уровне разработки это означает оперативное реагирование DevOps-инженеров на любые изменения компонентов продукта. Таким образом, пайплайны постоянно модифицируются, причем часто — разными инженерами, не уделяющими должного внимания вопросам безопасности.
- Информационная безопасность не является приоритетом. Даже если сотрудник ИБ найдет уязвимости в уже работающем пайплайне, ему будет сложно убедить коллег остановить CI-процесс до устранения всех недочетов. Для этого, скорее всего, заведут отдельный таск и поставят его в очередь в соответствии с расставленными бизнесом приоритетами. При этом никто не гарантирует, что в результате очередной модификации в пайплан опять не попадет небезопасный код.
- Безопасники не успевают анализировать пайплайны. Время активной жизни одного пайплайна может быть небольшим, при этом самих пайплайнов может быть очень много, поэтому ИБ-специалистам трудно (а иногда и невозможно) отслеживать и анализировать их совокупную деятельность с точки зрения угроз.
- Технические средства реализации микросервисной архитектуры небезопасны. Стремление к уменьшению Т2М привело к популярности микросервисной архитектуры как идеологии и контейнеров как технических средств ее реализации. Уровень изоляции у контейнеров ниже, чем у виртуальных машин, запущенных на гипервизорах bare-metal, что тоже не добавляет безопасности.
Что можно противопоставить перечисленным выше проблемам?
- Разрабатывать пайплайны так же, как и обычное ПО: осуществлять нумерацию версий программного обеспечения, следить за тем, чтобы каждый коммит был строго авторский, систематически проверять исходный код, в том числе с целью обнаружения и исправления ИБ-ошибок.
- Проводить тестирование.
- Использовать защищенное хранилище артефактов.
- Изолировать среды друг от друга: весь набор авторизационных данных должен действовать строго в одной среде, для другой он должен быть непригодным.
Дмитрий Ключников
руководитель направлений DLP и DevSecOps Центра информационной безопасности компании «Инфосистемы Джет».
Комментарий
ИТ-подразделения часто воспринимают ИБ-службы как камень преткновения на пути к осязаемым результатам для бизнеса и сокращению Time-To-Market. Неудивительно, что сегодня, на волне новой «реальности» с контейнерами и пайплайнами, ИТ-отделы ринулись покорять новые вершины, оставив негодующих безопасников позади в полном непонимании того, что делать со всеми этими «кубернетесами». Ведь сама безопасность часто поддерживает закрепившийся стереотип, когда пытается банально запретить все непонятное.
Между тем риски ИБ никуда не исчезли и безопасность остается неотъемлемым элементом любого процесса разработки. Более того, чем позже она включается в разработку и выпуск приложения, тем серьезнее могут быть потери при реализации угрозы: «долго» станет «еще дольше», «неидеально» превратится в «критично», а «дорого» окажется только началом трат на исправление ошибок.
Каким же должен быть подход к ИБ? Безопасность должна быть интегрирована в процесс разработки на всех ее этапах. Например, инструменты проверки кода и инфраструктуры должны быть встроены в конвейер и являться частью CI/CD, а не работать по отдельности. Служба ИБ должна находиться в постоянном контакте с командой разработки. Например, ИБ-специалисты могут устанавливать «чеки» на разных этапах тестирования кода и возвращать его на доработку с комментариями об ошибках для своевременного исправления уязвимостей. При этом код должен попадать в деплой только при прохождении всех «чеков». Кроме того, ИБ-служба должна брать на себя ответственность и стремиться к максимальному сокращению false positive срабатываний используемых инструментов. Помимо этого, важно определить единую точку входа для управления всеми ИБ-активностями при разработке ПО, выбрать «евангелиста», к которому смогут обращаться за консультациями все участники процесса.