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

Сначала был Jon Postel, IANA и InterNIC, потом появился RIPE NCC, следом APNIC, ARIN заменил InterNIC получив в наследство всё что выдавали ранее и никуда не влезающее, далее образовались LACNIC и AFRINIC. Чтобы никому не было обидно IANA поделила блоки /8 между RIR, но не все. Потом IPv4 стали кончатся, IANA отдала последнее, RIR стали меняться адресами и всё немного запуталось и IANA перестала владеть информацией обо всех перестановках адресов среди RIR. А потом придумали RPKI, а так как полной информацией не владеет никто, то соответственно, и нет единого центра, который может подтвердить достоверность подписи выданных объектов, точнее таких центров пять, для каждого RIR свой.
Предложение что с этим делать от Geoff Huston в блоге APNIC - всё-таки сделать мастер ключ для всех, используя статистику предоставляемую RIR для NRO, если уж IANA не обладает всей полнотой данных. Правда, чтобы ничего не сломать, придётся немного подправить OpenSSL для работы с уже готовыми сертификатами.

Сайт с ценами на Интернет по странам internetpoverty.io. Цель конечно другая, считают страны и людей которым недоступен приличный (1ГБайт/Мес., 10Мбит/c) мобильный интернет по финансовым причинам. Сильно не очень, по сравнению со всеми остальными, в основном в Африке, и в некоторых странах не смогли посчитать. Но при этом, посчитали отдельно для женщин и мужчин. В России цена мобильного Интернета по этим данным 14,1$, я плачу сильно меньше. Но так как используемые попугаи одни и те же для всех, то сравнивать можно.

Ожидаемый, для меня результат, что самые высокие результаты для использования SSH как удалённой консоли и передача файлов, даже парольная аутентификация 50/50, вот эти три варианта были моим выбором. Проброс X11 никогда не делал в принципе, прокси только пару раз чтобы выкрутится из ситуации. Проброс портов, я относительно не часто, но бывает использую, чтобы не выставлять наружу какие-то средства управления, вроде консоли БД. Наверное, SSH3 будет играть какую-то роль, если проект не забросят, а так случается с очень многими академическими проектами, но пока активность высокая.

Что-то точно случилось, а вот что?

Резко упал объём IPv6-трафика, наблюдаемого на точке обмена MSK-IX. Предположение — через данный маршрут к операторам перестали ходить Google и особенно YouTube, который является наиболее весомым трафикогенератором с поддержкой v6.

"В письме американской компании говорится, что с января 2024 года она перестанет передавать трафик через серверы маршрутизации на точках обмена трафиком." — https://www.rbc.ru/technology_and_media/25/12/2023/6585c3239a79478e653d35d1

Операторы приглашаются к открытию двусторонних подключений непосредственно с самим Google, без использования MSK-IX и подобных.

Драма сегодняшнего вечера - у Orange Испании угнали учётку от сервисов RIPE NCC и поломали связность изменив принадлежность их префиксов в RPKI. Но уже починили. Я думаю, что теперь остаётся только ждать подробностей, от Orange и от RIPE NCC, кто, что, когда и почему.

Потому что безопасность должна быть безопасной - Нексусы не нужны и цена не важна. Для безопасного просмотра на 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.