🧠 Skill: Документация для «себя из будущего» (и почему Word — это зло) 📝

Давайте честно: админы ненавидят писать документацию. Обычно это вордовский файл `.docx`, щедро усыпанный скриншотами, который устаревает на следующий день после создания.

Но если ты ведешь несколько проектов, отсутствие нормальной документации — это гарантированное выгорание. Главный скилл сеньора — писать доки так, чтобы через год, разбуженный в 3 ночи, ты сам понял, что там наворотил.

3 правила нормальной IT-документации в 2026 году:

1. Никакого Word. Документация должна быть в Markdown (`.md`). Это текст, который легко искать, он весит килобайты, его можно хранить в Git вместе с конфигами.
2. Пиши «ПОЧЕМУ», а не только «КАК». Команду для поднятия туннеля ты нагуглишь за минуту. А вот *почему* ты пробросил именно порт 8443 и зачем отключил проверку сертификатов для этого конкретного шлюза — ты забудешь уже в пятницу. Фиксируй логику решений.
3. Docs as Code (Документация как код). Идеально — развернуть легковесную wiki (например, BookStack или Outline) и приучить себя: закрыл сложный тикет ➔ набросал заметку на 5 строчек с куском конфига.

Твоя главная целевая аудитория для документации — это не новый сотрудник. Это ты сам, но уставший, злой и после 6 месяцев работы над другими задачами. Сделай себе одолжение.

#skills #documentation #sysadmin #mindset #devops #markdown #admin_future

🧠 Skill: Doc-as-Code — почему твоя документация должна лежать в Git 📖

Старые Word-файлы с инструкциями и пыльные страницы в Wiki умирают в тот момент, когда их создали. В 2026 году админ использует подход Documentation as Code (DaC). Это значит, что документация пишется в Markdown, хранится в Git и живет рядом с кодом или конфигами.

Техническая суть:

1. Версионность: Ты всегда видишь, кто и когда изменил инструкцию по восстановлению бэкапа.
2. Peer Review: Ты можешь создать Pull Request с описанием новой схемы сети, а коллеги проверят его на ошибки.
3. Автоматизация: При пуше в Git документация может сама собираться в красивый статический сайт (через MkDocs или Hugo).

Простой пример Markdown-структуры:

```markdown
# Инструкция: Восстановление БД из бэкапа
## Шаги:
1. Зайти на сервер `db-backup-01`.
2. Выполнить команду: `cat backup.sql | psql database`.
> Важно: Перед этим проверьте наличие свободного места в `/var/lib/postgresql`.

```

Вывод: Навык работы с Markdown и Git-флоу для документации делает тебя системным инженером нового уровня, чьи знания не потеряются при сбое Wiki-сервера.

#skills #documentation #markdown #git #devops #sysadmin #admin_future

🚀 Skills: Твоя вторая память — Зачем админу личная Wiki

Понедельник — отличное время, чтобы навести порядок в голове. Самая большая ошибка админа — полагаться на свою память. Фраза «я это точно запомню» — самая большая ложь, которую мы себе говорим. Через полгода ты не вспомнишь, какой «костыль» применил для настройки того странного принтера.

Почему личная база знаний (Wiki) — это твой главный скилл:

1. Скорость решения: Ты не гуглишь проблему заново, а открываешь свою заметку, где уже есть готовый конфиг.
2. Спокойный отпуск: Если ты передаешь дела коллеге, тебе достаточно скинуть ссылку на документацию, а не висеть на телефоне.
3. Структура: Описывая решение в Markdown, ты сам лучше понимаешь, как оно работает.

Что использовать:

1. Obsidian или Logseq — для тех, кто любит локальные файлы и связи между заметками.
2. Notion или Wiki.js — если нужна командная работа и красивый интерфейс.
3. Обычные .md файлы в Git-репозитории — путь настоящего минималиста.

Вывод: Админ без документации — это просто пожарный. Админ с базой знаний — это инженер. Начни записывать свои решения сегодня, и через месяц ты скажешь себе спасибо.

#skills #documentation #productivity #knowledgebase #markdown #admin_future