Интро
Пост с примерами неустроенностей/frustrations из своих рабочих проектов, на основе статьи «Toward a theory of evolution as multilevel learning.»
О чем говорим: Многомасштабная организация вселенной вызывает неустроенности. Они возникают, когда на системном уровне существует конфликт между задачами долгосрочной и краткосрочной оптимизации.
О чем не говорим: сознательно не концентрируюсь на возникновение сложности в результате описываемых конфликтов, то есть про выход на принцип E3.Многоуровневая иерархия. Такая тема может быть описана в отдельном посте.
Хотя, к примеру, в описанной здесь третьей системе интересно сейчас наблюдать над стремлением вендоров транформировать сервисные контракты на поддержку оборудования в полноценные договора на облачное сопровождение сложных сетей. Такие сети на обслуживании могут даже содержать оборудование других вендоров. Можно "поиграться" с концепциями из ссылочной статьи и представить себе юнит производства вендора Y в сети, построенной на базе оборудования вендора X. Такой юнит по аналогии может рассматриваться как вирус или паразит. Но ведь в любом случае будет горизонтальный перенос информации. Может оказаться, что этот юнит Y выполняет отдельные функции лучше окружения, что позволяет ему получить специализацию внутри системы, и при репликации (создании проекта следующей сети) он будет включен в цифровое описание как часть архитектуры.
Система первая, в которой мы любим людей и используем вещи
Посмотрим на работу аккаунт-менеджера, работающего в региональном представительстве крупного вендора - производителя решений для доменов ИТ и телекоммуникаций. B2B рынок, долгий цикл продаж.
Выстраивание отношений менеджера с заказчиками и партнерами проходит через постоянные развилки и выбор между долгосрочными и краткосрочными целями. Длительность цикла продаж может составлять месяцы и годы. В принятии решения участвуют множество стейкхолдеров.
Часть конфликтов:
- Между своими линейками оборудования - подешевле, но с меньшим запасом характеристик на масштабирование, или подороже, но с запасом на порядок выше.
- С решениями других вендоров (а ведь они почти равнозначны, помним про локальный оптимум).
- Между партнерами - интеграторами, которые реализовывают проекты.
- Между организационными звеньями заказчика.
Немаловажный конфликт - внутренняя мотивация. Как пишет Алексей Каптерев в книге "Хорошая, плохая продающая":
"Грань между «продавать» и «впаривать» очень тонкая. Меня однажды спросили, продавал ли Стив Джобс или впаривал — и если продавал, то что имеют в виду, когда говорят, что он обладал «полем искажения реальности»? Мне очень трудно ответить на этот вопрос. Если вы чувствительны к этике, вас всегда будет преследовать ощущение, что в продажах мы «любим вещи и используем людей — вместо того, чтобы любить людей и использовать вещи».
Подымаемся на уровень выше. Бизнес-юнит вендора, занятый продажами. Неустроенности:
- Между аккаунт-менеджерами. Как разделять рынок между ними: по отраслям экономики, по функционалу продаваемых решений, или каждый раз принимать отдельное решение? Как делить общие ресурсы, например, пул пресейл инженеров? Краткосрочная стратегия: пустить все на самотек.
- Конфликты за рынок и ресурсы с другими вендорами.
- Интересы центрального и регионального офисов, может быть, и офисов с соседних регионов. Есть ведь еще и глобальные заказчики, которые присутствуют географически на местном рынке, но продажи (часто очень хорошие) идут через глобальный аккаунт, а не через местный офис.
Отлично работает репликация накопленной информации: региональный рынок труда невелик и многие аккаунты, владеющие мастерством, успели поработать за свою карьеру у многих вендоров.
Еще одним уровнем выше: сами политика вендора на региональном рынке.
- Вендору можно сэкономить время и выйти на рынок через партнеров, нескольких или одного эксклюзивного.
- Если делать ставку на более длинную работу на рынке, то надо открывать региональный офис.
Еще одна развилка: продавать клиентам напрямую или через партнеров, через двухуровневую модель продаж. Напрямую выгоднее в отдельно взятых проектах, тогда как развитие партнерской сети помогает охватить весь рынок в долгой перспективе.
Система вторая, за которую нам платят
Телепортируемся к заказчику и смотрим на уже работающую у заказчика телекоммуникационную сеть, обслуживающую всё производство. То есть тысячи устройств, сотни магистральных каналов, десятки систем на обслуживании.
- Краткосрочная цель: поддерживать работоспособность сети, сосредоточиться на мониторинге эксплуатационных метрик и ликвидации "пожаров".
- Долгосрочная: прогнозировать и устранять будущие ограничения - узкие места по пропускной способности, морально и физически устаревающее оборудование, будущие потребности внутренних заказчиков.
Уровень ниже - сеть отдельного объекта, площадки.
- Краткосрочная цель: "работает - не трогай!".
- Долгосрочная: профилактические остановы на обслуживание активного и пассивного оборудования, замеры среды передачи данных (например, оптических линков). Также, тут можно вспомнить восемь заблуждений о распределенной архитектуре (тех ж, неустроенностей).
Еще одним уровнем ниже - отдельное устройство.
- Здесь и сейчас: максимальное использование индивидуальных возможностей устройства, тонкая индивидуальная настройка каждого порта, интерфейсного модуля, виртуальная "синяя изолента", которой вручную "подмотаны" проходящие через устройство потоки.
- Если хотим работать в долгую: централизованное раскатывание конфигураций, общие политики обработки трафика, автоматизация управлением control plane.
Система третья, в которой мы уменьшаем энтропию
Смещаем функцию на систему создания. Компания - партнер, построившая сеть площадки из второй системы на базе решений вендора из системы первой.
Уровень первый: сервисный договор на обслуживание сети заказчка.
- Краткосрочная цель: выполнение требований SLA по обслуживанию сети, поддерживать рабочие взаимоотношения с заказчиком.
- Долгосрочная: поиск плохих новостей, постоянное развитие собственных компетенций, state of the art технологий. Цель: поддержание уровня и цен услуг выше уровня рынка. Любой сервисный контракт заканчивается, и конкуренты будут готовы выполнить тот же объем работ за меньшую стоимость. То есть можно оказаться внутри чужого цикла, по концепции OODA.
Уровень второй: сеть объекта и ее системы. Конфликтов много, один из них: вокруг способа управления сетью. Вариант простой: управлять как есть, через терминальное подключение к каждому устройству. Вариант сложнее и красивее: каждый вендор сейчас будет рад продать систему управления сетью, которая снимает 80% работы с инженерного персонала, предоставит великолепные инструменты для автоматизации: мониторинга, настройки, автоматических политик. Но велик риск получить оба антипаттерна, описанных в статье про выбор корпоративного софта:
- «Vendor King» возникает, когда заказчик так увлекается системой управления сетью, что полностью выстраивает свою архитектуру вокруг этого продукта. В итоге появляется паталогическая привязка сети к продуктам одного вендора. На уровне сетевых протоколов все будет совместимо, а вот невозможность включить оборудование других вендоров в систему управления ограничит развиваемость /evolvability всей сети.
- «Ловушка последних 10%» : На 80% функционала развертывание системы затормозит. Следующие 10% можно будет сделать только, обходя с помощью разработчиков ограничения инструмента — например, с помощью скриптов. Последние 10% функций реализовать не удается вообще.
Уровень третий: отдельные устройства. Конфликтов/развилок много. Рассмотрим для примера развилку по сервисным контрактам на устройства.
- Краткосрочно: скорее всего, все будет работать, в крайнем случае, есть заводская гарантия вендора. На всякий случай, можно докупить наиболее чаще выходящие из строя компоненты, например, блоки питания.
- В долгосрочной перспективе есть платные сервисные контракты от вендора, которые за заметную долю цены от устройства готовы предоставляют расширенные сервисные гарантии. Дополнительно, в них включается обычно обновление встроенного программного обеспечения, доступ к технической поддержки, и т.п. За все надо платить: стоимость такого контракта за время существования сети будет сопоставима со стоимостью закупленного оборудования.
Выше перечислены три системы с описанием неустроенностей на трех системных уровнях для каждой. Очевидно, что как самих неустроенностей, так и самих уровней куда больше. Задача в том, чтобы учитывать их при работе со своими системами.
Вот не самый плохой ярлык из книги по программной архитектуре, который может запускать цепочку осознанных рассуждений:
There is no best design in architecture, only a least worst collection of trade-offs.
