Роками будь-яка зміна в мережі означала той самий ритуал. Відкрити термінал, зайти по SSH на один MikroTik, вставити правило файрвола, перестрибнути на наступний роутер, вставити знову і тихенько сподіватися, що ти ніде не схибив із крапкою з комою. У вдалий день на це йшло дві години. Це історія про те, як MikroTik, Terraform і підхід "мережа як код" перетворили цей ритуал на двадцятихвилинний pull request, без жодного одруку в SSH.
Епоха "зайшов по SSH і молися"
Уяви сорок роутерів, налаштованих повністю вручну. Копіюєш правило з однієї коробки на іншу, тут підправив IP, там коментар, і переконуєш себе, що з крапками з комою все гаразд. Жодного version control. Жодного відкату. Жодного audit trail. Лише вікно термінала і те, що ти встиг запам'ятати.
Сценарій провалу завжди однаковий. Щось падає о 23:00, і ти намагаєшся згадати, яке правило чіпав три години тому, на якому роутері, і чи доїхав твій фікс із дванадцятого пристрою до тринадцятого. Якщо зміна поклала мережу, "відкотити" означало заново набрати старий конфіг по пам'яті. Це не інженерія. Це рулетка.
А знання не жили ніде. Варто було єдиній людині, яка розуміла схему NAT, піти у відпустку, і мережа йшла разом із нею.
Чому про мережеве залізо забувають
Сервери отримали Infrastructure as Code роки тому. Ми версіонуємо конфіги застосунків, шаблонізуємо Kubernetes, рев'юємо Terraform для хмари в pull request'ах. А мережеві пристрої чомусь так і застрягли у світі "зайшов і молися": до них ставилися як до особливих ручних улюбленців, яких дозволено чіпати лише сеньйору.
Але ж у RouterOS є API. Якщо у пристрою є API, його можна автоматизувати. Не було жодної вагомої причини тримати роутери поза Git. Була тільки звичка.
Як це влаштовано: Terraform говорить з RouterOS
Тож я замінив увесь ритуал на Terraform-провайдер, який напряму звертається до MikroTik RouterOS API. Правила файрвола, NAT, DHCP, VLAN, усе описано в HCL і лежить у репозиторії, як будь-яка інша інфраструктура.
Кілька Python-скриптів беруть на себе те, що Terraform робить незграбно: масові операції по десятках роутерів і шар валідації, який відпрацьовує до того, як щось буде застосовано. Ця валідація, тихий герой. Вона ловить криве правило, підмережі, що перетинаються, одрук, раніше, ніж вони дістануться живого пристрою.
І кожна зміна проходить через pull request. Хтось читає diff. Хтось апрувить. Мережа відчуває зміну лише після того, як на неї подивилася людина, а не посеред марафону copy-paste о другій ночі.
Що реально змінилося
Різниця "до і після" виявилася зовсім не тонкою.
- Час на зміну: з 2-3 годин до 15-20 хвилин.
- Відкат: з "набери заново по пам'яті" до одного
git revert. - Помилки: валідація ловить їх до застосування, а не продакшн ловить їх замість тебе.
- Audit trail: повна історія кожної зміни, на кожному роутері, щоразу.
git blameчудово працює і для мережевих конфігів. - Онбординг: новий інженер читає HCL першого ж дня і розуміє всю топологію, замість того щоб копирсатися в історії SSH і питати "хто міняв NAT минулого четверга?".
Останній пункт важливіший за економію часу. Мережа перестала бути племінним знанням і стала тим, що можна просто взяти й прочитати.
Нудно, це і є мета
Ось що мене здивувало. Мережеві операції зі стресових стали нудними. Ні нічного адреналіну, ні молитов над крапками з комою, ні археологічних розкопок у пошуках того, що ж змінилося. Просто diff, рев'ю, apply.
А в мережах нудно, це саме те, що потрібно. Нудно означає передбачувано. Передбачувано означає, що штука, на якій тримається вся компанія, не підносить сюрпризів опівночі.
Якщо цього немає в Git, цього не існує
MikroTik, Cisco, Juniper, вендор майже не важливий. Принцип один і той самий: опиши в коді, версіонуй, рев'юй, застосовуй безпечно. Конфіг, який живе в голові однієї людини, помирає тієї миті, коли ця людина йде у відпустку. Конфіг, який живе в Git, нудний, версіонований і відновлюваний за хвилини.
Тож лишається одне справжнє питання, яке я продовжую ставити іншим інженерам: твій мережевий конфіг у Git чи в чиїйсь голові?