Однажды я наблюдал, как интернет-магазин небольшой компании перестал принимать заказы из-за того, что на другом конце планеты сервис, который определял страну посетителя по адресу, обновил формат ответа. Магазин не продавал за границу. Страна посетителя ему, по большому счёту, была не нужна. Но когда-то давно разработчик подключил эту проверку «на всякий случай», и теперь от неё зависела страница оформления заказа. Никто из сотрудников компании даже не знал о существовании этого сервиса. Узнали, когда продажи остановились. Я часто вспоминаю эту историю, когда говорю о сложности современного мира.
Эффект бабочки перестал быть метафорой
Учёный, который придумал образ бабочки, взмах крыльев которой вызывает ураган на другом континенте, говорил о погоде. Но сегодня этот образ описывает почти любую технологическую систему. Ваша учётная программа зависит от библиотек, которые написали тысячи незнакомых людей. Ваш сайт зависит от хостинга, от службы доменных имён, от платёжного шлюза, от сервиса рассылок, от браузеров, которые обновляются без Вашего согласия. Каждое из этих звеньев, в свою очередь, зависит от десятков других.
И это не только про технику. Бизнес устроен так же. Поставщик задержал одну деталь, и встал целый цех. Изменились правила на маркетплейсе, и упали продажи в трёх регионах. Ушёл один ключевой сотрудник, и перестали работать процессы, о которых все думали, что они работают сами. Мир состоит из составляющих, связанных друг с другом гораздо плотнее, чем это видно на схемах.
Почему сложность нельзя отменить
Первая реакция многих руководителей на такие истории: давайте всё упростим, уберём лишние связи, будем всё делать сами. Это понятное желание, но наивное. Отказаться от внешних связей значит построить крепость, которая всё производит сама, и проиграть тем, кто пользуется готовыми сервисами и тратит силы на главное. Сложность это не ошибка, которую можно исправить. Это цена, которую мы платим за возможности. Чем больше связей у системы, тем больше она умеет, и тем больше у неё точек, где что-то может пойти не так.
Значит, вопрос не в том, как избавиться от сложности, а в том, как жить с ней так, чтобы локальный сбой не превращался в катастрофу. И здесь у инженеров есть много чему поучиться у природы и у истории.
Уроки кораблестроителей
Корабли давно строят с водонепроницаемыми переборками. Корпус разделён на отсеки, и если пробоина затопила один, остальные держат судно на плаву. Это решение появилось не из любви к сложности, а из горького опыта: корабль без переборок тонет от одной дыры. Ровно этот принцип лежит в основе устойчивых программных систем.
Хорошая система не та, в которой ничего не ломается. Хорошая система та, в которой поломка одной части не топит все остальные.
На практике это означает несколько простых правил, которые мы применяем в проектах:
- изоляция модулей: каталог, заказы, склад, оплата устроены так, чтобы сбой в одном не останавливал остальные; если упал модуль рекомендаций, покупатель всё равно может оформить заказ;
- защита от внешних сбоев: если сторонний сервис не отвечает, система не ждёт его бесконечно, а через короткое время переходит к запасному сценарию или показывает понятное сообщение;
- необязательное остаётся необязательным: проверка, без которой можно обойтись, не должна блокировать критичный процесс, как в истории с определением страны;
- наблюдаемость: система сама сообщает, где у неё болит, прежде чем это заметят клиенты.
Видеть связи, прежде чем они порвутся
Самое опасное в сложных системах это невидимые связи. Те, о которых никто не помнит, которые появились когда-то по случайной причине и тихо живут годами. Поэтому одна из важнейших частей работы архитектора это не столько придумывать новое, сколько делать видимым существующее. Нарисовать карту: что от чего зависит, какие внешние сервисы используются, где проходят данные, какой процесс сломается, если исчезнет вот это звено.
Я регулярно предлагаю клиентам простое упражнение: выписать все внешние сервисы и всех людей, без которых их бизнес остановится хотя бы на день. Почти всегда список получается длиннее, чем ожидалось, и почти всегда в нём есть пара пунктов, о которых руководитель узнал впервые. Это неприятно, но гораздо приятнее, чем узнать о них в момент сбоя.
Что делать с этим знанием
Мир не станет проще. Он будет становиться только сложнее и связаннее, и, честно говоря, мне это нравится: в этом много красоты и возможностей. Но управлять компанией в таком мире можно только одним способом: принимать сложность как данность и строить системы, которые к ней готовы. Делить на отсеки. Знать свои зависимости. Иметь запасные сценарии для самого важного. И не подключать «на всякий случай» то, без чего можно обойтись.
В Systems мы начинаем любую архитектуру с карты связей, а модульность закладываем в фундамент, а не прикручиваем потом. Fractal в этом помогает, потому что система описывается как набор моделей с явными связями, и невидимым зависимостям в ней просто негде спрятаться. Бабочки будут махать крыльями всегда. Наша задача сделать так, чтобы у Вас от этого не начинался ураган.
