GetNet

Obsidian — система заметок. Obsidian позволяет документировать всё, что есть в инфраструктуре. Он поддерживает Markdown-форматирование, а значит, заметки могут содержать не только текст, но и ссылки, изображения, медиафайлы и даже PDF-мануалы с указанием конкретных страниц. Блоки кода тоже вставляются штатно — в работе инженера постоянно приходится сохранять куски конфигов.

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

Отдельно стоит отметить шаблоны: заранее подготовленный шаблон инцидента или проекта с готовыми чек-боксами избавляет от необходимости каждый раз придумывать структуру заново и вспоминать, «как это было месяц назад». В Obsidian удобно вести и рабочий дневник — что было настроено, какие команды выполнены, куда что прописано, — с фильтрацией по тегам.

Ещё одна полезная возможность — несколько хранилищ (vault). Логично разделить их на два: в первом лежат рабочие файлы по текущей инфраструктуре, во втором — личная база знаний со шпаргалками и заметками, не привязанными к конкретному работодателю. Поиск в таких хранилищах не пересекается, что довольно удобно.

KeePass — менеджер паролей. Менеджеров паролей много, но большинство из них облачные — и это тот же минус: сеть легла, доступ к паролям пропал. KeePass хранит пароли локально, а значит, они доступны всегда. Резервные копии, как обычно, на совести инженера.
Рекомендуется сразу завести два мастер-файла:

MobaXterm — терминальный клиент. MobaXterm умеет всё то же, что и другие SSH-клиенты, но имеет ряд встроенных возможностей:

Sublime Text 3 — текстовый редактор. Обычного блокнота здесь недостаточно, потому что Sublime Text 3 даёт две крайне полезные вещи.

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

Альтернативы существуют. VS Code — это скорее IDE, мультикурсор и регулярки в нём есть, но управлять этим менее удобно; Notepad++ многим сетевым инженерам нравится, но здесь это уже дело вкуса. Единственное, чего не умеет Sublime, но умеет Notepad++, — сортировка строк как чисел. Без неё IP-адреса и записи ARP-таблицы сортируются как текст: 1, 10, 11, 2, 20, 21, 3, 30. Ради одной этой функции Notepad++ имеет смысл держать установленным.

Draw.io ставится как клиентское приложение либо используется в облачных сервисах (например, прямо на Google Диске). Альтернатива в виде Visio довольно тяжёлая, неудобная в работе с объектами и непростая в установке.

Плюс draw.io ещё и в том, что схемы — это по сути обычные XML-файлы, которые принимают другие сервисы. Confluence корректно отрисовывает файлы draw.io, поэтому схему сети можно хранить прямо в базе знаний. Grafana также умеет работать с draw.io: на основе нарисованной схемы можно собрать пусть и «плюшевый», но динамичный мониторинг, где схема сети выступает фоном, а поверх неё располагаются активные объекты — горит зелёная лампочка, значит, всё работает. На первое время такой динамической схемы вполне достаточно.

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

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

L2-схема служит для работы с VLAN'ами и физическими линками — по сути, гибрид L1/L2. Отрисовывать нужно не всё, а только то, чего достаточно, чтобы протянуть VLAN из точки А в точку Б: устройства и их роль. Коммутатор с чисто L2-функционалом рисуется как L2-коммутатор, роутер — как роутер, файрвол — как файрвол.

Практические приёмы, до которых автор дошёл сам, отойдя от стандартов курсов CCNA/CCNP:

У L3-схемы задача другая — маршрутизация. Отображаются подсети: какие есть и где они терминируются. Больше по большому счёту ничего не нужно; VLAN можно указать комментарием к подсети, но это не принципиально. На L3-схеме не должно быть ничего, связанного с L1/L2 — никаких портов. Симметрично на L2-схеме из адресов допустимы максимум IP менеджмента сетевого оборудования.
Когда сеть подрастёт и появится динамическая маршрутизация, на схему можно добавить зоны OSPF, eBGP/iBGP и прочее. Но главное — подсети. Указывать их и адреса желательно полностью, а не сокращённо «через точку»: тогда работает поиск по Ctrl+F. Все подсети в голове всё равно не удержать, а поиск помогает очень часто.

L1-схема опциональна. Нужна только если в наследство досталась более-менее сложная СКС: патч-панели, пассивные мультиплексоры и подобное. Коммутаторов и вообще ничего активного на L1-схеме быть не должно.

Вести IPAM важно. На словах IP-план есть почти у всех — вместе с VLAN-планом он где-то лежит, и его никто не трогает.

На старте IP-план можно вести хоть в Excel. Заполняя его подсетями, найденными и отрисованными на L3-схеме, стоит сразу прикинуть, какие сети будут выделяться дальше, и разбить их по группам. IP-план должен быть именно планом, а не сборником текущих подсетей: понадобилась новая сеть — зашёл, увидел свободный диапазон, который бьётся с планом, взял.

То же самое с VLAN-планом: например, VLAN 10–255 — под локальную сеть (с соответствующим третьим октетом подсетей), 1000–2000 — серверный контур и так далее. Конкретика зависит от инфраструктуры.

Кабельный журнал в простейшем виде — это устройство А, порт А, устройство Б, порт Б, маркировка линка (если есть) и тип кабеля. Нужен он потому, что при хаосе в кабельном хозяйстве приходится искать концы по description портов или по LLDP/CDP, а найти удаётся не всегда. Начать можно с той же Excel.
Если время всё-таки есть, лучше развернуть NetBox и переносить IP-планы, VLAN-планы и кабельные журналы туда. NetBox бесплатен и позволяет вести учёт практически всей инфраструктуры: стойки, локации, Wi-Fi-сети, СКС — вплоть до учёта ИБП.

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

Дашборды. Вещь очевидная, но у многих их нет: «у нас алерты в Telegram» или «нам на почту приходит». Потом случается инцидент, прилетает несколько сотен сообщений, и люди скроллят ленту, пытаясь понять, что и где произошло. Дашборд отвечает на этот вопрос сразу. Формировать их стоит под конкретные задачи, а не общим миксом. Например, температурный дашборд по десятку хостов: температура растёт везде — вероятно, забыли закрыть дверь или сломался кондиционер; растёт на одном хосте — идти разбираться с этим хостом.

Темплейты. Готовые темплейты Zabbix не следует навешивать на оборудование и тем более редактировать. Их нужно клонировать и переименовать под свою инфраструктуру, пометив как собственный, отредактированный. Сегодня потребности одни, через полгода — другие, и оригинал должен остаться нетронутым, чтобы не пришлось искать и скачивать его заново.

Считается, что в небольших компаниях маркировка не нужна: кабель всегда можно продёрнуть и отследить. Выход так себе.
Существует стандарт ANSI/TIA-606, позволяющий маркировать кабели так, чтобы было видно, из какого помещения, с какой патч-панели и из какого порта пришёл кабель и куда он ведёт. Для статичной, организованной СКС это удобно: кабинеты и помещения переименовываются редко.

Но если сеть постоянно меняется, патч-корды перетыкаются с хоста на хост, а бизнес бурно растёт и требует изменений — маркировка уходит на второй план. Переткнули, «перемаркируем потом», потом забылось — и маркировка начинает вводить в заблуждение, а доверие к ней падает.

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