Записки IT специалиста

Вытяжка наклонная F 603 B KUPPERSBERG Надежная вытяжка от KUPPERSBERG — официальный сайт производителя. Узнать больше #реклама kuppersberg.ru О рекламодателе

ZRAM и ZSWAP в Proxmox VE В прошлой заметке мы подробно разобрали как работают ZRAM и ZSWAP, в чем их основное отличие и рекомендуемые сценарии использования. Но это касалось систем общего назначения, а когда мы переходим к специализированным системам, то расклад может измениться. Поэтому мы отдельно остановимся на популярном средстве виртуализации Proxmox VE. Казалось бы, а что там думать, серверная виртуализация, ZSWAP и всех делов. Но не все так просто. ZSWAP – функция ядра и для многих расположенных выше слоев системы она работает прозрачно. Приложение думает, что оно пишет в дисковый swap, а на самом деле оно пишет в кеш, расположенный в сжатой памяти. И если с виртуалками проблем не возникает, то LXC-контейнеры начинают вести себя своеобразно. Напомним, что у контейнеров нет ни своей памяти, ни своей подкачки, они используют ресурсы хоста в пределах установленных для них лимитов. Но для LXC использование SWAP-кеша не учитывается ни в одном лимите, в результате контейнер свободно выходит за пределы установленного лимита на подкачку. На первый взгляд – ничего страшного, кеш в памяти, он быстрее любого, даже самого быстрого диска, пусть работает. А теперь вспомним, что ZSWAP – это именно кеш, он может быть очищен ядром, он может начать вытеснять холодные данные на диск. Если коротко – это не гарантированное хранилище, а динамически выделяемый ресурс. В итоге может оказаться так, что кеш придется сбросить, а места в дисковой подкачке у вас недостаточно, что вполне реально, если несколько контейнеров выйдут за лимиты. И тогда – привет OOM-Killer. Либо, если вы выставили критичным службам защиту от указанного товарища, а именно они и сожрали память, то ваш сервер просто станет колом и потребуется принудительная перезагрузка. Поэтому Proxmox не рекомендует использовать ZSWAP, а предлагает, неожиданно, ZRAM. Но как так, спросит внимательный читатель, ведь только что вы писали, что ZRAM плохо влияет на производительность, особенно для виртуализации и СУБД. Все верно, но это в том случае, если мы используем его в качестве расширителя объема ОЗУ. Но если у нас достаточно памяти, то мы можем создать ZRAM устройство исключительно на замену swap. При этом, в Proxmox это отдельно подчеркивают, использование подкачки является временной мерой для защиты от OOM-Killer и использовать ее в качестве расширения памяти категорически не рекомендуется. Т.е. здесь мы приходим к тому, что памяти у нас для виртуальных машин и контейнеров достаточно, а подкачка нужна для сглаживания пиков, но не для повседневной работы. В этом случае перенос подкачки в ZRAM вполне оправдан, а так как это отдельное блочное устройство и настоящее пространство подкачки, то лимиты LXC здесь работают, как и задумано, считая несжатые данные. Ну и совершенно понятно, что выделять в таком случае под ZRAM не следует ни 25%, ни, тем более 50% ОЗУ. Исходим из того, сколько реально подкачки нам надо и делим на коэффициент сжатия. Для LZ4 это 2,5, для ZSTD около 4. Таким образом, если у нас есть хост с 64 ГБ ОЗУ, то отрезав всего 4 ГБ при помощи ZRAM и zstd мы спокойно организовываем пространство подкачки на 16 ГБ. Причем – быстрой подкачки. При этом Proxmox настоятельно советует дисковую подкачку отключить, так как совместное использование ZRAM и дисковой подкачки может вызвать неконтролируемый рост задержек и привести к катастрофической дестабилизации системы. В данном случае ZRAM предлагается использовать не как расширение памяти при ее недостатке, а как альтернативу дисковому swap, но в более предсказуемом виде, нежели ZSWAP-кеш. Это еще раз показывает, что любая технология может приносить пользу, если ее применяют правильно, или стать источником проблем при бездумном использовании.

Ремень EKONIKA Одна сторона ремня выполнена из натурального велюра в темно-коричневом цвете,... Узнать больше #реклама ekonika.ru О рекламодателе

Сакральная желтая бумажка С завидным постоянством наблюдем необъяснимое, можно даже сказать – сакральное отношение некоторых пользователей к пин-кодам программных лицензий 1С:Предприятие. Когда любой предложение что-то там сделать разбивается о «да вы что, это же новый пин-код придется использовать». На встречный вопрос «а что в этом такого, они для этого и нужны» приходится выслушивать истории одна другой удивительнее. Но все они сходятся к тому, что как закончатся пин-коды на бумажке, так сразу будет беда, все обязательно станет, лицензии слетят, а для их получения придется пройти сложный квест и прорваться сквозь злую поддержку. Причина таких страшных сказок кроется не в системе программного лицензирования 1С:Предприятие, а в отсутствии культуры работы с ней. Начнем с того, что любой лист программной лицензии содержит некоторое количество активных кодов и резервных к ним. Резервный коды нужны как раз для переактивации системы и сама поддержка 1С русским языком пишет:

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

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

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

Правила несложные, но мы очень редко видели, что кто-то им следует. Зато многократно сталкивались с тем, что администратор в принципе не имел понятия какой именно рег.номер лицензии на этом компьютере, какой пин-код активирован и с какими данными пользователя. А в этом случае никакое наличие бумажек с кодами вам не поможет. Поэтому никакой сакральности в этих желтых бумажках нет. Нужно использовать код – используйте. И тут же запрашивайте новый. Задача полностью будничная, указали рег.номер – получили новый код. И никому не интересно зачем он вам и для чего. Ну и не ждите слета лицензии, если по правилам она должна слететь. Просто переактивируйте не дожидаясь слета, а то, что она слетит – это 100%. И никакие соображения о мнимой «экономии» лицензий тут неприемлемы. Экономить тут нечего и незачем, разве что заведомо спровоцировать остановку сервиса в самый неподходящий момент. Оно вам надо?

Любые фрезы под любые задачи Ищете качественные фрезы и оснастку для ручных и ЧПУ фрезеров? Наша компания предлагает широкий ассортимент: фрезы, сверла и оснастка для обработки ЛДСП, МДФ, ДСП, фанеры, металла и пластика. Высокая точность и долговечность наших инструментов обеспечат отличные результаты в работе. Закажите фрезы и оснастку Многофрез прямо сейчас! Наш tg-канал t.me/cnctechnologi Выбрать #реклама mnogofrez.ru О рекламодателе

В чем сходство и в чем различие ZRAM и ZSWAP Каждый раз при упоминании этих технологий возникает ряд стандартных вопросов по их сходству и различию, а также совместному применению, поэтому давайте отдельно разберемся в этом вопросе. 1️⃣ Начнем с ZRAM. Эта технология создает в оперативной памяти блочное устройство и использует его в качестве пространства подкачки. Выделенная оперативная память сразу резервируется и не может быть использована системой. Цель ZRAM – за счет сжатия предоставить системе большее количество доступной оперативной памяти, чем есть на самом деле. Это достигается за счет сжатия. Средний коэффициент сжатия для LZ4 – 2,5, это значит, что, выделив для ZRAM 1 ГБ оперативной памяти мы получаем в свое распоряжение 2,5 ГБ очень быстрого swap, что позволяет достаточно эффективно решить вопрос нехватки ОЗУ. Например, для машины с 4 ГБ ОЗУ, что по нынешним временам критический минимум, мы можем, разделив память пополам получить эквивалент 6-8 ГБ ОЗУ что радикально поменяет в лучшую сторону пользовательский опыт работы с системой. Но за все нужно платить, за ZRAM мы платим процессорными ресурсами и ухудшением параметров доступа к сжатой памяти. Если сравнивать латентность доступа, то мы получим следующие цифры: ▫️Обычная RAM ~80–120 нс ▫️ZRAM (LZ4) ~1–5 мкс ▫️NVMe swap ~50–150 мкс ▫️SATA SSD swap ~200–500 мкс ▫️HDD swap миллисекунды Как видим, ZRAM дает существенный рост латентности (в 10-50 раз), но все еще остается самым быстрым пространством подкачки, потому что даже при использовании быстрого NVMe разница будет уже на порядок. Ну и ситуация, когда где-то что-то немного подтормаживает гораздо лучше ситуации, когда все стало колом из-за нехватки памяти. Но если средняя латентность растет относительно незначительно, то вот рост tail latency (Tail latency (p95 / p99)) оказывается гораздо более высоким, что может приводить к заметным фризам и каскадному росту задержек. Поэтому не следует использовать ZRAM в системах критичных к p95 / p99 – это большинство серверных применений, виртуализация и особенно СУБД, а также любые задачи критичные к задержкам, игры. 2️⃣ Теперь перейдем к ZSWAP, это Write Back кеш для пространств подкачки, общего с ZRAM у него только то, что он тоже использует сжатую память. В остальном это совершенно другая технология. Так как это кеш, то выделенная память не резервируется сразу, а используется по мере необходимости, также кеш всегда может быть сброшен ядром. Задача ZSWAP кеша – уменьшить количество обращений к пространствам подкачки на дисках, а выгода здесь также получается от сжатия данных. Например, в системе с 16 ГБ памяти для ZSWAP по умолчанию резервируется 20% или 3,2 ГБ, что эквивалентно (для LZ4) примерно 8 ГБ несжатой памяти. Т.е. получаем неплохой такой раздел подкачки прямо в ОЗУ. Что касается латентности, то она ничем не отличается от ZRAM, но в случае ZSWAP это только плюс, так как латентность сжатой памяти в 50-100 раз ниже, чем латентность быстрых NVME и на порядок лучше обычных дисков. Это позволяет эффективно сглаживать пиковые нагрузки и уменьшает рост p95 / p99, что позитивно сказывается на чувствительных к задержкам рабочих процессах. 👉 Вот здесь внимательный читатель может удивиться, как так, одна и таже технология дает прямо противоположные результаты. Но ничего странного в этом нет. Потому что в случае с ZRAM мы используем сжатую память вместо обычной, что ухудшает ее параметры. А ZSWAP использует сжатую память вместо дискового swap, который в любом случае гораздо более медленный. ‼️ Что касается совместного применения ZRAM и ZSWAP, то это не только лишено всякого смысла, но и серьезно ухудшает латентность, а также увеличивает нагрузку на CPU за счет двойного сжатия, потому что в этом случае у нас получится цепочка: RAM – ZSWAP – ZRAM – SWAP Поэтому так делать не нужно. А рекомендации просты: 🔹Мало памяти, нет особых требований к латентности – ZRAM 🔹Достаточно памяти, но требуется сгладить пики и улучшить производительность - ZSWAP

Авторское право – не пустой звук Сегодня с одним нашим коллегой и молодым автором произошел крайне неприятный случай. Он имел неосторожность использовать для КДПВ (картинки для привлечения внимания) стоковое изображение не озаботившись уточнить авторские права и лицензию. И это никого до сего дня не волновало, пока он не получил претензию от одной юридической фирмы, которая утверждала, что он нарушил авторские права и теперь круто всем должен, но они готовы решить вопрос за «смешные» 55 тыс. руб. Он обратился за советом в сообщество авторов, но ответы получил самые разные. Кто-то советовал просто забить, кто-то удалить и сделать вид, что ничего не было, а кто-то - просто тянуть время. Отдельные, радикально настроенные товарищи, вообще советовали пойти в отрицалово, мол пусть еще попробуют доказать. Мол скачал из открытых источников, знать не знал, ведать не ведал. Но, хорошо давать советы сидя в теплом кресле, а по факту надо что-то решать. И тут надо отталкиваться от самой претензии. Понятно, что с житейской точки зрения истец тут эксплуатирует нормы права в свою пользу и деятельность эта морально близка к вымогательству. Но то морально, а у нас юридически. А юридически претензия говорит, что мы зафиксировали нарушение авторского права на вашем сайте при помощи сервиса автоматической фиксации доказательств «ФИКСАТОР». Т.е. факт нарушения есть и зафиксирован. Пойти в отрицалово здесь не получится. Идем далее. Обычно тут спрашивают, а автор или сток вообще в курсе? С какого перепуга какое-то ООО Рога и Копыта предъявляет претензии? А по договору цессии (уступки требования). Это распространенная практика, когда автора за фиксированную сумму или процент передает право требования компенсации третьим лицам. А дальше вы даже можете найти автора и поговорить с ним, а он скажет, что первый раз вас слышит и никаких претензий к вам не имеет. Но что толку, если право требования от передал третьему лицу? Он и не имеет права с вас что-то требовать. Зачем ему это надо? Он делегировал это право или за фиксированную оплату, или за процент, у него все хорошо. Право продавать это фото на стоках и получать прибыль он не утратил. А что у нас там еще осталось? Пусть докажут? Так презумпция невиновности есть только в уголовном праве. В гражданском праве есть принцип состязательности. Если коротко, то если вы заявили какое-то обстоятельство, то именно вы должны его доказать и никак иначе. Возвращаясь к нашему делу – тут есть фиксация правонарушения через «ФИКСАТОР», т.е. истцу ничего доказывать не нужно. Наоборот, нужно доказать отсутствие факта правонарушения ответчиком. Ну и реальные перспективы: Ответчик морозится, булькнул в тину. Дело уходит в суд, суд удовлетворяет требования, плюс вешает на ответчика пошлину и юридические издержки истца: 55 + 10 + 20 = 85 тыс. руб. Ответчик приходит в суд и апеллирует на то, что правонарушение совершено им впервые, он сразу его устранил, не был, не участвовал, не привлекался. Итог: требования истца удовлетворены частично: 10 + 10 +20 (компенсация + пошлина + юридические услуги). Т.е. при самом лучшем раскладе мы получаем 40 тыс. руб. убытков. Плюс публичные записи о судебных делах и исполнительных производствах. Потому что истец сразу после решения суда в его пользу возьмет исполнительный лист и отдаст его приставам. А что тут делать? Ну в общем и целом не размещать у себя картинки, защищенные авторским правом. А если попали, то торговаться. Мол есть 15 тыс. руб. сейчас, а иначе попробуйте что-то с меня через приставов взять, активы я на жену вывел. Там тоже понимают, что лучше живые деньги сейчас, чем исполнительный лист когда-то потом. Поэтому если договорились на 20-25 тыс. – то это нормально. А правило простое – не нарушайте. Далее мы разберем все риски технического блогера и дадим советы. Но пока – всегда думайте, что у каждого изображения есть автор и он далеко не пацифист, а скорее давно продал право требования.

Преобразователь Murata MYSGK02506BRSR, DC/DC Converters SMD 5 TO 25VDC,6A. Миниатюрный монолитно-блочный неизолированный преобразователь Узнать больше #реклама chipdip.ru О рекламодателе

Selectel обновил пользовательское соглашение. А что там? Правильно:

6.4. Исполнитель не несет ответственности за убытки Заказчика, возникшие в связи с нарушением Соглашения Исполнителем вследствие: воздействия любых видов вооружения и средств поражения (включая, в частности, летательные аппараты и ракетное вооружение), в том числе применяемых с оборонительными целями, актов терроризма или диверсии, если такое воздействие затрагивает деятельность Исполнителя и (или) контрагентов Исполнителя (включая, в частности, энергосети, каналы связи и иную инфраструктуру); либо принятия органами государственной власти или местного самоуправления нормативных актов или решений, которые ограничивают или приостанавливают деятельность Исполнителя.

В общем, спасение утопающих - дело рук самих утопающих.

Раскройный нож Micron CER-45 d 45 мм Раскройный нож используется для быстрого и точного раскроя, подходит для правшей и... Узнать больше #реклама vseinstrumenti.ru О рекламодателе

И еще немного про алиасы в PowerShell PowerShell предлагает большой набор встроенных алиасов, про них мы подробно писали в нашей прошлой заметке. И предназначены они сугубо для интерактивного использования внутри командной оболочки, т.е. для сокращения руками вводимых команд и упрощения их запоминания, ключи, между прочим, тоже успешно можно пропускать, если располагать опции в надлежащем порядке. Это как раз решает проблему многословности PowerShell при интерактивном использовании. Можно ли создавать и применять в проде свои алиасы? Можно и даже нужно, если использовать их по назначению, а именно для интерактивной работы в консоли. Созданные алиасы без проблем можно выгружать и загружать на другой машине, для этого следует использовать команды Export-Alias и Import-Alias. Поэтому у грамотного администратора не будет проблемы с созданными алиасами на новой системе, равно как и не будет их у человека, про данные алиасы не знающего. А вот чего не стоит делать с алиасами не при каких обстоятельствах – это тащить их в скрипты. Скрипты давно никто на коленке в чистом блокноте не пишет, а любая среда разработки как минимум содержит подсказки и автодополнения, что позволяет быстро и удобно писать код с использованием полного синтаксиса. Также в скриптах следует обязательно указывать все ключи, даже если их можно пропустить. Это не повлияет на работу, но положительно скажется на читабельности кода вашими коллегами или вами через некоторое время. И, следует отметить, что многие упреки в неудобности и многословности PowerShell проистекают именно от незнания и попытки напрямую перенести на него предыдущий пользовательский опыт, не изучая возможности языка. А возможность использовать короткую и немногословную нотацию у него есть, для чего нужно просто ознакомиться со списком встроенных алиасов.

Детское кресло Аскона Teddy (Тедди), цвет розовый Аскона - товары для здорового сна вашего ребенка. Узнать больше #реклама askona.ru О рекламодателе

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

apt install libpam-pwquality

После чего откроем файл /etc/security/pwquality.conf, который отвечает за политику паролей. Опции будут перечислены в порядке их перечисления в файле со значениями по умолчанию: Количество символов, на которые новый пароль должен отличаться от старого.

difok = 1 

Минимальная длина пароля

minlen = 8 

При составлении пароля учитываются классы символов, их четыре: прописные буквы, строчные буквы, цифры и специальные символы. Мы можем поощрить использование определенных классов символов за счет более короткой длины пароля, для этого используется система кредитов. По умолчанию один любой символ – один кредит. Количество кредитов должно быть равно или превышать минимальную длину пароля. Следующие опции позволяют начислять дополнительные кредиты за каждый класс символов:

dcredit = 0 – цифры
ucredit  = 0 – прописные буквы
lcredit = 0 – строчные буквы
ocredit = 0 – специальные символы

Таким образом, если мы установим dcredit = 1, то пароль pass123 получит 10 кредитов, что будет эквивалентно его длине в 10 символов. Если же мы установим количество кредитов меньше нуля, то это будет требованием минимального количества символов данного класса, например, ocredit = -2 – не менее двух специальных символов в пароле. Для того, чтобы сочетать в пароле разные классы символов мы можем задать необходимое количество классов:

minclass = 0

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

maxrepeat = 0

Рядом есть другая опция, которая задает максимальное количество повторения символов одного класса:

maxclassrepeat = 0

Чтобы понять разницу между ними разберем простой пример, допустим, что оба параметра имеют значение, установленное в три. В первом случае пароль АААА не пройдет, а пароль ABCD пройдет, так как символы разные. Во втором не пройдут оба, так как и там и там символы одного класса. Учетная запись пользователя в Linux имеет специальное поле GECOS, которое может содержать его реальное имя, телефон, адрес почты и т.д. Мы можем проверить пароль на наличие в нем общедоступной информации:

gecoscheck = 0

При установке значения в единицу при нахождении в пароле данных GECOS он не будет пропущен. Также мы можем осуществлять проверку по словарям cracklib (ставятся по зависимостям):

dictcheck = 1

Следующая проверка исключает использование имени пользователя в пароле:

usercheck = 1

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

usersubstr = 0

Если установить его равным трем, то сочетание ivanov:ivan123 будет запрещено, равно как vano456, а iva123 будет пропущен. Следующая опция устанавливает количество попыток ввода пароля:

retry = 3

Но есть одна тонкость, все эти правила не распространяются на пользователя root, чтобы изменить это поведение просто раскомментируйте опцию:

enforce_for_root

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

Секционные ворота DOORHAN с монтажом за 1 день! Надежные и долговечные. Сохраняют тепло в гараже. Рассчитайте стоимость! Узнать больше #реклама mrqz.me О рекламодателе

Mageia 10 - такое волшебство нам не нужно! В мире Linux есть различные дистрибутивы, большая часть из них собирается энтузиастами для энтузиастов, но есть и знаковые системы, оказавшие значительное влияние на эволюцию этой операционной системы. Один из них - это Mandrake, позже Mandriva, первый реализовавший работающую концепцию "Linux с человеческим лицом". Но все проходит и современный Linux с его стандартизацией и унификацией, давно уже не тот и старые подходы в нем больше не работают. Немного истории: Mandrake Linux появился в 1998 году (версия 5.1) и стал во многом революционным, если не сказать культовым, так как одним из первых предложил пользователям простые графические утилиты для управления системой и доказал, что Linux может быть простым и дружелюбным к простому человеку. Разработкой занималась французская фирма, которая пыталась найти пути извлечения коммерческой прибыли из дистрибутива. Затем произошло объединение с бразильской Conectiva и дистрибутив был переименован в Mandriva. В 2010 году из-за финансовых трудностей компания сократила подразделение разработчиков Mandriva, которые приняли решение о создании собственного форка системы - Mageia (от греческого - магия), в дальнейшем остальные права на Mandriva, после банкротства компании, перешли к российской РОСА. Таким образом история системы насчитывает уже более 15 лет как самостоятельной ОС и приближается к своему тридцатилетию если брать семейство в целом. За это время индустрия и Linux сделали хороший рывок, но не все сумели остаться на волне технологического прогресса. Но обо всем по порядку. ✅ Читать далее: https://interface31.ru/post/mageia-10-takoe-volshebstvo-nam-ne-nuzhno/

Аренда и размещение серверов в дата-центрах Москвы ITSOFT оказывает услуги коммерческого дата-центра в Москве. 👌Аренда физических выделенных серверов (Dedicated Servers) в готовых конфигурациях и в рамках индивидуальных сборок. 👌Colocation и аренда серверных стоек. 👌Предоставление инфраструктурных ИТ-решений для физических лиц и корпоративных клиентов. 👌Предоставление высокоскоростных каналов передачи данных. Узнать цену #реклама 16+ itsoft.ru О рекламодателе

Зачем они варят пингвина в котле? А вообще от Mageia 10 впечатления удручающие, налицо не только стагнация, но и деградация. Разработчики явно не понимают, что окружающий мир изменился и современный пользователь предъявляет совершенно иные требования, чем пользователь десять лет назад. Ну и предлагать любая система должна не пакеты, репозитории и номера релизов, а некоторые ценности, которые тут размыты и фактически утеряны. Хотя это современная участь многих дистрибутивов в современных условиях стандартизации и унификации Linux. Скоро будет обзор.

ИИ уже в бизнесе. И что дальше? 19 ноября в Москве на RLT.Conf «В IT с головой × ИИ × бизнес» обсудят практическое применение ИИ в разработке и других ИТ-задачах. В программе конференции: 🔹 реальные кейсы применения ИИ — от вайбкодинга до автоматизации сложных процессов; 🔹 новые цифровые продукты и перспективные технологические решения; 🔹 взгляд на человека внутри этих изменений — мышление, стресс и поведение в нетипичных ситуациях. Среди спикеров — эксперты, которые задают новые подходы к работе с ИИ в своих сферах. А среди гостей — предприниматели, ИТ-специалисты, продакты и стартап-команды: будет с кем обменяться опытом и завести полезные знакомства. Ради этого точно стоит выбраться из рабочего чата в офлайн. Для участия необходимо зарегистрироваться на сайте.

Про «реальную производительность» и APDEX В комментариях нас уже несколько раз спросили, как мы оцениваем «реальную производительность» наших систем. Вопрос хороший, непростой вопрос. Мы специально взяли фразу «реальная производительность» в кавычки, потому что за ней кроется нечто непонятное, которое каждый понимает по-своему. Вот прямо сейчас попробуйте отвлечься от прочтения заметки и попытайтесь сформулировать определение этому термину. Скорее всего это будет синтетическая оценка в попугаях какого-либо популярного теста. Но если вас тут же спросят – а насколько хорошо будет работать на такой конфигурации некоторое бизнес-приложение вы вряд ли сможете дать точный ответ. А теперь сделаем некоторое лирическое отступление. IT-отдел подразделение сугубо затратное, прибыли оно не приносит. Его задача обеспечивать бизнес-процессы. Прибыль при этом генерируют совсем другие подразделения. Задача бизнеса – зарабатывать деньги. Бизнесу все равно насколько оно там технически правильно или какая «реальная производительность» в попугаях. Ему это не интересно, ему нужно чтобы работали производящие прибыль подразделения и поэтому мнение пользователей этих подразделений всегда будет иметь больший вес, чем мнение обслуживающих их айтишников. Если пользователи такого подразделения говорят, что система работает плохо, то вы можете до посинения показывать результаты бенчмарков и уверять, что с вашей стороны все хорошо, вон целых 100 попугаев по Гилеву, должно все летать… Ответ будет прост – не летает, пользователи недовольны. А в соседней конторе может стоять точно такой же сервер, с точной такой же конфигурацией 1С и там все довольны. Это как так? Почему? Потому что нельзя оценивать производительность только по техническим характеристиками и синтетическим бенчмаркам. К счастью, все уже придумано до нас – открытый международный стандарт оценки производительности корпоративных приложений – APDEX. Основным фактором влияния для APDEX является целевое время выполнения операции, если операция укладывается в период T – все довольны, если выходит за пределы 4T – полностью разочарованы. Собранные результаты обрабатываются и нормируются по шкале от 0 до 1, где 0 – полностью разочарованы, 1 – полностью довольны. 👉 Результаты интерпретируются по шкале: ▫️0.00 - 0.50 неприемлемо ▫️0.50 - 0.70 очень плохо ▫️0.70 - 0.85 плохо ▫️0.85 - 0.94 хорошо ▫️0.94 - 1.00 отлично APDEX вычисляется для каждой ключевой операции, что позволяет учесть конкретные потребности бизнеса и особенности его бизнес-процессов. И именно APDEX даст понимание степени комфортности работы с системой и позволит не просто так крутить показатели, а добиваться именно нужных результатов. А также сразу видеть, какие именно участки требуют внимания. Для операций можно выставить приоритет и тогда дополнительно будет видно, чем именно заняться в первую очередь. Но позвольте, скажет иной читатель, но как мне определить время T, чтобы пользователь был доволен, это ведь некоторая умозрительная величина. Согласны, степень довольства – величина субъективная, но APDEX как раз позволяет сопоставить субъективные ощущения с объективными данными. Если большинство пользователей говорит, что система работает так себе, то принимаем индекс APDEX за 0,65 – плохо, выясняем реальное время выполнения операции и на его основании рассчитываем желаемое T. А это уже меняет все. Теперь вы не пытаетесь угадать, как сделать чтобы все было хорошо или чем еще они недовольны, а получаете определенный показатель, к которому надо стремиться. Каким путем вы этого добьетесь – это уже совершенно иной вопрос, но ведь именно вы технический специалист и именно вам за это платят деньги. Также APDEX всегда позволяет дать ответ в каком текущем состоянии находится наша система и вовремя обосновать тот же апгрейд показав руководству вполне объективные данные, которые подтвердят, что жалобы пользователей имеют под собой реальные основания.

Привет! Я Рома, тимлид разработки 👋 Последний год плотно занимаюсь AI-агентами и OpenClaw и решил завести канал, куда складываю все полезное, что нахожу и проверяю по ходу работы. Делюсь полезными инструментами и исследованиями, разбираю интересные штуки в OpenClaw и иногда показываю, как мы сами разрабатываем агентов. В общем, это не новостник про ИИ. Пишу только про то, с чем сам работаю, что тестирую и что кажется полезным другим разработчикам. Если тоже изучаете OpenClaw и агентов или только хотите начать - залетайте, думаю, нам будет что обсудить 🤝 👉 Подписаться _ #реклама О рекламодателе