Тихая серверная

Ростислав любил тишину серверной так же, как другие любят шум моря. Тишина там была особенная — не пустая, а насыщенная: равномерный гул вентиляторов, едва заметный писк дросселей на блоках питания, редкие щелчки реле в стойках питания, мягкое “ш-ш-ш” кондиционеров. Если прислушаться, можно было различить ритм инфраструктуры. И Ростислав различал.

Он стал системным инженером не потому, что мечтал о бесконечных конфигурациях и ночных дежурствах. Скорее наоборот: он мечтал о спокойствии. Просто однажды понял, что спокойствие в IT не даётся бесплатно — его нужно проектировать, собирать, тестировать, мониторить, защищать, и иногда вырывать из лап хаоса в три часа ночи, когда “всё красное” и телефон вибрирует так, будто пытается выскочить из кармана.

Путь Ростислава начался банально. Первый Linux он поставил на старый ноутбук, потому что Windows “тормозила”, а деньги на апгрейд были студенту не по карману. Дистрибутив был на диске, скачанном у одногруппника, который говорил загадочными фразами: “Поставь, и всё будет летать”. Оно действительно полетело… в кювет. Wi-Fi не поднялся, тачпад вел себя как пьяная муха, а звук исчез вовсе. Ростислав провёл тогда ночь, читая форумы и пытаясь понять, почему жизнь так жестока к новичкам. Но утром звук заработал, Wi-Fi ожил после установки firmware, а тачпад — после какого-то магического параметра в конфиге. Ростислав впервые почувствовал вкус победы, который потом станет знакомым: не сладкий, а солоноватый — как пот после долгого бега.

Через несколько лет он работал в компании, где инфраструктура росла быстрее, чем успевали писать документацию. Там всё начиналось с пары виртуалок, затем появился отдельный сервер под базы, потом — кластер, потом — второй кластер “на всякий случай”, а затем случилось страшное слово: “прод”. Прод был капризным зверем. Он не прощал ленивых решений. Любое “потом поправим” в проде превращалось в “почему всё легло” через две недели.

Ростислав отвечал за Linux-сервера, сети, автоматизацию и — если говорить честно — за всё, что не было прибито гвоздями к чужой зоне ответственности. Он любил порядок. Поэтому у него были аккуратные Ansible-роли, структурированные inventory, шаблоны systemd-юнитов, стандарты именования, и особенно — мониторинг. Мониторинг был его религией. Он не верил в “вроде работает”. Он верил в графики, алерты и корреляцию событий.

В первый же месяц работы ему достался боевой инцидент. Ночью упал сервис, который, по ощущениям бизнеса, “держит весь мир”. Телефон зазвенел как тревога. Ростислав проснулся мгновенно, будто его подбросило. На экране — сообщение: “5xx выросли, latency > 3s, SLO горит”. Он не ругался, не паниковал. Он сделал то, чему его научили ночи с форумами: сначала — фактология.

Он открыл ноутбук, подключился по VPN, прыгнул на bastion, дальше — в кластер. top показал странное: нагрузки почти нет. Но сервис отвечает плохо. Тогда ss -s — тысячи соединений в TIME_WAIT, пачки SYN_RECV. Похоже на сетевую атаку? Но внутренний сервис… Он пошёл дальше. journalctl -u nginx -S "10 min ago" — предупреждения о лимитах, а рядом — аккуратные записи о том, что upstream иногда не отвечает. Он переключился на backend: journalctl -u app — “timeout connecting to redis”. И тут пазл сложился.

Redis жил на отдельной виртуалке. Ростислав зашёл туда. free -m — памяти почти нет, swap забит, IO wait высокий. Он посмотрел dmesg — ядро ругалось на OOM-killer пару часов назад. Сервис перезапускался, но снова забивал память. Так бывает, когда кто-то “на время” выключил ограничение, а потом забыл. Он открыл конфиг systemd и увидел: MemoryMax отсутствует. На соседних сервисах — стоит. На этом — нет.

Решение было простым. Нужно ограничить память, перезапустить, дождаться стабилизации, и после — разбираться, почему оно вообще утекло. Он добавил ограничение, перезапустил сервис, затем Redis. Дал пару минут. Графики начали ползти вниз, ошибки — исчезать. Он сделал короткое сообщение в чат дежурных: “Причина: OOM на redis-ноде из-за утечки/роста памяти, включил MemoryMax, перезапустил, сервис восстанавливается”. И только потом позволил себе выдохнуть.

Утром он пришёл в офис раньше обычного. С кофе в руках, но с холодной головой. Он любил постмортемы: это были не разборки, а инструменты улучшения. Он собрал команду, показал таймлайн, предложил действия: добавить лимиты в systemd для всех критичных юнитов, включить алерт по swap-usage и OOM-events, добавить нагрузочный тест для сценария, который забивает память, и — главное — сделать правило “никаких ручных правок на проде без ревью”. Все кивнули. Но Ростислав знал: кивать — легко. Сложно — внедрить.

Он внедрил. Он вообще был из тех, кто не просто говорит “надо”, а делает. Вечерами он приводил в порядок Ansible-роль, которая генерировала systemd-юниты. Добавил дефолтные лимиты, но так, чтобы их можно было переопределять. Сделал unit-тесты на шаблоны (да, даже на шаблоны). Добавил в CI проверку “почему здесь нет MemoryMax”. Поднял сбор логов OOM в central logging. И самое приятное — через пару недель поймал похожую проблему до того, как она стала инцидентом: алерт по swap дернулся на 60%, Ростислав посмотрел, увидел знакомые паттерны, и исправил без шума. В тот день серверная казалась тише обычного.

Но инфраструктура не любит застоя. В компании начали внедрять Kubernetes. Не потому, что “модно”, а потому, что проектов стало больше, команды размножились, деплои стали хаотичными, а сервера — складом “ещё одной виртуалки”. Ростислав не был фанатиком Kubernetes. Он видел и красоту, и боль. Красота — в декларативности, в масштабировании, в повторяемости. Боль — в том, что люди часто пытаются решить организационные проблемы технологией.

Он согласился вести часть миграции. Начал с малого: стандартизировал образы, настроил базовые политики, занялся сетью. В сеть он вцепился особенно. Потому что сеть — это то место, где “как-нибудь” превращается в “ничего не работает”. Он сделал сетевую схему, прописал правила, настроил ingress, выбрал подход к service mesh (и вовремя остановился, решив, что не надо усложнять раньше времени). Он любил простые решения, когда они честные.

Однажды, во время очередного релиза, всё снова пошло не так. Не катастрофа, но тревожно: поды живы, но часть запросов зависает. Графики показывают странный всплеск latency на одном из регионов. Ростислав снова начал с фактологии. Он сравнил логи приложений, посмотрел метрики на уровне ноды, проверил conntrack — и увидел, что таблица переполнена. Это было как заноза, которую сначала не заметили, а потом она воспалилось. Где-то в цепочке сетевых правил случился шторм соединений.

Он пошёл глубже: sysctl net.netfilter.nf_conntrack_max был слишком низким для текущих нагрузок. Это было наследие старых времён, когда нод было меньше, трафик — скромнее. Он поднял лимит, настроил мониторинг conntrack, добавил алерт. И снова — после инцидента сделал “на будущее”: автоматизировал sysctl через Ansible, чтобы на новых нодах не повторилась ошибка. Он не любил, когда знания живут только в голове дежурного. Он считал, что хорошая инфраструктура — это та, что продолжает работать, даже если конкретного человека нет рядом.

Ростислав умел держать удар. Но он не был роботом. Самым тяжёлым для него были не ночные инциденты и не сложные технические узлы. Самым тяжёлым было объяснять бизнесу, почему “это нельзя сделать быстро”. Когда приходил человек с горящими глазами и говорил: “Нам нужно завтра. Просто сделай.” Ростислав смотрел на него спокойно и отвечал: “Если сделать завтра, то потом неделю будем чинить. Если сделать за три дня, то будем спать.” И иногда его понимали. Иногда — нет.

Однажды он ввёл понятие “стоимость тишины”. Он сделал презентацию не про технологии, а про последствия. Рассказал, сколько времени тратится на инциденты, как они съедают фокус, как стресс дежурных приводит к ошибкам, как каждое “быстро” увеличивает вероятность падения. Он показал график: количество аварий до стандартизации и после. И сказал: “Тишина в серверной — не случайность. Это продукт.” Эта фраза разошлась по компании, как мем. Кто-то иронизировал, но большинство — запомнило.

Ростислав любил наставлять новичков. Но делал это без пафоса. Он не говорил: “Я знаю лучше”. Он говорил: “Давай проверим.” Когда приходил джун и говорил: “Сервис не работает”, Ростислав спрашивал: “Что значит ‘не работает’? Где признаки? Какие метрики? Какие логи?” Он учил людей думать не эмоциями, а наблюдениями. Он говорил: “Твой враг — не ошибка. Твой враг — неопределённость.”

Один новичок, Илья, однажды спросил: “А ты никогда не боишься?” Ростислав улыбнулся: “Боюсь. Просто страх — это сигнал. Он говорит: проверь гипотезы, не делай резких движений, делай бэкап, думай о rollback.” Илья кивнул. Через месяц Илья уже сам делал аккуратные изменения в конфиге, всегда готовя план отката. Ростислав видел это и испытывал тихую гордость. Не громкую — такую же тихую, как серверная.

Однажды, в самый обычный день, случилось неожиданное: компания решила переехать в другой дата-центр. Причины были прагматичные: условия, каналы, резервирование. Для Ростислава это звучало как “переехать домом” — только дом был из сотен сервисов, петабайт данных, сетевых связей и зависимости от времени. Он собрал план миграции: по шагам, с окнами обслуживания, с двойным запуском, с тестами. Он настоял на репетиции. Он знал: те, кто не репетирует, репетируют на проде.

В ночь миграции он не спал. Не потому что “надо следить” — следили многие. Он не спал, потому что чувствовал ответственность. Он сидел перед несколькими экранами: метрики, логи, статус каналов, чаты команд. В какой-то момент один из каналов начал терять пакеты. Не критично, но неприятно. Ростислав не стал паниковать. Он поднял mtr, увидел, где начинается деградация, связался с провайдером, параллельно переключил часть трафика на резерв. Всё это выглядело со стороны как магия: будто он просто “передвинул ползунок” — и стало лучше. Но на самом деле магия была в подготовке. Резерв был настроен заранее. Маршруты — прописаны. Мониторинг — готов. Это и есть “стоимость тишины”.

Миграция прошла. На рассвете Ростислав вышел на улицу, вдохнул холодный воздух и почувствовал, как усталость накрывает волной. Он шёл по пустой улице и думал о том, что в его работе мало видимых побед. Пользователи не пишут: “Спасибо, что у нас сегодня ничего не упало.” Они пишут только тогда, когда упало. Но именно это его и привлекало: работа на границе невидимого, работа, где результат — отсутствие проблем.

Через пару месяцев он столкнулся с другой угрозой — человеческой. Кто-то случайно выкатил секреты в лог. Пара токенов утекла в общий лог-агрегатор. Это не была утечка наружу, но это было нарушение правил. Ростислав отреагировал мгновенно: отозвал токены, почистил доступы, включил маскирование. Потом внедрил policy: секреты не должны попадать в stdout, только в vault, а если попали — алерт. Он добавил сканирование логов на паттерны. И снова — превратил “человеческую ошибку” в “системную защиту”.

Его иногда спрашивали: “Ты не выгораешь?” Ростислав отвечал честно: “Бывает тяжело.” Он знал, что выгорание приходит, когда ты борешься с хаосом в одиночку. Поэтому он строил команду. Он учил дежурить по-человечески: с ротацией, с адекватными окнами, с уважением к личному времени. Он настоял, чтобы после ночного инцидента человек мог отсыпаться, а не сидеть в митингах. Он был системным инженером не только по Linux. Он был системным инженером по людям.

Самым важным его принципом было: “Проблемы должны быть измеримы.” Он превращал субъективное в объективное. “Медленно” — это latency, p95, p99. “Иногда падает” — это error rate, аптайм, MTTR. “Нестабильно” — это частота рестартов, количество алертов, дрейф конфигураций. Он учил команду видеть мир как систему сигналов, а не как поток эмоций.

В один из вечеров, когда офис опустел, Ростислав сидел один и смотрел на графики. Это был странный момент спокойствия. Инфраструктура работала ровно. Алерты молчали. Логи были чистыми. Он поймал себя на мысли, что иногда скучает по драме инцидентов — но тут же усмехнулся: “Нет, не скучаю. Просто привык.” Он понимал: лучший день системного инженера — это день, когда он может заняться улучшениями, а не тушением пожаров.

Через год он стал тем человеком, к которому приходят за советом. Не потому что он громче всех говорил, а потому что он был надёжным. Он был тем, кто называет вещи своими именами, но не унижает. Тем, кто спокойно объясняет, почему нужно сделать правильно. Тем, кто не боится сказать “нет”, когда “да” приведёт к аварии. И тем, кто умеет сказать “да”, когда это реально можно сделать быстро и безопасно.

Однажды ночью снова пришёл алерт. Ничего нового: latency выросла, ошибки подскочили. Ростислав проснулся, открыл ноутбук, сделал привычные шаги. Но на этот раз он заметил кое-что другое: команда работала без него. В чате уже были гипотезы, уже проверяли метрики, уже делали rollback. Он вмешался только чтобы подсказать одну деталь: “Проверьте conntrack и лимиты, похоже на сетевой шторм.” Они проверили. Он оказался прав. Инцидент закрыли быстро.

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

И в этот момент он почувствовал настоящую гордость. Не за то, что он “герой” и “спас”. А за то, что мир стал устойчивее. За то, что тишина — заслуженная.

На следующий день он пришёл в серверную. Там было так же тихо. Он провёл ладонью по холодной дверце стойки, как будто приветствуя старого друга. Где-то внутри работали диски, текли пакеты, крутились процессы, исполнялись юниты systemd. Всё жило. Всё дышало.

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

И если бы кто-то спросил, что такое профессия системного инженера, Ростислав ответил бы просто: “Это когда ты отвечаешь за то, чтобы никто не думал о серверах. Чтобы люди делали свою работу, а инфраструктура — свою. И чтобы ночью, когда мир спит, серверная могла позволить себе быть тихой.”