HashiCorp Vault — стандарт для управления секретами. Но базовые действия требуют нескольких переходов, а состояние системы не читается с первого взгляда. Для небольшой команды это лишняя когнитивная нагрузка каждый день.
Задача — спроектировать интерфейс, где состояние системы читается с первого взгляда, а ротация и выдача доступа занимают минимум шагов.
B2E-продукт для АНО ИЦТО. Самостоятельно вёл дизайн продукта и проектировал интерфейс с нуля до передачи в разработку.
Изучил ключевых игроков: HashiCorp Vault и Infisical. Vault перегружен — базовые действия требуют нескольких уровней навигации. Infisical визуально проще, но ротация и управление доступами так же сложны.
«HashiCorp все ставят, потому что это правильная вещь, но работать с ним тяжело — особенно когда нужно быстро понять состояние системы», — инженер из команды.
Вывод: проблема не в функциональности, а в ежедневной когнитивной нагрузке.
Vault — список проектов
Проекты без контекста: только название и дата создания. Чтобы понять состояние секретов — нужно зайти внутрь каждого проекта. С главного экрана не видно ни количества секретов, ни критичных статусов.
Vault — управление доступами
Роли вынесены в отдельный раздел и не связаны с контекстом проекта. Добавить или отозвать доступ — это переход в другой раздел, поиск пользователя, назначение роли вручную. Три действия там, где должно быть одно.
Infisical — список проектов
Карточки показывают количество окружений, но не статусы секретов. Нет информации о том, что истекает или требует внимания. Визуально чище Vault, но та же проблема: состояние системы — за несколькими кликами.
Infisical — форма создания секрета
Боковая панель с шестью полями: ключ, значение, комментарий, теги, метаданные, окружение. Простое действие требует заполнения длинной формы — когнитивная нагрузка выше, чем нужна для ежедневного сценария.
Гипотеза 1
Боль не в создании секретов, а в их сроках: ротация и истечение ключей тревожат сильнее всего.
Гипотеза 2
Инженеры делают лишние проверки, потому что не доверяют тому, что показывает система.
Гипотеза 3
Vault сложен из-за навигации, а не из-за избытка функций.
Выше — три ключевые из четырёх проверенных. Каждую проверил в трёх интервью на реальных сценариях из практики инженеров.
1
экран до состояния системы
≤ 3
шага на выдачу или отзыв доступа
100%
ротация через UI, без CLI
15 с
чтобы оценить общую картину
Ориентиры заданы на этапе проектирования — замеры после пилота.
3 интервью с DevOps-инженерами АНО ИЦТО — прямыми пользователями продукта, ежедневно работающими с Vault внутри организации. Строил вопросы вокруг реальных сценариев — прямой доступ к команде позволил не изобретать кейсы: инцидент из-за истёкшего ключа, отпуск с критичным сервисом, срочная выдача доступа ночью.
Примеры вопросов
Обзор проектов
Один экран показывает все проекты, число секретов и критичные статусы. Инженер видит, что требует внимания, без лишних переходов — это прямой ответ на находку из интервью: «чтобы понять состояние системы, открываю четыре вкладки».
Секреты и статусы
Таблица выводит статус каждого секрета — действующий, истекает, просрочен. Сортировка по срокам поднимает критичное наверх. Решение строил вокруг гипотезы: DevOps мыслят состояниями, а не объектами.
Настройка ротации
Интервал, метод обновления и уведомления — в одной форме, без CLI и yaml-конфигов. Это самая болезненная точка из исследования: инженеры тревожатся о сроках ключей, а не о механике их замены.
Интеграции — опциональный экран
Добавил как дополнительный модуль — интеграции настраиваются вручную. Сделал осознанно: сначала убедиться, что механика нужна, потом автоматизировать.
Два раунда тестирования на прототипе — с командой разработчиков и двумя внешними DevOps-инженерами.
Что поменял: разделил роли явнее и добавил подсказки — управление доступами было неочевидным. Убрал лишний шаг в сценарии выдачи — теперь один клик из таблицы. Переработал цветовую кодировку статусов — читались неоднозначно.
Сессия 1 — Рома, DevOps-инженер
Рома работает с Vault ежедневно и согласился проверить прототип. Задание — проверить, истёк ли токен у конкретного сервиса, и выдать временный доступ коллеге. На экране секретов Рома завис на управлении ролями: кнопка «Выдать доступ» была вынесена в контекстное меню, которое он не заметил. Из этой сессии родилось решение: вынести действия с доступами на уровень строки таблицы.
Сессия 2 — Аскар, Backend-разработчик
Аскар не DevOps, но периодически работает с секретами: подключает сервисы к CI-пайплайну. Сценарий — отозвать доступ у уволившегося коллеги под давлением времени. Аскар прошёл сценарий быстрее Ромы, но споткнулся на экране подтверждения отзыва: модальное окно с двумя кнопками казалось ему «слишком серьёзным» для рутинного действия. Убрал шаг — отзыв теперь в один клик с явной меткой статуса.
Передал прототип в разработку. По итогам сценарного тестирования на прототипе: выдача доступа — с пяти переходов до одного клика; отзыв — убрал шаг подтверждения, стало однокликовым. Состояние секретов читается за 10–15 секунд на одном экране. Ротация настраивается в интерфейсе, без CLI и yaml-конфигов.