Эксперты в подборе IT-оборудования
Возраст сервера сам по себе ничего не говорит. Сервер не ломается строго на пятый год. Один работает восьмой год в углу серверной и тихо раздаёт файлы. Другой меняют на третий год, потому что вендор закрыл поддержку, а без свежих прошивок и патчей держать его в production уже страшно. Поэтому вопрос «сколько лет служит сервер» правильнее переформулировать: до какого момента его выгодно и безопасно держать.
Когда говорят «срок службы сервера», обычно мешают в кучу три разные вещи. Разведём их - дальше будет проще.
Технический срок - пока железо физически работает. Тут серверы живучие: качественная серверная платформа спокойно тянет 7-10 лет, если есть запчасти и нормальное охлаждение.
Экономический срок - пока держать старый сервер дешевле, чем поставить новый. Считается по общей сумме: ремонт, простои, электричество, время админа. Один чек за сервер тут ничего не решает.
Налоговый срок - амортизация. По бухгалтерии сервер списывается за 2-3 года (об этом отдельно в конце). Но списанный по налогу сервер не превращается в хлам: он продолжает работать, и это нормально.
Главная путаница - между этими сроками. «Сервер уже самортизирован, пора менять» - так себе логика: бухгалтерия и реальная жизнь железа идут по разным календарям. И наоборот: «он же ещё включается» - тоже плохой довод, если поддержки давно нет. Дальше - почему.
Интуиция подсказывает, что серверы меняют, когда они ломаются. В жизни крупный парк чаще обновляют по другой причине: заканчивается поддержка - вендорская, операционной системы, прошивок. Железо ещё бодрое, а вот жить с ним в production становится рискованно.
Тут нельзя путать три разные границы.
Разница принципиальная. Кончилась гарантия - не повод паниковать, сервис можно продлить или обслуживать своими силами. Наступил EOL - ещё спокойно живём, поддержка идёт. А вот EOSL - это красный флаг для боевых систем: с этого момента дыры в прошивке и BMC уже никто не закроет, а сломавшийся блок питания придётся искать на вторичном рынке.
Конкретные даты EOSL у каждой модели свои - их публикуют сами вендоры и сервисные компании в специальных базах. Перед планированием замены парка стоит просто свериться: какие из ваших серверов уже за этой чертой.
Ещё одна причина, по которой «срок службы» - понятие растяжимое: компоненты сервера стареют с разной скоростью. Процессор без движущихся частей может пережить две-три волны всего остального. А вот механика и расходники уходят первыми.
| Компонент | Как стареет | Чем ловить заранее |
|---|---|---|
| Жёсткие диски | механический износ, рост числа переназначенных секторов | мониторинг SMART, отслеживание ошибок |
| Вентиляторы | падают обороты, растёт шум и вибрация, подшипники изнашиваются | контроль оборотов через BMC/IPMI |
| Блоки питания | деградация конденсаторов, просадки под нагрузкой | логи питания, резервный второй БП |
| Батарея RAID-контроллера | теряет ёмкость - кэш записи отключается | статус контроллера, журнал событий |
| Процессор, чипсет | почти не деградируют, «устаревают» морально | сравнение с требованиями новой нагрузки |
Вывод простой: «живой» сервер обычно упирается не в нехватку вычислительной мощности, а в расходники и отказоустойчивость. Диск, вентилятор, блок питания - вот что заставляет нервничать раньше, чем процессор перестанет тянуть. И как раз эти вещи можно менять по отдельности, продлевая жизнь машине. Раннее предупреждение даёт диагностика дисков по SMART и контроль оборотов вентиляторов через BMC - сервер обычно подаёт сигналы заранее, если за ними следить.
Ставить всему парку единый срок «три года» или «пять лет» - удобно для отчёта, но неверно по сути. Сервер под гипервизором с десятком виртуалок и файловая помойка для бухгалтерии живут по очень разным календарям.
| Роль сервера | Ориентир цикла | Почему так |
|---|---|---|
| Гипервизор, СУБД, нагруженный 1С | короче | высокая нагрузка, критичность, требования новых версий ОС и ПО |
| Контроллер домена, почта, шлюз | средний | критичность по доступности, но нагрузка умеренная |
| Файловый сервер, печать, архив | длиннее | низкая нагрузка, нетребовательность к свежему железу |
| Тестовый стенд, песочница | самый длинный | некритично, туда часто и уходит «пенсионное» железо |
Отсюда и здравая практика: старое, но рабочее железо не выбрасывают - спускают вниз по иерархии. Сервер, отслуживший своё под боевой базой, ещё годы проживёт файловым хранилищем или тестовым стендом. Парк обновляется ролями, постепенно - так заметно мягче для бюджета.
Прежде чем считать бюджет на замену, стоит выжать из имеющегося железа всё, что оно может дать. Тема не сводится к «купите новое» - грамотное обслуживание спокойно добавляет серверу пару лет здоровой жизни.
Ни один из этих пунктов не требует капитальных вложений. Зато вместе они сдвигают момент замены вправо и убирают из жизни админа класс внезапных аварий.
Решение «пора менять» лучше принимать по конкретным сигналам, без оглядки на то, что сервер просто «старенький». Честные триггеры такие:
Экономику можно прикинуть на пальцах. Сложите за год стоимость обслуживания, потери от простоев и счёт за электричество для старого сервера. Когда эта сумма начинает подбираться к заметной доле цены нового сервера - дальше держать старое уже невыгодно. Точную границу каждый ставит под себя, но сам подсчёт отрезвляет: иногда «бесплатный» старый сервер на деле обходится дороже нового.
Между «терпеть как есть» и «купить новое» есть середина - апгрейд. Иногда точечная модернизация продлевает жизнь дёшево, иногда это деньги на ветер. Граница проходит по платформе.
Апгрейд оправдан, когда узкое место - не процессор: добавить оперативной памяти, поставить SSD или NVMe вместо старых дисков, обновить сетевую карту до 10 Гбит. Платформа остаётся, а машина получает второе дыхание под выросшую нагрузку. Хороший пример - апгрейд дисковой подсистемы, который часто снимает основной тормоз.
Менять стоит, когда упёрлись в поколение. Если для роста нужен другой процессор, а его уже не поставить в эту платформу; если материнская плата не держит нужный объём памяти; если сама модель в EOSL - вкладывать в неё деньги бессмысленно. Апгрейдить сервер, который через год останется без поддержки, - всё равно что ставить новую резину на машину перед сдачей в утиль.
Для домашнего файлового сервера довод «работает - не трогай» вполне годится. Для production-системы он опасен. Вот что стоит за сервером, оставшимся без поддержки.
Незакрытые уязвимости. После EOSL вендор не выпускает патчи и прошивки. Каждая новая найденная дыра в BMC, BIOS или микрокоде остаётся открытой навсегда. Для системы, доступной из сети, это накапливающийся риск, который однажды выстрелит.
Проблемы с аудитом и комплаенсом. Неподдерживаемое железо и ОС - частое замечание при проверках информационной безопасности. Если вы работаете с персональными данными, требования по защите подразумевают актуальные, обновляемые системы - сервер без патчей этому противоречит. «Зато дёшево» аудитора не убеждает.
Долгий простой при отказе. Когда оригинальных запчастей нет, а схема обслуживания не продумана, поломка превращается из «поменяли деталь за час» в «ищем по всему рынку три дня». Для бизнеса это уже не экономия, а лотерея.
«Работает же» - это про сегодня. Риск EOL - про тот день, когда перестанет, и окажется, что чинить нечем, а защищаться поздно. Заодно полезно периодически пересматривать инфраструктуру целиком - например, по чек-листу из материала как улучшить работу IT-инфраструктуры.
Многие компании держат серверы и за пределами поддержки - и это рабочий вариант, если делать его с открытыми глазами. Между «терпеть до аварии» и «срочно менять весь парк» есть третья опция: продлить жизнь железу сознательно.
Что для этого нужно:
Удобный источник запчастей и недорогих доноров - восстановленные серверы того же поколения. Тот же модельный ряд на вторичном рынке закрывает и потребность в ЗИП, и временную замену, пока вы планируете полноценное обновление. Это, кстати, и одна из причин, по которой бизнес осознанно покупает серверы с пробегом.
Если же вы дошли до решения менять - дальше начинается отдельная история про перенос данных и сервисов. Как это сделать без потерь, разбираем в материале про замену сервера и перенос данных.
Отдельно про бухгалтерский угол, потому что половина запросов «срок службы сервера» приходит от тех, кому нужен срок для амортизации.
Для налогового учёта сервер относят к электронно-вычислительной технике, 2-я амортизационная группа, код ОКОФ 330.28.23.23. Срок полезного использования для этой группы - от 25 до 36 месяцев, то есть 2-3 года. За это время сервер списывается в расходы.
Но налоговый срок полезного использования и реальный срок службы - разные вещи. 25-36 месяцев - это про то, как быстро стоимость сервера переносится в затраты для налога, а не про то, когда железо физически выйдет из строя. Полностью самортизированный сервер сплошь и рядом работает ещё годы. Так что для решения «менять или нет» бухгалтерский срок - не аргумент, ориентируйтесь на поддержку, риски и экономику.
Срок службы сервера - не про возраст и не про дату амортизации. Технически серверы живут 7-10 лет, по бухгалтерии списываются за 2-3 года, а менять их выгоднее всего тогда, когда заканчивается поддержка (EOSL), растут расходы на обслуживание и электричество или железо перестаёт тянуть нагрузку. Продлить жизнь парку помогают простые вещи: чистота и охлаждение, мониторинг SMART и журналов, резервные БП и вентиляторы, своевременные прошивки и тесты восстановления. А когда поддержки уже нет - довод «работает же» перестаёт работать: незакрытые уязвимости и отсутствие запчастей в production обходятся дороже нового сервера.
Технически - 7-10 лет при нормальном обслуживании и наличии запчастей. Практический ориентир обновления парка - 3-5 лет, но это не жёсткая норма: решает не возраст, а поддержка, риски и экономика.
Нет. Пять лет - распространённый ориентир, а не приговор. Если сервер ещё на поддержке, тянет нагрузку и обходится дешевле замены - он спокойно работает дальше. Менять стоит, когда наступает EOSL или экономика разворачивается не в его пользу.
2-я амортизационная группа, код ОКОФ 330.28.23.23, срок полезного использования 25-36 месяцев. Это налоговый срок для списания, он не равен реальному сроку службы железа.
Апгрейд оправдан, когда узкое место - память, диски или сеть, а платформа ещё актуальна. Менять стоит, когда упёрлись в поколение процессора или модель ушла в EOSL - вкладываться в железо без будущей поддержки невыгодно.
Можно, но осознанно: со своим запасом запчастей, понятной схемой обслуживания и готовностью к более долгому простою при отказе. Для некритичных ролей это нормально, для боевых систем с доступом из сети - рискованно из-за незакрытых уязвимостей.
