DevOps приходит в крупные ИТ-компании, готовы они к этому или нет. Проблем здесь может быть много, и мне хотелось бы поговорить об одной из них.
Возможно, это смелое заявление, но я считаю, что нынешняя организационная структура большинства служб ИТ-поддержки в корне ошибочна.
В такой ситуации успешное внедрение практик DevOps может оказаться практически невозможным.
В качестве альтернативы я хотел бы предложить новую методологию под названием Swarming, которая готова к внедрению в крупном бизнесе и идеально подходит для задач технической поддержки в эпоху DevOps.
Текущая ситуация: консерватизм трехуровневой системы техподдержки
Начать следует с краткого обзора сложившихся структур управления, лежащих в основе подавляющего большинства служб технической поддержки в организациях среднего и крупного бизнеса.Классическая техническая поддержка, построенная по принципам управления ИТ-сервисами, имеет трехуровневую иерархию.
- Уровень 1. Это служба технической поддержки (Service Desk), которая находится в прямом контакте с пользователями – обычно по телефону.
Направлен на оказание технической поддержки среднего звена по неспециализированным вопросам.
Основная задача – поддерживать стабильное качество услуг при условии, что большая часть входящих запросов будет решаться здесь, на первом уровне.
- Уровень 2. Обычно тесно связан с первым, но предполагает более глубокие общие или специальные знания и навыки сотрудников.
Специалисты второго уровня, например, могут пройти дополнительное обучение по поддержке распространенных операционных систем (таких как Microsoft Windows) или аппаратного обеспечения, получив необходимые навыки для решения более сложных задач.
- Уровень 3: Здесь представлены команды, специализирующиеся на конкретных технологиях или приложениях.
Компании, которые разрабатывают программное обеспечение самостоятельно, часто организуют отдельные группы поддержки для конкретных приложений и услуг.
Рассматриваемая методика используется практически повсеместно.
Есть несколько преимуществ, которые поощряют его использование.
- Клиентам предоставляется единый канал связи со службой технической поддержки независимо от характера проблемы.
- На рынке труда легко найти специалистов с техническими навыками, необходимыми для работы на первых двух уровнях поддержки.
Это также облегчает передачу задачи на аутсорсинг, что делается довольно часто.
- Специалисты по конкретным вопросам и направлениям изолированы от общения с клиентами и поручаются для выполнения задач, относящихся только к их областям компетенции.
Фактически во многих организациях некоторые запросы обрабатываются с помощью полностью автоматизированных сервисов, которые часто называют «нулевым уровнем».
Однако существует множество проблем, которые невозможно решить на первом уровне.
Процесс их перевода на уровни 2 и 3 называется эскалацией: 
Специалисты второго уровня обычно обрабатывают меньше запросов, чем их коллеги первого уровня, но это более сложные задачи, на решение которых в среднем уходит больше времени.
Заявки, достигающие третьего уровня (эскалированные со второго или отправленные непосредственно с первого), обычно составляют небольшую часть всех входящих запросов.
Но это сложнейшие задачи, решение которых требует высокого мастерства специалистов и значительных затрат времени.
Было предпринято множество попыток рассчитать относительную стоимость решения проблемы на каждом уровне поддержки.
Например, средняя стоимость закрытия тикета на первом уровне оценивается в $22, на втором уровне — в $62, на третьем уровне — в $85 (по данным других исследований, последняя цифра в несколько раз выше).
Проблемы с трехуровневой моделью
Критиковать такую общепринятую структуру совсем непросто.Однако движение Swarming стремилось именно к этому, взяв за основу существенные, но исправимые недостатки многоуровневой модели.
Давайте посмотрим на некоторые проблемы, влияющие на DevOps.
- Многоуровневая поддержка предполагает несколько очередей .
Поскольку первый уровень стремится как можно быстрее решить проблемы, все, что невозможно исправить сразу, ставится в очередь.
Фактический статус проблемы меняется, и она переходит из текущего в отложенный.
По сути, уровни 2 и 3 — это склады для незавершенных задач (Work in Progress), в чем проблема философии бережливого производства , который лежит в основе DevOps. Успешное внедрение DevOps в рамках Lean требует решительных шагов по сокращению незавершенной работы.
Сама по себе эта проблема является существенным сдерживающим фактором для входа DevOps в техническую поддержку.
- Многоуровневая поддержка может перекрыть путь к нужному специалисту.
DevOps выступает за повышение автономии и вовлеченности сотрудников.Сами разработчики поощряются поддерживать код. Компаниям, практикующим DevOps, удается добиться более высоких скоростей обработки запросов пользователей ( В 24 раза быстрее согласно отчету State of DevOps за 2016 год. ).
Но это бесполезно, если билету придется перепрыгнуть несколько очередей, прежде чем попасть к нужному специалисту.
Однажды, обсуждая внедрение Swarming в службе поддержки клиентов, один из менеджеров поддержки БМК (BBC) задал справедливый вопрос: «Почему мы ставим наших лучших людей в конец цепочкиЭ»
- Многоуровневая поддержка приводит к «футбольным» запросам.
При многоуровневой технической поддержке задача назначается исполнителю в одностороннем порядке.Это можно сделать на верхнем уровне или в рамках другой группы специалистов.
Исполнитель впервые видит запрос в тот момент, когда он появляется в его очереди задач.
К сожалению, тикет часто отправляют обратно, потому что либо команде нужно больше информации, либо задание оказалось неверным.
DevOps основан на сотрудничестве профессионалов: разработчиков, тестировщиков, специалистов по эксплуатации и т. д. Вертикальные и горизонтальные барьеры между подразделениями, присущие многоуровневой поддержке, а также пассивной (без участия принимающей стороны) передаче задач совершенно несовместимы.
в духе междисциплинарного взаимодействия и сотрудничества.
- Многоуровневая поддержка не решает проблему перегрузки профильных экспертов.
Хотя многоуровневая поддержка решает проблему передачи экспертам слишком простых для них вопросов, она не защищает их от перегрузки сложными задачами.Герои — бич управления ИТ-услугами (ITSM).
Это умные люди, которые, на первый взгляд, приносят ощутимую пользу организации и регулярно творят чудеса, решая сложные проблемы.
В действительности такие герои перегружены одиночными точками отказа.
Они, вольно или невольно, являются хранителями жизненно важных для организации знаний и склонны к выгоранию.
Многоуровневая поддержка, будучи линейной и изолирующей структурой, не предотвращает появление Культа Героев, а, возможно, даже поощряет его.
По мере того как традиционный бизнес смещается в сторону DevOps, мы видим сохранение моделей работы, в которых ключевые члены команды DevOps оказываются в конце цепочки эскалации.
Ущерб в сценарии DevOps, возможно, еще больше: ключевые разработчики отстранены от инноваций и вынуждены иметь дело с эскалированными и отнимающими много времени запросами пользователей.
Роение как альтернатива
«Совместные сообщества могут преодолеть профессиональные и организационные барьеры, чтобы стимулировать сотрудничество, обучение и прогресс».Концепция Swarming была предложена в конце прошлого десятилетия как новая платформа для организации технической поддержки.(Дон Тэпскотт и Энтони Д.
Уильямс, в Викиномика )
Она явно отвергает консервативную многоуровневую структуру в пользу модели сетевого взаимодействия: 
Источник: Консорциум инноваций в сфере услуг Ключевой компанией, первой внедрившей эту систему, стала Cisco. В 2008 году в документе под названием Цифровое роение она представила «Модель распределенного сотрудничества и принятия решений».
Впоследствии концепция была принята Консорциумом инноваций в сфере услуг, превратившись в Интеллектуальное роение .
Некоторые из его принципов:
- Не должно быть многоуровневых групп поддержки.
- Не должно быть эскалации из одной группы в другую.
- Задача должна быть передана непосредственно тому сотруднику, который с наибольшей вероятностью сможет ее решить.
- Лицо, принявшее обращение, несет за него ответственность до конца.
Роение на практике: пример платформы для DevOps
Роение не имеет одной четко выраженной структуры.Отчасти это связано с его новизной и, соответственно, малой распространенностью.
Однако приведенный ниже пример (основанный на методах поддержки большого числа пользователей BMC) является типичным.
Значительно улучшилась служба поддержки( что обсуждалось на выставке Servicedesk and IT Support Show в Великобритании в 2015 году ).
Роение начинается тогда, когда появляется проблема, которую невозможно решить сразу после получения запроса от пользователя.
Быстрая первичная сортировка задачи заканчивается ее отправкой в одну из двух групп (Swarms): 
Первичная сортировка в структуре Swarm Каждая группа (Swarm) — это небольшая команда, которая обрабатывает входящие запросы практически в реальном времени: Рой «Серьезность 1» (Группа реагирования первого уровня) 
- Три сотрудника работа по графику еженедельной ротации.
- Основное внимание: обеспечьте немедленный ответ, решите проблему как можно быстрее.
Ее участники координируют действия в сложных ситуациях, привлекают нужных людей и стараются организовать максимально быстрое решение критических проблем.
Этот процесс не сильно отличается от процесса реагирования на крупные инциденты, используемого в традиционной многоуровневой модели.
Однако параллельно была развернута еще одна группа, обрабатывающая гораздо большее количество запросов: Отправка рой (Диспетчерская группа) 
- Встречается каждые 60–90 минут. .
- Ориентирован на регионы и продуктовые линейки .
- Основное внимание: «хватай вишенку» (в первую очередь берись за то, что можно очень быстро исправить).
- Второстепенная задача: рассмотрение запросов перед отправкой их в группы поддержки продуктовой линейки.
Таким образом, решение пятиминутного вопроса может занять дни.
Членам этой группы буквально предлагается «выбирать вишню», не обращая внимания на проблемы, которые невозможно исправить немедленно.
Таким образом, время, затрачиваемое на решение значительного числа типов задач, может быть значительно сокращено.
Есть и дополнительная выгода.
Включение неопытных сотрудников приводит к тому, что они получают знания, которые в многоуровневой модели были бы доступны только при передаче узкоспециализированной команде.
При этом высококвалифицированные специалисты третьего уровня поддержки находятся ближе к клиенту.
Использование Dispatch Swarming приводит к быстрому решению значительного количества вопросов (в BMC их количество составляет примерно 30%), а остальные запросы попадают в очереди более традиционных групп поддержки, занимающихся отдельными линейками продуктов.
Здесь многие задачи будут знакомы и понятны обычным членам команды, поэтому их решение не должно вызвать затруднений.
При этом другая часть запросов (возможно, около 30%) может быть достойна внимания лучших специалистов поддержки вне зависимости от их структурной принадлежности.
Здесь используется третий тип группы: Рой невыполненных работ .
Рой невыполненных работ (Группа для работы с накопившимися задачами) 
- Встречается регулярно, обычно ежедневно.
- Основное внимание: решение сложных проблем, полученных от команд поддержки продуктовой линейки.
- Второстепенная задача: замена отдельных специалистов.
Они получают задания от специалистов на местах, которым теперь запрещено напрямую обращаться к экспертам индивидуально.
Вместо этого им следует отправлять задачи в соответствующий рой невыполненных работ.
Пример использования роения
Когда классическая техподдержка работает совместно с DevOps, проблемы многоуровневой модели только усиливаются.В этом случае активно накапливаются нерешенные задачи (незавершенные задачи), что, в свою очередь, ограничивает независимость и гибкость.
Такая система по сути является изолирующей.
Перечисленные проблемы противоречат философии DevOps и являются основным вызовом внедрения практик DevOps в организациях с традиционной бизнес-моделью.
Уже можно выделить следующие негативные аспекты.
- DevOps призывает разработчиков программного обеспечения взять на себя его поддержку (что иногда в народе называют «написал сам, разберись сам»).
Однако в зрелых службах поддержки крупных организаций многоуровневая структура является основным каналом, по которому проблемы пользователей доходят до инженеров.
Как мы уже знаем, барьеры между первым уровнем поддержки и командой DevOps могут привести к задержкам в решении проблем, а также к плохой первоначальной обработке запросов.
- Модель интеграции между системами продажи билетов ITSM и инструментами жизненного цикла программного обеспечения команд DevOps приводит к отсутствию ситуационной осведомленности среди сотрудников.
- Попытки создать вертикальные и горизонтальные барьеры мешают межфункциональному сотрудничеству, ключевому элементу успешного DevOps.
- Динамичное кросс-функциональное сотрудничество, позволяющее объединить в одну команду специалистов с разными навыками и областями компетенции.
- Гибкие команды против жестких иерархических структур.
- Автономия в сравнении с догматическими процессами (ключевым примером здесь является способность «выбирать вишню» при работе в составе Dispatch Swarm).
- Уменьшение количества невыполненных задач.
- Обмен навыками и опытом между специалистами в различных областях.
Заключение
«Большой бизнес не меняется медленно, потому что люди, работающие там, глупы или ненавидят технологии.DevOps бросает вызов самой сути устоявшихся консервативных способов работы, объединяя ранее изолированные роли разработчиков и специалистов по эксплуатации и пытаясь устранить укоренившиеся неэффективные практики.У них просто есть пользователи».
(Люк Кейнс, основатель и генеральный директор Puppet Labs. Configuration Management Camp, Бельгия, 2015 г.
)
Эта философия во многом (если не полностью) сформировалась в организациях нового поколения, у которых часто не было необходимости поддерживать устаревшие, но работающие системы и их пользователей.
Важно отметить, что это было сделано довольно успешно: 
Источник: Отчет о состоянии DevOps за 2016 год. Теперь DevOps добрался и до традиционных организаций, где в ходе (часто очень болезненного) процесса внедрения он столкнется с новыми проблемами.
Но для таких компаний это уже не вопрос улучшения, а необходимый шаг в борьбе за выживание.
Изменения в форме «созидательного разрушения» представляют собой постоянную и экзистенциальную угрозу для крупных компаний.
Только 12% компаний из списка Fortune 500 1955 года остались в списке в 2014 году.
ИТ-компании должны стараться использовать свежие идеи везде, где это возможно, и постоянно бросать вызов консервативным практикам.
Массовое движение начало атаку на многоуровневую модель поддержки, но прогресс в традиционном управлении ИТ-услугами идет медленно, поскольку он ограничивается несколькими дальновидными организациями.
Однако сходство основных элементов Swarming и DevOps сложно отрицать, а потому у них схожие проблемы реализации, решение которых облегчает использование обеих систем.
Таким образом, необходимо переосмыслить многоуровневую модель поддержки.
Новая методология должна использовать преимущества DevOps, сохраняя при этом функциональность и эффективность в крупных масштабах предприятия.
Думаю, что Swarming вполне может подойти на эту роль.
Теги: #DevOps #agile #techsupport #ITSM #роение
-
Нагрузочное Тестирование На Гатлинге
19 Oct, 24 -
О Борьбе С Качеством
19 Oct, 24 -
Терминаторы Комнаты: Восстание Игрушек
19 Oct, 24
