Взгляд на архитектуру систем

ПОДРОБНЕЕ О КНИГЕ

Ключевые виды деятельности

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

В общем случае система может находиться всего в трех возможных состояниях:

• созидание — движение от хаоса к порядку, от целей к будущим событиям;
• сохранение — поддержание существующего порядка вещей;
• разрушение — движение от порядка к хаосу, от внешних событий к будущим целям.

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

Операционные процессы направлены на предоставление сервисов клиентам и сохранение текущего качества как есть. Процессы развития, с одной стороны, направлены на выравнивание общего баланса при помощи изменения масштаба или архитектуры системы. С другой стороны, процессы развития направлены на изменение качества действующих систем и создание новых систем. Рискну предположить, что к каким бы умным процессным методикам мы ни обратились, в них найдется место для нескольких базовых процессов:

Управление ресурсами
• Мониторинг
• Основные бизнес-процессы
  • Операционные процессы (область реактивного поведения):
    • предоставление сервисов (управляется запросами клиентов);
    • регламентные работы (сохранение качества);
    • управление ошибками (предотвращение ошибок или восстановление качества)
  • Процессы развития (область проактивного поведения)
    • Управления масштабом (экстенсивное развитие):
      • слияние/поглощение;
      • масштабирование элементов системы;
      • управление емкостью элементов системы.
    • Улучшения качества (интенсивное развитие):
      • трансформация системы;
      • изменения архитектуры внутри системы;
      • тюнинг элементов системы.

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

Предоставление сервисов и регламентные работы

Предоставление сервисов — это деятельность системы, предоставленной самой себе, без любых вмешательств. Мы циклически исполняем основные рабочие процессы. Однако, предоставленная сама себе, система обладает свойством роста энтропии, что выражается в ее постепенном изнашивании и снижении качества.

Регламентные работы также довольно просты для понимания. Мы периодически или по запросам клиентов выполняем профилактические работы, минимальными усилиями поддерживая качество систем на должном уровне, удерживая энтропию постоянной.

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

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

• выравнивание баланса с изменившейся внешней средой (предложение догоняет спрос);
• сознательная разбалансировка по отношению к внешней среде (предложение обгоняет спрос).

Изменения можно провести несколькими способами. Рассмотрим их более детально.

Управление масштабом

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

До некоторого момента мы можем устранять раз­балансировку экстенсивным способом. Но обязательно наступает момент, когда линейный рост перестает работать, и требуются изменения в архитектуре системы. Это и есть действие закона перехода количественных изменений в качест­венные.

Стандартные действия или изменения?

Будучи участником конференций по управлению ИТ-сервисами, я был свидетелем двух, как мне кажется, противоположных высказываний довольно авторитетных ИТ-экспертов. В одном из них утверждалось, что любое действие по отношению к пользователю (например, установка рабочего места) является изменением. В другом утверждалось, что в ИТ скоро грядет революция, и большинство операций будет стандартизировано и роботизировано. Я имел неосторожность заявить, что любое изменение является уникальным, что стандартных изменений не бывает и любая стандартная работа относится скорее к области регламентных работ, устранению ошибок и исполнению заявок клиентов, нежели к области изменений. С удивлением я обнаружил, что в этой дискуссии я остался в меньшинстве и мои оппоненты действительно верят в существование стандартных изменений. Как мы выяснили в предыдущей публикации, точная граница (что считать, а что не считать изменением) субъективна и сильно зависит от точки зрения владельца или участника системы. Может показаться, что чем более масштабное действие происходит с системой, тем больше это действие похоже на изменение. Я сам одно время придерживался этого мнения, но сегодня считаю это заблуждением. Экстенсивный рост — это всего лишь результат однотипных плановых действий по наращиванию объема или мощности системы.

Ключевыми факторами, определяющими границу между изменениями и стандартными работами, на мой взгляд, являются:

• уникальность или повторяемость выполняемых действий;
• глубина изменения вашей личной или согласованной с другими модели архитектуры.

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

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

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

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

По отношению к модели архитектуры, в наших будущих действиях возможны три ситуации.

• Действие не затрагивает модель системы — обычная рутинная деятельность.
• Действие затрагивает модель системы — это и есть изменения.
• Действие затрагивает метауровень — перемены, крупные качественные изменения.

Если деятельность затрагивает изменение модели архитектуры системы — это действительно изменение, если не затрагивает — стандартная активность.

Здесь проходит тонкая граница между изменениями и операциями.

Таким образом, если в вашей компании 15 человек, выполняющих разные работы, то наверное, замена компьютера одному из них является серьезным изменением вашей инфраструктуры, поскольку эти 15 компьютеров и есть модель инфраструктуры вашего бизнеса. В большом же масштабе не стоит считать изменением подключение 50-миллион­ного абонента к мобильному оператору. В этом случае модель архитектуры включает само понятие абонента и сотового телефона, но не их количество. Количество же подключений управляется процессами оказания услуг абонентам и управлением масштабом сети, то есть стандартными активностями. Может показаться, что дело только в масштабе. Нет, дело в том, как вы построили собственную модель архитектуры и что оставили за ее пределами, как снаружи, так и внутри.

Проект — способ выравнивания баланса

Крупными изменениями удобно управлять, выделяя их в отдельную проектную деятельность. Проверим, как модель «6 x 4» работает на проектном цикле (рис. 1).

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

В реальной жизни огромное количество человеческих ресурсов тратится в левой части цикла, и особенно в точке «1. Предпроектный анализ». Большое количество идей и инициатив образуют воронку, проходят тщательный анализ и не доходит до реализации. Дело совершенно не в том, что это плохие идеи, а в том, что среди множества хороших надо найти те несколько, которые действительно «выстрелят» и принесут важные результаты, на которые стоит потратить как собственные, так и привлеченные ресурсы. Любая идея должна созреть, чтобы материализоваться. При этом состояние «1. Сбор и анализ информации» должно действительно превысить критическое значение разбалансировки (между рынком и вашими продуктами, между спросом и предложением, между уровнем вашей отдачи и получаемой зарплатой, между входящим и исходящим потоком событий и т.д.). Это подобно движению плит земной коры. Напряжения между ними рано или поздно приводят к землетрясению и снятию возникших состояний напряжения.

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

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

Управление ошибками

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

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

Рассмотрим несколько важных моментов, на которых важно фокусироваться при построении архитектуры поддержки клиента. При управлении ошибками в поле зрения попадают несколько во­просов, требующих ответа.

• Что, где, когда случилось и степень ухудшения качества? Первичная диагностика.
• На кого, на что и как сильно повлияло? Анализ влияния, на выходе которого возникает приоритет и срочность решения.
• Каковы причины? Как устранить? На выходе процесса мы должны иметь восстановленный сервис.
• Как предотвратить в будущем? Поиск ответа на этот вопрос является частью более глубокого процесса управления проблемами, на выходе которого мы должны получить обходное или постоянное решение по устранению корневой причины происходящих ошибок.

Чтобы свободно ориентироваться в процессе управления ошибками, необходимо внести ряд определений:

• событие мониторинга — формализованное событие, поступающее от систем мониторинга;
• аварийное событие — событие мониторинга, сигнализирующее об ошибке в работе системы;
• инцидент — событие, сигнализирующее об ошибке в работе системы. Источником информации об инцидентах могут быть как аварийные события, так и люди, обнаружившие ошибку;
• проблема — множество повторяющихся инцидентов, сигнализирующих о возможном существовании единой корневой причины происходящего.

В процессах поддержки сервиса клиента сущест­вуют два источника информации о состоянии качества сервисов (рис. 2):

• информация со стороны клиентов, как результат непосредственного обращения клиентов;
• информация со стороны инфраструктуры компании через системы технического монито­ринга.

Для изображения этих потоков наиболее удачный подход, пожалуй, используется в телекоммуникационной отрасли в виде двух слоев BSS и OSS — систем поддержки бизнеса и систем поддержки операций. Хотя точнее было бы сказать — поддержки клиентов и поддержки инфраструктуры.

Сами потоки информации, как мы убедились ранее, представляют собой воронки событий, сигнализирующие об ошибках сверху и снизу (рис. 3).

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

Управление собственными ошибками

Обратимся от бизнес-систем к личности. Ваше личное управлении собственными ошибками в повседневной жизни практически ничем не отличается от корпорации (рис. 4).

Люди, встречающиеся вам по жизни, — это ваши клиенты. Да и вы сами себе клиент. Превращение людей в формальных клиентов — очень тонкий вопрос. Думаю, что здесь главное — не заиграться в сервисы и не пытаться со всеми и по любому поводу заключать формальные контракты о качестве. Заключать или не заключать, например, брачный контракт — личное дело каждого. Думаю, что взаимное доверие — самый лучший контракт. Чем больше круг людей, которым вы доверяете, тем выше ваши шансы быть эффективным.

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

Если вы обнаруживаете, что это не так, вы имеете дело с завышенной или заниженной самооценкой или попросту некорректным пониманием ситуации. У вас есть повод задуматься и, подобно дайверам или пассажирам авиалайнера, выровнять «давление на мембрану» снаружи и изнутри. Для того чтобы это делать легко, старайтесь соблюдать в себе баланс между экстравертом и интровертом, а также баланс между логическим и интуитивным восприятием ситуации.

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

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