Потому что безопасность должна быть безопасной - Нексусы не нужны и цена не важна. Для безопасного просмотра на Linkedin нужен безопасный VPN. Здесь же где-то берёт начало параллельный импорт ;) ?

Мой товарищ спросил меня как-то: "Зачем я пишу о книжке, если в конце говорю что её не надо читать?" - очевидный ответ, чтобы её не читали, по причинам про которые я написал :) . Если читали, чтобы сравнить собственные впечатления после прочитанного, с не парадными впечатлениями ещё одного читателя. И в конце-концов отнестись критически и прочитать, чтобы согласится или не согласится с озвученным мнением. Книга в любом случае оставила впечатление достаточное чтобы про него сказать, книги без такого впечатления пылятся дальше без всякого упоминания.

В общем, я с трудом осилил "Site Reliability Engineering" от Google, с трудом, потому что попытки читать перед сном приводили к этому самому сну раньше чем я планировал, а в другое время - к активной скуке, потому что всё в духе Капитана Очевидность. Вроде как опять негативный отзыв, но почитать скорее стоит, чтобы оценить взгляд Google на DevOps и даже не столько на него, тем более есть несколько историй изнутри, не сказать чтобы детально описанных, но они есть, да и актуальность всё ещё присутствует, может быть поэтому и скучно, потому что такого очень много вокруг. Кстати, я почему-то думал что SRE не про DevOps, но книга в общем и не про него.

Структурно это набор статей, в нескольких разделах, где-то есть перекрёстные ссылки, но в целом каждый раздел самостоятелен, часто и каждая глава-статья самостоятельны. Во второй половине третьего раздела практически не упоминается про SRE/DevOps там про балансировку, консистентность, отказы, мониторинг, тесты, развёртывание в распределённых системах, не сказать что технически глубоко, но они больше всего технические. Вся книга по задумке, как мне показалась - про надёжность, в конце делается даже попытка сравнить как дела обстоят в разных отраслях, по отзывам сотрудников Google ранее в этих отраслях работавших. Но это не учебник, да и приведённого небольшого набора практик хватит на то чтобы только оценить свои подходы через ещё одну призму. Про надёжность как предмет изучения, к своему ужасу, я не могу вспомнить ни одной конкретной инженерной лекции в университете, всё больше про абстракции и вероятности, а вот в более приземлённом колледже что-то было, как минимум ориентироваться в терминах учили.

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

Итого, SR инженер, который DevOps, это конкретная должность по версии Google причём так же прямолинейно делящая свои обязанности по времени - 50% на операционную деятельность и 50% на инженерную деятельность. Операционная деятельность, рутина - сервису надо больше памяти чем обычно, видим тикет, накидываем память. Инженерная деятельность - найти причину утечки, если она в инфраструктуре, что-то автоматизировать, что-то инфраструктурное переписать, а если дело в самом сервисе то поработать с разработчиками. Если мы знаем что память можно накинуть автоматически, по каким-то предпосылкам, а потом убрать, то можно и так сделать, главное не в ручную. При этом SRE скорее не разработчик, хотя на эту позицию ищут людей с опытом разработки, есть целая глава с примером как писали сервис внутри службы SRE и как это важно - программная разработка, но её наличие мне показалось именно подчеркиванием исключительности этого. Упоминается что это часто что-то не очень большое и разработчики сервисов отделены от SRE, эволюционно (на момент выпуска книги 2016 года), Google пришли к тому что SRE надо приглашать на этапы разработки сервиса, чтобы сразу оценивать его будущую надёжность, но непосредственное участие в разработке они не принимают.

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

Интересно про жёсткое следование правилу 50 Dev/50 Ops - если упустить собственно Ops с перекосом в Dev, то инженеры перестанут понимать внутренности построенной системы, не хватит оперативных знаний и опыта и всё начнёт разваливаться. А если будет перекос в Ops то всех заест рутина, эффективность упадёт, сотрудников надо будет набирать больше. В приложениях есть конкретные опросники и примеры документов, в главах есть примеры работы с этими документами. В 2016 году, кстати, Google был за проектные команды в одном физическом месте, так проще с коммуникацией, хотя строгость подхода к дежурствам подразумевает что будь хоть какая авария, обязанность по её ведению передаётся новой смене если текущая смена кончается, пусть она даже заступает за тридевять земель.

Читать стоит, если никогда не касались вопроса организации службы эксплуатации не важно DevOps или нет, я думаю будет интересно. Если касались, настройтесь получить интерес в ответе на вопрос: "А как у них?".

Обещанные результаты в сравнении с прошлым годом для BGPv4 и BGPv6 по графикам бота от Darren O'Connor. Я бы назвал это сохранением трендов - замедление роста IPv4 префиксов до 25-30К за год, в прошлом году 35К и постоянство IPv6 ~30К за год. Если вспомнить допандемийные годы, то там стабильность была в IPv4 и нарастающий темп в IPv6. Наверное, это что-то да значит, но прогноз придётся поправить - миллион префиксов в IPv4 с таким ростом мы в 2024 не увидим, может даже и в 2025 не увидим.

Напоминание о том что бывают разные traceroute, стоит только поискать, если вас по каким-то причинам не устраивает стандартная утилита.

Windows и Linux разные, очень разные и вряд ли что-то изменилось. Я как-то пытался читать и бросил "Внутреннее устройство Windows" Руссиновича и других авторов - очень сложно для понимания, особенно без практики, там сама суть другая - не UNIX. В комментарии по ссылке выше как раз про это: объекты, фильтры, путешествие всего этого добра по стеку сверху вниз, потом снизу вверх. Могу лишь сказать что с WSL работать пошустрее чем с Cygwin, но утилиты Cygwin в стандартной Windows консоли очень удобно запускаются сильно расширяя классический набор ещё DOS команд, за этим и продолжаю его держать.

HPE Juniper Networks

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

Дыхание вашего Интернет подключения gfblip.appspot.com, подробности на Github.

Пока это ещё смешно, парочку на вечер https://procurve.juniper.mx. Но справедливости ради принтеры в отдельной компании вроде бы, не в HPE.

Простите

MPLS, VPNv4, RD и RT - вспоминаем что к чему и проверяем себя, что будет если забыть одну из частей пазла.

И ещё традиционной аналитики от Geoff Huston по размерам таблиц BGP и их обновлениям. И хотя в заключении говорится о неопределённости и сложности долгосрочных прогнозов, в самом начале говорится следующее:

The year 2023 marks a significant point in the evolution of the Internet where the strong growth numbers that were a constant feature of the past thirty years are simply not present in the data. Not only is the Internet’s growth slowing down significantly, but in the IPv4 network it appears to be shrinking, which is unprecedented in the brief history of the Internet to date.

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

Juniper новую фишку сделал для своих маршрутизаторов, сообщать в IPFIX причины сброса пакета, помимо тех что попали под ACL, например TTL дошёл до 0, или в MTU не влезли. В статье обзор и ссылка уже на документацию.

Прогресс в скорости решения задач оптимизации в линейном программировании с 1989 года составил 20 миллиардов раз. 60 секунд на решение в 2023 и 38000 лет для той же задачи в 1989 году, но конечно её в принципе невозможно было посчитать из-за отсутствия необходимых ресурсов. И это не только рост производительности компьютеров, но и производительности методов решения. В других задачах, может и не так хорошо, а может и ещё лучше, но точно прогресс не стоит на месте. Мы определённо в будущем, в бесконечно далёком от даже 1989 года.

Сканирование IPv6 адресов теория и практика во второй части. Конечно, и все это признают, что сканирование в лоб работает плохо, но кто сказал что надо делать именно так. Человеческий фактор когда хочется упростить и повесить свой маршрутизатор на первый адрес в подсети, связанные ресурсы, вроде DNS сдающие все адреса с потрохами, математические методы предсказания действительных адресов - всё это поможет найти достаточно целей в вашей сети, чтобы волноваться и не думать что это невозможно. Да и сканеры подтянулись, поэтому инструментов достаточно.

Семь шагов в семи статьях от Russ White от идеи до RFC.

В Linux 6.7 впилили новый тип сетевого интерфейса - netkit c BPF фильтрами, с помощью которых можно провести оптимизацию для виртуальных машин, чтобы поскорее принять очевидное решение и два раза внутри сетевого стека трафик не гонять.

Настройка авторизации по RADIUS на SR Linux, вроде как и везде, есть роли сразу из коробки.