В какое удивительное время мы живем, вот например рекламное видео нового терминала Windows https://www.youtube.com/watch?v=8gw0rXPMMPE

Вкладки, рендеринг текста, эмоджи и кастомизация вашего терминальчика в 2к19 от Microsoft.

Летом обещают залить в магазин приложений, а официальный релиз состоится ближе к концу года. Код для "поиграться" доступен уже сейчас: https://github.com/microsoft/terminal

DNS потихонечку переползает на Query Name Minimization, без особой помпы поддержка добавляется в существующие решения. Как результат всё меньше кто-то будет знать об истинных намерениях каждого. Наверное, это хорошо. Время "Интернета для технарей" прошло, поэтому заменили спокойствие - можно всё посмотреть и понять, на спокойствие обратное - меньше знаешь, крепче спишь.

Хм... ЦРУ открыло своё представительство в TOR: ciadotgov4sjwlzihbbgxnqg3xiyrg7so2r2o3lt5wz5ypk4sxyjstad.onion

​Ну теперь понятно, как защищаться от угроз сети.

У Kaspersky есть красивая карта с данными о вредоносной активности. То же что и здесь, но с большим количеством подробностей и статистики по всем странам. Россию больше всего атакуют, но тут возможно перекос из-за зоны наибольшего распространения Касперского у нас.

L2 дизайн против L3 на примере одной аварии. По моему опыту L2, в первую очередь, сложен своей отладкой у которой нет простых инструментов вроде traceroute, а последствия сбоя часто катастрофические, как в статье.

Когда какой-то коммутатор по своей прихоти начинает флудить в широковещательный домен, или подменять маки, начинают происходить странные, совсем не очевидные вещи. Заглянуть внутрь вилана сложно, а косвенные признаки можно интерпретировать по разному. В итоге, жалоба клиента: "У нас не работает DHCP (RIP, да что угодно) в вашем канале, хотя всё остальное вроде бы работает" - превращается в бесконечные часы тотального траблшутинга всего, пока в итоге не подключается сниффер и не находится флудящее устройство. И это реальный пример из практики нашего NOС, не самый разрушительный. Про кольца можно не говорить: STP по своей сути, протокол предотвращения аварии которая уже есть, а не созидательный (архитектурный) протокол, ERPS не многим лучше. Единственный способ работать с L2 - это регламентировать всё, задавая самые строгие из возможных режимов ничего не давая на откуп автоматике, но это добавляет сложностей в обслуживании.

У L2 есть красивые, быстрые решения для отказоустойчивости, например просто LAG или MLAG, vPC или любое другое специфичное название и этим хочется пользоваться. Но и это не всегда работает хорошо, даже LAG, особенно на стыке двух вендоров, или софтового и железного решения.

Ошибки могут быть у всех, но с выводами статьи я согласен - L2 можно пользоваться, но с бОльшим риском.

Свой speedtest как альтернатива speedtest.net, хотя к нему все и привыкли да и HTML5 он уже может. Но эти попугаи ничем не отличаются от тех попугаев. Выглядит красиво и можно под себя подстроить.

Пример настройки NAT из IPv6 в IPv4 и обратно на JunOS. На кажущуюся странность подобный подход очень простой, позволяющий оттянуть полномасштабное внедрение IPv6 достаточно далеко.
Если начать использовать IPv6 адреса у своих клиентов непосредственно, то сразу возникают задачи биллинга (у провайдеров), задачи аутентификации и безопасности. Потому что многое из того что есть заточено под IPv4. А с NAT можно остаться на IPv4 внутри, используя IPv6 снаружи. Наверное и я бы так поступил по возможности, но это двойная работа в будущем.

Питон для сетевых инженеров.

​Виджет с количеством BGP префиксов на разных устройствах в сети RIPEStat. Мне проблема кажется надуманной, но если можно сделать почему бы и не сделать. Гораздо интереснее наблюдать какой BGP разный, даже по количеству префиксов в разных частях Интернета. Каждый видит свою картину мира и только свою.

По пути на работу последние две недели я читаю книжку про Docker. Достаточно лёгкое чтение про базовые принципы современного, я бы уже не назвал это передовым, подхода к проектированию и работу программного обеспечения. Есть про всё, собственно Docker и механизмы управления им, облачные провайдеры, CI/CD, тестирование, микросервисы. Всё с конкретными простыми примерами для существующих продуктов. То есть, это книжка как пользоваться, а не как всё устроено. Знаете можно читать использование Linux и там будет описание ядра, прерывания, системные вызовы, а можно читать книгу с практически таким же названием и там будет как мышкой переместить файл из одной папки в другую, вот моя книжка это второй вариант.

И чем дальше я читаю тем больше понимаю откуда взялось выражение "сисадмины не нужны" или "сетевики не нужны". Потому что действительно не нужны. Если следовать логике изложения всё решается или самими разработчиками продукта и всё что нужно уже есть в докер образе, или высокоуровневыми концепциями связи контейнера с контейнером и подобными, не заботясь о том что это вообще значит, полагаясь на реализацию конкретного продукта или облачного провайдера. Я даже стал верить в это.

Опасное это заблуждение или нет, не могу сказать. Может вообще не заблуждение. Книга про основы, даже скорее для начинающих. В начале пути всегда кажется что всё известно, в других работах наверняка раскрывается больше тонкостей. Но очевидно что сети меняются и меняется роль специалиста по сетям. Под всё большим вопросом символ админства и скрытой магии - CLI, в блоге CellStream хорошее рассуждение Andrew Walding по этому поводу. Вопрос не просто в командном режиме который можно было бы использовать и через систему управления не попадая в консоль напрямую, а в полном уходе к высокоуровневым методам API.

Бояться изменений - остаться не у дел, так что пропускать тренды точно не стоит, но и слепо отказываться от того что было неправильно. Выйдет ли из этого симбиоз, мы это точно увидим в ближайшем времени.

Про книжку забыл, исправляюсь. Я выбирал только по одному критерию, чтобы на русском. Эдриен Моуэт "Использование Docker" 2017 год (по ссылке дальше в канале есть сама книжка). Автор много ссылается на будущее и пишет о многих продуктах как о находящихся в тестировании, но тут надо сделать скидку на год, всё уже работает у всех.

Мне не с чем сравнивать, так что не могу дать оценку качеству материала, с чем я сталкивался всё приемлемо. Читается легко для меня, есть код на Python, YAML, shell который поясняется постольку поскольку, лучше с этим быть знакомым. Есть подозрение что нужно быть в принципе знакомым с концептом микросервисов и программированием, тестами, но в целом все эти понятия объясняются с нуля.

Шпаргалки по регулярным выражениям со спецификой Vim: поиск, замена, описание и примеры. Даже для тех, как я, кто редактирует не больше 5 строчек в Vim в неделю, полезно. Я вот сегодня воспользовался, забыл как адресуются строки в режиме поиска.

Интересно, что многие реализации очень похожи, но в чём-то всё же есть отличия. Разве что на заре Unix команда g/REGEXP/p в редакторе ed работала в точности как утилита grep, потому что это был один и тот же код.

Microsoft выпустила патч для CVE-2019-0708 - можно получить удалённый доступ к системе через RDP и делать что хочешь: An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. Всё настолько серьёзно что и для XP есть патчи. С Windows 8 и 10 всё в порядке.
И у Cisco похожая история, можно управлять всем, вплоть до загрузчика.

На ближайшем RIPE78 Max Rottenkolber расскажет про Vita, это такой очень производительный VPN на Lua. Всё это в комплексе вместе со snabb - фреймворком для высокопроизводительной обработки трафика в userspace. В отличие от DPDK не привязан к Intel.
Цель всех подобных решений избавиться от посредника в виде ядра, которое своей универсальностью ломает производительность. Стоит упомянуть ещё packet_mmap, pf_ring, netmap, другие тоже есть. Ключевые слова для поиска Zero Copy и Userspace IO. Это позволяет выжимать гораздо больше чем может ядро зажатое рамками планировщика и прерываниями. Совсем прямой доступ к железу никто давать всё равно не хочет, хотя Intel с очередными багами в процессорах старается. Во времена DOS с этим было проще :-)

Прелесть многих старых протоколов прикладного уровня в том что они диалоговые: FTP, IMAP, в меньшей степени HTTP. Одна строчка вопрос, в удобочитаемом виде, одна или много в ответ, в более или менее читаемом виде. Модный сейчас JSON при всей его читаемости всё же машинный формат. Формировать запрос вручную почти не имеет смысла, это делает программа и программист, что и в случае бинарных протоколов.
Возможно имеет смысл унифицированный формат для всего, поэтому JSON везде, даже в почте и называется это JMAP. Cтатья в блоге IETF, потому что, видимо, процесс стандартизации к концу подходит. А за подробностями надо идти на сайт jmap.io

Про все утилиты знали? Для себя пару новеньких открыл. В начале есть пару ссылок на другие списки программ, не менее полезные.

Почти просто про PIM и мультикаст маршрутизацию на Habr. Совсем просто написано про PIM DM, про сообщения и общие принципы что к чему. Про PIM SM с его RP в принципе сложнее, так что проще не напишешь. Чтобы включить и всё заработало хватит. У мультикаста полно нюансов, но тут только опыт помогает.

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

Пылинка на оптическом волокне может стоить вам рабочей магистрали. Fluke крутые, у нас таких нет. Видео презентация.
На какой-то из конференций представитель Flukenetworks хвалился что у Тони Старка есть их продукция, даже видеодоказательство показывал из первых Мстителей, но я уже забыл в каком моменте.

По поводу аварии в Яндекс.Облако.

Амазон терял данные пользователей на EBS в 2011 году.
Сервис S3 лежал несколько часов в одном из регионов. Из-за этого у конечных пользователей были проблемы различного масштаба, от сломавшихся холодильников до неработающих пультов от телевизора.

GitLab убил production базу. Во время восстановления выяснилось, что бекапы работали некорректно, и восстановили в итоге из снимка ФС по чистому везению.

ЦОД GCP ушел в отказ, когда в него ударила молния два раза подряд. Два. Раза. Подряд.

Github в результате цепочки отказов работал в деградированном режиме 24 часа и 11 минут.

Про отказы Facebook, Instagram и ВК я вообще молчу.

У меня нет инсайдов о том, что именно произошло в Я.О, но по тем крупицам информации, что я нашел - это не самое страшное, что могло случиться, и масштаб трагедии гораздо меньше, чем пишут на Pikabu и Хабре.

На DevOps Forum Moscow я сказал, что будущее ИТ за развитием публичных и гибридных облаков, и Яндекс делает титаническую работу.

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

Прекращайте спекуляции и own your reliability (c)