Postmortem в ИТ: как превратить аварии в инструмент развития, а не в поиск виноватых

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

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

Именно на этапе эксплуатации становятся заметны настоящие преимущества зрелых инженерных практик. GitOps позволяет сделать управление доступами воспроизводимым. systemd и Kubernetes обеспечивают надёжный запуск. Аудит помогает отвечать на вопросы безопасников. А опыт эксплуатации учит тому, какие компромиссы действительно оправданы, а какие являются следствием инженерного перфекционизма.

Создать пользователя значительно проще, чем определить, что именно ему разрешено делать.

Большинство проблем современных IAM-систем возникает не на этапе аутентификации, а на этапе авторизации. Кто должен иметь доступ к production? Какие права положены подрядчикам? Что произойдёт после перевода сотрудника в другую команду? Как гарантировать, что увольнение автоматически приведёт к отзыву всех доступов?

Ответы на эти вопросы и отличают простую синхронизацию учётных записей от полноценной системы управления идентификацией.

После прочтения первой части могло сложиться впечатление, что встроенных возможностей Keycloak должно быть достаточно для большинства задач. Действительно, LDAP Federation прекрасно решает проблему аутентификации и избавляет от необходимости вручную создавать пользователей. Но опыт эксплуатации показывает, что именно после запуска системы в production начинают появляться требования, которые невозможно реализовать исключительно средствами Keycloak.

Бизнес хочет автоматически назначать роли новым сотрудникам. Информационная безопасность требует немедленно отзывать доступы у уволенных работников. Аудиторы задают вопросы о причинах изменения прав. Платформенные команды хотят хранить правила в Git и управлять ими декларативно.

Когда инфраструктура только появляется, управление доступами кажется удивительно простой задачей. Пользователей немного, сервисов ещё меньше, а новый сотрудник получает доступы буквально за несколько минут. Администратор заводит учётную запись в GitLab, вручную добавляет пользователя в Jenkins, создаёт VPN-профиль, отправляет логин и пароль в корпоративный мессенджер и идёт пить кофе с ощущением хорошо выполненной работы.

Проблемы начинаются тогда, когда компания перестаёт быть маленькой. Пять сотрудников превращаются в пятьдесят. Затем в сто. Затем появляется несколько команд разработки, отдел аналитики, подрядчики, стажёры, внешние консультанты и дежурные инженеры. Одновременно с этим растёт количество систем: GitLab, Jenkins, Grafana, ArgoCD, Harbor, OpenSearch, VPN, внутренние порталы, Wiki, корпоративные приложения и ещё несколько загадочных виртуальных машин, назначение которых никто уже толком не помнит, но выключить их страшно, потому что "что-то перестанет работать".

Есть одна мысль, которую многие компании почему-то осознают только после третьего массового увольнения, пятого выгорания команды и седьмого “а почему у нас опять все легло ночью”.

Инфраструктура - это не про технологии.
Инфраструктура - это про людей.