Для тех, кто не хочет заходить на сайт этим сообщением передам все его содержимое, извините, если забью канал:
noibrs noibpb nopti nospectre_v2 nospectre_v1 l1tf=off nospec_store_bypass_disable no_stf_barrier mds=off tsx=on tsx_async_abort=off mitigations=off

Открыл для себя удивительный мир CPU-троттлинга.

Купил тут Lenovo P1, там i9 процессор, 2.6 ггц, 8 ядер HT, turbo boost до 4.8 ггц.
Я себе еще и памяти до 48GB добавил. Решил – я ведь админ, я куплю реальный айпишник и подниму на ноутбуке кластер, чтобы нет?
Мимоходом, решил проверить проверить результаты PassMark Performance тест. Поделился с друзьями. Результаты оказались таксебе. “У меня на старом десктопе лучше”, сказал товарищ.

Решил закопаться.

Итак, мир чудных открытий:

1. Если вы думаете, что Turbo Boost это как у вас на 386-м была кнопочка Turbo, вы ее нажимали, и оно разгонялось – теперь это не так. Ну то есть, он бустится, но если не заморачиваться, буст происходит в короткие моменты когда хочется сделать что-то побыстрее. Запустить приложение, когда ни одно приложение не запущено. Если вы решили загрузить все 16 виртуальных ядер никакого турбо буста у вас не будет. Сейчас попробую объяснить почему.

2. Существует throttling. Вы, скорее всего о нем слышали, вы скорее всего думали что Throttling работает так: после того как процессор достигает определенной температуры, его частота занижается, чтобы там все не расплавилось. Температура? Ну градусов 80-90 наверное? Так вот, троттлингов теперь миллиард. Посмотреть на их виды вы можете поставив Intel Extreme Tuning Utility, названия бояться не надо, разобраться можно за пару дней ресеча (боже, я так каждый раз хочу написать слово “задротство”, но мне не позволяет этика, в общем, каждый раз когда я пишу “закопался” или “ресеч” – вы знаете, что я имею в виду). Нас интересует Power Limit Throttling, так как это самая загадочная вещь, с которой вам придется столкнуться. Всем остальным вы можете более менее управлять. Power Limit Throttling (по крайней мере в условиях Lenovo P1 и вроде бы Dell XPS) не тюнится. Проблема особенно существует с i9 процессорами.

3. Что же происходит? Когда вы начинаете во всю грузить процессор, процессор начинает потреблять мощность (простите меня, мне кажется треть читателей за “потреблять мощность” хочет меня уже распять) так как работает на высоких частотах. “Система” (не знаю, что это за система, проклянаю, хочу знать и пропатчить), начинает смотреть на потребляемую мощность и текущую температуру процессора, она все еще ок, 60 градусов. Но если так дальше будет – она повысится, и придется троттлить по температуре, остывать дольше, чем не нагреваться. Поэтому на этом этапе система начинает гасить мощность.

Что происходит человеческим языком? (Если команда make на человеческом языке). Вы говорите make -j16 на ненагруженном процессоре, система начинает компилить и начинает потреблять 50-60 ватт, и компилит где-то на 4.5 ггц. Троттлинг, у меня судя по всему стоит где-то на 25. Система еще вообще ни капли не нагрелась, но говорит “айайай, я сейчас разогреюсь”, и троттлит мощность. Компилирование продолжается на 2.0 (даже не на 2.3), температура 60 градусов.
Можно отключить turbo boost вообще, тогда по make -j 16 вы загрузите каждый проц на штатные 2.3, получите свои 25 ватт которые не затроттлятся и получите хороший результат.
Третий вариант – компилите и хотите быстрее? Ноутбук можно поставить в холодильник. Знакомый складывает в морозильник. Штука, которая троттлит по мощности учитывает текущую температуру, так что помогает.

В общем, что эта информация может дать юному следопыту?
1.  Поставьте Intel XTU, если он у вас есть, погрузите процессор, последите за троттлингом (у меня power trottling включен практически постоянно).
2.  Изучите про андревольт и прочие штуки, которые затюнить которые поможет для борьбы с другими видами троттлинга.
3.  Подставка с охлаждением судя по всему реально поможет, если сбросит температуру. Люди также меняют термопасту итп.
4.  Захотите быстро отрендерить на современном ноутбуке – положите его в морозильник. Ну или в холодильную камеру, поможет.
5.  Когда читаете характеристики, если не хотите извращаться и мы говорим о лэптопе (не десктопе с нормальным охлаждением) смотрите на нижнюю цифру в частоте процессора, турбо буст так себе замануха.

Планка сверху по красной линии - это практически постоянный power limit throttling, температура, как видите не растет

в холодильнике результаты сильно лучше! 😂

А демосцена оказывается ещё не просто существует, а внесена Финляндией в список культурного наследия ЮНЕСКО.

По этому поводу вот там видео демки (первое место 2018 на Assembly - это такой фестиваль демосцены) и ссылка на все демки с Assembly с 1987 по 2020

https://youtu.be/TaEoAJw_0Zc

https://files.scene.org/browse/parties/

Для тех, кто не знает - люди писали (и, оказывается, пишут) программы, которые представляют собой клип из компьютерной графики с музыкой. Раньше, правда, влазили в килобайты, а теперь по сто метров программы весят, ну чтож.

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

https://youtu.be/MOYBlOBhQWE

https://habr.com/ru/company/itsumma/blog/498566/

Выложили на хабр мои заметки с конференции ReDeploy 2019 - конференции про Resilience Engineering на которой я был в октябре 2019-го.

"Долгие годы в процессе разработки программного обеспечения превалировала механистическая картина мира — вера в то, что мы способны разработать программное обеспечение, которое будет работать без аварий, а если авария и произойдет, у неё будет некая коренная причина (root cause), исправив которую, можно предотвратить повторение подобных ошибок в будущем — и, таким образом, поскольку число ошибок конечно, в итоге исправить все ошибки, приводящие к авариям (см. отличную статью Dev, Ops и Determinism про это).

Этот же «инженерный» подход применяется и к тому, как взаимодействуют во время аварии люди: достаточно создать некий инструментарий, воспользовавшись которым, люди смогут исправить проблему (при этом не допуская ошибок).

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

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

Про это и была конференция. Очень долго прокрастинировал с публикацией.

Конференция была в октябре и я написал заметки сразу после нее, но про первые 4 доклада, из 16-и и никак не мог добраться до остальных.
Коллеги убедили, что стоит. Надеюсь, теперь доберусь до остального :)

Оформил заметку про Kubernetes для ретроградов в статью на хабре.
https://habr.com/ru/company/itsumma/blog/499102/
Там же немного обсуждаю.

Немного о "дизайне" для "программиста".

В рамках актуализации знаний технических понял что надо возвращаться во фронт, я там сейчас как динозавр - последнее что помню - это "верстать дивами" и "jQuery", прости господи.
С точки зрения чистой разработки копаюсь вокруг тайпскрипта и Angular/React-а.
Но вопрос возник другой.

Системно появляются сервисы (SaaS-ы я имею в виду), которые явно сделаны одним-двумя людьми, с UX на уровне.
Мы еще когда-то давно с товарищем обсуждали, что в принципе - вполне реально собрать некий "базис" дизайна, UX и типографики, который можно использовать из проекта в проект.

Вот я, например, хочу в качестве pet-project-а сделать обучалку нотам на грифе гитары/клавишах.
Фронт будет говорить "а сыграй-ка мне ноту ре на грифе, там где она встречается между первым и пятым ладом" - и юзер будет играть, а программа - говорить правильно юзер сыграл или нет. Интервалы там спрашивать, итп.
(чтобы на секунду понять куда продвинулся "фронт" - вот например digital audio workstation - https://github.com/rserota/wad как Ableton итп, можете эффекты навешать на звук, итп. Ну и тюнер в комплекте - я им пользуюсь чтобы ноты разобрать).

Так вот, я стал всех спрашивать - куда же стоит пойти "учиться" чтобы собрать себе базис вот этот UX-ерский, чтобы потом самому себе придумать некий стиль, и его лупить от петпроджекта к петпроджекту, так чтобы при этом все красиво и удобно было?

Выношу из фейсбука самый подробный коммент, спасибо Диме Пронину:

"А собственно https://blog.prototypr.io/design-for-programmers-d38c56982cd0 и хватит.

Есть шрифты и типографика.
- Не копаемся, берем популярные шрифты и их пары.
- Выставляем нужную иерархию https://nowodzinski.pl/syncope/

Есть иллюстрации и смысл.
Гуглим иллюстрация, ильяхов, визуальное повествование
Статьи, вебинары, что угодно.

Цвета
Гуглим хорошие палитры. Material Palette, гуглим разные сочетания. Тут опасно экспериментировать, проще взять проверенные хорошие надежные наборы.

Это про лендинги.

Дальше только нарабатывать скилл - какой заголовок напишешь, какую палитру выберешь, какой шрифт подберешь, какую иллюстрацию купишь. И нет супер-хитростей, только скилл и практика. (EP: я занялся тем, что в тех сервисах/сайтах где мне нравится как сделано - лезу в код и смотрю как это сверстано и по какой логике)

Про интерфейсы для айтишника.
Паттерны, шаблоны поведения, взаимодействия

Если делаем UI - можно повесится в сложности и мелочах. Поэтому - просто берем и читаем https://material.io/design и применяем все паттерны на мобильных устройствах. Можно покрасить в белый цвет, изменить шрифты, закруглить кнопки и все поведение перенести в iOS.

Для веба (вот тут внимание)!! Fluid Design https://docs.microsoft.com/en-us/windows/uwp/design/basics/commanding-basics
Панели, формы, переходы, навигация, структура разделов.

Дальше тоже - игра и баланс со шрифтами, чтобы получить Apple Design Awwards))

Все эти мелочи - а как упорядочить навигацию. А сколько информации отобразить на одном экране. А какая иерархия инпутов, дропдаунов, описаний. А почему ширина текста не должна быть на весь экран большим полотном, а желательно 66 символов шириной (desktop). А какой визуальный вес, последовательность элементов, баланс - там все уже решено, можно просто использовать.
Панели, формы, переходы, навигация, структура разделов.
Дальше тоже - игра и баланс со шрифтами, чтобы получить Apple Design Awwards))
Все эти мелочи - а как упорядочить навигацию. А сколько информации отобразить на одном экране. А каккая иерархия инпутов, дропдаунов, описаний. А почему ширина текста не должна быть на весь экран большим полотном, а желательно 66 символов шириной (desktop). А какой визуальный вес, последовательность элементов, баланс - там все уже решено, можно просто использовать."

В придачу интересные блоги/статьи которые можно поглядывать:
https://www.smashingmagazine.com/
https://css-tricks.com/
https://uxdesign.cc/

Вот хотя работаем давно, но до кейсов у нас все время почему-то не доходили руки, но вот наконец-то пришло время.
Рассказали на Хабре как поддерживаем Тануки.
https://habr.com/ru/company/itsumma/blog/500634/
Лайк, шер, репост плз (С) :)

Пятница, деплоите? Интересную штуку услышал на докладе John Allspaw на монитораме в 2019-м году, нормальный такой reality check.
"Быстрый, в некотором роде, мысленный эксперимент.

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

Теперь я хочу, чтобы подняли руки те, кто всем сердцем уверен, что система будет продолжать работать через 24 часа?
Поднимите руки те, кто считает, что система будет работать через 3 дня? 5 дней? Неделю? (остается одна рука). Ого, я хочу с вами поговорить (смех в зале)".
Почему этот эксперимент полезен - он дает ощутить вам что вы что-то делаете. Вы - та причина по которой система еще работает. Вы постоянно, прямо сейчас, помогаете избежать инцидентов."

https://www.youtube.com/watch?v=VgsRXPoYmwM&feature=youtu.be&t=121

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

У нас неплохой опыт создания и поддержки сайтов СМИ: ТАСС, The Bell, "Новая газета", Republic… Не так давно мы пополнили портфолио, выпустив в прод сайт Reminder. И пока быстро допиливали новые фичи и чинили старые баги, медленный деплой стал большой проблемой.

И когда я разговаривал с нашими директором по разработке, Евгением Финкельштейном про проект - узнал о том как команда работала над тем, чтобы сократить время сборки от 14 минут до 30 секунд.

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

https://habr.com/ru/company/itsumma/blog/501680/

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

Мы запустили рекламную кампанию связанную с переходом магазинов в онлайн, подготовили для нее лендинг, вот за ней и следил.
Поскольку люди не пишут в гугле “ищу системных администраторов для поддержки 24/7 для моего магазина”, то мы используем контекстно-медийную сеть, баннеры которые вы сто раз видели на сайтах. Мы таргетируемся на аудиторию, по которой уже показываем баннеры. Идея хорошая – тот кому будет нужно увидит баннер, кликнет, мы заплатим за клик.

И вот тут началось интересное. Постепенно, день за днем после запуска стали появляться странные пользователи. Вебвизор показывал их как довольно активных. Они заходили на лендинг, скроллили вниз, доходили до формы заявки, писали там имя, после чего не отрправляя формы поднимались на верх страницы и на этом сессия заканчивалось. Постепенно, таких пользователей стало много. Николай, Алла, Сергей, Михаил.

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

Стал смотреть глубже. Оказалось (см. скрин), что есть ограниченное количество сайтов – с CTR выше среднего в десятки раз. Среди них и авито. Поверхностный гугл привел к одному и тому же комментарию во всех статьях. Если используете display network (КМС) – вашей ежедневной работой станет бан таких сайтов. Боты, которых приводят такие сайты – выглядят как живые люди, гугл и яндекс их за фрод далеко не всегда принимают, таким образовым вы за них будете платить. То есть, если вы закупаете рекламу и закупаете баннеры – спросите у своих закупщиков – занимаются ли они этим. В нашем случае деньги небольшие, но неприятно. Среди сайтов кстати есть и авито. С большим удивлением спросил об этом в фейсбуке, в комменатариях сказали что ничего удивительного, ходят слухи что правда скликивают баннеры. Так что авито тоже лучше банить.

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

Такие дела, живите теперь с этим, если не знали.

продолжая карантинно/удаленную тему, взяли исходники VLC, и доработали.

теперь, если вы хотите посмотреть ютюб с друзьями или у вас есть какие-то видеофайлы которые вы хотите посмотреть синхронно можете скачать ITSKino, открыть там линку на ютюб или видеофайл и передать ссылку друзьям - VLC-шки затаймсинкаются и вы будете смотреть кино одновременно.
приятного просмотра! 😃

https://itskino.ru/

Вдруг понял, что не поделился двумя докладами на этой неделе. С определенной точки зрения изоляция делает крутые штуки, можно сегодня выступить в Челябинске (записью поделюсь), а завтра выступить в Новосибирске и никуда при этом не летать!

https://team.cft.ru/events/171

19:00 -19:45 (время по Новосибирску, в Москве это 15:00) Евгений Потапов, CEO ITSumma

"Мониторинг микросервисных приложений, взгляд SRE"

Расскажу про несколько специфичных для микросервисов проблем мониторинга, ну и свое классическое "на какие грабли можно наступить и как не наступить на эти грабли" (записью тоже поделюсь)

Тем, кто занимается маркетингом (или просто тем, кому интересно за кем шпионят ретаргетинговым пикселем) - замечательный сайт посмотреть на то, какую рекламу на вас ретаргетят - https://whoisretargeting.me/

Там же ссылка где можно отписаться от большинства рекламодателей, делающих ретаргетинг.

Не думаю, правда, что баннерный мир у тех, кто не использует баннерорезалку от этого станет лучше - так хотя бы реклама того, что вас когда-то интересовало будет, а так просто рандом :)

Из доклада на митапе ЦФТ получилась статья на хабр - https://habr.com/ru/company/itsumma/blog/505976/

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

Поддержка и обеспечение стабильности становятся объективно сложнее, появляются новые точки отказа и новые риски, но с этим придется жить.

В статье я рассматриваю несколько типичных именно для микросервисных архитектур ошибок в мониторинге и о том как их можно избежать.

В Лондоне (в "Лондоне", на самом деле онлайн) идет DevOps Enterprise Summit 2020.

Как говорят организаторы - конференция не для единорогов (типа Uber-а) а для рабочих лошадок (сейчас идет доклад про развития девопса в екоммерсе Adidas-а).

Надеюсь послушать все три дня докладов, конспект веду здесь:
https://www.notion.so/eapotapov/DevOps-Enterprise-Summit-London-2020-e182a157d3aa49849795cdbe4c34b840