Как стать автором
Обновить
70.26
Слёрм
Учебный центр для тех, кто работает в IT

Техподдержка в эпоху DevOps

Время на прочтение 10 мин
Количество просмотров 19K
Автор оригинала: Jon Hall



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


В такой ситуации успешное внедрение DevOps-практик может оказаться практически невозможным.


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


Текущая ситуация: консерватизм трехуровневой системы техподдержки


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


Классическая техподдержка, построенная согласно принципам управления ИТ-сервисами (IT Service Management), имеет трехуровневую иерархию.


  • Уровень 1. Это находящаяся в непосредственном контакте с пользователями — обычно по телефону — служба технической поддержки (Service Desk). Нацелена на предоставление техподдержки среднего уровня по неспециализированным вопросам. Основная задача — поддержание стабильного качества услуг при условии решения большинства поступающих запросов здесь же, на первом уровне.


  • Уровень 2. Обычно тесно связан с первым, но подразумевает более глубокие общие или специальные знания и навыки сотрудников. Специалисты второго уровня, например, могут проходить дополнительное обучение по поддержке распространенных операционных систем (таких как Microsoft Windows) или аппаратного обеспечения, получая необходимые навыки для решения более сложных проблем.


  • Уровень 3. Здесь находятся команды, специализирующиеся на конкретных технологиях или приложениях. Компании, самостоятельно разрабатывающие программное обеспечение, часто организуют отдельные команды поддержки для определенных приложений и сервисов.

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


  • Клиентам предоставлен единый канал общения с техподдержкой независимо от природы проблемы.


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


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

Путешествие клиентского обращения в службу поддержки может закончиться уже на первом уровне, практически не начавшись. Фактически во многих организациях часть обращений обрабатывается с помощью полностью автоматизированных сервисов, которые часто называются «нулевым уровнем» (Level zero).


Однако есть много проблем, которые не получается решить на первом уровне. Процесс их передачи на уровни 2 и 3 называется эскалацией:




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


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


Было предпринято немало попыток рассчитать сравнительную стоимость решения проблемы на каждом из уровней поддержки. В этой работе 2014 года, например, средняя стоимость закрытия тикета на первом уровне оценивается в 22 $, на втором — в 62 $, а на третьем — в 85 $ (согласно другим исследованиям последняя цифра больше в несколько раз).


Проблемы трехуровневой модели


Критиковать такую общепринятую структуру совсем непросто. Однако Swarming-движение нацелилось как раз на это, взяв за основу существенные, но исправимые недостатки многоуровневой модели. Давайте рассмотрим некоторые проблемы, затрагивающие DevOps.


  • Многоуровневая поддержка подразумевает несколько очередей. Поскольку первый уровень стремится решать проблемы максимально быстро, все, что не удалось исправить сразу, ставится в очередь. Фактический статус проблемы меняется, и она переходит из разряда текущих в отложенные. По существу уровни 2 и 3 являются складами задач, находящихся в процессе выполнения (Work in Progress), что является проблемой в рамках Lean-философии, которая лежит в основе DevOps. Успешное внедрение DevOps как части Lean требует решительных шагов по сокращению незавершенки (Work in Progress). Уже только эта проблема является существенным сдерживающим фактором прихода DevOps в техническую поддержку.


  • Многоуровневая поддержка может заблокировать путь к нужному специалисту. DevOps ратует за увеличение самостоятельности и вовлеченности сотрудников. Поощряется поддержка кода самими разработчиками. Компаниям, практикующим DevOps, удается достичь более высоких скоростей обработки обращений пользователей (согласно отчету «Состояние DevOps» (State of DevOps) за 2016 год в 24 раза быстрее). Но от этого нет никакой пользы, если тикет должен прорваться через несколько очередей, прежде чем попасть к нужному специалисту. Однажды во время обсуждения внедрения Swarming в службе поддержки пользователей один из менеджеров поддержки BMC (Би-эМ-Си) задал справедливый вопрос: «Почему мы помещаем наших лучших людей в конце цепочки?»



  • Многоуровневая поддержка приводит к «отфутболиванию» обращений. В многоуровневой техподдержке задача в одностороннем порядке назначается исполнителю. Это может быть сделано на предшествующем уровне или в другой команде специалистов. Исполнитель впервые видит заявку в том момент, когда она появляется в его очереди задач. К сожалению, тикет часто отправляется назад, поскольку либо специалистам нужна дополнительная информация, либо назначение оказалось ошибочным. DevOps основан на сотрудничестве между профессионалами: разработчиками, тестировщиками, специалистами служб эксплуатации и т. д. Вертикальные и горизонтальные барьеры между подразделениями, присущие многоуровневой поддержке, а также пассивная (без участия принимающей стороны) передача задач совершенно не соответствуют духу междисциплинарного взаимодействия и сотрудничества.



  • Многоуровневая поддержка не решает проблему перегруженности специалистов-экспертов (Subject Matter Experts). Хотя многоуровневая поддержка и решает проблему передачи экспертам слишком легких для них вопросов, она не защищает их от заваливания сложными задачами. «Герои» — настоящий бич Управления ИТ-сервисами (ITSM). Это умные люди, которые, как кажется на первый взгляд, приносят ощутимую пользу организации и регулярно творят чудеса, решая сложные проблемы. На самом деле такие герои — перегруженная работой единая точка отказа. Они вольно или невольно являются хранителями жизненно важных для организации знаний и склонны к выгоранию. Многоуровневая поддержка, будучи линейной и изолирующей структурой, не делает ничего, чтобы предотвратить культ Героя, и, пожалуй, даже поддерживает его. В процессе смещения традиционного бизнеса в сторону DevOps мы видим сохранение такой схемы работы, когда ключевые члены команды DevOps помещаются в конце цепочки эскалации. Ущерб в DevOps-сценарии, возможно, еще больший: ключевые разработчики отстраняются от новаторства и вынуждены заниматься решением эскалированных и уже потерявших время обращений пользователей.



Swarming в качестве альтернативы


«Основанные на сотрудничестве сообщества могут преодолевать профессиональные и организационные барьеры, стимулируя кооперацию, обучение и прогресс».
(Don Tapscott и Anthony D. Williams, в Wikinomics)

Концепция Swarming была предложена в конце прошлого десятилетия в качестве новой платформы для организации технической поддержки. Она в явном виде отвергает консервативную многоуровневую структуру в пользу модели сетевого взаимодействия:



Источник: Consortium for Service Innovation


Ключевой компанией, которая первой начала внедрять эту систему, была Cisco. В 2008 году в документе под названием Digital Swarming она представила «Модель распределенного сотрудничества и принятия решений». Концепция была впоследствии принята организацией Consortium for Service Innovation, трансформировавшись в Intelligent Swarming. Некоторые из ее принципов гласят:


  • Не должно быть разделенных на уровни групп поддержки.


  • Не должно быть эскалации от одной группы к другой.


  • Задача должна передаваться напрямую тому сотруднику, который наверняка сможет ее решить.


  • Человек, принявший обращение, отвечает за него до конца.

Swarming на практике: пример структуры для DevOps


У Swarming нет единственной четко определенной структуры. Отчасти это объясняется новизной и, соответственно, малой распространенностью. Однако показанный ниже пример (основанный на swarming-методах поддержки пользователей, применяемых в BMC) является типичным. Он существенно улучшил работу службы поддержки (о чем было рассказано на UK’s Servicedesk and IT Support Show в 2015).


Swarming начинается при появлении проблемы, которую невозможно решить сразу в момент получения обращения от пользователя. Быстрая первичная сортировка задачи заканчивается ее отправкой в одну из двух групп (Swarms):



Первичная сортировка в структуре Swarm


Каждая группа (Swarm) ­— это небольшая команда, которая обрабатывает поступающие заявки в режиме, близком к реальному времени:


“Severity 1” Swarm (Группа по работе с инцидентами первой степени тяжести)




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

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


Dispatch Swarm (Группа диспетчеризации)




  • Проводит встречи каждые 60–90 минут.
  • Сфокусирована на регионах и продуктовых линейках.
  • Основное внимание: «схватить вишенку» (в первую очередь браться за то, что можно исправить очень быстро).
  • Вторичная задача: проверка обращений перед их отправкой командам поддержки продуктовых линеек.

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


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


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


Использование Dispatch Swarming приводит к быстрому решению значительного числа задач (в BMC их количество составляет примерно 30%), а оставшиеся обращения попадают в очереди более привычных команд поддержки, которые занимаются отдельными линейками продуктов. Здесь многие задачи будут знакомы и понятны рядовым членам команды, поэтому их решение не должно вызывать трудностей. При этом еще одна часть обращений (возможно, около 30%) могут оказаться достойны внимания лучших специалистов службы поддержки независимо от их структурной принадлежности.


Здесь используется группа третьего типа: Backlog Swarm.




Backlog Swarm (Группа работы с накопившимися задачами)




  • Проводит встречи регулярно, обычно ежедневно.
  • Основное внимание: решение сложных задач, полученных от команд поддержки продуктовых линеек.
  • Вторичная задача: замена одиночных экспертов.

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


Пример использования Swarming


При работе классической техподдержки в связке с DevOps проблемы многоуровневой модели только усиливаются. В этом случае активно накапливаются нерешенные задачи (Work in Progress backlogs), что, в свою очередь, ограничивает самостоятельность и гибкость. Такая система по сути своей является изолирующей. Перечисленные проблемы противоречат философии DevOps и являются главным вызовом на пути внедрения DevOps-практик в организациях с традиционной моделью ведения бизнеса.


Уже сейчас можно выделить следующие негативные моменты.


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


  • Модель интеграции типа «выкинь это за забор», применяемая между ITSM-системами приема заявок и инструментами обеспечения жизненного цикла программного обеспечения DevOps-команд, приводит к недостатку ситуационной осведомленности сотрудников.


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

Напротив, концепция Swarming построена во многом на тех же принципах, которые находятся в основе успеха DevOps.


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


  • Гибкие команды в противовес косным иерархическим структурам.


  • Самостоятельность в противовес догматичным процессам (ключевым примером здесь является возможность «хватать вишенки», работая в составе Dispatch Swarm).


  • Уменьшение количества ожидающих решения задач.


  • Обмен навыками и опытом между специалистами различного профиля.

Заключение


«Большой бизнес не потому меняется медленно, что там работают глупые или ненавидящие технологии люди. Просто у них есть пользователи».
(Luke Kaines, основатель и генеральный директор, Puppet Labs. Configuration Management Camp, Бельгия, 2015)

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


Важно отметить, что это было сделано весьма успешно:



Источник: Отчет о состоянии Devops за 2016 год


Теперь DevOps добрался до традиционных организаций, где в процессе внедрения (зачастую очень болезненного) ему предстоит столкнуться с новыми вызовами. Но для таких компаний это уже не вопрос улучшения, а необходимый шаг в борьбе за выживание. Изменения в форме «творческого разрушения» являются постоянной и реальной угрозой существованию крупных компаний. Только 12% списка Fortune 500 от 1955 года оставались в нем и в 2014.


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


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


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

Теги:
Хабы:
+15
Комментарии 19
Комментарии Комментарии 19

Публикации

Информация

Сайт
slurm.io
Дата регистрации
Дата основания
Численность
51–100 человек
Местоположение
Россия
Представитель
Антон Скобин