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

было - стало

Вопросов нет, когда все знания могут сконцентрироваться в одной голове - все ОК. У меня не так. Довольно много людей колдуют над трансформацией.

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

А зачем тут "было-стало", тут важнее "как меняться"?
Т.е. если было 100K, через год станет 100mln, то два состояния - ни о чем не скажут, нужно описание процессов перехода, а это обычно самое сложное и интересное в таких проектах...

А зачем тут "было-стало", тут важнее "как меняться"?
Т.е. если было 100K, через год станет 100mln, то два состояния - ни о чем не скажут, нужно описание процессов перехода, а это обычно самое сложное и интересное в таких проектах

Я в данном случае говорю про топологию деплоя

а не про цифры

Даже если говорить только про деплой, то k8s - это малая часть задачи.
И, скорее всего, он даже не будет нужен

была картинка А стала картинка Б , по трейсу спустились в артефакты, собрали комиты и тд

Я же не про конкретные ваши решения. А все го лишь про полезность техники AB анализа

По трейсу чего? Картинки? Или привязанного к двум картинкам процесса перехода? И какие артефакты у процесса изменения?
И какие коммиты, там пара сотен релизов пройдет, коммитов вообще сотни тысяч

и инструмента

в спарксе - это объекты трассируемые

Тогда не понял, где тут полезность техники AB анализа (вообще, кстати, под AB-анализом подразумевают совсем другое)

Какие объекты? Картинки? Или изменение таковых?

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

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

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

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