берешь и читаешь доки

По моему опыту - нужно выделить компоненты системы (здесь у нас Oracle, здесь сервер приложений, тут монга, а события приходят по RabitMQ), определить их связи, определить внешние интерфейсы - взаимодействие с другими ситемами (к примеру есть REST сервис, который возвращает фазу Луны, а данные с котировками итальянской лиры забираем daily фидом с FTP сервера в Сорренто). Но это не методика, а скорее здравый смысл.

Еще хорошо, если есть документы типа "Runbook" в котором описано как система должна развертываться в production

Я бы начинала с определения информации, которая поступает в систему, и ее источников. А также информации, которую система передает вовне. Обычно это следует из назначения системы.

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

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

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

Цель то какая?
Задокументировать или проблемы порешать?
Отчёт делать на выходе надо? Если да, то для кого?

Леонид, а система внешних пользователей обслуживает, или внутри для себя писали?
Есть нюансы.

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

Документировать "для чего и кого"?

Это первый и самый главный вопрос

Леонид, коллеги намекают, что задокументировать -- это не цель.

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

Для исправления ошибок и каких-то небольших доработок, я так понимаю?

Цель - рассказать заказчику о том, что у него за система, какие данные обрабатывает. Кому данные предоставляет и как именно их хранит. Хотелось бы взять какую-то готовую методику аудита (ну типа PCI DSS) и от нее оттолкнутся.

А что такое паспорт системы?

Леонид, один вопрос назад -- система внутренняя? Enterprise?

Да, enterprise. Т.е. ее пользователи - сотрудники заказчика.

Обычно эффективно копать с двух сторон :
-- кто ведет эксплуатацию (h&i, dba, application support), и run book, user guide,...
-- кто аппрувил (паспорт у иб, кто-то под 152фз смотрел, риски, принятие в поддержку,...)

Это все при условии, что живые разработчики недоступны.
То есть корпоративная археология.

Если копать со стороны данных, то (бумажные) следы имеет смысл искать :
-- инфраструктура / бд
--  иб / риски
-- всякие планы bcp / drp, если есть