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

[dmitriylyalyuev]

Мне одному кажется, что DevOps — это несколько не про саппорт?
Или я плохо читал DevOps Cookbook?

DevOps постоянно "варится" в разработке вместе с девелоперами и у них нет необходимости обращаться в "техподдержку". Или это уже не DevOps.

Я не прав?

[foxmuldercp]

Я, честно, тоже не очень понял, зачем этот термин тут упоминается в каждом абзаце.
Не думаю, что смысл статьи сильно изменится, если слово "девопс" из неё убрать в принципе.
Говорю как сотрудник, выросший из саппорта крупнейших украинских хостеров до хостмастера за 5+ лет стажа

[VolCh]

Тут, скорее, речь про то, что девопсы и разработчики вовлекаются чуть ли не в первую линию поддержки.

[EuLeEr]

Полагаю, разговор идет о том из-за отсутствия оперативной поставки информации о логических ошибках, которые зачастую видят пользователи, в традиционной схеме обновления программного обеспечения осуществляются по схеме "один раз в неделю по четвергам". Связано это с тем, что ПО обновляется, а потом, в течении недели идут патчи к введенным фичам.
DevOps же — это устойчивая поставка обновлений ПО до нескольких раз в день. Поэтому есть сильное желание также получать информацию о прекращении работы фичи возможно более оперативней. Чтобы одни логические ошибки не наслаивались на другие.
А в общем да, разговор идет скорее о FastSupport ;-)

[denisssko]

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

[qwertyRu]

хотелось бы глянуть на цену решения тикета

[vanxant]

Как-то не очень чётко написано.
С одной стороны, никаких уровней и передач тикетов между уровнями.
С другой

Swarming начинается при появлении проблемы, которую невозможно решить сразу в момент получения обращения от пользователя

Ну так задача первого уровня саппорта и есть — попытаться решить сразу в момент получения обращения. А для начала вообще попытаться описать проблему из неразборчивого потока «мать-перемать-ничего-не-работает» от юзера.

[Aivendil]

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

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

[PapaPadlo]

Проблема в том, что опытному инженерц быстро надоест аникействовать и он будет брать только сложные тикеты. И трубку первый не будет брать, потому что у него за плечами (допустим) 15 лет опыта по zSeries и он откровенно не умеет принять звонок по поводу неработающего интерфейса оплаты кредиткой от гостя с юга. То есть получится та же самая 3х уровневая поддержка, только никто об этом не будет знать, потому что менеджеры отрапортуют что у них теперь swarm. Кстати, получать он будет как зеленый студент в такой команде?

[Ordinatus]

Ну а что насчет тулинга под новую методологию?
Попробовал поискать — ничего нет даже стартап уровня

[aGGre55or]

Swarming означает роение. Основное отличие от иерархии в том что рой ни за что не отвечает, но всегда занят. Любая иерархия может быть сведена к роению. Задача гарантированно окажется у тех 2-3 сотрудников которые работают за весь рой. Эта технология была разработана ещё в СССР и продана капиталистам под видом know how. Сегодня мы видим обратный процесс: технологию пытаются втюхать уже нам.

[Aivendil]

Задача гарантированно окажется у тех 2-3 сотрудников которые работают за весь рой.

— это шикарно. И именно так и будет, к сожалению.

[erthad]

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

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

[VolCh]

Троих по схемам типа два в день, два в ночь на весь мир.

[erthad]

Не совсем ясно, как follow the sun в таком контексте делать.
В каждом регионе держать как минимум по 1 специалисту высокого уровня (и что более сложно — всех уровней допуска!)?

Индусам аутсорсить L1 удобно не только потому что они дешевые, но и потому что не нужно открывать представительства своей компании по многим странам — всем часовым поясам.

[antirek]

В целом, проблема такая — есть классные спецы, но они за первой линией поддержки. Как следствие — они не видят всего многообразия проблем клиентов.

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

[Sergey-S-Kovalev]

У Вас какой то странный подход. Брать высококлассного спеца, чтобы он видел все заявки, и может быть он увидит какую то закономерность и починит то, что уменьшит количество заявок. Кхм. А отчетность в системах сервисдеска для чего? Считать закрытые инциденты и среднее время отклика/решения что бы рулить KPI?

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

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

[erthad]

Так аналитики в команду backlog swarm тоже входят.
Эту группу здесь почти все прочитавшие проглядели, а это, по-моему, чуть ли не основная группа здесь.

[Scf]

Известная тема еще по менеджменту разработки ПО. Можно создавать функциональные команды, которые специализируются на конкретных видах работ (дешевле), а можно проектные команды (дороже, но эффективнее).

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