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

• Само решение: сможем ли мы успешно конкурировать с зарекомендовавшими себя аналогами, не пострадает ли доступность и надёжность систем и автоматизация наших процессов?

• Издержки: сама миграция, адаптация к ней, сопровождение системы.

• Пользователи: полтысячи человек, привыкших к старому техпроцессу. Как они отреагируют, если их привычная система откажет?

Госрегулятор выставил жёсткие сроки и условия. Так что мы оказались в ситуации «хочешь не хочешь, а надо». Преодолевая страхи, мы не только сплотили команду, но и решили две вопиющие проблемы в организации рабочих процессов. И вот как это было.

Технология — не главное

В основе перехода были не технологии, а приоритеты:

1. Культура организации. Готовы ли мы адаптироваться с психологической точки зрения?

2. Анализ процессов. Нельзя ли их улучшить, несмотря на то, что привыкли к ним?

3. Технологическое решение. Как мы будем внедрять новую систему на практике?

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

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

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

Сбой — это подарок

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

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

Другая похожая проблема: мы недостаточно следили за релизами после того, как они уже вышли. Ряд ошибок, возникающих на боевых серверах, оказались системными. Они были вызваны скрытыми особенностями поведения релизов, которые мы просто не ловили. Потому что в целом, на первый взгляд, наш конечный продукт выглядел нормально. И казалось, что там буквально не к чему присматриваться. Этакий порочный круг: чтобы уловить системность ошибок, надо внимательнее наблюдать за поведением релизов на боевых серверах. Но наблюдать вроде бы и незачем — ошибки системными не выглядят.

Что мы сделали

1. Внедрили скоринговую модель и модель оценки рисков релиза. Это значит, что на каждом этапе в цикле разработки мы фиксируем определённый набор рисков. Если они реализуются, мы можем подключить инструменты или персонал на самых ранних этапах — как только риски становятся видимыми, а не в последний день перед выпуском. Тогда уже можно принимать решения по компенсационным мерам — перенести релиз или объявить планово-внеплановые рабочие субботу-воскресенье, если дело в регуляторе или в срочном релизе. Потому что раньше часто бывало так: мелкие сдвиги накапливаются, разработка идёт месяц, а отделу тестирования остаётся пара дней, чтобы со всем этим разобраться. Понятно, что в таких условиях стресс зашкаливает, страдает качество релиза и доступность системы для конечных пользователей.

2. Отстроили ворота качества — по возможности автоматизированные наборы проверок перед внедрением, покрытие тестами, проверки на уязвимости.

3. Завели дайджест по релизам, ту самую фокусировку внимания на том, как релиз ведёт себя после установки. Здесь надо отдельно повторить часть кадра выше:

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

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

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

Вы, наверное, заметили самолёт на одной из иллюстраций выше. Герои «Начала» собирались купить самолёт и бортпроводницу, но в итоге купили авиакомпанию, потому что… так проще. Вот и мы, решая частную задачу, изменили процессы в корне.

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

Да, чувствовали мы себя именно так, потому что переход был практически беспрецедентным для нашего банка. Во-первых, ПСБ — это крупный государственный банк и поэтому для нас было важно выполнить требования коллег из департамента информационной безопасности. Благодаря совместным усилиям и эффективным коммуникациям мы с коллегами из информационной безопасности смогли реализовать поставленные задачи и требования информационной безопасности были соблюдены в полном объеме.

Во-вторых, мы внедрили новую технологию в отношении систем QA — ушли от монолитной архитектуры к сервисной и развернули решение на докерах и даже немного перевыполнили план. Мы идем по пути централизованного импортозамещения и не за горами состоится переход на отечественный базовый докер-образ Astra Linux.   
 
Здесь надо отдельно поблагодарить нашу проектную команду за желание договориться с кем-то на берегу, за эффективные коммуникации. Это продуктивно — а ведь могли бы просто прийти к коллегам и сказать что-то в духе: «Теперь будет так, с этим ничего не поделать, у нас требования регулятора, это гриф ДСП». В любом случае каждое определение отстаивает свои интересы и свой протокол выпуска релизов, но мы оптимизировали процесс миграции. Разговаривать с людьми пришлось очень активно, подбирая для каждого проекта свои даты миграции, начиная с наиболее лояльных пользователей. Мы даже обещали откатить миграцию для каждого отдельного проекта, но в итоге, к счастью, ни одного отката не было.

Сделать это мы смогли во многом благодаря тому, что вендор подстроился под нас и понял наши требования. Мы смогли сохранить и перенести в новую систему и все артефакты тестирования сотни проектов, и структуру их ведения, причём сделали это прозрачно для конечного пользователя. Отдельно отметим, что миграция прошла не за квартал, а всего за месяц.

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

Итоги

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

Именно поэтому мы в статье оставили отсылки на «Начало» — практически это история трёх последовательных внедрений: в головы людей, в устройство организационных процессов и, наконец, в технологии.

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

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

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

Статья написана в соавторстве Романом Колташовым и Евгением Щеголяевым. Здесь мы выступаем как специалисты по обеспечению качества — руководитель направления и управляющий эксперт соответственно.