Обложка: гибридная система заметок в Obsidian
Обложка: гибридная система заметок в Obsidian

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

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


Гибридный подход: когда классика встречается с Zettelkasten

Классическая иерархия папок - отличный способ для крупных проектов и официальной документации, но бывает тяжёлой для быстроменяющихся задач. Zettelkasten - это свобода и сеть идей, но в больших командах может привести к хаосу. Гибрид объединяет оба подхода: структура для стабильных данных, карточки - для инцидентов и ошибок. Такой баланс помогает соответствовать современным стандартам и реально экономит время.

Сравнительная таблица

Критерий

Иерархия

Zettelkasten

Гибридный формат

Структура

Жёсткая, древовидная

Плоская, сеть взаимосвязанных заметок

Комбинация иерархии и сетевых связей

Поиск информации

По папкам и категориям

По связям и ключевым идеям

По структуре и связям

Гибкость

Низкая

Высокая

Средняя-высокая

Масштабируемость

Средняя

Высокая

Высокая

Обучение и освоение

Быстрое, интуитивное

Требует времени и практики

Среднее, требует понимания обоих подходов

Поддержка связей

Ограниченная (в основном вложенность)

Активное создание двунаправленных ссылок

Связи плюс иерархия для удобства

Применимость

Простые проекты, структурированные данные

Комплексные знания, исследовательская работа

Универсальный, подходит для разных задач

Автоматизация и плагины

Стандартные инструменты

Специализированные плагины (Dataview, backlinks)

Использует возможности обоих подходов

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


Как я дошёл до жизни такой

Вкратце расскажу, как. Без этого понимание дальнейших примеров будет не совсем удобным для читателя. Я представитель "поколения X", как сейчас многие любят выражаться, и классическая иерархическая структура для меня что-то вроде "Персонального внутреннего стандарта". Сейчас я занимаюсь проектами как частное лицо, поэтому могу позволить себе определённую гибкость в ведении документации и процессов. Однако, зачастую, мне приходится вести проекты, где работает целая команда самых разных специалистов, или принимать участие в проектах, являясь частью команды, поэтому желание по максимуму придерживаться стандартов и лучших практик меня никогда не покидало.

В итоге, пройдя через ряд типичных для моего случая ситуаций, проб и ошибок, в настоящее время я пришёл к структуре, которую представлю вам в следующем разделе.


Пример структуры

Фактически это структура организации микробизнеса, которая может включать в себя и классическую базу знаний.
Далее образец, который вы можете адаптировать под свои задачи. Он максимально приближен к стандартам и лучшим практикам (ITIL, ISO 20000, ISO 27001). Привожу пример на английском языке. В реальной жизни я использую и русскоязычные названия, в зависимости от конкретной ситуации и требований стандартов:

.obsidian/
_attachment/
    audio/
    docs/
    images/
    video/
_templates/
    Incident.md
    Error.md
    Problem.md
    Request.md
    Change.md
    Alert.md
    Runbook.md
    Instruction.md
    FAQ.md
000-Standards/
005-Audit/
010-Events/
    01-Incidents/
        #Заметки по инцидентам (Zettelkasten)
    02-Errors/
        #Заметки по ошибкам (Zettelkasten)
    03-Problems/
    04-Requests/
    05-Changes/
    06-Alerts/
    07-Security/
    08-Support/
    09-Risks/
020-Runbooks/
030-Hardware/
040-Software/
050-Projects/
055-Services/
060-Infrastructure/
100-Training/
110-Roles-and-Access/
120-Contractors/
130-Legal/
Inbox/
Archive/
Personal/
Drafts/

Почему именно так

  • Трёхзначные числовые префиксы в названиях папок облегчают желаемую сортировку и добавление элементов в структуру без лишних "телодвижений".

  • Projects (Проекты) - отдельными папками, чтобы не путать документацию разных направлений.

  • _attachment (Вложения) - содержит подпапки по типам, для порядка и быстрого поиска.

  • _templates (Шаблоны) - активно используются, чтобы ускорить создание новых заметок и стандартизировать оформление.

  • Standards - отдельная папка с внутренними правилами и соглашениями.

  • Personal (Личное) - отдельная папка для личных заметок, чтобы не мешать рабочему.


Что делать с категориями и тегами при гибридном подходе

Вопрос организации категорий и тегов в гибридной системе - один из самых частых и спорных. Если вы, как и я, цените порядок и наглядность, логично использовать категории и подкатегории строго как папки и подпапки. Такой подход отлично вписывается в корпоративные стандарты и облегчает навигацию даже в очень больших базах знаний.

Категории и подкатегории = папки и подпапки

В моей практике категории - это всегда отдельные папки верхнего уровня (например, 010-Events/, 020-Runbooks/, 030-Hardware/). Подкатегории реализуются как вложенные подпапки (01-Incidents/, 02-Errors/ и т.д.). Такой подход позволяет:

  • Сразу видеть структуру и быстро ориентироваться в ней;

  • Разделять рабочие процессы, проекты и типы данных на физическом уровне;

  • Легко делегировать права доступа и поддерживать стандарты хранения информации;

  • Избежать путаницы, когда одна и та же заметка «висит» в нескольких категориях.

Рекомендация по тегам при такой структуре

Если вы строите категории и подкатегории именно через папки, теги становятся инструментом для дополнительной гибкой классификации, а не дублёром структуры. Используйте теги для:

  • Тематики (#linux, #security, #hardware);

  • Статуса (#open, #closed, #draft);

  • Приоритета (#high-priority, #urgent);

  • Быстрого поиска по особенностям, которые не отражены в структуре папок (например, #critical, #external, #me).

Главное правило: не превращайте теги в альтернативную иерархию. Пусть они работают как фильтры и маркеры, а не как ещё одна система папок. Это позволит сохранить порядок, не потеряв гибкости и скорости поиска.

Метаданные и шаблоны - ваши друзья

Добавление YAML-метаданных в начале заметок помогает структурировать и фильтровать информацию. Это особенно полезно при использовании таких плагинов, как Dataview, для создания динамических отчётов.

Пример YAML:

---
category: "Инцидент"
status: "открыт"
date: 2025-05-14
tags: [linux, сбой, high-priority]
---

Пример шаблона (инструкция):

---
category: "Instruction"
status: "draft"
date: 2025-05-12
tags: [linux, setup]
---
# Название инструкции

## Цель
Краткое описание задачи.

## Требования
Перечень необходимых условий и ресурсов.

## Пошаговое руководство

1. Шаг первый  
2. Шаг второй  
3. ...

## Примечания
Дополнительная информация.

## Источники
- [Ссылка 1](https://...)
- [Ссылка 2](https://...)

Где пригодился Zettelkasten?

В разделах, где важна быстрая фиксация и гибкие связи (например, «Ошибки» или «Инциденты»), я использую короткие заметки с описанием, причинами и решениями. Такой подход позволяет быстро находить и связывать информацию, сохраняя гибкость Zettelkasten без потери порядка.

Пример заметки ("карточки", если вам будет угодно) об ошибке:

---
category: "Administration"
status: "resolved"
date: 2024-11-10
tags: [linux, error, kernel]
---

# Kernel panic: VFS unable to mount root fs

**Описание:**  
Критическая ошибка ядра Linux, возникающая при невозможности смонтировать корневую файловую систему.

**Причины:**  
- Повреждение загрузчика (GRUB)
- Отсутствие или повреждение initrd/initramfs
- Ошибки в UUID или метках дисков в /etc/fstab

**Решения:**  
- Проверить настройки загрузчика
- Восстановить initrd/initramfs
- Исправить /etc/fstab

**Ссылки:**  
- [Документация по GRUB](https://www.gnu.org/software/grub/manual/)
- [Форум поддержки Linux](https://linux.org.ru)

В большинстве остальных разделов используется классическая иерархия.


Недостатки и ограничения: честно о минусах

Гибридная система - это круто, но не без нюансов:

  • Порог входа. Новичкам придётся немного попотеть: нужно понять и структуру, и связи. Без короткого гайда можно быстро запутаться.

  • Рост хаоса. Чем больше заметок, тем выше шанс, что база начнёт обрастать дублями, «мертвыми» ссылками и устаревшей инфой. Ревизия - must have.

  • Дисциплина. Придётся следить за шаблонами, тегами и единым стилем. Особенно если работает команда.

  • Командные споры. Кто-то любит папки, кто-то - связи. Без договорённостей и синхронизации тут не обойтись.

  • Плагины иногда капризничают. Некоторые фишки Obsidian лучше работают с одной моделью, и гибрид требует чуть больше ручной настройки.

  • Стандарты требуют усилий. Если нужен жёсткий аудит (например, по ISO), придётся потратить время на адаптацию шаблонов и структуры.

Гибрид - штука мощная, но требует порядка и регулярного обслуживания. Если готовы к этому - результат вас точно порадует! Конкретно в моём случае, когда Zettelkasten используется только для событий, проблем не возникает.


А напоследок...

  • Для тех, кто только начинает: скорее всего вы неоднократно увидите совет бывалых пользователей Obsidian - «Не раздумывайте над структурой, а просто начинайте писать». Это абсолютно верный и ключевой принцип. По мере наполнения вашей базы заметок наиболее удобная именно для вас структура будет выстраиваться естественным образом. Да-да, народное «А оно само» в данном случае отлично работает.

  • Не рассматривайте эту статью как безусловную инструкцию, это всего лишь путеводный знак и один из способов решить проблему.

  • Продуманная структура - это не бюрократия, а настоящий спасательный круг в мире информации. Потратите немного времени на организацию сегодня - и завтра ваши заметки будут работать на вас, а не наоборот.

  • Тема организации знаний и эффективного ведения заметок в Obsidian огромна. Во время публикации, мне не один раз пришлось дополнять материал и постоянно приходило искушение добавить ещё. Однако, невозможно раскрыть все нюансы в рамках одной статьи. Здесь я не затрагиваю такие темы, как стандарты именования файлов и каталогов, и многое другое...

  • Я не буду добавлять в конце штампы типа: «А как вы делаете у себя», «Поделитесь...» и прочую маркетинговую чепуху, потому что всё это вам наверняка и так уже до жути надоело.

  • ...И да простят меня бородатые адепты файловых структур за «папки», а не «каталоги». Желаю вам нескучных заметок и удачного дня!


Полезные плагины Obsidian

  • Dataview - создание динамических списков и автоматических отчётов на основе метаданных.

  • Templater - расширенные шаблоны и автоматизация рутины.

  • QuickAdd - быстрое создание новых заметок по шаблонам.

  • Attachment Management - организация вложений и автоматизация их сортировки.

  • Graph Analysis - анализ графа связей и визуализация структуры базы знаний.

Использование этих плагинов значительно облегчает организацию и поддержание порядка.


Что можно почитать

Комментарии (11)


  1. flowing_abyss
    21.05.2025 05:59

    Статья весьма неплохая. Однако сама предложенная структура даже близко не гибридная. Это всё ещё жёсткая иерархическая система (примерно такая же, как Johnny.Decimal).


    1. Gedeonych Автор
      21.05.2025 05:59

      Это всего лишь образец для адаптации совмещающий в себе элементы классики и Zettelkasten, а также "отправная точка", как и написано в статье. Например, сейчас у меня в основном рабочем хранилище сокращенное количество каталогов, согласно требованиям стандарта, а также не используются числовые префиксы и заглавные буквы, согласно требованиям для автоматизации. Мне бы очень хотелось вместить все эти, и ещё кучу других нюансов в статью, но тогда бы она превратилась в энциклопедию. Увы...


    1. FriedricH
      21.05.2025 05:59

      Настоящий Цеттелькастен и есть такая гибридная иерархическая система с небольшим облаком случайных ассоциативных связей. Иерархия обеспечивается нумерацией, но можно все заменить деревом из папок при желании - правда при наличии связей это бессмысленно. Другое дело, что в ЦК эти связи различаются принципиально - структурные задаются нумерацией, определяя место в иерархии, а ассоциативные - вот теми самыми гипертекстовыми ссылками.


  1. fronik
    21.05.2025 05:59

    Занимаюсь погружение в Obsidian, спасибо за статья. По немного из каждой статьи черпаю для себя полезные инструменты, навыки, методы.


  1. matrixsh1t
    21.05.2025 05:59

    Я тоже изначально начал просто писать в обсидиан, потом начал раскладывать по папкам. Потом создал шаблон для заметки, каждый день создаю новую заметку с датой в теме (с помощью плагина), в заметке пишу все в течение дня и ставлю теги (линукс, еластиксерч, кейс, факап и тд). В конце дня стараюсь (но не всегда получается) делаю ревизию и добавляю теги, кладу в папку "работы". Отдельные заметки со своими темами создаю с тегами и раскладывать по папкам. Стараюсь не усложнять схему, все работает интуитивно...


  1. FriedricH
    21.05.2025 05:59

    Вы совершенно неправильно воспринимаете Zettelkasten - и я вас даже не виню, это устоявшаяся ошибка всех, кто читал о нём в пересказе. Zettelkasten никогда не был сетевой системой. У меня даже лежит на эту тему недописанная пара статей, надо будет заняться.

    Если коротко - Zettelkasten иерархичен, причем строго, по определению - у каждой заметки есть предок. Сама система нумерации позволяла вставку любой заметки в любом месте как категорию предыдущей или как продолжение какой-то мысли, ветвление. Это были не рандомные уникальные ID типа временной метки, как это принято показывать сейчас, а что-то типа 1/23a/7b55 - начинались с какой-то базовой темы (что уже предполагало базовую иерархию, Луман был академическим ученым все же), но не очень строгую. И дальше по цепочке рассуждений. По сути Луман хранил в своих ящиках деревья, которые можно было легко отсортировать по порядку и найти нужную последовательность. Последовательностями он и мыслил - каждая мысль крепко "сидела" в каком-то конкретном месте - что-то придумал - записал как аргумент, пример, контраргумент, замечание. Он всегда знал что куда "вставить".

    Слой случайных, ассоциативных связей, которым так восхищаются "сетевики" был очень редким, множество заметок вообще не ссылалось на другие просто потому, что их позиция в иерархии задавалась номером - мы всегда могли знать кто предок заметки по ее номеру и кто ее потомки. Весьма вероятно, что вот эти "блуждания", "прогулки" Лумана были именно походами по цепочке рассуждений. Фактически, он конспектировал свои заметки не просто как конспекты, а как рассуждения, элементы будущей книги, которые ему достаточно было просто переносить на бумагу - это не очень удобно для тех, кто ничего не публикует, но все же может быть полезно.

    Я много думал на эту тему и достаточно много читал - это популярные дискуссии среди поклонников Цеттелькастена, но пришел к выводу, что именно такая система должна работать. Просто случайный граф превращает систему в дурацкую википедию, которая будет хуже по качеству, чем настоящая, не дает возможности ничего найти или "вставить" пришедшую мысль. Луман гордился гипертекстововстью, потому что для него она была уникальной, новой, не замечая от рождения присущую его системе очень строгую иерархичность.


    1. Gedeonych Автор
      21.05.2025 05:59

      Вы описываете классический подход Zettelkasten, но ведь он не может работать в любой структуре одинаково эффективно. Всё зависит от конкретных задач. Поэтому каждый ищет для себя именно свой вариант, в том числе, используя некоторые принципы Zettelkasten. Причём не универсальный вариант, а для конкретной задачи, например рабочее хранилище может совершенно отличаться от домашнего по структуре и принципам связей. Более того, подходы могут быть по разному эффективны для разных типов личностей и типов мышления. Поэтому каждый строит структуру именно под себя, и это, я считаю - прекрасно.


      1. FriedricH
        21.05.2025 05:59

        Ну как бы сам по себе Zettelkasten - это способ организации карточек с атомарными заметками, обеспечивающий определенные свойства такой системы. У Лумана не было нашего полнотекстового поиска, но зато у него был контекст. И этот контекст "сетевики" упускают, а без него все превращается в неструктурированный гипертекст. Связи становятся натужными и лишними, к тому же по мере эволюции системы ни связи, ни теги не работают - нужно поддерживать какие-то карты знаний и обновлять теги по имеющимся карточкам регулярно - это адский труд, который мы себе добавили сами.

        Кстати, я не совсем понял почему вы организацию тикетов называете ZK? Это обычные атомарные заметки с тегами, в вашем примере есть только внешние ссылки. Полноценным ZK они бы стали, если бы у вас была собственная база знаний или хотя бы ее имитация с минимальными описаниями и заглушками, типа Linux - подсистемы, отдельные пакеты, классы софта - связное дерево, на которое вы сажаете тикеты, которые благодаря наличию родительских связей могут лежать в папке свободно. Все равно основным инструментом остается полнотекстовый поиск, но появляется приятный бонус в виде контекста, можно посмотреть какие тикеты находятся по соседству, если решение из тикета не подходит - иногда это наводит на мысль.

        Но в целом Луман решал свои очень специфические задачи, он работал в науке, отдельные области которой сам же и создавал. Для него этот контекст был принципиально важен, взяв любую карточку он мог пробежаться от корня или от любой вышестоящей карточки и проугляться по цепочке рассуждений, уйти в ответвления и пройти по цепочке там - это все работало на массивах от 20 - 30 000 карточек.

        Я не представляю как обычный граф с рандомно расставленными связями позволит хоть чем-то помочь. Но у тикетов нет и этих связей, ни места в системе кроме тегов. Луман жил в мире иерархии не придавая этому значения. Мы же почему-то считаем иерархию злом, подсознательно к ней стремясь. Просто если до Лумана картотеки представляли собой массивы неравной длины с редкими отсылками на другие отделы (Кристи такую описывала у мисс Лемон в рассказах о Пуаро), то Луман научился укладывать в картотеки деревья. А мы эти деревья убираем, в результате пытаясь придумать что-то не очень рабочее взамен.


        1. Gedeonych Автор
          21.05.2025 05:59

          Отвечу на вопрос. В каждом тикете именно в моём случае имеются ссылки на соответствующие элементы базы знаний и т.д. и т.п. Однако статья не посвящена эффективному управлению инцидентами в IT. К сожалению я не могу в таком коротком формате предусмотреть все варианты использования и построить на каждый из них пример структуры. В статье я привёл лишь некий "шаблон", как один из вариантов для отправной точки, чтобы читатели, особенно начинающие пользователи Obsidian, могли ухватить принцип и на его основании строить своё хранилище.


          1. FriedricH
            21.05.2025 05:59

            Ну видите, а в результате начинающие пользователи воспринимают ЦК чисто как сетевую структуру с ассоциативными связями, совершенно упуская из вида его гибридность. У Лумана классическая иерархия была изначально и она обеспечивалась нумерацией. Вы можете обеспечить ее очень простым способом - кроме некоторых "корневых", "входных" карточек, список которых вы можете держать в системе, используйте в своих шаблонах поле parent или как-то так, обязательно помещая туда ссылку на родительскую заметку. Я использую up, например. Если такой родительской заметки нет - пусть будет висячая ссылка. Но до тех пор, пока заметка не доходит до корня, я не бросаю ее в папку физически, они лежат во временной папке-отстойнике, пока я эту структуру не сформирую.

            В результате вместо физических папок можно обойтись такой структурой, которая элементарно отрисовывается тем же dataview - я написал функцию, которая рисует мне дерево заметок начиная от нужной мне на определенную глубину. Там же можно настроить фильтрацию по тегам, например. Главная задача - знать куда "посадить" каждую заметку, чтобы у нее обязательно был родитель, как полка для книги - тогда эта система начинает работать как надо, а не затыкается на паре сотен заметок, заброшенных в сеть. Попробуй их потом найди, если не помнишь ключевых слов, а заметок тысячи.


  1. CTAHuCVAB
    21.05.2025 05:59

    Статья не плохая, но явно не для профессионалов, а просто про костяк структуры.

    Как и во многих других статьях, очень мало практических советов, например по шаблонам. Какие-то фичи приходится придумывать самому, что не всегда просто из-за отсутствия глубоких познаний, а также из-за того что на практике Obsidian не все поддерживает из фунционала Markdown. Не хватает и экспертизы в части плагинов, уоторые существенно расширяют фунционал.