В прошлой статье я рассказал странную историю:
как нашёл под капотом машины кусок сала, выкинул его, а на следующий день увидел галку, которая явно пришла за своей заначкой и была крайне недовольна пропажей.
Если пропустили ту историю — вот она:
https://dzen.ru/a/abQt0AATVxI40hD2
Тогда я шутливо написал, что случайно сломал чей-то бизнес-процесс.
Но чем больше я думал об этой ситуации, тем больше понимал: она отлично иллюстрирует одну важную вещь из системного анализа — нефункциональные требования.
И галка, судя по всему, подошла к их проектированию довольно серьёзно.
Как выглядела система хранения сала
Попробуем посмотреть на ситуацию глазами птицы.
У неё есть ресурс — кусок сала.
Нужно решить задачу: где его безопасно сохранить, чтобы потом вернуться и съесть.
Это классическая задача проектирования системы хранения.
И галка, похоже, выбрала архитектуру примерно такую:
Хранилище: ниша у основания лобового стекла автомобиля (жабо).
Контейнер: автомобиль как физическая оболочка.
Доступ: сверху, через щель у стекла.
На первый взгляд решение кажется случайным, но если разобрать его через призму системного анализа, всё становится довольно логичным.
Нефункциональные требования галки
В IT-системах кроме функциональности всегда есть нефункциональные требования — то есть требования не к тому что система делает, а как она это делает.
Например:
- безопасность
- надёжность
- доступность
- устойчивость
Если попробовать восстановить требования нашей галки, получится примерно такая таблица.
Требование
Как оно выглядело
Безопасность
скрытое место, которое сложно заметить
Доступность
птица может легко достать запас
Скрытность
другие птицы не видят ресурс
Стабильность
запас лежит в одном месте
С точки зрения птицы машина во дворе — почти идеальное хранилище.
Она большая.
Закрытая.
У неё есть удобные щели и ниши.
И главное — большинство животных туда просто не доберётся.
Где архитектура дала сбой
Проблема оказалась в одном факторе, который система не учитывала.
Человек.
В архитектуре галки не было сценария:
«Владелец машины откроет капот, найдёт странный кусок сала и удалит его из системы».
А именно это и произошло.
Если переводить на язык IT, то произошла классическая ситуация:
неучтённый внешний пользователь изменил состояние системы.
В системном анализе такие вещи происходят регулярно.
Мы проектируем систему, учитываем пользователей, роли, сценарии…
а потом появляется кто-то, о ком никто не подумал.
Неожиданные пользователи системы
В IT для этого даже есть негласный термин — shadow users.
Это пользователи, о которых никто не думал при проектировании.
Например:
- другой отдел компании
- внешний сервис
- старый скрипт
- автоматическая интеграция
Они начинают пользоваться системой, потому что им это удобно.
В моей истории таким неожиданным пользователем оказалась галка.
А я, в свою очередь, стал администратором системы, который случайно удалил важный ресурс.
Почему нефункциональные требования часто ломают системы
Самое интересное, что многие реальные проблемы в IT происходят именно из-за нефункциональных требований.
Функционально система может работать идеально:
- запросы отправляются
- данные сохраняются
- интерфейс работает
Но если не продуманы:
- безопасность
- устойчивость
- ограничения доступа
- поведение системы в нестандартных ситуациях
— система начинает ломаться в самых неожиданных местах.
Иногда из-за сложных технических причин.
А иногда из-за человека, который просто открыл капот и выкинул кусок сала.
Небольшой факт про галок
Галки относятся к семейству врановых — группе птиц, которые считаются одними из самых умных.
Они умеют прятать еду в тайниках и возвращаться к ним позже, используя окружающую среду как естественное хранилище.
По сути, это довольно сложная стратегия хранения ресурсов.
И именно поэтому галка так настойчиво искала свою заначку на моём капоте.
Вывод
История с кусочком сала и галкой неожиданно хорошо показывает одну вещь.
Любая система работает в контексте.
Если этот контекст не учитывать, даже хорошая архитектура может разрушиться из-за одного простого действия.
Иногда это сложная интеграция между сервисами.
Иногда — бизнес-процесс внутри компании.
А иногда — тайник одной галки в машине системного аналитика.
Если вам нравятся такие разборы реальных ситуаций через призму системного анализа — подписывайтесь на канал. Здесь я регулярно показываю, как принципы проектирования систем проявляются в самых неожиданных жизненных историях.
А если вы пропустили первую часть этой истории — вот она:
https://dzen.ru/a/abQt0AATVxI40hD2