Всем привет, меня зовут Артём Смирнов. Я руковожу департаментом мультивендорных решений и экспертизы в YADRO.
Оценив потребности заказчиков, мы создали специальное подразделение нашего сервиса — департамент мультивендорных решений. Каждая задача сотрудника нашей команды — это настоящее исследование. Рассказываю, чем занимается наш департамент, как строится работа и кого берут решать сложные сервисные и архитектурные задачи.
Почему появился департамент
Дивизион Сервис YADRO обслуживает более 100 тысяч единиц IT-оборудования — от систем хранения данных до базовых станций — и более 150 тысяч персональных устройств. Сервисные инженеры и сотрудники техподдержки работают с разными инфраструктурами и SLA, в разных географических широтах и климатах. Серверы, СХД, коммутаторы YADRO работают и в ЦОД банков, и в ДИТ городской инфраструктуры.
Сервис и поддержка работы оборудования — неотъемлемая часть работы любого вендора. И здесь у нас существует классическая иерархия линий поддержки:
L0, она же служба диспетчеров и координаторов, — принимает и обрабатывает заявки.
L1 — команда квалификаторов и выездных инженеров. Они занимаются устранением базовых неполадок и типовых проблем, решение которых описано в базе знаний по продуктам.
L2 — занимается более сложными техническими вопросами, помогает первой линии и принимает решение об эскалации на третью линию.
L3 у нас делится на две части: одна — отвечает за решение самых сложных инцидентов в рамках наших продуктов, а другая — решает проблемы, которые связаны с окружением и настройками. Это и есть наш департамент.
Все линии поддержки по-своему помогают корректно эксплуатировать, обслуживать оборудование YADRO, решать проблемы, связанные с ним напрямую. Но на этом мир инфраструктуры наших клиентов не заканчивается. Он комплексный: в архитектуре сервисов особо крупных клиентов могут быть задействованы до десятка различных вендоров. Каждый узел, связывающий разное ПО и оборудование, — потенциальная точка отказа.
Мы решили, что не хотим оставлять наших клиентов, порой потенциальных, без поддержки в этом мультивендорном мире. Так в нашем сервисе появился новый департамент — мультивендорных решений и экспертизы.
Почему мультивендорных? Наши сервисные инженеры и архитекторы работают с продуктами других вендоров, не только с YADRO. Так, например, мы сотрудничаем с производителями ПО и вместе решаем сложные задачи.
Когда меня спрашивают об основной цели департамента, я отвечаю: «Чтобы клиенту было хорошо». Но для публикации на Хабре такое описание точно не подойдет, поэтому расскажу конкретнее о функционале команды. Для знакомства я бы выделил три крупных направления работы.
Проектирование комплексной мультивендорной архитектуры сервисов
Инженеры нашего департамента проектируют архитектуру высоконагруженных и критически важных сервисов по запросу. При этом нам не обязательно, чтобы компания, задачу которой мы решаем, уже пользовалась продуктами YADRO.
Несколько сценариев задач из практики департамента:
В компании заказчика появилась новая команда обслуживания информационных систем. Она пока не до конца понимает, из чего состоят ИС, за которые теперь отвечает. Мы беремся исследовать инфраструктурную «картину» сервисов, предоставляем CIO и его команде информацию о составе систем, ресурсах, которые они потребляют, о том насколько они оптимально работают. Имеются ли потенциальные проблемные места: например, при внештатных ситуациях или пиковой нагрузке. Мы расписываем дорожную карту по улучшениям и масштабированию систем.
У потенциального заказчика есть конкретная задача — допустим, уменьшить расход вычислительных и дисковых ресурсов — и есть текущий пул оборудования. Какая-то его часть неактуальна для этой задачи. Например, диски уже устарели, или вендор ушел с рынка — рискованно держать его оборудование в парке. Чтобы решить задачу, мы описываем, что и как можно обновить, заменить, оптимизировать или полностью исключить из инфраструктуры.
Заказчику необходимо обеспечение отказоустойчивости текущих систем. Для этого мы проверяем, насколько регламенты по переключениям на резервный контур описывают потенциальные риски. Мы проводим серию интервью, составляем матрицу рисков и формируем перечень необходимых процедурных и технических улучшений для обеспечения непрерывности работы критически важных информационных систем.
Вы спросите, а зачем нам тратить время на тех, кто еще не стал клиентом YADRO? Помогая решать задачи потенциальных заказчиков, мы улучшаем уровень развития IT-систем. Для нас это больше, чем просто инвестиция нашего времени — это прекрасная возможность делиться нашим опытом и улучшать сервисы, которыми мы сами ежедневно пользуемся.
Масштабирование архитектуры
Следующее направление работы — это обслуживание текущих потребностей заказчиков. Возьмем банковский процессинг и сезонные нагрузки. Например, в преддверии Нового года банкам важно подготовиться к резкому росту трафика, когда много клиентов совершает все больше покупок. Даже незначительный простой или задержки в работе системы ведет к репутационным и финансовым последствиям. Поэтому мы отдельно проверяем критически важные элементы инфраструктуры на предмет потенциальных проблем, которые могут проявиться в момент высокой нагрузки, но не проявляются сейчас.
Отдельным шагом проводим ретроспективу по предыдущим периодам высоких нагрузок, оцениваем запас по вычислительным ресурсам. Стоит ли что-то предпринять, чтобы последующий период прошел без проблем? Для этого мы отдельно встречаемся с заказчиками, уточняем планируемое увеличение количества клиентов или нагрузки. Далее проводим оценку текущих технических средств на соответствие, проверяем запас вычислительных ресурсов, подсистем хранения и пропускной способности сетей передачи данных.
Зачастую мы сталкиваемся с ситуациями, когда прирост нагрузки в незначительные 7-10% может привести к пересмотру всей архитектуры. Не все системы могут без ограничений масштабироваться вертикально, а горизонтальное масштабирование приводит к дополнительным накладным расходам для обеспечения необходимой производительности.
Планирование и сопровождение миграций
К нам приходят и компании, которые хотят перейти на наше оборудование. Тогда мы готовим дорожную карту миграции и оцениваем, что именно получится реализовать, интегрировать и через какое время.
Мы также помогаем в интеграции. Но наша задача здесь — не только сама настройка оборудования и процессы по внедрению. Команда подключается заранее, чтобы обсудить задачи перехода на наше оборудование. Мы проводим предварительное обследование необходимой для миграции инфраструктуры, текущей нагрузки — загрузки процессорных ресурсов, используемой памяти, утилизации каналов передачи данных, распределения данных по дисковых массивам — и используемых технологий. На основе этого вырабатываем поэтапный план перехода каждой информационной системы, чтобы минимизировать даунтаймы и не допустить влияния на доступность сервисов.
Эскалация проблем заказчиков, связанных с оборудованием других вендоров
Продукты YADRO задействованы в сервисах, которыми мы сами пользуемся каждый день: в финтехе, телекоммуникациях, промышленности, транспорте. Ошибка в инфраструктуре заказчика напрямую влияет на нашу жизнь — не просто в виде открытого инцидента, мы, как и любые другие пользователи, не сможем сделать онлайн-перевод или отправить сообщение в мессенджере.
Команда департамента обрабатывает сложные инциденты, которые, допустим, могут возникнуть на стыке софта и оборудования (в связке YADRO и другого оборудования) или из-за предустановленных настроек. Когда L2-инженеры понимают, что причина проблемы находится вне нашего оборудования, они эскалируют задачу на наш департамент.
Решение подобных проблем для заказчиков часто заканчивается «футболом». Иной вендор оборудования может сказать, что проблема не на его стороне и надо обратиться к производителю ПО. Последний, в свою очередь, может ответить, что проблема не в ПО и надо обратиться к поставщику оборудования.
YADRO как доверенный технологический партнер своих заказчиков не может себе позволить играть в такой «футбол». Чтобы это были не просто слова, мы взаимодействуем с большим количеством ISV-партнеров. И, там где это возможно, совместно решаем проблему, минимально вовлекая в процесс заказчика. К клиенту возвращаемся уже с обходным решением и предоставляем план, как избежать подобных ситуаций в будущем.
Например, к нам однажды обратился производитель одной из систем виртуализации. Они проводили тестирование системы у регионального заказчика, и у него возникала проблема с производительностью виртуальных машин. Еще до обращения к нам заказчика мы оперативно развернули совместный стенд в лаборатории с теми же настройками, что и на стенде заказчика, и определили проблемные места. Это позволило нам решить проблему заказчика на стенде и сэкономить его время на открытие двух инцидентов в двух разных сервисных службах.
Регулярное общение с ISV-партнерами позволяет и им, и нам заранее узнавать о потенциальных проблемах, еще до того, как заказчик завел сервисный инцидент.
Лаборатории для воспроизведения клиентских инсталляций
Расскажу про ранее упомянутые лаборатории: таких у нас десяток. Для нас они — один из инструментов быстрой и эффективной работы с задачами заказчиков. Например:
нам нужно воспроизвести определенную связку ПО и железа у заказчика, чтобы проверить работу оборудования под нагрузкой;
точно оценить результаты нагрузочного тестирования;
«проиграть» инцидент, с которым мог столкнуться клиент в мультивендорной архитектуре;
проверить процесс перехода с одного оборудования на другое.
Некоторые лабораторные стенды в точности повторяют архитектуру сервисов заказчиков. Это позволяет оперативно имитировать проблемы и разбираться с ними без доступа к самой системе.
С кем сотрудничает департамент мультивендорной экспертизы
Мы работаем с большим количеством клиентов и знаем особенности технологий и требуемой технической реализации, которые используются в сложных архитектурах. Поэтому регулярно общаемся внутри YADRO с департаментами разработки и продуктовым офисом по поводу применимости и необходимости той или иной технологии. Здесь нам помогает обширный «полевой» опыт: регулярно участвуем во внутренних тестированиях новых продуктов и программных релизов. Наша задача — быть тем самым клиентом, который будет работать с новым оборудованием или принимать новый релиз.
Так, эксперты департамента регулярно принимают участие в нагрузочных тестах. Поэтому мы собрали большое количество профилей нагрузки на блочные устройства, которые подключаются с систем хранения данных семейства TATLIN. Этими профилями и методиками тестирования мы делимся с департаментом разработки и продуктовым офисом, так как наши тестовые сценарии отражают потенциальное применение продуктов.
Или мы решаем какой-то комплексный инцидент, в котором задействовано большое количество программных продуктов. Для нас это опыт, который мы также передаем внутри компании всем заинтересованным отделам.
Один из примеров взаимодействия дивизиона Сервис и продуктовых команд — это serviceability, когда о сервисном обслуживании IT-оборудования думают еще на этапе его проектирования. Как это устроено на практике, читайте в статье Александра Чурикова.
Кто становится инженером департамента
Все знать невозможно. Так или иначе у специалистов департамента есть базовое направление экспертизы: в сетевом оборудовании, в СХД, в высокопроизводительных кластерах или в редких закрытых операционных системах. Мы знаем сильные стороны каждого сотрудника. Для распределения задач у нас есть матрица компетенций, по которой мы можем собирать «виртуальные команды» от 1 до 20 человек под конкретный проект.
Чем комплекснее проект, тем больше разных компетенций требуется. Они могут включать в себя и построение сложных многокомпонентных архитектур, и опыт промышленной эксплуатации высоконагруженных систем, и подход к выстраиванию процессов и регламентов.
Инженеры департамента постоянно растут в уровне знаний о сложных архитектурах и информационных системах. В том числе благодаря обмену опытом в команде: всегда можно пообщаться с коллегами, получить совет. Во многом сила департамента — в самоорганизации. У наших инженеров нет ограничения «вот это мое, а вот тут моя ответственность уже заканчивается». Именно поэтому специалисты успешно растут в команде, ведь они открыты к новому опыту и знаниям.
Можно решить, что инженеры департамента — исключительно эксперты с более чем двадцатилетним опытом в мультивендорной индустрии. Но это не так: в команде есть и стажеры, которые не только разбираются с инцидентами, но и решают комплексные задачи.
Один из таких «стажерских» проектов — подготовка платформы сервисного инструментария «Гегелло», который позволяет работать с диагностической информацией с различного оборудования, не скачивая ее себе на ноутбук. На платформе есть визуализация как самого оборудования, так и логических связей и сетевой топологии. Это позволяет в короткие сроки определить проблемные места. Также мы можем объединять диагностическую информацию нескольких устройств в одном месте и выстроить таймлайн ошибок: так мы отслеживаем, когда мог начаться инцидент и что стало его отправной точкой
Стажеры разработали интерфейс и написали скрипты под менторством старших коллег: они перенимали опыт, узнавали про работу со сложным оборудованием и устройство комплексных архитектур.
У стажеров не было ограничений, какой язык программирования использовать. В целом, мы всегда стараемся не ограничивать наших инженеров областями ответственности, а наоборот, показываем весь спектр задач и даем выбирать. Так и начинающим, и продолжающим специалистам проще раскрывать свои таланты.
Хотите узнать больше про работу департамента и стать по-настоящему востребованным и многофункциональным сервисным специалистом? Приходите к нам в команду, сейчас в дивизионе Сервис открыты вакансии:
Инженер-эксперт технической поддержки L3 – BIOS/BMC
Инженер по серверному оборудованию Центра компетенций (L3)
