Патчкорд

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

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

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

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

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

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

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

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

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

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

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

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

По автономным системам, с IPv6 префиксами растёт быстрее - 2000 в год, но их всё ещё в два раза меньше чем с поддержкой IPv4, которые росли медленнее - 1000 в год. Не забываем, что это пересекающиеся множества. Может быть в этих графиках появятся данные по автономкам только с IPv4 и IPv6 префиксами, чтобы было понятно за счёт чего этот рост, добавление IPv6 в существующие или создание новых только с IPv6.
Ещё графиков которых нет и которые я собираюсь добавить, это графики с долями по длинам префиксов: IPv4 /24 было 59% в начале года, сейчас 60%. IPv6 /48 - 42,6% выросло до 45,1%. Можно аккуратно предположить что IPv6 в стадии роста конечных пользователей с собственными сетями, а IPv4 кончились совсем, даже разбивать существующие сети уже не на что, но может мы до точки перелома ещё не дошли, когда количество IPv4 префиксов увеличится лавинообразно.

Всех тех кто отдыхает и всех тех кто всегда на работе, даже не знаю кого здесь больше, поздравляю с наступившим Новым 2024 годом. А чтобы время не терять зря, экспресс анализ года уходящего по тому, что уже посчитал @FullViewBGPbot.
Напомню, это данные коллектора RRC0 из проекта RIS RIPE NCC, там немного больше префиксов, на несколько десятков тысяч, чем вы можете увидеть у себя в Full View.

Интернет стабильно растёт на 30000 префиксов в IP4 и в IPv6, превысив соответственно миллион и 200000 в каждой из таблиц. Я не строил графики по этим данным за предыдущие годы, поэтому сравнивать не с чем, это мы сделаем чуть позже по данным @bgp_table_bot, но предположу, что сравниться с тем так быстро росло количество префиксов 5 лет назад у нас не выйдет. Миллион, наверное, то что будет во всех Full View в текущем 2024 году, ближе к концу года скорее всего.

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

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

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

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

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

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

Сначала был 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 для работы с уже готовыми сертификатами.

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

В этом году вот такая новогодняя ёлочка с которой мы выиграли конкурс ёлочек нашей компании. И ASCII календарь на следующий 2024 год, взамен старого. Всех с наступающим Новым годом и последней рабочей неделей этого года!

Если успеете прочитать "OSI Deprogrammer Re-conceptualizing cyberspace" до Нового года, а читать очень много, то вам определённо будет что жарко обсудить, где-то на 5-6 день выходных. Автор очень эмоционально ратует за то, чтобы упоминание семиуровневой модели OSI было исключено отовсюду как не только не актуальное сейчас и никогда не бывшим актуальным для Интернет и сетей, кроме мейнфреймов 70-х, но и в принципе бесполезное с какой стороны не посмотри. Доводы строятся на очень чётком следовании терминологии, как она озвучивается в модели OSI и ассоциации этой терминологии с современными сетями.

Беда, или счастье, но данность такова, что очень мало людей, в сетях в том числе, заглядывали дальше названий уровней и приблизительного их описания. Я специально открыл учебник Олиферов, там 15 страниц про это из 800, и на тех же страницах вводятся понятия и принципы протоколов, интерфейсов, стандартизации, важности открытого подхода, пол-лекции в университете в лучшем случае, а на собесах один вопрос про понимание принципа декомпозиции и построения стека протоколов. Поэтому модель OSI, как таковая, даже будучи прочитанной в учебнике, на практике не использовалась, разве что номера уровней прочно вошли в профессиональный жаргон.

То что OSI описывает одну сеть с разными уровнями, а у нас много сетей друг над другом и множество более детальных примеров, особенно, что касается сеансового уровня и уровня представления, используются автором в качестве базовых аргументов вредности модели OSI, которая путает все понятия и не отражает по его мнению современные сети ни коим образом. Очень много про профессоров университетов и учебники, которые держатся и преподают модель OSI, но тут наверное личное :).

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

И в целом, сложно не согласится в том что OSI как стек протоколов не прижился и в университетах можно было бы сразу учить о TCP/IP например, но, НО!, TCP/IP это один из многих, очень многих, а принципы декомпозиции, протоколов, интерфейсов и уровней как ни крути общие, пусть они к модели OSI, если читать всё буквально имеют опосредованное отношение. В блоге APNIC тоже небольшой обзор, можно начать с него и парочка комментариев, что не всё так однозначно.

К зимнему солнцестоянию QratorLabs опубликовал свой отчет по стабильности национальных интернет сегментов, расписав алгоритм.

Критерием устойчивости национальных интернет сегментов в этом алгоритме является некое произведение от метрик, в которм базой является доступность к Tier1.

Однако, тирваны это не центр интернета, в котором сосредоточены интересы пользователей, тирваны - это последний (резервный) путь ко всему интернету. Этот путь длиней, чем прямые связи, на один-два-три AS хопа, ведь вожделенный контент находится не на тирванах, а вне их. часть ближе к нам, чем к ним.

Хорошая связность операторов определяется не близостью к тирванами, а прямыми стыками со всякими ютубами, вконтактиками, акамаями, мейлрушечками и прочими твичами-тиктокам-телеками и запрещенными метами. Большие национальные операторы, заботящиеся о надежности и качастве своих услуг, минимизируют перепробег трафика через "центр" интерннета. Их связность организуется большим количеством разнотипных связей, а именно:
1) через прямые пиринговые или клиентские интерконнекты с ресурсами высокой популярности;
2) через точки обмена трафиком с просто популярными ресурсами и скромными индивидуальным трафиками для PNI;
3) через тирванов с редковсотребованным и далеким контентом.

При этом вес связности по трафику по п.1 где-то 70-80%, по второму пункту 15-25%, по третьему 5 - 10%. И никто не держит пустые емкости на тирванов с заметным запасом - они стоят денег! Портовая емкость операторов рунета в сторону тирванов не превышает 10% их портовой емкости в сторону популярных контент и сервис генераторов. Поэтому, когда бахнется у какого-то большого оператора России, не дай бог, прямые стыки с ВКашечкой или Гуглом тирванские порты не пропустят нужный трафик, задропятся и тут же начнут умрать. Поэтому стабильность как прямая доступуность всей совокупности тирванов - это та еще натяжка... А кого у нас принято натягивать? Правильно!

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

И нам это нравится. Спасибо, QratorLabs!

Труд полностью лежит тут

https://radar.qrator.net/blog/articles/184

читайте, думайте, умнейте.

On little-known Russian e-commerce sites like Nag, OCS Distribution, 3Logic Distribution and 4Telecom, complex technologies made by major American and European telecom manufacturers, such as Cisco, HP, Juniper, Ericsson and Nokia, are listed for sale.

- читаешь такое и думаешь, ну вроде обычное дело и всегда так было и никто за лицензионной чистотой особенно не гнался, порой даже наоборот, по крайней мере в "альтернативных" провайдерах да и в больших тоже. Вот в больших корпоратах, как мне сейчас видится, всё немного по другому происходило: контракты, лицензии, прямая поддержка от вендора - но и они свой условный НАГ нашли теперь, наверное, с контрактами и поддержкой. А малоизвестный в широких кругах НАГ, но хорошо известный в узких, теперь не такой малоизвестный :) с чем можно его и поздравить - это признание.