Руководство по колокации для вашего первого физического сервера

Почему один сервер всё ещё нуждается в runbook

Один сервер в колокации выглядит просто на бумаге. Одна коробка, один счёт, меньшие ежемесячные расходы. А потом в 2:10 ночи выходит диск, учётная запись VPN принадлежит бывшему контрагенту, единственный админ в полёте, и дата‑центр задаёт простой вопрос: "Что нам делать?" Дешёвое железо перестаёт быть дешёвым в тот момент, когда некому ответить.

Большинство простоев затягиваются по одной скучной причине: никто не отвечает за следующий шаг. Кто‑то имеет root‑доступ, но не может одобрить удалённые работы. Другой может одобрить работы, но не знает расположение сервера или номера запасных деталей. Оповещения уходят в общий почтовый ящик, который никто не смотрит вне рабочего времени. Можно потерять 45 минут, прежде чем кто‑то начнёт исправлять ситуацию.

Обычные пробелы проявляются быстро. Команды забывают задокументировать правила доступа для SSH, VPN, консоли и портала заявок дата‑центра. Они пропускают запасные части, потому что сервер — «всего одна коробка». Настраивают шумные оповещения и отключают их, либо не настраивают вовсе. Оставляют одобрения расплывчатыми, так что простые действия вроде перезагрузки или замены диска превращаются в цепочку звонков и сообщений.

Runbook не обязан быть толстым мануалом. Для одного сервера короткого рабочего документа достаточно, если он отвечает на вопросы, которые люди задают в стрессовой ситуации. Кого оповещать первым? Кто может одобрить простой? Какие детали есть на месте? Какие точные шаги должны выполнить remote hands, и чего им нельзя делать без разрешения?

Держите его простым и актуальным. Если новый инженер не сможет прочитать и действовать по нему за десять минут — он слишком длинный. Хороший runbook не предотвратит каждую поломку, но не даст маленькой аппаратной проблеме вырасти в полдня угадываний с участием трёх человек.

Решите, кто получает доступ до доставки

Правила доступа терпят неудачу, когда все полагают, что кто‑то другой сможет починить коробку в 2:00 утра. До того как сервер попадёт в стойку, назначьте людей, которые могут действовать, и пропишите, что конкретно каждый из них может делать.

Начните с трёх разных уровней доступа. Они разные, и их смешение быстро вызывает проблемы. Разработчику может быть нужен вход в ОС, чтобы смотреть логи или перезапустить сервис. Сеньор‑админу может понадобиться доступ к консоли, чтобы восстанавливать машину, когда сетевая подсистема отказывает. Физический доступ — совсем другое. Он включает нажатие кнопки питания, перестановку кабелей, замену диска или прочтение серийного номера на корпусе.

Перечисляйте людей по имени, а не только по роли. Роли меняются. Имена, номера телефонов, часовые пояса и запасные контакты экономят время, когда основной человек спит или офлайн.

Обычно достаточно простого разделения:

• Доступ в ОС для логина, sudo и изменений сервисов
• Доступ к консоли для перезагрузок, rescue‑режима, BIOS или IPMI
• Физический доступ для визитов в стойку и инструкций для remote hands
• Одобрение изменений для рискованных работ
• Управление инцидентом — человек, принимающий финальное решение во время простоя

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

Держите контактные данные прагматичными. Укажите мобильные номера, мессенджеры, если команда их использует, и локальные часовые пояса. Добавьте второй контакт для каждого человека с повышенными правами. Если вы пользуетесь внешним администратором или Fractional CTO, запишите и их уровень доступа и запасной контакт.

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

Составляйте первую версию по шагам

Начните с фактов, которые никогда не стоит угадывать под давлением. Поместите имя сервера вверху, затем добавьте положение в стойке и слот, инвентарный тег, модель производителя и все серийные номера, которые могут понадобиться для поддержки или замены. Если у привода, RAID‑контроллера или блока питания есть свой серийный номер — запишите и его.

Далее опишите конфигурацию, которая позволяет машине загрузиться и выйти в сеть. Укажите management IP, production IP, VLAN‑ы, порты коммутатора, MAC‑адреса, hostname, версию BIOS, схему RAID, режим загрузки и порядок загрузки. Держите это просто. Уставший человек должен понять за один проход.

Runbook также должен содержать действия, а не только инвентарь. Пропишите шаги перезагрузки точно так, как вы бы их выполняли: корректное завершение, проверка консоли, цикл питания и что проверить после восстановления. То же для rescue‑режима и полного переустановщика: укажите образ установщика, где хранятся учётные данные, как разбивать диски и какие проверки сервисов должны пройти, прежде чем считать сервер здоровым.

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

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

Потом протестируйте черновик при плановой перезагрузке. Следуйте runbook шаг за шагом и отмечайте, где вы колеблетесь, пропускаете деталь или вам требуется второй сервер, чтобы заполнить пробел. Эти слабые места важны. Отсутствующий номер порта коммутатора может стоить 30 минут. Старая заметка по порядку загрузки может превратить рутинную перезагрузку в звонок в дата‑центр.

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

Установите чёткие правила для remote hands

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

Разделите работы remote hands на две группы: задачи, которые они могут выполнять сразу, и задачи, требующие одобрения. Предодобренные работы должны быть низкорисковыми и легко проверяемыми: перезагрузка конкретной розетки, переустановка подписанного диска или перестановка одного помеченного кабеля в определённый порт. Всё, что может повлиять на данные, порядок загрузки, прошивку или аплинки — должно ждать подписи ответственного.

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

Фото помогают больше, чем многие думают. Попросите сделать фото до и после изменения. Общий кадр показывает стойку и номер блока. Крупный план показывает конкретную корзину диска, кабель или порт. Это даёт быстрый аудит‑трейл и облегчает последующую работу.

Опишите и лимиты по расходам. Установите простой предел для срочных работ на месте: максимальная сумма и максимальное время, которое они могут потратить без повторного согласования. После превышения предела — приостановить работу и позвонить утверждённому контакту.

Всегда используйте один и тот же формат запроса: имя устройства и положение в стойке, точное действие, как подтвердить успех, лимит затрат, статус одобрения и кто звонит, если что‑то не совпадает.

Хороший тикет — это скучно и конкретно. "Переустановить диск в отсеке 3 сервера app‑01, подтвердить зелёный индикатор активности, прислать фото" работает. "Проверьте сервер" — нет.

Храните запасные части, которые действительно экономят время

Сломавшаяся деталь за $60 может держать сервер в простое полдня. В runbook полка со спаренями важна почти так же, как сам сервер.

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

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

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

Для большинства односерверных установок базового набора достаточно: один совпадающий диск, правильный лоток/корзина, один проверенный кабель питания и любые модель‑специфичные детали, которые нельзя быстро купить рядом.

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

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

Следите за сигналами, которые важны

Если ваши оповещения говорят только о высоком CPU или нехватке RAM, вы пропустите отказы, которые больше всего бьют по колокейтед‑серверу. Диск может начать умирать за дни до изменения нагрузки. Вентилятор может прекратить работу, температура поднимется, или потеря пакетов сделает сервис неработоспособным, в то время как сервер выглядит живым.

Следите за аппаратными сигналами, которые обычно дают короткое окно предупреждения: SMART‑состояние дисков и ошибки чтения/записи, состояние RAID, ошибки ECC памяти, температуры CPU, платы и дисков, а также потеря пакетов и задержки по сети.

И это только половина дела. Пользователям всё равно, что у машины есть лишний CPU, если вход в систему не работает или страница грузится 12 секунд. Постоянно следите за одной–двумя проверками сервиса, например, отвечает ли приложение на запрос, выполняет ли база простой запрос или возвращает ли публичная точка ожидаемый статус‑код.

Держите эти виды представлений разделёнными. На одной панели должен быть ответ на вопрос: "Здоров ли сервер?" На другой — "Могут ли клиенты пользоваться сервисом?" Такое разделение ускоряет триаж. Если железо чисто, а время ответа растёт — вы знаете, куда смотреть первым.

Достаточно простой схемы: один путь оповещений вне рабочего времени, который будит реального человека; одна панель для состояния железа; одна панель для влияния на клиентов; и одно правило эскалации для вызова remote hands.

Не отправляйте оповещения туда, куда никто не смотрит после работы. Одна только почта часто терпит неудачу. Используйте телефонные оповещения, приложение для пейджинга или чат‑канал с чёткой on‑call‑ответственностью.

Обрежьте шумные оповещения до первого реального инцидента. Если что‑то срабатывает каждую ночь и никто не реагирует, исправьте порог или уберите его. Короткий список оповещений, которым люди доверяют, лучше, чем перегружённая панель, которая приучает всех игнорировать её.

Пройдите один реалистичный инцидент

В пятницу в 18:40 один диск в вашем RAID‑наборе начинает выдавать SMART‑ошибки. Через пять минут мониторинг присылает оповещение о деградированном массиве, повышенной задержке диска и ID отсека диска. Пользователи ещё ничего не замечают, но у вас пропал запас безопасности.

Инженер на дежурстве открывает панель, подтверждает, что сервер всё ещё обслуживает трафик, и смотрит runbook. В нём указаны имя сервера, позиция в стойке, модель корпуса, схема RAID, карта слотов дисков и шаблон серийных номеров для каждого диска. Это важно, потому что самый быстрый способ превратить маленькую проблему в большой — вытащить не тот диск.

Тикет для remote hands короткий и точный. В нём указано, какой отсек заменить, какой запасной диск использовать, где он хранится и кто должен одобрить замену перед началом работ. Если в runbook есть фото фронта корпусов и маркировки дисков, у техника мало пространства для ошибок.

Remote hands подтверждает метки, извлекает неисправный диск и вставляет запасной из вашего стока. Никому не приходится искать по местным магазинам. Никто не спорит о совместимости. Это само по себе может сэкономить от одного до трёх часов в плохой вечер.

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

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

К 20:05 массив перестраивается, трафик стабилен, и все знают время следующего обновления. Сбой всё ещё случился. Просто он остался маленьким.

Ошибки, которые растягивают короткую проблему на часы

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

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

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

Короткий чек‑лист помогает. Убедитесь, что вы знаете, кто может одобрить перезагрузку или цикл питания, кто имеет доступ к управлению вне полосы (out‑of‑band), где хранятся шаги восстановления и пароли, какие запасные части точно подходят к серверу и что remote hands могут делать без дополнительного согласования.

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

Мониторинг тоже может давать ложное чувство безопасности. Стандартные проверки часто говорят только о доступности сервера. Они не предупреждают, когда растут SMART‑ошибки, массив деградирует, блок питания умирает или температуры дрейфуют вверх. Сервер, который отвечает на ping, всё ещё может быть в одном шаге от полной остановки.

Remote hands — ещё одна ловушка. Многие команды никогда не тестируют формулировку запроса, который отправят в инциденте. Потом они просят дата‑центр "проверить сервер" и получают расплывчатое обновление через 40 минут. Сделайте одну сухую репетицию запроса заранее. Пропишите точные действия, метки и критерии успеха. Эта привычка сэкономит больше времени, чем покупка более быстрого железа.

Быстрые проверки перед тем, как считать всё готовым

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

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

Затем протестируйте части, которые обычно идут не так под давлением. Дайте remote hands одну тестовую задачу, например, заменить помеченный SSD или переместить сетевой кабель в отмеченный порт, и посмотрите, хватит ли ваших заметок. Сопоставьте каждую запасную деталь с конкретной моделью сервера, лотком, рельсом, типом кабеля и блоком питания в стойке. Подтвердите, что оповещения покрывают аппаратные и сервисные проблемы, а не только что‑то одно. Проведите одну плановую проверку восстановления, засеките время и зафиксируйте каждый шаг, который показался медленным или непонятным. Убедитесь, что данные для входа, доступ вне полосы и контакты одобрения работают извне офисной сети.

Короткий тест даёт больше, чем длинный документ. Попросите remote hands заменить загрузочный диск, опираясь только на ваши заметки. Если им понадобилось три дополнительных звонка, чтобы подтвердить серийник, тип лотка или порядок перезагрузки — исправьте runbook сейчас, а не во время инцидента.

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

Что делать после первого черновика

Runbook начинается как предположение. После первого реального инцидента он становится полезным.

Обновляйте его, пока детали ещё свежи. Если диск сломался, изменился порт коммутатора или кто‑то добавил новый шаг для доступа вне полосы — отредактируйте runbook в тот же день. Небольшие задержки превращают ясную память в плохие заметки.

Используйте каждый инцидент как тест. Если remote hands решили проблему за 10 минут — оставьте этот шаг. Если они застряли из‑за записи "проверьте плохой диск" без указания номера отсека или метки — перепишите с точными деталями.

После каждого изменения делайте короткий обзор. Добавляйте любые замены железа, движения кабелей, изменения BIOS или доступа. Удаляйте заметки, которыми никто не пользовался в последнем инциденте. Расширяйте шаги, которые заставляли кого‑то остановиться и задать вопрос. Записывайте, что именно требовалось от персонала дата‑центра, прежде чем он смог действовать. Отмечайте, какое оповещение сработало первым и какое пришло слишком поздно.

Именно здесь многие runbook раздуты. Сопротивляйтесь этому. Страница, полная старых обходных путей и полуправдивых заметок, замедляет людей. Оставляйте только то, что помогает в 2:00 ночи. Урезайте остальное.

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

Простой пример объясняет правило. Если последний простой добавил 25 минут из‑за того, что hands‑команда не могла подтвердить, какой порт NIC несёт трафик управления, добавьте точную карту портов в runbook. Не пишите "проверьте сеть". Пишите порт, метку и ожидаемое состояние линка.

Если хотите второе мнение, Oleg Sotnikov на oleg.is может проверить вашу colo‑настройку, мониторинг и правила доступа. Его опыт в качестве Fractional CTO и советника особенно полезен для маленьких команд, которым нужна надёжная эксплуатация без лишнего процесса.

Когда придёт следующий сервер, не начинайте с нуля. Скопируйте шаблон, обновите факты и сохраните формат.