Передача

Что должно перейти из рук в руки, когда программа переходит к новой команде?

Девять областей и последовательность. Последовательность важнее списка, и если перепутать одну её часть, можно оказаться запертым снаружи собственных аккаунтов.

Короткий ответ

При передаче переходят четыре вещи: владение аккаунтами, способность эксплуатировать и выпускать систему, понимание того, что в ней есть, и рассуждения, которые живут только в людях. Идите по ним в этом порядке: владение — до подачи уведомления о расторжении, затем техническая картина, потому что её дыры задают повестку, затем показ, затем рассуждения, и смена доступов — в последнюю очередь. Замените «документация передана» тремя приёмочными проверками: выпустить, восстановить, объяснить.

#Последовательность

Прочитайте это до списка. Именно порядок трудно исправить, если ошибиться.

  1. Владение — до подачи уведомления, если это хоть как-то возможно

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

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

  2. Техническая картина — рано, потому что её дыры и есть повестка

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

  3. Показ — пока знающие люди ещё доступны

    Принимающая команда сама поднимает систему локально, выкатывает настоящее изменение и разворачивает бэкап. Сама, а не смотрит. Это превращает каждое «должно работать» в факт.

  4. Рассуждения — единственное, чего потом не восстановить

    Конкретные письменные вопросы с письменными ответами. Чего вы опасаетесь; что пробовали и не вышло; что ломается регулярно; что здесь стоит из-за ограничения, которого больше нет.

  5. Смена доступов — последней, после того как ваши пути входа проверены

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

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

#Девять областей

1. Код и история

  • Репозиторий в организации, принадлежащей компании
  • История коммитов целиком — не схлопнутый снимок Именно в истории новая команда находит, почему всё устроено так, как устроено.
  • Все ветки, теги и история релизов на месте
  • Права владельца организации есть у двух человек из компании
  • Есть список кода, который живёт вне этого репозитория

2. Среды

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

3. Инфраструктура и аккаунты

Единственная область, после которой можно остаться в проигрыше навсегда.

  • Регистрация домена на аккаунте компании
  • Управление DNS на аккаунте компании
  • Облачный аккаунт или организация принадлежит компании
  • Почта и телефон восстановления на всех критичных аккаунтах ведут в ящики компании Самый часто пропускаемый пункт в любом списке для передачи.
  • Счета по всем сервисам идут на корпоративный способ оплаты
  • Учтены сертификаты и всё, что продлевается автоматически
  • Аккаунты издателя в магазинах приложений переданы, если это применимо

4. Выкатка и релиз

  • Принимающая команда сама выкатила в продакшен
  • Конфигурация CI/CD передана вместе с хранящимися в ней секретами
  • Есть процедура отката, которую кто-то реально выполнял
  • Процесс релиза записан так, как выполнялся, а не так, как помнят
  • Найдены все ручные шаги в релизе

5. Данные и восстановление

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

6. Интеграции и зависимости

  • Перечислены все внешние сервисы, нужные системе
  • Рядом с каждым записано, на чьём он аккаунте
  • Перечислены входящие интерфейсы — кто снаружи зависит от этой системы
  • Перечислены исходящие потоки, включая файлы по расписанию и вебхуки
  • Найдены договоры и коммерческие условия, привязанные к зависимостям

7. Эксплуатация

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

8. Понимание

  • Актуальная техническая картина, выведенная, а не вспомненная
  • Открытые вопросы записаны и расставлены по приоритету
  • Письменные ответы на вопросы, которые может дать только уходящая команда
  • Какие части им было бы страшно отдать на изменение и почему
  • Что пробовали и бросили и что стоит здесь из-за исчезнувшего ограничения
  • Названы точки, завязанные на одного человека

9. Закрытие передачи

  • Владение подтверждено и ваши пути входа проверены ДО любого отзыва доступов
  • После передачи все доступы поменяны
  • Личные аккаунты и ключи удалены
  • Согласовано платное окно консультаций на последующие недели
  • Пройдены три приёмочные проверки

#Что заменяет документацию в качестве определения готовности

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

  1. Выпустить. Принимающая команда выкатывает настоящее изменение в продакшен, не обращаясь к уходящей.
  2. Восстановить. Она разворачивает бэкап во временную среду и показывает, что данные пригодны.
  3. Объяснить. Она письменно и правильно отвечает на десять вопросов о системе — выбранных вами, а не ею.

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

#Что вписать в договор

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

  • Аккаунты остаются за компанией. Подрядчик получает доступ, а не владение, и любой новый аккаунт заводится на компанию.
  • Определённый период передачи при расторжении, когда обе команды доступны и оплачены.
  • Три проверки как критерии приёмки вместо «документация передана».
  • Окно консультаций после, — небольшое число оплаченных часов в следующие месяц-два, потому что важные вопросы всплывают, когда новая команда начинает что-то менять.

#Что идёт не так

Оставить вопрос владения аккаунтами на конец процесса.

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

Потратить оставшиеся часы уходящей команды на архитектурный документ.

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

Согласиться на показ вместо самостоятельного выполнения.

Вместо этого Каждый шаг, который принимающая команда не проделала лично, — это шаг, который не передан.

Менять доступы до подтверждения владения.

Вместо этого Подтвердите владение, создайте свои пути входа, проверьте их — и только потом меняйте доступы.

Нулевой зазор между уходящей и приходящей командой.

Вместо этого Сделайте пересечение и оплатите его. Именно в зазоре всё подразумеваемое оказывается неправдой.

Считать, что репозиторий и есть вся система.

Вместо этого Спросите явно, что работает вне его: задачи по расписанию на сервере, облачная функция, созданная в консоли, скрипт на чьей-то машине, таблица, которую кто-то ведёт.

#Чего это не покрывает

Чего это не делает

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

Отмечайте по ходу или распечатайте.

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

Открыть интерактивный чек-лист Сначала проверить готовность