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

Покупать машины в РФ — бессмысленно. Вот почему: Покупать авто в России в 2025 году - фатальная ошибка. Из-за утильсбора и роста цен даже за 3 млн ₽ сложно найти свежий автомобиль. А в январе ожидается повышение +20-30%. Вот что реально можно привезти из Кореи за 30 дней и дешевле на сотни тысяч: 🚗 BMW 3 Series - 3 600 000 - 2 800 000 руб. 🚗 Kia K5 - 3 100 000 - 2 550 000 руб. 🚗 Hyundai Elantra - 2 200 000 - 1 800 000 руб. Все авто - с историей, фотоотчётами и договором. Хотите видеть реальные цены без наценок? ✅ Подписывайтесь на закрытый канал SILENKOAUTOcratia - команда с 2020 года привозит авто из Кореи, Китая и Японии и имеет рейтинг 5 на Яндексе. Подписаться #реклама О рекламодателе

Кот из дома – мыши в пляс Хотите посмотреть, что делают ваши сотрудники, подрядчики и прочие лица, наделенные административным доступом в Linux? Да, можно почитать логи, посмотреть историю команд, но это не даст полного представления, особенно если были использованы интерактивные утилиты. Но sudo готово нам помочь, причем совершенно «бесплатно», все нужные инструменты уже есть из коробки, осталось только использовать. Для этого добавьте в /etc/sudoers два параметра, которые отвечают за запись потоков ввода и вывода сессии, например:

%sudo   ALL=(ALL:ALL) NOPASSWD:LOG_INPUT:LOG_OUTPUT:ALL

Потом смотрим, кто и когда работал под sudo указав имя пользователя:

sudoreplay -l user andrey

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

sudoreplay 000005 -R -s 2

Приятного просмотра!

Разыгрываем сертификаты на Ozon за лучшие комментарии Самое время добавить к предновогодней суете немного интеллектуального азарта, согласны? ✅Тогда переходите к правилам конкурса, оставляйте свои комментарии и ждите новогоднего чуда. Троих счастливчиков наградим сертификатами Ozon номиналом 3 000 рублей💰 Узнать больше #реклама itelon.ru О рекламодателе

AppArmor-шум или тонкие настройки логов в LXC-контейнерах Proxmox Изучая системный журнал Proxmox, вы можете обнаружить целые блоки записей вида:

apparmor="DENIED" operation="sendmsg" class="file" namespace="root//lxc-803_<-var-lib-lxc>" profile="rsyslogd" name="/run/systemd/journal/dev-log"

Они не свидетельствуют о каких-либо проблемах и могут быть проигнорированы, однако таких записей может быть много, что серьезно засоряет лог и затрудняет его чтение. Но что это вообще за записи? Давайте разберемся. Как мы можем видеть источником записи является служба rsyslogd контейнера, которая хочет получить доступ к dev-log хоста, чтобы что-то записать в системный лог, но AppArmor ей в этом препятствует. В общем и целом, в rsyslogd для контейнеров нет особой нужны, она только дублирует работу systemd-journald, поэтому его можно отключить, это полностью решит проблему AppArmor-шума. Но мы пойдем немного дальше и подумаем, а нужны ли нам вообще системные логи в контейнерах? Чтобы посмотреть, что systemd-journald туда пишет запустите:

journalctl -f

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

systemctl stop rsyslog 
systemctl mask rsyslog

Затем создадим директорию

mkdir -p /etc/systemd/journald.conf.d

А в ней создадим и откроем на редактирование файл:

nano /etc/systemd/journald.conf.d/00-journal.conf

В который внесем следующее содержимое:

[Journal]
Storage=volatile
RuntimeMaxUse=64M
ForwardToSyslog=no

Первые две строки предписывают использовать для логов оперативную память и задают доступный размер (в нашем случае 64 МБ). Последняя строка запрещает перенаправлять события в syslog, несмотря на то что мы отключили rsyslog данная опция не будет лишней, потому что по умолчанию systemd-journald перенаправляет туда каждое событие. Да, они будут перенаправляться в никуда, но зачем вообще тратить на это ресурсы? А в некоторых конфигурациях это может стать дополнительным источником сообщений в логах. Сохраняем содержимое файла и перезапускаем службу:

systemctl restart systemd-journald

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

⚡️ Бесплатный вебинар от GigaDevOps — «Как админу перейти в DevOps и выйти на доход 200–300k+» Системные администраторы всё чаще уходят в DevOps Почему? Потому что: – Зарплаты 80–130к — и потолок – Те же задачи каждый день – Нет проектного опыта и CI/CD 📍На бесплатном вебинаре GigaDevOps расскажут, как администратору вырасти до уровня DevOps‑инженера и повысить доход в 2–3 раза. 15 января. 19:00 МСК. Что будет на встрече: ✅ Реальный кейс: админ → DevOps за 4 месяца ✅ Карта развития: Linux → Docker → Kubernetes ✅ Чего ждут на собеседовании ✅ Главные ошибки новичков 🎁 Регистрация открыта — при записи скидка 10% на обучение 🔗 Записаться на встречу

И снова про рекламу и донаты Эта тема уже неоднократно поднималась на данном ресурсе и непременно будет подниматься вновь, так уж устроен человек. Мы сейчас не будем бросаться в крайности, потому что всегда найдется категория читателей, которая в принципе не переносит рекламу и считает, что автор должен персонально им и вообще должен быть голодным. Мы же будем говорить о читателе адекватном, который в принципе понимает, что количество и качество публикуемых материалов каким-то образом связано с количеством рекламы и где-то там соглашается с позицией: нет рекламы – нет контента. Сегодня мы хотим показать другую сторону этой всей кухни – то, как создаются материалы и сколько времени это занимает. Все материалы в канале делятся, собственно, на материалы канала и анонсы статей сайта. Обязательный план – минимум две заметки в день. Средняя техническая заметка для Telegram занимает час-полтора времени. Потому что нужно найти материал, проверить его, скомпоновать, упорядочить и придумать как уместить все это в 4000 символов. Короткая заметка за жизнь, типа этой, также занимает не менее часа, потому что нужно сделать подводку, выразить основную мысль и сделать заключение, опять-таки в пределах тех самых 4000 символов. Нет, можно, конечно, выплеснуть сразу из головы, только будет это нечитаемая каша, мутный поток сознания. Итого по нашему плану имеем 1,25 * 30 = 37,5 часов в месяц, без чуть-чуть рабочая неделя. Это только на подготовку коротких заметок в канал. Но основной контент мы по-прежнему размещаем на сайте. План – от 4 статей в месяц. А вот там все гораздо сложнее. Даже такой простой обзор, как вчерашний требует куда больше времени, чем заметка. Прежде всего надо изучить что уже написали по этой теме, на что обратить внимание самому и вообще, есть ли смысл писать. Минимум от часа времени. Развернуть систему, проверить все интересующие аспекты, сделать скриншоты – где-то еще часа два. Потому что проверить и посмотреть надо многое, но не все из этого попадет в статью. План статьи – еще час, делается либо параллельно, либо по горячим следам. Потому что бес плана статью можно писать только с колес, уже на следующий день многое из того, что обратило на себя внимание забудется. По мере составления плана может оказаться что не хватает каких-то скриншотов или надо проверить некоторые иные моменты, возвращаемся в предыдущий пункт. Само написание обзора – час-полтора, затем вычитка, проверка орфографии, пунктуации, стилистики – еще полчаса. Что имеем в сухом остатке? По минимуму 5,5-6 часов. На обзор, который читается за 5-10 минут. В этом, собственно, и смысл подобных материалов – коротко, но емко дать общую информацию. Полотно на десять экранов вниз с сотней картинок просто никто не будет читать. Технические статьи занимают еще больше времени. Там тоже все начинается с этапа изучения уже написанного, тот же час. Затем изучается документация, еще час-два. Потом стенд и кропотливая запись каждого действия. Сделали? Разворачиваем стенд по новой и дословно воспроизводим записанное. Должны получить полное совпадение результата. В зависимости от сложности еще часа два -три. Если документация скупа или что-то не получается, то начинается поиск и отладка, тоже часы, но мы их считать не будем. Если результат нас устроил и показывает повторяемость, то составляем план статьи, готовим скриншоты, схемы и т.д., это еще один чистовой прогон. Еще два часа. Само написание текста, в зависимости от сложности оформления, еще несколько часов, от двух до четырех. Итог? Опять по минимуму 9-10 часов, на одну статью. Или около 40 часов в месяц. Итого в месяц получаем 80 часов работы с контентом, это две полноценных рабочих недели. Можно ли тащить такой объем на энтузиазме? Или донатах, которых за прошлый год набралось целых десять тысяч рублей? Совмещая это с основной работой, семьей, бытом? Занимаясь этим регулярно, через «лениво» и «не хочу»? Как минимум семья не поймет, а потом и сам сядешь и подумаешь: «А на фига оно мне надо? Может лучше в лес или на рыбалку?»

150 дней фитнеса в подарок в сети фитнес-клубов XFIT! Успейте воспользоваться акцией ✅ "150 дней фитнеса в подарок" в сети фитнес-клубов XFIT . Предложение действует в городах: - Москва и МО - Волгоград - Воронеж - Екатеринбург - Казань - Краснодар - Новосибирск - Пермь - Санкт-Петербург В клубах есть бассейны (в том числе с морской водой), банные комплексы, сайкл-студии, звездный тренерский состав, новое оборудование, групповые программы и всё, что нужно для эффективных тренировок и здоровья! Нажмите на кнопку ✅ "Получить предложение"⚡, чтобы найти ближайший клуб и получить "150 дней фитнеса в подарок" при покупке карты. Получить предложение #реклама О рекламодателе

Мониторинг - он такой разный Каждый администратор рано или поздно приходит к теме мониторинга. Но мониторинг - он бывает разный и нельзя сказать что какой-то хуже или лучше. Он, как и любой инструмент, рассчитан на свой круг задач, где-то узкий, где-то широкий. 📉 Начнем с совсем простых инструментов. Таких как Системный монитор в Windows или, например, nmon в Linux. Это приложения наподобие диспетчера задач, но немного круче - они позволяют произвольно сочетать и отслеживать в реальном времени нужные метрики и проводить причинно-следственные связи между ними. А также могут записать нужную информацию в файл. Они хороши когда нужно разобраться здесь и сейчас. Когда кто-то сильно грузит систему или потребляет много ресурсов. 🟢 Вторая категория - это локальный мониторинг отдельного узла, мы рассматривали одну из таких программ - Monitorix. Она уже постоянно запущена, как сервис и собирает заданные метрики на постоянной основе, а также умеет вовремя оповещать о происходящих событиях. Подключившись к ней можно оценить текущую загрузку узла, тенденции изменения показателей, их историю. Не требует сторонней инфраструктуры. Но минус всех этих программ в том, что если сервер с ними вдруг окажется недоступен, то вы так и не сможете узнать о том, что происходило перед этим, так как мониторинг будет недоступен вместе с сервером. 🛰 Отдельной строчкой стоят средства мониторинга сети, один из популярных - The Dude от Mikrotik. Можно ли при помощи Dude контролировать метрики узла? Кое что можно, но для этого есть другие инструменты, более для этого предназначенные. А так и саморезы можно молотком забивать, при великой и неотложной нужде. Эти программы в первую очередь нужны для того, чтобы быстро реагировать на происшествия в вашей сетевой инфраструктуре. Показывая доступность узлов и нагрузку каналов. Это тоже важно и нужно, но не заменяет другие средства. 🏆 Ну и наконец такие монстры уровня предприятия как Zabbix. Многие представляют его как пульт управления ядерным реактором. Где мигают лампочки, рисуются графики, постоянно меняются показатели. Многие даже начинают настраивать под себя визуализацию. Но на деле все гораздо скучнее и прозаичнее. Zabbix - это действительно ПО уровня предприятия. И куча графиков будет только мешать, отвлекая от важного. Ну и как показывает практика, смотрят на них всего пару раз. Сразу как сделал и когда решил показать другу. Zabbix, как и любой хороший мониторинг такого класса, вообще не должен привлекать к себе излишнего внимания. Его задача вовремя оповестить от том, что где-то там возникла проблема и с этим он отлично справляется. Когда в вашем подчинении оказывается пару десятков устройств, то уделить каждому внимание и просмотреть показатели становится практически невозможным (ну или надо забросить другие дела). Поэтому Zabbix работает по другому. Он молча собирает показатели и сообщает когда они выходят за пределы установленных значений. У опытных админов на панели Zabbix обычно всего два виджета: проблемы и история проблем. ☝️ При этом нельзя сказать, что какая-то одна из систем может закрыть на 100% все запросы. Системы мониторинга дополняют друг друга и нет ничего плохого в том, чтобы их комбинировать.

​​Мониторинг - он такой разный Каждый администратор рано или поздно приходит к теме мониторинга. Но мониторинг - он бывает разный и нельзя сказать что какой-то хуже или лучше. Он, как и любой инструмент, рассчитан на свой круг задач, где-то узкий, где-то широкий. 📉 Начнем с совсем простых инструментов. Таких как Системный монитор в Windows или, например, nmon в Linux. Это приложения наподобие диспетчера задач, но немного круче - они позволяют произвольно сочетать и отслеживать в реальном времени нужные метрики и проводить причинно-следственные связи между ними. А также могут записать нужную информацию в файл. Они хороши когда нужно разобраться здесь и сейчас. Когда кто-то сильно грузит систему или потребляет много ресурсов. 🟢 Вторая категория - это локальный мониторинг отдельного узла, мы рассматривали одну из таких программ - Monitorix. Она уже постоянно запущена, как сервис и собирает заданные метрики на постоянной основе, а также умеет вовремя оповещать о происходящих событиях. Подключившись к ней можно оценить текущую загрузку узла, тенденции изменения показателей, их историю. Не требует сторонней инфраструктуры. Но минус всех этих программ в том, что если сервер с ними вдруг окажется недоступен, то вы так и не сможете узнать о том, что происходило перед этим, так как мониторинг будет недоступен вместе с сервером. 🛰 Отдельной строчкой стоят средства мониторинга сети, один из популярных - The Dude от Mikrotik. Можно ли при помощи Dude контролировать метрики узла? Кое что можно, но для этого есть другие инструменты, более для этого предназначенные. А так и саморезы можно молотком забивать, при великой и неотложной нужде. Эти программы в первую очередь нужны для того, чтобы быстро реагировать на происшествия в вашей сетевой инфраструктуре. Показывая доступность узлов и нагрузку каналов. Это тоже важно и нужно, но не заменяет другие средства. 🏆 Ну и наконец такие монстры уровня предприятия как Zabbix. Многие представляют его как пульт управления ядерным реактором. Где мигают лампочки, рисуются графики, постоянно меняются показатели. Многие даже начинают настраивать под себя визуализацию. Но на деле все гораздо скучнее и прозаичнее. Zabbix - это действительно ПО уровня предприятия. И куча графиков будет только мешать, отвлекая от важного. Ну и как показывает практика, смотрят на них всего пару раз. Сразу как сделал и когда решил показать другу. Zabbix, как и любой хороший мониторинг такого класса, вообще не должен привлекать к себе излишнего внимания. Его задача вовремя оповестить от том, что где-то там возникла проблема и с этим он отлично справляется. Когда в вашем подчинении оказывается пару десятков устройств, то уделить каждому внимание и просмотреть показатели становится практически невозможным (ну или надо забросить другие дела). Поэтому Zabbix работает по другому. Он молча собирает показатели и сообщает когда они выходят за пределы установленных значений. У опытных админов на панели Zabbix обычно всего два виджета: проблемы и история проблем. ☝️ При этом нельзя сказать, что какая-то одна из систем может закрыть на 100% все запросы. Системы мониторинга дополняют друг друга и нет ничего плохого в том, чтобы их комбинировать.

Сочи, 2-ух комнатная, ремонт, вид на море, ипотека от 3% Мечтаете о квартире у моря, но цены и необходимость делать ремонт пугают💰? Да, выбор и ремонт требует времени и денег . Но не отказывайтесь от мечты! В ЖК Фестивальный готовые квартиры с ремонтом, скидкой до 20% и ипотекой от 3%😊. ✨ Из окон видно море, до которого всего 10 минут, на территории школа, сад, магазины и даже бассейн 👍! ✅ Оставь телефон чтобы узнать цену! Узнать цену Изучите все условия кредита (займа) на сайте в соответствующем разделе. Оценивайте свои финансовые возможности и риски. Финансовые услуги оказывает: ПАО Сбербанк. #реклама festivalniy.estatesochi.com О рекламодателе

Токсичность – наша национальная черта? Привычка? О токсичности русскоязычных IT-сообществ наслышаны многие, многие вживую столкнулись с этим явлением. Особенно в сообществах старых, устоявшихся. Хотя, справедливости ради, надо сказать, что появляются и новые типы сообществ, где подобное поведение пресекается, но это только исключение, подтверждающее правило. Есть у меня одна родственница, которая в свободное от основной работы время 3D дизайном, преимущественно в Blender. Делает всякий рекламный креатив, чем серьезно поддерживает семейный бюджет. И вот случилась у нее беда. Сгорел SSD в ноутбуке. Большинство она восстановила, что-то было продублировано, но осталась одна мелочь – 3D-объект воздушных шариков, он был простой, бесплатный, скачанный с сайта с бесплатными объектами. Но тот сайт приказал долго жить и больше нигде она такого объекта не нашла. Оно бы и фиг с ним, но на нем было завязано много готовых проектов и переделывать их сильно не хотелось, тем более что заказчики хотели именно такой же, только немного другой. Ну подалась она в одно из самых крупных отечественных сообществ на эту тему, где пожаловалась на свою беду и попросила помощи. Самым первым делом ей объяснили, что она дура. Ну это классика жанра, пропускаем мимо ушей. Дальше ей пояснили, что такое нарисовать самому – пять минут делов, а после посыпались услуги сделать тоже самое от 10 до 25 тыс. руб. Сказать, что она офигела, это ничего не сказать. Хотя эти самые шарики были в работах очень многих и проблемы поделиться ими как таковой не было. В общем решила она попытать счастья за бугром, благо была зарегистрирована на зарубежном крупном форуме по теме. Перевела свой вопрос переводчиком, извинилась за плохой английский и уже через полчаса получила первое сообщение. К ней обращался известный метр и заслуженный участник того форума. Он извинился, что у него нет готового пакета, но он посмотрел, где лежат файлы и закинул их в архив. Ей надо только разместить их точно также у себя. После чего он добавил, чтобы она обязательно отписалась и если не поможет, они будут вместе думать дальше. Потом появились сообщения еще от нескольких участников, которые сбросили ей недостающее. Но ей помог самый первый архив, о чем она сообщила и всех отблагодарила. На что ей пожелали успехов и попросили не теряться, заходить и общаться, невзирая на языковые сложности. Когда она вернулась на наш форум, то обнаружила в своей теме срач на пяток страниц, ну написала, как ей помогли там. В итоге срач разросся до совсем неприличных размеров. Тот форум она больше не посещает. Смысла нет. Равно как нет смысла читать его. Практического толка там ноль, зато срач и флуд бьют фонтаном. Я думаю, что читателям все это знакомо. Но возникает вопрос, что является причиной тому? Тяжелое наследие СССР, 90-х, царской России (нужное подчеркнуть), менталитет, национальные особенности? Хотя я могу привести пример современных комьюнити, лишенных этого недостатка. Иногда можно даже сравнить, скажем в мире 1С есть Инфостарт и Миста. И если первый является вполне современным и дружелюбным, но последняя как деревенский клуб ближе к полуночи. И самое интересное, что и там и там могут общаться одни и те же люди, но в радикально различном амплуа. Тут мы приличные и благообразные специалисты, там – разнузданные тролли. На мой взгляд люди везде одинаковые, но там интернет появился несколько раньше, чем у нас и там более прагматичный подход к монетизации ресурсов. Это у нас почему-то монетизация считается чем-то порицаемым. Там – просто бизнес. Тролли и токсичность монетизации мешают, поэтому от них надо избавляться. У нас же часто сообщества играют роль некоторых закрытых клубов «причастных» и начинают оказывать влияние на владельцев по принципу «хвост виляет собакой». Поэтому давайте прививать вокруг здоровое, взаимоуважительное общение. А лучший критерий – это готовы ли вы сказать другому в лицо все то, что только что написали?

Непонятно одно, зачем это? Прочитал сегодня новости о выпуске первой версии MiDesktop -форка KDE версии 1, адаптированного для современных систем Linux. Ну, в старых системах и интерфейсах есть своя прелесть, равно как остаются любители классики. Поэтому задача в целом интересная… Ровно до того, как мы начали изучать подробности. А там очень интересно все: в проекте использован тулкит Osiris, который является форком Qt 2 для решения лицензионных проблем и ограничений ветки Qt 1. Серьезно? Qt2 в 2026 году? С разрешениями от FHD и выше? Требованиями к экранам, сглаживанию и т.д. и т.п. Оказывается серьезно и вообще они бы Qt1 использовали, если бы не лицензионные ограничения. После чего возникает закономерный вопрос – а зачем и для чего это все? Зачем возрождать KDE 1 в его первозданном виде? Ведь поезд давно уехал, технологии шагнули вперед и то, что было в свое время актуально, сегодня устарело морально и физически. Нравятся заложенные в KDE 1 идеи и принципы? Ну так развивайте их, адаптировав к современным технологиям. И примеры тому есть. Например, Trinity Desktop Environment (TDE) – который развивает основные идеи KDE 3.5, посмотреть на него можно в операционной системе Q4OS на базе Debian. У нас установлена не самая свежая версия, но уже и по ней ясно, что зацикливаться на старых «кедах» один к одному никто не стал. Да, взяли основное и переделали на современный лад, переписав весь код на Qt5. Есть среда Mate, которая взялась развивать старый добрый GNOME2, но и там от основоположника остались только основные идеи, а так это вполне современная система. Даже экзотическая Haiku, повторяя визуально оригинальный стиль BeOS использует современные фреймворки и предоставляет вполне актуальное качество картинки, пригодное для работы с HiDPI. Да, не везде все гладко, есть свои проблемы, но все эти системы нацелены не на воскрешение старой среды в неизменном виде, а развитии ее основных идей на современных рельсах. Поэтому MiDesktop в текущем виде – проект мертворожденный. Потому что KDE 1 в 2026 году в своем оригинальном виде никому не нужна. Нравятся какие-то идеи или концепция внешнего вида? Так выделите их, сформулируйте и развивайте на современном технологическом уровне.

Подарите своей кукушечке трип ...куда-нибудь на Восток, к пальмам и золотому песку, а не вот это всё. Тем более что Яндекс Путешествия дарят промик со скидкой 5 000 ₽ на отели по промокоду BLIZKO5000. Забронировать #реклама special.travel.yandex.ru О рекламодателе

Распределенные системы или история одного блекаута Последнее время все большую популярность получают удаленные или облачные решения, когда на рабочем месте устанавливается тонкий клиент, а все остальные вычисления и данные расположены где-то там. В удаленном офисе, в облаке, неважно, где, главное, что не здесь локально. И на все возражения, что это ненадежно обычно есть ответ – ой, да у нас тут интернет хороший, второй канал есть, бесперебойники, стабилизаторы, ну что тут может пойти не так? Однако критерием истины является практика. А также сильное влияние имеет ряд совсем нетехнических вопросов. Когда все хорошо ими особо никто не задается. А когда становится не очень хорошо, то всплывает классическое: кто виноват и что делать? Бизнес – это про зарабатывать деньги и больше не про что иное. Это может быть не очень приятно осознавать, но именно бизнес платит нам зарплату. Не будет денег у бизнеса – не будет денег у нас. Простой – это плохо, особенно если у вас скоропортящийся товар и убыток тут складывается вполне реальный, в настоящих рублях, а не в некоторой «упущенной прибыли». А еще хуже, когда у вас простой, а конкуренты худо-бедно, но работают. И неважно кто и когда принимал определенные решения, обязательно будет разбор полетов и поиск крайнего. Вчера у нас в городе приключится блекаут. Самый настоящий, пропало электроснабжение, отопление, водоснабжение, связь, интернет. Не везде набор был полным, но практически везде выбило комбо. Худо-бедно электроснабжение и связь стали появляться только во второй половине дня, а нормализовалась ситуация только к ночи. Понятно, что это форс-мажор, но даже при форс-мажоре бизнес должен работать и даже не в погоне за длинным рублем, а для того, чтобы человек мог где-то недалеко от дома купить воды, молока, хлеба, спички и батарейки. И тем, кто сделал ставку на облака или удаленку было вчера плохо, очень плохо. И если облака еще худо-бедно поднимались по мере появления интернета, то с удаленными серверами, расположенными в пределах города, была вообще беда. Те же, кто использовал распределенные системы, несмотря на более сложную поддержку и обслуживание таковых, пережили блекаут более-менее нормально. Запустили генератор и уже как-то торгуем, пусть даже только за наличные. Стала появляться связь? Можем начать принимать карты. Появилась связь с офисом – хорошо, нет – и так проживем. Также сильно помогла децентрализация вспомогательных служб: сервера удаленного администрирования, синхронизации, VPN и т.д. Причем не обязательно использовать для этого публичные сервисы, достаточно купить VPS, это не дорого, но в разы повышает надежность, нежели если бы это все было сосредоточено в центральном офисе. Появился интернет? Уже есть сетевая связность, возможность получить поддержку, передать или получить документы и т.д. и т.п. Пропал? Ну пропал он на одной точке, остальные худо-бедно работают, а тот же администратор или управляющий при необходимости может выехать туда, где связь есть и продолжить работу оттуда. Так вчера дежурная поддержка и менеджеры спокойно набились в подсобку одного из магазинов, где было электричество и связь и спокойно половину дня работали оттуда. Также были сделаны правильные выводы насчет ИБП – это не средство резервного питания. Это защита от кратковременных перебоев в энергоснабжении. В случае аварии все что вам нужно – это корректно выключить оборудование. Поэтому в подобных условиях настраивайте управляющий софт тушить сервера сразу, не дожидаясь разряда батарей. А сами сервера лучше включать по WoL самостоятельно, либо не раньше, чем через 15-20 минут после устойчивого появления энергоснабжения. Ну и напоследок можем сказать, что подобные блекауты – это, конечно, форс-мажор. Но вот блекауты и аварии локального масштаба с сопоставимыми последствиями вполне вероятны, начиная от стихийных бедствий, заканчивая тем, что тракторист дядя Вася перекопал подвод электричества или связи к зданию.

Где я окажусь в конце 2026? Нет лучшего момента помечтать о будущем, чем перед праздниками. Команда Selectel подумала ровно так же и выделила целый новогодний сервер для твоих планов на будущий год ✨ На сайте можно отправить письмо себе в будущее: записать самые смелые и амбициозные мечты на 2026-й. Ровно на год послание сохранится на сервере, а потом ты получишь его обратно на почту — будет возможность сравнить желаемое с действительным. Прыгнуть с парашютом, наконец разгрести бэклог или стать лидом? Отправляй хотелки на Новогодний сервер — это весело и секьюрно. Попробовать #реклама 16+ careers.selectel.ru О рекламодателе

Слишком много изменений… Новый год – новые изменения, но иногда их бывает слишком много. Так и в этом году. Многочисленные изменения законодательства затронули практически всех и заставили обновлять все что нужно и не нужно. Возьмем для примера торговую фирму, так как тут данная проблема встает в полный рост. Нужно обновить… Ох, много чего обновить нужно… И когда это все? Чтобы не быть голословными, скажем, что обновить обычно нужно: платформу 1С:Предприятие, прикладное решение 1С:Предприятие, драйвера торгового оборудования, прошивки торгового оборудования. Если у вас сеть, то эти обновления еще надо разогнать по сети. В общем – дел хватает. И все это, как обычно, надо было еще позавчера. И самой большой ошибкой будет долго готовиться и разом обновиться. Сразу по всем направлениям. При этом вы можете сколько угодно гонять изменения в тестовом контуре, но после их раскатки в продакшен неизбежно начнут вылазить проблемы. А дальше начинается паника, точнее ПАНИКА, потому что все недовольны, все жалуются и абсолютно непонятно куда бежать и за что хвататься. В общем, даже если вы героически победите все эти проблемы, то никакой благодарности не заслужите, потому что все будут уверенны, что это IT уронил прод всеми этими обновлениями. И как быть? Просто. Слона нужно есть по частям, равно как и внедрять изменения. Да, это будет не так быстро, не так эффективно, но более-менее мягко и безболезненно для продакшена, ну точно уже без авралов и панических настроений. Что бывает, когда мы накатываем сразу несколько изменений и получаем после этого проблемы? А бывает то, что мы не знаем, какое именно изменение эти проблемы вызвало и вынуждены отрабатывать массу вариантов. А предприятие все это время работает через пень-колоду. Кто будет крайним? А тот, кто это все затеял и затеял именно в такой форме. Поэтому никогда не надо так делать. Разбивайте внесение изменений на этапы. Сегодня изменили то, завтра получили обратную связь, убедились, что все работает как надо. Тогда после завтра можно обновить что-то еще. И снова все проверить. Это не исключает проблем, но в случае их возникновения вы уже точно будете знать, с чем они связаны и куда смотреть, кому писать. Ну и не забывайте про моратории. Перед теми же выходными. И вопрос тут даже не в том, что отдохнуть хотите вы. Отдохнуть хотят все и есть очень большой риск, что все проблемы пятницы сотрудники просто заметут под ковер и выкатят вам утром понедельника. Которое окажется очень недобрым. Поэтому реальный план – это работаем с понедельника по четверг с обязательным тестированием в реальной эксплуатации каждого этапа изменений. И только после получения положительных отзывов от эксплуатантов переходим к следующему этапу. Но сроки, скажет иной читатель. Как быть, если требуют. А просто, достаточно документировать все обращения и формализировать этапы тестирования. Т.е. если вы сегодня выкатили изменений, то по окончании рабочего дня эксплуатанты должны подтвердить наличие или отсутствие проблем. К нему прилагаем список выявленных проблем и решений. После чего становится видно, что вы не баклуши били, а весьма напряженно работали в тесной смычке с теми, кто систему эксплуатирует. Ну это давно известно, чем больше бумаг, тем чище пятая точка. Поэтому не забывайте об этой стороне вопроса, которая иногда может оказаться важнее технической. Просто потому, что эти ваши технические тонкости никому кроме вас не понятны, а язык бюрократии понятен всем управленцам и руководителям.

Хочешь меньше работать руками и больше головой — забирай 15 бесплатных инструментов автоматизации, которые реально экономят время. Я собрал чек-лист в формате «Мне нужно… → чем пользоваться»: У каждого инструмента: что умеет бесплатно, под какие задачи, кому подходит и где он заменяет живого сотрудника, а где просто выжигает рутину. Чтобы забрать чек-лист — подпишись на мой канал. Тем, кто это сделает, дополнительно скину аудиокнигу «Как ИИ меняет нашу жизнь и работу». Telegram: https://t.me/ciologia?erid=2W5zFKAGUPJ

​​Где смотреть «логи» в Windows Казалось бы, странный вопрос – все знают оснастку Просмотр событий и Журналы Windows в ней. Только вот часто этот журнал не спешит радовать нас подробностями происходящего в системе и часто дело на этом и заканчивается. Отсюда и пошло расхожее мнение, что с журналированием в Windows не очень, не то, что в Linux, где бери нужный лог и читай. Однако стоит спуститься в оснастке чуть ниже и раскрыть дерево Журналы приложений и служб, как сразу станет ясно, что это не так. Именно здесь можно найти подробные журналы для каждой системной службы и приложения, также сюда могут писать и сторонние приложения, что прекрасно видно на скриншоте. И именно этой частью журнала мы пользовались, чтобы разобраться с проблемами Samba в статье: https://interface31.ru/tech_it/2023/05/ispravlyaem-oshibku-podklyucheniya-windows-k-obshhim-resursam-na-servere-samba-linux.html Но это еще не все, оснастка Просмотр событий позволяет нам использовать настраиваемые представления, т.е. создавать собственные журналы на основе других журналов или источников событий, так же мы можем гибко фильтровать события, попадающие в этот журнал. Этим пользуются далеко не все, но именно настраиваемые представления позволяют легко и удобно проводить диагностику, собирая все необходимые события в одном месте. 🤔 А вы пользуетесь расширенными возможностями оснастки Просмотр событий?

Утильсбор вырос. Что делать? Рассказываем Авто свыше 160 л.с. подорожали. Но есть решение! 5+ лет возим машины из Японии, Кореи, Китая. В канале — актуальные новости и лайфхаки. Подписывайся! Подписаться #реклама О рекламодателе

Открытые системы В нашей заметке о HP-UX мы говорили о проприетарных коммерческих системах и о том, что они не выдержали конкуренции с открытой архитектурой. Но открытая – это не значит свободная и тем более бесплатная. Снова окунемся в историю. На рынке ПК и особенно серверов в 80-х бал правили коммерческие решения, в которых производитель предоставлял полностью закрытый программно-аппаратный комплекс. Он включал собственное железо, собственное ПО, собственную периферию и был минимально совместим с чем либо, даже иными линейками того же производителя. Системы были закрытыми, и никто другой не мог начать производить что-то подобное или хотя-бы минимально совместимое. Что касается ПО, то на этом рынке безраздельно царствовал UNIX, но говорить о какой-то единой системе также не приходилось, каждый производитель развивал систему так, как считал нужным и общего у них был только общий прародитель и общая философия и архитектура. Это серьезно ограничивало возможности клиентов, так как фактически не предоставляло им выбора, заставляя полностью замкнуться на решения одного вендора. И вот в начале 80-х на рынке появилось то, что на момент своего появления не имело, с точки зрения гигантов рынка, настоящего, не говоря уже о будущем. И это был IBM PC. IBM не рассматривало PC как серьезный бизнес, но в тоже время хотела обозначить свое присутствие на рынке персональных ПК. Поэтому она дала команде разработчиков большую самостоятельность в принятии решений и поставила крайне сжатые сроки. И тогда руководитель проекта Дон Эстридж принял решение о том, что IBM PC должен иметь открытую архитектуру, это позволило использовать уже существующие на рынке решения и быстро обеспечить поддержку нового ПК всем необходимым, особенно периферией. Впоследствии IBM сильно пожалеет об этом решении, но это будет потом. Первый IBM PC был представлен публике в 1981 году, и компания ставила план реализовать 250 тыс. таких машин в течении 5 лет, но скоро стала продавать такое же количество ПК ежемесячно. Вместе с этим IBM получила огромное количество клонов, так как никто не мешал другим производителям купить процессор от Intel, систему от Microsoft и выпустить на рынок полностью совместимый ПК. Со временем рынок отказался от термина IBM PC ,и платформа сначала стала просто PC, а затем x86 и, позже, x86-64. Первой заявкой на использование платформы в серверных целях стала Novell, которая еще в начале 80-х отказалась от выпуска собственного оборудования и сосредоточилась на ОС. Теперь, чтобы управлять собственной сетью вам нужно было купить обычный x86 компьютер и поставить на него ОС от Novell. Второй звоночек прозвенел в середине 90-х с выходом Windows NT 3.5, а затем и Windows NT 4.0 Terminal Server, который позволил закрыть потребности в серверных функциях для малого бизнеса без существенных вложений в инфраструктуру. Теперь сервером мог быть обычный ПК, пусть немного более мощный и дорогой – но самый обычный, все что требовалось – купить серверную ОС от Microsoft или Novell, либо поставить бесплатные BSD или Linux. Тут еще и Intel подсуетился, выпустив в конце 90-х серверную платформу на базе Xeon. Окончательно как серверная платформа x86 заявила о себе в нулевых, особенно на фоне неудачи архитектуры Itanium. Теперь даже средние и крупные игроки рынка предпочитали не связывать себе руки дорогими проприетарными системами, а купить обычный x86-64 и поставить туда обычный Linux или BSD. Тогда же началось активное развитие коммерческих Linux-систем, того же RHEL, которую в конце концов приобретет IBM. С тех пор начался быстрый закат проприетарных закрытых систем в пользу открытых архитектур, который мы видим до сих пор. На рынке оборудования между собой конкурируют открытые x86-64 и ARM, появился перспективный открытый игрок RISC-V. На рынке ОС значимое место занимает открытая платформа Linux и открытые стандарты на многие форматы файлов и алгоритмы обработки. Что касается периферии, то также канули в лету нестандартные разъемы и протоколы, практически везде для подключения используется USB, а устройство определяется как стандартно