Третья линия поддержки YADRO (L3) — комплексная инженерная структура, состоящая из множества подразделений. Внутри L3 есть несколько центров компетенций, куда попадают самые сложные случаи — те, которые не удается решить обычным анализом логов или проверкой конфигурации. Одно из направлений работы центров — это BIOS/BMC.

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

Меня зовут Павел Гуделёв, я руковожу центром компетенций L3. В этой статье я на примерах покажу, с какими задачами мы сталкиваемся. Будьте готовы — впереди несколько инженерных детективов. А в конце статьи я перечислю навыки, нужные для этой работы, поделюсь вакансией и расскажу, как подготовиться к собеседованию.

С подготовкой статьи мне помог мой коллега Александр Старцев @staralex86, эксперт технической поддержки L3 YADRO.

Место центра компетенций в жизненном цикле инцидента

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

Про один из центров компетенций мы уже рассказывали — это департамент мультивендорной экспертизы, который помогает решать проблемы, связанные с окружением и настройками. У нас же задачи немного другие. Мы ищем причину сбоя или аномалии, описываем ее и готовим статью-инструкцию для нижестоящих уровней поддержки с описанием действий при повторном сбое. При необходимости мы передаем задачу в RnD для доработки или исправления функциональности. Для этого инженеру L3 нужно найти путь гарантированного воспроизведения ошибки. 

Одно из направлений наших задач — проблемы, связанные с BIOS/BMC. Как мы работаем с BMC? В одной из статей мой коллега поделился опытом работы с OpenBMC в компании. За десять лет многое изменилось, но суть осталась той же. 

Множество встроенных микроконтроллеров (MCU) в рамках серверной платформы выполняют свои небольшие задачи под управлением собственной прошивки (микрокода). А их работой управляет BMC: он «следит» за состоянием оборудования с помощью этих микроконтроллеров. Кроме того, со временем он обрастает новым функционалом, который появляется в ответ на требования заказчиков.

BMC в составе сервера можно представить как отдельный компьютер, встроенный в серверную платформу. Как правило, это SoC со своим процессором, памятью, периферией и собственной операционной системой Linux. Он работает независимо от основной ОС сервера, мониторит как аппаратную часть платформы, так и программно-аппаратные процессы внутри самого BMC и хоста. А также управляет питанием, взаимодействует с микроконтроллерами и их прошивками, работает с UEFI, обнаруживает ошибки в работе BMC и хоста, отслеживает состояние сетевых контроллеров и других компонентов.

Условно BMC можно разделить на две связанные составляющие. Первая — низкоуровневая часть, которая напрямую взаимодействует с аппаратными компонентами через микроконтроллеры и специализированные аппаратные интерфейсы. Вторая — Linux и работающие поверх него сервисы, которые координируют эту работу, обрабатывают события и объединяют множество разрозненных компонентов в единую систему управления сервером.

Где начинается BIOS? BIOS — «соседняя» с BMC подсистема, которая отвечает за запуск основной вычислительной системы сервера. Во время включения BMC управляет подачей питания и контролирует состояние платформы, а BIOS, выполняясь на основном процессоре, инициализирует его окружение, проверяет оборудование и готовит систему к загрузке операционной системы. Вместе они обеспечивают корректный запуск и работу сервера. 

Современный BIOS, он же UEFI, появился относительно недавно, но уже успел завоевать и сердца инженеров, и аппаратную часть большинства современных компьютеров. Больше о нем — в статье моего коллеги Сергея Пушкарёва «Внутренняя кухня UEFI: что это такое и как мы готовим его в YADRO».

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

Глубокие знания предметной области и смекалка

Работа L3-инженера в направлении BIOS/BMC редко подразумевает разбор ошибок одной подсистемы «в вакууме». Важно понимать не только то, как работают отдельные составляющие сервера — аппаратная платформа, прошивки, операционная система и ПО, — но и как они связаны между собой.

Рассмотрим на кейсе. При выключении сервера BMC регистрировал аварийную ситуацию с одним из компонентов. При этом во время работы не было никаких изъянов, и никакая другая система о проблеме не оповещала. 

Чтобы локализовать проблему, надо было определить ключевой фактор поведения системы. Оказалось, им был именно факт выключения сервера. Благодаря сравнительному анализу с аналогичным исправно работающим сервером мы нашли ошибку в конфигурационном файле одного из компонентов. Такие ошибки могут случаться, так как компонентов больше сотни и для каждого из них есть свой конфигурационный файл. А за каждым из них — влияние человеческого фактора. 

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

Умение (и стремление) разбираться в проблеме и проводить многоуровневые расследования

BIOS/BMC-инженер проводит полноценные инженерные расследования, где требуется умение основательно подходить к решению задач. Наш департамент включается там, где решить проблему перезагрузкой оборудования нельзя (иногда это сделает только хуже). Прелесть работы в направлении BIOS/BMC в центре компетенций L3 — возможности проводить полноценные расследования так, чтобы устранить, казалось бы, нерешаемый инцидент полностью и минимизировать риск его повторения в будущем.

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

Как вы думаете, что могло произойти? Поможет аналогия. Представим, что мы завели машину, нажали педаль газа и начали путь. Спустя пару минут после отправления руль у машины начал вращаться самостоятельно, панель замигала — управление вы потеряли, но машину удалось остановить. В сервисном центре сказали, что с машиной все в порядке. Но тогда почему произошла эта ситуация?

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

Для решения такой задачи необходимо хорошее понимание железа и BMC — как строится связь между объектом и субъектом. Такие случаи требуют терпения и упорства, чтобы не только исправить их, но и предотвратить в будущем.

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

Стремление искать пути и помогать развивать продукт

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

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

Изначально мы полагали, что это перегрузка шины управления I²C: BMC не успевает возвращать корректный статус по оборудованию в систему мониторинга, потому что заказчик запрашивал эти статусы очень часто. Мы пытались облегчить нагрузку на шину, временно удалив существенное количество датчиков из опроса, но это не помогло. 

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

К чему мы пришли? К sales-менеджерам. Те приходили с запросами от заказчиков по расширению функционала BMC к программистам, а они, в свою очередь, дописывали «надстройки» BMC. Для этого они разделили определенный функционал на два модуля: первый из них отвечает за сбор данных с датчиков, а второй — за выдачу нужных данных в системы мониторинга заказчиков. Первая часть сохраняет данные в кеш, а вторая — читает уже из кеша. И порой связь между модулями разрывалась и не могла автоматически восстановиться. Это как раз и создавало проблему.

Но порой продвижение идей по улучшению продукта происходит не из-за ошибок — инженеры центра компетенций инициируют идеи сами. Так получилось с системой мониторинга состояния здоровья серверов (Server Health). Раньше мы искали виновника уже после сбоя. Это затягивало закрытие инцидентов и в целом создавало много проблем. Наши инженеры предложили реализовать в BMC проактивную систему мониторинга — механизм, что мониторит определенные адреса на шине и своевременно регистрирует информацию об аномалии микроконтроллера, о которой тот сообщил по указанному адресу. Такая система позволяет предотвратить сбой всей системы либо, если это невозможно, сразу получить дополнительную информацию для диагностики и поиска причины ошибки.

Навыки эксперта центра компетенций L3

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

Откликнуться можно по ссылке → Инженер-эксперт Центра компетенций L3 в направлении BIOS/BMC.

Эта роль подойдет инженерам, которые:

• «на ты» с устройством серверного железа и любят искать первопричины инцидентов, будь то проблема с кабелем, аппаратной платформой или прошивкой;

• готовы разбираться дальше одного компонента и глубоко исследовать всю систему;

• уверенно чувствуют себя в Linux и хотят понимать, как устроен Linux внутри BMC;

• «бегло» читают код и могут проследить, где скрывается проблема;

• ясно излагают свои мысли, умеют их документировать;

• умеют взаимодействовать на уровне команд и доносить свои идеи до разработчиков так, чтобы те действительно могли «убрать ненужное, поставить нужное»;

• готовы к сложным инженерным расследованиям и хотят влиять не только на решение инцидентов, но и на развитие продукта.

Подготовка к собеседованию

Собеседования на позицию инженера-эксперта по BIOS/BMC в центр компетенций L3 мы проводим в три этапа:

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

2. Беседа с техническим специалистом в направлении BIOS/BMC: вопросы становятся ближе к повседневным задачам будущего сотрудника. Проверяем его кругозор в железе, программировании, операционных системах.

3. Встреча с директором дивизиона Сервис в YADRO: на этом этапе нам важно убедиться, что мышление и потенциал нашего будущего инженера-эксперта соответствуют ожиданиям.