В статье также поставлено под сомнение абсолютная способность предсказания хотя бы потому, что если предположить, что мы обладаем свободой воли, то с предсказаниями все не просто. Но это не отменяет того факта, который скорее следует из житейского опыта, что кто-то предсказывает лучше, а кто-то хуже и для этого мы используем такое понятие как мудрость.
Я отчасти согласен с вами. Если пытаться честно читать, вдумываясь, то начало статьи, с введением новой терминологии, аббревиатуры, закономерностей может и раздражать, и отпугивать. Поэтому я убрал детали под кат, что позволяет (на мой взгляд) сначала быстро просмотреть статью и если уж станет интересно, то потом разбираться со всем этим.
Боюсь, что без введения всего этого вначале, мне бы пришлось часто объяснять все это в статье. Ведь именно в этом и есть смысл определения новых понятий и открытия закономерностей — чтобы просто потом ссылаться на них по их названию, не пытаясь каждый раз раскрывать их суть.
Прежде всего уверен (и комментарии это подтверждают), что существуют разные способы решения этой задачи. Если вы нашли свой подход, и он удобен для вас, то отлично.
В-вторых, сложно сравнивать методы. Я знаю детально сильные стороны изложенного мной подхода (слабые тоже), но не могу сказать, что осознаю до конца, что предлагаете вы. Поэтому могу говорить только какие-то общие вещи, а именно
1) подход с markdown выглядит более универсальным — вы можете конвертировать не только в Word, но и в другие форматы
2) лично для меня markdown очень удобен — в Word слишком много всего, и все должны делать это в едином стиле…
3) мне нравится разделение функций — Git отвечает за многопользовательскую работу, за версионирование и все что с этим связано, а Markdown — это информационная часть. В вашем же подходе, какие-то функции Git приходится делать силами Word и я не уверен, что там все это реализовано так же удобно
Но, еще раз хочу сказать, что описанный подход я не воспринимаю как лечение от всех болезней
Всегда пользовался Latex для статей связанных с математикой. Наверно, много лишнего, чего обычно не нужно для обычной документации в IT.
Но, если удобней Latex, то подход тот же.
>я не совсем уверен…
в проектировании очень полезно. Вы имеете трек всех изменений, понимаете кто делал эти изменения и когда. Так же вы можете ввести процедуру согласования изменений с архитекторами и если хотите с клиентом, вы можете делать разные ветки,… В общем все тоже что и врограммировании… поверьте это очень полезно. И я как раз говорил про полезность данного действие при проектировании.
>неужто у вас одинаковые приложения?
нет, конечно. Но это может быть с десяток различных конфигураций, ну, может чуть больше. Я их опишу за пару дней. Создание шаблонов это во многом простое копирование вашей реальной конфигурации.
Если же вам каждый раз или почти каждый раз приходится создавать что-то новое, то этот подход не для вас, но зачем такое разнообразие?
Да, конечно, все надо применять по делу. Думаю есть много ситуаций, когда это не имеет смысла, если только не хочется самим научиться чему-то новому :)
В YAML файле вы можете все это указать. На какой свитч заходить, какая модель свича, что делать с stp. И исходя из этого будут созданы конфиги.
Так же ничто не мешает вам сначала понять по какой логике вы куда заходите и правите а потом формально отразить это в ваших скриптах. Вы же принимете решение исходя из каких-то начальных параметров или условий — опишите их формально а потом воплотите.
Посмотрите как это сделано например с доступам в psefabric
В README проекта PAY я пишу когда это может быть полезным.
В основном это может быть полезно в двух случаях:
у вас есть повторяющиеся операции с одинаковым или похожим синтаксисом, но с разными параметрами
на этапе реализации проекта. Этот подход позволяет вам использовать best practices в управления изменениями на основе git и git-подобных приложений
В моем случае это и второе и первое. У нас датацентр состоит из 3х сегментов. С точки зрения дизайна они одинаковы. То есть темплейты одинаковы. Так же есть еще аналогичные staging и dev. Мне не нужно думать над конфигруацией — я только ввожу то, чем все эти сегменты отличаются, а именно ip адреса, номера bgp as, имена объектов… и все — конфиг создается сам.
И после этого мне не нужно идти и добавлять все это в документацию. Говоря про 90 процентов я думаю, что я даже приуменьшил :)
В вашем случае нужно найти повторяющиеся задачи. Например, в моей практике это было создание виртуальных серверов для балансировки — вам нужно создать конфигурацию на F5, создать виртуальные машины, открыть доступы… и обычно это все довольно однотипно. А делать это приходилось довольно часто.
Может быть не точно выразил свою мысль.
Нет претензий к Касперскому.
Предположим, в качестве фаервола вы используете Juniper SRX c Касперским в качестве антивируса (https://habr.com/ru/post/241295/). Предположим, что на конечных хостах вы так же используете Касперский. В данном случае вы используете одни и те же алгоритмы и базы данных как для защиты на фаерволе, так и на конечном устройстве.
И я хотел сказать, что использование разных алгоритмов увеличивает вероятность обнаружения атаки, например, если на SRX вы по-прежнему будете использовать Касперский, а на конечных хостах Symantec.
Здесь все практично. Не говорю о конкретых реализациях потому что
— можно реализовать по-разному, и в моей практике многие вещи были действительно реализованы разными средствами (как минимум на разном оборудовании), но концепции при этом остаются теми же
— если понимаете что хотите реализовать и знаете точно что это возможо, найти решение не так сложно
— часто не хватает именно общего взгляда. Хороших инженеров, способных разобраться как сконфигурить оборудование не мало (если не помните, то берете документацию и делаете), а вот концептульное знание формируется после продолжительной практики и (успешной) работы в разных сетях и проектах
В этом смысле мне, наверно, повезло и у меня был такой опыт. С чем и делюсь.
В принципе, все о чем идет здесь проверено практикой. Все примеры решений, которые приведены, были успешно реализованы. Если же вопрос о том, будут ли конкретные примеры конфигураций, то нет, не будут. Здесь речь идет о концептах, о достаточно высокоуровеневых решениях, больше о направлении движения и о стратегии чем о конкретных шагах и тактике.
Даже от руки нарисованная схема, лежащая в столе — это намного лучше, чем ничего. Бывают конечно простые сети, но все равно невозможно удержать в голове всех деталей.
Смотрели какие-то решения лет 10 назад. Но сейчас не вижу в них особого смысла. Но нужно сказать что последние лет 8 инвентаризация не находилась в моей зоне ответственности.
Инвентаризация — это совместная задача бухгалтерии, дата-центр инженеров и helpdesk. И как мне кажется разумно делать ее вручную, потому что вряд ли автоматическая система, например, поймет в каком дата-центре, в какой комнате и стойке стоит оборудование, но может я чего-то уже не знаю, все-таки информация почти 10-летней давности. Если есть опыт и знаете какой-то интересный продукт, напишите — интересно.
Я ввел его прежде всего потому, что оно позволяет легко объяснить ИМЛ и циклы регенерации
Но если вы посмотрите далее, нигде логика рассуждения не опирается на ААВД.
Хотя сама концепция в силу своего противоречия кажется мне интересной.
Боюсь, что без введения всего этого вначале, мне бы пришлось часто объяснять все это в статье. Ведь именно в этом и есть смысл определения новых понятий и открытия закономерностей — чтобы просто потом ссылаться на них по их названию, не пытаясь каждый раз раскрывать их суть.
В-вторых, сложно сравнивать методы. Я знаю детально сильные стороны изложенного мной подхода (слабые тоже), но не могу сказать, что осознаю до конца, что предлагаете вы. Поэтому могу говорить только какие-то общие вещи, а именно
1) подход с markdown выглядит более универсальным — вы можете конвертировать не только в Word, но и в другие форматы
2) лично для меня markdown очень удобен — в Word слишком много всего, и все должны делать это в едином стиле…
3) мне нравится разделение функций — Git отвечает за многопользовательскую работу, за версионирование и все что с этим связано, а Markdown — это информационная часть. В вашем же подходе, какие-то функции Git приходится делать силами Word и я не уверен, что там все это реализовано так же удобно
Но, еще раз хочу сказать, что описанный подход я не воспринимаю как лечение от всех болезней
Спасибо всем!
Таблицы, конечно, требуются, но функциональности Markdown оказалось достаточно.
Но, если удобней Latex, то подход тот же.
в проектировании очень полезно. Вы имеете трек всех изменений, понимаете кто делал эти изменения и когда. Так же вы можете ввести процедуру согласования изменений с архитекторами и если хотите с клиентом, вы можете делать разные ветки,… В общем все тоже что и врограммировании… поверьте это очень полезно. И я как раз говорил про полезность данного действие при проектировании.
>неужто у вас одинаковые приложения?
нет, конечно. Но это может быть с десяток различных конфигураций, ну, может чуть больше. Я их опишу за пару дней. Создание шаблонов это во многом простое копирование вашей реальной конфигурации.
Если же вам каждый раз или почти каждый раз приходится создавать что-то новое, то этот подход не для вас, но зачем такое разнообразие?
Так же ничто не мешает вам сначала понять по какой логике вы куда заходите и правите а потом формально отразить это в ваших скриптах. Вы же принимете решение исходя из каких-то начальных параметров или условий — опишите их формально а потом воплотите.
Посмотрите как это сделано например с доступам в psefabric
В основном это может быть полезно в двух случаях:
В моем случае это и второе и первое. У нас датацентр состоит из 3х сегментов. С точки зрения дизайна они одинаковы. То есть темплейты одинаковы. Так же есть еще аналогичные staging и dev. Мне не нужно думать над конфигруацией — я только ввожу то, чем все эти сегменты отличаются, а именно ip адреса, номера bgp as, имена объектов… и все — конфиг создается сам.
И после этого мне не нужно идти и добавлять все это в документацию. Говоря про 90 процентов я думаю, что я даже приуменьшил :)
В вашем случае нужно найти повторяющиеся задачи. Например, в моей практике это было создание виртуальных серверов для балансировки — вам нужно создать конфигурацию на F5, создать виртуальные машины, открыть доступы… и обычно это все довольно однотипно. А делать это приходилось довольно часто.
Нет претензий к Касперскому.
Предположим, в качестве фаервола вы используете Juniper SRX c Касперским в качестве антивируса (https://habr.com/ru/post/241295/). Предположим, что на конечных хостах вы так же используете Касперский. В данном случае вы используете одни и те же алгоритмы и базы данных как для защиты на фаерволе, так и на конечном устройстве.
И я хотел сказать, что использование разных алгоритмов увеличивает вероятность обнаружения атаки, например, если на SRX вы по-прежнему будете использовать Касперский, а на конечных хостах Symantec.
— можно реализовать по-разному, и в моей практике многие вещи были действительно реализованы разными средствами (как минимум на разном оборудовании), но концепции при этом остаются теми же
— если понимаете что хотите реализовать и знаете точно что это возможо, найти решение не так сложно
— часто не хватает именно общего взгляда. Хороших инженеров, способных разобраться как сконфигурить оборудование не мало (если не помните, то берете документацию и делаете), а вот концептульное знание формируется после продолжительной практики и (успешной) работы в разных сетях и проектах
В этом смысле мне, наверно, повезло и у меня был такой опыт. С чем и делюсь.
И насчет недооцененности, я не жалуюсь :)
Инвентаризация — это совместная задача бухгалтерии, дата-центр инженеров и helpdesk. И как мне кажется разумно делать ее вручную, потому что вряд ли автоматическая система, например, поймет в каком дата-центре, в какой комнате и стойке стоит оборудование, но может я чего-то уже не знаю, все-таки информация почти 10-летней давности. Если есть опыт и знаете какой-то интересный продукт, напишите — интересно.