Как мы сервис крупного проекта коллегам из Индии передавали
Привет, Хабр! С вами Дарина — инженер второй линии поддержки платформы или просто бывший участник второй линии UNIX team на международном ритейл-проекте. В команду в январе 2021 я пришла новичком, младшим сисадмином UNIX-систем. На проекте проработала я больше двух лет, получила промоушн, и по итогу оказалась в группе core team. За это время не только принимала участие во всех активностях, но и неплохо выросла как системный администратор, обучила 3 стажеров, которые в последствии тоже стали системными администраторами на проекте.
Скоуп задач был достаточно большим, и в любой момент могла появиться срочная таска — например, в стор пришел технишн, чтобы поменять жесткий диск, и с нашей стороны нужно было убедиться, что все сделано верно, и начать процесс реинсталла юнита. Но сама работа была настолько интересной, что все было в кайф. *вспомнила и прослезилась*
Одним из таких проектов стал последний и самый, пожалуй, крупный, о котором и пойдет речь в этой статье. Так случилось, что, работая ранее в качестве ключевого бизнес-партнера одной японской ИТ-корпорации, проекты которой мы выполняли на аутсорсе, после известных событий начала 2022 года нам пришлось полностью отделиться от компании и начать работу целиком с чистого листа. А ведь сервис нужно было кому-то передать во всем его объеме — и таким адресатом стали наши коллеги из Индии.
Пара слов о проекте, или о чем здесь весь сыр-бор
Сам проект успешно был в нашей поддержке нашей около 10 лет. На нем работали 2 и 3 линия поддержки платформы (Unix team), 2 и 3 линия поддержи приложений, change management team, release management team, разработчики и тестировщики, архитекторы. В общем, кого только там не было.
У нас в поддержке было 40 стран (в основном Европа, но были и несколько стран Азии — Южная Корея, Япония, Австралия и Новая Зеландия), а это около 3 000 магазинов и, соответственно, около 30 000 юнитов в поддержке команды, состоящей из 20 ребят в Казани. Помимо нас было большое количество команд из других стран, например, Service Desk DBA team, problem management team и т. д.
Немного о буднях на поддержке
Чем мы занимались в наши трудовые будни второй линии поддержки платформы?
Решение инцидентов
Большая часть работы была завязана на решении инцидентов, мы получали их в ServiceNow и решали в соответствии со сроками SLA. Естественно, вели статистику по количеству инцидентов за день, неделю и месяц, по странам (чтобы понимать, что чаще всего ломается в конкретной стране или, например, был всплеск инцидентов после чейнджа), также была статистика по юнитам (смотрели, что чаще ломается кассы, компы, сканнеры и др.).
Сервис был в формате 24/7, и за рабочий день в нашем стеке решали до 300–400 инцов. Какие-то могли занимать небольшое количество времени — сделать рефреш юнита или проверить, корректно ли подключена периферия, а для инцидентов, связанных с реинсталлом юнитов, уходило гораздо больше времени, особенно если этот юнит — сервер магазина.
Реализация изменений — чейнджи
Помимо дневных активностей, мы выполняли работу в ночное время, после закрытия магазинов. Если днем мы катали чейнджи в тестовых средах, то ночью мы делали это уже в проде.
После заполнения всех ассессментов, инсталляций изменений в тесте и получения подтверждения, что все отлично работает, мы получали зеленый свет на чейнджи в проде в соответствии со списком магазинов и датами. Чейнджи мы делали 4 ночи в неделю, не затрагивая пятницу, субботу и воскресенье. И обычно за ночь охватывали 5–6 стран.
Чейнджи были разные — на уровне страны (изменение конфигураций для всех магазинов разом) или конкретных магазинов (новые релизы, обновление периферии, перевод времени с зимнего на летнее и наоборот). Чейнджи на уровне магазинов выполняли по подготовленному третьей линией воркфлоу и, в случае проблем во время имплементации, на третьей линии дежурил TOC-инженер, которому следовало звонить в плохой ситуации.
Мониторинг почты и звонки
Пожалуй, самое стандартное. На почту мы получали информацию от техников, которым требовалась наша помощь, когда они находились непосредственно в магазине, письма от других команд, или запросы на выполнение чейнджей в тестовых средах или же обсуждение проблем после чейндже в проде, приглашение на звонки и другие срочные таски.
Также ежедневно у нас были звонки с представителями других команд — например, с командой по открытию новых магазинов, где обсуждали будущие открытия, предварительные шаги с нашей стороны или какие-то проблемы с текущими открытиями, или звонки с командой Service Desk, где решались вопросы по конкретным инцидентам.
Как началась передача сервиса
Примерно в июле 2022 мы узнали, что скоро начнется процесс передачи нашего проекта, так как нашли команду, которая будет у нас этот сервис перенимать. Конечно, по очевидным причинам еще с марта мы знали, что этот день рано или поздно настанет, и однажды нам придется начать процесс передачи и попрощаться с проектом. Но оказалось, что в душе мы не были к этому готовы, и всем стало максимально грустно от осознания, что процесс уже запущен.
Забегая вперед, скажу, что передача сервиса индийским коллегам началась в августе 2022 года и закончилась в июне 2023. Для этого мы поделили весь процесс на 5 этапов: выделили core team, которая состояла из компетентных и высокогогрейдовых инженеров 2 линии, составили план работы и начали с КТ- и QA-сессий по каждой теме — далее показывали, как мы решаем инциденты, смотрели, как индусы это делали самостоятельно, и на последнем этапе были менторами, которые отвечали на вопросы индусов по сложным инцам или чейнджам. Ниже расскажу подробнее.
5 шагов передачи сервиса
Подготовка базы знаний
Первые две недели мы проверяли всю нашу базу знаний, максимально обновляли ее и вносили новые статьи, так же часть статей переводили на английский язык. По итогу наша база знаний вышла на 700 страниц.
КТ-сессии
1,5+ месяца ежедневно мы проводили по две сессии, на которых рассказывали каждую тему из КБ. Предварительно создали core team проекта (нас было 6 человек), вместе раскидали график проведения сессий между собой, каждый выбрал темы, которые хотел бы рассказать и ушли готовиться каждый по своей части. Каждые две недели дополнительно получали приглашения и список вопросов от коллег из Индии для QA-сессий по пройденным темам.
Первые две недели мы рассказывали темы (каждый день по два звонка — минимум две темы, а если темы мелкие, то за одну сессию их могло быть до 4) и через 2 недели получали 25+ тем, по которым индусы отправляли нам вопросы.
Часть вопросов были покрыты статьями из КБ, и мы просто указывали нужный топик, что нужно прочитать, чтобы получить ответ на вопрос, часть могли закрыть тем, что отправить индусов пересматривать КТ сессию по теме и оставалась часть вопросов, на которые мы отвечали на звонке.
Shadow
В рамках этого блока было все просто: мы попросту делали свою привычную работу и параллельно шарили свой экран индусам.
Обычно днем у нас были такие сессии на 3–4 часа, для чего мы выделяли на звонок одного инженера, который выполнял чейнджи, далее скоуп рос, и мы показывали чейнджи уже в тестовых средах.
Со временем у нас появились такие ночные звонки, на которых мы так же показывали работу над инцидентами и чейнджами в проде. Особенно важно было показать, как взаимодействовать с другими командами, предварительные шаги, само выполнение чейнджа, что делать в экстренной ситуации, если что то пошло не так, что такое роллбэк и когда/как его следует делать, форматы писем заказчику после активности. Сессии были максимально продуктивными, так как на каждый шаг был вопрос о действиях с нашей стороны.
Reverse shadow
Так мы назвали блок, где индусы делали, а мы смотрели, как они это делают. Вместе с этим отвечали на их вопросы, вместе смотрели КБшки, поправляли их и делали свою работу.
Расписание таких сессий было такое же, как и в предыдущем блоке. С нашей стороны был инженер, который сидел с ними на звонке днем, а другой делал то же самое ночью. Но если ночью мы смотрели, как коллеги из Индии делали чейнджи в проде, то звонки могли растянуться на большее количество часов, ведь важно было довести активность до конца. Все это происходило во время звонка, где они шарили экран, и на первом этапе делали инциденты по выделенным странам, далее переходили к такому же формату выполнения чейнджей.
На этом этапе мы начали процесс передачи некоторых стран в их поддержку. Процесс передачи начался с 3 стран, а полностью 40 стран мы передали через полтора месяца. Такие звонки были необходимы и важны, так как с каждой новой страной, которая пополнялась в списке поддержки Индии, были новые специфики, с которыми индусы еще не сталкивались на практике.
Менторство
С января и до июня этого года мы остались на ролях менторов. У нас уже не было стран в поддержке, и мы помогали индусам лишь в решении их собственных вопросов. У нас был чат и специально подготовленный шаблон для обращения (номер инцидента, какими статьями пользовались, что уже успели сделать и какой непосредственно вопрос к нам). Каждый день были совместные дэйли, звонки с заказчиком и другими командами, так как мы выступали экспертами в некоторых вопросах.
Вместо заключения, или немного о впечатлениях работы с индусами
По окончанию процесса передачи пришло осознание, что у меня никогда не было такого опыта работы (да и не работы в целом) — ведь все по началу казалось чересчур странным и непонятным.
Берем стрессовый фактор, потерю дорогого сердцу проекта, добавляем всем известный и крайне трудно дающийся индийский акцент английского языка, к которому мы привыкли только через пару месяцев, обращения друг к другу через «хей, bro!», шумный вайб индийских улиц на фоне, иные подходы к работе — и получаем серьезный межкультурный замес, адаптация к которому происходит не сразу. К примеру, нашим ребятам было в новинку, что в ответ на непрочтенное сообщение коллеги из Индии принимались сразу звонить, да еще и по нескольку раз, или на звонки могли спокойно выходить с пробежки в лесу или с кассы в супермаркете.
Но мы справились — благодаря нашей команде, проектным и сервисным менеджерам удалось не только провести передачу максимально безболезненно, но и получить большую благодарность от заказчика за наши старания.
Несмотря на страх и напряжение в моменте, сейчас я с улыбкой вспоминаю это время. И также иногда могу потосковать по дням работы на любимом проекте. На своем первом проекте в роли системного администратора, который научил меня многому и познакомил с миром IT.
