Алгоритм заземления, или как видеть реальность
Типичный случай в компании: приходит менеджер и заявляет, что нужен мониторинг сервиса подписок. На самом деле он имеет в виду следующее: менеджер хочет, чтобы при инциденте команда быстро узнавала, что сервис упал, могла выяснить причину и восстановить сервис. И по итогу, с его точки зрения, команда должна перестать регулярно узнавать о падении сервиса постфактум и постоянно бегать тушить пожары. Но ни сам менеджер, ни инженеры, получившие задачу, не пытаются обсудить, что на самом деле хотел постановщик, каково было его намерение. Менеджер считает, что инженеры его поняли, и не описывает задачу (не составляет описание/Description в FPF), а оставляет формулировку задачи как чистую эпистему/хотелку/намерение (Intensional Object в FPF). Инженеры поняли менеджера по-своему: «Нужно нарисовать дашборд в Grafana и собрать метрики». Они тоже, как и менеджер, не пытаются заземлиться и обсудить, что требуется на самом деле, как это будет выглядеть в эксплуатации. Просто молча предполагают, как надо, не согласовывают это с менеджером. В итоге через неделю дашборд в Grafana появляется, но сервис всё так же падает, а команда узнаёт об этом не сразу, потому что нет уведомлений, нет прописанных процедур быстрого восстановления сервиса, непонятно, какие агенты в какие временные промежутки должны выполнить эти процедуры, и так далее. Новый дашборд появился, но в работе SRE-команды ничего не изменилось, сервис падает. Команда, по меткому выражению одного из наших инженеров-менеджеров, сделала капусту вместо яичницы.
Что нужно было бы делать, чтобы этой ситуации не было: заземлиться. Обсудить, какую именно проблему решаем: «отсутствие информации о падении сервиса» или «медленное восстановление сервиса и неразбериха при восстановлении». Договориться, какой именно конечный результат нужен: «Когда сервис падает, уведомление немедленно приходит в выделенный канал, члены команды приступают к восстановлению сервиса по графику согласно описанным процедурам». Требуется договориться, кто и по какому сигналу принимает какое решение и начинает действовать какими методами, как проверять, что всё сделано.
Поэтому при постановке задач, в ходе разрешения инцидентов и в принципе в процессе любой коммуникации полезно заземляться. Заземление удобно проводить по следующему алгоритму:
- Опишите, что (какие объекты) должно измениться в физическом мире после того, как задача будет сделана. Явно пропишите: с точки зрения какой роли вы будете смотреть на ситуацию. Альтернативно: опишите, что вас смущает, что у вас «дребезжит», то есть, распишите ситуацию/контекст с выбранной точки зрения[1].
- Выделите в описании агентов, которые начали действовать иначе. Назовите эти иные действия. Назовите результаты этих действий: какие объекты сменили состояния (с точки зрения выбранной роли), назовите артефакты. Опишите последствия.
- Распишите, каким образом/способом/методом вы будете проверять, что в физическом мире произошли нужные вам изменения. Какие замеры вы будете делать, чтобы увидеть, что изменения реальны? Что вы будете измерять?
- При каких условиях результат возможно получить? А при каких невозможно?
- Какие сигналы могут вам указать заранее на то, что делается что-то не то?
Например, вы как менеджер хотите ускорить выпуск ленточных конвейеров для шахт в 1,5 раза. Соответственно, вам требуется отыскать оргзвено/рабочую станцию (в терминологии операционного менеджмента), работу которой нужно ускорить. Вы знаете, что согласно теории ограничений такая рабочая станция ровно одна: ускорение работы других станций не даст требуемый результат. Поэтому вы моделируете весь граф создателей/производственную цепочку (в терминологии операционного менеджмента), определяете, у какой рабочей станции самое длинное время цикла/потоковое время/Cycle Time/Flow Time, и ускоряете работу этой станции в 1,5 раза. Измеряем результат: ускорился ли выпуск конвейеров в 1,5 раза? Если да, правильно вычислено ограничение и выбраны правильные действия для оптимизации работы этого ограничения.
Нужный результат можно получить, если есть модель предприятия (или его части, выпускающей ленточные конвейеры для шахт), если собирается статистика по потоковому времени/времени цикла, причём сбор данных ведётся по одной методике, если у менеджера есть полномочия для проведения оргизменений.
Менеджеру потребуется отслеживать, как (не) сокращается потоковое время поставки очередной партии ленточных конвейеров для шахт. Также нужно будет внимательно следить за тем, как происходит оргизменение внутри выбранной рабочей станции. Команда сотрудничает? Команда выполняет поручения, или всячески саботирует?
Увидеть достаточно рано, что происходит что-то не то, он сможет, если потоковое время не сокращается, а также если команда не сотрудничает: всё время сомневается, затягивает сроки выполнения поручений, члены команды не приходят с вопросами, а всё время ждут встречи, в итоге время выполнения каждой задачи растягивается.
Что если менеджер не заземлится? Он предпримет управленческие действия, но может предпринять их не там. Например, он ускорит работу инженеров-конструкторов в 3 раза – но ограничением являются производственники, поэтому выпуск ленточных конвейеров никак не увеличится (реальный случай). Цель не достигнута, оргизменение, по большому счёту, проведено зря. Инженеры-конструкторы просто завалят работой и так медленных производственников – либо вскоре вернутся к старому темпу работы.
Как обычно происходит заземление? Сначала мы формулируем хотелку/намерение/чистую эпистему/intensional object. Формулируем её мы обычно «художественным» языком, полным метафор[2]. Метафоры и прочие художественные приёмы позволяют сильно сжать количество передаваемой информации. «За столом переговоров Эфиопия и Непал» – короткая фраза, но мы, благодаря впитанным из культуры эпистемам, сразу понимаем, что никакие страны ни за каким столом, конечно, не сидят, как это делают люди. В данной фразе речь лишь о том, что дипломаты, представляющие Эфиопию и Непал и уполномоченные говорить как представители своих стран, провели переговоры. Распаковка художественной фразы даже в первом приближении оказывается длиннее, чем сама фраза – а ведь мы даже не привели объяснение, что такое «дипломат» (в данном случае – роль), почему дипломаты имеют право говорить как представители своих стран, откуда возникло выражение «стол переговоров», и так далее. Говорить на художественном языке нас обучают с детства, он привычен нам. Кроме того, человечество значительную часть истории говорило на неформальном, художественном языке. Формализация используемых профессиональных языков постепенно происходит, но, как и любое эволюционное изменение, происходит оно медленно.
Поэтому свои первые хотелки мы формулируем очень нечётко. Например, менеджер говорит «нужен мониторинг сервиса подписок». Это ещё не формулировка задачи! Это лишь первая попытка выразить намерение/мысль: что нужно сделать. Чтобы поставить задачу, надо сначала описать, что нужно сделать – то есть, от чистой эпистемы/intensional object перейти к описанию/description.
Напомню, что описание в руководствах МИМ используется не как слово из бытового языка, а как слово из профессионального языка. Если вы натыкаетесь на слово «описание», значит, имеется в виду, что:
- вы отсылаете к каким-то конкретным объектам/described_entity,
- описанным с какой-то определённой точки зрения/viewpoint,
- в определённом контексте/bounded context,
- и можете проверить, что описание соответствует описываемым объектам в нужные моменты времени.
В данном случае менеджеру надо сформулировать проблему: «Сервис подписок регулярно падает, и восстановление его работоспособности занимает несколько часов. Мне как менеджеру необходимо, чтобы сервис падал в 2 раза реже и восстанавливался в пределах получаса. Причём процедура восстановления должна начинаться автоматически, все члены команды должны знать, что делать». Это уже куда больше похоже на описание ситуации с точки зрения/viewpoint менеджера, чем «нужен мониторинг сервиса подписок». Дальше можно обсуждать с командой, что необходимо сделать, чтобы достичь описанного результата.
Аналогично придётся раскрывать встречающиеся в текстах ваших документов магические фразы вида «автоматизировать процессы». Надо будет сначала разобраться, какие «процессы» надо автоматизировать, что такое вообще «процессы» в вашем контексте, насколько они сейчас оптимально выполняются – и не следует ли сначала навести порядок в ваших процессах. Бесполезно автоматизировать плохо настроенные процессы – вы получите только автоматизированный хаос.
В FPF заземление описывается кластером паттернов C.2.1”. + C.2.1 + A.6.P. При выполнении заземления вместе с LLM, усиленной FPF, просите её при ответе опираться на эти паттерны.
Подробнее о ролях и точках зрения вы узнаете в разделе 2 ↩︎