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

🚀 26 лет — и уже тимлид в ИТ. Как это возможно? Многие думают, что до хорошей зарплаты в разработке нужно идти десятилетиями. Но путь может быть быстрее, если с первых лет учёбы получать опыт, делать проекты и работать с реальными задачами. Как выглядит грамотный карьерный трек в ИТ — разобрали в МАП 👇 🔗 Читать #реклама О рекламодателе

02:17. Pager разрывается. Продакшн падает. А вы — дежурный SRE. Успеете среагировать за 15 минут? Мы сделали интерактивный симулятор реального инцидента: API отвечает 500-й ошибкой, задержка растёт, разработчики спят, а бизнес уже требует ответов. Вам предстоит принять 5 решений — ровно так, как это делают дежурные инженеры в проде: ⏩ что проверить первым ⏩ какую метрику считать критичной ⏩ когда объявлять инцидент ⏩ что написать пользователям ⏩ что делать после того, как всё починили ❗️Никакой теории — только реальная ситуация и разбор каждого шага сразу после ответа. В конце узнаете, насколько ваш подход похож на мышление настоящего SRE, и получите список навыков, которые стоит прокачать. Проверьте, спасли бы вы продакшн⬇️ ЗАБРАТЬ СИМУЛЯТОР

Какие признаки выхода из строя можно увидеть в SMART NVMe-диска   NVMe-диски имеют совершенно иной, собственный SMART, разработанный для твердотельных накопителей, а не унаследованный от жестких дисков и содержит достаточно простые и понятные показатели, а также отдельный параметр Critical Warning для отображения критических состояний.   Но, как это чаще всего бывает, диск умирает, когда ничто не предвещает беды. Вроде и SMART отличный, а диск все равно умер. Ситуация знакомая еще по жестким дискам и сразу скажем, что SMART – это не панацея, но есть определенные параметры, изменение которых может указывать на проблемы с диском.   Начнем со следующей  пары:   🔹 Media and Data Integrity Errors - ошибки целостности данных и носителя – данный счетчик фиксирует случаи, когда информация из ячейки не смогла быть прочитана и восстановлена при помощи механизмов коррекции. Указывает на ошибки и износ памяти.    🔹 Error Information Log Entries - записи в журнале ошибок – это другой тип ошибок, происходящих на уровне общения диска с внешним миром, могут указывать на кривые драйвера, плохой разъем, перегрев и ошибки контроллера и не обязательно означают неисправность самого диска.   Поэтому если у вас начал расти первый показатель – это повод серьезно напрячься и задуматься о дальнейшем здоровье диска. Если растет второй – то прежде всего изучите внешние условия и режимы эксплуатации, скорее всего проблема не в самом диске, а в окружающей инфраструктуре.   Также крайне полезно контролировать еще один параметр:   🔹 Available Spare -  количество запасных ячеек, в норме это значение равно 100%.   Есть еще один связанный параметр - Available Spare Threshold – который показывает при снижении запасных ячеек до какого количества диск выбросит критическую ошибку, разные производители устанавливают разные значения: от 1% до 10%.   Если же у нас вместе с ростом Media and Data Integrity Errors наблюдается падение Available Spare – то можно говорить о том, что диск посыпался и его следует заменить. Не ждите появления критической ошибки, если процесс пошел, то в какой-то момент он может начать развиваться лавинообразно и до предупреждения диск может не дожить.   В ответственных системах следует поставить эти два показателя на мониторинг.

Если при слове «облако» вы думаете не о небе, а об инфраструктуре и сетях — вам понравится канал «Кучевые АйТи». Здесь команда компании «Облакотека» пишет о развитии облачных технологий и о том, как превратить инфраструктурный хаос в удобные виртуальные решения для бизнеса. Читайте в канале: 🔹Apple Hills Digital подсчитали: каждая четвертая российская компания уже использует или пилотирует ИИ в облаке, и еще 18% планируют начать в ближайший год. Читать в канале 🔹ИТ-льготы взлетели до облаков в прямом смысле. Все преференции для ИТ сохранятся в том же виде, но теперь освобождение от НДС распространится и на облачный софт. Читать в канале 🔹Перед запуском нового сервиса кажется, что самая сложная часть уже позади. Но как бы не так. Рассказываем, что Product Owner должен рассказать поддержке до релиза. Читать в канале Подписаться: @oblakoteka

Как быстро настроить в Ubuntu переключение раскладки по Alt+Shift?   А действительно, что сложного, зашел в настройки и поменял. Но не тут-то было, стандартная утилита настройки упорно хочет сочетание из трех клавиш, что совсем не соответствует желаемому. Поэтому двинемся другим путем, можно установить утилиту GNOME Tweaks sudo apt install gnome-tweaks   И затем, открыв приложение Дополнительные настройки перейти к Клавиатура и мышь → Дополнительные варианты раскладки → Переключение на другую раскладку и выбрать там желаемое сочетание. Но можно сделать еще проще, открываем терминал и вводим заклинание:   gsettings set org.gnome.desktop.input-sources xkb-options "['grp:alt_shift_toggle']"   Проверить текущие настойки можно следующим образом:   gsettings get org.gnome.desktop.input-sources xkb-options   Для вступления настроек в силу, неважно каким образом вы их сделали потребуется выйти из сеанса и зайти заново. При этом старая раскладка для переключения сохраняется, можно использовать обе.

Издательский дом «Новые отраслевые медиа» собрал для вас лучшие каналы из сферы искусственного интеллекта и интернет-технологий, которые помогают своим подписчикам быть в курсе всех важных профессиональных новостей. Здесь - всё про ключевых игроков отрасли, государственное регулирование, инсайды и кейсы от отраслевых лидеров. ✅Серверная - канал об индустрии дата-центров: технологиях, инфраструктуре, облачных решениях, энергоэффективности и применении ЦОД в ключевых отраслях экономики. ✅Робосфера - канал об индустрии робототехники: технологии и тренды. Промышленные и сервисные роботы, коботы, автоматизация, ИИ, машинное зрение, автономные системы. ✅AI для бизнеса - всё об AI-решениях для бизнеса: внедрение, автоматизация, корпоративный ИИ, агенты. ✅ТехноРитейл - канал о производстве и продаже бытовой техники и электроники в России: бренды, e-com, маркетинг, retail tech. Подписывайтесь, и эти каналы смогут изменить вашу жизнь к лучшему! Реклама. Харламов А.Е. ИНН 712803816807. erid: 2W5zFGoVNG9

Надо еще больше золота! Яндекс, пользуясь практически монопольным положением продолжает закручивать гайки. И, как это водится последнее время, ждем аналогичных инициатив от Майл.ру. P.S. А куда ты с подводной лодки денешься...

Пока всё работает, о хорошей инженерной работе обычно не говорят. Но от нее зависит, насколько устойчивыми остаются критические ИТ-системы, как быстро бизнес восстанавливается после сбоев и насколько надежно защищена инфраструктура. Именно поэтому в рамках IT Elements 2026 пройдет первая профессиональная премия «Инженерное искусство». 💙 Она посвящена людям, которые каждый день создают, защищают и развивают корпоративное ИТ. Если вам есть чем гордиться или вы знаете проект, который действительно заслуживает профессионального признания, расскажите о нем профессиональному сообществу. ✨ Возможно, именно ваша инженерная история станет ориентиром для коллег по отрасли. 📌 Прием заявок уже открыт.

Обновляем Proxmox Mail Gateway с версии 8 до 9 Proxmox Mail Gateway - специализированное решение почтового шлюза для фильтрации входящих и исходящих потоков почты эффективно защищающее от спама и вредоносных вложений. Продукт бесплатный и простой в развертывании, при этом способный закрыть потребности как малого бизнеса, так и крупных предприятий. Сегодня мы расскажем как обновить его до последней версии, материал основан на официальной документации и дополнен собственным опытом. ✅ Читать далее: https://interface31.ru/post/obnovlyaem-proxmox-mail-gateway-s-versii-8-do-9/

Возможно, ваша команда платит за слишком много сервисов... Pabit объединяет всё необходимое для работы над проектами в одном месте — от задач и файлов до звонков, документации и аналитики. Вдруг часть ваших подписок действительно больше не понадобится 😏 Попробуйте бесплатно тут https://tglink.io/74686119f164a3?erid=2W5zFHRZHQD А промокод RMGRM8NEE8 даст вам скидку в 10% на платных тарифах Реклама. Бардин П.А. ИНН 772622793401.

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

apt policy 

В ее выводе нас прежде всего будет интересовать опция «источник (origin)», которая выводится после ключа o=. Теперь мы можем получить полный список пакетов из этого репозитория командой:

apt list ~Onginx

В данном случае указываем наименование источника сразу после ключа ~O, без пробела. Обратите внимание, что данная команда выводит все пакеты, содержащиеся в репозитории, установленные пакеты при этом помечены отдельно как [установлен]. Если репозиторий небольшой, то этого достаточно. Вы можете быстро понять, что из него уже установлено, что вы можете установить и нужно ли это вам вообще в текущий момент времени. В противном случае нужно будет добавить дополнительные отборы, например, добавим фильтр по только установленным пакетам:

apt list ?and\(~i\,~Oprox\)

Здесь мы соединили через логическое И два условия: пакет установлен ~i и пакет принадлежит определенному источнику ~O, также не забывайте использовать обратный слеш для экранирования служебных символов. Также обратите внимание, что имя источника не обязательно указывать полностью, так как это регулярное выражение. Так для репозитория o=Proxmox мы использовали просто ~Oprox. Но здесь нас может поджидать несколько иная сложность, среди установленных пактов нам могут попасться пакеты со статусом [установлен, автоматически] и их может быть много, очень много. Статус [установлен, автоматически] обозначает что мы не выбирали этот пакет для установки, и он был получен автоматически, по зависимостям. Для больших репозиториев таких пакетов может оказаться сильно много, и они серьезно ухудшают восприятие. Поэтом добавим еще одно условие:

apt list ?and\(~i\,\!~M\,~Oprox\)

Где параметр !~M обозначает «кроме установленных автоматически». Теперь вывод команды покажет только пакеты, которые были установлены вручную из указанного репозитория. Данные конструкции можно использовать не только с командой apt list, но и с любыми другими командами apt, например для установки или удаления пакетов. А больше информации вы можете получить при помощи:

man apt-patterns

Или обратившись к подобной информации в сети интернет.

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

За одного битого двух небитых дают. Часть 2 Проблемы стали расти как снежный ком. Они больше не купировались на нижнем уровне, а летели прямиком к руководству. С программой тоже начался ад. Не секрет, что УТ 11 — конфигурация весьма специфическая. После древней, но понятной ТиС 9.7, которая стояла там раньше, глухое недовольство пользователей было абсолютно ожидаемым.   Контора бурно росла, появлялись новые люди. Меня они видели впервые, поэтому быстро предложили руководству: «А давайте позовём независимый аудит?»   В качестве «независимого светила» нашелся ведущий преподаватель местного учебного центра «1С», обвешанный сертификатами по самое не балуйся.   На встрече он разнес меня в пух и прах: «Всё написано не по методикам! Конфигурацию тупо изуродовали! Для чего это сделано? Зачем?» А я сидел, обтекая, и мотивированно ответить мне было нечем…   К счастью, собственники бизнеса оказались парнями хоть и простыми, но далеко не глупыми. Они предложили проверить теорию практикой: «Берем два компьютера. На один ставим "изуродованную" программу автора, на второй — чистую, но настроенную по методике эксперта».   «Светило» с темы технично съехало — мол, не барское это дело. В итоге оба стенда я собирал сам. Результат оказался предсказуем. Вердикт вынесли в мою пользу: «Косяки у автора есть, не без этого. Но в штатной "коробочной" версии вообще финиш — мы там соберем очереди как в мавзолей, а то, что сейчас делается за день, будет занимать неделю».   Когда мы вышли покурить с Сашей, я не выдержал и упрекнул его: «Чего ты сидел и молчал, пока меня ссаной тряпкой по морде возили? Обидно вообще-то. Столько впахивал, делал как для себя!»   И тут Саша выдал абсолютно резонную вещь, которая перевернула мое понимание ИТ-архитектуры. Он сказал, что не молчал, а слушал. А то, что я делал «как для себя» и не ставил их в известность — это огромная ошибка.   «Во-первых, мы понятия не имели, что в программе было изначально, а что добавил ты. Во-вторых, ты не владелец бизнеса и смотришь со своей колокольни. Максимум, что ты можешь потерять  — это сумму в месяц. Все остальные издержки лягут на меня. Ты же не будешь кормить моих детей и платить зарплату моим сотрудникам?»   Мне нечего было возразить.   С тех пор правила игры жестко изменились. Теперь все идеи, проблемы и доработки идут строго через верх, санкционируются руководством и только потом спускаются вниз. Такой подход позволяет директорам четко видеть: окупаются ли доработки и использует ли их персонал.   И теперь на классическое нытье линейщиков: «А тут у нас… Это… Того… Не работает!» — у руководства сразу готов ответ: «Вам под эту задачу неделю назад кнопку вывели и инструкции на почту скинули. Почему не пользуемся?»   Это гораздо лучше ситуации, когда сотрудники бегут жаловаться начальству, а руководство косо смотрит на админа, который «изуродовал» систему.   Но самый главный мой косяк был в другом: я вовремя не донес до руководства истинное положение дел на низах. Пока я героически тушил пожары в одиночку, у боссов была иллюзия, что проблем нет — ни с людьми, ни с процессами, ни с софтом. А когда при масштабировании всё это разом выплеснулось наружу, на меня вылили ушат холодной воды, и оправдываться пришлось мне.   Как дела обстоят сейчас:   1️⃣ Тотальный учет: Каждое обращение тщательно фиксируется, систематизируется и раз в месяц ложится на стол собственникам с моими выводами.   2️⃣ Платная поддержка: Все заявки теперь оплачиваются отдельно, и я не боюсь обсуждать их с бизнесом.   3️⃣ Разделение логики: Там, где виной человеческий фактор, руководство включает материальную мотивацию (штрафы/премии). Там, где можно помочь технически — я пилю доработки.   👆 Главный урок, который я вынес: всё, что вы делаете для бизнеса (неважно, на фрилансе или в штате), должно учитываться, документироваться и согласовываться наверху. У руководства должна быть полная картина. Иначе однажды бизнесу откроется весь пласт накопившихся проблем, а крайним сделают вас — просто потому, что вы замкнули всё на себя и вовремя никого не предупредили.

И вы знаете Поэтому просто ещё раз обозначим, что промокод NETSIL скинет 5000 рублей при бронировании жилья на Яндекс Путешествиях. Забронировать #реклама travel.yandex.ru О рекламодателе

За одного битого двух небитых дают. Часть 1 Эту заметку прислал мой коллега с Урала и попросил опубликовать анонимно. История в сотню крат отражает классические грабли во взаимоотношениях ИТ и бизнеса. На мой взгляд — максимально поучительно. Далее повествование от первого лица. Имена и места действия изменены. В то время я был относительно молод, тридцать с небольшим. Работал на заводе системным администратором. Зарплата — не фонтан, зато стабильная, да и работой особо не заваливали. Плюс стандартные плюшки: соцпакет, предсказуемый отпуск и спокойствие. Жена как раз ушла в декрет, поэтому «синица в руках» была всяко лучше журавля, хоть временами и приходилось туго затягивать пояса. Как-то вечером в своем районе я встретил одноклассника Сашу. Друзьями мы никогда не были, но несколько лет просидели за одной партой. Саша звезд с неба не хватал: занимался стройкой и ремонтом, а к моменту встречи открыл с компаньонами бизнес. У них было несколько строительных магазинчиков формата «все у дома» под управлением Саши и крупная торговая база за городом, которой рулили его партнеры. Саша предложил подработку: автоматизировать магазины и настроить там нормальный учет. В свободное от завода время я как раз баловался программированием на «1С» — брал заказы на фрилансе, да и на основной работе по мелочи писал отчеты и обработки. Понеслась. Задач подвалило много, и все интересные. Платил Саша исправно, и вскоре этот проект начал приносить мне вторую полноценную зарплату. Жить стало веселей. Но именно тогда я допустил ряд серьезных тактических ошибок, которые жестко аукнулись мне в будущем: 1️⃣ Ошибка первая: Работа «как для себя». Я глубоко вникал в процессы и дорабатывал систему под нужды линейных сотрудников, чтобы сделать их работу проще и быстрее. Но делал это молча: никак не фиксировал, не афишировал, да никто с меня отчетов и не требовал. Всех все устраивало, деньги платились. 2️⃣ Ошибка вторая: Отсутствие учета задач. Никакой работы с обращениями не было. Проблемы решались по звонку или через удаленку в режиме «потушить пожар». Я просто брал фиксированную абонентскую плату в месяц с каждой торговой точки. А потом от розничных магазинов я плавно перешел к автоматизации той самой загородной базы компаньонов. Это совпало со строительным бумом в регионе — бизнес начал бурно расти. Задачи стали масштабнее, количество моих подопечных увеличилось раза в три. И вот тут начались настоящие проблемы. То, что идеально работало на маленькой сети, где все знали друг друга по именам, при масштабировании мгновенно сломалось.   Продолжение истории вечером…

Получи грант до 1,35 млн руб. на обучение в магистратуре Хочешь развиваться в сфере ИТ и получить фундаментальные знания с практикой? Поступай в магистратуру Центрального университета! — 4 офлайн программы по востребованным направлениям ИТ — 2 онлайн-программы: машинное обучение и продуктовый менеджмент — 550 грантов до 75% — Вечерние занятия и учеба по выходным — удобно совмещать с работой — Обучение по модели STEM-образования: на стыке науки, технологий и бизнеса — Возможность стажировок и трудоустройства в ведущих компаниях — Государственный диплом за 2 года Магистратура в Центральном университете — это современный подход к образованию, сильный преподавательский состав и актуальные кейсы от индустрии. Оставляй заявку на грант уже сейчас! Зарегистрироваться #реклама 16+ cu.ru О рекламодателе

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