что такое сервисная модель

Что такое сервисная модель

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

Возьмем торговую компанию со штатом в 100 человек, которую благополучно обслуживает ИТ-аутсорсер. Но благополучие это сохраняется лишь до тех пор, пока компания не начнет расти, и у нее не появятся новые ИТ-сервисы, от которых будет зависеть ее основная деятельность. Например, CRM-система, которая сразу поднимает количество запросов и инцидентов, скажем, на 10%.

Чтобы обработать их, организации придется докупить у своего поставщика ИТ-услуг полное время еще одного сотрудника, ведь другие занятые на проекте специалисты до отказа загружены работой (в этом аутсорсер кровно заинтересован). В лучшем случае заказчику предложат «половину человека», но она обойдется ему удельно дороже на 20-30%, т.к. аутсорсеру нужно будет покрыть свои затраты (на дорогу специалиста к клиенту и др.). При этом приобретенный втридорога сотрудник, благополучно закрыв все заявки по CRM, скорее всего, остальное время будет простаивать. А купить не 50–100%, а нужные ему 10% времени специалиста заказчик, по условиям договора, не может.

И это не особенность конкретного договора — так работает ресурсная модель ИТ-аутсорсинга, самая распространенная в среднем бизнесе. Если бы заказчик выбрал иную — сервисную — модель, то вопрос с масштабированием решился бы безболезненно. Ведь эта модель работает по схеме: «бизнес формулирует потребность (например, обработка заявок по CRM с заданным уровнем качества), а исполнитель оценивает свои затраты и дает цену». Каким образом исполнитель собирается «освоить» новый объем задач — нагрузив имеющегося специалиста или подключив дополнительные ресурсы — заказчику совершенно неважно. Главное, чтобы рост цены контракта был бы примерно пропорционален росту запросов.

Все ниже и ниже: ресурсная модель вместо сервисно-ориентированной

В другой типичной ситуации, когда бизнес экономит и не докупает нужные ресурсы, несмотря на рост объема работ по ИТ, перегруженные заявками сотрудники не стремятся отслеживать качество своих услуг и повышать интенсивность работы. Скорее, она у них со временем падает. Исполнитель при этом может спокойно «умыть руки», ведь задач стало больше, а заказчик не хочет за них доплачивать.

Уровень ИТ-сервиса здесь неизбежно страдает. Да и сама перспектива сотрудничества оказывается под угрозой, ведь стороны больше не удовлетворены друг другом. И снова в неверно выбранной ресурсной модели единственным возможным решением для клиента становится доплата за дополнительные руки, головы и время. Хотя даже это не подтолкнет аутсорсера к проактивности в решении инцидентов и проблем. Ведь в ресурсной модели поставщику услуг выгоднее продавать больше человеко-часов, а не заставлять сотрудников работать продуктивнее.

Более выгодной в этой ситуации для заказчика оказываются сервисная или сервисно-ориентированная модели ИТ-аутсорсинга. В них клиенту не нужно покупать сервис «большими кусками» — по 50% или 100% времени от специалиста на полный день. Заказчик просто добирает необходимый объем услуг в 10-20%, и получает их. Причем, с заданным уровнем качества. Затраты возрастают пропорционально. Причем заказчик может скомпенсировать этот рост за счет контролируемого снижения SLA или перехода к схеме SmartSLA, если провайдер ИТ-аутсорсинга располагает соответствующей технологией.

Качество ИТ-обслуживания: как получить нужное

Ресурсная модель ИТ-обслуживания могла бы изжить себя в 2016 году вместе с запуском закона о запрете на заемный труд (аутстаффинг), трансформировавшись в сервисную или сервисно-ориентированную. Но во многих случаях это произошло только «на бумаге» — договоры на аутстаффинг были заменены на сервисные, без изменений в самих услугах. Потому что переход к иным моделям обслуживания требует от исполнителя глубокого и системного знания сервисного подхода ITSM, наличия полной матрицы ИТ-процессов. А главное — реального опыта использования этих процессов для заказчиков различного масштаба и уровня зрелости в ИТ.

Кроме того, чтобы эффективно использовать выбранную модель ИТ-сервиса, нужно хорошо понимать ключевые характеристики, особенности и ограничения каждой из них.

Три модели обслуживания: главные характеристики и отличия

Сервисная модель: супер-стандартизация как главный принцип

Сервисная модель ИТ-поддержки подразумевает, что заказчик получает от исполнителя не конкретных специалистов, а обезличенные услуги с оговоренными параметрами. Например, техническую поддержку пользователей и рабочих мест, техническую поддержку бизнес-приложений, обеспечение непрерывной работы серверного ландшафта. Каждая такая услуга решает одну или несколько ИТ-задач, что при современном уровне зависимости бизнеса от ИТ почти автоматически превращает эти задачи в «бизнесовые». Поэтому у услуг, предоставляемых в рамках сервисной модели, всегда есть согласованные с бизнесом параметры: качество, сроки, стоимость. Как быстро будет взята в работу заявка? Когда она будет решена? Как скоро будет устранен сбой в инфраструктуре и заработает почта? На все эти вопросы есть понятные ответы, не расходящиеся с действительностью более, чем предусмотрено договором на оказание услуг.

Также у услуг в этой модели есть понятный принцип ценообразования. Например, 800 руб. в месяц за поддержку одного рабочего места. 50 руб. за одно решенное обращение. Штраф исполнителю 1000 руб. за каждый час просрочки.

В совокупности сервисная модель позволяет заказчику получить услуги нужного качества, с гарантией, по справедливой цене. Поэтому складывается ощущение, что если бизнес выберет сервисную модель ИТ-поддержки, то у него все сложится идеально. Однако, это не так. Покажем на примере.

Допустим, крупный заказчик — западная фармацевтическая или FMCG-компания, представленная в России, — покупает услуги первой линии техподдержки (прием и диагностику обращений и ИТ-инцидентов по почте, их решение в рамках SLA, установленных глобальным офисом), а также эскалацию более сложных проблем на вторую линию. В услугу входит и база знаний, к которой обращаются ИТ-специалисты. Там очень мало или почти нет опыта глубокого экспертного уровня. Но его достаточно, чтобы решать 50–70% запросов и придерживаться согласованных с заказчиком параметров качества, оставаясь в жестких рамках бюджета, а также максимальной стандартизации обслуживания — с помощью понятных регламентов и инструкций. В этой схеме уровень качества стабилен и не «завязан» на конкретного исполнителя — если они меняются, ИТ-сервис от этого не страдает.

Но есть одна досадная тонкость: принцип «действуем только в рамках SLA» распространяется даже на инциденты с самым высоким приоритетом, затрагивающие весь бизнес или его ключевые фигуры. Казалось бы, в чем проблема — достаточно задать жесткие требования к уровню сервиса, например, 15 минут на реакцию и 30 минут на решение задачи. Но, разумеется, подобный сервис оказывается крайне дорогим, особенно в масштабах международной корпорации. Поэтому корпоративный SLA, как правило, является значительно более мягким.

Совсем не редкость, когда на решение заявки с высоким приоритетом, если она не относится к общекорпоративным сервисам (ERP или электронная почта), отводятся часы или даже дни, и это будет «ОК» с точки зрения SLA. Есть даже примеры, когда стандарты сервиса процветающей международной компании вовсе не регламентируют время решения запроса.

На практике для сотрудников это часто означает «стабильно плохой сервис». Любой сотрудник компании, включая генерального директора, может ждать реакции на инцидент 2–4 часа. Еще день-два уйдет на то, чтобы ее решить. Все это время сотрудник, по сути, не может полноценно работать, и эта ситуация является совершенно нормальной с точки зрения корпоративного уровня сервиса. Получая такое «извращение» модели обслуживания, ИТ-директор вынужден решать такие инциденты аврально, обходя регламенты и снимая специалиста с другого участка, да еще и вразрез с корпоративным SLA.

Сервисно-ориентированная модель: рождение нового на стыке парадигм

Все вышеописанные ситуации указывают на очевидную вещь: в дополнение к двум господствующим моделям ИТ-обслуживания — ресурсной и сервисной — российскому бизнесу стала требоваться третья — сервисно-ориентированная. Потому что именно она объединяет сильные стороны традиционных парадигм обслуживания: исполнитель предлагает услуги с заданными параметрами качества, формируя команду специалистов «под заказчика». В этом случае клиент получает все основные преимущества сервисной модели: стабильность качества, SLA, понятное ценообразование. Добавляя к ним оперативность реагирования, гибкость управления, накопление и сохранение компетенций, присущие выделенным ИТ-командам в сервисно-ориентированной парадигме.

Новая парадигма в действии: как это работает и что получает заказчик

В новой модели большую часть времени команда работает в «сервисном режиме», обеспечивая решение задач в рамках корпоративного SLA. Но в случае форс-мажора, когда строгое следование формальному SLA становится неприемлемым, часть команды переходит в «экспертный» режим. Теперь задача решается не в общем потоке, а приоритетно и экспертно, с максимально быстрым восстановлением сервиса и последующим поиском системного решения. Причем эта процедура — штатная, насколько вообще может быть штатной работа по срочным инцидентам.

В этом случае генеральный директор уже через 20 минут получит новый аккумулятор для ноутбука, а не будет ждать стандартные 8 часов, отведенные SLA. А команда, вернувшись в «сервисный режим», начинает планомерно общаться с сервисным центром, системно решая задачу.

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

Однако здесь есть ловушка, которой аутсорсеру надо избегать во что бы то ни стало: преимущества работы в контексте заказчика (т.е. при «полной индивидуализации») создают соблазн возврата к ресурсной модели. А вместе с этим — ко всем ее недостаткам (переплата за невостребованные ресурсы, падение качества обслуживания, отсутствие проактивности). Чтобы избежать этого, исполнителю нужно отказаться от формирования жесткой структуры команды, когда все участники являются ключевыми. И создавать «ядро» из компетентных специалистов, создающих и сохраняющих экспертизу, плюс гибко масштабируемое окружение из сотрудников ServiceDesk, обеспечивающих «сервисные» функции.

Выбор модели ИТ-обслуживания: заключение контракта или скрытые ИТ

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

В последнем случае CIO, головой и креслом отвечающий за качество ИТ-сервиса на вверенном ему участке (1000 — 10 000 пользователей, крупная российская или западная компания), заключают контракт «на консультационные услуги» с локальным поставщиком ИТ. Или же в штате компании появляются таинственные «аналитики», «сотрудники инженерных служб», «техники», которые на деле являются ИТ-специалистами. По выражению одного из директоров международного производственного холдинга, возникают т.н. «скрытые ИТ».

Все они предоставляют заказчику главное — местный «спецназ», имеющий требуемый уровень экспертизы на конкретном участке ИТ или сразу на нескольких. Например, поддержку локальных бизнес-приложений медицинских представителей, или администрирование торговой системы. И возможность обратиться в собственный (или дружественный) центр компетенций, если проблеме присваивается повышенная сложность, а свои компетенции в этой части только нарабатываются или подтягиваются до нужной планки.

Разноуровневая экспертиза ключевых специалистов или команд быстрого реагирования открывает широкое поле для оптимального решения многих ИТ-задач. Это дает гарантию того, что срочные инциденты не превратятся в проблемы, серьезно влияющие на бизнес, а наиболее сложные проблемы (например, на стыке работы разных приложений, связанные с их производительностью) будут решены в короткие сроки или обнаружены заранее.

Итого: три способа решения ИТ-задач

На практике все три модели ИТ-обслуживания сегодня мирно сосуществуют на нашем ИТ-рынке. Но распределение популярности ресурсной, сервисной и сервисно-ориентированной моделей для разных сегментов рынка сильно различается. Так, около 50% средних сервисных и производственных компаний, особенно если уровень их ИТ-зрелости ниже среднего, склоняются к ресурсной модели, «арендуя» нужных специалистов. Почти 80% крупных международных компаний, например, фармацевтических или FMCG с представительствами в России — склоняются к явной сервисной или замаскированной сервисно-ориентированной. Аналогичным образом обстоят дела у розничных сетей: крупный ритейл тяготеет к сервисной и сервисно ориентированной моделям, а средний, развивающийся — к ресурсной.

Обобщая, можно сделать вывод, что ресурсная модель преимущественно используется компаниями с невысокой зрелостью ИТ. Другая категория предприятий, выбирающих эту модель — компании, претерпевающие ряд непрерывных изменений — например, рост торговой или филиальной сетей, когда гибкость «ручного управления» оказывается предпочтительнее сервисной стабильности.

И, напротив, компании с высокой зрелостью ИТ-служб, международные компании, заинтересованные в стандартизации процессов обслуживания и снижении издержек на ИТ-обслуживание при одновременном повышении его качества, предпочитают сервисную и сервисно-ориентированную модели.

Источник

Зачем строить ресурсно-сервисную модель ИТ-услуг

Качество предоставления услуг в компании зависит от стабильной работы всех компонентов ИТ-инфраструктуры. Оборудование, лицензии, ПО и другие активы взаимосвязаны между собой. Ресурсно-сервисная модель помогает прогнозировать все возможные последствия от изменения активов, находить слабые места в инфраструктуре и заранее предотвращать сбои. Также ресурсно-сервисная модель служит основной для сервисно-финансовой модели и модели влияния активов друг на друга.

Что такое ресурсно-сервисная модель

Ресурсно-сервисная модель отражает все объекты ИТ-инфраструктуры и показывает иерархические связи между ними. Разберем на примере.

Чтобы предоставить пользователям услугу «электронная почта», потребуется определенное ПО, которое работает на нескольких виртуальных серверах. Каждый из них в свою очередь расположен на физических серверах. Чтобы разместить их в компании, понадобятся стойки и специальное помещение — центр обработки данных (ЦОД). В ресурсно-сервисной модели эти связи визуально отражены.

Ресурсно-сервисная модель услуги «Корпоративная Электронная почта»

Эта информация позволяет получить данные о взаимосвязях между элементами инфраструктуры и в дальнейшем:

Как группируются активы в ресурсно-сервисной модели

Рассмотрим, как выстраиваются связи между активами на примере Naumen ITAM. Отображение ресурсно-сервисной модели в этом решении реализовано с помощью модуля визуализации связей. Он использует информацию обо всех активах в системе и их взаимосвязях, чтобы сформировать наглядную карту ИТ-инфраструктуры компании.

Объекты в ресурсно-сервисной модели группируются вертикально и горизонтально.

Вертикально активы объединяются по территориальному признаку с учетом иерархии расположений. Это позволяет быстро скрыть или показать активы, находящиеся на одной площадке.

Горизонтально активы объединяются по типам согласно классификации. Например, в категорию «ИТ-инфраструктура» входит элемент классификатора «Серверная инфраструктура». Она содержит два дочерних компонента — «Виртуальные машины» и «Физические серверы». Активы, относящиеся к элементу классификатора или к его дочернему компоненту, будут сгруппированы горизонтально.

Принцип организации классификации активов

Каждый элемент классификации и его дочерний компонент определяет:

Также все элементы классификации содержат реестр активов и реестр запросов по активам, включая аудиты и планово-предупредительные работы.

Классификацию ресурсно-сервисной модели из первого примера можно описать следующим образом: предоставление услуги «Корпоративная Электронная почта» поддерживают дочерние компоненты серверной инфраструктуры: виртуальные машины и физические серверы.

Пример классификации ресурсно-сервисной модели для услуги «Корпоративная Электронная почта»

В практике NAUMEN роль классификатора выполняет услуга и ее сервисные компоненты (составные части). Помимо выполнения функциональных требований к классификатору это позволяет:

Схематично это объединение выглядит следующим образом.

Элементы, которые объединяются или используются при классификации активов через управляющую ими услугу

В зависимости от взаимосвязей активы в ресурсно-сервисной модели также делятся по «уровням». Не существует универсального расположения «уровней». Так, в модели одной услуги оборудование поддерживает ПО, тогда как в другой услуге ПО координирует работу оборудования. В третьей услуге может не быть «уровня» оборудования, т.к. она поставляется «из облака» и т.д.

Ресурсно-сервисная модель для каждой услуги должна располагать горизонтальные группы (типы активов) в зависимости от связей между активами. Организация взаимосвязей между активами и управляющими ими услугами — тема отдельной статьи.

Зачем строить ресурсно-сервисную модель услуг и настраивать связи между активами

1. Оптимизируется работа специалистов по поддержке

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

2. Повысится скорость изменений ИТ-активов

Визуализация всех связей помогает понять, как устроена та или иная услуга и какие узкие места есть в ее предоставлении. Например, на схеме видно, что определенная услуга зависит от одного физического сервера. Если услуга критичная, лучше подстраховаться: виртуализировать сервер или подключить второй (зеркало), чтобы сбой в работе единственного сервера не остановил предоставление услуги.

3. Станет легче найти причину сбоя и сократить простои оборудования

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

4. ИТ-инфраструктура компании станет наглядной

При необходимости новому сотруднику, поставщику оборудования или подрядчику получится быстро объяснить и показать устройство инфраструктуры, в т.ч. особенности ее отдельных компонентов.

Источник

Разработка архитектуры системы через сервисно-ресурсную модель

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

Исходная позиция: разрабатываю и эксплуатирую с коллегами онлайн-систему, которая обслуживает сотни клиентов. Наша система работает на нескольких серверах, использует несколько БД, использует очереди сообщений, внешние сервисы для отправки смс и почты. Типичная ситуация? Вполне.

Хочу получить более прозрачную систему для охвата всей картины подшефного хозяйства, чтобы видеть узкие места, видеть зависимости одних частей системы от других, знать, что ssh на одном сервере крайне важен для «вон того маленького обработчика», который работает по ночам на другом сервере.

Зачем? Иногда требуется охватить взглядом все свое подведомственное хозяйство для получения четкой картины, увидеть направления масштабирования и узкие места. В общем, подумать об архитектуре всей системы. Понимаешь, что одни сервисы (БД, очереди сообщений) используются другими (приложения), а эти сервисы в свою очередь используются третьими. Это удобно для архитектора-разработчика при разработке и развитии системы, это удобно для эксплуатанта при эксплуатации системы.

Почему не ITSM/ITIL? Если глянуть в ITSM/ITIL, то можно там увидеть тему про сервисно-ресурсную модель. Вполне вероятно, что я не совсем компетентен рассуждать о сложностях ITSM/ITIL и внедрении оного в компаниях. Поэтому поправляйте меня, пожалуйста, если я где-то ошибаюсь, здесь и далее.

ITSM (IT Service Management) — подход к управлению и организации ИТ-услуг, направленный на удовлетворение потребностей бизнеса. Управление ИТ-услугами реализуется поставщиками ИТ-услуг путём использования оптимального сочетания людей, процессов и информационных технологий. (ITSM в Википедии)

ITIL (IT Infrastructure Library) — библиотека, описывающая лучшие из применяемых на практике способов организации работы подразделений или компаний, занимающихся предоставлением услуг в области информационных технологий. (ITIL в Википедии)

В ITSM/ITIL есть про сервисно-ресурсную модель. Но когда я начинаю читать всю эту кухню и думать о внедрении какого-либо «ентерпрайз» продукта, например: ИнфраМенеджер или ОмниТрекер, то «мой голова вай-вай». (Более того эти продукты целиком мне ни к чему, затраты на их покупку, внедрение и замену используемых в текущий момент будут ого-го, причем большая часть затрат будет не на ПО). Из всего ITSM мне надо немного — только схему зависимостей ресурсов, более того ITSM вроде как должен охватить всю организацию, я же хочу всего лишь использовать на маленьком выделенном участке в узкой области.

Далее изложу очень упрощенную версию сервисно-ресурсной модели. Почему такое упрощение? Просто пока не испытываю потребности вводить больше сущностей для понимания работы всей своей системы.

Система — сочетание всего нашего ИТ-хозяйства, которое установлено на наших серверах.

Сервис — любое приложение, будь-то веб-сервер или БД (далее приложение = сервис)

Ресурс — предоставляемая возможность сервисом для его использования из-вне сервиса.

Зависимость — связь сервиса с каким-либо ресурсом иного сервиса.

Т.е. систему можно представить как совокупность сервисов, часть из которых предоставляет ресурсы, а другая их использует.

Надо понимать, что зависимость от ресурса — это не равно потоку данных. Т.е. если наше приложение, например, зависит от сервера сообщений, то оно как принимает, так и отправляет сообщения через сервер сообщений.

Нарисуем простую схему концепта.

Например, у нас есть два хоста, на одном работает приложение node.js и сервер БД, на другом сервер PowerDNS и сервер БД. Наше приложение на node.js при создании новой учетной записи добавляет соответствующий домен 3-его уровня, занося записи в БД PowerDNS’а.

Далее можно дополнять и увеличивать количество сервисов и их зависимостей. Принцип понятен.

Раньше я подобные схемы рисовал в Gliffy.com. Но сейчас все чаще сталкиваюсь с необходимостью поддерживать эту схему в актуальном состоянии. Но в gliffy связи на схеме — это всего лишь соединение линии и прямоугольника. Поэтому идет поиск инструмента для хранения структуры взаимосвязей и отображения этих связей на схеме.

Вот пример моей схемы в Gliffy

Извините, пожалуйста, за качество.

Пока идет поиск (а я надеюсь, что вы, уважаемые читатели, в комментариях подскажете мне какие-либо инструменты, возможно, что-то подобное уже было на Хабре, да я не нашел), как прототип мы с коллегой набросали небольшое приложение deedoo. В нем мы храним информацию о хостах, сервисах, их ресурсах и зависимостях, а также строим схему зависимостей. Схема строится с использованием библиотеки Joint.js.

Проект на гитхабе: github.com/antirek/deedoo Инструкция по установке есть в репозитории. С помощью deedoo нарисована схема с PowerDNS выше.

Вот, например, как выглядят зависимости node.js приложения в веб-интерфейсе deedoo

Пока приложение Deedoo кроме рисования зависимостей больше ничего не умеет. Но еще есть идея использовать его как сервер настроек. Ведь если мы знаем, что наше произвольное приложение зависит от некоторых ресурсов, пусть оно их требует для своей работы.

Написав, что-то вроде config = serverConf(‘http://config.server.ru’).appID(‘super_key’).get(); мы можем получить все необходимые настройки приложения при его запуске. При отсутствии в загруженном конфиге необходимых параметров мы просто не запускаем приложение. Например, при переносе БД на другой хост нам для получения настроек приложением достаточно только перезагрузить, не так ли?

Пока не знаю. С одной стороны хочется более универсально, с другой — практично. Ведь цель — это сделать развитие системы более четким, прозрачным. С одной стороны подпирает мониторинг, с другой управление конфигурациями. Т.е. к этому списку сервисов — хочется видеть их метрики работы, состояния, производительности. А еще хотелось бы нажать кнопку и обновить параметры БД, приложения и т.д.

Итак, подошли к самому ключевому моменту данной заметки: что делать дальше? Варианты:

а) таки сделать все серьезно — внедрять ITSM/ITIL, выбрав какой-либо готовый продукт? (возможно есть отличные free & open source решения? описания внедрений в интернете?)

б) развивать свой велосипед? Т.е. использовать сервис, описывающий все зависимости. А новые разрабатываемые приложения используют загрузку настроек из этого сервиса. ( Мне, в целом, нравится идея любым получения настроек любым приложением с сервера настроек, добавить группы, типы — и вообще получится здравая система, имхо. Более того получение настроек свяжет эти декларированные зависимости в deedoo с реальными приложениями, которые работают на серверах. Но может это как-то стоит делать иначе? Может быть есть уже подобные системы? )

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

Источник