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

Как стать QA с нуля и выйти на оффер от 150 К/мес За годы в IT я прошёл путь от первых шагов до Senior QA. И знаю, как это выглядит изнутри: Сначала не знаешь, с чего начать, и тонешь в инфе Потом учишься, стараешься, но на собесах всё равно валишься А дальше работа вроде есть, а зарплата годами стоит на месте И всё время кажется, что проблема в тебе. Но чаще всего проблема не в мотиваци, а в отсутствии системы. Именно её я и выстраивал все эти годы: через ошибки, отказы и набитые шишки — пока не дошёл до офферов от X5, .bank, Bars Group и VL Projects. А теперь собрал этот опыт в понятный маршрут и делюсь им в канале: – как стартовать и расти в QA – как наработать опыт для резюме – как готовиться к собеседованиям – как проходить отбор увереннее – как выйти на оффер от 150К/мес Подписывайся, пройдём этот путь вместе Подписаться #реклама 16+ edqa.ru О рекламодателе

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

Увлечённые игрой в хорошей компании, этот пост для вас. Мы делаем кастомные фигурки и миниатюры: • По вашему фото • По подробному описанию персонажа • По референсам из игр и аниме Что можно заказать: • Своего D&D-персонажа (любого класса, расы и вооружения) • Главного героя из любимой игры • Аниме-персонажа или OC в стиле аниме • Персональную миниатюру себя в стиле киберпанка, фентези • Миниатюры для всей партии — чтобы на столе было эпично Высокая детализация, качественная покраска, прочные материалы. Подойдёт и для стола в D&D, и для полки в геймерской комнате, и как коллекционный арт-объект. • Идеальный подарок себе, тиммейту или мастеру на день рождения 🎲 В канале прямо сейчас идёт КОНКУРС! Напиши в комментариях подробное описание своего персонажа (D&D, игра, аниме — не важно) — и у тебя есть шанс выиграть бесплатную кастомную миниатюру этого героя!

Управляемый хаос   Много лет информационные системы строились, да и строятся, по принципу борьбы с отказами. Давайте купим «надежное» брендовое серверное железо, аппаратный RAID с батарейкой, корпус с дублирующим блоком питания и т.д. и т.п.   Все это должно уберечь нас от отказа, который в нашей парадигме – чрезвычайное происшествие со всеми вытекающими последствиями и оргвыводами.   И самое печальное в этом, что нашему брату админу тут форменный цугцванг. Чтобы ты не делал, любой твой ход только ухудшает ситуацию.   Купил недостаточно брендовое или вообще десктопное железо? А мы говорили, а мы предупреждали, надо было…   Сделал ровно наоборот? И отказ таки приключился? А теперь поясни, дорогой наш друг, ради чего мы выделили на это все такие большие деньги…   Поэтому современный подход - Design for Failure (Проектирование с расчетом на сбои) – исходит совершенно из обратных посылов. Сбои – это неотъемлемая часть нашей жизни, как природные явления за окном, бороться с ними невозможно, тем более предотвращать.   Все что может сломаться – сломается, все что может упасть – упадет, любой кто может накосячить – накосячит.   И это не выдумки теоретиков, это то, к чему пришли гиганты индустрии: Google, Facebook или Netflix. Они честно признались в том, что не могут бороться с отказами, но могут бороться с их последствиями.   Отсюда были выведены основные принципы: 🔹 Сбои неизбежны (Assume Failure): Все, что может сломаться (железо, сеть, стороннее API, человеческий фактор), обязательно сломается. Это не баг, это закон природы.   🔹 Изоляция отказов (Bulkheading): Проблема в одном модуле не должна лавинообразно уничтожать всю систему. Если «легла» рекомендательная система, корзина и оплата должны продолжать работать. 🔹 Контролируемая деградация (Graceful Degradation): Если система не может отдать пользователю идеальный результат, она должна отдать «приемлемый». Например, вместо пустой страницы показать закешированные вчерашние данные.   🔹 Автоматическое восстановление (Self-Healing): Система должна уметь сама перезапускать упавшие контейнеры, переключаться на резервные копии баз данных и отсекать проблемные узлы без звонка дежурному админу в 3 часа ночи.   И все это легко переносится на админские будни. Мы не можем обеспечить 100% надежность, брендовое железо может оказаться бракованным, аппаратный RAID развалит массив из-за бага в прошивке, ПО ляжет из-за бага в обновлении. И, наконец, добро пожаловать самая неизвестная переменная – человек, которому свойственно ошибаться.   Попытка строить системы, которые почти никогда не упадут на таком фундаменте обречены на провал. А вот исходить из того, что все упадет и сломается (или будет сломано) – трезвый современный подход.   И все инструменты для этого у администратора есть: кластеризация, HA, виртуализация и контейнеризация, распределенные хранилища, инфраструктура как код.   Да, местами сложно, местами непривычно, но именно это современное IT,  с его управляемой деградацией и способностью к самовосстановлению. Сервер СУБД сожрал всю память? Он не уронит весь стек, а просто упадет сам, а балансировщик переключит на вторую активную ноду. Сам же контейнер будет перезапущен или вообще пересоздан из эталона. И это лучше, чем слать алерт администратору в три часа ночи.   Резко выросла нагрузка? Кластер сам перераспределит нагрузку между нодами. Упала нода? Остальные подхватят упавший флаг, да сервис деградирует, но продолжит работать. Тормозит? Да! Но работает ведь! Клиенты не уходят, бизнес-процессы не останавливаются.   И админ спит ночами спокойно, упало – да и пес с ним, завтра в рабочее время разберется, нет необходимости вскакивать посреди ночи, брать такси (выпил вечером банку пива) и нестись, теряя ботинки в серверную.   Да и вообще в этой парадигме ломать полезно, у Netflix есть Chaos Monkey – специальный скрипт который в рабочее время в случайном порядке ломает ноды или виртуалки, что помогает инженерам найти слабые места в инфраструктуре и устранить их до тех пор, пока это станет проблемой.

Если Bash уже не справляется — пора изучить Python Рано или поздно каждый инженер сталкивается с задачами, где Bash уже недостаточно. Нужно обработать логи, поработать с API, разобрать JSON, автоматизировать рутину или написать удобный инструмент для команды. И здесь начинается Python. Но чтобы начать использовать его в работе, не нужно тратить месяцы на изучение теории. Мы подготовили бесплатный гайд «Python за 60 минут для инженера», в котором вы: ✔️разберётесь с основами Python; ✔️научитесь писать простые автоматизирующие скрипты; ✔️поймёте, как читать чужой код; ✔️увидите, где Python действительно помогает инженеру. ➡️ Забирайте гайд бесплатно в боте и сделайте первый шаг к автоматизации своих задач

Gemini PRO практически даром На рынке аккаунтов появилось интересное предложение Gemini PRO на 18 месяцев за смешные 200-300 руб. Честно. Без обмана. Но в чем подвох, ведь не может быть все так прекрасно? А подвох в том, что это специальная акция от индийского телеком-гиганта Jio для своих пользователей. Но технически это никто не проверяет. А продавцам это ничего не стоит, предложение бесплатное. Поэтому и цена символическая. Но тем не менее все нормально активируется и работает на текущий аккаунт, даже если у него регион отличается от Индии. Риски? Как без них, Google может в любой момент проверить правомерность владения подпиской и заблокировать «левые» аккаунты и примеры тому уже были, не так давно массовый бан пущенных «налево» аккаунтов устраивал Perplexity. С другой стороны, даже если и забанят – не жалко. Главное – не увлекаться, в смысле не забивать халявные 5 ТБ диска, идущие в комплекте с подпиской. А остальное некритично, можно спокойно пережить. Как найти? На любой площадке ищем Gemini PRO на 18 месяцев. Нормальная цена 200-300 руб.

malloc - устройство памяти в системном программировании Поймёте, как устроено динамическое выделение памяти в системных программах Зарегистрироваться #реклама 16+ otus.ru О рекламодателе

Что не так со скрипом Васи? Предположений было довольно много, но большинство указанных и неуказанных в опросе, но всплывшие в обсуждении недостатки не являются фатальными. Основной и очень грубой ошибкой является использование для получения списка файлов команды ls, также все сказанное далее в полной мере относится и к find. Обе эти команды созданы для интерактивного взаимодействия с оператором и не предназначены для использования в скриптах. Почему? В обсуждении было приведено несколько хороших ссылок на подробные материалы, правда на английском, но даже с переводчиком смысл будет понятен. Мы же остановимся коротко на основных проблемах. 🔹 Первая и самая очевидная - пробелы, имя файла с пробелами превратится в набор строк, каждая из которых будет обрабатываться скриптом отдельно. И если в данном примере это относительно безопасно, то в реальных сценариях это может привести к абсолютно непредсказуемым последствиям. Например, в нашей практике мы сталкивались со скриптом, который таким образом подсчитывал количество файлов в папке, потом сортировал их по дате создания и удалял самые старые, чтобы осталось всего N-файлов. Файл с пробелами в имени сразу грубо ломает эту логику и может привести к удалению нужных данных. Обернуть ls *.mp4 в кавычки тоже не даст результата, так как в этом случае в качестве единой строки будет использоваться весь вывод команды. 🔹Вторая проблема – возможное наличие в имени файла управляющих и подстановочных символов. На практике встречается гораздо реже, но так как Linux вполне допускает подобные имена, то вы вполне можете с ними столкнуться, например, они могут появиться в результате ошибок в работе скриптов. Допустим у вас есть набор файлов: 1Сезон-1Серия.mp4, 1Сезон-2Серия.mp4 и т.д. и туда случайным образом затесался файл где имя состоит из единицы и звездочки за ним. Символ звездочки будет расценен как подстановочный и ls подставит туда все попадающие под маску файлы. В результате все ваши серии попадут в вывод два раза. Как мы уже говорили, если в данном случае это безопасно, то в других сценариях может привести к различным негативным эффектам. 🔹Третья основная проблема – символы национальных алфавитов. Сейчас эта проблема отошла на второй план, но актуальной быть от этого не перестала. А причина все таже – ls и find рассчитаны на то, чтобы выводить информацию на экран. А далее все зависит от установленной локали, если локаль не содержит символа, соответствующего его коду, то на его месте появится «крякозябкрик» или знак вопроса в ромбе, иди еще что-нибудь, а также такой символ может быть просто пропущен. 👆 Теперь о том, как сделать правильно. В оболочках POSIX, которым относится bash и его производные, есть функция позволяющая использовать в именах файлов символы подстановки, поэтому вывод никаких дополнительных команд анализировать не нужно, а переменную следует обязательно обернуть в кавычки:

for file in ./*.mp4; do
    mv -f “$file” /new_path/video        
done

В этом случае корректно будут отработаны и пробелы, и спецсимволы, и символы национальных алфавитов. Также можно подстраховаться и добавить проверку на существование файла:

for file in ./*.mp4; do
   [ -e "$file" ] || continue
    mv -f “$file” /new_path/video        
done

Если указанный файл не существует, то цикл пропустит текущую итерацию и перейдет к следующей.   👉 P.S. Почему мы заострили внимание именно на этой проблеме, а не на проверке наличия папки и наличия закрывающего слеша? Потому что это архитектурный баг скрипта, а остальное – частный случай с неправильной конфигурацией окружения. Если Вася проследит, чтобы папка на момент запуска скрипта существовала – проблем у него не возникнет, никогда и никаких. А вот использование ls/find для поиска файлов - это 100% проблема, заложенная архитектурно.   Если же Вася отразит в документации, мол перед запуском скрипта обязательно проверьте наличие целевой папки, то это уже будет не баг, а фича.

AI уже умеет писать код. Следующий шаг — поручить ему код-ревью. Большинство разработчиков используют AI как продвинутый автокомплит. Но агенты уже умеют выполнять полноценные инженерные задачи: проверять pull request, искать баги, следить за стилем и безопасностью кода. На бесплатном воркшопе покажут, как собрать такого агента своими руками и встроить его в GitHub. Что будет на практике: 🔹 Настроите AI-ревьюера на Opencode и AGENTS.md; 🔹 Разберётесь, как работают MCP, Tools и Skills; 🔹 Подключите агента к репозиторию; 🔹 Протестируете его на реальном pull request; 🔹 Получите готовый workflow, который можно использовать после воркшопа. Подойдёт разработчикам, тимлидам, DevOps, QA и всем, кто хочет внедрять AI в реальные процессы разработки, а не просто общаться с чат-ботами. 21 июля, 19:00 (МСК). Участие бесплатное. Записаться → #реклама О рекламодателе

У Васи есть папка с закачками, куда он скачивает без разбора всякое разное, и чтобы каждый раз не разбирать ее руками он пишет скрипт, который будет автоматически перемещать видеоролики в другую папку:

for file in $(ls *.mp4); do 
    mv -f $file /new_path/video         
done

Что не так с этим скриптом? 👇 Ответы в опросе ниже 👇

Продуктовые новости от команды @coreinfra Поддержали вышедшую серию GPT-5.6 моделей в AI Hub: Sol, Terra и Luna. Модели, по первым впечатлениям – замечательные: устанавливают новый фронт Парето на большинстве бенчмарков. С одной стороны – в 3 раза более дешевая альтернатива Fable (Sol), с другой – более дешевая альтернатива GLM (!!!, Luna). Факт, который понравился – это то, что это первые модели, добившиеся ненулевых результатов в ARC-AGI-3, и даже выиграли одну игру:

Sol at max reasoning effort is the only performant model (as of July 2026) averaging 13.33% on Public and 7.78% on Semi-Private. It is the first model to win an ARC-AGI-3 public game (ft09, 87%).

Бонус: поддержали фишки, необходимые для корректной работы нового Codex App ChatGPT Work, в т.ч. auto permissions! Computer use – просто магия, с офисными документами можно работать из коробки – очень впечатляет!

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

P = I *U

Как видим, формула линейно зависит как от напряжения, так и от тока. Теоретически мы можем играть от обеих сторон, но это чисто теоретически. Вернемся к нашей аналогии, давайте возьмем мощность в 1200 Вт, для 12 В это будет ток в 100 А, а для 400 В всего в 3 А. Ну и что? А снова вернемся к воде, для выполнения одной и той же работы нам нужно или 3 куба воды или 100 кубов. Есть разница? А что будет, если у нас что-то пойдет не так, и эта вода неконтролируемо растечется? Ну три куба спокойно по канавке стекут в ближайшую реку, а вот 100 кубов способны наделать бед. И вода веде не просто течет на условную мельницу, кроме полезной работы она делает и совсем не полезную – подмывает берега, переносит грунт. Так и ток, протекая через проводники он их нагревает, потому как проводники обладают некоторым сопротивлением, приводящим к потерям. А так как работу выполняет именно ток, то мощность, выделяемая на сопротивлении (а любой проводник – это сопротивление) рассчитывается по формуле:

P = I^2 * R

В нашем случае результат будет отличаться на порядки, хотя полезная мощность нагрузки не изменится. Так при сопротивлении проводника в 1 Ом и полезной нагрузке 1200 Вт при 400 В и 3 А потери в проводнике составят всего 9 Вт, не мало, но и не много, обычный пассивный радиатор проблему решит. А вот при 12 В и 100 А на этом же проводнике в виде тепла выделится 10 кВт, которые нам нужно или куда-то деть (отопить помещение) или у нас начнет гореть и плавиться сам проводник, плата под ним, соседние детали, корпус. Хотя на самом деле такого тока в этой цепи возникнуть не может и больше 12 А там не потечет. Закон Ома, но и 144 Вт – это уже не шутки, без активного охлаждения не обойтись. Поэтому нормальный путь – это повышение напряжения, грубо говоря повысив напряжение в 2 раза и на столько же уменьшив ток, при одной и той же мощности нагрузки, мы уменьшаем потери в 4 раза. Именно поэтому магистральные ЛЭП сплошь высоковольтные. Но бесконечно увеличивать напряжение мы не можем, ток, он как вода, ищет любую дырочку. И при определенной разности потенциалов он может заставить электроны начать упорядоченное движение даже в непроводящей среде. Для бытовой техники с допусками по влажности и наличии в воздухе пыли принято считать, что 1 см воздуха пробивается 1 кВ напряжения. А это создает ненужные риски. Поэтому импульсные блоки питания работают на уровне примерно 400 В – золотой середине, потери падают квадратично и можно отлично экономить на сечении проводов, размере компонентов и теплоотводов, но не подвергая себя риску электрического пробоя. А все высокотоковые цепи стараются разместить как можно ближе к потребителю, не даром на материнской плате VRM прижат как можно ближе к сокету. Потому что мизерные напряжения питания процессора обуславливают крайне высокие токи. Повысить напряжение мы не можем, так как уменьшение технологического процесса требует понижения напряжения, во избежание электрического пробоя. Меньше напряжение – больше ток и квадратично большее тепловыделение, которое и стало главным ограничивающим фактором роста частот и быстродействия современной электроники.

Проектирование сетей ЦОД: от плана до схемы за 1 вебинар 20 июля в 20:00 – вебинар по проектированию сетей ЦОД. Узнаете, как не запутаться в Underlay vs Overlay, применять суммаризацию, использовать unnumbered и выбирать уровни. Сможете спроектировать адресное пространство IPv4/IPv6 с нуля. Пошаговый пример. Регистрируйтесь сейчас! ✅ Узнать больше #реклама 16+ otus.ru О рекламодателе

Как устроен и работает брандмауэр Windows Брандмауэр Windows впервые был представлен в 2001 году вместе с выходом SP2 для Windows XP, а современный облик приобрел вместе с выходом Windows Vista, но не смотря на столь преклонный возраст для многих он до сих пор остается чем-то непонятным. Такую ситуацию нельзя считать нормальной, как и полное отключение брандмауэра. Поэтому сегодня мы рассмотрим, как устроен и работает брандмауэр Windows, как он взаимодействует с пользователем и как следует составлять и читать его правила. Мы уже не раз и не два говорили, что Microsoft имеет талант давать своим продуктам неудачные названия, которые очень часто становятся еще хуже при переводе на другие языки. Так и в этом случае, основной рабочий интерфейс брандмауэра называется Монитор брандмауэра Защитника Windows в режиме повышенной безопасности. Длинно, мудрено и еще повышенную безопасность зачем-то приплели, но другого графического интерфейса для управления брандмауэром в Windows нет. Попасть в него можно классическим путем через Панель управления - Брандмауэр Защитника Windows - Дополнительные параметры. Туда же туда ведут несколько разных путей, например, через свойства сетевых подключений, но в разных версиях Windows эти пути могут быть различны и нами не рассматриваются. ✅ Читать далее: https://interface31.ru/post/kak-ustroen-i-rabotaet-brandmauer-windows/

Infrax — это современная платформа для корпоративного управления, коммуникаций и автоматизации внутренних процессов компании. В новой версии Infrax мы сделали важный шаг вперёд — представляем NODYX. Это корпоративный портал со встроенным конструктором бизнес-процессов, который помогает компаниям быстрее настраивать рабочие сценарии, автоматизировать согласования, распределять задачи и выстраивать прозрачное взаимодействие между подразделениями. Что нового: — единая цифровая среда для сотрудников; — встроенный конструктор бизнес-процессов без сложной разработки; — гибкая настройка маршрутов согласования и задач; — удобный корпоративный портал для новостей, документов и внутренних сервисов; — больше контроля, прозрачности и скорости в ежедневной работе. Новая версия Infrax с NODYX — это не просто обновление, а новый уровень цифровой зрелости компании. infrax.ru #реклама О рекламодателе

Раз уж подняли тему ИБП, то повторим. Так как знают не все и продолжают покупать дорого ИБП с малой емкостью батарей, но большой мощностью и удивляться. Как правильно выбрать ИБП Сегодня столкнулись с тем, что не все наши коллеги умеют правильно выбрать ИБП и рассчитать приблизительное время работы оборудования. Большинство, выбирая ИБП, исходят из его мощности, полагая что чем больше мощность, тем дольше будет держать ИБП. Что абсолютно неверно. Почему? Начнем с того, что такое мощность. Мощность это способность электрического тока выполнить определенную работу. Потребляемая (активная) мощность электроприборов выражается в Ваттах (Вт, W). При этом в сетях переменного тока реальная потребляемая мощность может быть выше активной мощности устройства, так как существует еще и реактивная емкость, связанная с емкостной и индуктивной составляющей устройства. Поэтому в таких случаях принято говорить о полной мощности, которая измеряется в Вольт-Амперах (ВА, VA) и именно ее указывают для ИБП. Чтобы правильно рассчитать полную мощность нам нужно знать коэффициент фазового сдвига, вносимый устройством, а это сделать довольно непросто. Поэтому упростим себе задачу и будем считать, что полная мощность компьютера или периферийного устройства больше активной мощности в 1,4 раза.

 S = 1,4 * P

Таким образом, если средний офисный ПК потребляет 200 Вт активной мощности, то полную мощность такого устройства следует принять за 280 ВА. Мощность ИБП показывает предельную мощность подключенных устройств и не более того. Грубо говоря, к ИБП на 650 ВА мы можем подключить только два условных ПК, а к ИБП на 850 ВА – уже три. Превышение мощности приведет к перегрузке ИБП и отключению нагрузки. А что же у нас со временем? А время у нас напрямую зависит от двух параметров: емкости батареи, которую измеряют в Ампер-часах (А-ч, Ah) и током потребления нагрузки (читай – мощностью). Вычислить время можно по приблизительной формуле:

 t = E * U / S

Где E – емкость АКБ, U – напряжение батареи АКБ, S – полная мощность нагрузки. Результат получим в часах. Если мы возьмем две реальные модели ИБП: ▫️ DEXP CEE-E 650VA – 2999 руб. ▫️ DEXP CEE-E 850VA – 3799 руб. То может показаться, что приобретение второй модели для нашего условного ПК предпочтительнее, как-никак на целых 200 ВА больше. Но оба ИБП имеют в составе единственную батарею 12 В, 7 А-ч, это стандартная батарея, все их знают. Теперь считаем:

 t = 7 * 12 / 280 = 18 минут

Если нагрузить оба этих ИБП почти по полной, т.е. подключить к первому два условных ПК, а ко второму три, то время работы от батареи составит 9 и 6 минут соответственно. Но это идеальная цифра, в реальности добавим сюда КПД инвертора и потерю емкости батареями, поэтому полученную цифру следует уменьшить примерно на 25-30%. Это будет примерно объективной оценкой времени на которое вы можете рассчитывать. При этом, обратите внимание, более мощный бесперебойник обеспечивает меньшее время работы чем менее мощный, но обеспечивает более высокий ток для нагрузки. Кому-то это может показаться парадоксальным, но это факт: при использовании одного и того же набора аккумуляторных батарей с увеличением мощности ИБП время работы в автономном режиме будет падать. И тем более нет смысла в покупке более мощного ИБП если ваша нагрузка позволяет купить менее мощный, время работы от этого не увеличится, а вы просто выбросите деньги на ветер.

Хотите сгореть – купите б/у ИБП Короткая, но поучительная история от коллеги. Не так давно в новую стойку ему понадобился ИБП, новый стоит дорого, поэтому купили на Авито Powercom без батарей. Внешне все хорошо, докинули батарейки – все работает. До тех пор пока на выходных в здании не делали что-то с электрикой, несколько раз включая и отключая свет, чем загнали ИБП в глубокий разряд. А понедельник встретил их в офисе непередаваемым запахом паленого пластика, который исходил как раз от ИБП. Батареи фактически кипели и что ничего не загорелось и не сгорело – это вопрос везения. Сначала не поняли, взяли новые батареи – все норм, немного разрядили – тоже вроде все нормально. Но стоило только посадить батареи практически полностью, как у ИБП снова включился режим кипятильника. Хорошо сэкономили. Рынок б/у – это всегда лотерея и есть вещи, с которыми в лотерею лучше не играть, ИБП – одна из таких вещей.

Этим летом родители могут бесплатно записать школьников на программу обучения программированию. Курс познакомит с ИТ-профессиями, научит разрабатывать на Python, создавать 3D-игры и мультфильмы. Участники получат именные сертификаты – они помогут при поступлении в вуз и в будущей карьере. Трёхдневный интенсив проводит федеральная школа «Алгоритмика» (лауреат премии «Бренд года‑2024», участник Сколково). Преподаватели – практики из Яндекса, Сбера и Иннополиса. Запись открыта только до конца недели. Чтобы участвовать, выберите направление по возрасту и оставьте заявку на сайте: https://tglink.io/f557958b044e38?erid=2W5zFGYkrqw Количество мест ограничено. #реклама О рекламодателе