Настольная книга эксплуататора. Всё, что вы хотели знать о повседневной жизни датацентров, но боялись спросить - Алексей Жумыкин

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

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

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

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

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

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

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

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

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

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

Заполнить оперативный отчет об инциденте. В отличие от предыдущего способа коммуникации, когда важно максимально быстро передать минимальное количество информации, необходимое коллегам из других отделов для их работы, следующим шагом дежурный должен собрать как можно больше информации о текущем состоянии объекта и системы, на которой произошла неисправность. Эта информация понадобится для дальнейшего разбора случившегося. Проще всего такой сбор осуществлять с помощью заранее подготовленной формы с вопросами, на которые дежурный должен ответить, приложив релевантную информацию. Такая форма, например, может сразу направляться письмом на рассылку всех вовлеченных специалистов, а также создавать тикет для разбора всех подробностей инцидента – то, что обычно в мире называют Root Cause Analysis (RCA[28]).

Разобрать инцидент. После того как событие зарегистрировано и первоначальный набор информации о нем собран, важно разобрать его в команде специалистов. Для этого следует разработать форму RCA, которая в итоге должна отвечать на следующие вопросы:

• Из-за чего произошел инцидент?

• Что было сделано / нужно сделать, чтобы устранить последствия этого инцидента?

• Что нужно сделать, чтобы подобный инцидент не повторялся в дальнейшем?

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

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

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

Кроме уже перечисленных отчетов по каждому RCA отмечу следующий статистический уровень: сколько инцидентов случилось в период, на каких площадках и на каких системах. Такая статистика может, например, показать, что у нас подавляющее число проблем происходит с ИБП. В таком случае можно поставить вопрос о замене ИБП на более надежную модель либо, если замена не вариант, о наращивании компетенции в обслуживании и ремонте.

Еще один очевидный отчет – так называемый Availability Report, показывающий, как случившиеся инциденты повлияли на фактическую доступность сервиса. Форматов и применений этому отчету можно найти много, а по сути, это просто краткое перечисление произошедшего с учетом фактического времени, в течение которого сервис не предоставлялся, либо произошло снижение уровня резервирования.

Глава 11

Работа с проектами

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

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