История про кусок сала, галку и системный анализ или как я случайно сломал бизнес-процесс одной галки
Иногда жизненные ситуации очень точно объясняют, чем на самом деле занимается системный аналитик.
Недавно со мной произошла довольно абсурдная история.
Я поехал помыть машину на робот-мойку. После мойки решил открыть капот, чтобы долить омывающую жидкость. Открываю — и вижу странную картину.
У петли капота лежит кусок сала. Причём нормальный такой кусок — сантиметров 15 длиной, как будто от грудинки отрезали.
Первая мысль была простая:
«Это что вообще такое?»
Вторая мысль — чуть менее приятная:
«Я что, кому-то во дворе так мешаю, что мне под капот сало подложили?»
Но потом включилась логика. Вреда от такого «диверсионного метода» особо не будет. Скорее всего всё гораздо проще: какая-то птица спрятала запас еды, а на мойке поток воды просто загнал его глубже под капот.
Я выкинул кусок сала, закрыл капот и поехал домой.
История могла бы закончиться здесь, но самое интересное произошло на следующий день.
Утром я выглянул в окно и увидел, как по моему капоту ходит большая тёмная птица — похожая на галку. Она бегала туда-сюда, заглядывала под дворники, прыгала по капоту и явно что-то искала.
Причём было заметно, что птица искренне возмущена.
Если попытаться перевести её поведение на человеческий язык, это выглядело примерно так:
«Я точно оставляла стратегический запас здесь. Где мой ресурс?!»
И в этот момент я понял:
я только что случайно сломал чей-то бизнес-процесс.
Архитектура хранения сала
Если посмотреть на ситуацию глазами той самой галки, всё выглядит довольно логично.
Есть система хранения ресурсов.
Компоненты системы:
- источник еды — где-то найденный кусок сала
- хранилище — ниша у основания лобового стекла (жабо)
- защитный корпус — автомобиль
- план использования — вернуться позже и забрать запас
С точки зрения птицы архитектура выглядела вполне надёжной.
Сало спрятано. Место закрыто. Доступ ограничен.
Но в архитектуре оказался неучтённый фактор — внешний оператор системы.
То есть я.
Я открыл капот, обнаружил неизвестный объект и удалил его из системы.
Инцидент-менеджмент глазами галки
На следующее утро птица фактически проводила расследование инцидента.
Сценарий выглядел примерно так:
Инцидент:
пропал стратегический запас сала.
Первичная диагностика:
обход территории хранения.
Проверка гипотез:
— под дворниками
— у основания стекла
— на поверхности капота
Результат:
ресурс отсутствует.
Вероятная причина:
вмешательство внешнего пользователя системы.
В IT такие вещи называются incident investigation — поиск причины, почему система перестала работать так, как ожидалось.
Где здесь системный анализ
Эта история смешная, но она очень точно показывает несколько вещей, с которыми постоянно сталкиваются системные аналитики.
1. Пользователи системы могут быть не теми, кого вы ожидали
Когда проектируется система, обычно думают о конкретных пользователях.
Но в реальности появляются так называемые shadow users — пользователи, о которых никто не думал.
В IT это могут быть:
- сторонние интеграции
- скрипты
- автоматические сервисы
- команды из других отделов
В моей истории таким «неожиданным пользователем» оказалась галка.
Система «автомобиль» неожиданно стала частью её логистической инфраструктуры.
2. Нефункциональные требования тоже важны
С точки зрения птицы система хранения должна была удовлетворять нескольким требованиям:
- сохранность ресурса
- защита от внешнего доступа
- стабильность хранения
Но архитектура оказалась неустойчивой к одному простому событию — вмешательству человека.
В IT это как раз относится к нефункциональным требованиям:
- надёжность
- устойчивость
- безопасность
- отказоустойчивость
Система может работать идеально…
пока не происходит что-то, о чём никто не подумал.
3. Изменение системы без анализа зависимостей
С моей точки зрения всё было просто:
я открыл капот → увидел странный объект → удалил его.
Но с точки зрения системы это было незапланированное изменение архитектуры.
Я изменил состояние системы, не понимая всех зависимостей.
В IT это происходит постоянно.
Кто-то меняет одну маленькую вещь — и неожиданно ломается процесс, о существовании которого никто не знал.
Хорошая система начинается с понимания
В системном анализе есть простая, но важная мысль:
любая система работает в контексте.
Если этот контекст не понимать, можно очень легко сломать чей-то процесс — даже не подозревая об этом.
Иногда это касается сложных банковских интеграций.
Иногда — распределённых сервисов.
А иногда — запасов сала одной галки.
Итог
История смешная, но мораль у неё вполне рабочая для IT.
Перед тем как менять систему, важно понимать:
- кто ей пользуется
- какие процессы вокруг неё построены
- какие зависимости существуют
Потому что иначе можно случайно сломать чей-то бизнес-процесс.
Даже если этот бизнес-процесс принадлежит птице.