Короткий ответ
#Что на самом деле потеряно
Быть здесь точным стоит того: из четырёх вещей две возвращаются, а две нет — и ближайший месяц строится вокруг этого различия.
| Что | Пример | Восстановимо? |
|---|---|---|
| Устройство | Из чего состоит система, что с чем разговаривает, что от чего зависит | Да — это свойство кода |
| Поведение | Что происходит, когда платёж не прошёл; что делает ночная задача | В основном — читается из кода, но с усилием |
| Рассуждения | Почему сделано именно так, что пробовали и отбросили, какое было ограничение | Нет. Только от него и только пока он готов отвечать |
| Рабочие привычки | Что он смотрит после выкладки, какой алерт всегда шум, как чинится то, что ломается регулярно | Нет — и именно это будет больно в три часа ночи |
Обычно весь срок отработки уходит на первые две строки: просят документацию, просят провести по системе. Две последние теряются целиком, потому что о них никто не догадывается спросить.
Переверните это. Первые две кто-то другой выведет из системы позже и без него. Оставшиеся у него часы — единственный в мире источник для двух последних.
#Первая неделя, по порядку
-
Опишите доступы прежде, чем что-то в них менять
Перечислите каждую учётную запись, без которой система не живёт: хостинг репозитория, облако, регистратор домена, DNS, база, CI, сбор ошибок, платёжный провайдер, почта, хранилище, мониторинг. Напротив каждой напишите, на чьё имя она оформлена.
На чьё имя, а не у кого есть доступ. Это разные вопросы, и опасен из них первый.
-
Убедитесь, что можете выкатиться без него
Не «у нас есть все доступы», а действительно выложите что-нибудь безобидное. Удивительно часто на сороковой день выясняется, что один шаг релиза существовал только на одном ноутбуке.
-
Убедитесь, что можете восстановиться из резервной копии
Тоже по-настоящему, в отдельное окружение. Копия, из которой никто не разворачивался, — это вера, а не копия.
-
Получите независимую техническую картину
Пусть тот, у кого код ещё есть, прогонит анализ. Нужна не сводка, а карта со ссылками на источники и явным перечнем того, что установить не удалось.
Это и делает 1ADK. Кодовый агент сам по себе тоже даст неплохую версию; чего он не даст — так это отделения прочитанного от додуманного и себя же через три месяца с ответом на руках.
-
Превратите пробелы в вопросы к нему
Открытые вопросы из анализа — это кратчайший возможный список того, на что может ответить только он. Отправьте его списком. Не «напишите, пожалуйста, документацию», а двенадцать конкретных вопросов.
На конкретный вопрос отвечают даже на неделе увольнения. На открытую просьбу — нет.
#Доступы, в правильной последовательности
Первый порыв — отозвать всё немедленно. Именно этот порыв запирает компании снаружи их собственных систем.
Провал здесь конкретный и частый: учётная запись оформлена на самого разработчика, а не на компанию. Отзыв его доступа ничего не передаёт — он убирает единственный вход. Обычные кандидаты: облачные организации, регистрация домена, аккаунты магазинов приложений и вход в кабинет платёжного провайдера.
-
Сначала выясните, чьё это
По каждой записи: владелец — корпоративный адрес, которым распоряжаетесь вы, или личный? Всё второе — это передача с процедурой, а не снятие прав.
-
Передайте то, что передаётся
Домен, облачная организация, регистратор, магазины приложений, платёжный провайдер. У некоторых процедура занимает несколько дней, и одна из них вас удивит.
-
Заведите собственный вход
Административные записи компании везде, с восстановлением на адрес, которым распоряжается компания. Проверьте каждую, прежде чем переходить к следующему шагу.
-
И только теперь отзывайте
Личные учётные записи, личные токены, ключи SSH и всё, что лежит на его машине. Смените все секреты, которые он мог видеть: считать их раскрытыми — это гигиена, а не обвинение.
То, на чём попадаются
Адрес и телефон восстановления на критичных учётных записях. Если в облачном аккаунте восстановление уходит на личную почту, всё сделанное выше отменяется тем, кто этой почтой владеет. Проверьте это на каждой записи, потерять которую вы не можете себе позволить.
#О чём спросить, пока он на связи
Исходите из того, что у вас есть один час его настоящего внимания, а не сорок. Потратьте его на то, чего нет больше нигде.
Не просите документацию. Её напишут под давлением и в спешке, и она опишет то, что человек помнит, а не то, что есть. Задавайте вопросы — и задавайте их письменно, чтобы ответы остались.
Рассуждения — то, что действительно не восстановить
- Какую часть системы вы бы побоялись отдать на изменение кому-то другому и почему? Один этот вопрос надёжно вытаскивает то, что иначе нашли бы через полгода.
- Что вы пробовали и что не сработало, почему в итоге пошли этим путём?
- Что здесь сделано из-за ограничения, которого больше нет?
- Что вы сделали бы иначе, будь у вас ещё месяц?
Рабочие привычки — знание на три часа ночи
- Что вы смотрите после выкладки?
- Какие оповещения вы игнорируете, а какие действительно что-то значат?
- Что ломается регулярно и что вы с этим делаете?
- Что приходится делать руками и когда? Ручные шаги раз в месяц и раз в квартал обнаруживаются на третьем месяце.
Внешнее и человеческое
- От каких внешних сервисов это зависит и на чьё имя оформлен каждый?
- Кто снаружи компании заметит, если это остановится, — партнёры, интеграторы, клиент с ключом к API?
- Работает ли что-нибудь, чего нет в этом репозитории?
- У кого ещё когда-либо был доступ ко всему этому?
Что запросить до ухода разработчика — это же самое, но подробнее и в виде передачи дел.
#Что можно установить без него
Больше, чем ожидает большинство владельцев, и ценой одной инструкции, а не консалтингового проекта.
Любой, у кого код ещё есть, — оставшийся разработчик, подрядчик, агентство, которое вы рассматриваете, или вы сами, если умеете выгрузить репозиторий, — может собрать структурированную техническую картину системы без всякой помощи ушедшего. В неё входят:
- компоненты, из которых состоит система, и внятное назначение каждого;
- что от чего зависит и в какую сторону;
- внешние сервисы, без которых она не работает;
- интерфейсы, которые она наружу отдаёт, и примерный смысл каждой операции;
- данные, которые она хранит, и куда эти данные движутся;
- и — здесь это важнее всего — перечень того, что установить не удалось, и почему.
Оптимизировать стоит именно последний список. Он превращает безграничный страх («мы не понимаем собственную систему») в ограниченную задачу («есть одиннадцать конкретных вопросов, четыре из них важные, вот кто может знать ответ»).
#Где 1ADK помогает, а где нет
Где помогает
- Собрать картину, никому не выдавая доступ к репозиторию.
- Отделить прочитанное от додуманного, чтобы новая команда знала, каким предложениям верить.
- Превратить пробелы в конкретный список вопросов по важности.
- Сохранить результат, чтобы следующий пришедший не начинал заново.
- Показать, что изменилось с прошлого раза, включая утверждения, которые больше не подтверждаются.
Где не помогает
- Восстановить рассуждения. Почему сделано именно так — этого в коде нет.
- Восстановить рабочие привычки. Что он смотрел после выкладки — не свойство софта.
- Передать учётные записи. Это ваша работа, и порядок в ней важен.
- Сказать, хорош ли код.
- Найти уязвимости.
#Чтобы следующий раз обошёлся дешевле
Это повторится — со следующим разработчиком, со следующим агентством или с вами. Три вещи делают второй раз заметно дешевле, и все три дёшевы, пока ничего не горит:
-
Каждая учётная запись — на компанию
Домен, облако, регистратор, кабинеты провайдеров. Восстановление — на корпоративные почтовые ящики. Это один вечер, и он убирает худшую категорию сюрпризов целиком.
-
Актуальная техническая картина, живущая не в чьей-то голове
Обновляемая тогда, когда что-то существенно изменилось, а не по календарю. Ценность не в самом документе, а в том, что разница между двумя такими картинами видна.
-
Открытые вопросы, записанные в момент появления
Каждый раз, когда кто-то говорит «а вот как это работает, вообще-то никто не знает», — это запись в списке. Сделанная, пока человек, способный ответить, ещё в компании.
Проверка зависимости от разработчика — это пятнадцать вопросов на тему «насколько плохо станет, если это случится завтра», и она не требует аккаунта.
Вопросы, которые задают на самом деле
Большую часть технической картины — да, потому что она свойство кода, а не человека. Не восстанавливаются рассуждения: почему выбрали такой путь, что пробовали и отбросили, какое было ограничение. Сначала восстанавливают картину — именно она показывает, какие из недостающих объяснений действительно важны.
Сначала выясните, какие учётные записи он держит и на чьё имя оформлена каждая, и только потом что-то меняйте. Отзыв доступа в неправильном порядке способен закрыть вход в аккаунт, который был оформлен только на него. Здесь порядок важнее скорости.
Да, и это стоит сделать: быстро и работает. Агент не сделает двух вещей — не скажет, какие из его утверждений прочитаны, а какие додуманы, и не окажется рядом через три месяца, чтобы сказать, что изменилось. Если вопрос разовый, одного агента достаточно.
Сам анализ — от минут до нескольких часов работы агента, в зависимости от размера системы. Настоящие усилия уходят на открытые вопросы, которые он вернёт, и этот объём конечен: конкретный список, а не бесконечное расследование.
Немного — и меньше, чем принято думать. Существующую документацию всё равно принимают как заявление, а не как наблюдение: ей может быть несколько лет. Система без документации и система с неверной документацией ближе друг к другу, чем любая из них к системе с актуальной.