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

Ребята из BMC(пилят ITSM Remedy), Cisco, Microsoft заявляют, что есть достойная альтернатива.
Прежде чем погружаться в новую структуру, давайте выясним какие недостатки есть у классики.

Но сначало по верхам рассмотрим, что из себя представляет трехуровневая структура:

Уровень 1: Первая линия, непосредственно принимает входящие обращения заказчиков.

Уровень 2: Обладает более продвинутыми навыками или специализированными знаниями.

Уровень 3: Специализированные группы поддержки, сосредоточенные на конкретных технологиях и приложениях.

Так как DevOps практики проникли и проникают во все IT организации, трехуровневая иерархия вставляет палки в колеса, а именно:
1️⃣ Cоздает несколько очередей
Любая заявка, которая не решается на первой линии, создает беклог для L2 или L3.

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

2️⃣Разделённая на уровни поддержка мешает корректной маршрутизации
Заявка, которая может быть решена только специалистами L2 или L3, обязательно проходит через L1.
Часто бывает, что заявка возвращается назад, либо для предоставления уточнений, либо потому, что маршрутизация была выполнена не по назначению. Начинается "футбол".

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

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

На самом же деле, герой – это перегруженная, подверженная сбоям точка отказа, преднамеренно или непреднамеренно действующая как хранитель эксклюзивных знаний, которые следовало бы распространить. Многоуровневая поддержка, являющаяся линейной и разделённой структурой, не делает ничего, чтобы предотвратить "культ Героя". Скорее, даже усиливает его.

С точки зрения подхода DevOps ключевые инженеры при этом не участвуют в развитии, а занимаются “тушением пожаров”, эскалированных им с других линий поддержки.

В следующем посте рассмотрим, как альтернативная структура решает проблемы выше.