Привет, Хабр! С вами Дарина – инженер второй линии поддержки платформы или просто бывший участник второй линии UNIX team на международном ритейл-проекте. В команду в январе 2021 я пришла новичком, младшим сисадмином. На проекте проработала я больше двух лет, получила промоушн, и по итогу оказалась в группе core team. За это время не только принимала участие во всех активностях, но и неплохо выросла как системный администратор, обучила 3 стажеров, которые в последствии тоже стали системными администраторами на проекте.

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

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

Пара слов о проекте, или о чем здесь весь сыр-бор

Сам проект успешно был в нашей поддержке около 10 лет. На нем работали 2 и 3 линия поддержки платформы (Unix), 2 и 3 линия поддержи приложений, команда управления изменениями, команда управления релизами, разработчики и тестировщики, архитекторы. В общем, кого только там не было.

У нас в поддержке было 40 стран (в основном Европа, но были и несколько стран Азии – Южная Корея, Япония, Австралия и Новая Зеландия), а это около 3 000 магазинов и, соответственно, около 30 000 юнитов в поддержке команды, состоящей из 20 ребят в Казани. Помимо нас было большое количество команд из других стран, например, команда Service Desk, команда проблем-менеджмента и т. д.

Немного о буднях на поддержке

Чем мы занимались в наши трудовые будни второй линии поддержки платформы?

1. Решение инцидентов

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

   Сервис был в формате 24/7, и за рабочий день в нашем стеке решали до 300-400 инцидентов. Какие-то могли занимать небольшое количество времени – сделать обновление юнита или проверить, корректно ли подключена периферия, а для инцидентов, связанных с переустановкой, уходило гораздо больше времени, особенно если этот юнит – сервер магазина.

2. Реализация изменений – чейнджи

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

   После заполнения всех ассессментов, инсталляций изменений в тесте и получения подтверждения, что все отлично работает, мы получали зеленый свет на чейнджи в проде в соответствии со списком магазинов и датами. Изменения мы реализовывали 4 ночи в неделю, не затрагивая пятницу, субботу и воскресенье. И обычно за ночь охватывали 5-6 стран.

   Чейнджи были разные – на уровне страны (изменение конфигураций для всех магазинов разом) или конкретных магазинов (новые релизы, обновление периферии, перевод времени с зимнего на летнее и наоборот). Чейнджи на уровне магазинов выполняли по подготовленному третьей линией рабочего процесса, в случае проблем во время имплементации, на третьей линии дежурил TOC-инженер, которому следовало звонить в плохой ситуации.

3. Мониторинг почты и звонки

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

   

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

Как началась передача сервиса

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

Забегая вперед, скажу, что передача сервиса индийским коллегам началась в августе 2022 года и закончилась в июне 2023. Для этого мы поделили весь процесс на 5 этапов: выделили core team, которая состояла из компетентных и высокогогрейдовых инженеров 2 линии, составили план работы и начали с КТ- и QA-сессий по каждой теме – далее показывали, как мы решаем инциденты, смотрели, как индусы это делали самостоятельно, и на последнем этапе были менторами, которые отвечали на вопросы индусов по сложным инцидентам или чейнджам. Ниже расскажу подробнее.

5 шагов передачи сервиса

1. Подготовка базы знаний

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

2. КТ-сессии

Более полутора месяцев ежедневно мы проводили по две сессии, на которых рассказывали каждую тему из КБ. Предварительно создали core team проекта (нас было 6 человек), вместе раскидали график проведения сессий между собой, каждый выбрал темы, которые хотел бы рассказать и ушли готовиться каждый по своей части.  Каждые две недели дополнительно получали приглашения и список вопросов от коллег из Индии для сессий вопросов и ответов по пройденным темам.

Первые две недели мы рассказывали темы (каждый день по два звонка – минимум две темы, а если темы мелкие, то за одну сессию их могло быть до 4) и через 2 недели получали 25+ тем, по которым индусы отправляли нам вопросы.

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

3. Shadow

В рамках этого блока было все просто: мы попросту делали свою привычную работу и параллельно шарили свой экран индусам.

Обычно днем у нас были такие сессии на 3-4 часа, для чего мы выделяли на звонок одного инженера, который выполнял чейнджи, далее объем рос, и мы демонстрировали изменения уже в тестовых средах.

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

4. Reverse shadow

Так мы назвали блок, где индусы делали, а мы смотрели, как они это делают. Вместе с этим отвечали на их вопросы, вместе смотрели КБшки, поправляли их и делали свою работу.

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

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

5. Менторство

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

Вместо заключения, или немного о впечатлениях работы с индусами

По окончанию процесса передачи пришло осознание, что у меня никогда не было такого опыта работы (да и не работы в целом) – ведь все по началу казалось чересчур странным и непонятным.

Берем стрессовый фактор, потерю дорогого сердцу проекта, добавляем всем известный и крайне трудно дающийся индийский акцент английского языка, к которому мы привыкли только через пару месяцев, обращения друг к другу через «хей, bro!», шумный вайб индийских улиц на фоне, иные подходы к работе – и получаем серьезный межкультурный замес, адаптация к которому происходит не сразу. К примеру, нашим ребятам было в новинку, что в ответ на непрочтенное сообщение коллеги из Индии принимались сразу звонить, да еще и по нескольку раз, или на звонки могли спокойно выходить с пробежки в лесу или с кассы в супермаркете.

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

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