Есть фрагменты воспоминаний, которые почему‑то остаются в памяти гораздо дольше, чем команды, номера интерфейсов и модели оборудования. До сих пор вспоминаю, как поднимаюсь по лестнице на третий этаж Павловского районного узла связи и открываю тяжёлую железную дверь с кодовым замком. За ней начинался наш технический мир: центральный узел доступа, серверная, кабинеты инженеров и оперативных дежурных, кросс, производственно‑техническая лаборатория. За годы работы движение пальцев по кодовому замку стало настолько автоматическим, что эту дверь я мог открыть ночью, в темноте, не глядя на кнопки — практически с закрытыми глазами.
Прошло много лет, но тяжёлый звук закрывающейся двери, постоянный шум вентиляторов серверной, голоса коллег и отдельные яркие картины работы в РУСе почему‑то до сих пор живут в моей памяти.
Я пришёл в связь 1 декабря 2006. Интернет тогда находился в важной переходной точке развития: dial‑up ещё оставался совершенно нормальным способом выхода в Сеть, а ADSL в нашем районе только начинал разворачиваться и должен был превратить существующую телефонную медную сеть в массовую широкополосную сеть доступа в Интернет. За следующие годы районная сеть прошла путь от модемного пула и первого DSLAM до тысяч xDSL‑подключений, распределённых узлов доступа, корпоративных VPN/MPLS, IPTV, FTTB/ETTH, DWDM и 10G.
Но эта статья не только об оборудовании. Она ещё и о людях, которые заставляли это оборудование работать, о том, как вместе с сетью менялась сама организация связи, и о том, что происходит с технической системой, когда из неё постепенно исчезают люди, десятилетиями хранившие её эксплуатационную память.
Пока менялась сеть, менялся и сам узел связи
За годы моей работы организационная структура менялась едва ли не так же часто, как оборудование. В памяти остались разные этапы и разные названия: Павловский РУС — районный узел связи, затем Павловский ОУС — объединённый узел электросвязи, структуры ОАО «ЮТК» — «Южной телекоммуникационной компании», позднее ЛТЦ и межрайонные структуры. После присоединения ЮТК к «Ростелекому» появлялись новые уровни подчинения, в том числе Павловский ЛТЦ и Тихорецкий МЦТЭТ.
Точную последовательность всех поздних реорганизаций спустя столько лет я уже не хочу восстанавливать исключительно по памяти. Для этой статьи важнее другое: за изменениями вывесок постепенно происходило изменение самой модели эксплуатации сети передачи данных и доступа в Интернет. От относительно самостоятельного районного технического подразделения система всё больше двигалась к централизации функций и сокращению специалистов на местах.
Когда я только начинал работать, районный узел связи был практически самостоятельным техническим организмом. Здесь находились люди, знавшие станционное оборудование, линейное хозяйство, медь, оптику, электропитание, абонентскую сеть, маршрутизацию, серверы и историю конкретных районных объектов связи. Если связь переставала работать, проблему нельзя было бесконечно передавать между подразделениями. В какой‑то момент возле реального оборудования всё равно должен был оказаться человек, который понимает, что именно перед ним находится и что с этим делать.
До ADSL был dial‑up
Когда я пришёл в декабре 2006 года, dial‑up ещё оставался обычной услугой. В центральном узле работал многоканальный модемный пул. На сохранившихся схемах оборудования того периода виден Cisco AS5300 — access‑server с модемными ресурсами, который одновременно обслуживал большое количество dial‑up‑соединений.
Сегодня сама механика dial‑up для молодого пользователя может выглядеть почти музейной. Абонентский модем звонил на номер провайдера через обычную телефонную сеть, на другой стороне соединение принимал модемный пул, происходило характерное звуковое согласование, после чего пользователь проходил авторизацию и получал доступ в Интернет. Телефонная линия на время сеанса фактически занималась передачей данных, а скорость измерялась десятками килобит в секунду. Это было вполне нормально. Интернет тоже был другим: почта, форумы, ICQ, относительно лёгкие сайты; загрузка одного MP3-файла могла занимать очень долго, а обрыв соединения иногда означал необходимость начинать часть работы заново.
Именно поэтому появление ADSL воспринималось не как очередное изменение тарифа. Это была практически смена эпохи. Та же телефонная медная пара внезапно могла передавать данные постоянно, а скорость начинала измеряться уже не килобитами, а мегабитами.
Nokia D500: первый DSLAM
Практически сразу после моего прихода в центральной серверной появился Nokia D500 — первый DSLAM, с которым мне предстояло работать самостоятельно. Смысл технологии был понятен: по существующей медной телефонной паре организовывался DSL, множество таких линий сходилось на DSLAM, а абонентский трафик агрегировался и передавался дальше в операторскую сеть.
Гораздо сложнее оказалось впервые этот DSLAM запустить. Nokia установили в телекоммуникационный шкаф, но дальше нужно было получить управление, разобраться с CLI, включить устройство в служебную сеть, настроить интерфейсы, сервисы и абонентские порты.
Нормальной пошаговой русскоязычной эксплуатационной инструкции у меня не было. Какие‑то материалы существовали на английском, отдельные сведения удавалось получить у коллег, но руководства формата «сделайте двадцать действий и получите работающую систему» не существовало. Всё приходилось разгадывать практически с нуля.
Сервисный разъём внешне напоминал обычный сетевой, но имел собственную распиновку. Один из инженеров станционной группы изготовил по найденной схеме консольный кабель, после чего я подключил ноутбук через COM‑порт и HyperTerminal. Первые пару дней ушли только на то, чтобы нормально получить управление и включить устройство в служебную сеть. А затем началось изучение уже самого DSLAM: портов, сервисов, параметров линий, диагностики, настройки интерфейсов, VLAN, ADSL‑плат и множества других вещей.
Со временем это превратилось в полноценную собственную эксплуатационную базу знаний. Речь уже шла не о нескольких найденных командах, а о десятках и сотнях операций: как запустить оборудование с нуля, как диагностировать конкретную линию, что проверить после аварии, как восстановить сервис, какие особенности имеет конкретная версия программного обеспечения.
Nokia D500 при этом осталась у меня в памяти не только потому, что была первой. Из xDSL‑оборудования того поколения она до сих пор кажется мне одной из наиболее удачных систем, с которыми приходилось работать: достаточно логичный CLI, хорошая стабильность, понятная диагностика и предсказуемое поведение в круглосуточной эксплуатации.
Телефон есть — а ADSL подключить нельзя
Само появление DSLAM ещё не означало, что теперь ADSL можно подключить каждому владельцу стационарного телефона. Телефонная сеть Павловского района строилась задолго до массового Интернета, и при прокладке старых медных кабелей никто, естественно, не рассчитывал их ёмкость исходя из того, что через десятилетия практически каждой квартире понадобится индивидуальная высокочастотная последняя миля.
Одним из серьёзных ограничений было цифровое абонентское уплотнение — ЦАУ. Такое оборудование позволяло экономнее использовать существующее кабельное хозяйство: через одну физическую медную линию можно было организовать работу нескольких телефонных абонентов. Для телефонии это помогало решать проблему дефицита пар, но для классического ADSL становилось препятствием.
Поэтому наличие исправно работающего домашнего телефона совершенно не гарантировало техническую возможность подключения Интернета. Человек мог написать заявление на ADSL, после чего выяснялось, что он находится на уплотнении и индивидуальной пригодной медной пары до оборудования доступа у него просто нет.
Когда спрос на ADSL начал расти, появилась дополнительная постоянная работа: станционные и линейные специалисты по возможности снимали потенциальных ADSL‑абонентов с уплотнения, искали свободные пары, выполняли перекроссировки и пытались выделить человеку отдельную линию. Иногда решение находилось, а иногда физически свободной пары просто не существовало.
В этом особенно хорошо сталкивались две технологические эпохи. Медную сеть когда‑то строили для массовой телефонизации, а затем от той же инфраструктуры внезапно потребовали совсем другого — индивидуальной широкополосной линии до каждого желающего.
Поэтому старая фраза «отсутствует техническая возможность» далеко не всегда была бюрократической отпиской. Иногда технической возможности действительно не существовало на уровне физического кабеля.
ANSI, G.dmt и почему Auto не всегда лучше
Очень быстро выяснилось, что теоретического понимания ADSL для нормальной эксплуатации недостаточно. Конкретная медная линия, DSLAM и конкретный абонентский модем могли вести себя совершенно не так, как должно было быть в теории.
Одними из первых у нас были чёрные модемы AusLinx. На части линий наиболее устойчивую работу с ними удавалось получить при выбранном вручную режиме ANSI. При других вариантах конкретная последняя миля могла вообще не синхронизироваться или DSL‑link периодически падал. С популярными впоследствии D‑Link часто лучше работал G.dmt, то есть классический ADSL первого поколения.
На Nokia можно было выбирать разные DSL‑режимы. Позднее появился ADSL2+, который позволял получить существенно более высокую скорость downstream. Имелся и автоматический выбор модуляции, но Auto далеко не всегда оказывался лучшим решением. Некоторые сочетания модема и конкретной медной пары в автоматическом режиме работали нестабильно, тогда как вручную выбранный профиль давал устойчивую связь.
Инженерная задача состояла не в том, чтобы получить максимальную цифру скорости в момент синхронизации. Нужно было заставить линию стабильно работать круглосуточно. Именно здесь начиналась эксплуатационная практика, которую практически невозможно получить только из документации. Через несколько лет уже знаешь: этот CPE любит такой режим, на этой линии лучше не пытаться выжать последний мегабит, здесь ADSL2+ будет устойчив, а здесь правильнее оставить более консервативную модуляцию.
То же самое относилось к ADSL‑ и SHDSL‑модемам, DSLAM и коммутаторам агрегации. У каждой модели существовали собственные особенности, болезни и иногда совершенно нелогичные состояния. Постепенно конфигурация сетевого оборудования превращалась в отдельный мир, который нужно было не только знать теоретически, но и чувствовать по накопленному эксплуатационному опыту.
Первый пользователь ADSL
Один из первых полноценных тестов нового ADSL‑подключения проводился прямо на станционном кроссе. Я сидел с ноутбуком и тем самым чёрным AusLinx, рядом находились другие сотрудники станции. После нескольких дней конфигурирования нужно было наконец проверить весь тракт целиком.
Появилась устойчивая DSL‑синхронизация, поднялась PPPoE‑сессия и пошёл трафик. Получается, что фактически одним из первых пользователей ADSL Павловского района оказался инженер‑программист с ноутбуком возле станционного кросса. Разумеется, я не говорю об официальном «абоненте № 1» — это была эксплуатационная проверка.
После dial‑up ADSL воспринимался почти как космос. Позднее хорошая линия могла давать около 7–8 Мбит/с, а с ADSL2+ downstream уже переваливал за 20 Мбит/с. Мы использовали Speedtest и смотрели на эти цифры совсем другими глазами, чем сегодня.
Тогда казалось, что такой скорости хватит навсегда.
Сначала ADSL ещё приходилось объяснять людям
Сегодня это звучит немного странно, но в первые месяцы массового ажиотажа вокруг новой услуги не было. Людям, организациям и школам приходилось объяснять, зачем вообще нужен постоянный широкополосный ADSL‑доступ. Кто‑то отвечал, что dial‑up и так работает — зачем покупать новый модем?
Но ситуация изменилась очень быстро. Через несколько лет проблема стала противоположной: не хватало и портов, и пригодных прямых медных пар вне ЦАУ. DSLAM расширялись, появлялись новые узлы, оборудование устанавливалось в других населённых пунктах района. Технология, которую поначалу приходилось популяризировать, превратилась в обычную инфраструктуру, отсутствие которой пользователь воспринимал уже как серьёзную проблему.
В первые годы ADSL‑модемы даже выдавали в аренду тем, кто не хотел покупать своё оборудование. Позднее обычным стал modem/router, самостоятельно устанавливающий PPPoE‑сессию. Использовался и режим bridge, когда PPPoE поднимался непосредственно на компьютере. Домашний Wi‑Fi уже существовал, но ещё не стал обязательным атрибутом практически каждой квартиры.
Упрощённый путь трафика выглядел так:
ADSL‑модем → медная пара → кросс/сплиттер → DSLAM → сеть доступа → агрегация → операторская IP‑инфраструктура → PPPoE/RADIUS → Интернет.
В ATM‑сегменте хорошо запомнился PVC 0/35 для Internet и 2/35 для IPTV. Телевидение работало через multicast. Параллельно существовали служебные VLAN управления, корпоративные сети и другие сервисы.
Для пользователя всё это помещалось в несколько лампочек на модеме. Для инженера за этими лампочками находилось несколько совершенно разных технологий.
«Техническая возможность имеется»
В первые годы ADSL тарифные планы различались в том числе по максимальной скорости. Точную коммерческую сетку двадцатилетней давности я сейчас уже не восстановлю и не хочу придумывать её по памяти, но принцип был примерно таким: существовали тарифы на нескольких скоростных уровнях — условно до 2, 4, 8 Мбит/с и другие варианты. Upstream был значительно ниже downstream и зависел от установленного профиля порта, технического состояния линии и её удалённости от узла доступа.
Абонентский отдел регулярно приносил мне стопки нарядов на проверку технической возможности выбранного тарифа. Фактически это была небольшая инженерная экспертиза конкретной последней мили. Я заходил на DSLAM, находил нужную линию и соответствующий ей порт, смотрел SNR Margin, Line Attenuation, текущую скорость синхронизации, потенциально достижимую скорость, ошибки и общее состояние DSL. После этого в наряде появлялось моё заключение: техническая возможность для выбранной скорости имеется либо линия такой режим устойчиво не выдержит.
Это была очень наглядная граница между коммерческой услугой и реальными физическими возможностями сети. В биллинге можно назначить абоненту практически любую скорость, но медная пара тарифный план не читает.
Позднее тарифная модель менялась, скорости росли, и фактический максимум всё больше определялся техническими возможностями конкретной последней мили.
DSL есть, а Интернет всё равно работает плохо
В рабочем разговоре часто говорили просто: «DSL есть?» или «Сигнал есть?». Это означало, что модем и DSLAM синхронизировались. Но наличие DSL‑sync ещё ничего не гарантировало в отношении качества самой услуги.
При диагностике линии анализировались SNR Margin / Noise Margin, Line Attenuation, фактическая скорость синхронизации, Attainable Rate, CRC, FEC и HEC. Downstream и upstream обязательно рассматривались отдельно.
На оборудовании Siemens существовала своя xDSL performance‑статистика. Можно было смотреть параметры со стороны xTU‑C и xTU‑R, сбрасывать счётчики, ждать и наблюдать, как они набираются снова. Если линия за короткое время получала огромное количество ошибок, зелёный статус UP был слабым утешением.
Поэтому нормальная диагностика шла дальше по всей цепочке: физическая линия → DSL → VLAN/L2 → агрегация → PPPoE → RADIUS/авторизация → IP‑сервис. Иногда приходилось прослеживать MAC‑адрес через несколько уровней коммутаторов и выяснять, на каком именно участке перестаёт проходить трафик.
Порты, которые «умирали», а потом воскресали
У ADSL‑портов существовала неприятная особенность: отдельный порт периодически переставал выдавать DSL‑сигнал вообще. В рабочем обиходе говорили просто: «порт сгорел». Абонента переставляли на другой порт, а неисправный помечали.
Но со временем обнаружилась довольно странная вещь. Некоторые порты, долго считавшиеся неработоспособными, через год или два внезапно снова начинали нормально синхронизироваться. Поэтому периодически ведущий инженер или начальник узла поручали мне возвращаться к спискам неисправных портов и диагностировать их повторно.
Я последовательно проходил такие порты и пытался вернуть их в эксплуатацию. Иногда таким образом удавалось восстановить заметную часть потерянной ёмкости DSLAM. Обычный restart отдельного порта помогал далеко не всегда; иногда приходилось перезапускать целую DSL‑плату или весь DSLAM.
Бывали и ещё более интересные состояния. DSL‑link поднимается, параметры линии выглядят приемлемо, но PPPoE на конкретном порту не работает. Тогда неисправность находилась уже выше физического DSL‑уровня. В некоторых случаях я полностью разбирал логическую конфигурацию такого подключения: удалял связанные сервисные настройки, VLAN и subinterface, после чего собирал всё заново.
На первый взгляд это выглядело нелогично: если конфигурация отображается правильно, повторная запись тех же параметров вроде бы ничего не должна изменить. На практике после полной пересборки сервис иногда начинал работать. Сейчас я сформулировал бы это осторожнее: проблема могла находиться во внутреннем состоянии программной части DSLAM или связанных сервисных объектов, неочевидном из обычного вывода конфигурации.
Тогда нас прежде всего интересовал результат. После нескольких часов диагностики PPPoE снова поднимался.
Когда высокая скорость синхронизации не гарантирует реальную скорость у абонента
Ещё одной классической проблемой массового ADSL была многопарная медь. DSLAM мог показывать вполне приличную синхронизацию, например 8 Мбит/с downstream и 512 Кбит/с upstream или 20 Мбит/с downstream и 768 Кбит/с upstream, но у пользователя при этом появлялись потери пакетов и задержки. Особенно плохо ситуация могла проявляться вечером, когда одновременно начинало активно работать большое количество соседних линий.
При заполнении кабельного пучка множеством DSL возрастало взаимное влияние соседних пар — crosstalk, в том числе NEXT/FEXT. В эксплуатации старались не занимать DSL все пары небольшой группы, но это была реальная сеть с постоянным дефицитом свободной ёмкости. В условной десятипарке могли оказаться восемь, девять, а иногда практически все десять работающих DSL‑линий.
Иногда даже снижение скорости до 2 Мбит/с не давало идеального результата. Подобные ситуации очень хорошо отучают делать вывод по одному параметру: стабильный DSL‑sync ещё не означает качественный IP‑сервис.
Из одного DSLAM выросла сеть всего района
Первые ADSL‑порты находились в Павловской, но оптика постепенно начала уходить в другие населённые пункты. На удалённых площадках появлялись собственные DSLAM и коммутаторы, а существующая телефонная медь становилась последней милей.
Постепенно сформировалась распределённая сеть примерно из 16 географических узлов доступа. Это были Павловская и вынесенные узлы внутри неё, Атаманская, Новолеушковская, Новопетровская, Краснопартизанское, Новопластуновская, Северный, Весёлая, Незамаевская, Старолеушковская, Упорный и другие населённые пункты.
К концу 2012 года только xDSL‑сегмент районной сети имел установленную ёмкость порядка 5,8 тысячи портов, а действующих xDSL‑подключений было примерно 5,5 тысячи. В одной Павловской счёт шёл примерно на 3,7 тысячи портов, почти полностью занятых.
Здесь важно уточнить: это именно статистика xDSL, а не общее количество всех пользователей широкополосной сети. К этому времени уже развивался Ethernet‑доступ, позднее FTTB/ETTH стал значительной частью инфраструктуры. Поэтому моя память о том, что общее количество подключений могло быть уже порядка десяти тысяч, сама по себе не противоречит сохранившейся xDSL‑статистике. Но документально подтверждённого совокупного числа у меня сейчас нет, поэтому превращать воспоминание в точную цифру я не хочу.
Сеть, которая перестраивалась почти каждый день
При этом сеть передачи данных и узлы доступа практически никогда не находились в неподвижном состоянии. Модернизация шла постоянно, и именно поэтому объём конфигурационной работы был огромным.
Сегодня с одного DSLAM снималась линейная плата и переставлялась в другой узел. Завтра освобождался целый DSLAM и уезжал в другой населённый пункт. Потом менялся Cisco Catalyst, QTech или D‑Link, перестраивалась агрегация, переносился uplink, появлялись новые сервисы. На некоторых DSL‑платах приходилось обновлять программное обеспечение. Одновременно каждый день подключались новые абоненты, а уже работающим нужно было обеспечивать стабильный доступ в Интернет. Если оборудование уже эксплуатировалось у меня раньше, я обычно знал его особенности почти наизусть: какую версию ПО лучше использовать, какие дефекты встречаются у конкретного релиза, какие режимы могут приводить к нестабильности и какими конфигурационными решениями это приходится компенсировать. У железа, как и у людей, со временем появлялась собственная биография, и инженер эту биографию помнил.
После физической перестановки оборудования работа только начиналась. Нужно было заново продумать его место в существующей топологии и полностью адаптировать конфигурацию под новый узел: management, VLAN, trunk и access‑порты, PPPoE, multicast, корпоративные сервисы, VPN/MPLS и множество других параметров.
Особенно важно было ничего не потерять при миграции. За одним коммутатором или DSLAM могли находиться сотни зависимых подключений, а вся районная сеть обслуживала уже многие тысячи абонентов. Недостаточно было просто снять старую коробку и поставить новую: требовалось понимать, что именно проходило через старое оборудование, куда всё это должно перейти и как перестроить сеть так, чтобы после модернизации она действительно заработала.
Такое происходило практически постоянно. Операторская сеть росла не несколькими большими красивыми проектами в год, а сотнями небольших ежедневных изменений.
Иногда я работал как «семиделка»
Бывали дни, когда со стороны моя работа действительно напоминала человека‑оркестр. Я иногда осознавал, что работаю как семиделка: в одной руке радиотелефон, по которому кто‑то из коллег сообщает состояние линии или удалённого узла, рядом звонит второй телефон, на коленях ноутбук с консольным кабелем, подключённым к коммутатору или DSLAM.
В одном окне CLI, одновременно нужно проверить что‑нибудь в Onyma или АСР «Курс», рядом лежат наряды, а кто‑то уже ждёт решения следующей задачи. Я был единственным IT‑специалистом такого профиля непосредственно в узле, но вокруг находился большой коллектив инженеров связи, станционных специалистов, линейщиков, радиоинженеров, электромехаников, работников абонентского отдела. Каждый был силён в своей области, и сеть работала именно потому, что эти знания соединялись.
Сегодня подобные обязанности во многих организациях разделили бы между специалистами нескольких профилей. На районном уровне значительную часть этого приходилось держать одному человеку. В этом и заключалась специфика моей работы: не максимально узкая специализация в одной технологии, а способность одновременно понимать несколько взаимосвязанных уровней системы.
365 дней в году: когда инженер всегда на связи
Формально календарь, конечно, содержал субботы, воскресенья и праздничные дни. Практически для меня эксплуатация сети передачи данных существовала 365 дней в году и 24 часа в сутки. Работы по модернизации специально нередко переносились на выходные или на время минимальной нагрузки, а авария вообще не интересуется календарём. Поэтому в субботу или воскресенье я вполне мог ехать на центральный или периферийный узел, менять оборудование, перестраивать конфигурацию или устранять отказ.
Позвонить мог Александр Николаевич или любой из оперативных дежурных — их было несколько, Сергей был только одним из них. Звонок мог прозвучать днём, ночью, в праздник или во время отдыха. В той рабочей культуре пропустить серьёзный аварийный вызов и просто остаться недоступным воспринималось как недопустимое. Я сам относился к этому ещё жёстче: телефон практически всегда находился рядом, потому что понимал, что за звонком могут стоять сотни или тысячи абонентов и целый участок районной сети.
При этом СПД была главным, но далеко не единственным моим хозяйством. На мне находилось администрирование более пятидесяти рабочих станций Windows, серверов на FreeBSD и Linux, файловых ресурсов Samba, сервера «Какаду», СПУС и других внутренних систем. Добавлялись кассовые рабочие места и контрольно‑кассовая техника, IP‑камеры, МФУ, принтеры и множество более мелких устройств. Диапазон задач был настолько широким, что часть такой работы со временем переставала восприниматься как отдельная задача — скорее как короткая разминка перед очередным выходом в настоящий сетевой «шторм».
Но главным океаном для меня всё равно оставалась сеть передачи данных. В голове постоянно жила её топология: какие узлы через что включены, где находятся слабые места, какое оборудование стоит на периферии, какие сервисы проходят через конкретный участок и что недавно менялось. Это была не абстрактная память о схеме, а непрерывная модель работающей системы, которую приходилось обновлять каждый день.
Именно поэтому мне трудно смотреть на историю этой сети только как на последовательность технологий. Массовый широкополосный доступ строили и расширяли люди, часто в режиме предельной нагрузки и ответственности. Когда основной этап бурного строительства закончился, многие локальные специалисты постепенно исчезли из штатного расписания. Я не знаю всей внутренней экономики и кадровой логики большой компании и не хочу приписывать ей намерений, которых не могу доказать. Но со стороны человека, прошедшего этот период изнутри, контраст остаётся болезненным: сначала знания и самоотдача огромного числа связистов были критически необходимы для быстрого роста сети, а затем многие носители этих знаний оказались за пределами прежней профессии.
За каждым таким сокращением находилась не «единица персонала», а отдельная человеческая судьба. Особенно большое уважение у меня всегда вызывали не только инженеры и электромеханики связи,но электромонтёры связи: трудолюбие, дисциплина, физически тяжёлая работа, знание своего участка и готовность в любую погоду идти к линии или абоненту. Без них никакой красивой схемы СПД просто не существовало бы.
Nateks и эксплуатационное знание, которого нет в руководстве
За годы работы у меня сформировалось очень практическое отношение к производителям оборудования: не по известности бренда и не по заявленным характеристикам, а по тому, насколько спокойно это сетевое железо можно оставить работать круглые сутки в режиме 24/7 и насколько предсказуемо оно ведёт себя во время аварии.
Nokia D500 у меня до сих пор вызывает уважение. Siemens DSLAM имел свои особенности, но давал серьёзные возможности диагностики и управления. QTech и D‑Link для своих задач тоже запомнились хорошо: понятный синтаксис, нормальная функциональность, предсказуемая эксплуатация.
Совсем другие впечатления оставила часть оборудования Nateks. Это именно мой собственный опыт работы с конкретными устройствами и версиями ПО, а не универсальная характеристика всего производителя.
На части сетевого оборудования, находившегося у нас в боевой эксплуатации, было критически важно установить определённую версию программного обеспечения, иначе проявлялись серьёзные дефекты. После обновления часть проблем исчезала, но оставались особенности конфигурации, под которые приходилось приспосабливать реальные абонентские сервисы. Некоторые необходимые рабочие последовательности вообще не следовали из документации: опытным путём находишь способ, при котором устройство начинает вести себя устойчиво, фиксируешь его и дальше используешь в эксплуатации.
Иногда такие действия со стороны действительно выглядели как «танцы с бубном». Но если на этом оборудовании работают живые абоненты, сетевой инженер всё равно обязан научиться жить с этим железом.
Именно это я называю настоящим эксплуатационным знанием. Руководство объясняет, что команда должна делать. Инженер через несколько лет знает ещё и то, что конкретная версия устройства действительно сделает в реальной сети, какие у неё баги и как избежать ситуации, когда формально правильная конфигурация приводит к неправильному результату.
Huawei на шестнадцать портов
В какой‑то момент к нам передали небольшой Huawei на шестнадцать ADSL‑портов для установки на периферийном узле доступа. Три ADSL порта уже считались неисправными, поэтому фактически пользоваться можно было тринадцатью.
Передача оборудования между узлами была совершенно обычной практикой. Если где‑то после модернизации освобождалось устройство, способное решить проблему другого подразделения, оно могло уехать в другой узел и получить вторую жизнь.
Начальник Александр Николаевич с совершенно серьёзным видом постоянно произносил Huawei как «Хуйвей», что почему‑то неизменно нас веселило. DSLAM оказался ещё одним новым CLI и ещё одной собственной логикой конфигурации, но к тому времени после Nokia, Siemens, Cisco, QTech, D‑Link, Nateks и другого оборудования очередной командный интерфейс уже воспринимался примерно как новый диалект знакомого языка. Сначала находишь его внутреннюю логику, а затем начинаешь работать почти автоматически.
За годы работы мне пришлось освоить множество разных CLI, командных языков и синтаксисов конфигурирования. Называть всё это «языками программирования» было бы неправильно, но необходимость постоянно переключаться между совершенно разными системами существовала ежедневно. К этому добавлялись SQL, Linux, Windows‑инфраструктура, специализированное операторское ПО и серверные сервисы.
Со временем значительную часть привычных последовательностей я действительно набирал практически вслепую. На аварийном выезде открываешь ноутбук, подключаешь консольный кабель, видишь приглашение CLI — и пальцы уже сами начинают печатать команды. Коллег это иногда впечатляло, и я не стану делать вид, будто мне самому это было безразлично. Конечно, я собой гордился и, главное, чувствовал себя нужным и востребованным.
Длинные линии, школы и НУП
Не каждый объект можно было подключить по простой схеме «DSLAM — несколько километров меди — модем». Особенно сложными были удалённые школы и другие объекты.
На протяжённых медных направлениях использовалось специализированное оборудование класса FG‑PAM/FlexDSL и линейные регенераторы. В НУПах — необслуживаемых усилительных пунктах — находились промежуточные устройства, позволявшие передать цифровой сигнал на расстояние, уже проблемное для обычной DSL‑линии.
Одно такое направление особенно запомнилось сложностью запуска. Линия долго не хотела работать устойчиво. Приходилось последовательно разбирать весь тракт, работать с промежуточным оборудованием и искать режим, при котором связь перестанет постоянно падать. Диагностику дополнительно усложняли большие расстояния между участками тракта: на протяжении строительства СПД это вообще было обычной особенностью периферийных направлений. В итоге удалось получить стабильный канал примерно в 1 Мбит/с.
Сегодня такая скорость выглядит почти смешной, но инженерная победа состояла не в мегабитах. Победа состояла в слове «стабильно».
Интернет был далеко не единственной задачей
Через районную СПД работал не только массовый Интернет физических лиц. Были школы, отделения «Почты России», корпоративные клиенты, различные VPN, проекты для детей с инвалидностью, инфраструктура выборов, позднее видеотрансляция ЕГЭ.
Каждый такой проект имел собственную техническую логику. Где‑то нужно было организовать VPN и адресацию, где‑то настроить удалённый CPE, где‑то проверить устойчивость длинной последней мили, где‑то построить отдельный VLAN. В проекте видеотрансляции ЕГЭ приходилось работать уже с IP‑камерами, адресацией, видеопотоками и передачей изображения через операторскую сеть.
Этот пласт важен, потому что хорошо показывает: районная сеть была не просто способом открыть сайт дома. Через неё работали системы, для которых стабильность связи имела совсем другое значение.
Я намеренно не буду приводить реальные IP, адресные планы, номера клиентских VLAN, имена VPN и другие эксплуатационные детали старых проектов. Мы скрываем то, что позволяло бы эксплуатировать сеть, но сохраняем то, что позволяет понять, как она была спроектирована.
VLAN, VRF и MPLS
Для корпоративных подключений использовалась отдельная логическая сегментация. Трафик конкретного сервиса или клиента выделялся в собственный VLAN, а на маршрутизирующем уровне помещался в соответствующий VRF — отдельную таблицу маршрутизации.
Благодаря этому несколько независимых корпоративных сетей могли работать поверх общей физической инфраструктуры, оставаясь логически изолированными. На Cisco 7206 для подобных сервисов использовались subinterface, dot1Q, VRF, адресация, статическая маршрутизация и service‑policy.
В обезличенном виде принцип выглядел примерно так:
interface GigabitEthernet0/1.<VLAN>
encapsulation dot1Q <VLAN>
ip vrf forwarding <CUSTOMER-VRF>
ip address <ADDRESS> <MASK>
service-policy input <RATE-POLICY>
service-policy output <RATE-POLICY>
Реальные адреса, номера VLAN и имена клиентских VRF здесь намеренно удалены. Дальше трафик включался в MPLS‑инфраструктуру оператора. Одни и те же маршрутизаторы и коммутаторы могли одновременно обслуживать массовый Интернет, IPTV, служебную сеть управления и отдельные корпоративные VPN.
Физическая сеть была общей, но логически внутри неё существовало множество совершенно разных сетей.
Операторская сеть развивается слоями
Когда сегодня смотришь на историю сети, легко представить аккуратную последовательность: выключили dial‑up, поставили ADSL, затем построили FTTB и после этого получили 10G. В реальной эксплуатации так практически никогда не происходит.
Новые устройства устанавливаются рядом со старыми. Старое оборудование продолжает работать, пока выполняет нужную функцию. В одной серверной одновременно могут находиться системы нескольких технологических поколений.
На ранних схемах видны Cisco 3600/7200, Catalyst 3750E, Cisco AS5300, Nokia D500, Catalyst 2950G и серверная инфраструктура. Позднее появился Cisco 7604, затем центральная агрегация менялась снова. В разные периоды приходилось работать и с Linux‑системами; например, локальный шлюз узла работал на CentOS, а система мониторинга Nagios позднее — на FreeBSD.
К концу 2012 года в центральном узле уже фигурировали Juniper MX480, DWDM Huawei OptiX OSN 6800 и 10G, хотя рядом продолжали работать Nokia и Siemens DSLAM. Через несколько лет в одной серверной одновременно находились устройства Cisco разных поколений, Nokia, Siemens, Juniper, QTech, серверы IBM и множество другой техники.
Это и есть нормальная операторская жизнь. Новая технология редко убивает старую мгновенно — она просто становится ещё одним слоем.
FTTB и ETTH: казалось, теперь медные проблемы закончились
Следующим большим этапом стала Ethernet‑последняя миля. Проекты ETTH существовали уже примерно с 2010 года, а особенно масштабное строительство развернулось в 2012–2013 годах.
В Павловской сеть строили сразу крупными участками, охватывая целые кварталы многоквартирных домов. До дома приходила оптика, внутри устанавливался управляемый коммутатор, а до квартиры абонента оставался уже сравнительно короткий Ethernet‑сегмент по витой паре.
Архитектура принципиально отличалась от ADSL:
агрегация → оптический uplink → управляемый ETTH/FTTB‑коммутатор → Ethernet до квартиры.
Значительную часть конфигурационной работы этих коммутаторов выполнял я. Загружал и адаптировал конфигурации QTech, создавал необходимые VLAN, настраивал параметры PPPoE‑сервисов и multicast, конфигурировал uplink/trunk и абонентские порты. При этом мне было важно не просто добиться состояния «сейчас работает», а заранее подумать об эксплуатации: как сеть будет расширяться, насколько легко в ней найти неисправность, какие проблемы могут возникнуть при изменении топологии и сможет ли другой инженер через несколько лет понять логику конфигурации.
Все изменения сразу отражались в моих схемах. Для меня физическая топология, логическая конфигурация и документация всегда были частями одной системы. Если переносился коммутатор, менялся uplink или появлялся новый сервис, схема тоже должна была измениться.
На первый взгляд после ADSL должна была наступить практически идеальная жизнь. Нет многокилометровой медной линии до DSLAM, нет SNR Margin, Attenuation и взаимного влияния десятков DSL‑пар. До дома приходит оптика, затем обычный Ethernet. Казалось бы, если оптический uplink исправен, порт поднят и ошибок на нём нет, то что вообще может пойти не так?
Как выяснилось — довольно многое.
PPPoE пережил смену технологии доступа
Переход с ADSL на FTTB/ETTH не означал отказа от PPPoE. Менялась сеть доступа: вместо медной пары и DSLAM появились оптические линии и Ethernet-коммутаторы, но сама схема авторизации абонентов сохранилась.
При ADSL она выглядела примерно так:
ADSL-модем → DSLAM → сеть оператора → BRAS → PPPoE → AAA/RADIUS → биллинг
После перехода на FTTB/ETTH:
роутер → Ethernet → коммутатор доступа → агрегация → BRAS/BNG → PPPoE → AAA/RADIUS → биллинг
PPPoE не привязан к ADSL. Он может использоваться и в сетях FTTB/ETTH, и поверх GPON. Поэтому при модернизации сети оператору не обязательно менять уже существующую систему авторизации и биллинга вместе с технологией последней мили.
Именно так произошло и с нашей сетью. После перехода от ЮТК к Ростелекому и дальнейшего развития сети PPPoE никуда не исчез. В Краснодарском крае значительная часть абонентов Ростелекома и сегодня подключается по PPPoE с теми же привычными логином и паролем.
При этом у другого частного интернет-провайдера в Павловской используется совершенно другая схема. Сеть построена на GPON, PPPoE отсутствует, а абонент привязывается к сетевому окончанию или оборудованию. Получаются два разных подхода к решению одной задачи.
Параметр | PPPoE | Привязка к порту / ONT / роутеру |
Идентификация и авторизация абонента | По PPPoE-учётным данным через AAA/RADIUS | По сетевому окончанию, порту, ONT, MAC или другому идентификатору |
Зависимость от конкретного роутера | Обычно нет: можно перенести логин/пароль на другое устройство | Часто есть привязка к конкретному устройству, MAC, ONT или порту |
Удобство замены роутера | Достаточно внести учётные данные | Может потребоваться перепривязка у оператора |
Централизованная авторизация | Удобно реализуется через AAA/RADIUS | Реализуется через данные сети доступа |
Интеграция с биллингом | Пользователь и его сессия явно идентифицированы | Услуга связывается с портом, ONT, MAC или другим идентификатором |
Управление тарифом и профилем | На уровне абонентской сессии | По профилю порта, VLAN, DHCP/AAA или конфигурации доступа |
Состояние абонентской сессии | Есть отдельная PPP-сессия | Отдельной PPP-сессии нет |
«Зависшие» сессии | Возможны | Такой класс проблем отсутствует |
Накладные расходы | PPPoE/PPP overhead, типичный MTU 1492 | Нет PPPoE-overhead, обычно можно сохранить MTU 1500 |
Нагрузка на BRAS/BNG | Необходимо вести состояние PPP-сессий | Нет необходимости вести PPP-сессии |
Диагностика | Видно, поднята ли сессия, кто авторизован и когда подключился | Диагностика идёт через порт, ONT, DHCP, MAC, VLAN и другие признаки |
Смена технологии доступа | PPPoE/AAA можно сохранить при ADSL → FTTB/ETTH → GPON | Зависит от архитектуры конкретной сети |
У PPPoE есть реальный недостаток — дополнительный протокольный overhead и необходимость поддерживать состояние абонентских сессий. Отсюда же знакомая эксплуатационная проблема: линия и оборудование доступа могут быть полностью исправны, но Интернет не работает из-за зависшей PPPoE-сессии или проблемы с авторизацией.
У схемы без PPPoE этого класса неисправностей нет. Но появляется другая зависимость: абонент сильнее привязан к конкретному сетевому окончанию или оборудованию, и простая самостоятельная замена роутера уже может потребовать перепривязки со стороны оператора.
Поэтому сам по себе переход на FTTB, ETTH, FTTH или GPON не означает отказа от PPPoE. Технология сети доступа и способ идентификации и авторизации абонента — разные части операторской архитектуры.
Когда идеальная линия всё равно не означает работающий Интернет
Практически сразу после развития FTTB/ETTH стали возникать странные случаи деградации абонентских сервисов. Физический Ethernet работает, оптический uplink исправен, порт коммутатора находится в нормальном состоянии, конфигурация на первый взгляд правильная, но пользователь всё равно получает нестабильный Интернет или не может нормально авторизоваться. В моей практике регулярно встречались и зависшие состояния PPPoE‑ или учётных сессий в сервисно‑биллинговой цепочке. Поэтому биллинговые и связанные с авторизацией системы я всегда рассматривал как один из возможных уровней проблемы, но не как автоматически доказанную причину каждого такого случая.
И здесь Ethernet повторил главный урок ADSL: работающий физический уровень ещё не означает работающую услугу.
По моему тогдашнему эксплуатационному опыту часть подобных проблем по косвенным признакам находилась уже выше самой линии доступа — в области PPPoE, состояния сервисных объектов, авторизации и взаимодействия с централизованными системами. Значительная часть сервисной и биллинговой инфраструктуры находилась уже на краевом уровне, поэтому районный инженер мог полностью проверить свою сеть доступа, но не контролировал всю цепочку предоставления услуги.
Я не могу спустя столько лет доказательно отнести каждый такой случай к конкретному серверу или единственной причине, поэтому не хочу превращать эксплуатационное наблюдение в универсальный диагноз. Но сама картина повторялась достаточно часто: локальный Ethernet выглядит практически идеальным, а сервис всё равно приходится восстанавливать действиями, которые уже никак не относятся к кабелю или последней миле.
Иногда помогал restart абонентского порта или самого коммутатора, иногда приходилось заново проверять и переписывать VLAN и связанные интерфейсы. Бывали ситуации, когда формально правильная конфигурация начинала устойчиво работать только после её фактической пересборки. Я изучал поведение конкретных QTech и всей цепочки предоставления услуги и постепенно вырабатывал варианты конфигурации, которые именно в нашей сети давали наиболее устойчивый результат.
Снова возникал тот самый слой эксплуатационного знания, которого не существует на красивой принципиальной схеме. На бумаге всё предельно просто:
оптика → коммутатор → Ethernet → PPPoE → Интернет.
Реальная сеть знает состояния, о которых такая схема ничего не рассказывает.
С годами я вообще всё меньше верил в понятие «идеально простая технология». Сначала ADSL научил меня тому, что хорошая синхронизация ещё не гарантирует услуги. Затем FTTB показал то же самое уже на почти идеальной физической линии: оптика исправна, Ethernet‑link поднят, конфигурация выглядит правильной — а абонент всё равно остаётся без Интернета. Просто точка поиска неисправности переместилась выше по стеку.
Главный урок всех этих лет для меня оказался одинаковым и для ADSL, и для Ethernet, а намного позже — и для веб‑трафика: простая схема не означает простую эксплуатацию. Настоящая система начинается там, где заканчивается картинка из учебника.
“Какаду”, MOXA, Курс и Onyma
Работа районного IT‑инженера не заканчивалась на DSLAM и коммутаторах. Был, например, программно‑аппаратный комплекс с запоминающимся названием «Какаду», который использовался для автоматического обзвона абонентов с задолженностью.
Сервер работал в связке с оборудованием MOXA и несколькими аналоговыми телефонными линиями. Из АСР «Курс» формировалась выгрузка должников, затем с помощью SQL я подготавливал необходимые данные и импортировал базу в систему обзвона. После запуска несколько дней нужно было контролировать работу, обновлять информацию и следить за процессом. Позднее данные приходилось получать и из Onyma.
Я участвовал в сопровождении АСР «Курс», взаимодействовал с абонентским отделом, участвовал в закрытии периода, занимался Onyma, ARGUS и другим специализированным ПО.
Onyma тоже играла важную роль в предоставлении доступа в Интернет. Она была связана с PPPoE-авторизацией абонентов и биллингом. При подключении новых абонентов я регистрировал в Onyma выдаваемые им DSL-карты с логином и паролем, работал с лицевыми счетами и исправлял возникающие ошибки. Через Onyma приходилось разбираться и с уже работающими подключениями: сбрасывать зависшие сессии, исправлять некорректные начисления за услуги Интернета и IPTV, разбираться с ошибками в учётных записях и другими проблемами, возникавшими в процессе эксплуатации. При этом сама линия и оборудование могли быть полностью исправны: модем синхронизировался с DSLAM, VLAN работал, но абонент всё равно не мог выйти в Интернет из-за проблемы на уровне PPPoE-авторизации или учётной записи в Onyma. Со временем я обучил работе в Onyma других сотрудников Павловского узла связи, и обычные операции по подключению абонентов стали выполнять уже многие сотрудники.
Очень многому в работе с Onyma меня научила Светлана из отдела биллинга Краснодарского филиала. За годы работы возникло большое профессиональное доверие, и со временем мне предоставили повышенный уровень доступа к системе — более широкий, чем обычно был у сотрудников районных подразделений. Благодаря этому многие проблемы я мог исправлять самостоятельно, но и ответственность была выше. Onyma не работала отдельно от других систем: её процессы были связаны с АСР «Курс», в том числе в части начислений. Каждый месяц необходимо было выполнять закрытие периода и другие операции, связанные с биллингом. Эта работа не зависела от праздников и выходных, поэтому иногда работать приходилось и 31 декабря, и 1 января, и 1 мая.
Постепенно в Павловском узле я стал человеком, к которому обращались, когда в Onyma возникала какая-то нестандартная проблема или ошибка. Я сопровождал работу в системе абонентских отделов по физическим и юридическим лицам, обучал сотрудников, помогал разбираться с ошибками и исправлять их. Похожая ситуация была и с СПД. По мере накопления опыта мне предоставляли более высокий уровень доступа к Cisco Catalyst и маршрутизаторам. Это позволяло самостоятельно выполнять больше работ по настройке оборудования и устранять проблемы, для решения которых раньше требовалось обращаться к специалистам более высокого уровня. Если же с проблемой в Onyma я не мог разобраться сам или она находилась на уровне краевых систем, я обращался к Светлане. Она практически всегда помогала разобраться. Мне запомнились не только её знания и готовность помочь, но и её спокойный голос. Когда возникала сложная ситуация и я уже начинал нервничать, иногда достаточно было услышать её голос, чтобы успокоиться и продолжить разбираться с проблемой.
Прошло много лет, а мне до сих пор не хватает этого голоса и той поддержки, которую я тогда от неё получал. Позднее небольшой отдел биллинга Краснодарского филиала, в котором работала Светлана, был сокращён. А это были специалисты, которые много лет работали с Onyma и другими биллинговыми системами и хорошо знали их особенности. Вместе с сокращением таких подразделений терялись не только рабочие места, но и накопленные годами знания. Исчезали и прямые связи между специалистами: раньше районный инженер мог связаться с человеком, который хорошо знал конкретную систему, и вместе с ним разобраться с проблемой. В дальнейшем такие вопросы всё чаще проходили через более длинную цепочку взаимодействия между подразделениями, а некоторые из них в итоге так и оставались без решения.
Это ещё одна особенность районной эксплуатации. Ты не мог быть специалистом только по одной красивой технологии. Проблема появлялась там, где появлялась, и её всё равно кто‑то должен был решить.
Документация как внешняя память сети
Документировать подключения я начал практически с первых дней. Так появилась большая Excel‑таблица, которую я поддерживал много лет. Параллельно создавались Visio‑схемы, инструкции, рабочие заметки по особенностям оборудования.
В центральной серверной и на удалённых площадках я маркировал сетевые кабели, чтобы находящемуся возле стойки инженеру было понятно, откуда приходит конкретный линк и куда он уходит.
Это кажется мелочью только до первой серьёзной аварии. Когда перед тобой десятки одинаковых патч‑кордов, а другому человеку по телефону нужно объяснить, какой именно кабель переставить, хорошая маркировка внезапно превращается в очень важную технологию.
Со временем таблицы, Visio‑схемы, инструкции и бирки на кабелях стали фактически внешней памятью сети. Потому что держать в голове абсолютно всё невозможно.
ЗИП, Краснодар и немного Нострадамуса
Запасные части далеко не всегда лежали на складе и спокойно ждали нужной аварии. ЗИП часто формировался из старого, но исправного оборудования, снятого во время модернизаций.
Сегодня коммутатор кажется ненужным, а через несколько лет именно он спасает центральный или периферийный узел доступа к Интернету. Если нужного оборудования в Павловской не было, приходилось ехать за ним на вышестоящий узел в Краснодар. Иногда ночью.
С периферийными площадками существовала другая проблема: расстояние до некоторых составляло десятки километров. Если приехать на место и обнаружить, что кроме предполагаемого SFP требуется ещё блок питания или другой коммутатор, можно потерять несколько часов.
Поэтому перед выездом приходилось мысленно проигрывать несколько сценариев отказа и брать с собой всё, что теоретически могло пригодиться. Инженеру перед аварийной поездкой иногда приходилось немного становиться Нострадамусом.
Азовский район. Два часа ночи
Один аварийный выезд особенно хорошо остался в памяти. Примерно в два часа ночи перестал отвечать узел доступа в Азовском районе станицы Павловской. Позвонил оперативный дежурный. Была холодная осенняя ночь, шёл дождь.
Мы с инженером станционной группы приехали в Азовский район. Оборудование узла доступа находилось в уличном телекоммуникационном шкафу. Когда открыли дверь, вода буквально полилась сверху. Внутри находились оптика, Catalyst, Siemens Surpass HiX и другое оборудование. Практически всю оставшуюся ночь пришлось работать возле этого шкафа с ноутбуком под дождём.
Catalyst вышел из строя. Нашли подходящий запасной коммутатор, но готовой актуальной конфигурации под рукой не было. И здесь знания Cisco IOS было уже недостаточно. Нужно было понимать эту конкретную сеть: какие VLAN куда идут, какой downstream находится за каким портом, где management, что должно быть trunk, а что access.
Я восстанавливал конфигурацию по собственной схеме сети и по памяти топологии этого участка. Примерно к шести утра мы закончили работу и восстановили Интернет в Азовском районе. Когда мы вернулись мокрые насквозь и заносили из машины на центральный узел сетевое железо, инструменты и остальные вещи, ко мне подошёл оперативный дежурный Василий. Смысл его слов я запомнил примерно так: «Славик, я много лет работаю в связи и видел ребят, которые вот так же отдавали работе всего себя. А потом их не стало здесь, и оказалось, что они никому не нужны». Тогда я отнёсся к этим словам скептически и не понимал, почему он говорит это именно мне. Спустя годы, когда моя собственная работа в узле закончилась, я не раз вспоминал тот разговор. Теперь он воспринимается почти как предупреждение, смысл которого я понял намного позже.
Документация Cisco может рассказать, как настроить trunk. Однако она не знает, что находится за конкретным портом конкретного Catalyst в уличном шкафу Азовского района станицы Павловской, какие особенности есть у конкретного оборудования и где находятся подводные камни, известные только людям, которые годами строили и эксплуатировали эту сеть. Вот для этого и нужен человек, который много лет работает с собственной сетью и знает её почти как самого себя.
Nagios: увидеть сеть целиком
Когда количество оборудования выросло, понадобился постоянный мониторинг. Nagios работал на сервере FreeBSD.
Мы не пытались превратить его в огромную систему телеметрии. Главная задача была практической: видеть доступность узлов и понимать топологические зависимости.
Дежурный видел карту. Зелёное — работает. Красное — нужно разбираться. Очень полезными были parents: если пропадает один DSLAM — одна ситуация, а если исчез вышестоящий коммутатор и вместе с ним становятся недоступными все устройства ниже, мониторинг сразу показывает, что десять DSLAM не могли одновременно сломаться независимо друг от друга. На рабочем месте оперативного дежурного мы сделали и звуковое оповещение: если ночью какой‑то сегмент СПД переходил в DOWN, Nagios включал сирену.
Сохранившаяся конфигурация 2016 года позволяет оценить масштаб системы: порядка 115 пользовательских сетевых объектов, среди них около сорока DSLAM, примерно пятьдесят FTTX‑устройств и несколько десятков элементов доступа и агрегации. Обычная проверка выполнялась примерно раз в пять минут, повторная после ошибки — быстрее.
Это тоже была сеть. Не ради красивого графика, а чтобы ночью понять, куда ехать.
«228 на приёме»
Одним из людей, без которых для меня вообще невозможно представить ни Павловский узел связи, ни саму связь тех лет, ни мои воспоминания о ней, был Сергей — оперативный дежурный. Именно дежурный одним из первых видел крупную аварию, следил за мониторингом и звонил инженерам, когда очередной участок района переставал отвечать.
У Сергея была характерная фраза: «228 на приёме», но Сергей был далеко не просто человеком перед экраном Nagios. Он был талантливым радиолюбителем, самостоятельно создавал радиоэлектронное оборудование и усилители, строил огромные антенны и занимался дальней радиосвязью. Доходило даже до связи с использованием отражения сигнала от Луны. Мы часто общались у него дома, и я восхищался системой управления поворотом радиоантенны: с помощью джойстика он управлял большой антенной, установленной на крыше пятиэтажного многоквартирного дома. У него был собственный радиолюбительский позывной. Я специально не буду приводить его здесь, но самое удивительное, что спустя столько лет всё ещё помню его наизусть. Сергей мог возиться со своим оборудованием, работать в эфире, что‑нибудь настраивать, а мы разговаривали. Для него радиотехника была не хобби в смысле «купил готовую коробку и нажал кнопку». Это был мир, который он строил собственными руками.
ПТЛ — отдельная инженерная цивилизация
На третьем этаже существовал ещё один удивительный мир — ПТЛ, производственно‑техническая лаборатория. Там работали инженеры с фундаментальной подготовкой в электронике, КИП и схемотехнике.
На рабочих столах лежали платы, микросхемы, транзисторы, конденсаторы, измерительные приборы и паяльные станции. Эти люди не были специалистами, которым разрешено лишь вынуть неисправный модуль и поставить новый. Они понимали, что происходит внутри устройства, могли найти неисправность на уровне схемы, отремонтировать оборудование, собрать электронный узел или печатную плату под конкретную задачу связи.
Особенно хорошо я помню Николая Алексеевича и Валерия Николаевича. Иногда они до сих пор мне снятся: будто я снова открываю дверь ПТЛ, а они сидят среди паяльников и электронных компонентов, поднимают голову и улыбаются. В мире схемотехники они чувствовали себя примерно так же, как хороший капитан чувствует себя в море. Некоторые устройства, которые они собирали или ремонтировали, возможно, работали ещё много лет после того, как прежнего коллектива уже не стало. Людей можно убрать из штатного расписания значительно быстрее, чем перестают работать результаты их рук.
Пятницы в СЮК
Был и ещё один инженерный мир, формально вообще не относившийся к нашему узлу связи. По пятницам мы с двумя моими близкими коллегами часто заходили в «Сервис Юг ККМ», который все называли просто СЮК.
В то время эта организация занимала очень сильные позиции в районе по ремонту и техническому обслуживанию контрольно‑кассовой техники. Там собиралась удивительная компания инженеров. Вокруг лежали разобранные кассовые аппараты, платы, микросхемы, паяльники, программаторы и инструменты. После окончания рабочего дня на столе иногда появлялось и кое‑что уже совсем не из мира электроники, но разговор удивительным образом всё равно быстро возвращался к технике.
Это были очень умные люди с острым инженерным мышлением. Многие сначала были друзьями моих коллег, а постепенно стали и моими. Именно среди таких людей я чувствовал себя совершенно естественно.
Позднее инженерное ядро СЮК стало исчезать. Насколько я помню те события, сокращения начались ещё в то время, когда обычные ККМ стояли практически в каждой торговой точке и организация занимала очень сильное положение в Павловском районе. Постепенно специалисты СЮКа, на которых держались ремонт и техническое обслуживание, были сокращены, а вместе с этим стало исчезать и прежнее положение «Сервис Юг ККМ» на местном рынке.
Я не знаю внутренней экономики организации и не хочу спустя годы приписывать её дальнейшую судьбу одной единственной управленческой причине. Но для меня это был ещё один пример закономерности, которую позднее я видел неоднократно: инженерную команду можно довольно быстро сократить на бумаге, а вернуть накопленную ею компетенцию значительно сложнее.
Музыка после сетей
С этими же коллегами нас связывала не только работа. На выходных мы могли собраться дома и несколько часов смотреть концерты W.A.S.P., Aerosmith, Metallica, Motörhead и других hard rock и heavy metal групп.
Сегодня кому‑то эта деталь может показаться совершенно ненужной в статье о DSLAM и узлах доступа, но для меня — нет. Сеть строят не названия должностей, а конкретные люди, которые живут своим делом и отдают ему большую часть жизни. Днём вы спорите о причине сетевой неисправности, ночью вместе поднимаете удалённый узел, а на выходных слушаете музыку.
Так коллеги постепенно становятся близкими друзьями.
Пломбир на третьем этаже
Есть один совсем маленький эпизод, который тоже очень хорошо сохранился в памяти. На втором этаже находился абонентский отдел, а третий был в основном нашим техническим миром.
Однажды я купил сразу много обычного пломбира и принёс его на третий этаж, чтобы раздать коллегам. Никакой программы улучшения корпоративной культуры за этим не стояло — просто захотелось сделать людям приятное.
Реакция оказалась неожиданно сильной. Все искренне обрадовались, а через некоторое время уже кто‑то другой принёс мороженое для остальных. Потом ещё кто‑то, и так неожиданно появилась маленькая традиция.
Мне очень хорошо запомнился этот простой эффект: добро иногда распространяется. Один человек сделал что‑то приятное другим, и другим захотелось сделать то же самое.
«Бригада X»
Когда проектировалась или серьёзно перестраивалась сеть передачи данных, мы могли собираться в кабинете начальника Александра Николаевича. Он внимательно выслушивал каждого. Станционные инженеры смотрели на проблему со своей стороны, линейные специалисты — со своей, я — со стороны сети и программной конфигурации.
Никто не может знать абсолютно всё, но каждый хорошо знал собственную область, и именно поэтому вместе мы могли решать задачи, которые одному человеку было бы сложно даже правильно диагностировать.
Иногда я называл нас про себя «бригадой X». Работали без шума и пыли. Решить техническую проблему было для нас не просто служебной обязанностью, а вопросом профессионального достоинства. Оставить пользователя с плохо работающим Интернетом, если ты понимаешь, что неисправность существует и её можно найти, считалось просто неправильным.
Когда сеть работала устойчиво и срочных задач не было, могла найтись минутка и на Counter‑Strike. Это не отменяло отношения к работе. Скорее наоборот: мы прекрасно знали, что в любую секунду зелёная карта Nagios может покраснеть, зазвонит телефон и вся спокойная жизнь закончится. Это было лучшее время моей жизни. Я был счастлив и видел такое же ощущение увлечённости делом у своих коллег по цеху связи.
Такая инженерная культура не описывалась отдельным приказом. Она существовала в людях.
«Слава, Слава, Слава! Ну что, пошло?»
Многие работы заканчивались одним и тем же коротким диалогом. Пока я находился возле оборудования или сидел за консолью, Сергей из дежурной следил за восстановлением связности. Телефон мог зазвонить несколько раз:
— Слава, Слава, Слава! Ну что, пошло? Пошло?
Если конфигурация наконец была закончена, оборудование поднялось и трафик действительно пошёл, я отвечал:
— Пошло, Серёга. Пошло.
Сергей рапортовал Александру Николаевичу, и где‑то рядом уже слышалось его характерное удовлетворённое:
— Добро, добро, добро...
В нескольких словах умещался итог иногда многих непрерывных часов ответственной работы. Для человека со стороны просто снова появился Интернет. Для нас «пошло» означало, что найден отказ, восстановлена или перестроена конфигурация, поднялось оборудование и можно наконец считать задачу законченной.
Районный инженер — не «недо‑DevOps»
Когда я начал собирать эту статью, у меня периодически возникала мысль: а что вообще подумает Хабр? Здесь множество специалистов, занимающихся сложнейшим программным обеспечением, высоконагруженными платформами, распределёнными системами. На этом фоне инженер районного узла связи может кому‑то показаться специалистом слишком «низкого» уровня.
Тем не менее я считаю, что такая постановка вопроса сама по себе некорректна. Это просто другая инженерная модель.
В небольшой региональной технической команде ширина компетенций становилась частью профессии. Сегодня ты конфигурируешь DSLAM, завтра восстанавливаешь Catalyst, затем разбираешь корпоративный VPN, проверяешь Nagios, работаешь с АСР, запускаешь ETTH‑коммутатор, диагностируешь длинную xDSL‑линию, а ночью едешь на удалённый узел с ноутбуком и консольным кабелем.
Такой специалист может не быть разработчиком JVM, ядра Linux или экспертом по современной CI/CD‑инфраструктуре. Но он получает другой тип опыта: способность видеть реальную техническую систему целиком и доводить проблему от первого непонятного симптома до работающего результата.
Александр Николаевич во многом воспитал во мне отношение к работе, которое осталось со мной до сих пор: техническую задачу нужно доводить до результата, а проблему нельзя игнорировать только потому, что она сложная или неприятная. Неважно, какую музыку ты слушаешь дома, как одеваешься и чем занимаешься в свободное время. На работе есть простой вопрос: решил ты поставленную задачу или нет.
Когда всё сделано и связь работает, можно спокойно закончить день — завтра сеть всё равно принесёт новое море технических задач. Когда я пришёл в связь, мне было чуть больше двадцати лет, и значительную часть своей молодости я отдал Павловскому узлу связи. В 33 года потерять работу и коллектив, которыми я жил, оказалось для меня тяжёлым испытанием.
Большой Интернет строился не только в столичных дата‑центрах. Он строился и в районных узлах связи, небольших городах и станицах — руками специалистов, чьи имена обычно остаются за кадром.
Схему можно передать. Десять лет памяти — нет
Позднее модель работы всё больше централизовалась. Типовые обращения стали уходить на единые линии поддержки. Сам по себе call‑центр не является чем‑то плохим: забытый пароль действительно незачем сразу передавать сетевому инженеру.
Но сложная неисправность всё равно в какой‑то момент должна попасть к человеку, который понимает конкретную сеть. И здесь возникает фундаментальная проблема: нельзя полностью централизовать знание распределённой физической инфраструктуры.
Сама сеть остаётся в конкретных станицах, шкафах, кроссах и серверных. Я помнил не абстрактную «СПД Павловского района», а конкретные направления, особенности удалённых узлов, проблемные линии, историю модернизаций, старые нестандартные решения.
Часть этого можно нарисовать, часть можно записать, но очень большой пласт эксплуатационного знания существует только в голове инженера.
Схему можно передать. Конфигурацию можно скопировать. Десять лет эксплуатационной памяти инженера одной командой скопировать нельзя.
Люди на периферии, без которых этой сети не существовало
Когда сегодня смотришь на старую схему СПД Павловского района, на ней видны названия станиц, узлы доступа, линии и оборудование. Но на настоящей сети за каждой такой точкой стояли конкретные люди. В Новопетровской, Новолеушковской, Старолеушковской, Незамаевской, Атаманской и других населённых пунктах района работали местные электромонтёры связи и другие технические специалисты. Они обслуживали линии и станционное оборудование своих населённых пунктов и были нашей постоянной опорой при строительстве сети, модернизациях и устранении аварий.
Володя из Новопетровской почти всегда встречал нас с улыбкой и своей фразой: «Специалисты из района приехали». Он смотрел на нас с восхищением, а я точно так же с восхищением смотрел на него. Володя знал каждую медную пару, практически каждого абонента, каждый роутер, каждую муфту и историю местной сети. Достаточно было назвать проблему, и он уже понимал, где искать.
Связь вообще редко существует в виде идеально прямой линии из учебника. Реальная сеть проживает десятилетия: её достраивают, перекроссируют, ремонтируют после аварий, переносят, соединяют со старой инфраструктурой. В ней неизбежно появляются временные решения и те самые инженерные «костыли». На схеме они могут выглядеть одной линией, а на местности историю каждого такого решения часто знает только человек, который сам когда‑то его сделал и потом много лет вместе с этой сетью жил.
В Старолеушковской работали два электромонтёра, которые неизменно поднимали настроение своими шутками. При этом свою сеть они знали буквально наизусть: где и как проходит каждая линия, что находится на станции, как скроссирован конкретный абонент, что когда‑то менялось и почему было сделано именно так. Они знали не только оборудование — они знали историю своих абонентов и самой сети.
Когда нужно было устранить проблему с Интернетом в какой‑нибудь школе или на другом объекте на периферии, помощь местного специалиста иногда ускоряла работу в разы. Нас встречали, сразу везли куда нужно, проводили к нужной линии, кроссу или оборудованию, подсказывали историю подключения. Я только начинал формулировать мысль, а человек уже понимал, что понадобится дальше, и сам предлагал, как сделать быстрее и лучше.
Пётр из Незамаевской особенно запомнился отношением к своему узлу. Там была практически образцовая чистота. Подходишь к зданию связи, заходишь внутрь — всё блестит, а у входа стоят специальные прорезиненные тапочки, в которые нужно переобуться. Но дело было не только в чистоте. Мы понимали друг друга с полуслова, иногда почти без слов: я ещё только успевал подумать о следующем действии, а нужная вещь уже была рядом.
Саша из Новолеушковской был очень серьёзным и ответственным специалистом. Он тоже знал свой участок наизусть. Когда я конфигурировал в Новолеушковской DSLAM или коммутатор, Саша мог переживать за происходящее так, будто в этот момент решалась судьба всей Вселенной. Это была настоящая личная ответственность за связь своего населённого пункта.
Поездки на периферию Павловского района для меня и многих других инженеров часто становились отдушиной. Там нас встречали простые, открытые люди и при этом сильнейшие практики, которым не нужно было долго объяснять, зачем ты приехал. У каждого была своя территория ответственности, и каждый воспринимал её почти как личное хозяйство.
Позднее большинство этих местных должностей было сокращено. От прежней распределённой сети специалистов по станицам осталось очень мало, а значительную часть работ стала выполнять выездная модель обслуживания. У такой организации может быть своя экономическая логика, но вместе с людьми из сети ушёл огромный объём локальной эксплуатационной памяти, который невозможно положить на склад или мгновенно передать следующей бригаде.
Именно поэтому фраза «схему можно передать, конфигурацию можно скопировать» для меня относится не только к моей работе. Она относится ко всему району. Можно передать карту линии. Но нельзя одной командой скопировать десятилетия памяти человека, который знает, где лежит каждая муфта, как менялась конкретная пара, почему когда‑то сделали именно такую перекроссировку и что на самом деле скрывается за одной аккуратной линией на схеме.
Как менялся коллектив
Вместе с организацией постепенно менялась и атмосфера между людьми. В первые годы мы действительно были очень близки: ходили друг к другу домой, собирались после работы, знали семьи друг друга, проводили вместе выходные.
Потом начались реорганизации, оптимизация численности и постоянная неопределённость. Когда человек годами не знает, останется ли его должность завтра, отношения начинают меняться. Люди всё реже встречаются вне работы, становятся осторожнее, меньше доверяют друг другу.
Я видел, как страх потерять место способен менять совершенно нормальных людей. Там, где раньше был товарищ, иногда начинает появляться потенциальный конкурент за остающуюся должность.
Я не хочу обвинять в этом каждого конкретного человека. Мне кажется, проблема глубже: среда тоже воспитывает коллектив. Когда она поощряет взаимопомощь, люди начинают носить друг другу мороженое. Когда система годами заставляет бояться следующего сокращения, постепенно возникает совсем другая модель отношений.
«Отдел мотивации»
Особенно своеобразно на этом фоне звучало слово «мотивация». Насколько сохранилось в моей памяти, в структуре краевого филиала существовало подразделение с названием «отдел мотивации».
Сегодня у меня нет документов, позволяющих восстановить его официальный функционал, поэтому приписывать этому подразделению конкретные решения я не буду. Но само название осталось в памяти именно из‑за контраста.
Где‑то существовала «мотивация», а инженер на месте всё чаще думал, не исчезнет ли завтра его должность. Возможно, сверху управленческая логика выглядела совершенно иначе. Я видел её результат снизу — из районного узла связи.
Для меня это стало одним из примеров того, насколько по‑разному может выглядеть «эффективность» в финансовой таблице и в реальной технической системе.
Когда должность исчезает, а работа остаётся
В конце 2014 года я получил уведомление о сокращении моей штатной единицы инженера‑программиста. Позднее сокращение официально отменили, но практически одновременно мне дали понять, что вопрос, скорее всего, лишь откладывается и новую работу всё равно стоит искать.
Местное руководство, которому моя работа, как мне тогда казалось, действительно была нужна, инженерной должности для меня не выделило. Вместо этого в 2015 году меня перевели на освободившуюся неинженерную должность, которая не соответствовала фактически выполняемым мной функциям и обязанностям.
Одновременно с этим мне стало известно, что в Павловский узел связи был оформлен сотрудник из вышестоящего подразделения. При этом, насколько я помню, непосредственно в Павловском узле связи его никто из нас фактически не видел. Я не знаю всех кадровых и организационных причин этого решения, поэтому не хочу приписывать ему мотивы, которых не могу доказать. Но для меня тогда ситуация выглядела достаточно красноречиво: инженерной должности для человека, который много лет фактически выполнял эту работу на месте, не нашлось.
К тому времени Александр Николаевич уже не руководил подразделением. Новый начальник дал мне совершенно конкретное поручение: обучить моей работе шестерых коллег, подготовить для них инструкции и фактически написать учебные материалы по тем задачам, которыми я занимался.
Именно этот момент окончательно заставил меня задуматься о происходящем. Формально инженерной должности у меня уже не было, но сама инженерная работа никуда не исчезла. Более того, знания и эксплуатационный опыт, которые я накапливал в течение многих лет, теперь требовалось в максимально короткие сроки передать сразу нескольким другим сотрудникам.
Я не могу утверждать, что целью этого решения изначально было именно подготовить мою окончательную замену: внутренних кадровых планов я не видел. Но изнутри происходящее воспринималось именно так. Сначала исчезает должность, затем человека переводят на работу, не соответствующую его фактическим обязанностям, а после этого просят распределить накопленные им знания между теми, кто останется в подразделении после его ухода.
Получалось, что моя должность организации уже была не нужна, а мои знания — всё ещё были нужны.
Я по‑прежнему занимался DSLAM, Nagios, ETTH, сетевым оборудованием, VPN, PPPoE, VLAN, multicast и другими задачами. Изменилось название должности, но маршрутизаторы и абонентские сервисы приказов о реорганизации не читали.
Я оставался там ещё почти два года. Наверное, потому, что до последнего надеялся каким‑то образом вернуться к нормальной инженерной работе и не хотел уходить из места, которому отдал столько лет.
В 2017 году моя работа там окончательно закончилась. Это не было добровольным решением однажды проснуться и выбрать новую карьеру. Это был вынужденный разрыв с местом, из которого сам я, скорее всего, никогда бы не ушёл.
Когда у старой сети появился оптический конкурент
После моего ухода в Павловской всё заметнее стал развиваться местный частный провайдер Гуднэт. Насколько я помню развитие событий, в Павловской он сделал ставку именно на строительство собственной оптической инфраструктуры и подключение абонентов по GPON.
Для районного рынка это был серьёзный технологический скачок. ADSL к тому времени уже много лет пытался получить максимум из старого телефонного кабельного хозяйства: качество зависело от длины и состояния медной пары, затухания, помех, соединений и множества других факторов. GPON решал последнюю милю совсем иначе.
По ключевым характеристикам для массового широкополосного доступа — доступной скорости, запасу дальнейшего развития и независимости от большинства типичных проблем длинной телефонной меди — это был уже другой технологический класс. Когда‑то ADSL безоговорочно выигрывал у dial‑up, а теперь примерно в таком же положении относительно новой оптической инфраструктуры оказался уже сам ADSL.
Особенно хорошо мне запомнилась последовательность событий. До появления заметного местного конкурента массового строительства GPON “Ростелекомом” в Павловской я практически не видел. Когда Гуднэт начал активно строить оптику и подключать абонентов, «Ростелеком» тоже стал значительно активнее разворачивать GPON в станице.
Со стороны человека, много лет наблюдавшего эту сеть изнутри, это выглядело так, будто появление реальной конкуренции заметно ускорило технологическую модернизацию.
Я не могу утверждать, что без Гуднэта «Ростелеком» никогда не построил бы здесь GPON — внутренних инвестиционных планов компании я не знал. Но в моём восприятии ответное строительство началось уже тогда, когда местный конкурент успел выйти на рынок с современной оптической технологией и начал активно набирать абонентов.
Для района это означало ещё одну важную вещь: исчезла прежняя фактическая безальтернативность. У человека появился выбор не просто между тарифами, а между разными операторами и разной инфраструктурой.
И здесь история снова возвращает меня к одному и тому же выводу. Физическая распределённая сеть имеет локальную специфику. Чем ближе инженер находится к этой сети и чем лучше знает конкретную местность, оборудование и историю инфраструктуры, тем быстрее во многих случаях можно понять настоящую причину неисправности.
Возвращение, которое не состоялось
Спустя много лет произошла история, после которой я особенно ясно понял: вернуться можно в здание, но невозможно вернуться в прежнее время.
Мне понадобилась характеристика с бывшего места работы. Я обратился за помощью к Александру Николаевичу, который к тому времени давно был на пенсии. В результате я оказался у руководителя соседнего подразделения. Он вспомнил меня и неожиданно предложил работу — ведущим инженером в Павловском узле связи.
Для меня это прозвучало почти нереально. После стольких лет снова открыть ту тяжёлую дверь, услышать шум вентиляторов серверной, вернуться к сети, снова увидеть близких мне когда‑то людей и единомышленников — фактически вернуться в тот дом, которому я посвятил значительную часть своей жизни. На несколько дней мне действительно показалось, что это возможно.
Я передал документы в кадровую службу, начался процесс оформления. А затем руководитель позвонил мне и сообщил, что против моего возвращения выступили двое бывших коллег — те самые люди, с которыми когда‑то мы годами работали плечом к плечу и составляли одну техническую команду.
Речь шла не о посторонних сотрудниках и не о людях, которые сомневались в моей квалификации. Оба прекрасно знали, как я работал, знали мой профессиональный уровень, много лет видели меня в реальных авариях, при вводе оборудования и решении сложных проблем. Мы были близкими друзьями и вне работы: встречались, ходили друг к другу, проводили время одной компанией, вместе бывали в СЮК.
Когда‑то это были люди, которых я считал очень близкими.
Почему спустя годы они выступили против моего возвращения, я знать наверняка не могу. Я описываю этот разговор так, как его передал мне руководитель; позиции самих этих людей у меня нет. Мне остаётся только собственное восприятие произошедшего. Мне показалось, что бывший товарищ и единомышленник к тому времени мог восприниматься уже прежде всего как конкурент за одно из немногих оставшихся мест.
На несколько дней дверь в прежний мир будто снова открылась, а потом закрылась второй раз. И удар оказался неожиданно сильным.
Наверное, тогда я окончательно понял: тот Павловский узел связи, куда мне хотелось вернуться, существовал не только в здании, стойках и должностях. Он существовал прежде всего в людях и в отношениях между ними.
А этого мира в прежнем виде уже не было.
Девять лет спустя я снова увидел ту же последнюю милю
В августе 2026 года, уже во время работы над этой статьёй, произошло странное совпадение. Мне позвонил двоюродный брат и попросил помочь с домашним Интернетом.
На месте я увидел старый D‑Link 2540, который сам настраивал ему примерно пятнадцать лет назад. Нашёлся более новый TP‑Link с Wi‑Fi, и сначала казалось, что достаточно просто заменить домашнее оборудование.
Но практически сразу стало понятно, что проблема находится не в роутере. DSL‑синхронизация устанавливалась нестабильно: одна успешная попытка могла перемежаться несколькими неудачными. Показатели линии вызывали вопросы, downstream составлял несколько мегабит, а после поднятия DSL‑link трафик шёл со значительными потерями пакетов. Одновременно нормально не работала и обычная аналоговая телефония.
И здесь возникло почти физическое ощущение дежавю. Я прекрасно знал, через какой участок старой сети приходит эта линия. Абонент был подключён через тот самый узел доступа в Азовском районе Павловской, где когда‑то ночью под дождём мы восстанавливали Catalyst и оборудование доступа.
Я прекрасно понимал, что проверял бы тогда: DSL‑порт, профиль, SNR Margin, Attenuation, ошибки, историю синхронизации. При необходимости попробовал бы другой DSL‑profile, одновременно попросив линейных специалистов проверить медную пару, кросс и соединения.
Но теперь у меня не было доступа к DSLAM. Я уже девять лет там не работал.
После долгого ожидания первая линия поддержки зарегистрировала обращение, а ближайший возможный визит специалиста оказался почти через две недели. Я подробно описал технические симптомы, но из разговора не услышал ничего, что позволило бы понять, выполнялась ли в этот момент глубокая диагностика конкретного DSL‑порта со стороны сети.
Для меня ситуация получилась почти символической. Когда‑то подобная проблема запускала бы целую цепочку местной работы: я проверяю сетевое оборудование и DSLAM, станционные инженеры — оборудование и кросс, линейные специалисты — последнюю милю.
Теперь я смотрел на тот же DSL с другой стороны — как обычный пользователь, которому остаётся ждать назначенного выезда.
Неподалёку я при этом видел уже строящуюся оптическую инфраструктуру. На вопрос о возможности перевести конкретный дом на оптику в поддержке сообщили, что технической возможности пока нет.
Я не хочу делать из одного обращения статистику по огромной компании. Но как личный эпилог к истории о локальной инженерной эксплуатации этот случай оказался почти слишком точным.
Когда локальная эксплуатация позволяла решать инцидент за минуты
В наиболее простых случаях инцидент отдельного абонента мог занимать от нескольких минут до получаса — не потому, что неисправности были примитивными, а потому, что все участники цепочки находились рядом с сетью и разговаривали напрямую. Если проблема возникала, например, в Старолеушковской, местный электромонтёр мог позвонить мне уже из дома абонента, находясь возле его оконечного оборудования.
Пока электромонтёр по моей просьбе проверял роутер, ADSL‑ или SHDSL‑модем, кабель или кросс, я одновременно проходил соединение со стороны сети: порт доступа, DSL‑параметры, VLAN, коммутаторы агрегации, PPPoE и вышестоящие узлы. За годы эксплуатации многие сочетания симптомов стали узнаваемыми. По характеру ошибки, состоянию порта, изменению счётчиков или поведению сессии уже возникало несколько наиболее вероятных гипотез, которые можно было проверять последовательно, не начиная каждый раз диагностику с нуля.
Особенно ценным было то, что местный специалист знал физическую сторону подключения, а я — логическую и сетевую. Эти две картины складывались прямо во время одного телефонного разговора. Поэтому вопрос не путешествовал по нескольким очередям заявок: человек возле абонента и человек возле сетевой консоли одновременно смотрели на разные концы одной и той же цепочки.
Для корпоративных и социально значимых проектов эта эксплуатационная память была ещё важнее. Школы, отделения почты, банковские и другие объекты, отдельные социальные проекты работали через VPN/MPLS и могли включать PE, VRF, несколько промежуточных узлов и специфическое оконечное оборудование. Формальную топологию можно было увидеть в документации, но реальные особенности конкретного пути — старое оборудование, нестандартный участок, известный дефект, особенность линии или временно оставленное решение — часто знали только люди, которые этот путь сами строили и много лет сопровождали.
Сейчас я смотрю на эту систему уже со стороны абонента и бывшего инженера. Мне известны отдельные случаи, когда простое пользовательское обращение растягивается на многие дни, а нетипичная корпоративная задача требует длинной цепочки эскалаций между подразделениями. Я видел и ситуации, когда подключение дополнительной услуги или изменение схемы доступа ожидалось неделями. Это мой личный опыт наблюдения, а не статистическое исследование всего «Ростелекома» в Краснодарском крае. Бывшие коллеги, с которыми я продолжаю общаться, рассказывают о похожей картине: один инцидент может проходить через несколько уровней и информационных систем, многократно переадресовываться между подразделениями, тогда как сам абонент всё это время остаётся без нормально работающей услуги. На фоне многолетнего сокращения районного инженерно‑технического персонала возникает парадокс: количество формальных этапов обработки обращения растёт, а локального специалиста, который знает конкретный узел, линию и историю подключения и способен сразу начать техническую диагностику, становится меньше. В результате внутренние показатели обработки заявок могут существовать сами по себе, не совпадая с тем, что абонент воспринимает как главный результат: связь либо восстановлена, либо нет.
Но именно здесь для меня проявляется принципиальная цена централизации. Я не считаю сокращение местных технических специалистов доказанной «экономической эффективностью» только потому, что уменьшается штат. По моим воспоминаниям, в прежней районной модели в узле работали сотни людей разных специальностей, а сама эксплуатация была значительно ближе к оборудованию и абоненту. Позднее объём и технологическая сложность услуг выросли на порядки — к телефонии добавились массовый Интернет, VPN/MPLS, IPTV, Ethernet‑доступ и другие сервисы, — однако локальный технический штат при этом последовательно сокращался. Для меня это не выглядит простым движением от «неэффективной» системы к эффективной. Это переход к другой организационной модели, в которой часть затрат на людей действительно убирается из района, но одновременно теряется локальная эксплуатационная память и увеличивается дистанция между неисправностью и инженером, способным разобраться с ней на месте. Чем сложнее конкретная авария и чем больше в ней особенностей последней мили, коммутации, маршрутизации и истории данного узла, тем заметнее становится цена этой потери.
Провайдер существует не только для того, чтобы продать услугу
Для уже подключённого человека качество провайдера определяется очень просто: Интернет работает или нет, работает хорошо или плохо.
Продажа заканчивается после заключения договора. Эксплуатация в этот момент только начинается.
Когда происходит сложная авария, связь восстанавливают не рекламные материалы и не коммерческие презентации. Её восстанавливают сетевые инженеры, электромеханики, станционные специалисты, линейщики, системные администраторы и другие люди, которые действительно понимают инфраструктуру.
Маркетинг приводит человека к услуге, но именно инженерная служба во многом определяет, останется ли этот человек абонентом через год.
Когда в технологической компании инженер начинает восприниматься исключительно как статья расходов, организация постепенно рискует начать экономить на самом продукте, который продаёт.
Как после связи я оказался в вебе
После ухода из узла связи в 2017 году мне пришлось фактически строить профессиональную жизнь заново. Я занялся созданием сайтов, постепенно всё глубже уходил в веб‑разработку и SEO.
На первый взгляд это была совершенно другая область. Вместо DSLAM и Cisco — CMS, веб‑серверы, поисковые системы, аналитика и сайты. Но инженерная привычка никуда не исчезла. Если сайт работает неправильно, мне всё равно недостаточно увидеть симптом. Хочется понять всю цепочку: что происходит на сервере, как идёт запрос, что отвечает приложение, откуда приходит трафик и почему система ведёт себя именно так.
Примерно с 2019 года на некоторых SEO‑проектах я стал всё чаще замечать странный автоматизированный трафик. На сайты заходили боты, парсеры и другие автоматические клиенты, иногда в очень больших объёмах. Часть такого трафика просто загрязняла аналитику, часть создавала дополнительную нагрузку, часть имела явно нежелательное поведение. Отдельно меня заинтересовали визиты, которые внешне были похожи на обычных пользователей, но создавали аномальную картину поведения.
Я не хочу упрощать поисковые алгоритмы и утверждать, что любое изменение позиций вызывается ботами. Но сама проблема автоматизированного трафика была вполне реальной, и я начал искать способы управлять им технически, а не только смотреть на последствия в системах аналитики.
Cloudflare как школа веб‑фильтрации
Одним из первых серьёзных инструментов, через который я начал строить такую защиту, стал Cloudflare. Сначала это выглядело очень удобно: DNS, проксирование, firewall rules, различные проверки и возможность принимать решение ещё до того, как запрос дойдёт до сайта.
Я начал всё глубже разбираться, как отличать нормального посетителя от автоматизированного клиента, как строить исключения, как не ломать поисковых роботов, AJAX, API и другие легитимные функции сайта.
По сути я снова оказался в знакомой среде. Раньше цепочка выглядела примерно так:
физическая линия → DSL → VLAN → PPPoE → IP‑сервис.
Теперь она выглядела иначе:
клиент → HTTP‑запрос → фильтрация → веб‑сервер → приложение.
Но принцип диагностики оказался удивительно похожим. Зелёный статус одного уровня ещё не гарантирует, что вся система работает правильно.
Постепенно появились первые клиенты, которым я уже отдельно настраивал защиту от нежелательного автоматизированного трафика. Работа всё меньше напоминала обычное SEO и всё больше возвращала меня к знакомой инженерной логике эксплуатации сети.
Почему одной внешней платформы со временем стало мало
Чем глубже я погружался в эту задачу, тем очевиднее становилось ограничение любой внешней платформы: инженер может использовать только те механизмы, которые ему предоставлены.
Если проблема находится внутри чужого сервиса, ты не можешь открыть его архитектуру и исправить поведение самостоятельно. Можно изменить собственные правила, написать в поддержку, показать воспроизводимый случай, попытаться построить обходное решение, но саму платформу ты не контролируешь. Были и ситуации, когда я мог воспроизвести проблему и подробно описать её, но всё равно оставался зависимым от того, будет ли внешняя платформа менять своё поведение.
Для моих задач со временем стало тесно. Мне хотелось видеть больше параметров запроса, самому определять последовательность проверок, комбинировать сетевые и поведенческие признаки, хранить собственное состояние клиента, создавать различные уровни доверия, самостоятельно разбирать ложные срабатывания и менять саму архитектуру фильтрации.
Дополнительным фактором стала сама зависимость от внешней инфраструктуры. Мне всё меньше нравилась идея строить целое техническое направление на предположении, что конкретная зарубежная платформа всегда будет доступна, всегда сохранит нужные функции и всегда позволит мне реализовать именно ту логику, которую я считаю правильной.
В какой‑то момент выбор стал достаточно простым: либо оставаться внутри возможностей готовой платформы, либо начинать строить собственную систему.
Я выбрал второе.
Собственный контур фильтрации
Поначалу это, конечно, не было отдельным большим сервисом. Были серверы, правила, журналы, небольшие программы и эксперименты. Я анализировал реальный трафик, пытался понять, какие признаки действительно позволяют отличать человека от автоматизации и как сделать это так, чтобы сама защита не превращалась в источник проблем для нормального пользователя.
Постепенно система становилась сложнее. Появлялась многоуровневая проверка запросов, собственная логика доверия к клиенту, различные сетевые и поведенческие признаки, отдельная обработка поисковых роботов, браузеров, API, служебных URL и подозрительного трафика.
Я снова занимался тем, что когда‑то любил больше всего: наблюдал реальную систему, находил аномалию, строил гипотезу, проверял её по журналам, менял конфигурацию и смотрел на результат.
Если легитимный пользователь попадал под фильтр, нужно было понять причину и исправить правило так, чтобы не открыть дорогу нежелательному трафику. Если бот проходил защиту, нужно было разобраться, почему он оказался похож на нормального клиента и какой дополнительный уровень проверки необходим.
С каждым годом система всё меньше была набором отдельных правил и всё больше становилась самостоятельным защитным контуром.
От собственной инженерной системы к сервису защиты сайтов
В какой‑то момент стало понятно, что я уже занимаюсь не просто настройкой отдельных сайтов. Возникла собственная инфраструктура фильтрации, которую можно использовать для разных проектов и развивать как единую систему.
Так постепенно появился мой нынешний сервис защиты сайтов от автоматизированного и вредоносного трафика.
Для этой истории важнее всего происхождение самого подхода. После многих лет вне связи я неожиданно обнаружил, что снова занимаюсь очень похожей по духу работой.
Когда‑то я строил и диагностировал прохождение трафика через Cisco, Nokia, Siemens, QTech и другую операторскую инфраструктуру, разбирал VLAN, PPPoE, DSL, маршрутизацию и аномальные состояния оборудования. Теперь я строю правила прохождения HTTP‑трафика, анализирую сетевые и поведенческие признаки и пытаюсь понять, почему конкретный запрос должен быть пропущен, дополнительно проверен или остановлен.
Оборудование другое. Протоколы другие. Но инженерный принцип остался прежним: понять систему целиком, найти место возникновения проблемы и не останавливаться на первом очевидном объяснении.
Возможно, я просто снова нашёл свою сеть
Наверное, именно поэтому работа с фильтрацией веб‑трафика со временем стала для меня значительно больше, чем очередная услуга. В ней вернулось то ощущение, которое когда‑то давала связь: сложная система нуждается в тебе, потому что ты умеешь её понять и заставить работать правильно.
Я снова строю схемы и правила, веду мониторинг, анализирую журналы, ищу аномалии и разбираю случаи, которые невозможно решить одной кнопкой. В каком‑то смысле я действительно снова нашёл свою сеть.
Но одного вернуть не удалось — тех коллег и единомышленников рядом, с которыми когда‑то можно было вместе разбирать проблему, спорить, искать решение и радоваться короткому «пошло».
Технологическую систему можно построить заново. Человеческую команду — далеко не всегда.
От Cloudflare к собственному WAF: та же инженерная логика, другой трафик
К фильтрации так называемых поведенческих ботов я пришёл примерно в 2019 году, ещё до того, как эта тема стала привычной отдельной услугой у большого количества исполнителей. Тогда я много экспериментировал на реальных SEO‑проектах: сопоставлял динамику автоматизированного трафика с аналитикой сайта, искал повторяющиеся признаки, строил гипотезы и проверял их на длительных интервалах. Терминологию для своих рабочих заметок и статей я часто формулировал сам, потому что описывал прежде всего то, что видел в собственных данных.
Сначала главным инструментом стал Cloudflare. Готового рецепта не существовало: приходилось с нуля изучать firewall rules, проверять сочетания условий, анализировать ложные срабатывания, снова менять правила и наблюдать результат. Сохранившийся архив хорошо показывает сам характер этой эволюции: отдельные конфигурации появлялись для органического трафика и внутренних переходов, спама, защиты рекламного трафика, IPv6, интеграций и разных типов автоматизации. Система росла не одной большой идеей, а множеством маленьких итераций — почти так же, как когда‑то росла районная СПД.
Мне всегда было важно не просто скопировать типовой шаблон, а понять, почему конкретная последовательность действий работает. В сетевом оборудовании я старался самостоятельно осмыслять конфигурацию и её поведение, потому что это расширяло собственную диагностическую базу. Тот же подход перешёл и в WAF: правило интересно не само по себе, а тем, какое место оно занимает в общей цепочке принятия решения и что произойдёт с легитимным и нелегитимным трафиком после его изменения.
Здесь обнаружилось неожиданное сходство с операторской сетью. В СПД эффективность определялась не наличием команды vlan или route, а тем, насколько инженер понимает всю цепочку передачи данных. В WAF наличие отдельного правила тоже почти ничего не гарантирует. Ошибка в порядке проверок, слишком широкое условие или плохо продуманное исключение может либо пропустить автоматизированный трафик, либо начать ломать нормальных пользователей. Поэтому ценность возникает не в количестве правил, а в архитектуре их взаимодействия.
В собственном контуре эта идея стала многоуровневой. На высоком уровне запрос можно рассматривать сразу в нескольких плоскостях: сетевой контекст источника, свойства HTTP‑запроса, идентичность и состояние клиента, накопленный уровень доверия, исключения для легитимных сервисов и результат предыдущих проверок. Некоторые сигналы дают основание пропустить запрос сразу, другие — провести дополнительную проверку, ограничить его или остановить. Важен не один «магический» признак, а согласованность нескольких независимых уровней.
В рабочей реализации используются и списочные признаки, и сетевой контекст, и проверка легитимных поисковых роботов, и дополнительные браузерные состояния, и механизмы доверия, и служебные ловушки для автоматизированных клиентов. Но точные условия, последовательность правил, внутренние идентификаторы и алгоритмы я намеренно здесь не публикую. Для статьи достаточно архитектурного принципа: запрос проходит несколько независимых этапов, а итоговое решение формируется только после сопоставления их результатов.
Главное сходство с моей прежней работой состоит в обратной связи. Конфигурацию нельзя однажды написать и считать законченной. Нужно смотреть журналы, замечать аномалию, разбирать ложное срабатывание, понимать, почему бот прошёл или почему реальный пользователь был остановлен, корректировать правило и снова наблюдать систему. Именно такой эксплуатационный цикл когда‑то существовал у меня между DSLAM, коммутаторами и абонентами; теперь он существует между HTTP‑клиентом, защитным контуром и веб‑приложением.
Пока писал эту статью
Я долго сомневался, стоит ли вообще всё это публиковать. Это не история создания новой СУБД, не разработка ядра операционной системы и не hyperscale‑платформа, созданная сотней программистов. Это история районной сети доступа и людей, которые её обслуживали. Но чем дальше я писал, тем яснее понимал: такие истории тоже являются частью истории IT. Причём писать статью оказалось значительно тяжелее, чем я ожидал. Я думал, что просто восстановлю хронологию: вот Nokia, вот Cisco, вот схема, вот авария, вот ETTH. Но вместе с техническими деталями начали возвращаться люди: третий этаж, ПТЛ, Александр Николаевич, Сергей, коллеги, СЮК, ночные поездки, Counter‑Strike, музыка, пломбир, шум вентиляторов серверной. И оказалось, что некоторые события спустя девять лет вовсе не стали для меня просто спокойными воспоминаниями. Где‑то эта история до сих пор болит. Наверное, поэтому статья пишется намного тяжелее обычного технического текста.
Зачем всё это сохранять
Технологическая система имеет не только стоимость оборудования, количество портов и показатели эффективности. У неё есть человеческая история. За каждой работающей сетью находятся тысячи маленьких решений, которые когда‑то принимали конкретные люди. Кто‑то ночью отремонтировал устройство. Кто‑то подписал кабель. Кто‑то написал инструкцию. Кто‑то подобрал правильную модуляцию DSL. Кто‑то нашёл неверный VLAN. Кто‑то сел в машину в два часа ночи. Кто‑то просто остался в центральном узле, пока другой инженер ехал на аварию. Большая часть этого никогда не попадёт в официальную историю компании. Поэтому мне хотелось сохранить хотя бы эту историю: историю небольшой сети одного района, которая за сравнительно короткое время прошла путь от dial‑up до 10G, и людей, которые прошли этот путь вместе с ней.
И именно здесь для меня находится главный смысл этой статьи. Я пишу её не для того, чтобы удивить кого‑то командами Cisco или показать секрет конфигурации DSLAM. Технические детали нужны здесь как свидетельство масштаба системы и той работы, которую выполняли конкретные люди. Мне хочется сохранить память о связистах, которые строили и десятилетиями поддерживали сеть одного района, и показать цену исчезновения локального инженерного знания.
Сейчас я иногда встречаю бывших электромонтёров связи уже совсем в другой жизни — в том числе за прилавком рынка или на работе, никак не связанной с тем, чему они посвятили десятилетия. Среди них есть умнейшие люди и прекрасные специалисты. Некоторые смотрят с той же грустью, которую чувствую я сам, и говорят, что тоже хотели бы вернуться назад. Мне тяжело видеть, как профессиональный опыт, который когда‑то был необходим целому району, оказался почти невостребованным.
Технически современная сеть, безусловно, стала мощнее той, которую мы строили в начале этой истории: появились GPON, значительно выросли скорости и пропускная способность магистралей. Но технологическая мощность и качество локальной эксплуатации — не одно и то же. Оптическое волокно не знает историю конкретного участка, а централизованная система сама по себе не заменяет человека, который десятилетиями жил своей сетью и понимал её до последней пары и муфты.
Я не знаю, может ли одна статья вернуть кому‑то прежнюю работу или изменить организационную модель большой компании. Но она может привлечь внимание к цене потери местных специалистов. Если после неё хотя бы кто‑то задумается о том, что инженер, электромонтёр, дежурный или местный связист — это не просто строка расходов, а носитель многолетней памяти инфраструктуры, значит я написал её не зря.
Историю развития связи легко свести к перечню технологий: dial‑up, ADSL, FTTB, 10G, GPON. Но между этими словами находились люди. Кто‑то знал каждую медную пару своей станицы, кто‑то ночью смотрел Nagios, кто‑то ремонтировал электронные платы, кто‑то конфигурировал DSLAM, кто‑то ехал на аварию под дождём. Мне хочется, чтобы после всех реорганизаций и сокращений эти люди не остались просто удалёнными строками из старого штатного расписания.
Вместо эпилога
Прошло много лет, но иногда мне всё ещё снится Павловский узел связи: третий этаж, тяжёлая железная дверь, дежурная, мой кабинет инженера‑программиста и постоянный шум вентиляторов серверной. Снятся люди, которых когда‑то видел практически каждый день, их голоса, разговоры и обычные рабочие моменты, которые тогда казались совершенно будничными.
Особое место в этих воспоминаниях занимает Александр Николаевич — мой начальник в те годы, когда узел связи для меня действительно был вторым домом. Наверное, во многом он был для меня почти как отец. Я очень уважал его прежде всего за человеческое отношение к людям и за умение видеть и ценить в инженере не строчку в штатном расписании, а его знания, профессионализм и реальную пользу для общего дела.
Ко мне он тоже относился с уважением и доверием. Мы хорошо понимали друг друга и во многих вещах действительно были на одной волне. Когда обсуждалась сеть, он умел выслушать инженеров, дать каждому высказать своё мнение и доверить человеку ту работу, в которой тот действительно разбирался. Для молодого специалиста это значило очень много: ты понимал, что твои знания нужны, твой труд замечают, а твоя ответственность за работающую сеть — не формальность.
Мы и сейчас иногда созваниваемся с Александром Николаевичем. Недавно я сказал ему то, что, наверное, давно должен был сказать: время, когда я работал вместе с ним в узле связи, было для меня лучшим временем в жизни. И это не красивая фраза для статьи. Я действительно так чувствую.
С Сергеем мы тоже не потерялись. Я до сих пор общаюсь с ним и нередко встречаюсь. Он по‑прежнему живёт своим миром радиосвязи, экспериментирует с дальней связью и работает, в том числе, со связью через отражение сигнала от Луны. Прошло столько лет, а в некоторых вещах он остался тем же Серёгой, которого я помню по дежурной узла связи.
Я понимаю, что вернуться в 2006 год невозможно. Всё изменилось, организация другая, изменились люди, да и меня самого двадцатилетней давности уже не существует. Но иногда очень хочется снова подняться на третий этаж, открыть ту тяжёлую дверь, зайти в свой кабинет инженера‑программиста и увидеть рядом тех людей, с которыми когда‑то прожил значительную часть своей жизни.
Иногда мне кажется, что я действительно отдал бы очень многое за возможность хотя бы ненадолго вернуться туда: в ту серверную, к тем коллегам, в тот узел связи, которым я когда‑то жил. Не для того, чтобы что‑то исправить или изменить. Просто ещё раз оказаться среди своих, услышать знакомые голоса и почувствовать то старое ощущение, что ты находишься именно там, где должен быть.
К сожалению, вернуться туда уже нельзя, даже если само здание по‑прежнему стоит на том же месте. Потому что домом его делали не стены, не стойки с оборудованием и не табличка на двери моего кабинета. Домом его делали люди и то время, которое мы прожили вместе.
Наверное, поэтому в каком‑то внутреннем смысле я оттуда до конца так и не ушёл. И иногда после долгого конфигурирования, диагностики, наладки и запуска уже совсем другого сетевого оборудования трафик наконец начинает идти именно так, как должен.
А в памяти через двадцать лет снова раздаётся знакомый голос:
— Слава, Слава... ну что, пошло? Пошло?
— Пошло, Серёга. Пошло.
