Что на самом деле должно быть в первые тридцать дней?

Ваши тридцать дней

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

Первая неделя

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

Вторая неделя

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

Третья неделя

• Превратите дыры в вопросы и принесите их команде — именно как вопросы, а не как находки. Смотрите, на какие никто не может ответить: это ваша повестка на два квартала.
• Сосчитайте точки, завязанные на одного человека — по частям: кто мог бы ответить на трудный вопрос по каждой. Части с одним именем и есть ваш реестр рисков.
• Установите, что будет, если один конкретный человек недоступен — на таком размере это не гипотеза, и ответ обычно «мы встаём».
• Найдите компоненты без явного владельца — когда развёрнутых систем больше пяти, почти всегда есть хотя бы одна, которую никто не забрал себе.
• Смотрите на края, а не на ядро — в молодой системе ядро обычно в порядке, а углы срезаны на несчастливых путях: повторы, таймауты, аутентификация вебхуков, что происходит при сбое.

Четвёртая неделя

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

Чего в этом месяце делать не надо

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

Распечатать или сохранить в PDF