А кто-нибудь знает как и почему это работает?

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

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

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

В долгах как в шелках

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

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

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

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

С этим регулярно сталкиваешься, когда работаешь не с одним сервисом, а с нормальной живой инфраструктурой, которая развивалась несколько лет. Есть несколько сервисов, база, очередь, CI/CD, мониторинг. Потом добавляется новый сервис, новый кластер. Затем внешний API. Потом какая-то интеграция, которую «пока не трогаем». В какой-то момент часть инфраструктуры вообще переезжает в облако. Потом выясняется, что один из сервисов почему-то ходит через старый прокси :/

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

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

Что произойдет?

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

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

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

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

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

Причем это можно представить не только как проблему документации. Она может быть идеальной, а один человек всё равно может оставаться единственным, кто понимает, как устроена какая-нибудь критичная часть системы.

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

Каждая такая вещь сама по себе выглядит мелочью, а вместе они постепенно делают изменения всё более непредсказуемыми.

Поэтому я сейчас хочу проверить одну довольно простую гипотезу, один простой вопрос. Можно ли как-то посчитать этот самый «топологический долг» и посмотреть, связан ли он с проблемами после изменений? Не придумывать очередной индекс ради индекса, а попробовать взять историю реальных изменений и посмотреть, что было с системой непосредственно перед ними, например, было ли много плохо понятных зависимостей? Были ли старые связи, про которые давно никто не вспоминал? Были ли внешние сервисы, без которых всё разваливается? Было ли вообще понятно, кто это должен чинить? А потом сравнить это с тем, чем закончилось изменение.

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

Пока я условно называю её Topology Debt или Топологический долг.

Тонкая грань...

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

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

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

То есть вопрос примерно такой - насколько наши архитектурные решения мешают нам развивать систему дальше?

С топологическим долгом я пытаюсь смотреть немного с другой стороны - насколько наше представление о системе соответствует тому, как она на самом деле работает?

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

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

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

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

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

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

Именно здесь мне как раз интересно мнение людей, которые работают с большими живыми системами.

• Бывали ли у вас ситуации, когда небольшое изменение внезапно задевало совершенно неожиданные вещи?

• Когда выяснялось, что какой-то сервис критичен, хотя никто так не думал?

• Когда документация была в целом нормальной, но реальная инфраструктура давно ушла куда-то в другую сторону?

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

Мне кажется, такие истории у многих найдутся.

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