Как избежать неработоспособности API при изменениях? 8 пунктов, о которых стоит подумать

Представьте что вы работаете в средней или крупной организации. По системам бегают заявки, документы, всё прошито бизнес-процессами. Системы разрабатывает ~50 команд. Они живут в своих темпах и друг с другом практически не общаются. Бывает такое, что сделали изменения в одном месте (Например в 1С добавили обязательное поле «КПП получателя» в документ «СЧЕТ»), не предупредили, а в других местах все развалилось. Как сделать так, чтобы такого не было?

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

Ответы в двух категориях

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

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

Уточняющие вопросы

Коллеги имели возможность задать вопросы и вот что они спросили:

А кто отвечает за вывод доработок в пром и тестирование? Это централизовано происходит или каждая команда проводит это сама? Кто является заказчиком доработок? Кто отвечает за весь процесс, где участвуют все эти системы?

Каждая команда сама. В каждой команде в основном свои заказчики. За весь процесс отвечает владелец процесса.

Есть вопрос а в чём корневая причина проблемы? Возможные ответы:
а) При постановке задачи забыли что нужно при изменении контракта доработать смежный сервис?
б) У второй команды задача потерялась?
в) Команды отработали корректно но задеплоены несоответствующие версии сервисов?

Не то что забыли, а даже и не знали. Вариант А.

А что значит всё развалилось?

Интеграция с этим 1с начала падать у части команд и из-за этого платежки не проходили.

Проверяем на последствия

Интересно, что в канале у меня совсем нет бизнесменов :), всего один человек задал уточняющие вопросы, связанные с влиянием таких сбоев на бизнес.

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

Частотный

Генри Нив в своей книге «Организация как система» развивает идеи Шухарта и говорит:

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

Ребята в Motorolla, когда придумывали 6 сигм, договорились что чинить будут только те ситуации, которые выводят процесс из 6 сигм. Это очень серьезный уровень, посмотрите в таблицу:

DPMO — количество косяков на миллион возможностей.  Если бы в организации из кейса было принято качество по 6 сигма, то на 1 000 000 релизов допускалось 3 ошибки. Первые три косяка за год игнорировали, а на 4 надо было бы заниматься.

Я не видел применения этой методологии в процессах разработки. Думаю, она больше применима к огромному потоку однотипных процессов, где результатом труда являются типовые единицы, а не каждый раз уникальный код. Для кейса я бы прикинул так «Если у нас 1000 успешных релизов в год, а на 1 из них приходится такой сбой», то можно и забить.

Денежный

Нужно прикинуть, сколько денег мы потеряли, можем потерять в будущем и сколько +- стоит починить эту проблему.

Допустим ошибка привела к простою на 2 дня, мы не смогли оплатить 2000 заявок и  20 проектов, где нужны были эти оплаты, отодвинулись на 2 недели вперёд.  1 неделя каждого проекта стоит 1 000 000 рублей.  Сейчас мы потеряли 40 000 000 рублей.

Поговорили с айтишниками и они сказали, что такое в прошлом году случалось раза 3 на 1000 релизов, поэтому будем  считать вероятность повторения — 0.3%. 40 000 000 * 0.3% = 120 000 рублей. Это сумму мы платим в год за не устранение этого риска, меньше месячной зарплаты 1с-ника.

Настоящие рисковики засмеют с таким подходом, но для данного кейса подойдет 🙂 Если вас интересует анализ рисков и принятие решений, то почитайте книжку ниже.

Клиентский

Можно оценить, насколько сильно данные дефекты оказали влияние на клиентов — клиенты жаловались и нагружали тех. поддержку, отказывались от наших услуг,  писали гневные комментарии в соц.сетях, есть ли у данного дефекта долгосрочные последствия для бренда. Важно еще учесть количество клиентов, которые попали под сбой. Одно дело сбой на всю клиентскую базу, другое — на 0.5%.

 

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

Конкретные предложения

Я разделил все предлагаемые изменения на несколько категорий по смыслу изменений. Они немного пересекаются, в реальной жизни вам потребуются изменения почти из каждой категории. А еще в реальной жизни возможные изменения будут зависеть от бюджета, который мы выше считали — если падает раз в год на 2 дня, то никаких НСИ или интеграционных шин не будет.

1. Централизация и общие требования

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

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

Что конкретно предложили коллеги:

• • Внедрить централизованное управление НСИ
  • Организовать управление программой изменений в ПО
  • Внедрить SLA для API
  • Использовать интеграционную шину
  • Решать на этапе проектирования.
  • Ввести руководителя сквозной функции, руководителя проекта. Он будет координировать и согласовывать работу проектных команд и всех изменений и графики релизов.
  • Назначить ответственного менеджера, который будет «шиной», и к нему обращаться по всем вопросам и проблемам. Он организует процесс изменений во всех командах, и проработать санкции за косяки.
  • За всеми документами в 1с закрепить владельцев. Если документ задействует несколько отделов, то со всеми надо согласовать изменения. Только после согласования необходимости аналитик их прорабатывает.
  • Сделать основные принципы построения сервисов и их взаимодействия между собой.  «Либеральны что принимаете», «Консервативны что отправляете», использовать «толерантный читатель».
  • Жизненный цикл API

• Сделать бизнес-процесс о согласовании/изменении заинтересованных команд
• Сделать матрицу пересечений систем-тим лидов и сущностей и просить у них согласование при изменении

2. CI/CD

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

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

Вот что написали:

• На пайплайнах не давать задеплоить 1с, если все не собралось с новой версией.
• При сборке проверять, что твой приклад не использует deprecated API.

Интересно, что никто не упомянул канареечное или блю-грин разворачивание, а следовало бы 🙂

3. Синхронизация

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

• Синхронизировать релизы зависящих друг от друга модулей.
• Выделение экспертов уровня системы и проверять через них, что  ничего не пропустили.

4. Тестирование

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

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

5. Документирование

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

Я не видел чтобы это работало хотя бы раз на проектах, где больше 2-3 команд, потому что это ОЧЕНЬ трудоёмко.

Вот что написали коллеги:

• Проработка документации педантичная и фиксация всех систем, контрактов и пользователей.
• Сделать реестр всех нси связь всех потребителей и их статусы.
• При изменении контракта надо внести изменения во все зависимые компоненты.

6. Перестройка орг.структуры

Тут только одно предложение и оно очень интересное — организовать фича-тимы. Единственное предложение, которое пытается разобраться с причиной «А  почему КПП то вдруг стал обязательный?». Ожидается, что если бы мы собрали команду «КПП заполнителей» из участников всех команд и дали задание обеспечить честное заполнение КПП по всей организации, они бы не пропустили соседние системы и всё сделали четко.

7. Техника

А здесь просто перечень технических решений, которые можно было бы применить:

• Использовать поход contract-first.
• Версионность API.
• Использование protobuff.
• Заставить 1С систему саму как-то найти КПП, а если не получается — кидать на ручной разбор и там уже ручками заполнять. (Заботливый подход о потребителе, мне нравится!)

8. Культурные изменения

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

• Знали своих потребителей.
• Заботились о них — писали им письма, объясняли почему будут происходить изменения и как именно их выполнить.
• Адекватно выполняли требования на уровне организации( версионирование API, API lifecycle и т.д.)

В культурные изменения можно запихнуть что хочешь, самым важным считаю идея о том, что твоим продуктом (API) кто-то пользуется и ему будет грустно, если он перестанет работать. Заботься о коллеге!

 

А как там у них?

Netflix

Угорели по культуре — основная идея  «Свобода и ответственность» — там инженеры могут делать все что угодно с любым инструментарием. И , конечно, много тестирования и CI/CD. Люди, которые занимаются централизацией, у них тоже есть, но не всего подряд, а каких-то отдельных направлений. Вот, например, вакансия Release Manager.

Подробности в статье.

Google

В гугле придумали небольшой фреймфорк для Change Managment и через него прогоняются большие изменения:

Больше в статье. С техникой у них тоже всё в порядке, вот тоже самое, но для разработчиков и девопсов.

Вывод

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