Записки IT специалиста
رفتن به کانال در Telegram
IT-канал, просто о сложном https://interface31.ru Купить рекламу: https://telega.in/c/interface31
نمایش بیشتر9 016
مشترکین
+224 ساعت
-137 روز
+2730 روز
در حال بارگذاری داده‌ها
کانال‌های مشابه
ابر برچسب‌ها
اشارات ورودی و خروجی
---
---
---
---
---
---
جذب مشترکین
اکتبر '26اکتبر '26
اکتبر '26
+91
در 0 کانال‌ها
سپتامبر '26
+99
در 0 کانال‌ها
Get PRO
اوت '26
+155
در 1 کانال‌ها
Get PRO
ژوئیه '26
+113
در 0 کانال‌ها
Get PRO
ژوئن '26
+154
در 0 کانال‌ها
Get PRO
مه '26
+149
در 0 کانال‌ها
Get PRO
آوریل '26
+153
در 2 کانال‌ها
Get PRO
مارس '26
+126
در 0 کانال‌ها
Get PRO
فوریه '26
+115
در 2 کانال‌ها
Get PRO
ژانویه '26
+159
در 0 کانال‌ها
Get PRO
دسامبر '25
+187
در 1 کانال‌ها
Get PRO
نوامبر '25
+177
در 1 کانال‌ها
Get PRO
اکتبر '25
+201
در 2 کانال‌ها
Get PRO
سپتامبر '25
+253
در 2 کانال‌ها
Get PRO
اوت '25
+197
در 1 کانال‌ها
Get PRO
ژوئیه '25
+147
در 1 کانال‌ها
Get PRO
ژوئن '25
+142
در 0 کانال‌ها
Get PRO
مه '25
+179
در 2 کانال‌ها
Get PRO
آوریل '25
+211
در 3 کانال‌ها
Get PRO
مارس '25
+174
در 2 کانال‌ها
Get PRO
فوریه '25
+184
در 0 کانال‌ها
Get PRO
ژانویه '25
+222
در 1 کانال‌ها
Get PRO
دسامبر '24
+276
در 0 کانال‌ها
Get PRO
نوامبر '24
+261
در 1 کانال‌ها
Get PRO
اکتبر '24
+270
در 1 کانال‌ها
Get PRO
سپتامبر '24
+288
در 2 کانال‌ها
Get PRO
اوت '24
+284
در 0 کانال‌ها
Get PRO
ژوئیه '24
+219
در 0 کانال‌ها
Get PRO
ژوئن '24
+242
در 6 کانال‌ها
Get PRO
مه '24
+258
در 0 کانال‌ها
Get PRO
آوریل '24
+327
در 0 کانال‌ها
Get PRO
مارس '24
+4 259
در 0 کانال‌ها
Get PRO
فوریه '24
+337
در 0 کانال‌ها
Get PRO
ژانویه '24
+306
در 0 کانال‌ها
Get PRO
دسامبر '23
+255
در 0 کانال‌ها
Get PRO
نوامبر '23
+96
در 0 کانال‌ها
Get PRO
اکتبر '23
+452
در 0 کانال‌ها
Get PRO
سپتامبر '23
+79
در 0 کانال‌ها
Get PRO
اوت '23
+99
در 0 کانال‌ها
Get PRO
ژوئیه '23
+115
در 0 کانال‌ها
Get PRO
ژوئن '23
+82
در 0 کانال‌ها
Get PRO
مه '23
+78
در 0 کانال‌ها
Get PRO
آوریل '23
+84
در 0 کانال‌ها
Get PRO
مارس '23
+96
در 0 کانال‌ها
Get PRO
فوریه '23
+90
در 0 کانال‌ها
Get PRO
ژانویه '23
+97
در 0 کانال‌ها
Get PRO
دسامبر '22
+173
در 0 کانال‌ها
Get PRO
نوامبر '22
+136
در 0 کانال‌ها
Get PRO
اکتبر '22
+99
در 0 کانال‌ها
Get PRO
سپتامبر '22
+106
در 0 کانال‌ها
Get PRO
اوت '22
+107
در 0 کانال‌ها
Get PRO
ژوئیه '22
+105
در 0 کانال‌ها
Get PRO
ژوئن '22
+98
در 0 کانال‌ها
Get PRO
مه '22
+122
در 0 کانال‌ها
Get PRO
آوریل '22
+122
در 0 کانال‌ها
Get PRO
مارس '22
+253
در 0 کانال‌ها
Get PRO
فوریه '22
+81
در 0 کانال‌ها
Get PRO
ژانویه '22
+162
در 0 کانال‌ها
Get PRO
دسامبر '21
+108
در 0 کانال‌ها
Get PRO
نوامبر '21
+124
در 0 کانال‌ها
Get PRO
اکتبر '21
+137
در 0 کانال‌ها
Get PRO
سپتامبر '21
+130
در 0 کانال‌ها
Get PRO
اوت '21
+113
در 0 کانال‌ها
Get PRO
ژوئیه '21
+154
در 0 کانال‌ها
Get PRO
ژوئن '21
+1 541
در 0 کانال‌ها
| تاریخ | رشد مشترکین | اشارات | کانال‌ها | |
| 27 اکتبر | +2 | |||
| 26 اکتبر | +5 | |||
| 25 اکتبر | +1 | |||
| 24 اکتبر | +1 | |||
| 23 اکتبر | +3 | |||
| 22 اکتبر | +4 | |||
| 21 اکتبر | +2 | |||
| 20 اکتبر | 0 | |||
| 19 اکتبر | +4 | |||
| 18 اکتبر | +1 | |||
| 17 اکتبر | +1 | |||
| 16 اکتبر | +9 | |||
| 15 اکتبر | +7 | |||
| 14 اکتبر | +4 | |||
| 13 اکتبر | +4 | |||
| 12 اکتبر | +4 | |||
| 11 اکتبر | +5 | |||
| 10 اکتبر | +2 | |||
| 09 اکتبر | +2 | |||
| 08 اکتبر | +4 | |||
| 07 اکتبر | +2 | |||
| 06 اکتبر | +4 | |||
| 05 اکتبر | +4 | |||
| 04 اکتبر | +4 | |||
| 03 اکتبر | +1 | |||
| 02 اکتبر | +9 | |||
| 01 اکتبر | +2 |
پست‌های کانال
Электроника кажется чем-то сложным, пока не попробуете
Для этого есть бесплатный курс по схемотехнике для начинающих. С самых азов: что такое электрическая цепь, зачем нужен каждый компонент и почему схема работает именно так. Можно проходить одному или вместе с детьми.
Раньше стартовый набор приходилось собирать по разным магазинам. Теперь партнер курса собрал отдельную коробку со всем необходимым. Открываете коробку, кликаете на задание и собираете схему.
А еще у курса есть чат, где напрямую отвечает сам автор — Павел Кириченко, ведущий инженер-схемотехник в YADRO. Среди участников чата — розыгрыш: 10 коробок с наборами компонентов. Заходите, если хотели собрать свою первую схему.
Узнать больше
#реклама 16+
О рекламодателе
| 2 |  Режимы выделения виртуальной памяти в Linux
Еще один вопрос, который вызывает ряд неверных толкований и ошибок в применении – это режим выделения виртуальной памяти в Linux. А именно политика overcommitment – избыточного выделения памяти процессам, чем есть в системе на самом деле.
Постойте, но зачем выделять памяти больше, чем ее есть на самом деле? Может быть надо жить по средствам? Но не все так просто. Многие процессы запрашивают памяти больше, чем используют на самом деле.
Объем заметки не позволяет углубиться в суть происходящих процессов, поэтому допустим определенные упрощения. Во-первых, процесс может резервировать память «на всякий случай», во-вторых – в память могут отображаться разреженные структуры, например, файл 1 ГБ, у которого реально занято 250 МБ, остальное нули (виртуальный диск).
И, наконец, процессы могут использовать память совместно. Скажем если материнский процесс порождает потомка, то он тоже запрашивает выделение памяти как у материнского процесса, но на самом деле использует общую с ним память до тех пор, пока не изменит одну из страниц и только тогда измененная страница будет скопирована в выделенное пространство памяти процесса.
Таким образом выделение памяти процессу не означает ее обязательного использования. Реальное использование физической памяти начинается только после обращения к ней. При этом для процесса не делается разницы между оперативной памятью и подкачкой, и то и другое – физическая память.
Выделение памяти – это, по сути, обещание ядра такую память предоставить, а не ее жесткое резервирование. В результате может сложиться ситуация, что сразу несколько процессов потребуют предоставить зарезервированную память, но ее не окажется в наличии. В этом случае на сцену выходит OOM-killer и убивает самый «негодный» процесс.
Режим работы этого механизма можно задать при помощи опции
vm.overcommit_memory
Которая может принимать одно из трех значений: 0, 1 и 2
🔹vm.overcommit_memory = 0 – значение по умолчанию, лимит выделения памяти рассчитывается ядром эвристически, с учетом реального ее использования. Такая стратегия позволяет наиболее эффективно использовать всю наличную память.
В таком режиме ядро обычно допускает умеренный overcommit на основе объема свободной памяти, swap и освобождаемого дискового кэша.
Из минусов мы имеем некоторую неопределенность. Один и тот же запрос на выделение памяти, может быть, как одобрен ядром, так и отклонен. Также имеется возможность неожиданного срабатывания OOM-killer.
Несмотря на это данный режим наилучшим образом подходит для рабочих станций и универсальных серверов с разноплановой нагрузкой.
🔹 vm.overcommit_memory = 1 – выделение памяти происходит всегда, все лимиты отключены. Очень специфический режим, который тем не менее может оказаться полезным для процессов активно использующих порождение потомков и общую память (веб-сервера).
Но включая данный режим нужно очень четко представлять, что вы делаете, так как очень высокий риск привести систему в нестабильное состояние из-за реального недостатка памяти, плюс крайне высок риск непредсказуемого срабатывания OOM-killer.
🔹 vm.overcommit_memory = 2 – жесткий лимит на выделение памяти, для этого режима используется еще одна опция:
vm.overcommit_ratio = 100
Которая обозначает какой процент памяти используется для вычисления лимита, который производится по формуле:
CommitLimit = swap_total + (RAM_total × vm.overcommit_ratio / 100)
По умолчанию vm.overcommit_ratio = 50 и поэтому если вы его не зададите явно, то лимит будет меньше имеющейся в наличии физической памяти.
Данный режим рекомендуется использовать вместе с приложениями, которые сами управляют выделением памяти, например, СУБД. В документации PostgreSQL такая настройка указана явно.
Причина здесь проста. В случае тяжелого запроса лучше получить явный отказ в выделении памяти и выдать пользователю ошибку «недостаточно памяти», нежели процесс СУБД окажется завершен OOM-killer и потребует аварийного перезапуска.
В ряде систем с высокими требованиями к стабильности рекомендуется уменьшить лимит выделения до 70-80%. | 422 |
| 3 |  Braun — технологии для безупречного ухода
✨Оригинальные бритвы, триммеры и эпиляторы
✨ Точность, комфорт и стиль — вместе с Braun
Купить
#реклама
market.yandex.ru
О рекламодателе | 879 |
| 4 |  Как изменить SID в Windows 10/11 и Server 2025
О проблеме дублирующихся SID мы писали в нашей прошлой заметке, сегодня расскажем о том, как изменить его без переустановки системы.
❗️Важно! Данный способ является неофициальным и потенциально может привести к нарушению работы системы и/или потере информации. Поэтому все действия вы производите исключительно на свой страх и риск!
Для работы мы будем использовать утилиту SIDCHG, которую следует скачать с официального сайта, там же расположен лицензионный ключ пробной версии, который представлен в качестве изображения и меняется каждый месяц, на октябрь 2026 года ключ такой:
77JAY-XcFfv-2OiLw-2f
После чего узнайте текущий SID машины, например, при помощи PsGetsid64 от Sysinternals.
‼️ Если система использует BitLocker (а Windows 11 использует его по умолчанию), то шифрование нужно отключить, а диски расшифровать.
Статус можно узнать командой:
manage-bde -status C:
Отключить:
manage-bde -off C:
Если дисков несколько – повторить для каждого, после чего следует дождаться процесса расшифровки и перезагрузить ПК.
‼️ Если вы используете EFS, то скопируйте зашифрованные файлы в другое место, а также не забудьте экспортировать сертификат с ключами.
Будьте готовы к тому, что некоторое программное обеспечение может потребовать повторной активации.
🔹 Затем отключите службу UCPD — это User Choice Protection Driver
sc config UCPD start=disabled
schtasks.exe /change /Disable /TN "\Microsoft\Windows\AppxDeploymentClient\UCPD velocity"
Перезагрузитесь, иначе защита полноценно отключена не будет.
Выключите онлайн-защиту антивируса, включая Defender и запустите скачанную утилиту с ключом R:
SIDCHG64.exe /R
Введите лицензионный ключ и подтвердите свои действия, утилита завершит сеанс, и вы окажетесь на экране блокировки. Не входите в систему до завершения ее работы, особенно это важно для сервера, где могут быть удаленные сеансы.
По завершении работы компьютер автоматически перезагрузится. После чего первым делом включаем обратно службу UCPD и снова перезагружаемся.
schtasks.exe /change /Enable /TN "\Microsoft\Windows\AppxDeploymentClient\UCPD velocity"
sc config UCPD start=auto
После чего убедитесь, что SID действительно изменился.
👉 В некоторых случаях могут начать нестабильно работать современные приложения и меню Пуск, в этом случае нужно выполнить сброс их настроек, для этого снова запустите утилиту:
SIDCHG64.exe / RESETALLAPPS
Данная команда сбросит все современные приложения, либо, если хотите действовать точечно:
SIDCHG64.exe /RESETAPPS=App_1
Где App_1 – имя современного приложения, можно перечислить несколько значений через запятую.
При соблюдении всех указанных подготовительных мер данный способ работает, но не нужно забывать, что он не является официальным и Microsoft такой сценарий не поддерживает. Поэтому обязательно делайте бекапы, а по возможности лучше переустановите систему. | 996 |
| 5 |  Сеоника: сайты, деньги и нейросети на практике
Делюсь практикой на своих проектах: создание сайтов, магазинов, автоматизация, SEO и привлечение клиентов. По-чесноку: что получилось, где ошибся, сколько потратил.
Для вебмастеров, маркетологов и тех, кто продвигает свой бизнес в интернете. Подписывайтесь!
Подписаться
#реклама
О рекламодателе | 1 194 |
| 6 |  Подключаем диск из NAS в Linux, или монтирование RAID и LVM разделов
Всем нам знакомы и привычны аппаратные NAS, они используются дома и на работе для хранения самых различных данных. Но любое оборудование может выходить из строя, обычно неожиданно и перед администратором может встать задача копирования данных с дисков NAS.
На первый взгляд в ней нет ничего сложного: в основе прошивки Linux, а значит берем любую Linux систему, подключаем, монтируем, сливаем...
Однако не все так просто и для выполнения этой задачи могут потребоваться достаточно глубокие знания систем хранения Linux и навыков работы с ними.
Разбирать подобные ситуации лучше на примерах, тем более в нашем случае он как будто специально, достаточно показательный.
На днях к нам обратился коллега с просьбой помочь достать информацию с диска, вышедшего из строя NAS Synology DS216. На наш вопрос в чем там проблема он уклончиво ответил, что как-то все сложно и он боится сделать что-нибудь не так и испортить данные.
Ну что же, давайте разбираться. Итак, перед нами следующие вводные: есть диск из двухдискового NAS, работавшего с зеркальным RAID-массивом, в качестве файловой системы использовалась ext4.
✅ Читать далее: https://interface31.ru/post/podklyuchaem-disk-iz-nas-v-linux-ili-montirovanie-raid-i-lvm-razdelov/ | 1 214 |
| 7 |  Монолит vs микросервисы: битва за ваши нервы
💻 Монолит или микросервисы? Кажется, что ответ очевиден, но почему-то одни проекты летают, а другие тонут в хаосе?
Присоединяйтесь к открытому уроку Сергея Прощаева и получите пошаговое руководство по выбору архитектуры.
📅 9 ноября в 20:00. Разберём:
- Как не попасть в ловушку «модных» микросервисов.
- Признаки, что пора выходить из монолита.
- Архитектурные паттерны перехода: Strangler Fig, BFF, Self-contained systems.
- Организационные и технические риски — что пойдёт не так.
- Роль DevOps, CI/CD и мониторинга.
Вы научитесь оценивать реальные риски и стоимость микросервисов, внедрять изменения без сбоев и хаоса и принимать взвешенные решения, сохраняя технический контроль и производительность команды.
✅ Запишитесь сейчас!
Узнать больше
#реклама 16+
otus.ru
О рекламодателе | 1 302 |
| 8 | Какую ФС на серверах с Linux вы используете? (Можно выбрать несколько значений) | 1 470 |
| 9 |  Современные файловые системы Linux
Выбор файловой системы в Linux может оказаться сложной задачей для новичка. На что смотреть? На тесты и бенчмарки, которые проводятся на пустом SSD и не отражают реальность?
Сегодня мы коротко разберем актуальный квартет: ext4, XFS, Btrfs и ZFS, подсветив все их основные плюсы и минусы.
1️⃣ ext4: Проверенная временем классика
Это классическая блочная журналируемая ФС с записью «на месте» (In-place update). Максимальная стабильность, предсказуемость и надежность, минимальное потребление ресурсов CPU и RAM. Все это проверено десятилетиями.
Но это именно классическая ФС и если вы хотите снапшоты, пулы, сжатие и проверку целостности – ничего этого нет.
Есть еще «родовая травма» - таблица индексных дескрипторов (inodes) размечается один раз на этапе форматирования и впоследствии изменена быть не может.
Если диск используется под сценарии с миллионами крошечных файлов (почтовый сервер с Maildir, кэш аватарок веб-сервера, мелкие сессии, очереди задач), наступает классический парадокс: свободное место есть , а записать файл нельзя.
2️⃣ XFS: Enterprise-стандарт
XFS - 64-битная высокомасштабируемая журналируемая ФС с аллокацией по экстентам (extents) и разделением пространства на независимые группы размещения (Allocation Groups).
Обеспечивает высокую производительность при параллельной многопоточной записи/чтении и работе с крупными файлами (видео, дампы, медиа).
Дефолтная ФС в enterprise-дистрибутивах (RHEL / Rocky / AlmaLinux).
Но есть и достаточно серьезные недостатки - раздел XFS нельзя уменьшить, вообще никак: система XFS умеет расти (xfs_growfs), но архитектурно не умеет уменьшаться.
А далее имеем классический случай, на смену одним дискам на 1 ТБ (честный двоичный байт 2^40 = 1024 ГБ) купили маркетинговый «терабайт» (10^12 байт ~ 931 ГиБ). И что? И все, приехали.
Btrfs: «Спасение» силами гигантов индустрии
На заре своего появления (конец 2000-х / начало 2010-х) Btrfs имела репутацию крайне нестабильной, «сырой» и опасной системы. Она регулярно теряла данные при падениях питания, страдала от критических багов в аллокаторе свободного места, а алгоритмы RAID5/6 были в целом неработоспособные.
Red Hat со временем и вовсе официально признала Btrfs устаревшей (deprecated в RHEL 7.4) и полностью вырезала её поддержку в RHEL 8, сделав будущее этой ФС очень туманным.
Поворотным моментом стал приход в Meta* новой команды инженеров (Крис Мейсон, Йозеф Бачик и прочие). Они переписали и довели до ума самые проблемные места, код работы со свободным пространством, асинхронную очистку, сжатие ZSTD и интеграцию с механизмами ядра Linux.
В итоге это превратило вечную «бета» в надежную систему, которая используется по умолчанию для SUSE и Fedora.
ZFS: Монолитная СХД в одном флаконе
Это не просто ФС, а связка: файловая система + менеджер томов + RAID с пулом накопителей и легкими датасетами. Полный сквозной контроль целостности: контрольные суммы на каждый блок, самовосстановление, снапшоты, репликация и собственный кэш ARC в RAM.
Но за это все приходится платить, в первую очередь высокими требованиями к RAM и высоким коэффициентом WAF (что характерно для всех CoW систем).
Хотя в грамотных руках это того стоит, вы получаете очень гибкое, настраиваемое и масштабируемое хранилище корпоративного уровня.
Выводы:
🔹Нужна железобетонная стабильность «поставил и забыл»? ext4.
🔹Высокие параллельные нагрузки, базы или огромные файлы без нужды сжимать раздел? XFS.
🔹Десктоп, снапшоты системы перед апдейтом и сжатие на лету? Btrfs.
🔹СХД, отказоустойчивые пулы, виртуализация и контроль целостности? ZFS.
* Meta признана экстремистской организацией в России. | 1 267 |
| 10 |  Специальное предложение на Москвич 3. Кредит от 0,01%
Мощность 136 л.с. Хромированные вставки. Подходит для АИ-92. Предложение ограничено
Узнать больше
Изучите все условия кредита (займа) на сайте в соответствующем разделе. Оценивайте свои финансовые возможности и риски. Финансовые услуги оказывает: АО "Авто Финанс Банк", ПАО "Совкомбанк".
#реклама
moskvich.ru
О рекламодателе | 1 360 |
| 11 |  Кошмар на улице Вязов
Сегодня мне приснился страшный сон, от которого я проснулся буквально в холодном поту. На его фоне любые киношные монстры, маньяки и прочие ужастики кажутся невинным детским утренником.
Сон пересказывать не буду: местами он иррациональный, как и положено сновидениям. Но суть свелась к простой фабуле: в чужом городе у меня украли телефон, и я остался в незнакомом месте — без связи, без денег и без навигации.
И ведь это реальный кошмар современного мира. Сегодня смартфон — не просто средство связи, а цифровой центр человека, в котором сосредоточено практически всё. Оказавшись без него, чувствуешь себя буквально голым.
Начнём со связи. Сколько номеров помнит наизусть современный человек? Хорошо, если один — свой собственный. Люди старой закалки, возможно, удержат в памяти два-три номера самых близких. Но и то вряд ли: мы видим цифры один раз при сохранении, а дальше просто тапаем по записи в адресной книге.
К тому же основным средством общения давно стали мессенджеры. Они хоть и привязаны к номеру, но просто попросить телефон у прохожего и «быстро черкнуть в телегу» не выйдет. В итоге, даже если добрый человек протянет вам свой аппарат, звонить будет попросту некому. Память пуста. Но это лишь верхушка айсберга.
Деньги. Многие уже много лет назад отказались от наличных, а некоторые — и от физического пластика. Зачем носить с собой карты, если их можно потерять или забыть, когда всё и так в телефоне?
Тем более что у большинства карт больше одной: повседневная, для онлайн-покупок, для регулярных автосписаний. Деньги между ними перекидываются за секунду в банковском приложении.
Без смартфона вы рискуете остаться либо без копейки вообще, либо без доступа к основной части своих средств. А это уже проблема принципиально другого масштаба.
Третий момент — навигация. Мы намертво привыкли ориентироваться по экрану. Вбил адрес — тебе проложили маршрут или сразу вызвали такси. Причем можно даже без точного адреса: просто ткни «метро такое-то» или название торгового центра.
Спросить дорогу у прохожих? Большинство знает свой дом и пару соседних дворов. Если это не центральный вокзал, вам просто неопределенно махнут рукой: мол, идите вон до того угла, а там еще у кого-нибудь спросите. Да и до того же вокзала без денег и такси еще попробуй доберись.
Но и это не всё. Цифровизация окончательно поглотила сервисы: билеты, бронирования, документы. Недавно покупал билеты на поезд: на почту упало несколько PDF, в приложении РЖД всё подтянулось.
На посадку пустят по паспорту, но номер поезда, вагон и место надо где-то подсмотреть. Ладно, вокзал — полбеды: пришел пораньше, сел и жди, проводник через любой вагон разберется.
А как быть с арендой жилья? Сейчас повсеместно внедряют бесконтактное заселение. К моменту заезда вам в мессенджер просто скидывают код от кодового замка или сейфа с ключом.
Нет телефона — нет кода. И хоть головой в дверь бейся — никто не откроет, потому что на месте никого нет, а служба поддержки сидит в чате. Имея на руках полностью оплаченную бронь, вы запросто останетесь ночевать на лавочке.
Добавьте сюда страховки, справки, медицинский полис, который давно никто не носит на бумаге, — всё лежит на «Госуслугах». А ключ к ним — опять в кармане.
Конечно, можно по старинке распечатывать стопку бумаг, возить с собой заначку наличных и выбирать отели исключительно с круглосуточным ресепшеном. Но тренд неумолим: мы всё глубже уходим в стопроцентную цифру.
И смартфон в этой реальности стал единственной точкой присутствия человека. Потерял, разбил, украли или просто сел аккумулятор — и ты в ту же секунду выброшен на обочину жизни. | 1 244 |
| 12 |  INMYROOM — маркетплейс мебели для людей со вкусом
130 000+ товаров для дома. Мебель, свет, декор. Нас выбирают дизайнеры интерьера
Узнать больше
#реклама
inmyroom.ru
О рекламодателе | 1 323 |
| 13 |  Про эффективный менеджмент
Сегодня суббота, а поэтому будет одна поучительная история из жизни. Середина нулевых, один местечковый районный провайдер, тогда таких было много.
Мы одно время работали в одном здании с ними, а поэтому хорошо друг друга знали. Потом у них дела пошли в гору, и они переехали в отдельное здание и наши пути потихоньку разошлись.
Ребята там были неплохие, кроме директора, был он, мягко скажем, немного скуповатым, хотя если честно, то далеко не немного. Но была у него еще вторая негативная черта характера. Все, кто имел сомнительное удовольствие с ним долго общаться не именовали его иначе чем чудак на букву М.
Я тоже жил в том районе и пользовался их интернетом и вскоре начал замечать, что проблемы только растут и множатся. То скорости нет, то связь пропала, то еще что-нибудь.
Хотя были иногда и приятные моменты, скажем, на майские праздники отключился биллинг и каждый качал-закачивался. А интернет в ту пору тарифицировался, если кто не помнит или не знает, помегабайтно.
Потом я как-то спросил ребят провайдера, а что это за аттракцион невиданной щедрости был?
Выяснилось, что шеф расплевался с их давним сисадмином, который стоял еще у истоков конторы и тот ушел, хлопнув дверью и назвав шефа чудаком. За серверами с диковинной FreeBSD никто не следил, так как не понимал, как следить, и в один прекрасный день место на дисках просто закончилось.
Биллинг прилег и народ все праздники резвился, попутно загоняя контору в долги. После чего из конторы ушел второй человек, который также стоял у ее основания и понимал в сетях.
Но шефа ничего не смутило, подумаешь, сисадмин, ну и подумаешь сетевой инженер. Больно нужны, у нас же все хорошо. Были приглашены специалисты со стороны и был внедрен новый биллинг, уже на Linux.
Между тем качество услуг стремительно падало, но во всем оказались виноваты пользователи, мол это они положили сеть широковещательными чатами и DC++ обменом. После чего эти приложения попытались просто запретить. Мол у кого обнаружим – отключим.
Но отключить пришлось бы решительно всех, поэтому такая инициатива сошла на нет. Лучше, естественно, не стало. Да и как оно станет в отсутствие сетевого инженера.
Прошло еще года полтора, звонит мне их шеф, мол ты же в Linux понимаешь? Понимаю. Приезжай, дело есть.
Приехал. Новый биллинг лежит. Начинаю разбираться. В наличии неплохой по тем временам сервер и RAID 5 с запасным диском. В RAID 5 выпали два диска из трех, а запасной кто-то свистнул, поставив вместо него неисправный диск бытовой серии.
Ну что тут было сказать? Только похлопать по плечу и сообщить, что медицина бессильна. Особенно если в штате не было ни одного следящего за инфраструктурой сотрудника.
Пошарившись по серверной нашли сервер с бекапами, но там был только бекап БД биллинга.
Ну вот, не все так плохо, можно восстановить.
Он спрашивает меня, смогу ли я это сделать. Отвечаю, что нет, я этот биллинг первый раз в жизни вижу и лучше всего обратиться к его разработчикам.
Выяснилось, что это не вариант, так как он им денег должен и за поддержку не платил два года. А зачем, ведь все работало.
В общем, принес ему свои соболезнования и сказал, что мне пора и было бы неплохо дать мне денег.
На что услышал, а за что тебе денег, ты же ничем мне не помог. В итоге, пояснил ему, что он чудак, развернулся и ушел.
Провайдеру тут же настал карачун, народ разбежался. А шеф? Шеф продал сети одному из федеральных провайдеров.
А что же теперь? А он теперь начальник в местном отделении федерального провайдера. До чего-то важного его не допускают, но теплое кресло выделили. Ну и репутация чудака на букву М за ним числится до сих пор.
Он же, в свою очередь, особенно после пары рюмок, любит поучать молодежь и рассказывать как у него давно был свой бизнес и как он его удачно продал, поняв, что не может тягаться на равных с федералами. | 1 305 |
| 14 |  +4Телеграм канал AI для бизнеса
AI - не будущее. Это настоящее вашего бизнеса.
Телеграм-канал "AI для бизнеса" знает все о внедрении и использовании искусственного интеллекта в бизнесе в России и мира. Только со своими подписчиками канал делится:
- как внедрить искусственный интеллект в реальные бизнес-процессы,
- разборами кейсов: как компании сократили затраты на 30-50% с помощью AI,
- лайфхаками по автоматизации рутинных задач,
- новостями мира AI и разборами трендов.
Сами давно читаем и вам советуем подписаться.
Подписаться
#реклама 16+
О рекламодателе | 1 246 |
| 15 |  ZFS на скромном сервере
ZFS привыкли воспринимать как тяжеловесный enterprise-комбайн. Но если спуститься на землю — в реалии небольшого продакшна (один сервер, Proxmox/LXC, связка из 1С с PostgreSQL и потребительские NVMe), возможности ZFS раскрываются с сугубо прикладной стороны.
Главное — сразу отбросить старые догмы.
1️⃣ Почему ZFS идеальна для LXC и баз данных
В отличие от классического LVM или жестких разделов, ZFS дает единый пул (zpool), поверх которого нарезаются датасеты — легкие логические файловые системы. Никаких фиксированных гигабайт: каждый датасет видит весь свободный пул, но управляется индивидуально.
🔸 recordsize под задачу. По умолчанию в ZFS блок равен 128 КБ. Для СУБД со случайной записью страницами по 8 КБ это верная смерть накопителя из-за дикого Write Amplification (WAF). Датасет базы с recordsize=8k сразу убирает оверхед. Датасет под бэкапы или логи при этом спокойно живет со стандартными 128 КБ.
🔸 Встроенное сжатие (LZ4/ZSTD). Это не про экономию диска, это про ресурс потребительского флеша. Сжатие уменьшает физический объем, который контроллер SSD пишет в ячейки. Меньше физической записи - ниже WAF и дольше живет TBW.
🔸 ARC вместо page cache. Умный двухфакторный кэш в оперативной памяти (ARC) отслеживает не просто недавние обращения (MRU), но и их частоту (MFU). Случайный тяжелый отчет в 1С не вымоет из памяти горячие индексы живой базы.
2️⃣ L2ARC: почему вторичный кэш здесь вреден
L2ARC создавался 15 лет назад для гибридных хранилищ, чтобы прикрыть медленные «холодные» HDD быстрыми SSD. Ставить его в NVMe-сервер - грубейшая ошибка.
🔸 Кража оперативной памяти. Чтобы адресовать блоки в L2ARC, ZFS держит таблицу указателей прямо в RAM. Выделяя SSD под L2ARC, вы отбираете мегабайты и гигабайты памяти у ARC.
🔸 Бессмысленность шины. Чтение блока с соседнего бытового NVMe идет с теми же задержками PCIe, что и с основного пула. Профита по задержкам - ноль.
🔸 Сжигание ячеек мусором. В L2ARC вытесняется в основном MRU-хвост. Туда потоком летят одноразовые блоки от бэкапов и квартальных проводок. Вы просто тупо стираете ресурс записью «мусора», который больше никогда не будет прочитан
3️⃣ SLOG на копеечном Optane 16 ГБ: громоотвод для СУБД
Базы данных требуют строгой фиксации транзакций (fsync). У потребительских NVMe нет аппаратной защиты от потери питания (PLP). При каждом вызове fsync бытовой контроллер сбрасывает буферы прямо во флеш-память, вызывая провалы по задержкам и раздувая WAF двойной записью в ZIL.
Спасение — отдельный лог записи (SLOG) на стареньком Intel Optane на 16 ГБ (серия M10), купленном за копейки:
🔸 Нам не нужны терабайты: SLOG держит данные только до сброса транзакционной группы (раз в 5 секунд).
🔸 Линейная скорость не важна (у 16 ГБ Optane она всего ~150 МБ/с). Главное — физика памяти 3D XPoint: у нее нет блоков стирания, нет падения скорости после SLC-кэша и микросекундные задержки.
🔸 Optane спокойно живет даже на переходнике в одной линии PCIe x1. Его задача — быстро подтвердить транзакцию СУБД за микросекунды и избавить основной NVMe-пул от мелкоблочной случайной записи.
4️⃣ Special VDEV: когда он нужен, а когда создает риски
Special Allocation Class выносит метаданные (а опционально и мелкие блоки) на выделенные накопители.
🔸В чем риск? Special VDEV — это не кэш, а часть структуры данных пула. Смерть special хоронит zpool целиком. Поэтому сюда допустимо ставить строго зеркало (Mirror). На чисто твердотельном NVMe-сервере под 1С от него мало толку - задержки метаданных на основном пуле и так микросекундные.
🔸 Где он идеален? В сценариях сегрегации нагрузки. Например, у вас есть холодный архив на HDD (почта, файлопомойка): пара небольших NVMe под special заставит поиск и листинг миллионов файлов летать без дерганья шпинделей.
👉 Резюме: ZFS на потребительском железе требует не слепого следования мануалам, а понимания физики накопителей. Выравнивайте recordsize, включайте сжатие, забывайте про L2ARC как про страшный сон, а на сдачу поставьте копеечный Optane под журнал ZIL. | 1 439 |
| 16 |  Пятница, 17:30. Макет почти готов
Но один сценарий всё ещё вызывает вопросы. Обсудить сейчас или вернуться в понедельник?
Решайте вместе с командой hh.ru в «Охэхэнных новостях».
Подписаться
#реклама
О рекламодателе | 1 263 |
| 17 |  Наташ, ты спишь? Мы там все уронили и мониторинг твой не сработал…
Мониторинг – тема сложная, гораздо сложнее чем кажется на первый взгляд и главное в ней правильно настроить объект мониторинга, чтобы получать нужное и не получать ненужное.
А еще хуже, когда мы мониторим вообще не то, что надо. В результате о случившемся нас оповестит не мониторинг, а разгневанные пользователи.
На днях обновляли 1С:Предприятие в одной подопечной организации и местный админ попросил что-нибудь простое и современное для мониторинга доступности основных сервисов, чтобы просто видеть, что живо, а что упало.
Показали ему Uptime Kuma, понравилось, запустили. Он пошел добавлять узлы, а мы принялись за свою работу, а потом все-таки заглянули посмотреть, что он там сделал и сильно удивились.
В общем это классика жанра. В нашем случае это был веб-сервер с опубликованными на нем базами 1С:Предприятие, скажем 1с.example.com, ну вот наш коллега ничтоже сумняшеся взял и добавил в монитор именно этот узел.
После чего мы предложили ему сесть и подумать, что именно будет контролировать такой монитор? Чтобы активировать мыслительный процесс мы предложили перейти по этой ссылке и полюбоваться на стандартную заглушку IIS/Apache.
Да, такой монитор покажет нам жив ли веб-сервер в принципе, но никакого контроля над опубликованными на нем сервисах у нас не будет. В данном случае хуже будет только Ping, хотя и так многие делают, а потом сильно удивляются, когда их будят рано утром.
А вот здесь самое время подумать, что именно нам нужно мониторить. Веб-сервер? Его статус в вакууме нам не даст никакой полезной информации. Веб-приложения? Именно, вот именно их состояние нам и интересно.
Мы вполне можем получить ситуацию, когда веб-сервер работает нормально, а веб-приложение или сайт вдруг начали выдавать коды 4хх или 5хх и наша задача узнать об этом своевременно, а не тогда, когда найдут и разбудят.
Поэтому добавляем в мониторинг не один узел, а три, по количеству опубликованных веб-сервисов (понятно, что у вас может быть любое количество) и теперь мы будем видеть состояние каждого из них в отдельности.
Теперь вы можете своевременно реагировать на происходящее и четко понимать, что и с кем случилось.
Этот подход следует применять для любых систем мониторинга и сервисов. Помните, что нас интересует не состояние узла, а работоспособность развернутых на нем сервисов, поэтому мониторить нам нужно именно их, а потом уже все остальное.
Кстати, состоянием узла тоже пренебрегать не стоит. Особенно если есть возможность настраивать зависимости. Скажем в Zabbix вы можете настроить зависимости триггеров сервисов от состояния узла и если он полностью выключен, то Zabbix не будет спамить вас десятком сообщений о недоступности каждого сервиса в отдельности, а просто скажет, что узел такой-то не в сети.
Но первичны у нас именно сервисы, помните об этом! | 1 534 |
| 18 |  AI меняет IT. Но какие технологии действительно заслуживают внимания?
Новые модели, AI-агенты и инструменты автоматизации появляются ежедневно. Важно не просто следить за новостями, а понимать их реальную ценность.
⚡ AI News Engine — технологическое медиа, где мы отбираем значимые события и объясняем, что изменится, почему это важно и где можно применить новые технологии.
Без информационного шума. Только факты, контекст и практическая польза.
AI News Engine — меньше шума, больше смысла. | 1 312 |
| 19 |  Про помогаторов
На фоне последних событий рассмотрим еще один феномен – помогаторство.
Суть его сводится к тому, что коллеги начинают ошибочно путать процесс зарабатывания денег с помощью клиенту, даже если он об этом не просил и денег за это не предлагал.
В чем это проявляется? Обычно берут подряд на один вид работ, но в процессе всплывают некоторые сложности и вместо того, чтобы озадачить этим клиента, они начинают решать вопрос самостоятельно, либо пытаются решить задачу наличными средствами.
Например, аппаратные средства заказчика явно не соответствуют решаемой задаче. Правильно – это сделать стоп и довести до заказчика реальные требования. А не соглашаться «ну сделать пока как-то так, а там решим».
Потому что ничего «там» не решат, а будут тянуть полудохлую систему до последнего, постоянно прося вас «что-то» сделать. И если вначале просить будут вежливо и даже давать денег, то потом начнут просто требовать и возмущаться, потому как мы тебе столько денег заплатили, а ты нормально ничего сделать не можешь.
А попытка таки вернуть ситуацию на стартовую позицию с покупкой адекватного железа обернется тем «а почему ты мне сразу не сказал» и вряд ли вы снова что-то нормально заработаете. Плюс вам заказчик будет постоянно внушать чувство вины за ваш прошлый «прокол».
Следует понимать, что у вас свой бизнес, у него свой и каждый из вас преследует цель заработать денег, а не взять на себя проблемы и головняки контрагента.
Ему нужно работать? Ну так пусть покупает адекватное железо или ищет неадекватного исполнителя, которому потом будет выносить мозги тем, как у него всё плохо, и это все потому, что исполнитель не может ничего нормально наладить.
Еще раз – это его бизнес и его проблемы. А не ваши. Ваша проблема – заработать указанную сумму денег без лишних проблем и заморочек. Пытаясь решить проблему заказчика подобным образом, вы только перекладываете чужие проблемы на себя.
При этом проблема никуда не денется, ее придется решать, только уже не заказчику, а вам. Так как голова начнет болеть не у него, а у вас. Потому что это вы ему пообещали сделать хоть как-нибудь, и он с вас будет требовать обещанное.
А то, что обещанное не решается наличными средствами, так заказчику это неведомо, он и знать ничего такого не обязан, но как рачительный собственник он, конечно же, попытался у вас узнать, можно ли как-то пока поработать так, вы сказали можно.
Вторая крайность - это создание для заказчика дополнительных сервисов и услуг, которые он не заказывал. Тот же мониторинг, резервные копии и т.д. и т.п.
Возможно, это связано с профдеформацией при работе в крупных организациях, где специалист знает, что при сбоях с него в первую очередь спросят про то, где был мониторинг и откуда взять резервные копии.
Здесь все гораздо проще. Доступно объясняете заказчику, на понятном ему языке, что может произойти и какие варианты вы предлагаете на этот случай. Отказывается – объясняем еще раз. Предельно понятно. Вот это сервер, он сгорел, нафиг, совсем, ничего нет. Что делать будешь?
Снова отказывается? Ну это его проблемы. Спокойно уходим, а если он таки прибегает с такой проблемой, то разводим руками и говорим, что мы его предупреждали. И никаких угрызений совести тут быть не должно. Это его бизнес, его риски. Вы сделали ровно то, что вас просили, остальное не ваши проблемы.
И здесь мы плавно подходим к тому, что нужно уметь твердо, но корректно говорить заказчику нет, когда он пытается попутно нагрузить вас другой проблемой. Следует пояснить, что выполнили вы один объем работ, то, что он хочет – это другое, это другой объем услуг и другая оплата.
Хороший пример был в комментариях, мол вы настроили нам обмен, а теперь у нас не идут остатки. Тут все просто, обмен – это обмен. Работает? Ну прекрасно, вот акт, вот счет.
Надо что-то решать с остатками? Это другая услуга, стоить будет примерно столько. Устраивает? Работаем.
Иначе вы так и останетесь помогатором, который будет тратить собственное время и решать при этом чужие проблемы за собственный счет. | 1 846 |
| 20 | Сломает ли ИИ рынок труда? IT-инженеров не будет?
Уже длительное время коллеги по цеху задаются интересным вопросом: «Заменит ли ИИ программистов?».
Эта тема хайповая, вопросы по ней провокационные, а ответы на них поляризованы. Я же постараюсь найти истину в не самом тривиальном исполнении и с опорой на хоть какие-то исследования...
IT, бизнес, экономика и политика...
https://t.me/+K9YHFEuzZRI0OTIy?erid=2W5zFGQ26Uy
Реклама. Дегтярев Г.М. ИНН 643910922420. | 1 382 |
