Как стать автором
Обновить

«В чём сила, брат?», или зачем нужен Источник Правды

Время на прочтение8 мин
Количество просмотров4K
Всего голосов 11: ↑10 и ↓1+9
Комментарии8

Комментарии 8

И тут мы натыкаемся на ситуацию, когда источников правды по разным темам несколько, и некоторые источнки под одной теме начинают перетягивать одеяло на себя, и -- оппа! -- у нас два источника правды для одной той же системы. В итоге я всячески продвигаю идею (не очень успешно, сопротивление сильно) всего в CMDB, иногда -- в виде ссылок на GIT и прочие системы. В таком случае попытки дёрнуться в сторону пресекаются автоматически: правда только то, на что ссылается, скажем, объект класса сервера.

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

А бэкапы\реплики этой системы считаем источниками правды? Если да, то кто гарантирует консистентность?

А если в результате неявного повреждения данных (а оно всегда будет накапливаться в крупных системах) данные в источнике правды будут расходиться с объективной реальностью - то кому верить?

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

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

А бэкапы\реплики этой системы считаем источниками правды? Если да, то кто гарантирует консистентность?

В случае бэкапов это "версия нашей системы на момент X". В случае реплики вы выбираете нужные буковки вам из CAP.

А если в результате неявного повреждения данных (а оно всегда будет накапливаться в крупных системах) данные в источнике правды будут расходиться с объективной реальностью - то кому верить?

Именно поэтому Источник правды нужно держать настолько маленьким, насколько это возможно. И как можно больше данных генерировать автоматически.

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

Ну во-первых, есть естественный механизм доработки инструмента (самостоятельно или PR в гит автору). Во-вторых, да, можно на некоторое время позволить расхождение реальности с Источником Правды. Но по-хорошему это нужно очень срочно чинить, а саму ситуацию подсвечивать большой красной лампочкой.

Вполне достаточно обычного проведения документов и периодической сверки с реальным миром.

Это я и называю "документацией Шрёдингера". В каждый конкретный момент времени вы не утверждать, что ваша документация валидна, пока не произведёте сверку. А "обычное проведение документов", если оно не полностью автоматическое, сильно зависит от человеческого фактора.

Но по-хорошему это нужно очень срочно чинить, а саму ситуацию подсвечивать большой красной лампочкой.

Обычно в таких ситуациях сначала очень срочно чинят поломку, а не систему учета.

Во-вторых, да, можно на некоторое время позволить расхождение реальности с Источником Правды. 

Окей. У вас есть ассет менеджмент, и в нем есть куча ассетов (и среди них возможно есть лишние и дубли). У вас есть ресурс менеджмент, и там есть доступные вам ресурсы, в том числе и человеческие (но вполне возможно, что отдельные ресурсы временно недоступны, а у человека, например, просто зуб заболел и он сегодня не в состоянии сворачивать горы).

А ещё есть Источник Правды, который вроде как и ни то, и ни сё - а главное - при таких допусках он лишается своего единственного преимущества - достоверности в моменте. Это притом, что в реальной жизни очень мало кому нужна полная достоверность в моменте, в большинстве кейсов хватает оценочных сведений.

Поэтому если исключить [нездоровый] перфекционизм, то я никак не могу вкурить, зачем всё это нужно.

Обычно в таких ситуациях сначала очень срочно чинят поломку, а не систему учета.

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

Окей. У вас есть ассет менеджмент, и в нем есть куча ассетов (и среди них возможно есть лишние и дубли).

Ну такого, положим быть не должно, и бухи за это сделают атата.

А ещё есть Источник Правды, который вроде как и ни то, и ни сё - а главное - при таких допусках он лишается своего единственного преимущества - достоверности в моменте.

Вы точно не путаете Источник Правды с мониторингом?

Глупые вопрос о всей концепции:

Первый вопрос: SoT не должен (в идеале) уметь в автообновление информации (сбор как есть)? например иметь автодискавер по IP (к нетбоксу прикручивается, видел) или же, например, хранить в себе дифы конфигов (как это пытаются сделать в nautobot или в плагинах к нетбоксу, которые прикрчивают к нему гит) или же прикручивать NAPALM, например, который пинает железки по запросу и т.д.

Второй вопрос: необходимо ли налаживать связи между SoT и другими системами? например как то кодом (скриптом) связать отдельный гит с нетбоксом, нетбокс с заббиксом (например) и т.п

  1. Должна быть какая-то система импорта данных в SoT, при которой можно однозначно сказать, что данные валидны. В докладе я упоминал проблемы с любым автодискавери - вы не можете быть уверенными в том, что вам заехали "валидные" данные. Можно прикручивать линтеры, фильтры и т.д. - на ваше усмотрение. Или в принципе забить на SoT-концепцию, и использовать тот же NetBox как inventory (т.е. слепок текущего состояния)

  2. Все остальные системы должны ходить в Netbox за валидными данными - адресами, списком оборудования и т.д.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий