BeerPanda. Органично недоразвитый DevOps

Какая связь между World of Tanks и переменными окружения?

А точнее, знаете ли вы на самом деле зависимости и ограничения своего или чужого софта, который применяете у себя?

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

Оказывается, что в новой модной игрушке где-то глубоко зашита древняя (в смысле заслуженная) утилита curl, которая видит ваши переменные окружения, и в частности http_proxy, и если таковая есть - лезет в интернет через этот прокси. Вне зависимости от того, есть в настройках самой игры подключение через прокси или прямое. В итоге если у вас на десктопе по какой то причине есть специфическая конфигурация сети, чтобы разный софт в интернет ходил по-разному, то нет, не получится поиграть. Танки не запустятся, если этот curl не сможет проломиться через этот http_proxy.
Разработчики Танков решили не заморачиваться нативными способами доставки контента в единой сетевой модели - они просто обернули curl.
Потому что ну вы знаете - так в примерах показано, чего там уж париться?

И это простой пример. А сколько у вас таких примеров и копи-пасты кода пораспихано по проду? Знаете ли вы все зависимости и требования своего софта?
Сколько кода у вас вообще подсасывается из гитхаба при сборке, а не хранится в локальных репозиториях?

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

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

Теоретики от ИБ решили посмотреть в глаза действительности. Но, как обычно, получилось не очень.

https://3dnews.ru/1112035/eksperti-utvergdayut-chto-slognie-paroli-snigayut-bezopasnost

PGBench для самых маленьких. Часть 1.

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

Самый простой способ, конечно - использовать встроенную утилиту pgbench. Но если ты сам не спец по СУБД и постгресу, то... тратить полгода на изучение, забросив все остальное?

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

А что делать, если тесты надо запускать много и в вариантах, да еще на пачке серверов, да еще разных архитектур?

Есть интересный пакет Phoronix Test Suite, и в рамках него есть встроенный pgbench тест, который буквально по одной команде сразу прогонит вам 80 вариантов (полторы недели на цикл).

$ phoronix-test-suite benchmark pts/pgbench

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

И вот мы делаем ррраз! И прогналось 80 тестов.

А есть там один нюанс - как и в большинстве бесплатных проектов, да в которые должны вкладываться десятки разных случайных людей, не обошлось без еще некоторых проблем.
А именно - в инсталляционном скрипте есть ошибка, из-за которой все тесты идут с буфером 8ГБ, хотя рекомендуемый буфер 1/4 от общего объема RAM.

Соответственно, необходимо зайти в (если тест ставился не от рута)
~/.phoronix-test-suite/installed-tests/pts/pgbench-1.14.0
или (от рута)
/var/lib/phoronix-test-suite/installed-tests/pts/pgbench-1.14.0

И исправить там скрипт запуска теста pgbench (имя файла). Выставляем размер в 1/4 от RAM (в мегабайтах).

SHARED_BUFFER_SIZE=131072

Вот теперь ваши результаты будут похожи на правду.

Продолжение следует.

Открылся дружественный чат смежной тематики - Что вы не знали о сексе российской виртуализации или боялись спросить.

Обсуждаем все что связано с zVirt, RuStack, Росплатформой, Скалой-Р и всем остальным.

https://t.me/rusvirtug

Почему для датацентров делают специальные кондиционеры и при чем тут физика 8го класса?

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

Напряжение для пробития искрой в нос необходимо порядка 10-12 тыс В (киловольт). При работе с электроникой положено надевать антистатический браслет (по сути провод от тела до корпуса) для выравнивания потенциалов. Потому что в нос будет просто больно, а микроэлектронику такой разряд просто убивает.

Напряжение статического пробоя тем выше, чем меньше влажность.
При этом имеет также значение и расстояние. "Электрическая прочность" измеряется в кВ/см. Для "влажного" воздуха 1 кВ/см (100 В/мм), а для сухого 20 кВ/см (2 кВ/мм).
Надо при этом и не забывать, что напряжение в случае статического пробоя совсем не то же самое, что напряжение между проводами, подключенными к источнику питания. Это самое напряжение является одновременно и показателем "объема" электричества. Т.е. если мы доведем объем (в Кулонах) до такого, что возникнет пробой на значительном расстоянии - то именно эти Кулоны и подвинутся. В случае с источником питания же ток продолжится.
Соответственно одна из главных задач - снизить токи / объемы.

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

Но при чем тут кондиционеры?

А тут все просто. Датацентровые кондиционеры помимо собственно охлаждения должны еще держать определенный уровень влажности, для чего у них есть подача воды и кипятильники. Убрать влажность у них получается просто по принципу работы - идет конденсация на холодной решетке.

Как работает многозадачность

Исполнение программ

На первом занятии на спецкурсе по программированию Владимир Денисович Лелюх (земля ему пухом) говорил студентам: компьютер, несмотря на свое название, считать не умеет, он умеет делать вид, что умеет считать. Но если нечто выглядит как утка, ходит как утка и крякает как утка, с практической точки зрения это утка.

Попробуем это запомнить для дальнейшего практического использования.

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

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

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

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

Многозадачность

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

Появляется псевдо-многозадачность — когда задача выполняется при непосредственном на нее переключении.

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

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

"Общая теория и археология виртуализации x86"

Что то прям ностальгия взяла - прикупил вот.

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

Рекомендуется к просмотру всем, кто слышал название "виртуальная машина".

https://www.youtube.com/watch?v=gZVk6-Jdy3Y

В очередной раз про облака

В 2011 году я начал говорить о том, как правильно входить в облака.

"Входить в облако надо с готовой стратегией выхода из него".

До санкций было еще 11 лет и я говорил в основном о том, что у вас как пользователей может поменяться мнение о качестве услуг, об их стоимости. Было еще несколько лет до CloudMouse, и даже Селектел еще не отжигал.

Идет 2024 год. Slack добивает пользователей по признаку "получите, русские сволочи". В 2022 были убиты корпоративные аккаунты, причем некоторые серьезные компании пострадали (не будем их называть).

Недостатки - логическое продолжение достоинств. Удобство облака и возможность моментально развернуть ресурсы = возможность моментально их удалить. Ваш обиженный инженер может это сделать в отместку за невыплаченную премию. Но так же это может сделать и сотрудник провайдера, например, демонстрируя свою личную политическую или иную позицию.
Компания-провайдер может схлопнуться, а может просто взять и заблокировать вам аккаунт (Amazon vs Parler). Дальше делайте что хотите.

Мы сейчас смеемся над дурачками, которые за полкопейки в 20 лет жгут релейные шкафы РЖД, а потом получают 20 лет тюремного срока. Так кто вам сказал, что очередной такой дурачок не окажется сотрудником облака с возможностью разворотить вам все?

Повтори, а потом еще три раз повтори.

Как правильно входить в облако.

1. Облако - это не высшие технологии, а способ сэкономить. В том числе экономит провайдер. У вас должны быть резервные копии всего. Причем в обязательном порядке резервные копии на оборудовании, которое находится на вашей контролируемой территории (On premise). Оборудование должно быть полностью контролируемо вами, софт резервного копирования должен полностью контролироваться вами. Чтобы исключить возможность блокирования вам доступа или автоматического удаления резервной копии по команде "оттуда".

У вас должны быть в том числе оффлайновые бэкапы на "отчуждаемых носителях". CD, DVD, HDD, лента - да что угодно. То, что не требует питания и может быть закрыто в сейф на ключ.

2. У вас должен быть готов полный план по переключению на другое облако, запускаемый по нажатию кнопки. После чего все ваши данные, машины, контейнеры и тд переезжают / заливаются в новое облако из резервной копии.

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

4. Совсем в идеале у вас должен быть план по переезду из облака на on-premise. Т.е. на собственное железо, пусть хоть и не в собственную серверную, но хотя бы коммерческий ЦОД на colocation в вашей юрисдикции и где ваши инженеры могут физически дойти ногами и что то сделать с оборудованием. Если вам недоступно оборудование / ваши инженеры не имеют возможности оборудование физически потрогать в любой момент, а обслуживает его исключительно команда ЦОДа - это ничем не отличается от облака.

5. Если вы крупный клиент - ЦОД / облако должна одобрить ваша СБ, а им провайдер должен продемонстрировать как, кто и зачем имеет доступ, как контролируется этот доступ.

Запоминаем:
- если кто-то посторонний имеет доступ к вашей инфраструктуре - это не ваша инфраструктура
- если кто-то посторонний имеет доступ к вашему серверу - это не ваш сервер
- если кто-то может по одному клику мышкой закрыть вам доступ к вашим данным - это не ваши данные

Разница между архитектором и инженером-исполнителем. Серия очередная.

Сегодня откопали вопрос из моего списка вопросов для собеседования архитекторов-инфраструктурщиков.

"Вам нужно передать 100 ТБ данных из филиала во Владивостоке в Москву. Канал 100 мегабит, в течение рабочего дня его можно использовать только на 30 мегабит. В среднем раз в час происходит сбой и приходится передавать заново от 5 до 10% переданных за последний час данных. Сколько времени займет передача данных?"

Тут же посыпались вопросы:
- А сколько?
- А можно?
- А какие требования?
- А если я вот так?
- Недостаточно данных.

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

Один работник зашел к барину и говорит:
— Барин! Почему ты мне платишь всего пять копеек, а Ивану всегда пять рублей?
Барин смотрит в окно и говорит:
— Вижу я, кто-то едет. Вроде бы сено мимо нас везут. Выйди-ка, посмотри.
Вышел работник. Зашел снова и говорит:
— Правда, барин. Вроде сено.
— А не знаешь откуда? Может, с Семеновских лугов?
— Не знаю.
— Сходи и узнай.
Пошел работник. Снова входит.
— Барин! Точно, с Семеновских.
— А не знаешь, сено первого или второго укоса?
— Не знаю.
— Так сходи, узнай!
Вышел работник. Возвращается снова.
— Барин! Первого укоса!
— А не знаешь, по чем?
— Не знаю.
— Так сходи, узнай.
Сходил. Вернулся и говорит:
— Барин! По пять рублей.
— А дешевле не отдают?
— Не знаю.
В этот момент входит Иван и говорит:
— Барин! Мимо везли сено с Семеновских лугов первого укоса. Просили по 5 рублей. Сторговались по 3 рубля за воз. Я их загнал во двор, и они там разгружают.

Архитектор - это человек, который не является математической функцией от вводных данных, а способен к самостоятельному анализу ситуации и прогнозированию данных или ответов на основе индустриальных практик, личной экспертизы или через связи и знакомых, что подскажут.
Т.е. архитектор напишет математическую функцию, так же как и инженер, но при нехватке данных не остановится в выполнении задачи, а решит задачу в общем, подставив "какие то данные". В случае собеседования на архитектора ключевой вопрос заключается не в том, может ли кандидат написать линейное уравнение с дробями (уровень 5го класса), а понимает ли как это вообще считается и от чего зависит. Необходимо продемонстрировать правильный ход рассуждений и логику, а не дать единственный математически правильный ответ.
Банально потому что математически правильного ответа может не быть вообще (и значит надо менять требования), может быть субоптимальный ответ, может быть множество субоптимальных ответов. Может быть даже множество математически правильных ответов. Важно уметь понимать как они получаются и как между ними можно выбирать и на основании чего.

А ответ "три недели" покажет лишь, что вы умеете в математику 5го класса.

Происхождение термина Debug

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

Именно с огромными размерами связано и англоязычное название отладки программного кода — “debugging”. Одна из первых в истории программистов, Грейс Хоппер (да-да, женщина), офицер военно-морских сил, сделала в 1945 году запись в журнале действий после расследования неполадки с программой.

Поскольку moth (мотылек) в общем случае это bug (насекомое), все дальнейшие проблемы и действия по решению персонал докладывал начальству как “debugging” (буквально обезжучивание), то за сбоем программы и ошибкой в коде намертво закрепилось название баг, а отладка стала дебагом.