Comments 32
У Дмитрия Фиголя есть отличный канал со стримами на эту тему.Не знаю, что за канал Вы рекламируете, но в современных браузерах он не открывается изначально, или блокируется антивирусом. Не могли бы предоставить ссылку в явном виде, без СМС, регистраций, куки и java скриптов?
Да, спасибо. Ссылка неправильно вставилась. Поправил.
А конкретно — плейлист по network programmability.
А конкретно — плейлист по network programmability.
Антивирус тут не причем, там ссылка кривая YAML,%20Python%20netmiko%20and%20async%20SSH%20%E2%80%93%20Network%20programmability%20stream%201
Известно, что 80% проблем случаются во время изменения конфигурации — косвенное тому свидетельство — то, что в период новогодних каникул обычно всё спокойно.«Безнаказанность — рождает вседозволенность, вседозволенность рождает беспредел». Как только за такую халатность будут отстранять от должности с записью в трудовую книжку, проблема решиться сама собой.
Любая система имеет заложенное свойство компенсирующей обратной связи. Как только сделает то, что вы предлагаете:
1) На сети нельзя будет проводить никаких работ (обложимся регламентами с согласованием через год)
2) Если работы все-таки были и прошли неуспешно, появится куча оправданий и кивков в сторону производителя/подрядчика/программистов… Мы будем ещё до начала работ думать на кого свалить косяк
1) На сети нельзя будет проводить никаких работ (обложимся регламентами с согласованием через год)
2) Если работы все-таки были и прошли неуспешно, появится куча оправданий и кивков в сторону производителя/подрядчика/программистов… Мы будем ещё до начала работ думать на кого свалить косяк
Всё верно. Зато у работодателей при найме будет больше информации:
у одного сотрудника 5 факапов, у второго 25. Один будет твердить о своей сверхответсвенности, второй говорить о том, что не ошибается тот, кто ничего не делает. Обе стороны в выигрыше, бизнес выберет тот вариант, который предпочтителен в данной ситуации.
у одного сотрудника 5 факапов, у второго 25. Один будет твердить о своей сверхответсвенности, второй говорить о том, что не ошибается тот, кто ничего не делает. Обе стороны в выигрыше, бизнес выберет тот вариант, который предпочтителен в данной ситуации.
Основная проблема у нас в чем?
При разборе ошибок в 99 случаях из 100 выясняется, что инженеру было просто лень потратить 5, 10, 15 (говорю по максимуму) минут на предварительную проверку. Элементарный подсчет стоимости работы 15 минут инженера и стоимости простоя инфраструктуры определяет цену греха.
Данная статья предлагает автоматизацию в качестве решения этой проблемы. Но, ключевой момент в том, что автоматизация не только не решает, но и усугубляет положение. Проверка корректности работы системы управления дольше и дороже, а ошибка распространяется сразу на тысячи устройств, увеличивая даунтайм в разы.
Единственный плюс для инженера: он может попытаться свои косяки переложить на разработчиков софта. Скорее всего эта отмазка не сработает.
При разборе ошибок в 99 случаях из 100 выясняется, что инженеру было просто лень потратить 5, 10, 15 (говорю по максимуму) минут на предварительную проверку. Элементарный подсчет стоимости работы 15 минут инженера и стоимости простоя инфраструктуры определяет цену греха.
Данная статья предлагает автоматизацию в качестве решения этой проблемы. Но, ключевой момент в том, что автоматизация не только не решает, но и усугубляет положение. Проверка корректности работы системы управления дольше и дороже, а ошибка распространяется сразу на тысячи устройств, увеличивая даунтайм в разы.
Единственный плюс для инженера: он может попытаться свои косяки переложить на разработчиков софта. Скорее всего эта отмазка не сработает.
Ну всё понятно. Заминусли комментарий и рейтинг упал сразу на 20 пунктов. Это только подтверждает халатное отношение к работе.
В соседней теме есть разбор отличий поколения X, Y, Z к своим обязанностям. Людям в возрасте 40+ лет свойственно сначала думать, потом делать, поколение помоложе от глупости может оставить только серьезное наказание.
В соседней теме есть разбор отличий поколения X, Y, Z к своим обязанностям. Людям в возрасте 40+ лет свойственно сначала думать, потом делать, поколение помоложе от глупости может оставить только серьезное наказание.
Согласен с комментатором выше. Неотвратимое наказание за любую ошибку приведёт только к порочной практике искать виновного, обкладывать бумажками, чтобы снять с себя ответственность, параличу при принятии решений и даже деплою изменений.
А самое главное — человек уже совершил ошибку, в здоровой компании он не захочет повторения этой ситуации и вряд ли сделает это ещё раз.
Правильные действия после инцидента — собрать группу, расследовать шаг за шагом, выработать список конкретных действий, чтобы а) предотвратить повторную ошибку, б) если
уж ошибка произошла, то она не должна привести к негативным результатам.
А самое главное — человек уже совершил ошибку, в здоровой компании он не захочет повторения этой ситуации и вряд ли сделает это ещё раз.
Правильные действия после инцидента — собрать группу, расследовать шаг за шагом, выработать список конкретных действий, чтобы а) предотвратить повторную ошибку, б) если
уж ошибка произошла, то она не должна привести к негативным результатам.
А самое главное — человек уже совершил ошибку, в здоровой компании он не захочет повторения этой ситуации и вряд ли сделает это ещё раз.Практика показывает обратное. Если человек привык учиться на своих ошибках, он будет это делать до конца своих бренных дней.
Собирать комиссию по расследованию аварий хорошо и правильно, но даже коллективный разум не способен предугадать всех возможных действий, который может совершить безумный инженер.
Неотвратимое наказание за любую ошибку приведёт только к порочной практике искать виновного, обкладывать бумажками, чтобы снять с себя ответственность, параличу при принятии решений и даже деплою изменений.В здоровой компании изменения производят в технологическое окно, предварительно расписав риски, вероятный простой сервиса и план отката, в случае неудачи. Естественно, предварительно и заблаговременно предупредив всех заинтересованных лиц. Порочная практика втихаря накатить обновление в пятницу вечером и уйти пить пиво, выключив телефон, должна уйти в прошлое хотя бы среди профессионалов.
Не знаю, в каких здоровых компаниях вы работали, но если абсолютно любые изменения производить в «технологическое окно», то
1) в работе будет паралич — каждое изменение же надо согласовать
2) клиенты разбегутся (или обращать внимания не будут) — как можно предупреждать о возможных простоях три раза в неделю?
Если уж на то пошло, изменения (как и аварии) делятся на несколько категорий, только вот нельзя заранее угадать, что из-за косяка инженера/ошибки оборудования/наложения нескольких таких работ (бывали случаи, в момент проведения работ резервный кабель рвал экскаватор или попросту на площадке выключали свет) невинное изменение превращалось в аварию высокой категории
1) в работе будет паралич — каждое изменение же надо согласовать
2) клиенты разбегутся (или обращать внимания не будут) — как можно предупреждать о возможных простоях три раза в неделю?
Если уж на то пошло, изменения (как и аварии) делятся на несколько категорий, только вот нельзя заранее угадать, что из-за косяка инженера/ошибки оборудования/наложения нескольких таких работ (бывали случаи, в момент проведения работ резервный кабель рвал экскаватор или попросту на площадке выключали свет) невинное изменение превращалось в аварию высокой категории
я думаю речь идет об этом канале www.twitch.tv/dmfigol
Возможно. Не буду теряться в догадках.
Скажу лишь, что впервые за 5 лет не пожалел о купленном антивирусе. Доверие к ссылкам на этом ресурсе упало в минуса.
Скажу лишь, что впервые за 5 лет не пожалел о купленном антивирусе. Доверие к ссылкам на этом ресурсе упало в минуса.
Имелся в виду канал на ютубе, а конкретно его плейлист.
В автоматизации сетевой инфраструктуры есть маааленькая проблемка. Если мы хотим выкатывать конфигурацию "не глядя" (роботами), то нужны тесты. И всё хорошо пока мы копаемся в LAN-песочнице. А потом у нас пяток аплинков и у каждого свой full view, причём живой.
Как показал печальный опыт, нельзя заменять живой full-view статической репликой (не воспроизводит волнительный опыт флапающих между карриерами AS'ок). А вот софта для bgp save/reply я не видел. Хотя очень хотел бы.
Согласен, очень сложный вопрос с бордерами и даже рефлекторам.
Но как бы то ни было — катить конфигурацию придётся. Руками или роботом — не так важно.
Весь вопрос в правильности сгенерированной конфигурации.
Тут поможет наглядный дифф, который нужно подтвердить двум людям до деплоя и выкатка на тест, чтобы очевидные проблемы выявить.
Но как бы то ни было — катить конфигурацию придётся. Руками или роботом — не так важно.
Весь вопрос в правильности сгенерированной конфигурации.
Тут поможет наглядный дифф, который нужно подтвердить двум людям до деплоя и выкатка на тест, чтобы очевидные проблемы выявить.
Ох… Проблема в том, что большая часть проблем нифига не очевидная. Т.е. роботы прекрасно могут проверить, что мы анонсируем то, что должны анонсировать и т.д., а вот нетривиальные вещи проверить просто невозможно, и никакие глаза тут не помогут. Если юнит-тесты самих роботов сфейлились (в смысле, пропустили баг), то глазами его точно не увидишь. А в современном bgp проблема ещё круче: к моменту, когда человек может отладить проблему робот обычно уже следующую конфигурацию подготовил, а старая уже просто не актуальна.
Увы, увы, SDN пришёл там, где его не ожидали, и не все ему рады. И пришёл он не потому что solve problems, а потому что provide opportunities (это означает, что он может вместо решения проблем поднакинуть ещё).
Ну я всё ещё здесь не вижу причину в автоматизации и тестах. Это, скорее, вообще особенность современной сети — она слажная.
И на самом деле есть вещи, которые мы не увидим глазами, но могут увидеть роботы. То есть мы прогнозируем целевое поведение, и проверяем его после коммитов.
Например, крайне сложно глазами быстро отловить, что на каких-то маршрутах коммьюнити отъехали, особенно, если принимающая сторона не в нашей ЗО, и нельзя проверить на их стороне.
И на самом деле есть вещи, которые мы не увидим глазами, но могут увидеть роботы. То есть мы прогнозируем целевое поведение, и проверяем его после коммитов.
Например, крайне сложно глазами быстро отловить, что на каких-то маршрутах коммьюнити отъехали, особенно, если принимающая сторона не в нашей ЗО, и нельзя проверить на их стороне.
Спасибо за Ваши статьи, всегда интересно и познавательно.
Ничего личного — просто зашел выразить свое почтение и благодарность.
Начало многообещающее.
Начало многообещающее.
Спасибо за статью, очень интересное содержание и легкий слог. Есть несколько вопросов по материалу.
Зачем хранить бэкапы в гите? Это ведь, при вашем подходе, данные, которые можно получить путем применения CI/CD пайплайна. Конечно же, бэкапы необходимы, но складывать их в гит, на мой взгляд, не самая лучшая идея.
Как будет контролироваться идемпотентность применения кофигурации? Будет ли конфигурация катиться полностью или будет высчитываться дифф? Как система управления конфигурацией поймет какое состояние на сетевом устройстве?
Зачем хранить бэкапы в гите? Это ведь, при вашем подходе, данные, которые можно получить путем применения CI/CD пайплайна. Конечно же, бэкапы необходимы, но складывать их в гит, на мой взгляд, не самая лучшая идея.
Как будет контролироваться идемпотентность применения кофигурации? Будет ли конфигурация катиться полностью или будет высчитываться дифф? Как система управления конфигурацией поймет какое состояние на сетевом устройстве?
Я напишу обо всём в своё время.
Скажем так, я пока не продумывал все детали наперёд. Возможно (наверняка), некоторые вещи я пересмотрю.
Но пока считаю, что хранить бэкап в гите недорого, но может принести пользу — например, проверять диф, что не появилось что-то лишнее тогда, когда не было никакой выкатки.
Другой момент — знать фактическое состояние сети на любой момент времени.
Пайплайн выкатки конфигурации считают целевую на определённый момент. Благодаря нему мы не узнаем, что было с сетью 8 месяцев назад.
Почему?
Этот и следующие вопросы всё же достойны отдельных статей, а не комментариев.
Скажем так, я пока не продумывал все детали наперёд. Возможно (наверняка), некоторые вещи я пересмотрю.
Но пока считаю, что хранить бэкап в гите недорого, но может принести пользу — например, проверять диф, что не появилось что-то лишнее тогда, когда не было никакой выкатки.
Другой момент — знать фактическое состояние сети на любой момент времени.
Пайплайн выкатки конфигурации считают целевую на определённый момент. Благодаря нему мы не узнаем, что было с сетью 8 месяцев назад.
складывать их в гит, на мой взгляд, не самая лучшая идея.
Почему?
Как будет контролироваться идемпотентность применения кофигурации?
Этот и следующие вопросы всё же достойны отдельных статей, а не комментариев.
Почему?
В этом суждении я руководствуюсь мнением Джеза Хамбла и Дейвида Фарли, которые в своей книге «Continious delivery», обсуждали процесс СI/CD, а также связанные с ним вопросы. В частности, обсуждалось хранение артефактов сборки. И хотя авторы допускают хранение артефактов в гите, они считают что так делать не стоит, поскольку артефакты достаточно просто получить из кода, путем запуска пайплайна.
например, проверять диф, что не появилось что-то лишнее тогда, когда не было никакой выкатки
Возможно, в дальнейшем вы откажитесь от практики ручного входа на оборудование. Дело в том, что при ручных правках конфигурации вы приводите систему из известного состояния (полученного в ходе CI/CD, выполнения тестов) в неизвестное состояние. Подобное может привести к сбою в процессе деплоя новых версий конфы, сбоям в момент применения конфы руками. Она ведь становится не протестированной как в пределах самой себя, так и во взаимодействии с остальным оборудованием. Пишу об этом, поскольку мы много такого хапнули при применении конфигурации на сервера. В итоге, отказались от входа на сервера вообще и конфа катится только пользователем ci.
Этот и следующие вопросы всё же достойны отдельных статей, а не комментариев.
В таком случае, с удовольствием прочитаю следующие статьи. Видите ли, у нас возникла схожая потребность, а именно, сделать IaC. С серверами все хорошо, есть пайплайны, тестирование и т.п, а вот к сетевому оборудованию пока непонятно как подобраться. Вопросы, которые я задал выше — это те вопросы которые сейчас перед нами стоят.
UFO just landed and posted this here
Тут еще с лабораторным окружением загвоздка: полностью повторять физическую сетевую инфраструктуру по понятным причинам никто не станет, а виртуальные устройства, мягко говоря, не аналогичны аппаратным. Вот и приходится вносить элемент лотереи в использование автоматизации.
Если только боевая инфраструктура полностью виртуальная, тогда, наверное, да «можем повторить». А какие-нибудь Nexus 9K + куча FEX на них с vPC — не виртуализируются полностью. Или сейчас уже не так?
Если только боевая инфраструктура полностью виртуальная, тогда, наверное, да «можем повторить». А какие-нибудь Nexus 9K + куча FEX на них с vPC — не виртуализируются полностью. Или сейчас уже не так?
Спасибо за интересную статью! С нетерпением жду продолжения.
Очень хотелось-бы что-бы вторым счастливчиком в мультивендорной сети кроме джунипера Вы выбрали Cisco нексус 9/3к.
Очень хотелось-бы что-бы вторым счастливчиком в мультивендорной сети кроме джунипера Вы выбрали Cisco нексус 9/3к.
Если я что-то и выберу кроме джунипера, то в последнюю очередь это будет нексус :)
Это такая чисто идеологическая неприязнь к нексусам или что-то большее с практической точки зрения? На практике, почти как в вашем примере, небольшой multi-site/multi-pod ДЦ с VXLAN/EVPN/mutlicast с несколькими десятками нексусов — все замечательно живет (без серьезной автоматизации пока).
В любом случае спасибо ещё раз за интерсную и актуальную тему.
В любом случае спасибо ещё раз за интерсную и актуальную тему.
Sign up to leave a comment.
Автоматизация для самых маленьких. Часть нулевая. Планирование