Please open Telegram to view this post
VIEW IN TELEGRAM
🤔37👍4🫡4❤1
Forwarded from godnoTECH - Новости IT
Официальный домен минобрнауки.рф, ранее принадлежавший Министерству просвещения РФ, теперь перенаправляет пользователей на сайт онлайн-казино. Всё из-за того, что министерство вовремя не продлило регистрацию.
Домен был зарезервирован для госнужд ещё в 2010 году, но после 2 марта 2023 года стал «ничейным». Уже 4 апреля его выкупило частное лицо и настроило редирект на азартный ресурс. Онлайн-казино, к слову, запрещены в России, и такие сайты подлежат блокировке.
Координационный центр доменов .RU/.РФ объяснил, что с 2019 года ответственность за продление доменов полностью лежит на самих госорганах. Чтобы избежать таких историй, планируют ввести отдельного регистратора для органов власти. Законопроект уже готовят.
Please open Telegram to view this post
VIEW IN TELEGRAM
😁105🤷♂10🌚6❤3⚡1🦄1
Please open Telegram to view this post
VIEW IN TELEGRAM
😁58😎7❤4✍1
Please open Telegram to view this post
VIEW IN TELEGRAM
❤66💯10🔥9👍3💊2
Типичный Сисадмин
На фото причины, которые до сих пор не могут договориться об одном формате конфигов для всего. Поэтому мы и не сидим без работы. З.Ы. Руссиновича это не касается, он просто чинит то, что эти трое напридумывали. Типичный 🥸 Сисадмин
Встречаются как-то создатель Linux, два отца Windows NT и отец Sysinternals...
🤔43👍14❤1
AI "Пнул Спящий Рынок Коммутаторов: +32% Роста и Взлет 800 GbE
Рынок сетевых коммутаторов для дата-центров, долгое время пребывавший в стагнации, получил мощный импульс благодаря буму AI. Аналитики IDC зафиксировали в Q1 2025 выручку в $11.7 млрд, что на 32.3% больше год к году. Главный драйвер – развертывание высокоскоростной инфраструктуры с низкой задержкой для поддержки AI-нагрузок.
Доходы от коммутаторов для ЦОД выросли на 54.7% в Q1, ускорившись по сравнению с +32.1% в Q4 2024. Сегмент 200/400 GbE показал рост на 189.7% год к году. IDC также начала отслеживать 800 GbE коммутаторы, которые уже принесли $350.8 млн, быстро заняв 5% рынка.
Главный бенефициар – Nvidia. Её выручка от коммутаторов взлетела на 760.3% год к году, достигнув $1.46 млрд, и на 183.7% по сравнению с Q4 2024. У Arista рост доходов от коммутаторов для ЦОД составил +27.1% ($1.6 млрд). А вот у Cisco доходы от этого сегмента умудрились упасть на 3.2%, что намекает на успешное откусывание доли конкурентами в этом раскаленном сегменте (хотя общая выручка Cisco от коммутаторов выросла на 4.7%).
Рынок коммутаторов для кампусных и филиальных сетей (не ЦОД) тоже подрос, но скромнее – на +9.6%. Выручка от WLAN также показала рост на +10.6% в Q1, что говорит о стабилизации рынка после проблем с поставками из-за COVID-19. И здесь AI также играет роль, стимулируя спрос на новое поколение Wi-Fi (6 GHz) и AI-управляемые решения.
---
Кажется, AI скоро потребует для своей работы персональный интернет-магистраль прямо в стойку. И чтобы без шейпинга!
Типичный🥸 Сисадмин
Рынок сетевых коммутаторов для дата-центров, долгое время пребывавший в стагнации, получил мощный импульс благодаря буму AI. Аналитики IDC зафиксировали в Q1 2025 выручку в $11.7 млрд, что на 32.3% больше год к году. Главный драйвер – развертывание высокоскоростной инфраструктуры с низкой задержкой для поддержки AI-нагрузок.
Доходы от коммутаторов для ЦОД выросли на 54.7% в Q1, ускорившись по сравнению с +32.1% в Q4 2024. Сегмент 200/400 GbE показал рост на 189.7% год к году. IDC также начала отслеживать 800 GbE коммутаторы, которые уже принесли $350.8 млн, быстро заняв 5% рынка.
Главный бенефициар – Nvidia. Её выручка от коммутаторов взлетела на 760.3% год к году, достигнув $1.46 млрд, и на 183.7% по сравнению с Q4 2024. У Arista рост доходов от коммутаторов для ЦОД составил +27.1% ($1.6 млрд). А вот у Cisco доходы от этого сегмента умудрились упасть на 3.2%, что намекает на успешное откусывание доли конкурентами в этом раскаленном сегменте (хотя общая выручка Cisco от коммутаторов выросла на 4.7%).
Рынок коммутаторов для кампусных и филиальных сетей (не ЦОД) тоже подрос, но скромнее – на +9.6%. Выручка от WLAN также показала рост на +10.6% в Q1, что говорит о стабилизации рынка после проблем с поставками из-за COVID-19. И здесь AI также играет роль, стимулируя спрос на новое поколение Wi-Fi (6 GHz) и AI-управляемые решения.
---
Кажется, AI скоро потребует для своей работы персональный интернет-магистраль прямо в стойку. И чтобы без шейпинга!
Типичный
Please open Telegram to view this post
VIEW IN TELEGRAM
❤20💯6🍾5
Please open Telegram to view this post
VIEW IN TELEGRAM
😁78✍7❤1🦄1
Forwarded from godnoTECH - Новости IT
Nvidia Инвестирует в Ядерную Энергию для AI
Nvidia (через фонд NVentures) вложилась в TerraPower – ядерный стартап Билла Гейтса, разрабатывающий малые модульные реакторы (SMR). Цель – обеспечить энергией растущие аппетиты AI-датацентров. В раунде на $650 млн также участвовал HD Hyundai.
Пилотная АЭС Natrium (345 МВт + 1 ГВт хранилище) в Вайоминге ожидается к 2030 году, но регуляторное одобрение еще не получено. Другие техгиганты (AWS, Google, Microsoft, Oracle) также активно смотрят в сторону SMR. Для Nvidia это логичный шаг: больше энергии – больше проданных GPU.
Однако SMR – технология дорогая, медленная и рискованная (NuScale уже свернули проект). Скептики сомневаются в их экономической целесообразности.
Главное, чтобы SMR не начали "троттлить" из-за перегрева💥
🥸 godnoTECH - Новости IT
Nvidia (через фонд NVentures) вложилась в TerraPower – ядерный стартап Билла Гейтса, разрабатывающий малые модульные реакторы (SMR). Цель – обеспечить энергией растущие аппетиты AI-датацентров. В раунде на $650 млн также участвовал HD Hyundai.
Пилотная АЭС Natrium (345 МВт + 1 ГВт хранилище) в Вайоминге ожидается к 2030 году, но регуляторное одобрение еще не получено. Другие техгиганты (AWS, Google, Microsoft, Oracle) также активно смотрят в сторону SMR. Для Nvidia это логичный шаг: больше энергии – больше проданных GPU.
Однако SMR – технология дорогая, медленная и рискованная (NuScale уже свернули проект). Скептики сомневаются в их экономической целесообразности.
Главное, чтобы SMR не начали "троттлить" из-за перегрева
Please open Telegram to view this post
VIEW IN TELEGRAM
Terrapower
TerraPower Announces $650 Million Fundraise
TerraPower announced the close of a $650 million fundraise. This fundraise was comprised of both new investors, including NVentures, and current investors, including Bill Gates and HD Hyundai.
❤16🤔7🌚2🔥1
Please open Telegram to view this post
VIEW IN TELEGRAM
❤75😭24🙏9💯9🌚4🔥1
Что делать, если MySQL/MariaDB переросла один сервер? Стратегии масштабирования 🎹
Вопрос, который рано или поздно встает перед многими: что предпринять, когда база данных MySQL или MariaDB становится слишком большой и нагруженной для одного хоста, а простое увеличение CPU/RAM уже не помогает? По следам недавнего обсуждения, инициированного коллегой, собрал пул эффективных стратегий и практических советов.
Первым и часто самым логичным шагом является внедрение репликации и разделение нагрузки, особенно на чтение. Если ваше приложение генерирует значительно больше запросов на чтение, чем на запись (например, в соотношении 90/10), добавление реплик (read replicas) и направление на них части трафика через приложение или с помощью ProxySQL может дать существенный выигрыш. ProxySQL, к слову, полезен на любом этапе, так как способен кешировать запросы и управлять пулами соединений, снижая нагрузку даже на одиночный мастер-сервер.
Когда нагрузка на запись становится значительной (приближаясь к соотношению 50/50 или даже преобладая), стоит рассмотреть решения для multi-master кластеризации, такие как Galera Cluster. Эта технология, встроенная в MariaDB и используемая в Percona XtraDB Cluster (PXC), обеспечивает синхронную репликацию и повышает доступность. Однако важно помнить, что хотя Galera помогает с масштабированием записи, все узлы в кластере по-прежнему должны обрабатывать все транзакции, что может стать ограничением.
Для действительно огромных нагрузок, особенно смешанных или с преобладанием записи, следующим шагом может стать шардинг. Технологии вроде Vitess предоставляют инструменты для горизонтального масштабирования путем разделения данных на множество независимых баз (шардов). Альтернативно, шардинг можно реализовать на уровне приложения, но это требует серьезных изменений в коде и усложняет многие операции, например, поиск по всем данным.
Не стоит забывать и об оптимизации и кешировании на уровне приложения. Часто лучший запрос – это тот, который не пришлось делать. Прежде чем бросаться в масштабирование инфраструктуры, необходимо убедиться, что все запросы к базе данных максимально эффективны, используются правильные индексы, а частые данные кешируются, например, с помощью Redis. Иногда корень проблемы кроется в неэффективной логике самого приложения, требующей пересмотра.
В некоторых случаях рассматривается переход на другие СУБД. PostgreSQL часто упоминается за его зрелые возможности кластеризации и хорошую масштабируемость на одном узле. Для специфических MySQL-совместимых распределенных решений есть TiDB, а для аналитических нагрузок, убивающих традиционные реляционные базы, — ClickHouse. Однако смена СУБД – это всегда большой проект, и важно понимать, что ни одна из них не является "волшебной палочкой".
Прежде чем приступать к масштабным изменениям, критически важно понять характер вашей нагрузки: соотношение операций чтения и записи, самые тяжелые запросы, наличие кешируемого контента. Часто проблема, формулируемая как "как масштабировать MySQL", на самом деле является проблемой XY, скрывающей необходимость оптимизации приложения или самих запросов к базе. Опыт показывает, что некоторые решения, например, master-master репликация на бинарных логах или InnoDB Clusters, могут быть нестабильны в продакшене, в то время как Galera Cluster считается более надежным для multi-master конфигураций.
Идеального решения не существует, есть только наиболее подходящее для ваших текущих задач🎩
Типичный🥸 Сисадмин
Вопрос, который рано или поздно встает перед многими: что предпринять, когда база данных MySQL или MariaDB становится слишком большой и нагруженной для одного хоста, а простое увеличение CPU/RAM уже не помогает? По следам недавнего обсуждения, инициированного коллегой, собрал пул эффективных стратегий и практических советов.
Первым и часто самым логичным шагом является внедрение репликации и разделение нагрузки, особенно на чтение. Если ваше приложение генерирует значительно больше запросов на чтение, чем на запись (например, в соотношении 90/10), добавление реплик (read replicas) и направление на них части трафика через приложение или с помощью ProxySQL может дать существенный выигрыш. ProxySQL, к слову, полезен на любом этапе, так как способен кешировать запросы и управлять пулами соединений, снижая нагрузку даже на одиночный мастер-сервер.
Когда нагрузка на запись становится значительной (приближаясь к соотношению 50/50 или даже преобладая), стоит рассмотреть решения для multi-master кластеризации, такие как Galera Cluster. Эта технология, встроенная в MariaDB и используемая в Percona XtraDB Cluster (PXC), обеспечивает синхронную репликацию и повышает доступность. Однако важно помнить, что хотя Galera помогает с масштабированием записи, все узлы в кластере по-прежнему должны обрабатывать все транзакции, что может стать ограничением.
Для действительно огромных нагрузок, особенно смешанных или с преобладанием записи, следующим шагом может стать шардинг. Технологии вроде Vitess предоставляют инструменты для горизонтального масштабирования путем разделения данных на множество независимых баз (шардов). Альтернативно, шардинг можно реализовать на уровне приложения, но это требует серьезных изменений в коде и усложняет многие операции, например, поиск по всем данным.
Масштабировать MySQL, не оптимизировав запросы, – это как пытаться выиграть гонку на машине с квадратными колесами, просто доливая в нее больше бензина🚘
Не стоит забывать и об оптимизации и кешировании на уровне приложения. Часто лучший запрос – это тот, который не пришлось делать. Прежде чем бросаться в масштабирование инфраструктуры, необходимо убедиться, что все запросы к базе данных максимально эффективны, используются правильные индексы, а частые данные кешируются, например, с помощью Redis. Иногда корень проблемы кроется в неэффективной логике самого приложения, требующей пересмотра.
В некоторых случаях рассматривается переход на другие СУБД. PostgreSQL часто упоминается за его зрелые возможности кластеризации и хорошую масштабируемость на одном узле. Для специфических MySQL-совместимых распределенных решений есть TiDB, а для аналитических нагрузок, убивающих традиционные реляционные базы, — ClickHouse. Однако смена СУБД – это всегда большой проект, и важно понимать, что ни одна из них не является "волшебной палочкой".
Прежде чем приступать к масштабным изменениям, критически важно понять характер вашей нагрузки: соотношение операций чтения и записи, самые тяжелые запросы, наличие кешируемого контента. Часто проблема, формулируемая как "как масштабировать MySQL", на самом деле является проблемой XY, скрывающей необходимость оптимизации приложения или самих запросов к базе. Опыт показывает, что некоторые решения, например, master-master репликация на бинарных логах или InnoDB Clusters, могут быть нестабильны в продакшене, в то время как Galera Cluster считается более надежным для multi-master конфигураций.
Идеального решения не существует, есть только наиболее подходящее для ваших текущих задач
Типичный
Please open Telegram to view this post
VIEW IN TELEGRAM
✍32❤8👍6🔥2
Начиная с июня 2025 (обновление 24H2), автоматические точки восстановления Windows 11 будут удаляться через 60 дней вместо прежних 90. Изменение затронет все будущие версии, включая 25H2.
— Автоточки (создаваемые системой перед обновлениями) теперь «живут» всего 2 месяца;
— Ручные точки (созданные пользователем) не ограничены и хранятся, пока есть место на диске;
— Если сбой проявится позже 60 дней после обновления — откатиться через автоточку будет нельзя.
Официально Microsoft это сделала для оптимизации дискового пространства. Неофициально (по мнению PCWorld) — подталкивает пользователей к облачным бэкапам OneDrive.
Типичный
Please open Telegram to view this post
VIEW IN TELEGRAM
😡46👍10❤4
Please open Telegram to view this post
VIEW IN TELEGRAM
😁143❤10🌚6😎2🔥1
Forwarded from Linux / Линукс
Коллега поделился по-настоящему странной проблемой, с которой столкнулся после обновления нескольких виртуальных машин Ubuntu Server. Эта история – отличный пример того, какими непредсказуемыми могут быть трудовые будни, и как важно иногда просто сравнить конфиги.
Началось все с рутинной задачи: обновления старых Ubuntu серверов. Два из них, работавшие на версии 18.04, потребовали двух последовательных циклов
Самое мистическое в этой ситуации было то, что если загрузиться в консоль восстановления, а затем выбрать опцию "продолжить обычную загрузку", система волшебным образом стартовала и работала как ни в чем не бывало. Две из двадцати виртуальных машин демонстрировали идентичное поведение, что добавляло загадочности. Админ перепробовал многое: проверил конфигурации, вручную обновил тип виртуальной машины, пересобрал initramfs, обновил GRUB – но ничего не помогало, кроме этого странного обходного пути через rescue-консоль. Подозрение падало на конфигурацию самой ВМ, так как даже live-образ Ubuntu 22.04 на этих машинах загружался с трудом.
В ходе поисков решения были отброшены различные гипотезы: нехватка места на
Разгадка пришла, когда автор сделал то, что, по его собственному признанию, "нужно было сделать еще прошлой ночью": он сравнил (
Как именно конфигурация виртуальной видеокарты могла повлиять на доступ к диску при загрузке – остается небольшой загадкой, но это яркий пример того, что при крупных обновлениях операционных систем могут меняться поддержка или поведение различных моделей виртуального оборудования. Старые конфигурации виртуальных машин не всегда переносятся без сюрпризов.
Linux / Линукс🥸
Началось все с рутинной задачи: обновления старых Ubuntu серверов. Два из них, работавшие на версии 18.04, потребовали двух последовательных циклов
do-release-upgrade. Однако после второго апгрейда, до версии 22.04, обе эти виртуальные машины наотрез отказались нормально загружаться, просто зависая на старте. Логи намекали на проблемы с монтированием корневого раздела /dev/vda1.Самое мистическое в этой ситуации было то, что если загрузиться в консоль восстановления, а затем выбрать опцию "продолжить обычную загрузку", система волшебным образом стартовала и работала как ни в чем не бывало. Две из двадцати виртуальных машин демонстрировали идентичное поведение, что добавляло загадочности. Админ перепробовал многое: проверил конфигурации, вручную обновил тип виртуальной машины, пересобрал initramfs, обновил GRUB – но ничего не помогало, кроме этого странного обходного пути через rescue-консоль. Подозрение падало на конфигурацию самой ВМ, так как даже live-образ Ubuntu 22.04 на этих машинах загружался с трудом.
В ходе поисков решения были отброшены различные гипотезы: нехватка места на
/boot, проблемы с fstab или udev (хотя и пробовались разные варианты монтирования), ошибки файловой системы. Kernel panic при обычной загрузке указывал на невозможность найти корневой раздел, который, тем не менее, прекрасно находился при старте через rescue-режим.Разгадка пришла, когда автор сделал то, что, по его собственному признанию, "нужно было сделать еще прошлой ночью": он сравнил (
diff) XML-файл конфигурации проблемной виртуальной машины (/etc/libvirt/qemu/server.xml) с аналогичным файлом работающей ВМ. И вот оно! В секции <video> у проблемных машин был указан тип модели vmvga. Простое изменение `vmvga` на `qxl` немедленно решило проблему! Виртуальные машины стали загружаться штатно.Как именно конфигурация виртуальной видеокарты могла повлиять на доступ к диску при загрузке – остается небольшой загадкой, но это яркий пример того, что при крупных обновлениях операционных систем могут меняться поддержка или поведение различных моделей виртуального оборудования. Старые конфигурации виртуальных машин не всегда переносятся без сюрпризов.
Linux / Линукс
Please open Telegram to view this post
VIEW IN TELEGRAM
🫡82👀11❤10🤔6🔥5👍3
Исследователи из Akamai нашли способ вырубать криптомайнерские ботнеты, не трогая легитимные пулы. В отчёте описаны две техники, которые используют особенности протокола Stratum и политики самих пулов. Всё сводится к тому, чтобы валить прокси или кошелёк злоумышленника через фродовые действия, имитируя поведение майнера.
Первая методика — "bad shares". Она работает, если у атакующего используется прокси-сервер между ботами и пулом. Исследователи подключаются к этому прокси как будто обычные майнеры и начинают слать плохие шары (некорректные результаты). Прокси не валидирует их как надо и пробрасывает в пул. В ответ пул банит прокси, и вся ботнет-сеть идёт на паузу — загрузка CPU у жертвы падает с 100% до нуля.
Вторая техника нацелена на ситуации, когда майнер напрямую подключён к публичному пулу без прокси. Если кошелёк связан более чем с 1000 активных воркеров, пул может временно заблокировать его. Akamai использовали инструмент, который запускает более 1000 соединений с одним и тем же кошельком. В результате — часовой бан кошелька, остановка добычи. Правда, тут всё откатывается, как только атака прекращается.
Для этого Akamai разработали собственный тул XMRogue, который маскируется под легитимного майнера, шлёт плохие шары и сносит прокси или кошелёк с пула. Всё это уже протестировано на Monero, но подход можно адаптировать и под другие коины.
Легитимный майнер поправит кошелёк и IP за пару минут. А вот ботнету с десятками тысяч узлов придётся делать рефакторинг всей архитектуры. И как показывает практика, у дешёвых криптоопераций на это просто нет рук.
Типичный😎 Сисадмин
Первая методика — "bad shares". Она работает, если у атакующего используется прокси-сервер между ботами и пулом. Исследователи подключаются к этому прокси как будто обычные майнеры и начинают слать плохие шары (некорректные результаты). Прокси не валидирует их как надо и пробрасывает в пул. В ответ пул банит прокси, и вся ботнет-сеть идёт на паузу — загрузка CPU у жертвы падает с 100% до нуля.
Вторая техника нацелена на ситуации, когда майнер напрямую подключён к публичному пулу без прокси. Если кошелёк связан более чем с 1000 активных воркеров, пул может временно заблокировать его. Akamai использовали инструмент, который запускает более 1000 соединений с одним и тем же кошельком. В результате — часовой бан кошелька, остановка добычи. Правда, тут всё откатывается, как только атака прекращается.
Для этого Akamai разработали собственный тул XMRogue, который маскируется под легитимного майнера, шлёт плохие шары и сносит прокси или кошелёк с пула. Всё это уже протестировано на Monero, но подход можно адаптировать и под другие коины.
Легитимный майнер поправит кошелёк и IP за пару минут. А вот ботнету с десятками тысяч узлов придётся делать рефакторинг всей архитектуры. И как показывает практика, у дешёвых криптоопераций на это просто нет рук.
Типичный
Please open Telegram to view this post
VIEW IN TELEGRAM
👍38❤15🔥2🏆1🫡1😡1
США рассматривают вариант отзыва спецразрешений на поставки технологий и оборудования для заводов TSMC, Samsung и SK Hynix в КНР. Если статус Validated End User (VEU) аннулируют, производителям чипов придётся пробираться к американскому «железу» через бюрократические дебри.
Речь идёт об оборудовании, необходимом для выпуска полупроводников — от смартфонов до серверов. Рынок уже отреагировал: поставщики техники в минусе, а акции Micron (прямой конкурент) — в плюсе.
Сами производители пока молчат. А власти США называют это «подготовкой на случай провала торгового соглашения» и обещают больше контроля ради «равных условий». Поставки редкоземельных из Китая тоже под вопросом — без них полупроводниковая отрасль не поедет.
Типичный
Please open Telegram to view this post
VIEW IN TELEGRAM
👎16😁5👀3❤2
alpine, а внутрь монтируется /hostroot, то есть корень хост-системы. Это даёт злоумышленнику возможность модифицировать файлы на хосте и выйти за пределы контейнера.Внутри нового контейнера запускается Base64-зашифрованный скрипт, который ставит Tor и тянет дальнейшие инструкции с onion-домена. Весь трафик, включая DNS-запросы, уходит через
socks5h, что затрудняет отслеживание и блокировку C&C-инфраструктуры. После разворачивания запускается docker-init.sh, который проверяет наличие примонтированного /hostroot, настраивает удалённый доступ по SSH с root-правами и добавляет ключ злоумышленника в ~/.ssh/authorized_keys.Дальше ставятся masscan, libpcap, zstd, torsocks и отправляется информация о системе на C&C. В завершение загружается бинарник-дроппер, который запускает XMRig с готовой конфигурацией, кошельком и пулом.
Атаки нацелены на компании в сфере технологий, финансов и здравоохранения. Это продолжение общей тенденции — использовать дыры в облачной инфраструктуре для криптоджекинга. Параллельно с этим, исследователи из Wiz нашли сотни валидных секретов в
.env, mcp.json, AI-конфигах и ноутбуках Jupyter, включая данные от Fortune 100 компаний. Всё это превращается в подарок для атакующих — особенно если ноутбук содержит результаты кода, связанные с конкретной организацией.Контейнер с Tor и майнером? Ну хоть не WordPress с phpMyAdmin — уже прогресс
Типичный
Please open Telegram to view this post
VIEW IN TELEGRAM
❤15🤯8🔥3👏2
Forwarded from IT-Мемасы от Эникея
Почему люди ждут бесплатной IT-помощи? 😩
Коллега поднял наболевшую тему о том, почему многие ожидают от IT-специалистов бесплатной помощи так, будто это само собой разумеющееся?
Да и айтишники в этой беде не одиноки. Действительно, механики, врачи (особенно стоматологи, урологи и ветеринары), юристы и даже историки регулярно сталкиваются с просьбами быстренько помочь или просто посоветовать в нерабочее время и бесплатно.
Многие айтишники нашли спасение в священном бартере – обмене услугами с друзьями и знакомыми других профессий (сосед – механик, я ему с компьютерами, он мне с машиной – идеально!). Такой подход работает, когда обе стороны ценят навыки друг друга и готовы к взаимовыгодному сотрудничеству.
Чтобы отбиться от назойливых просьб, бывалые выработали целый арсенал отмазок. Я встречал такой топ: "Извини, я работаю с серверным оборудованием в дата-центрах, про домашний Windows/MacOS я мало что знаю" (классика, даже если это не совсем правда), "Я специализируюсь на бэкенд-коде, а не на пользовательской стороне" или "Моя экспертиза – хранилища данных на сотни дисков, для домашнего ПК могу лишь посоветовать купить M2 SSD". Ну и конечно, фраза "Мой час стоит 5к, минимальный заказ – 2 часа. Какая у вас проблема?" часто действует отрезвляюще.
Со временем многие приходят к необходимости устанавливать четкие границы и учиться говорить "нет". Особенно утомляют просьбы от дальних знакомых или ситуации, когда родственники дарят твои профессиональные услуги своим друзьям без твоего ведома. Защита личного времени становится приоритетом для тех, кто и так почти 24/7 на связи по рабочим вопросам.
Однако не все так категорично. Помогать друзьям и близким – это нормально, ведь в этом и заключается дружба. "Я спрашиваю друзей-финансистов про инвестиции и проценты, они меня – про IT. Ключевое здесь – взаимность и разумные пределы. Одно дело – ответить на вопрос или дать совет, и совсем другое – выполнять полноценную работу бесплатно, особенно если это занимает много времени.
Но в конечном счете проблема не столько в специфике IT, сколько в людях и их желании получить что-то бесплатно, особенно если это касается нематериального интеллектуального труда. Важно ценить свой труд и время, уметь устанавливать границы, развивать взаимовыгодный бартер и помнить, что вы не обязаны быть круглосуточной бесплатной техподдержкой для всего мира.
А как вы справляетесь с такими просьбами? 👇
IT-Мемасы от Эникея🫡
Коллега поднял наболевшую тему о том, почему многие ожидают от IT-специалистов бесплатной помощи так, будто это само собой разумеющееся?
Да и айтишники в этой беде не одиноки. Действительно, механики, врачи (особенно стоматологи, урологи и ветеринары), юристы и даже историки регулярно сталкиваются с просьбами быстренько помочь или просто посоветовать в нерабочее время и бесплатно.
Многие айтишники нашли спасение в священном бартере – обмене услугами с друзьями и знакомыми других профессий (сосед – механик, я ему с компьютерами, он мне с машиной – идеально!). Такой подход работает, когда обе стороны ценят навыки друг друга и готовы к взаимовыгодному сотрудничеству.
Чтобы отбиться от назойливых просьб, бывалые выработали целый арсенал отмазок. Я встречал такой топ: "Извини, я работаю с серверным оборудованием в дата-центрах, про домашний Windows/MacOS я мало что знаю" (классика, даже если это не совсем правда), "Я специализируюсь на бэкенд-коде, а не на пользовательской стороне" или "Моя экспертиза – хранилища данных на сотни дисков, для домашнего ПК могу лишь посоветовать купить M2 SSD". Ну и конечно, фраза "Мой час стоит 5к, минимальный заказ – 2 часа. Какая у вас проблема?" часто действует отрезвляюще.
Со временем многие приходят к необходимости устанавливать четкие границы и учиться говорить "нет". Особенно утомляют просьбы от дальних знакомых или ситуации, когда родственники дарят твои профессиональные услуги своим друзьям без твоего ведома. Защита личного времени становится приоритетом для тех, кто и так почти 24/7 на связи по рабочим вопросам.
Однако не все так категорично. Помогать друзьям и близким – это нормально, ведь в этом и заключается дружба. "Я спрашиваю друзей-финансистов про инвестиции и проценты, они меня – про IT. Ключевое здесь – взаимность и разумные пределы. Одно дело – ответить на вопрос или дать совет, и совсем другое – выполнять полноценную работу бесплатно, особенно если это занимает много времени.
Но в конечном счете проблема не столько в специфике IT, сколько в людях и их желании получить что-то бесплатно, особенно если это касается нематериального интеллектуального труда. Важно ценить свой труд и время, уметь устанавливать границы, развивать взаимовыгодный бартер и помнить, что вы не обязаны быть круглосуточной бесплатной техподдержкой для всего мира.
А как вы справляетесь с такими просьбами? 👇
IT-Мемасы от Эникея
Please open Telegram to view this post
VIEW IN TELEGRAM
❤43💯31👍10🔥1