Без штатного CTO безопасность решений держится не на героизме и не на «самом опытном разработчике», а на процедуре: решения делят на легко обратимые и дорогие в отмене, для вторых записывают контекст, варианты и условие пересмотра, в репозитории и инфраструктуре действуют минимальные защитные правила, а внешний взгляд привлекают в заранее определённых точках. Основатель при этом остаётся владельцем ключевых доступов. Ниже — порядок, который команда может внедрить своими силами и вести без внешней помощи.
Содержание
Чего на самом деле не хватает без CTO
Небольшая команда без технического директора обычно умеет писать код. Не хватает другого — функций, которые CTO выполняет помимо программирования. Если их не назначить явно, они не исчезают, а выполняются случайно: тем, кто первым столкнулся с проблемой.
Владелец технических решений
- Что происходит без владельца
- Решения принимаются в чатах и забываются, через полгода никто не помнит причин
- Минимальная замена
- Журнал решений в репозитории
Фильтр рисков
- Что происходит без владельца
- Дорогие в отмене решения принимаются так же быстро, как мелкие
- Минимальная замена
- Правило двух классов решений
Связь бизнеса и технологий
- Что происходит без владельца
- Команда оптимизирует то, что интересно, а не то, что важно продукту
- Минимальная замена
- Регулярный короткий разбор приоритетов с основателем
Хранитель доступов и непрерывности
- Что происходит без владельца
- Домен, облако и репозиторий оформлены на личные аккаунты разработчиков
- Минимальная замена
- Все ключевые аккаунты — на компанию, список доступов
Оценка кандидатов и подрядчиков
- Что происходит без владельца
- Нанимают по впечатлению, подрядчика принимают без проверки результата
- Минимальная замена
- Внешний взгляд в заранее определённых точках
Два класса решений
Большинство технических решений легко отменить: выбор библиотеки для дат, способ вёрстки формы, название переменной. Их стоит принимать быстро, силами того, кто делает задачу. Но есть решения, отмена которых стоит месяцев работы или ставит под угрозу данные. Для них нужна другая процедура.
Легко обратимые — решает команда сразу
- Внутренние библиотеки и утилиты
- Структура компонентов интерфейса
- Инструменты разработчика
- Порядок задач внутри спринта
Дорогие в отмене — запись и второй взгляд
- Модель данных и выбор базы данных
- Способ аутентификации и хранения персональных данных
- Облачный провайдер и регион размещения
- Мобильный стек, архитектура многоарендного продукта
- Договоры с поставщиками API и платформ
Простой тест для спорных случаев: что будет, если через полгода решение окажется ошибочным? Если ответ — «поменяем за день», решение обратимое. Если в ответе есть слова «миграция данных», «переписать», «уведомить пользователей» или «расторгнуть договор» — решение относится ко второму классу.
Журнал решений: короткая запись вместо памяти
Для решений второго класса подходит формат ADR (architecture decision record), который в 2011 году описал Майкл Найгард: короткий документ в репозитории проекта с разделами «Название», «Контекст», «Решение», «Статус» и «Последствия». Записи нумеруются, номера не переиспользуются, а отменённое решение не удаляют, а помечают как заменённое.
Смысл журнала Найгард формулирует так: новый человек в проекте, не зная причин прошлых решений, либо слепо их принимает, либо слепо отменяет — и оба варианта плохи. Для команды без CTO журнал ещё и заменяет «память» отсутствующего руководителя.
Проблема
Что нужно решить и почему сейчас; какие ограничения есть у бизнеса и команды.
Варианты
Два-три реальных варианта, включая «ничего не менять», с плюсами и минусами каждого.
Решение
Что выбрано и почему; что сознательно отвергнуто.
Владелец
Кто отвечает за исполнение и к кому идти с вопросами.
Условие пересмотра
Дата или событие, при котором решение стоит открыть снова: рост нагрузки, новый рынок, смена команды.
Минимальные защитные правила
Защитные правила снижают цену ошибки, кто бы её ни совершил. Они не требуют штатного архитектора — их настраивают один раз и проверяют периодически.
- Репозиторий, домен, облачные аккаунты, аккаунты сторов и платёжных сервисов оформлены на компанию; у основателя есть права владельца.
- Двухфакторная аутентификация обязательна для всех участников. В GitHub владелец организации может требовать её; внешние соавторы без неё удаляются из организации.
- Основная ветка защищена: изменения проходят через pull request с одобрением и обязательными автоматическими проверками, принудительная перезапись истории и удаление ветки запрещены.
- Секреты не хранятся в репозитории; у каждого окружения свои ключи.
- Резервные копии делаются автоматически, а восстановление из них проверяется на практике, а не только в настройках.
- Боевое и тестовое окружения разделены; данные клиентов не копируются в тестовое без обезличивания.
- При уходе сотрудника или подрядчика доступы отзываются по списку, а не по памяти.
- Зависимости обновляются регулярно, а не только после инцидента.
Ритм и метрики без бюрократии
Процедура работает, если у неё есть ритм. Достаточно короткой регулярной встречи, на которой команда с основателем просматривает новые записи журнала, открытые риски и инциденты за период.
Чтобы видеть, улучшается ли процесс поставки, можно опереться на метрики исследовательской программы DORA. Их пять:
- Время внесения изменения — от коммита до работы в продакшене.
- Частота развёртываний.
- Время восстановления после неудачного развёртывания.
- Доля развёртываний, потребовавших срочного вмешательства — отката или исправления.
- Доля незапланированных развёртываний, вызванных инцидентом.
DORA прямо предупреждает: не превращайте метрики в целевые показатели и не сравнивайте команды между собой — их задача показывать динамику вашей собственной команды. Для небольшой команды это удобный способ говорить с основателем о качестве процесса без технических подробностей.
Инциденты разбирают письменно и без поиска виноватых. В книге Google SRE разбор (postmortem) определяется как письменная запись об инциденте, его последствиях и принятых мерах, а среди поводов для него — потеря данных любого рода, заметный пользователям простой и случаи, когда проблему обнаружил человек, а не мониторинг.
Когда звать внешний взгляд и когда нанимать CTO
Внешний взгляд полезен не постоянно, а в определённых точках. Договоритесь о них заранее, чтобы обращение за советом не воспринималось как признание слабости.
- Перед решением второго класса, если в команде нет опыта именно в этой области.
- Перед передачей продукта подрядчику или приёмкой результата от него.
- Перед привлечением инвестиций, когда продукт будут проверять со стороны.
- После серьёзного инцидента, особенно с данными.
- Когда команда долго спорит и не может выбрать между вариантами.
Штатный CTO нужен, когда технологии — ядро продукта и стратегические технические решения идут постоянным потоком, а команда выросла настолько, что требует найма, развития и управления людьми. Внешнее сопровождение эту роль не заменяет: оно помогает принимать и проверять решения, но не берёт на себя управление персоналом.
Техническое сопровождение InterLAB — это регулярные консультации, ревью решений и pull request в оговорённом объёме, а результат — журнал решений и следующие шаги по периоду. Частота и объём фиксируются в договоре; режима «на связи 24/7» и ответственности CTO по умолчанию в нём нет — расширенные полномочия возможны только после отдельного согласования. Стоимость определяется после брифа и согласования объёма.
