Привет, Хабр! Меня зовут Денис Фурсенко, в Росбанке мы в команде с Владиславом Смеловским развиваем процессы непроизводственных сред, работу с дефектами на них, разворачиваем дополнительный интеграционный контур банка, а также координируем развитие интеграционных поставок. В этом посте я расскажу, как устроены циклы поставок у нас в банке — в частности, интеграционные поставки. Остановлюсь на том, как мы выявляем причины инцидентов после поставок, поделюсь лайфхаками и расскажу, как менеджеры поставки могут повлиять на качество поставок.
Если вы заметили, мы употребляем термин «поставка» вместо «релиз». В ходе работы мы увидели, что команды используют разную терминологию и, дабы унифицировать подход, мы решили устроить небольшую революцию в банке и внедрили в обиход «поставку», так как считаем, что этот термин наиболее точно отражает процесс доставки изменений.
Главная цель нашей с Владом работы — сделать поставки стабильными, а пользователей непроизводственных сред — довольными. Кроме того, мы координируем вывод интеграционных поставок центральных ИТ-систем банка. Сокращенное название таких интеграционных поставок — ОПИП (общебанковская плановая интеграционная поставка).
Циклы поставки и хорошие практики
Что особенного в интеграционных поставках? График таких поставок планируется на год вперед, они тестируются и выводятся совместно. А мы координируем и прорабатываем риски, связанные с интеграционными задачами, делаем так, чтобы сбоев здесь было как можно меньше.
За время координации и работы с такими поставками мы выработали хорошие практики. Расскажу про основные.
Практика ОПИП заключается в совместном интеграционном тестировании и внедрении нескольких центральных банковских ИТ-систем, тесно связанных между собой. Организатору такой поставки выделяется своя роль — главный менеджер поставки. Он координирует вывод и прорабатывает риски только интеграционных задач в рамках поставок этих систем; при этом у самих систем по отдельности сохраняются свои менеджеры поставки.
Составить график поставок. Это помогает команде выработать ритм. Когда срок следующей поставки известен команде, у нее повышается уровень самоконтроля. И заказчики при этом знают, когда и в каком составе ждать изменения. График позволяет разнести значимые изменения по датам, с учетом дней высоких нагрузок, инфраструктурных изменений и т. п., сократив в итоге потенциальное влияние на бизнес.
Писать читабельные release notes. Мы считаем, что во многом это зависит от культуры внутри команды, от того, насколько четко она прописывает задачи. Иногда стороннему наблюдателю вообще непонятно, что было сделано в рамках задачи, на которую он смотрит.
Заводить задачу типа ReleaseCycle. Release notes ориентированы, скорее, на заказчиков и новичков в команде. ReleaseCycle — это нечто более техническое, для тех, кто уже давно в проекте. Эта задача включает в себя все задачи, что планируются в поставке. Так команда сможет увидеть всё, что должно получиться в итоге, вне зависимости от того, кто как работает — через эпики, истории или как-то иначе.
Фиксировать отклонения. Представим, что мы разработали и протестировали поставку, написали план работ и наметили время выхода в продакшен. Но вдруг что-то пошло не так. Например, не запустился какой-то скрипт, из-за чего поставку пришлось отложить. Вы разобрались в ситуации, быстро что-то сделали и вывели поставку в продакшен. Но затем стоит провести ретроспективу на уровне команды, чтобы избежать такой ситуации в будущем.
Определить роль по сопровождению непроизводственных сред. Такая роль в большой команде позволит ускорить путь изменений через все необходимые этапы. Это может быть совмещенная роль с администратором или менеджером поставки, но нужно четко обозначить, кто ее выполняет. Сопровождающий определяет, через какие этапы должна пройти задача; эта практика отлично показывает себя в рамках процесса оценки команд.
Создать стратегию поставки и поделиться ей с командой. Еще один важный пункт, который мы популяризируем. Неважно, как выглядит стратегия — главное, чтобы она описывала, какие среды используются в команде, какие критерии перехода и этапы приемки между этими средами установлены. Самый простой пример — это definition of ready и definition of done со ссылками, эндпоинтами и прочей важной информацией. Команда знает правила игры, что делает прозрачными все процессы и ускоряет онбординг.
Тестировать поставку в продакшен. Здесь мы часто встречаемся с сопротивлением. Коллеги, например, спрашивают, как тестировать платежи без тестовых данных и аккаунтов. Да, это реально не во всех случаях, но нужно искать такие возможности. Вы же не будете платить за ремонт в своей квартире, просто посмотрев на «демоквартиру» строителей? :) Логика здесь такая же: доводить изменения до прода и тестировать их там по мере возможности, чтобы реально показать ценность заказчику.
Автоматизировать развертывание. Есть разные типы развертывания — канареечное, blue-green, Ramp Up и другие. Мы за то, чтобы минимизировать простой сервисов. Например, при обновлении одной из центральных ИТ-систем простоя сервисов нет и происходит понодный рестарт. Системы, понятное дело, разные, но об автоматизации забывать не стоит.
Циклы поставки: интеграционные задачи
ОПИП, которую мы обозначили выше, включает набор задач, доработка которых затрагивает несколько систем одновременно. Но эти задачи необязательно должны ставиться в один и тот же момент. Есть заблуждение, что если задача обозначена как интеграционная, то связанная с ней задача должна ставиться одновременно с ней. Это не всегда так.
Интеграционная задача — это просто задача, которую нужно реализовать в рамках разных систем. Приведу пример: весной мы делали регуляторную доработку, которая затрагивала несколько критичных ИТ-систем банка. Это комплексная задача, включавшая 40–50 подзадач, в разной степени связанных друг с другом. В рамках подготовки ОПИП мы отслеживаем такие задачи, собираем по ним информацию, чтобы понять, на что они могут повлиять. Во-первых, смотрим, могут ли они повлиять на выпуск поставки. Во-вторых, могут ли повлиять на текущий функционал — если, к примеру, одна часть задачи уже выводится, а другая докатится до прода позже. Здесь главное — ничего не сломать в текущем функционале. В-третьих, нужно понять, когда до прода будет доставлен весь функционал задачи, донесена вся ценность для бизнеса.
Менеджерам поставки мы рекомендуем отслеживать такие задачи в составе поставки и их потенциальное воздействие на смежников, просчитывать риски. Как-то мы делали небольшую поставку для ИТ-системы, работающей с автокредитами, но не учли, что в серой зоне у нас была интеграция с CRM. Поймали инцидент — небольшой, но показательный.
Вместе с командами мы прорабатываем риски, план работ, оповещаем все заинтересованные стороны.
Когда работы проведены, команды дежурят некоторое время на случай непредвиденных ошибок. Крайне редко, но случается, что какой-то нюанс не был предусмотрен или произошел набор действий, который вызвал ошибку, не связанную при этом с последней поставкой.
Причины инцидентов: когда код начинает вести себя хуже твоего дяди на свадьбе
В банке каждый день случаются разные инциденты, и в работе мы фокусируемся на тех, что были вызваны именно поставкой, поскольку в рамках своей работы мы можем на них повлиять. Чтобы понять, действительно ли инцидент произошел из-за поставки, мы категоризировали причины инцидентов и детально анализируем все значимые инциденты. По итогам анализа, выявлены топ-5 групп причин, по которым случаются инциденты:
После «Сбоя ПО» и «Ошибки пользователя» идет «Незавершенный анализ». Эти инциденты потенциально могут повториться, поскольку пока они не проанализированы и не приняты меры по их предотвращению.
Треть значимых инцидентов происходит из-за поставок. Приведу здесь распространенные причины инцидентов, по которым уже завершили анализ:
Ошибка разработки. «Совпало название поля таблицы и параметра запроса. Это существовало 6 лет….». «…Ошибка в коде компонента, с 20-го года компонент не изменялся, связано, скорее всего, с тем, что был простой двух ИТ-систем».
Отсутствие требований к системе. «…Достигнуто максимальное значение в сиквенсе…». «ПТАФ не смог переварить весь объем данных по оперативной памяти. Ожидали трафик 5x – 7x рпс, а пришло в пять раз больше…».
Ошибка тестирования. «При тестировании не хватило тест-кейсов, не отловили, так как на тестовой среде не такое разнообразие платежей…». «Есть сотрудники….у которых было указано ИНН=000000000000…. на интеграционном контуре не было такого тест-кейса».
Ошибка тестового ландшафта. «В миноре изменили настройку, которой не было в справочнике прода. Ее тестировали, в справочнике на тестовых средах настройка была…».
Как понять причину инцидента
Самый любимый прием здесь — «почему?». Иногда на ретроспективе по инцидентам можно услышать от коллег: «коренная причина инцидента в том, что потекла память, из-за этого и упал сервис». На самом деле это не коренная причина; надо понять, из-за чего конкретно потекла память. Или пример с «человеческим фактором»:
– Почему не заметили ошибку? Не было тест-кейсов?
– Да.
– А если бы были, можно ли было отловить ошибку?
– Наверно.
– Значит, причина не в тестах, а в коде?
– Ну да.
– А что в коде было не так?
– Не учли формат данных.
– Почему не учли?
– Разработчик не учел, задача была неправильно поставлена.
Клубок можно разматывать долго, но это необходимо, чтобы добраться до реальной причины. Поэтому мы задаем эти уточняющие вопросы. В процессе выяснения и вскрывается то, о чем мы говорили выше.
Как повлиять на поставку: чек-листы
Хороший инструмент — чек-листы для проведения работ, где мы пошагово описываем, что нужно сделать, кого предупредить, что предусмотреть в разных ситуациях; в каком порядке и в какой период делать задачи. Но даже если обложиться чек-листами, всё равно что-нибудь может пойти не так.
Приведу пример из жизни. На одной из прошлых работ я был менеджером поставки. У нас был довольно жесткий контракт на поддержку, по которому критичный инцидент нужно решить в течение часа — иначе штраф компании на много миллионов рублей. Однажды в три часа дня пришел такой инцидент: сломалась реплика баз данных в продакшене. Понятно, что за час мы реплику починить не успеем, потому что не знаем причину проблемы. DevOps-инженер предлагает накатить базу с родительской продакшен-системы на нашу дочернюю. Базу накатывать 40 минут. Что может пойти не так?
Когда база накатывается, система падает вообще: 40 минут она просто не работает. Изменения копятся. Приходит второй инцидент: система не работает. Всё в итоге обошлось, но что еще стоило сделать в тот момент? Наверно, предупредить заказчика: мы сейчас будем перенакатывать базу, и система на это время ляжет, нужно ли вам это? Или вы понизите приоритет до среднего, и мы перенакатим базу в нерабочее время? Да, даже если обложиться чек-листами, всё может пойти не по плану.
Чек-листы могут иметь разную наполненность, разный уровень детализации и доступности в нужный момент, когда подскакивает адреналин, а с ним и число сообщений в чатах, звонков, созвонов разработчиков и владельцев систем… а еще и курьер посылку привез :)
Помимо чек-листов, мы стараемся популяризировать отчет о качестве поставок. Каждый ОПИП у нас сопровождается отчетом, где собраны важные, на наш взгляд, показатели поставки. Это помогает подсветить, что со временем меняется в работе. Помимо основных, здесь мы также выделяем информационные показатели, которые не влияют на оценку, но косвенно показывают, к каким изменениям привела поставка. Информационные показатели для поставки одной из ключевых систем, например, выглядят так:
количество комплексных (интеграционных) задач / всего задач;
количество дефектов — то, что нашли во время тестирования/санити на проде;
количество дефектов на непроизводственных средах;
соотношение количества дефектов, выявленных на этапах тестирования, и багов в производственной среде;
количество багов в проде за первую неделю после поставки (нужно учитывать, что баги могут относиться к предыдущим поставкам);
количество багов в проде за всю поставку (опять же, нужно учитывать, что баги могут относиться к предыдущим поставкам).
Чему учат инциденты поставок
Случился инцидент. Команда провела разбор полетов, прошла ретро, пост мортем, выяснила, что, к примеру, разработчик что-то не так написал в коде. Изредка еще можно услышать: «Мы сделали человеку внушение, он так больше не будет». И на этом всё заканчивается.
Но цель разбора, на наш взгляд, не наказать человека, не внушить ему чувство вины, а вынести урок и начать действовать по-другому, зафиксировать этот урок как «лучшую практику», чтобы вся команда его видела и могла найти при необходимости. Человек, совершивший ошибку, может уйти из команды, но экспертность останется, если её зафиксировать.
Что мы делаем после инцидентов? Если видим вероятность, что высокий или критичный инцидент произошел из-за поставки, мы приходим с дополнительными вопросами к команде. Потом предлагаем технические и организационные мероприятия, чтобы предотвратить инцидент — например, докрутить тест-кейсы или подумать про автоматизацию.
Друзья, мы рассказали, как у нас устроен процесс вывода поставок и приоткрыли завесу работы с инцидентами. У команд, с которыми мы работаем, и у нас самих есть планы развития в этом направлении — здесь и автоматизация, и развитие практик производства, в том числе всеми любимые микросервисы, докеры и кубернетесы. В одних командах это всё есть, другим нужно что-то улучшить, и мы работаем вместе с ними, чтобы сделать процесс поставки легким и стабильным для бизнеса.
Поделитесь в комментариях: как вы управляли или управляете выпуском интеграционных поставок?
