Теперь берём управление доступностью. В первом случае, приведённом в заметке Жени, процесс будет управляющим по отношению к деятельности любого айтишника, влияющего на доступность. Во втором — по отношению к процессам жизненного цикла, если таковые выделены и организованы. В любом из двух случаев менеджер управления доступностью также может не быть в курсе технических деталей разных частей инфраструктуры. Его задача — организовать деятельность других так, чтобы с доступностью всё было в порядке. Чтобы про неё не забывали при проектировании, тестировании, внедрении, эксплуатации.

Оба варианта имеют право на жизнь, разве нет?

Можно ведь для простоты картины считать «верхние» процессы тактическими, убирая из них по максимуму оперативную часть. Грубо говоря, пусть в предельном случае управление мощностями раз в год выдаёт план мощностей, аккурат к бюджетному циклу. А мониторинги и прочие оперативные процедуры отрабатывают те, кто «внизу» — в рамках процессов или ещё как, неважно.

А вместо плюсов-минусов можно рассмотреть границы применимости. Например, если организация в ближайшие годы собирается освоить пару-тройку операционных процессов и вдруг дойти до одного-двух тактических (простите за терминологию из ITIL v2), то первый вариант будет предпочтительнее. И крыша сразу не уедет, и сложной картины строить не нужно.

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

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

Менеджер по мощностям (читай — архитектор ИС) знает о том, как происходят релизы в продуктив и поддержка пользователей?

1. «к размыванию ответственности и усложнению контроля» Мне кажется как раз наоборот, повышается вероятность того, что внедряемое решение пройдет проверку/проработку по всем значимым характеристикам. Т.к. например, люди осуществляющие разработку заинтересованы в скорейшей реализации, а не в детальной проработке вопросов доступности. Так же как и люди осуществляющие внедрение. А расхлебывать потом людям, которые потом займутся эксплуатацией получившегося решения.

2. «к смешиванию...» — зависит от ролевой модели, тактическими вопросами могут заниматься одни люди, а операционные решать другие. При этом все могут прекрасно понимать что и зачем они делают.

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

1. к размыванию ответственности и усложнению контроля;

2. к смешиванию в рамках процессов CAP/AVM активностей разного уровня управления (операционного и тактического), что усложняет понимание процесса исполнителями;

3. и, как следствие 1 и 2, повышает риски нарушения процессов и снижает их эффективность.

Вопрос к докладчику — нужно покритиковать? предложить третий вариант? рассмотреть плюсы/минусы?